셋 중 둘이 아니다
CAP은 흔히 “일관성·가용성·분단 내성 중 둘만 고를 수 있다”로 소개된다. 이 요약이 오해를 만든다.
P는 선택지가 아니다. 네트워크는 끊긴다. 패킷은 유실되고 지연되며 노드는 죽는다. 분산 시스템을 만드는 이상 분단은 일어나는 사건이지 고르는 옵션이 아니다.
정확한 진술은 이렇다.
네트워크 분단이 일어났을 때, 일관성과 가용성 중 하나를 포기해야 한다.
분단이 일어나면
노드 A와 B가 서로 통신할 수 없게 됐다. 클라이언트가 A에 쓰기를 요청한다.
- 일관성을 지키려면 — B에 전파할 수 없으니 요청을 거부한다. 낡은 값을 읽는 일은 없지만 쓸 수 없다
- 가용성을 지키려면 — 일단 A에 쓰고 나중에 맞춘다. 계속 쓸 수 있지만 B를 읽는 클라이언트는 낡은 값을 본다
이게 CAP이 말하는 전부다. “CA 시스템”이라는 말이 성립하지 않는 이유이기도 하다. 그건 분산 시스템이 아니라 단일 노드다.
CAP은 평소에 대해 말하지 않는다
더 중요한 한계가 있다. 분단은 드물게 일어난다. 그런데 시스템은 대부분의 시간을 정상 상태로 보낸다. CAP은 그 시간에 대해 아무것도 알려주지 않는다.
Daniel Abadi가 제안한 PACELC가 이 빈틈을 메운다.
if (P) then A or C, else L or C
분단이 아닐 때(Else)에도 선택이 남는다. 지연(Latency)과 일관성 사이다. 모든 복제본의 확인을 받고 응답하면 일관되지만 느리다. 하나만 확인하고 응답하면 빠르지만 낡은 값을 읽을 수 있다.
실제 운영에서 매일 체감하는 건 이쪽이다.
기능 단위로 다르다
시스템 전체를 하나로 분류할 필요도 없다.
- 결제 잔액 → 일관성. 느려도 틀리면 안 된다
- 조회수, 좋아요 수 → 가용성. 잠깐 어긋나도 된다
- 상품 목록 캐시 → 지연 우선. 몇 초 낡아도 문제없다
같은 서비스 안에서도 데이터마다 답이 다르다.
정리
- P는 고르는 게 아니라 대비하는 것이다
- CAP은 분단 상황에 한정된 이야기다
- 평소의 선택은 지연과 일관성 사이에 있다
- 시스템이 아니라 데이터와 기능 단위로 정한다