CAP 이론은 알겠는데, 그래서 분산 시스템은 어떻게 설계해야 하나요?
많은 엔지니어가 CAP 이론을 C(일관성), A(가용성), P(파티션 허용) 세 가지 중 둘만 선택할 수 있는 제한 조건으로 알고 있습니다. 하지만 진짜 실무에선 이걸 넘는 고민이 필요합니다. 왜냐하면, 시스템은 언제든 장애가 나고, 그 순간 ‘무엇을 포기할지’ 결정해야 하기 때문입니다. 예를 들어, 글로벌 유저가 사용하는 SNS에서 네트워크 파티션이 발생했다면, 메시지를 유실 시키더라도 실시간 응답성을 유지할지, 아니면 서비스 자체를 일시 정지 시키더라도 데이터 일관성을 보장 할 지를 선택해야 합니다.
실제로 AWS S3는 “Availability 우선” 구조를 택해 일부 오래된 데이터를 eventual consistency로 보장합니다. 반면 Google Spanner는 TrueTime을 통해 글로벌 일관성을 지키며 CAP의 한계를 기술적으로 극복하려고 시도했죠. DynamoDB는 아예 AP 중심으로 시작해, 개발자가 어떤 일관성 모델을 선택할지 구성에서 직접 명시하도록 했습니다. 이처럼 실전 설계에서는 단순히 "CA냐 CP냐"의 이론이 아니라, 어떤 유저 경험을 제공할지, 어떤 장애를 감내할 수 있을지에 대한 ‘비즈니스적 우선순위 판단’이 설계 전략의 핵심이 됩니다.
다음 글에서는 실제 장애 상황에서 어떤 전략을 택해야 하는지, 그리고 Kafka, Spanner, DynamoDB가 CAP을 어떻게 ‘현실적으로 타협 했는지’ 비교 분석해 드리겠습니다.
“CAP 이론은 아는데, 그래서 어떻게 설계 하라는 거지?”
CAP 이론은 이제 개발자라면 누구나 한 번쯤은 들어본 개념입니다.
Consistency(일관성), Availability(가용성), Partition tolerance(파티션 허용성)
이 세 가지 중 두 개만 고를 수 있다는 이론이죠.
하지만 실무에선 단순히 “CA냐, AP냐”로만 선택하지 않습니다.
진짜 문제는 ‘어떤 상황에서 무엇을 포기 할지를 언제 결정 하느냐’입니다.
CAP을 이렇게 씁니다
Amazon DynamoDB
장애 허용성과 확장성을 우선시하는 AP 중심 구조.
기본적으로 eventual consistency를 택하고, 필요할 경우 strong consistency 옵션을 선택할 수 있습니다.
Google Spanner
CP 중심이지만 TrueTime API를 활용해 글로벌 일관성을 지켜냅니다.
CAP의 한계를 인프라(하드웨어) 레벨에서 해결하려는 접근입니다.
Kafka
Producer는 high availability 중심으로 데이터를 브로커에 기록하지만, Consumer 측에서는 메시지 일관성을 직접 컨트롤합니다.
"데이터 수신자가 일관성을 책임진다"는 분산 아키텍처 철학이 반영된 구조입니다.
설계는 결국, 비즈니스 요구와 경험의 문제입니다
은행 거래 시스템은 가용성보다 일관성을 우선합니다.
소셜 피드는 일관성보다 가용성을 우선합니다.
실시간 게임 서버는 네트워크 지연과 파티션 발생 시, 유저 경험을 기준으로 트레이드오프를 결정해야 합니다.
즉, “무엇을 포기할 것인가”는 기술의 문제가 아니라,
“어떤 사용자 경험을 지키고 싶은가”라는 전략적 선택입니다.
하지만 여전히 질문이 남습니다.
전자상거래 같은 중요한 시스템에서 AP 모델이 적용될 수 있을까?
의외로 전자상거래는 AP 모델이 잘 맞는 영역도 많습니다. 상품 상세 페이지, 검색, 추천, 장바구니처럼 즉각적인 일관성이 없어도 되는 영역에서는 빠른 응답성과 글로벌 확장성이 더 중요한 요소가 되죠.
예컨대 DynamoDB 같은 AP 계열 시스템은 전 세계 사용자에게 수 밀리초 단위로 응답하면서도, 재고 수량이 몇 초 늦게 반영되는 정도의 최종 일관성(eventual consistency) 은 UX에 큰 영향을 주지 않습니다. 반면, 결제나 주문 확정 같은 민감한 트랜잭션은 DynamoDB의 트랜잭션 기능이나 별도의 CP 계열 DB로 도메인 분리 및 보강 처리합니다.
이렇게 도메인 단위로 CAP 우선순위를 나누는 하이브리드 구조는 현재 아마존, 쿠팡, Shopify 등의 글로벌 커머스 시스템에서 실제로 쓰이는 전략입니다. 핵심은 전체 시스템을 하나의 CAP 선택에 고정시키지 않고, 서비스 영역별로 다른 선택을 조합하는 유연한 구조를 만드는 것입니다.
이처럼 “전자상거래니까 무조건 CP”라는 생각은 실제로는 지나친 단순화일 수 있습니다. 트랜잭션이 필요한 도메인에서는 CP, UX가 중요한 도메인에서는 AP, 이 둘의 균형과 경계를 어떻게 설계하느냐가 실력의 차이를 만듭니다. CAP 이론을 알고 있는 것과, CAP 이론으로 분산 시스템을 '현실적으로 타협하며 설계하는 것'은 전혀 다릅니다.
Netflix의 분리 전략 - 스트리밍은 A, 결제는 C
Netflix는 서비스의 대부분을 AP 지향으로 운영합니다. 예를 들어 스트리밍 콘텐츠 메타데이터, 사용자 시청 기록, 추천 엔진 등은 데이터 정합성보다 즉각적인 응답성과 가용성이 중요합니다. 여기에 Cassandra, Dynomite, EVCache 같은 AP 중심의 분산 저장소를 활용합니다. 네트워크 파티션이나 일부 장애가 발생해도 재시도 전략, eventual consistency로 대응하죠.
하지만 결제, 인증, 정책 설정처럼 정합성이 핵심인 도메인은 CP 설계가 적용됩니다. Netflix는 이 부분에선 strong consistency 보장 시스템과 fallback 설계, 그리고 fail-closed 전략을 통해 서비스의 신뢰성을 지킵니다.
→ 즉, “성능 우선” 도메인에는 AP, “신뢰 우선” 도메인에는 CP.
Amazon의 분리 전략 - 쇼핑은 A, 주문은 C
Amazon 역시 핵심 커머스 시스템에서 CAP을 도메인 단위로 나눠 설계합니다.
상품 검색, 추천, 장바구니 시스템은 일관성보다 반응성이 중요한 영역. DynamoDB나 자체 AP 계열 시스템을 이용해 eventual consistency를 허용합니다. 예: 장바구니에 담긴 수량이 몇 초 늦게 반영되어도 UX엔 큰 문제 없음.
주문 확정, 결제, 포인트 차감 시스템에서는 하나라도 잘못되면 고객 신뢰를 잃을 수 있는 영역. 이때는 S3 기반의 Write-Ahead Logging, DynamoDB 트랜잭션, SQS + Lambda 기반의 Exactly-once 처리 보강 등으로 CP 또는 강화된 보상 트랜잭션 모델을 구성합니다.
→ Amazon의 철학은 “90%는 eventual로 빠르게, 10%는 정확하게”입니다.