오늘은 분산 시스템에서 자주 사용되는 일관성 모델인 Eventual Consistency (최종적 일관성) 에 대해 자세히 공부했다. 실제 대규모 글로벌 서비스에선 이 개념이 성능, 확장성, 사용자 경험을 좌우하는 핵심이라는 걸 느꼈다. 특히 Eventual Consistency는 단순히 느슨한 일관성을 의미하는 게 아니라 의도적으로 일관성을 늦추고 대신 가용성과 확장성을 확보하는 전략이라는 점에서 매우 전략적인 선택이란 걸 알게 되었다.
이러한 전략은 CAP 이론과도 깊은 관련이 있다. CAP 이론은 분산 시스템이 Consistency(일관성), Availability(가용성), Partition Tolerance(네트워크 분할 허용) 중 두 가지만 만족할 수 있으며 세 가지를 동시에 완벽하게 보장할 수는 없다고 말한다. 예를 들어 네트워크 분할(P)이 발생했을 때 시스템은 일관성(C)을 선택할지 아니면 가용성(A)을 유지할지 선택해야 한다. Eventual Consistency는 이 상황에서 가용성과 파티션 허용성을 유지하고 일관성은 일정 시간 뒤에 확보하는 모델이다. 반대로 Strong Consistency는 가용성을 일부 포기하더라도 항상 최신의 정합성을 보장하는 방향을 택한다.
결국 Eventual Consistency는 “정합성을 희생하고 확장성과 장애 대응력을 얻는다”는 전략적 선택이고 Strong Consistency는 “정확성을 우선하며 속도나 가용성은 희생한다”는 선택이다. 분산 시스템을 설계할 때 CAP 이론의 관점에서 어떤 요소를 가장 중요하게 생각하는지에 따라 적용해야 할 일관성 모델이 달라진다는 점을 이해하게 되었다.
개념 이해를 위한 예시: 인스타그램 좋아요 동기화
가장 이해가 잘 됐던 예시는 인스타그램의 '좋아요' 기능이다.
A 유저가 한국에서 어떤 게시글에 '좋아요'를 누르면 그 행동은 A가 연결된 한국 리전의 서버(DB)에 먼저 기록된다. 이 기록은 곧바로 미국이나 일본 등의 다른 리전에 있는 DB로 복제되지만 이 복제는 즉시 동기화가 아닌 비동기 방식으로 늦게 전파된다.
🔄️ 시점별 흐름
-
A가 '좋아요'를 누름
A의 클라이언트는 거의 즉시 반응을 받아 "좋아요 1"로 업데이트되고 이 데이터는 한국 리전의 DB에만 우선 반영된다. -
동시에 미국에 있는 유저 B가 같은 게시글을 조회함
미국 리전의 DB는 아직 복제되지 않았기 때문에 B가 보는 화면엔 "좋아요 0"으로 나오게 된다.
이게 바로 일시적인 데이터 불일치 상태이다. -
몇 초 뒤 백그라운드 복제 완료
좋아요 정보가 미국 리전으로도 전파된다. 이후 B가 새로고침하거나 다른 기기로 접속하면 "좋아요 1"로 보이게 된다. -
결국 모든 서버의 DB가 동일한 상태로 수렴됨
이게 바로 "Eventual Consistency (최종적 일관성)"이다.
✅ 장점
1. 사용자 경험 향상 (즉시 반응)
가장 먼저 느낀 장점은 유저 A는 자신의 행동에 즉시 반응을 확인할 수 있다는 것이다. 좋아요를 누른 뒤 백그라운드에서 모든 글로벌 리전에 동기화되기까지 기다리지 않아도 된다. 사용자 입장에선 빠르게 피드백을 받기 때문에 더 쾌적한 UX를 제공할 수 있다.
2. 글로벌 확장성
이 구조를 채택하면 전 세계 어디에 있든 사용자의 데이터는 가장 가까운 리전에 기록되고 이후에 전파되기만 하면 된다. 이로 인해 물리적 거리나 네트워크 지연 문제를 무시할 수 있고 새로운 리전을 추가하기도 매우 쉬워진다. 즉, 물리적 확장성과 유연성이 극대화된다.
3. 장애 회복력
만약 한국 리전의 DB가 장애로 쓰기 불가 상태가 된다 하더라도 다른 리전에서 쓰기 요청을 계속 받아줄 수 있다. 그리고 나중에 다시 살아났을 때도 복제 메커니즘으로 인해 데이터는 eventually 맞춰진다. 즉, 시스템의 가용성(Availability)이 매우 높아진다.
❌ 단점
1. 일시적인 데이터 불일치
Eventual Consistency는 본질적으로 "모든 리전이 언제나 같은 값을 갖고 있진 않다"는 걸 인정하는 모델이다. 위 예시처럼 B 유저는 같은 시간에 A와는 다른 데이터를 보게 된다. 이건 좋아요, 댓글 같은 정합성이 완화 가능한 기능에서는 괜찮지만 쇼핑몰의 재고, 금융의 잔액, 티켓팅 시스템의 좌석 수 등에서는 치명적인 문제다.
예를 들어 재고가 1개 남은 상품을 두 명이 동시에 결제하면 Eventual Consistency는 시스템에서는 둘 다 성공한 것처럼 처리될 수 있다. 이렇게 되면 중복 결제 발생하고 결국 신뢰도는 하락하게 된다.
2. 복잡한 충돌 해결
예를 들어 A와 B가 동시에 같은 데이터를 다르게 수정한 경우 어느 것이 최종값이 될까?
이건 시스템이 알아서 결정할 수 없기 때문에 충돌 해결 정책을 개발자가 직접 구현해야 한다.
대표적인 전략은 다음과 같다
- Last Write Wins: 가장 최근에 저장된 값 기준
- Vector Clock: 시간/버전 정보를 추적하여 충돌 판단
- Application-defined Resolution: 상황에 맞게 도메인 로직으로 해결 (예: 가장 긴 닉네임?)
하지만 이런 전략을 설계하고 테스트하는 건 꽤나 까다로운 작업이다.
3. 사용자 혼란
실시간 서비스에서 "내가 한 행동이 적용되지 않은 것처럼 보이는 것"은 매우 헷갈리고 답답할 수 있다. A는 분명히 좋아요를 눌렀지만 페이지를 나갔다 와보니 좋아요가 꺼져 있고 다시 눌렀더니 "이미 눌렀습니다" 같은 메시지가 나오게 된다면 UX는 최악이다.
→ 멱등성, 캐시 무효화 전략, 일관성 버퍼 UI 등을 통해 해소 필요
Strong Consistency (강한 일관성)
Eventual Consistency (최종적 일관성)에 대해 공부하면서 자연스럽게 그 반대편에 있는 개념인 Strong Consistency(강한 일관성)도 함께 이해할 필요가 있다고 느꼈다. Strong Consistency는 말 그대로 모든 사용자와 시스템이 항상 동일한 최신 데이터를 조회할 수 있도록 보장하는 모델이다. 누군가가 데이터를 수정하거나 갱신한 순간 그 변경 사항은 전 시스템에 즉시 반영되며 그 이후의 모든 읽기 요청은 반드시 최신 값을 반환해야 한다. 이는 "일관성이 생명"인 도메인에서는 절대적으로 필요한 보장이다.
예를 들어 금융 시스템에서의 잔액 조회나 이체 처리, 티켓팅 시스템의 좌석 예매, 쇼핑몰의 재고 차감 같은 영역에서는 1초라도 잘못된 값을 보여주면 돌이킬 수 없는 문제가 발생할 수 있다. 이럴 때는 아무리 응답 속도가 빨라도 소용없고 데이터 정합성이 무엇보다 우선되어야 한다. 그래서 이런 시스템에서는 RDB의 트랜잭션 처리, Pessimistic Lock, 분산 락(Redisson 등)을 적극적으로 활용하며 여러 노드 간의 합의를 통해 '단 하나의 진실'을 만들고 유지하는 데 집중한다.
Strong Consistency는 이런 면에서 속도와 확장성보다는 정확성과 신뢰성을 추구하는 방향이다. 데이터를 쓰기 위해 락을 걸고 모든 복제본 노드가 변경 내용을 수신한 뒤에야 쓰기 작업을 완료하는 구조이기 때문에 대기 시간이 늘어나고 경우에 따라선 쓰기 병목이 발생하기도 한다. 데이터의 일치가 중요한 서비스에서는 굉장히 좋은 설계이다.
결국 이 모델은 언제, 누구에게든 항상 정확한 데이터를 보여줘야 하는 도메인에서 반드시 필요하며 실시간 일관성과 무결성이 핵심인 환경에서 신뢰를 구축하는 기반이 된다. 그리고 이러한 환경에선 속도보다 정합성을 선택해야 한다는 교훈도 함께 얻게 되었다.
Eventual Consistency vs Strong Consistency 비교
| 구분 | Eventual Consistency (최종적 일관성) | Strong Consistency (강한 일관성) |
|---|---|---|
| 정의 | 시간이 지나면 모든 노드가 동일한 값에 수렴하는 모델 | 모든 트랜잭션이 즉시 전체 노드에 반영되어 항상 동일한 최신 값을 반환 |
| 보장 수준 | 느슨한 정합성 (일시적 불일치 허용) | 강력한 정합성 (항상 최신값 보장) |
| 응답 속도 | 빠름 (쓰기/읽기 응답 속도 빠름) | 느릴 수 있음 (락, 트랜잭션 필요) |
| 쓰기 처리 | 빠르게 로컬 노드에만 기록 후 복제 | 모든 복제본에 반영된 후 쓰기 완료 |
| 충돌 가능성 | 존재함 (충돌 해결 전략 필요) | 없음 (동시성 제어로 방지) |
| 사용자 혼란 | 일시적으로 과거 데이터를 볼 수 있음 | 항상 최신 데이터 확인 가능 |
| 사용 사례 | 좋아요, 알림, 로그 수집, 피드 | 결제, 재고 관리, 좌석 예매, 은행 시스템 |
이처럼 Eventual Consistency와 Strong Consistency는 각자의 장단점이 매우 뚜렷하다. 이제는 아키텍처 설계에서 단순히 “어떤 기술이 좋다”가 아니라, “이 기능이 어느 정도의 정합성을 필요로 하는가?”, “사용자 경험보다 데이터의 정확성이 더 중요한가?”를 먼저 판단한 뒤 그에 따라 적절한 일관성 모델을 적용할 수 있어야 한다. 이러한 시야는 특히 대규모 시스템 설계나 마이크로서비스 분산 환경에서 꼭 필요한 관점이라고 생각한다.
📝 배운점
Eventual Consistency (최종적 일관성)은 단순히 느슨한 일관성을 허용하는 것이 아니라 분산 시스템에서 확장성과 가용성을 극대화하기 위한 전략적인 설계 선택이라는 것을 이번 학습을 통해 이해하게 되었다. 특히 글로벌 서비스를 운영할 때는 "모든 사용자에게 항상 동일한 데이터를 즉시 제공"하는 것이 불가능하거나 그것을 보장하기 위해 성능과 사용자 경험을 희생해야 하는 경우가 많다. 이럴 때 Eventual Consistency는 의도적으로 일관성을 늦춤으로써 응답 속도를 확보하고 장애에도 유연하게 대응할 수 있게 해준다. 예컨대 인스타그램 좋아요 동기화와 같은 사례는 빠른 반응성과 낮은 지연이 중요한 도메인에서는 일관성을 완화하더라도 사용자 경험이 훨씬 더 좋아질 수 있다는 걸 보여준다.
하지만 Eventual Consistency는 만능 해법이 아니라 트레이드오프의 결과라는 점도 분명히 깨달았다. 쇼핑몰 재고나 금융 잔액처럼 일관성이 가장 중요한 도메인에서는 Eventual Consistency는 위험할 수밖에 없고 반드시 Strong Consistency나 트랜잭션 처리가 필요하다. 결국 이 개념을 제대로 활용하려면 내가 다루고 있는 데이터가 "지연돼도 되는 데이터인지", "잠깐 다른 값을 보여줘도 되는 데이터인지"를 먼저 판단할 수 있어야 한다. 그리고 Eventual Consistency를 선택했다면 반드시 충돌 해결 전략, 멱등성 보장, 캐시 설계, 사용자 혼란 방지 UI까지 모두 함께 고민해야 한다는 것도 알게 되었다.
참고
