AI 에이전트 오케스트레이션: 실패, 승인, 재시도

여러 에이전트가 같은 프로젝트에서 작업한다고 하면 매우 효율적으로 들립니다. 하나는 작업을 계획하고, 다른 하나는 디자인을 맡고, 세 번째는 코드를 작성합니다. 문제가 생기기 전까지는 잘 작동합니다. 그리고 실패는 생각보다 자주 발생합니다.

이러한 실패를 방지하려면 신중한 워크플로우 엔지니어링이 필요합니다. 그럼 오케스트레이션된 워크플로우의 신뢰성을 떨어뜨리는 요인을 살펴보고, 프로덕션 환경의 안정성을 위한 오케스트레이션 모범 사례를 알아보겠습니다.

AI 에이전트 오케스트레이션은 여러 AI 에이전트, 모델, 도구를 조율하여 여러 단계로 이루어진 작업을 완료하는 것입니다. 하지만 어떤 에이전트를 먼저 실행할지, 에이전트가 어떤 정보를 받을지, 에이전트가 작업을 마친 후 무슨 일이 일어날지는 여전히 누군가, 혹은 무언가가 결정해야 합니다. 이것이 바로 오케스트레이터의 역할로, 관리자 역할을 하는 AI 에이전트이거나 소프트웨어로 제어되는 실행 계층입니다.

간단히 말해, 오케스트레이션 계층은 목표를 더 작은 작업으로 나누고, 종속성을 추적하며, 적절한 에이전트에 실행을 위임하고, 공유 컨텍스트를 관리하며, 결과물을 하나로 통합합니다.

오케스트레이션 실행 엔진 다이어그램: 목표 및 계획, 에이전트로 라우팅, 격리된 환경에서 도구 실행, 구조화된 결과, 영구 워크플로우 상태, 그리고 재시도, 반환, 일시 중지, 대기 또는 다음 작업으로 진행을 결정하는 검증 및 결정 단계.

오케스트레이터에 작업을 맡기면 어떤 일이 일어나는지 살펴보겠습니다.

Perplexity의 Computer 워크숍에서 다룬 예시를 살펴보겠습니다. Salesforce, Snowflake, 이메일, 캘린더, 최신 뉴스의 정보를 활용해 고객사 인텔리전스 대시보드를 구축하는 사례입니다.

목표를 이해하고 작업을 계획합니다. 오케스트레이터는 요청된 결과에서 출발해 이를 명시적인 종속성이 있는 작업으로 분해합니다. 대시보드 예시에서는 여러 소스에서 정보를 수집하고 이를 완성된 결과물로 만드는 과정이 포함됩니다. 플래너는 어떤 단계가 다른 단계에 종속되고 어떤 단계가 독립적으로 실행될 수 있는지 정합니다.
작업을 적절한 에이전트로 라우팅합니다. 오케스트레이터는 종속성이 충족된 작업을 식별하고 전문 에이전트나 모델에 작업을 위임합니다. 종속된 작업은 선행 작업이 완료될 때까지 기다립니다. Perplexity Computer는 여러 프런티어 모델을 사용하며, 워크플로우의 각 부분을 해당 작업에 적합한 시스템으로 라우팅합니다. 이를 통해 독립적인 작업을 병렬로 실행할 수도 있습니다.
통제된 환경에서 도구 호출을 실행합니다. 에이전트는 웹 검색, API, 연결된 애플리케이션, 파일 작업, 코드 실행 같은 도구를 통해 환경과 상호작용합니다. 실행 계층은 이러한 작업을 실행하고 결과를 에이전트에 반환합니다.
에이전트 간에 결과와 컨텍스트를 전달합니다. 에이전트가 작업을 마치면, 다음 다운스트림 에이전트가 작업을 이어가기 위해 관련 출력이 필요합니다. 핸드오프 기록에는 작업 ID, 출력 참조, 스키마 버전, 소스 메타데이터가 포함될 수 있습니다. 오케스트레이터는 후속 단계에 필요한 컨텍스트를 유지하면서 이러한 핸드오프를 조율합니다. 중요한 점은 에이전트가 다른 모든 에이전트의 전체 작업 기록을 자신의 컨텍스트 창에 담고 있을 필요가 없다는 것입니다.
실행 상태를 에이전트 컨텍스트와 별도로 기록합니다. 에이전트가 작업을 시작하거나 완료하거나 실패하면, 실행 엔진은 작업 상태, 실행 시도, 출력 참조, 남은 작업을 담은 영구 워크플로우 기록을 업데이트합니다. 이 기록 덕분에 오케스트레이터는 LLM이 대화 기록에서 워크플로우를 재구성하지 않아도 진행 상황을 추적하고 중단 후 작업을 재개할 수 있습니다.
결과를 검증하고 다음 단계를 결정합니다. 작업이 반환되면 오케스트레이션 계층은 해당 출력이 예상된 계약을 충족하는지, 다음 작업의 종속성이 충족되었는지 확인합니다. 문제가 발견되면 워크플로우는 수정을 위해 이전 단계로 돌아가거나 일시 중지될 수 있습니다. 그렇지 않으면 완료를 향해 진행됩니다.

