포트폴리오 첨삭 받는 법: 요청 양식과 수정 순서

학교나 부트캠프의 취업지원 창구, 개발자 오픈채팅·디스코드·취업 스터디, 현직자 멘토링 플랫폼의 공개 질문, 유료 1:1 리뷰, AI 점검 도구가 주요 경로입니다. 경로마다 확인하기 좋은 항목이 다르므로 한 곳에서 모든 답을 얻으려 하기보다 목적에 따라 나누어 쓰는 편이 낫습니다.

현직자를 고를 때는 연차나 회사 이름보다 지원하려는 직무의 서류를 읽어 본 경험이 있는지를 먼저 봅니다. 백엔드 지원자라면 백엔드 지원서를 검토해 본 사람의 한 마디가 유명한 사람의 일반론보다 수정에 쓸모가 있습니다. 저장소나 파일을 보내기 전에는 회사 내부 정보와 개인정보가 들어 있지 않은지 먼저 지웁니다.

지원 직무, 목표 공고, 자료의 완성 단계, 확인하고 싶은 지점 두세 개를 함께 보냅니다. '포트폴리오 좀 봐 주세요'라고만 보내면 리뷰어는 판정 기준이 없어 일반적인 인상만 답하게 됩니다.

아래는 프리터뷰가 편집 제안으로 만든 요청문 빈칸 템플릿입니다. 공인된 양식이 아니므로 상황에 맞게 줄이거나 바꿔 쓰면 됩니다.

• 지원 직무: [예: 주니어 백엔드 개발자]
• 목표 공고: [링크 또는 필수 요건 요약]
• 완성 단계: [예: 프로젝트 선정과 순서는 정했고 문장은 다듬기 전]
• 확인하고 싶은 지점 1: [예: 첫 화면만 보고 제 강점이 무엇으로 읽히는지]
• 확인하고 싶은 지점 2: [예: 결과 서술이 부족한 프로젝트가 어디인지]
• 확인하고 싶은 지점 3: [예: 이 공고의 필수 요건 중 자료에서 보이지 않는 항목]

'이걸로 서류 통과할까요'라는 질문은 피하는 편이 좋습니다. 리뷰어가 답할 수 없는 질문이라 격려나 걱정만 돌아오기 쉽습니다. 보여 주는 시점은 완성 후보다 프로젝트 선정과 순서가 막 정해진 무렵이 낫습니다. 그때가 구조를 바꾸라는 조언을 실제로 반영할 수 있는 시점입니다.

위치, 근거, 수정 방향이 붙어 있는 지적을 먼저 반영합니다. 이 세 가지는 프리터뷰가 제안하는 검토 기준이며, 셋이 모두 빠진 지적은 기록만 해 두고 다음 리뷰에서 다시 물어보면 됩니다.

'성의 없어 보인다'는 말에는 고칠 자리가 없습니다. 반면 '주문 관리 대시보드 항목에 결과가 한 줄도 없다'는 말은 어느 항목인지, 무엇이 빠졌는지, 무엇을 추가할지가 모두 담겨 있어 그날 저녁에 고칠 수 있습니다. 말투가 차갑더라도 이런 지적이 가장 값싼 개선 기회입니다.

지적이 서로 충돌할 때는 다수결 대신 목표 공고의 필수 요건에 비추어 정합니다. 한 사람은 성능 수치를 더 넣으라 하고 다른 사람은 억지스럽다고 하는 상황이라면, 공고가 트래픽 처리 경험을 요구하는지 아니면 제품 초기 단계의 판단 경험을 요구하는지가 기준이 됩니다.

여러 사람에게 따로 받은 지적을 한 문서에 모아 두면 반복되는 항목이 보입니다. 서로 다른 사람이 같은 자리를 짚었다면 우선 손보고, 한 명만 언급한 문장 취향은 뒤로 미룹니다.

프로젝트마다 맡은 범위, 문제, 본인이 한 일과 그 이유, 결과가 한 항목 안에서 읽히도록 씁니다. MIT 진로센터의 이력서 안내는 프로젝트와 활동을 문제·행동·결과 순으로 구체적으로 적고 검증 가능한 규모를 쓰도록 권합니다 공식 안내. 아래는 그 틀을 참고해 프리터뷰가 만든 설명을 위한 가상 예시입니다.

수정 전: '4인 팀 프로젝트로 중고거래 플랫폼을 개발했습니다. React, Spring Boot, MySQL, Docker를 사용했습니다. 채팅 기능과 결제 모듈을 구현했습니다.'

수정 후: '4인 팀 중고거래 플랫폼에서 채팅과 결제 서버를 맡았습니다. 채팅 메시지 유실이 반복되어 폴링을 웹소켓으로 바꾸고 재연결 로직을 추가했으며, 로컬 테스트에서 재연결 후 메시지 순서가 유지되는 것을 확인했습니다. 결제 모듈은 외부 API 장애에 대비해 재시도 횟수와 실패 기록 방식을 제가 정했습니다.'

수정 후 문장에서 달라진 것은 주어와 결과입니다. 주어 없이 팀 전체의 일로 읽히던 문장이 '제가 맡은 범위'로 바뀌었고, 기술 이름 나열이 그 기술로 해결한 문제로 바뀌었으며, 확인 조건이 붙은 결과가 들어갔습니다. 프로젝트 자체를 더 크게 꾸민 부분은 없습니다. 면접에서는 이 문장 하나하나가 질문으로 돌아올 수 있으므로 포트폴리오 면접 질문 예시와 답변 준비법에서 이어지는 질문 유형을 함께 확인해 두면 좋습니다.

