신입 프로그래머가 처음 맡는 일은 무엇일까?

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

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

첫 주는 코드를 짜기보다 환경을 세팅하고 읽는 시간입니다

입사 직후에는 개발 환경을 갖추는 데 생각보다 시간이 걸립니다. 저장소에서 프로젝트를 받아 빌드하고, 엔진 버전과 플러그인을 맞추고, 사내 툴 계정을 만듭니다. 프로젝트 규모가 크면 처음 빌드하는 데만 반나절이 걸리기도 합니다.

환경이 갖춰지면 사수나 팀 리드가 프로젝트 구조를 설명해 줍니다. 어떤 폴더에 어떤 코드가 있는지, 게임이 시작될 때 어떤 순서로 초기화되는지, 데이터 테이블은 어디서 읽는지 같은 내용입니다. 이 단계에서 메모를 남겨 두면 나중에 같은 질문을 반복하지 않게 됩니다.

팀마다 정해 둔 코딩 규칙 문서도 이때 읽습니다. 변수 이름을 짓는 방식, 주석을 다는 기준, 커밋 메시지 형식처럼 사소해 보이는 약속들입니다. 이런 규칙은 수십 명이 같은 코드를 다룰 때 혼란을 줄이기 위해 존재합니다. 첫 리뷰에서 지적받는 내용의 상당수가 기능이 아니라 이런 규칙 위반이라는 점을 기억해 두면 좋습니다.

사수와 온보딩 과제로 프로젝트에 천천히 들어갑니다

규모가 있는 회사는 신입에게 사수를 붙여 주거나, 실제 서비스 코드와 분리된 온보딩 과제를 먼저 주기도 합니다. 간단한 테스트 맵에서 캐릭터를 움직이게 하거나, 사내 프레임워크로 작은 창 하나를 만들어 보는 식입니다. 과제의 목적은 실력을 시험하는 것보다 팀의 도구와 흐름에 익숙해지게 하는 데 있습니다.

이 시기에 많이 하는 실수는 혼자 너무 오래 붙잡고 있는 것입니다. 일정 시간 고민해도 실마리가 없으면, 지금까지 시도한 것과 막힌 지점을 정리해서 질문하는 편이 낫습니다. 좋은 질문은 사수의 시간을 아끼고, 신입이 문제를 어떻게 생각하는지도 보여 줍니다.

가장 흔한 첫 업무는 범위가 좁은 버그 수정입니다

신입에게 처음 배정되는 작업은 원인이 비교적 분명하고 영향 범위가 작은 버그인 경우가 많습니다. 예를 들어 특정 창을 닫았다 열면 버튼 글자가 사라지는 문제, 아이템 개수 표시가 한 칸 어긋나는 문제 같은 것입니다. 이런 작업은 고치는 것 자체보다 원인을 찾아가는 과정에서 배우는 것이 많습니다.

• QA가 남긴 재현 절차를 따라 버그를 직접 재현하기
• 디버거로 중단점을 걸고 값이 언제 바뀌는지 추적하기
• 고친 뒤 비슷한 화면이나 기능에서 같은 문제가 없는지 확인하기
• 수정 내용을 짧게 정리해 코드 리뷰에 올리기

처음에는 한 줄을 고치기 위해 수십 개 파일을 읽어야 할 수도 있습니다. 이 시간이 낭비처럼 느껴지지만, 이렇게 읽은 코드가 쌓여 프로젝트 전체 그림이 잡힙니다. 버그를 고칠 때마다 관련된 클래스와 흐름을 한 줄씩 기록해 두면, 몇 주 뒤에는 나만의 프로젝트 지도가 생깁니다. 이 기록은 다음 신입이 들어왔을 때 설명 자료로도 쓸 수 있습니다.

버그가 익숙해지면 작은 기능과 UI 연결을 맡습니다

