좋은 포트폴리오는 예쁘게 꾸민 페이지가 아니라
지원자의 역할과 성과를 빠르게 검증할 수 있는 문서입니다
노션으로 포트폴리오를 만들 때 가장 흔한 실수는 아이콘, 커버 이미지, 색상과 레이아웃부터 고민하는 것입니다. 하지만 채용 담당자나 실무자가 실제로 확인하려는 것은 어떤 문제를 맡았고, 본인이 무엇을 했으며, 결과가 어떻게 달라졌는지입니다.
제작 순서는 지원 직무 정의 → 핵심 역량 선정 → 프로젝트 선별 → 프로젝트별 문제·역할·과정·성과 정리 → 첫 화면 요약 → 탐색 구조 설계 → 시각자료 배치 → 공개 범위 점검 → 모바일·비로그인 환경 검수 → 지원처별 수정으로 가져가는 것이 효율적입니다.
🧭 정보구조 📁 프로젝트 📊 성과 🔐 공개검수포트폴리오 제작 전 목적과 직무 설정
노션 포트폴리오를 만들기 전에 가장 먼저 결정해야 할 것은 디자인이 아니라 누구에게 무엇을 보여줄 것인지입니다. 같은 프로젝트라도 개발자, 마케터, 기획자, 디자이너, 데이터 직무가 강조해야 하는 부분은 달라집니다.
예를 들어 하나의 서비스 출시 프로젝트에 참여했더라도 기획자는 요구사항과 의사결정 과정, 개발자는 구현과 기술적 문제 해결, 마케터는 고객 세분화와 성과 지표를 중심으로 설명하는 편이 자연스럽습니다. 따라서 프로젝트를 정리하기 전에 지원 직무의 핵심 역량을 먼저 적어보는 것이 좋습니다.
경험을 많이 넣는 것보다 선별하는 것이 중요합니다
처음 포트폴리오를 만들면 참여했던 프로젝트를 모두 넣고 싶어집니다. 하지만 비슷한 역량을 보여주는 프로젝트가 반복되면 페이지는 길어져도 지원자를 이해하는 데 필요한 새로운 정보는 늘어나지 않을 수 있습니다.
프로젝트를 고를 때는 규모보다 지원 직무와의 관련성을 먼저 봅니다. 작은 개인 프로젝트라도 문제를 어떻게 정의했고 어떤 판단을 내렸으며 결과를 어떻게 검증했는지가 명확하다면 단순 참여 경험보다 설명력이 높을 수 있습니다.
팀 성과와 개인 기여를 분리합니다
팀 프로젝트에서 가장 중요한 실무 체크 항목 중 하나입니다. 프로젝트 전체 성과를 설명하는 것과 본인이 직접 담당한 업무를 설명하는 것은 구분되어야 합니다.
예를 들어 서비스 전환율이 개선되었다면 전체 프로젝트 결과라고 표시하고, 자신이 담당한 사용자 조사나 화면 개선, 데이터 분석이 그 과정에서 어떤 역할을 했는지 별도로 적습니다. 이 구분이 명확할수록 면접에서 구체적인 후속 질문에도 대응하기 쉽습니다.
□ 해당 직무에서 보여줄 핵심 역량을 정했는가
□ 경험을 직무 관련성에 따라 선별했는가
□ 대표 프로젝트를 우선 배치했는가
□ 프로젝트별 본인 역할을 설명할 수 있는가
□ 팀 성과와 개인 기여를 구별했는가
□ 공개할 수 없는 회사 자료를 제외했는가
□ 포트폴리오를 한 문장으로 설명할 수 있는가
💡 선별 기준: 프로젝트가 많다면 '가장 힘들었던 프로젝트'보다 '지원 직무에 필요한 역량을 가장 명확하게 증명할 수 있는 프로젝트'를 먼저 배치합니다.
첫 화면과 전체 정보구조 설계
포트폴리오의 첫 화면은 모든 내용을 설명하는 장소가 아니라 방문자가 다음에 무엇을 볼지 결정하도록 돕는 화면입니다. 이름만 크게 적고 긴 자기소개를 이어가기보다 직무, 핵심 역량, 대표 프로젝트와 연락 방법을 빠르게 파악할 수 있도록 구성합니다.
첫 화면에는 판단에 필요한 정보부터 배치합니다
첫 화면에서 자신의 경력을 모두 설명하려 하면 정보가 지나치게 많아집니다. 간단한 소개 문장과 주요 역량, 대표 작업으로 이동할 수 있는 구조를 만들고 세부 내용은 프로젝트 페이지에서 보여주는 방식이 읽기 쉽습니다.
핵심 역량 → 직무와 직접 연결되는 능력 중심
대표 프로젝트 → 우선 확인할 작업을 상단 배치
경력·활동 → 필요한 경우 세부 페이지로 연결
연락 → 이메일 등 실제 확인 가능한 수단
외부 자료 → 코드·디자인·문서 등 필요한 자료만 연결
페이지 깊이를 지나치게 늘리지 않습니다
하위 페이지를 여러 단계로 만들면 구조는 정돈되어 보일 수 있지만 방문자는 필요한 정보를 찾기 위해 계속 이동해야 합니다. 첫 화면에서 대표 프로젝트로 바로 이동하고 프로젝트 안에서 핵심 내용을 확인할 수 있도록 탐색 단계를 줄이는 편이 좋습니다.
정보를 숨기기 위해 토글을 과도하게 사용하는 것도 주의합니다. 보조 설명이나 세부 기록은 접어둘 수 있지만 본인의 역할, 문제, 해결 과정, 성과처럼 평가에 필요한 핵심 정보까지 모두 숨기면 페이지를 펼쳐보지 않고 지나갈 가능성이 있습니다.
디자인 규칙을 먼저 정하고 반복합니다
노션 포트폴리오에서 디자인 완성도는 화려한 장식보다 일관성에서 나옵니다. 제목 크기, 프로젝트 이미지 비율, 구분선 사용, 강조색과 프로젝트 소개 순서를 일정하게 맞추면 내용이 많은 페이지도 안정적으로 보입니다.
⚠️ 꾸미기 과잉: 커버 이미지와 아이콘을 많이 사용하는 것이 전문성을 자동으로 높이지는 않습니다. 시각 요소 때문에 프로젝트명, 역할, 성과가 뒤로 밀린다면 장식을 줄이는 편이 좋습니다.
프로젝트 페이지 실무형 작성법
프로젝트 페이지는 결과물 전시장이 아니라 업무 수행 과정을 검증할 수 있는 사례 문서에 가깝게 작성합니다. 완성 화면만 여러 장 보여주면 무엇을 만들었는지는 알 수 있지만 지원자가 어떤 판단을 했는지는 파악하기 어렵습니다.
프로젝트 첫 부분에서 전체 맥락을 압축합니다
상세 내용을 읽기 전에 어떤 프로젝트인지 파악할 수 있도록 기간, 목표, 팀 구성, 담당 역할과 사용한 도구 등을 간결하게 정리합니다. 여기에서 가장 중요한 것은 사용한 도구의 개수가 아니라 프로젝트 안에서 본인이 맡은 책임 범위입니다.
과정보다 문제 해결 논리를 보여줍니다
'회의를 했다 → 조사했다 → 제작했다'처럼 시간순으로만 작성하면 업무일지에 가까워집니다. 포트폴리오에서는 어떤 문제가 있었고 무엇을 근거로 판단했으며 여러 선택지 중 왜 그 방법을 사용했는지를 보여주는 것이 중요합니다.
실제 사례처럼 대입해 보면 '사용자가 불편해했다'보다 '특정 단계에서 이탈이 반복되어 원인을 확인했고, 관찰 결과와 데이터를 바탕으로 절차를 단순화했다'는 구조가 더 많은 정보를 전달합니다. 사실과 근거가 있는 범위 안에서 문제와 행동의 연결을 보여주는 방식입니다.
성과는 숫자가 있을 때만 좋은 것이 아닙니다
매출이나 전환율처럼 명확한 수치를 확보할 수 있다면 측정 기준과 기간을 함께 제시하는 것이 좋습니다. 하지만 학생 프로젝트나 내부 업무처럼 정량 성과를 확보하기 어려운데도 임의의 수치를 만들어서는 안 됩니다.
정량 지표가 없다면 완료한 기능, 해결한 문제, 업무시간 감소 여부, 사용자 피드백, 프로세스 개선, 검증 결과 등 실제 확인 가능한 변화로 설명합니다. 성과를 크게 보이게 만드는 것보다 질문을 받았을 때 근거를 설명할 수 있는지가 중요합니다.
| 항목 | 좋은 작성 방향 | 주의할 표현 |
|---|---|---|
| 문제 | 구체적인 상황과 근거 | 막연한 불편함 |
| 역할 | 직접 담당한 범위 | 팀 성과를 개인 성과처럼 표현 |
| 과정 | 판단 근거와 선택 이유 | 단순 작업 나열 |
| 성과 | 측정 가능한 변화와 근거 | 근거 없는 과장 |
| 회고 | 한계와 다음 개선안 | 형식적인 소감 |
📌 프로젝트 압축법: 상세 페이지를 작성하기 전에 '문제는 무엇이었나 → 나는 무엇을 맡았나 → 왜 그렇게 판단했나 → 무엇을 실행했나 → 무엇이 달라졌나'에 각각 한두 문장으로 먼저 답해봅니다.
데이터베이스·시각자료·링크 활용
프로젝트가 여러 개라면 데이터베이스 형태로 정리하면 직무, 분야, 사용 기술, 기간 등의 속성을 기준으로 경험을 관리하기 편합니다. 다만 내부 관리에 유용한 구조와 외부 방문자가 읽기 쉬운 구조가 반드시 같지는 않습니다.
데이터베이스는 관리 도구로 먼저 생각합니다
모든 속성을 방문자에게 노출하면 프로젝트 카드가 복잡해질 수 있습니다. 내부에서는 직무, 기간, 상태, 기술, 공개 여부처럼 다양한 속성을 관리하더라도 외부 포트폴리오에서는 프로젝트를 이해하는 데 필요한 정보만 보여주는 편이 좋습니다.
지원 분야가 여러 개라면 같은 경험 데이터에서 보여주는 프로젝트의 우선순위를 달리하는 방식도 생각할 수 있습니다. 중요한 것은 데이터베이스 기능 자체를 많이 사용하는 것이 아니라 방문자가 관련 프로젝트를 빠르게 발견하도록 만드는 것입니다.
이미지는 증거와 이해를 돕는 용도로 사용합니다
화면 캡처를 많이 넣으면 포트폴리오가 풍성해 보이지만 작은 글자가 가득한 이미지는 모바일에서 거의 읽히지 않을 수 있습니다. 한 이미지가 어떤 내용을 설명하는지 먼저 정하고 필요한 부분을 잘라 사용합니다.
그래프나 대시보드를 넣는 경우에도 이미지 자체보다 무엇을 발견했고 그 결과 어떤 판단을 했는지를 짧게 설명합니다. 디자인 결과물 역시 완성 화면만 나열하기보다 핵심 변화가 무엇인지 캡션을 붙이면 이해가 쉬워집니다.
외부 링크는 클릭한 이후까지 확인합니다
코드 저장소, 디자인 결과물, 영상, 문서 등의 외부 링크를 연결했다면 링크가 존재하는지만 확인해서는 부족합니다. 로그인 없이 열리는지, 권한 요청 화면이 나타나지 않는지, 파일이 삭제되지 않았는지 실제 방문자 환경에서 확인해야 합니다.
□ 대표 프로젝트가 첫 화면에서 바로 보이는가
□ 이미지가 내용을 실제로 설명하고 있는가
□ 작은 글자가 포함된 이미지에 설명을 추가했는가
□ 외부 링크가 정상적으로 열리는가
□ 링크된 자료의 공개 권한이 적절한가
□ 삭제하거나 이동한 페이지로 연결되지 않는가
□ 모바일에서도 프로젝트 순서가 자연스러운가
🔐 실무 자료 주의: 재직 중 제작한 프로젝트를 공개할 때는 고객 정보, 내부 지표, 계약 내용, 관리자 화면, 개인정보, 비공개 전략과 회사가 외부 공개를 허용하지 않은 자료가 포함되지 않았는지 먼저 확인해야 합니다.
직무별 실무 응용과 차별화 전략
노션 포트폴리오의 장점은 같은 기본 구조를 유지하면서도 지원 직무에 따라 강조점을 바꾸기 쉽다는 것입니다. 반대로 모든 직무에 동일한 페이지를 제출하면 프로젝트는 많아도 지원 직무와 어떤 관련이 있는지 방문자가 직접 해석해야 하는 문제가 생깁니다.
기획 직무는 의사결정 과정을 보여줍니다
서비스·제품 기획 포트폴리오에서는 결과 화면만큼 문제 정의와 요구사항 정리, 우선순위 결정, 협업 과정이 중요합니다. 무엇을 만들었는지만 설명하면 디자인 결과물과 구별하기 어렵습니다.
사용자 요구와 사업 조건이 충돌했을 때 어떤 기준으로 우선순위를 정했는지, 개발이나 디자인과 협업하면서 요구사항이 어떻게 변경되었는지 등을 사실에 근거해 정리하면 실무적인 판단 과정을 보여주기 좋습니다.
마케팅 직무는 목표와 지표를 연결합니다
마케팅 프로젝트에서는 캠페인 이미지만 보여주기보다 어떤 고객을 대상으로 어떤 목표를 세웠는지부터 설명합니다. 사용한 채널, 콘텐츠 전략, 실험 내용과 측정 가능한 결과가 있다면 서로 연결해서 보여줍니다.
성과 수치를 제시할 때는 숫자를 크게 만드는 것보다 기준을 명확하게 적는 것이 중요합니다. 이전 기간 대비인지, 특정 캠페인 기간의 결과인지, 팀 전체 성과인지 본인이 직접 담당한 영역의 성과인지 구별합니다.
개발 직무는 구현과 문제 해결을 연결합니다
개발 포트폴리오에서 사용 기술 목록을 길게 적는 것만으로는 실제 활용 수준을 판단하기 어렵습니다. 프로젝트에서 어떤 기능을 구현했고 어떤 기술적 문제가 있었으며 그것을 어떻게 해결했는지 설명하는 편이 좋습니다.
코드 저장소를 연결했다면 포트폴리오 본문에도 프로젝트 구조와 본인 기여를 요약합니다. 방문자가 외부 링크를 모두 열어봐야만 프로젝트를 이해할 수 있는 구조는 피하는 것이 좋습니다.
데이터 직무는 분석 질문과 결과 해석을 보여줍니다
분석 포트폴리오에서는 사용한 언어와 라이브러리보다 어떤 질문에서 분석을 시작했는지가 중요합니다. 데이터를 어떻게 정제했고 어떤 분석 방법을 선택했으며 결과가 실제 의사결정에 어떤 의미가 있는지를 연결합니다.
그래프를 많이 넣는 것보다 핵심 그래프를 선별하고 그 아래에 발견한 사실과 해석을 적는 편이 효과적입니다. 상관관계를 인과관계처럼 표현하거나 분석 결과보다 큰 결론을 주장하지 않는 것도 중요합니다.
신입은 경험의 크기보다 사고 과정을 보완합니다
경력이 없는 신입이 억지로 실무 경험처럼 보이게 작성할 필요는 없습니다. 개인 프로젝트, 교육 과정, 팀 과제, 동아리와 공모전 등에서도 문제를 스스로 정의하고 개선한 과정이 있다면 충분히 구조화할 수 있습니다.
| 직무 | 우선 보여줄 내용 | 보조 자료 |
|---|---|---|
| 기획 | 문제·요구사항·의사결정 | 기획서·흐름도·지표 |
| 마케팅 | 목표·타깃·실행·성과 | 콘텐츠·성과자료 |
| 개발 | 구현·기술 선택·문제 해결 | 코드·구조도·실행화면 |
| 데이터 | 분석 질문·방법·해석 | 그래프·분석 문서 |
| 디자인 | 문제·사용자·설계 판단 | 프로토타입·과정 이미지 |
🎯 지원처별 수정: 포트폴리오 전체를 매번 새로 만들기보다 대표 프로젝트의 순서, 첫 소개 문장, 강조할 역량을 채용공고와 직무에 맞게 조정하는 방식이 관리하기 편합니다.
공개 전 오류·보안·가독성 검수
포트폴리오를 완성한 뒤 가장 중요한 단계가 공개 상태 검수입니다. 제작자 계정에서는 모든 페이지와 파일이 정상적으로 보이기 때문에 권한 오류를 발견하지 못하는 경우가 있습니다.
로그인하지 않은 방문자 관점에서 다시 확인합니다
공유 링크를 만든 뒤 자신이 로그인한 브라우저에서만 확인하지 않습니다. 가능한 범위에서 비로그인 환경이나 다른 브라우저를 사용해 첫 페이지와 주요 하위 페이지, 이미지, 첨부자료, 외부 링크가 실제로 열리는지 확인합니다.
특히 상위 페이지는 공개되지만 중요한 하위 자료나 외부 문서의 권한이 제한되어 있는 경우를 점검합니다. 반대로 공개하지 않아야 할 페이지가 연결되어 있지는 않은지도 함께 확인해야 합니다.
개인정보는 필요한 만큼만 공개합니다
연락을 위한 이메일처럼 목적이 명확한 정보와 불필요한 개인정보는 구분합니다. 집 주소, 개인 전화번호, 신분증 정보처럼 포트폴리오 공개 목적에 필요하지 않은 민감한 정보는 공개 페이지에 넣지 않는 것이 좋습니다.
회사 프로젝트의 화면 캡처에도 고객명, 이메일 주소, 주문번호, 내부 관리자 정보 등이 숨어 있을 수 있습니다. 이미지 일부를 가리는 것만으로 충분한지 판단하기 어려운 자료라면 회사의 공개 정책을 먼저 확인하고 안전한 대체 자료를 사용하는 편이 낫습니다.
모바일 화면은 별도로 읽어봅니다
PC에서 보기 좋은 다단 구성이나 넓은 이미지는 작은 화면에서 읽는 순서가 달라질 수 있습니다. 스마트폰에서 첫 화면부터 대표 프로젝트까지 직접 스크롤하면서 제목과 이미지가 지나치게 길게 이어지지 않는지 확인합니다.
□ 대표 프로젝트 하위 페이지가 모두 열리는가
□ 외부 문서의 권한 요청이 발생하지 않는가
□ 삭제된 링크나 빈 이미지가 없는가
□ 이메일과 연락 수단에 오타가 없는가
□ 개인정보와 회사 비공개 정보가 없는가
□ 모바일에서 읽는 순서가 자연스러운가
□ 이미지 속 글자가 지나치게 작지 않은가
□ 팀 성과와 개인 역할이 구별되는가
□ 성과 수치에 설명 가능한 근거가 있는가
□ 맞춤법과 날짜·기간 표기가 일관적인가
□ 지원서에 제출할 링크를 마지막으로 다시 열어봤는가
⚠️ 마지막 수정 후 재검수: 페이지를 복제하거나 이동하고 프로젝트 구조를 변경하면 기존 링크와 공개 범위도 다시 확인하는 것이 좋습니다. 제출 직전에는 실제 제출할 주소를 직접 열어 최종 화면을 확인합니다.
노션 포트폴리오 자주 묻는 질문
제출 전 최종 체크리스트
| 영역 | 최종 확인 | 주의할 부분 |
|---|---|---|
| 첫 화면 | 직무·강점·대표 작업 | 긴 자기소개 |
| 프로젝트 | 문제·역할·판단·성과 | 작업 결과만 나열 |
| 근거 | 설명 가능한 수치·자료 | 과장된 성과 |
| 공개 | 비로그인 링크 확인 | 권한 오류·민감정보 |
| 제출 | 지원 직무별 우선순위 | 모든 지원처에 동일 구성 |
노션 포트폴리오를 처음 만들 때는 디자인부터 시작하지 말고 지원하려는 직무와 보여주고 싶은 역량을 먼저 정합니다. 프로젝트를 고르는 기준 역시 유명하거나 규모가 큰 경험보다 해당 역량을 구체적으로 증명할 수 있는지에 둡니다.
첫 화면에서는 방문자가 지원자의 직무와 대표 경험을 빠르게 이해할 수 있어야 합니다. 모든 경력과 프로젝트 설명을 첫 페이지에 길게 나열하기보다 대표 프로젝트로 자연스럽게 이동하도록 정보의 우선순위를 만듭니다.
프로젝트 페이지에서는 무엇을 만들었는가에서 끝나지 않고 왜 이 문제가 중요했는가 → 본인은 무엇을 맡았는가 → 어떤 근거로 판단했는가 → 무엇을 실행했는가 → 결과가 어떻게 달라졌는가의 순서로 설명합니다.
팀 프로젝트라면 전체 결과와 개인 기여를 반드시 구별합니다. 프로젝트의 성공을 모두 자신의 성과처럼 표현하기보다 팀 전체 결과를 설명한 뒤 본인이 직접 맡은 업무와 의사결정을 구체적으로 보여주는 것이 신뢰도를 높이는 데 도움이 됩니다.
성과를 정리할 때도 숫자가 많아야 좋은 포트폴리오라고 생각하지 않습니다. 실제로 측정한 수치가 있다면 기준과 기간을 함께 설명하고, 수치가 없다면 해결한 문제와 검증 결과, 사용자 반응, 프로세스 변화처럼 확인 가능한 사실을 사용합니다.
시각자료는 페이지를 꾸미기 위해 추가하기보다 설명을 보완하는 용도로 사용합니다. 화면 캡처, 그래프, 결과 이미지를 넣었다면 방문자가 이미지를 보고 무엇을 확인해야 하는지 한두 문장으로 설명해 두는 것이 좋습니다.
공개 전에는 내용 검토만큼 권한 검수가 중요합니다. 비로그인 환경에서 첫 페이지와 프로젝트가 열리는지 확인하고 외부 자료의 권한, 깨진 링크, 모바일 가독성, 연락처 오타와 불필요한 개인정보 노출을 차례로 점검합니다.
재직 중 수행한 프로젝트를 활용한다면 공개 가능 여부를 가장 먼저 확인합니다. 회사 내부 자료를 일부 가리기만 하면 된다고 임의로 판단하지 말고 외부 공개가 허용되는 범위 안에서 내용을 재구성하거나 공개 가능한 대체 이미지와 설명을 사용합니다.
실무 제작 순서를 압축하면 지원 직무 분석 → 핵심 역량 정의 → 경험 목록화 → 대표 프로젝트 선별 → 문제·역할·행동·결과 작성 → 첫 화면 구성 → 시각자료 정리 → 프로젝트 연결 → 공개 권한 설정 → 비로그인·모바일 검수 → 지원처별 우선순위 조정으로 정리할 수 있습니다.
결국 노션 포트폴리오 제작에서 가장 중요한 기준은 기능을 얼마나 많이 사용했는지가 아닙니다. 처음 방문한 사람이 짧은 탐색만으로도 어떤 일을 할 수 있는 사람인지 이해하고, 대표 프로젝트를 통해 그 주장을 검증할 수 있도록 만드는 것이 핵심입니다. 노션은 그 정보를 읽기 쉽게 연결하는 도구로 활용하는 것이 가장 실무적인 접근입니다.