[분산 시스템] Day 4: CAP과 일관성 모델 - 무엇을 포기할 것인가
이 글은 AI(Claude)의 도움을 받아 작성하고, 작성자가 검토·편집했습니다.
서론: 분산 시스템엔 공짜 점심이 없다
복제(Day 2)와 파티셔닝(Day 3)으로 시스템을 분산하면 피할 수 없는 질문에 부딪힌다. “한 노드의 변경이 다른 노드에 즉시 보여야 하는가, 아니면 잠시 달라도 되는가?” 이 질문의 답이 일관성 모델이고, 그 한계를 규정한 것이 CAP 정리다. 오늘은 “무엇을 포기할 것인가”를 다룬다.
1. CAP 정리: 셋 중 둘
1
2
3
4
5
C (Consistency): 모든 노드가 같은 순간 같은 데이터를 본다
A (Availability): 살아있는 노드는 항상 응답한다
P (Partition tolerance): 네트워크가 쪼개져도 시스템이 동작한다
정리: 네트워크 분할(P)이 일어나면 C와 A를 동시에 만족할 수 없다
흔한 오해를 바로잡자. 네트워크 분할은 선택이 아니라 분산 시스템에서 반드시 일어나는 현실이다. 따라서 P는 필수고, 실제 선택은 분할이 일어났을 때 C냐 A냐다.
2. CP vs AP: 분할 시의 선택
1
2
3
4
5
6
7
8
9
10
11
분할 발생 시:
CP 선택 (일관성 우선):
소수파 쪽 노드는 응답을 거부 → 틀린 데이터를 주느니 에러를 반환
예: ZooKeeper, etcd, 합의 기반 시스템 (Day 1의 Raft)
쓰임: 설정·리더 선출·잔액처럼 틀리면 안 되는 데이터
AP 선택 (가용성 우선):
분할된 양쪽 모두 응답 → 일시적으로 데이터가 갈릴 수 있음
예: Cassandra, DynamoDB (튜닝 가능)
쓰임: 장바구니·좋아요 수·피드처럼 잠시 달라도 되는 데이터
은행 잔액은 CP(“잠깐 멈출지언정 틀린 잔액은 안 됨”), SNS 좋아요는 AP(“잠깐 숫자가 달라도 멈추면 안 됨”)가 어울린다.
3. PACELC: CAP의 확장
CAP은 “분할이 났을 때”만 말한다. 하지만 분할이 없는 평상시에도 선택이 있다.
1
2
3
4
5
6
7
PACELC:
if Partition: choose A or C (분할 시: 가용성 vs 일관성)
Else: choose L or C (평상시: 지연 Latency vs 일관성)
예:
DynamoDB: PA / EL (분할 시 가용성, 평상시 저지연 — 일관성을 늦춤)
분산 RDB: PC / EC (분할 시도 평상시도 일관성 우선 — 지연 감수)
핵심 통찰: 강한 일관성은 분할 시뿐 아니라 평상시에도 노드 간 조율 비용(지연)을 요구한다. 일관성은 항상 무언가를 대가로 한다.
4. 일관성 모델의 스펙트럼
일관성은 흑백이 아니라 스펙트럼이다. 강할수록 추론은 쉽지만 비싸다.
1
2
3
4
5
6
7
8
강함 ──────────────────────────────────────────> 약함
선형화 순차 일관성 인과 일관성 최종 일관성
(Linearizable) (Sequential) (Causal) (Eventual)
모든 연산이 프로그램 순서 인과관계만 언젠가는
실시간 전역 유지 순서 보장 수렴
순서를 가짐
↑ 비쌈, 느림 싸고 빠름 ↑
5. 선형화: 가장 강한 보장
선형화(linearizability)는 “분산 시스템이 마치 단일 복사본인 것처럼 동작”한다는 보장이다.
1
2
3
4
5
6
7
쓰기 x=1이 완료된 순간 이후의 모든 읽기는 1 이상을 봐야 한다
(이전 값 0을 보면 위반)
대가:
- 모든 읽기·쓰기가 노드 간 조율 필요 → 높은 지연
- 합의(Day 1) 또는 동기 복제(Day 2)로 구현
- 분할 시 가용성 희생 (CP)
분산 락, 유일성 보장(중복 계정 방지), 리더 선출에 필수다. 하지만 모든 데이터에 적용하면 시스템이 느려지고 분할에 취약해진다.
6. 최종 일관성과 인과 일관성
대부분의 대규모 시스템은 더 약한 모델로 가용성과 성능을 얻는다.
1
2
3
4
5
6
7
8
9
최종 일관성(Eventual):
"쓰기가 멈추면 언젠가 모든 복제본이 같아진다"
→ 그 '언젠가'까지 오래된 값을 읽을 수 있음 (Day 2의 복제 지연)
→ 가장 약하지만 가장 가용·빠름
인과 일관성(Causal): 실용적 중간 지점
"인과관계 있는 연산만 순서 보장" (질문→답변 순서는 지키되,
무관한 연산은 순서 자유)
→ 최종 일관성의 가장 이상한 현상들을 막으면서도 저렴
현실 설계의 정석은 데이터마다 다른 모델을 적용하는 것이다. 결제는 선형화, 사용자 세션은 인과 일관성, 분석 카운터는 최종 일관성처럼.
7. Day 4 체크리스트
- CAP에서 P는 필수이고 실제 선택은 분할 시 C냐 A냐임을 이해했다.
- CP(일관성 우선)와 AP(가용성 우선) 시스템의 적합한 용도를 구분했다.
- PACELC로 평상시에도 지연 vs 일관성 선택이 있음을 파악했다.
- 선형화·순차·인과·최종 일관성의 스펙트럼과 비용 차이를 안다.
- 데이터 종류별로 다른 일관성 모델을 적용하는 설계 원칙을 잡았다.
다음 편 예고
이론을 갖췄으니 마지막은 현실이다. Day 5(시리즈 마무리)에서는 분산 시스템에서 실제로 터지는 장애들 — 시계 문제, 부분 실패, split-brain, 멱등성, 그리고 이를 다루는 운영 패턴을 정리한다.