648. 캡 정리 (CAP Theorem)와 분산 스토리지

핵심 인사이트 (3줄 요약)

1. 본질: 캡 정리 (CAP Theorem)는 분산 스토리지에서 네트워크 분단이 발생했을 때, 일관성 (Consistency) 과 가용성 (Availability) 을 동시에 완벽히 보장할 수 없다는 장애 시점의 선택 원리를 설명한다.
2. 가치: 이 정리는 어떤 데이터는 잠시 틀려도 되는가, 아니면 잠시 멈추더라도 맞아야 하는가를 분명히 하여, 저장 시스템 설계를 기술 문제가 아니라 비즈니스 의미 문제로 바꿔 준다.
3. 판단 포인트: CAP은 흔한 오해처럼 "셋 중 둘을 고르는 표어"가 아니라, 분단 허용은 현실에서 사실상 필수이며 분단 시 C와 A 중 무엇을 우선할지 결정하라는 정리다.

Ⅰ. 개요 및 필요성

분산 스토리지는 같은 데이터를 여러 노드에 복제해 빠른 응답과 장애 대응을 얻으려 한다. 하지만 노드가 지역을 넘나들고 네트워크 장비가 여러 계층으로 연결될수록, 링크 단절·스위치 장애·패킷 손실로 인해 일부 복제본끼리 통신이 끊기는 순간은 피할 수 없다. CAP 정리는 바로 이 현실적 상황에서 저장 시스템이 어떤 행동을 해야 하는지를 설명하는 기본 원리다.

핵심 질문은 단순하다. 한쪽 복제본에 기록된 최신 값이 다른 쪽으로 아직 전달되지 않았는데, 클라이언트가 읽기나 쓰기를 요청하면 어떻게 할 것인가? 정확하지 않다면 응답을 미루는 선택은 일관성을 지키지만 가용성을 희생하고, 일단 응답하는 선택은 가용성을 지키지만 값이 어긋날 수 있다. 따라서 CAP은 기술적 제약을 드러내는 동시에 서비스 우선순위를 묻는 프레임이 된다.

• 📢 섹션 요약 비유: 본점과 지점의 전화선이 끊긴 은행과 같다. 지금 잔액을 꼭 맞춰야 하면 창구를 잠시 닫아야 하고, 손님을 계속 받으려면 잠깐 틀린 잔액을 보여줄 위험을 감수해야 한다.

Ⅱ. 아키텍처 및 핵심 원리

CAP을 저장 시스템 관점에서 보면 복제 집합, 읽기·쓰기 경로, 분단 감지, 복구 후 동기화라는 네 요소로 정리된다. 분단 허용 (Partition Tolerance) 은 현대 분산 시스템에서는 사실상 제거할 수 없는 전제이므로, 실제 설계는 분단이 생겼을 때 강한 일관성을 유지할지 혹은 응답성을 유지할지를 고르는 문제로 수렴한다.

아래 그림은 세 복제본 중 한쪽이 네트워크로 분리되었을 때 분산 스토리지가 맞닥뜨리는 선택을 보여 준다.

┌────────────────────────────────────────────────────────────────────┐
│ Replica set under a network partition                             │
├────────────────────────────────────────────────────────────────────┤
│ Client L -> [Replica A] --- [Replica B]      X      [Replica C]   │
│                               ▲                                   │
│                               │                                   │
│                          link broken                              │
│                                                                   │
│ CP choice: block or reject minority-side requests                 │
│ AP choice: answer on both sides and reconcile later               │
└────────────────────────────────────────────────────────────────────┘

정족수 기반 읽기·쓰기 역시 CAP 안에서 움직인다. 예를 들어 복제 수 N에 대해 읽기 수 R과 쓰기 수 W가 R + W > N을 만족하도록 잡으면 강한 일관성에 가까운 동작을 얻을 수 있지만, 분단 중에는 그 정족수를 모으지 못해 가용성이 떨어진다. 반대로 로컬 복제본만 보고 바로 응답하면 분단 상황에서도 서비스는 계속되지만 이후 충돌 조정과 병합이 필요해진다.

• 📢 섹션 요약 비유: 회의 참석자 전원이 같은 최신 회의록을 볼 때까지 회의를 멈출지, 아니면 각자 가진 복사본으로 일단 진행하고 나중에 맞출지 결정하는 문제와 같다. 둘 다 장단점이 분명하다.

Ⅲ. 비교 및 연결

CAP은 보통 CP와 AP의 비교로 가장 잘 드러난다. CP 계열은 분단 시 일부 요청을 거절하거나 대기시켜 데이터의 단일 진실을 지키고, AP 계열은 응답을 우선한 뒤 나중에 상태를 수렴시킨다. 이 차이는 단순 철학 차이가 아니라 복구 방식, 사용자 경험, 운영비까지 바꾼다.

