Backend interview
백엔드 시스템 확장성 면접 질문 준비
백엔드 개발자 면접에서 트래픽 증가, 병목, 장애 대응 질문에 답할 때 무엇을 증명해야 하는지 정리합니다.
내 경험으로 바로 연습하기
이 질문을 내 이력서와 지원 공고 기준으로 받아보세요.
Google 로그인 후 문서를 등록하면, 이 주제를 반영한 질문과 답변 피드백으로 이어집니다. 가입 시 제공되는 무료 크레딧으로 먼저 연습할 수 있어요.
무료로 이 질문 연습하기핵심 요약
좋은 답변은 기술 선택을 나열하지 않고, 관측 지표와 의사결정 기준, 결과를 함께 설명합니다.
흔히 보이는 답변 패턴
이 직무 질문에서 반복적으로 나타나는 약한 답변 유형입니다. 내 답변이 이 중 하나에 해당하는지 먼저 점검해보세요.
도구 나열형 답변
기술 스택 이름은 말하지만, 그것을 선택한 의사결정 근거(왜 다른 대안이 아니었는지)가 없다.
단일지표 의존형 답변
CPU 사용률 같은 지표 하나만 보고 확장 여부나 병목 위치를 판단한다.
가설 생략형 답변
원인 분석 없이 캐시 도입이나 스케일아웃 같은 해결책으로 바로 직행한다.
회고 누락형 답변
장애 대응 이후 프로세스나 코드에서 구체적으로 무엇을 바꿨는지 없이 '더 조심하겠다'는 다짐으로 끝난다.
질문 1
트래픽이 갑자기 3배 증가했을 때 어떤 지표를 보고 확장 여부를 결정하시겠어요?
평가 의도
운영 지표 해석, 병목 가설, 비용과 안정성의 균형
흔한 실수
- 무조건 서버를 늘린다고 답한다.
- 관측 지표 없이 사용한 기술 스택만 나열한다.
좋은 답변 신호
- CPU 같은 단일 지표가 아니라 latency, queue depth, error rate를 함께 본다.
- 스케일아웃 전에 병목 위치를 좁히는 순서를 말한다.
- 사용자 영향과 비용을 함께 설명한다.
답변 비교: 아쉬운 답변 → 좋은 답변
아쉬운 답변
트래픽이 늘었으니 서버를 늘리겠습니다.
보통 답변
CPU 사용률이 올라가면 오토스케일링으로 인스턴스를 추가하겠습니다.
좋은 답변
먼저 latency p95/p99, 에러율, 큐 적재량을 함께 봅니다. CPU만 오르고 나머지가 정상이면 단순 컴퓨트 병목이지만, DB 커넥션 풀 대기나 큐 적체가 같이 보이면 다른 계층이 원인이라 그쪽을 먼저 봅니다. 병목 위치를 좁힌 다음에야 스케일아웃, 캐시, 쿼리 개선 중 비용 대비 효과가 큰 것을 고릅니다.
- →latency·에러율·큐 적재량을 함께 본다고 말해 단일지표 의존형 답변을 피했다.
- →CPU만 오르는 경우와 다른 지표가 같이 움직이는 경우를 나눠 원인 계층을 구분했다.
- →해결책을 고르기 전에 병목 위치를 좁히는 순서를 먼저 제시했다.
꼬리질문 대비
스케일아웃과 쿼리 개선 중 실제로는 무엇을 먼저 했나요?
면접관 의도
원칙이 아니라 실제 경험에서 나온 판단인지 확인
좋은 방향
본인이 겪은 사례에서 어느 쪽이 더 빠르고 쌌는지 시간·비용으로 답한다.
오토스케일링 임계치는 어떻게 정했나요?
면접관 의도
운영 디테일까지 다뤄본 경험인지 검증
좋은 방향
과거 트래픽 패턴이나 콜드스타트 시간 같은 구체적 근거를 든다.
길이별 답변
30초
latency, 에러율, 큐 적재량을 함께 보고 병목 계층을 먼저 좁힙니다. 그다음 스케일아웃과 캐시·쿼리 개선 중 비용 대비 효과가 큰 쪽을 선택합니다.
60초
CPU 하나만 보지 않고 latency p95/p99, 에러율, 큐 적재량을 함께 확인합니다. CPU만 오르면 단순 컴퓨트 병목이지만, DB 커넥션 대기나 큐 적체가 함께 보이면 다른 계층이 원인이므로 그쪽을 먼저 의심합니다. 병목 위치를 좁힌 뒤에 스케일아웃, 캐시 도입, 쿼리 개선 중 비용 대비 효과가 큰 방법을 고릅니다.
90초
CPU 하나만 보지 않고 latency p95/p99, 에러율, 큐 적재량을 함께 확인합니다. 예를 들어 CPU는 60%에서 80%로만 올랐는데 큐 적재량이 평소보다 5배가 됐다면, 컴퓨트가 아니라 다운스트림(DB나 외부 API) 처리 속도가 원인일 가능성이 큽니다. 이런 식으로 어느 계층이 실제 병목인지 좁힌 다음에야 스케일아웃, 캐시 도입, 쿼리 개선 중 비용 대비 효과가 큰 방법을 고릅니다. 스케일아웃은 빠르지만 비용이 선형으로 늘고, 캐시나 쿼리 개선은 적용에 시간이 걸리지만 근본 원인을 줄여줍니다.
질문 2
데이터베이스가 병목이 됐을 때 캐시 도입과 쿼리 개선 중 무엇을 먼저 하시겠어요?
평가 의도
근본 원인 우선 사고, 캐시 부작용 이해, 단계적 개선 설계
흔한 실수
- 원인 분석 없이 Redis 도입을 정답처럼 말한다.
- 캐시 무효화·정합성 문제를 언급하지 않는다.
좋은 답변 신호
- 캐시를 먼저 깔지 않고 슬로우 쿼리·인덱스·N+1을 먼저 확인한다.
- 캐시 도입 시 무효화 전략과 정합성 비용을 함께 말한다.
- 개선 전후를 같은 지표(p95, QPS)로 비교해 효과를 증명한다.
답변 비교: 아쉬운 답변 → 좋은 답변
아쉬운 답변
캐시를 도입하겠습니다.
보통 답변
Redis 캐시를 붙여서 DB 부하를 줄이겠습니다.
좋은 답변
캐시를 깔기 전에 슬로우 쿼리 로그와 실행 계획을 먼저 봅니다. 인덱스 누락이나 N+1 패턴이 원인이면 캐시 없이도 해결되는 경우가 많습니다. 그래도 부족하면 캐시를 추가하는데, 이때 무효화 전략과 정합성 비용을 같이 설계합니다. 개선 전후는 같은 지표(p95 latency, QPS)로 비교해서 효과를 증명합니다.
- →캐시를 정답으로 두지 않고 슬로우 쿼리·인덱스·N+1을 먼저 확인해 가설 생략형 답변을 피했다.
- →캐시 도입 시 무효화 전략과 정합성 비용을 같이 언급해 부작용을 이해하고 있음을 보였다.
- →개선 전후를 같은 지표로 비교한다고 말해 효과를 증명하는 습관을 보였다.
꼬리질문 대비
캐시 무효화는 어떤 전략을 썼나요?
면접관 의도
캐시의 실제 운영 경험과 정합성 문제 이해도 확인
좋은 방향
TTL, write-through, 이벤트 기반 무효화 중 선택 이유와 트레이드오프를 구체적으로 말한다.
인덱스를 추가했는데도 느리다면 다음엔 무엇을 보나요?
면접관 의도
단계적 진단 능력 검증
좋은 방향
실행 계획을 다시 읽고 조인 순서, 락 경합, 데이터 분포 왜곡 등 다음 가설로 넘어가는 과정을 설명한다.
길이별 답변
30초
캐시를 먼저 깔지 않고 슬로우 쿼리와 인덱스, N+1을 먼저 확인합니다. 그래도 부족하면 캐시를 추가하되 무효화 전략을 같이 설계하고, 개선 전후를 같은 지표로 비교합니다.
60초
캐시를 깔기 전에 슬로우 쿼리 로그와 실행 계획을 먼저 봅니다. 인덱스 누락이나 N+1 패턴이 원인이면 캐시 없이도 해결되는 경우가 많기 때문입니다. 그래도 부족하면 캐시를 추가하는데, 이때 무효화 전략과 정합성 비용을 같이 설계합니다. 개선 전후는 같은 지표로 비교해서 효과를 증명합니다.
90초
캐시를 깔기 전에 슬로우 쿼리 로그와 실행 계획을 먼저 봅니다. 예를 들어 N+1 쿼리 하나를 조인으로 바꾸는 것만으로 p95 latency가 800ms에서 150ms로 줄어든 경험이 있는데, 이런 경우는 캐시 없이도 해결됩니다. 인덱스와 쿼리 구조를 다 확인한 뒤에도 부족하면 캐시를 추가하는데, 이때 무효화 전략(TTL인지 write-through인지)과 정합성 비용을 같이 설계합니다. 개선 전후는 같은 지표(p95 latency, QPS)로 비교해서 실제로 효과가 있었는지 증명합니다.
질문 3
장애가 발생했을 때 가장 먼저 한 일과, 재발 방지를 위해 바꾼 것은 무엇인가요?
평가 의도
장애 대응 우선순위, 영향 범위 산정, 사후 개선 실행력
흔한 실수
- 장애 원인 분석 과정만 길게 말하고 사용자 영향 차단 순서가 없다.
- 재발 방지가 '더 조심하겠다' 수준의 다짐으로 끝난다.
좋은 답변 신호
- 원인 규명보다 사용자 영향 차단(롤백, 차단, 우회)을 먼저 했다고 말한다.
- 영향 범위를 숫자(영향 사용자 수, 지속 시간)로 설명한다.
- 포스트모템에서 프로세스·알림·테스트 중 무엇을 바꿨는지 구체적으로 말한다.
답변 비교: 아쉬운 답변 → 좋은 답변
아쉬운 답변
원인을 찾아서 고쳤습니다.
보통 답변
로그를 보고 원인을 찾아 핫픽스를 배포했습니다.
좋은 답변
원인 규명보다 사용자 영향을 먼저 차단했습니다. 이번 경우는 롤백으로 영향 사용자 수를 즉시 줄이고, 그다음 원인을 분석했습니다. 영향 범위는 영향 사용자 수와 지속 시간으로 정리해 보고했고, 포스트모템에서는 알림 임계치를 낮추고 회귀 테스트를 추가해 같은 패턴의 장애가 다시 나면 더 빨리 잡히게 했습니다.
- →원인 규명보다 사용자 영향 차단(롤백)을 먼저 했다고 말해 우선순위 판단을 보였다.
- →영향 범위를 영향 사용자 수와 지속 시간으로 숫자화했다.
- →재발 방지로 알림 임계치와 회귀 테스트라는 구체적인 변경을 들어 회고 누락형 답변을 피했다.
꼬리질문 대비
롤백할지 핫픽스를 배포할지는 어떻게 판단했나요?
면접관 의도
장애 상황에서의 의사결정 기준 검증
좋은 방향
롤백 소요 시간과 핫픽스 위험도를 비교한 기준을 구체적으로 말한다.
그 장애 이후 비슷한 장애가 또 발생했나요?
면접관 의도
재발 방지가 실제로 효과가 있었는지 확인
좋은 방향
재발 여부와, 재발했다면 무엇이 부족했는지를 솔직하게 말한다.
길이별 답변
30초
원인 분석보다 사용자 영향 차단(롤백)을 먼저 했습니다. 영향 범위는 사용자 수와 지속 시간으로 정리했고, 재발 방지로 알림 임계치를 낮추고 회귀 테스트를 추가했습니다.
60초
원인 규명보다 사용자 영향을 먼저 차단했습니다. 이번 경우는 롤백으로 영향 사용자 수를 즉시 줄이고, 그다음 원인을 분석했습니다. 영향 범위는 영향 사용자 수와 지속 시간으로 정리해 보고했고, 포스트모템에서는 알림 임계치를 낮추고 회귀 테스트를 추가했습니다.
90초
원인 규명보다 사용자 영향을 먼저 차단했습니다. 이번 경우는 배포 직후 에러율이 급등한 게 확인돼서, 원인을 파지 않고 바로 이전 버전으로 롤백해 영향 사용자 수를 5분 안에 줄였습니다. 그다음 로그와 배포 diff를 비교해 원인을 분석했고, 영향 범위는 영향 사용자 수와 지속 시간으로 정리해 보고했습니다. 포스트모템에서는 같은 패턴의 변경에 대한 알림 임계치를 낮추고, 이번 장애를 유발한 코드 경로에 회귀 테스트를 추가해 같은 문제가 배포 전에 잡히도록 했습니다.
내 답변으로 연습하기
내 이력서의 운영 경험을 바탕으로 확장성 질문에 답변해보고, 지표와 결과가 부족한지 점검합니다.
이 질문으로 연습하기