AI 에이전트 워크플로우 패턴: 7가지 패턴과 각각이 실제로 유리한 시점 (2026)

AI 에이전트 워크플로우 패턴이 마침내 수치를 얻었다. 2026년 1월 Google Research는 180개의 에이전트 구성을 평가했고, 동일한 조율 변경이 병렬화 가능한 금융 추론에서 80.9% 향상을 가져왔으나 PlanCraft의 순차 계획에서는 최대 70%를 떨어뜨렸다. 같은 수단, 정반대의 결과. 승자를 결정하는 변수는 에이전트 수가 아니라 작업 분해 가능성이며, 아래의 7가지 패턴은 벤더 다이어그램이 아닌 공개된 데이터로 판단된다.

  • 7가지 패턴이 중요하다: 순차, 라우팅, 병렬화, 오케스트레이터-워커, 반사, ReAct, 계획-실행.
  • 작업 분해 가능성이 승자를 결정한다. 병렬화 가능한 작업은 이득을 얻고, 순차 작업은 악화된다.
  • 1개의 에이전트로 시작하라. 단일 에이전트가 ~85% 정확도 이하로 멈출 때만 두 번째를 추가하라.

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

7가지 AI 에이전트 패턴은 순차(프롬프트 체이닝), 라우팅(핸드오프), 병렬화(팬아웃/팬인), 오케스트레이터-워커, 반사(평가자-옵티마이저), ReAct, 계획-실행이다. 5개의 벤더 문서에서는 이들을 다르게 이름 붙이지만, 이 7가지 형태는 Anthropic, OpenAI, Vercel, Microsoft, Google Cloud가 현재 발표하는 모든 분류법을 포함한다. 휴먼-인-더-루프는 7가지 중 하나가 아니다: 이것은 이들 중 어느 것이든 감싸는 제어 계층이다.

측정된 열을 회의적으로 읽어라. 3개의 행은 실제 숫자를 담고 있고, 4개는 "공개 측정 없음"을 담고 있으며, 이것이 2026년 현장의 정직한 상태다. 5개 벤더는 실제로는 3-4개의 기본 형태인 것을 5가지 다른 이름으로 발표한다. 마지막 열은 이들 이름 중 어느 것이든 그 아래의 형태로 매핑할 수 있도록 존재하며, 나머지 글에서 각 족(族)별로 펼쳐진다.

SERP에서 아무도 논의하지 않는 두 가지 열은 토큰 비용과 레이턴시 예산이다. 순차와 라우팅은 둘 다 최소한만 소비한다; 오케스트레이터-워커는 둘 다 최대한 소비한다; 병렬화는 토큰 지출을 월-클록 시간으로 바꾼다. 인상적으로 보이는 다이어그램이 아니라 작업이 실제로 제약하는 리소스로 패턴을 선택하라.

AI 에이전트 워크플로우 패턴이란 무엇인가 (그리고 AI 워크플로우의 4단계는 무엇인가)?

AI 에이전트 워크플로우 설계 패턴은 LLM 호출, 도구 사용, 제어 로직을 시스템으로 배열하기 위한 재사용 가능한 형태다. 모든 벤더 분류법에서 반복되는 7가지는 순차, 라우팅, 병렬화, 오케스트레이터-워커, 반사, ReAct, 계획-실행이다. 각각은 토큰 비용, 레이턴시, 정확도를 다르게 절충하므로, 올바른 선택은 사용 중인 프레임워크가 아니라 작업의 구조에 달려있다.

전형적인 AI 에이전트 워크플로우는 루프에서 4단계를 실행한다:

  • 계획(Plan): 모델은 목표와 지금까지의 이력을 감안하여 다음에 할 일을 결정한다.
  • 행동(Act): 도구를 호출하며, 2026년에는 보통 MCP 서버 또는 함수 호출을 의미한다. 모델 컨텍스트 프로토콜(MCP)은 모델 간 도구 계층을 표준화한다.
  • 관찰(Observe): 도구 결과가 새로운 메시지로 컨텍스트에 돌아온다.
  • 반사/루프(Reflect/loop): 모델은 결과가 충분히 좋은지 판단한 다음 루프하거나 멈춘다.

이 글의 모든 패턴은 이 4단계를 배선하는 다른 방식이다. 순차는 코드에서 순서를 고정한다. ReAct는 모델이 매 턴마다 다음 단계를 선택하도록 한다. 오케스트레이터-워커는 루프를 여러 모델에 걸쳐 분할한다.

이 카탈로그 전에 하나의 구별이 중요하다. 워크플로우는 미리 결정된 코드 경로이고, 에이전트는 제어를 모델에 넘긴다. Anthropic은 건효적인 에이전트 구축에서 이 선을 그었다: "워크플로우는 잘 정의된 작업을 위한 예측 가능성과 일관성을 제공하며, 에이전트는 규모에서 유연성과 모델 주도의 의사결정이 필요할 때 더 나은 선택이다."

만약 당신이 AI의 고전적인 에이전트 유형(단순 반사, 모델 기반, 목표 기반, 학습)을 찾으러 왔다면, 그 분류법은 LLM 이전이다; 위의 7가지 패턴이 빌드 배포 여부를 결정하는 것들이다.

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

