코더 관점에서 다시 보는 블루프린트

블루프린트는 '쉬운 코딩'이 아니라 '보이는 실행 모델'입니다

Unity에서 C#을 오래 쓴 개발자가 언리얼 엔진을 처음 열면 가장 먼저 당황하는 지점이 블루프린트입니다. 화면에는 코드 파일 대신 상자와 선이 가득합니다. 변수 하나를 읽는 데도 노드를 놓아야 하고, 함수 호출 하나를 하려 해도 핀을 끌어 연결해야 합니다. 코더 입장에서는 자연스럽게 이런 생각이 듭니다.

"이걸 왜 굳이 그림으로 해야 하지?"

하지만 블루프린트를 단순히 "비프로그래머를 위한 쉬운 도구"로 보면 금방 한계에 부딪힙니다. 노드를 외우는 동안에는 빠르게 느는 것 같지만, 조금만 복잡한 시스템을 만들면 그래프가 미로처럼 얽힙니다. AI에게 "체력 시스템 만들어줘"라고 시켜도 결과물이 맞는지 틀린지 판단하기 어렵습니다. 노드 이름은 그럴듯하고 선도 연결되어 있는데, 실행 시점이 틀렸거나 참조가 잘못되어 있으면 게임은 조용히 망가집니다.

그래서 이 장의 목표는 노드 이름을 많이 외우는 것이 아닙니다. 블루프린트를 언리얼의 실행 모델과 객체 통신을 시각화한 시스템으로 이해하는 것입니다. 블루프린트는 언리얼 에디터 안에서 노드 기반 인터페이스로 게임플레이 요소를 만드는 완전한 스크립팅 시스템입니다.¹ 코드를 없앤 것이 아니라 코드의 구조, 실행 순서, 데이터 흐름, 객체 참조를 눈에 보이게 펼쳐 놓은 것입니다.

코더에게 블루프린트는 새로운 언어라기보다 새로운 디버거에 가깝습니다. 텍스트 코드에서는 머릿속으로 그리던 흐름을, 블루프린트에서는 선과 핀으로 직접 봅니다. 함수 호출의 순서, 조건 분기, 변수 값의 이동, 객체 간 메시지 전달이 화면에 드러납니다. 이 관점을 잡는 순간 블루프린트는 답답한 장난감이 아니라 강력한 설계 도구가 됩니다.

C++ 위에 얹힌 시각적 레이어로 이해하기

언리얼에서 블루프린트와 C++는 서로 경쟁하는 두 세계가 아닙니다. C++가 엔진의 뼈대와 성능이 중요한 규칙을 만들고, 블루프린트가 그 뼈대 위에서 게임별 행동과 데이터를 빠르게 조립하는 관계에 가깝습니다.

C++ 클래스가 UCLASS, UPROPERTY, UFUNCTION 같은 매크로를 통해 언리얼의 리플렉션 시스템에 등록되면, 에디터와 블루프린트는 그 클래스와 변수, 함수를 알아볼 수 있습니다. 리플렉션은 프로그램이 자기 자신의 구조를 런타임이나 에디터에서 조회할 수 있게 해주는 장치입니다. 쉽게 말해 "이 클래스에는 어떤 변수가 있고, 어떤 함수가 있으며, 에디터에 노출해도 되는가?"를 엔진이 알 수 있게 만드는 시스템입니다.

블루프린트는 이 정보를 바탕으로 노드를 만듭니다. C++ 함수가 BlueprintCallable로 노출되어 있으면 블루프린트 그래프에서 함수 호출 노드로 나타납니다. C++ 변수가 EditAnywhere나 BlueprintReadWrite로 열려 있으면 Details 패널에서 수정하거나 그래프에서 읽고 쓸 수 있습니다. 그래서 블루프린트 노드를 볼 때는 "그림이다"가 아니라 "언리얼에 등록된 함수 호출 또는 데이터 접근이다"라고 읽어야 합니다.

블루프린트가 실행될 때는 그래프가 내부 표현으로 컴파일되고 런타임에 실행됩니다. 이때 성능상 C++보다 비용이 들 수 있으므로 모든 것을 블루프린트로만 만들겠다는 전략은 위험합니다. 반대로 모든 것을 C++로만 만들겠다는 전략도 언리얼의 생산성을 제대로 활용하지 못합니다. 실무적으로는 다음 경계가 유용합니다.

