질문 라이브러리

Backend interview

백엔드 시스템 확장성 면접 질문 준비

백엔드 개발자 면접에서 트래픽 증가, 병목, 장애 대응 질문에 답할 때 무엇을 증명해야 하는지 정리합니다.

Core takeaway

좋은 답변은 기술 선택을 나열하지 않고, 관측 지표와 의사결정 기준, 결과를 함께 설명합니다.

Question 1

트래픽이 갑자기 3배 증가했을 때 어떤 지표를 보고 확장 여부를 결정하시겠어요?

평가 의도

운영 지표 해석, 병목 가설, 비용과 안정성의 균형

흔한 실수

  • 무조건 서버를 늘린다고 답한다.
  • 관측 지표 없이 사용한 기술 스택만 나열한다.

좋은 답변 신호

  • CPU 같은 단일 지표가 아니라 latency, queue depth, error rate를 함께 본다.
  • 스케일아웃 전에 병목 위치를 좁히는 순서를 말한다.
  • 사용자 영향과 비용을 함께 설명한다.

Question 2

데이터베이스가 병목이 됐을 때 캐시 도입과 쿼리 개선 중 무엇을 먼저 하시겠어요?

평가 의도

근본 원인 우선 사고, 캐시 부작용 이해, 단계적 개선 설계

흔한 실수

  • 원인 분석 없이 Redis 도입을 정답처럼 말한다.
  • 캐시 무효화·정합성 문제를 언급하지 않는다.

좋은 답변 신호

  • 캐시를 먼저 깔지 않고 슬로우 쿼리·인덱스·N+1을 먼저 확인한다.
  • 캐시 도입 시 무효화 전략과 정합성 비용을 함께 말한다.
  • 개선 전후를 같은 지표(p95, QPS)로 비교해 효과를 증명한다.

Question 3

장애가 발생했을 때 가장 먼저 한 일과, 재발 방지를 위해 바꾼 것은 무엇인가요?

평가 의도

장애 대응 우선순위, 영향 범위 산정, 사후 개선 실행력

흔한 실수

  • 장애 원인 분석 과정만 길게 말하고 사용자 영향 차단 순서가 없다.
  • 재발 방지가 '더 조심하겠다' 수준의 다짐으로 끝난다.

좋은 답변 신호

  • 원인 규명보다 사용자 영향 차단(롤백, 차단, 우회)을 먼저 했다고 말한다.
  • 영향 범위를 숫자(영향 사용자 수, 지속 시간)로 설명한다.
  • 포스트모템에서 프로세스·알림·테스트 중 무엇을 바꿨는지 구체적으로 말한다.

내 답변으로 연습하기

내 이력서의 운영 경험을 바탕으로 확장성 질문에 답변해보고, 지표와 결과가 부족한지 점검합니다.

이 질문으로 연습하기