AI 에이전트의 일반적인 워크플로 패턴과 활용 시점

https://claude.com/blog/common-workflow-patterns-for-ai-agents-and-when-to-use-them

세 가지 대표적인 워크플로 패턴을 사용해 에이전트 작업을 구조화하는 방법과, 각 패턴의 트레이드오프와 이점을 실무 관점에서 정리한 가이드입니다.

AI 에이전트는 스스로 의사결정을 내리며, 워크플로는 그 자율성에 구조를 부여하는 수단입니다. 워크플로는 여러 단계에 걸친 작업, 예측 가능한 결과, 타이밍 조율이 필요한 복잡한 문제에 대해, 에이전트의 능력을 한 방향으로 모아 실행하는 패턴을 정해 줍니다.

여러 에이전트를 함께 사용해야 할 때, 실제로 중요한 결정은 “어떤 패턴이 이 문제에 맞는가”입니다.

우리는 AI 에이전트를 구축하는 수많은 팀과 함께 작업해 왔고, 실제 프로덕션 환경에서 대부분의 사용 사례는 세 가지 패턴으로 정리됩니다: 순차(sequential), 병렬(parallel), 그리고 평가자-개선자(evaluator-optimizer) 패턴입니다.

각 패턴은 서로 다른 문제를 해결하며, 잘못 선택하면 지연(latency), 토큰 비용, 신뢰성 측면에서 대가를 치르게 됩니다. 이 글에서는 세 가지 패턴을 모두 살펴보고, 언제 어떤 패턴을 쓰면 좋을지와 패턴을 조합하는 방법을 안내합니다.

워크플로와 에이전트가 함께 동작하는 방식

팀을 관리해 본 적이 있다면, 이미 워크플로의 개념을 이해하고 있는 셈입니다.

제조업 생산라인을 떠올려 보세요. 각 공정마다 그 작업에 특화된 숙련된 작업자가 있고, 각자는 자신의 작업에 대해 의사결정을 내립니다. 하지만 전체 흐름은 사전에 설계되어 있습니다. 개별 단계에서 라우팅이나 재시도처럼 동적으로 결정되는 부분이 있더라도 마찬가지입니다.

에이전트 워크플로도 동일하게 작동합니다.

워크플로와 완전 자율 에이전트의 차이 이해하기

워크플로는 에이전트의 자율성을 대체하는 것이 아니라, 에이전트가 어디에서, 어떻게 그 자율성을 발휘할지 모양을 잡아 줍니다.

완전 자율 에이전트는 모든 것을 스스로 결정합니다. 어떤 툴을 쓸지, 어떤 순서로 작업을 실행할지, 언제 멈출지를 모두 에이전트가 정합니다.

워크플로는 전체 구조를 제공합니다. 전반적인 흐름을 정의하고, 중간 점검 지점을 만들며, 각 단계에서 에이전트가 어떻게 동작해야 하는지 경계(boundary)를 설정합니다. 그 안에서 에이전트는 여전히 동적으로 행동할 수 있습니다.

워크플로의 각 단계는 여전히 에이전트의 추론과 도구 사용을 활용할 수 있지만, 전체 오케스트레이션은 정의된 경로를 따릅니다. 워크플로 패턴은 각 단계에 에이전트의 지능을 주입하면서도, 전체 작업에 대해 예측 가능한 프로세스 흐름을 제공합니다.

에이전트 워크플로 패턴

실제 프로덕션 환경에서는 세 가지 워크플로 패턴이 가장 자주 등장합니다. 이들을 엄격한 템플릿이라기보다, 필요에 따라 조합하고 중첩할 수 있는 빌딩 블록으로 보는 것이 좋습니다.

순차 워크플로(Sequential workflows) — 고정된 순서로 작업을 실행할 때
병렬 워크플로(Parallel workflows) — 서로 독립적인 작업을 여러 에이전트에 동시에 수행시킬 때
평가자-개선자 워크플로(Evaluator-optimizer workflows) — 출력물을 반복적으로 다듬어야 할 때

