CAP 정리 — P는 고르는 게 아니라 주어진다

결론 먼저

CAP 정리는 흔히 “일관성(Consistency), 가용성(Availability), 분할 내성(Partition Tolerance) 셋 중 둘을 고른다”로 소개된다. 하지만 실제 선택은 그렇게 자유롭지 않다.

핵심은 이렇다. 네트워크 파티션이 발생한 상황에서 C와 A 중 하나를 포기해야 한다. P는 설계자가 고르는 옵션이 아니라 분산 환경이 강제하는 전제이기 때문이다. 그래서 진짜 선택지는 CP와 AP 둘로 좁혀지고, CA는 이론적으로만 의미가 있다.

즉 CAP는 “셋 중 둘”이 아니라 “파티션이 났을 때 C를 살릴까 A를 살릴까”의 문제다.

세 속성의 정확한 의미

Eric Brewer가 2000년에 제시하고 이후 정식으로 증명된 이론이다. 분산 시스템이 가질 수 있는 세 가지 보장을 말한다.

일관성(Consistency) — 모든 노드가 같은 시점에 동일한 데이터를 본다. 어느 노드에 읽기를 보내든 가장 최신 쓰기 결과를 반환하거나, 아니면 오류를 반환한다.

가용성(Availability) — 모든 요청이 응답을 받는다. 단, 그 응답이 최신 데이터라는 보장은 없다.

분할 내성(Partition Tolerance) — 노드 간 네트워크가 끊기거나 지연(파티션, partition)되어도 시스템이 계속 동작한다.

A와 P는 층위가 다르다

혼동하기 쉽지만 A와 P는 보는 대상이 다르다.

• A는 클라이언트와 시스템 사이의 약속 — 사용자가 요청을 보냈을 때 답을 받느냐.
• P는 시스템 내부 노드들 사이의 문제 — 서버들끼리 통신이 끊겼을 때 버티느냐.

콜센터에 비유하면, A는 “전화하면 누군가 받는다”이고, P는 “본사와 지사 사이 전화선이 끊겨도 지사가 영업을 계속한다”이다. 별개의 얘기다.

왜 동시에 만족할 수 없는가 — 불가능성 증명 스케치

세 속성을 모두 보장하는 시스템이 있다고 가정하고 모순을 끌어내 보자.

노드가 두 그룹 G1, G2로 나뉘어 통신이 끊긴 상태(파티션)를 그린다. G1에 값 x를 바꾸는 쓰기가 들어오고, 곧이어 G2에 x를 읽는 요청이 들어온다. G2는 G1과 통신할 수 없으니 방금 쓰인 x를 알 길이 없다. 이때 G2가 할 수 있는 건 둘뿐이다.

• 옛날 값이라도 즉시 응답한다 → A는 지키지만 C가 깨진다(최신 쓰기를 못 봤다).
• 동기화될 때까지 응답을 미루거나 거부한다 → C는 지키지만 A가 깨진다(요청이 답을 못 받았다).

파티션이 걸린 이상 이 딜레마를 빠져나갈 제3의 길이 없다. 따라서 C·A·P를 동시에 만족하는 시스템은 존재할 수 없다.

남는 질문은 “그럼 P를 빼면 되지 않나”인데, 여기서 P의 성격을 짚어야 한다. 네트워크 장애는 설계자가 켜고 끄는 스위치가 아니라 원치 않아도 언제든 발생하는 단절이다. 파티션이 실제로 일어나는 이상 그 사건을 감당하는 것(P) 외에 다른 선택지가 없다. 그래서 앞서 말했듯 현실의 트레이드오프는 CP와 AP 사이에서만 일어난다.

CA / CP / AP

CA — 일관성 + 가용성 (분할 내성 포기) 파티션이 절대 없다고 가정한다. 모든 노드가 항상 통신 가능하면 C와 A를 둘 다 누릴 수 있다. 하지만 분산 환경에서 네트워크 단절은 반드시 일어나므로, CA는 사실상 파티션이라는 사건 자체가 존재할 수 없는 단일 노드 시스템에서만 성립한다. 단일 서버 위의 전통적 RDBMS가 여기 해당한다.

CP — 일관성 + 분할 내성 (가용성 포기) 파티션이 나면 최신임을 보장할 수 없는 노드는 요청을 거부하거나 오류를 반환한다. “틀린 답을 주느니 답을 안 주겠다”는 입장이다. 데이터 정합성이 절대적으로 중요한 시스템에 맞는다. 예 — etcd, ZooKeeper, HBase, MongoDB(기본 설정).

AP — 가용성 + 분할 내성 (일관성 포기) 파티션이 나도 모든 노드가 계속 응답한다. 대신 끊긴 동안 다른 노드의 최신 쓰기를 못 봤을 수 있어 오래된 데이터를 반환할 수 있다. 파티션이 복구되면 나중에 데이터를 맞춰간다(최종 일관성, eventual consistency). 예 — Cassandra, DynamoDB, ScyllaDB. (한때 대표 예로 꼽히던 Riak은 개발사 Basho가 2017년 파산한 뒤 사실상 레거시·비주류가 됐다.)

함정 정리

CAP의 C ≠ ACID의 C. CAP의 C는 선형화 가능성(linearizability)에 가깝고, ACID의 C는 무결성 제약 조건을 뜻한다. 같은 글자지만 가리키는 대상이 다르다.

“partition”이라는 단어의 이중 의미. CAP의 P는 네트워크 파티션(노드 간 통신이 끊긴 장애 모드)만 가리킨다. RDBMS의 테이블 파티셔닝(range/hash)이나 샤딩은 데이터 파티셔닝(설계 기법)으로, 완전히 다른 개념이다. 단일 노드에서 테이블을 아무리 쪼개도 “노드 간 단절”이라는 사건이 없으므로 CAP 관점에서는 여전히 CA다. P가 의미를 가지려면 데이터가 여러 노드에 흩어져 있어야 한다.

CAP의 빈틈과 PACELC

CAP는 “파티션이 없는 평상시”에 대해서는 아무 말도 하지 않는다. 평상시에는 C와 A를 모두 누릴 수 있다. 이 한계를 메우려고 나온 게 PACELC 정리다 — “파티션(P)이면 A 또는 C, 그렇지(Else) 않으면 지연시간(Latency) 또는 일관성(Consistency)”. 평상시의 지연-일관성 트레이드오프까지 포함해 더 완전한 그림을 준다.

정리하면, CAP는 파티션이라는 예외 상황에서의 C/A 선택을 말하고, PACELC는 거기에 평상시의 지연/일관성 선택을 더한다. 두 정리 모두 P를 자유로운 선택지가 아니라 주어진 전제로 놓는다는 점이 출발점이다.

관련 글

글	이 글과의 관계
분산 DB 확장 — 샤딩·분산 트랜잭션·합의	CAP을 전제로 한 실무 확장
NoSQL 개요 — 문서·키밸류·컬럼·그래프	BASE·최종 일관성으로 CAP 트레이드오프를 택하는 스토어들