깃허브 기여 그래프의 초록색 칸은 활동을 보여주는 단서입니다. 그러나 칸의 개수만으로 코드 품질이나 협업 능력을 판단할 수는 없습니다. 취업용 깃허브를 정리한다면 활동량보다 문제 해결 과정이 보이도록 구성하세요.
먼저 잔디가 무엇을 세는지 확인하세요
GitHub의 기여 그래프 공식 문서에 따르면 커밋, 이슈, 풀 리퀘스트 등은 조건에 따라 표시됩니다. 커밋 이메일이나 브랜치 조건 때문에 실제 작업이 그래프에 나타나지 않을 수도 있습니다. 따라서 잔디가 적다고 곧바로 활동이 없다고 판단하거나, 잔디를 늘리기 위한 빈 커밋을 만들 필요는 없습니다.
대표 저장소부터 정리하는 순서
- 프로젝트 목적: 해결하려는 사용자 문제를 한두 문장으로 적습니다.
- 실행 방법: 설치, 환경 변수, 테스트, 배포 주소를 재현 가능하게 기록합니다. 비밀키는 저장소에 올리지 않습니다.
- 본인 역할: 팀 프로젝트라면 담당 기능과 의사결정 근거를 분리해 적습니다.
- 검증 결과: 테스트, 성능 점검, 접근성 개선처럼 확인 가능한 결과를 보여줍니다.
- 한계와 다음 단계: 아직 해결하지 못한 문제도 명확히 씁니다.
README는 방문자가 프로젝트를 이해하는 첫 화면입니다. GitHub README 안내를 참고해 설치와 사용법을 정리하세요.
커밋 기록에는 무엇을 남길까요?
큰 변경 하나보다 변경 이유가 드러나는 작은 단위가 읽기 쉽습니다. 버그 수정이라면 재현 방법, 원인, 수정 방법, 확인 결과를 이슈 또는 풀 리퀘스트에 기록하세요. 협업 경험은 커밋 수가 아니라 리뷰 의견을 어떻게 반영했는지로 설명할 수 있습니다.
면접 전 마지막 점검
- 대표 저장소 링크가 작동하는가?
- 누구나 README만 보고 실행할 수 있는가?
- 본인 기여 범위를 과장하지 않았는가?
- 기술 선택의 대안과 한계를 설명할 수 있는가?
프로젝트 소개를 이력서와 연결할 때는 프론트엔드 포트폴리오 점검표를 함께 활용하세요.