이 비교는 이후의 최종 일관성, 정족수 조정, PACELC 정리로 이어진다. 특히 CAP이 분단 시의 선택을 말한다면, 평상시 지연시간과 일관성의 균형은 패컬크 정리 (PACELC Theorem) 가 더 잘 설명한다. 따라서 CAP은 분산 스토리지를 보는 첫 렌즈이고, 그 위에 세부 튜닝 이론이 덧붙는 구조로 이해하는 것이 좋다.

• 📢 섹션 요약 비유: CP는 정답을 확인하기 전에는 시험지를 제출하지 않는 학생이고, AP는 일단 답을 적어 내고 나중에 정오표를 붙이는 학생과 같다. 어떤 방식이 맞는지는 시험 종류에 따라 달라진다.

Ⅳ. 실무 적용 및 기술사 판단

실무에서는 데이터를 한 덩어리로 보지 말고 의미별로 나눠야 한다. 계좌 잔액, 권한 정보, 리더 선출 메타데이터는 CP 성향이 맞고, 추천 피드, 장바구니, 읽기 로그, 캐시 데이터는 AP 성향이 더 실용적일 수 있다. 즉 CAP 판단은 저장 엔진 하나를 고르는 문제가 아니라, 데이터 종류마다 허용 가능한 오차와 중단 시간을 정의하는 일이다.

체크리스트

1. 이 데이터가 잠시 틀리면 금전·보안·규제 문제가 발생하는가?
2. 분단 시 사용자가 오류 메시지를 더 싫어하는가, 잠시 오래된 값을 더 싫어하는가?
3. 읽기 이후 곧바로 자신의 쓰기를 확인해야 하는가?
4. 충돌이 생겼을 때 자동 병합 가능한 데이터 구조인가, 아니면 사람 판단이 필요한가?
5. 복제본이 여러 지역에 퍼져 있다면, 장애 영역과 지연시간을 별도로 측정하고 있는가?

안티패턴

• 전 세계 분산 배치 시스템을 두고도 우리는 CA라고 가정하는 경우
• 댓글 수나 캐시 같은 데이터까지 모두 CP로 묶어, 작은 네트워크 흔들림에도 서비스 전체가 굳어 버리는 경우
• AP 시스템을 도입하고도 충돌 해결 규칙과 세션 일관성 보완책을 준비하지 않는 경우

기술사 관점에서는 CAP을 선택 이론이 아니라 장애 설계 문서로 다뤄야 한다. 분단이 일어났을 때 어떤 요청을 막고, 어떤 요청은 살리며, 복구 후 어떤 방식으로 다시 맞출지까지 써야 한다. 그래야 CAP이 시험용 슬로건이 아니라 실제 장애 대응 아키텍처가 된다.

• 📢 섹션 요약 비유: 비 오는 날 우산을 펼칠지 뛰어갈지 미리 정해 두는 것과 같다. 비가 오고 나서야 고민하면 이미 다 젖는다.

Ⅴ. 기대효과 및 결론

CAP 관점을 명확히 적용하면 시스템이 장애 시 어떤 모습을 보일지 예측 가능해진다. 사용자는 어떤 상황에서 잠시 대기해야 하는지, 어떤 데이터는 약간 늦게 맞춰질 수 있는지 일관된 경험을 하게 되고, 운영자는 불필요한 과설계나 잘못된 기대를 줄일 수 있다. 즉 CAP은 기능보다 실패 시 행동의 품질을 높여 주는 이론이다.

물론 CAP만으로 설계가 끝나지는 않는다. 평상시 지연시간, 정족수 비용, 충돌 병합 난이도, 하드웨어 지연 특성은 추가로 따져야 한다. 그래도 이 주제를 기억할 때 가장 중요한 문장은 하나다. 분산 스토리지는 분단을 피할 수 없고, 따라서 장애 순간에 무엇을 지킬지 미리 결정해야 한다. 이것이 CAP 정리가 남기는 가장 실무적인 메시지다.

• 📢 섹션 요약 비유: CAP은 세 가지 보물을 다 주는 마법 주문이 아니라, 폭풍이 왔을 때 무엇을 먼저 건질지 정하게 해 주는 선장의 우선순위 표와 같다.

📌 관련 개념 맵

📈 관련 키워드 및 발전 흐름도

Single-node storage assumptions
    │
    ▼
Replication across unreliable networks
    │
    ▼
CAP trade-off under partition
    │
    ▼
Quorum / eventual consistency design patterns
    │
    ▼
PACELC and workload-specific consistency tuning

이 흐름은 저장 시스템 논의가 복제하면 더 안전하다는 수준에서, 복제 중 어떤 실패 행동을 선택할 것인가를 설계하는 수준으로 깊어졌음을 보여 준다.

👶 어린이를 위한 3줄 비유 설명

1. 친구 셋이 같은 공책을 같이 쓰는데, 두 친구 사이 전화가 끊기면 바로 문제가 생겨요.
2. 그때는 잠깐 기다리면서 공책 내용을 꼭 맞출지, 아니면 일단 쓰고 나중에 맞출지 골라야 해요.
3. CAP 정리는 컴퓨터가 이런 어려운 순간에 어떤 선택을 해야 하는지 알려주는 규칙이에요.