단순해 보이는 AI 에이전트 오케스트레이션 뒤에는 수많은 요소가 움직이고 있습니다. 에이전트 간 조율을 어떻게 구성하느냐에 따라 실행을 얼마나 제어할 수 있는지가 결정됩니다. 물론 이 모든 조율에는 오버헤드가 따릅니다. 따라서 항상 그만한 가치가 있는 것은 아닙니다.

작업의 각 부분에 서로 다른 전문성이 필요하거나, 독립적인 작업을 병렬로 실행할 수 있거나, 다음 단계를 미리 정할 수 없을 때 멀티 에이전트 오케스트레이션을 고려하세요.

따라서 오케스트레이션은 다음 세 가지 상황에서 유용합니다:

작업에 서로 다른 전문 분야가 필요한 경우. 예를 들어 코딩 프로젝트에서는 계획, 디자인, 개발, 검토를 각각 담당하는 에이전트를 따로 두는 것이 도움이 될 수 있습니다.
독립적인 작업을 병렬로 실행할 수 있는 경우. 하나의 에이전트가 모든 작업을 순차적으로 완료하는 대신, 여러 에이전트가 동시에 작업하고 결과를 오케스트레이터에 반환할 수 있습니다.
문제가 개방형인 경우. 에이전트가 미리 정해진 순서를 따르기보다 다양한 접근 방식을 탐색하고, 결정을 내리고, 협업해야 할 수 있습니다.

그 외의 경우라면 오케스트레이션은 비용만 많이 드는 유행일 뿐입니다. 에이전트가 많아질수록 조율할 일도 늘어나고 토큰 비용도 높아질 수 있습니다.

“저는 보통 가장 단순한 방식에서 시작해 점차 발전시켜 나갑니다. 단계가 정해져 있고 반복 가능하다면 아마 워크플로우일 것입니다. 여러 에이전트를 도입할 이유가 있다고 보는 경우는 에이전트마다 책임, 권한 또는 사용자가 다를 때뿐입니다.”라고 Josh Spilker(AirOps 검색 마케팅 책임자)는 말합니다.

그런 경우에도 추가적인 모델 호출, 핸드오프, 지연 시간, 장애 지점과 비교해 이점을 따져 보세요.

에이전트 간 조율을 구성하는 일반적인 방법은 중앙 집중식, 분산식, 계층식 오케스트레이션의 세 가지입니다. 적합한 아키텍처를 선택하는 일은 결국 한 가지 질문으로 귀결됩니다. 누가 작업을 제어하며, 에이전트는 서로 어떻게 조율하는가?

중앙 집중식 오케스트레이션에서는 하나의 오케스트레이터가 프로세스를 관리합니다. 오케스트레이터는 작업을 세분화하고, 전문 에이전트에게 작업을 위임하며, 진행 상황을 추적하고, 결과를 하나로 통합합니다.

중앙 집중식 오케스트레이션 다이어그램: 하나의 오케스트레이터가 사용자 요청을 받아 리서치, 분석, 디자인 에이전트에 작업을 위임하고, 각 에이전트는 자체 도구를 사용하며, 그 결과가 결합되어 최종 대시보드가 됩니다.

장단점: 중앙 집중식 조율을 사용하면 단일 제어 지점에서 실행을 추적하고 공통 규칙을 적용하기가 더 쉽습니다. 하지만 오케스트레이터가 병목이 될 수 있으며, 시스템이 복구를 지원하지 않으면 오케스트레이터 장애로 전체 워크플로우가 중단될 수 있습니다.

분산식 오케스트레이션에서는 하나의 관리자가 모든 결정을 내리는 데 의존하지 않고 에이전트끼리 더 직접적으로 조율합니다. 에이전트는 메시지를 주고받고, 공유 상태를 읽고, 다음 단계를 독립적으로 결정할 수 있습니다.

분산식 오케스트레이션 다이어그램: 리서치, 분석, 디자인, 검토 에이전트가 서로 직접 소통하고 공유 상태 및 도구와 상호작용하여 최종 대시보드를 만듭니다.

장단점: 에이전트가 중앙 플래너를 기다리지 않고 작동할 수 있으므로, 이 방식은 탐색적 작업과 독립적인 기여에 유용합니다. 하지만 에이전트 간 의견이 다르거나, 공유 정보를 업데이트하거나, 일관된 결과에 도달해야 할 때는 조율이 더 어려워집니다.

계층식 오케스트레이션은 관리자 방식을 여러 단계로 확장합니다. 최상위 오케스트레이터가 하위 오케스트레이터에 책임을 위임하고, 하위 오케스트레이터는 각자의 전문 에이전트 그룹을 조율합니다.

