시스템 설계·분산 — 백엔드 면접 (실제 기출 기반·심화)

"트래픽 10배면 어떻게 확장", "CAP 정리", "레플리케이션 vs 샤딩", "분산 트랜잭션을 Saga로", "서킷 브레이커", "선착순 재고 동시성" — 주니어~시니어 경계를 가르는 단골. 정답보다 트레이드오프 설명이 핵심이다.

함정형 단골: ① CAP는 셋 중 둘? → 분할(P) 시에만 C/A 택1(PACELC가 정밀) ② Saga가 2PC를 완전 대체? → 최종 일관성·격리성 약함 ③ 서킷 브레이커만 달면 끝? → 타임아웃·벌크헤드 병행.

---

1. 확장·복제·샤딩 (★★ 단골)

실제 질문: "트래픽이 10배가 되면 어떻게 확장하나요?" · "레플리케이션과 샤딩 중 무엇을 쓸 건가요?" (VSFe·WeareSoft)

• 수직(scale-up): 사양↑(간단·한계·SPOF) vs 수평(scale-out): 대수↑(무한 확장·상태 문제 → stateless + 로드밸런서).
• 복제(Replication): 같은 데이터를 여러 노드에 → 읽기 확장·가용성. ⚠️ 복제 지연(replication lag) → 슬레이브 읽기가 stale → 쓰기 직후 읽기는 마스터로(read-your-writes).
• 샤딩(Sharding): 데이터를 쪼개 여러 DB 서버로 → 쓰기/용량 수평 확장. 과제: 샤드 간 조인·트랜잭션 불가·리밸런싱·핫스팟·글로벌 유니크 키.
• 파티셔닝(한 DB 내 분할: 수평=행/수직=컬럼) vs 샤딩(여러 서버).

꼬리질문: "복제로 쓰기 확장?" → 안 됨(쓰기는 마스터 한 곳) → 샤딩. / "샤드 키를 잘못 잡으면?" → 핫스팟(특정 샤드 집중). / "트래픽 10배 접근?" → 캐시·읽기 복제·비동기 큐·샤딩·CDN·오토스케일 — 측정해서 병목부터.

함정: ❌ "복제로 쓰기 부하 분산" → 읽기만.

---

2. CAP·PACELC (★★★ 단골·함정)

실제 질문: "CAP 정리를 설명하라." · "PACELC는?" · "MySQL은 CAP상 어디인가요?"

CAP는 "네트워크 파티션이 일어났을 때"의 선택이다(평시엔 셋 다 가능).

• Consistency·Availability·Partition tolerance. 파티션 내성은 선택이 아니다(네트워크 장애는 불가피) → 파티션 시 실질 선택은 CP vs AP:
  • CP(일관성 우선): 최신 보장 못 하면 거부(은행 잔액).
  • AP(가용성 우선): 응답하되 stale 가능·나중에 수렴(SNS 좋아요).
• PACELC: If Partition → A or C, Else → Latency or Consistency(Abadi). 파티션이 없을 때조차 강한 일관성을 위해 여러 노드를 기다리면 느려진다.

꼬리질문: "MySQL은 CAP상?" → 단일 노드는 CA 성향·복제 구성에 따라 다름. / "P를 포기할 수 있나?" → 현실 분산은 P 필수 → CA는 비현실. / "Redis/Mongo는?" → 구성에 따라(Mongo AP 성향·Redis CP 성향).

함정: ❌ "CAP는 셋 중 둘을 항상 고른다" → 분할 시에만 C/A 택1(평시엔 셋 다)·PACELC가 정밀.

---

3. 분산 트랜잭션·Saga (★★★ 단골)

실제 질문: "분산 환경에서 트랜잭션을 어떻게 관리하나요?" · "Saga 패턴을 설명하라. Choreography vs Orchestration?" (VSFe·junhyunny)

MSA는 서비스마다 DB(database-per-service)라 하나의 ACID로 못 묶는다.

• 2PC(2단계 커밋): prepare→commit. 강한 일관성이나 블로킹·코디네이터 SPOF·느림 → MSA 부적합.
• Saga: 분산 트랜잭션을 로컬 트랜잭션 연쇄로 쪼개고 실패 시 **보상 트랜잭션(compensating)**으로 되돌림.

