8장 · 멀티에이전트 아키텍처 — 절 목차01. 한 종류로는 답이 안 나오는 질문 02. 왜 하나에 도구를 다 몰아넣지 않는가 역할 분리 03. 따라하기 네 에이전트를 한 파일로 모으기 04. 구성 방식 두 가지 한 명에게 넘기기 vs 나눠서 맡기기 05. 따라하기 팀장이 작업 목록을 만들게 하기 06. 따라하기 각 담당에게 배분하고 실행하기 07. 따라하기 여러 보고를 하나의 판단으로 합치기 08. 실행 스마트워치 Fit 5 어떻게 대응할까요 전체 데모 09. 한 담당이 실패해도 나머지는 살리기 10. 수료 무엇을 만들었고 다음에 무엇을 할 수 있나

구성 방식 두 가지 — 한 명에게 넘기기 vs 나눠서 맡기기

한 줄 요약

에이전트를 하나의 팀으로 만드는 방식은 크게 넘기기(Supervisor) 와 나누기(Planner–Worker) 입니다. 이 과정은 나누기를 씁니다. 왜 그런지, 언제 다른 쪽이 나은지 정리합니다.

1. 방법 ① — 한 명에게 넘기기 (Supervisor)

감독자 방식 — 매번 '다음은 누구'를 다시 판단한다

감독자가 한 명 부르고 → 보고를 읽고 → 다음을 정하고를 반복합니다.

감독자가 한 번에 한 명씩 지목하고, 보고를 받은 뒤 다음에 누구를 부를지 다시 정합니다.

ReAct 루프와 구조가 같습니다. 도구 대신 담당자를 부른다는 점만 다르죠.

장점	단점
앞 결과를 보고 다음을 정한다	순차적이라 느리다
필요 없으면 안 부른다	감독자 호출이 매번 일어난다
유연하다	몇 번 돌지 예측이 어렵다

2. 방법 ② — 나눠서 맡기기 (Planner–Worker)

팀장 방식 — 계획을 한 번에 세우고 나눠 맡긴 뒤 종합한다

담당은 넷이지만 매번 넷을 다 부르지는 않습니다. 위 질문에는 주문번호가 없어 주문담당이 빠집니다 — 누구를 부를지는 팀장이 정합니다.

계획을 한 번에 세우고, 워커들이 각자 조사한 뒤, 종합 단계에서 합칩니다.

장점	단점
흐름이 단순하다 (계획→실행→종합)	계획이 틀리면 전부 틀린다
몇 번 도는지 예측 가능	앞 결과를 보고 조정 못 한다
담당끼리 독립적이라 병렬화 가능	필요 없는 조사를 할 수 있다

3. 이 과정이 ②를 쓰는 이유

세 가지입니다.

① 흐름이 눈에 보인다

  [계획]
    → 데이터분석가: ...
    → 규정담당: ...
    → 시장조사원: ...
  [데이터분석가 보고] ...
  [규정담당 보고] ...
  [시장조사원 보고] ...
  [최종 답변] ...

계획 → 실행 → 종합이 화면에 그대로 찍힙니다. 배우는 입장에서 무슨 일이 일어나는지 명확합니다.

Supervisor 방식은 "감독자 호출 → 담당 호출 → 감독자 호출 → ..." 이 반복돼서 흐름을 따라가기가 더 어렵습니다.

② 우리 대표 질문에는 어차피 여럿이 필요하다

"승승 스마트워치 Fit 5, 지금 어떻게 대응해야 할까요?"

어차피 데이터분석가·규정담당·시장조사원 셋을 다 부릅니다. 그렇다면 "누구를 부를지 매번 다시 판단"할 이유가 없습니다.

앞 결과에 따라 다음이 달라지는 질문이라면 Supervisor가 낫습니다.

③ 그래프가 단순하다

아래는 code/ch08_multi_agent.py 의 일부입니다 — 위에서 이미 붙여 넣었으니 다시 넣지 마세요.

graph.add_edge(START, "plan")
graph.add_edge("plan", "execute")
graph.add_edge("execute", "synthesize")
graph.add_edge("synthesize", END)

일직선입니다. 7장에서 배운 add_edge 만으로 됩니다.

Supervisor는 되돌아가는 화살표가 필요해서 add_conditional_edges 를 써야 합니다. 7장 2절에서 "이 과정에서는 안 쓴다"고 했던 그것이죠.

4. 세 번째 방법 — 파이프라인

미리 순서를 정해 두는 방법도 있습니다.

질문 → [데이터분석가] → [규정담당] → [시장조사원] → [종합] → 답변
       (앞 결과를 다음 사람에게 넘김)

계획도 안 세웁니다. 순서가 코드에 박혀 있죠.

장점	단점
가장 단순하고 예측 가능	모든 질문에 담당을 다 부른다
앞 결과를 다음이 활용	유연성이 없다

"재고 몇 개?" 같은 질문에도 담당이 전부 움직입니다. 낭비죠.

이 과정에서 안 쓰지만, 정해진 업무 흐름(예: 매일 아침 리포트 생성)에는 파이프라인이 가장 적합합니다.

5. 세 방법 비교

	Supervisor	Planner–Worker	파이프라인
누가 정하나	감독자가 매번	팀장이 한 번	코드에 고정
흐름	반복(루프)	일직선	일직선
앞 결과 활용	✓	✗	✓
예측 가능성	낮음	높음	가장 높음
호출 수	많음	중간	적음
그래프	조건부 엣지 필요	단순 엣지	단순 엣지
이 과정		✓

