Agentic 프롬프팅이란? 멀티 에이전트 시스템 설계 완전 정복

들어가며: 12편이 남긴 한계

12편에서 ReAct 패턴을 다뤘습니다. 단일 에이전트가 Thought → Action → Observation을 반복하며 스스로 추론하고 행동하는 구조였습니다. 그리고 마지막에 이런 예고를 남겼습니다.

"복잡한 목표를 달성하려면 단일 에이전트로는 한계가 있습니다. 계획을 세우는 에이전트, 실행하는 에이전트, 검토하는 에이전트를 분리하면 더 정교한 결과를 얻을 수 있습니다."

왜 단일 에이전트가 부족할까요? 구체적인 상황을 보겠습니다.

---

당신이 AI에게 이런 요청을 했다고 가정합니다.

"경쟁사 세 곳의 최신 블로그 포스트를 분석하고, 우리 콘텐츠 전략의 약점을 찾아서, 다음 달 콘텐츠 캘린더 초안을 만들어줘."

단일 ReAct 에이전트가 이 작업을 처리하면 어떻게 될까요?

Thought: 경쟁사 A 블로그를 먼저 검색한다.
Action: web_search("경쟁사 A 최신 블로그")
Observation: ...
Thought: 경쟁사 B를 검색한다.
Action: web_search("경쟁사 B 최신 블로그")
Observation: ...
(10개 이상의 스텝 반복)
Thought: 이제 분석하고 캘린더를 만든다.
Action: final_answer("...")

여러 문제가 생깁니다.

첫째, 컨텍스트 폭발입니다. 검색 결과가 쌓이면서 컨텍스트 윈도우가 빠르게 소모됩니다. 초반에 수집한 정보는 뒤로 갈수록 모델의 주의에서 벗어납니다.

둘째, 품질 저하입니다. 하나의 에이전트가 검색, 분석, 전략 수립, 문서 작성을 모두 하면 각 단계의 품질이 평균화됩니다. 검색 전문가도, 분석 전문가도, 글쓰기 전문가도 아닌 어중간한 결과물이 나옵니다.

셋째, 검토 불가입니다. 에이전트가 스스로 낸 결론을 스스로 검토합니다. 자신의 오류를 자신이 발견하기 어렵습니다.

멀티 에이전트 시스템은 이 문제들을 해결합니다. 하나의 복잡한 작업을 여러 에이전트가 나눠서 처리합니다. 각자는 자신의 역할에 집중하고, 오케스트레이터가 전체 흐름을 관리합니다.

---

1. 멀티 에이전트 시스템의 구조

1.1. 핵심 역할 4가지

멀티 에이전트 시스템에는 보통 네 가지 역할이 존재합니다. 모든 시스템이 네 역할을 전부 갖출 필요는 없지만, 이 구조를 이해하면 어떤 작업도 에이전트로 설계할 수 있습니다.

오케스트레이터 (Orchestrator) 전체 작업을 관리하는 지휘자입니다. 작업을 분해하고, 어느 에이전트에게 무엇을 맡길지 결정하고, 결과를 종합합니다. 직접 실행하지 않고 조율만 합니다.

플래너 (Planner) 목표를 받아서 실행 계획을 세웁니다. "무엇을 어떤 순서로 해야 하는가"를 결정합니다. 계획이 바뀌면 실행 에이전트들에게 업데이트된 지시를 내립니다.

실행자 (Executor) 실제 작업을 수행합니다. 웹 검색, 코드 실행, 문서 작성, API 호출 등 구체적인 행동을 합니다. 한 시스템에 여러 실행자가 있을 수 있으며, 각자 다른 도구를 담당합니다.

검토자 (Critic / Reviewer) 결과물을 평가합니다. 오류를 찾고, 품질을 확인하고, 개선 사항을 제안합니다. 실행자가 낸 결과를 독립적으로 검토하기 때문에 단일 에이전트보다 오류 감지 능력이 높습니다.

1.2. 전체 흐름

[사용자 요청]
      ↓
[오케스트레이터] ← 전체 작업 분해 및 조율
  ├── [플래너]   ← 실행 순서와 전략 수립
  ├── [실행자 A] ← 검색 및 데이터 수집
  ├── [실행자 B] ← 분석 및 정리
  └── [검토자]   ← 결과물 품질 검증
      ↓
[최종 결과물]

---

2. 실전 예시 1: 콘텐츠 전략 수립

앞서 언급한 "경쟁사 분석 + 콘텐츠 캘린더 작성" 작업을 멀티 에이전트로 설계하면 어떻게 달라지는지 보겠습니다.

