엔진·툴 프로그래머 포트폴리오에서는 '얼마나 깊이 이해하고 있는가'와 '다른 사람이 쓸 수 있게 만들었는가'가 함께 평가됩니다. 화려한 게임 화면보다 설계 문서와 측정 자료가 더 중요한 역할을 합니다. 어떤 작업을 어떻게 보여 줄지 정리했습니다.

넣으면 좋은 프로젝트 유형

모든 유형을 갖출 필요는 없습니다. 엔진 쪽을 목표로 한다면 자작 엔진과 성능 개선 사례를, 툴 쪽을 목표로 한다면 제작 툴과 엔진 확장을 중심에 둡니다.

프로젝트마다 첫머리에 한 줄 요약을 두면 읽는 사람이 빠르게 판단할 수 있습니다. 예를 들어 '기획 데이터의 잘못된 참조를 저장 전에 찾아내는 에디터 확장 기능'처럼 무엇을, 누구를 위해 만들었는지가 드러나게 씁니다.

자작 엔진 프로젝트 보여 주는 법

자작 엔진은 규모보다 설계 의도가 중요합니다. 어떤 구조로 나눴는지, 왜 그렇게 나눴는지, 어떤 부분을 직접 구현하고 어떤 부분에 외부 라이브러리를 썼는지를 분명히 적습니다. 엔진 위에서 돌아가는 작은 데모 게임을 함께 보여 주면 엔진이 실제로 쓰일 수 있다는 근거가 됩니다.

• 시스템 구조도: 렌더링, 입력, 리소스, 오브젝트 관리가 어떻게 연결되는지
• 핵심 구현 설명: 가장 고민한 부분 두세 개와 코드 일부
• 데모 영상: 엔진으로 만든 장면이나 간단한 게임

툴 프로젝트 보여 주는 법

툴은 사용 장면이 가장 강력한 자료입니다. 툴이 없을 때의 작업 과정과 툴을 쓸 때의 과정을 나란히 보여 주면 가치가 바로 전달됩니다. 실제 사용자에게 받은 피드백과 그에 따라 개선한 내용을 적어 두면, 사용자 관점에서 개발한다는 점을 보여 줄 수 있습니다.

사용 설명서도 포트폴리오의 일부입니다. 툴 프로그래머는 동료가 쓸 도구를 만드는 사람이므로, 짧고 명확한 설명서를 함께 제출하면 문서화 능력까지 증명할 수 있습니다.

툴의 화면 구성도 평가 대상이 됩니다. 버튼 이름이 명확한지, 잘못된 입력에 친절한 오류 메시지를 보여 주는지, 작업을 되돌릴 수 있는지 같은 요소는 사용자를 배려한 개발 습관을 보여 줍니다. 이런 부분을 캡처해 짧게 설명해 두면 좋습니다.

성능 개선 사례 정리

1. 문제: 어떤 상황에서 무엇이 느렸는지
2. 측정: 어떤 도구로 어디가 병목인지 찾았는지
3. 분석: 원인이 무엇이었는지(예: 메모리 할당이 너무 잦음, 캐시 효율이 낮은 데이터 배치)
4. 개선: 무엇을 바꿨는지
5. 결과: 같은 조건에서 측정한 전후 비교

수치는 직접 측정한 것만 쓰고, 측정 환경을 함께 적습니다. 개선 폭이 크지 않더라도 원인을 정확히 찾아낸 과정 자체가 좋은 평가를 받을 수 있습니다.

코드 저장소 정리

엔진·툴 포트폴리오는 코드를 직접 읽어 보는 경우가 많습니다. 설명 파일에 빌드 방법, 폴더 구조, 주요 파일 위치를 적고, 핵심 코드에는 설계 의도를 설명하는 주석을 남깁니다. 테스트 코드가 있다면 함께 올려 안정성을 고민했다는 점을 보여 줍니다.

상용 엔진의 소스 코드는 라이선스 조건에 따라 공개가 제한될 수 있으니, 엔진 확장 작업을 공개할 때는 본인이 작성한 부분만 정리해 올리고 라이선스 조건을 확인합니다.

제출 전 점검

• 빌드 방법대로 따라 하면 실제로 빌드가 되는가
• 구조도와 코드가 일치하는가
• 성능 수치에 측정 환경이 적혀 있는가
• 외부 라이브러리 출처와 라이선스를 밝혔는가

SBS아카데미게임학원 언리얼엔진(Unreal) 과정에서 다루는 C++ 프로그래밍과 블루프린트, 데이터 관리 내용은 엔진 확장과 에디터 툴 프로젝트를 시작하는 바탕이 될 수 있습니다.

자주 묻는 질문