영업, 재무, 법무 팀이 관여하는 엔터프라이즈 워크플로우를 생각해 보세요. 최상위 오케스트레이터는 각 워크스트림을 도메인별 코디네이터에게 위임할 수 있습니다. 그러면 각 코디네이터가 자체 전문 에이전트를 관리하고 통합된 결과를 보고하게 됩니다.

이 구조는 워크플로우의 범위가 너무 넓어 하나의 오케스트레이터가 효과적으로 관리하기 어려울 때 도움이 될 수 있습니다.

계층식 오케스트레이션 다이어그램: 최상위 오케스트레이터가 영업, 재무, 법무 오케스트레이터에 작업을 위임하고, 각 오케스트레이터는 두 개의 전문 에이전트를 관리하며, 그 작업이 결합되어 통합된 결과물이 됩니다.

장단점: 계층 구조를 사용하면 팀이 조율 책임을 나누고, 개별 분기 내에서 장애를 처리할 수도 있습니다. 하지만 핸드오프가 늘어나고, 상태 관리가 더 복잡해지며, 운영 오버헤드도 커집니다. 또한 로컬 복구는 체크포인트와 실행 상태가 어떻게 구현되었는지에 따라 달라집니다.

각 아키텍처 비교:

기준	중앙 집중식	분산식	계층식
실행 책임	하나의 오케스트레이터가 위임을 제어	에이전트가 피어 또는 공유 상태를 통해 조율	책임이 여러 오케스트레이션 단계에 분산됨
상태 일관성	단일 제어 지점을 통해 조율하기가 더 쉬움	명시적인 동기화 및 충돌 처리가 필요함	분기 내부 및 분기 간 조율이 필요함
장애 격리	중앙 컨트롤러가 핵심 종속성이 될 수 있음	개별 에이전트는 독립적으로 장애가 발생할 수 있지만, 공유 인프라는 여전히 핵심 요소임	복구를 고려해 설계하면 장애를 분기 내로 국한할 수 있음
정책 적용	공통 통제를 중앙에서 적용할 수 있음	모든 참여자에게 정책을 일관되게 적용해야 함	전역 수준과 도메인 수준에서 통제를 적용할 수 있음
운영 복잡성	일반적으로 낮음	조정 복잡성이 더 높음	여러 오케스트레이션 계층으로 인해 복잡성이 더 높음

이해해 둘 만한 차이가 하나 더 있습니다. 아키텍처는 에이전트를 누가 조정하는지를 결정합니다. 실행 패턴은 작업이 어떻게 진행되는지를 결정합니다.

실행 패턴은 다음 세 가지입니다:

순차 워크플로우: 에이전트가 미리 정해진 순서대로 작업하며, 한 에이전트의 결과가 다른 에이전트의 입력이 됩니다.
병렬 실행: 서로 독립적인 에이전트가 동시에 작업합니다.
핸드오프 기반 실행: 작업이 진행됨에 따라 제어권이 전문 에이전트 사이에서 이동합니다. 다음 단계를 처리하기에 더 적합한 에이전트가 따로 있을 때 유용하지만, 핸드오프할 때마다 작업을 이어 가는 데 필요한 정보를 보존해야 합니다.

이러한 패턴은 상호 배타적이지 않으며, 오케스트레이션 아키텍처와 일대일로 대응하지도 않습니다. 목표는 워크플로우의 의존성, 조정 요구 사항, 허용 가능한 운영 오버헤드를 뒷받침하는 가장 단순한 구조를 선택하는 것입니다.

오케스트레이션에서는 단순한 실수부터 복잡한 장애 요인까지 무엇이든 잘못될 수 있습니다. 때로는 에이전트가 제 역할을 올바르게 수행하는 것처럼 보이는데도 전체 워크플로우는 실패하기도 합니다. 실무자들의 경험을 바탕으로, 오케스트레이션된 워크플로우를 불안정하게 만드는 흔한 실수를 정리했습니다. 다음 사항에 주의하세요:

정보가 손실되는 에이전트 핸드오프. 오케스트레이터가 요약된 계획을 전문 에이전트에게 전달하지만, 요약 과정에서 제약 조건, 의존성 또는 구현 세부 사항이 누락됩니다.
성급한 팬인(fan-in) 실행. 모든 업스트림 작업이 끝나기 전에 다운스트림 에이전트가 결과 집계를 시작합니다.
비결정적 공유 상태 업데이트. 병렬 에이전트가 명확하게 정의된 병합 의미 체계 없이 같은 상태 키에 씁니다. 프레임워크가 업데이트를 처리하는 방식에 따라 쓰기 손실, 데이터 중복, 순서에 따라 달라지는 출력, 충돌하는 변경이 발생할 수 있습니다.
체크포인트와 부수 효과의 불일치. 작업이 외부 연산을 수행했지만, 워커가 실패하기 전에 그 성공적인 실행이 영구적으로 기록되지 않습니다. 복구 시 오케스트레이터는 완료되지 않은 작업을 발견하고 이를 다시 실행합니다.
사람 승인 후 재개 시의 경쟁 상태. 실행을 일시 중지했다가 재개하는 과정 자체에서 동기화 문제가 발생합니다.
위임 루프와 재시도 증폭. 책임이 겹치거나, 의존성이 순환하거나, 완료 조건이 모호해서 에이전트들이 서로에게 작업을 반복적으로 넘깁니다.
지시 수준의 통제를 실행 보안으로 오인. 오케스트레이터가 에이전트에게 특정 리소스에 접근하거나 민감한 작업을 수행하지 말라고 지시할 수는 있지만, 모델 지시는 운영 체제 권한, 네트워크 제한, 권한 부여 경계를 강제하지 않습니다. Perplexity의 보안 엔지니어링 리서치는 악의적인 지시가 없더라도 에이전트가 정당한 목표를 추구하는 과정에서 보안 경계를 넘을 수 있는 이유를 조명합니다

