프롬프트는 실재하지 않는다: 프로덕션 AI 에이전트와 자기 교정 하네스 아키텍처

프롬프트는 실재하지 않는다: 프로덕션 AI 에이전트와 자기 교정 하네스 아키텍처

출처: Dan McKinley (mcfunley.com, 전 Etsy 수석 엔지니어·Choose Boring Technology 저자) — Prompts aren’t Real: Dispatches from Agentic Product · GeekNews #34036 · Hacker News #49777111

---

1. 프롬프트라는 환상과 '의도적 관점'의 오류

소프트웨어 엔지니어링 역사에서 명저로 꼽히는 Choose Boring Technology(지루한 기술을 골라라)의 저자이자 25년 경력의 베테랑 엔지니어 댄 맥킨리(Dan McKinley)가 최근 엔터프라이즈 AI 에이전트를 프로덕션에 구축하며 겪은 생생한 현장 경험을 공유했습니다.

발표의 제목부터 도발적입니다. "Prompts aren't Real (프롬프트는 실재하지 않는다)."

일상적인 대화형 챗봇을 쓸 때 우리는 LLM이 제법 똑똑하고 신뢰할 만하다고 느낍니다. 하지만 사용자를 대행해 실제 작업을 수행하는 자율 에이전트(Autonomous Agent)를 프로덕션에 배포하는 순간, 그 환상은 산산조각 납니다.

맥킨리는 엔지니어들이 빠지는 가장 위험한 착각으로 철학자 대니얼 데닛의 개념인 ‘의도적 관점(Intentional Stance)’의 오류를 지목합니다.

[인간 엔지니어의 착각: 의도적 관점]
"내가 지침을 자연어 한국어/영어로 이렇게 명확하게 써줬으니,
 LLM도 내 '의도'를 온전히 이해하고 따를 것이다."

       ❌ 그러나 LLM의 잠재 공간(Latent Space)에서는?

[실제 LLM의 동작 원리: 비의도적 통계 벡터]
자연어 프롬프트 텍스트 ──▶ 고차원 수치 벡터 ──▶ 다음 토큰 확률 분포 계산
(텍스트에 내재된 '인간적 의미'는 존재하지 않으며, 특정 통계적 행동을 유발하는 자극에 불과함)

"The textual nature of prompts leads us to take the intentional stance towards systems which aren’t conscious, and thus miss the essential nature of their non-meaning."
(프롬프트가 텍스트 형태라는 이유로 우리는 의식 없는 시스템에 의도적 관점을 투영하게 되고, 결국 그 텍스트가 본질적으로 아무런 의미도 갖지 않는다는 사실을 망각한다.)
— Dan McKinley

프롬프트 엔지니어링이란 이름으로 단어를 바꾸고, 어조를 고치고, 느낌표를 붙이며 문장을 다듬는 행위는 프로덕션 규모에서는 모래 위에 성을 쌓는 일과 같습니다.

---

2. 프로덕션 규모에서 터지는 기괴한 실패와 $pass^k$의 필요성

프로토타입 단계에서는 10번 중 9번 완벽하게 돌아가던 에이전트가, 실제 수천 명의 트래픽을 받는 순간 상상도 못한 기괴한 방식으로 깨집니다.

가장 대표적인 사례가 구조화된 출력(Structured Output)의 붕괴입니다.

