좋아 보이는 포트폴리오 사례를 그대로 따라 만들면 본인의 문제 해결 과정을 보여주기 어렵습니다. 다른 사람의 결과물은 배치와 기술 이름보다 무엇을 증명하는지 분석하는 자료로 사용하세요.
사례를 볼 때 던질 질문
프로젝트가 해결하려는 문제는 무엇인가요? 만든 사람이 맡은 기능이 분명한가요? 설계 대안과 선택 이유가 적혀 있나요? 다른 사람이 코드를 실행할 수 있나요? 실패한 입력이나 알려진 한계가 있나요? 이 다섯 질문에 답이 없으면 화면이 좋아 보여도 실무 판단을 평가하기 어렵습니다.
내 프로젝트에 적용하기
기존 예제와 같은 예약 서비스를 만들어도 중복 예약 처리, 권한, 취소 규칙을 본인의 요구사항으로 정하면 다른 프로젝트가 됩니다. 팀 작업이라면 전체 결과와 자신의 코드 기여를 분리하세요. GitHub README 안내처럼 목적과 시작 방법을 먼저 적고, 풀 리퀘스트 기록으로 주요 변경을 설명할 수 있습니다.
사례를 베끼지 않기 위한 기록
참고한 자료의 링크와 본인이 바꾼 요구사항, 독자적으로 해결한 문제를 따로 남깁니다. 공개 코드를 가져왔다면 라이선스와 표시 조건을 확인하세요. 면접에서 “왜 이렇게 만들었나”라는 질문에 답할 수 있는 범위만 자신의 작업으로 제시해야 합니다.
포트폴리오의 기본 구조를 먼저 잡으려면 IT 기술 스택과 프로젝트 가이드를 참고하세요.