API Strong Consistency 전략은 데이터가 변경되는 즉시 모든 사용자와 시스템에서 동일한 최신 상태를 보장하는 방식입니다. 이 전략은 데이터 정확성이 중요한 시스템에서 필수적으로 요구되며, 사용자가 어떤 시점에서 데이터를 조회하더라도 항상 일관된 결과를 제공하는 것을 목표로 합니다.
재고가 분명히 있다고 떠 있는데 주문을 넣으면 "품절"이 뜨는 상황, 한 번쯤 겪어보셨을 겁니다. 저는 단순한 UI 버그겠거니 했는데 실제 원인을 들여다보니 데이터 일관성 전략의 문제였습니다. 그 이후로 Strong Consistency가 단순한 이론이 아니라, 서비스 신뢰도를 결정짓는 설계 선택이라는 걸 몸으로 배웠습니다.
일관성 전략 : 같은 데이터, 다른 결과
API 설계에서 데이터 일관성 전략은 크게 두 갈래로 나뉩니다. Strong Consistency(강한 일관성)는 데이터가 바뀌는 순간 모든 노드에 즉시 반영되는 방식입니다. 반면 Eventual Consistency(최종적 일관성)는 "언젠가는 같아진다"는 전제 아래, 일시적인 데이터 불일치를 허용합니다.
문제는 이 차이가 사용자에게 어떻게 체감되느냐입니다. 제가 직접 경험한 케이스를 예로 들면, 특정 한정판 상품이 오픈 직후 순식간에 소진됐는데도 일부 사용자에게는 수십 초 동안 "구매 가능" 상태로 보였습니다. Eventual Consistency 구조였기 때문입니다. 그 결과 실제로 결제가 진행된 건수 중 일부가 나중에 강제 취소됐고, 고객 문의가 폭발했습니다.
Strong Consistency 환경에서는 이런 일이 원천적으로 차단됩니다. 재고 데이터가 0이 되는 순간, 그 사실이 모든 시스템에 동시에 전파되기 때문입니다. 같은 데이터를 조회하더라도 어느 노드를 통하든 결과가 동일합니다. 이걸 보장하기 위한 메커니즘이 분산 락(Distributed Lock)과 동기식 복제(Synchronous Replication)입니다.
분산 락은 여러 서버가 동시에 같은 데이터를 수정하지 못하도록 먼저 접근한 쪽이 "자물쇠"를 거는 방식이고, 동기식 복제는 데이터 변경이 모든 복제 서버에 완료됐다는 확인을 받기 전까지 응답 자체를 내보내지 않는 방식입니다. 정확성을 위해 속도를 담보로 잡는 구조라고 보시면 됩니다.
Strong Consistency가 치르는 성능 비용의 실체
Strong Consistency를 적용하고 나서 처음 부하 테스트를 돌렸을 때, 응답 시간이 이전 대비 눈에 띄게 늘어난 걸 보고 당황했습니다. 이론으로는 알고 있었지만 수치로 직접 보니 체감이 달랐습니다.
CAP 정리(CAP Theorem)를 먼저 짚어야 합니다. CAP 정리란 분산 시스템에서 일관성(Consistency), 가용성(Availability), 네트워크 분할 허용성(Partition Tolerance) 세 가지를 동시에 완전히 만족하는 것은 불가능하다는 원칙입니다. Strong Consistency를 선택한다는 건 가용성 일부를 포기하는 쪽으로 저울을 기울이는 결정입니다. 출처: ACM Digital Library - Brewer의 CAP 정리 원문
분산 환경에서 Strong Consistency를 구현하면 다음과 같은 비용이 발생합니다.
- 노드 간 데이터 동기화 과정에서 네트워크 왕복 시간(RTT)만큼 응답이 지연됩니다.
- 트랜잭션이 커밋되기 전까지 해당 데이터에 접근하려는 다른 요청들이 대기 상태로 쌓입니다.
- 일부 노드에 장애가 생기면 동기화 확인이 불가능해져 전체 처리가 멈출 수 있습니다.
- 처리량(Throughput)이 전체적으로 낮아져 동시 요청이 많은 구간에서 병목이 생깁니다.
경험상 이 문제가 가장 크게 터지는 시점은 트래픽이 갑자기 몰리는 순간입니다. 평소에는 멀쩡하다가 이벤트 오픈 직후 수천 건의 요청이 동시에 들어오면, 분산 락을 기다리는 요청들이 큐에 쌓이면서 응답 지연이 연쇄적으로 퍼져나갑니다. 이걸 타임아웃으로 처리하면 그것대로 또 문제가 생깁니다.
그렇다고 Strong Consistency를 포기하는 게 답은 아닙니다. 일관적으로 알려진 것처럼 "성능이 느리니까 쓰지 말자"는 접근은 지나치게 단순합니다. 제 생각에는 성능 비용을 수용할 수 있는 구간과 그렇지 않은 구간을 명확히 가르는 게 핵심입니다.
어느 구간에 Strong Consistency를 써야 하는가
제가 써보면서 내린 결론은, Strong Consistency는 "데이터 오류가 곧 비즈니스 손실"로 이어지는 지점에만 집중적으로 적용해야 한다는 겁니다. 전체 시스템에 획일적으로 씌우면 불필요한 성능 낭비가 생깁니다.
명확하게 Strong Consistency가 필요한 영역은 금융 거래와 결제 처리입니다. 계좌 잔액이 동시에 두 거래에서 다르게 보이면 이중 출금이 발생하고, 이건 법적 책임으로까지 번질 수 있습니다. 재고 관리도 마찬가지입니다. 재고 수량이 실시간으로 정확하게 반영되지 않으면, 없는 상품을 판 뒤 강제 취소라는 최악의 시나리오를 피할 수 없습니다.
반대로 소셜 피드나 조회수, 추천 콘텐츠 같은 영역은 Eventual Consistency로 충분합니다. 게시물 좋아요 숫자가 몇 초 늦게 반영된다고 해서 서비스가 망하지는 않습니다. 이런 곳까지 Strong Consistency를 들이밀면 오히려 시스템 자원을 낭비하는 결과가 됩니다.
실전에서 효과적인 방식은 혼합 전략입니다. 결제·재고처럼 정합성이 생명인 레이어에는 Strong Consistency를 적용하고, 나머지 레이어는 Eventual Consistency로 가져가되 데이터 불일치가 발생했을 때 이를 감지하고 보정하는 보상 트랜잭션(Compensating Transaction) 로직을 별도로 두는 방식입니다. 보상 트랜잭션이란 이미 완료된 작업을 되돌리거나 수정하는 사후 처리 메커니즘으로, Eventual Consistency의 약점을 실무 수준에서 보완해주는 장치입니다.
구글 Spanner나 Amazon DynamoDB의 강한 읽기 일관성 옵션 같은 현대적 데이터베이스들이 이 혼합 접근을 지원하는 방향으로 발전하고 있는 것도 같은 맥락입니다. 출처: Google Cloud - Spanner External Consistency
Strong Consistency는 만능이 아니지만, 써야 할 자리에 쓰지 않으면 서비스 전체의 신뢰가 흔들립니다. 어디에 정확성이 필요하고, 어디까지 지연을 허용할 수 있는지를 먼저 구분하는 것이 설계의 출발점입니다. 전략을 고민하고 있다면 먼저 자신의 서비스에서 "데이터 오류가 실제 손실로 이어지는 지점"이 어디인지부터 짚어보시길 권합니다. 그 지점이 명확해지면, 나머지 선택은 생각보다 단순해집니다.
관련 글
댓글
댓글 쓰기