AI 에이전트 워크플로 패턴 7가지: 각각 언제 실제로 이기는가 (2026)

AI 에이전트 워크플로 패턴 7가지: 각각 언제 실제로 이기는가 (2026)

AI 에이전트 워크플로 패턴에 드디어 숫자가 붙었습니다. 2026년 1월, Google Research는 180가지 에이전트 구성을 평가했고, 동일한 협업 방식의 변화가 병렬화 가능한 금융 추론은 80.9% 끌어올린 반면, 순차적 계획은 PlanCraft에서 최대 70%까지 떨어뜨린 사실을 확인했습니다. 같은 레버인데 정반대의 결과입니다. 승패를 가르는 변수는 에이전트 개수가 아니라 작업 분해 가능성이며, 아래 일곱 가지 패턴은 벤더 다이어그램이 아니라 공개된 데이터로 평가합니다.

• 일곱 가지 패턴이 중요합니다: 순차형, 라우팅, 병렬화, 오케스트레이터-워커, 리플렉션, ReAct, 계획-실행.
• 승패는 작업 분해 가능성이 결정합니다. 병렬화 가능한 작업은 이득을 보고, 순차적 작업은 성능이 떨어집니다.
• 에이전트 하나로 시작하세요. 단일 에이전트가 약 85% 정확도 아래로 멈출 때만 두 번째를 추가합니다.

AI 에이전트 워크플로 패턴 한눈에 보기: 데이터가 말하는 것

일곱 가지 AI 에이전트 패턴은 순차형(프롬프트 체이닝), 라우팅(핸드오프), 병렬화(팬아웃/팬인), 오케스트레이터-워커, 리플렉션(평가자-최적화), ReAct, 계획-실행입니다. 다섯 벤더의 문서는 각각 다른 이름으로 부르지만, 이 일곱 가지 구조는 Anthropic, OpenAI, Vercel, Microsoft, Google Cloud가 현재 공개하는 모든 분류 체계를 아우릅니다. 휴먼 인 더 루프는 일곱 가지 중 하나가 아닙니다: 어떤 패턴이든 감싸는 제어 계층입니다.

측정 열은 회의적으로 읽으세요. 실제 숫자가 있는 행은 셋뿐이고, 넷은 "공개된 측정 없음"이라고 적혀 있습니다. 이것이 2026년 이 분야의 솔직한 현주소입니다. 다섯 벤더가 사실상 서너 가지에 불과한 기본 구조에 다섯 가지 다른 이름을 붙여 공개합니다. 마지막 열은 그런 이름을 무엇이든 그 아래의 기본 구조로 다시 대응시킬 수 있도록 마련했고, 이 글의 나머지 부분은 한 계열씩 차례로 풀어냅니다.

SERP의 누구도 논의하지 않는 두 가지 열은 토큰 비용과 지연 시간 예산입니다. 순차형과 라우팅은 둘 다 가장 적게 씁니다. 오케스트레이터-워커는 둘 다 가장 많이 씁니다. 병렬화는 토큰 지출을 벽시계 시간(wall-clock time)과 맞바꿉니다. 패턴은 인상적인 다이어그램이 아니라, 여러분의 작업이 실제로 제약하는 자원에 따라 고르세요.

AI 에이전트 워크플로 패턴이란 (그리고 AI 워크플로의 4단계란)?

AI 에이전트 워크플로 디자인 패턴은 LLM 호출, 도구 사용, 제어 로직을 하나의 시스템으로 배치하기 위한 재사용 가능한 구조입니다. 모든 벤더의 분류 체계에서 반복해서 등장하는 일곱 가지는 순차형, 라우팅, 병렬화, 오케스트레이터-워커, 리플렉션, ReAct, 계획-실행입니다. 각각 토큰 비용, 지연 시간, 정확도를 서로 다르게 맞바꾸기 때문에, 올바른 선택은 사용하는 프레임워크가 아니라 작업의 구조에 달려 있습니다.

전형적인 AI 에이전트 워크플로는 네 단계를 루프로 실행합니다:

