CAP 정리 쉽게 이해하기: 일관성·가용성·분할 허용 중 무엇을 선택하는가

현장에서 CAP가 문제로 드러나는 장면은 의외로 단순하다

CAP 정리는 서비스가 느려지거나 일부 화면이 멈춘 상황에서 "데이터를 맞출지, 응답을 줄지"의 선택 기준을 세우는 작업이다.

예를 들어 결제는 성공했는데 주문 조회가 한동안 비어 보이거나, 로그인은 되는데 장바구니가 저장되지 않는 현상이 발생한다.

장애 대응 중 팀이 갈라지는 지점은 "일단 사용자에게 뭐라도 보여 주자"와 "틀린 정보를 보여 주면 더 큰 사고가 난다"의 충돌이다.

자주 하는 착각은 CAP가 '셋 중 둘을 버튼처럼 고르는 규칙'이라고 믿는 것이다.

실제 현장에서는 네트워크가 갈라지는 순간(분할)이 생기면, 그때부터 일관성과 가용성 중 무엇을 우선할지 정책으로 드러난다.

세 글자에 들어 있는 약속을 분리해서 읽어야 한다

핵심 개념 1) 분할 허용(P: Partition Tolerance)

정의: 네트워크가 둘로 갈라져 일부 노드끼리 통신이 끊겨도 시스템이 그 상황을 전제로 동작하도록 설계하는 성질이다.

핵심 특징: 지역 간 통신 장애, 라우팅 문제, 타임아웃 증가 같은 현실적인 단절을 "언젠가 반드시 일어난다"로 가정한다.

주의점: 분할이 발생한 순간부터는 "모든 노드가 같은 사실을 공유한다"는 전제가 깨지므로, 이후 선택은 일관성 또는 가용성 쪽으로 기울게 된다.

핵심 개념 2) 일관성(C: Consistency)

정의: 쓰기 성공 후의 읽기에서, 어떤 노드를 보더라도 같은 최신 상태를 관찰하도록 맞추는 약속이다.

핵심 특징: 사용자 화면과 운영 판단이 단일한 사실을 기준으로 움직이게 만들며, 금액·재고·권한 같은 민감 데이터에 유리하다.

주의점: 분할 상황에서는 최신 상태를 보장하려면 일부 요청을 거절하거나 대기시켜야 하며, 그 결과 응답 실패가 늘 수 있다.

CAP 정리의 세 요소 관계 구조

표로 정리하면 "무엇을 선택하는가"가 아니라 "무엇을 포기하는가"가 보인다

상황	CP(일관성 우선)	AP(가용성 우선)
분할 발생 시 사용자 경험	일부 요청을 막거나 지연시켜 "틀린 값" 노출을 줄인다	응답은 유지하되 "잠시 어긋난 값"을 허용한다
대표 데이터	결제 상태, 재고 차감, 권한 변경	피드, 추천, 조회수, 캐시된 목록
장애 시 비용	실패율 증가, 타임아웃 증가	중복 처리, 순서 뒤바뀜, 충돌 해결
운영 판단	장애 중에도 "맞는 값" 기준으로 결정	장애 중 "임시 값"임을 전제로 안내

이 표의 요지는 "CP가 좋다, AP가 좋다"가 아니다.

분할이 생기면 C와 A를 동시에 100%로 유지하기 어렵다는 현실을 문장으로 고정하는 데 의미가 있다.

YES/NO 체크리스트로 서비스 성격을 빠르게 분류한다

• YES: 금액·재고·권한처럼 틀린 값이 바로 사고로 이어지는 데이터가 있다
• YES: 같은 키를 여러 지역/노드에서 동시에 업데이트할 가능성이 있다
• YES: 데이터가 "한 번만 처리"되어야 하며 중복이 허용되지 않는다
• NO: 잠깐 다른 값이 보여도 사용자 피해가 제한적이며, 나중에 맞추면 된다
• NO: 충돌이 나면 덮어쓰기/정렬/병합 같은 규칙으로 정리해도 된다
• NO: 장애 시에도 기능 중단보다 응답 유지가 더 우선이다

YES가 위쪽에 몰리면 CP 성향이 강해지고, NO가 아래쪽에 몰리면 AP 성향으로 기운다.

다만 한 시스템 안에서도 기능별로 성향이 다르며, 이 혼합이 실무에서 가장 흔한 형태다.

확인 순서를 정해 두면 "CAP 논쟁"이 "증거 기반 결정"으로 바뀐다

분할이 의심되는 장애에서 CAP를 논의할 때는 먼저 분할의 흔적과 영향 범위를 확인해야 한다.

아래 절차는 도구가 달라도 적용할 수 있도록 "경로/메뉴/체크 포인트" 형태로 정리한 흐름이다.

