대학생이 졸업 전에 유니티 개발자 포트폴리오 만드는 법

이 글과 연결된 과정유니티 과정 알아보기

게임 클라이언트 개발자는 기획서에 적힌 규칙을 실제로 동작하는 시스템으로 바꾸는 사람입니다. 유니티 수업에서는 캐릭터 조작, 충돌과 물리, UI 연결, 저장과…

유니티 포트폴리오에서 평가자가 확인하는 것

유니티는 입문 자료가 많아 시작하기 쉬운 엔진입니다. 그만큼 비슷한 튜토리얼 결과물도 많아서, 평가자는 지원자가 엔진을 '따라 쓴' 것인지 '이해하고 쓴' 것인지 구분하려 합니다. 이를 가르는 기준은 대개 구조입니다. 게임 오브젝트와 컴포넌트를 어떻게 나눴는지, 씬 사이에서 데이터를 어떻게 전달했는지, 반복되는 오브젝트를 프리팹으로 관리했는지 같은 부분입니다.

프리팹은 여러 번 재사용할 오브젝트를 틀로 저장해 두는 유니티의 기능입니다. 적, 총알, 아이템처럼 반복되는 요소를 프리팹으로 관리하고, 수치는 코드에 직접 적지 않고 데이터 파일로 분리했다면 그 설계를 포트폴리오에서 드러내세요. 기획자가 코드를 건드리지 않고 수치를 바꿀 수 있는 구조는 실무에서 높이 평가됩니다.

C# 코드의 품질도 봅니다. 하나의 스크립트에 모든 기능을 몰아넣었는지, 역할별로 나눴는지가 코드 저장소에서 그대로 보입니다.

대학생에게 현실적인 프로젝트 구성

졸업 전 대학생이라면 큰 프로젝트 여러 개보다 완성도 있는 프로젝트 하나와 보조 프로젝트 한두 개가 현실적입니다. 중심 프로젝트는 시작부터 끝까지 플레이할 수 있고, 저장과 설정 같은 기본 기능까지 갖춘 게임이면 좋습니다. 보조 프로젝트는 특정 기능을 깊게 보여 주는 작은 데모로 구성할 수 있습니다.

• 중심 프로젝트: 실제 기기에서 실행되는 완성 게임
• 기능 데모: 인벤토리, 대화 시스템, 적 AI처럼 한 기능을 깊게 구현한 작은 프로젝트
• 팀 프로젝트: 기획자·아티스트와 협업해 만든 게임과 내가 맡은 기능
• 확장 경험: AR·VR이나 인터랙티브 콘텐츠처럼 게임 외 분야에 유니티를 써 본 작업

확장 경험은 필수는 아니지만, 유니티가 게임 밖에서도 쓰이는 만큼 지원할 수 있는 회사의 폭을 넓혀 줍니다. 수업이나 공모전에서 이런 작업을 해 볼 기회가 있다면 놓치지 마세요.

실제 기기 빌드가 차이를 만듭니다

에디터 안에서는 잘 돌아가던 게임이 휴대폰에 옮기면 느려지거나 화면이 잘리는 경우가 많습니다. 그래서 실제 기기에서 빌드하고 테스트해 본 경험은 유니티 개발자 포트폴리오에서 강력한 근거가 됩니다. 가지고 있는 휴대폰에 직접 설치해 보고, 가능하다면 화면 비율이 다른 기기 몇 대에서도 확인해 보세요.

기기 테스트를 하면 자연스럽게 최적화 과제가 생깁니다. 프레임이 떨어지는 장면을 찾고, 유니티의 프로파일러 같은 분석 도구로 원인을 확인한 뒤, 오브젝트 재사용이나 텍스처 크기 조정 같은 방법으로 개선해 보세요. 개선 전후의 프레임 변화를 기록해 두면 그대로 포트폴리오의 문제 해결 사례가 됩니다.

스토어 출시까지 해 볼 수 있다면 좋은 경험이지만, 계정 등록과 심사 조건은 플랫폼마다 다르고 바뀔 수 있으니 공식 안내를 확인하세요. 출시가 어렵다면 테스트용 배포 파일과 플레이 영상만으로도 충분합니다.

학기와 방학에 나눠 진행하는 순서

1. 학기 중: C# 문법과 객체지향 개념을 복습하고 유니티 컴포넌트 구조 익히기
2. 학기 중: 기능 하나씩 작은 데모로 만들어 보기(이동, 충돌, UI 연결 등)
3. 방학: 중심 프로젝트를 기획하고 프리팹과 데이터 구조를 먼저 설계한 뒤 구현하기
4. 다음 학기: 실제 기기에 빌드해 테스트하고 성능 문제를 찾아 개선하기
5. 다음 방학: 팀 프로젝트나 기능 데모를 추가하고 코드 리팩터링하기
6. 졸업 학기: 저장소, 영상, 기술 문서를 정리하고 코딩 테스트 준비 병행하기

3단계에서 구현 전에 구조를 먼저 설계하는 습관이 중요합니다. 바로 코드를 쓰기 시작하면 기능이 늘어날수록 고치기 어려워집니다. 간단한 구조도를 그리고 시작한 기록을 남겨 두면, 포트폴리오에서 설계 능력을 보여 주는 자료가 됩니다.

자주 보이는 약점과 보완법

무료나 유료 에셋을 많이 쓴 프로젝트는 무엇을 직접 만들었는지 헷갈리게 합니다. 에셋을 쓰는 것은 문제가 아니지만, 사용한 에셋 목록과 직접 구현한 부분을 분명히 구분해 적어야 합니다. 특히 기능이 담긴 코드 에셋을 썼다면 반드시 밝히세요.

또 하나는 기술 문서 없이 영상만 있는 경우입니다. 영상은 결과를 보여 주지만 어떻게 만들었는지는 보여 주지 못합니다. 핵심 기능 몇 가지에 대해 구조와 구현 이유를 짧게 정리한 문서를 꼭 덧붙이세요.

마지막으로 UI가 해상도에 따라 깨지는 문제도 자주 보입니다. 화면 비율이 바뀌어도 버튼과 글자가 제자리를 지키도록 기준점을 설정했는지 확인하세요. 이런 기본기가 실제 기기 빌드에서 바로 드러납니다.

졸업 직전 점검 목록

졸업 학기에는 빌드 파일이 다른 사람의 기기에서도 실행되는지, 저장소의 소개 문서에 실행 방법과 사용 버전이 적혀 있는지, 영상의 첫 부분에 핵심 장면이 나오는지 확인하세요. 유니티 버전에 따라 프로젝트가 열리지 않을 수 있으니 사용한 버전을 꼭 기록해 두는 것이 좋습니다.

면접에서는 프로젝트의 구조를 그림으로 설명해 보라는 요청을 받을 수 있습니다. 구조도를 보지 않고도 주요 클래스와 데이터 흐름을 설명할 수 있도록 미리 연습해 두세요.

유니티로 만든 게임은 있는데 구조와 기기 대응까지 포트폴리오로 보여 주기에 충분한지 확인하고 싶다면, SBS아카데미게임학원 유니티3D 과정 상담에서 지금의 프로젝트를 함께 보며 졸업 전까지 보완할 기능과 정리 순서를 정해 볼 수 있습니다.

자주 묻는 질문

가까운 캠퍼스에서 유니티 알아보기

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

함께 읽으면 좋은 글