기업 규모만으로 개발자 포트폴리오의 정답이 달라지는 것은 아닙니다. 지원하는 회사의 실제 공고와 직무 업무에 맞춰 보여줄 증거를 고르는 것이 먼저입니다. 특정 대기업이 같은 평가표를 쓴다고 가정하지 마세요.
포트폴리오 작성 7단계
- 공고 읽기: 담당 업무와 필수·우대 조건을 분리하고 반복되는 기술보다 해결할 문제를 적습니다.
- 프로젝트 선택: 공고의 업무와 연결되는 결과물 두세 개만 앞에 둡니다. 다른 분야의 작품을 무조건 삭제할 필요는 없습니다.
- 개인 역할 표시: 팀 전체 기능과 본인의 설계·구현·테스트 범위를 구분합니다.
- 문제와 대안: 어떤 선택지가 있었고 왜 현재 방식으로 결정했는지 적습니다.
- 검증 결과: 정상 입력과 실패 입력, 테스트와 성능 측정 범위를 명시합니다. 근거 없는 수치 개선 주장은 쓰지 않습니다.
- 재현 안내: 저장소 링크, 설치와 실행 명령, 필요한 환경 변수 이름을 적습니다. GitHub README 안내가 기본 구조를 잡는 데 도움이 됩니다.
- 한계와 다음 단계: 미완성 기능과 다시 만든다면 바꿀 점을 숨기지 않습니다.
제출 전 점검
지원서에 적은 프로젝트 링크가 열리는지, 다른 기기에서 실행 설명이 통하는지 확인합니다. 면접에서 코드의 중요한 부분과 리뷰받은 변경을 설명할 수 있어야 합니다. 풀 리퀘스트 안내처럼 변경 이유와 검토 과정을 남기면 협업 경험을 구체화할 수 있습니다.
공고 분석을 처음 시작한다면 기술 스택 선택 가이드에서 목표 직무를 먼저 정하세요.