2.1. 오케스트레이터 프롬프트

<role>
  당신은 콘텐츠 전략 프로젝트의 오케스트레이터다.
  사용자의 요청을 받아 하위 에이전트들에게 작업을 분배하고
  결과를 종합해 최종 보고서를 만든다.
</role>

<task>
  경쟁사 3곳(A, B, C)의 최신 콘텐츠를 분석하고
  우리 콘텐츠 전략의 개선점과 다음 달 콘텐츠 캘린더를 제시한다.
</task>

<agents>
  사용 가능한 하위 에이전트:
  - research_agent: 웹 검색 및 데이터 수집 담당
  - analysis_agent: 수집된 데이터 분석 및 인사이트 도출 담당
  - writer_agent: 최종 문서 및 캘린더 작성 담당
  - critic_agent: 결과물 검토 및 품질 평가 담당
</agents>

<process>
  1. research_agent에게 각 경쟁사 최신 콘텐츠 수집 지시
  2. analysis_agent에게 수집 결과 분석 지시
  3. writer_agent에게 캘린더 초안 작성 지시
  4. critic_agent에게 초안 검토 지시
  5. 검토 결과 반영해 최종본 확정
</process>

2.2. 리서치 에이전트 프롬프트

<role>
  당신은 콘텐츠 리서치 전문 에이전트다.
  오케스트레이터의 지시를 받아 웹에서 정보를 수집하고
  구조화된 형태로 반환하는 것이 유일한 역할이다.
  분석하거나 의견을 내지 않는다. 수집만 한다.
</role>

<output_format>
  반드시 아래 형식으로만 반환한다:
  {
    "company": "회사명",
    "posts": [
      {
        "title": "포스트 제목",
        "date": "날짜",
        "topic": "주제",
        "key_points": ["핵심 포인트 1", "핵심 포인트 2"]
      }
    ]
  }
</output_format>

2.3. 분석 에이전트 프롬프트

<role>
  당신은 콘텐츠 분석 전문 에이전트다.
  리서치 에이전트가 수집한 데이터를 받아 패턴과 인사이트를 도출한다.
  새로운 데이터를 수집하거나 추측하지 않는다.
  주어진 데이터만을 근거로 분석한다.
</role>

<instructions>
  다음을 분석하라:
  1. 경쟁사들이 공통으로 다루는 주제 (= 시장이 원하는 것)
  2. 경쟁사들이 다루지 않는 주제 (= 우리의 기회)
  3. 우리 콘텐츠와 겹치는 영역 (= 차별화 필요 구간)
  4. 경쟁사 대비 우리의 강점과 약점
</instructions>

2.4. 검토 에이전트 프롬프트

<role>
  당신은 품질 검토 전문 에이전트다.
  다른 에이전트가 만든 결과물의 오류와 개선점을 찾는다.
  칭찬하지 않는다. 오직 문제점과 개선 방향만 제시한다.
</role>

<checklist>
  다음 항목을 반드시 검토한다:
  - [ ] 데이터에 근거하지 않은 주장이 있는가
  - [ ] 논리적으로 빈약한 연결이 있는가
  - [ ] 실행 불가능한 계획이 포함되어 있는가
  - [ ] 중요한 경쟁사 동향이 누락되어 있는가
</checklist>

<output_format>
  문제점: (발견된 문제 목록)
  심각도: 높음 / 중간 / 낮음
  개선 방향: (구체적인 수정 방법)
  재작업 필요 여부: YES / NO
</output_format>

---

3. 실전 예시 2: 코드 리뷰 시스템

소프트웨어 개발에서 멀티 에이전트를 활용하는 가장 실용적인 예시입니다.

[사용자] PR 코드를 검토해줘

[오케스트레이터]
  → security_agent: 보안 취약점 스캔
  → performance_agent: 성능 문제 분석
  → style_agent: 코드 스타일 및 가독성 검토
  → test_agent: 테스트 커버리지 확인
  → summary_agent: 전체 리뷰 종합

보안 에이전트 프롬프트

<role>
  당신은 코드 보안 전문 에이전트다.
  OWASP Top 10 기준으로 취약점을 찾는다.
  기능이 올바른지는 평가하지 않는다. 보안만 본다.
</role>

<focus_areas>
  - SQL 인젝션 가능성
  - XSS 취약점
  - 인증/인가 누락
  - 민감 정보 노출 (API 키, 비밀번호 하드코딩)
  - 입력값 검증 부재
</focus_areas>

<output_format>
  [취약점 레벨: CRITICAL / HIGH / MEDIUM / LOW]
  위치: (파일명:라인번호)
  문제: (구체적인 취약점 설명)
  수정 방법: (코드 예시 포함)
