취업 포트폴리오 만드는 법: 구성·분량·작업 소개 양식

지원 직무의 공고에 적힌 업무와 겹치는 작업을 넣고, 그 작업에서 내가 내린 판단을 한 문장으로 말할 수 없는 작업은 빼요. 결과물이 아무리 좋아도 왜 그렇게 만들었는지 설명이 비어 있으면 읽는 쪽에 판단 재료를 주지 못합니다.

고르는 절차를 뒤집으면 훨씬 수월해요. 지원할 공고 서너 개를 먼저 펴 놓고 담당 업무와 자격 요건을 한 줄씩 옮겨 적은 다음, 내 작업 목록과 겹치는 줄마다 표시합니다. 표시가 없는 작업은 뺄 후보, 여러 줄과 겹치는 작업은 맨 앞에 둘 후보예요. 공고 문장 중 어느 하나가 특별히 중요하다는 규칙은 없으니 관련 요건을 전부 읽고 대조하세요.

설명을 위한 가상 예시예요. 서비스 기획 공고에 '요구사항 정의, 화면 설계, 지표 관리'가 적혀 있고, 내 작업이 동아리 앱 화면 설계, 카페 메뉴판 디자인, 학회 홍보 영상이라면 앱 화면 설계만 두 줄과 겹칩니다. 나머지 둘은 한 줄 목록으로 내리거나 지우는 편이 문서를 읽기 쉽게 만들어요.

공고나 회사 안내에 장수·용량·개수 조건이 있으면 그 숫자가 기준이에요. 조건이 없다면 장수 대신 설명 시간으로 정하는 방식을 연습용으로 제안합니다. 처음부터 끝까지 소리 내어 설명해 보고, 발표 시간이 정해진 자리라면 그 시간 안에, 아니라면 5분 안팎에 끝나도록 작업이나 장을 덜어 내는 방식이에요. 5분은 채용사의 기준이 아니라 스스로 상한을 잡기 위한 제안 값입니다.

작업 개수는 설명 시간에서 역산돼요. 개수를 늘려 두께를 채우면 설명이 붙지 않은 항목이 함께 늘고, 그 항목마다 스스로 답하기 어려운 질문이 생깁니다. 작업마다 설명 길이가 달라서 몇 개가 적당하다고 미리 못 박기는 어렵고, 시간 안에 판단 이유까지 말할 수 있는 개수가 곧 내 개수예요.

직군 관행도 감안하세요. 시각 결과물이 중심인 디자인은 페이지가 자연스럽게 늘고, 코드와 배포 링크가 중심인 개발은 저장소 주소와 실행 화면 몇 장이 긴 설명을 대신하기도 합니다. 개발 직군의 문서 구성은 개발자 이력서 작성 가이드와 함께 보면 이력서와 포트폴리오의 역할 분담이 정리돼요.

작업마다 같은 틀을 쓰면 읽는 쪽이 두 번째 작업부터는 어디에 무엇이 있는지 알아요. 아래는 프리터뷰가 제안하는 빈칸 템플릿이고, 각 줄을 한두 문장으로 채운 뒤 결과물 이미지나 링크를 그 아래에 붙입니다.

• 문제: 누가 어떤 상황에서 무엇이 불편했는지
• 내 역할과 범위: 팀 작업이면 전체 중 내가 맡은 구간
• 판단과 이유: 선택지 중 무엇을 골랐고 왜 골랐는지
• 결과: 무엇이 달라졌는지, 확인 가능한 지표가 있으면 그 지표
• 다시 한다면: 지금 보이는 한계와 고칠 점 한 가지

설명을 위한 가상 예시로 작성 전후를 비교해 볼게요. 작성 전은 '동아리 회비 관리 앱 화면 설계. 피그마 사용. 20명 사용'처럼 결과물 이름과 도구만 있는 상태예요. 작성 후는 '총무가 매달 엑셀로 회비 납부 여부를 확인하느라 한 시간씩 걸렸다(문제). 화면 설계와 사용자 확인을 맡았다(역할). 납부 현황을 목록이 아니라 달력 형태로 보여 주기로 했는데, 총무가 날짜 기준으로 확인한다는 인터뷰 결과 때문이었다(판단). 회원 20명이 한 학기 사용했고 총무가 확인에 쓰는 시간이 줄었다고 답했다(결과)'가 됩니다.

결과 줄에 숫자가 없으면 만들어 넣지 마세요. 확인한 사실만 적고, 수치가 없으면 '사용자 다섯 명이 확인해 준 반응'처럼 실제로 있었던 근거로 대신합니다. MIT 경력센터의 이력서 안내도 프로젝트를 문제·행동·결과로 구체적으로 쓰고 확인 가능한 규모를 적도록 안내하는데, 포트폴리오 페이지에도 같은 원칙이 맞아요.

