깃허브 잔디가 취업에 영향을 줄까?

이 글과 연결된 과정게임프로그래밍 과정 알아보기

게임 회사 프로그래머 채용에서는 코딩 테스트와 함께 직접 만든 프로젝트를 봅니다. 수업 중에 자료구조와 알고리즘 문제를 꾸준히 풀고, 동시에 캐릭터 조작, 물…

검토자는 잔디보다 저장소 안쪽을 봅니다

포트폴리오에 깃허브 주소를 적으면 검토자는 대개 대표 프로젝트 저장소부터 엽니다. 먼저 첫 화면의 설명 문서를 읽고, 폴더 구조를 훑은 뒤, 핵심 코드 몇 개를 열어 봅니다. 이 과정에서 잔디 그래프는 잠깐 스쳐 지나가는 정보에 가깝습니다.

검토자가 실제로 확인하는 것은 코드가 읽기 쉬운지, 기능이 적절히 나뉘어 있는지, 이름을 의미 있게 붙였는지 같은 기본기입니다. 커밋 기록을 열어 보면 이 사람이 작업을 어떤 단위로 나누고 기록하는지도 드러납니다. 기능 하나를 추가할 때마다 짧고 분명한 메시지를 남긴 저장소는 그 자체로 협업 습관을 보여 줍니다.

반대로 잔디는 빽빽하지만 커밋 메시지가 전부 수정, 업데이트처럼 내용 없는 단어라면 오히려 아쉬운 인상을 줄 수 있습니다. 무엇을 바꿨는지 알 수 없는 기록은 실무에서 동료가 가장 곤란해하는 습관이기 때문입니다.

잔디가 의미를 갖는 경우도 있습니다

잔디가 전혀 쓸모없는 것은 아닙니다. 몇 달에 걸쳐 꾸준히 이어진 기록은 이 사람이 개발을 습관처럼 해 왔다는 근거가 됩니다. 특히 비전공자나 경력 전환자에게는 짧은 기간에 급하게 만든 포트폴리오가 아니라는 점을 보여 주는 보조 자료가 될 수 있습니다.

또 하나의 프로젝트를 오랜 기간 개선해 온 기록은 완성도를 높이려는 태도를 보여 줍니다. 처음 버전에서 구조를 어떻게 바꿨는지, 버그를 어떻게 잡았는지가 커밋으로 남아 있으면 면접에서 이야기할 거리도 자연스럽게 생깁니다. 면접관이 이 커밋에서 무엇을 고쳤는지 물었을 때 바로 답할 수 있다면 그것만으로도 좋은 대화가 됩니다.

다만 회사마다 깃허브를 보는 비중은 다릅니다. 실행 파일과 영상 위주로 평가하는 곳도 있고, 코드 저장소를 꼼꼼히 읽는 곳도 있습니다. 어느 쪽이든 잔디만으로 판단하는 경우는 드물기 때문에, 잔디는 있으면 좋은 보조 신호 정도로 생각하는 것이 정확합니다.

잔디를 채우려다 생기는 역효과

잔디를 채우는 것 자체가 목표가 되면 문제가 생깁니다. 공백 하나를 고치고 커밋하거나, 의미 없는 파일을 매일 수정해 기록을 남기는 식입니다. 이런 기록은 커밋 내역을 열어 보는 순간 바로 드러나고, 보여 주기식 활동으로 읽힐 수 있습니다.

더 큰 손해는 시간입니다. 잔디를 매일 채우는 데 신경 쓰다 보면, 정작 며칠씩 고민해야 하는 큰 기능이나 구조 개선을 미루게 됩니다. 실력은 하루 한 번의 커밋보다, 어려운 문제를 붙잡고 해결해 낸 경험에서 더 많이 늘어납니다. 잔디는 열심히 개발한 결과로 자연스럽게 생기는 것이 가장 좋습니다.

잔디보다 먼저 정리해야 할 다섯 가지

• 대표 저장소 고정: 보여 주고 싶은 프로젝트 두세 개를 프로필 상단에 고정하기
• 설명 문서: 게임 소개, 플레이 영상이나 이미지, 사용 엔진과 버전, 실행 방법, 내가 맡은 부분 적기
• 폴더 구조: 엔진이 만드는 임시 파일과 빌드 결과물을 제외하고 소스 위주로 정리하기
• 커밋 메시지: 무엇을 왜 바꿨는지 한 줄로 알 수 있게 쓰기
• 핵심 코드 안내: 꼭 봐 줬으면 하는 스크립트 경로를 설명 문서에 적어 두기

게임 엔진 프로젝트는 그대로 올리면 용량이 크고 불필요한 파일이 섞이기 쉽습니다. 엔진에 맞는 제외 목록 파일을 설정해 두면 저장소가 훨씬 깔끔해지고, 검토자가 코드를 찾기도 쉬워집니다. 팀 프로젝트라면 내가 작성한 부분을 구분해 적는 것도 잊지 마세요.

설명 문서는 영어와 한국어 중 편한 쪽으로 써도 괜찮습니다. 중요한 것은 처음 보는 사람이 몇 분 안에 이 프로젝트가 무엇이고 어디를 보면 되는지 알 수 있게 하는 것입니다.

커밋 습관은 입사 후에도 그대로 이어집니다

게임 회사에서는 여러 프로그래머가 같은 프로젝트를 동시에 수정합니다. 기능 단위로 브랜치를 나누고, 작게 자주 커밋하고, 메시지로 변경 이유를 남기는 습관은 실무에서 바로 쓰입니다. 일부 회사는 깃 대신 다른 버전 관리 도구를 쓰기도 하지만, 변경을 기록하고 합치는 원리는 같습니다.

그래서 개인 프로젝트에서도 혼자 쓰는 저장소라고 아무렇게나 기록하기보다, 동료가 읽는다고 생각하고 관리해 보는 것이 좋습니다. 기능을 추가할 때 브랜치를 따로 만들고, 완성되면 합치는 흐름을 한 번이라도 경험해 두면 면접에서 협업 질문이 나왔을 때 훨씬 구체적으로 답할 수 있습니다.

결론은 기록의 양보다 기록의 질입니다

잔디가 듬성듬성해도 대표 프로젝트가 잘 정리되어 있다면 충분히 경쟁력이 있습니다. 반대로 잔디가 가득해도 저장소 안이 정리되지 않았다면 큰 도움이 되지 않습니다. 지금 잔디가 비어 있다면 매일 채우려 애쓰기보다, 대표 프로젝트 하나를 골라 설명 문서와 코드 구조부터 다듬어 보세요.

그다음에는 새 기능을 추가하거나 구조를 개선할 때마다 의미 있는 커밋을 남기면 됩니다. 이렇게 하면 잔디는 억지로 채우지 않아도 자연스럽게 늘어나고, 그 안에는 면접에서 설명할 수 있는 이야기가 함께 쌓입니다. 일주일에 몇 번이라도 꾸준히 이어지는 기록이 하루 몰아서 채운 기록보다 훨씬 설득력이 있습니다.

내 저장소가 검토자에게 어떻게 보일지 객관적으로 판단하기 어렵다면, SBS아카데미게임학원 게임프로그래밍 과정 상담에서 현재 깃허브와 프로젝트를 보며 정리 방향을 함께 짚을 수 있습니다.

자주 묻는 질문

가까운 캠퍼스에서 게임프로그래밍 알아보기

사는 곳과 가까운 캠퍼스를 고르면 수업 내용, 오시는 길, 상담 신청을 한 번에 볼 수 있습니다.

함께 읽으면 좋은 글