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

AI 에이전트는 자율적으로 결정을 내리며 워크플로우는 이러한 자율성을 구조화하는 방법입니다. 조정된 단계, 예측 가능한 결과, 조율된 타이밍이 필요한 복잡한 문제로 에이전트 역량을 집중시키는 실행 패턴을 확립합니다.

여러 에이전트가 함께 작업해야 할 때 실제 결정은 어떤 패턴이 적합한지에 달려 있습니다.

AI 에이전트를 빌드하는 수십 개의 팀과 협업했는데 프로덕션 환경에서 sequential, parallel, evaluator-optimizer의 세 가지 패턴이 대부분의 사용 사례를 처리합니다.

각 패턴은 서로 다른 문제를 해결하며 패턴을 잘못 선택하면 지연 시간, 토큰, 신뢰성 측면에서 손실이 발생합니다. 이 문서는 세 가지 패턴을 상세하게 분석하고 각 패턴이 적합한 경우와 이러한 패턴을 어떻게 결합할 것인지에 대한 지침을 제공합니다.

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

팀을 관리한 적이 있다면, 이미 워크플로우를 이해하고 있는 것입니다.

제조 조립 라인을 생각해 보세요. 각 스테이션에는 특정 작업에 대해 결정을 내리는 숙련된 작업자가 있으며 개별 단계에서 라우팅이나 재시도와 같은 능동적 결정이 필요하더라도 전체 흐름은 미리 설계됩니다.

에이전트 워크플로우는 동일한 방식으로 작동합니다.

워크플로우와 자율 에이전트 이해

워크플로우는 에이전트의 자율성을 대체하지 않고, 에이전트가 자율성을 적용할 경우 및 적용 방법을 구성합니다.

완전 자율 에이전트는 모든 것을 결정합니다. 여기에는 사용할 도구, 작업 실행 순서, 중단 시점이 포함됩니다.

워크플로우는 구조를 제공합니다. 전체 흐름을 확립하고, 체크포인트를 정의하며, 각 단계에서 에이전트가 작동하는 방식의 경계를 설정하면서도 해당 경계 내에서 능동적 행동을 허용합니다.

워크플로우의 각 단계는 여전히 에이전트의 추론과 도구를 활용할 수 있지만, 전반적인 오케스트레이션은 정의된 경로를 따릅니다. 워크플로우 패턴은 각 단계 내에서 에이전트 인텔리전스를 제공하고, 전체 작업에서 예측 가능한 프로세스가 흐르게 됩니다.

에이전트 워크플로우 패턴

프로덕션 환경에서 3가지 워크플로우 패턴이 가장 자주 나타나는 것을 확인했습니다. 이러한 패턴을 엄격한 템플릿이 아니라 빌딩 블록으로 생각하세요. 요구 사항이 발전함에 따라 패턴을 결합하거나 중첩하게 되는 경우가 종종 발생할 것입니다.

1. Sequential 워크플로우 — 고정된 순서로 작업을 실행하기 위한 워크플로우입니다.
2. Parallel 워크플로우 — 에이전트 전반에서 독립적인 작업을 동시에 실행하기 위한 워크플로우입니다.
3. Evaluator-optimizer 워크플로우 — 반복적으로 개선이 필요한 결과물을 위한 워크플로우입니다.

각 워크플로우 유형은 구체적인 문제를 해결하고, 복잡성, 비용, 성능과 관련해 분명한 장단점을 가지고 있습니다.

문제를 해결하는 가장 간단한 패턴으로 시작하세요. sequential이 기본 워크플로우로 설정되어 있습니다. 지연 시간이 병목 지점이고 작업이 독립적인 경우 병렬 방식으로 전환하고, 품질 향상을 측정할 수 있는 경우에만 evaluator-optimizer 루프를 추가합니다.

Sequential 워크플로우

Sequential 워크플로우는 미리 결정된 순서대로 작업을 실행합니다.

각 단계의 에이전트는 입력값을 처리하고, 결정을 내리며, 필요에 따라 도구 호출을 수행한 뒤, 결과를 다음 단계로 전달합니다. 그 결과, 출력이 시스템을 통해 선형적으로 흐르는 명확한 작업 체인이 생성됩니다.