이러한 실패가 얼마나 다른지 주목하세요. 성급한 스케줄러 전환이나 모호한 외부 쓰기는 모두 잘못된 결과를 낳을 수 있지만, 그 원인은 실행 수명 주기의 서로 다른 부분에 있습니다. 그렇기 때문에 안정적인 오케스트레이션에는 프롬프트 개선이나 재시도 추가 이상의 것이 필요합니다.

모호한 목표와 불명확한 완료의 정의는 에이전트가 생성한 결과를 실망스럽게 만드는 경우가 많습니다. 해결책은 프롬프트 계약(에이전트를 위한 작업 범위)입니다. 실행이 시작되기 전에 목표, 제약 조건, 출력 형식, 실패 조건에 합의하세요.

예를 들어, 간헐적으로 실패하는 통합 테스트를 수정하는 에이전트의 계약은 다음과 같이 정의할 수 있습니다:

목표: 불안정한(flaky) 체크아웃 API 통합 테스트의 원인을 파악하고 수정합니다.
입력: 테스트 소스 코드, CI 실패 로그, 최근 커밋, 관련 애플리케이션 코드.
제약 조건: 테스트를 비활성화하거나, 어설션을 완화하거나, 관련 없는 애플리케이션 동작을 수정하지 마세요.
예상 출력: 코드 패치, 근본 원인에 대한 설명, 테스트 실행 결과.
수락 기준: 이전에 실패하던 테스트가 10회 연속 실행에서 통과하고, 관련 회귀 테스트 스위트도 통과합니다.
실패 조건: 근본 원인을 규명할 수 없거나, 수정으로 인해 회귀가 발생하거나, 필요한 테스트 환경을 사용할 수 없는 경우.

하지만 또 하나 중요한 부분이 있습니다. 에이전트는 언제 멈춰야 할까요?

만족스러운 결과를 내지 못했다는 이유로 에이전트가 무한정 반복해서는 안 됩니다. 무엇을 성공적인 완료로 볼지, 언제 부분적으로 완료된 작업을 반환할지, 요구 사항을 충족할 수 없어 언제 중지할지를 정의하세요. 최대 위임 깊이와 반복 횟수 제한 또는 실행 예산을 설정해 해결되지 않은 작업이 끝없는 루프가 되지 않도록 하세요.

다시 CI 예시로 돌아가 보겠습니다. 다음과 같은 중지 조건을 정의할 수 있습니다:

성공: 수정 사항이 10회 연속 테스트 실행과 관련 회귀 테스트 스위트를 통과합니다.
반복 제한: 에이전트는 후보 수정안을 최대 두 개까지만 시도할 수 있습니다.
실행 예산: 문제가 해결되지 않았더라도 에이전트는 60분 후에 중지해야 합니다.
위임 제한: 에이전트는 하나의 전문 에이전트에게 작업을 위임할 수 있으며, 그 이상의 하위 에이전트 위임은 할 수 없습니다.
부분 완료: 두 번의 시도가 모두 실패하거나 시간 제한이 만료되면, 에이전트는 발견한 내용, 시도한 변경 사항, 테스트 결과를 반환합니다.
실행 차단: 테스트 환경을 사용할 수 없으면 에이전트는 성공했다고 주장하는 대신 작업을 중지하고 차단 요인을 보고합니다.

개발자가 오케스트레이터에 너무 많은 책임을 맡기는 경우가 있는데, 그러면 오케스트레이터는 전문 에이전트를 조정하는 대신 직접 코드를 작성하거나, 디버깅하거나, 세부적인 리뷰를 수행하기 시작합니다. 이는 병목 현상을 일으킵니다. 오케스트레이터가 구현 세부 사항에 컨텍스트 예산을 소모하고, 위임이 지연되며, 결과에 대한 책임 소재가 모호해집니다.

따라서 오케스트레이터는 본연의 역할에 집중하게 하고, 원래 작업, 관련 입력, 출력 아티팩트, 실행 상태, 미해결 문제 등 구체적인 아티팩트를 참조하는 방식으로 핸드오프를 적용하세요.

