📘TIL - 언리얼 플러그인 생성 및 에셋 관리 구조 설계

문제 1. 플러그인 생성 후 빌드 실패

신규 프로젝트에서 플러그인을 생성하고 빌드를 시도했을 때
다음과 같은 에러가 발생했다.

• Target.cs 관련 RulesError
• UnrealEditor-MySpartaLog.lib 중복 생성 에러
• 모듈이 중복으로 빌드되는 문제

---

분석 1. 모듈 중복 등록 구조

에러 로그를 기반으로 원인을 추적한 결과,
플러그인 모듈이 두 개의 경로에서 동시에 빌드 대상으로 잡히고 있었다.

구조 다이어그램 (문제 상황)

[Project Target.cs]
        ↓
  MySpartaLog (직접 등록)
        ↓
-------------------------
        ↑
[Plugin .uplugin]
        ↓
  MySpartaLog (자동 등록)

원인 정리

구분	원인	영향
Target.cs	ExtraModuleNames.Add("MySpartaLog")	플러그인 모듈을 프로젝트 모듈로 인식
.uplugin	Modules 등록	플러그인 시스템에서 자동 로딩
캐시	Plugins/Intermediate 잔존	이전 빌드 정보 충돌
네이밍	플러그인명/모듈명 혼용	중복 인식 가능성 증가

결과적으로 동일 모듈이 두 번 컴파일 대상이 되면서 동일 lib 생성 충돌 발생

---

해결 1. 모듈 책임 분리 및 구조 정리

수정 구조 다이어그램

[Project Target.cs]
        ↓
  ModuleAndPlugin (프로젝트 모듈만)
        
[Plugin .uplugin]
        ↓
  MySpartaLog (플러그인 모듈)

적용 내용

• Target.cs에서 플러그인 모듈 제거
• 플러그인 모듈은 .uplugin에서만 관리
• Plugins 내부 Intermediate, Binaries 삭제
• 모듈 폴더 중복 제거
• 네이밍 통일

최종 구조

Plugins/
 └─ MySpartaLog/
     ├─ MySpartaLog.uplugin
     └─ Source/
         └─ MySpartaLog/

---

문제 2. 플러그인 에셋 관리 구조 부재

플러그인에 기본 에셋을 포함시키려 했지만

• 에셋을 어디에 둘지
• 코드에서 어떻게 참조할지
• 프로젝트별 커스터마이징을 어떻게 할지

명확한 기준이 없었다.

---

분석 2. 잘못된 에셋 참조 방식

초기 접근은 경로 기반 하드코딩 방식이었다.

ConstructorHelpers::FObjectFinder<UMaterial>(TEXT("/Plugin/..."));

문제점

문제	설명
강한 결합	코드가 특정 경로에 의존
유지보수 어려움	경로 변경 시 코드 수정 필요
확장성 부족	프로젝트별 커스터마이징 불가
로딩 문제	초기화 타이밍 의존성 발생

즉, 코드와 에셋이 직접 연결된 구조였다.

---

해결 2. 정석적인 플러그인 에셋 구조

전체 구조 다이어그램

[Plugin Content]
        ↓
[PrimaryDataAsset (에셋 묶음)]
        ↓
[DeveloperSettings (설정 선택)]
        ↓
[Plugin Code (Soft Reference 로딩)]

---

구성 요소 역할 정리

구성 요소	역할
Plugin Content	기본 에셋 저장
PrimaryDataAsset	에셋 묶음 관리
DeveloperSettings	프로젝트별 설정
Plugin Code	실제 로직 처리

---

적용 구조

플러그인 콘텐츠 구조

Plugins/MySpartaLog/Content/
 ├─ Data/
 ├─ Materials/
 ├─ Widgets/

---

에셋 묶음 (PrimaryDataAsset)

UCLASS()
class UMySpartaLogDefaults : public UPrimaryDataAsset
{
    GENERATED_BODY()

public:
    TSoftObjectPtr<UMaterialInterface> DefaultMaterial;
    TSoftClassPtr<UUserWidget> DefaultWidget;
};

---

설정 (DeveloperSettings)

UCLASS(Config=Game)
class UMySpartaLogSettings : public UDeveloperSettings
{
    GENERATED_BODY()

public:
    TSoftObjectPtr<UMySpartaLogDefaults> DefaultsAsset;
};

---

사용 흐름

Settings → DefaultsAsset → 실제 에셋 로드

auto Settings = GetDefault<UMySpartaLogSettings>();
auto Defaults = Settings->DefaultsAsset.LoadSynchronous();

---

개선 효과

Before / After 비교

구분	Before	After
에셋 참조	경로 하드코딩	DataAsset 기반
결합도	높음	낮음
확장성	낮음	높음
유지보수	어려움	쉬움
커스터마이징	불가능	가능

---

오늘의 정리

• 이번 작업의 핵심은 단순한 플러그인 생성이 아니라
  모듈 구조와 에셋 의존성 분리 설계였다.

모듈 → .uplugin 기준 관리
에셋 → DataAsset으로 묶기
설정 → DeveloperSettings로 분리
로드 → Soft Reference 사용