AI와 함께 작업할 때도 이 구분은 중요합니다. "대시 기능 만들어줘"라고만 말하면 AI는 모든 로직을 블루프린트에 밀어 넣을 수 있습니다. 하지만 "입력 이벤트와 쿨다운 타이머는 블루프린트로 만들고, 나중에 이동 계산을 C++ 함수로 분리할 수 있게 함수 단위로 구성해줘"라고 말하면 결과물이 훨씬 좋아집니다. AI에게 좋은 답을 얻으려면 사람이 먼저 경계를 알고 있어야 합니다.

노드 그래프를 읽는 세 가지 눈

블루프린트를 처음 볼 때 초보자는 노드 이름부터 읽습니다. Branch, Cast To BP_Player, Set Current Health, Print String 같은 이름을 하나씩 따라갑니다. 물론 노드 이름도 중요하지만, 그것만 보면 큰 그림을 놓치기 쉽습니다.

코더 관점에서는 블루프린트 그래프를 항상 세 겹으로 나누어 읽어야 합니다. 실행 흐름, 데이터 흐름, 참조 관계입니다.

실행 흐름은 흰색 실행 핀이 만드는 흐름입니다. 이벤트가 발생하면 어느 노드가 먼저 실행되고, 어느 조건에서 다음 노드로 넘어가며, 어디에서 멈추는지를 봅니다. 텍스트 코드의 제어 흐름과 같습니다.

데이터 흐름은 색이 있는 핀을 따라갑니다. Float, Boolean, Vector, Object Reference 같은 값이 어디에서 만들어지고 어디로 전달되는지를 보는 것입니다. 실행 선이 연결되어 있어도 데이터 핀이 잘못 연결되어 있으면 로직은 엉뚱한 값으로 실행됩니다.

참조 관계는 "이 노드가 누구를 대상으로 실행되는가?"를 따지는 눈입니다. 블루프린트에서 가장 흔한 오류는 함수 자체가 틀린 것이 아니라 대상 객체가 틀린 경우입니다. Set Visibility를 호출했는데 내가 끄고 싶은 UI가 아니라 다른 컴포넌트를 가리키고 있을 수 있습니다. Apply Damage를 호출했는데 데미지를 받을 Actor 참조가 비어 있을 수 있습니다. AI가 만든 그래프를 검토할 때도 가장 먼저 물어야 할 질문은 "이 함수는 누구에게 호출되고 있는가?"입니다.

예를 들어 캐릭터가 코인을 먹는 로직을 생각해 봅시다. 실행 흐름만 보면 OnComponentBeginOverlap → Cast To Player → Add Score → Destroy Actor로 그럴듯합니다. 데이터 흐름을 보면 Overlap 이벤트의 Other Actor가 Cast의 입력으로 들어가야 합니다. 참조 관계를 보면 Destroy Actor의 대상은 플레이어가 아니라 코인 자신이어야 합니다. 이 세 가지를 분리해서 보면, 그래프가 길어져도 길을 잃지 않습니다.

변수, 함수, 이벤트, 매크로를 코드 구조로 번역하기

블루프린트의 기본 요소는 코더에게 이미 익숙한 개념과 대응됩니다. 이름과 모양이 다를 뿐입니다. 여기서 중요한 것은 "무엇을 어디에 써야 하는가"입니다.

변수는 상태입니다. CurrentHealth, MaxHealth, bIsDashing, TargetActor처럼 객체가 기억해야 할 값을 담습니다. 블루프린트 변수는 Details 패널에 노출할 수 있고, 카테고리와 툴팁을 붙일 수 있습니다. 코더라면 변수 이름만 잘 지어도 그래프 절반은 정리됩니다. Value, Temp, NewVar_0 같은 이름은 AI가 자주 남기는 흔적이니 반드시 고쳐야 합니다.

함수는 재사용 가능한 행동입니다. TakeDamage, CanInteract, CalculateDashDirection처럼 이름만 읽어도 역할을 알 수 있어야 합니다. 함수 안의 그래프가 너무 길어지면 텍스트 코드에서 200줄짜리 메서드를 만든 것과 같습니다. 블루프린트에서는 선이 얽히기 때문에 더 빨리 무너집니다. 한 함수가 한 가지 일을 하도록 쪼개야 합니다.