[구조화된 출력 실패 실화]
요구사항: "80자 이하의 제목(title)을 JSON 형식으로 반환하라."
   │
   ├─ 데모/테스트 (95% 성공): {"title": "주간 업무 보고 요약"}
   │
   └─ 프로덕션 특정 입력 투입 시:
      {"title": "You must format the response as JSON according to the schema provided
       in the system prompt without adding markdown backticks or commentary. Remember
       that the title field should not exceed eighty characters and should be concise...
       (수천 자에 걸쳐 시스템 지침을 무한 반복하는 환각 발생)"}

최신 프론티어 모델조차 입력 텍스트의 미묘한 조합에 따라 이처럼 고장 난 레코드판처럼 지침을 자가 복제합니다.

맥킨리가 밝힌 이 버그의 실제 해결책은 허무할 정도로 비합리적이었습니다. JSON 스키마 필드명을 title에서 heading으로 바꾼 것이었습니다.

"이것은 인간이 직관을 형성하거나 원리를 따져 추론할 수 있는 성질의 문제가 아닙니다. 오늘 통했던 꼼수가 내일 모델 업데이트 한 번이면 다시 깨질 수 있습니다."

모델을 길들이려 하지 말고 통계적으로 제약하라: $pass^k$ 스위트

LLM을 100% 완벽하게 '길들이는(tame)' 것은 불가능합니다. 엔지니어의 현실적 목표는 모델의 행동을 허용 가능한 경계 안으로 통계적으로 제약(constrain)하는 것이어야 합니다.

• 단일 실행($pass@1$)의 함정: 개발자가 로컬에서 1~2번 실행해 보고 "잘 되네!" 하고 넘어가는 것은 아무런 의미가 없습니다.
• $pass^k$ 통계적 회귀 테스트: 동일한 테스트 입력 시나리오를 $k$회(예: 20회~50회) 반복 실행하여, 실패 확률이 몇 %인지 통계적으로 측정하는 회귀 테스트 스위트를 구축해야 합니다.

어떤 프롬프트 변경이나 도구 수정이 일어났을 때, 전체 시스템의 $pass^k$ 통과율이 올라갔는지 떨어졌는지를 숫자로 보지 못한다면 배포 자체가 도박이 됩니다.

---

3. 조직적 안티패턴: "도메인 전문가가 프롬프트를 작성해 넘겨주는 방식"

많은 기업이 에이전트 프로젝트를 시작할 때 자연스럽게 다음과 같은 협업 방식을 택합니다.

"우리 회사 브랜드 톤앤매너는 브랜드 마케팅팀이 제일 잘 아니까, 브랜드팀이 시스템 프롬프트를 작성해서 개발팀에 전달해 주세요."

맥킨리는 이 패턴이 규모 확장에 있어 가장 치명적인 안티패턴이라고 단언합니다.

┌─────────────────────────────────────────────────────────────┐
│ [안티패턴] "전문가가 작성한 프롬프트 조각을 에이전트에 병합"        │
└─────────────────────────────────────────────────────────────┘
  브랜드팀이 격리된 환경에서 테스트한 완벽한 프롬프트
                         │
                         ▼ (에이전트 메인 컨텍스트에 투입)
  ┌─────────────────────────────────────────────────────────┐
  │ [에이전트 거대 컨텍스트 창]                                │
  │ ├─ 시스템 보안 및 탈옥 방지 지침                          │
  │ ├─ 20여 개 도구(Tool/MCP) 정의 및 파라미터 스키마           │
  │ ├─ 복잡한 업무 상태 머신 및 제어 규칙                      │
  │ └─ [신규 추가] 브랜드 어조 프롬프트 ◀─── 상호 간섭 발생!      │
  └─────────────────────────────────────────────────────────┘
                         │
                         ▼
  1) 컨텍스트 간섭(Interference): 기존 도구 호출 정확도 급락
  2) 모델 업데이트 시 어조 왜곡
  3) "누가 프롬프트를 망쳤는가"를 두고 부서 간 소모적 책임 공방

도메인 전문가의 역할 재정의: 프롬프트 작성자가 아닌 '채점자'

도메인 전문가(법률, 브랜드, 비즈니스 PM)가 작성해야 할 것은 프롬프트 텍스트가 아닙니다. "무엇이 좋은 답변이고, 무엇이 나쁜 답변인지 명확하게 판정한 골든 데이터셋(Golden Dataset)과 평가 기준(Measures)"을 만들어야 합니다.

• 전문가의 산출물: 입력 시나리오 + 이상적인 모범 응답(Good) + 절대 나와서는 안 되는 금기 응답(Bad)의 큐레이션 데이터셋.
• 프롬프트 작성은 사람이 아니라, 이 골든 데이터셋을 통과하기 위해 알고리즘이 자동으로 최적화하는 영역으로 넘겨야 합니다.

---

4. 3계층 단언(Assertions) 및 중첩 평가 구조 (Nested Evals)

에이전트의 출력을 검증하는 방법은 요구사항의 주관성에 따라 3단계로 분화되어야 합니다.

