산문처럼 프롬프트를 작성하는 것을 멈추세요: LLM 드리프트(drift)를 방지하는 4가지 계약 구조

대부분의 '프롬프트 엔지니어링' 조언은 문구 다듬기에 관한 것입니다. 실제 문제는 사람들이 이메일을 쓰듯이, 즉 산문으로 프롬프트를 작성하고 모델이 실행할 때마다 '드리프트(drift)'하는 것에 놀라워한다는 점입니다.

운영 환경에서 사용되는 프롬프트는 산문이 아닙니다. 그것들은 계약서입니다. 계약서는 네 가지를 명시적으로 정의해야 하며, 그렇지 않으면 모델은 통계적으로 가장 가능성이 높은 것으로 빈틈을 채우게 됩니다. 이것이 바로 여러분이 목격하고 있는 드리프트입니다.

4가지 구성 요소

두 번 모두 동일하게 작동해야 하는 모든 프롬프트는 이 네 가지 질문에 답해야 합니다:

역할(Role) — 누가 말하는지, 그리고 무엇을 최적화하는가?
작업(Task) — 단일 결과물은 무엇인가? (목록이 아닙니다. 한 가지만.)
제약 조건(Constraints) — 절대로 일어나서는 안 되는 것은 무엇인가?
출력 계약(Output contract) — 유효한 답변의 정확한 형태와, 입력이 이를 충족할 수 없을 때 무엇을 해야 하는가?

프롬프트에 이 중 어느 하나라도 빠지면 모델은 추측합니다. 추측은 적입니다.

이전 방식: 산문(prose)

You are a helpful assistant. Summarize the following customer review and tell me
if it's positive or negative and maybe what the main complaint is. Be concise.

이것은 입력에 따라 다섯 가지 다른 방식으로 실패하며, 어떤 것을 예측할 수 없습니다.

이후 방식: 계약(contract)

ROLE
You extract structured feedback from customer reviews. You optimize for accuracy,
not for making the review sound better.
...

두 번째 프롬프트가 더 길고, 그것이 요점입니다. 추가되는 모든 줄은 모델에게 매 실행마다 다르게 만들도록 내버려 두는 대신, 여러분이 한 번에 결정하는 것입니다.

출력 계약(Output contract)이 모두가 건너뛰는 부분입니다

탈출구(escape hatch)가 없는 스키마는 특정 실패를 유발합니다. 즉, 입력이 맞지 않을 때 모델은 스키마를 만족시키기 위해 조작합니다. 패배를 인정하기보다는 잘못된 형태이지만 유효한 객체를 반환하는 것을 더 선호한다는 것입니다. 따라서 항상 실패 형태를 명시적으로 정의하고(`{

이제 "드리프트(drift)"는 세 시스템 다운스트림에서 조용히 잘못된 답을 내놓는 대신, 크고 포착 가능한 오류가 됩니다.

행동 변화를 실제로 일으키는 제약 조건 (Constraints)

제약 조건 라인이 바로 승리하는 지점입니다. 약한 제약 조건은 아무 효과가 없습니다("정확하게 답변하라"); 강력한 제약 조건은 특정 실패 모드(failure modes)를 제거합니다:

"텍스트에 없는 불만 사항을 절대 꾸며내지 마라" → 환각성 세부 정보(hallucinated details) 생성을 막습니다.
"서문이나 마크다운 펜스(markdown fence)는 쓰지 마라" → 모델이 JSON을 json ... 안에 감싸는 것을 방지합니다.
"하나의 결과물만 제공하라" → 모델이 질문하지 않은 세 가지 답변을 하는 것을 막습니다.
"X라면, Y를 하라" → 모델에게 법적인 탈출구(legal exit)를 제공하여 꾸며내는 행위를 줄입니다.

모두가 _부정적_이거나 _조건적_이라는 점에 주목하세요. "도움이 되게 답변하라"는 반증할 수 없지만, "절대 꾸며내지 마라"는 테스트 가능합니다.

주의사항 (Gotchas)

느낌(vibe)이 아니라 계약(contract)을 테스트하세요. 20~50개의 입력/기대 쌍(input/expected pairs)을 유지하고 프롬프트를 건드릴 때마다 실행하십시오. "더 나은 느낌"이 드는 프롬프트 변경이라도 케이스의 10%를 조용히 망가뜨릴 수 있습니다.
추론 과정에 과도하게 제약 조건을 걸지 마세요. 작업에 추론할 여지가 필요하다면 모델에게 생각할 공간을 주세요. 단, 그 생각이 출력물로 새어 나오게만 하지 마십시오. (두 번의 호출 패턴(two-call pattern)을 사용하세요: 하나는 추론용, 하나는 형식 지정용.)
프롬프트에 코드를 쓰듯 버전 관리하세요. 프롬프트는 종속성(dependency)입니다. 변경 로그(changelog)와 함께 git에 저장되어 있지 않다면 회귀(regression)를 되돌릴 수 없습니다.
모든 제공업체에게 동일한 계약을 적용하세요. 모델 간 장애 조치(fail over)를 할 경우, 출력물 계약이 그들의 응답을 상호 교환 가능하게 유지하는 핵심 요소입니다.

이것이 중요한 이유 (Why this matters)

데모용 프롬프트와 프로덕션용 프롬프트 사이의 격차는 기발함(cleverness) 때문이 아니라 명시성(explicitness) 때문입니다. 검증할 수 있는 계약은 실제로 배포하고, 모니터링하며, 디버깅할 수 있는 프롬프트입니다. 그 외의 모든 것은 희망에 불과합니다.

저는 이와 같은 프로덕션급 시스템 프롬프트 32개(여섯 가지 범주로 구성되며, 각 범주는 엄격한 출력 계약을 가집니다)와 JSON 스키마 및 stdlib 전용 검증기 CLI를 여기에 모았습니다:

https://ancuboy.gumroad.com/l/promptops-pro

그리고 크리에이터/이커머스를 위한 더 큰 프롬프트 템플릿 은행이 여기 있습니다 (원하는 만큼 지불, 최소 $1):

https://ancuboy.gumroad.com/l/ai-ultimate-prompt-vault

피드백 환영합니다 — 특히 제가 목록에 올리지 않은 실패 모드를 확실하게 제거할 수 있는 제약 조건이 있다면 더욱 좋습니다.