분산 DB의 '시간 문제'를 우아하게 푼 하이브리드 논리 시계(HLC)

분산 데이터베이스에서 '시간'은 왜 이렇게 골치 아플까

서버 한 대로 돌아가는 평범한 데이터베이스라면 '어떤 작업이 먼저 일어났는지'를 따지는 게 어렵지 않아요. 시계 한 번 보면 되니까요. 그런데 데이터베이스가 서울, 도쿄, 프랑크푸르트처럼 전 세계에 흩어져 있다고 생각해보세요. 서버마다 자기 시계를 들고 있는데, 이 시계들이 미세하게 다 어긋나 있거든요. NTP(인터넷으로 시간을 맞추는 프로토콜)로 맞춰도 수 밀리초에서 수십 밀리초씩 차이가 나요. 그 짧은 틈에 두 서버에서 거의 동시에 일이 벌어지면 '진짜로 누가 먼저였나'를 판단할 수가 없어요.

이 문제를 다룬 고전 논문이 바로 버팔로 대학에서 나온 '하이브리드 논리 시계(Hybrid Logical Clocks, HLC)' 연구예요. 2014년에 나왔지만 지금 우리가 쓰는 분산 DB의 핵심 부품이 됐기 때문에, 한 번쯤 제대로 이해해두면 두고두고 쓸모가 있어요.

물리 시계와 논리 시계, 둘 다 반쪽짜리

시간을 다루는 방법은 크게 두 가지예요. 하나는 '물리 시계'예요. 우리가 흔히 아는 벽시계 시간이죠. 장점은 사람이 보기에 직관적이고 실제 시각과 가깝다는 거예요. '오후 3시에 주문이 들어왔다' 같은 게 바로 나오니까요. 단점은 아까 말한 것처럼 서버끼리 어긋난다는 거고요.

다른 하나는 '논리 시계'예요. 1978년 레슬리 램포트가 제안한 램포트 시계가 대표적인데요. 이게 뭐냐면, 실제 시각은 신경 쓰지 않고 '사건의 순서'만 숫자로 매기는 방식이에요. A가 B에게 메시지를 보내면, B의 카운터는 무조건 A보다 커지도록 맞춰요. 그러면 '인과관계'(원인과 결과의 순서)는 절대 뒤집히지 않아요. 대신 이 숫자는 실제 시각과 아무 상관이 없어서, '이 사건이 대략 몇 시에 일어났나'를 알 수가 없어요. 로그를 봐도 언제 일인지 감이 안 오는 거죠.

결국 물리 시계는 '실제 시각은 알지만 순서가 헷갈리고', 논리 시계는 '순서는 정확하지만 실제 시각을 모르는' 반쪽짜리들이에요. HLC의 아이디어는 단순해요. '이 둘을 합쳐버리자'는 거죠.

HLC는 어떻게 동작하나

HLC가 만들어내는 타임스탬프는 두 부분으로 되어 있어요. 하나는 물리 시간에 최대한 가깝게 따라가는 부분이고, 다른 하나는 같은 물리 시간 안에서 사건 순서를 구분해주는 작은 카운터예요.

핵심 규칙은 이래요. 어떤 노드에서 이벤트가 생기면, 자기 물리 시계와 지금까지 본 가장 큰 논리 시간을 비교해서 더 큰 쪽을 따라가요. 물리 시계가 앞서 있으면 그걸 쓰고 카운터는 0으로 리셋하고, 그렇지 않으면 기존 논리 시간을 유지하면서 카운터만 1 올려요. 메시지를 받을 때도 상대방의 타임스탬프와 내 시계를 함께 비교해서 더 앞선 쪽으로 맞춰요. 이렇게 하면 두 가지가 동시에 보장돼요. 첫째, 인과관계가 절대 깨지지 않아요(논리 시계의 장점). 둘째, 이 값이 실제 물리 시각에서 크게 벗어나지 않아요. NTP 오차 범위 안에서만 움직이거든요(물리 시계의 장점).

게다가 이 모든 정보를 64비트 정수 하나에 욱여넣을 수 있어요. 상위 비트에 물리 시간을, 하위 비트에 카운터를 넣는 식이죠. 그래서 기존 타임스탬프 필드를 그대로 쓰면서 적용할 수 있어 실무 도입이 쉬워요. 그리고 이렇게 일관된 타임스탬프가 있으면, 특정 시점의 '일관된 스냅샷'(전 세계 서버의 데이터를 마치 같은 순간에 찍은 사진처럼 읽어오는 것)을 만들 수 있어요. 백업이나 분석 쿼리에서 정말 중요한 기능이죠.

구글 스패너와 비교해보면

비슷한 문제를 구글은 '스패너(Spanner)'에서 '트루타임(TrueTime)'이라는 방식으로 풀었어요. 트루타임은 데이터센터마다 GPS 수신기와 원자시계를 깔아서 시간 오차의 '상한선'을 보장해요. 대신 그 불확실한 구간만큼 일부러 기다렸다가(commit wait) 커밋을 확정하죠. 정확하지만 특수 하드웨어가 필요하다는 게 부담이에요. 아무나 GPS랑 원자시계를 데이터센터에 깔 순 없잖아요.

HLC의 매력은 '특별한 하드웨어가 전혀 필요 없다'는 거예요. 평범한 서버와 NTP만 있으면 소프트웨어만으로 비슷한 효과를 내거든요. 그래서 오픈소스 분산 DB들이 너도나도 채택했어요. 코크로치DB(CockroachDB), 유가바이트DB(YugabyteDB) 같은 분산 SQL 데이터베이스가 HLC를 쓰고, 몽고DB(MongoDB)도 인과적 일관성을 위해 비슷한 개념을 적용했어요. 우리가 쓰는 도구 깊은 곳에 이 논문이 들어가 있는 셈이에요.

한국 개발자에게

요즘은 스타트업도 멀티 리전(여러 지역에 서버를 두는 구성)을 쉽게 굴리는 시대예요. 글로벌 서비스를 만들면 자연스럽게 분산 DB를 만나게 되고요. 그때 'read timestamp', 'causal consistency', 'snapshot' 같은 단어가 튀어나오는데, HLC 개념을 알고 있으면 이게 왜 필요하고 어떻게 동작하는지 단번에 이해돼요. 당장 HLC를 직접 구현할 일은 거의 없겠지만, 내가 쓰는 DB가 시간을 어떻게 다루는지 아는 것과 모르는 것은 장애 대응에서 큰 차이를 만들어요.

분산 시스템의 시간 문제는 '완벽한 동기화는 불가능하다'는 전제에서 출발해요. 그 한계를 인정하고도 실용적인 답을 찾아낸 게 HLC의 멋진 점이고요.

여러분은 분산 환경에서 이벤트 순서 때문에 골치 아팠던 경험이 있나요? 물리 시계만 믿다가 사고 난 적은 없으세요?