1. 계획(Plan): 모델은 목표와 지금까지의 이력을 바탕으로 다음에 무엇을 할지 결정합니다.
2. 실행(Act): 도구를 호출합니다. 2026년에는 보통 MCP 서버나 함수 호출을 의미합니다. Model Context Protocol(MCP)은 모델 전반에서 그 도구 계층을 표준화합니다.
3. 관찰(Observe): 도구 결과가 새 메시지로 컨텍스트에 다시 들어갑니다.
4. 성찰 / 루프(Reflect / loop): 모델은 결과가 충분히 좋은지 판단한 뒤 루프를 돌거나 멈춥니다.

이 글의 모든 패턴은 이 네 단계를 서로 다르게 배선하는 방법입니다. 순차형은 코드 안에서 순서를 고정합니다. ReAct는 매 턴마다 모델이 다음 단계를 고르게 합니다. 오케스트레이터-워커는 루프를 여러 모델에 걸쳐 나눕니다.

카탈로그로 들어가기 전에 중요한 구분이 하나 있습니다. 워크플로는 미리 정해진 코드 경로이고, 에이전트는 모델에 제어권을 넘깁니다. Anthropic은 Building Effective Agents에서 이렇게 선을 그었습니다: "워크플로는 잘 정의된 작업에 예측 가능성과 일관성을 제공하고, 에이전트는 유연성과 모델 주도 의사결정이 대규모로 필요할 때 더 나은 선택지입니다."

AI의 고전적인 에이전트 유형(단순 반사형, 모델 기반, 목표 기반, 학습형)을 찾아오셨다면, 그 분류 체계는 LLM 이전의 것입니다. 위에서 본 일곱 가지 패턴이야말로 여러분의 빌드가 출시될지를 결정하는 패턴입니다.

결정론적 패턴: 순차형, 라우팅, 병렬화

세 가지 패턴은 제어권을 모델이 아니라 여러분의 코드 안에 둡니다. 실행 비용이 가장 싸고 디버깅이 가장 쉽습니다. 2026년 3월 Claude 팀의 안내는 어디서 시작할지 직설적으로 말합니다: "문제를 해결하는 가장 단순한 패턴으로 시작하라. 기본은 순차형이다."

순차형 (프롬프트 체이닝)

하나의 호출이 다음 호출로 이어집니다. 어려운 작업을 순서가 있는 단계로 나누고, 각 단계는 이전 단계의 출력을 입력으로 받습니다. 장점은 가독성입니다: 모든 중간 결과를 검사하고 각 단계를 캐시할 수 있습니다. 하위 작업이 독립적이라면 피하세요. 필요 없는 순서 맞추기에 지연 시간을 지불하는 셈이기 때문입니다. 상태가 단계 사이 또는 세션 사이에 살아남아야 한다면, 그건 체이닝 문제가 아니라 메모리 문제입니다. 그 구분은 에이전트 메모리 가이드를 참고하세요. 공개된 유일한 지지는 "기본값"이라는 것뿐입니다: 체이닝 자체의 이득을 측정한 연구는 없습니다. 다른 모든 패턴이 추가로 비용을 지불하면서 넘어서야 하는 기준선이기 때문입니다.

from anthropic import Anthropic

client = Anthropic()

def chain(steps: list[str], context: str = "") -> str:
    for step in steps:
        msg = client.messages.create(
            model="claude-sonnet-4-5",
            max_tokens=1024,
            messages=[{"role": "user", "content": f"{context}\n\n{step}"}],
        )
        context = msg.content[0].text
    return context

summary = chain([
    "Extract the five key claims from this report: {report}",
    "Rewrite those claims as bullets an engineer would trust.",
])

라우팅 (핸드오프)

