두 서버의 이벤트를 timestamp로 정렬했더니 나중에 일어난 변경이 먼저 보입니다. 서버 시각만으로 변경 적용 순서를 정해도 되나요?

서로 다른 서버의 timestamp만으로 변경 적용 순서를 정하면 위험합니다. 벽시계는 동기화해도 오차가 남고 조정 중 뒤로 움직일 수 있습니다. 표시용 발생 시각과 권위 있는 커밋 순서를 분리하겠습니다.

시계의 용도

벽시계는 사람에게 보일 날짜·시각이고, 단조 시계는 한 프로세스의 경과 시간을 뒤로 가지 않게 재는 값입니다. 서버 A와 B의 단조 시계를 서로 비교해 전역 순서를 만들 수 없습니다. 로컬 timeout과 retry deadline의 경과 시간은 같은 프로세스의 단조 시계로 계산합니다. 분산 lease의 소유권은 별도의 프로토콜과 저장 지점 검사가 필요합니다.

같은 계정 상태의 순서가 필요하면 권위 저장소의 증가 버전이나 로그 index를 씁니다. 조건부 갱신으로 version = expected를 확인해 늦은 쓰기를 거절할 수 있습니다. 여러 지역이 독립 수정하면 last-write-wins는 단순하지만 중요한 변경을 잃을 수 있고, 논리 시계도 병합 규칙을 대신하지 않습니다.

인과와 표시를 나눈다

메시지를 받은 뒤 만든 이벤트의 인과관계는 논리 시계로 표현할 수 있지만 큰 숫자가 원인이라는 역추론은 못 합니다. 벡터 시계나 HLC를 써도 콘텐츠 병합은 별도 데이터 규칙입니다. 로그에는 벽시계, 요청·작업 ID, 원본·커밋 버전을 함께 남깁니다. 외부에서 온 시각은 미래 값과 재생을 검증합니다.

검증은 서버 시계 오차·점프, 동시 변경, 지연 메시지를 주입해 timeout이 음수가 되지 않는지, 늦은 버전이 새 상태를 덮지 않는지 봅니다. 시계 동기화는 운영 품질을 높이지만 정합성의 유일한 근거가 아닙니다.

경과 시간과 소유권은 다른 문제입니다

서버 A의 단조 시계 100과 B의 90은 같은 기준점에서 시작했다는 보장이 없어 대소 비교로 사건 순서를 만들 수 없습니다. 로컬 timeout은 시작과 끝을 같은 단조 시계로 재고, 다른 프로세스로 넘길 때는 남은 시간 예산을 전달하거나 동기화 오차를 고려한 절대 deadline 계약을 사용합니다. 재부팅 전 단조 시각을 디스크에 저장했다가 새 프로세스에서 그대로 만료 시각으로 쓰는 것도 피해야 합니다.

lease 제공자가 10초 소유권을 줬더라도 작업자가 오래 멈춘 뒤 깨어나면 자기 메모리의 소유권 판단이 낡을 수 있습니다. 단조 시계는 로컬 경과 시간을 계산하는 도구이고, 늦은 쓰기를 막는 것은 저장 지점의 증가하는 펜싱 토큰 검사입니다. 시계 오차·정지·갱신 지연의 가정을 명시하고, 시간 계산만으로 다른 작업자가 이미 얻은 새 소유권을 무효화하지 않겠습니다.

논리 순서도 목적에 맞춰 선택합니다. 단일 계정의 변경은 저장소 버전으로 직렬화할 수 있지만 서로 다른 계정의 버전 7과 9는 전역 선후가 아닙니다. Lamport 시계는 인과 순서를 거스르지 않는 번호를 만들고 벡터 시계는 독립 수정의 동시성을 표현할 수 있습니다. HLC는 물리 시간에 가까운 표시와 논리 증가를 결합하지만 순서 충돌의 업무상 병합 규칙까지 결정하지는 않습니다.