고객 응대 봇이 어색한 문장을 내놓는다. "그 부분에서 무엇이 무너질 것 같으세요?" 같은 질문이 대화마다 튀어나온다. 당신은 시스템 프롬프트에 한 줄을 더한다 — "'무너질 것 같으세요'라고 묻지 마라." 다음 주에는 다른 고정 문구가 나온다. 또 한 줄을 더한다. 몇 주 뒤 프롬프트에는 금지 규칙이 스무 개 넘게 쌓여 있고, 그중 몇은 서로 부딪힌다. 이 글은 그 길로 가지 않는 법이다.
모델이 지시를 어기면 규칙을 어디에 둬야 하나
모델의 실수를 금지 문장으로 덧대지 말고, 규칙을 세 자리로 나눠 맡긴다 — 프롬프트에는 '무엇을·왜'의 원칙을, 코드에는 상황과 무관하게 늘 참이어야 하는 불변식을, 평가 세트에는 상황마다 달라지는 품질을.
셋은 잘하는 일이 다르다. 프롬프트는 모델이 판단할 방향을 준다. 코드는 판단 없이 기계적으로 확인할 수 있는 것을 확실히 막는다. 평가 세트는 사람이 보기에 좋은가를 바뀔 때마다 다시 잰다. 한 자리에 다른 자리의 일을 맡기면 비용이 커진다.
왜 "~하지 마라"를 한 줄씩 더하면 안 되나
금지 문장은 모델이 피할 길만 알려 주고 갈 길은 안 알려 준다. 특히 작은 모델은 막힌 문구 옆의 다른 고정 문구로 옮겨 갈 뿐이다. 실제로 한 대화 서비스에서 어색한 질문 하나를 금지하자 비슷한 틀의 다른 질문이 그 자리를 채웠고, 이렇게 덧댄 규칙이 몇 주 만에 20개를 넘어 서로 부딪혔다(2026-10, 실기기 대화를 보며 센 수).
함정이 하나 더 있다. 모델은 프롬프트 안의 예시 문장을 글자 그대로 베낀다. 규칙을 설명하려고 "예: '그때 어떤 기분이었어요?'"라고 적으면 그 문장이 그대로 대화에 나온다. 그래서 고칠 때는 두 가지를 한다.
- 금지 목록을 지우고, 그 금지들이 지키려던 목적을 원칙 몇 개로 다시 쓴다("상대가 이미 한 말을 되묻지 않는다 — 들었다는 것을 보여 주는 게 목적이다")
- 예시는 서로 많이 다른 것 3~4개만 태그로 감싸 두고, 그대로 쓰라는 문장이 아니라 결을 보여 주는 견본이라고 밝힌다
이 방향은 모델 제공사의 공식 지침과도 같다. Anthropic 의 프롬프트 지침은 하지 말 것 대신 할 것을 말하라고 하고, 예시는 다양한 것 몇 개를 태그로 감싸라고 한다.
코드로 막을 것과 막지 않을 것은 어떻게 가르나
"그럼 지켜야 할 건 전부 코드로 검사해서 다시 쓰게 하면 되지 않나?" 그 길도 막혀 있다. 상황별 품질 규칙("앞날을 걱정하는 사람에게는 구체적 장면을 캐묻지 마라")까지 코드로 걸러 다시 쓰게 하면 규칙은 다시 끝없이 늘고, 걸린 턴마다 다시 쓰는 호출 하나만큼 응답이 늦어진다 — 실측으로 턴당 1~2초였다.
가르는 기준은 하나다. 상황을 몰라도 참·거짓을 정할 수 있는가. 코드에 둘 만한 것:
- 안전 규칙 — 어떤 상황에서도 깨지면 안 되는 것
- 모델의 말과 서버 상태의 일치 — "아래 버튼을 눌러 주세요"라고 했는데 화면에 버튼이 없으면 안 된다
- 예시 베끼기 — 출력이 프롬프트 예시와 N자 이상 겹치면 다시 쓰게 한다
- 같은 질문 되풀이 — 직전 턴들과 거의 같은 질문
- 형식과 길이의 상한 — JSON 칸이 다 있는가, 너무 길지 않은가
상황에 따라 맞기도 틀리기도 한 것은 코드가 아니라 평가 세트(대표 대화 몇십 개를 정해 두고 바꿀 때마다 돌려 보는 묶음)로 잰다. 대화가 좋았는지는 사람이 판정하고, 통과/실패와 이유 한 줄로 남긴다.
코드 검사에 걸렸을 때 다시 쓰게 하는 법은
코드 검사에 걸린 출력을 통째로 다시 쓰게 하면 새 문제가 생긴다. 모델은 다시 쓰면서 멀쩡하던 다른 칸까지 바꾸고, 그 칸이 또 걸리고, 결국 칸이 빈 채로 저장된다. 한 구조화 출력에서 실제로 해석·인용 칸이 이렇게 비었다. 고치는 순서는 이렇다.
- 다시 쓰기 요청에 어느 칸이 왜 걸렸는지 적고, 나머지 칸은 그대로 두라고 한다
- 두 번 다 실패하면 두 응답에서 칸별로 통과한 값을 골라 합친다
- 각 규칙이 다시 쓰기를 몇 % 일으키는지 센다. 20% 넘게 걸리는 스타일 규칙은 지연과 빈 칸만 만든다 — 없애거나 느슨하게 한다(한 경우: 문장 40자 상한을 80자로)
분류기도 마찬가지다. 오탐("이것도 위험으로 잡았다")을 "이런 경우도 아니다" 예시를 덧붙여 막으면 다음 주제가 또 걸린다. 대신 판정 기준을 확인 가능한 사실이 있는가로 다시 쓰고, 긍정 판정에는 근거 문장을 원문에서 그대로 인용하게 한 뒤 코드가 원문과 대조해 인용이 없으면 기각한다 — 원칙(프롬프트)과 불변식(코드)이 짝을 이루는 꼴이다.
당신의 프롬프트에 바로 넣을 것
프롬프트를 고치는 사람(또는 고치는 에이전트)에게 이 지침을 준다:
모델 출력이 규칙을 어기면, 금지 문장을 추가하기 전에 다음을 차례로 확인한다.
1. 이 규칙은 상황을 몰라도 참·거짓을 정할 수 있는가?
- 예 → 코드 검사로 둔다. 걸리면 어느 칸이 왜 걸렸는지 적어 그 칸만 다시 쓰게 한다.
- 아니오 → 프롬프트의 원칙을 고친다(무엇을·왜). 평가 세트에 이 사례를 하나 더한다.
2. 프롬프트에 금지 문장("~하지 마라")이 몇 개인가? 5개를 넘으면 목적별 원칙으로 다시 쓴다.
3. 출력이 프롬프트 안의 예시와 겹치는가? 겹치면 예시를 줄이고 서로 다르게 바꾼다.
4. 각 코드 검사가 다시 쓰기를 몇 % 일으키는지 센다. 20%를 넘으면 규칙을 없애거나 느슨하게 한다.
확인 목록
- 프롬프트에 남은 금지 문장 수를 세 보았다
- 모든 예시가 서로 충분히 다르고, 출력과의 겹침을 코드가 잰다
- 코드 검사 목록에 상황을 알아야 판정되는 규칙이 섞여 있지 않다
- 다시 쓰기 요청이 걸린 칸만 고치게 한다
- 규칙별 다시 쓰기 비율과 그로 인한 지연을 재고 있다
- 상황별 품질은 사람이 판정한 평가 세트로, 바꿀 때마다 다시 잰다