5~10년차 시니어 백엔드 면접에서는 단순 개념보다 설계 판단력, 트러블슈팅 경험, 기술 선택의 근거를 봅니다.

이 시리즈에서는 제가 면접관이라면 어떻게 질문하고, 어떤 꼬리질문으로 진짜 실력을 확인할지 정리했습니다.

시리즈 구성:

  • 1편 (현재): 인프라/스케일링 - 트래픽, DB, 분산시스템
  • 2편: 운영/안정성 - 장애대응, 이벤트 아키텍처, 배포
  • 3편: 설계/리더십 - 의사결정, 시스템디자인, 코드리뷰

1. 대용량 트래픽 처리

Q1. 갑자기 트래픽이 10배 증가하면 어떻게 대응하시겠어요?

기대 답변: 단기적으로는 오토스케일링으로 인스턴스 확장, 장기적으로는 병목 구간 분석 후 캐싱, 비동기 처리, DB 최적화 등을 적용합니다.

🔄 꼬리질문 1: 병목 구간은 어떻게 찾나요?

기대 답변:

  • APM 도구(Datadog, New Relic, Pinpoint)로 트랜잭션별 응답시간 분석
  • DB slow query 로그 분석
  • CPU/메모리/네트워크 지표 모니터링
  • 분산 트레이싱으로 서비스 간 호출 추적

🔄 꼬리질문 2: 캐시를 도입한다면 어디에, 어떻게 적용하시겠어요?

기대 답변:

  • 읽기 비율 높은 데이터: 사용자 프로필, 상품 정보 → Redis Cache-Aside 패턴
  • API 응답 캐싱: CDN 또는 API Gateway 레벨
  • 세션 저장소: 분산 환경에서 Redis 클러스터
  • TTL 설정과 캐시 무효화 전략(Write-Through, Write-Behind)도 고려

🔄 꼬리질문 3: 캐시 스탬피드(Cache Stampede)가 뭔지 알고 계시죠? 어떻게 방지하나요?

기대 답변: TTL 만료 시 동시에 수많은 요청이 DB로 몰리는 현상입니다.

  • Lock: 한 요청만 DB 조회, 나머지는 대기
  • Probabilistic Early Expiration: TTL 만료 전 확률적으로 미리 갱신
  • Background Refresh: 별도 스레드가 주기적으로 갱신

2. 데이터베이스 확장

Q2. DB가 한계에 도달했을 때 어떻게 확장하시겠어요?

기대 답변:

  • Scale-Up: 장비 스펙 업그레이드 (한계 있음)
  • Read Replica: 읽기 분산
  • Sharding: 데이터 수평 분할
  • CQRS: 읽기/쓰기 모델 분리

🔄 꼬리질문 1: 샤딩 키는 어떤 기준으로 선택하나요?

기대 답변:

  • Cardinality: 값의 종류가 충분히 많아야 함
  • 분산 균등성: 특정 샤드에 데이터 쏠림 방지
  • 쿼리 패턴: 가장 많이 조회하는 조건과 일치
  • 예: 사용자 ID, 지역, 날짜 등

🔄 꼬리질문 2: Cross-shard 쿼리가 필요하면 어떻게 하나요?

기대 답변:

  • 최대한 피하도록 데이터 모델 설계
  • 불가피하면 애플리케이션에서 병합 (Scatter-Gather)
  • 집계 데이터는 별도 테이블/서비스로 비정규화
  • Elasticsearch 같은 검색엔진 활용

🔄 꼬리질문 3: 실제로 샤딩 경험이 있으신가요? 어떤 어려움이 있었나요?

이 질문의 의도: 이론만 아는지, 실제로 해봤는지 구분합니다. 마이그레이션 전략, 리샤딩, 분산 트랜잭션 처리 등 실무 경험을 확인합니다.

3. 분산 시스템 설계

Q3. 분산 환경에서 동시에 같은 자원을 수정하면 어떤 문제가 생기나요?

기대 답변: Race Condition이 발생합니다. 동시 구매로 재고가 음수가 되거나, 중복 결제가 발생할 수 있습니다.

🔄 꼬리질문 1: 분산 락(Distributed Lock)을 어떻게 구현하시겠어요?

기대 답변:

  • Redis: SET key value NX PX timeout (Redlock 알고리즘)
  • Zookeeper: Ephemeral Sequential Node
  • DB: SELECT FOR UPDATE, Advisory Lock

