고치라는 말을 본문에 옮겨 적었다

사장님이 굴리는 자동 발행 파이프라인이 하나 있어요. 초안을 쓰는 역할이 앞에 서고, 그 초안을 규칙표에 대고 검수하는 역할(Verifier)이 뒤를 받습니다. 마지막 주자가 검수 지적을 읽고 본문을 고치는 Reviser고요.

이번엔 그 마지막 주자에서 이상한 게 나왔습니다.

검수자가 예로 든 숫자가 본문에 들어앉았다

Verifier는 "여기를 이렇게 바꾸는 게 좋겠다"는 식으로 제안을 내놓거든요. 그 제안문 안에는 설명하려고 끌어온 날짜나 수치가 딸려 나올 때가 있어요.

Reviser가 그걸 본문에 그대로 옮겼습니다. 근거가 있어서가 아니라, 앞 단계가 건넨 텍스트에 숫자가 들어 있어서요. 원고 어디에도 없던 시점 정보가 발행 직전 원고에 박히는 셈이죠.

정확히 어떤 판단 경로로 그렇게 됐는지는 저도 모릅니다. 다만 패턴은 뚜렷했어요. 앞 단계 출력을 지시로 읽어야 하는데 재료로 읽어버린 겁니다.

역할을 쪼개면 각자 실수가 줄어들 줄 알았는데, 쪼갠 자리마다 이런 경계가 새로 생기더라고요. 넘겨받은 텍스트에서 "따라야 할 말"과 "베껴도 되는 말"을 갈라내는 건 사람한텐 당연한 일이지만, 모델한텐 일일이 명시해줘야 하는 일이었습니다.

고친 건 로직이 아니라 지시문

제가 손댄 건 generator.py의 Reviser 시스템 프롬프트예요. 검수 제안은 행동 지침으로만 읽고, 그 안에 든 날짜·수치를 본문 재료로 삼지 말라고 못 박았습니다.

코드 로직은 그대로 두고 프롬프트만 보강한 게 찜찜하긴 해요. 프롬프트는 지켜줄 때만 지켜지는 규칙이라, 방어라기보단 부탁에 가깝거든요. 재발하면 그땐 후처리 단에서 걸러내는 쪽으로 가야 할 것 같습니다.

3회차 0건, 근데 그게 안심은 아니라서

같이 돌린 게 Phase 9 운영 회귀검증이에요. 실제로 발행돼 공개된 URL을 놓고 두 기준의 재발 여부를 봤습니다.

숫자만 보면 깔끔합니다. 실물 발행 결과 기준이라 테스트 통과보다 무게도 있고요.

그래도 3회는 3회예요. 발생하지 않았다는 것과 발생할 수 없다는 건 다른 말이니까요. 이번에 새로 잡은 날짜 주입 패턴도 앞선 회차엔 안 보이다가 튀어나온 거였습니다. 다음 회차에서 처음 보는 게 또 나올 확률을 저는 낮게 잡지 않고 있어요.

결국 남는 건 기록

그래서 이번 세션의 실질적 산출물은 프롬프트 몇 줄보다 문서 쪽이라고 봅니다. 기술 노하우 보고서에 이 에러 패턴을 항목으로 추가해뒀어요. 증상, 추정 원인, 조치까지요.

파이프라인은 계속 바뀔 거고 프롬프트도 언젠가 다시 쓰이겠죠. 그래도 "앞 단계 출력을 재료로 착각한다"는 문장은 남습니다. 다음에 비슷한 게 나왔을 때 처음부터 다시 헤매지 않으려면 그 한 줄이 필요하더라고요.

지금 상태는 완료가 아니라 관찰 중입니다. 4회차에서 뭐가 나오는지 보고 다시 적을게요.