CAP·BASE와 Paxos/Raft로 설계하는 분산 시스템의 일관성 전략
CAP 이론과 BASE 속성, Paxos·Raft 합의를 바탕으로 분산 시스템의 일관성, 가용성, 쿼럼 설계를 정리한다.
2026-08-14 · 최초 발행 2025-10-31
분할이 발생했을 때 어떤 응답을 포기할 것인가
분산 시스템은 확장성과 장애 허용을 위해 여러 노드에 상태를 나눈다. 이 구조에서는 네트워크 분할이 일어났을 때 모든 요청에 즉시 응답하면서 모든 노드가 같은 최신 값을 보게 할 수 없다. CAP 이론, BASE 속성, 분산 합의 알고리즘은 이 선택을 설계와 운영 언어로 바꾸는 도구다.
CAP에서 분할 허용성(Partition tolerance, P)은 전제다. 분할이 생긴 상황에서 일관성(Consistency, C)을 우선하면 CP, 가용성(Availability, A)을 우선하면 AP가 된다. 일관성은 모든 노드가 동일한 최신 값을 관찰하는 성질이고, 가용성은 모든 요청이 응답을 받는 성질이다. 실제 선택 비용은 지연과 오류 모델에 따라 달라진다.
BASE는 Basically Available, Soft state, Eventual consistency를 뜻한다. AP 성격의 시스템에서 주로 사용하는 설계 원칙으로, 최종적 일관성을 전제로 충돌 해결, 재시도, 멱등성(idempotency), 사가(Saga) 같은 보상 트랜잭션을 함께 준비해야 한다.
Paxos와 Raft는 다수결(quorum)로 동일한 순서의 로그를 복제하고 커밋 상태를 합의하는 알고리즘 계열이다. 장애나 분할이 있어도 단일하고 일관된 상태 기계를 제공하는 것이 목표다. Paxos는 이론적 최소성과 복잡성에, Raft는 이해와 구현 용이성에 더 무게를 둔다. 실무에서는 etcd, Consul, Raft 라이브러리 등에서 Raft 채택을 자주 볼 수 있다.
일관성 모델은 업무 불변성에서 출발한다
선형화 같은 강한 일관성, 최종적 일관성, R/W 쿼럼을 조절하는 튜너블 일관성은 같은 데이터라도 서로 다른 요구에 맞는다. 업무 불변성, 금융 원장, 리더 선출처럼 잘못된 순서나 중복을 허용할 수 없는 경로에는 강한 일관성이 적합하다.
반대로 캐시, 피드, 추천은 최종적 일관성을 허용할 수 있다. 이때 스낵바나 리프레시 같은 UX 보정과 백그라운드 동기화가 사용자 체감의 불일치를 줄인다.
복제계수 N, 읽기 쿼럼 R, 쓰기 쿼럼 W의 조합도 이 결정에 포함된다. R+W>N이면 강한 읽기를 달성할 수 있고, W>⌊N/2⌋이면 쓰기 내구성을 확보한다. 예를 들어 N=3, W=2, R=2는 1노드 장애를 허용하지만, 평균 지연은 W 지연만큼 증가한다. 지연, 가용성, 내구성은 함께 최적화할 수 없는 운영 변수다.
리더 기반 합의 시스템은 선거(election), 임기(term), 로그 인덱스, 커밋 인덱스로 상태를 관리한다. 리더는 로그 순서를 보장하고 충돌한 로그를 정리한다. 스냅샷과 로그 압축(compaction)은 저장소 사용량과 복구 비용을 관리하는 수단이다.
실패 감지는 하트비트와 타임아웃에 의존한다. 네트워크가 분할되면 소수파는 읽기 전용이 되거나 로그 수용만 허용한다. 재선출 구간의 가용성 저하를 감수해야 하며, 커밋에 이르지 못한 엔트리는 롤백하거나 다시 적용한다.
AP와 BASE 체계에서는 버전 벡터, 램프 클락, CRDT, 최종 승자 규칙(LWW)으로 충돌을 다룬다. 다만 업무 규칙을 반영한 도메인 병합 로직이 필요할 수 있다. 멱등 키와 중복 제거, 재시도, 사가 보상은 사용자 상태와 비즈니스 상태의 불일치를 줄이는 보완 장치다.
선택에 따라 달라지는 운영 특성
| 유형 | 대표 예시 | CAP 선택 | 일관성 | 성능(지연) | 확장성 | 안정성(페일오버) | 운영 편의 |
|---|---|---|---|---|---|---|---|
| CP 리더 기반 K/V | etcd, Consul, ZooKeeper | CP | 강한 일관성 | 쓰기 지연↑(쿼럼) | 수평 제한적(리더 중심) | 높음(자동 선출) | 중 |
| CP RDB 동기 복제 | PostgreSQL+Patroni, Galera | CP | 강한 일관성 | 쓰기 지연↑, 읽기 중 | 수직/리더-팔로워 | 높음(동기 페일오버) | 중 |
| 튜너블 스토어 | Cassandra, Dynamo | AP(튜너블) | R/W로 조절 | 지연 낮음(지역 쿼럼) | 높음(샤딩) | 중(노드 증감 용이) | 중상 |
| 로그 스트리밍 | Kafka(acks=all, min ISR) | CP 성향(구성 의존) | 파티션 단위 강한 커밋 | 프로듀스 지연↑ | 높음(파티션) | 높음(컨트롤러) | 중 |
Kafka는 설정에 따라 C/A 트레이드오프를 조절할 수 있다.
업무 경로마다 다른 합의 수준을 둔다
지급결제와 원장 시스템은 이체·정산의 강한 일관성과 RPO=0 지향이 요구되므로 CP 선택에 가깝다. 트랜잭션 로그는 Raft 기반 config/lock 스토어(etcd)로 보조하고, 원장은 동기 복제 DB에 둔다. 거래 ID를 멱등 키로 사용하고 재처리 큐를 마련하는 방식이 여기에 맞는다.
피드와 상품 추천은 낮은 지연과 고가용성을 우선하면서 약간의 불일치를 허용할 수 있다. 캐시와 이벤트 기반 역류 처리, Cassandra R=W=QUORUM, 쓰기 포화 시 백프레셔, TTL 기반 soft state가 BASE 설계의 구성 요소가 된다.
서비스 디스커버리와 리더 선출은 정확히 한 리더와 강한 구성 관리 일관성이 필요하다. Consul이나 etcd의 세션-락으로 이를 관리하고, 장애 때 자동 재선출과 워처 기반 동적 설정 롤아웃을 연결할 수 있다.
배포와 샤드 이동처럼 운영 토폴로지 변경의 원자성이 중요한 경우에는 Paxos/Raft 기반 메타데이터 스토어를 쓴다. 변경 계획을 단일 커밋 로그에 기록하고, 다중 컨트롤러의 합의로 적용 순서를 보장한다.
Raft 쓰기 요청이 커밋되기까지
클라이언트는 payload와 현재 리더 term을 바탕으로 쓰기 요청을 보낸다. 리더는 로그에 엔트리를 추가한 뒤 팔로워에 AppendEntries를 전파한다. 과반 응답을 받으면 커밋 인덱스를 높이고 상태 기계에 적용하며, 클라이언트에는 commit index를 포함한 성공 응답을 돌려준다. 실패한 요청은 재시도하거나 리더로 리다이렉트한다.
리더가 없으면 election timeout 이후 후보자 승격을 거쳐 새 리더가 정해진다. 이 구간에서는 쓰기를 거부하거나 리다이렉트한다. 네트워크 분할에서는 과반을 확보하지 못한 소수파 리더를 봉쇄하고 읽기를 제한하며, stale read는 ReadIndex 또는 lease read로 감시한다. term 또는 index가 맞지 않는 로그는 팔로워가 롤백한 뒤 다시 동기화한다.
합의 범위를 좁히고 장애 행동을 표준화한다
CAP 의사결정에서는 P를 상수 전제로 두고, 도메인별 C/A 우선순위를 먼저 명시한다. 강한 일관성이 필요한 경로를 최소화하면 성능과 복잡도를 완화할 수 있다. 다중 리전에서는 쓰기 경로에 지역 쿼럼을 사용하고, 글로벌 일관성은 Outbox+CDC로 비동기 보정할 수 있다.
N=3, W=2, R=2 구성은 1노드 장애를 허용하며, 읽기와 쓰기 지연은 각각 1.3~2.0배 증가할 수 있다. 이 값은 네트워크 RTT와 스토리지에 좌우된다. 강한 읽기가 필요한 구간은 R=W=QUORUM으로 두고, 나머지는 R=ONE/R=LOCAL_ONE으로 비용을 낮춘다.
합의 클러스터는 홀수 노드 구성(3/5/7)과 지리적 지연의 균형을 고려한다. 스냅샷과 압축 주기를 조정해 로그 팽창을 막고, 선거 빈도, 커밋 지연, Appends 실패율, 리더 변경을 관찰 대상으로 둔다. Chaos 및 분할 테스트로 복구 동작을 검증한다.
응용 계층에서는 멱등 요청 키, 중복 방지 저장소, 사가 보상, 타임아웃, 재시도 기하 백오프를 조합한다. CQRS로 읽기 모델을 분리하면 강한 쓰기와 느슨한 읽기를 함께 운영할 수 있다.
N=3, W=2 구성은 단일 노드 장애에서도 99.95%+ 서비스 지속 가능성을 확보할 수 있다. 다중 AZ 배치와 과반 커밋은 단일 영역 장애에서 데이터 손실 확률을 현저히 낮춘다. 리더 지역 내 쿼럼은 p99 지연을 1.5~3.0배 높일 수 있지만, 읽기 캐시와 비즈니스 분리를 함께 적용하면 총 처리량을 1.2~1.8배 향상할 수 있다.
이런 선택을 문서화하면 장애 시 시스템 행동을 예측하기 쉬워진다. Consistency SLA를 팀 간 계약으로 명시하면 변경 비용과 인시던트 빈도를 줄이고, 데이터 품질과 사용자 경험의 균형을 관리할 수 있다.