UE5 Delegate와 Event의 차이점

1. Delegate와 Event

언리얼 엔진 컨텍스트에서 '델리게이트(Delegate)'와 '이벤트(Event)'는 종종 혼용되지만, 명확한 개념적, 기술적 차이가 존재합니다. 이 둘의 관계를 이해하는 것은 견고하고 유연한 시스템을 설계하는 데 매우 중요합니다.

• Delegate (델리게이트): 기술적인 구현체(Implementation)입니다. C++의 함수 포인터를 대체하는 타입-안전(type-safe) 콜백 메커니즘 그 자체를 의미합니다. 델리게이트는 특정 시그니처를 가진 함수를 저장하고 호출할 수 있는 변수 또는 객체입니다.
• Event (이벤트): 개념적인 디자인 패턴(Design Pattern)이자, 델리게이트의 특수한 활용 사례입니다. 이벤트는 "어떤 일이 발생했음"을 외부에 알리는 역할을 합니다. 언리얼 엔진에서는 주로 TMulticastDelegate를 특정 접근 방식으로 노출시킨 형태를 '이벤트'라고 부릅니다. 특히 블루프린트에 노출되어 시각적으로 처리될 수 있는 델리게이트를 지칭하는 경우가 많습니다.

핵심 요약
모든 언리얼 '이벤트'는 내부적으로 '델리게이트'를 사용하지만, 모든 '델리게이트'가 '이벤트'의 역할을 하는 것은 아닙니다. 이벤트는 델리게이트를 사용하여 구현된 "발생-구독(Publish-Subscribe)" 패턴의 한 형태입니다.

2. 주요 차이점: 접근성과 소유권

가장 근본적인 차이점은 델리게이트의 기능을 누가, 어디까지 제어할 수 있는가에 대한 소유권(Ownership)과 접근성(Accessibility) 문제입니다.

구분	Delegate (일반적인 TMulticastDelegate)	Event (BlueprintAssignable 델리게이트)
소유권	느슨함. 델리게이트 변수에 접근할 수 있는 모든 외부 코드가 바인딩(Add), 해제(Remove), 그리고 호출(Broadcast)까지 가능	엄격함. 일반적으로 소유한 클래스만 호출(Broadcast)할 수 있고, 외부에서는 구독(Add)/구독 취소(Remove)만 가능하도록 설계.
접근 제어	C++의 일반 변수와 동일. public으로 선언 시 모든 기능이 외부에 노출됨.	UPROPERTY 매크로와 접근 지정자(private, protected)를 조합하여 노출 수준을 세밀하게 제어.
주요 목적	C++ 시스템 간의 유연한 콜백 및 통신.	블루프린트와의 상호작용. 클래스의 상태 변화를 외부에 안전하게 알리는 것.

코드 예시

사례 1: 일반적인 Public 델리게이트 (잘못된 이벤트 설계)

// HealthComponent.h
DECLARE_MULTICAST_DELEGATE(FOnHealthChangedSignature);

class UHealthComponent : public UActorComponent
{
    GENERATED_BODY()
public:
    // 누구나 호출(Broadcast)할 수 있어 위험!
    FOnHealthChangedSignature OnHealthChanged;

    void TakeDamage(float Damage)
    {
        Health -= Damage;
        OnHealthChanged.Broadcast(); // 소유자가 직접 호출
    }
private:
    float Health;
};

// SomeOtherClass.cpp
void USomeOtherClass::DoSomething(UHealthComponent* HealthComp)
{
    // 외부에서 멋대로 HealthComponent의 이벤트를 발생시킬 수 있음!
    // 이는 Health 데이터와 이벤트 발생 시점이 동기화되지 않는 버그를 유발.
    HealthComp->OnHealthChanged.Broadcast(); 
}

위 코드에서 OnHealthChanged 델리게이트는 public이므로, HealthComponent와 아무 상관없는 외부 클래스가 마음대로 Broadcast를 호출하여 이벤트를 발생시킬 수 있습니다. 이는 심각한 버그의 원인이 됩니다.

사례 2: 접근이 제어된 이벤트 (올바른 설계)

C#의 event 키워드처럼, 언리얼에서도 접근 지정자를 통해 이를 해결합니다. 델리게이트 자체는 private 또는 protected로 선언하고, 외부에서는 바인딩만 할 수 있도록 public 접근이 가능한 BlueprintAssignable 속성을 부여하는 것입니다.

// HealthComponent.h
DECLARE_DYNAMIC_MULTICAST_DELEGATE_OneParam(FOnHealthChangedSignature, float, NewHealth);

class UHealthComponent : public UActorComponent
{
    GENERATED_BODY()
public:
    // 외부에 노출된 이벤트. 외부에서는 Add/Remove만 가능.
    UPROPERTY(BlueprintAssignable, Category = "Events")
    FOnHealthChangedSignature OnHealthChanged;

    void TakeDamage(float Damage)
    {
        Health -= Damage;
        // Broadcast는 소유 클래스 내부에서만 호출.
        OnHealthChanged.Broadcast(Health);
    }

private:
    float Health;
};

