분산 데이터베이스 설계의 핵심은 ‘CAP에서 무엇을 포기할 것인가’가 아니라, 장애 상황에서 어떤 데이터에 어떤 보장을 적용할지 정하는 데 있다. 결제·재고처럼 중복 처리가 위험한 데이터는 일관성을 우선하고, 조회수·추천·온라인 상태처럼 잠시 늦어도 되는 데이터는 가용성과 지연 시간을 우선할 수 있다.
📌 핵심 5줄 요약
1. CAP의 C는 모든 데이터가 항상 같다는 뜻이 아니라, 분산 환경에서 단일한 최신 상태처럼 읽히는 보장을 의미한다.
2. A는 일부 노드가 고장 나도 모든 정상 요청이 오류 없이 응답해야 한다는 보장이다.
3. P는 노드 사이의 통신이 끊기거나 지연되는 네트워크 분할을 견디는 성질이다.
4. 네트워크 분할이 발생하면 CP는 일부 요청을 거절하거나 대기하고, AP는 서로 다른 값을 허용한 뒤 나중에 수렴시킨다.
5. 실무에서는 시스템 전체가 아니라 기능·데이터·작업 단위별로 일관성 정책을 다르게 설계하는 것이 일반적이다.
📌 목차
01 | 분산 데이터베이스에서 일관성이 중요한 이유
02 | CAP 정리의 세 가지 요소
03 | CAP 정리에서 말하는 일관성
04 | 가용성과 분할 내성의 의미
05 | 네트워크 분할이 발생하는 순간
06 | CP와 AP의 차이
07 | 최종 일관성과 강한 일관성
08 | 쿼럼과 복제 수의 관계
09 | 실제 설계에서 데이터 분류하기
10 | 충돌 해결 전략 선택하기
11 | Cassandra형 설계의 특징
12 | Spanner형 강한 일관성 설계
13 | 흔히 하는 CAP 오해
01 | 분산 데이터베이스에서 일관성이 중요한 이유
분산 데이터베이스는 여러 서버에 같은 데이터를 복제하거나 데이터를 나누어 저장한다. 이를 통해 처리량과 장애 대응 능력을 높일 수 있지만, 한 서버에서 변경한 값이 다른 서버에 언제 반영되는지라는 문제가 생긴다.
예를 들어 사용자가 한 지역에서 상품을 구매한 직후 다른 지역 서버에 접속했을 때 재고가 여전히 남아 보일 수 있다. 이 지연이 허용되지 않으면 중복 판매가 발생할 수 있고, 반대로 모든 읽기 요청이 최신 복제 완료를 기다리면 응답 시간이 길어지거나 일부 장애 상황에서 서비스가 중단될 수 있다.
02 | CAP 정리의 세 가지 요소
CAP 정리는 분산 데이터 저장소가 다음 세 가지 성질을 네트워크 분할 상황에서 동시에 모두 보장할 수 없다는 이론이다. 이 정리는 에릭 브루어가 제안했고, 길버트와 린치가 분산 웹 서비스 모델에서 형식적으로 증명했다.
| 요소 | 의미 |
|---|---|
| 일관성 | 모든 클라이언트가 동일한 최신 상태를 관찰하도록 보장한다. |
| 가용성 | 정상적으로 동작하는 노드가 모든 요청에 응답하도록 보장한다. |
| 분할 내성 | 노드 사이의 네트워크가 끊기거나 메시지가 지연되어도 시스템이 동작하도록 설계한다. |
‘세 가지 중 두 개를 고르면 된다’고 단순화하기 쉽지만, 실제 핵심은 네트워크 분할이 발생한 순간 C와 A 중 어느 보장을 유지할지 결정하는 것이다.
03 | CAP 정리에서 말하는 일관성
CAP의 일관성은 데이터베이스의 ACID 전체를 뜻하지 않는다. 특히 트랜잭션의 원자성, 격리 수준, 내구성까지 모두 보장한다는 의미가 아니다. CAP에서 말하는 C는 복제된 데이터에 대해 각 클라이언트가 서로 모순되는 상태를 관찰하지 않도록 하는 분산 시스템의 일관성 보장에 가깝다.
실무에서는 선형화 가능성, 직렬 가능성, 읽기 일관성, 인과적 일관성, 최종 일관성처럼 여러 수준을 구분해야 한다. 따라서 ‘이 데이터베이스는 일관성이 있다’는 표현만으로는 부족하며, 어떤 연산과 어떤 범위에서 어떤 읽기 결과를 보장하는지 명시해야 한다.
04 | 가용성과 분할 내성의 의미
CAP에서 가용성은 단순히 서버가 살아 있다는 뜻이 아니다. 일부 노드가 정상이고 네트워크 분할이 발생했을 때에도, 정상 노드가 요청을 처리해 결과를 반환해야 한다는 의미다.
분할 내성은 오늘날 여러 노드와 네트워크를 사용하는 시스템에서 사실상 중요한 설계 조건이다. 케이블 장애, 라우팅 오류, 리더와 팔로어 사이의 통신 지연, 리전 간 연결 문제처럼 메시지가 유실되거나 늦게 도착하는 상황을 완전히 제거하기 어렵기 때문이다.
05 | 네트워크 분할이 발생하는 순간
두 복제 그룹이 서로 통신하지 못하는 상황을 생각해 보자. 양쪽이 모두 쓰기를 허용하면 같은 상품의 재고나 같은 계정의 잔액에 서로 다른 변경이 기록될 수 있다. 이후 연결이 복구되면 시스템은 두 변경을 병합해야 한다.
이때 CP 방식은 합의에 필요한 노드에 접근하지 못하면 쓰기를 거부하거나 읽기를 제한한다. AP 방식은 각 지역의 요청을 계속 처리하고, 복구 후 버전 비교·병합·업무 규칙을 이용해 상태를 맞춘다. 어느 쪽이 옳은지는 데이터 손실 비용과 서비스 중단 비용을 비교해 결정한다.
06 | CP와 AP의 차이
| 구분 | 장애 상황의 선택 | 적합한 예 |
|---|---|---|
| CP | 일관성을 지키기 위해 일부 요청을 대기·실패 처리한다. | 결제 상태, 재고 차감, 권한 변경 |
| AP | 서비스 응답을 유지하고 일시적인 값 차이를 허용한다. | 피드, 조회수, 추천 결과, 온라인 상태 |
| 혼합형 | 핵심 상태는 CP, 부가 데이터는 AP로 나눈다. | 주문 시스템과 검색 색인·알림 기능 |
CP와 AP는 데이터베이스 제품의 영구적인 성격이라기보다 특정 구성과 요청 경로에서의 선택으로 이해하는 편이 정확하다. 같은 제품도 읽기 수준, 쓰기 수준, 리전 배치, 장애 정책에 따라 다른 동작을 할 수 있다.
07 | 최종 일관성과 강한 일관성
강한 일관성은 쓰기가 성공한 뒤 이후의 읽기가 그 변경을 관찰할 수 있도록 하는 방향의 보장이다. 선형화 가능한 시스템은 각 연산이 하나의 전역 순서 안에서 실행된 것처럼 보이게 한다.
최종 일관성은 업데이트가 즉시 모든 복제본에 보이지 않을 수 있지만, 새로운 변경이 멈추고 통신과 복구가 정상화되면 복제본이 같은 상태로 수렴한다는 모델이다. 최종 일관성을 사용하려면 사용자가 잠시 오래된 데이터를 보거나, 동시에 수정된 값이 충돌하는 상황을 애플리케이션이 처리할 수 있어야 한다.
최종 일관성은 데이터가 사라져도 된다는 뜻이 아니다. 복제 지연, 충돌 병합, 재시도, 중복 이벤트, 삭제 전파를 별도로 설계하지 않으면 최종 상태가 예상과 다르게 수렴할 수 있다.
08 | 쿼럼과 복제 수의 관계
복제 수를 N, 쓰기에 필요한 응답 수를 W, 읽기에 필요한 응답 수를 R이라고 하면, 흔히 W + R이 N보다 큰 구성을 사용해 읽기 집합과 쓰기 집합이 겹치도록 만든다. Apache Cassandra 문서도 Dynamo 방식의 쿼럼 원리와 일관성 수준을 설명하며, 충분한 읽기·쓰기 집합이 겹치면 최신 쓰기를 확인할 가능성과 보장을 높일 수 있다고 설명한다.
다만 쿼럼만으로 모든 문제가 해결되지는 않는다. 동시 쓰기 충돌, 시계 차이, 삭제된 데이터의 재등장, 네트워크 재시도에 따른 중복 처리, 리전 장애와 지연 시간까지 함께 검토해야 한다.
09 | 실제 설계에서 데이터 분류하기
설계의 첫 단계는 기능 목록이 아니라 데이터 항목별 실패 비용을 정하는 것이다. 다음과 같이 분류하면 CAP 선택이 구체화된다.
강한 일관성이 필요한 데이터
잔액, 결제 승인, 재고 차감, 좌석 배정, 권한 변경처럼 중복 처리나 잘못된 순서가 직접적인 손실로 이어지는 데이터다. 이 경우 쓰기 전에 리더나 합의 가능한 복제본을 확인하고, 조건부 갱신이나 트랜잭션을 사용한다.
지연을 허용할 수 있는 데이터
상품 설명 캐시, 검색 색인, 추천 결과, 조회수, 알림 상태처럼 잠시 오래된 값이 보여도 핵심 거래가 깨지지 않는 데이터다. 비동기 이벤트와 재처리를 활용하면 가용성과 확장성을 높일 수 있다.
10 | 충돌 해결 전략 선택하기
AP 성격의 시스템은 연결 복구 후 충돌을 해결해야 한다. 단순한 최종 쓰기 승자는 구현이 쉽지만, 네트워크 지연이나 서버 시계 차이에 따라 정당한 변경이 덮어써질 수 있다.
대안으로 버전 번호, 논리 시계, 벡터 시계, 애플리케이션별 병합 함수, 충돌 이벤트를 운영자에게 전달하는 방식을 사용할 수 있다. 장바구니는 항목 합집합처럼 병합할 수 있지만, 송금 상태는 자동 병합보다 중복 방지 키와 단일 처리 주체가 더 적합할 수 있다.
11 | Cassandra형 설계의 특징
Cassandra는 작업별 일관성 수준을 선택할 수 있는 튜너블 일관성 모델을 제공한다. 문서에는 단일 노드 응답에 가까운 수준부터 쿼럼 기반 수준까지 다양한 선택지가 설명되어 있으며, 읽기와 쓰기의 조합을 통해 지연 시간과 일관성 사이의 균형을 조정할 수 있다.
이 방식은 지역별 서비스 가용성과 높은 쓰기 처리량이 중요한 경우 유용하지만, 애플리케이션이 어떤 읽기 수준을 선택했는지와 충돌을 어떻게 복구하는지까지 함께 관리해야 한다. 데이터 모델도 조회 패턴에 맞춰 설계해야 하며, 여러 파티션에 걸친 복잡한 트랜잭션을 당연하게 기대해서는 안 된다.
12 | Spanner형 강한 일관성 설계
Google Spanner는 전역 분산 환경에서 트랜잭션 순서를 관리하고 외부 일관성을 제공하는 시스템의 대표 사례다. Google 문서에 따르면 외부 일관성은 트랜잭션이 순차적으로 실행된 것처럼 보이면서, 커밋이 관찰되는 순서와 직렬 순서가 일치하도록 하는 보장이다.
이런 설계는 강한 보장을 제공하는 대신 합의, 복제, 리전 간 통신, 트랜잭션 조정에 따른 비용과 지연을 고려해야 한다. 즉 ‘강한 일관성은 불가능하다’가 아니라, 강한 보장을 얻기 위해 시스템이 추가적인 조정 비용을 지불한다는 관점이 중요하다.
13 | 흔히 하는 CAP 오해
오해 1. 모든 시스템은 무조건 C·A·P 중 하나를 버린다
CAP의 핵심은 분할이 발생했을 때 C와 A를 동시에 유지하기 어렵다는 것이다. 네트워크가 정상일 때는 강한 일관성과 높은 가용성을 함께 제공할 수 있으며, 분할이 발생하는 범위와 지속 시간에 따라 동작도 달라진다.
오해 2. AP는 데이터가 계속 틀린 상태라는 뜻이다
AP 시스템도 버전 관리, 재시도, 읽기 복구, 이벤트 재처리, 병합 규칙을 통해 상태를 수렴시킬 수 있다. 다만 수렴 시점과 충돌 처리 책임이 데이터베이스 또는 애플리케이션 중 어디에 있는지 확인해야 한다.
오해 3. ACID와 CAP는 같은 개념이다
ACID는 트랜잭션의 처리 특성을 설명하는 개념이고, CAP는 네트워크 분할 상황에서 분산 복제 시스템이 제공하는 보장의 한계를 설명한다. 강한 트랜잭션을 지원하는 분산 시스템도 구성과 장애 조건에 따라 CAP 관점의 선택을 해야 한다.
☑ 체크리스트
☑ 데이터 항목별로 오래된 값이 허용되는 시간을 정했는가
☑ 중복 결제·중복 차감·중복 예약을 막을 멱등 키가 있는가
☑ 네트워크 분할 때 읽기와 쓰기를 각각 어떻게 처리할지 정의했는가
☑ 복제 지연과 충돌을 감지할 지표와 로그가 있는가
☑ 장애 복구 후 어떤 순서로 재동기화할지 정했는가
☑ 쿼럼 설정이 실제 리전 배치와 장애 도메인에 맞는가
☑ 강한 일관성 비용과 서비스 중단 비용을 함께 비교했는가
📝 마무리
CAP 정리는 분산 데이터베이스를 CP와 AP 중 하나로 단순 분류하는 암기 법칙이 아니다. 네트워크 분할이라는 실패 상황에서 데이터별로 어떤 오류를 허용할지 결정하고, 그 선택을 복제·트랜잭션·충돌 해결·운영 지표로 구체화하는 설계 원칙이다.
가장 실용적인 접근은 결제와 재고 같은 핵심 상태에는 강한 보호 장치를 두고, 검색·추천·통계 같은 부가 기능에는 지연과 최종 일관성을 허용하는 혼합형 구조를 만드는 것이다.