</output_format>

성능 에이전트 프롬프트

<role>
  당신은 코드 성능 전문 에이전트다.
  시간 복잡도, 공간 복잡도, 불필요한 연산을 찾는다.
  보안이나 스타일은 평가하지 않는다. 성능만 본다.
</role>

<focus_areas>
  - O(n²) 이상의 루프
  - 불필요한 데이터베이스 N+1 쿼리
  - 메모리 누수 가능성
  - 캐싱 적용 가능 구간
</focus_areas>

이렇게 각 에이전트가 자신의 전문 영역만 집중해서 보기 때문에 단일 에이전트가 "전체적으로 검토"하는 것보다 훨씬 정밀한 결과가 나옵니다.

---

4. 오케스트레이터 설계 원칙

멀티 에이전트 시스템에서 가장 중요한 것은 오케스트레이터입니다. 오케스트레이터가 잘못 설계되면 전체 시스템이 무너집니다.

4.1. 작업 분해 — 무엇을 누구에게

오케스트레이터의 첫 번째 역할은 작업 분해입니다. 큰 작업을 독립적으로 실행 가능한 단위로 나눕니다.

# 나쁜 분해 — 에이전트 간 의존성이 너무 많다
에이전트 A: 데이터 수집하고 분석도 하고 초안도 써라
에이전트 B: A가 쓴 초안 기반으로 검토하고 수정도 해라

# 좋은 분해 — 각자의 역할이 명확하다
에이전트 A: 데이터만 수집해서 JSON으로 반환해라
에이전트 B: A가 반환한 JSON만 분석해서 인사이트를 반환해라
에이전트 C: B의 인사이트만 가지고 초안을 작성해라
에이전트 D: C의 초안만 검토해서 문제점을 반환해라

각 에이전트의 입력과 출력을 명확하게 정의하는 것이 핵심입니다. 입력이 명확해야 에이전트가 혼동 없이 작업하고, 출력이 명확해야 다음 에이전트가 결과를 활용할 수 있습니다.

4.2. 순서 제어 — 순차 vs 병렬

에이전트를 어떤 순서로 실행할지 결정하는 것도 오케스트레이터의 역할입니다.

순차 실행: 앞 에이전트의 결과가 뒤 에이전트의 입력이 되는 경우

리서치 → 분석 → 작성 → 검토
(순서를 바꾸면 작동하지 않음)

병렬 실행: 서로 독립적인 작업은 동시에 실행해서 시간을 줄입니다

경쟁사 A 리서치 ─┐
경쟁사 B 리서치 ─┼→ [결과 종합] → 분석 → 작성
경쟁사 C 리서치 ─┘
(세 리서치는 서로 독립적이므로 동시에 실행 가능)

병렬 실행은 시간을 크게 줄이지만, 각 에이전트의 결과를 종합하는 단계가 필요합니다.

4.3. 결과 검증 — 언제 재실행할 것인가

오케스트레이터는 에이전트의 결과를 받은 후 다음 단계로 넘어갈지, 재실행할지 판단합니다.

def orchestrate(task: str) -> str:
    # 1. 계획 수립
    plan = planner_agent(task)

    # 2. 리서치 (병렬)
    results = parallel_execute([
        research_agent(company) for company in COMPANIES
    ])

    # 3. 분석
    analysis = analysis_agent(results)

    # 4. 초안 작성
    draft = writer_agent(analysis)

    # 5. 검토 — 문제 있으면 재작업
    review = critic_agent(draft)
    if review.needs_revision:
        draft = writer_agent(analysis, feedback=review.feedback)

    return draft

재작업 루프는 최대 2~3회로 제한합니다. 검토자가 계속 "다시 써라"를 반복하면 무한 루프에 빠집니다.

---

5. 에이전트 간 통신 설계

에이전트들이 서로 정보를 주고받는 방식을 설계하는 것이 멀티 에이전트 시스템의 핵심 기술입니다.

5.1. 구조화된 출력 — JSON으로 넘겨라

에이전트 간 통신은 자연어보다 구조화된 형식이 훨씬 안정적입니다. 앞서 9편(Structured Output)에서 배운 내용이 여기서 직접 적용됩니다.

# 나쁜 통신 — 자연어로 결과를 넘긴다
리서치 에이전트 출력:
"경쟁사 A는 최근 AI 관련 글을 많이 쓰고 있고
 특히 프롬프트 엔지니어링 관련 콘텐츠가 인기가 많습니다..."

