게임아카데미게임·웹툰·AI 진로 상담
게임은 사람이 동시에 즐기는 경우가 많아 서버와 네트워크 지식도 중요합니다. 과정 후반에는 여러 명이 접속하는 간단한 멀티플레이 기능을 구현해 보며 클라이언트…
깃허브는 코드라는 증거를, 블로그는 생각의 과정을 보여 줍니다
깃허브는 깃(Git)으로 관리하는 코드 저장소를 온라인에 올려 두는 서비스입니다. 프로젝트의 코드, 커밋 기록, 설명 문서(README)가 함께 남기 때문에 평가자는 지원자가 어떤 구조로 코드를 짜는지, 얼마나 꾸준히 작업했는지 직접 확인할 수 있습니다.
개발 블로그는 글로 기록하는 공간입니다. 버그를 어떻게 찾았는지, 왜 이 구조를 골랐는지, 새로 배운 개념을 어떻게 이해했는지 같은 내용이 담깁니다. 코드에는 결과만 남지만 블로그에는 그 결과에 이르기까지의 판단이 남는다는 점이 다릅니다.
두 가지는 경쟁 관계가 아니라 역할이 다른 도구입니다. 다만 시간과 에너지가 한정된 취업 준비생에게는 어느 쪽을 먼저 다듬을지가 현실적인 고민이 됩니다. 특히 게임 프로젝트는 엔진 파일과 리소스가 많아서 저장소 정리에만도 꽤 시간이 들기 때문에, 순서를 정해 두지 않으면 두 가지 모두 어중간한 상태로 지원하게 되기 쉽습니다.
같은 기준으로 놓고 비교해 보면
| 기준 | 깃허브 | 개발 블로그 |
|---|---|---|
| 보여 주는 것 | 실제 코드, 프로젝트 구조, 작업 기록 | 문제 해결 과정, 학습 내용, 글쓰기 능력 |
| 평가자가 보는 시간 | 대표 저장소 몇 개를 짧게 확인 | 링크된 글 한두 편을 골라 읽음 |
| 준비에 드는 노력 | 프로젝트 정리와 README 작성 | 글 한 편마다 정리와 퇴고 시간 필요 |
| 흔한 함정 | 잔디 채우기용 의미 없는 커밋 | 공식 문서를 옮겨 적은 듯한 요약 글 |
| 가장 효과적인 때 | 지원 직전, 포트폴리오와 함께 제출 | 면접에서 깊이 있는 대화를 이끌 때 |
표에서 보듯 깃허브는 서류 단계에서, 블로그는 면접 단계에서 더 큰 역할을 합니다. 채용 과정의 앞 단계를 먼저 넘어야 다음 단계가 있으니, 순서도 자연스럽게 깃허브가 앞섭니다.
깃허브를 먼저 정리해야 하는 이유
프로그래머 채용에서 서류 단계의 핵심 질문은 '이 사람이 코드를 짤 줄 아는가'입니다. 이 질문에 가장 빠르게 답하는 자료가 깃허브입니다. 포트폴리오 문서에 게임 영상과 설명을 넣었더라도, 코드를 확인할 저장소 링크가 없으면 평가자는 판단을 미룰 수밖에 없습니다.
정리할 때는 저장소 개수보다 대표 프로젝트 몇 개의 상태가 중요합니다. 고정(Pin) 기능으로 지원 직무와 관련된 프로젝트를 맨 위에 두고, 각 저장소의 README 첫 부분에 게임 소개, 플레이 영상 링크, 사용 엔진과 언어, 본인이 맡은 부분, 빌드 방법을 적어 두세요.
- README 첫 화면만 보고도 무슨 프로젝트인지 알 수 있는가
- 엔진이 자동으로 만드는 임시 파일이 올라가 있지 않은가
- 커밋 메시지가 무엇을 바꿨는지 알 수 있게 쓰여 있는가
- 팀 프로젝트라면 본인 담당 코드 위치를 안내했는가
흔히 말하는 '잔디'(매일 커밋하면 초록색으로 채워지는 기록)는 꾸준함의 참고 자료일 뿐입니다. 빈칸을 채우려고 의미 없는 커밋을 쌓으면 오히려 기록을 들여다본 평가자에게 좋지 않은 인상을 줄 수 있습니다.
개발 블로그가 힘을 발휘하는 순간
블로그는 서류 통과 이후에 진가를 발휘하는 경우가 많습니다. 면접관이 미리 블로그 글을 읽고 오면 '이 글에서 쓴 방식 말고 다른 방법은 생각해 봤나요?' 같은 깊은 질문이 나옵니다. 이런 대화는 지원자가 자신 있는 주제로 면접을 이끌 기회가 됩니다.
좋은 글은 화려한 주제보다 구체적인 경험에서 나옵니다. 오브젝트 풀링(자주 생기고 사라지는 객체를 미리 만들어 재사용하는 기법)을 적용했더니 프레임이 어떻게 달라졌는지, 충돌 판정이 가끔 빗나가던 원인을 어떻게 찾았는지 같은 글이 대표적입니다. 문제, 시도, 결과, 남은 과제 순서로 쓰면 읽기 쉽습니다.
반대로 문법 정리나 개념 요약만 이어지는 블로그는 차별점이 약합니다. 누구나 찾을 수 있는 내용보다 본인 프로젝트에서만 나올 수 있는 기록에 집중하는 편이 좋습니다. 개념 정리를 쓰더라도 내 게임에 어떻게 적용했는지를 덧붙이면 글의 가치가 달라집니다.
둘을 연결해서 운영하는 현실적인 방법
가장 효율적인 방법은 깃허브와 블로그를 서로 연결하는 것입니다. 프로젝트 README에서 관련 블로그 글로 이동할 수 있게 링크를 걸고, 블로그 글에서는 해당 코드가 있는 저장소를 안내합니다. 이렇게 하면 평가자가 어느 쪽에서 출발하든 코드와 설명을 함께 볼 수 있습니다.
- 지금 가진 프로젝트 중 대표작 두세 개를 골라 깃허브 정리하기
- 프로젝트마다 가장 어려웠던 문제 하나를 블로그 글 한 편으로 쓰기
- 새 프로젝트를 할 때는 작업 중 기록을 짧게 메모해 두기
- 메모가 쌓이면 한 달에 몇 편 정도로 다듬어 블로그에 올리기
블로그를 매일 써야 한다는 부담은 내려놓아도 됩니다. 꾸준함보다 내용의 밀도가 더 중요합니다. 몇 편이라도 직접 겪은 문제를 깊이 있게 다룬 글이 있다면 충분히 의미가 있습니다.
지금 내 상황에 맞는 선택
아직 완성한 프로젝트가 없다면 둘 다 미뤄도 됩니다. 이 단계에서는 게임 하나를 완성하는 것이 먼저이고, 그 과정을 깃으로 관리하는 습관만 들여 두면 됩니다. 프로젝트가 생겼고 지원을 앞두고 있다면 깃허브 정리가 먼저입니다. 서류를 통과한 경험이 있는데 면접에서 기술 대화가 짧게 끝났다면 블로그로 깊이를 보여 줄 때입니다.
가진 프로젝트를 어떻게 정리해야 평가자에게 잘 읽힐지 감이 오지 않는다면, SBS아카데미게임학원 게임프로그래밍 과정 상담에서 저장소 구성과 함께 쓸 만한 글감을 함께 골라 드립니다.
자주 묻는 질문
개발 블로그는 어느 플랫폼에 만드는 게 좋나요?
평가자가 읽기 편하고 코드 블록이 잘 보이는 곳이면 어디든 괜찮습니다. 플랫폼보다 글의 내용과 정리 상태가 훨씬 중요합니다.
깃허브에 올린 코드가 부끄러운 수준이면 공개하지 않는 게 나을까요?
처음 배울 때의 연습 코드는 비공개로 돌리고, 대표 프로젝트만 정리해서 공개하는 방법이 있습니다. 공개 저장소는 평가받아도 괜찮은 상태로 다듬어 두세요.
가까운 캠퍼스에서 게임프로그래밍 알아보기
사는 곳과 가까운 캠퍼스를 고르면 수업 내용, 오시는 길, 상담 신청을 한 번에 볼 수 있습니다.