개발자 모의면접 연습법: CS·프로젝트·꼬리질문

축마다 막히는 이유가 달라서예요. CS 기초는 지식의 빈틈에서, 프로젝트 딥다이브는 '왜 그렇게 만들었나'의 논리에서, 행동 질문은 구조 없이 길어지는 데서, 기술 심층 면접은 생각을 입 밖으로 내지 못하는 데서 막혀요. 처방이 다르니 연습도 따로 하는 편이 나아요.

비중은 지원처에 따라 달라요. 신입·주니어 공고는 CS 기초와 프로젝트 설명이 중심이 되는 경우가 많고, 경력 공고는 설계 판단과 협업 경험 쪽으로 무게가 옮겨가요. 지원 회사 공고의 필수 요건과 우대 사항을 모두 읽고 어느 축에 시간을 더 쓸지 먼저 정하세요. 갈래별 질문은 백엔드 개발자 면접 질문 가이드와 프론트엔드 개발자 면접 질문에서 이어서 볼 수 있어요.

정의, 비교, 적용의 세 문장 틀로 소리 내어 답하는 연습을 추천해요. 인덱스라면 '조회를 빠르게 하는 자료구조다(정의), 대신 쓰기 성능과 저장 공간을 내준다(비교), 그래서 조회가 몰리는 컬럼에만 걸었다(적용)'처럼요. 틀이 입에 붙으면 낯선 질문에도 뼈대는 잡혀요.

자신이 쓴 기술의 공식 문서 범위에서 설명하는 습관도 도움이 돼요. 트랜잭션 격리 수준을 묻는다면 PostgreSQL을 썼던 사람은 PostgreSQL 문서의 격리 수준 설명(공식 안내)을 기준으로 답하고, 같은 이름의 격리 수준이라도 DB마다 구현이 다를 수 있다고 덧붙이는 식이에요. 프론트엔드라면 React 문서가 trigger, render, commit을 구분한다는 점(공식 안내)을 근거로 '렌더가 곧 DOM 교체는 아니다'까지 말할 수 있으면 좋아요.

설명하다 막히는 지점이 다시 공부할 목록이에요. 프로세스와 스레드의 차이는 알았는데 '컨텍스트 스위칭 비용은 왜 다른가요'에서 멈췄다면 그 지점만 골라 공부하세요. 키워드를 길게 나열하는 답보다, 주제 수를 줄이더라도 '왜 그렇게 설계됐는지'까지 말할 수 있는 주제를 늘리는 편이 꼬리질문에 대응하기 좋아요.

이력서 한 문장마다 '왜 그 기술을 골랐나, 대안은 무엇이었나, 결과는 어땠나'의 3단 문답을 미리 써 두는 게 준비의 대부분이에요. 결과에 숫자를 쓰려면 측정 조건을 함께 적고, 측정하지 않은 항목은 측정하지 않았다고 말하는 편이 나아요. 없는 숫자를 만들어 넣지 마세요.

설명을 위한 가상 예시예요. 이력서에 '상품 목록 API 응답을 Redis로 캐싱'이라고 썼다면 이렇게 준비할 수 있어요. 왜: 목록 조회가 요청의 대부분이라 DB 부하를 줄이고 싶었다. 대안: 애플리케이션 로컬 캐시도 검토했지만 서버가 두 대라 캐시 불일치가 걱정됐다. 결과: 로컬에서 부하 도구로 비교했고 운영 환경 수치는 없다고 밝힌다. 이어서 '무효화는 어떻게 했나'라는 꼬리질문에 상품 수정 이벤트에서 키를 삭제했다고 답할 수 있게 실제 코드를 다시 열어 보세요.

당시 이유가 '튜토리얼이 많아서'였다면 그대로 말하고, 지금이라면 어떤 기준으로 다시 고를지 덧붙이세요. 사후에 근사한 이유를 지어내면 코드와 어긋나는 부분이 생기기 쉬워요. 아키텍처는 화이트보드 없이도 '클라이언트 요청이 게이트웨이를 지나 이 서비스로' 식으로 데이터 흐름을 입으로 따라가는 연습을 해 두세요.

