포트폴리오 면접 질문 예시: 선택 이유·성과·내 역할

설명이 비어 있는 자리예요. 무엇을 썼다고만 적혀 있고 왜 골랐는지가 없는 대목, 정도를 알 수 없는 성과 문장, 주어가 '우리'인 협업 설명, 어려웠다고만 적고 푼 과정이 한 줄인 항목, 유행하는 도구를 쓴 항목이 그렇죠. 문서가 달라도 비어 있는 자리의 모양은 비슷해요.

내 문서를 처음 보는 사람의 눈으로 항목마다 이 표의 흔적이 있는지 확인해 보세요. 표시가 붙은 자리가 곧 답을 미리 채워 둘 자리예요. 문서 자체의 구성이 고민이면 포트폴리오 만드는 법: 넣을 작업, 뺄 작업, 배열 순서를 먼저 보셔도 좋아요.

고려한 대안, 판단 기준, 그래서 내린 결론 순으로 답해요. 대안을 하나만 말해도 비교한 흔적이 생기고, 판단 기준에 당시 조건이 붙으면 답이 단단해져요. '성능이 좋아서'만으로는 어떤 상황에서 왜 그 성능이 필요했는지가 빠져 있어요.

설명을 위한 가상 예시예요. '캐시를 붙일 때 로컬 메모리 캐시와 별도 캐시 서버를 놓고 봤어요. 서버가 두 대라 인스턴스마다 값이 달라지면 안 됐고, 팀에 캐시 서버 운영 경험이 있어서 그쪽을 골랐어요. 다만 초기 셋업이 늘어난 건 감수했어요.' 대안, 기준, 결론, 감수한 비용이 한 번에 들어 있어요.

지금이라면 다르게 하겠다는 답도 좋아요. 당시 판단과 지금 판단을 나눠 말하면 그 사이에 무엇을 배웠는지가 드러나요. 다만 그때가 틀렸다고만 하고 끝내지 말고, 어떤 정보를 새로 알게 돼서 판단이 바뀌었는지까지 붙이세요.

지금이라도 잴 수 있는 값부터 찾아요. 응답 시간, 처리 건수, 작업에 걸린 시간, 오류 발생 횟수처럼 되짚어 확인할 수 있는 값이 있으면 그 값을 쓰고, 비교 대상과 측정 조건을 같이 말해요. MIT 진로센터의 이력서 안내도 확인 가능한 규모와 결과를 구체적으로 적도록 권해요. 없는 숫자를 만들어 넣지 말자는 것은 프리터뷰의 편집 원칙이에요.

정말 숫자가 없으면 관찰 가능한 변화로 답해요. '배포 후 같은 문의가 더 들어오지 않았어요', '수동으로 하던 확인 단계가 없어졌어요'처럼 다른 사람도 확인할 수 있는 형태면 충분해요. 왜 측정하지 못했는지를 한 문장으로 덧붙이면 질문이 자연스럽게 마무리돼요.

지어낸 숫자는 쓰지 않아요. 측정 방법과 전후 조건을 되묻는 질문이 이어질 수 있고, 답하지 못하는 숫자 하나가 다른 항목의 설명까지 의심하게 만들 수 있어요. 숫자를 말할 때는 언제, 어떤 조건에서, 무엇으로 쟀는지를 함께 준비해 두세요.

맡은 범위를 먼저 긋고 시작해요. 전체 구조를 한 문장으로 설명한 뒤 그중 내가 담당한 부분을 짚으면 과장 없이도 규모가 전달돼요. 옆 부분은 어디까지 알고 어디부터 모르는지를 나눠 말하면 뒤이은 질문에도 답하기 쉬워요.

설명을 위한 가상 예시예요. '네 명이 만든 예약 서비스였고, 저는 예약 생성과 취소 API를 맡았어요. 결제 연동은 다른 팀원이 했는데, 예약과 결제 사이 상태 전이는 제가 표로 정리해서 같이 맞췄어요. 프론트 쪽 구현은 인터페이스 합의까지만 관여했어요.' 범위, 경계, 협업에서 한 일이 구분돼 있어요.

작았던 부분은 작았다고 말해도 돼요. 대신 그 안에서 내가 내린 판단 하나를 골라 깊게 설명하세요. 인터페이스를 먼저 정하자고 제안한 일, 리뷰에서 잡아낸 문제, 다시 짠 일정처럼 협업 과정에서 한 일도 기여로 말할 수 있어요.

문제 해결은 증상, 원인을 좁힌 방법, 시도한 것, 확인한 방법 순으로 다시 펼쳐요. '어려웠지만 해결했다'로 끝난 항목은 원인을 어떻게 찾았는지가 빠져 있어서, 로그를 봤는지 재현 조건을 바꿔 봤는지 같은 과정을 말하면 문제를 정의하는 방식이 보여요.