값싼 분류기가 입력을 읽고 전문가 프롬프트나 모델로 보냅니다. OpenAI는 Agents SDK 문서에서 이렇게 설명합니다: "트리아지 에이전트가 대화를 전문가에게 라우팅하고, 그 전문가가 나머지 턴 동안 활성 에이전트가 됩니다." 분류기가 하나의 범용 경로를 그냥 실행하는 것보다 신뢰도가 낮다면 라우팅을 피하세요. 잘못된 라우팅 하나하나가 조용한 오답이기 때문입니다. 여기서 이름 붙은 실패 모드는 핸드오프 사이의 컨텍스트 손실입니다: 전문가는 라우터가 전달한 것만 봅니다. 전체 추적 기록을 가져갈지 말지는 컨텍스트 엔지니어링의 결정이며, 이를 잘못하면 라우팅된 시스템이 건망증처럼 느껴지는 이유가 됩니다. 그래도 토큰 계산은 라우팅에 유리합니다: 분류기는 작은 모델(위의 gpt-4o-mini)에서 실행되므로, 라우터는 요청당 값싼 토큰 수백 개를 추가할 뿐, 비싼 두 번째 호출을 추가하지 않습니다.

from openai import OpenAI

client = OpenAI()
SPECIALISTS = {
    "billing": "You answer billing and refund questions.",
    "technical": "You debug API errors and integration issues.",
}

def route(question: str) -> str:
    triage = client.responses.create(
        model="gpt-4o-mini",
        input=f"Reply with exactly one of {list(SPECIALISTS)}: {question}",
    )
    key = triage.output_text.strip().lower()
    return client.responses.create(
        model="gpt-4o",
        instructions=SPECIALISTS.get(key, SPECIALISTS["technical"]),
        input=question,
    ).output_text

병렬화 (팬아웃/팬인)

독립적인 하위 작업을 한꺼번에 실행한 뒤, 병합 단계에서 결과를 합칩니다. Anthropic은 이를 섹셔닝(작업 나누기)과 보팅(같은 작업을 여러 번 실행하고 비교하기)으로 나눕니다. 이것이 2026년 1월 Google Research가 병렬화 가능한 금융 추론에서 단일 에이전트 대비 +80.9%로 측정한 구조입니다. 작업이 깔끔하게 분해되었기 때문에 정확히 그 결과가 나왔습니다. 단계 n+1이 단계 n의 출력에 의존하는 순간 병렬화를 피하세요. 의존성 체인을 병렬화하면 오답을 더 빨리 재배열할 뿐입니다. 지연 시간은 이득의 다른 절반입니다: 독립적인 호출은 동시에 실행되므로 벽시계 시간은 워커 수에 대략 비례해 줄어드는 반면, 총 토큰 지출은 그대로입니다.

from concurrent.futures import ThreadPoolExecutor
from anthropic import Anthropic

client = Anthropic()

def run(subtask: str) -> str:
    msg = client.messages.create(
        model="claude-sonnet-4-5",
        max_tokens=1024,
        messages=[{"role": "user", "content": subtask}],
    )
    return msg.content[0].text

def fan_out(subtasks: list[str]) -> list[str]:
    with ThreadPoolExecutor(max_workers=len(subtasks)) as pool:
        return list(pool.map(run, subtasks))

parts = fan_out([
    "Summarize Q1 revenue drivers in two sentences.",
    "Summarize Q1 churn drivers in two sentences.",
])
merged = run(f"Combine into one executive summary:\n{parts}")

ReAct 대 계획-실행: 어떤 추론 패턴을 써야 할까?

ReAct는 추론과 행동을 번갈아 수행합니다: 모델은 생각하고, 도구를 호출하고, 결과를 관찰한 뒤, 그제서야 다음 단계를 결정합니다. 계획-실행은 도구가 실행되기 전에 전체 계획을 먼저 작성한 뒤, 단계를 순서대로 실행합니다. ReAct는 실행 중 뜻밖의 상황에 적응합니다. 계획-실행은 처음에 한 번의 큰 계획 호출에 비용을 지불하고 경로를 신뢰합니다.

ReAct는 모든 관찰 뒤에 다음 단계를 결정합니다. 계획-실행은 첫 도구 호출 전에 전체 경로를 확정합니다.

ReAct는 Yao 등의 논문(arXiv 2210.03629, v1 2022년 10월, v3 2023년 3월)에서 나왔습니다. 이 논문은 모방 학습 및 강화학습 기준선 대비 ALFWorld에서 절대값 +34%, WebShop에서 +10%의 성공률 향상을 보고했으며, 인컨텍스트 예시는 단 한두 개만 사용했습니다. 이는 도구를 사용하는 대부분의 에이전트 뒤의 기본 루프이며, SERP 3위 결과의 빈틈이기도 합니다: Microsoft Learn의 7,133단어 오케스트레이션 문서는 ReAct를 완전히 빠뜨렸습니다. 그 관찰-결정 리듬 덕분에 ReAct는 개방형 작업("X를 찾을 때까지 탐색하라")을 어떤 사전 계획보다 잘 처리합니다: 계획은 페이지를 읽기 전에 페이지 내용을 짐작해야 하기 때문입니다.

