백엔드 개발자 면접 질문 가이드 — DB부터 장애 대응까지 갈래별로 답하는 법

데이터베이스·트랜잭션, 네트워크·HTTP, 동시성, 장애 대응, 시스템 설계, 포트폴리오 꼬리질문의 여섯 갈래예요. DB는 데이터를 안전하고 빠르게 다루는 법, 네트워크는 요청이 오가는 경로, 동시성은 같은 자원에 여러 요청이 붙었을 때, 장애 대응은 깨졌을 때의 행동, 설계는 없는 것을 새로 만들 때의 판단, 꼬리질문은 앞의 다섯이 내 손에 붙어 있는지를 확인합니다.

갈래가 이렇게 나뉘는 건 백엔드 업무 자체가 그렇게 생겼기 때문이에요. 데이터를 저장하고, 네트워크 너머로 주고받고, 동시에 들어오는 요청을 버티고, 깨지면 복구하는 일. 면접 질문은 그 업무의 축소판이고, 그래서 '실무에서 만날 법한 상황'을 얼마나 구체적으로 그려내느냐가 답변의 품질을 가릅니다.

갈래별 시간 배분은 지원하는 회사의 스택을 보고 정하세요. 채용 공고의 기술 스택이 곧 질문 범위입니다. 참고로 스택오버플로 2025 개발자 서베이(177개국 4만 9천여 명 응답)에서 가장 많이 쓰이는 데이터베이스 1위는 PostgreSQL이었고 MySQL·SQLite·Redis·MongoDB가 뒤를 이었어요. Docker 역시 가장 널리 쓰이는 도구 상위에 있었습니다. 공고에 적힌 이름들이 이 목록과 겹친다면, 그 도구의 기본 동작과 한계는 반드시 물어봅니다.

'정의 → 트레이드오프 → 내 프로젝트에서의 선택'까지가 한 세트예요. 인덱스라면 정의(조회를 빠르게 하는 자료구조)에서 멈추지 말고, 쓰기 성능과 저장 공간을 내준다는 대가, 그래서 어떤 컬럼에만 걸었는지까지 이어져야 합니다. 자주 나오는 주제는 인덱스와 실행 계획, 정규화와 반정규화, 트랜잭션의 ACID, 격리 수준, 락, N+1 문제, 커넥션 풀 정도예요.

격리 수준은 이름 네 개를 외우는 게 아니라 '내가 쓰는 DB의 기본값이 무엇이고 그때 무엇이 허용되는가'로 답해야 합니다. PostgreSQL 공식 문서는 "Read Committed is the default isolation level in PostgreSQL"이라고 명시하고, 같은 트랜잭션 안의 두 SELECT가 서로 다른 데이터를 볼 수 있다고 적어 둡니다. 반면 MySQL 공식 매뉴얼은 REPEATABLE READ가 InnoDB의 기본 격리 수준이라고 밝히고 있어요. 두 DB의 기본값이 다르다는 사실 자체가 좋은 답변 재료입니다 — 그래서 '어떤 이상 현상이 우리 서비스에서 실제로 문제가 되는가'로 이야기를 끌고 갈 수 있어요.

꼬리질문은 대개 실패 케이스로 들어옵니다. '인덱스를 걸었는데도 느리면 뭘 보나요'에는 실행 계획, 카디널리티, 복합 인덱스의 컬럼 순서, 함수를 씌워 인덱스를 못 타는 경우를 순서대로 짚으면 돼요. 'N+1은 어떻게 발견했나요'에는 쿼리 로그와 요청당 쿼리 수를 근거로 답하고, 해결책(조인, 배치 로딩, 캐시) 각각의 대가까지 붙이세요. 도구 이름만 나열하면 그다음 질문에서 무너집니다.

요청 하나가 클라이언트에서 내 서버까지 갔다 오는 경로를 끊김 없이 말할 수 있는지를 봅니다. 주소창에 URL을 넣고 응답이 그려질 때까지 — DNS 조회, TCP 연결과 TLS 핸드셰이크, 로드밸런서, 애플리케이션 서버, DB, 그리고 응답이 되돌아오는 길. 이 흐름을 한 번 입으로 완주해 두면 네트워크 질문 대부분이 이 줄기에서 갈라져 나옵니다.

자주 나오는 묶음은 TCP와 UDP의 차이, HTTP/1.1과 HTTP/2·HTTP/3의 차이, 상태 코드 선택(400과 422, 401과 403), 쿠키·세션과 JWT, CORS가 막는 것과 막지 않는 것, 타임아웃과 재시도예요. 이 중 인증은 거의 매번 트레이드오프로 파고듭니다. 세션은 서버가 상태를 들고 있어 즉시 무효화가 되지만 확장할 때 저장소가 필요하고, JWT는 무상태라 확장이 쉽지만 발급한 토큰을 중간에 죽이기가 어렵죠. '무엇을 골랐나'가 아니라 '무엇을 포기했나'를 말해야 답이 됩니다.