• Choreography(중앙 없이 이벤트 발행/구독·단순·추적 어려움) vs Orchestration(중앙 오케스트레이터가 단계·상태 관리·명확·집중).
• Saga는 ACID가 아닌 최종 일관성(원자성=보상·격리성 없음·중간 상태 보임). 보상 트랜잭션은 멱등이어야.

꼬리질문: "Saga는 격리성이 없는데 dirty read는?" → 시맨틱 락·상태 플래그로. / "보상 트랜잭션이 실패하면?" → 재시도·수동 개입·멱등. / "outbox와 함께?" → 이벤트 발행 원자성(메시지큐 편).

함정: ❌ "Saga가 2PC를 완전 대체" → 최종 일관성·격리 약함 → 강일관 필요엔 부적합.

---

4. 장애 대응 — 서킷 브레이커·재시도·멱등 (★★ 단골)

실제 질문: "서킷 브레이커가 무엇이고 왜 필요한가요?" · "타임아웃·리트라이와 어떻게 조합하나요?" (resilience4j·올리브영)

• 서킷 브레이커(resilience4j): 의존 서비스 연속 실패율이 임계(failureRateThreshold) 초과 → OPEN(즉시 fallback·cascading failure 차단) → waitDuration 후 HALF_OPEN(탐색) → 성공 시 CLOSED.
• 멱등성(재시도 안전)·재시도+지수 백오프+지터(멱등할 때만)·타임아웃·벌크헤드(자원 격리)·폴백(degrade).

꼬리질문: "서킷 브레이커만 달면 끝?" → 아니다(★). 타임아웃·리트라이·벌크헤드를 함께 안 하면 스레드풀 고갈. / "HALF_OPEN에서 또 실패?" → 다시 OPEN. / "재시도가 위험할 때?" → 비멱등 연산(중복 결제) → 멱등 보장 먼저.

함정: ❌ "서킷 브레이커 하나면 장애 전파 끝" → 타임아웃·벌크헤드 병행 필요.

---

5. 동시성 처리 — 선착순·재고 (★ 단골)

실제 질문: "선착순 쿠폰·재고에서 동시성을 어떻게 처리하나요?" (실무 단골)

• DB 비관락(SELECT … FOR UPDATE·성능 비용)·낙관락(@Version·재시도)·Redis 분산락(Redisson)·원자 연산(UPDATE … WHERE stock>0·Redis DECR).
• 고경합(티켓팅)엔 원자 연산·분산락, 저경합엔 낙관락. (캐시·DB 편 연결)

꼬리질문: "분산 환경에서 DB 락만으로 충분?" → 부족하면 Redis 분산락(단 Redlock 한계). / "과매도 방지?" → UPDATE WHERE stock>0·원자 DECR.

---

6. 분산 ID·합의 (★ 심화)

• 분산 ID: auto-increment 불가 → Snowflake(타임스탬프+노드ID+시퀀스·시간순 정렬·중복 없음·고성능)·UUID·티켓 서버.
• 합의(Consensus): 여러 노드가 하나의 값/리더에 동의 → Raft·Paxos(리더 선출→로그 복제→과반 커밋). etcd·Kafka KRaft.

꼬리질문: "왜 UUID 대신 Snowflake?" → 시간순 정렬(인덱스 친화)·짧음. / "정족수?" → W+R>N이면 최신 보장(읽기/쓰기 집합 겹침).

---

7. 리버스 프록시·게이트웨이·내결함성 (★ 기출 보강·2026-07)

실제 질문: "리버스 프록시란? forward proxy와 차이는?" · "리버스 프록시 vs 로드밸런서 vs API 게이트웨이?" · "Fault-tolerant(무정지) 시스템으로 가려면 무엇이 필요한가?" (ksundong·gyoogle)

리버스 프록시(nginx 등): 클라이언트와 서버 사이에서 서버를 대리해 요청을 받아 뒤의 오리진으로 전달·응답. forward proxy(클라이언트를 대리해 나가는 트래픽 은닉)와 방향이 반대. 기능: SSL termination·캐싱·압축·정적 서빙·로드밸런싱·오리진 은닉(보안)·요청 라우팅.

