CAP 정리 (CAP Theorem)
쉽게 풀면
여러 지점에 매장을 둔 은행을 떠올려 보세요. 지점 사이의 통신선이 끊기는 "분단(Partition)" 상황은 언제든 일어날 수 있고, 분산 시스템은 이를 견뎌야 합니다. 그런데 통신이 끊긴 상태에서 한 지점이 계속 서비스를 제공하려 하면(가용성, Availability), 그 지점의 잔액 정보가 다른 지점과 다를 수 있습니다(일관성, Consistency 훼손). 반대로 모든 지점의 잔액을 항상 똑같이 맞추려면(일관성), 통신이 끊긴 지점은 서비스를 잠시 멈춰야 합니다(가용성 포기). CAP 정리는 바로 이 상황, 즉 네트워크 분단이 발생했을 때 일관성과 가용성 중 하나는 반드시 포기해야 한다는 것을 수학적으로 증명한 이론입니다.
왜 중요한가
클라우드 서비스는 대부분 여러 지역의 서버에 데이터를 복제해 두는 분산 시스템으로 운영되며, 네트워크 장애는 예외가 아니라 언제든 벌어질 수 있는 일상적인 조건입니다. CAP 정리는 이런 환경에서 시스템 설계자가 무엇을 포기할지를 명시적으로 선택하게 만드는 이론적 근거를 제공하기 때문에, 데이터베이스·분산 스토리지·마이크로서비스 아키텍처를 다루는 논문에서 설계 근거를 설명할 때 빠짐없이 등장합니다. 또한 이 정리는 이후 등장한 다양한 절충안(예: 결과적 일관성 모델)과 신뢰도 있는 합의 알고리즘 연구의 출발점이 되었다는 점에서도 자주 인용됩니다.
논문에서는 이렇게 쓰입니다
이 문장은 설계자가 통신 장애가 생겼을 때 "무조건 데이터를 정확히 일치시키기"보다 "서비스가 멈추지 않고 응답하는 것"을 우선순위로 골랐다는 뜻입니다. 어떤 두 속성을 선택할지는 서비스의 성격(예: 금융 거래 vs. SNS 피드)에 따라 달라집니다.
사물인터넷처럼 통신이 자주 끊기는 환경을 다루는 논문에서는, 일부 정보가 잠시 어긋나더라도 시스템 전체가 멈추지 않는 쪽을 택하는 경우가 많습니다. 이때도 CAP 정리는 왜 그런 설계를 택했는지를 설명하는 이론적 근거로 인용됩니다.
반대로 금융이나 결제처럼 데이터가 조금이라도 어긋나면 안 되는 분야의 논문에서는, 통신 장애가 나면 차라리 서비스를 잠시 중단하더라도 모든 지점의 값을 일치시키는 쪽을 택했다고 설명하는 예문이 자주 나타납니다.
조금 더 깊게 보면
CAP 정리를 넘어서 논문을 읽다 보면 "결과적 일관성(Eventual Consistency)"이나 "강한 일관성(Strong Consistency)"처럼 일관성의 정도를 세분화한 표현을 자주 마주치게 됩니다. 이는 CAP 정리가 일관성을 "지킨다/포기한다"의 이분법으로 단순화한 것과 달리, 실제 시스템은 그 사이의 다양한 수준을 절충안으로 채택하기 때문입니다. 아울러 CAP 정리와 함께 "PACELC"라는 확장 개념이 언급되기도 하는데, 이는 분단이 없는 평상시에도 지연 시간(Latency)과 일관성 사이에 별도의 트레이드오프가 존재한다는 점을 보완해 설명하는 개념입니다. 어떤 절충안을 택했는지는 대체로 시스템의 합의 알고리즘이나 복제 방식에 대한 서술을 통해 확인할 수 있습니다.
주의할 점
CAP 정리는 "세 가지 중 반드시 하나를 완전히 버려야 한다"는 극단적 이분법으로 자주 오해되지만, 실제 시스템은 네트워크가 정상일 때는 세 속성을 모두 만족하다가 분단이 발생한 "그 순간"에만 트레이드오프가 생깁니다. 또한 분산 합의 알고리즘 알고리즘이나 일관성 해싱과 함께 언급되지만 서로 다른 개념이므로 혼동하지 않아야 합니다.