혼자 공부할 때 가장 시간을 많이 잡아먹는 것은 오류입니다. 같은 오류를 몇 시간씩 붙잡고 있다가 포기하는 경우가 많습니다. 수업에서는 오류 메시지를 읽는 법…
README 첫 화면에서 게임이 보여야 합니다
README는 저장소의 첫 화면에 보이는 설명 문서입니다. 비어 있거나 엔진이 자동으로 만든 문구만 있으면, 보는 사람은 이 프로젝트가 무엇인지 알기 위해 폴더를 하나하나 열어야 합니다. 대부분은 그 전에 창을 닫습니다.
- 게임 이름과 한두 문장 소개, 장르와 플랫폼
- 플레이 장면 이미지나 짧은 움직이는 이미지, 플레이 영상 링크
- 사용한 엔진과 버전, 언어, 주요 라이브러리
- 직접 실행해 볼 수 있는 빌드 다운로드 링크와 실행 방법
- 개발 기간과 인원, 그중 내가 맡은 부분
- 핵심 기능별로 주요 코드 파일로 가는 링크
특히 마지막 항목이 중요합니다. '인벤토리 시스템은 이 폴더의 이 파일', '적 인공지능 상태 전환은 이 파일'처럼 바로 이동할 수 있게 해 두면, 검토자가 짧은 시간에 내 코드의 핵심을 볼 수 있습니다. 어떤 문제를 어떻게 풀었는지 짧은 설명을 붙이면 더 좋습니다. 예를 들어 '적이 많아지면 끊기던 문제를 오브젝트를 재사용하는 방식으로 줄였다'처럼 문제, 해결 방법, 결과를 한 줄씩 적으면 면접 질문으로 이어지기도 쉽습니다.
올리면 안 되는 파일이 섞여 있지 않은가
게임 엔진 프로젝트는 작업 중에 자동으로 생기는 임시 파일과 캐시 폴더가 많습니다. 이것까지 올리면 저장소가 무거워지고 정작 중요한 코드가 묻힙니다. 유니티라면 라이브러리나 임시 폴더처럼 엔진이 다시 만들 수 있는 폴더, 언리얼이라면 중간 빌드 결과물과 저장 폴더가 대표적입니다.
이런 파일은 .gitignore라는 설정 파일로 제외합니다. 깃허브에서 저장소를 만들 때 엔진별 기본 템플릿을 고를 수 있고, 이미 올려 버린 파일은 추적을 해제한 뒤 다시 정리해야 합니다. 정리한 뒤에는 저장소를 새 폴더에 내려받아 엔진에서 정상적으로 열리는지 한 번 확인하세요. 꼭 필요한 설정 파일까지 빠뜨리는 경우가 있기 때문입니다.
가장 조심할 것은 비밀번호, 서버 주소, 외부 서비스 키 같은 민감한 정보입니다. 설정 파일에 그대로 적혀 있다면 지원 전에 반드시 빼고, 이미 기록에 남았다면 해당 키를 새로 발급받아 바꿔야 합니다. 기록에서 지워도 이미 복제된 곳에는 남아 있을 수 있습니다.
대용량 리소스와 에셋 라이선스 확인
이미지, 사운드, 3D 모델 같은 큰 파일은 일반 저장소에 그대로 올리면 용량 제한에 걸리거나 내려받는 데 오래 걸립니다. 큰 파일을 따로 관리하는 Git LFS 같은 기능을 쓰거나, 리소스는 빌드에만 포함하고 저장소에는 코드와 필수 설정만 남기는 방법도 있습니다.
에셋 라이선스도 꼭 확인합니다. 에셋 스토어에서 산 유료 에셋은 공개 저장소에 원본 파일을 올리는 것이 라이선스상 허용되지 않는 경우가 많습니다. 무료 에셋도 출처 표기를 요구하는 것이 있습니다. 사용한 외부 에셋 목록과 출처를 README에 적고, 재배포가 제한된 파일은 저장소에서 빼는 것이 안전합니다. 이 부분을 깔끔하게 처리했다는 것 자체가 실무 감각을 보여 줍니다.
커밋 기록과 폴더 구조가 작업 습관을 보여 줍니다
커밋은 작업 내용을 기록하는 저장 단위이고, 커밋 메시지는 그 기록에 붙이는 설명입니다. '수정', '1111', '최종진짜최종' 같은 메시지만 가득하면 어떤 순서로 무엇을 만들었는지 알 수 없습니다. 이미 지난 기록을 모두 고칠 필요는 없지만, 앞으로의 커밋은 '플레이어 점프 높이 조절 기능 추가'처럼 무엇을 했는지 알 수 있게 씁니다.
폴더 구조도 한번 훑어봅니다. 스크립트가 한 폴더에 수십 개 섞여 있거나, 쓰지 않는 테스트 코드와 예전 버전 파일이 남아 있으면 정리가 안 된 인상을 줍니다. 기능별로 폴더를 나누고, 주석 처리된 채 남은 큰 코드 덩어리는 지우세요. 기록은 커밋에 남아 있으니 언제든 되살릴 수 있습니다.
팀 프로젝트는 내 기여가 보이게
팀 프로젝트 저장소는 여러 사람의 코드가 섞여 있어서 내가 무엇을 했는지 드러나지 않습니다. README에 팀 구성과 역할을 적고, 내가 맡은 기능과 파일을 따로 표시하세요. 개인 계정에 복사본을 둘 때는 팀원들의 동의를 받고, 원래 저장소의 출처를 적어 두는 것이 예의입니다.
프로필 첫 화면도 정리합니다. 깃허브는 대표 저장소를 프로필 상단에 고정해 보여 주는 기능이 있습니다. 연습용 저장소가 수십 개 있어도 지원에 쓸 프로젝트 몇 개를 고정해 두면 첫인상이 달라집니다. 프로필 소개에는 주로 쓰는 엔진과 언어, 관심 분야를 짧게 적습니다. 포트폴리오 문서나 개발 블로그가 있다면 링크를 함께 걸어 두세요.
지원 직전 마지막 점검 순서
- 로그아웃한 상태나 다른 브라우저로 저장소가 공개되어 보이는지 확인
- README의 이미지와 링크가 모두 열리는지 확인
- 빌드 파일을 내려받아 다른 컴퓨터에서 실행해 보기
- 민감한 정보와 라이선스 문제 파일이 없는지 다시 검색
- 지원서에 적은 저장소 주소가 정확한지 확인
정리하다 보면 코드 자체를 고치고 싶은 부분도 보일 것입니다. 시간이 있다면 핵심 기능 한두 곳만 골라 구조를 다듬고, 무엇을 개선했는지 README에 적어 두세요. 어느 코드를 대표로 보여 줘야 할지, 구조를 어디까지 고쳐야 할지 고민된다면 SBS아카데미게임학원 게임프로그래밍 과정 상담에서 저장소를 함께 보며 정리 방향을 잡아 드립니다.
자주 묻는 질문
깃허브 잔디(커밋 기록)가 적으면 불리한가요?
기록의 양보다 프로젝트의 완성도와 코드 품질을 더 중요하게 보는 경우가 많습니다. 다만 꾸준히 작업한 흔적은 성실함을 보여 주는 보조 자료가 될 수 있습니다.
README는 영어로 써야 하나요?
국내 회사 지원이라면 한국어로 써도 충분합니다. 해외 지원도 고려한다면 핵심 소개만 영어로 함께 적어 두는 방법이 있습니다.
가까운 캠퍼스에서 게임프로그래밍 알아보기
사는 곳과 가까운 캠퍼스를 고르면 수업 내용, 오시는 길, 상담 신청을 한 번에 볼 수 있습니다.