6. 언제 무엇을 쓰나

상황	권장
질문이 다양하고, 앞 결과에 따라 다음이 달라짐	Supervisor
질문 유형이 정해져 있고, 담당이 독립적	Planner–Worker
업무 흐름이 고정돼 있음 (일일 리포트 등)	파이프라인
배우는 중	Planner–Worker (흐름이 보인다)

실무에서는 섞어 씁니다. 예를 들어 "Planner가 계획을 세우고, 각 워커 안에서는 ReAct 루프가 돈다" — 우리 구조가 정확히 그렇습니다. 워커는 create_agent 라서 안에서 ReAct 루프를 돕니다.

7. 우리 구조를 다시 보기

루프가 몇 개인지가 여기서 헷갈립니다. 그림으로 분명히 정리해 둡니다.

바깥은 한 바퀴, 안쪽 워커는 ReAct 루프를 몇 바퀴든 돈다

바깥은 한 바퀴, 안은 여러 바퀴입니다. 안쪽 루프는 우리가 짜지 않았습니다 — create_agent 가 돌립니다.

각 담당 안에서 도는 루프는 이렇게 생겼습니다.

   주문담당:    생각 → get_order_status 호출 → 관찰 → 답변
   데이터분석가: 생각 → run_pandas 호출 → 관찰 → 답변
   규정담당:    생각 → policy_search 호출 → 관찰 → 답변
   시장조사원:  생각 → search_web 호출 → 관찰 → 답변

4장에서 배운 루프가 담당 넷 안에 하나씩, 모두 네 겹으로 들어 있습니다. 4장 5절에서 "8장의 플래너–워커 구조는 이 루프를 한 단계 위에서 다시 그린 것" 이라고 한 것이 이 뜻입니다.

8절(전체 데모)의 호출 수 계산이 여기서 나옵니다. 작업 하나에 최소 2번인 이유는 안쪽 루프가 최소 두 바퀴(도구를 부르는 말 한 번 + 결과를 보고 답하는 말 한 번)이기 때문입니다. 작업 8개면 1 + 16 + 1 = 18번.

8. 계획을 한 번만 세우는 약점

한계도 짚고 넘어갑니다.

[계획]
  → 데이터분석가: 리뷰 반응을 분석해주세요.
  → 규정담당: 제품 사양을 알려주세요.

[데이터분석가 보고] "배터리 불만이 많다"
[규정담당 보고]    "배터리 일반 7일 / GPS 18시간"

  ← 여기서 "그럼 환불 규정도 확인해야겠다"고 판단할 자리가 없다

Supervisor라면 두 보고를 읽고 "환불 규정도 알아봐야겠다"며 규정담당을 한 번 더 부를 수 있습니다.

우리 구조에서는 종합 단계에서 그냥 답을 만듭니다.

줄이는 방법

계획을 세울 때 넉넉하게 잡으면 됩니다. 실제로 우리 실행 결과를 보면 플래너가 규정담당에게 두 가지 작업을 줬습니다.

    → 규정담당: 제품 사양(배터리·방수 등)을 알려주세요.
    → 규정담당: 환불·교환 기간 규정을 알려주세요.

같은 담당을 두 번 부른 것입니다. planner_prompt() 가 돌려주는 시스템 지시의 이 규칙 덕분이죠.

"한 task 에는 한 가지 주제만 담는다. 물어볼 것이 둘이면 task 를 둘로 나눈다."

완전한 해결은 아닙니다. 규칙으로 줄일 뿐, 보고를 읽고 계획을 다시 세우지는 못합니다. 진짜 해결은 종합에서 계획으로 되돌아가는 화살표를 다는 것인데, 그러면 Supervisor 쪽으로 한 걸음 가는 셈이고 호출도 그만큼 늡니다. 이 과정은 흐름이 눈에 보이는 쪽을 골랐습니다.

스스로 해 보기

실행 결과의 [계획] 을 보세요. 몇 개의 작업이 나왔나요? 같은 담당이 두 번 나오나요?
planner_prompt() 안에서 "한 task 에는 한 가지 주제만 담는다" 줄을 지우고 실행해 보세요. 계획이 어떻게 달라지나요?
planner_prompt() 안에서 "필요 없는 팀원은 부르지 않는다" 줄을 지우고 "P0003 재고가 몇 개인가요?" 를 물어 보세요. 몇 명을 부르나요?
파이프라인 방식으로 바꿔 보세요 — 계획 노드를 없애고 워커 넷을 순서대로 부르게. 무엇이 나빠지나요?

핵심 정리

구성 방식 셋 — Supervisor(넘기기) · Planner–Worker(나누기) · 파이프라인(고정 순서).
Supervisor 는 매번 다음 담당을 정합니다. 유연하지만 느리고 예측이 어렵습니다.
Planner–Worker 는 계획을 한 번에 세웁니다. 흐름이 단순하고 예측 가능합니다.
파이프라인은 순서가 코드에 박혀 있습니다. 정해진 업무 흐름에 적합합니다.
이 과정은 Planner–Worker 를 씁니다 — 흐름이 보이고, 대표 질문에는 어차피 여럿이 필요하고, 그래프가 단순하기 때문입니다.
우리 구조는 바깥은 Planner–Worker, 안(각 워커)은 ReAct 루프입니다. 4장의 루프가 담당 넷 안에 네 겹으로 들어 있습니다.
약점은 계획을 한 번만 세운다는 것입니다. "한 task 에 한 주제" 규칙으로 줄이지만, 완전한 해결은 되돌아가는 화살표입니다.