이력서는 내가 "할 수 있다고 말하는 것"이에요. GitHub은 내가 "실제로 해낸 것"이고요. 어느 쪽이 더 설득력 있을까요?
채용 담당자가 이력서 1장을 보는 시간은 평균 6초예요[2]. 이 짧은 시간 안에 전공·경력·스킬이 다 전달되지는 않죠. 그래서 신입이거나 비전공자일수록 프로젝트 섹션과 GitHub이 합격의 실질적인 기준이 돼요[2]. 면접 후반부에는 엔지니어가 코드 품질, 프로젝트 구조, 테스트, 커밋 히스토리까지 상세히 살펴봐요[2].
이 글에서는 채용 담당자가 GitHub에서 진짜로 보는 것과, 주니어 개발자가 우선순위를 잡아 프로필을 꾸미는 법을 정리했어요.
왜 GitHub이 이력서보다 강력한가요?
세 가지 이유예요.
"주장"이 아닌 "증거"예요. 이력서에는 "Spring Boot 중급"이라고 쓸 수 있지만, GitHub에는 실제 코드가 있어요.
최근 활동이 "살아 있는 개발자"를 증명해요. 꾸준한 커밋은 "지금도 배우고 있다"는 가장 강한 신호예요.
면접에서 다 못 보여주는 걸 보여줘요. 코드 구조, 네이밍, 커밋 메시지, README 작성 능력까지 — 한 시간 면접으로는 확인 못 할 것들을 GitHub이 대신 말해줘요.
특히 CS 학위가 없거나 경력이 짧다면, 프로젝트 섹션(= GitHub)이 사실상 유일한 검증 도구가 돼요[2]. 이력서보다 강하다는 말이 과장이 아닌 이유예요.
채용 담당자가 GitHub에서 진짜 보는 것 5가지
1. 핀 고정(Pinned) 레포 — 첫 인상의 전부
GitHub 프로필 상단에 6개까지 대표 프로젝트를 고정할 수 있어요. 이게 첫 인상이에요[1]. 여기에 빈 프로젝트나 튜토리얼 따라한 HelloWorld가 올라와 있으면 바로 뒤로가기 버튼을 눌러요.
선정 기준: "이 프로젝트를 면접에서 30분 동안 설명할 수 있는가?"
2. 프로필 README — 한 페이지 자기소개
2020년 5월 GitHub이 도입한 기능이에요[4]. 사용자명과 같은 이름의 레포를 만들면 README가 프로필 상단에 표시돼요[3].
필수 요소:
한 줄 소개 — "백엔드 개발자 | Java·Spring 중심 | 3년차"
기술 스택 — 실제로 쓸 줄 아는 것만
대표 프로젝트 링크
연락처 — 이메일, LinkedIn[2]
만드는 법: New repository → 레포 이름을 본인 사용자명과 똑같이 → Public → "Add README" 체크 → Create[3].
3. 각 레포의 README.md — 가장 많이 놓치는 요소
많은 지원자가 이걸 안 만들어요[1]. 그런데 이게 있냐 없냐로 "성의 있는 개발자"인지 아닌지가 갈려요.
좋은 README에 꼭 들어가야 할 것:
프로젝트 개요 — 무엇을, 왜 만들었나
기술 스택 — 어떤 도구를 썼고 왜 선택했나
주요 기능 — 스크린샷이나 GIF로 보여주기[2]
실행 방법 — README만 보고
git clone→run가능해야 함[1]배포 링크 — 있으면 무조건 넣기. "엔드 투 엔드 실행 능력"의 증명이에요[1]
본인 기여 — 팀 프로젝트라면 "제가 맡은 부분은 X입니다" 명시[2]
4. 커밋 히스토리 — 사고 방식을 드러내는 로그
커밋 메시지는 10~70자 사이로, 무엇이 왜 바뀌었는지 명확하게 쓰세요[1]. fix, wip, asdf 같은 메시지는 "이 사람은 협업이 안 되는 사람"이라는 인상을 줘요.
권장: Conventional Commits 스타일[2]
`` feat: 사용자 로그인 기능 추가 fix: 비밀번호 재설정 시 이메일 미발송 버그 refactor: AuthService 책임 분리 ``
커밋은 작게 자주 하세요. 큰 덩어리 하나보다, 작은 단위 10개가 "모듈적 사고"를 증명해요[2].
5. 활동 그래프와 코드 품질
활동 그래프가 지나치게 비어 있거나, 반대로 부자연스럽게 꽉 차 있는 것 둘 다 위험 신호예요. 특히 가짜 커밋(dummy commits)이나 활동 조작은 즉시 적신호로 인식돼요[1].
코드 자체에서는 린터 적용, 의미 있는 변수명, 적절한 메서드 길이 같은 기본기를 봐요[1].
우선순위별 실행 체크리스트
완벽하게 꾸미려고 하면 시작도 못 해요. 아래 순서대로 작게 시작하세요.
단계 | 작업 | 예상 시간 |
|---|---|---|
1 | 프로필 사진·실명·바이오 추가 | 10분 |
2 | 프로필 README 만들기 (사용자명 레포) | 30분 |
3 | 대표 프로젝트 3~6개 핀 고정 | 10분 |
4 | 각 레포 README 작성 (프로젝트당) | 30분 |
5 | 앞으로의 커밋 메시지 스타일 통일 | 지속 |
1단계만 해도 "빈 프로필"은 벗어나요. 그다음에 주말마다 프로젝트 하나씩 README를 채워가면 돼요.
주니어가 흔히 하는 실수 5가지
실수 | 왜 문제인가 |
|---|---|
핀 고정 없음 | 첫 인상에서 "보여줄 게 없는 개발자"로 인식 |
레포 README 없음 | 성의 부족, 문서화 역량 부족으로 해석[1] |
튜토리얼 복붙 프로젝트만 | 차별점이 없고, 본인 사고 과정이 안 보임 |
커밋 메시지 "fix", "asdf" | 협업 경험 부족으로 인식[1] |
가짜 커밋으로 그래프 채우기 | 즉시 감지되는 적신호[1] |
마무리
GitHub은 "꾸미는 것"이 아니라 "쌓는 것"이에요. 화려한 배지나 가짜 streak은 오히려 역효과예요. 중요한 건 실제로 만든 프로젝트를, 제대로 설명하는 것이에요.
프로젝트를 만들면서 배운 점과 의사결정 근거를 그때그때 기록해두면, 나중에 README를 쓸 때도, 이력서를 쓸 때도 훨씬 수월해져요. 트리업의 경험 관리로 프로젝트별 의사결정과 성과를 정리해두면, 이력서와 GitHub README에 각각 맞게 활용할 수 있어요.
그리고 GitHub과 이력서는 대체재가 아니라 짝꿍이에요. 트리업의 이력서 빌더와 함께 쓰면, 이력서의 "했다"가 GitHub의 "이렇게 했다"로 연결되면서 완전한 설득력을 갖게 돼요.
작은 프로젝트 하나부터, README 한 줄부터 시작해보세요. 그게 진짜 포트폴리오의 시작이에요.