계획-실행은 Wang 등의 Plan-and-Solve Prompting(arXiv 2305.04091, ACL 2023)에서 나왔습니다. 이 논문은 먼저 작업을 하위 작업으로 나누는 계획을 세운 뒤, 그것들을 실행합니다. 논문은 평가한 열 개 데이터셋 전체에서 제로샷 연쇄 사고(chain-of-thought)를 능가했다고 보고합니다. 논문 초록이 어떤 단일 수치도 공개하지 않기 때문에 저희도 단일 수치는 인용하지 않습니다. 경로를 예측할 수 있고 매 단계마다 다시 계획하는 것이 토큰 낭비일 때 사용하세요. 트레이드오프는 취약성입니다: 3단계가 실패하면 계획-실행 루프에는 명시적인 재계획 훅이 필요한 반면, ReAct는 구조적으로 재계획합니다.

측정된 근거 행이 솔직한 단서입니다. ReAct에는 작업 단위 숫자가 담긴 2022년 논문이 있습니다. 계획-실행에는 열 개 데이터셋을 훑은 결과와 제목이 될 만한 수치가 없으며, 이것이 벤치마크보다 인용이 더 자주 되는 이유 중 하나입니다.

from anthropic import Anthropic

client = Anthropic()

def react(question: str, tools: list, max_steps: int = 8) -> str:
    messages = [{"role": "user", "content": question}]
    for _ in range(max_steps):
        msg = client.messages.create(
            model="claude-sonnet-4-5",
            max_tokens=1024,
            tools=tools,
            messages=messages,
        )
        if msg.stop_reason == "end_turn":
            return msg.content[0].text
        messages.append({"role": "assistant", "content": msg.content})
        messages.append({"role": "user", "content": dispatch(msg.content)})
    return "Stopped: hit the iteration cap with no final answer."

그 반복 상한은 선택이 아닙니다. 종료 조건 없는 ReAct 루프는 예산이 바닥날 때까지 토큰을 태웁니다. max_steps는 이 글 전체에서 가장 값싼 안전장치입니다. 계획-실행에는 한 단계 위에서 같은 안전장치가 필요합니다: 단계뿐 아니라 재계획 횟수도 제한하세요. 그렇지 않으면 실패하는 계획이 무한히 스스로를 재생성합니다.

품질 패턴: 리플렉션, 평가자-최적화, 휴먼 인 더 루프

품질 패턴은 출력 품질을 높이기 위해 추가 토큰을 씁니다. 그리고 품질을 측정할 수 있을 때만 효과가 있습니다. 리플렉션(Anthropic은 평가자-최적화라고 부릅니다)은 생성기와 비평가를 루프 안에서 돌립니다: 한 모델이 초안을 쓰고, 다른 모델이 비평하고, 초안이 개선됩니다. 출력에 테스트, 루브릭, 채점 모델로 점수를 매길 수 없다면, 비평가는 혼자서 말싸움하는 추가 토큰에 불과합니다. 그 채점기를 만드는 것이 어려운 부분입니다. 쓸 만한 점수 함수에 무엇이 필요한지는 프로덕션 에이전트 평가 가이드에서 다룹니다. 전제 조건이 성립하는 곳에서 이 패턴은 값싼 보험입니다: Anthropic은 평가자-최적화를 루프 안의 두 번의 LLM 호출, 하나는 생성하고 하나는 비평하는 것으로 설명하며, 이는 몇 초의 추가 지연 시간으로 측정 가능한 품질 향상을 사줍니다.

아무도 다이어그램으로 그리지 않는 실패 모드는 폭주하는 리플렉션입니다: 비평가와 생성기가 영원히 루프를 돌거나, 더 나쁘게는 진동합니다. 해결책은 프롬프트로 요청할 것이 아니라 코드로 작성하는, 단단한 반복 상한과 개선 없음 시 중단입니다:

