에이전트 시스템에서 결정론적 워크플로가 AI 기반 오케스트레이션보다 뛰어난 이유

AI 기반 오케스트레이션: 유혹과 현실

어떤 에이전트를 호출할지, 어떤 순서로 실행할지, 실패를 어떻게 처리할지 결정하는 "메타 에이전트" 개념은 유연성과 최소한의 하드코딩으로 매력적입니다. 그러나 여러 번의 시도 끝에 이 접근 방식은 실제로 신뢰성 있게 작동하지 않았습니다.

AI 오케스트레이션의 문제점

• 비결정적 라우팅: 오케스트레이터 에이전트가 동일한 입력으로 매번 다르게 결정하여 다른 실행 경로를 만듭니다. 때로는 단계를 건너뛰거나 불필요한 단계를 추가하여 디버깅을 어렵게 합니다.
• 오류 누적: 오케스트레이터의 잘못된 라우팅 결정이 모든 하류 에이전트로 전파되어 파이프라인 전체에 실수를 물려줍니다.
• 비용 폭발: 오케스트레이터가 작업 전에 무엇을 할지 결정하는 데 토큰을 소비합니다. 파이프라인에 6개의 에이전트가 있으면 최소 7개의 LLM 호출 비용을 지불하며, 오케스트레이터 호출은 전체 컨텍스트가 필요하기 때문에 종종 가장 비쌉니다.
• 디버깅 불가능: 무언가 고장 나면 이유를 추적할 수 없습니다. 오케스트레이터의 라우팅 로직, 하류 에이전트의 실행, 오케스트레이터 프롬프트의 컨텍스트 드리프트 중 무엇 때문인지 알 수 없어 AI로 AI를 디버깅하게 됩니다.

해결책: 결정적 오케스트레이션

해결책은 워크플로우 엔진을 AI가 아닌 코드로 만드는 것이었습니다. AI는 자신이 잘하는 일(콘텐츠 생성, 분석, 추론)을 하고, 코드는 자신이 잘하는 일(순서화, 라우팅, 오류 처리, 재시도)을 합니다.

네 가지 결정적 워크플로우 패턴

• 시퀀스 패턴: 에이전트 A 실행, 출력을 에이전트 B로 전달, 그다음 에이전트 C로 전달. 결정 없이 파이프라인만 존재합니다.
• 라우터 패턴: 규칙 기반 라우터(AI 아님)가 입력을 검사하고 적절한 전문 에이전트로 전달합니다. 결정적이고 디버깅 가능하며 빠릅니다.
• 플래너→실행자: 하나의 AI 에이전트가 계획을 생성합니다. 결정적 엔진이 각 단계를 실행합니다. AI는 계획하고 코드는 오케스트레이션합니다.
• 병렬 패턴: 여러 에이전트가 서로 다른 측면에서 동시에 실행됩니다. 결정적 병합 단계가 결과를 결합합니다.

실제 예시: 콘텐츠 파이프라인

3단계로 구성된 콘텐츠 파이프라인: 리서치 에이전트가 정보 수집, 라이팅 에이전트가 리서치 출력을 사용하여 글 초안 작성, 리뷰 에이전트가 정확성과 스타일 확인.

이전 접근 방식(AI 오케스트레이터): 약 40%의 실행에 문제가 있었습니다. 오케스트레이터가 때로는 리서치를 건너뛰고, 때로는 라이팅 전에 리뷰를 실행하고, 때로는 무한 루프에 빠졌습니다.

새 접근 방식(결정적 시퀀스): 3개월 동안 오케스트레이션 실패 0%. 모든 실행이 동일한 경로를 따릅니다. 무언가 실패하면 정확히 어떤 에이전트가 실패했고 왜 실패했는지 알 수 있습니다.

핵심 원칙

에이전트 파이프라인을 구축한다면 워크플로우 엔진을 "똑똑하게" 만들고 싶은 유혹을 거부하세요. 예측 가능하게 만드세요. 디버깅 가능하게 만드세요. 에이전트가 똑똑하게 하고, 인프라는 지루하게 하세요. 모든 신뢰성 향상은 더 많은 지능이 아닌 더 많은 구조를 추가함으로써 이루어집니다. 오케스트레이션 계층에 AI가 적을수록 에이전트는 더 신뢰할 수 있게 됩니다.