📘TIL-언리얼 로그 말풍선 플러그인 버그 수정

문제

기존 플러그인 구조와 말풍선 시스템의 기본 설계 및 1차 구현을 완료했지만,
실제 반영 단계에서 여러 가지 예상 못한 문제들이 한 번에 터졌다.

정리해보면 이런 상태였다.

• 말풍선은 뜨긴 하는데 로그 시스템과 완전히 연결되지 않음
• 일부 함수는 블루프린트에서 아예 노드가 안 보임
• 로그는 찍히는데 말풍선은 안 뜨고 PrintString만 나옴
• 위젯 접근 과정에서 protected 접근 에러 발생
• 말풍선이 월드에는 존재하지만 카메라 기준으로 보기 불편함
• 블루프린트에서 쓰려니 노드가 너무 길어지고 반복됨

결국 설계 자체는 틀리지 않았는데,
“실제로 쓰는 단계”에서 구조가 끊긴 상태였다.

---

분석

---

1. BlueprintFunctionLibrary 사용 방식 문제

처음에는 단순히 “함수 선언이 잘못됐나?” 정도로 생각했는데
문제는 생각보다 구조적인 부분이었다.

void LogTypedTextToActor(...)

이 상태에서는:

• 블루프린트에서 검색이 안 되거나
• 전역 함수처럼 노드가 나오지 않았다

반면 아래 함수는 정상 동작했다.

static void LogTextToActor(...)

---

여기서 깨달은 포인트

UBlueprintFunctionLibrary는 그냥 클래스가 아니라

• 객체를 만들지 않고
• 인스턴스 기반으로 호출되지 않고
• 전역 함수 묶음처럼 동작하는 구조다

그래서 함수는 반드시

객체 없이 호출 가능한 형태

여야 한다.

---

정리하면

구분	결과
static	블루프린트 전역 노드로 생성됨
non-static	호출 대상 없음 → 노드 자체가 안 만들어짐

이걸 이해하고 나니까
“왜 안 뜨는지”가 명확해졌다.

---

해결

UFUNCTION(BlueprintCallable)
static void LogTypedTextToActor(...)

이렇게 바꾸니까 바로 정상 동작했다.

---

여기서 얻은 감각

단순히 “static 붙여야 된다”가 아니라

BPLibrary는 애초에 객체가 없기 때문에
호출 주체가 필요 없는 함수만 허용된다

이게 핵심이었다.

---

2. 로그는 나오는데 말풍선이 안 뜨는 문제

이건 코드 문제라기보다
함수 역할을 혼동한 상태였다.

---

현재 구조

LogText
 → 로그만 출력

LogTextToActor
 → 로그 + 말풍선

LogTypedTextToActor
 → 로그 + 말풍선 + 스타일

---

실제 문제 상황

상황	원인
말풍선 안 뜸	LogText 사용
특정 경우만 뜸	TargetActor 잘못
들쭉날쭉	ShowSpeech 직접 호출

---

정리

LogText는 애초에 말풍선 안 뜨는 게 정상

이걸 모르고 계속 디버깅하고 있었다…

---

좋다. 이 부분은 핵심은 잘 잡혀 있는데 설명 밀도가 부족한 상태라서
디버깅 과정 + 왜 그렇게 되는지까지 살 붙여서 보강해줄게.

---

3. TargetActor 설정 문제

말풍선 출력은 단순히 “함수 호출”이 아니라
TargetActor를 기준으로 컴포넌트를 찾는 구조였다.

TargetActor
 → SpeechComponent 찾기
 → ShowSpeech 실행

---

문제 발생 조건

TargetActor가 말풍선 컴포넌트를 가지고 있지 않은 경우

이 상황에서는:

• 함수는 정상 호출됨
• 로그도 정상 출력됨
• 하지만 내부에서 컴포넌트를 못 찾기 때문에 아무 일도 안 일어남

→ 겉으로 보면 “함수가 안 먹히는 것처럼 보임”

---

디버깅하면서 헷갈렸던 포인트

• PrintString은 잘 나오니까 함수는 정상이라고 착각함
• 실제 문제는 호출 대상(TargetActor)이 틀린 것

