온라인 쇼핑몰에서 결제 버튼을 눌렀는데 재고가 ‘있음’으로 보이던 상품이 갑자기 품절이 됩니다. 다른 서버에는 아직 예전 재고가 남아 있었기 때문입니다. 여러 대의 컴퓨터가 한 서비스처럼 움직일 때, 데이터는 언제나 같고 응답은 언제나 오며 네트워크는 절대 끊기지 않는다는 세 가지를 동시에 약속하기 어렵습니다. 이 딜레마를 한 줄로 정리한 것이 바로 ‘CAP 정리(CAP Theorem)’입니다.

CAP 정리란 쉽게 말해 ‘분산 시스템에서 일관성(Consistency), 가용성(Availability), 분할 내성(Partition tolerance)을 동시에 모두 보장할 수 없다’는 이론을 의미합니다. 2000년 에릭 브루어(Eric Brewer)가 PODC 키노트에서 제안했고, 2002년 세트 길버트(Seth Gilbert)와 낸시 린치(Nancy Lynch)가 형식적으로 증명했습니다.

본 자료에서는 CAP 정리의 탄생 배경과 정확한 정의부터 C·A·P 세 글자의 의미, 셋이 동시에 불가능한 이유, 그리고 실무에서 이 정리를 어떻게 읽어야 하는지까지 쉽게 이해할 수 있도록 정리합니다.

CAP 정리: 분산 시스템이 마주하는 세 가지 약속

CAP 정리란 무엇인가?

분산 시스템은 한 대의 컴퓨터가 아니라 여러 노드가 네트워크로 연결된 구조입니다. 쇼핑몰, 메신저, 클라우드 데이터베이스처럼 규모가 커질수록 데이터를 여러 곳에 나눠 두는 편이 자연스럽습니다. 문제는 노드 사이의 통신이 항상 완벽하지 않다는 점입니다. 케이블이 끊기거나, 지연이 폭증하거나, 일부 서버가 응답하지 않으면 ‘분할(Partition)’이 생깁니다.

브루어는 이런 환경에서 시스템이 동시에 지킬 수 없는 세 가지 성질을 C·A·P로 묶었습니다. 핵심 메시지는 단순합니다. 네트워크 분할이 실제로 발생하면, 일관성과 가용성 가운데 하나를 우선해야 한다는 것입니다. ‘셋 중 둘만 고른다’는 말로 흔히 요약되지만, 현대 해석에서는 분할 내성을 사실상 필수 전제로 두고 C와 A의 트레이드오프로 읽습니다.

이 정리를 읽을 때 함께 두면 좋은 개념은 다음과 같습니다.

• 분산 시스템(Distributed System): 여러 컴퓨터가 하나의 서비스처럼 협력하는 구조입니다.
• 노드(Node): 그 협력에 참여하는 개별 서버나 프로세스입니다.
• 복제(Replication): 같은 데이터를 여러 노드에 복사해 두는 방식입니다.
• 트레이드오프(Trade-off): 한 성질을 강화하면 다른 성질을 양보해야 하는 관계입니다.

C·A·P, 세 글자의 정확한 의미

세 글자를 일상 언어로 옮기면 개념이 선명해집니다.

(1) 일관성(Consistency)
모든 노드가 동시에 같은 최신 값을 본다는 약속입니다. 한 곳에서 재고를 1로 줄였다면, 다른 곳에서 바로 이어서 조회해도 1이어야 합니다. CAP에서 말하는 C는 데이터베이스 이론의 ‘강한 일관성’에 가깝고, 최종적으로만 같아지는 느슨한 일관성과는 구분됩니다.

(2) 가용성(Availability)
살아있는 노드라면 요청에 반드시 응답한다는 약속입니다. 실패나 타임아웃 없이 ‘읽기·쓰기 결과가 돌아온다’는 뜻이지, 그 결과가 항상 최신이라는 뜻은 아닙니다. 느리더라도 답이 오는 것과, 아예 거절하는 것은 다른 선택입니다.

