샘플 프로젝트 템플릿 (PAR 구조)

아래 템플릿을 복사해 프로젝트별로 채워 넣으세요. 핵심은 “문제 → 해결 → 성과” 흐름과 검증 가능한 지표입니다.

1. 프로젝트 개요

  • 프로젝트명: Example Project
  • 기간: 2024.03 ~ 2024.06 (12주)
  • 역할: FE 리드 / 백엔드 협업 / PM 보조
  • 기술: React, Next.js, Node.js, PostgreSQL, AWS

2. 문제(Problem)

  • 어떤 문제를 해결하려 했나요?
  • 대상 사용자/비즈니스 임팩트는 무엇이었나요?

예) 가입 전환율이 28%에서 정체. 모바일에서 이탈이 높았음.

3. 해결(Action)

  • 해결 전략과 설계(아키텍처, 데이터 모델, 실험 설계)
  • 구체적 구현(컴포넌트/엔드포인트/배포/모니터링)
  • 협업/의사결정(이슈/PR, 코드리뷰, 실험 계획)

예) 폼 단계를 3→2로 축소, 서버 액션 도입으로 TTFB 40% 감소, A/B 테스트 2주 운영.

4. 성과(Result)

  • 핵심 지표와 변화율(전/후 비교)
  • 사용자/매출/효율 등 정량 성과

예) 전환율 28% → 41%(+13%p), 모바일 이탈 -22%, 연간 추정 매출 +1.2억.

5. 지표/측정(Metrics)

  • 추적 지표: 전환율, 로드타임, MAU, CAC/LTV 등
  • 측정 도구: GA4, Amplitude, Datadog, Sentry, Lighthouse 등

6. 링크/증빙(Links)

7. 회고(Retrospective)

  • 잘한 점 / 아쉬운 점
  • 다음 개선 아이디어
  • 배운 점(기술, 협업, 비즈니스)
힌트: 각 섹션에 스크린샷, 그래프, before/after 비교 이미지를 넣으면 신뢰도와 전달력이 크게 향상됩니다.

심화: 포트폴리오 제출 형식과 분량

내용이 좋아도 열리지 않거나, 너무 길거나, 핵심을 찾기 어려우면 끝까지 읽히지 않습니다. 제출 전에 형식과 분량을 점검하세요.

1. 형식 고르기

형식장점주의할 점
PDF어디서나 같은 모양으로 열림, 첨부 제출에 적합파일 크기, 링크 클릭 가능 여부
웹 페이지 (노션, 개인 사이트)업데이트가 쉽고 영상·인터랙션을 보여 줄 수 있음공개 범위 설정, 링크가 오래 유지되는지
GitHub개발자에게 익숙, 코드와 문서를 함께 보여 줌README가 정리되지 않으면 오히려 감점

공고에 형식 안내가 있다면 그대로 따르고, 없다면 PDF 한 부 + 웹 링크를 함께 준비하는 것이 가장 안전합니다.

2. 분량

  • 프로젝트 수: 3~5개가 적당합니다. 많을수록 좋은 것이 아니라, 공고와 관련된 프로젝트를 골라 깊게 보여 주는 것이 좋습니다.
  • PDF 페이지 수: 전체 15~25쪽 안팎을 기준으로, 프로젝트 하나에 3~6쪽 정도가 읽기 편합니다.
  • 첫 페이지: 이름, 직무, 연락처, 그리고 대표 프로젝트 요약을 한 페이지에 담으세요. 첫 페이지만 보고도 어떤 사람인지 알 수 있어야 합니다.
  • 순서: 지원 직무와 가장 관련 있는 프로젝트를 맨 앞에 두세요. 시간 순서일 필요는 없습니다.

3. 파일 관리

  • 파일 크기: 이메일 첨부나 지원 시스템에는 용량 제한이 있는 경우가 많습니다. 이미지 해상도를 조정해 수십 MB가 넘지 않게 하세요.
  • 파일 이름: 홍길동_UX디자이너_포트폴리오.pdf
  • 링크 점검: PDF 안의 링크가 클릭되는지, 로그인 없이 열리는지 다른 기기에서 확인하세요.
  • 버전 관리: 지원하는 회사마다 프로젝트 순서를 바꿨다면, 어떤 버전을 어디에 냈는지 기록해 두세요.