사용 시점: Sequential 워크플로우는 작업이 명확한 종속성과 함께 별도의 단계로 자연스럽게 나누어질 때 탁월한 성능을 발휘합니다. 각 에이전트가 모든 것을 한 번에 처리하는 대신 특정 하위 작업에 집중함으로써 정확도를 높이는 대신 약간의 지연 시간을 감수하는 것입니다.

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

• 각 단계가 이전 결과물에 따라 좌우되는 다단계 프로세스
• 각 단계가 구체적인 값을 추가하는 데이터 변환 파이프라인
• 고유한 종속성으로 인해 병렬화할 수 없는 작업
• 초안 작성-검토-다듬기 같은 반복적 개선 사이클

건너 뛰어야 할 경우: 단일 에이전트가 전체 작업을 효과적으로 처리할 수 있는 경우나 에이전트가 순차적으로 작업을 넘겨주지 않고 협업해야 하는 경우에는 순차적 워크플로우를 건너뛰세요. 작업이 구조에 자연스럽게 맞지 않는데도 순차적 단계로 강제로 진행하면 불필요한 복잡성이 추가됩니다.

예: 각 단계가 실질적으로 다른 작업을 수반할 때 순차적 워크플로우가 잘 작동합니다.

• 마케팅 카피를 생성한 다음 여러 언어로 번역하거나, 문서에서 데이터를 추출하고 스키마와 비교해 검증한 뒤 데이터베이스로 로드하는 작업
• 또한 콘텐츠 모더레이션 파이프라인은 순차적으로 잘 작동함: 콘텐츠를 추출하여 분류, 모더레이션 규칙을 적용한 뒤 적절하게 라우팅

프로 팁: 먼저 파이프라인을 단일 에이전트로 사용해 보세요. 여기서 단계는 프롬프트의 일부일 뿐입니다. 이 정도로 충분하다면, 추가적인 복잡성 없이 문제를 해결할 수 있습니다. 단일 에이전트가 안정적으로 처리할 수 없는 경우에만 다단계 워크플로우로 분할합니다.

Parallel 워크플로우

Parallel 워크플로우는 동시에 실행되는 여러 에이전트로 독립적인 작업을 분산시킵니다. 한 에이전트가 완료될 때까지 기다린 다음 에이전트를 시작하는 대신, 여러 에이전트를 동시에 실행하고 결과를 병합할 수 있습니다.

이 패턴은 작업이 서로 의존하지 않는 경우에 속도를 개선할 수 있습니다.

이 접근 방식은 분산 시스템의 팬아웃/팬인(Fan-out/Fan-in)과 유사합니다. 동일하거나 관련된 작업을 여러 에이전트에 보내고, 각 에이전트가 독립적으로 처리한 다음, 그 결과물을 집계하거나 종합합니다.

에이전트는 서로 작업을 넘겨주지 않고, 자율적으로 작동하며, 전반적인 작업에 기여하는 결과를 생성합니다.

사용 시점: 병렬화는 동시 처리 시 이득인 독립적인 하위 작업으로 나누는 것이 가능하거나, 동일한 문제에 대해 여러 관점이 필요할 때 의미가 있습니다. 또한 관심사의 분리를 가능하게 합니다. 여러 엔지니어가 서로 업무를 방해하지 않고도 개별 에이전트를 독립적으로 소유하고 최적화할 수 있습니다. 복잡한 작업의 경우, 각 고려 사항을 별도의 AI 호출로 처리하는 것이 한 번의 호출로 모든 것을 한꺼번에 처리하려는 것보다 성능이 뛰어난 경우가 많습니다.

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

• 여러 에이전트가 서로 다른 측면을 처리하는 섹션화 접근 방식(예: 에이전트 하나는 쿼리를 처리하고, 다른 에이전트 하나는 안전 문제 선별)
• 각 에이전트가 서로 다른 품질 차원을 평가하는 평가 시나리오
• 여러 에이전트가 동일한 콘텐츠를 분석하고, 사용자가 에이전트의 평가를 종합하는 투표 패턴

