요약: 실제 에이전트 시스템은 단일 패턴을 거의 사용하지 않습니다. 대신, 여러 패턴을 연결합니다. 요청을 라우팅하고, 검색을 분산하며, 응답하기 전에 크리틱(critic)을 실행하는 식입니다. Google은 이러한 조합을 복합 패턴(composite pattern)이라고 부르며, 이것만으로도 충분하지 않을 때 사용자 정의 로직 패턴(custom logic pattern)을 제공합니다. Anthropic 역시 같은 아이디어를 빌딩 블록(building blocks)의 결합 및 커스터마이징 관점에서 설명합니다.

복합 패턴이란 무엇인가?

복합 패턴은 기본 패턴들을 결합하여 프로덕션 레벨 애플리케이션을 구축하는 방식입니다 (Google Developers). Anthropic 역시 그 빌딩 블록에 대해 같은 점을 지적합니다: 이들은 규정적인 것이 아니라, 사용 사례에 맞게 모양을 만들고 결합하는 일반적인 패턴이라는 것입니다 (Anthropic).

Google이 제시한 예시는 고객 지원 시스템입니다. 코디네이터(coordinator)가 요청을 라우팅하고, 기술적 문제가 발생하면 문서 및 사용자 기록에 대한 병렬 검색이 트리거되며, 최종 답변은 사용자에게 도달하기 전에 톤을 일관되게 유지하기 위해 제너레이터-크리틱 루프(generator-critic loop)를 거칩니다 (Google Developers).

Diagram: a pipeline of combined patterns, a coordinator routes, a parallel stage fans out, a critic gates quality, then the reply goes to the user.

하나의 패턴만으로는 부족할 때: 사용자 정의 로직

때로는 단일 패턴이 제공할 수 없는 실제 분기(branching)가 필요합니다. Google의 사용자 정의 로직 패턴은 조건문과 같은 구조를 사용하여 오케스트레이션(orchestration)을 코드로 구현할 수 있게 함으로써 최대의 유연성을 제공하며, 이를 통해 여러 분기 경로를 가진 워크플로우를 생성할 수 있습니다 (Google Cloud).

예시로 환불 에이전트가 있습니다. 코디네이터(coordinator)는 구매자와 환불 적격성을 동시에 확인하는 병렬 검증기(parallel verifier)를 실행합니다. 그런 다음 도구(tool)를 호출하여 적격성을 결정합니다. 사용자가 적격하면, 환불 처리기(refund processor)로 경로를 지정하고, 그렇지 않으면 스토어 크레딧을 위한 별도의 순차적 흐름으로 경로를 지정합니다. 어떤 경로가 실행되든, 최종 에이전트가 답변을 작성합니다 (Google Cloud). 이러한 병렬 검사와 두 가지 다른 다운스트림 프로세스로의 조건부 분기(conditional branch) 조합이야말로 사용자 지정 로직(custom logic)의 교과서적인 사례입니다.

복합 패턴 및 사용자 지정 로직 사용 시점

하나의 작업이 자연스럽게 여러 형태, 즉 결정(decision), 동시 작업(concurrent work), 품질 검사(quality check)를 포괄하는 경우에 복합 패턴을 사용합니다. 대부분의 프로덕션 시스템은 여기에 해당하는데, 실제 요청은 균일하지 않기 때문입니다.

사용자 지정 로직 패턴은 세밀한 제어(fine-grained control)가 필요하거나 워크플로우가 어떤 표준 패턴에도 맞지 않을 때 특별히 사용해야 합니다 (Google Cloud). 이는 미리 정의된 규칙과 모델 추론(model reasoning)을 혼합하는 복잡하고 분기되는 로직에 적합한 도구입니다.

사용하지 말아야 할 경우

하나의 패턴이 실패하기 전에는 여러 패턴을 결합하지 마십시오. Google 자체의 조언은 간단하게 시작하여 순차적인 체인(sequential chain)을 작동시키고, 디버깅한 다음, 비로소 복잡성을 추가하는 것입니다 (Google Developers). 첫날부터 구축된 복합 시스템은 비교할 기준점 없이 디버깅 악몽이 될 수 있습니다.