• 셋의 관계: 리버스 프록시는 개념/역할, L4/L7 로드밸런서는 분산에 특화(리버스 프록시가 흔히 겸함), API 게이트웨이는 MSA 진입점으로 인증·인가·rate limit·라우팅·응답 집계·프로토콜 변환까지. 규모·요구에 따라 겹치거나 계층화.

Fault-tolerant(내결함성): 일부 구성요소가 죽어도 서비스가 계속 동작. 축:

• 리던던시(N+1)·SPOF 제거: 모든 계층을 다중화(앱·DB·LB), 다중 AZ/리전.
• 페일오버·복제: 헬스체크로 죽은 노드 제외, 스탠바이 승격(DB replica 승격·Sentinel).
• 장애 격리: 서킷브레이커·벌크헤드·타임아웃으로 전파 차단(4절).
• 우아한 저하(graceful degradation): 핵심만 살리고 부가 기능은 폴백/degrade.
• 자가 복구: 재시도(멱등 전제)·오토스케일·무중단 배포·헬스 기반 재기동.
• 관측성: SLO·알람·부하 테스트·카오스 엔지니어링으로 장애를 미리 발견.

꼬리질문: "고가용성(HA)과 내결함성 차이?" → HA는 가동시간 목표(짧은 다운 허용), 내결함성은 장애 중에도 무중단 — 후자가 더 강한 요구·비용↑. / "리버스 프록시로 어떻게 무중단 배포?" → 뒤 오리진을 블루/그린으로 두고 프록시가 트래픽을 전환.

함정: ❌ "로드밸런서 = 리버스 프록시" → LB는 분산 역할, 리버스 프록시는 더 넓은 개념(캐싱·SSL·라우팅 포함). ❌ "다중화만 하면 무정지" → 상태 복제·페일오버·격리·데이터 정합성까지 있어야.

(출처: NGINX — reverse proxy·load balancing·System Design Interview(Alex Xu)·Release It!(Nygard, 안정성 패턴) 교차검증. 기출 프레이밍: docs/01-ksundong.)

---

흔한 오답·함정 정리

• CAP는 셋 중 둘을 항상 고른다 → 분할 시에만 C/A 택1(PACELC).
• Saga가 2PC를 완전 대체 → 최종 일관성·격리 약함.
• 서킷 브레이커 하나면 장애 전파 끝 → 타임아웃·벌크헤드 병행.
• 복제로 쓰기 부하 분산 → 읽기만(샤딩이 쓰기).
• MSA는 무조건 좋다 → 분산 트랜잭션·네트워크·운영 복잡도.

한국 면접 단골 Q&A (답변 골격)

꼬리질문 대비 (상 난이도)

• "방금 쓴 걸 못 읽음?" → 복제 지연 → 리더 읽기·read-your-writes.
• "Saga 중간 상태가 보임?" → 격리 없음 → 시맨틱 락·상태 플래그.
• "서킷 브레이커 + 무엇?" → 타임아웃·리트라이(멱등)·벌크헤드·폴백.
• "핫 파티션?" → 키 분산(salting)·복제·캐시.
• "분산 락?" → Redis(SET NX EX)·ZooKeeper·etcd·fencing token.

한 줄 요약 — 확장은 수평(stateless+LB)·복제(읽기·지연)·샤딩(쓰기·조인 불가). CAP는 분할 시 CP vs AP(P 필수)·PACELC는 평시 지연 vs 일관성. 분산 트랜잭션은 2PC(블로킹·부적합) 대신 Saga(보상·choreography/orchestration·최종 일관성·격리 약함). 장애는 서킷 브레이커(+타임아웃·벌크헤드·멱등 재시도). 동시성은 비관/낙관락·원자 연산·분산락. 분산 ID는 Snowflake·합의는 Raft.

(출처 — 한국 면접 기출·교차검증 2026-06: VSFe/Tech-Interview — Database·gyoogle — MSA·junhyunny — 분산 트랜잭션/Saga·올리브영 — 서킷브레이커 재고 · CAP theorem(Brewer)·PACELC(Abadi)·microservices.io — Saga·Designing Data-Intensive Applications(Kleppmann) 교차검증.)