포트폴리오에 프로젝트 개수가 많아도 각 프로젝트에서 무엇을 직접 결정했는지 보이지 않으면 평가하기 어렵습니다. 비전공자라면 학습 과정을 숨기기보다 문제를 이해하고 구현하고 검증한 흔적을 한 프로젝트에 모으세요.
첫 화면에 적을 네 가지
프로젝트 목적, 대상 사용자, 본인이 맡은 기능, 실제로 실행할 수 있는 링크 또는 명령을 먼저 적습니다. 팀 프로젝트라면 팀 전체 기능과 본인의 기여를 분리하세요. 화면 캡처가 있다면 설명을 돕는 용도로 쓰고 코드 저장소와 실행 방법을 빠뜨리지 않습니다.
결정 과정을 사례로 보여주기
예를 들어 검색 기능을 만들었다면 “검색 가능”보다 검색어가 비어 있을 때, 결과가 없을 때, 서버 오류가 날 때 각각 어떤 화면과 응답을 정했는지 설명합니다. 데이터 프로젝트라면 누락값 처리와 분석 가정을 적습니다. 결과가 예상과 달랐다면 데이터를 수정해 결론에 맞추는 대신 원인과 한계를 기록합니다.
재현 가능성 점검
GitHub의 README 자료를 참고해 설치, 실행, 테스트 명령을 정리합니다. 비밀 키는 저장소에 올리지 말고 필요한 환경 변수 이름만 예시로 제시하세요. 다른 사람이 README만 따라 해 실행할 수 있는지 확인합니다.
지원 공고에 맞게 순서 조정
백엔드 공고에는 API와 데이터·테스트의 설명을, 프론트엔드 공고에는 사용자 흐름과 접근성을 앞에 둡니다. 한 프로젝트를 억지로 모든 직무에 맞춘다고 주장하지 않습니다. 공고 분석 방법은 기술 스택 선택 가이드에서 이어서 확인하세요.