레벨 작업을 하다 보면 하나의 오브젝트로 여러 베리에이션을 만들어야 하는 상황이 자주 발생합니다. 예를 들어 동일한 구조물이지만 색상이나 재질만 다르게 표현해야 한다면, 매번 스태틱 메시의 머티리얼을 직접 교체하며 작업하는 방식은 비효율적입니다.
이럴 때 Enum(열거형)을 활용하면 하나의 Blueprint로 다양한 케이스를 깔끔하게 관리할 수 있습니다. 특히 Construction Script와 함께 사용하면, 에디터에서 값을 변경하는 즉시 결과를 확인할 수 있어 반복 작업 속도가 크게 향상됩니다.
Switch on Int와 String의 한계
분기 처리를 할 때 가장 먼저 떠올리는 방법은 Switch on Int나 Switch on String을 사용하는 것입니다. 하지만 실무에서 이 방식들은 명확한 한계를 드러냅니다.
Switch on Int의 가독성 문제
Switch on Int는 정수 값으로만 분기를 처리하기 때문에 숫자만 봐서는 그것이 무엇을 의미하는지 파악하기 어렵습니다. 0, 1, 2가 각각 “Stone”, “Wood”, “Metal”을 의미한다는 것을 Blueprint를 열어보지 않고는 알 수 없죠. 팀 작업 환경에서는 다른 작업자가 해당 Blueprint를 수정할 때 매번 맥락을 파악하는 데 시간을 소비하게 됩니다. 프로젝트 규모가 커질수록 이런 작은 비효율이 누적되어 전체 파이프라인의 속도를 떨어뜨립니다.
Switch on String의 디버깅 리스크
Switch on String은 Int보다는 직관적이지만, 더 치명적인 문제를 안고 있습니다. 문자열은 오타에 취약하며, 컴파일 단계에서 오류를 잡아낼 수 없습니다. “Stone”을 “Ston”으로 잘못 입력해도 컴파일은 정상적으로 진행되고, 런타임에서 Default 케이스로 넘어가 버립니다.
이런 버그는 게임을 실행해 봐야만 발견할 수 있고, 문제의 원인을 찾기 위해 여러 Blueprint를 확인하다 보면 디버깅 시간이 예상보다 길어집니다.
특히 빌드 직전에 발견된다면 출시 일정에 영향을 줄 수도 있는 치명적인 리스크입니다.
Enum을 통한 타입 안정성 확보
열거형(Enum)은 위의 두 가지 문제를 동시에 해결합니다. Enum은 선택 가능한 옵션을 미리 정의해 두는 타입으로, 컴파일 단계에서 타입 체크가 이루어지기 때문에 정의되지 않은 값이 들어갈 가능성을 원천 차단합니다. 동시에 각각의 값에 명확한 이름을 부여할 수 있어 Int의 가독성 문제도 해결됩니다.
Content Browser에서 우클릭 → Blueprint → Enumeration을 선택하여 새로운 Enum을 생성할 수 있습니다. 생성한 Enum에는 프로젝트에서 사용할 케이스들을 추가합니다. 예를 들어 재질 타입을 구분하는 Enum이라면 “Stone”, “Wood”, “Metal” 등의 항목을 정의하는 식입니다. 각 항목에는 Description을 추가할 수 있어 나중에 다른 팀원이 봐도 각 옵션의 용도를 명확히 이해할 수 있습니다.
생성한 Enum은 Blueprint의 변수로 추가하여 사용합니다. Instance Editable 옵션을 활성화하면 레벨에 배치된 각 Actor마다 다른 Enum 값을 설정할 수 있어, 하나의 Blueprint 클래스로 씬 전체의 다양한 Variation을 만드는데 사용할 수 있습니다.
방법1. Construction Script에서의 응용
하나의 오브젝트로 다양한 베리에이션을 만드는 응용 과정을 설명해보겠습니다.
Construction Script는 에디터에서 Actor가 배치되거나 속성이 변경될 때마다 실행되므로, Enum 값을 바꾸는 즉시 뷰포트에서 결과를 확인할 수 있습니다.
예를 들어 위 이미지처럼 오브젝트의 색을 선택하는 시스템을 구현한다고 가정해 봅시다.
Switch on Enum을 사용하면 각 분기가 명확하게 레이블링되어 있어 Blueprint 그래프만 봐도 전체 로직의 흐름을 한눈에 파악할 수 있습니다.
또한 새로운 재질 타입을 추가해야 할 때도 Enum에 항목을 추가하기만 하면 Switch 노드에 자동으로 핀이 생성되어 누락 없이 모든 케이스를 처리할 수 있습니다.
이런 구조는 특히 여러 아티스트가 동시에 작업하는 환경에서 강점을 발휘합니다. Topdown 토글로 정보가 포함된 분기점을 선택하면 되니 직관적이고, 오타같은 실수를 범할 걱정도 없어집니다. 그리고 각자 맡은 에셋의 variation을 자유롭게 테스트하면서도, 코어 로직은 하나의 Blueprint에서 중앙 관리되므로 버전 컨트롤에서의 conflict도 최소화됩니다.
Tip
예제 같이 하나의 함수를 가지고 데이터 테이블을 만들고 싶다면 분기점보단 데이터
Select방식을 사용하는게 낫습니다.
방법2. Select 노드를 활용한 최적화
분기가 단순히 하나의 함수를 만드는 용도라면, Switch보다 Select 노드가 더 적합할 수 있습니다. 특히 Material Instance나 Texture 같은 에셋을 선택할 때는 Select 노드가 그래프가 더 간결해지고, 관리 측면에서도 유리합니다.
Select 노드는 Index 입력에 연결된 값에 따라 해당하는 Option을 출력합니다. Enum 변수를 Select의 Index 핀에 직접 연결하면 Enum의 순서대로 Option 핀이 생성되므로, 각 Option에 해당하는 Material이나 Parameter 값을 연결하기만 하면 됩니다.
차이점
Switch on Enum은 각 케이스마다 별도의 실행 경로를 가지므로 복잡한 로직을 처리하기에 적합하지만, 단순히 데이터를 선택하는 용도라면 Select가 더 깔끔합니다.
실제로 하나의 함수(예: Set Vector Parameter Value)를 여러 케이스에서 반복 호출한다면, 분기를 나누는 것보다 입력 데이터만 바꿔주는 방식이 Blueprint 그래프의 복잡도를 낮추고 유지보수성을 높입니다.
이런 디테일한 선택의 차이가 프로젝트 후반부로 갈수록 작업 효율성에 큰 영향을 미칩니다. 특히 대규모 오픈월드 프로젝트에서 수백 개의 Prop Blueprint를 관리할 때, 초기에 구조를 얼마나 명확하게 설계했느냐가 최종 퀄리티 폴리싱 단계의 속도를 결정하게 됩니다.