def refine(task: str, score_fn, max_rounds: int = 4) -> str:
    best = generate(task)
    best_score = score_fn(best)
    for _ in range(max_rounds):
        critique = critic(task, best)
        candidate = generate(f"{task}\n\nCritique:\n{critique}")
        score = score_fn(candidate)
        if score <= best_score:
            break  # no improvement: stop spending tokens
        best, best_score = candidate, score
    return best

휴먼 인 더 루프는 여덟 번째 패턴이 아니라 제어 계층입니다. 일곱 가지 중 어떤 것이든 감쌉니다: 되돌릴 수 없는 단계가 실행되기 전에 사람이 승인합니다. 상위 6개 SERP 결과 중 이를 다루는 것은 단 2개뿐입니다. 게이트는 되돌릴 수 없는 행동, 실제 지출, 외부 커뮤니케이션으로 시스템을 떠나는 모든 것에 두세요. 그 밖의 모든 것은 무인으로 실행되거나 실행되지 말아야 합니다. 게이트 자체는 또 다른 LLM이 아니라 멍청한 코드여야 합니다: 승인 큐, 지출 임계값, 도메인 허용 목록 등. 사람이 봐야 하는지를 모델이 결정하게 두면 목적 자체가 무너집니다.

멀티 에이전트, 토큰 15배의 가치가 있나? 벤치마크가 실제로 말하는 것

오케스트레이터-워커는 일곱 번째 패턴입니다: 리더 에이전트가 작업을 분해하고, 조각을 워커 에이전트에게 위임하고, 그들이 반환한 것을 병합합니다. "멀티 에이전트"는 이 패턴을 극단으로 밀어붙인 것이지 별도의 구조가 아닙니다. 그래서 진짜 질문은 오케스트레이터가 언제 그 오버헤드를 정당화하느냐입니다.

단일 에이전트 대신 멀티 에이전트를 언제 써야 할까요? 단일 에이전트가 해당 작업에서 약 85% 정확도 아래로 멈출 때만입니다. 이 경험칙은 Google Research 연구와 함께 r/AI_Agents(2026-04-23)에서 회자되었고, 측정된 데이터와도 일치합니다: 그 기준을 넘어서면 추가된 에이전트는 정확도를 더하지 못한 채 비용과 오류 증폭만 더합니다.

저희가 검증할 수 있었던 모든 공개 수치를 나란히 놓으면 다음과 같습니다:

클릭하기 전에 주의할 점 하나: 위의 모든 Google Research 수치는 2026-01-28 블로그 게시글에서 나온 것이며, 그 뒤의 논문(arXiv 2512.08296)은 개정되었습니다. 그래서 현재 버전은 블로그의 180개와 0.513이 아니라 260개 구성과 R² = 0.373을 보고합니다. 방향은 어느 쪽이든 유지됩니다. 정확한 수치는 어떤 버전을 읽느냐에 달려 있습니다.

이 중 두 행은 습관적으로 잘못 인용되므로, 여기서 계산을 보여드립니다. Anthropic의 15배 수치는 채팅 상호작용을 기준으로 측정한 것이고, 그 단일 에이전트 수치는 4배입니다. 따라서 멀티 에이전트는 단일 에이전트 토큰의 대략 15 / 4 = 3.75배이지 15배가 아닙니다. 그리고 Google Research의 오류 증폭, 독립형 에이전트 17.2배 대 중앙 집중 4.4배는, 오케스트레이터가 에이전트를 무감독으로 놔두는 것보다 대략 17.2 / 4.4 = 3.9배 적은 오류 증폭을 의미합니다.

Anthropic의 기록을 Google Research 수치에 비춰 읽어보면, 저희의 해석은 에이전트 개수가 아니라 분해 가능성이 승패를 가르는 변수라는 것입니다. Anthropic의 리서치 작업은 병렬 하위 검색으로 깔끔하게 나뉘었고, 그래서 더 많은 에이전트가 도움이 되었습니다. Google의 순차적 계획 작업은 나뉘지 않았고, 그래서 더 많은 에이전트가 서로를 방해했습니다.