다음 예를 살펴보세요. status: completed는 전체 워크플로우가 아니라 에이전트에게 할당된 작업을 가리킵니다. 테스트가 아직 pending 상태이므로 오케스트레이터는 최종 결과를 승인해서는 안 됩니다.

json

{
  "task_id": "fix-42",
  "status": "completed",
  "artifact_ref": "patch-17",
  "test_status": "pending",
  "blockers": []
}

에이전트의 대화 기록은 워크플로우 진행 상황을 신뢰할 수 있게 기록하지 못합니다. 컨텍스트 윈도우가 가득 차면 자동 압축 과정에서 중요한 세부 정보가 누락될 수 있습니다. 또한 워커가 충돌하면 다음 에이전트는 실제로 어떤 단계가 완료되었는지 알아야 합니다.

예를 들어 코딩 에이전트가 패치를 생성한 뒤 충돌하면, 다음 워커는 저장된 아티팩트를 가져와 기록된 워크플로우 상태부터 작업을 이어 가야 합니다. 하지만 에이전트가 외부 CI 실행도 트리거했다면, 오케스트레이터는 해당 작업을 반복하기 전에 그 실행 상태를 별도로 확인해 정합성을 맞춰야 합니다

따라서 실행 상태를 에이전트의 작업 컨텍스트와 분리해 두세요. 작업 상태, 실행 시도, 완료된 단계, 아티팩트 참조는 영구 스토리지에 저장하세요. 한편 전체 실행 기록을 컨텍스트 윈도우에 몰아넣는 대신, 에이전트의 현재 작업과 관련된 지시, 입력, 결과만 불러오세요.

CI 에이전트가 테스트 실행을 트리거했는데 API 요청이 타임아웃되었다고 가정해 보겠습니다. 테스트 실행이 시작되지 않은 걸까요, 아니면 CI 서비스가 실행을 대기열에 넣었는데 응답만 유실된 걸까요?

타임아웃이 반드시 작업 실패를 의미하지는 않습니다. 그렇기 때문에 다음에 무엇을 할지 결정하기 전에 오류를 구분해야 합니다:

일시적 오류(429, 503): 상한이 있는 지수 백오프와 지터를 적용해 재시도하고, Retry-After가 제공되면 이를 준수합니다.
유효성 검사 또는 권한 오류(400, 403): 같은 요청을 반복하지 말고 중지하거나 근본적인 문제를 해결합니다.
모호한 결과(쓰기가 발생했을 수 있는 상황에서의 타임아웃): 다시 시도하기 전에 작업이 성공했는지 확인합니다.

참고: 재시도 가능한 오류에도 제한이 필요합니다. 도구 호출마다 타임아웃을 설정하고, 재시도 횟수와 총 재시도 시간에 상한을 두고, 전체 워크플로우 기한을 적용해 중첩된 에이전트가 같은 작업을 계속 재시작하지 못하도록 하세요. 의존성이 반복적으로 실패하면 서킷 브레이커를 사용해 요청을 일시적으로 중단하세요.

외부 부수 효과가 있는 작업에는 논리적 작업마다 안정적인 멱등성 키를 할당하고 재시도 시 이를 재사용하세요. API가 서버 측 중복 제거를 지원하면 작업을 두 번 수행하지 않고도 반복된 요청을 인식할 수 있습니다. 지원하지 않는다면 상관관계 ID나 기타 신뢰할 수 있는 참조를 사용해 외부 시스템을 조회하세요.

무슨 일이 일어났는지 확인할 수 없다면 중지하고 에스컬레이션하세요.

다음은 CI 에이전트의 재시도 로직을 의사 코드로 표현한 예시입니다:

python

op_id = get_or_create_operation_id(
    task_id=task_id,
    patch_id=patch_id,
    action="start_ci_run"
)

try:
    return ci.start_run(commit, request_id=op_id)
except TimeoutError:
    run = ci.find_by_request_id(op_id)
    if run:
        return run

    if ci.supports_idempotency:
        return bounded_retry(
            lambda: ci.start_run(commit, request_id=op_id)
        )

    raise NeedsReconciliation(op_id)

코드 참고: 이 예시는 CI API가 요청 ID로 실행을 조회하는 기능을 지원한다고 가정합니다. request_id는 제공업체가 멱등성을 명시적으로 보장하는 경우에만 중복을 방지합니다. bounded_retry()는 설명을 위한 의사 코드입니다. 프로덕션에서는 작업별 재시도 예산(최대 시도 횟수 또는 경과 시간)과 전체 워크플로우 기한 모두로 재시도를 제한해야 합니다.

여러 서비스에 걸친 긴 워크플로우에서는 이후 단계가 실패할 때 보상 작업을 조정하기 위해 Saga 패턴을 고려해 보세요. 다만 보상이 항상 완전한 롤백은 아니라는 점을 기억하세요. 데이터베이스 업데이트는 되돌릴 수 있지만, 이미 보낸 이메일은 취소할 수 없습니다.

