유니티 개발자 포트폴리오에서 자주 보이는 실수 7가지

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

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

실수 1·2: 에셋이 결과물의 대부분이고, 튜토리얼 흔적이 그대로다

첫 번째 실수는 에셋 스토어의 그래픽, 캐릭터 컨트롤러, UI 패키지를 가져와 조립한 게임을 내 작업처럼 보여 주는 것입니다. 에셋을 쓰는 것 자체는 문제가 아닙니다. 실무에서도 많이 씁니다. 문제는 무엇이 에셋이고 무엇이 내가 만든 코드인지 구분되지 않는 경우입니다. 이동과 전투까지 패키지로 해결했다면 평가자가 볼 수 있는 내 코드가 거의 없게 됩니다.

사용한 에셋 목록과 용도를 저장소 설명에 적고, 핵심 게임플레이 로직은 직접 작성하세요. 그래픽은 단순한 도형이어도 괜찮습니다. 프로그래머 포트폴리오에서는 화려한 그래픽보다 직접 짠 시스템이 훨씬 중요합니다.

두 번째 실수는 튜토리얼 예제를 거의 그대로 낸 경우입니다. 유니티 공식 학습 자료나 유명 강의의 예제는 평가자도 대부분 알고 있습니다. 튜토리얼에서 출발했다면 원래 예제에 없던 기능을 설계해 추가하고, 무엇을 바꿨는지 분명히 적어 두세요.

실수 3: 모든 로직을 Update 하나에 몰아넣는다

유니티 입문자 코드에서 가장 많이 보이는 패턴은 플레이어 스크립트 하나의 Update 함수에 입력, 이동, 공격, 체력, UI 갱신을 모두 넣는 것입니다. 처음에는 편하지만 기능이 늘어날수록 수정할 때마다 다른 기능이 깨집니다. 평가자는 이런 코드를 보면 구조 설계 경험이 부족하다고 판단합니다.

역할별로 컴포넌트를 나누고, 서로의 상태를 직접 건드리기보다 이벤트로 알리는 방식으로 바꿔 보세요. 예를 들어 체력이 줄었다는 사실을 UI 스크립트가 매 프레임 확인하는 대신, 체력 컴포넌트가 바뀔 때만 알려 주는 식입니다. 매 프레임 오브젝트를 이름으로 찾거나 컴포넌트를 새로 가져오는 코드도 미리 저장해 두는 방식으로 정리하면 성능과 가독성이 함께 좋아집니다.

실수 4·5: 데이터가 코드에 박혀 있고, 프로젝트 정리가 안 되어 있다

네 번째 실수는 몬스터 체력, 공격력, 아이템 가격 같은 값을 코드에 직접 적어 두는 것입니다. 실무에서는 기획자가 이런 값을 자주 바꾸기 때문에, 프로그래머가 매번 코드를 고쳐야 하는 구조는 협업에 불리합니다. ScriptableObject(유니티에서 데이터를 별도 파일로 관리하는 방식)나 외부 데이터 파일로 값을 분리하면, 기획자와 함께 일할 수 있는 구조를 이해하고 있다는 점이 드러납니다.

다섯 번째 실수는 프로젝트 창이 정리되지 않은 상태입니다. 스크립트, 프리팹, 재질, 이미지가 한 폴더에 섞여 있거나, 이름이 New Material처럼 기본값으로 남아 있으면 평가자는 프로젝트를 열자마자 피곤해집니다. 폴더를 용도별로 나누고, 쓰지 않는 씬과 에셋은 정리하세요. 씬 계층 구조도 빈 오브젝트로 묶어 무엇이 어디에 있는지 한눈에 보이게 합니다.

• 폴더가 스크립트, 프리팹, 아트, 씬처럼 용도별로 나뉘어 있는가
• 기본 이름 그대로인 에셋과 쓰지 않는 파일이 없는가
• 반복해서 쓰는 오브젝트가 프리팹으로 관리되는가
• 씬 계층이 역할별로 묶여 있어 찾기 쉬운가

실수 6: 모바일을 목표로 하면서 성능을 확인하지 않았다

유니티로 지원하는 회사 중에는 모바일 게임을 만드는 곳이 많습니다. 그런데 포트폴리오 게임을 PC 에디터에서만 테스트하고, 실제 기기에서 돌려 보지 않은 경우가 흔합니다. 에디터에서는 매끄럽던 게임이 휴대폰에서는 프레임이 떨어지고 발열이 생길 수 있습니다.

실제 기기에 빌드해 실행해 보고, 프로파일러로 어디서 시간이 많이 드는지 확인한 기록을 남기세요. 총알이나 적을 계속 만들고 지우는 대신 미리 만들어 두고 재사용하는 오브젝트 풀링, 매 프레임 생기는 불필요한 메모리 할당 줄이기 같은 개선을 한 가지라도 전후 비교로 보여 주면 좋습니다. 측정한 기기와 조건도 함께 적어야 비교가 의미를 가집니다.

실수 7: 바로 해 볼 수 있는 빌드와 설명이 없다

마지막 실수는 평가자가 게임을 직접 해 볼 방법이 없는 것입니다. 저장소만 있으면 같은 버전의 유니티를 설치하고 프로젝트를 열어야 하는데, 평가자가 그 수고를 감수할 가능성은 높지 않습니다. PC용 실행 파일이나 웹 빌드를 함께 제공하고, 플레이 영상도 짧게 붙여 두세요.

저장소 설명에는 사용한 유니티 버전, 실행 방법, 조작법, 주요 기능, 내가 구현한 범위, 사용한 에셋 목록을 적습니다. 대표 기능의 코드 위치도 함께 적어 두면 평가자가 바로 핵심 코드로 들어갈 수 있습니다. 웹 빌드를 올렸다면 다른 브라우저에서도 실행되는지 한 번 더 확인하세요.

다시 손볼 때는 구조 정리 하나를 깊게 보여 줍니다

일곱 가지 실수를 다 고치려고 새 게임을 만들 필요는 없습니다. 지금 프로젝트에서 Update에 몰려 있던 로직 하나를 컴포넌트와 이벤트 구조로 나누고, 데이터를 분리하고, 그 전후를 비교해 보여 주는 것만으로도 충분히 좋은 사례가 됩니다. 리팩터링(동작은 그대로 두고 코드 구조를 개선하는 작업) 과정을 기록하는 것 자체가 실력을 증명하는 자료입니다.

내 유니티 프로젝트에서 어느 부분을 먼저 정리해야 효과가 클지 판단이 어렵다면, SBS아카데미게임학원 유니티3D 과정 상담에서 현재 프로젝트 구조를 함께 보며 보완 순서를 정해 보세요.

자주 묻는 질문

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

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

함께 읽으면 좋은 글