각 워크플로 유형은 특정한 문제를 해결하며, 복잡도, 비용, 성능 측면에서 분명한 트레이드오프를 가집니다.

	해결하는 문제	사용할 때	트레이드오프	이점
Sequential	작업 간에 의존성이 있음: B 단계는 A 단계의 결과가 필요함	다단계 프로세스, 데이터 파이프라인, 초안–리뷰–다듬기(draft-review-polish)와 같은 사이클	각 단계가 이전 단계의 완료를 기다려야 하므로 지연이 늘어남	각 에이전트가 한 가지에 집중하게 함으로써 정확도를 높일 수 있음
Parallel	작업은 독립적이지만, 하나씩 처리하면 느림	여러 기준에 걸친 평가, 코드 리뷰, 문서 분석	여러 API 호출을 동시에 수행하므로 비용이 늘고, 결과를 모으는 전략이 필요함	전체 완료 시간을 단축하고, 엔지니어링 팀 간에 관심사를 분리하기 쉬움
Evaluator-optimizer	한 번에 생성한 초안의 품질이 충분하지 않음	기술 문서, 고객 커뮤니케이션, 특정 기준을 만족해야 하는 코드 생성	토큰 사용량이 늘어나고 반복에 따른 시간이 추가됨	구조화된 피드백 루프를 통해 더 나은 결과물을 얻을 수 있음

문제를 해결할 수 있는 가장 단순한 패턴부터 시작하세요. 기본값은 순차 워크플로입니다. 지연이 병목이고 작업이 서로 독립적일 때 병렬 패턴으로 확장하고, 품질을 높이기 위한 반복이 실제로 도움이 될 때만 평가자-개선자 루프를 추가하세요.

순차 워크플로(Sequential workflows)

순차 워크플로는 미리 정해진 순서대로 작업을 실행합니다.

각 단계의 에이전트는 입력을 받아 처리하고, 의사결정을 내리고, 필요한 경우 툴을 호출한 뒤, 그 결과를 다음 단계에 전달합니다. 이렇게 하면 출력이 시스템 전체를 따라 선형으로 흐르는 명확한 작업 체인이 만들어집니다.

사용할 때: 순차 워크플로는 작업이 자연스럽게 서로 다른 단계로 나뉘고, 각 단계 사이에 분명한 의존성이 있을 때 특히 잘 맞습니다. 모든 일을 한 번에 처리하려 하기보다는, 각 에이전트가 특정 하위 작업에 집중하도록 만들어 정확도를 높이고, 그 대가로 어느 정도 지연을 감수하는 셈입니다.

다음과 같은 경우 순차 워크플로를 사용하세요.

각 단계가 이전 결과에 의존하는 다단계 프로세스
각 단계가 특정한 가치를 더해 가는 데이터 변환 파이프라인
본질적으로 병렬화할 수 없는, 내재된 의존성이 있는 작업
초안–리뷰–다듬기와 같은 반복 개선 사이클

피해야 할 때: 하나의 에이전트만으로도 전체 작업을 효과적으로 처리할 수 있다면, 혹은 에이전트가 순차적으로 일을 넘기는 것보다 서로 협업해야 한다면, 순차 워크플로는 피하는 것이 좋습니다. 자연스럽게 순차 구조에 맞지 않는 작업을 억지로 단계로 쪼개면, 불필요한 복잡성만 더하게 됩니다.

예시: 각 단계가 확실히 다른 종류의 일을 할 때, 순차 워크플로는 특히 잘 동작합니다.

마케팅 카피를 생성한 다음, 이를 여러 언어로 번역하는 경우 혹은 문서에서 데이터를 추출하고, 스키마에 맞게 검증한 뒤, 데이터베이스에 적재하는 경우
콘텐츠 모더레이션 파이프라인 또한 순차 구조에 잘 맞습니다. 콘텐츠를 추출하고, 분류하고, 모더레이션 규칙을 적용한 뒤, 적절한 경로로 라우팅하는 식입니다.