숫자를 지어내지 않고 무엇이 달라졌는지를 사실로 적습니다. 결과가 필요하다는 말은 전과 후가 문장에 있어야 한다는 뜻이며, 모든 문장에 퍼센트를 붙이라는 요구는 아닙니다. 사용자 없는 연습 프로젝트에 '전환율 30% 개선'을 적으면 그 숫자를 어떻게 쟀는지 설명해야 할 때 답이 없습니다.

지금이라도 잴 수 있는 것은 재고 조건을 함께 적습니다. 설명을 위한 가상 예시로 '목록 조회 API 응답 시간을 로컬에서 100회 측정해 평균 800ms에서 120ms로 줄였다'처럼 측정 환경과 횟수가 붙으면 작은 숫자도 검증 가능한 결과가 됩니다.

잴 대상이 없으면 사실형 결과로 씁니다. '중복 코드 세 곳을 공통 모듈로 합쳐 이후 기능 추가 때 한 곳만 고치면 되게 했다', '배포 스크립트를 만들어 수동 절차 다섯 단계를 한 단계로 줄였다' 같은 문장은 숫자 없이도 전과 후가 있습니다.

클론 코딩이나 부트캠프 공통 과제라면 원본과 다르게 결정한 지점 한 줄을 적습니다. 과제 자체가 문제가 되기보다, 원본과 어디가 다른지가 없으면 같은 과제를 낸 다른 지원자와 구별할 근거가 사라집니다. '튜토리얼은 상태를 전역으로 관리했지만 화면 단위로 나눈 이유' 한 줄이면 충분합니다.

사실 오류, 결과와 역할 서술, 구조, 문장 표현 순서로 반영하기를 제안합니다. 눈에 띄는 것부터 손대면 대개 문장 다듬기부터 시작하게 되는데, 표현이 매끈해져도 빠진 결과와 역할은 그대로 남습니다.

1. 사실 오류 정리: 깨진 링크, 접근 권한이 막힌 저장소, 오탈자, 회사명·직무명 오기, 만들다 만 페이지를 먼저 고칩니다. 판단이 필요 없는 수정이라 먼저 끝내 둡니다.
2. 결과와 역할: 지원 직무와 가장 가까운 프로젝트 두세 개를 골라 각각에 결과 한 줄과 담당 범위 한 줄을 넣습니다. 나머지 프로젝트는 목록으로 내리거나 뺍니다.
3. 구조: 스크롤하기 전 첫 화면에 지원 직무, 한 줄 요약, 대표 프로젝트 링크가 있는지 확인합니다. 무엇을 넣고 뺄지는 포트폴리오 만드는 법: 넣을 작업, 뺄 작업, 배열 순서를 참고하면 됩니다.
4. 문장 표현: 마지막에 문장을 다듬습니다. 한 바퀴 고친 뒤에는 처음 봐 준 사람과 다른 사람에게 보여 주고, 처음 요청문의 확인 지점이 해소됐는지를 같은 질문으로 다시 묻습니다.

이력서와 포트폴리오를 함께 고친다면 이력서의 프로젝트 요약부터 정리하는 편이 순서상 편합니다. 요약에서 강조할 항목이 정해지면 포트폴리오에서 무엇을 앞에 둘지도 같이 정해집니다. 이력서 쪽은 개발자 이력서 작성 순서와 AI 첨삭 활용법에서 다룹니다.

AI 점검 도구는 구조, 결과 서술 유무, 역할 명시처럼 텍스트로 판단할 수 있는 항목을 확인하는 데 쓰고, 기술 판단과 회사별 적합도는 사람이나 목표 공고로 다시 확인합니다. 도구가 링크 너머의 실제 구현을 열어 보지는 못합니다.

프리터뷰의 포트폴리오 점검은 파일이나 링크를 넣으면 결과·역할 서술이 빠진 항목과 구조상 보완할 지점을 짚어 주는 기능입니다. 서류 기반 모의면접과 면접 후 피드백도 함께 제공하므로 고친 포트폴리오로 바로 질문을 받아 볼 수 있습니다. 2026년 10월 8일 기준으로 가입하면 포트폴리오 점검을 하루 1회 무료로 쓸 수 있고(자소서 첨삭과 합산), 모의면접은 무료 제공분이 없어요. 요금과 이용권 구성은 요금 페이지에서 확인할 수 있어요. 무료 점검에서는 점수와 평가, 개선안 1개의 상세 내용을 보여 주고, 나머지 개선안은 제목만 보이며 내용은 결과 화면에서 유료로 열립니다. 현재 조건은 요금·이용 조건에서, 지적의 구체성은 예시 리포트에서 먼저 확인한 뒤 어디까지 맡길지 정하면 됩니다.

어떤 도구든 점수나 등급을 합격 예측으로 읽지 않는 편이 좋습니다. 첫 점검 결과는 어디부터 고칠지 좌표를 잡는 용도이고, 최종 판단은 지원할 회사의 공고와 사람 리뷰어의 의견에 맞춥니다.