백엔드 면접 용어 사전
시스템 설계

PACELC

분단 시 A/C, 정상 시 지연(L)/일관성(C)의 선택을 함께 보는 확장 모델.

CAP을 확장해 분단이 없는 평상시의 선택까지 포함한 모델.

if (P)thenA or C분단이 나면 → 가용성이냐 일관성이냐
elseL or C평상시에는→ 지연(Latency)이냐 일관성이냐

읽는 법: Partition이면 Availability냐 Consistency냐, Else Latency냐 Consistency냐.

왜 CAP만으로는 부족한가

분단은 드문 사건이다. 1년에 몇 번 있을까 말까 한 상황을 두고 시스템 성격을 규정하는 것은 실용적이지 않다.

정작 매일 영향을 주는 것은 평상시의 트레이드오프다.

쓰기를 할 때 모든 복제본의 확인을 기다린다  → 일관성 ↑, 지연 ↑
리더만 쓰고 바로 응답한다                  → 지연 ↓, 일관성 ↓

이 선택이 사용자가 매일 체감하는 것이다. PACELC는 이것을 명시적으로 다룬다.

분류

시스템분류읽는 법
DynamoDB, CassandraPA/EL분단 시 가용성, 평상시 저지연
BigTable, HBasePC/EC항상 일관성 우선
MongoDBPA/EC분단 시 가용성, 평상시 일관성
MySQL 클러스터PC/EC항상 일관성
PNUTS(야후)PC/EL분단 시 일관성, 평상시 저지연

PA/EL 조합이 가장 흔하다 — 인터넷 서비스는 대체로 속도와 가용성을 우선한다.

왜 평상시에도 트레이드오프가 있나

복제본이 여러 곳에 있으면 동기화 자체에 시간이 든다.

서울 ─── 미국 서부 : 왕복 약 150ms

미국 복제본의 확인까지 기다리면 모든 쓰기가 150ms 이상 걸린다. 안 기다리면 빠르지만 미국에서 읽는 사용자는 옛 값을 볼 수 있다.

분단이 없어도 물리적 거리는 존재한다 — 이것이 PACELC의 통찰이다. 빛의 속도는 협상 대상이 아니다.

설계에 어떻게 쓰나

같은 시스템 안에서도 데이터마다 다르게 정할 수 있다.

  • 결제 트랜잭션 — → EC (느려도 정확하게)
  • 상품 조회 — → EL (빠르게, 잠깐 옛 값이어도 됨)
  • 재고 표시 — → EL (표시는 대략)
  • 재고 차감 — → EC (실제 차감은 정확히)

"재고 표시는 EL, 차감은 EC" 같은 구분이 실무의 답이다. 전체를 한쪽으로 몰지 않는다.

면접에서

CAP만 말하면 평범하지만, "CAP은 분단 시만 다루는데 실제로는 평상시의 지연-일관성 트레이드오프가 더 자주 문제가 됩니다" 라고 하면 분산 시스템을 실제로 고민해 본 사람으로 보인다.

함께 보면 좋은 용어

노트에서 맥락과 함께 보기 — 시스템 설계·분산 — CAP·복제·샤딩·Saga·서킷브레이커