정리와 체크리스트

20장에서 배운 것

복합 요청 — 한 문의 안에 서로 다른 처리가 여럿 들어 있는 것. 작업으로 나눠 처리합니다.
Planner-Worker — 계획 → 실행 → 취합 세 단계로 일을 나누는 구조입니다.
Planner — 문의를 작업 목록으로 쪼갭니다. 도구 없이 구조화 출력으로 계획만 냅니다.
작업 유형(TaskType) — 계획에 들어갈 수 있는 작업의 종류. 개발자가 정한 테두리입니다.
Worker — 작업 유형 하나를 맡는 함수. 자기 일에 필요한 도구만 가집니다.
결과 이어 주기 — 앞 Worker의 보고를 쌓아 다음 Worker의 입력에 넣는 일. 코드가 합니다.
취합 — 보고들을 고객에게 보낼 답변 하나로 합칩니다.

한눈에 보는 핵심

plan = make_plan(question)                       # 계획: 모델이 작업 목록을 만든다
context = f"[고객 문의] {question}"
for i, task in enumerate(plan.tasks, 1):         # 실행: 코드가 순서대로 부른다
    out = WORKERS[task.task_type](task.instruction, context)
    context += f"\n[작업{i} 결과] {out}"          # 앞의 보고를 뒤에 넘긴다
# 취합: 보고들을 답변 하나로 (LLM 1번)

	라우터 (19장)	Planner-Worker (20장)
문의 하나에	길 하나	작업 여러 개
무엇을 할지 정하는 것	분류 결과 + 라우팅 표	모델이 세운 계획
보는 곳	한 곳	작업마다 한 곳씩, 여러 곳
LLM 호출	적다 (2번 안팎)	많다 (작업 3개면 8번 안팎)
어울리는 문의	한 가지만 묻는 문의	여러 가지를 한꺼번에 묻는 문의

체크리스트

[ ] 복합 문의가 봐야 하는 세 곳(주문 데이터, 정책 문서, 상품 데이터)을 말할 수 있다.
[ ] 계획·실행·취합 세 단계에서 각각 누가 무엇을 하는지 설명할 수 있다.
[ ] ReAct 루프와 Planner-Worker의 차이를 "계획이 어디에 있는가"로 설명할 수 있다.
[ ] 계획을 문장이 아니라 구조화 출력으로 받는 이유를 말할 수 있다.
[ ] TaskType이 계획의 테두리라는 말의 뜻을 설명할 수 있다.
[ ] Worker들이 서로의 결과를 어떻게 알게 되는지 코드로 짚을 수 있다.
[ ] "모른다"와 "없다"가 왜 다른지, 재고 안내를 예로 설명할 수 있다.
[ ] worker_stock의 프롬프트가 다른 Worker보다 긴 이유를 말할 수 있다.
[ ] 실행 결과에서 계획과 최종 답변을 견주어, 세 작업이 모두 답변에 들어갔는지 확인했다.
[ ] 문의 하나에 LLM을 몇 번쯤 부르는지 셀 수 있다.

한 줄 핵심

쪼개는 것은 모델, 쪼갤 수 있는 종류와 실행 순서는 코드가 정합니다. 단계마다 규칙을 두고, 단계마다 출력합니다.