멀티 에이전트 프롬프트 최적화, 오히려 시스템을 죽일 때가 있다
자동 프롬프트 최적화를 돌렸다가 멀티 에이전트 파이프라인이 통째로 죽어버린다면? 실제 협업 리뷰 실험에서는 최적화가 끝난 뒤 남은 결과물이 아예 없었고, 가용 출력이 0인 상태, 즉 시스템 붕괴였습니다. 원인은 프롬프트가 ‘내용 생성’과 ‘실행 규칙’이라는 두 가지 역할을 동시에 맡기 때문입니다. 이 글은 멀티 에이전트 프롬프트 최적화가 시스템을 무너뜨리는 구조적 원인과, 이를 막는 제어-데이터 분리 설계를 워털루대 연구팀의 실측 결과와 함께 정리합니다.
프롬프트는 편지 봉투와 편지 내용을 한 장에 쓴다
멀티 에이전트 시스템에서 프롬프트는 두 가지 일을 동시에 합니다. 하나는 할 일을 알려주는 내용이고, 다른 하나는 시스템이 실행을 판단하는 규칙입니다.
사회자가 누구인지, 각 에이전트가 무엇을 출력해야 하는지, JSON 형식인지, 다음 에이전트에게 뭘 넘기는지. 이런 실행 규칙들을 코드가 그대로 읽고 의존합니다. 비유하자면 편지지 한 장에 본문과 함께 우편번호·수신처·발송 규칙을 같이 적어 보내는 상황입니다. 배달원(코드)은 이 주소 부분을 보고 배달할까 말까를 결정합니다.
여기까지는 문제가 없습니다. 사람이 직접 고칠 때는 주소를 자세히 보고 고치니까요. 그런데 자동 최적화 프로그램이 이 편지를 통째로 수정하기 시작하면 얘기가 달라집니다. 프로그램은 본문을 다듬는 교정관이지, 우체국 규정을 아는 전문가가 아닙니다.
최적화가 계약서를 고치기 시작하면 시스템이 무너진다
텍스트 그라디언트 계열 기법은 프롬프트를 한 줄의 텍스트로 보고, 성능 점수가 높아지는 방향으로 문자열을 통째로 편집합니다. 여기서 치명적 사고가 납니다. 최적화기가 실행 규칙(우편번호, 필드명, 형식)까지 편집 대상으로 보고 건드리기 때문입니다.
실측에서 무엇이 벌어졌는지 봅니다. 협업 리뷰 생성 파이프라인에 최적화를 적용하자 모델이 JSON 형식 블록 전체를 삭제하고, 스키마 필드명을 자기 멋대로 바꿔치기했습니다. 파이프라인은 더 이상 다음 단계로 넘길 물건을 생산하지 못했고, 결국 결과물이 0이 되는 공황 상태로 끝났습니다. 실험에서 이 방식(나이브 최적화)의 최종 안정성은 0%, 즉 전량 실패였습니다.
이런 사고를 사후에 막아주는 도구(DSPy의 스냅-투-버킷 등)도 있습니다. 출력 결과물이 규칙에 어긋나면 가장 가까운 표준 값에 끼워 맞추는 방식입니다. 하지만 이것은 터진 뒤 복구일 뿐입니다. 고장을 결정한 프롬프트 자체는 커지고, 구조가 뒤틀리면 복구 자체가 불가능합니다.
그래서 필요한 것은 사후 복구가 아니라, 최적화기가 실행 규칙에 접근하는 것을 구조적으로 차단하는 일입니다.
실행 규칙(제어)과 작업 내용(데이터)을 프롬프트 안에서 나눕니다.
규칙을 타입 지정 객체와 스키마로 고정해 최적화 접근을 차단합니다.
작업 내용 문자열만 자동 프롬프트 최적화 대상으로 남깁니다.
제어는 코드로 동결하고, 데이터만 최적화하라
워털루대 연구팀이 공개한 논문에서 ‘제어-데이터 흐름 분리’라는 원리를 제안하고 실측으로 검증했습니다. 핵심은 프롬프트가 가진 두 역할을 처음부터 분리하는 것입니다.
- 제어 채널(실행 규칙): 시스템이 파이프라인을 실행하는 데 반드시 필요한 부분입니다. 타입이 지정된 파이썬 객체(데이터클래스·Pydantic 모델)로 만들고, 사용자와 최적화기 모두 접근할 수 없는 ‘동결 슬롯(Frozen Slot)’으로 관리합니다.
- 데이터 채널(작업 내용): 프롬프트의 나머지 부분입니다. 여기만 최적화 프로그램이 자유롭게 다듬을 수 있습니다.
이렇게 하면 최적화기가 실행 규칙을 건드릴 수 없습니다. 편지 본문은 다듬되, 봉투의 주소·규격은 우체국 시스템이 보호하는 구조입니다.
결과 수치를 봅니다. 이 구조에서는 추론(BBH)부터 협업 리뷰 생성, 합성 보험 요율, 업계 보험 요율까지 네 가지 실험 작업 모두에서 최종 프로토콜 유효성(출력이 정해진 형식·스키마를 지키는 비율)이 100%를 기록했고, 나이브 최적화에서 나왔던 시스템 붕괴는 0건이었습니다. 제어 표면에 닿은 편집 비율도 흥미롭습니다. 리뷰 생성 작업에서는 나이브 방식이 제어 토큰을 약 4배 더 자주 수정한 데 비해(16.6% 대 4.2%), 분리 구조에서는 이 비율이 다른 작업들에서도 일관되게 낮았습니다(합성 27.0%→14.6%, BBH 22.9%→18.6%, 보험 22.6%→12.2%).
멀티 에이전트 프롬프트 최적화, 성능도 정말 오르나?
분리가 안정성만 지키는 게 아니라 성능 향상까지 유지하는지가 핵심입니다. 메인 실험 수치를 봅니다.
- 보험 요율 작업: 업계에서 쓰는 파트너 고정 프롬프트(40줄 이상)는 정확도 31.7%, 분리 구조는 36.7%로 약 5% 포인트 올랐습니다.
- 협업 리뷰 생성(자카드 유사도): 생성 리뷰가 참조 리뷰와 얼마나 겹치는지를 보는 지표로, 고정 프롬프트 31.0에서 분리 구조 44.4로 올랐습니다.
모델 계열을 바꿔가며 검증한 실험에서도 세 계열(OpenAI·Anthropic·Google) 모두 프로토콜 안정성은 100%를 기록했습니다. 다만 성능 향상 폭은 모델마다 달랐습니다. Anthropic은 25.1에서 33.5로, Google은 33.7에서 40.3으로 올랐고, OpenAI는 고정 프롬프트와 근사한 42.2를 기록했습니다. ‘아무 모델이나 골라도 성능이 뛴다’고 단정할 일은 아닙니다. 실질 가치는 어느 모델에서도 붕괴 없이 최적화를 끝까지 돌릴 수 있다는 점입니다. 실측 수치 전체는 공개된 실험 코드에서 재현할 수 있습니다.
안정성과 정확성은 다릅니다 (논문이 스스로 밝힌 한계)
연구팀은 논문에서 명확하게 경고합니다. 이 방식이 보장하는 것은 안정성이지, 정확성이 아닙니다. 최적화가 아주 안정적으로 끝났어도 결과가 논리적으로 틀렸을 수 있다는 뜻입니다.
이 설계는 작업 구조와 스키마를 미리 선언해야 한다는 전제가 있습니다. 실행 중에 에이전트 수가 바뀌는 동적인 팀 구성을 다루려면 설계 보완이 따라옵니다. 최적화가 끝났다고 해서 정확성·안전 검증까지 건너뛰면 안 됩니다.
잘못된 사례와 올바른 사례를 실측 수치로 나란히 놓아보겠습니다.
| 구분 | 고정 프롬프트 | 나이브 자동 최적화 | 분리 구조 |
|---|---|---|---|
| 리뷰 생성 Jaccard | 31.0 | 0.0(붕괴) | 44.4 |
| 리뷰 생성 안정성 | 측정 안 함 | 0% | 100% |
| 제어 표면 편집(리뷰) | — | 16.6% | 4.2% |
| 보험 요율 정확도 | 31.7%(파트너 고정) | 붕괴 위험 | 36.7% |
멀티 에이전트 프로젝트에 바로 적용하는 체크리스트
- 실행 규칙을 코드로 옮깁니다. 출력 형식·라우팅·종결 신호는 프롬프트 말고 파이썬 타입 객체와 스키마 검증으로 고정합니다.
- 최적화 범위를 한정합니다. 자동 프롬프트 최적화는 사람이 쓴 내용 부분에만 적용하고, 실행 규칙 문자열은 대상에서 제외합니다.
- 실패 감지를 넣습니다. 최적화 도중 프로토콜이 어긋나면 즉시 멈추고 로깅해서, 원인 프롬프트를 알 수 있게 합니다.
- 결과 검증을 남깁니다. 이 방식은 안정성만 보장합니다. 최적화가 끝난 뒤 정확성 샘플 검토와 안전 점검을 별도로 수행합니다.
참고로 대부분의 자동 최적화 도구는 프롬프트 전체를 수정 대상으로 삼기 때문에, 분리 구조 없이 바로 돌리면 이 글에서 본 나이브 최적화처럼 붕괴할 수 있습니다. 실행 규칙을 코드로 분리한 뒤 도구를 적용하세요.
마무리: 파이프라인을 배달 시스템처럼 설계하자
프롬프트 최적화를 돌리다가 시스템이 죽는 문제는 모델 성능 때문이 아니라, 최적화 대상과 시스템의 계약이 뒤섞여 있기 때문입니다. 제어는 코드로 동결하고 데이터만 최적화하는 분리는 단순한 설계 원칙이지만, 그 효과는 지난 실험에서 프로토콜 유효성 100%라는 숫자로 확인됐습니다. 멀티 에이전트 프롬프트 최적화를 계획 중이라면, 지금 만들고 있는 프롬프트에서 봉투와 본문을 먼저 나눠보세요. 실행 규칙 훼손에서 오는 최적화 붕괴는 이 분리 설계 하나로 막을 수 있습니다. 이 연구의 상세한 논의는 EMNLP 2026 Findings 리뷰에서 확인할 수 있습니다.