타임아웃과 재시도는 백엔드 면접에서 실력 차가 크게 벌어지는 지점이에요. 외부 API를 호출하는 코드를 짰다면 '응답이 30초 걸리면 어떻게 되나요', '재시도하면 결제가 두 번 되지 않나요' 같은 질문이 따라옵니다. 연결 타임아웃과 읽기 타임아웃을 나눠 잡았는지, 지수 백오프를 썼는지, 재시도해도 안전한 요청인지를 구분해 답하세요.

'같은 요청이 동시에 두 번 들어오면 어떻게 되나요'가 표준 문제예요. 재고 차감, 선착순 쿠폰 발급, 중복 결제, 포인트 적립이 단골 소재입니다. 답의 뼈대는 세 단계예요 — 경쟁 조건이 정확히 어느 지점에서 생기는지 짚고(조회와 갱신 사이), 방어 수단을 고르고(DB 비관적 락, 낙관적 락과 버전 컬럼, 유니크 제약, 분산 락, 큐로 직렬화), 그 수단의 대가를 말하는 것.

가장 싸고 확실한 방어는 유니크 제약이라는 점을 기억해 두세요. '주문 번호 + 상품'에 유니크 인덱스를 걸어 두면 애플리케이션 로직이 틀려도 DB가 마지막에 막아 줍니다. 여기에 멱등성 개념을 붙이면 답이 한 단계 올라가요. 같은 요청을 몇 번 보내도 결과가 같도록 요청에 고유 키를 부여하는 방식(Idempotency-Key)은 네트워크가 불안정한 세상에서 재시도를 안전하게 만드는 기본기입니다.

언어와 프레임워크에 따라 꼬리질문의 방향이 달라요. 스레드 기반이면 스레드 풀과 커넥션 풀의 크기, 데드락과 락 순서를 묻고, 이벤트 루프 기반이면 루프를 블로킹하는 작업을 어디로 뺐는지 묻습니다. 내가 쓰는 런타임이 요청을 어떻게 병렬로 처리하는지 한 문단으로 설명할 수 있으면 이 갈래는 통과예요.

장애 질문은 시간순으로 답하는 게 가장 안전해요. 탐지(무엇을 보고 알았나) → 격리(피해를 어떻게 멈췄나) → 원인(무엇이 진짜 원인이었나) → 수습(어떻게 되돌렸나) → 재발 방지(무엇을 바꿨나)의 다섯 단계입니다. 면접관이 보는 건 장애의 규모가 아니라 이 순서를 스스로 밟았는지예요. 알림도 없이 사용자 제보로 알았다면 그 사실을 말하고 '그래서 지표와 알림을 이렇게 붙였다'로 잇는 편이 훨씬 낫습니다.

배포 뒤 깨지는 일이 드물지 않다는 건 업계 데이터로도 확인됩니다. 구글 클라우드가 전 세계 기술 종사자 약 5천 명을 조사해 발표한 2025년 DORA 리포트에서 응답자의 90%가 업무에 AI를 쓴다고 답했고, 80% 이상이 생산성이 올랐다고 했지만, AI 도입은 소프트웨어 전달 안정성과 여전히 음의 관계를 보였어요. 리포트는 그 이유를 이렇게 정리합니다 — "AI는 소프트웨어 개발을 가속하지만, 그 가속이 하류의 약점을 드러낼 수 있다. 강한 자동화 테스트, 성숙한 버전 관리, 빠른 피드백 루프 같은 견고한 통제 장치가 없으면 변경량 증가는 불안정으로 이어진다." 변경이 빨라질수록 장애 대응 경험을 묻는 이유가 여기 있습니다.

설계 질문('URL 단축기를 설계해 보세요', '알림 시스템을 설계해 보세요')에서 첫 수는 되묻기예요. 트래픽 규모, 읽기와 쓰기 비율, 지연 허용치, 정합성 요구 수준을 확인하고 나서 큰 그림을 그립니다. 그다음 병목을 스스로 지목하고(단일 DB, 핫 키, 팬아웃), 해결책과 대가를 함께 말하세요. 설계 질문에 정답은 없고, 요구사항을 좁히는 질문과 트레이드오프를 입 밖으로 내는 태도가 점수입니다.

