에이전트형 시스템에서 의사결정이 어떤 방식으로 어디에서 이루어지는지 신중하게 고려해야 합니다.
더 많은 결정을 LLM에 맡기면 시스템이 더 다양한 작업에 일반화될 수 있지만, 속도와 신뢰성, 견고성이 떨어질 수 있습니다.
가능한 한 많은 의사결정 과정을 LLM에서 분리해 명시적인 소프트웨어 코드로 구현하세요. 특히 위험도가 높거나 프로덕션 환경에서 실행되는 워크플로에서는 더욱 그렇습니다.
LLM 기반 에이전트형 시스템을 설계할 때 가장 중요한 선택 중 하나는 의사결정을 어느 정도까지 LLM 모델에 맡기고 어느 정도를 명시적인 소프트웨어로 구현할지 정하는 것입니다.
이 선택은 다음 두 접근 방식을 양 끝으로 하는 스펙트럼으로 이해할 수 있습니다.
라우터 기반 아키텍처는 코드로 순서와 로직을 명시하여 범위가 좁은 작업에서 테스트 가능성과 예측 가능성, 견고성을 보장합니다. ‘워크플로 에이전트’라고도 합니다.
오케스트레이터 에이전트는 대규모 언어 모델(LLM)이 자연어 프롬프트를 바탕으로 작업 흐름을 동적으로 결정합니다. 미리 정의된 로직만으로는 처리하기 어렵거나 불가능한 개방형 상호작용에 적합합니다.
위험도가 높은 프로덕션 워크플로에는 일반적으로 라우터 기반 기능을 더 많이 사용하고, 유연한 범용 대화가 필요한 애플리케이션에 오케스트레이터를 활용하는 것이 좋습니다.
라우터 기반 아키텍처
라우터형 에이전트 시스템의 특징:
의사결정 흐름을 코드나 소프트웨어로 명시하고, LLM을 사용해 소프트웨어가 따를 경로를 결정합니다.
일관된 결과로 이어지는 명확하고 예측 가능한 경로를 갖춘다는 점에서 기존 소프트웨어 시스템에 더 가깝습니다.
엄격하게 정의할 수 있는 작업에 적합합니다.
다음은 ‘라우터 접근 방식’을 사용하는 항공사 챗봇 예약 에이전트의 간단한 예입니다. LLM은 세 가지 선택지 중에서 질문의 의도를 분류하지만, 최종적으로는 소프트웨어가 이 의도를 템플릿 응답에 연결합니다. LLM에 강한 제약이 적용되므로 사용자는 더 일관된 동작을 경험하게 됩니다.
오케스트레이터 아키텍처
라우터 시스템과 달리 오케스트레이터형 에이전트 시스템은 다음과 같이 작동합니다.
소프트웨어 대신 자연어 프롬프트로 로직의 흐름을 정의합니다. 참고: 프로그래밍 언어와 비교하면 자연어는 본질적으로 모호하고 유연합니다. 이는 장점이자 단점이며 뒤에서 자세히 살펴보겠습니다. 이를 ‘지시가 아닌 의도’라고 생각할 수 있습니다.
여러 처리 옵션을 제공하고 LLM이 실행 순서와 방식을 결정하도록 할 수 있습니다.
소프트웨어로 명시하기 어려운 새로운 로직 경로를 동적으로 만들 수 있습니다.
이러한 모호성으로 인해 결과가 일관되지 않을 수 있지만, 제대로 작동하면 ‘마법’처럼 느껴질 수 있습니다.
다음 예에서는 동일한 간단한 항공사 문제에 오케스트레이터 접근 방식을 적용합니다. 어떤 응답이 적절한지 소프트웨어가 결정하는 대신 LLM 계층에 의사결정을 위임합니다. 이 다중 에이전트 시스템에서는 ‘총괄’ 오케스트레이터 에이전트가 사용자 질의를 분류하고 항공편 변경 전용 에이전트에 넘기며, 해당 에이전트가 최종적으로 사용자에게 응답합니다.
이 예에서 LLM 계층은 분류기와 라우터, 응답 작성자의 역할을 모두 수행합니다. 라우터 예에서는 LLM이 분류기 역할만 수행하고 나머지는 소프트웨어가 처리했습니다.
가능한 경우 다음과 같은 장점이 있는 라우터 기반 접근 방식을 권장합니다.
속도와 효율성: 로컬 연산은 외부 API에 의존하는 오케스트레이터보다 훨씬 빠릅니다. 또한 ‘IF/ELSE’ 로직은 LLM 제공업체의 4,000억 개 매개변수 모델로 보내 처리하는 것보다 Python에서 실행하는 편이 훨씬 저렴합니다.
테스트 가능성과 예측 가능성: 확립된 소프트웨어 관행을 활용하면 디버깅과 테스트, 유지 관리가 훨씬 쉽습니다.
투명성과 신뢰성: 동작의 편차가 적어 문제 해결이 간단합니다. 또한 애플리케이션 흐름 중 더 많은 부분이 불투명하고 해석하기 어려운 LLM 가중치가 아니라 투명하고 버전 관리되는 소프트웨어로 표현됩니다.
라우터 접근 방식은 경직되고 유연성이 떨어질 수 있으며, 개방형 문제를 처리하기 어렵다는 단점이 있습니다. 항상 똑같은 답변만 내놓는 챗봇은 사용자에게 지루하거나 정체된 것처럼 보일 수 있습니다.
오케스트레이터 설계는 다음과 같은 강력한 기능을 제공합니다.
계획: 응답을 동적으로 계획할 수 있습니다.
도구 선택/에이전트 인계: 적절한 도구를 선택하거나 에이전트에 작업을 위임합니다.
반복적인 결과 조합: 결과를 반복해서 검토하고 창의적으로 재조합합니다.
완료 여부 판단: 응답을 완성하는 데 충분한 정보가 수집되었는지 판단합니다.
Pydantic-AI나 OpenAI의 Agents SDK 같은 프레임워크를 사용하면 오케스트레이션을 쉽고 빠르게 구현할 수 있습니다. 따라서 데모나 개념 증명에 매우 적합합니다.
이 접근 방식에는 다음과 같은 단점이 있습니다.
LLM의 계획 단계와 후속 작업이 정확하거나 적절하다고 보장할 수 없습니다. 라우터 시스템에도 같은 문제가 있지만 제약이 더 많기 때문에 동작을 더 쉽게 예측할 수 있습니다.
단순하고 명확하게 정의된 작업에는 다중 에이전트 시스템의 모든 기능이 필요하지 않을 가능성이 큽니다. 예를 들어 앞서 살펴본 항공사 에이전트의 경우, 사용자가 항공사 고객 지원 시스템에서 실제로 처리하려는 문의 유형은 제한적일 가능성이 큽니다.
더 많은 로직이 LLM에 포함되므로 악의적 행위자의 탈옥이나 악용에 훨씬 더 취약합니다.
의사결정을 LLM 내부로 추상화하므로 시스템을 이해하기가 더 어려워집니다. 다만 Langfuse나 Braintrust 같은 모니터링 도구가 일부 도움이 될 수 있습니다.
독자 참고 사항: 모델의 성능은 빠르게 발전하고 있지만 아래 내용은 가까운 시일 내에 달라지지 않을 가능성이 큽니다.
문제의 범위를 정하세요.
원하는 의사결정 로직을 다이어그램으로 쉽게 정의할 수 있나요?
애플리케이션의 실패나 예기치 않은 동작을 허용하기 어려운가요?
둘 중 하나라도 ‘예’라면 라우터 기능이 더 적합합니다.
가능한 범위에서는 라우터 접근 방식을 사용하는 것이 좋습니다. 일반적으로 시스템의 일부를 코드로 표현할 수 있다면 코드로 구현하세요. 즉, 필요하지 않은 곳에 LLM을 남용하지 마세요.
라우터 접근 방식이 한계에 이르면 오케스트레이터가 지닌 개방형 처리의 장점 일부를 제한된 방식으로 구현할 수 있습니다. 예를 들면 다음과 같습니다.
도구 선택/에이전트 인계: 조건부 분기나 LLM 분류기로 쉽게 구현할 수 있습니다.
완료 여부 판단: 간단한 LLM 분류기를 사용해 사용자에게 응답을 반환하기 전에 완성도를 확인할 수 있습니다.
하지만 경직된 라우터 시스템에서 ‘계획’과 ‘반복적인 결과 조합’을 구현하기는 확실히 훨씬 어렵습니다. 따라서 작업에 이러한 기능이 필요하다고 LLM 분류기나 다른 로직이 판단하면 시스템에 제약이 더 적은 오케스트레이터 분기를 만드는 것이 좋습니다.
라우터와 오케스트레이터 아키텍처 중 무엇을 선택할지는 애플리케이션의 명확성과 복잡성, 상호작용 방식에 따라 결정해야 합니다. 현재 라우터 기반 접근 방식은 명확하게 정의된 작업에 신뢰성과 효율성, 테스트 용이성을 제공합니다. 오케스트레이터는 더 광범위한 대화형 상호작용에 더 뛰어난 유연성을 제공합니다.
LLM이 계속 발전함에 따라 두 접근 방식 간의 균형도 달라질 수 있습니다. 프로덕션 워크로드에는 라우터 기반 또는 하이브리드 아키텍처를 선호하며, 역동적이고 사람과 같은 상호작용이 필요한 개방형 문제에는 오케스트레이터를 활용하는 편이 좋습니다.