아키텍처

AI 워크플로 설계: 다단계 에이전트 프로세스를 위한 5가지 패턴

글쓴이: IdeaBosque최종 업데이트: 2026年9月1日

핵심 요약

OpenAI를 경유한 MCP 도구 호출은 2026년 8월 1월 수준의 98배에 도달했고, 8월 한 달에만 두 배 이상 증가했습니다(AAIF) — 하나의 사용자 요청이 이제 여러 호출로 이루어진 워크플로를 유발하며, 프롬프트 설계가 아닌 워크플로 설계가 생산 규율이 되었습니다.
Gartner는 2028년까지 에이전트 워크플로당 AI 추론 비용이 5배 이상 증가할 것으로 예측합니다 — 토큰당 가격은 하락하는데 워크플로당 비용은 상승하는데, 그 이유는 에이전트 워크플로가 채팅보다 몇 자릿수 더 많은 토큰을 소비하기 때문입니다.
MCP 로드맵은 Tasks를 공식 확장(SEP-2663)으로 개편하고 Multi Round-Trip Requests(SEP-2322)를 추가하여, 다단계 흐름이 상태 비저장 서버에서 살아남을 수 있게 했습니다 — 프로토콜은 이제 작업이 오래 실행되고 여러 라운드에 걸친다고 가정합니다.
OpenAI는 자사의 부정렬 모니터가 "에이전트가 장기간 실행되는 작업"을 일시 중지할 수 있으며, API 작업은 재개가 아닌 중지된다고 명시합니다 — 생산 워크플로는 살아 있는 프로세스가 아니라 영구 상태에서 재개 가능해야 합니다.
38개 도구의 RFQ 모듈이 이 모든 패턴을 코드로 실행합니다 — 가드로 강제된 상태 전환, 15분 TTL의 멱등한 홀드 해제, 견적 시점에 고정된 FX 스냅샷.

Agentic AI Foundation의 사용 분석에 따르면, ChatGPT 사용자의 MCP 도구 호출은 2026년 8월에 1월 수준의 98배에 도달했습니다 — 그리고 8월 한 달에만 두 배 이상 증가했습니다. Resend의 MCP 트래픽은 공급자 측에서 같은 이야기를 들려줍니다: 4월 106,719건, 8월 1,062,650건의 호출. 프로토콜의 유지 관리자들 스스로 새로운 MCP 로드맵에서 운영상의 결론을 내렸습니다: "현대의 에이전트 워크로드는 더 이상 표준 요청-응답 패턴에 맞지 않습니다. 루프는 더 오래 실행될 수 있고, 서버는 스트리밍 결과를 푸시할 수 있으며, 작업을 중간에 조종할 명확한 필요성이 있습니다."

어려운 부분은 결코 채팅이 아니었습니다. 워크플로입니다: 하나의 RFQ 뒤에 있는 카탈로그 조회의 팬아웃, ERP 쓰기 전에 도착해야 하는 승인, 견적 도중에 시간 초과되는 공급업체 API, 가격 책정과 예약 사이에서 표류하면 안 되는 환율. Gartner는 2028년까지 워크플로당 추론 비용이 5배 이상 상승할 것으로 예측합니다. 토큰당 가격이 하락하는데도 말입니다. 에이전트 워크플로는 여러 호출에 걸쳐 추론하고, 협상하고, 스스로를 다시 질문하기 때문입니다. 본문은 다단계 에이전트 프로세스가 이 부하를 견딜 수 있는지를 결정하는 5가지 워크플로 수준 패턴 — 팬아웃, 체크포인트, 보상, 영구 상태, 측정 기반 분기 — 를 정의하고, 각각을 GraphQL 백엔드에 38개의 MCP 도구를 등록하는 가동 중인 RFQ 구현에 고정시킵니다.

워크플로는 당신이 설계하는 단위입니다. 아래 다이어그램은 5가지 패턴을 1분으로 압축합니다: 병렬 읽기 팬아웃, 두 개의 인간 게이트를 가진 직렬화된 쓰기 척추, 실패 시의 타입화된 보상, 그리고 이들을 묶는 영구 상태 규칙.

패턴 1: 읽기는 팬아웃, 쓰기는 직렬화

