영어로 원하는 걸 적어 모델에 넘기면, 작동하는 프로토타입이 오후 한나절 만에 나옵니다. 그런데 바로 그 손쉬움이 함정입니다. 빠르게 만든 그 데모가 좀처럼 믿을 만한 제품으로 자라지 못하고 어느 순간 옴짝달싹 못 하게 되는 이유가 있습니다.

데이터·AI 분야 엔지니어 Drew Breunig이 이 현상에 ‘프롬프트 부채(prompt debt)’라는 이름을 붙였습니다. 자연어 프롬프트는 일회성 작업에는 최적이지만, 시스템의 동작을 오래 규정하는 명세서로 쓰기 시작하면 청구서가 천천히, 평범한 진전처럼 위장한 채 날아온다는 것이 핵심입니다.

출처: The Problem is Prompt Debt – Drew Breunig

부채는 어떻게 쌓이는가

부채라는 비유가 잘 들어맞습니다. 처음엔 가볍습니다. 사용자가 오류를 발견하면 지시문을 한 줄 덧붙여 모델을 다잡습니다. 원치 않는 동작이 사라지지 않으면 같은 지시를 더 강한 어조로 반복합니다. 이렇게 쌓인 빚은 세 가지 형태로 돌아옵니다.

첫째, 반복 속도가 느려집니다. 프롬프트가 비대해지면서 한 줄짜리 핫픽스가 더는 통하지 않고, 새 수정이 어제 잘 되던 지시를 망가뜨리기 시작합니다.

둘째, 팀이 마비됩니다. 예외 처리와 대문자 경고로 뒤덮인 프롬프트는 작성한 본인조차 읽기 버겁고, 동료에게는 거의 해독 불가능한 문서가 됩니다.

셋째, 특정 모델에 묶입니다. GPT-4o에서 멀쩡하던 핫픽스가 다른 모델로 바꾸면 전혀 새로운 방식으로 깨집니다. 그래서 더 싸고 빠르고 좋은 모델이 나와도 옮기지 못한 채 낡은 모델을 붙들고 있게 됩니다. Datadog의 보고서에 따르면 관측된 트래픽에서 가장 많이 쓰인 모델이 여전히 GPT-4o였다고 합니다.

자연어라는 불안정한 재료

왜 이런 일이 생길까요. 근본 원인은 자연어가 부정확하고, 그 자연어를 받는 언어 모델이 확률적이라는 데 있습니다. 같은 의도라도 단어가 다르면 출력이 달라집니다.

한 연구에서는 똑같은 사실을 담은 임상 질문을 환자의 말투로 물었을 때와 의사의 말투로 물었을 때, 모델(Opus)이 열 번 모두 거절하던 것에서 열 번 모두 답하는 쪽으로 뒤집혔습니다. 말투만 바꿨을 뿐인데 정반대 결과가 나온 겁니다. 하버드 연구에서는 한술 더 떠서, 사용자가 응원하는 NFL 팀을 언급한 것만으로 민감한 질문에 대한 거절 빈도가 달라졌습니다. 질문과 아무 상관 없는 문장이 추론 과정에 영향을 준 것이죠.

문제의 본질은 여기서 드러납니다. 지시를 하나 더 추가하면 그 지시가 어제까지 멀쩡하던 다른 지시의 해석까지 흔들 수 있습니다. 프롬프트가 고칠수록 더 부서지기 쉬워지는 이유입니다.

가중치와 싸우기

지시를 반복하게 되는 데는 또 다른 이유가 있습니다. 우리가 원하는 동작이 모델이 학습한 성향과 어긋날 때입니다. Breunig은 이를 ‘가중치와 싸우기(fighting the weights)’라고 부릅니다.

증거는 시스템 프롬프트 곳곳에 있습니다. 과거 ChatGPT의 이미지 프롬프트는 생성된 이미지를 반환할 때 답하지 말라는 지시를 무려 여덟 번 반복했습니다. 모델이 대화를 계속 이어가도록 학습돼 있었기 때문입니다. Claude Code는 한 응답에 여러 도구 호출을 묶어 반환하라고 Opus에게 일곱 번 말합니다. 한 모델의 시스템 프롬프트는 특정 저작권 규칙 하나를 여섯 번이나 다시 적어 둡니다. 같은 말을 여러 번 해야 겨우 말을 듣는다는 건, 한 번으로는 듣지 않는다는 뜻입니다.

이 수선이 특정 모델 하나에 맞춰져 있다는 점이 결정타입니다. 버클리 주도 연구는 기업들이 낡은 모델에 머무는 이유로, 새 모델이 기존 에이전트를 망가뜨리기 때문이라는 점을 짚었습니다. 모델은 깔끔하게 버전 관리되는 소프트웨어가 아니라, 가중치가 다르면 예측 불가능하고 문서화되지 않은 방식으로 다르게 행동하는 존재이기 때문입니다.

코딩 에이전트가 보여준 길

해법은 멀리 있지 않습니다. 코딩 에이전트를 쓰는 프로그래머들이 이미 길을 보여줬다고 Breunig은 말합니다. 이들이 다듬어 온 방식의 핵심은 두 가지입니다.

첫째, 동작을 산문이 아니라 측정으로 명세하는 것입니다. 출력이 확률적이고 언어가 부정확하다면, 단단한 경계를 따로 세워 가둡니다. 평가(evaluation), 지표, 타입이 명시된 명세가 그것입니다. 이것들은 동료가 읽고 함께 고칠 수 있는 공유 가능한 산출물이라, 부서지기 쉬운 프롬프트가 막아 온 협업을 다시 가능하게 합니다. 그래서 뛰어난 엔지니어일수록 이제 테스트에 더 많은 시간을 씁니다. 테스트가 더는 안전망이 아니라, 모델이 마음껏 일하게 풀어 주는 장치가 된 셈입니다.

둘째, 프롬프트를 손으로 쓰지 않는 것입니다. 후보를 점수 매길 지표가 있으면, 프롬프트는 더 이상 공들여 빚는 대상이 아니라 탐색하는 대상이 됩니다. 자연어가 허용하는 단어와 구조의 경우의 수는 사람이 일일이 손볼 수 있는 범위를 한참 넘어섭니다. 이건 원래 언어 모델이 잘하는 영역이고, DSPy나 GEPA처럼 이 작업을 대신 맡아 주는 시스템이 이미 나와 있습니다.

손으로 하던 일을 기계에 넘긴다는 것

프롬프트가 자동으로 생성되고 프로그램의 동작이 측정으로 정의되면, 더는 특정 모델에 묶이지 않습니다. 새 모델 평가가 몇 주가 아니라 몇 시간으로 줄고, 모델이 규제로 내려가거나 노후로 폐기돼도 그건 화재경보가 아니라 그저 잡일이 됩니다.

이 글이 가리키는 건 단순한 도구 추천이 아닙니다. 성숙한 공학 분야는 결국 한때 손으로 한다는 데 자부심을 느끼던 바로 그 일을 기계에 넘긴다는 통찰입니다. 어셈블리는 컴파일러에, 손으로 짠 쿼리는 플래너에, 수동 메모리 관리는 기계에 자리를 내줬습니다. ‘적절한 단어로 모델을 구슬리는’ 솜씨도 분명 실력이지만, 믿을 만하고 개선 가능하며 옮겨 다닐 수 있는 시스템을 만들려면 프롬프트를 손으로 만지는 단계에서 언젠가 벗어나게 된다는 이야기입니다. 지금 프롬프트를 한 줄씩 덧대며 고치고 있다면, 한 번쯤 자신이 쌓고 있는 게 진전인지 부채인지 들여다볼 만합니다.