API Eventual Consistency (초기 불일치, 데이터 수렴, 비즈니스 영향)
API Eventual Consistency 전략은 분산 시스템에서 데이터 변경이 즉시 모든 노드에 반영되지 않더라도, 일정 시간이 지나면 결국 일관된 상태에 도달하도록 설계하는 방식입니다. 이 전략은 강한 일관성을 유지하기 어려운 대규모 시스템에서 널리 사용되며, 특히 글로벌 서비스 환경에서 확장성과 성능을 확보하는 데 중요한 역할을 합니다.
저는 Eventual Consistency를 공부했을 때, "어차피 나중엔 맞춰지니까 괜찮다"는 말을 너무 가볍게 받아들였습니다. 그게 실제 서비스에서 어떤 문제를 일으키는지 몸으로 겪기 전까지는요. 분산 시스템에서 데이터 일관성을 어떻게 다루느냐는 단순한 이론 문제가 아니라 사용자 신뢰와 비즈니스 손실로 직결되는 문제였습니다.
초기 불일치, 생각보다 훨씬 눈에 잘 뛴다
일반적으로 데이터 변경 직후의 불일치는 잠깐이라 사용자가 잘 못 느낀다고 알려져 있습니다. 그러나 사용자는 생각보다 민감하고, 특히 자기 데이터가 바뀌지 않은 것처럼 보일 때 굉장히 당황합니다.
Eventual Consistency 환경에서는 특정 노드(시스템 내 개별 서버 또는 데이터 저장 단위)에 데이터 변경이 반영되더라도, 다른 노드나 캐시 레이어에는 즉시 전파되지 않습니다. 프로필을 수정했는데 새로고침하면 이전 이름이 뜨는 상황, 저도 직접 재현해 본 적이 있습니다. 처음엔 버그인 줄 알았습니다.
이게 설계상 의도된 동작이라는 걸 이해하고 나서도 찜찜함은 남았습니다. 읽기 트래픽이 쓰기보다 압도적으로 많은 시스템이라면 이 구조가 효율적이라는 건 알겠습니다. 하지만 "효율적"이라는 말이 "사용자가 이상하다고 느끼는 순간을 만들어도 된다"는 뜻은 아니잖습니까. 그 간극을 좁히는 것이 결국 설계자의 역할이라고 생각합니다.
특히 글로벌 서비스에서는 지역 간 네트워크 레이턴시(데이터가 한 지점에서 다른 지점으로 이동하는 데 걸리는 시간 지연)가 존재하기 때문에 이 불일치 구간이 더 길어질 수 있습니다. 서울에서 수정한 데이터가 유럽 리전에 반영되기까지 수 초에서 수십 초가 걸리는 상황은 이론이 아니라 실제입니다.
데이터 수렴 과정, 자동으로 해결된다는 믿음이 위험하다
Eventual Consistency의 핵심 전제는 "시간이 지나면 결국 모든 노드가 같은 값을 갖게 된다"는 것입니다. 비동기 복제(데이터 변경을 실시간이 아닌 별도 타이밍에 다른 노드로 전송하는 방식)나 이벤트 기반 동기화를 통해 변경 사항이 점진적으로 전파됩니다. 이 과정 자체는 맞습니다.
문제는 이 수렴 과정이 항상 깔끔하게 끝나지 않는다는 점입니다. 제가 직접 써봤는데, 서로 다른 노드에서 거의 동시에 같은 레코드를 수정하면 충돌이 발생합니다. 이때 어떤 값을 최종 상태로 채택할 것인지를 정하는 충돌 해결 알고리즘(Conflict Resolution)이 없으면 데이터가 예측 불가능한 상태로 남습니다.
일반적으로 타임스탬프 기반의 LWW(Last Write Wins, 가장 최근 쓰기가 이김) 방식이 많이 쓰인다고 알려져 있습니다. 그런데 이 방식이 실제로 적용될 때 벡터 클록(Vector Clock, 각 노드의 쓰기 순서를 추적해 인과 관계를 보존하는 자료 구조)이 제대로 구현되지 않으면 나중에 쓴 값이 무조건 이긴다는 보장도 없습니다. 클럭 동기화 문제 때문입니다. 솔직히 이건 예상 밖이었습니다. 개념은 단순해 보여도 현실 구현은 생각보다 까다롭습니다.
Eventual Consistency 구조를 도입할 때 수렴 알고리즘을 꼼꼼히 검증해야 하는 이유가 여기에 있습니다. "알아서 맞춰진다"는 막연한 믿음은 위험합니다. 출처: All Things Distributed (Werner Vogels, AWS CTO)에서도 Eventual Consistency는 약속이 아니라 조건부 보장임을 명시하고 있습니다.
비즈니스 영향, 어떤 데이터에 허용할 것인지가 핵심
기술적으로 Eventual Consistency가 필요하다는 건 이해합니다. 그러나 비즈니스 입장에서 이게 어디까지 허용 가능한지는 전혀 다른 이야기입니다. 경험상 이 둘을 구분하지 못한 채 "분산 시스템이니까 일단 Eventual Consistency 적용"이라고 결정하면 반드시 후회할 순간이 옵니다.
가장 대표적인 사례가 재고 관리입니다. 재고 데이터가 즉시 반영되지 않으면 실제로는 재고가 0인 상품이 여러 사용자에게 동시에 주문 가능한 상태로 노출됩니다. 이건 단순한 UX 문제가 아니라 환불 처리, 고객 불만, 운영 비용으로 이어지는 실제 손실입니다. 저도 이 부분에서 한 번 제대로 배웠습니다.
그렇다면 어떤 기준으로 Eventual Consistency 적용 여부를 결정해야 할까요? 제가 실제로 사용하는 분류 기준은 다음과 같습니다.
- 금전·재고·권한처럼 불일치가 실제 손실로 이어지는 데이터 → 강한 일관성(Strong Consistency) 유지
- 좋아요 수, 조회수처럼 약간의 오차가 허용되는 집계 데이터 → Eventual Consistency 적용 가능
- 사용자 프로필, 설정값처럼 중요하지만 즉각성이 절대적이지 않은 데이터 → 읽기 일관성 수준(Read-Your-Writes Consistency)만 보장해도 충분
Read-Your-Writes Consistency란 데이터를 수정한 사용자 본인에게는 변경 결과가 즉시 보이도록 보장하되, 다른 사용자에게는 일정 지연을 허용하는 중간 전략입니다. 모 아니면 도 방식이 아니라, 데이터 종류에 따라 세분화해서 적용하는 것이 현실적입니다.
모니터링도 중요합니다. 동기화 지연이 허용 범위를 초과하거나 수렴 실패가 발생했을 때 빠르게 감지할 수 있는 체계가 없으면, 문제가 이미 사용자에게 노출된 뒤에야 발견하게 됩니다. 이 부분을 나중으로 미루는 경우를 많이 봤는데, 반드시 설계 단계부터 함께 고려해야 합니다.
Eventual Consistency는 분산 시스템에서 피할 수 없는 현실이지만, "언젠가 맞춰진다"는 말을 너무 편하게 받아들이면 반드시 어딘가에서 터집니다. 어떤 데이터에 적용할 것인지, 충돌은 어떻게 해결할 것인지, 사용자에게는 어떻게 보일 것인지를 처음부터 명확히 정의하는 것이 출발점입니다. 이 글을 읽고 지금 설계 중인 시스템의 데이터를 한 번 분류해 보시는 것도 좋을 것 같습니다.
관련 글
댓글
댓글 쓰기