설명을 위한 가상 예시예요. '특정 시간대에만 저장이 실패했어요. 요청 로그를 시간별로 나눠 보니 배치 작업과 겹치는 구간이었고, 락 대기 시간을 확인해서 배치 실행 시각을 옮겼어요. 옮긴 뒤 일주일 동안 같은 실패가 없는지 로그로 확인했어요.'

새 도구를 쓴 자리는 필요했던 조건과 그 도구가 그 조건을 어떻게 채웠는지를 말해요. 써 보고 싶어서 골랐다면 그렇게 말하고, 실제로 써 보니 어떤 점이 맞고 어떤 점이 부담이었는지를 붙이면 학습 목적의 선택도 설명이 돼요. 기술 질문의 깊이를 연습하고 싶다면 개발자 모의면접 가이드 — CS 기초부터 꼬리질문까지 4축 연습법도 참고하세요.

발표 시간과 형식은 회사 안내를 따르고, 안내가 없으면 문의해서 확인해요. 시간이 짧을수록 작업 수를 줄이고 한 작업의 판단 과정을 깊게 보여 주는 편이 나아요. 작업마다 문제, 선택 이유, 결과, 내 역할 순으로 짧게 말하면 발표 뒤 질문도 그 흐름 위에서 들어와요.

순서는 결과물을 먼저 보여 주고 이유를 붙이는 쪽이 듣기 편해요. 쓴 도구 목록은 슬라이드에 적어 두되 말로 나열할 필요는 없고, 포부 같은 이야기는 질의응답에서 물으면 답하는 편이 자연스러워요.

대본은 문장 전체를 외우기보다 슬라이드마다 키워드 몇 개와 근거가 되는 값 하나를 적어 두고, 그 키워드로 말하는 연습을 시간을 재며 두세 번 해 보세요. 문장 단위로 외우면 한 줄이 끊겼을 때 이어 가기 어려운 경우가 있고, 발표 뒤 질문에서 같은 문장을 반복하기 쉬워요.

자리마다 두 겹 아래 질문까지 미리 적어 두는 것이 대비예요. 선택 자리는 '왜 골랐나 → 대안은 무엇이었나 → 그 대안을 버린 근거는', 성과 자리는 '얼마나 → 어떻게 쟀나 → 전후 조건이 같았나', 기여 자리는 '무엇을 맡았나 → 경계는 누가 정했나 → 옆 부분은 어디까지 아나' 식으로 이어지는 경우가 많아요. 꼬리질문의 일반적인 흐름은 면접 꼬리질문 대비법에서 따로 다뤄요.

아래는 프리터뷰가 제안하는 빈칸 점검표예요. 항목마다 한 장씩 채워 문서 옆에 두면, 세 번째 칸이 비어 있는 자리가 면접 전에 보완할 자리예요.

• 항목 이름: ____
• 걸리는 자리(선택 / 성과 / 기여 / 문제 해결 / 새 도구): ____
• 첫 질문과 내 답 한 문장: ____
• 두 번째 '왜'와 내 답: ____
• 세 번째 '왜'와 내 답, 또는 솔직히 모르는 부분: ____
• 답의 근거를 확인할 수 있는 자료(로그, 커밋, 회의 기록 등): ____

내 문서의 빈 자리는 쓴 사람 눈에 잘 안 보여요. 프리터뷰는 포트폴리오 점검으로 설명이 비어 있는 자리를 짚어 주고, 올린 문서의 문장을 바탕으로 되묻는 모의면접과 면접 후 피드백을 함께 제공해요. 어느 대목에서 질문이 들어올 수 있는지 면접 전에 한 번 겪어 보는 용도로 쓸 수 있어요. 이용 조건은 요금·이용 조건에서, 피드백 형태는 예시 리포트에서 확인하세요.

질문이 나올 자리 자체는 그대로 둬도 돼요. 답할 준비가 된 자리를 남겨 두면 대화가 내가 아는 쪽으로 흐를 가능성이 커져요. 고쳐야 할 것은 사실과 다른 부분이에요. 과장된 수치, 실제보다 넓게 적힌 기여 범위, 지금이라면 다르게 할 선택이 설명 없이 남아 있는 대목이 대표적이에요.

고쳤다면 고친 버전을 다시 보내거나 면접 자리에서 먼저 밝히세요. 면접관이 가진 제출본과 내 설명이 어긋나면 그 차이가 새로운 질문이 돼요. 분량이 많다면 자신 있는 작업을 앞으로 옮기고 설명이 없는 프로젝트는 줄이는 편이 질문을 준비한 쪽으로 모으는 데 도움이 돼요. 다른 사람의 눈으로 점검받는 방법은 개발자 포트폴리오 첨삭·피드백 받는 법에 정리했어요.