답변마다 예상 꼬리질문을 두 단계 붙여 표로 만드는 방식을 프리터뷰 편집 제안으로 소개해요. 공인된 양식이 아니라 연습용 정리표예요. 한 행에 질문, 내 답변 요지, 1차 꼬리, 2차 꼬리, 확인할 자료를 적고, 아래는 설명을 위한 가상 예시로 채운 모습이에요.

모르는 꼬리질문이 나오면 아는 범위, 추론, 확인이 필요한 부분을 나눠 말하는 연습을 해 두세요. '정확한 내부 구현은 확인이 필요하지만, B-tree 기반이라면 이런 특성일 것 같습니다'처럼요. 추론을 확정된 사실처럼 말하지 않아야 이어지는 확인 질문에서 부담이 줄어요. 혼자서는 꼬리질문이 잘 재현되지 않으니 스터디원이나 AI 도구에 '답변마다 꼬리질문 두 개'를 규칙으로 요청하세요. 꼬리질문 자체를 더 다룬 글은 면접 꼬리질문이에요.

협업 갈등, 장애 대응, 아쉬웠던 결정을 하나씩 골라 상황·과제·행동·결과로 정리하면 대부분의 행동 질문에 재료가 돼요. STAR 구분과 본인의 행동과 역할을 사실대로 구체적으로 설명하라는 안내는 MIT CAPD 자료(공식 안내)에서 볼 수 있어요. 팀 프로젝트라면 팀이 한 일과 내가 한 일을 구분해서 말하는 게 특히 중요해요.

설명을 위한 가상 예시예요. '코드 리뷰에서 팀원과 의견이 갈렸던 경험'이라면 이렇게 정리할 수 있어요. 상황: API 응답 형식을 두고 두 안이 나뉨. 과제: 배포 일정 전에 합의가 필요했음. 행동: 두 안을 프론트엔드 팀의 사용 편의 기준으로 비교한 표를 만들어 공유. 결과: 상대 안을 채택했고 내 안의 장점은 다음 버전에 반영하기로 함. 결과가 내 의견 채택이 아니어도 괜찮고, 그 과정에서 내가 무엇을 했는지가 답의 중심이에요.

혼자 연습은 답변을 녹음해 길이와 군말을 확인하고, CS 개념을 러버덕에게 설명하듯 소리 내는 데 맞아요. 스터디는 면접관 역할을 맡아 남의 답에서 빈틈을 찾아 보는 경험이 자기 답변 설계로 돌아오고, 사람 앞에서 말하는 긴장도 미리 겪을 수 있어요. 대신 일정 조율이 필요하고 피드백 품질은 구성원에 따라 달라요.

AI 모의면접은 같은 딥다이브 질문을 여러 번 돌려 답을 입에 붙이는 반복과 두괄식·장황함 같은 형식 피드백에 맞아요. 프리터뷰는 이력서·포트폴리오 같은 서류를 바탕으로 모의면접을 진행하고 면접 후 피드백과 포트폴리오 점검을 제공해요. 이용 조건은 요금·이용 조건에서, 결과물 형태는 예시 리포트에서 먼저 확인하세요. 어떤 도구든 AI가 말하는 기술 사실은 공식 문서로 교차 확인이 필요해요. 방식별 자세한 비교는 모의면접 연습 방법 총정리에 있어요.

아래 일정은 프리터뷰 편집 제안이고 남은 기간과 지원처에 맞춰 조정하면 돼요. 첫 주는 재료를 모으는 기간이에요. 공고와 이력서에서 4축별 예상 질문을 모아 답 초안을 쓰고, 딥다이브 3단 문답과 행동 질문 STAR 초안을 완성해요. 아직 소리 내는 단계는 아니에요.

둘째 주는 소리 내는 기간이에요. 하루에 한 축씩 같은 질문을 여러 번 답하고, 이 기간에 모의면접을 두세 번 배치해요. 매 회 끝나면 막힌 질문, 길어진 답, 몰랐던 개념을 복기 노트에 남기세요. 복기 없이 횟수만 늘리면 같은 지점에서 다시 막히기 쉬워요.

마지막 이틀은 새로운 개념에 손대지 않는 기간이에요. 복기 노트에서 약했던 답 몇 개만 골라 다듬고, 지원 회사의 제품과 기술 블로그를 다시 훑고, 역질문을 준비하세요. 전날 밤은 연습보다 컨디션 관리가 더 큰 변수예요.