LangGraph와 LlamaIndex Workflows가 현재 많은 화제를 모으고 있으며, 저희는 이를 단순히 코드를 직접 작성하는 방식과 비교했을 때 실제 성능이 어떠한지 확인해 보고 싶었습니다. 이를 위해 저희가 프레임워크 없이 코드로 직접 구축하고 배포했던 직관적인 에이전트 아키텍처(agent architecture)를 가져와, 이를 LangGraph와 Workflows를 사용하여 구현해 보았습니다. 저희의 주요 목표는 이러한 프레임워크들이 단순한 에이전트 설계를 자신들의 추상화(abstractions)로 어떻게 변환하는지 탐구하고, 개발 및 디버깅(debugging) 과정에 미치는 영향을 평가하는 것이었습니다.

저희는 이러한 프레임워크들이 마찰을 일으키는 지점과 빛을 발하는 지점에 대해 실질적인 예시와 솔직한 관찰을 제공함으로써, 커뮤니티와 발견한 내용을 공유하고자 합니다. 현재 많은 과장된 홍보(hype)가 존재하며, 저희는 실제 코드 예시와 편향되지 않은 관점을 통해 명확성을 제공하기를 희망합니다.

맥락을 설명하자면, 저희는 약 8개월 동안 자체적인 Co-pilot 에이전트/어시스턴트(agent/assistant)를 프로덕션(production) 환경에서 운영해 왔습니다. 또한 고객들이 대규모로 어시스턴트를 트러블슈팅(troubleshoot)하는 것을 도왔기 때문에, 광범위한 유스케이스(use cases)와 과제들을 목격해 왔습니다.

저희가 테스트한 아키텍처는 단일 계층 LLM 라우터(single-tier LLM router)로, 다양한 고객 구현 사례에서 자주 볼 수 있는 패턴입니다. 이는 함수 호출(function calling)을 사용하여 작업이나 기술을 라우팅하는 단일 LLM 라우터를 포함하며, 라우터로 제어권을 반환하기 전에 또 다른 LLM 호출이 포함될 수 있습니다. 이는 단순하지만 다재다능한 패턴입니다.

이 프로젝트에 대해 저희가 작성한 Towards Data Science 글은 다음과 같습니다: https://towardsdatascience.com/choosing-between-llm-agent-frameworks-69019493b259

전체 코드: https://github.com/Arize-ai/phoenix/tree/main/examples/agent_framework_comparison

핵심 의견 #1: 숙련된 개발자에게 프레임워크의 추상화는 불필요한 복잡성을 더할 수 있습니다.
핵심 의견 #2: 내장된 병렬성(parallelism)은 유망해 보이지만, 디버깅을 매우 복잡하게 만들 수 있습니다.
핵심 의견 #3: 스캐폴딩(scaffolding)이 없는 경험이 적은 개발 팀이 있는 환경에서는, 이러한 프레임워크가 유용한 구조를 제공할 수 있습니다. 적어도 POC(Proof of Concept) 단계에서는 말입니다.

현재 CrewAI 및 Autogen을 사용하여 이 과정을 반복하고 있으며, 관련 학습 내용은 곧 공유할 예정입니다.

그리고 이 중 어떤 것이든 로그를 심층 분석(Deep dive)하고 싶다면, Arize Phoenix로 캡처된 트레이스(Traces)를 이곳에 게시해 두었습니다.
Pure code: https://phoenix-demo.arize.com/projects/UHJvamVjdDo2
LangGraph: https://phoenix-demo.arize.com/projects/UHJvamVjdDoy
LlamaIndex Workflows: https://phoenix-demo.arize.com/projects/UHJvamVjdDo1

다른 분들은 어떻게 생각하시는지 궁금합니다. 이러한 프레임워크를 사용해 본 경험은 어떠셨나요? 그리고 직접 에이전트 솔루션을 구축하는 것과 비교했을 때 어떤 차이가 있었나요?