#2-2. codegen 페이로드 수정 (PR #70) 25.11.24 ~ 25.11.26

#문서 업데이트를 하려다 발견한 버그

PR #67이 머지된 다음 날이었다.

PR 리뷰 때 문서 업데이트는 별도 PR로 하겠다고 했었기에, Signal 페이로드 관련 문서를 작성하려고 signals.mdx 파일을 열었다.

문서를 작성하면서 예제 코드를 정리하다 보니, 뭔가 이상한 점이 눈에 들어왔다.

#하드코딩의 잔재

C++ 코드 제너레이터(cxx_generator.rs)를 다시 살펴보니, 내가 PR #67에서 구현할 때 페이로드 추출 로직이 onProgress와 onError라는 시그널 이름에 대해서만 하드코딩되어 있었다.

쉽게 말하면, onProgress나 onError라는 이름의 시그널에서만 페이로드가 제대로 추출되고, 다른 이름의 시그널에서는 페이로드가 무시되는 버그가 있었던 것이다.

사실 이건 내가 처음 구현할 때 예제 기반으로 코드를 작성하면서 발생한 문제였다. 예제에서 onProgress와 onError만 사용했기 때문에 그 이름들로 하드코딩한 거였는데, 실제로는 어떤 이름의 시그널이든 페이로드를 가질 수 있어야 했다.

내가 만든 버그를 내가 고치는 상황이라 좀 민망했지만, 뭐 발견하자마자 고치는 게 중요한 거니까.

#수정 내용

수정 자체는 간단했다. 하드코딩된 시그널 이름 체크를 제거하고, schema.signals에서 동적으로 if-else 체인을 생성하도록 변경했다.

// Before: 하드코딩된 이름 체크
if signal_name == "onProgress" { ... }
else if signal_name == "onError" { ... }

// After: schema 기반 동적 생성
for signal in &schema.signals {
    // 모든 시그널에 대해 페이로드 처리 코드 생성
}

변경된 파일은 4개뿐이었다. cxx_generator.rs에서 코드 생성 로직을 수정하고, 스냅샷 테스트를 갱신하고, 문서를 업데이트하고, 예제 코드를 정리했다.

PR #67에서 30개 넘는 파일을 건드린 것에 비하면 훨씬 작은 변경이었지만, 버그를 잡는다는 면에서는 더 중요한 수정이었을 수도 있다.

#문서 업데이트

버그 수정과 함께 원래 목적이었던 문서 업데이트도 같이 넣었다.

signals.mdx에 다음 내용을 추가했다:

• Signal<T>로 페이로드를 전달할 수 있다는 설명
• 페이로드 있는 시그널과 없는 시그널의 예제
• Rust 쪽에서 페이로드를 emit하는 방법
• Limitations 섹션 업데이트 (이제 페이로드를 보낼 수 있으니까)

기존에 "시그널은 데이터를 전달할 수 없다"고 적혀있던 부분을 수정하는 게 꽤 뿌듯했다. 내가 구현한 기능으로 인해 문서의 제한사항이 사라진 거니까.

#PR 제출과 리뷰

이번에는 리뷰도 빨랐다. 11월 24일에 올렸는데 11월 26일에 바로 리뷰가 왔다.

"LGTM. Thank you for taking care of this!"

별다른 수정 요청 없이 바로 승인이 되었다. 아마 변경 범위가 작고 명확했기 때문일 것이다.

#머지 2025-11-26

2일 만에 머지가 되었다. PR #67 때의 8일에 비하면 훨씬 빨랐다.

내가 만든 버그를 내가 고친 거라 자랑스러운 건 아니지만, 적어도 문서를 작성하는 과정에서 버그를 발견할 수 있었다는 건 나름 의미가 있다고 생각한다.

코드를 작성하고 나서 문서를 정리하는 게 그냥 귀찮은 일이 아니라, 자신의 코드를 다시 한번 검증하는 과정이기도 하다는 걸 느꼈다. 뭐 당연한 얘기를 새삼스럽게 깨달은 거지만.