숏컷 코드
text
Inspector 연결 중심
-> UnityEvent
코드 중심 런타임 이벤트
-> C# event / Action문법과 예시
셋 다 "이벤트"지만 운영 방식이 다르다
UnityEvent는 Inspector에서 연결하기 쉽고, C# event는 코드 계약이 명확하며, Action은 빠르게 콜백을 넘기기 좋습니다.
이름이 비슷해 보여도 refactor 안전성, 디버깅 방식, 직렬화 가능성, 연결 위치가 다릅니다.
UI와 디자이너 연결이 중요하면 UnityEvent가 편하다
버튼 클릭, 간단한 UI 반응, 프리팹에서 눈으로 연결해야 하는 흐름은 UnityEvent가 편합니다. 하지만 연결이 Inspector에 숨어 있으므로 대규모 런타임 시스템의 핵심 이벤트까지 UnityEvent에만 의존하면 추적이 어려워집니다.
런타임 시스템 중심이면 C# event가 더 명확하다
체력 변경, 전투 종료, 상태 전이처럼 코드 규약이 중요한 이벤트는 C# event가 더 안전합니다. Action은 가볍지만, 공개 계약으로 오래 유지할 이벤트면
event로 감싸는 편이 의도와 캡슐화가 더 선명합니다.
Action은 내부 조립용 콜백에 가깝고, event는 공개 규약에 가깝다
Action은 빠르게 넘기기 좋지만 구독/해제 책임과 공개 범위가 흐려지기 쉽습니다. 반대로 event는 발행 권한을 감추고 구독만 허용하므로,
상태 변경 규약을 노출하는 API에는 더 적합합니다.
이벤트 표면을 고를 때 핵심
| 상황 | 적합한 선택 |
|---|---|
| Inspector에서 손쉽게 연결해야 할 때 | UnityEvent |
| 코드 중심 런타임 계약이 중요할 때 | C# event |
| 짧은 내부 콜백 전달이 필요할 때 | Action |
| 대규모 시스템 이벤트를 추적해야 할 때 | UnityEvent보다 C# event 우선 |
| UI 프리팹 단위 연결이 중요할 때 | UnityEvent 검토 |
특이 케이스와 주의할 점
흔한 실패는 모든 이벤트를 UnityEvent로 통일하는 것입니다. 소규모 UI는 편해도, 핵심 런타임 규약은 코드 표면에 드러나는 편이 유지보수에 더 유리합니다.
text
실패 예시
- 체력, 퀘스트, 전투 종료, 세이브 알림까지 전부 UnityEvent로만 연결
결과
- 누가 어디서 연결됐는지 코드 검색이 어려움
- refactor 안전성도 낮아짐참고 링크
1 sources