개발자 포트폴리오에 모든 회사가 공통으로 적용하는 ‘합격 기준’은 없습니다. 지원 직무와 경력 수준, 채용 공고의 업무가 다르기 때문입니다. 자신에게 필요한 기준은 공고의 요구사항을 추려 실제 프로젝트 증거에 연결하면서 만드세요.
공고에서 업무와 도구를 분리
‘React 경험’처럼 도구를 적은 항목과 ‘사용자 기능 구현·운영’처럼 업무를 적은 항목을 구분합니다. 기술 이름만 맞추는 대신 해당 기술로 어떤 문제를 해결했는지 보여 주세요. 공고에 없는 기술까지 억지로 끼워 넣으면 핵심 경험이 흐려집니다.
요구사항마다 근거 하나 연결
표의 왼쪽에는 공고 문구, 오른쪽에는 저장소 파일·배포 화면·테스트·설계 문서의 링크를 적습니다. 근거가 없는 항목은 ‘경험 있음’이라고 쓰지 말고 학습 중인 범위로 표시하세요. 팀 프로젝트라면 내 코드와 결정의 범위를 분명히 합니다.
검증 가능한 문장으로 바꾸기
‘성능 향상’은 무엇을 어떻게 측정했는지가 없으면 평가하기 어렵습니다. ‘목록 페이지의 이미지 크기를 조정했다’처럼 실제 작업을 적고, 비교 데이터를 보유했다면 측정 환경을 함께 제시하세요. 장애 해결이나 오류 수정도 재현·원인·수정·확인 순서로 기록합니다.
읽는 사람의 동선을 점검
첫 화면에서 대표 프로젝트에 도달하고, README에서 실행 방법과 제약을 찾을 수 있어야 합니다. GitHub README 안내를 참고해 저장소 구조를 정리하세요. 직무별 대표 프로젝트 선택은 포트폴리오 구성 가이드에서 이어집니다.
마지막으로 다른 사람에게 문서만 전달해 어떤 역할과 기술을 이해했는지 물어보세요. 설명과 실제 코드가 일치하는지 직접 검증하는 과정이 가장 중요합니다.