이력서에 GitHub 링크가 붙어 있어요. 들어가 보니 네 명이 함께 만든 프로젝트예요. README는 깔끔하고 서비스도 그럴듯해요. 그런데 정작 궁금한 것은 하나예요.
이 중에서 지원자가 한 일은 무엇일까요?
레포만 봐서는 알기 어려운 이유
팀 프로젝트 레포는 팀 전체의 결과물이에요. 지원자가 핵심 기능을 설계했을 수도 있고, 문구 몇 줄만 고쳤을 수도 있어요. 겉으로 보이는 완성도는 둘을 구분해 주지 않아요.
직접 확인하려면 커밋 기록에서 지원자의 커밋만 걸러서 하나씩 열어 봐야 해요. 지원자가 수십 명이라면 현실적으로 하기 어려운 일이에요. 그래서 대부분은 README만 훑고 넘어가거나, 면접에서 "어떤 부분을 맡으셨어요?"라고 묻는 것으로 대신해요.
무엇을 확인하면 좋을까요
1. 얼마나 참여했는지
커밋 수와 라인 수를 둘 다 봐야 해요. 한쪽만 보면 쉽게 오해해요.
- 커밋 수는 많은데 라인 수가 적다면, 작게 자주 올리는 사람이거나 자잘한 수정을 주로 맡은 사람이에요.
- 커밋 수는 적은데 라인 수가 많다면, 한 번에 크게 올리는 사람이거나 자동으로 만들어진 파일이 섞여 있을 수 있어요.
두 숫자가 크게 어긋난다면 그 자체가 면접에서 물어볼 좋은 질문이 돼요.
2. 어떤 기능을 맡았는지
참여한 양보다 더 중요한 것은 무엇을 만들었는지예요. 지원자의 커밋이 어떤 기능에 몰려 있는지 보면 이력서의 "백엔드 담당"이 실제로 무엇을 뜻하는지 알 수 있어요. 지원한 직무와 맡았던 기능이 이어지는지도 여기서 확인돼요.
3. 코드를 어떻게 쓰는지
이름을 어떻게 짓는지, 함수를 얼마나 잘게 나누는지, 예외 상황을 챙기는지, 주석을 어떻게 다는지 같은 것들이에요. 과제 전형의 코드는 잘 보이려고 다듬은 코드지만, 팀 프로젝트의 커밋에는 평소 습관이 남아 있어요.
4. 어떻게 일하는지
- 프로젝트 기간 내내 꾸준히 올렸는지, 마감 직전에 몰아서 올렸는지
- 커밋 메시지를 읽는 사람이 이해할 수 있게 썼는지
- PR을 올리고 다른 사람의 리뷰를 받았는지
이런 기록은 입사 후에 함께 일하는 모습을 가장 가깝게 보여줘요.
빠르게 확인하는 방법
WhoIsLoafing에 지원자가 제출한 레포 링크를 넣으면 위 네 가지를 대화 형식으로 정리해 드려요. 설치나 로그인 없이 공개 레포라면 바로 볼 수 있어요.
- 레포 링크를 넣으면 어떤 서비스인지와 기술 스택을 먼저 알려드려요.
- 기여도 분석을 고르면 참여자별 커밋 수, 라인 수, 기여도 순위를 보여드려요.
- 이어서 참여자마다 맡은 기능 목록과 코드 스타일을 정리해 드려요.
- 분석이 끝난 뒤 특정 참여자 상세에서 지원자를 고르면 그 사람의 수치, 활동 시간대, 맡은 기능만 모아서 볼 수 있어요.
막판에 몰아서 작업한 사람이 있는지, PR은 어떻게 주고받았는지도 추가 질문으로 확인할 수 있어요.
숫자를 읽을 때 꼭 기억해 주세요
이 부분이 가장 중요해요. 분석 결과는 판단을 도와주는 자료이지, 판단을 대신해 주는 점수가 아니에요.
- 커밋에 남지 않는 일이 있어요. 기획, 설계 회의, 디자인, 다른 팀원의 코드 리뷰, 일정 관리는 숫자에 잡히지 않아요. 기여도가 낮게 나온 사람이 팀을 실제로 이끈 사람일 수도 있어요.
- 옆에 앉아서 같이 짠 코드는 한 사람의 이름으로 올라가요. 둘이 함께 작업하고 한 사람의 컴퓨터에서 커밋했다면 다른 한 사람의 기록은 남지 않아요.
- 커밋을 뭉쳐서 합치는 팀이 있어요. 이런 팀에서는 커밋 수가 실제 작업량보다 훨씬 적게 보여요.
- 자동으로 만들어진 파일이 라인 수를 부풀려요. 분석을 시작할 때 빼고 계산하기를 고르면 잠금 파일과 빌드 결과물을 뺀 숫자를 볼 수 있어요.
- 계정이 연결되지 않은 커밋이 있을 수 있어요. 같은 이름이나 이메일로 최대한 한 사람으로 합치지만, 완전히 다른 이름으로 커밋한 기록은 다른 사람으로 보일 수 있어요.
- 비공개 레포는 분석하지 않아요. 지원자가 비공개 레포를 제출했다면 다른 방법으로 확인해야 해요.
그래서 숫자가 낮다는 이유만으로 지원자를 떨어뜨리는 용도로는 쓰지 않기를 권해요.
면접 질문으로 바꿔 보세요
분석 결과가 가장 쓸모 있는 순간은 면접 질문을 준비할 때예요. 막연한 질문 대신 기록에 근거한 질문을 할 수 있어요.
| 기록에서 보인 것 | 이렇게 물어볼 수 있어요 |
|---|---|
| 결제 관련 커밋이 가장 많아요 | "결제 흐름에서 가장 까다로웠던 부분은 무엇이었나요?" |
| 마지막 사흘에 커밋이 몰려 있어요 | "프로젝트 막바지에 어떤 일이 있었나요? 다시 한다면 일정을 어떻게 잡으실 건가요?" |
| 커밋 수에 비해 라인 수가 아주 많아요 | "한 번에 크게 올리신 커밋이 있던데, 어떤 작업이었나요?" |
| 기여도 숫자는 낮은데 이력서에는 팀장이라고 적혀 있어요 | "코드 말고 어떤 역할을 주로 맡으셨나요?" |
| 팀의 커밋 메시지 규칙을 꾸준히 지켰어요 | "팀 규칙은 누가 어떻게 정했나요?" |
지원자 입장에서도 "어떤 부분을 맡으셨어요?"라는 질문보다 자신의 작업을 구체적으로 짚어 주는 질문이 훨씬 대답하기 좋아요. 자기 작업을 제대로 읽고 온 면접관이라는 인상도 남아요.
정리하면
레포 분석은 지원자를 걸러내는 도구가 아니라, 지원자를 더 정확하게 이해하고 더 좋은 질문을 준비하는 도구예요. 기록이 말해 주는 것은 무엇을 했는지까지고, 왜 그렇게 했는지는 직접 들어야 알 수 있어요.