Clock Skew란 무엇인가
Clock Skew(시계 오차)는 여러 서버가 각자 가지고 있는 시스템 시계가 서로 다른 시각을 가리키는 현상을 말합니다. 하나의 서버에서 동작하는 애플리케이션이라면 시간 개념이 단순하지만, 분산 시스템에서는 수십, 수백 대의 서버가 각자의 하드웨어 클록을 기준으로 동작하기 때문에 시간이 조금씩 어긋나는 일이 자연스럽게 발생합니다.
비유하자면, 여러 명이 각자 다른 손목시계를 차고 마라톤 기록을 재는 상황과 같습니다. 실제로는 A가 B보다 늦게 도착했더라도, A의 시계가 몇 초 빠르게 맞춰져 있다면 기록상으로는 A가 먼저 도착한 것처럼 보일 수 있습니다. 분산 시스템에서도 이런 착시가 발생하면 이벤트의 순서, 즉 인과관계가 뒤바뀌어 기록될 수 있습니다.
동작 원리와 발생 예시
서버의 시계는 NTP(Network Time Protocol) 같은 프로토콜로 주기적으로 동기화되지만, 완벽하게 일치시키는 것은 불가능합니다. 네트워크 지연, 하드웨어 크리스탈 오실레이터의 미세한 오차, NTP 서버 접근 실패 등 다양한 이유로 서버 간 수 밀리초에서 심하면 수 초까지 시간 차이가 발생할 수 있습니다.
예를 들어 분산 데이터베이스에서 각 노드가 자신의 로컬 타임스탬프를 기준으로 트랜잭션 순서를 기록한다고 가정해봅시다. 노드 A에서 데이터를 먼저 쓰고, 노드 B에서 나중에 값을 수정했더라도, B의 시계가 A보다 느리게 설정되어 있다면 타임스탬프상으로는 B의 쓰기가 더 이전 것으로 기록됩니다. 이 경우 나중에 값을 병합하거나 충돌을 해결할 때 실제로는 최신 데이터인 B의 값이 오래된 데이터로 오인되어 덮어써지는 문제가 생길 수 있습니다.
대표적으로 구글의 Spanner 데이터베이스는 이런 문제를 해결하기 위해 ‘TrueTime’이라는 API를 도입해 시계 오차의 범위(불확실성 구간)를 명시적으로 다루고, 트랜잭션 커밋 시 그 오차만큼 대기하는 방식으로 순서를 보장합니다.
실무에서 왜 중요한가
Clock Skew를 제대로 고려하지 않으면 다음과 같은 문제가 실무에서 발생할 수 있습니다.
- 분산 락(lock)의 만료 시간이 서버마다 다르게 계산되어 동시에 두 프로세스가 락을 획득하는 상황
- 로그나 이벤트의 시간 순서가 뒤섞여 디버깅이 어려워지는 상황
- 캐시 만료(TTL) 시점이 서버별로 달라 데이터 정합성이 깨지는 상황
이런 이유로 실무에서는 물리적 타임스탬프에만 의존하기보다 Lamport Timestamp나 Vector Clock 같은 논리적 시계 개념을 함께 사용하거나, NTP 동기화 상태를 모니터링하며 오차 허용 범위를 설계에 반영합니다. 결국 Clock Skew는 없앨 수 없는 물리적 한계이므로, 이를 인정하고 시스템 설계 단계에서 대비하는 것이 분산 시스템 안정성의 핵심입니다.