---

해결

TargetActor = Self

또는

확실하게 SpeechComponent가 붙어있는 Actor 전달

---

정리

이 문제는 로직 문제가 아니라
"대상이 틀린 상태에서 정상 로직이 실행된 케이스"

---

4. protected 접근 문제

이건 단순 에러가 아니라
구조 설계를 잘못 잡았을 때 나오는 전형적인 문제였다.

---

문제 상황

GetSpeechWidget() protected
→ 외부에서 접근 시 컴파일 에러

처음에는 접근 제한을 풀어야 하나 고민했는데
그 방향이 아니라 구조를 바꿔야 하는 문제였다.

---

잘못된 접근

BPLibrary → Widget 직접 접근

이 구조는:

• UI 구현에 의존하게 됨
• 캡슐화 깨짐
• 나중에 위젯 바뀌면 전부 깨짐

---

수정한 구조

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

---

여기서 얻은 핵심 감각

외부는 "기능 요청"만 하고
실제 처리는 해당 레이어 내부에서 한다

---

정리

Widget은 데이터 표현 계층이고
외부에서 직접 접근하면 구조가 무너진다

---

5. 블루프린트 사용성 문제

기능은 되는데 쓰기가 불편한 상태였다.

---

기존 구조

Branch
 → LogTypedTextToActor(...)

이게 반복되니까:

• 그래프가 길어짐
• 가독성 떨어짐
• 실수 발생 가능성 증가

---

개선 방향

ShowErrorBubble("메시지")
ShowWarningBubble("메시지")

---

아직 적용 안 한 이유

지금 단계에서는

기능 검증이 먼저
→ 추상화는 나중

으로 가져가는 게 맞다고 판단

---

정리

지금은 구조 안정화 단계
→ 사용성 개선은 다음 단계

---

6. 테스트 구조 정리

여기서 제일 효과 본 부분이다.

---

테스트 방식

BeginPlay → 기본 말풍선 테스트

1 → 로그만
2 → 로그 + 말풍선
3 → Info
4 → Warning
5 → Error

---

왜 이 방식이 좋았냐면

• 기능을 완전히 분리해서 테스트 가능
• 어디서 끊기는지 바로 확인됨
• 재현이 쉬움

---

실제 디버깅 흐름

1번 정상 → 로그 문제 아님
2번 실패 → 말풍선 경로 문제
3~5번 비교 → 스타일 문제 여부 확인

---

정리

테스트를 기능 단위로 쪼개니까
문제 위치가 바로 드러났다

---

해결

---

1. BPLibrary static 적용

노드 자체가 안 보이던 문제 해결

---

2. 로그 → 말풍선 흐름 명확화

Blueprint
 ↓
LogTypedTextToActor
 ↓
SpeechComponent
 ↓
Widget

→ 중간 단계가 명확해짐

---

3. Component 중심 구조 유지

외부 → 요청
Component → 처리

→ 구조 안정화 + 재사용성 확보

---

4. TargetActor 기준 명확화

Self 기준으로 통일

→ 디버깅 포인트 감소

---

5. 카메라 대응 처리

Billboard 처리 추가

→ 실제 사용 가능 수준으로 개선

---

6. 로그 타입 분리

Info / Warning / Error

→ UI 확장 가능 구조 확보

---

구조 요약

[Blueprint]
   ↓ (요청)
[BPLibrary]
   ↓ (전달)
[SpeechComponent]
   ↓ (처리)
[WidgetComponent]
   ↓ (표현)
[Widget]

---

책임 분리 (조금 더 명확하게)

레이어	역할	핵심 포인트
BPLibrary	외부 인터페이스	어디서든 호출 가능
Component	핵심 로직	상태 + 제어 담당
WidgetComponent	월드 표현	위치 / 회전
Widget	UI	시각적 표현
DataAsset	스타일	색상, 타입
Settings	전역 설정	기본 값 관리

---

오늘의 정리

문제는 코드가 아니라 구조 이해 부족에서 발생했고, 디버깅을 통해 각 레이어의 책임을 구분하는 게 중요하다는 걸 느꼈다.