이벤트는 실행의 입구입니다. 코드에서 Start(), Update(), OnTriggerEnter() 같은 콜백을 떠올리면 됩니다. 언리얼에서는 Begin Play, Tick, 입력 이벤트, Overlap 이벤트, Hit 이벤트 등이 대표적입니다. 이벤트는 내가 원하는 순간에 마음대로 호출되는 것이 아니라 엔진의 라이프사이클이나 특정 시스템에 의해 호출됩니다. 따라서 이벤트를 이해한다는 것은 곧 언리얼의 시간표를 이해한다는 뜻입니다.

매크로는 반복되는 노드 묶음을 줄이는 도구입니다. 하지만 매크로는 함수와 달리 내부 실행 흐름이 호출 지점에 펼쳐지는 성격이 있으므로, 지나치게 많이 쓰면 디버깅이 어려워집니다. "그래프가 보기 싫으니 일단 매크로로 감춘다"는 접근은 좋지 않습니다. 감추는 것이 아니라 의미 단위로 이름 붙이는 것이 목적이어야 합니다.

Begin Play, Tick, Construction Script의 시간표

블루프린트가 어려운 이유 중 하나는 "언제 실행되는가"를 놓치기 쉽기 때문입니다. 텍스트 코드에서는 파일 위에서 아래로 읽는 습관이 있지만, 언리얼의 게임플레이 코드는 엔진의 시간표에 따라 호출됩니다.

Construction Script는 Actor가 생성되거나 에디터에서 속성이 변경될 때 실행되는 구성용 스크립트입니다. 게임을 플레이하기 전에 배치된 Actor의 모양이나 컴포넌트 구성을 변수 값에 따라 바꾸는 데 유용합니다. Unity의 OnValidate와 비슷한 감각으로 받아들이면 쉽지만, 언리얼에서는 레벨 제작 워크플로우와 더 깊게 연결됩니다.

Begin Play는 게임플레이가 시작될 때 한 번 실행됩니다. 여기서는 참조를 캐싱하고, 이벤트를 바인딩하고, 초기 상태를 세팅하기 좋습니다. 예를 들어 플레이어 캐릭터 참조를 가져와 변수에 저장하거나, 체력 컴포넌트의 OnHealthChanged 디스패처에 UI 갱신 이벤트를 연결할 수 있습니다.

Tick은 매 프레임 실행됩니다. 강력하지만 위험합니다. Tick에 로직을 넣는다는 것은 60FPS 기준으로 초당 60번, 120FPS 기준으로 초당 120번 그 로직을 실행하겠다는 뜻입니다. 플레이어 하나가 Tick을 쓰는 것은 괜찮을 수 있지만, 적 200마리와 투사체 500개가 모두 Tick에서 Cast와 검색을 반복하면 성능은 빠르게 나빠집니다.

Event Graph는 런타임 이벤트들이 모이는 큰 작업대입니다. 처음에는 모든 로직을 Event Graph에 놓아도 괜찮습니다. 하지만 조금만 규모가 커지면 Event Graph는 곧 잡동사니 창고가 됩니다. 입력 처리, 전투, UI 알림, 사운드, 디버그 출력이 한 화면에 섞이면 AI도 사람도 제대로 읽지 못합니다. Event Graph는 "이벤트를 받아 적절한 함수로 넘기는 라우터" 정도로 유지하고, 실제 로직은 함수로 분리하는 습관이 좋습니다.

초보자가 가장 먼저 줄여야 할 것은 Tick입니다. 매초 한 번만 확인하면 되는 로직은 Timer로 바꾸고, 상태가 바뀔 때만 반응하면 되는 로직은 Event Dispatcher로 바꾸는 편이 좋습니다. "계속 확인하기"보다 "변할 때 알려주기"가 언리얼식 설계에 더 잘 맞습니다.

객체 통신의 3대 패턴: Cast, Interface, Event Dispatcher

게임은 객체들이 서로 이야기하는 프로그램입니다. 플레이어가 문에게 "열려라"라고 말하고, 적이 체력 컴포넌트에게 "데미지를 받았다"라고 알리고, 체력 컴포넌트가 UI에게 "체력이 바뀌었다"라고 알려야 합니다. 언리얼 블루프린트에는 이런 통신을 위한 대표 패턴이 있습니다. Cast, Blueprint Interface, Event Dispatcher입니다. 에픽 문서에서도 블루프린트 간 통신 방법을 별도 주제로 다룰 만큼, 이 선택은 게임 구조에 큰 영향을 줍니다.²

