prompt를 고치는 것은 코드에 주석을 바꾸는 것과 비슷하다 — 한 곳을 고치면 다른 곳에서 회귀가 난다. 마이리얼트립 팀이 도달한 답은 품질 개선의 대상을 바꾸는 것이었다. 실패가 나면 prompt를 만지는 게 아니라 Knowledge(Metric Registry·rule·skill)를 수정하고, 재발 방지 test를 추가한다. 실패 사례를 ‘지식 카탈로그의 버그 리포트’로 취급하는 순간, 품질은 소프트웨어처럼 단조 증가하기 시작한다.
이 관점의 전환이 중요한 이유: prompt는 버전 관리와 회귀 테스트가 어려운 반면, YAML 카탈로그와 rule은 diff가 가능하고 test로 고정할 수 있다. 즉 “무엇을 고쳤고, 그게 다른 걸 깨뜨리지 않았는가”를 기계적으로 답할 수 있는 형태로 지식을 옮기는 것이 운영 루프의 본질이다.
근거
품질을 prompt 수정으로만 올리려고 했더니, 한 곳을 고치면 다른 데서 회귀가 났어요. 그래서 운영 루프를 박았습니다 — 실패 사례 기록 → 원인 분석 → Knowledge 수정(Metric Registry/rule/skill) → 재발 방지 test 추가.
shell test와 eval이 실제 Slack 대화를 자동 재현해 정확성·행동 경로·안정성·형식 네 가지를 매번 검증한다 — 실패가 test suite에 편입되므로 같은 실패는 두 번 일어나지 않는다.
연결된 생각
- 20260515-trust-comes-from-tests-not-prompts — 같은 운영 루프의 ‘신뢰’ 측면. 이 노트는 ‘수정 대상이 어디인가’에 초점
- 20260612-metric-registry-as-ai-dictionary — 수정 대상이 되는 Knowledge 카탈로그의 구조
- 20260602-evaluation-first-then-build — evaluation 틀이 먼저 있어야 이 루프가 돌 수 있다