가장 설명할 자신이 있는 작업을 맨 앞에 둬요. 뒤쪽까지 읽힌다는 보장이 없으니, 분량을 줄이는 일과 순서를 정하는 일은 결국 같은 문제입니다. 자신 있다는 기준은 결과물 만족도보다 질문 대비에 가까워요. 왜 그렇게 했는지, 다른 선택지는 무엇이었는지, 다시 한다면 무엇을 바꿀지를 말할 수 있는 작업이 앞자리에 맞습니다. 질문이 이어지는 방식은 면접 꼬리질문 대비법에 정리돼 있어요.

첫 화면에는 세 가지, 곧 지원 직무, 나를 요약하는 한 줄, 대표 작업으로 가는 링크를 두면 충분해요. 이름과 연락처는 그 아래에 있어도 됩니다. 결과물은 인상적이지만 과정 기억이 흐릿한 작업은 중간에 두고, 지원 직무와 거리가 있지만 남기고 싶은 작업은 뒤쪽 목록으로 내려요.

기획·마케팅·연구개발도 공고에서 포트폴리오나 경력기술서를 요구하는 경우가 있어요. 판단 기준은 공고입니다. 적혀 있으면 내고, 없으면 면접에서 꺼낼 자료로 준비해 두세요. 요구가 없는데 두꺼운 문서를 보내면 읽는 쪽 부담만 커집니다.

기획은 제안서, 요구사항 정의서, 화면 설계서가 재료예요. 회사 문서를 그대로 낼 수 없으면 고객사명과 실제 수치를 지우고 문제 정의와 판단 근거만 남겨 다시 씁니다. 마케팅은 캠페인 단위로 묶어 무엇을 어느 채널에 집행했고 지표가 어떻게 움직였는지 적고, 사내 데이터를 공개하기 어려우면 절대값 대신 비율이나 배수로 적되 그렇게 처리했다는 사실을 문서에 밝혀요.

연구개발은 실험 목록을 나열하기보다 배경, 방법, 결과, 내가 맡은 구간 순으로 접습니다. 논문이나 특허가 여러 건이면 목록을 길게 붙이는 대신 그중 한 건의 문제 정의를 한 장으로 풀어 쓰는 편이 읽혀요. 공동 연구라면 전체 그림을 먼저 그리고 내 담당 실험에 표시를 남기면 규모와 기여가 함께 전달됩니다.

지원 직무의 일과 닮은 작업 하나를 새로 만드는 방법이 있어요. 지난 경험을 뒤져 억지로 채우는 것보다, 2~3주 안에 끝낼 수 있는 작은 작업을 하나 완성하면 재료와 면접에서 할 말이 함께 남습니다. 무엇을 만들지는 공고의 업무 문장에서 고르세요.

설명을 위한 가상 예시예요. 마케팅 공고에 '콘텐츠 성과 분석'이 있다면 본인 계정이나 지인 가게 계정으로 4주 동안 게시 형식을 바꿔 가며 반응을 기록하고, 무엇을 바꿨을 때 어떤 반응이 있었는지 표로 남깁니다. 기획이면 자주 쓰는 서비스 하나를 골라 불편한 지점을 정리하고 개선안을 화면 설계까지 그려요. 규모가 작아도 판단 과정이 보이면 재료가 됩니다.

비전공이라는 사실을 문서에 따로 적을 필요는 없어요. 다만 직무와 관련된 전공 과목이나 교육 이력이 있다면 지우지 말고 해당 작업과 연결해 적으세요. 혼자 만든 작업은 사용자를 한 명이라도 붙이면 성격이 달라집니다. 친구 몇 명이 써 보고 남긴 반응과 그중 실제로 고친 지점 하나를 적으면 '다시 한다면' 줄이 자연스럽게 채워져요.

아래는 프리터뷰가 제안하는 제출 전 점검표예요. 낯선 사람에게 첫 화면만 보여 주고 무슨 일을 하는 사람인지 물어 보는 항목부터 시작합니다.

• 첫 화면만 보고 지원 직무를 맞힐 수 있는가
• 작업마다 문제·역할·판단 이유·결과가 빠짐없이 적혀 있는가
• 저장소, 문서, 영상 링크가 로그인 없이 열리고 만료되지 않았는가
• 팀 작업에서 내 담당 범위가 표시돼 있는가
• 숫자는 전부 확인한 사실이고, 가린 데이터는 가렸다고 밝혔는가
• 그 직무의 기본 용어와 도구 이름을 정확하게 썼는가
• 소리 내어 설명했을 때 목표 시간 안에 끝나는가

혼자 보면 빈 곳이 잘 안 보여요. 프리터뷰의 포트폴리오 점검은 올린 문서에서 설명이 비어 있는 자리를 짚어 주고, 이력서와 포트폴리오 문장을 바탕으로 한 모의면접과 면접 후 피드백도 함께 제공합니다. 이용 조건은 요금·이용 조건에서, 결과물 형태는 예시 리포트에서 확인하세요. 사람에게 첨삭받는 경로와 반영 순서는 포트폴리오 첨삭·피드백 받는 법에 있어요.