첫 번째 워크플로 결정은 의존성 그래프의 형태입니다. 대부분의 다단계 에이전트 프로세스는 대부분 병렬입니다: 하나의 RFQ에는 세 개의 공급업체 카탈로그의 가격대, 다섯 개의 품목에 대한 배치 가용성, 고객 세그먼트가 필요합니다 — 이들은 서로 의존하지 않습니다. 이 단계들을 직렬화하면 지연 시간이 단계 수만큼 곱해지고, 단 한 번의 타임아웃 영향 반경도 곱해집니다. 올바른 기본값은 독립적인 모든 읽기를 병렬로 발산하고, 각 단계가 이전 단계의 출력을 소비하는 쓰기 체인만 직렬화하는 것입니다.

견적 워크플로에서 쓰기 체인이 엄격하게 순서화된 것은 기술적이 아닌 비즈니스적 이유 때문입니다: 요청 확정 → 견적 생성 → 가용성 홀드 → 분할 납부 계획. 우리의 RFQ 엔진은 코드 속 operation guards로 이를 강제합니다 — RequestOperationGuard는 확정되지 않은 요청으로부터 견적 생성을 거부하고, QuoteOperationGuard는 견적이 편집 가능 창을 지나면 품목 수정을 거부합니다. 워크플로 패턴은 모든 시스템에서 동일합니다: 배치 로더 뒤의 병렬 읽기, 상태 변경 쓰기를 위한 좁은 직렬화된 척추, 그리고 프롬프트가 아닌 코드 속 가드. 매 실행마다 "순서를 결정하는" 에이전트는 불변 조건이 없는 워크플로입니다.

패턴 2: 인간 체크포인트는 상태이지, 프롬프트가 아니다

두 번째 패턴은 인간이 어디에 위치하는지를 다룹니다. 프롬프트만 있는 설계에서 "제출 전에 사용자에게 묻기"는 모델이 따를 수도 따르지 않을 수도 있는 제안입니다. 워크플로 설계에서 체크포인트는 영구 상태입니다: 프로세스는 이름 있는 상태에서 멈추고, 계속하는 데 필요한 모든 것을 영속화하며, 오직 인간의 행동만이 그것을 앞으로 나아가게 합니다. 9월 1일, OpenAI가 공개했습니다. 동사의 프로덕션 부정렬 모니터가 잠재적으로 무단인 활동을 자동으로 중지할 수 있다는 것 — 그리고 그 대가를 정직하게 짚었습니다: 안전장치는 "정당한 활동을 잠재적 사이버 오용으로 가끔 표시할 수 있다…… 여기에는 사이버 보안과 직접 관련이 없어 보이는 작업이나 에이전트가 장기간 실행되는 작업이 포함될 수 있습니다". ChatGPT와 Codex에서는 사용자에게 일시 중지된 작업의 검토를 요청합니다; API에서는 작업이 중지됩니다.

그 세계를 위해 구축된 워크플로는 일시 중지를 예외가 아니라 설계된 상태로 다룹니다: 실행 기록은 무엇이 완료되었고 무엇이 대기 중인지, 재개 경로가 무엇인지 보여줍니다. 우리 RFQ 엔진의 두 편의 도구 — confirm_request_and_create_quotes와 confirm_quote_and_create_installments — 가 존재하는 이유는 바로 인간 게이트가 그들 사이에 있기 때문입니다: 인간이 확인하면, 다단계의 기계적 작업이 하나의 감사된 호출로 실행됩니다. Camunda의 1,150명 시니어 IT 리더 설문에서 조직의 71%가 AI 에이전트를 사용하지만 사용 사례의 11%만이 생산에 도달하는 것으로 나타났습니다; 그 간극을 넘는 워크플로는 승인이 시스템 프롬프트 속 한 문장이 아니라 시스템이 몇 시간이든 머물 수 있는 상태인 워크플로입니다. 체크포인트를 런타임 계층에서 강제하는 메커니즘은 Loop Engineering: 왜 에이전트 런타임이 새로운 미들웨어인가에 있습니다; 워크플로 패턴은 무엇인가를 출시하기 전에, 어떤 단계가 인간 앞에서 멈추고 프로세스가 어떤 상태에서 재개될지를 결정하는 것입니다.

패턴 3: 모든 전진 단계에는 보상 경로가 필요하다

