프롬프트 체이닝과 라우팅

멀티 에이전트라는 말이 붙어 있어도, 가장 많이 등장하는 패턴은 사실 에이전트가 아니다. 프롬프트 체이닝과 라우팅은 모두 워크플로우(workflow)다. 즉 모델이 스스로 다음 행동을 정하는 것이 아니라, 흐름을 내 코드가 결정하고 모델은 각 단계에서 정해진 일만 한다. 시험은 이 구분을 집요하게 묻는다. "단계가 정해져 있고 코드가 순서를 통제할 수 있는가"라면 답은 에이전트가 아니라 워크플로우다. 더 단순한 계층으로 충분한데 에이전트를 꺼내는 것이 전형적인 오답이다.

프롬프트 체이닝

체이닝은 작업을 여러 개의 LLM 호출로 쪼개고, 한 호출의 출력을 다음 호출의 입력으로 흘려보내는 구조다. 한 번에 시키면 품질이 떨어지는 복합 작업을 단계로 분해해 각 단계의 정확도를 끌어올린다. 예를 들어 초안 작성, 사실 검증, 다듬기로 이어지는 작업은 세 번의 순차 호출로 구현된다. 중간에 게이트(gate)를 두어, 검증 단계가 통과하지 못하면 다음 단계로 진행하지 않고 재작성하거나 중단할 수 있다.

# workflow/chain.pyimport anthropicclient = anthropic.Anthropic()def call(prompt: str) -> str:    resp = client.messages.create(        model="claude-opus-4-8",        max_tokens=16000,        thinking={"type": "adaptive"},        messages=[{"role": "user", "content": prompt}],    )    return next(b.text for b in resp.content if b.type == "text")draft = call(f"다음 주제로 개요를 작성하라: {topic}")if "근거 없음" in call(f"이 개요의 사실 오류를 점검하라:\n{draft}"):    draft = call(f"지적된 오류를 고쳐 개요를 다시 써라:\n{draft}")final = call(f"이 개요를 매끄러운 산문으로 다듬어라:\n{draft}")

루프를 도는 주체가 모델이 아니라 코드라는 점에 주목하라. 각 호출은 독립적인 messages.create 한 번이고, 순서·분기·중단은 전부 파이썬이 통제한다. 이것이 체이닝을 에이전트와 가르는 결정적 차이다.

라우팅

라우팅은 입력을 먼저 분류한 뒤, 분류 결과에 따라 서로 다른 전용 처리 경로로 보내는 구조다. 고객 문의를 환불·기술지원·일반 질문으로 나눠 각기 다른 프롬프트(혹은 다른 모델)로 보내는 것이 전형이다. 분류 단계는 구조화 출력으로 구현해 결과를 안정적으로 파싱한다. 최신 모델에서는 output_config.format을 사용하며, 구버전 파라미터인 output_format은 사용하지 않는다.

# workflow/route.pyresp = client.messages.create(    model="claude-opus-4-8",    max_tokens=1024,    messages=[{"role": "user", "content": f"이 문의를 분류하라: {inquiry}"}],    output_config={"format": {"type": "json_schema", "schema": {        "type": "object",        "properties": {"category": {"type": "string",            "enum": ["refund", "tech", "general"]}},        "required": ["category"], "additionalProperties": False}}},)import jsoncategory = json.loads(next(b.text for b in resp.content if b.type == "text"))["category"]reply = HANDLERS[category](inquiry)  # 분류된 경로 하나로만 분기

라우팅의 본질은 "여러 경로 중 하나를 고른다"이다. 다음 절의 오케스트레이터-워커가 "여러 작업으로 펼친다(fan-out)"인 것과 정반대다. 시험은 이 둘을 바꿔치기해 함정을 만든다. 분기가 하나로 좁혀지면 라우팅, 여러 갈래가 동시에 펼쳐지고 그 개수를 미리 알 수 없으면 오케스트레이터-워커다.

여기서 라우팅을 "라우팅 API"라고 부르는 별도 기능으로 착각하면 안 된다. 라우팅은 어디까지나 설계 패턴이며, 분류 호출과 코드 분기로 구현된다. Anthropic이 제공하는 것은 분류를 안정화하는 구조화 출력일 뿐, 라우터라는 엔드포인트가 따로 있는 것이 아니다.

두 패턴의 차이를 한눈에 비교하면 다음과 같다. 체이닝은 출력을 다음 입력으로 흘려보내는 순차 구조이고, 라우팅은 분류 후 한 경로로 분기하는 구조다.

시험에서 어떻게 나오는가

• 함정 1. "이 작업에 에이전트가 필요한가"를 묻는 문제에서, 단계가 고정되고 코드가 순서를 통제할 수 있으면 워크플로우(체이닝·라우팅)가 정답이다. 작업이 다단계이고 사전에 완전히 명세하기 어려울 때만 에이전트로 올라간다.
• 함정 2. 라우팅과 오케스트레이터-워커를 혼동시키는 보기. "하나를 선택"이면 라우팅, "여럿으로 분해"면 오케스트레이터다.
• 핵심 포인트. 모든 코드에서 thinking은 {"type": "adaptive"}만 쓰고 budget_tokens·temperature·top_p는 쓰지 않는다. 구조화 출력은 output_config.format을 쓴다.

정리

• 프롬프트 체이닝과 라우팅은 에이전트가 아니라 코드 주도 워크플로우이며, 루프를 도는 주체는 모델이 아니라 내 코드다.
• 체이닝은 출력을 다음 입력으로 흘려보내는 순차 분해이고, 게이트로 단계 진행을 통제한다.
• 라우팅은 분류 후 하나의 경로로 분기하는 구조이며, 분류는 output_config.format 구조화 출력으로 안정화한다.
• 라우팅은 "하나 선택", 오케스트레이터-워커는 "여럿 분해"라는 점이 시험의 단골 함정이다.
• 더 단순한 계층으로 충분하면 그 계층에 머무는 것이 정답이며, 불필요한 에이전트화는 과잉설계로 채점된다.