신입 개발자 포트폴리오 만드는 법: 프로젝트 선정, README, 배포, 깃허브 정리

프로젝트는 몇 개, 어떤 걸?

• 2~3개면 충분합니다. 작은 프로젝트 열 개보다 깊이 있는 프로젝트 두세 개가 훨씬 설득력 있습니다.
• 지원 직무와 맞춰야 합니다. 백엔드 지원자라면 API 설계, 데이터베이스, 인증, 성능 개선 같은 서버 쪽 고민이 드러나야 합니다. 프론트엔드라면 화면 상태 관리, 반응형, 접근성, 렌더링 성능 같은 부분이 보여야 합니다.
• 문제에서 출발한 프로젝트가 좋습니다. 내가 실제로 불편했던 것, 주변 사람이 쓰는 도구처럼 "왜 만들었는지"를 말할 수 있는 주제가 면접에서 이야기를 끌어내기 쉽습니다.
• 실제 사용자가 있으면 큰 강점입니다. 몇 명이라도 써 보고 피드백을 받아 고친 경험은 강의 따라 만든 결과물과 확실히 구분됩니다.

README가 첫인상입니다

1. 한 줄 소개: 무엇을 하는 서비스인지
2. 배포 주소와 화면: 바로 눌러 볼 수 있는 링크, 주요 화면 캡처나 짧은 시연 영상
3. 기술 스택과 선택 이유: 왜 이 기술을 썼는지 한두 문장
4. 핵심 기능: 3~5개로 요약
5. 구조: 시스템 구성도나 데이터베이스 설계 그림
6. 트러블슈팅: 겪은 문제, 원인, 해결 방법, 결과
7. 실행 방법: 다른 사람이 내려받아 돌려 볼 수 있는 순서

배포는 꼭 하세요

• 무료 또는 저렴한 호스팅·클라우드 서비스로도 충분히 배포할 수 있습니다.
• 서버를 계속 켜 두기 어렵다면 시연 영상을 README에 함께 올려 두세요.
• 지원 기간에는 링크가 살아 있는지 주기적으로 확인합니다. 깨진 링크는 오히려 감점 요인입니다.
• 비밀번호, API 키 같은 비밀 값이 저장소에 올라가지 않았는지 반드시 점검하세요. 한 번 커밋된 값은 기록에 남습니다.

깃허브 정리하기

• 대표 프로젝트를 프로필 상단에 고정합니다.
• 연습용, 미완성 저장소는 비공개로 돌리거나 정리합니다.
• 커밋 메시지가 "수정", "ㅇㅇ"처럼 의미 없는 것뿐이면 협업 습관이 의심받습니다. 무엇을 왜 바꿨는지 알 수 있게 쓰세요.
• 팀 프로젝트라면 내가 맡은 부분을 README에 분명히 적습니다.

흔한 실수

• 기술 이름만 잔뜩 나열하고 왜 썼는지 설명하지 못하는 것
• 팀 프로젝트 전체를 혼자 한 것처럼 쓰는 것
• 화면 캡처 없이 코드만 있는 저장소
• 포트폴리오 문서와 실제 저장소 내용이 다른 것

제출 전 마지막 점검

• 다른 사람에게 링크만 주고 5분 안에 무엇을 만든 프로젝트인지 이해하는지 물어보세요.
• 휴대폰으로도 배포 주소와 README가 잘 보이는지 확인합니다.
• 이력서, 포트폴리오 문서, 깃허브 저장소에 적힌 기간과 역할, 기술 스택이 서로 같은지 맞춰 봅니다.
• 오래된 프로젝트라면 의존성 경고나 깨진 화면이 없는지 다시 실행해 봅니다.