[실험] 오케스트레이터 프롬프트 한 줄 차이 — 멀티 에이전트 결과가 이렇게 갈렸어요

지난 글에서 멀티 에이전트 오케스트레이션을 어떻게 설계해야 하는지 정리했었죠. 그런데 정작 글을 쓰면서 가장 답답했던 건 따로 있었어요. **"오케스트레이터 역할을 프롬프트로 어떻게 정의하느냐에 따라 작업 분배 결과가 너무 달라진다"**는 점이었어요.

그래서 이번 주에는 같은 작업을 주고, 오케스트레이터 프롬프트만 세 가지 패턴으로 바꿔서 직접 돌려봤어요. 결론부터 말하면 — 한 줄 차이가 결과를 거의 다른 시스템처럼 보이게 만들었어요. 어떤 패턴이 가장 깔끔했는지, 입출력 비교와 함께 풀어 볼게요.

---

이번 실험, 이렇게 세팅했어요

복잡하게 가지 않으려고 조건을 최대한 단순하게 잡았어요.

항목설정

모델	Claude Sonnet 4.6
에이전트 구성	오케스트레이터 1 + 서브 에이전트 3 (자료조사 · 초안작성 · 검수)
테스트 작업	"중학교 2학년 대상 'AI 리터러시' 1차시 수업 지도안 만들기"
변경 변수	오케스트레이터의 역할 정의 프롬프트 한 문단만
고정 변수	서브 에이전트 3개의 프롬프트, 작업 지시문, 출력 형식

같은 작업을 세 번 돌리면서, 오케스트레이터의 첫 줄만 바꿔봤어요.

---

패턴 A — "매니저형" (가장 흔한 방식)

처음 시도한 건 가장 무난한 매니저 톤이에요. 에이전트 설계 글마다 거의 비슷하게 등장하는 그 패턴이요.

프롬프트 A (오케스트레이터 역할 정의) 당신은 멀티 에이전트 시스템의 매니저입니다. 사용자의 요청을 분석하고, 적절한 서브 에이전트에게 작업을 분배한 뒤, 결과를 종합해 사용자에게 답변하세요.

결과

오케스트레이터가 작업을 순차적으로 분배했어요. 자료조사 → 초안작성 → 검수 순서대로요. 결과물 자체는 나쁘지 않았는데, 한 가지 문제가 있었어요. 검수 에이전트의 피드백이 초안에 반영되지 않은 채 그대로 사용자에게 전달됐어요. "검수 결과: 학습 목표가 모호함"이라는 코멘트가 붙은 채로요.

오케스트레이터는 "분배하고 종합한다"는 지시만 충실히 따랐던 거예요. 피드백을 받아서 다시 돌릴 권한이 있는지는 명시되어 있지 않았으니까요.

---

패턴 B — "감독관형" (권한을 명시한 버전)

그래서 두 번째는 권한을 구체적으로 적어줬어요. 단어 하나 추가가 아니라, 권한 범위와 종료 조건을 명시한 거예요.

프롬프트 B 당신은 멀티 에이전트 시스템의 감독관입니다. 서브 에이전트에게 작업을 위임하되, 결과물의 품질이 기준에 미치지 못하면 같은 에이전트에게 재작업을 지시할 권한이 있습니다. 검수 에이전트가 "수정 필요" 판정을 내리면, 최대 2회까지 초안작성 에이전트에게 수정을 요청한 뒤 사용자에게 최종본을 전달하세요.

결과

이번엔 루프가 돌았어요. 초안 작성 → 검수 "학습 목표 모호" → 수정 요청 → 재작성 → 검수 통과 → 사용자 전달. 결과물이 훨씬 깔끔했어요. 학습 목표도 SMART 형식으로 정리됐고요.

다만 토큰 사용량이 약 1.7배 늘었어요. 재작업 루프가 도는 만큼 비용도 올라가는 거죠. 품질-비용 트레이드오프를 어디서 끊을지가 새로운 고민이 됐어요.

---

패턴 C — "조율자형" (병렬 처리를 유도)

마지막은 좀 다르게 가봤어요. 순차 분배가 아니라 병렬 처리를 유도하는 프롬프트요.

프롬프트 C 당신은 멀티 에이전트 팀의 조율자입니다. 작업을 시작할 때 먼저 어떤 작업을 동시에 실행할 수 있고 어떤 작업이 순차적으로 의존하는지 분석하세요. 독립적인 작업은 병렬로 위임하고, 의존성이 있는 작업만 순차로 진행하세요. 모든 결과가 모이면 최종 검수를 거쳐 사용자에게 전달합니다.

결과

이게 가장 흥미로웠어요. 오케스트레이터가 작업 시작 전에 의존성 그래프를 먼저 출력하더라고요.