Cast는 상대의 정확한 타입을 알고 있을 때 쓰는 직접 통신입니다. 가장 직관적이고 빠르게 시작할 수 있지만, 의존성이 강해집니다. 플레이어가 BP_Door_Wood에 직접 Cast하면 나중에 BP_Door_SciFi, BP_Chest, BP_NPC와 상호작용할 때마다 Cast가 늘어납니다.

Blueprint Interface는 상대의 구체 타입을 몰라도 "이 메시지를 처리할 수 있는가?"만 보고 호출하는 방식입니다. 예를 들어 BPI_Interactable에 Interact 함수를 정의해 두면, 문, 상자, NPC, 버튼이 모두 각자 방식으로 Interact를 구현할 수 있습니다. 플레이어는 대상을 문으로 Cast하지 않고 "너 Interactable이니? 그렇다면 Interact 해줘"라고 말하면 됩니다.

Event Dispatcher는 한 객체의 사건을 여러 객체에게 방송하는 방식입니다. 체력 컴포넌트가 OnHealthChanged를 호출하면, UI, 사운드 시스템, 피격 이펙트, 퀘스트 시스템이 각각 이 이벤트를 듣고 자기 일을 할 수 있습니다. 호출하는 쪽은 누가 듣고 있는지 몰라도 됩니다. 코드에서 옵저버 패턴이나 C#의 event/delegate를 떠올리면 됩니다.

중요한 기준은 "누가 누구를 알아야 하는가?"입니다. Cast는 호출자가 수신자의 정체를 압니다. Interface는 호출자가 수신자의 역할만 압니다. Dispatcher는 발신자가 수신자를 거의 모릅니다. 프로젝트가 커질수록 두 번째와 세 번째 방식의 가치가 커집니다.

Cast는 나쁜 것이 아니라 비싼 결합입니다

블루프린트 조언을 듣다 보면 "Cast를 쓰지 마라"는 말을 자주 만납니다. 하지만 Cast 자체가 악은 아닙니다. 문제는 Cast가 코드 구조의 지름길로 남용될 때입니다.

플레이어가 게임 시작 시 자신의 HUD를 찾아 캐싱하는 Cast, Overlap된 Actor가 특정 투사체인지 확인하는 Cast, GameMode에서 현재 플레이어 컨트롤러를 특정 타입으로 다루는 Cast는 충분히 자연스럽습니다. 특히 작은 프로토타입에서는 Cast가 가장 빠른 길입니다.

문제는 Cast가 늘어날수록 클래스들이 서로의 구체 이름을 알아야 한다는 점입니다. BP_PlayerCharacter가 BP_Door_A, BP_Door_B, BP_Item_Coin, BP_Item_Key, BP_NPC_Merchant를 모두 Cast하기 시작하면 플레이어 클래스는 게임 세계의 온갖 세부사항에 묶입니다. 문 하나를 바꿨는데 플레이어 그래프를 수정해야 하는 상황이 생깁니다.

또 다른 문제는 Cast 실패 경로를 무시하는 습관입니다. Cast 노드에는 성공 실행 핀과 실패 실행 핀이 있습니다. 초보자는 성공 핀만 연결하고 실패는 방치합니다. 그러면 로직이 왜 실행되지 않는지 알 수 없습니다. AI가 만든 그래프에서도 이 문제가 자주 보입니다. 최소한 디버깅 단계에서는 실패 핀에 Print String을 연결해 "Cast Failed: Expected BP_PlayerCharacter"처럼 원인을 드러내야 합니다.

Cast를 쓸 때는 스스로에게 세 가지를 물어보면 됩니다. 이 객체의 정확한 클래스가 정말 필요한가? 같은 역할을 하는 다른 클래스가 앞으로 생길 가능성은 없는가? 이 Cast가 Tick 안에서 반복 실행되고 있지는 않은가? 세 질문에 모두 자신 있게 답할 수 있다면 Cast를 써도 괜찮습니다.

Interface는 역할을 기준으로 세계를 나누는 도구입니다

Blueprint Interface의 핵심은 타입이 아니라 역할입니다. 문은 문이고, 상자는 상자이며, NPC는 NPC입니다. 하지만 플레이어 입장에서는 모두 "상호작용 가능한 대상"일 수 있습니다. 이때 필요한 것이 인터페이스입니다.