보안과 저작권 점검

회사 업무나 고객 프로젝트를 포트폴리오에 넣을 때는 특히 주의해야 합니다.

  1. 공개해도 되는지 확인: 회사의 보안 규정이나 계약서에 비밀 유지 조항이 있는지 확인하세요. 애매하면 이전 회사에 공개 가능 여부를 문의하는 것이 안전합니다.
  2. 민감 정보 가리기: 고객 이름, 매출 수치, 내부 시스템 화면, 미공개 기능은 가리거나 가상 데이터로 바꾸세요.
  3. "재구성" 표시하기: 화면이나 데이터를 바꿨다면 "보안을 위해 일부 내용을 재구성했습니다"라고 밝혀 두세요.
  4. 내 기여 범위 밝히기: 팀 작업물이라면 내가 맡은 부분을 분명히 적으세요. 다른 사람의 작업을 내 것처럼 보이게 하면 면접에서 바로 드러나고, 신뢰를 잃습니다.
  5. 외부 자료 출처: 사용한 이미지, 폰트, 아이콘의 라이선스를 확인하고 필요하면 출처를 적으세요.

제출 전 마지막 점검표

  1. 첫 페이지만 봐도 직무와 대표 프로젝트를 알 수 있는가?
  2. 프로젝트마다 문제 → 행동 → 결과 → 회고가 들어 있는가?
  3. 지원 공고와 가장 관련 있는 프로젝트가 앞에 있는가?
  4. 모든 링크가 로그인 없이 열리는가?
  5. 민감 정보가 가려져 있고, 재구성 여부를 밝혔는가?
  6. 오탈자, 다른 회사 이름이 남아 있지 않은가?
  7. 파일 크기와 이름이 제출 조건에 맞는가?

직무별 예시는 개발자, 디자이너, PM 포트폴리오 템플릿에서 확인할 수 있습니다.

포트폴리오 공통 실전 적용 키트

실제 준비 과정에서 자주 쓰는 적용 시나리오

상황: 경력 3년차 제품팀 지원자

문제: 포트폴리오가 작업물 스크린샷 중심이라 문제 정의와 성과 연결이 약해 면접 전환이 낮은 상태였습니다.

실행: 각 프로젝트를 Problem-Action-Result 구조로 재정리하고, 성과 지표와 본인 기여 범위를 문서 첫 화면에 명시했습니다.

결과: 포트폴리오 검토 피드백에서 전달력 점수가 개선됐고, 서류 통과 후 과제/면접 전환율이 눈에 띄게 상승했습니다.

제출 전 실행 체크리스트

  • 프로젝트마다 문제-행동-성과 흐름이 한눈에 보이는가
  • 본인 기여 범위(역할/책임/협업 범위)를 명확히 분리했는가
  • 정량 지표 또는 전후 비교 근거를 최소 1개 이상 제시했는가
  • 의사결정 이유와 대안 비교를 서술했는가
  • 캡처 이미지에 맥락 설명 캡션을 붙였는가
  • 링크(저장소/프로토타입/문서)가 실제로 열리는지 검증했는가

자주 묻는 질문

Q. 포트폴리오는 몇 개 프로젝트가 적당한가요?

A. 직무에 맞는 2~4개를 깊게 보여주는 편이 많은 프로젝트를 얕게 나열하는 것보다 효과적입니다.

Q. 성과 수치가 없으면 어떻게 보완하나요?

A. 전/후 비교, 사용자 반응, 운영 효율 변화 등 검증 가능한 관찰치를 근거로 제시하세요.

Q. 비공개 프로젝트는 어떻게 공개하나요?

A. 민감 정보를 제거한 요약본, 흐름 다이어그램, 본인 기여와 결과 중심 설명으로 대체할 수 있습니다.