Q1. DB가 느릴 때 첫 대응은 스케일아웃 아닌가요?

답변

아닙니다. 실무에서는 보통 아래 순서가 안전합니다.

  1. 측정: 슬로우쿼리, 락 대기, 커넥션 풀 고갈 여부 확인
  2. 쿼리/인덱스: EXPLAIN으로 Full Scan, filesort, temporary 제거
  3. 캐시: 반복 조회 핫키를 캐시로 흡수
  4. 비동기화: 집계/후처리를 큐로 분리
  5. 스케일: 마지막에 레플리카/샤딩 검토

Q2. 왜 이 순서가 중요한가요?

답변

원인 검증 없이 스케일아웃하면 비용만 늘고 문제는 남습니다.

  • 쿼리 한두 개가 병목이면 서버를 늘려도 그대로 느립니다.
  • 락 경합 문제면 노드 증가가 오히려 경쟁을 키울 수 있습니다.

즉, 병목 위치를 증거로 특정한 뒤 확장해야 합니다.

Q3. 면접에서 어떻게 답하면 좋아요?

답변

  • 결론: “저는 먼저 측정하고, SQL/인덱스를 고친 뒤 캐시/비동기, 마지막으로 스케일합니다.”
  • 근거: “대부분 병목은 구조적 원인이라 수평 확장 전에 제거할 수 있습니다.”
  • 사례: “슬로우쿼리 1개 튜닝으로 p95가 크게 줄고, 이후 캐시로 안정화했습니다.”
  • 트레이드오프: “캐시는 정합성 복잡도가 증가하므로 TTL/무효화 전략을 같이 설계했습니다.”

Q4. 자주 실수하는 포인트는?

답변

  • APM/슬로우로그 없이 감으로 병목 추정
  • 인덱스 추가 후 write 성능 악화 검증 누락
  • 캐시 도입 후 무효화 정책 부재
  • 비동기화 후 멱등성/재처리 설계 누락

Q5. 체크리스트를 주세요

답변

  • p95/p99, QPS, 에러율 확인
  • 상위 슬로우 쿼리 5개 확인
  • 락 대기/데드락 로그 확인
  • 캐시 적중률, 스탬피드 유무 확인
  • 큐 적체(consumer lag) 확인

요약

  • DB 병목 대응은 기술 나열이 아니라 우선순위 프레임이 핵심입니다.
  • 측정 없는 스케일아웃은 비용 증가로 끝나기 쉽습니다.
  • 면접에서는 “왜 그 순서인지"를 설명하면 실무 감각이 드러납니다.

다음 글