BPI_Interactable을 만들고 Interact(Interactor) 함수를 정의해봅시다. 문은 이 함수를 받으면 회전 애니메이션을 재생합니다. 상자는 아이템 목록 UI를 엽니다. NPC는 대화를 시작합니다. 플레이어는 각 객체의 내부 사정을 몰라도 됩니다. 라인트레이스로 맞은 Actor가 인터페이스를 구현했는지만 확인하고 Interact 메시지를 보내면 됩니다.

이 구조는 AI에게 작업을 시킬 때도 강력합니다. "문, 상자, NPC를 각각 Cast해서 처리해줘"라고 말하면 AI는 분기와 Cast를 잔뜩 만들 가능성이 큽니다. 대신 "BPI_Interactable 인터페이스를 만들고, 플레이어는 라인트레이스 결과 Actor가 이 인터페이스를 구현했을 때만 Interact 메시지를 호출하게 구성해줘"라고 지시하면 훨씬 확장 가능한 구조가 나옵니다.

인터페이스를 설계할 때는 욕심을 줄여야 합니다. 하나의 인터페이스에 Interact, Open, Close, Talk, Buy, Sell, Highlight, TakeDamage를 모두 넣으면 이름만 인터페이스일 뿐 거대한 잡동사니가 됩니다. 인터페이스는 작고 선명해야 합니다. BPI_Interactable, BPI_Damageable, BPI_Highlightable처럼 역할별로 나누는 편이 좋습니다.

Event Dispatcher는 "나에게 관심 있는 사람은 들어라"라는 방송입니다

Event Dispatcher는 처음에는 조금 낯설지만, 언리얼 프로젝트가 커질수록 매우 중요해집니다. Dispatcher를 이해하면 Tick으로 계속 확인하던 많은 로직을 이벤트 기반으로 바꿀 수 있습니다.

체력 시스템을 예로 들어봅시다. 플레이어의 체력이 바뀔 때 UI 체력바가 갱신되어야 합니다. 가장 쉬운 방법은 UI가 Tick마다 플레이어의 현재 체력을 읽어 체력바를 업데이트하는 것입니다. 동작은 합니다. 하지만 매 프레임 확인할 필요가 없는 일을 계속 확인하고 있습니다.

더 나은 방식은 체력 컴포넌트에 OnHealthChanged Dispatcher를 만들고, 체력이 실제로 바뀌는 순간에만 호출하는 것입니다. UI는 Begin Play 또는 초기화 시점에 이 Dispatcher에 바인딩합니다. 체력이 변하면 UI가 알림을 받고 체력바를 갱신합니다. 나중에 피격 사운드, 붉은 화면 효과, 업적 시스템이 추가되어도 체력 컴포넌트는 그들을 직접 알 필요가 없습니다. 관심 있는 쪽이 알아서 구독하면 됩니다.

다만 Dispatcher에는 생명주기 관리가 필요합니다. 듣는 객체가 사라졌는데도 바인딩이 남아 있거나, 같은 이벤트에 여러 번 바인딩되면 예상치 못한 호출이 생길 수 있습니다. UI 위젯처럼 생성과 제거가 잦은 객체는 바인딩 시점과 해제 시점을 특히 신경 써야 합니다.

AI에게 Dispatcher 구조를 요청할 때는 "어떤 이벤트를 누가 발행하고, 누가 구독하며, 언제 바인딩하고, 언제 해제하는지"를 명시해야 합니다. AI는 이벤트 이름과 변수는 잘 만들지만, 바인딩 생명주기를 빠뜨리는 경우가 있습니다.

AI가 만든 블루프린트를 검증하는 법

AI가 만든 결과를 검토할 때 노드 이름을 하나씩 보며 "대충 맞는 것 같은데?"라고 판단하면 위험합니다. 앞에서 배운 세 가지 눈을 사용해야 합니다. 실행 흐름, 데이터 흐름, 참조 관계입니다.

먼저 실행 흐름을 봅니다. 이벤트가 적절한 시점에서 시작되는지 확인합니다. 초기화 로직이 Tick에 들어가 있지는 않은지, 한 번만 해야 할 바인딩이 매 프레임 반복되지는 않는지, Branch의 True와 False가 뒤바뀌지는 않았는지 봅니다.