(3) 분할 내성(Partition tolerance)
노드 사이 통신이 끊겨도 시스템이 멈추지 않고 계속 동작한다는 약속입니다. 현실의 인터넷과 데이터센터에서는 분할이 드물지 않으므로, 대부분의 대규모 서비스는 P를 포기하기 어렵습니다.

쉬운 비유로, 두 지점의 은행 창구가 전화선으로만 연결되어 있다고 해 봅시다. 전화가 끊긴 순간(분할)에도 두 창구가 각각 출금을 허용하면(가용성) 잔액이 어긋날 수 있고(일관성 손상), 잔액을 맞추려고 거래를 멈추면(일관성 유지) 손님은 거절당합니다(가용성 손상).

왜 셋 다 동시에 가질 수 없는가

네트워크가 분할되면 노드 무리는 서로 최신 상태를 확인할 수 없습니다. 이때 선택지는 대략 두 갈래입니다.

(1) CP를 택하는 경우
일관성을 지키려면, 상대 쪽 상태를 모른 채 쓰기를 허용해서는 안 됩니다. 그래서 일부 요청을 거절하거나 대기시킵니다. 데이터는 맞지만, 그 순간 서비스는 ‘응답하지 않음’으로 보일 수 있습니다. 전통적인 합의 기반 데이터베이스나 강한 일관성을 강조하는 시스템이 이 쪽에 가깝습니다.

(2) AP를 택하는 경우
가용성을 지키려면, 각 노드가 가진 정보만으로라도 응답합니다. 서비스는 계속 열리지만, 분할이 해소되기 전까지 서로 다른 값을 보여줄 수 있습니다. 이후 동기화·충돌 해결로 맞추는 ‘최종 일관성(Eventual Consistency)’ 전략이 자주 짝을 이룹니다.

‘CA 시스템’이라는 말도 교과서에 나오지만, 분할이 절대 생기지 않는 환경을 전제로 한 이상화에 가깝습니다. 단일 장비나 매우 안정적인 로컬 클러스터에서는 근사적으로 가능해도, 광역 분산에서는 P를 무시하기 어렵습니다. 따라서 실무의 질문은 “C·A·P 중 무엇을 버릴까?”보다 **“분할이 왔을 때 C와 A 중 무엇을 얼마나 양보할까?”**에 가깝습니다.

실무에서 CAP를 어떻게 읽어야 하는가

CAP 정리는 강력한 통찰이지만, 만능 라벨은 아닙니다. 브루어 본인도 이후 글에서 ‘2 out of 3’ 슬로건이 오해를 불렀다고 돌아본 바 있습니다. 현대 시스템에는 다음과 같은 보완 시각이 함께 필요합니다.

• 정도의 문제: 일관성과 가용성은 켜고 끄는 스위치가 아니라 스펙트럼입니다. 읽기만 느슨히 하고 쓰기는 강하게 하는 식의 혼합이 흔합니다.
• 지연과의 관계: 대니얼 어바크(Daniel Abadi)가 정리한 PACELC는, 분할이 없을 때(Else)도 지연(Latency)과 일관성 사이에서 선택이 있다고 봅니다.
• 업무별 우선순위: 결제·재고처럼 금액이 걸린 흐름은 C 쪽에, 피드·조회수처럼 약간의 시차가 허용되는 흐름은 A 쪽에 기울기 쉽습니다.

설계자는 “우리 시스템은 CP다/AP다”라고 한 단어로 끝내기보다, 어떤 연산이 어떤 상황에서 무엇을 보장하는지를 구체적으로 적어야 합니다. CAP는 선택지를 없애는 법칙이 아니라, 분산 환경의 한계를 미리 드러내 주는 지도입니다.

CAP 정리는 ‘완벽한 분산 시스템은 없다’는 경고가 아닙니다. 한계를 인정한 뒤, 비즈니스에 맞는 타협을 설계하라는 초대입니다. 네트워크가 어긋날 때를 가정하고 일관성과 가용성 중 무엇을 지킬지 미리 정하는 것, 그것이 안정적인 분산 설계의 첫걸음입니다.