또한, 지원되는 패턴이 이미 적절하게 맞는 경우 사용자 지정 로직으로 건너뛰지 마십시오. 직접 구현한 오케스트레이션(Hand-rolled orchestration)은 유지보수하는 데 가장 많은 노력이 필요하므로, 표준 형태가 실제로 흐름을 표현할 수 없을 때만 사용해야 합니다.

알려진 문제점

알려진 문제점

커스텀 로직의 비용은 소유권(ownership)입니다. Google은 명확히 밝힙니다: 이 접근 방식은 개발 및 유지보수 복잡성을 증가시키는데, 이는 사용자가 전체 오케스트레이션 흐름을 설계하고 구현하며 디버깅할 책임이 있기 때문이며, 이는 ADK와 같은 도구가 지원하는 미리 정의된 패턴보다 오류가 발생하기 쉽습니다 (Google Cloud).

복합 시스템은 또한 구성 요소들의 모든 실패 모드를 상속받습니다. 루프를 포함하는 복합체는 영원히 반복할 수 있고, 병렬 작업을 포함하는 것은 레이스 컨디션(race condition)에 직면할 수 있으며, 라우팅을 하는 것은 잘못된 경로로 안내할 수 있습니다. 패턴을 많이 쌓을수록 실패할 지점이 많아지므로, 하나씩 추가하는 규율이 매우 중요합니다.

패턴 결합 전 세 가지 전문가 팁

Google은 이와 직접적으로 관련된 세 가지 사항으로 가이드를 마무리합니다 (Google Developers):

1. 상태를 화이트보드처럼 취급하세요. 한 에이전트가 출력을 작성할 때 설명적인 키(descriptive keys)를 사용하면, 다운스트림(downstream) 에이전트들이 정확히 무엇을 읽고 있는지 알 수 있습니다.
2. 정확한 설명을 작성하세요. 모든 라우팅 단계에서 서브-에이전트의 설명은 모델이 결정하는 데 사용하는 문서입니다. 정확해야 합니다.
3. 간단하게 시작하세요. 첫날부터 중첩 루프 시스템을 구축하지 마십시오. 체인(chain)을 작동시키고, 그 다음 측정된 단계로 복잡성을 추가하십시오.

FAQ

복합 에이전트 패턴이란 무엇인가요?
복합 패턴은 라우팅, 병렬화, 크리틱 루프(critic loop)와 같은 기본 패턴들을 하나의 시스템으로 결합하는 것입니다. 대부분의 프로덕션 에이전트는 복합체입니다.

표준 패턴 대신 커스텀 로직을 언제 사용해야 하나요?
워크플로우가 단일 패턴으로는 표현할 수 없는 분기(branching)를 필요로 하거나, 코딩된 규칙과 모델 추론을 혼합하는 세밀한 제어(fine-grained control)가 필요할 때입니다.

복합 시스템으로 바로 시작하면 안 되는가?
디버깅할 수 있는 능력을 잃기 때문입니다. 하나의 패턴부터 시작하여 검증한 다음, 다음 패턴을 추가하는 것이 좋습니다. 처음부터 복합 시스템을 구축하면 기준선(baseline)이 없고 버그를 숨기게 됩니다.

복합 시스템은 비용이 더 많이 드는가?
일반적으로 그렇습니다. 더 많은 패턴과 더 많은 모델 호출을 실행하기 때문입니다. 또한 포함된 모든 패턴의 실패 모드(failure modes)를 상속받으므로, 각 패턴에 대한 안전장치를 계획해야 합니다.

참고 자료 (Sources)

• Google Developers Blog, ADK에서의 다중 에이전트 패턴 개발자 가이드: https://developers.googleblog.com/developers-guide-to-multi-agent-patterns-in-adk/
• Google Cloud Architecture Center, 에이전트형 AI 시스템을 위한 디자인 패턴 선택: https://docs.cloud.google.com/architecture/choose-design-pattern-agentic-ai-system
• Anthropic, 효과적인 에이전트 구축: https://www.anthropic.com/engineering/building-effective-agents