🔁 Unity 어셈블리 순환 참조, 어떻게 해결할까?

EventBus 기반 구조로 완전히 디커플링하는 방법

---

🧩 문제 배경 Unity 프로젝트에서 .asmdef(Assembly Definition) 파일을 사용하면, 모듈 간 의존성을 명확히 나눌 수 있습니다. 하지만 규모가 커지고 모듈이 나뉘다 보면 필연적으로 다음과 같은 문제가 발생합니다:

✅ A 모듈에서 B를 참조하고 싶은데, ❌ B도 A를 참조하고 있어 에러가 발생하는 상황

대표적인 예가 **Core와 Services 간의 순환 참조 문제**입니다.

---

• Core 어셈블리: 전체 시스템의 중심 로직, 관리 클래스
• Services 어셈블리: 개별 기능 모듈 (예: UserService, GameLogicService)
• App 어셈블리: 초기 실행, UI, 씬 제어 등

CS0234: The type or namespace name 'Services' does not exist in the namespace 'MyProject'

---

🎯 해결 전략: EventBus를 통한 완전한 디커플링 서비스들을 직접 호출하지 않고, 이벤트 기반 메시지 전달 방식(EventBus)** 을 사용해** 모듈 간의 직접적인 의존성을 제거합니다.

---

🧱 구조 전환 전/후 비교

구조	Before	After (EventBus 방식)
의존성	Core → Services 직접 참조	Core → EventBus, Services → EventBus
호출 방식	직접 메서드 호출	이벤트 발행 및 구독
테스트성	어려움	쉬움 (모듈 독립)
확장성	낮음 (의존성 증가)	높음 (구독만 하면 됨)

---

🔧 핵심 구현 요소 ✅ 1. EventBus 시스템

public static class EventBus {
    private static Dictionary _handlers = new();

    public static void Subscribe(Action listener) { ... }
    public static void Unsubscribe(Action listener) { ... }
    public static void Publish(T evt) { ... }
}

✅ 2. 서비스 관련 이벤트 정의

public struct ServiceInitializeRequestEvent {}
public struct ServiceInitializedEvent {}
public struct ServiceQueryRequestEvent { public Action callback; }

---

🧩 구조 흐름 예시 ▶ 서비스 초기화 요청

// Core에서 발행
EventBus.Publish(new ServiceInitializeRequestEvent());

// 각 서비스에서 구독
EventBus.Subscribe(() => {
    InitializeSelf();
    EventBus.Publish(new ServiceInitializedEvent());
});

---

▶ 특정 서비스 조회 요청

// App에서 서비스 요청
EventBus.Publish(new ServiceQueryRequestEvent {
    callback = service => { _userService = service; }
});

// 서비스에서 구독 후 응답
EventBus.Subscribe>(evt => {
    evt.callback?.Invoke(this);
});

---

✅ 최종 구조

Assets/
├── Core/                 ← Core.asmdef
├── Services/             ← Services.asmdef
├── UI/                   ← UI.asmdef
├── EventBus/             ← EventBus.asmdef
├── App/                  ← App.asmdef

어셈블리	참조 대상
Core	✅ EventBus
Services	✅ EventBus
UI	✅ EventBus
App	✅ EventBus
EventBus	❌ 아무 것도 참조 안 함

---

• Core ↔ Services ↔ UI 사이 복잡한 호출이 얽히기 시작할 때
• 여러 서비스가 한 관리자의 호출을 받아야 할 때
• 서비스 간 직접 호출 없이 유연한 연결이 필요할 때
• 구조적으로 확장성과 테스트성을 중요하게 생각할 때

---

• Uber의 RIBs 아키텍처: 초기에는 모든 통신을 이벤트로 하려고 했으나, 결국 직접 참조도 허용함.
• FaceBook의 Flux: “모든 것이 이벤트”에서 시작했지만, Redux에서는 직접 접근도 지원하기 시작함.
• Unity의 ECS: 순수 이벤트 시스템을 시도했지만, ComponentSystem에서 직접 접근을 허용함.
• 혼합 접근법(Hybrid Approach)타입이 명확하고 강결합이 필요한 경우 인터페이스로 강하게 결합.
• 느슨한 결합이 필요한 경우 이벤트버스를 사용해서 느슨하게 결합.

// 직접 참조: 타입이 명확하고 강결합이 필요한 경우
public class GameManager : IGameService
{
    public GameState CurrentState { get; set; }
}

// EventBus: 느슨한 결합이 필요한 경우  
EventBus.Publish(new PlayerDiedEvent(player));

2. 계층별 역할 분담(Hierarchical Approach)

계층	모듈	설명	참조 대상
①	EventBus	이벤트 메시지 통신 허브	없음 ❌
②	Core	공통 유틸, 인터페이스, 모델	✅ EventBus
③	Services	게임 시스템 (플레이어, 매치 등)	✅ Core, EventBus
④	UI	화면 컴포넌트, 인풋 처리	✅ Services, Core, EventBus
⑤	App	Bootstrap, EntryPoint	✅ 모든 것

---

---