백엔드 면접 질문과 답변 예시: DB·동시성·장애 대응

여섯 갈래는 백엔드 업무의 축소판입니다. 데이터를 저장하고, 네트워크 너머로 주고받고, 동시에 들어오는 요청을 처리하고, 깨지면 복구하고, 없는 기능을 새로 설계하는 일이 그대로 질문 범위가 됩니다. 마지막 꼬리질문 갈래는 앞의 다섯 가지를 실제로 써 봤는지 이력서를 근거로 확인하는 자리입니다.

갈래별 시간 배분은 채용 공고의 기술 스택과 우대 사항을 모두 읽고 정합니다. 공고에 적힌 DB, 메시지 큐, 배포 도구는 기본 동작과 한계를 묻는 질문으로 이어질 수 있으니, 공고에 없는 기술보다 먼저 준비하는 편이 효율적입니다.

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

격리 수준은 이름 네 개를 외우는 문제가 아닙니다. PostgreSQL 공식 문서는 격리 수준별로 동시 트랜잭션에서 허용되는 현상을 설명합니다(공식 안내). PostgreSQL을 썼다면 이 문서로, 다른 DB를 썼다면 그 DB의 공식 문서로 동작을 확인해 둡니다. 같은 이름의 격리 수준이라도 DB마다 구체적인 구현이 다르므로, 다른 DB 문서를 근거로 일반화하지 말고 실제로 사용한 DB의 문서를 인용하는 편이 정확합니다.

설명을 위한 가상 예시입니다. 질문 '격리 수준을 바꿔 본 적이 있나요?'에 '정산 배치에서 같은 트랜잭션 안의 두 조회가 다른 결과를 보는 일이 있어, DB 문서에서 기본 격리 수준의 동작을 확인하고 해당 트랜잭션만 더 높은 수준으로 올렸습니다. 대신 충돌 시 재시도 로직을 추가했습니다'라고 답하면, 꼬리질문은 '재시도 횟수는 어떻게 정했나요'처럼 근거를 묻는 방향으로 이어집니다.

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

주소창에서 응답이 그려질 때까지 자신의 시스템에서 요청이 지나가는 경로를 설명해 보세요. DNS, 연결 수립, 로드밸런서, 서버, 저장소를 따라가되 캐시 적중과 연결 재사용도 구분합니다. HTTPS의 HTTP/1.1·2에서는 TCP와 TLS를, HTTP/3에서는 QUIC를 설명해야 하므로 모든 요청을 TCP 연결로 단정하지 않습니다(HTTP/3 표준).

TCP와 UDP, HTTP 버전, 상태 코드, 쿠키·세션·JWT, CORS, 타임아웃과 재시도를 자신의 구현과 연결해 준비합니다. 인증에서는 서버가 어떤 상태를 보관하고 검증하는지부터 설명하세요. JWT라는 토큰 형식만으로 시스템 전체가 무상태가 되는 것은 아닙니다. 로그아웃과 토큰 폐기, 만료, 여러 서버에서의 상태 일치를 어떻게 구현했는지 비교하면 선택 이유가 구체적으로 드러납니다.

외부 API를 호출하는 코드를 썼다면 '응답이 30초 걸리면 어떻게 되나요', '재시도하면 결제가 두 번 되지 않나요' 같은 질문을 예상해 둡니다. 연결 타임아웃과 읽기 타임아웃을 나눠 잡았는지, 지수 백오프를 썼는지, 재시도해도 안전한 요청과 아닌 요청을 어떻게 구분했는지를 자신의 코드 기준으로 설명하면 됩니다.

재고 차감, 선착순 쿠폰, 중복 결제, 포인트 적립이 단골 소재입니다. 답의 뼈대는 세 단계입니다. 경쟁 조건이 정확히 어느 지점에서 생기는지 짚고, 방어 수단을 고르고, 그 수단의 대가를 말합니다. 방어 수단으로는 DB 비관적 락, 버전 컬럼을 쓰는 낙관적 락, 유니크 제약, 분산 락, 큐를 통한 직렬화가 있습니다.

설명을 위한 가상 예시입니다. '선착순 쿠폰 API에 같은 사용자의 요청이 동시에 두 번 들어와 쿠폰이 두 장 발급된 것을 로컬에서 재현했습니다. 사용자 ID와 쿠폰 ID에 유니크 제약을 걸고, 제약 위반이 나면 이미 발급된 것으로 응답하도록 바꿨습니다. 분산 락도 검토했지만 인프라가 하나 늘어나는 대가가 커서 DB 제약으로 충분하다고 판단했습니다.' 이 답은 경쟁 지점, 방어 수단, 포기한 대안이 한 문단에 들어 있습니다.

재시도를 다룰 때는 같은 작업의 재시도에 같은 멱등 키를 재사용하고, 서버가 그 키와 처리 결과를 어떻게 저장·중복 판정하는지까지 설명합니다. 매 시도마다 새 키를 만들면 같은 작업인지 구분할 수 없습니다. Stripe의 멱등 요청 안내는 한 구현 사례이며, 다른 API의 키 보관 기간과 오류 처리는 해당 문서에서 확인해야 합니다. 키만 붙이면 부작용이 사라지는 것은 아니므로 동시 요청과 중간 실패도 검증합니다.

