여러 지역의 문서 충돌을 가장 큰 timestamp로 해결합니다. last-write-wins는 어떤 변경을 잃을 수 있나요?

벽시계가 큰 값이 실제로 마지막에 발생한 변경이라는 보장은 없습니다. LWW는 충돌을 결정적으로 선택하는 정책일 수 있지만 사용자의 의도나 인과관계를 모두 보존하는 정책은 아닙니다.

동작 원리와 전제

시계가 빠른 A의 옛 수정이 B의 나중 수정을 덮을 수 있습니다. 미래 timestamp가 들어오면 이후 정상 변경이 오랫동안 밀릴 수도 있습니다. 동점 처리와 시각 검증을 정하고 시계 동기화만으로 완전 해결됐다고 하지 않습니다.

선택과 실패 처리

중요 문서는 버전 조건·벡터 시계의 동시 변경 감지·사용자 병합을 검토합니다. CRDT가 맞는 데이터도 있지만 임의 텍스트의 의미 병합을 자동 해결하지는 않습니다. 단일 권위 저장소의 순서가 필요한 기능과 잠정 지역 변경을 구분합니다.

구체적인 사례와 검증

수정 X가 실제로 먼저 일어났지만 시계가 5분 빠른 서버에서 생성되면 이후 정상 시각의 수정 Y가 계속 무시될 수 있습니다. 단순히 NTP를 켰다고 모든 순간의 오차와 점프가 사라지는 것은 아닙니다. 서버가 허용하는 미래 범위와 이벤트 출처를 검증하고 변경 손실을 감사할 이력을 남깁니다. 논리 시계를 쓰면 인과 순서를 표현할 수 있지만 동시 문서 수정의 의미상 병합은 여전히 필요합니다. LWW를 택할 수 있는 설정·선호 데이터와 금전·권리처럼 손실이 허용되지 않는 데이터를 구분합니다. 충돌을 숨기는 단순 정책이 어떤 사용자 변경을 버렸는지 추적 가능해야 합니다.

시계 점프·동시 수정·지연 메시지·재생을 시험합니다. 최종 수렴뿐 아니라 사라진 변경과 감사·복구 가능성을 확인합니다. 간단한 충돌 정책을 선택할 수는 있지만 그 대가인 변경 손실을 명시하겠습니다.