포트폴리오 교육이 “최신” 기술을 사용한다고 해서 지원서의 설득력이 자동으로 높아지지는 않습니다. 교육 과정에서 본인이 해결한 문제와 이를 검증한 기록을 남길 수 있는지 확인해야 합니다.
과정표에서 볼 항목
프로젝트 주제를 누가 정하는지, 팀 작업에서 개인 역할을 구분하는지, 멘토가 디자인만 보는지 실제 코드와 테스트를 검토하는지 확인합니다. 결과물을 멋진 사진으로 만들더라도 실행 방법이 없으면 기술 면접에서 설명하기 어렵습니다.
피드백의 깊이
“코드가 돌아간다”라는 평가보다 오류 입력, 권한, 데이터 규칙을 검토하는 피드백이 필요합니다. 백엔드라면 API와 테스트, 프론트엔드라면 접근성과 로딩·오류 화면, 데이터 분석이라면 정제와 해석의 한계를 각각 점검해야 합니다. GitHub 풀 리퀘스트 같은 변경 검토 과정을 수업에서 쓰는지 물어보세요.
수료 후 소유와 실행
저장소 접근 권한과 배포 계정, 사용한 이미지·코드의 라이선스, 교육 종료 후 수정 가능 여부를 확인합니다. README 공식 안내를 기준으로 새 기기에서 설치와 실행이 가능한지 시험해 보세요. 저작권이나 계약의 구체적 조건은 과정 계약서를 확인해야 합니다.
교육을 받아도 설명하지 못하는 기능을 많이 넣기보다 한 기능의 결정 과정을 깊게 기록하세요. 다른 사례를 참고하는 법은 포트폴리오 사례 분석법에서 확인할 수 있습니다.