프랑켄슈타인 프롬프트가 태어나는 과정
프롬프트를 하나 쓴다. 누군가 버그를 신고한다. 문장 하나를 덧붙인다. 새 버그가 나오면 또 한 줄을 붙인다. 여섯 달이 지나면 4,000단어짜리 프롬프트 안에 아무도 알아채지 못한 모순이 박혀 있어. 이게 편집 표류고, 운영 프롬프트에서 가장 흔한 품질 저하야.
눈에 띄는 증상
- "be concise"와 "include all relevant context"처럼 서로 당기는 지시가 함께 있어.
- 이미 상위 시스템에서 고친 옛 버그를 막는 임시 문장이 남아 있어.
- 출처도 이유도 모르는 프롬프트에서 물려받은 상투적 문장이 있어.
- 응답 형식을 설명한 문장과 실제 스키마가 서로 달라졌어.
표류를 막는 정비 습관
- 더하기 전에 차이를 읽어 — 새 문장을 넣기 전에 기존 프롬프트 전체를 다시 봐.
- 덧붙이지 말고 고쳐 써 — 새 지시가 옛 지시와 겹치면 둘을 쌓지 말고 기존 문장을 바꿔.
- 임시 처방에는 날짜를 남겨 — 언제 왜 넣었는지 적고 원인이 사라지면 지워.
- 주기적으로 처음부터 다시 써 — 분기마다 같은 평가 모음을 돌려 성적이 가장 나쁜 프롬프트를 백지에서 다시 작성해. 대개 더 짧고 또렷해져.
- 책임자를 한 명 정해 — 누구나 편집하지만 아무도 책임지지 않는 프롬프트가 가장 빨리 표류해.