세 번째 패턴은 튜토리얼이 건너뛰는 것입니다: 무엇이 단계를 되돌리는가. 장기 실행 워크플로는 도중에 실패합니다 — 공급업체 API가 다섯 품목 중 네 번째에서 오류를 반환하거나, 에이전트가 가격을 매기는 동안 홀드가 만료되거나, 견적은 승인되었지만 결제 일정이 실패합니다. 보상 체인이 없는 워크플로는 모든 실패를 수동 정리로 바꿉니다. 보상을 갖춘 워크플로는 모든 실패를 타입화되고 멱등한 역방향 작업으로 바꿉니다.

견적 구현은 그 해부 구조를 보여줍니다. 가용성 홀드는 15분 TTL로 만료되며, 실패 면은 타입화된 오류로 열거됩니다 — HOLD_NOT_FOUND, HOLD_ALREADY_EXPIRED, AVAILABILITY_INSUFFICIENT — 각각은 구별되는 복구에 매핑됩니다: 재확인, 재획득, 또는 인간에게 에스컬레이션. 홀드 해제는 멱등이므로 네트워크 분할 후 재시도가 이중 해제할 수 없고, 홀드 확인이 이중 차감하는 일도 없습니다. 도구 호출은 지수 백오프가 있는 재시도 데코레이터로 감싸이고, 모든 호출의 상태, 소요 시간, 페이로드(400KB 초과분은 오브젝트 스토리지로 오프로드)가 감사 레코드에 기록됩니다. 이것이 일반화된 패턴입니다: 전진 단계는 자원을 획득하고; 보상 단계는 그것을 해제하며; 모든 보상은 두 번 실행해도 안전합니다. 당신의 워크플로가 각 단계의 되돌리기를 이름 지을 수 없다면, 워크플로가 없는 것입니다 — 아직 공급업체 장애를 만나지 못한 데모가 있을 뿐입니다.

패턴 4: 상태 비저장 프로토콜, 상태 저장 워크플로

네 번째 패턴은 2026-07-28 MCP 명세의 표면상 모순을 해결합니다. 명세는 서버가 상태를 유지하지 않고 수평 확장할 수 있도록 프로토콜 수준 세션과 초기화 핸드셰이크(SEP-2575, SEP-2567)를 제거했습니다. 그리고 로드맵은 Tasks를 공식 확장(SEP-2663)으로 개편했고, Multi Round-Trip Requests(SEP-2322)가 서버 시작 요청을 대체하여 elicitation 흐름이 작업 중간에도 계속 작동합니다. 프로토콜은 상태 비저장입니다; 상태를 운반하는 것은 워크플로입니다. 구체적으로: 모든 요청은 자기완결적으로 도착해야 하며, 워크플로의 상태는 영구적이고 검사 가능한 레코드 — 서버의 메모리가 아니라 — 에 존재합니다.

이 아키텍처 선택이 바로 이전 패턴을 생존 가능하게 합니다. 우리의 RFQ 엔진에서 홀드의 hold_token과 hold_expires_at은 견적 품목에 직접 놓이고, 환율은 견적 시점에 fx_rate_locked_at 타임스탬프와 함께 고정됩니다 — 스냅샷이지 살아 있는 참조가 아닙니다. 어떤 서버 인스턴스도 다음 요청을 인수할 수 있습니다; 재시작된 프로세스는 RAM이 아니라 레코드에서 재개합니다. 그리고 Astra의 경고는 재개 가능성을 단순한 충돌 내성이 아니라 플랫폼 상호작용 요건으로 만듭니다: 프런티어 모델의 안전장치가 당신의 38시간 무인 실행을 일시 중지하면, 살아남는 워크플로는 상태를 프로세스 밖에 보관했던 워크플로입니다. 상태 비저장 명세의 배포 메커니즘은 MCP 상태 비저장 프로토콜: B2B 배포에서 무엇이 바뀌는가에서 다룹니다; 워크플로 수준에서의 규칙은 단순합니다 — 모든 단계가 일시 중지 직전의 마지막 단계일 수 있다고 가정하고 설계하며, 다음 단계가 감사 추적으로부터 재구성 가능하게 만드는 것입니다.

패턴 5: 모델 판단이 아니라 측정된 데이터로 분기한다

