게임아카데미게임·웹툰·AI 진로 상담
처음 코딩을 배우면 문법은 이해했는데 막상 무엇을 만들어야 할지 막막해지는 시기가 옵니다. 수업에서는 이 시기를 짧게 넘기도록 작은 게임 하나를 정해 기능을 …
평가자가 두 종류의 포트폴리오에서 읽는 신호는 다릅니다
1인 프로젝트를 볼 때 평가자는 지원자의 실력을 그대로 확인합니다. 게임 루프, 입력 처리, UI, 저장 기능까지 모두 지원자가 짰기 때문에 코드 품질과 구조가 곧 그 사람의 수준입니다. 기획이나 그래픽이 단순해도 괜찮습니다. 오히려 기능이 깔끔하게 나뉘어 있는지, 버그 없이 끝까지 플레이되는지가 핵심입니다.
팀 프로젝트에서는 결과물의 화려함보다 '이 사람이 무엇을 맡았는가'를 먼저 찾습니다. 게임이 아무리 완성도 높아도 본인이 한 부분이 흐릿하면 평가할 근거가 없습니다. 기획자, 아티스트와 어떻게 소통했고 충돌이 생겼을 때 어떻게 해결했는지도 면접에서 자주 묻는 부분입니다.
같은 기준으로 비교한 1인 개발과 팀 개발
| 기준 | 혼자 개발 | 팀 개발 |
|---|---|---|
| 증명하는 것 | 전체 구조를 설계하고 완성하는 능력 | 역할 분담, 소통, 협업 도구 사용 |
| 코드 평가 | 모든 코드가 본인 실력으로 읽힘 | 담당 모듈만 따로 보여 줘야 함 |
| 주로 쓰는 도구 | 엔진, 깃 개인 저장소 | 깃 브랜치·병합, 일정 관리 도구, 문서 |
| 약점 | 협업 경험을 보여 주기 어려움 | 본인 기여도가 흐려지기 쉬움 |
| 면접 질문 | 왜 이 구조로 설계했는가 | 팀에서 어떤 문제를 어떻게 풀었는가 |
표를 보면 두 포트폴리오는 서로의 약점을 채워 주는 관계입니다. 그래서 신입 지원자 포트폴리오에 두 종류가 모두 들어 있으면 평가자가 확인할 수 있는 정보가 크게 늘어납니다.
혼자 만든 게임을 포트폴리오로 쓸 때 주의할 점
1인 개발에서 가장 흔한 실수는 범위를 너무 크게 잡는 것입니다. 큰 RPG를 반쯤 만들다 멈춘 프로젝트보다, 작은 퍼즐 게임 하나를 완성하고 다듬은 쪽이 훨씬 좋은 평가를 받습니다. 미완성 프로젝트는 '끝까지 만들지 못하는 사람'으로 읽힐 수 있습니다.
또 하나는 에셋 출처 표시입니다. 혼자 만들면 그래픽과 사운드를 외부 에셋으로 채우는 경우가 많은데, 어떤 것을 가져왔고 어떤 부분을 직접 구현했는지 문서에 분명히 적어야 합니다. 그래야 평가자가 지원자의 작업을 정확히 볼 수 있습니다.
코드도 '나만 알아보는 코드'가 되기 쉽습니다. 혼자 작업했더라도 함수와 변수 이름을 명확히 하고, 주요 시스템마다 짧은 설명을 붙여 두세요. 평가자는 그 코드를 처음 보는 사람이라는 점을 기억해야 합니다.
팀 프로젝트에서 내 몫을 분명하게 보여 주는 방법
팀 프로젝트를 정리할 때는 결과물 소개보다 본인 역할 설명에 더 많은 공간을 씁니다. 예를 들어 '전투 시스템 담당'이라고만 쓰기보다, 어떤 기능을 맡았고 어떤 구조로 만들었는지 구체적으로 적는 편이 좋습니다.
- 담당한 기능 목록과 그 기능의 코드 위치(저장소 폴더나 파일)
- 기획 문서를 받아 구현하면서 조율한 부분과 그 이유
- 병합 충돌, 일정 지연 같은 문제를 겪고 해결한 과정
- 팀원이 쓰기 편하도록 만든 도구나 공통 코드가 있다면 그 내용
- 프로젝트 이후 다시 만든다면 바꾸고 싶은 점
깃 커밋 기록은 이런 설명을 뒷받침하는 좋은 증거입니다. 커밋 메시지를 평소에 알아보기 쉽게 써 두면 나중에 따로 정리할 일이 줄어듭니다.
두 프로젝트를 한 포트폴리오에 담는 순서
두 종류를 모두 갖고 있다면 앞쪽에는 지원 직무와 가장 가까운 프로젝트를 둡니다. 클라이언트 프로그래머로 지원한다면 전투나 UI처럼 플레이에 직접 닿는 기능을 맡은 프로젝트가 먼저 보이는 편이 좋습니다. 1인 프로젝트는 그 뒤에 두고, 전체 구조를 혼자 설계했다는 점을 짧게 강조합니다.
각 프로젝트 첫 화면에는 개발 기간, 인원, 내 역할, 사용 엔진과 언어를 한 줄씩 정리합니다. 평가자는 여러 지원자의 자료를 빠르게 넘기며 보기 때문에, 이 정보가 맨 위에 있어야 프로젝트를 제대로 읽기 시작합니다. 플레이 영상과 빌드 파일, 저장소 링크도 바로 찾을 수 있는 위치에 두세요.
프로젝트 수를 늘리기보다 두세 개를 깊이 있게 설명하는 쪽이 낫습니다. 각 프로젝트에서 가장 어려웠던 문제 하나와 그 해결 과정을 적어 두면, 면접에서도 같은 이야기를 자연스럽게 이어 갈 수 있습니다.
상황에 따라 비중을 다르게 잡으세요
아직 게임을 하나도 완성해 본 적이 없다면 먼저 혼자서 작은 게임을 끝까지 만들어 보세요. 그 경험이 있어야 팀에 들어가서도 맡은 부분을 책임지고 끝낼 수 있습니다. 팀 프로젝트부터 시작하면 다른 사람의 코드에 기대어 기본기가 비어 있는 상태로 남기도 합니다.
이미 1인 프로젝트가 몇 개 있다면 이제는 팀 경험이 필요한 시점입니다. 게임잼, 학교 동아리, 교육 과정의 팀 프로젝트처럼 기획자와 아티스트가 함께 있는 환경이면 더 좋습니다. 실제 회사와 비슷한 역할 구조를 경험할 수 있기 때문입니다. 이때는 혼자서는 해 보기 어려운 일, 예를 들어 다른 사람이 쓸 수 있는 공통 기능 만들기나 코드 리뷰 주고받기를 일부러 맡아 보는 것도 좋습니다.
결국 혼자 개발이 맞는 사람은 기본기를 증명해야 하는 단계에 있는 사람이고, 팀 개발이 맞는 사람은 기본기 위에 협업 경험을 더해야 하는 사람입니다. 지금 가진 프로젝트로 어떤 구성이 부족한지 판단이 어렵다면, SBS아카데미게임학원 게임프로그래밍 과정 상담에서 포트폴리오를 함께 보며 다음 프로젝트를 혼자 할지 팀으로 할지 정해 보세요.
자주 묻는 질문
팀 프로젝트에서 제가 맡은 부분이 작으면 넣지 않는 게 나을까요?
작더라도 맡은 기능이 분명하고 그 과정에서 배운 점을 설명할 수 있다면 넣는 편이 좋습니다. 다만 다른 팀원의 작업을 본인 것처럼 보이게 쓰지 않도록 주의해야 합니다.
온라인으로 모인 팀 프로젝트도 협업 경험으로 인정되나요?
인정됩니다. 원격으로 일정과 작업을 어떻게 나눴는지, 어떤 도구로 소통했는지를 정리하면 오히려 좋은 이야깃거리가 됩니다.
1인 프로젝트를 여러 개 넣으면 팀 경험이 없어도 괜찮을까요?
실력 증명에는 도움이 되지만 협업 관련 질문에 답할 거리가 부족할 수 있습니다. 짧은 게임잼이라도 한 번 참여해 두면 좋습니다.
가까운 캠퍼스에서 게임프로그래밍 알아보기
사는 곳과 가까운 캠퍼스를 고르면 수업 내용, 오시는 길, 상담 신청을 한 번에 볼 수 있습니다.