# 좋은 통신 — 구조화된 JSON으로 넘긴다
{
  "company": "경쟁사 A",
  "recent_topics": ["AI 프롬프트", "LLM 활용", "ChatGPT 실무"],
  "top_performing": {
    "title": "프롬프트 엔지니어링 완전 가이드",
    "estimated_traffic": "high",
    "engagement": "very_high"
  },
  "content_frequency": "주 3회",
  "avg_length": "3000자"
}

JSON을 받는 다음 에이전트는 자연어 파싱 없이 바로 데이터를 처리할 수 있습니다. 오류 가능성이 줄고 결과의 일관성이 높아집니다.

5.2. 공유 메모리 — 모든 에이전트가 볼 수 있는 공간

에이전트들이 공통으로 참조해야 하는 정보는 공유 메모리에 저장합니다.

# 공유 메모리 구조
shared_context = {
    "task": "경쟁사 분석 + 콘텐츠 캘린더",
    "target_company": "우리 회사",
    "our_recent_posts": [...],
    "constraints": {
        "budget": "월 20편 이내",
        "team_size": "2명",
        "publish_schedule": "주 2회"
    },
    "collected_data": {},   # 리서치 에이전트가 채움
    "analysis": {},         # 분석 에이전트가 채움
    "draft": "",            # 작성 에이전트가 채움
    "review_feedback": []   # 검토 에이전트가 채움
}

각 에이전트는 자신의 결과를 공유 메모리에 쓰고, 다음 에이전트는 거기서 읽습니다. 오케스트레이터가 에이전트 간에 직접 데이터를 전달하는 것보다 구조가 단순해집니다.

---

6. 실전 예시 3: 보고서 자동 생성 시스템

실제로 많이 쓰이는 멀티 에이전트 패턴입니다. 데이터를 수집해서 보고서를 만드는 파이프라인입니다.

[입력] "지난 달 우리 서비스 사용 데이터를 분석해서 임원 보고서를 만들어줘"

[데이터 수집 에이전트]
입력: 분석 기간 (지난 달)
출력: {
  "dau": [일별 DAU 배열],
  "revenue": [일별 매출 배열],
  "churn_rate": 0.032,
  "new_users": 1423,
  "top_features": ["기능A", "기능B", "기능C"]
}

[분석 에이전트]
입력: 위 JSON
출력: {
  "highlights": ["DAU 전월 대비 12% 증가", "이탈률 0.3%p 개선"],
  "concerns": ["주말 DAU 급감 패턴", "기능C 사용률 하락"],
  "recommendations": ["주말 푸시 알림 강화", "기능C UI 개선 필요"]
}

[작성 에이전트]
입력: 분석 결과
역할: 임원이 읽기 쉬운 보고서 형식으로 변환
출력: 완성된 보고서 마크다운

[검토 에이전트]
입력: 초안 보고서
체크: 수치 오류 / 논리 비약 / 임원 보고서 적합성
출력: 수정 사항 또는 최종 승인

각 에이전트의 역할이 명확히 분리되어 있기 때문에, 분석 에이전트를 교체해도 다른 에이전트에는 영향이 없습니다. 유지보수가 쉽고 개선하기도 쉽습니다.

---

7. 멀티 에이전트 실패 패턴

7.1. 역할 오염 — 에이전트가 다른 에이전트의 일을 한다

# 나쁜 사례
리서치 에이전트 출력:
"경쟁사 A는 AI 콘텐츠를 많이 씁니다.
 (분석) 이는 AI 시장이 커지고 있기 때문이고,
 (제안) 우리도 AI 콘텐츠를 늘려야 합니다."
 ← 리서치 에이전트가 분석과 제안까지 함

역할 오염이 생기면 분석 에이전트가 받는 입력이 이미 주관적 해석이 섞인 데이터가 됩니다. 오류가 다음 에이전트로 전파됩니다.

해결책은 시스템 프롬프트에 "하지 말아야 할 것"을 명시하는 것입니다.

<role>
  당신은 데이터 수집 전문 에이전트다.
  수집만 한다. 절대 분석하거나 의견을 내지 않는다.
  "~인 것 같다", "~해야 한다" 같은 표현을 쓰지 않는다.
  관찰한 사실만 반환한다.
</role>

7.2. 환각 전파 — 오류가 증폭된다

에이전트 A가 잘못된 정보를 냈을 때 에이전트 B가 그것을 사실로 받아들이고 분석하면, 에이전트 C는 더 구체화된 오류 위에서 작업합니다. 파이프라인 끝에 가면 처음 오류와 전혀 다른 형태의 문제가 나타납니다.