다섯 번째 패턴은 조건 분기를 다룹니다. 다단계 워크플로에는 의사결정 지점이 있습니다 — 이 품목이 견적할 만큼 수익성이 있는가, 이 배치가 느리게 움직여 표시해야 하는가, 이 고객 세그먼트가 할인 등급을 해제하는가. 모델에게 그 분기를 즉흥적으로 맡기면 결정론적 동작이 중요한 유일한 곳에 분산을 다시 도입합니다. 워크플로의 답은 측정된 게이트입니다: 데이터가 플래그를 실어 나르고, 분기가 그것을 읽습니다.

RFQ 엔진에서 각 견적 품목은 배치 레코드에서 적재된 guardrail_price_per_uom과 slow_move_item을 실어 나릅니다 — "정가로 견적" 대 "마진 검토 표시"의 분기는 모델에게 마진을 추정하게 하는 대신 두 필드를 읽습니다. 할인 규칙은 네 개의 계층적 범위(전역, 세그먼트, 품목, 공급업체 품목)에서 데이터로 구성되며, 추론 단계로서가 아닙니다. 여기가 워크플로 설계가 비용과 만나는 곳이기도 합니다: Gartner의 추론 분석은 "작업을 에이전트 추론 모델로 라우팅하면 공급자 추론 비용이 최소 5배 증가한다"고 경고하고, "고도로 최적화된 추론 티어링, 라우팅, 오케스트레이션"을 권장합니다. 저장된 플래그로 분기하는 워크플로는 모델 추론을 필요한 단계 — 가격 판단, 예외 해석, 협상 초안 — 를 위해 아끼고, 나머지는 타입화된 데이터가 결정하게 합니다. 같은 규율이 데이터 플랫폼에도 나타나며, Dagster의 오케스트레이션 컨텍스트 작업은 구체화 이벤트를 워크플로가 재유도하는 것이 아니라 소비하는 운영 컨텍스트로 다룹니다.

다섯 가지 패턴, 각각 한 줄로

읽기는 팬아웃, 쓰기는 직렬화 — 형태는 비즈니스 불변 조건이므로 가드로 인코딩한다. 체크포인트는 시스템이 머물 수 있는 상태다. 플랫폼 자체가 당신을 일시 중지하기 때문이다. 보상은 모든 전진 단계를 위한 일급 단계이며, 구조상 멱등이다. 상태는 프로토콜이나 프로세스가 아니라 영구 레코드에 존재한다. 분기는 측정된 플래그를 읽고, 모델 추론은 그 비용을 지불할 단계를 위해 아낀다. 이 패턴들 중 어느 것도 프레임워크 마이그레이션을 요구하지 않습니다; 모두 단계별로 누가 그것을 소유하는지 — 모델, 런타임, 아니면 인간 — 를 결정할 것을 요구합니다.

대표적인 구축 사례

호텔, 항공, 액티비티에 걸쳐 주당 200건의 단체 예약 RFQ를 처리하는 중견 투어 운영자가 이 패턴들에 기반해 견적 워크플로를 재구축했습니다. 읽기는 병렬로 발산됩니다 — 다섯 개의 카탈로그, 배치 가용성, 가격대 — 11개 도메인 믹스인에 걸쳐 38개 도구를 노출하는 단일 MCP 모듈을 통해, 각 도구의 스키마는 타입화되고 모든 호출이 감사됩니다. 쓰기 척추는 직렬화됩니다: 요청 확정, 견적 시점에 FX를 고정하여 견적 조립, 15분 TTL과 멱등 해제로 홀드 획득, 분할 납부 계획 일정화. 두 개의 인간 게이트가 자금이 걸리는 지점 — 요청 확인과 견적 확인 — 에 위치하고, 각 게이트는 프로세스가 몇 시간이든 대기할 수 있는 영속화된 상태입니다. 공급업체 API가 가격 책정 도중 시간 초과되면, 타입화된 오류가 견적을 손상시키는 대신 해당 품목을 재확인으로 라우팅합니다. 견적 처리 시간은 3일의 수동 조회에서 4시간 미만으로 단축되었고, 모든 쓰기에 인간 승인이 붙었습니다. 결과는 인력 대체가 아니라 소규모 팀을 위한 견적 처리 능력입니다.