여기서 균형을 맞춰야 할 것은 두 가지입니다. 각 작업에 필요한 모델 성능의 수준과 동시에 실행할 수 있는 작업의 수입니다. 둘 중 하나라도 잘못 판단하면 에이전트들이 공유 API 할당량을 두고 경쟁하거나 값비싼 추론 모델에만 의존하게 될 위험이 있습니다.

모델 선택의 경우, 모델 성능과 추론 강도를 작업 복잡도에 맞추세요. 간단하지만 의외로 자주 간과되는 부분입니다. 라우팅 규칙을 구성하고 모델을 직접 평가할 수도 있고, 모델 선택을 대신 처리해 주는 오케스트레이션 플랫폼을 사용할 수도 있습니다.

예를 들어 Perplexity Computer의 Effort Mode를 사용하면 모델을 직접 선택하지 않고도 작업에 들일 노력의 정도를 정할 수 있습니다. Light, Standard, High, Ultra 중 하나를 고르면 Perplexity가 오케스트레이션 모델과 그 추론 수준을 자동으로 선택합니다. 그러면 해당 오케스트레이터가 하위 작업을 보조 에이전트에게 위임하며, 이 에이전트들은 여러 제공업체의 모델을 사용할 수 있습니다.

Perplexity는 품질과 비용 측면에서 모델 구성을 평가하며, 비슷한 결과를 내는 더 저렴한 옵션을 우선합니다. 모델과 추론 수준을 직접 선택하고 싶다면 Custom 컨트롤을 사용할 수도 있습니다.

병렬 처리의 경우, 한도는 인프라와 외부 의존성을 기준으로 정해야 합니다. 공유 API의 요청 및 토큰 속도 제한을 확인한 다음, 동시성을 높여 가며 워크플로우에 대한 부하 테스트를 수행하세요. 처리량이 개선되는지, 아니면 요청이 대기열에 쌓이거나 느려지거나 429 오류를 반환하기 시작하는지 지켜보세요.

리소스 사용량을 예측 가능하게 유지하려면 리소스 제한과 스케줄링 제어를 적용하세요:

동시성과 요청 속도 제어: 서비스별로 진행 중인 호출 수에 상한을 두고 초과 작업은 대기열에 넣으세요. 동시성 상한만으로는 분당 요청 수나 분당 토큰 수 제한이 적용되지 않는다는 점을 기억하세요.
토큰 및 비용 예산 추적: 하위 에이전트를 포함해 전체 워크플로우의 사용량을 집계하고, 남은 예산이 부족하면 새 작업 시작을 중단하세요.
실행 기한 적용: 작업 및 워크플로우 시간 제한을 설정하고, 지원되는 경우 실행 중인 에이전트에 취소를 전파하세요.
의존성 준수: 모든 에이전트를 동시에 시작하는 대신, 필요한 입력이 준비되었을 때만 다운스트림 작업을 시작하세요.

자신의 작업이 안전한지 모델에게 판단하게 하지 마세요. 대신 에이전트에게 최소 권한을 부여하고, 위험 기반 승인 규칙을 애플리케이션 코드에서 강제하세요. 에이전트가 코드를 실행한다면 그 실행을 호스트 환경과 격리하고 파일, 네트워크, 자격 증명에 대한 접근을 제한하세요. 이렇게 하면 에이전트가 실수하거나 안전하지 않은 코드를 실행하더라도 피해 범위를 제한할 수 있습니다.

“저는 지나치게 복잡한 멀티 에이전트 시스템에 회의적입니다. 특히 에이전트들이 서로의 작업을 리뷰하고 승인하는 경우가 그렇습니다. 여러 에이전트가 같은 실수를 자신 있게 넘겨주기만 하고, 정작 아무도 그 실수를 잡아내지 못하는 상황이 생길 수 있습니다.” Spilker는 이렇게 경고합니다.

승인 흐름 다이어그램: 에이전트가 매개변수, 대상 리소스, 상태 버전과 함께 작업을 제안하고, 사람이 이를 승인하거나 거부합니다. 승인된 작업은 다시 검증된 후 파일, 네트워크, 자격 증명 접근이 제한된 격리 환경에서 실행됩니다. 거부되거나 만료된 요청은 종료되며, 변경된 요청은 새로 승인을 받아야 합니다.

사람의 승인이 필요한 작업의 경우, 실행을 일시 중지하고 제안된 작업을 정확히 그대로 저장하세요:

작업의 매개변수
작업의 대상 리소스
작업의 커밋 또는 상태 버전
검토자의 결정

또한 승인이 거부되거나, 만료되거나, 에스컬레이션이 필요한 경우 어떻게 할지 정의하세요. 이는 재개 가능한 프레임워크에서 필수적입니다. 중단된 노드를 재개하면 해당 노드의 처음부터 코드가 다시 실행되기 때문입니다. 중단 전에 실행된 부수 효과가 다시 발생할 수 있습니다.

따라서 승인이 거부되거나 만료되면 요청은 종료됩니다. 실행 전에 대상 커밋, 매개변수 또는 권한이 변경되면 기존 승인을 무효화하고 새 승인을 요청하세요.