3가지 패턴은 코드에서 제어를 유지한다. 이들은 실행 비용이 가장 적고 디버깅이 가장 쉬우며, Claude 팀의 2026년 3월 지침은 어디서 시작할지에 대해 무뚝뚝하다: "문제를 해결하는 가장 단순한 패턴으로 시작하라. 기본값으로 순차를 사용하라."

순차 (프롬프트 체이닝)

한 호출이 다음 호출을 공급한다. 어려운 작업을 순서대로 된 단계로 나누고, 각 단계는 이전 단계의 출력을 입력으로 받는다. 이점은 가독성이다: 모든 중간 결과를 검사할 수 있고 각 단계를 캐시할 수 있다. 소작업이 독립적일 때는 피하라. 왜냐하면 필요하지 않은 순서 지정을 위해 레이턴시를 지불하고 있기 때문이다. 상태가 단계 간이나 세션 간에 유지되어야 한다면, 그것은 체이닝 문제가 아니라 메모리 문제다; 에이전트 메모리 가이드를 참조하라. 유일한 공개 인정은 기본값이다: 체이닝 자체로부터의 이득을 측정하는 연구가 없다. 왜냐하면 그것은 모든 다른 패턴이 이기기 위해 더 지불하는 기준선이기 때문이다.

라우팅 (핸드오프)

저렴한 분류기가 입력을 읽고 특화된 프롬프트 또는 모델로 배열한다. OpenAI는 에이전트 SDK 문서에서 이렇게 표현한다: "분류 에이전트가 대화를 특화된 에이전트로 라우팅하며, 그 특화된 에이전트가 턴의 나머지 기간 동안 활성 에이전트가 된다." 분류기가 단일 일반 경로를 실행하는 것보다 덜 신뢰할 수 있을 때는 라우팅을 피하라. 왜냐하면 모든 잘못된 라우팅은 조용한 잘못된 답변이기 때문이다. 여기서 명명된 실패 모드는 핸드오프 간 컨텍스트 손실이다: 특화된 에이전트는 라우터가 전달하는 것만 본다. 전체 추적을 가져가는 것은 컨텍스트 엔지니어링 결정이며, 이를 잘못하는 것이 라우팅된 시스템이 건망증이 있는 이유다. 토큰 수학은 어쨌든 라우팅에 유리하다: 분류기는 작은 모델(위의 gpt-4o-mini)에서 실행되므로, 라우터는 요청당 몇 백 개의 저렴한 토큰을 추가하지 비싼 두 번째 호출을 추가하지 않는다.

병렬화 (팬아웃/팬인)

독립적인 소작업이 동시에 실행되고, 병합 단계가 이들을 결합한다. Anthropic은 이를 섹셔닝(작업 분할)과 투표(동일한 작업을 여러 번 실행하고 비교)로 분할한다. 이것이 Google Research가 2026년 1월 병렬화 가능한 금융 추론에서 단일 에이전트보다 +80.9%로 측정한 형태이며, 정확히 작업이 깔끔하게 분해되었기 때문이다. 단계 n+1이 단계 n의 출력에 의존하는 순간 이를 피하라; 의존성 체인을 병렬화하면 잘못된 답변이 더 빨리 재정렬될 뿐이다. 레이턴시가 이득의 다른 절반이다: 독립적인 호출이 동시에 실행되므로, 월-클록 시간은 대략 워커 수에 따라 떨어지고 총 토큰 지출은 평탄하게 유지된다.

ReAct vs 계획-실행: 어느 추론 패턴을 사용해야 하나?

ReAct는 추론을 행동과 얽힌다: 모델이 생각하고, 도구를 호출하고, 결과를 관찰하고, 그 다음 다음 단계를 결정한다. 계획-실행은 도구가 실행되기 전에 전체 계획을 쓰고, 단계를 순서대로 실행한다. ReAct는 실행 중 놀라움에 적응한다; 계획-실행은 하나의 큰 계획 호출을 앞서 지불하고 경로를 신뢰한다.

ReAct는 모든 관찰 후 다음 단계를 결정하고, 계획-실행은 첫 번째 도구 호출 전에 전체 경로에 커밋한다.

ReAct는 Yao et al. ( arXiv 2210.03629 , v1 2022년 10월, v3 2023년 3월)에서 나왔으며, ALFWorld에서 +34% 절대 성공률과 WebShop에서 +10%를 모방 및 강화 학습 기준선에 비해 보고했으며, 단 1-2개의 문맥 내 예제를 사용했다. 이것은 도구를 사용하는 대부분의 에이전트 뒤의 기본 루프이며, #3 SERP 결과에서 빠진 부분이다: Microsoft Learn의 7,133단어 오케스트레이션 문서는 ReAct를 완전히 생략했다. 그 관찰-결정 케이던스가 ReAct가 개방형 작업("X를 찾을 때까지 탐색")을 어떤 사전 계획보다 더 잘 처리하는 이유다: 계획은 페이지를 읽기 전에 그것이 무엇을 포함하는지 추측해야 했을 것이다.

...

출처 바로가기