이는 시스템이 프로덕션에 도달하면 실무자들이 말하는 내용과도 일치합니다. r/AI_Agents에서 "멀티 에이전트 시스템은 프로덕션에서 완전한 악몽이다"라는 제목의 스레드(2026-04-23, 56포인트, 68댓글)는 20개 이상의 클라이언트 시스템을 출시한 작성자에게서 나왔습니다: "실제로 계속 돌아가는 것들은… 거의 민망할 정도로 단순합니다", 그리고 "에이전트 하나가 다른 에이전트와 말할 때마다 컨텍스트를 잃습니다. 그 전화 게임(전언 전달 놀이) 같습니다." 최상위 댓글은 이 섹션 전체를 압축합니다: "단일 에이전트로 문제를 해결하려 해보세요. 그 에이전트의 정확도가 85%를 넘는다면 멀티 에이전트 시스템은 어떤 가치도 더하지 못합니다."

에이전트를 추가하기 전에, Anthropic이 측정한 값싼 수정부터 시도하세요: 개선된 도구 설명 하나가 작업 완료 시간 40% 감소를 만들었고, 병렬 도구 호출은 리서치 시간을 최대 90% 줄였습니다. 둘 다 비용 면에서 두 번째 에이전트를 이깁니다. 실제 도구에서 멀티 에이전트로 간다면, Claude Code 서브에이전트는 한 줄씩 검사할 수 있는 오케스트레이터-워커입니다.

같은 패턴, 다섯 가지 이름: 프레임워크 로제타 테이블

같은 네 가지 구조가 모든 벤더 문서에서 다른 이름으로 등장하며, 네이밍은 프레임워크 사이에서 옮겨지지 않습니다. Microsoft의 "magentic"과 "group chat"은 번역하기 전까지 OpenAI SDK에서 아무 의미도 없으며, 그 번역 비용은 이 테이블이 제거해주는 실질적인 비용입니다.

다섯 벤더, 다섯 가지 어휘, 서너 가지의 진짜 구조. 실질적인 비용은 프레임워크를 바꿀 때 나타납니다: Microsoft의 Agent Framework에서 OpenAI SDK로 옮기는 팀은 코드를 한 줄도 옮기기 전에 "magentic"을 agents-as-tools로, "group chat"을 핸드오프 그래프로 다시 대응시켜야 합니다. Google Cloud의 열한 가지 이름 분류 체계가 가장 길고, Anthropic의 일곱 가지 이름 목록이 가장 많이 인용되며, Claude 블로그의 세 가지 이름이 여러분이 가장 먼저 구현하게 될 것들입니다. 구조를 읽은 뒤 SDK를 읽으세요. 열 헤더는 문서 그 자체입니다: Anthropic, Claude 블로그, OpenAI Agents SDK, Vercel AI SDK, Microsoft Learn, Google Cloud. 구조가 보이기 시작하면, 프레임워크 선택은 별개의 결정입니다. 그 부분은 2026년 최고의 AI 에이전트 프레임워크 정리와 LangGraph 대 CrewAI 대 OpenAI Agents SDK 비교에서 다룹니다.

에이전트 워크플로를 아예 쓰지 말아야 할 때는?

종종, 쓰지 말아야 합니다. r/AI_Agents에서 가장 많은 추천을 받은 의사결정 사다리(2026-03-09)는 plainly 말합니다: "if…then 문으로 해결되면 그걸 써라. 그다음 전통적 워크플로로 해결되면 그걸 써라. 그렇지 않을 때만 에이전틱 AI를 써라." 상위 3개 SERP 결과 중 둘은 구조적으로 "덜 만들라"고 말할 수 없는 클라우드 문서입니다. 저희는 그렇게 말할 수 있습니다. 이 글의 데이터도 같은 방향을 가리킵니다: 측정된 가장 큰 두 이득(+80.9%와 +90.2%)은 둘 다 깔끔하게 분해되는 작업에서 나왔고, 측정된 가장 큰 손실(−70%)은 에이전트를 그렇지 않은 작업에 강제로 밀어넣었을 때 나왔습니다.

