PACELC는 CAP 뒤에 한 질문을 더 붙입니다
같은 분산 DB라도, 파티션 시점과 정상 시점의 우선순위는 다를 수 있습니다.

장애가 생기면 P에서 C vs A를 고르고, 장애가 없을 때도 E에서 L vs C를 고릅니다. 그래서 PACELC는 "어떤 DB가 무엇을 포기하는가"를 더 구체적으로 읽게 해줍니다.

파티션 발생 시 P
C vs A

노드 간 연결이 끊기면 데이터 일관성을 지킬지, 일부 불일치를 감수하고 계속 응답할지 선택합니다.

정상 운영 시 E
L vs C

파티션이 없어도 응답 지연을 더 낮출지, 더 강한 일관성을 위해 추가 조율을 감수할지 선택합니다.

대표 시스템을 패턴으로 읽기 C = 일관성, A = 가용성, L = 낮은 지연
패턴 / 예시
P
E
읽는 포인트
일관성 유지형 MySQL(InnoDB), MongoDB, CockroachDB
C
C
장애 시에도 정합성을 우선하고, 평상시에도 조율 비용을 감수하며 강한 일관성을 지향합니다.
가용성·지연 우선형 Cassandra, DynamoDB
A
L
끊김 상황에서는 응답 지속을, 평상시에는 빠른 처리와 확장성을 더 중시하는 계열입니다.
혼합형 Spanner
C
L
파티션에서는 일관성을 지키되, 정상 시에는 TrueTime 같은 장치로 지연을 줄이려는 절충을 보여줍니다.
핵심: CAP가 "장애가 나면 무엇을 지킬까?"를 묻는다면, PACELC는 여기에 "장애가 없어도 어떤 비용을 감수할까?"를 추가해 분산 DB의 운영 성격을 더 선명하게 드러냅니다.