몇 번의 수정이 무난하게 끝나면 기존 구조 위에 작은 기능을 얹는 일이 주어집니다. 기획서에 적힌 새 팝업을 띄우고 서버에서 받은 값을 화면에 연결하는 작업, 이미 있는 이벤트 시스템에 보상 항목 하나를 추가하는 작업 등이 대표적입니다.

이때 중요한 것은 이미 팀이 쓰는 방식을 따르는 것입니다. 내가 아는 더 깔끔한 방법이 있더라도 프로젝트의 기존 패턴과 다르면 리뷰에서 수정 요청을 받기 쉽습니다. 새 방식을 제안하고 싶다면 먼저 왜 지금 구조가 이렇게 되어 있는지 물어보는 편이 좋습니다.

코드 리뷰와 일정 공유도 신입의 중요한 업무입니다

게임 회사는 대부분 코드를 합치기 전에 다른 프로그래머의 리뷰를 거칩니다. 신입은 리뷰를 받는 쪽이 많지만, 선배의 코드를 읽고 질문하는 것도 좋은 공부가 됩니다. 리뷰 코멘트를 개인 비판으로 받아들이지 않고 바로 반영하는 태도가 신뢰를 쌓는 지름길입니다.

일정 공유도 생각보다 큰 비중을 차지합니다. 맡은 작업이 예상보다 오래 걸릴 것 같으면 마감 직전이 아니라 막힌 시점에 알려야 합니다. 일일 회의나 업무 관리 툴에 진행 상황을 짧게 남기는 습관은 실력만큼이나 평가에 영향을 줍니다.

작업 시간을 예측하는 감각도 이 시기에 길러집니다. 처음에는 하루면 될 줄 알았던 일이 사흘씩 걸리기 일쑤입니다. 맡은 작업마다 예상 시간과 실제 걸린 시간을 적어 두면, 몇 달 뒤에는 내 속도를 꽤 정확하게 말할 수 있게 됩니다. 팀 리드는 빠른 사람보다 예측이 맞는 사람에게 더 큰 일을 맡기는 경향이 있습니다.

입사 전에 미리 해 두면 첫 몇 달이 편해지는 준비

1. 오픈소스 게임이나 엔진 예제 프로젝트를 받아 구조를 읽고 기능 하나를 고쳐 보기
2. Git으로 브랜치를 나누고 충돌을 해결하는 과정을 직접 겪어 보기
3. 디버거 사용법을 손에 익히기: 중단점, 변수 감시, 호출 스택 확인
4. 내 코드의 수정 이유를 두세 문장으로 설명하는 연습하기
5. 팀 프로젝트에서 다른 사람이 짠 코드에 기능을 붙여 보기

특히 디버거는 학생 때 거의 쓰지 않다가 입사 후 처음 제대로 배우는 경우가 많습니다. 로그를 찍어 보며 추측하는 방식으로도 버그를 잡을 수는 있지만, 프로젝트가 커질수록 시간이 몇 배로 늘어납니다. 호출 스택을 따라 올라가며 이 함수를 누가 불렀는지 확인하는 연습만 해 둬도 첫 업무의 막막함이 크게 줄어듭니다. 엔진 공식 문서에서 원하는 정보를 빠르게 찾는 요령도 함께 익혀 두면 좋습니다.

포트폴리오용 게임을 혼자 처음부터 만드는 경험도 중요하지만, 실무의 첫 업무는 남이 만든 큰 코드 안에서 일하는 것입니다. 두 가지 경험을 모두 갖춘 지원자는 면접에서도 입사 후 모습을 구체적으로 설명할 수 있습니다. 내 코드가 실무 협업 방식에 얼마나 가까운지 점검해 보고 싶다면, SBS아카데미게임학원 게임프로그래밍 과정 상담에서 현재 프로젝트를 놓고 보완할 부분을 짚어 드립니다.

자주 묻는 질문

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

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

함께 읽으면 좋은 글