📘TIL - 에러 로그 말풍선 플러그인 구현

문제

기존 플러그인의 기본 구조와 에셋 포함 방식에 대한 설계만 되어 있었고,
실제 기능은 거의 없는 상태였다.

정리하면 이런 상태였다.

• 플러그인 모듈 구조만 만들어진 상태
• 플러그인에 콘텐츠(에셋)를 포함시키는 방식만 설계됨
• 말풍선 UI 없음
• 캐릭터 연동 없음
• 로그와 연결된 구조 없음
• 블루프린트에서 사용하는 패턴도 정리되지 않음

그래서 단순히 UI 하나 만드는 게 아니라,

플러그인 내부에 콘텐츠를 포함하고
그걸 기반으로 동작하는 "로그 말풍선 시스템"을 실제로 구현 가능한 구조로 만드는 게 목표였다.

---

분석

1. 단순 WidgetComponent 방식은 한계가 명확했다

처음에는 자연스럽게
"캐릭터에 WidgetComponent 붙이고 텍스트만 바꾸면 되지 않나?"
라는 생각이 들었다.

구조로 보면 이런 형태다.

Character
 └─ WidgetComponent
      └─ Text Widget

빠르게 테스트는 가능하지만, 바로 문제가 보였다.

• 캐릭터 코드에 로직이 박힘
• 플러그인 구조랑 연결이 약함
• 프로젝트마다 재사용하기 어려움
• 스타일 교체가 번거로움
• 블루프린트 연결이 계속 반복됨

결론적으로
이건 “임시 UI” 수준이지 플러그인 구조로 보기엔 부족했다.

---

2. 플러그인은 결국 “코드 + 콘텐츠 분리”가 핵심이었다

오늘 구조를 잡으면서 가장 중요하게 정리된 포인트는 이거였다.

코드가 에셋을 직접 들고 있으면 안 되고
설정 데이터를 통해 간접적으로 참조해야 한다

그래서 구조를 이렇게 나눴다.

[Plugin Content]
 - 말풍선 위젯
 - 스타일 DataAsset

[Plugin Source]
 - SpeechComponent
 - Log BPLibrary
 - Settings

이렇게 분리하니까 자연스럽게 정리됐다.

• UI는 블루프린트에서 수정
• 로직은 C++에서 제어
• 스타일은 DataAsset으로 관리

---

3. 말풍선을 “UI”가 아니라 “로그 출력 방식”으로 보는 게 더 자연스러웠다

구현 방향을 잡으면서 가장 크게 바뀐 부분이 이거였다.

처음에는
“캐릭터 위에 말풍선을 띄운다” 였는데,

정리하다 보니 더 맞는 구조는 이거였다.

로그 시스템
 ├─ Output Log
 ├─ Screen Debug
 └─ Speech Bubble

즉 말풍선은 하나의 UI가 아니라
로그를 보여주는 출력 채널 중 하나로 보는 게 더 자연스러웠다.

이렇게 바꾸니까 확장이 쉬워졌다.

• 같은 로그를 OutputLog에도 남길 수 있음
• ScreenDebug도 같이 출력 가능
• 특정 액터에게만 출력 가능
• 타입별 스타일 적용 가능

---

4. 구조를 정리하면서 필요한 구성 요소가 명확해졌다

최종적으로 필요한 요소는 이렇게 정리됐다.

구성	역할
BPLibrary	외부에서 로그 호출
SpeechComponent	말풍선 실제 출력
Widget Base	UI 베이스
DataAsset	스타일 관리
DeveloperSettings	기본 설정
Widget BP	실제 UI 표현

---

해결

1. 플러그인 구조를 명확하게 정리

Plugins/
 └─ MySpartaLog/
     ├─ Source/
     └─ Content/

• Source → 로직
• Content → 에셋

이렇게 나누는 게 가장 깔끔했다.

---

2. DataAsset 중심 구조로 확정

핵심 흐름은 이렇게 잡았다.

DataAsset
  ↓
SpeechComponent
  ↓
WidgetComponent
  ↓
Widget

이 구조의 장점은 명확했다.

• 위젯 교체 쉬움
• 스타일 변경 쉬움
• 코드 수정 최소화
• 프로젝트별 오버라이드 가능

---

3. 캐릭터 직접 수정 대신 Component 방식 적용

Character
 └─ SpeechComponent

이 방식이 좋은 이유는 명확했다.

• NPC / 플레이어 모두 재사용 가능
• 캐릭터 코드 오염 없음
• 플러그인 교체 쉬움

---

4. BPLibrary로 “로그 → 말풍선” 흐름 통합

Blueprint
 ↓
Log 함수 호출
 ↓
SpeechComponent
 ↓
말풍선 출력

이 구조로 바꾸면서

• 블루프린트 사용성이 좋아졌고
• 반복 노드 연결이 줄어들었다

---

5. 로그 타입 도입

Info / Warning / Error

이걸 나누니까

• 색상 분리 가능
• 의미 전달이 명확해짐
• UI 확장하기 쉬워짐

---

6. 말풍선 방향 문제 해결

World Space 유지 + 카메라 바라보게 처리

Tick
 → 카메라 방향 계산
 → Widget 회전

이 방식이 가장 자연스러웠다.

---

7. UI는 전부 Widget BP로 위임

• C++ → 언제 띄울지
• Component → 어디에 띄울지
• DataAsset → 어떻게 설정할지
• Widget → 어떻게 생겼는지

이렇게 분리하는 게 가장 깔끔했다.

---

8. 블루프린트에서 자주 발생하는 에러 패턴 정리

유형	의미
Cast 실패	타입 불일치
IsValid 실패	참조 없음
Branch False	조건 미충족

이걸 로그 타입이랑 연결해서 쓰는 게 제일 깔끔했다.

---

9. Widget 직접 접근 대신 Component API로 제한

문제였던 부분:

외부에서 위젯 직접 건드림 → 접근 제한 / 결합도 증가

해결 방식:

외부
 ↓
Component 함수 호출
 ↓
Component 내부에서 Widget 처리

이게 훨씬 안정적이었다.

---

최종 구조

Blueprint
 ↓
BPLibrary
 ↓
SpeechComponent
 ↓
WidgetComponent
 ↓
Widget BP

---

오늘의 정리

오늘 작업은 단순히 말풍선을 구현한 게 아니라,
플러그인 구조 + 콘텐츠 에셋 + 컴포넌트 + 로그 시스템을 연결해서
재사용 가능한 형태로 설계 방향을 확정한 작업이었다.