"자료조사(독립) → 초안작성(자료조사 의존) → 검수(초안 의존). 따라서 자료조사를 먼저 수행하고 초안과 검수는 순차 진행합니다. 단, 자료조사 안에서 '교육과정 조사'와 '사례 조사'는 병렬 처리 가능합니다."

전체 작업 시간이 패턴 A보다 짧아졌어요(약 30% 단축). 결과물 품질은 패턴 B와 비슷하거나 살짝 못한 정도였고요. 다만 검수 단계의 피드백 루프가 빠져 있어서, 패턴 B에서 잡혔던 "학습 목표 모호" 이슈가 다시 나타났어요.

---

세 패턴 비교

항목A. 매니저형B. 감독관형C. 조율자형

결과물 품질	보통	우수	우수
토큰 사용량	1.0x (기준)	1.7x	1.2x
응답 속도	보통	느림	빠름
피드백 루프	없음	있음 (최대 2회)	없음
적합한 상황	단순 분배 작업	품질이 비용보다 중요	시간이 비용보다 중요

같은 모델, 같은 서브 에이전트, 같은 작업이었는데 결과가 이렇게 갈리더라고요. 오케스트레이터 프롬프트는 단순한 역할 설명이 아니라, 시스템의 작동 방식 자체를 결정하는 설계 문서라는 게 이번 실험의 핵심 인사이트였어요.

---

그래서 어떤 걸 써야 할까

세 패턴을 다 돌려보고 나서 제가 내린 결론은 이거예요. "하나만 고르려 하지 말고, 작업 성격에 맞춰 섞어 쓰자."

• 품질이 절대적으로 중요한 작업(예: 학생에게 직접 전달되는 자료) → 패턴 B
• 반복 작업, 정기적 자동화(예: 매주 발행하는 글감 리스트) → 패턴 C
• 빠른 시제품, 일회성 실험 → 패턴 A

특히 교육 콘텐츠를 만들 때는 패턴 B의 피드백 루프가 큰 차이를 만들었어요. 학습 목표가 한 번에 잘 잡히는 경우가 거의 없거든요. 비용이 1.7배 들어도 결과물 품질을 생각하면 충분히 값어치를 한다고 봤어요.

---

바로 쓸 수 있는 템플릿

이번 실험에서 가장 잘 작동한 패턴 B를 일반화한 템플릿이에요. 그대로 복사해서 {} 부분만 채우면 돼요.

당신은 {도메인} 작업을 수행하는 멀티 에이전트 시스템의 감독관입니다.

작업 흐름

1. 사용자 요청을 분석해 필요한 서브 에이전트를 식별하세요.
2. 각 에이전트에게 명확한 작업 지시와 출력 형식을 전달하세요.
3. {검수 에이전트}가 "수정 필요" 판정을 내리면, 최대 {N}회까지 해당 작업 에이전트에게 재작업을 요청하세요.
4. {N}회 이후에도 통과하지 못하면, 사용자에게 현재 상태와 미해결 이슈를 함께 보고하세요.

금지 사항

• 사용자 확인 없이 작업 범위를 확장하지 마세요.
• 검수를 통과하지 않은 결과물을 최종본으로 표시하지 마세요.

{검수 에이전트}와 {N} 값을 작업에 맞게 조정하면, 대부분의 교육 콘텐츠 자동화에서 안정적으로 작동했어요.

---

마무리 — 다음 실험 예고

오케스트레이터 프롬프트 한 줄이 멀티 에이전트 시스템 전체를 어떻게 바꾸는지 직접 확인해 본 실험이었어요. 결국 프롬프트 엔지니어링은 "단어를 잘 고르는 일"이 아니라 **"권한과 종료 조건을 명확히 적는 일"**이라는 걸 새삼 느꼈네요.

다음 Prompt Lab 실험에서는 이번에 만든 패턴 B 템플릿에 가드레일 프롬프트를 추가했을 때 결과가 어떻게 달라지는지 비교해 볼 예정이에요. 특히 학생 안전과 관련된 가드레일을 어디까지 명시해야 효과적인지 궁금해서요.

궁금한 실험 주제나 직접 돌려보고 싶은 비교가 있다면 댓글로 남겨 주세요. 다음 실험에 반영할게요!

→ 관련 글: 이번 실험의 배경이 된 멀티 에이전트 오케스트레이션 설계 원칙은 [Agent Design] 카테고리에서, 오케스트레이터 패턴을 실제 수업 도구로 만든 사례는 [EdTech Tool] 카테고리에서 확인하실 수 있어요.

2026.04.05 - [[Agent Design] AI 에이전트 설계] - 멀티 에이전트 오케스트레이션 — 교육 현장에 이렇게 설계하세요

멀티 에이전트 오케스트레이션 — 교육 현장에 이렇게 설계하세요

 

도움이 되셨다면 공감 한 번 부탁드려요 :)