장애 이야기는 시간순이 읽기 쉽습니다. 탐지(무엇을 보고 알았나), 격리(피해를 어떻게 멈췄나), 원인(무엇이 문제였나), 수습(어떻게 되돌렸나), 재발 방지(무엇을 바꿨나)의 다섯 단계로 말하면 장애 규모가 작아도 판단 과정이 드러납니다. 알림 없이 사용자 제보로 알았다면 그 사실을 그대로 말하고, 그 뒤 붙인 지표와 알림으로 이야기를 잇는 편이 사실과 맞고 배운 점도 보여 줍니다.

설계 질문에서 첫 수는 되묻기입니다. 트래픽 규모, 읽기와 쓰기 비율, 지연 허용치, 정합성 요구 수준을 확인한 뒤 큰 그림을 그리고, 병목이 될 지점(단일 DB, 핫 키, 팬아웃)을 스스로 지목한 다음 해결책과 대가를 함께 말합니다. 정답이 정해진 문제가 아니므로 요구사항을 좁히는 질문과 트레이드오프를 입 밖으로 내는 과정 자체가 답변의 내용이 됩니다.

신입에게는 분산 시스템보다 '이 기능을 어떤 테이블과 API로 만들겠나' 수준으로 좁혀서 묻는 경우가 많습니다. 이 경우에도 되묻기와 한계 언급은 그대로 유효합니다. 꼬리질문이 이어지는 방식은 면접 꼬리질문 대비법에서 따로 다뤘습니다.

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

신입이라면 프로젝트 규모 대신 근거의 밀도를 채웁니다. 사용자가 없는 토이 프로젝트라도 '동시 요청을 넣어 봤더니 재고가 음수가 돼서 이렇게 막았고, 이렇게 검증했다'는 이야기는 실무 장애 이야기와 같은 구조를 가집니다. 이런 실험은 면접 전에 직접 해 보고 결과를 기록해 두어야 답변 중에 숫자를 지어내지 않습니다.

경력이라면 반대로 코드 이야기만 하지 않도록 주의합니다. 무중단 마이그레이션, 온콜과 장애 회고, 레거시 때문에 받아들인 타협, 팀에 남긴 문서와 규칙이 경력 면접의 재료입니다. 각 항목에 이야기 하나씩을 준비하면 기술 질문과 협업 질문을 같은 재료로 답할 수 있습니다.

아래는 프리터뷰가 제안하는 편집용 템플릿으로, 이력서에 적은 기술 선택마다 네 칸을 채우는 방식입니다. 공인된 평가 기준이 아니라 답변 재료를 빠짐없이 모으기 위한 점검표입니다.

• 왜 골랐나: 당시 요구사항과 제약 조건, 비교한 기준
• 대안은 무엇이었나: 검토했지만 버린 선택지와 버린 이유
• 결과와 근거: 측정한 값이나 확인한 로그, 없으면 '측정하지 않음'으로 기록
• 지금이라면: 다시 한다면 바꿀 점과 그 이유

백엔드 포트폴리오에는 '트래픽이 100배가 되면 어디가 먼저 문제가 되나', '외부 API가 죽으면 사용자에게 무엇이 보이나', '데이터가 안 맞기 시작하면 어떻게 알아채나' 같은 질문이 붙기 쉽습니다. 세 질문에 대한 답을 프로젝트별로 써 두고, 수치가 없다면 지금이라도 부하 테스트를 한 번 돌려 응답 시간과 실패율을 실제로 측정합니다. 포트폴리오에서 나오는 질문의 유형은 포트폴리오 면접 질문 정리를 참고하세요.

2주 절차는 재료 만들기와 말하기 연습을 나눕니다. 1. 첫 주에는 갈래별 예상 질문을 뽑고 4칸 템플릿을 채웁니다. 2. 둘째 주에는 하루 한 갈래씩 같은 질문을 세 번 소리 내어 답하고, 막힌 질문과 장황했던 답, 몰랐던 개념을 복기 노트에 남깁니다. 3. 마지막 이틀은 새 개념 대신 복기 노트의 약한 답 다섯 개만 다듬고 지원 회사의 기술 블로그를 다시 읽습니다. 말하기 연습을 구성하는 방법은 개발자 모의면접 가이드에 정리돼 있습니다.

말할 상대를 구하기 어렵다면 프리터뷰의 서류 기반 모의면접과 면접 후 피드백, 포트폴리오 점검을 리허설에 쓸 수 있습니다. 이용 조건은 요금·이용 조건에서, 결과물 형태는 예시 리포트에서 먼저 확인하세요. 어떤 도구를 쓰든 격리 수준이나 프레임워크 기본값처럼 버전마다 바뀌는 기술 사실은 공식 문서로 교차 확인해야 합니다.