1. 포트폴리오는 “작품집”이 아니라 “채용 증거 문서”다
신입 개발자 포트폴리오의 목적은 나를 길게 소개하는 것이 아니다. 채용 담당자가 3분 안에 “이 사람이 우리 직무에서 일할 수 있을까?”를 판단하게 하는 증거 모음이어야 한다.
예를 들어 “저는 React를 할 줄 압니다”보다 아래 문장이 더 강하다.
React로 상태 관리, API 연동, 라우팅, 로그인 권한 분기까지 직접 구현했습니다.
| 나쁜 포트폴리오 | 좋은 포트폴리오 |
|---|---|
| 기능을 많이 나열한다 | 문제 해결 과정을 보여준다 |
| 기술 스택을 아이콘으로만 보여준다 | 왜 썼고 어디까지 직접 했는지 쓴다 |
| 팀 프로젝트라고만 쓴다 | 내 담당 범위와 PR/커밋 링크를 건다 |
| 예쁜 화면만 보여준다 | 코드, 배포, README, 회고까지 연결한다 |
2. 첫 화면에 반드시 보여줄 5가지
포트폴리오 첫 화면에서 채용자가 10초 안에 “어떤 개발자인지” 알아야 한다.
첫 화면에는 아래 5가지를 바로 보여줘야 한다.
| 항목 | 예시 |
|---|---|
| 이름/지원 직무 | 신입 백엔드 개발자 김OO |
| 한 줄 소개 | Spring Boot 기반 API 설계와 배포 경험이 있는 신입 개발자 |
| 핵심 기술 | Java, Spring Boot, MySQL, JPA, AWS |
| 대표 프로젝트 | 주문 관리 API, 스터디 매칭 서비스 |
| 링크 | GitHub, 배포 URL, 이메일, 이력서 PDF |
3. 프로젝트는 2~3개만 고르고 깊게 써라
신입 포트폴리오에서 프로젝트를 6개, 7개씩 넣는 것은 오히려 불리할 수 있다. 채용자는 모든 프로젝트를 자세히 보지 않는다. 지원 직무와 가장 가까운 대표 프로젝트 2~3개를 깊게 설명하는 편이 낫다.
| 프로젝트 유형 | 넣어도 되는 경우 | 빼야 하는 경우 |
|---|---|---|
| 클론코딩 | 기능을 직접 확장했거나 구조를 바꿨다 | 강의 그대로 따라 했다 |
| 팀 프로젝트 | 내 역할, PR, 이슈 기록이 있다 | 기여도가 불명확하다 |
| 졸업작품 | 배포, 사용자 흐름, 문제 해결이 있다 | 시연 화면만 있다 |
| 개인 프로젝트 | 기획부터 배포까지 설명 가능하다 | CRUD만 있고 차별점이 없다 |
4. 프로젝트 설명 공식: 문제 → 역할 → 구현 → 해결 → 결과
프로젝트마다 같은 구조로 쓰면 읽는 사람이 빠르게 비교할 수 있다.
``markdown`
이 프로젝트는 [누구의 어떤 문제]를 해결하기 위해 만들었습니다.
저는 [내 역할]을 맡아 [핵심 기능]을 구현했습니다.
사용 기술은 [기술명]이며, [선택 이유] 때문에 사용했습니다.
구현 중 [문제]가 있었고, [해결 방법]으로 개선했습니다.
결과적으로 [배포/기능 완성/성능 개선/사용자 흐름 개선]을 만들었습니다.
Before/After 예시는 이렇게 바꿔라.
| 나쁜 설명 | 좋은 설명 |
|---|---|
| 로그인 기능 구현 | JWT 기반 로그인과 권한 분기를 구현했습니다. 만료 토큰 처리 문제를 인터셉터에서 공통 처리하도록 수정했습니다. |
| 게시판 CRUD 구현 | 게시글 작성, 수정, 삭제 API를 만들고, 중복 로직을 서비스 계층으로 분리해 유지보수성을 개선했습니다. |
| 팀 프로젝트 참여 | 결제 내역 조회 API와 관리자 페이지 연동을 담당했고, 관련 PR 4개와 이슈 3개를 링크로 정리했습니다. |
5. 기술 스택은 “왜 썼는지”까지 써라
기술 스택을 아이콘으로만 나열하면 실력이 보이지 않는다. 아래처럼 직접 다룬 범위를 써야 한다.
| 기술 | 나쁜 예 | 좋은 예 |
|---|---|---|
| React | React 사용 | 컴포넌트 분리, 상태 관리, API 연동, 라우팅 구현 |
| Spring Boot | Spring Boot 사용 | REST API 설계, 예외 처리, JPA 연관관계 매핑 구현 |
| MySQL | DB 사용 | 테이블 설계, 인덱스 검토, 쿼리 개선 경험 |
| AWS | AWS 사용 | EC2 배포, RDS 연결, 환경변수 분리 |
6. README는 채용자가 보는 두 번째 포트폴리오다
GitHub 링크를 걸었다면 README가 정리되어 있어야 한다. 최소한 아래 구조는 포함하자.
`markdown
프로젝트명
1. 프로젝트 소개
누구의 어떤 문제를 해결하는 서비스인지 설명
2. 주요 기능
- 로그인/회원가입
- 게시글 작성
- 관리자 기능
3. 기술 스택
기술명 + 선택 이유 + 직접 구현한 범위
4. 실행 방법
설치, 환경변수, 실행 명령어
5. 폴더 구조
주요 디렉터리 역할 설명
6. 트러블슈팅
문제 상황, 원인, 해결 방법
7. 링크
배포 URL, 시연 영상, 회고, 주요 PR
``
7. 직무별로 앞에 둘 프로젝트가 다르다
| 지원 직무 | 앞에 둘 프로젝트 |
|---|---|
| 프론트엔드 | 사용자 흐름, 상태 관리, 반응형 UI, API 연동이 잘 보이는 프로젝트 |
| 백엔드 | API 설계, DB 모델링, 인증/인가, 배포 경험이 있는 프로젝트 |
| 풀스택 | 기획부터 프론트, 백엔드, 배포까지 연결된 프로젝트 |
| 데이터 | 데이터 수집, 전처리, 분석 결과, 시각화가 명확한 프로젝트 |
| 앱 개발 | 화면 흐름, 네이티브 기능, API 연동, 배포 테스트 경험이 있는 프로젝트 |
8. 프로젝트가 약하다면 새로 만들기보다 보강하라
기존 프로젝트가 평범해도 아래 중 2~3개를 추가하면 설득력이 올라간다.
| 보완 방법 | 포트폴리오에 쓸 수 있는 문장 |
|---|---|
| 기능 추가 | 검색, 필터, 권한 분기 기능을 추가했습니다. |
| 리팩토링 | 중복 코드를 공통 함수로 분리했습니다. |
| 테스트 | 주요 서비스 로직에 단위 테스트를 추가했습니다. |
| 성능 개선 | 불필요한 API 호출을 줄이고 로딩 상태를 개선했습니다. |
| 배포 자동화 | GitHub Actions로 배포 과정을 자동화했습니다. |
9. 팀 프로젝트는 기여도를 증명해야 한다
“5명이 함께 만들었습니다”만 쓰면 내 실력이 보이지 않는다. 아래 자료를 링크로 남겨라.
- 내가 만든 화면 캡처
- 내가 작성한 PR 링크
- 내가 맡은 이슈 링크
- 주요 커밋 링크
- 회고 글
- 담당 기능 설명
문장은 이렇게 쓰면 된다.
팀 프로젝트에서 주문 내역 조회 API와 관리자 주문 상태 변경 기능을 담당했습니다. 관련 이슈, PR, 테스트 결과를 README에 연결해 제 작업 범위를 확인할 수 있게 정리했습니다.
10. 1주 완성 로드맵
| 날짜 | 할 일 |
|---|---|
| 1일차 | 지원 직무를 정하고 채용공고 3개에서 요구 기술을 뽑는다 |
| 2일차 | 대표 프로젝트 2~3개를 고르고 나머지는 제거한다 |
| 3일차 | 각 프로젝트를 문제 → 역할 → 구현 → 해결 → 결과 구조로 다시 쓴다 |
| 4일차 | README에 실행 방법, 폴더 구조, 트러블슈팅을 추가한다 |
| 5일차 | GitHub, 배포 URL, 회고, 이력서 PDF 링크를 연결한다 |
| 6일차 | 첫 화면을 이름, 직무, 핵심 기술, 대표 프로젝트 중심으로 정리한다 |
| 7일차 | 공고 요구사항과 포트폴리오 내용이 맞는지 점검한다 |
