CAP 정리

분산 시스템은 일관성(C)·가용성(A)·분단 내성(P) 셋 중 둘만 동시에 만족할 수 있다는 정리.

세 글자의 정확한 뜻 — 여기서 오해가 시작된다

주의 — CAP의 C는 ACID의 C와 완전히 다르다. ACID의 C는 "제약조건 위반이 없다"이고, CAP의 C는 "모든 노드가 같은 값을 본다"이다.

"셋 중 둘"이라는 말이 오해를 부른다

P는 선택 사항이 아니다. 네트워크는 반드시 끊긴다 — 케이블, 스위치, 방화벽, GC 정지, 패킷 손실. 분산 시스템을 만드는 이상 P를 버릴 수 없다.

그래서 실제 선택은 "분단이 발생했을 때 C와 A 중 무엇을 포기할 것인가" 다.

분단이 일어난 순간을 상상해 보자

        ✂ 네트워크 단절 ✂
노드 A  ┃  노드 B
값: 10  ┃  값: 10

클라이언트가 노드 A에 "값을 20으로 바꿔줘" 요청 A는 B에게 전달할 수 없다. 이제 어떻게 할 것인가?

선택 1 — CP (일관성 우선)

• A: "지금은 처리할 수 없습니다" 라고 에러 반환
• 두 노드가 어긋나는 일은 없다 (C 유지)
• 하지만 요청을 거절했다 (A 포기)

선택 2 — AP (가용성 우선)

A: 일단 20으로 바꾸고 성공 응답
→ 응답은 했다 (A 유지)
→ 하지만 B는 아직 10 — 두 노드가 다르다 (C 포기)
→ 나중에 합쳐야 한다 (최종 일관성)

실제 시스템의 분류

설정으로 바뀌는 경우가 많다. Cassandra도 쿼럼 수준을 올리면 CP에 가까워지고, MongoDB도 write concern을 낮추면 AP에 가까워진다. 이분법이 아니라 스펙트럼이다.

무엇을 골라야 하나 — 도메인이 결정한다

• 결제·재고 차감 — → CP. 틀린 값보다 "잠시 안 됨"이 낫다
• 좋아요 수·조회수 — → AP. 잠깐 달라도 무방, 안 보이는 게 더 나쁘다
• 설정·리더 선출 — → CP. 리더가 둘이 되면 재앙(split-brain)
• 장바구니 — → AP. 아마존은 "담기"를 절대 실패시키지 않는다

아마존의 유명한 판단 — 장바구니 담기는 절대 실패하면 안 되므로 AP를 택하고, 충돌하면 두 장바구니를 합친다. 사용자가 지운 물건이 되살아나는 부작용이 있지만, "담기 실패"보다 낫다고 본 것이다.

면접 답변 골격

"P는 선택할 수 없으므로 실제 질문은 분단 시 C와 A 중 무엇을 포기하느냐입니다. 그리고 CAP은 분단 상황만 다루므로, 평상시의 지연까지 고려하려면 PACELC로 보는 것이 더 실용적입니다."

이 마지막 문장이 다음 단계 이해를 보여 준다.