개발자 이직 면접 준비 방법 — 기술 이름 말고, 왜 골랐는지 적으세요

퇴근 뒤 노트북을 엽니다. 한쪽 탭에는 알고리즘 문제, 다른 탭에는 시스템 설계 강의, 메모장에는 새로 공부할 기술 이름이 줄을 섰습니다. 면접은 다가오는데 할 일만 늘죠. ‘개발자 이직 면접 준비 방법’을 검색한 건 준비가 없어서가 아니라, 어디부터 잘라야 할지 몰라서일 겁니다.

먼저 자르겠습니다. 새 기술을 하나 더 얹기 전에, 이력서에 이미 쓴 기술 하나의 ‘왜’를 적으세요. 경력 개발자 면접에서 기술 이름은 답이 아니라 질문을 여는 버튼입니다. 면접관은 ‘Redis를 썼다’에서 멈추지 않고, 왜 필요했고 무엇과 비교했고 어떤 대가를 감수했는지로 내려갑니다.

🖥 기술 이름은 평가 항목이 아니라 질문 생성기입니다

먼저 뽑는 쪽 화면부터 풀겠습니다. 여기서 말하는 평가 화면은 면접관이 ‘설계 판단·문제 해결·협업’ 같은 항목마다 답변에서 확인한 근거를 적는 표입니다.

20년 넘게 뽑아본 입장에서, 겪은 바로는 제가 참여한 기술 면접에서는 면접관이 이력서의 기술 이름 하나를 평가 화면의 ‘설계 판단’ 칸과 연결한 뒤 장애 조건·대안·확인 방법을 차례로 물어 답변의 일관성을 적고, 채용 회의는 ‘Redis를 아는가’가 아니라 운영 제약 아래 그 선택에 참여한 증거가 남았는지로 다음 전형 여부를 정했습니다.

그래서 ‘Redis 캐시로 응답 속도 개선’이라는 한 줄은 자랑으로 끝나지 않습니다. 뽑는 쪽에서는 곧바로 질문 나무가 열립니다. 왜 캐시가 필요했나. 서버 안 캐시와 무엇이 달랐나. 값이 오래 남는 문제는 어떻게 막았나. Redis가 멈추면 서비스는 어떻게 버티나. 개선 여부는 무엇으로 확인했나.

스택을 적는 순간, 그 스택의 실패 조건까지 설명할 책임도 생깁니다. 이건 다른 직군의 ‘열심히 한 경험을 정리하세요’로 바꾸면 성립하지 않는, 개발자 이력서 특유의 계약입니다. 😐

📊 프로젝트를 캐는 데는 바깥 근거도 있습니다

원티드의 ‘원티드 개발자 리포트’는 원티드 회원 508명의 온라인 설문과 채용 데이터를 바탕으로 만들었고, 응답자를 면접관 참여 경험이 있는 그룹과 지원자 그룹으로 나눠 채용 평가 요소를 물었습니다.

면접관 경험 그룹에서 프로젝트 경험을 중요하게 평가했다는 응답은 75.0%였습니다. 포트폴리오는 43.1%였습니다. 이 수치가 모든 회사의 기술 면접표를 대신하지는 않습니다. 다만 포트폴리오의 페이지를 더 꾸미는 일보다, 이미 적힌 프로젝트에서 판단 근거를 꺼내는 일이 먼저라는 우선순위는 세울 수 있습니다.

프로젝트의 크기를 부풀릴 필요도 없습니다. 면접관이 옮겨 적을 수 있는 건 서비스의 유명세가 아니라 당신이 본 제약, 버린 대안, 감수한 대가, 확인한 결과입니다. 그 네 가지가 있어야 프로젝트 경험이 평가 화면의 증거가 됩니다.

🌳 ‘왜 Redis였나요?’ 다음 질문까지 준비하세요

가상의 답 두 개를 놓고 보겠습니다.

막히는 답 — ‘Redis가 빠르다고 배워서 선택했습니다.’

이 답에는 기술 설명은 있지만 당신의 판단이 없습니다. 면접관 화면에는 ‘Redis의 장점을 안다’ 정도만 남고, 설계 판단 칸은 비어 있습니다.

근거가 남는 답 — ‘행사 시간에 상품 조회가 원본 데이터베이스에 몰렸습니다. 당시 서버 안 캐시는 인스턴스마다 갱신 시점이 달랐기에 뺐고, 여러 서버가 함께 쓰는 Redis를 골랐습니다. 대신 Redis에 문제가 생기면 원본 데이터베이스로 우회하게 했고, 배포 뒤에는 요청 중 캐시에서 바로 답한 비율과 응답 시간, 원본 데이터베이스 부하를 함께 확인했습니다.’

여기에는 문제, 대안, 선택의 대가, 장애 때의 행동, 확인 방법이 있습니다. 면접관은 이 답을 다시 파고들 수 있고, 파고들어도 앞뒤가 맞는지 확인할 수 있습니다. 기술 면접의 꼬리질문은 지식을 더 말하라는 주문이 아니라, 그 결정이 정말 당신 경험인지 확인하는 검증입니다.

🧾 오늘은 프로젝트 하나만 ‘의사결정 검증표’로 바꾸세요

할 일은 하나입니다. 이력서에서 기술 이름이 들어간 프로젝트 한 줄을 고르고, 아래 여섯 칸을 각각 한두 문장으로 채우세요.

문제 — 어떤 현상이 일어나서 바꿔야 했나.
제약 — 시간·트래픽·비용·인력 중 무엇이 선택을 묶었나.
대안 — 함께 검토한 다른 방법은 무엇이었나.
선택 — 왜 이 기술을 골랐고, 결정에서 당신이 맡은 부분은 무엇이었나.
대가 — 이 선택으로 새로 생긴 위험이나 운영 부담은 무엇이었나.
확인 — 배포 뒤 무엇을 비교해 선택이 맞았는지 봤나.

여섯 칸이 모두 채워지면 완료입니다. 회사 밖으로 낼 수 없는 수치는 쓰지 마세요. 정확한 값 대신 측정한 지표와 좋아지거나 나빠진 방향만 적어도 판단 구조는 남습니다. 반대로 빈칸이 있다면 새 강의를 결제할 때가 아니라, 당시 문서나 기록을 확인할 자리입니다.

오늘 두 번째 프로젝트로 넘어가지 마세요. 한 줄을 끝까지 방어할 수 있게 만드는 것이 완료 조건입니다.

🧭 코딩 테스트와 시스템 설계는 공고가 시키는 만큼만 분리하세요

이 글이 알고리즘이나 시스템 설계를 버리라는 뜻은 아닙니다. 채용 공고나 안내 메일에 코딩 테스트가 적혀 있으면 그 전형은 따로 준비해야 합니다. 시스템 설계 면접이 예고됐다면 요구사항을 좁히고 구조를 설명하는 연습도 필요합니다.

다만 그 공부가 이력서 검증을 대신하지는 못합니다. 알고리즘 문제를 풀어도 ‘실서비스에서 왜 이 인덱스를 골랐나’는 별도 질문이고, 시스템 설계 강의를 들어도 ‘당시 장애에서 왜 롤백하지 않았나’는 당신 기록에서만 나옵니다.

순서는 간단합니다. 공고가 명시한 시험은 시험대로, 이력서에 적은 선택은 검증표대로. 둘을 한 바구니에 넣으니 준비가 끝없이 불어났던 겁니다. 분리하면 오늘 끝낼 수 있는 일이 보입니다.