다음으로 데이터 흐름을 봅니다. 함수 입력에 올바른 값이 들어가는지, 데미지 계산 결과가 체력 감소에 실제로 사용되는지, Vector와 Rotator가 혼동되지 않았는지 확인합니다. 특히 언리얼에서는 위치, 방향, 회전이 모두 비슷한 이름의 노드로 등장하기 때문에 AI가 그럴듯하게 잘못 연결하는 경우가 있습니다.

마지막으로 참조 관계를 봅니다. 함수 호출 대상이 누구인지, 변수에 저장된 Actor 참조가 언제 세팅되는지, 참조가 비어 있을 때의 방어 로직이 있는지 확인합니다. Is Valid 노드는 남용하면 지저분해지지만, 외부 객체 참조를 다룰 때는 적절한 안전장치가 됩니다.

검토할 때 다음 순서가 실용적입니다.

1. 그래프의 시작 이벤트를 찾고 실행 흐름을 왼쪽에서 오른쪽으로 따라갑니다.

2. Branch, Sequence, Loop처럼 흐름을 바꾸는 노드마다 조건과 종료 조건을 확인합니다.

3. 함수 호출 노드의 Target 핀을 보고 "누구에게 호출하는가?"를 확인합니다.

4. Object Reference 변수가 언제, 어디서 세팅되는지 역추적합니다.

5. Tick, Get All Actors of Class, Cast 반복처럼 비용이 큰 패턴이 있는지 찾습니다.

6. 실패 경로, None 참조, Cast 실패, 빈 배열 같은 예외 상황을 확인합니다.

7. 그래프가 너무 길면 함수, 인터페이스, Dispatcher로 나눌 수 있는지 판단합니다.

AI의 장점은 초안을 빠르게 만든다는 것입니다. 사람의 역할은 그 초안을 엔진의 실행 모델에 맞게 검증하고 구조화하는 것입니다. 이 능력이 없으면 AI는 빠른 손이 아니라 빠른 혼란이 됩니다.

작은 예제: 피격 가능한 상자를 설계해보기

간단한 상자를 하나 만들어봅시다. 플레이어가 공격하면 상자가 데미지를 받고, 체력이 0이 되면 깨지며, UI나 사운드 시스템이 그 사건을 들을 수 있어야 합니다.

초보적인 접근은 플레이어 공격 그래프에서 Cast To BP_BreakableBox를 하고, CurrentHealth 변수를 직접 감소시킨 뒤, 0 이하이면 Destroy Actor를 호출하는 것입니다. 작은 테스트에서는 잘 됩니다. 하지만 나중에 항아리, 나무통, 적, 훈련용 더미가 추가되면 플레이어 공격 그래프는 Cast 지옥이 됩니다.

조금 더 나은 설계는 BPI_Damageable 인터페이스를 만드는 것입니다. 이 인터페이스에는 ApplyDamage(DamageAmount, InstigatorActor) 함수를 둡니다. 상자, 항아리, 적은 모두 이 인터페이스를 구현합니다. 플레이어 공격은 맞은 대상이 BPI_Damageable을 구현했는지만 확인하고 메시지를 보냅니다. 대상별 체력 처리와 파괴 연출은 각 블루프린트 안에서 알아서 처리합니다.

여기에 Event Dispatcher를 더하면 구조가 좋아집니다. 상자 안에 OnDestroyedByDamage Dispatcher를 만들고, 상자가 파괴되는 순간 호출합니다. 레벨에 배치된 문이 이 이벤트를 듣고 열릴 수도 있고, 사운드 매니저가 깨지는 소리를 재생할 수도 있습니다. 상자는 "내가 깨졌다"고 방송할 뿐, 누가 반응하는지는 모릅니다.

이 예제에는 세 패턴이 모두 등장합니다. 플레이어가 자기 무기 컴포넌트를 직접 다룰 때는 직접 참조나 Cast가 괜찮습니다. 공격 대상에게 데미지를 전달할 때는 Interface가 좋습니다. 파괴 사건을 여러 시스템에 알릴 때는 Event Dispatcher가 좋습니다. 이 감각이 생기면 블루프린트 설계가 훨씬 덜 흔들립니다.

그래프를 깨끗하게 유지하는 코더의 습관