건너 뛰어야 할 경우: 에이전트가 누적된 컨텍스트가 필요하거나 서로의 작업을 기반으로 작업해야 하는 경우에는 parallel 워크플로우를 사용하지 마세요. API 할당량과 같은 리소스 제약으로 인해 동시 처리가 비효율적이거나, 여러 에이전트의 모순되는 결과를 처리하기 위한 명확한 전략이 부족한 경우에는 이 패턴을 건너뜁니다. 결과 집계가 너무 복잡해지거나 출력 품질이 저하된다면 병렬화를 수행할 가치가 없습니다.

예: Parallel 워크플로우는 다음과 같은 경우에 잘 작동합니다.

• 평가 자동화(각 에이전트가 서로 다른 품질 지표를 검사) 또는 코드 검토(여러 에이전트가 서로 다른 취약점 카테고리를 검토)
• 문서 분석은 또 다른 확실한 사용 사례입니다. 주요 테마 추출, 감정 분석, 사실 검증을 병렬화한 뒤, 인사이트를 결합합니다.

프로 팁: 병렬 에이전트를 구현하기 전에 결과 취합 전략을 먼저 설계하세요. 과반수 투표를 실시할 건가요? 평균 신뢰도 점수를 사용할 건가요? 가장 전문화된 에이전트에게 맡길 건가요? 결과를 종합하기 위한 명확한 계획을 세워두면 해결할 방법이 없는 상충하는 결과물이 수집되는 상황을 방지할 수 있습니다.

Evaluator-optimizer 워크플로우

Evaluator-optimizer 워크플로우는 반복적인 주기에서 두 개의 에이전트를 짝짓습니다. 하나는 콘텐츠를 생성하고, 다른 하나는 특정 기준에 대해 평가하며, 생성자는 해당 피드백을 기반으로 다듬습니다. 이 과정은 결과물이 품질 임계값에 도달하거나 최대 반복 횟수에 도달할 때까지 계속됩니다.

핵심 인사이트는 생성과 평가가 서로 다른 인지 작업이라는 것입니다. 생성과 평가를 분리하면 각 에이전트가 전문화할 수 있습니다. 생성자는 콘텐츠 생성에 집중하고 평가자는 일관된 품질 기준을 적용하는 데 집중할 수 있습니다.

사용 시점: 이 패턴은 AI 평가자가 일관되게 적용할 수 있는 명확하고 측정 가능한 품질 기준이 있을 때, 첫 번째 시도와 최종 품질 사이의 차이가 추가 토큰과 지연 시간을 정당화할 수 있을 만큼 충분히 의미가 있을 때 작동합니다.

다음과 같은 경우 evaluator-optimizer 워크플로우를 고려해 보세요.

• 구체적인 요구 사항(보안 표준, 성능 벤치마크, 스타일 가이드라인)에 따라 코드 생성
• 어조와 정확도가 중요한 전문적인 커뮤니케이션
• 첫 번째 최초 초안 작성 품질이 지속적으로 요구 사항을 충족하지 못하는 모든 시나리오

건너 뛰어야 할 경우: 최초 시도 품질이 이미 요구 사항을 충족한 경우 evaluator-optimizer 워크플로우를 건너뜁니다. 이 워크플로우를 그냥 실행하면 불필요한 반복 작업에 토큰을 낭비하게 됩니다. 즉각적인 응답이 필요한 실시간 애플리케이션이나 기본 분류와 같은 간단한 일상적인 작업이나 평가 기준이 너무 주관적이어서 AI 평가자가 일관되게 적용할 수 없는 경우에는 이 패턴을 사용하지 마세요. 코드 스타일을 위한 linter와 같은 결정적 도구가 있다면 대신 사용하세요. 또한 리소스 제약이 품질 향상보다 더 중요할 때는 이 패턴을 사용하지 마세요.

예시: Evaluator-optimizer 워크플로우는 다음과 같은 경우에 잘 작동합니다:

• API 문서 생성(생성자가 문서 작성, 평가자가 코드베이스와 비교해 완전성, 명확성, 정확성 확인)
• 고객 커뮤니케이션 작성(생성자가 이메일 초안 작성, 평가자가 어조와 정책 준수 평가)
• SQL 쿼리 생성(생성자가 쿼리 작성, 평가자는 효율성과 보안 문제 확인)