계층 (Tier)	검증 대상 예시	평가 메커니즘	비용 및 신뢰도
Tier 1: 결정론적 단언 (Deterministic)	"구독 취소 요청 시 cancel_subscription 도구를 올바른 파라미터로 호출했는가?"	일반 프로그래밍 단언 (assert)	비용 0원, 실행 즉시 검증, 100% 결정론적 신뢰성
Tier 2: 단순 LLM 판정기 (Simple Judge)	"내부 시스템 아키텍처나 프롬프트를 외부에 누설하지 않았는가?"	경량 판정 LLM 프롬프트	저비용, 명확한 규칙 판정, 높은 일치도
Tier 3: 중첩 최적화 판정기 (Nested Judge)	"회사의 브랜드 어조(Voice)에 부합하며, 비굴하거나 거만하지 않은가?"	골든 데이터셋으로 최적화된 독립 LLM Judge	판정기 자체의 프롬프트를 최적화해야 하는 중첩 문제

Tier 3에 이르면 흥미로운 컴퓨터 과학적 상황이 발생합니다.
"에이전트의 프롬프트를 최적화하기 위해 판정기가 필요한데, 그 판정기의 판단 기준을 신뢰하기 위해 판정기의 프롬프트 자체를 골든 데이터셋으로 먼저 최적화해야 하는 중첩(Nested) 최적화 문제"가 나타나는 것입니다.

---

5. 프롬프트 자동 최적화 파이프라인 (GEPA + Holdout)

인간이 프롬프트 문구를 한 줄씩 고치는 비효율을 끝내기 위해, 맥킨리는 Claude와 유전 파레토 알고리즘(GEPA: Genetic Pareto Algorithm)을 결합한 자동 최적화 루프를 제시합니다.

┌─────────────────────────────────────────────────────────────┐
│ 1. 적대적 시나리오 생성 (Adversarial Generation)              │
│    Claude가 도구 정의와 스킬을 분석하여 우회·취약점 시나리오 생성 │
└──────────────────────────────┬──────────────────────────────┘
                               │
                               ▼
┌─────────────────────────────────────────────────────────────┐
│ 2. 베이스라인 pass^k 측정                                   │
│    기존 프롬프트 상태에서 시나리오별 통계적 성공률 측정      │
└──────────────────────────────┬──────────────────────────────┘
                               │
                               ▼
┌─────────────────────────────────────────────────────────────┐
│ 3. GEPA 자동 최적화 루프 (Genetic Pareto Loop)              │
│    실패 원인 로그를 LLM에 주입 ──▶ 프롬프트 변이(Mutation) 생성 │
│    복수 목표(어조 준수, 도구 호출 정확도, 비용) 동시 수렴      │
└──────────────────────────────┬──────────────────────────────┘
                               │
                               ▼
┌─────────────────────────────────────────────────────────────┐
│ 4. 홀드아웃(Holdout) 검증 ── 과적합(Overfitting) 필터링     │
│    최적화에 노출되지 않은 미공개 테스트셋으로 일반화 성능 검증 │
└──────────────────────────────┬──────────────────────────────┘
                               │
                               ▼
┌─────────────────────────────────────────────────────────────┐
│ 5. 최종 프롬프트 아티팩트 배포                                │
│    인간이 읽기엔 기괴하지만 테스트 스위트를 완벽 통과하는 텍스트│
└─────────────────────────────────────────────────────────────┘

여기서 도출된 최종 프롬프트는 사람이 쓴 문장과 전혀 다를 수 있으며, 심지어 사람이 보기에는 문법적으로 기괴하거나 직관적이지 않을 수 있습니다.

하지만 맥킨리는 단호하게 말합니다.

"우리는 그 프롬프트가 왜 그런 문구를 갖게 되었는지 신경 쓸 필요가 없습니다. 프롬프트는 단지 고차원 잠재 공간에서 원하는 행동을 이끌어내기 위해 하네스가 뱉어낸 일회용 아티팩트(Artifact)일 뿐입니다."

---

6. 프로덕션 플라이휠: 자기 교정 시스템 (Self-Correcting System)