1. 경로: 모니터링 대시보드 → 네트워크/인프라 패널 → 지역/존별로 분리해서 보기
2. 체크 포인트: 한쪽만 타임아웃이 증가하거나, 특정 존의 오류율이 급증하는지 확인한다.
3. 경로: 로그 검색 → "timeout", "connection reset", "unreachable" 같은 키워드로 필터
4. 체크 포인트: 같은 시각에 여러 서비스가 서로를 호출하다 끊긴 흔적이 동시에 나타나는지 확인한다.
5. 경로: 데이터 저장소 상태 페이지/콘솔 → 리더/팔로워 상태 및 지연 지표 확인
6. 체크 포인트: 복제 지연이 커졌거나, 리더 선출/재선출이 반복되는지 확인한다.
7. 경로: 애플리케이션 설정/피처 플래그 → "읽기 라우팅", "대체 경로", "캐시 사용" 옵션 확인
8. 체크 포인트: 장애 중에 읽기를 가까운 노드로 돌렸는지, 그 결과 값이 어긋날 여지가 생겼는지 확인한다.
9. 경로: 운영 런북(runbook) 정책 문서 → "장애 시 우선순위" 항목 확인
10. 체크 포인트: 해당 기능이 CP로 설계된 것인지 AP로 설계된 것인지, 사용자 안내 문구까지 포함해 확인한다.

분할 의심 장애에서 CAP 관점으로 판단하는 흐름

사례로 보면 "어긋남"이 왜 생기는지 한 번에 연결된다

문제: 주문 생성은 성공했는데, 주문 조회 화면에서 30초 동안 "주문이 없음"으로 보였다.

왜 발생: 쓰기는 A 지역에서 처리됐지만, 읽기는 장애 회피 설정 때문에 B 지역의 캐시/복제본으로 라우팅 되었고 전파가 늦었다.

어떤 선택이 적합: 주문 조회처럼 사용자 불안을 키우는 화면은 짧은 시간이라도 "최근 쓰기 반영"을 우선하는 경로를 분리하는 편이 맞다.

잘못 쓰면 어떤 문제: 모든 화면을 CP로 강제하면 분할 시 실패율이 커져 결제 자체가 막히는 상황이 생길 수 있다.

확인/해결: 장애 시 읽기 라우팅 정책과 캐시 무효화 규칙을 점검하고, "쓰고 바로 읽는 구간"만 예외 경로로 설계한다.

[로그 예]
region=A write_order success order_id=582194 at 10:21:05.113
region=B read_order miss cache_key=order:582194 at 10:21:06.004
region=B replica_lag_seconds=28
message="fallback_read_to_nearest_region=true"

이 사례에서 핵심은 시스템이 한 가지 성향으로만 동작하지 않았다는 점이다.

평상시에는 AP처럼 빠르게 응답하다가, 특정 구간은 CP처럼 맞춰야 사용자가 혼란을 덜 겪는다.

결론

CAP는 분할이 생기는 현실을 전제로, 일관성과 가용성 중 어떤 손실을 감수할지 정리하는 틀이다.

같은 서비스 안에서도 기능과 데이터 성격에 따라 CP 성향과 AP 성향이 섞일 수 있다.

분할 흔적을 확인하고, 사용자 피해가 큰 구간부터 예외 경로를 설계하면 "논쟁"이 "정책"으로 바뀐다.

연계 주제 제안: 최종 일관성에서 충돌을 다루는 방법(버전/ETag/재시도), 복제 지연과 캐시 무효화가 UX에 미치는 영향이 함께 이어지기 좋다.

FAQ

Q1. CAP에서 P(분할 허용)는 선택이 아니라 필수라는 말은 무슨 뜻인가

분산 시스템에서는 네트워크 단절이 아예 없다고 가정하기 어렵다.

따라서 분할이 생겼을 때도 동작하도록 설계하는 전제(P)를 깔고, 그 순간 C와 A의 우선순위를 정하게 된다.

Q2. CP를 선택하면 항상 데이터가 맞고, AP를 선택하면 항상 데이터가 틀린가

CP는 분할 중에 "맞는 값을 유지하려고 실패를 늘릴 수 있다"는 방향에 가깝다.

AP는 분할 중에 "응답을 유지하되 잠깐 어긋남을 허용한다"는 방향이며, 이후 보정으로 맞출 수 있다.

Q3. 초보자가 실무에서 가장 먼저 정해야 할 CAP 관련 결정은 무엇인가

"쓰고 바로 읽는 구간"에서 틀린 값이 허용되는지부터 정하는 편이 빠르다.

그 구간을 분리해 별도 경로로 만들면, 나머지 영역은 성능과 가용성을 우선하는 설계를 적용하기 쉬워진다.