프로 팁: 먼저 전체 파이프라인을 “단일 에이전트”로 시도해 보세요. 각 단계를 프롬프트 안의 단계(step)로만 정의하는 방식입니다. 이 정도로도 충분하다면, 추가적인 복잡성 없이 문제를 해결한 것입니다. 단일 에이전트로는 안정적으로 처리하기 어려울 때에만, 여러 단계로 나눈 워크플로로 분리하세요.

병렬 워크플로(Parallel workflows)

병렬 워크플로는 서로 독립적인 작업을 여러 에이전트에 분산시키고, 이들이 동시에 실행되도록 합니다. 한 에이전트가 끝날 때까지 기다린 후 다음 에이전트를 시작하는 대신, 여러 에이전트를 한꺼번에 실행하고, 마지막에 결과를 모읍니다.

작업들 사이에 의존성이 없을 때, 이 패턴은 상당한 속도 향상을 제공합니다.

이 접근 방식은 분산 시스템에서의 fan-out/fan-in 패턴과 유사합니다. 동일하거나 관련된 작업을 여러 에이전트에게 보내고, 각 에이전트는 독립적으로 처리한 뒤, 그 출력들을 마지막에 집계(aggregate)하거나 통합(synthesize)하는 것입니다.

에이전트들은 서로에게 일을 넘기지 않습니다. 각 에이전트는 자율적으로 동작하고, 전체 작업에 기여하는 결과만 산출합니다.

사용할 때: 병렬화는 작업을 서로 독립적인 하위 작업으로 나눌 수 있고, 이를 동시에 처리하는 것이 이득일 때 적합합니다. 또한 하나의 문제에 대해 여러 관점이 필요한 경우에도 유용합니다. 더불어, 서로 다른 에이전트가 개별적으로 최적화될 수 있게 만들어, 엔지니어들이 각 에이전트를 분리된 소유권으로 관리하기에도 좋습니다. 복잡한 작업에서는, 각 고려 사항을 별도의 AI 호출로 처리하는 편이, 하나의 호출에서 모든 것을 한꺼번에 다루려는 것보다 결과가 더 나은 경우가 많습니다.

다음과 같은 경우 병렬 워크플로를 고려하세요.

한 에이전트가 쿼리를 처리하는 동안, 다른 에이전트가 안전성 문제를 검사하는 등, 서로 다른 측면을 담당하는 섹셔닝(sectioning) 방식
각 에이전트가 다른 품질 기준을 평가하는 평가 시나리오
여러 에이전트가 동일한 콘텐츠를 분석하고, 그 결과를 집계하는 투표(voting) 패턴

피해야 할 때: 에이전트들이 누적된 컨텍스트를 공유해야 하거나, 서로의 결과를 기반으로 작업을 이어가야 하는 경우, 병렬 워크플로는 적합하지 않습니다. 또한 API 할당량과 같은 리소스 제약으로 인해 동시 처리가 비효율적일 때, 혹은 서로 모순되는 결과들을 어떻게 처리할지에 대한 명확한 전략이 없을 때도 피해야 합니다. 결과 집계가 지나치게 복잡해지거나, 오히려 전체 출력 품질을 떨어뜨린다면, 병렬화는 그만큼의 가치가 없습니다.

예시: 병렬 워크플로는 다음과 같은 상황에서 잘 동작합니다.

자동화된 평가 - 각 에이전트가 서로 다른 품질 지표를 검사하는 경우 또는 코드 리뷰 - 여러 에이전트가 각각 다른 취약성 범주를 검토하는 경우
문서 분석 역시 좋은 사례입니다. 핵심 주제 추출, 감성 분석, 사실 검증 등을 병렬로 수행한 뒤, 마지막에 통합된 인사이트를 만드는 방식입니다.

