프로그래밍 과제 전형 코드 정리법

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

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

평가자는 코드를 이 순서로 엽니다

과제를 받은 평가자가 가장 먼저 하는 일은 프로젝트를 실행해 보는 것입니다. 실행이 안 되거나 방법을 찾느라 시간이 걸리면, 코드 품질을 보기도 전에 인상이 나빠집니다. 그다음에 폴더 구조를 훑고, 핵심 로직이 담긴 파일 몇 개를 골라 읽습니다.

즉 평가자에게 코드 전체를 처음부터 끝까지 읽을 시간은 거의 없습니다. 그래서 정리의 목표는 "어디를 보면 되는지" 빨리 알려 주는 것입니다. 실행 안내, 구조 설명, 핵심 파일 위치가 한눈에 보이면 평가자는 남은 시간을 설계와 구현을 보는 데 씁니다.

README 하나로 실행과 설계 의도를 함께 전하기

README는 과제의 첫 화면입니다. 길게 쓸 필요는 없지만, 아래 항목은 빠지지 않게 넣는 것이 좋습니다. 특히 "구현하지 못한 것"을 솔직하게 적는 칸은 생각보다 평가에 도움이 됩니다. 숨기다가 들키는 것보다 알고 있다는 것을 보여 주는 편이 낫기 때문입니다.

• 실행 환경: 엔진 버전, 개발 언어, 필요한 패키지
• 실행 방법: 어떤 씬이나 파일을 열고 무엇을 누르면 되는지
• 조작법과 확인 포인트: 평가자가 꼭 보면 좋을 기능
• 구조 요약: 주요 폴더와 클래스가 맡은 역할 몇 줄
• 설계 판단: 왜 이 방식을 골랐는지, 다른 선택지와 비교
• 미구현·알려진 문제: 시간이 더 있었다면 고칠 부분

설계 판단은 한두 문단이면 충분합니다. 예를 들어 적 AI를 상태 머신(상태별로 행동을 나눠 관리하는 구조)으로 만든 이유, 데이터를 코드 대신 별도 파일로 뺀 이유처럼 결정과 근거를 짝지어 적습니다.

폴더와 이름만 봐도 구조가 읽히게 만들기

폴더 구조는 기능 단위나 계층 단위 중 하나로 일관되게 나눕니다. 플레이어, 적, UI, 데이터처럼 나누든, 화면 표시와 게임 규칙과 데이터를 나누든 괜찮습니다. 중요한 것은 한 가지 기준을 끝까지 지키는 것입니다. 기준이 섞이면 평가자는 구조를 이해하는 데 시간을 씁니다.

이름 짓기도 같은 원리입니다. 클래스, 함수, 변수 이름에 규칙을 정하고 모든 파일에 똑같이 적용합니다. test2, temp, newScript 같은 이름은 제출 전에 모두 바꿉니다. 함수 이름만 읽어도 무슨 일을 하는지 알 수 있다면 주석이 훨씬 적어도 됩니다.

주석은 "무엇을 하는지"보다 "왜 이렇게 했는지"를 적을 때 가치가 있습니다. 코드를 그대로 다시 말하는 주석은 지우고, 예외 처리나 성능 때문에 일부러 돌아간 부분에만 짧게 남깁니다. 주석 처리한 옛 코드 덩어리도 제출본에서는 지웁니다.

한 파일에 모든 기능을 몰아넣지 않기

과제 코드에서 가장 자주 보이는 문제는 게임 매니저 같은 파일 하나가 수백 줄로 커져 입력, 점수, UI, 저장까지 모두 처리하는 경우입니다. 동작은 하더라도 평가자는 이 지원자가 협업 코드에서 역할을 나눌 줄 아는지 의심하게 됩니다.

클래스 하나가 한 가지 책임만 지도록 나누면 읽기 쉬워지고 수정도 편해집니다. 예를 들어 점수 계산과 점수 표시를 분리해 두면, 화면 디자인이 바뀌어도 계산 코드는 건드리지 않아도 됩니다. 이런 분리가 과제 안에서 한두 군데만 보여도 설계 감각이 있다는 신호가 됩니다.

게임 수치도 같은 관점에서 봅니다. 이동 속도, 공격력, 생성 간격 같은 값이 코드 곳곳에 숫자로 박혀 있으면 기획자가 조정할 때마다 프로그래머가 코드를 열어야 합니다. 이런 값을 한곳에 모으거나 인스펙터, 데이터 파일로 빼 두면 협업을 생각하는 사람이라는 인상을 줍니다. 엔진이 제공하는 데이터 저장 방식을 써도 되고, 간단한 표 형식 파일을 읽어도 됩니다.

다만 작은 과제에 디자인 패턴을 과하게 적용하는 것도 좋지 않습니다. 기능 세 개짜리 과제에 인터페이스와 추상 클래스가 열 개씩 있으면 오히려 판단력이 부족해 보입니다. 과제 규모에 맞는 만큼만 나누고, 그 기준을 README에 짧게 적어 두면 충분합니다.

커밋 기록은 작업 과정을 보여 주는 두 번째 서류

저장소 링크로 제출하는 과제라면 커밋 기록도 함께 읽힙니다. 마지막에 한 번에 올린 커밋 하나보다, 기능 단위로 나눠진 기록이 작업 순서와 판단 과정을 더 잘 보여 줍니다. 커밋 메시지는 "수정"처럼 뭉뚱그리지 말고 무엇을 바꿨는지 한 줄로 씁니다.

빌드 결과물, 엔진이 자동으로 만드는 캐시 폴더, 개인 설정 파일은 저장소에 올리지 않습니다. 무시 목록 파일로 미리 걸러 두면 저장소가 가벼워지고 평가자가 받는 시간도 줄어듭니다. 압축 파일로 제출할 때도 같은 기준으로 불필요한 폴더를 빼고 묶습니다.

제출 전 마지막 점검과 면접에서 나올 질문

1. 다른 폴더에 새로 받아서 README만 보고 실행해 보기
2. 경고와 사용하지 않는 코드, 디버그 출력 정리하기
3. 과제 요구사항을 한 줄씩 대조하며 빠진 기능 확인하기
4. 하드코딩한 숫자를 상수나 데이터로 옮겼는지 보기
5. 파일 이름과 제출 형식이 공고 안내와 맞는지 확인하기

과제 전형 뒤 면접에서는 제출한 코드를 놓고 질문하는 경우가 많습니다. "이 구조를 고른 이유는?", "기능이 열 배로 늘어나면 어디가 먼저 문제가 될까요?", "시간이 더 있었다면 무엇을 고치겠어요?" 같은 질문이 대표적입니다. 답변 방향은 정답을 맞히기보다 판단 근거와 한계를 스스로 알고 있다는 것을 보여 주는 쪽입니다.

피해야 할 답은 "시간이 없어서요"로 끝내는 것입니다. 시간이 부족했다면 무엇을 우선순위로 두었는지까지 말해야 합니다. 지금 만든 과제 코드를 남에게 보여 줘도 될지 판단이 서지 않는다면, SBS아카데미게임학원 게임프로그래밍 과정 상담에서 제출 전 구조와 정리 방향을 함께 살펴볼 수 있습니다.

자주 묻는 질문

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

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

함께 읽으면 좋은 글