프롬프트 부채라는 문제
프롬프트를 직접 손으로 튜닝하면 모델 독립성은 사라진다
핵심 요약
- 프롬프트 부채란 — 자연어 프롬프트를 직접 손으로 튜닝할 때 쌓이는 기술 부채다. 개발 속도가 점점 느려지고, 팀 전체가 손을 못 대게 되며, 결국 특정 모델에 완전히 묶이는 결과를 낳는다.
- 왜 생기는가 — 자연어의 모호함과 확률론적 모델의 특성이 맞물리면, 같은 의도라도 표현 방식에 따라 출력이 달라진다. 원치 않는 동작을 고치려고 규칙을 반복 추가하다 보면 프롬프트는 점점 더 부서지기 쉬운 상태가 된다.
- 해결책: 측정으로 명세하라 — 동작을 산문이 아닌 평가(eval), 지표, 타입 명세로 정의해야 한다. 그러면 프롬프트는 직접 쓰는 것이 아니라 탐색하는 대상이 된다. DSPy나 GEPA 같은 도구가 이 작업을 자동화한다.
- 모델 독립성 회복 — 행동이 측정값으로 정의되면 새 모델 평가에 몇 주 대신 몇 시간이면 충분하다. 모델 교체는 재난이 아니라 일상적인 작업이 된다.
• • •
자연어 인터페이스 덕분에 AI 애플리케이션을 빠르게 프로토타이핑할 수 있습니다. 원하는 내용을 영어로 쓰고 최신 모델에 넘기면, 오후 한나절 만에 동작하는 프로토타입이 나옵니다. 놀라운 능력입니다. 일회성 작업에는 최적이죠. 하지만 신뢰할 수 있는 시스템을 구축하는 방법으로서 자연어 프롬프트는 함정입니다.
그런데 프로토타입을 그토록 손쉽게 만들어 주던 바로 그 평문 영어 프롬프트가, 시스템 동작을 명세하는 방식으로는 형편없다는 사실이 드러납니다. 청구서는 천천히 날아옵니다. 평범한 진전처럼 위장한 채로요. 그러다 결국 애플리케이션은 거의 움직이지 못하는 상태가 됩니다. 문제는 어느 하나의 프롬프트가 아닙니다. 자연어는 애초에 공학적 명세 언어가 아닙니다. 그걸 명세 언어처럼 쓰는 순간, 만들 수 있는 것의 천장이 조용히 내려오기 시작합니다.
프롬프트 부채의 덫
프롬프트 부채 (prompt debt) 의 첫 번째 증상은 반복 속도의 저하입니다. 사용자들이 오류를 신고하고 엣지 케이스를 발견할수록, 지침에 항목이 하나씩 더해지고 모델을 조금씩 올바른 방향으로 끌어당기게 됩니다. 원치 않는 동작이 계속되면 지침이 반복되고, 점점 더 강한 어조로 거듭됩니다. 어느새 프롬프트는 뒤엉킨 덩어리가 되고, 빠른 수정 하나가 이전 지침을 망가뜨립니다. 오류를 한 줄짜리 “핫픽스”로 처리할 수 없게 되고, 개발 사이클은 기어가는 속도로 느려집니다.
search_instructions, search_usage_guidelines, mandatory_copyright_requirements, hard_limits, self_check_before_responding, critical_reminders입니다.Fable의 시스템 프롬프트는 저작권 안내를 최대 여섯 번 반복합니다. search_instructions, search_usage_guidelines, mandatory_copyright_requirements, hard_limits, self_check_before_responding, critical_reminders라는 섹션 이름으로요.
다음으로, 프롬프트 부채는 팀 전체를 무력화시킵니다. 엣지 케이스와 대문자 경고문으로 가득 찬 취약한 프롬프트는 작성자 본인도 간신히 읽을 수 있는 수준이고, 동료들에게는 아예 해독 불가능합니다. 많은 팀이 이 문제를 완화하려고 프롬프트를 런타임에 조립되는 복잡한 템플릿으로 분리하고, 각 부분이 특정 관심사만 다루도록 나눕니다. 하지만 이 프롬프트 조각들도 함께 진화하면서 조건문의 덤불로 자라납니다.
마지막으로, 프롬프트 부채는 여러분을 단일 모델에 묶어 놓습니다. GPT-4o에서는 잘 작동하던 핫픽스가, 추론 대상을 GPT-5.4-mini로 바꾸는 순간 전혀 새로운 방식으로 실패합니다. 그래서 4o에 머물고, 인퍼런스 제공사에서 점점 자주 날아오는 지원 종료 이메일이 허풍이길 바라며, 더 저렴하고 빠르고 더 나은 모델을 누릴 기회마저 놓쳐버립니다. Datadog의 최근 보고서에 따르면 이는 흔한 상황입니다. 관찰된 트래픽에서 가장 많이 사용된 모델은 GPT-4o였습니다.
이 문제들 중 하나만 있다면 그냥 불편한 수준입니다. 하지만 셋이 합쳐지면 이야기가 달라집니다. 화려한 프로토타입에 머무느냐, 여러분·고객·비즈니스와 함께 성장하는 제품이 되느냐의 갈림길입니다. 반짝이던 신규 AI 기능은 얼어붙고, 전면 재구축 없이는 개선이 불가능하며, 낡아가는 모델에 갇히게 됩니다.
왜 프롬프트 부채가 생기는가
자연어 인터페이스는 훌륭합니다. 일회성 작업과 폭넓은 대화형 흐름에는 딱 맞는 방식입니다. 문제는 자연어를 통해 지속적인 시스템 동작을 정의하려 할 때 시작됩니다.
자연어의 모호함과 확률론적 언어 모델이 결합되면, 같은 의도라도 표현하는 단어에 따라 출력이 달라질 수 있습니다. 최근 연구에서, 동일한 사실을 담은 임상 질문을 환자의 목소리로 물었을 때와 의사의 목소리로 물었을 때, Opus 의 응답이 완전히 뒤집혔습니다. 열 번 모두 거부하던 것이 열 번 모두 답하는 쪽으로요.
단어 선택만이 문제가 아닙니다. 겉보기에 무관한 문장들이 같은 프롬프트 안에 있는 것만으로도 결과에 영향을 줄 수 있습니다. 하버드 연구에서 연구자들은 사용자가 응원하는 NFL 팀을 밝히는 것만으로도 모델이 민감한 주제에 답변을 거부하는 빈도가 달라진다는 사실을 발견했습니다. 관련 없는 진술이 예측할 수 없는 방식으로 추론 과정에 영향을 미칩니다. 그래서 수정을 추가할수록 프롬프트가 더 부서지기 쉬워지는 겁니다. 고집스러운 오류를 잡으려고 추가한 지침이, 어제까지 멀쩡히 작동하던 다른 지침의 해석에 영향을 미칠 수 있으니까요.
지침 반복은 프롬프트 부채를 가속화하지만, 원하는 동작이 모델의 학습과 충돌할 때는 불가피합니다. 이것이 바로 가중치와의 싸움이고, 이를 인식하고 나면 시스템 프롬프트 어디서나 보입니다. 예를 들어, 모델은 항상 대화를 이어가도록 훈련되어 있어서, ChatGPT의 이미지 프롬프트는 생성된 이미지가 반환됐을 때 LLM에게 응답하지 말라고 여덟 번이나 지시해야 했습니다.
우리가 분석한 코딩 에이전트 시스템 프롬프트에는 예외 없이 반복 지침, 강경한 경고, 대문자 요구가 담겨 있었습니다. Claude Code는 Opus에게 단일 응답에서 여러 도구 호출을 반환하라고 일곱 번이나 지시합니다. 가장 발전한 모델조차 프롬프트 작성자가 가중치와 싸우게 만듭니다. 유출된 Fable의 시스템 프롬프트는 특정 저작권 규칙을 여섯 번이나 재진술합니다.
이 사례들 중 어느 것도 고립된 경우가 아닙니다. 반복된 규칙이 우리가 검토하는 시스템 프롬프트 전반에 걸쳐 얽혀 있습니다. 고집스러운 오류들이 프롬프트를 빠르게 부풀리고, 편집할 때마다 취약성과 회귀 위험이 높아집니다.
더 나쁜 것은, 이 수정들이 단일 모델의 동작에 맞춰 조정된다는 점입니다. 버클리 주도 연구에서 신규 모델이 기존 에이전트를 망가뜨리기 때문에 기업들이 구형 모델을 유지한다는 사실이 확인됐습니다. 모델은 깔끔하게 버전관리된 소프트웨어가 아니기 때문입니다. 모델마다 가중치가 달라 예측 불가능하고 문서화되지 않은 방식으로 서로 다른 동작을 만들어냅니다. GPT-4o에서 완벽하게 작동하던 프롬프트가 GPT-5.5에서는 실패할 수 있습니다. Fable에 대한 Anthropic의 자체 릴리스 노트도 이전 모델을 위해 개발된 기능이 “출력 품질을 저하”시킬 수 있다고 경고합니다.
프롬프트 부채는 애플리케이션을 단일 모델에 가둬버립니다. 모델을 쉽게 교체하지 못하는 이유는 프론티어 랩들이 영리한 해자를 만들어서가 아닙니다. 부정확한 자연어 명세를 확률론적 모델에 맞춰 계속 다듬어온 결과입니다.
프롬프트 부채 예방하기
다행히 프롬프트 부채를 완화하는 방법을 이론으로만 논할 필요는 없습니다. 이미 한 분야가 길을 보여줬으니까요. 코딩 에이전트를 사용하는 프로그래머들은 모델 능력의 들쭉날쭉한 프런티어 위에 있는 아웃라이어들, 즉 모델이 할 수 있는 것의 최전선에 선 사람들입니다. 지난 몇 년간 그들은 모델이 코드를 더 많이 작성하면서도 유지보수 가능하고 모듈화된 소프트웨어를 내놓을 수 있는 모범 사례들을 발전시켜 왔습니다.
첫 번째 원칙: 산문이 아니라 측정값으로 시스템 동작을 명세하라. 모델의 출력이 확률론적이고 언어가 부정확할 때, 우리는 이를 제약할 단단한 경계를 만들어야 합니다. 평가(eval), 지표, 타입 명세가 바로 그것입니다. 이것들은 동료들이 읽고 기여할 수 있는 가독성 있는 공유 산출물이며, 취약한 프롬프트가 가로막던 협업을 가능하게 합니다.
최고의 엔지니어들은 이제 그 어느 때보다 많은 역량을 테스트에 쏟고 있습니다. 테스트는 이제 안전망이 아니라 모델이 제대로 활약하게 해주는 것이기 때문입니다.
두 번째 원칙: 프롬프트를 손으로 쓰는 것을 멈춰라. 후보를 평가할 수 있는 지표가 마련되면, 프롬프트는 더 이상 장인적으로 만드는 무언가가 아니라 탐색해야 할 무언가가 됩니다. 그리고 자연어가 허용하는 단어, 구절, 구조의 조합은 인간이 일일이 탐색하기에는 너무 광대합니다. 이 영역은 LLM이 탐색하도록 만들어진 지형입니다. DSPy와 GEPA 같은 시스템이 이 작업을 대신 관리하며, 여러분의 설계 기준에 맞게 프롬프트에 책임을 묻습니다.
프롬프트가 생성되고 프로그램의 동작이 측정값으로 정의되면, 더 이상 특정 모델에 묶일 이유가 없습니다. 새 모델 평가에 몇 주가 아니라 몇 시간이면 충분합니다. 더 빠르고 저렴한 모델이 등장하면 시도해볼 수 있습니다. 지원 종료 이메일이 와도 하루 만에 대안을 확보할 수 있습니다. 규제 이유로 철수하든(Anthropic의 Fable처럼), 노후화로 지원이 종료되든(지난주 Groq가 Llama-3.1-8b에 대해 발표한 것처럼), 수정은 재난 대응이 아니라 그냥 할 일이 됩니다.
성숙한 공학 분야는 예외 없이, 한때 자랑스럽게 손으로 하던 바로 그 일을 결국 기계에게 넘깁니다. 어셈블리는 컴파일러에게, 손으로 튜닝하던 쿼리는 플래너에게, 수동 메모리 관리는 (대부분) 기계에게 자리를 내줬습니다. 프롬프트 작성도 다르지 않습니다.
꼭 맞는 단어로 모델을 설득하는 것은 진짜 기술이고, 일회성 작업에서는 종종 최선의 방법입니다. 하지만 신뢰할 수 있고, 개선 가능하며, 이식 가능한 시스템을 구축하려면 프롬프트를 손으로 튜닝해서는 안 됩니다.
• • •
저자 소개: Drew Breunig — AI 제품 및 시스템에 대해 글을 쓰는 엔지니어·저술가입니다. dbreunig.com
참고: 이 글은 Drew Breunig이 2026년 6월 22일 게시한 아티클을 번역한 것입니다.
원문: The Problem is Prompt Debt — Drew Breunig (2026-06-22)
생성: Claude (Anthropic)