프로 팁: 병렬 에이전트를 구현하기 전에, 결과 집계 전략을 먼저 설계하세요. 다수결로 결정할 것인지? 신뢰도 점수의 평균을 낼 것인지? 가장 특화된 에이전트의 판단에 우선권을 줄 것인지? 이런 전략을 명확히 해 두면, 서로 상충하는 결과만 잔뜩 모아 놓고도 어떻게 처리해야 할지 모르는 상황을 피할 수 있습니다.

평가자-개선자 워크플로(Evaluator-optimizer workflows)

평가자-개선자 워크플로는 두 에이전트를 반복 루프로 묶는 패턴입니다. 한 에이전트가 콘텐츠를 생성하면, 다른 에이전트가 명확한 기준에 따라 이를 평가하고, 생성자는 그 피드백을 바탕으로 결과를 개선합니다. 출력물이 품질 기준을 충족하거나, 미리 정한 최대 반복 횟수에 도달할 때까지 이 과정을 반복합니다.

핵심 통찰은, 생성과 평가가 서로 다른 인지 작업이라는 점입니다. 이 둘을 분리하면, 한 에이전트는 콘텐츠 생성에 집중하고, 다른 에이전트는 일관된 품질 기준을 적용하는 데 집중할 수 있습니다.

사용할 때: 이 패턴은 AI 평가자가 일관되게 적용할 수 있는 명확하고 측정 가능한 품질 기준이 있고, 첫 시도(first attempt)와 최종 결과 사이의 품질 격차가 반복을 통해 메울 만큼 충분히 클 때 잘 맞습니다.

다음과 같은 경우 평가자-개선자 워크플로를 고려하세요.

특정 요구사항(보안 기준, 성능 벤치마크, 스타일 가이드 등)을 만족해야 하는 코드 생성
톤(tone)과 정확성이 중요한 전문적인 커뮤니케이션
첫 초안의 품질이 요구사항에 못 미치는 상황이 지속적으로 발생하는 모든 경우

피해야 할 때: 한 번에 생성한 결과가 이미 요구사항을 충족한다면, 평가자-개선자 워크플로는 불필요한 토큰 소모일 뿐입니다. 실시간으로 즉각적인 응답이 필요한 애플리케이션, 단순 분류 같은 간단한 작업, 혹은 평가 기준이 너무 주관적이라 AI 평가자가 일관되게 적용하기 어려운 경우에도 적합하지 않습니다. 코드 스타일처럼 이미 결정론적인 툴(예: 린터)이 존재하는 영역이라면, 이 패턴 대신 그런 툴을 사용하는 것이 더 낫습니다. 또한 자원 제약이 품질 향상 효과를 상쇄할 정도로 크다면, 이 패턴은 피해야 합니다.

예시: 평가자-개선자 워크플로는 다음과 같은 작업에 잘 맞습니다.

API 문서 생성: 생성자가 문서를 작성하고, 평가자가 코드베이스를 기준으로 완전성, 명확성, 정확성을 확인하는 경우
고객 커뮤니케이션 작성: 생성자가 이메일을 초안으로 만들고, 평가자가 톤과 정책 준수 여부를 평가하는 경우
SQL 쿼리 생성: 생성자가 쿼리를 작성하고, 평가자가 효율성과 보안 이슈를 점검하는 경우

프로 팁: 반복을 시작하기 전에 명확한 종료 조건을 설정하세요. 최대 반복 횟수와 구체적인 품질 기준을 정의해야 합니다. 이런 가드레일이 없으면, 평가자가 사소한 문제만 계속 발견하고, 생성자는 그에 맞춰 미세 조정을 반복하느라 비용만 늘고, 실제 품질은 훨씬 이전에 이미 정체되는 루프에 빠질 수 있습니다. 어느 시점에서 “이 정도면 충분히 좋다(good enough)”고 볼지 미리 정해 두는 것이 중요합니다.