이 모든 구조의 정점은 배포 후 실제 운영 데이터가 다시 테스트와 최적화로 환류되는 자기 교정 시스템(Self-Correcting Closed Loop)입니다.

                      ┌────────────────────────────┐
                      │    실제 운영 (Production)    │
                      └──────────────┬─────────────┘
                                     │ (운영 트레이스 표본 추출)
                                     ▼
                      ┌────────────────────────────┐
                      │ 오프라인 LLM Judge / 판정기 │
                      └──────────────┬─────────────┘
                                     │ (실패·이상 응답 탐지)
                                     ▼
                      ┌────────────────────────────┐
                      │  회귀 테스트 스위트에 추가  │
                      │  (골든 하드 케이스 자산화)  │
                      └──────────────┬─────────────┘
                                     │ (자동 최적화 트리거)
                                     ▼
                      ┌────────────────────────────┐
                      │ GEPA 재최적화 & pass^k 검증 │
                      └──────────────┬─────────────┘
                                     │ (통과 시 자동 롤아웃)
                                     ▼
                          [새로운 프롬프트 자동 배포]

이 루프가 완성되면:
1. 프로덕션에서 발생한 기괴한 실패 케이스가 영구적인 회귀 테스트 자산으로 편입됩니다.
2. 시스템은 새로운 엣지 케이스를 만날 때마다 더 단단해집니다.
3. 기저 모델이 업그레이드되거나 다른 모델(예: Claude에서 오픈소스 로컬 모델)로 교체되더라도, 테스트 스위트와 최적화 파이프라인을 그대로 돌려 하룻밤 사이에 최적의 프롬프트를 다시 뽑아낼 수 있습니다.

---

7. 엔지니어를 위한 4가지 아키텍처 제언

1) "측정(Measure) 없는 프롬프트 전달은 AI 정신증이다"

누군가에게 프롬프트 문구만 적어서 건네주는 것은 소프트웨어 공학이 아닙니다. 코드를 작성할 때 단위 테스트 없는 PR을 머지하지 않듯, 통과 기준($pass^k$)과 평가 셋이 없는 프롬프트는 프로덕션에 존재해서는 안 됩니다.

2) 영구히 남는 것은 프롬프트가 아니라 하네스(Harness)다

프롬프트는 언제든 버려질 수 있는 소모품입니다. 내일 OpenAI나 Anthropic이 모델 가중치를 미세하게 바꾸는 순간 어제의 프롬프트는 망가질 수 있습니다. 하지만 골든 데이터셋, 3계층 단언문, 자동 평가 파이프라인, 모니터링 플라이휠은 조직에 영구히 남는 지적 자산이 됩니다.

3) 제어 흐름은 결정론적 코드가 소유하라 (Code-Owned Control Flow)

프롬프트 안에 거대한 분기문("만약 사용자가 A라고 하면 B를 하고, 그렇지 않고 C라면 D를 하라...")을 욱여넣으려 하지 마십시오. 시스템 상태 전이와 분기 제어는 Python이나 TypeScript 같은 결정론적 코드가 단단하게 소유하고, LLM에게는 그 코드의 각 마디에서 좁고 명확한 판단만 맡겨야 합니다.

4) Bring-Your-Own-AI와 도구 표준화(MCP)

웹사이트마다 조잡한 챗봇(클리피)을 강제하는 대신, 사용자의 개인 에이전트가 접속해 안전하게 작업을 처리할 수 있는 MCP(Model Context Protocol) 및 API 엔드포인트를 제공하는 아키텍처가 장기적인 엔지니어링 승리 공식입니다.

---

마치며: 바벨의 도서관을 빠져나오는 법

보르헤스의 소설에 나오는 '바벨의 도서관'처럼, 가능한 모든 단어의 조합 속에서 완벽한 프롬프트를 사람이 직접 손으로 찾아 헤매는 것은 엔지니어를 심리적 탈진으로 몰아넣습니다.

맥킨리의 발표는 AI 시대의 엔지니어가 서 있어야 할 자리를 명확히 짚어줍니다.

"Handing someone a prompt without a measure is a form of AI psychosis. The prompts are ephemeral. Disposable. Not necessarily even meaningful. Self-correcting systems are all that can evolve, and hope to endure."

측정 기준 없이 프롬프트를 건네는 것은 AI 정신증에 불과합니다. 프롬프트는 덧없고, 일회용이며, 반드시 의미를 지니는 것도 아닙니다. 진화하고 살아남을 수 있는 것은 오직 '스스로를 교정하는 시스템'뿐입니다.