// SomeOtherClass.cpp
void USomeOtherClass::DoSomething(UHealthComponent* HealthComp)
{
    // HealthComp->OnHealthChanged.Broadcast(100.f); // 컴파일 에러! Broadcast는 private 함수처럼 취급됨.

    // 외부에서는 구독만 가능.
    HealthComp->OnHealthChanged.AddDynamic(this, &USomeOtherClass::OnTargetHealthChanged);
}

UPROPERTY(BlueprintAssignable)이 붙은 델리게이트는 특별하게 취급됩니다. C++ 코드상에서는 public으로 선언되어 AddDynamic, RemoveDynamic 등의 바인딩 함수에 접근할 수 있지만, Broadcast 함수는 해당 클래스 외부에서 호출하려고 하면 컴파일 오류가 발생합니다. (정확히는 Broadcast 자체가 아니라, 블루프린트 VM을 통해 호출되는 내부 메커니즘에 의해 보호됩니다.)

이것이 델리게이트를 '이벤트'로 사용하는 핵심적인 설계 패턴입니다. 즉, 이벤트의 발생(Broadcast)은 오직 소유자만이 책임지고, 외부 구독자들은 알림을 받기만 하는 구조입니다.

3. 기술적 구현의 차이: Static vs Dynamic

'이벤트'로 사용되는 델리게이트는 대부분 블루프린트와의 연동을 위해 다이나믹 델리게이트(Dynamic Delegate)로 선언됩니다. 이는 또 다른 중요한 차이점을 만듭니다.

특징	일반 C++ 델리게이트 (주로 Static)	블루프린트 이벤트 (주로 Dynamic)
성능	빠름. C++ 가상 함수 호출 수준.	느림. 함수 이름(FName)을 사용한 리플렉션 기반 호출.
바인딩 대상	모든 C++ 호출 가능 대상 (멤버, 전역, 람다 등)	UFUNCTION() 매크로가 붙은 UObject 멤버 함수만 가능.
직렬화	불가. 바인딩 정보가 저장되지 않음.	가능. 레벨에 배치된 액터의 이벤트 바인딩 정보가 저장됨.
블루프린트	연동 불가.	완벽 연동. 이벤트 노드로 표시되고, 그래프에서 연결 가능.

결국, '이벤트'는 단순히 델리게이트를 사용하는 것을 넘어, 블루프린트 시스템과 통합되고, 소유권이 명확하며, 직렬화가 가능한 형태로 특화된 델리게이트의 활용 형태라고 정의할 수 있습니다.

4. 언제 무엇을 사용해야 하는가?

• 순수 C++ 델리게이트 (TDelegate, TMulticastDelegate)를 사용해야 할 때:
  • 고성능이 요구되는 C++ 내부 시스템 간의 통신.
  • 블루프린트에 노출할 필요가 전혀 없는 기능.
  • 게임플레이 로직보다는 엔진 서브시스템, 플러그인 등 저수준(low-level)에서 콜백이 필요할 때.
  • 람다(lambda)나 일반 C++ 클래스의 멤버 함수를 바인딩해야 할 때.
• 이벤트 (BlueprintAssignable 다이나믹 델리게이트)를 사용해야 할 때:
  • 블루프린트에서 이 이벤트에 반응하여 로직을 실행해야 할 때. (가장 중요한 기준)
  • UI 요소의 클릭, 액터의 오버랩 등 게임플레이와 직접적으로 관련된 이벤트를 외부에 알릴 때.
  • 레벨 에디터에서 디자이너가 두 액터를 연결하고 이벤트에 반응하도록 설정해야 할 때.
  • 이벤트 연결 정보가 레벨과 함께 저장되어야 할 때.

5. 요약

 델리게이트는 C++ 함수 포인터를 대체하는 기술적인 도구 그 자체입니다. 함수를 담을 수 있는 변수라고 생각하시면 됩니다. 반면, 이벤트는 이 델리게이트라는 도구를 사용해서 만든 디자인 패턴에 가깝습니다.

 

 가장 큰 차이는 '누가 이벤트를 발생시킬 수 있는가'에 대한 통제권입니다. 그냥 public 델리게이트를 쓰면, 아무나 그 델리게이트를 호출해서 이벤트를 마음대로 터뜨릴 수 있는 문제가 생깁니다. 하지만 우리가 흔히 '이벤트'라고 부르는 BlueprintAssignable 델리게이트는, 오직 이벤트를 소유한 클래스 내부에서만 터뜨릴 수 있고(Broadcast), 외부에서는 '구독'(AddDynamic)만 할 수 있도록 접근이 제어되어 있습니다.

 또한, 블루프린트와 연동되는 '이벤트'는 대부분 다이나믹 델리게이트로 만들어집니다. 그래서 속도는 C++ 전용 델리게이트보다 느리지만, 블루프린트 그래프에 노드로 표시되거나 레벨에 그 연결 상태가 저장될 수 있다는 큰 장점이 있습니다. 따라서 블루프린터에게 노출할 필요가 있다면 '이벤트' 패턴을 사용하고, 순수 C++ 내부에서 고성능으로 통신할 때는 일반 델리게이트를 사용하면 됩니다.