Spilker는 완전 자율형 엔드투엔드 에이전트를 목표로 삼는 생각에도 동의하지 않습니다. “제가 보기에 더 나은 접근 방식은 명확한 책임, 정의된 권한, 적절한 지점의 사람 검토를 갖춘 소수의 특화된 에이전트를 구축하는 것입니다. 그러면 완전한 통제권을 포기하지 않고도 효율성을 얻을 수 있습니다.” 그는 이렇게 결론짓습니다.

에이전트가 실제로는 실패했는데 Success라고 보고한 적이 있나요? 짜증스럽다 못해 화가 날 수도 있는 일이며, 에이전트의 최종 메시지가 어디서 문제가 생겼는지 반드시 알려 주지는 않기 때문에 빠르게 해결하기도 어렵습니다.

원인을 조사하려면 실행 중에 무슨 일이 있었는지 추적하고 결과를 독립적으로 검증하세요. 그럼 시간을 들여 문제를 격리하고 해결해 보겠습니다.

에이전트의 프롬프트를 디버깅하기 전에 전체 실행 경로를 캡처하세요. 같은 워크플로우 실행 아래에서 에이전트 호출, 도구 호출, 오류, 재시도를 연결하는 트레이스가 필요합니다.

OpenTelemetry의 GenAI 시맨틱 규칙은 이러한 작업을 표준화된 방식으로 기술할 수 있게 해 줍니다. 예를 들어 invoke_workflow는 워크플로우 실행을, invoke_agent는 에이전트 호출을, execute_tool는 도구 호출을 나타냅니다. 각 작업은 타이밍, 상태, 관련 메타데이터와 함께 span으로 기록할 수 있습니다.

이 단계를 거치면 실행 경로의 트레이스를 확보할 수 있으므로, 에이전트가 어디에서 문제를 겪었는지 파악할 수 있습니다.

plaintext

invoke_agent  generate_patch   OK
execute_tool  start_ci_run     OK  run_id=9812
execute_tool  get_ci_result    TIMEOUT

agent_response: "Success"

실행 트레이스 예시.

가능하면 프로그래밍 방식의 검사를 사용하세요. JSON 스키마에 따라 출력을 검증하고, 단위 테스트와 통합 테스트를 실행하고, 필요한 아티팩트가 존재하는지 확인하고, 외부 시스템을 조회해 작업이 실제로 성공했는지 확인하세요.

주관적인 판단이 필요해 프로그래밍 방식의 검사로 평가할 수 없는 출력에는 독립적인 리뷰어 에이전트를 도입하세요. 한 가지 방법은 구현자–리뷰어–해결자 루프입니다. 한 에이전트가 아티팩트를 생성하면 새로운 컨텍스트의 리뷰어가 문제를 찾아내고, 해결자가 이를 처리한 뒤 검증을 다시 실행합니다.

가능하면 리뷰어의 발견 사항도 검증해야 하며, 반복 평가에 LLM 기반 채점기를 사용한다면 사람이 검토한 예시를 기준으로 채점기의 판단을 보정하세요.

지금까지 에이전트가 실행한 작업을 추적하고 그 출력이 올바른지 확인했습니다. 하지만 워커가 작업 도중 크래시되거나 API가 요청을 수락한 뒤 타임아웃되면 어떻게 될까요? 놀랍게도 워크플로우는 정상적인 조건에서는 완벽하게 동작하더라도 복구 과정에서는 실패할 수 있습니다.

이를 테스트하려면 테스트 환경에서 의도적으로 장애를 주입해 보세요:

API 타임아웃 시뮬레이션하기
외부 쓰기와 체크포인트 사이에서 워커를 크래시시키기
잘못된 형식의 도구 출력 반환하기
승인 만료시키기

각 테스트가 끝나면 실행 트레이스를 검사하여 어떤 단계가 실행되었는지, 워크플로우가 어디서 재개되었는지, 반복되거나 건너뛴 작업이 있는지 확인하세요. 그런 다음 실제 결과를 검토하세요.

CI 에이전트가 테스트 실행을 시작하라는 요청을 보냈는데 API 응답이 타임아웃되었다고 가정해 보겠습니다. 에이전트는 재시도하여 성공 응답을 받고 Success를 보고합니다. 모든 것이 정상으로 보이지만, CI 서비스를 확인해 보면 테스트 실행이 하나가 아니라 두 개 생성되었다는 사실을 발견하게 됩니다.

그렇기 때문에 워크플로우에 기록된 상태와 외부 시스템의 실제 변경 사항을 모두 검증해야 합니다. 복구 테스트는 워크플로우가 의도하지 않은 부작용 없이 예상된 상태에 도달했을 때만 통과해야 합니다.

발견한 실패 사례를 회귀 테스트에 추가하여 향후 변경으로 인해 같은 문제가 다시 발생하지 않도록 하세요.

결국 성공이란 워크플로우가 필수 검사를 통과하고 외부 결과까지 검증되었음을 의미합니다.

