게임아카데미게임·웹툰·AI 진로 상담
최근에는 AI 코딩 도구를 쓰는 개발자가 늘었지만, 생성된 코드가 맞는지 판단하려면 결국 기본기가 필요합니다. 수업에서는 직접 짜는 연습을 충분히 한 뒤 AI…
실수 1: 플레이 영상은 화려한데 코드 이야기가 없다
프로그래머 포트폴리오인데 게임 소개 페이지처럼 만든 경우가 많습니다. 캐릭터와 배경 이미지, 플레이 영상, 게임 규칙 설명이 대부분이고 코드에 관한 내용은 마지막에 저장소 링크 하나뿐입니다. 이런 구성이면 평가자는 그 게임에서 지원자가 정확히 무엇을 구현했는지 알기 어렵습니다.
고치는 법은 기능 단위로 설명을 쓰는 것입니다. 예를 들어 '인벤토리 시스템'이라는 항목 아래 어떤 요구가 있었고, 어떤 구조로 나눴고, 어떤 점이 어려웠는지를 짧게 정리하세요. 핵심 코드 몇 줄과 구조를 보여 주는 간단한 그림을 함께 넣으면 평가자가 저장소를 열기 전에도 실력을 짐작할 수 있습니다. 플레이 영상은 이 설명을 뒷받침하는 자료로 쓰면 됩니다.
실수 2·3: 튜토리얼 결과물이 중심이고, 저장소가 실행되지 않는다
두 번째 실수는 강의나 튜토리얼을 따라 만든 게임을 거의 그대로 넣는 것입니다. 유명한 예제는 평가자도 알아보기 쉬워서, 따라 한 결과물만 있으면 스스로 설계한 경험이 없다고 판단할 수 있습니다. 튜토리얼에서 출발했다면 새로운 기능을 직접 추가하거나 구조를 바꾼 부분을 분명히 표시하세요. '원래 예제에는 없던 저장·불러오기 기능을 직접 설계했다'처럼 차이를 말할 수 있어야 합니다.
세 번째 실수는 저장소를 받아도 실행이 안 되는 경우입니다. 필요한 파일이 빠져 있거나, 엔진 버전을 적지 않았거나, 첫 화면에 설명이 없으면 평가자는 실행을 포기합니다. 저장소 첫 화면에 프로젝트 소개, 사용한 엔진과 버전, 실행 방법, 주요 기능, 내가 구현한 범위를 적어 두세요. 다른 컴퓨터에서 처음부터 받아 실행해 보는 것이 가장 확실한 점검 방법입니다.
실행 파일을 함께 제공할 수 있다면 더 좋습니다. 평가자가 엔진을 설치하지 않고도 바로 플레이해 볼 수 있기 때문입니다. 실행 파일 링크는 저장소 설명과 포트폴리오 문서 양쪽에 넣어 두세요.
실수 4: 팀 프로젝트에서 내 역할이 흐릿하다
팀 프로젝트는 협업 경험을 보여 주는 좋은 자료지만, 역할이 불분명하면 오히려 약점이 됩니다. '전투 시스템 구현' 같은 표현만 있으면 혼자 다 한 것인지, 일부만 맡은 것인지 알 수 없습니다. 면접에서 세부 질문을 받았을 때 대답하지 못하면 신뢰를 잃습니다.
내가 맡은 기능을 구체적으로 나열하고, 다른 팀원과 어떻게 나눠 작업했는지 적으세요. 버전 관리 도구에서 내 작업 기록을 보여 주는 것도 방법입니다. 기획자, 아티스트와 의견을 맞춘 경험이 있다면 짧게 덧붙이면 좋습니다. 클라이언트 프로그래머는 다른 직군과 가장 많이 소통하는 자리라서, 이런 경험이 실무 적응력으로 읽힙니다.
실수 5·6: 구조 설계와 문제 해결 과정이 보이지 않는다
다섯 번째 실수는 하나의 거대한 스크립트에 모든 기능을 몰아넣은 코드입니다. 처음에는 돌아가지만 기능이 늘어날수록 수정이 어려워집니다. 평가자는 플레이어, 적, UI, 데이터가 어떻게 분리되어 있는지, 기능끼리 서로 얼마나 얽혀 있는지를 봅니다. 구조를 보여 주는 간단한 그림을 넣고, 왜 그렇게 나눴는지 설명하세요. 디자인 패턴을 썼다면 이름만 쓰지 말고 그 패턴으로 무엇이 편해졌는지까지 적어야 합니다.
여섯 번째 실수는 잘 된 결과만 보여 주고 문제를 해결한 과정을 생략하는 것입니다. 실무에서는 버그 원인을 찾고 성능 문제를 해결하는 시간이 많습니다. 프레임이 떨어지던 장면을 어떻게 분석했는지, 재현이 어려운 버그를 어떻게 잡았는지 같은 이야기가 포트폴리오에 하나라도 있으면 큰 차별점이 됩니다.
- 어떤 증상이 있었는지
- 원인을 어떻게 찾았는지 (사용한 도구나 방법)
- 어떻게 고쳤고 다른 방법은 왜 택하지 않았는지
- 같은 문제를 막기 위해 무엇을 바꿨는지
실수 7: 기술 이름만 길게 나열한다
마지막 실수는 포트폴리오 앞부분에 언어, 엔진, 라이브러리 이름을 잔뜩 적는 것입니다. 많이 적을수록 좋아 보일 것 같지만, 평가자는 그중 어느 것을 실제로 깊이 써 봤는지 알 수 없습니다. 오히려 한 번 써 본 기술까지 나열하면 면접에서 그 기술에 대한 질문을 받았을 때 곤란해집니다.
주력 기술 몇 가지를 적고, 각 기술을 어느 프로젝트의 어떤 기능에 썼는지 연결하세요. 기술 목록과 프로젝트 설명이 서로 이어지면 목록이 짧아도 훨씬 신뢰가 갑니다. 기술 수준을 별점이나 막대그래프로 표시하는 방식도 피하세요. 기준이 없는 자기 평가는 평가자에게 아무 정보도 주지 못하고, 오히려 면접에서 확인 질문만 늘어납니다. 대신 '이 기술로 무엇을 만들었는지'를 한 줄씩 붙이는 편이 훨씬 구체적입니다.
고칠 때는 프로젝트 하나를 기술 문서처럼 다시 씁니다
일곱 가지를 한 번에 해결하려 하기보다, 가장 자신 있는 프로젝트 하나를 골라 기능별 설명, 구조 그림, 문제 해결 사례, 실행 방법을 갖춘 문서로 다시 정리해 보세요. 이 작업만으로도 포트폴리오의 인상이 크게 바뀝니다. 나머지 프로젝트는 같은 형식으로 짧게 맞추면 됩니다.
어떤 프로젝트를 대표로 세우고 무엇을 덜어 낼지 판단이 서지 않는다면, SBS아카데미게임학원 게임프로그래밍 과정 상담에서 현재 저장소와 문서를 보며 보완 순서를 함께 정해 보세요.
자주 묻는 질문
알고리즘 문제 풀이 기록도 포트폴리오에 넣어야 하나요?
코딩 테스트를 준비하고 있다는 근거로 짧게 언급할 수는 있습니다. 다만 클라이언트 포트폴리오의 중심은 게임 프로젝트여야 하고, 풀이 기록은 보조로 두는 편이 좋습니다.
완성하지 못한 프로젝트도 넣어도 되나요?
핵심 기능이 동작하고 설계 의도를 설명할 수 있다면 넣을 수 있습니다. 미완성이라는 점과 어디까지 구현했는지를 솔직하게 밝히세요.
가까운 캠퍼스에서 게임프로그래밍 알아보기
사는 곳과 가까운 캠퍼스를 고르면 수업 내용, 오시는 길, 상담 신청을 한 번에 볼 수 있습니다.