포트폴리오 개선 사례를 읽을 때 ‘합격했다’는 결론만 따라 하면 본인 프로젝트에 적용하기 어렵습니다. 원본과 수정본에서 무엇이 달라졌고 그 결과를 어떻게 확인했는지 비교해야 합니다. 아래 방식으로 자신의 포트폴리오를 실제 사례로 분석해 보세요.
수정 전 상태 보관
첫 화면, 프로젝트 설명, README, 배포 링크의 현재 모습을 저장하고 방문자가 세 가지 질문에 답할 수 있는지 확인합니다. 무엇을 만들었는가? 본인이 무엇을 담당했는가? 실행 결과를 어디서 볼 수 있는가? 답을 찾기 어렵다면 바꿀 지점을 기록합니다.
한 번에 한 문제씩 고치기
예를 들어 기능 목록만 나열한 문장을 문제–선택–구현–검증 순서로 바꿉니다. 깨진 링크를 고치고, 설치·실행 방법을 추가하고, 팀 프로젝트의 개인 기여를 분리합니다. GitHub는 README를 저장소 방문자에게 보여 주는 구조를 안내합니다. 첫 방문자가 필요한 정보에 도달하는지 직접 확인하세요.
전후 결과는 사실로만 비교
수정 전에는 실행 방법이 없었고 수정 후에는 명령과 환경 변수가 설명되어 있다면 이는 확인 가능한 개선입니다. 반면 면접 통과율이나 조회수 증가를 측정하지 않았다면 성과 수치로 쓰지 마세요. 다른 사람에게 읽어 보게 하고 무엇을 이해했는지 질문하면 설명의 명확성을 점검할 수 있습니다.
사례를 공개할 때
수정 날짜, 변경한 문단, 이유, 남은 한계를 함께 적으세요. 회사 내부 코드나 고객 데이터는 포함하지 않습니다. 제출 전 기능·화면 점검은 프론트엔드 포트폴리오 점검표로 이어서 확인할 수 있습니다.