실패 모드에는 이름이 붙어 있고, 각각에 이제 숫자가 붙습니다:

• 핸드오프 사이의 컨텍스트 손실: 에이전트 간 메시지마다 상태가 빠집니다(r/AI_Agents의 "전화 게임" 불만, 2026-04-23).
• 오류 증폭: 독립형 에이전트 17.2배 대 중앙 집중 4.4배(Google Research, 2026-01-28).
• 폭주하는 리플렉션 루프: 위의 코드처럼 반복을 제한하고 개선이 없을 때 중단하세요.
• 순차적 작업의 성능 저하: 분해되지 않는 작업을 병렬화하면 39~70% 나빠집니다(Google Research, 2026-01-28).
• 비용 폭증: 멀티 에이전트 시스템은 채팅 토큰의 대략 15배(Anthropic, 2025-06-13).

그 실패 모드마다 열 줄의 코드로 작성할 수 있는 상한이 있고, 그 상한은 여러분이 추가하려던 에이전트보다 항상 값쌉니다.

Cognition의 Walden Yan은 Don't Build Multi-Agents(2025-06-12)에서 빌더의 관점에서 같은 주장을 했습니다: "컨텍스트를 공유하고, 개별 메시지만이 아니라 전체 에이전트 추적 기록을 공유하라", 그리고 "행동은 암묵적 결정을 담고, 충돌하는 결정은 나쁜 결과를 담는다." r/AI_Agents의 비교가 저희가 계속 돌아오는 것입니다: "멀티 에이전트는 마이크로서비스와 많이 닮아 보인다. 경계가 진짜일 때는 강력하고, 경계를 지어낼 때는 고통스럽다."

Techsy가 패턴 선택에 접근하는 방법

아래 사다리는 Google Research와 Anthropic의 발견, 그리고 실무자 스레드에 대한 저희의 해석이지, 저희 자신의 측정 결과가 아닙니다. 위에서 아래로 실행하며 맞는 첫 번째 행에서 멈춥니다:

이 글의 데이터에서 세 가지가 따라옵니다. 순차형으로 시작하세요. Anthropic이 그렇게 말하고, SERP의 그 무엇도 이를 반박하지 않기 때문입니다. 분해되는 것만 병렬화하세요. 동일한 협업 변화가 +80.9%로 측정되면서 동시에 −70%로도 측정되었기 때문입니다. 그리고 두 번째 에이전트는 최후의 수단으로 취급하세요. 토큰 청구서는 현실이고 오류 증폭은 측정되었기 때문입니다. 관통하는 핵심은 에이전트 추가는 품질 움직임이 아니라 스케일링 움직임이라는 것입니다: 벤치마크는 작업이 나뉘는 곳에서만 그에 보상하고, 실무자 스레드는 그 밖의 모든 곳에서 이를 확인해줍니다. 건축하기 전에 아키텍처에 대한 제2의 의견을 원하신다면, 무료 상담을 받아보세요.

자주 묻는 질문

AI 에이전트 패턴 7가지는 무엇인가요?

일곱 가지는 순차형(프롬프트 체이닝), 라우팅(핸드오프), 병렬화(팬아웃/팬인), 오케스트레이터-워커, 리플렉션(평가자-최적화), ReAct, 계획-실행입니다. Anthropic부터 Google Cloud까지 모든 벤더의 분류 체계에서 다른 이름으로 반복 등장합니다. 휴먼 인 더 루프는 이들과 함께 논의되지만, 일곱 가지 중 어떤 것이든 감싸는 제어 계층이지 여덟 번째 패턴이 아닙니다.

AI 에이전트 워크플로의 4단계는 무엇인가요?

계획, 실행, 관찰, 성찰입니다. 모델은 다음 단계를 계획하고, 도구를 호출해 실행하고, 도구 결과가 컨텍스트에 들어오는 것을 관찰한 뒤, 목표가 달성되었는지 성찰하고 루프를 돌거나 멈춥니다. 이 글의 모든 패턴은 이 네 단계를 서로 다르게 배선하는 방법입니다.

AI 워크플로와 AI 에이전트의 차이는 무엇인가요?