사일로화된 에이전트는 각자의 작업은 올바르게 완료하더라도 함께 놓고 보면 일관되지 않은 결과를 낼 수 있습니다. 영업 에이전트가 10시에 고객 계약 조건을 조회하고, 가격 책정 에이전트가 10시 5분에 업데이트된 가격으로 견적을 계산하며, 법무 에이전트가 10시 7분에 변경된 계약서를 검토한다고 상상해 보세요. 각 에이전트가 서로 다른 시점의 비즈니스 스냅샷을 기반으로 작업하므로 출력이 서로 모순될 수 있습니다.

엔터프라이즈 규모에서는 이 문제가 더욱 두드러집니다. 에이전트가 각각 독립적으로 업데이트되는 여러 시스템과 상호작용하고, 서로 다른 권한으로 작동하며, 컨텍스트나 실행 상태를 반드시 공유하지는 않기 때문입니다.

최대 도구 호출 재시도 횟수, 최대 에이전트 반복 횟수, 위임 깊이, 전체 워크플로우 마감 시한 등 여러 수준에서 제한을 설정하세요. 재시도하기 전에 실패 유형을 분류하세요. 일시적인 429 응답의 경우 Retry-After가 제공되면 이를 따르세요. 그렇지 않으면 지터를 적용한 제한된 지수 백오프를 사용하세요.

유효성 검사 오류나 권한 오류가 발생한 후에는 변경하지 않은 요청을 다시 시도하지 마세요. 다운스트림 서비스가 반복적으로 실패하는 경우 서킷 브레이커를 사용하면 에이전트가 추가 부하를 발생시키는 것을 막을 수 있습니다.

복구 메커니즘은 사용하는 런타임에 따라 다릅니다. LangGraph에서는 PostgresSaver와 같은 영구 체크포인터가 그래프 상태를 thread_id 단위로 저장하므로 저장된 상태에서 실행을 이어갈 수 있습니다. Temporal에서는 다른 워커가 이벤트 기록을 재생하여 워크플로우를 재구성할 수 있습니다. 재생 중에는 이전에 기록된 액티비티 결과를 재사용합니다.

워크플로우가 아직 실행 중인 상태에서 애플리케이션을 재배포하면 저장된 상태와 실행 기록이 더 이상 호환되지 않을 수 있습니다. Temporal은 Worker Versioning과 워크플로우 패칭으로 이 문제를 해결합니다. 체크포인트 기반 시스템의 경우 호환되지 않는 변경 사항을 배포하기 전에 스키마 마이그레이션을 계획하고, 기존에 저장된 상태를 대상으로 복구를 테스트하세요.

동일한 대표 작업을 여러 번 실행하고 pass@k(k번의 시도 중 최소 한 번 성공하는지)와 pass^k(k번의 시도가 모두 성공하는지)를 구분하세요

하나의 종합 성공률에 의존하기보다는 작업 범주와 워크플로우 버전별로 결과를 측정하세요. 첫 시도 성공률, 반복 실행 간 일관성, p95 지연 시간, 완료된 작업당 비용, 사람의 개입이 필요한 비율을 추적하세요. 성공률에 대해서는 표본 크기와 불확실성 구간을 함께 보고하세요.

AI 에이전트 오케스트레이션이란?

AI 에이전트 오케스트레이션의 작동 방식: 실행 엔진 내부 살펴보기

AI 에이전트 오케스트레이션은 언제 사용해야 할까요?

AI 에이전트 오케스트레이션 아키텍처와 각각의 장단점

중앙 집중식 오케스트레이션

분산식 오케스트레이션

계층식 오케스트레이션

순차, 병렬, 핸드오프 기반 실행

흔히 발생하는 AI 에이전트 오케스트레이션 실패

프로덕션 안정성을 위한 AI 에이전트 오케스트레이션 모범 사례 7가지

1. 명시적인 작업 계약, 수락 기준, 중지 조건 정의하기

2. 오케스트레이터를 가볍게 유지하고 구조화된 핸드오프 적용하기

3. 워크플로우 상태를 영구 저장하고 컨텍스트 증가 제어하기

4. 실패를 고려한 재시도와 복구 가능한 도구 실행 설계하기

5. 명시적인 리소스 예산으로 작업을 라우팅하고 병렬화하기

6. 승인을 강제하고 에이전트 실행 격리하기

7. 출력을 독립적으로 검증하고 복구 동작 테스트하기

워크플로우를 추적해 문제 원인 파악하기

출력을 독립적으로 검토하기

장애를 주입해 복구 테스트하기

AI 에이전트 오케스트레이션 FAQ

사일로화된 AI 에이전트는 왜 엔터프라이즈 규모에서 제대로 작동하지 않을까요?

AI 에이전트의 무한 재시도 루프는 어떻게 방지하나요?

크래시 후 AI 에이전트 워크플로우는 어떻게 재개하나요?

AI 에이전트 오케스트레이션의 신뢰성은 어떻게 테스트하나요?