블루프린트에서 가독성은 미학이 아니라 생존 문제입니다. 텍스트 코드는 줄 수가 늘어나도 검색과 리팩터링이 어느 정도 버텨줍니다. 하지만 블루프린트 그래프는 선이 얽히면 읽는 속도가 급격히 떨어집니다. AI가 만든 그래프일수록 정리 작업이 필요합니다. AI는 기능을 만드는 데 집중하지, 팀의 가독성 규칙까지 자동으로 지켜주지는 않습니다.

가장 먼저 할 일은 이름을 고치는 것입니다. 변수, 함수, 이벤트 이름이 명확해야 합니다. DoThing, Check, Handle Event 같은 이름은 나중에 반드시 빚으로 돌아옵니다. CanStartDash, ApplyIncomingDamage, HandleHealthChanged처럼 조건, 행동, 반응이 드러나는 이름을 붙이세요.

그다음은 그래프를 함수 단위로 나누는 것입니다. Event Graph에는 이벤트 진입점만 남기고 실제 계산은 함수로 보냅니다. 예를 들어 입력 이벤트에서 바로 대시 로직 전체를 펼치지 말고, TryStartDash 함수를 호출하게 합니다. 그 안에서 CanDash, CalculateDashDirection, ConsumeDashCooldown 같은 작은 함수로 나누면 AI도 사람도 다음 수정 지점을 쉽게 찾습니다.

Comment Box와 Reroute Node도 적극적으로 사용해야 합니다. 코멘트는 "이 노드들이 무엇을 하는가"를 설명하는 표지판입니다. Reroute Node는 긴 선을 정리해 데이터 흐름을 읽기 쉽게 만듭니다. 다만 정리 도구가 구조적 문제를 가리는 데 쓰이면 안 됩니다. 선이 너무 길고 복잡하다면 예쁘게 휘게 만들 것이 아니라 함수를 나누어야 합니다.

마지막으로 Event Graph 하나에 모든 것을 넣지 마세요. 이것은 블루프린트 초보가 가장 흔히 빠지는 함정입니다. 코더라면 이미 알고 있습니다. 모든 코드를 main() 함수 하나에 넣는 프로그램은 오래가지 못합니다. 블루프린트도 같습니다.

블루프린트를 알면 AI의 속도를 통제할 수 있습니다

앞으로의 장에서는 AI에게 블루프린트를 시키는 구체적인 방법을 다룹니다. Claude나 ChatGPT에게 노드 구성을 설명하게 할 수도 있고, UnrealClaude 같은 에디터 통합 도구는 블루프린트 생성과 수정 기능까지 제공합니다.³ 하지만 도구가 강력해질수록 사람의 판단은 더 중요해집니다.

AI는 노드를 빠르게 놓을 수 있습니다. 하지만 어떤 로직이 Tick에 들어가면 위험한지, Cast가 구조적 결합을 늘리는지, Interface로 바꾸면 확장성이 좋아지는지, Dispatcher의 바인딩 시점이 안전한지는 사용자가 판단해야 합니다. 블루프린트의 본질을 모르면 AI가 만든 그래프를 "작동 여부"로만 평가하게 됩니다. 반대로 본질을 이해하면 "작동은 하지만 구조가 나쁘다"는 것도 보입니다.

이 장에서 가져가야 할 핵심은 단순합니다. 블루프린트는 노드 암기 과목이 아닙니다. 언리얼의 실행 흐름, 데이터 흐름, 참조 관계를 시각화한 시스템입니다. 변수와 함수는 코드의 구조를 이루고, 이벤트는 엔진의 시간표에 맞춰 실행을 시작하며, Cast·Interface·Dispatcher는 객체들이 서로 이야기하는 방식을 결정합니다.

이제 블루프린트를 볼 때 노드 이름만 보지 마세요. 흰색 실행 선이 언제 흐르는지, 색깔 핀이 어떤 데이터를 옮기는지, 파란 참조 핀이 누구를 가리키는지 보세요. 그 세 가지가 보이기 시작하면 AI가 만든 블루프린트도 더 이상 검은 상자가 아닙니다. 빠르게 만들고, 직접 검증하고, 자신 있게 고칠 수 있는 코드의 또 다른 형태가 됩니다.

참고

¹Blueprints Visual Scripting in Unreal Engine

²Blueprint Communications in Unreal Engine

³UnrealClaude: Claude Code CLI integration for Unreal Engine