언리얼 개발자 포트폴리오에서 자주 보이는 실수 7가지

이 글과 연결된 과정언리얼 과정 알아보기

언리얼 프로젝트는 파일이 크고 구조가 복잡해서 처음부터 폴더와 에셋을 정리하는 습관이 중요합니다. 수업에서는 회사에서 쓰는 이름 규칙과 폴더 구조를 기준으로 …

실수 1: 템플릿과 마켓 에셋이 결과물의 대부분이다

언리얼의 3인칭, 1인칭 템플릿은 캐릭터 이동과 카메라가 이미 갖춰져 있습니다. 여기에 마켓에서 받은 배경과 캐릭터를 얹으면 순식간에 그럴듯한 화면이 나옵니다. 문제는 평가자도 이 템플릿을 잘 안다는 것입니다. 기본 캐릭터가 그대로 뛰어다니는 화면을 보면 지원자가 직접 만든 부분이 어디인지부터 찾기 시작합니다.

템플릿에서 출발했더라도 이동, 전투, 상호작용 같은 핵심 시스템은 직접 설계해 바꾸고, 그 사실을 분명히 적으세요. 사용한 에셋과 템플릿의 출처는 설명 문서에 목록으로 정리합니다. 그래픽이 단순해지더라도 내가 만든 시스템이 분명하게 보이는 편이 프로그래머 포트폴리오로서는 훨씬 낫습니다.

실수 2·3: 블루프린트가 엉켜 있고, C++과의 역할 분담이 없다

두 번째 실수는 선이 거미줄처럼 얽힌 블루프린트를 그대로 캡처해 넣는 것입니다. 블루프린트(노드를 연결해 로직을 만드는 언리얼의 시각적 스크립트)는 빠르게 만들 수 있는 대신 정리하지 않으면 금방 읽기 어려워집니다. 하나의 이벤트 그래프에 모든 기능이 붙어 있으면 평가자는 협업하기 어려운 코드라고 판단합니다.

기능별로 함수와 매크로로 나누고, 노드 묶음에 주석 상자를 달아 무엇을 하는 부분인지 표시하세요. 반복되는 로직은 하나로 모으고, 선이 겹치지 않도록 정리하는 것만으로도 인상이 크게 달라집니다. 변수와 함수 이름도 기본값 대신 역할이 드러나는 이름으로 바꿔 두세요.

세 번째 실수는 C++과 블루프린트를 왜 그렇게 나눴는지 설명이 없는 것입니다. 실무에서는 성능이 중요하거나 구조의 뼈대가 되는 부분을 C++로 만들고, 자주 조정하는 값이나 연출을 블루프린트로 노출하는 방식이 많이 쓰입니다. 어느 쪽이든 정답은 없지만, 내 프로젝트에서 무엇을 어디에 두었고 그 이유가 무엇인지 설명할 수 있어야 합니다. 블루프린트만 썼다면 C++로 옮겨 본 기능 하나라도 추가해 두는 것을 권합니다.

실수 4: 엔진의 게임플레이 구조를 무시하고 만든다

네 번째 실수는 언리얼이 제공하는 게임플레이 구조를 쓰지 않고 모든 것을 캐릭터 하나에 넣는 것입니다. 언리얼에는 게임 규칙을 담당하는 GameMode, 플레이어 입력을 받는 PlayerController, 플레이어별 상태를 들고 있는 PlayerState 같은 역할 구분이 있습니다. 이 구분을 무시하고 점수, 입력, UI, 규칙을 캐릭터 블루프린트 하나에서 처리하면 기능이 늘어날수록 꼬이게 됩니다.

• 게임 규칙과 승패 판정이 게임 모드 쪽에 있는가
• 입력 처리가 컨트롤러와 캐릭터 사이에서 적절히 나뉘어 있는가
• 점수나 재화처럼 유지되어야 하는 값의 위치가 분명한가
• UI가 게임 로직을 직접 바꾸지 않고 값을 받아 보여 주기만 하는가

이 구조를 그림 한 장으로 정리해 포트폴리오에 넣으면 엔진을 이해하고 쓰는 개발자라는 점이 분명해집니다. 멀티플레이 기능을 넣었다면 어떤 값을 서버에서 판단하고 어떻게 다른 플레이어에게 전달했는지도 함께 적어 두세요.

실수 5·6: 화면은 무겁고, 성능을 확인한 흔적이 없다

다섯 번째 실수는 고사양 그래픽 설정만 켜 두고 성능을 신경 쓰지 않은 프로젝트입니다. 언리얼은 기본 설정만으로도 화면이 무거워지기 쉬워서, 평가자의 컴퓨터에서는 프레임이 크게 떨어질 수 있습니다. 게임이 끊기면 아무리 좋은 시스템도 제대로 평가받기 어렵습니다.

여섯 번째 실수는 성능을 확인한 기록이 전혀 없는 것입니다. 엔진의 통계 명령이나 프로파일링 도구로 어떤 부분이 무거운지 확인하고, 하나라도 개선한 사례를 전후 비교로 남기세요. 매 틱(매 프레임) 실행되는 블루프린트 로직을 필요할 때만 실행되도록 바꾼 경험처럼 작은 개선도 좋은 사례가 됩니다. 측정한 컴퓨터 사양과 조건은 함께 적어야 의미가 있습니다.

실수 7: 프로젝트가 너무 커서 받아 볼 수 없다

마지막 실수는 수십 기가바이트에 이르는 프로젝트를 그대로 저장소에 올리거나, 실행 파일 없이 프로젝트만 제공하는 것입니다. 평가자가 그 용량을 받아 엔진에서 여는 일은 거의 없다고 봐야 합니다. 쓰지 않는 에셋을 정리하고, 패키징한 실행 파일과 플레이 영상을 함께 제공하세요.

저장소 설명에는 엔진 버전, 실행 방법, 조작법, 주요 기능, C++과 블루프린트로 각각 구현한 부분, 사용한 에셋 목록을 적습니다. 대표 기능의 클래스 이름이나 블루프린트 위치를 함께 적어 두면 평가자가 핵심으로 바로 들어갈 수 있습니다. 패키징한 실행 파일은 다른 컴퓨터에서 한 번 실행해 본 뒤 올리세요.

다시 정리할 때는 시스템 하나를 구조부터 보여 줍니다

일곱 가지를 모두 고치려고 새 프로젝트를 만들 필요는 없습니다. 지금 프로젝트에서 대표 시스템 하나를 골라 블루프린트를 정리하고, 게임플레이 구조에 맞게 역할을 나누고, 일부를 C++로 옮긴 과정을 전후 비교로 기록해 보세요. 이 과정 자체가 언리얼을 깊이 이해하고 있다는 가장 확실한 증거가 됩니다.

어떤 시스템을 대표로 삼고 어디까지 C++로 옮길지 판단이 어렵다면, SBS아카데미게임학원 언리얼엔진 과정 상담에서 현재 프로젝트 구조를 함께 보며 정리 방향을 잡아 볼 수 있습니다.

자주 묻는 질문

가까운 캠퍼스에서 언리얼 알아보기

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

함께 읽으면 좋은 글