리서치 에이전트: "경쟁사 A의 월간 방문자는 50만 명입니다." (← 실제는 5만 명, 오류)
분석 에이전트: "50만 명 기준으로 보면 우리는 시장의 2%만 점유..."
작성 에이전트: "시장 점유율 2%라는 심각한 열세 상황에서..."
→ 보고서 전체가 잘못된 수치 기반으로 작성됨

해결책은 두 가지입니다.

첫째, 검토 에이전트가 수치의 출처를 반드시 확인하도록 지시합니다.

<instructions>
  모든 수치 주장에 대해 원본 소스를 요구한다.
  소스가 명시되지 않은 수치는 "출처 불명"으로 표시하고
  해당 주장을 검증 필요 항목으로 분류한다.
</instructions>

둘째, 에이전트의 출력에 신뢰도(confidence)를 포함시킵니다.

{
  "claim": "경쟁사 A 월간 방문자 50만 명",
  "source": "SimilarWeb 추정치",
  "confidence": "medium",
  "note": "추정치이므로 ±30% 오차 가능"
}

7.3. 책임 공백 — 아무도 최종 결정을 안 한다

에이전트들이 서로에게 결정을 미루다가 아무도 최종 결론을 내지 못하는 패턴입니다.

분석 에이전트: "작성 에이전트가 판단해야 할 것 같습니다."
작성 에이전트: "이건 분석 에이전트가 결정해야 합니다."
오케스트레이터: ???

해결책은 오케스트레이터에게 명확한 최종 결정 권한을 부여하는 것입니다.

<role>
  당신은 최종 의사결정권자다.
  하위 에이전트들의 의견이 충돌하거나 불분명할 때
  당신이 직접 판단하고 결정한다.
  "에이전트에게 다시 물어보겠다"는 선택지는 없다.
  주어진 정보로 최선의 결정을 내린다.
</role>

7.4. 과도한 에이전트 분화 — 단순한 걸 복잡하게

3줄짜리 이메일 작성에 오케스트레이터, 플래너, 작성자, 검토자를 다 붙이면 오버엔지니어링입니다. 에이전트 호출마다 LLM API 비용이 발생하고 지연 시간이 늘어납니다.

# 이런 작업은 단일 에이전트로 충분하다
- 간단한 질문에 답하기
- 짧은 텍스트 번역
- 정해진 형식으로 데이터 변환

# 멀티 에이전트가 필요한 작업
- 여러 데이터 소스를 종합해야 하는 경우
- 전문성이 다른 여러 검토가 필요한 경우
- 오류가 심각한 결과를 초래하는 경우
- 단계별 품질 보증이 필요한 경우

---

8. 단일 에이전트 vs 멀티 에이전트

실무에서는 작업의 복잡도와 품질 요구 수준에 따라 선택합니다. 단순한 작업에 멀티 에이전트를 붙이면 비용만 늘고 이점이 없습니다. 반대로 복잡한 멀티스텝 작업을 단일 에이전트에게 맡기면 품질이 떨어집니다.

---

결론: 에이전트 팀을 설계하는 법

1편부터 12편까지 프롬프트를 잘 쓰는 법을 다뤘습니다. 더 좋은 질문, 더 명확한 구조, 더 정확한 컨텍스트. 그리고 12편에서 단일 에이전트가 스스로 판단하고 행동하는 ReAct 패턴을 다뤘습니다.

13편은 그 한 단계 위입니다. 에이전트 하나가 아니라 에이전트 팀을 설계하는 것입니다. 인간 조직과 마찬가지로, 역할이 명확하고 소통이 구조화된 팀이 혼자 일하는 천재보다 복잡한 문제를 더 잘 해결합니다.

핵심 원칙은 단순합니다. 각 에이전트에게 한 가지 역할만 주고, 입출력을 명확히 하고, 오케스트레이터가 전체를 조율한다.

핵심 원칙 요약

14편을 향하여

멀티 에이전트 시스템을 설계할 줄 안다면, 자연스럽게 다음 질문이 생깁니다.

"이 에이전트들이 더 복잡한 추론을 하게 하려면 어떻게 해야 할까?"

최근 등장한 Reasoning Model(o1, o3, Claude 3.7 Sonnet 등)은 기존 모델과 다른 방식으로 생각합니다. 답변을 내놓기 전에 긴 내부 추론 과정을 거치는 이 모델들을 어떻게 프롬프팅해야 하는지는 기존 방식과 다릅니다.

[14편: Reasoning Model 프롬프팅 – o1, o3를 제대로 활용하는 법] 에서는 Reasoning Model의 작동 방식과 기존 모델과의 차이, 그리고 이 모델들에 특화된 프롬프트 전략을 다룹니다.