올바른 워크플로 패턴 선택하기

적절한 워크플로 패턴 선택은, 작업의 구조, 요구되는 품질 수준, 리소스 제약에 따라 달라집니다.

패턴을 선택하기 전에, 먼저 해당 작업을 단일 에이전트 호출로 시도해 보세요. 그 결과가 품질 기준을 충족한다면, 이미 문제를 해결한 것입니다. 그렇지 않다면, 어디에서 부족한지 파악하는 것이 중요합니다. 그 부분이 바로 어떤 패턴을 써야 할지를 알려 줍니다.

다음 질문들이 결정에 도움이 됩니다.

단일 에이전트가 이 작업을 효과적으로 처리할 수 있는가?
→ 그렇다면, 워크플로는 쓰지 마세요.
작업에 분명한 순차적 의존성이 있는가?
→ 그렇다면, 순차 워크플로를 사용하세요.
하위 작업들을 서로 독립적으로, 동시에 처리할 수 있고, 완료 시간이 중요하게 작용하는가?
→ 그렇다면, 병렬 워크플로를 고려하세요.
반복적인 개선을 통해 품질이 의미 있게 향상되는가?
→ 그렇다면, 평가자-개선자 패턴을 고려하세요.

패턴을 선택한 뒤에는 다음을 함께 고민해야 합니다.

장애 처리: 각 단계에서의 폴백(fallback) 동작과 재시도(retry) 로직을 정의하세요.
지연 및 비용 제약: 동시에 몇 개의 에이전트를 실행할 수 있는지, 몇 번의 반복을 감당할 수 있는지 결정합니다.
개선 효과 측정: 단일 에이전트 기준선을 먼저 만들어 두어야, 워크플로가 실제로 도움이 되는지 판단할 수 있습니다.

패턴을 결합하기: 세 가지 패턴은 서로 배타적인 개념이 아닙니다. 복잡도가 높아질수록, 패턴을 서로 중첩해서 사용할 수 있습니다.

평가자-개선자 워크플로 내부에서, 여러 평가자가 서로 다른 품질 기준을 동시에 점검하는 병렬 평가를 사용할 수 있습니다.
순차 워크플로의 특정 단계에서, 여러 독립 작업을 다음 단계로 넘어가기 전에 병렬로 처리하도록 만들 수도 있습니다.

핵심은 패턴의 복잡도를 실제 요구사항에 맞추는 것입니다. 단지 병렬 처리가 가능하다는 이유로 병렬화를 추가하지 말고, 동시에 실행하는 것이 분명한 이득을 줄 때만 도입하세요. 마찬가지로, 평가자-개선자 루프 역시 품질을 측정 가능한 방식으로 실제로 높여 줄 때에만 구현하는 것이 좋습니다.

워크플로를 점진적으로 발전시키기

가장 중요한 조언은 다음과 같습니다. 항상 가장 단순한 패턴에서 시작하세요. 순차 워크플로만으로 사용 사례를 충분히 처리할 수 있다면, 여기에 병렬화를 추가할 필요는 없습니다. 한 번에 생성하는 결과물이 충분히 좋다면, 평가자-개선자 루프도 생략하세요.

이 세 가지 패턴은 요구사항이 바뀌었을 때 워크플로를 확장할 수 있는 명확한 업그레이드 경로를 제공합니다. 순차 워크플로는 병목이 되는 특정 단계에 병렬 처리를 추가할 수 있고, 에이전트 기반 접근은 품질 기준이 강화될 때 평가 단계를 추가할 수 있습니다. 또한 이 패턴들은 모듈식이기 때문에, 워크플로를 완전히 다시 작성하지 않고도 구조를 확장할 수 있습니다.

구현 가이드, 상세 예시, 하이브리드 방식을 포함한 고급 패턴에 대해서는, 전체 백서 효과적인 AI 에이전트 구축: 아키텍처 패턴과 구현 프레임워크를 참고하세요.