인터넷의 ‘합격 사례’를 그대로 복사하기보다 같은 프로젝트를 두 방식으로 설명해 보세요. 아래 A·B는 실제 합격자의 사례가 아닌 작성법을 비교하기 위한 가상의 예시입니다.
A: 기능만 나열한 설명
“일정 관리 앱. React, Node.js 사용. 로그인, 일정 추가, 검색 기능.” 사용한 기술과 기능은 알 수 있지만 누가 어떤 문제를 겪었고 작성자가 무엇을 구현했는지는 보이지 않습니다. 실행 방법과 검증 결과도 빠져 있습니다.
B: 문제와 근거를 연결한 설명
“중복 예약을 찾기 어려운 상황을 가정해 일정 충돌을 표시하는 웹 앱을 만들었다. 나는 입력 검증과 충돌 표시를 구현했고, 빈 제목과 겹치는 시간 입력을 테스트했다.” 여기에 저장소·배포 링크와 한계를 붙이면 방문자가 내용을 확인할 수 있습니다. 측정하지 않은 사용자 만족도는 추가하지 않습니다.
자신의 글에 적용
각 프로젝트의 첫 문단에 사용자 문제, 본인 기여, 확인 가능한 결과를 적습니다. 다음 단락에 기술 선택 이유와 대안, 제약을 넣습니다. 팀의 성과와 개인 역할을 구분하세요.
실행 자료 확인
README에는 설치·실행·테스트 방법을 적습니다. GitHub 공식 README 안내를 기준으로 다른 사람이 프로젝트를 재현할 수 있는지 시험하세요. 전체 정보 배치는 포트폴리오 구조 가이드를 참고하세요.