🔄 꼬리질문 2: Redis 단일 노드로 분산 락 걸면 문제가 뭔가요?

기대 답변: Redis 장애 시 락이 풀리거나 중복 획득 가능합니다. Redlock은 다수 노드 과반 합의로 이를 완화하지만, Martin Kleppmann의 비판처럼 완벽하진 않습니다. 비즈니스 특성에 따라 락 없이 멱등성으로 처리하는 게 나을 수도 있습니다.

🔄 꼬리질문 3: 멱등성(Idempotency)은 어떻게 보장하나요?

기대 답변:

  • Idempotency Key: 클라이언트가 고유 키 전송, 서버가 중복 체크
  • DB Unique Constraint: 중복 요청 자체를 막음
  • 상태 기반 처리: 이미 완료된 상태면 스킵

4. 인덱스와 쿼리 최적화

Q4. 인덱스가 있으면 무조건 빠른가요?

기대 답변: 아니요.

  • 데이터가 적으면 Full Scan이 더 빠를 수 있음
  • INSERT/UPDATE/DELETE 시 인덱스 갱신 비용 발생
  • 선택도(Selectivity)가 낮으면 효과 없음

🔄 꼬리질문 1: 복합 인덱스에서 컬럼 순서가 왜 중요한가요?

기대 답변: 복합 인덱스는 정의된 순서대로 정렬됩니다. (A, B, C) 인덱스가 있을 때:

  • WHERE A = 1 → 사용됨
  • WHERE A = 1 AND B = 2 → 사용됨
  • WHERE B = 2 → 사용 안됨 (첫 번째 컬럼 없음)

🔄 꼬리질문 2: 커버링 인덱스(Covering Index)가 뭔가요?

기대 답변: 쿼리에 필요한 모든 컬럼이 인덱스에 포함되어 테이블 접근 없이 인덱스만으로 결과를 반환하는 것입니다. 디스크 I/O를 줄여 성능이 크게 향상됩니다.

🔄 꼬리질문 3: 실행계획(EXPLAIN) 봐본 적 있나요? 어떤 걸 확인하나요?

기대 답변:

  • type: ALL(풀스캔) < range < ref < eq_ref < const
  • rows: 예상 검색 행 수
  • Extra: Using filesort, Using temporary는 주의
  • key: 실제 사용된 인덱스

5. CAP 정리와 일관성

Q5. CAP 정리가 뭔가요?

기대 답변: 분산 시스템에서 Consistency(일관성), Availability(가용성), Partition Tolerance(분할 허용) 중 최대 2개만 보장할 수 있다는 이론입니다.

🔄 꼬리질문 1: 네트워크 파티션이 발생하면 CP와 AP 중 어떤 걸 선택하시겠어요?

기대 답변: 비즈니스에 따라 다릅니다.

  • CP: 금융, 결제 등 일관성이 중요한 경우
  • AP: SNS, 검색 등 가용성이 중요한 경우
  • 실제로는 대부분 AP를 선택하고 Eventual Consistency로 보완

🔄 꼬리질문 2: Eventual Consistency는 어떻게 구현하나요?

기대 답변:

  • 비동기 복제 + 충돌 해결 전략
  • Last Write Wins: 타임스탬프 기준 최신 값 선택
  • Vector Clock: 인과관계 추적
  • CRDT: 충돌 없이 병합 가능한 자료구조

🔄 꼬리질문 3: 2PC(Two-Phase Commit)의 문제점은 뭔가요?

기대 답변:

  • Blocking: Coordinator 장애 시 참여자들이 대기 상태로 멈춤
  • Single Point of Failure: Coordinator 의존성
  • 성능: 모든 참여자가 응답할 때까지 락 유지
  • 대안으로 SAGA 패턴, Outbox 패턴 사용

마무리: 1편 핵심 정리

  1. 트래픽 처리: 오토스케일링 + 캐싱 + 비동기 처리
  2. DB 확장: Read Replica → Sharding → CQRS
  3. 분산 시스템: 락보다 멱등성, Trade-off 이해
  4. 쿼리 최적화: 실행계획 분석, 인덱스 설계
  5. 일관성: CAP 이해, Eventual Consistency 전략

다음 편에서는 장애 대응, 이벤트 아키텍처, 배포 전략을 다룹니다.