신입에게는 '아는가'를, 경력에게는 '판단했는가'를 묻습니다. 신입 면접의 무게중심은 CS 기초와 프로젝트의 근거이고, 경력 면접은 설계 판단·운영 경험·팀 안에서의 결정으로 옮겨가요. 같은 '캐시를 썼다'는 문장에도 신입에게는 '왜 캐시가 필요했나'가, 경력에게는 '캐시 무효화 전략과 정합성 깨짐을 어떻게 감당했나'가 따라옵니다.

시장 구조를 알고 가면 전략이 분명해져요. 앞서 인용한 사람인·점핏 '2025 상반기 개발자 채용 리포트'에서 채용 공고의 39.7%가 5~10년차를 찾았고 신입 공고는 0.8%, 1년차는 1.4%였습니다. 반면 입사지원에서는 신입이 29.5%로 가장 많았어요. 점핏 관계자는 발표 자료에서 "기업은 수요가 높은 영역에 채용 포지션을 지속적으로 열고 있었으나, 개인의 선택은 반드시 그 방향과 일치하지 않았다"고 짚었습니다. 신입이 경쟁하는 자리는 좁고, 그래서 면접에서 '경력처럼 판단해 본 흔적'이 결정적으로 작동해요.

신입이라면 프로젝트의 규모 대신 근거의 밀도를 채우세요. 사용자가 없는 토이 프로젝트라도 '동시 요청을 100건 넣어 봤더니 재고가 음수가 돼서, 이렇게 막았다'는 이야기는 경력 지원자의 답변과 같은 구조를 갖습니다. 경력이라면 반대로 코드 이야기만 하지 마세요. 마이그레이션, 온콜과 장애 회고, 레거시를 안고 내린 타협, 팀에 남긴 문서와 규칙이 경력 면접의 재료예요.

이력서에 쓴 문장마다 '왜 골랐나 → 대안은 뭐였나 → 결과는 어땠나 → 지금이라면 어떻게 하겠나' 네 칸을 채워 두면 꼬리질문의 8할이 커버됩니다. 백엔드 포트폴리오에는 특유의 꼬리가 붙어요 — "트래픽이 100배가 되면 어디가 먼저 터지나요", "그 외부 API가 죽으면 사용자에게 무엇이 보이나요", "데이터가 안 맞기 시작하면 어떻게 알아채나요". 세 질문에 답이 준비돼 있으면 대부분의 딥다이브가 안전권입니다. 수치가 없다면 지금이라도 부하 테스트를 한 번 돌려 응답 시간과 실패율을 측정해 채워 넣으세요.

2주 루틴은 재료와 연습을 나누는 게 핵심이에요. 첫 주(D-14~D-8)에는 갈래별 예상 질문 30~40개를 뽑고 포트폴리오 네 칸 문답을 씁니다. 둘째 주(D-7~D-3)에는 하루 한 갈래씩 같은 질문을 세 번씩 소리 내어 답하고, 모의면접을 2~3회 배치한 뒤 매번 '막힌 질문·장황했던 답·몰랐던 개념'을 복기 노트로 남기세요. 이 소리 내는 단계를 건너뛰는 사람이 많습니다. 기술면접 준비자 131명을 조사해 2025년 소프트웨어공학 학회 FSE에 발표한 논문 「How do Software Engineering Candidates Prepare for Technical Interviews?」에서 모의면접을 한 번도 해본 적 없다는 응답이 35%(46명), 다섯 번 이하가 82%(107명)였고, 구두 전달력이 중요하다고 답한 비율은 78%였어요. 같은 논문은 다른 사람과 함께 준비하거나 말하기를 자주 연습한 지원자의 준비도가 통계적으로 유의하게 높았던 반면, 하루에 푼 코딩 문제 수는 준비도와 연결되지 않았다고 보고했습니다.

말할 상대를 구하기 어렵다면 도구로 메워도 됩니다. 프리터뷰처럼 말로 문답을 주고받고 결과를 리포트로 정리해 주는 모의면접이나 포트폴리오 점검 기능은 '왜 → 대안 → 결과' 문답을 입에 붙이는 리허설에 쓰기 좋고, 가입하면 무료 사용권 1개가 주어져 결과물을 먼저 확인할 수 있어요. 다만 어떤 도구를 쓰든 기술 사실은 공식 문서로 교차 확인하세요 — 격리 수준이나 프레임워크 기본값처럼 버전마다 바뀌는 항목은 특히 그렇습니다. 마지막 이틀(D-2~D-1)은 새로운 개념에 손대지 말고, 복기 노트에서 약했던 답 다섯 개만 다듬고 지원 회사의 기술 블로그를 다시 훑으세요.