워크플로는 미리 정해진 코드 경로를 따릅니다. 에이전트는 모델이 자신의 제어 흐름을 직접 지시하게 합니다. Anthropic의 규칙: 잘 정의된 작업의 예측 가능성에는 워크플로를, 모델 주도 결정이 대규모로 필요할 때의 유연성에는 에이전트를 쓰라는 것입니다. 대부분의 프로덕션 시스템은 안에 몇 개의 에이전트 단계를 담은 워크플로입니다.

ReAct 대 계획-실행: 무엇을 써야 하나요?

다음 단계가 마지막 도구가 반환한 것에 의존하고 경로가 실행 중에 바뀔 수 있으면 ReAct를 쓰세요. 경로를 사전에 예측할 수 있고 매 단계마다 재계획하는 것이 토큰 낭비라면 계획-실행을 쓰세요. ReAct는 ALFWorld에서 +34%를 측정했고(Yao 등, 2022), 계획-실행은 열 개 데이터셋에서 제로샷 CoT를 능가했습니다(Wang 등, 2023).

이런 패턴을 쓰려면 LangGraph 같은 프레임워크가 필요한가요?

아니요. 이 글의 모든 코드 블록은 평범한 SDK 호출이며, 패턴은 그것들에 이름을 붙인 프레임워크보다 먼저 존재했습니다. 프레임워크가 제 값을 하는 곳은 상태 지속성, 재시도, 추적이지 패턴 자체가 아닙니다. 하나를 고르는 중이라면, 저희 프레임워크 비교가 트레이드오프를 다룹니다.

리플렉션 루프가 영원히 도는 것은 어떻게 막나요?

두 가지 안전장치, 둘 다 코드로: 단단한 반복 상한(저희는 4라운드를 사용합니다)과 비평가의 재작성이 현재 초안보다 나은 점수를 받지 못하는 순간 멈추는 개선 없음 중단입니다. 프롬프트가 루프를 끝내리라 믿지 마세요. 모델은 비용이 얼마인지 전혀 모릅니다.

단일 에이전트로 충분할 때는 언제인가요?

해당 작업에서 대략 85% 정확도를 넘을 때입니다. Google Research 연구와 함께 r/AI_Agents(2026-04-23)에서 회자된 이 휴리스틱은 벤치마크와 일치합니다: 그 기준을 넘으면 추가 에이전트는 정확도를 더하지 못한 채 비용과 오류 증폭만 더합니다. 더 큰 것을 설계하기 전에 단일 에이전트 기준선을 측정하세요.

코드와 함께 AI 에이전트 워크플로 패턴 예시를 어디서 찾을 수 있나요?

위의 다섯 개 Python 블록은 순차형, 라우팅, 병렬화, ReAct, 리플렉션을 다루며, 모두 그대로 가져다 쓸 수 있는 평범한 SDK 호출입니다. 벤더 색이 담긴 예시로는, Vercel AI SDK가 패턴별로 실행 가능한 TypeScript를 제공하고 OpenAI Agents SDK 문서는 핸드오프와 agents-as-tools를 다룹니다. 둘 다에 대한 링크는 아래 출처 목록에 있습니다.

출처

• Anthropic, Building Effective Agents (2024-12-19)
• Anthropic, How we built our multi-agent research system (2025-06-13)
• Google Research, Towards a science of scaling agent systems (2026-01-28); 논문: arXiv 2512.08296
• Yao 등, ReAct: Synergizing Reasoning and Acting in Language Models (v3 2023-03-10)
• Wang 등, Plan-and-Solve Prompting (ACL 2023)
• Claude by Anthropic, Common workflow patterns for AI agents (2026-03-05)
• OpenAI Agents SDK, Orchestrating multiple agents
• Vercel AI SDK, Workflow Patterns
• Microsoft Learn, AI Agent Orchestration Patterns (updated 2026-05-12)
• Google Cloud, Choose a design pattern for your agentic AI system (2026-05-28)
• Cognition (Walden Yan), Don't Build Multi-Agents (2025-06-12)
• r/AI_Agents, Multi agent systems are a total nightmare in production (2026-04-23); Wait, are workflows actually better than multi-agent systems? (2026-03-09)