프로 팁: 반복을 시작하기 전에 명확한 정지 기준을 설정하고 최대 반복 횟수와 구체적인 품질 임계값을 정의하세요. 이러한 가드레일이 없으면 평가자가 사소한 문제를 계속 찾아내고 생성자가 계속 조정하는 비용이 큰 반복 루프에 빠질 수 있으며, 반복을 멈추기 훨씬 전에 품질은 이미 정체됩니다. 충분한 수준이 언제인지 파악하세요.

올바른 워크플로우 패턴 선택

올바른 워크플로우 패턴은 작업 구조, 품질 요구 사항, 리소스 제약에 따라 달라집니다.

패턴을 선택하기 전에 먼저 단일 에이전트 호출로 작업을 시도해 보세요. 이번 호출이 품질 기준을 충족하면 된 것입니다. 충족하지 않는 경우 부족한 부분을 식별하세요. 그러면 어떤 패턴을 선택해야 하는지 알 수 있습니다.

다음은 결정에 도움이 되는 몇 가지 질문입니다.

• 단일 에이전트가 이 작업을 효과적으로 처리할 수 있나요? 그렇다면 워크플로우를 아예 사용하지 마세요.
• 작업에 명확한 순차적 종속성이 있나요? sequential 워크플로우를 사용하세요.
• 하위 작업을 독립적으로 동시에 처리할 수 있으며, 더 빠른 완료가 도움이 되나요? parallel 워크플로우를 생각해 보세요.
• 반복적인 개선으로 품질이 의미 있게 향상되나요? evaluator-optimizer 패턴을 고려해 보세요.

패턴을 선택했으면 다음 사항을 고려하세요.

• 실패 처리: 각 단계에 대한 폴백 동작 및 재시도 로직을 정의합니다.
• 지연 시간 및 비용 제약: 이에 따라 실행할 수 있는 에이전트 수와 감당할 수 있는 반복 횟수가 결정됩니다.
• 개선 측정: 워크플로우가 실제로 도움이 되는지 여부를 판단할 수 있도록 단일 에이전트로 기준을 설정합니다.

패턴 결합: 이러한 패턴은 상호 배타적이지 않습니다. 복잡성에 필요한 경우 패턴을 중첩할 수 있습니다.

• evaluator-optimizer 워크플로우는 여러 평가자가 서로 다른 품질 차원을 동시에 평가하는 병렬 평가를 사용할 수 있습니다.
• sequential 워크플로우는 다음 단계로 넘어가기 전에 여러 개의 독립적인 작업이 수행되는 특정 단계에서 병렬 처리를 포함할 수 있습니다.

패턴 복잡성을 실제 요구 사항에 맞추는 것이 중요합니다. 할 수 있다는 이유만으로 병렬 처리를 추가하지 마세요. 동시 실행이 명확한 이점이 있을 때 추가하세요. 측정 가능한 방식으로 출력 품질을 향상시키지 않는 한, evaluator-optimizer 루프는 구현하지 마세요.

신중하게 워크플로우 발전시키기

최적의 조언: 효과적이면서 가장 간단한 패턴으로 시작하세요. sequential 워크플로우가 사용 사례를 처리하는 경우, 병렬화를 추가하지 마세요. 첫 번째 시도 품질이 충분히 좋다면 evaluator-optimizer 루프는 건너뜁니다.

이러한 세 가지 패턴을 적용하면 요구 사항이 변화할 때 명확한 경로에 따라 업그레이드할 수 있습니다. sequential 워크플로우는 병목 단계에서 병렬 처리를 통합할 수 있습니다. 품질 표준이 강화될 때 에이전틱 접근 방식은 평가를 추가할 수 있으며, 이러한 패턴은 모듈식이기 때문에 완전히 다시 작성할 필요가 없습니다.

구현 지침, 상세한 예시, 하이브리드 접근 방식을 포함한 고급 패턴은 백서(효과적인 AI 에이전트 구축: 아키텍처 패턴 및 구현 프레임워크) 전문을 확인하세요.

‍

지금 Claude Developer Platform에서 구축해 보세요.