AI Agent 시대의 시작
LangGraph나 LlamaIndex Workflows
2023년은 '검색 증강 생성(RAG) '이라는 개념이 크게 주목받은 해였습니다. 이것은 AI가 단순히 정보를 검색하는 것을 넘어, 검색한 내용을 바탕으로 새로운 것을 만들어내는 능력을 가진 도구들이 많이 등장했음을 의미합니다. 그러나 2024년이 되면서, '에이전트(Agent)'라는 개념이 더 주목받고 있습니다.
에이전트란 사람 대신 일을 처리해주는 AI 프로그램을 의미합니다. 요즘 많은 기업들이 챗봇 같은 AI 에이전트를 실험하고 있습니다. 예를 들어, LangGraph나 LlamaIndex Workflows 같은 프레임워크은 개발자들이 이런 에이전트를 쉽게 만들 수 있도록 도와줍니다.
그럼에도 불구하고, 에이전트가 AI 연구자들 사이에서는 인기가 많지만, 일반 소비자들이나 기업들 사이에서는 아직 큰 성공을 거두지 못하고 있습니다. 쉽게 말해, 사람들은 아직 이 에이전트를 일상에서 많이 사용하지 않는다는 뜻입니다.
그래서 기업의 팀이나 개발자들은 새로운 에이전트 관련 프레임워크나 방향성을 어떻게 탐색하고, 어떤 도구를 사용해야 할지 고민이 됩니다. 어떤 도구가 다음에 만들 제품에 적합할지 선택하는 것이 중요한 과제가 되었습니다.
에이전트 정의
에이전트는 기본적으로 AI 모델(LLM: 대규모 언어 모델)을 이용해 여러 작업을 수행하도록 설계된 소프트웨어 시스템입니다. 이 시스템은 원하는 결과를 얻기 위해 여러 단계로 작업을 나누고, 각 단계에서 LLM을 호출하여 필요한 작업을 처리합니다. 에이전트는 작업을 수행하는 동안 의사 결정을 내리거나, 필요한 정보를 기억하는 기능을 가지고 있습니다.
이제 현재 에이전트가 어떻게 발전하고 있는 지 살펴보겠습니다.
ReAct 에이전트의 실패
사실, 에이전트라는 개념 자체는 새로운 것이 아닙니다. 작년에 AI 트위터에서는 수많은 에이전트가 등장했는데, 이들은 굉장히 똑똑해 보였고, 다양한 작업을 할 수 있을 것처럼 보였습니다. 이 1세대의 에이전트들은 "ReAct(Reason, Act)"라고 불렸습니다. 즉, 먼저 상황을 분석(Reason)하고, 그다음에 행동(Act)을 취하는 구조로 만들어졌습니다. 이 에이전트들은 매우 추상적으로 설계되어 있었고, 다양한 작업을 처리할 수 있을 것처럼 보였습니다.
하지만 이 1세대의 에이전트들은 실제로는 많은 어려움을 겪었습니다. 너무 추상적으로 만들어진 탓에 사용하기가 어려웠고, 처음에는 굉장한 능력을 보여줄 것 같았지만, 실제로는 원하는 결과를 거의 얻지 못했습니다.
이런 실패의 경험을 바탕으로, 많은 사람들은 "에이전트가 어떻게 구성되어야 하는가?"에 대해 다시 생각하게 되었습니다. 그 결과, 2세대 에이전트가 나오게 되었습니다.
2세대 에이전트란 무엇인가?
2세대 에이전트는 이전 세대인 ReAct 에이전트와 비교하여 더 엄격하고 구체적인 방식으로 설계되었습니다. 이 에이전트들은 수행할 수 있는 작업과 행동 경로가 명확하게 정의되어 있어, 보다 안정적이고 효율적인 성능을 보여줍니다.
특징은 다음과 같습니다.
1. 더 엄격한 구조와 정의
제한된 작업 범위: 2세대 에이전트는 수행할 수 있는 작업의 범위가 명확하게 한정되어 있습니다. 즉, 에이전트가 어떤 상황에서 어떤 행동을 해야 하는지가 구체적으로 정해져 있습니다.
명확한 경로 설정: 에이전트가 목표를 달성하기 위해 따라야 하는 단계와 절차가 구체적으로 설계되어 있습니다. 이는 에이전트가 불필요한 과정을 거치지 않고 효율적으로 작업을 수행하도록 도와줍니다.
2. 더 작은 작업 공간
더 작은 작업 공간이란? 여기서 공간은 에이전트가 문제를 해결하기 위해 시도할 수 있는 모든 가능한 방법과 경로를 의미합니다.
효율성 증가: 공간이 작아지면, 에이전트가 선택할 수 있는 옵션이 줄어들어 결정 과정이 빨라지고 오류가 줄어듭니다.
강력한 성능: 제한된 범위 내에서 최적화된 행동을 수행하기 때문에, 에이전트의 성능과 신뢰성이 높아집니다.
3. LLM 라우터 단계의 활용
LLM(Large Language Model) 라우터란?: 이는 에이전트가 작업을 수행하는 과정에서 대규모 언어 모델을 활용하여 다음에 어떤 행동을 취할지 결정하는 단계입니다.
의사 결정 지원: LLM은 방대한 데이터와 학습을 바탕으로 최적의 행동을 추천하거나 예측하여 에이전트의 의사 결정을 돕습니다.
정확도 향상: LLM의 도움으로 에이전트는 보다 정확하고 적절한 반응을 생성할 수 있습니다.
4. 반복 루프를 통한 데이터 처리
반복 루프(iterative loop)란?: 에이전트가 특정 작업을 완료할 때까지 같은 과정을 반복적으로 수행하는 구조를 말합니다.
단계적 개선: 반복 과정을 통해 에이전트는 각 단계에서 결과를 확인하고 필요에 따라 수정하여 점진적으로 목표에 근접합니다.
복잡한 작업 처리: 이러한 구조는 복잡한 문제를 작은 단계로 나누어 효과적으로 해결하는 데 유용합니다.
이를 통해 2세대 에이전트는 실제 응용 분야에서 더 유용하고 효과적인 결과를 제공할 수 있게 됩니다.
에이전트의 구성 요소
에이전트의 구성 요소에 대해서 설명해 보겠습니다.
에이전트는 보통 라우터라는 핵심 요소를 가지고 있습니다. 라우터는 에이전트가 작업을 진행하면서 다음에 어떤 단계를 취할지 결정하는 역할을 합니다. 쉽게 말해, 라우터는 에이전트가 계속해서 다음 단계로 나아갈 수 있도록 길을 안내해주는 네비게이션과 같습니다.
에이전트가 취할 수 있는 각 행동은 컴포넌트로 표현됩니다. 컴포넌트는 특정한 작은 작업을 수행하는 코드 블록이라고 생각하면 됩니다. 예를 들어, LLM을 호출하거나, 여러 번의 LLM 호출을 조정하거나, 내부 API를 호출하거나, 특정 애플리케이션 코드를 실행하는 작업이 컴포넌트가 됩니다.
이 컴포넌트들은 각기 다른 프레임워크에서 다른 이름으로 불리기도 합니다. 예를 들어, LangGraph에서는 이들을 노드라고 부르고, LlamaIndex Workflows에서는 단계라고 합니다.
에이전트가 복잡해질수록, 이러한 컴포넌트들을 기능 또는 기술 단위로 그룹화하는 것이 유용합니다.
예를 들어, 고객의 주문 배송 상태를 확인하는 에이전트를 생각해보겠습니다.
1) 사용자가 입력한 질문에서 주문 ID를 추출하고,
2) 주문 ID를 사용해 백엔드 시스템에 API를 호출하고,
3) API의 응답을 받아와서 분석한 뒤
4) 사용자에게 적절한 답변을 제공합니다.
이러한 각 단계가 하나의 컴포넌트가 될 수 있으며, 이 모든 단계를 "배송상태확인"이라는 그룹으로 묶을 수 있습니다.
마지막으로, 많은 에이전트는 작업을 수행하면서 공유 상태나 메모리를 추적합니다. 이는 에이전트가 다양한 컴포넌트들 사이에서 필요한 정보를 쉽게 전달할 수 있도록 도와줍니다. 예를 들어, 에이전트가 처음에 주문 ID를 추출한 정보를 나중 단계에서도 계속 활용할 수 있도록 메모리에 저장해둡니다. 이렇게 하면 여러 단계에 걸쳐 필요한 데이터를 쉽게 관리할 수 있습니다.
이런 구조 덕분에 에이전트는 복잡한 작업을 체계적으로 처리할 수 있게 됩니다.
에이전트 아키텍처 프레임워크
LangGraph
LangGraph는 기존의 Pregel 그래프 개념을 기반으로 하여, 이 개념을 에이전트 설계에 적용한 시스템입니다. Pregel 그래프는 컴퓨터 과학에서 큰 데이터를 처리할 때 사용하는 모델인데, 이를 LangGraph에서는 에이전트가 수행할 작업을 정의하는 데 사용합니다.
LangGraph에서는 에이전트가 움직일 수 있는 노드(Node)와 에지(Edge)를 정의합니다. 쉽게 말해, 노드는 에이전트가 특정 작업을 수행할 수 있는 지점이고, 에지는 노드 사이를 연결하는 길입니다. 에이전트는 이 노드들을 따라 이동하며 작업을 처리하게 됩니다.
LangGraph에서도 라우터 노드를 정의할 수 있지만, 일반적으로는 필요하지 않습니다. 특히, 여러 에이전트가 동시에 작동하는 멀티 에이전트 애플리케이션을 사용하지 않는 경우에는 더욱 그렇습니다.
대신에, LangGraph에서는 조건 논리를 노드와 에지에 직접 적용할 수 있습니다. 이 조건 논리는 에이전트가 어떤 노드에서 다음 노드로 이동할지 결정하는 규칙입니다. 예를 들어, 에이전트가 특정 조건을 만족하면 A 노드에서 B 노드로 이동하고, 그렇지 않으면 C 노드로 이동하는 식입니다. 이렇게 조건을 설정하면 라우터를 따로 사용하지 않고도 에이전트의 경로를 유연하게 조절할 수 있습니다.
정리하자면, LangGraph는 에이전트가 수행할 작업을 그래프 형태로 설계하고, 노드와 에지를 통해 작업의 흐름을 관리하는 시스템입니다. 라우터 대신 노드와 에지에 조건 논리를 적용하여 에이전트의 행동을 결정할 수 있도록 합니다.
LlamaIndex Workflows
LlamaIndex Workflows는 에이전트를 설계하는 또 다른 방식으로, 이벤트와 이벤트 리스너를 사용해 에이전트가 노드 사이를 이동하게 합니다. 이 프레임워크는 에이전트가 어떤 작업을 수행해야 할 때 발생하는 사건(이벤트)과, 그 사건에 반응하는 기능(이벤트 리스너)을 통해 에이전트의 행동을 결정합니다.
LangGraph처럼, LlamaIndex Workflows에서도 라우팅 노드가 필수는 아닙니다.
대신, LlamaIndex Workflows에서는 단계라고 부르는 각각의 노드가 이 역할을 합니다.
단계는 들어오는 이벤트를 처리하고, 그 결과로 새로운 이벤트를 만들어내어 다음 단계로 보내는 역할을 합니다. 예를 들어, 에이전트가 특정 데이터를 처리한 후, 그 결과를 바탕으로 다음 작업을 자동으로 결정할 수 있습니다. 이 모든 과정은 각 단계 내부에서 처리되기 때문에, 에이전트의 논리(즉, 어떤 순서로 작업을 수행할지에 대한 결정)는 주로 이 단계 내에서 이루어집니다.
쉽게 말해, LlamaIndex Workflows에서는 각 단계가 개별적으로 작동하며, 단계들 사이에서 정보를 주고받는 방식으로 에이전트가 작업을 수행합니다. 이를 통해 에이전트의 동작이 자연스럽게 연결되고, 각 단계가 독립적으로 논리를 처리할 수 있습니다.
에이전트를 고려할 때의 핵심 질문
Q. 에이전트를 개발하기 위해 프레임워크를 사용해야 합니까?
A. 필자의 생각은 현재까지는 시기상조. 전반적인 시스템에 너무 많은 복잡성이 있어서 Pregel 기반 아키텍처에 적합하지 않다고 봅니다. 프레임워크보다 필요한 기능만 코드를 통해서 구현가능 가능하다고 생각합니다.
하지만 우리는 에이전트 프레임워크 방식도 고려해볼만한 가치가 있다고 봅니다.
이들 프레임워크들이 지속적으로 개선되고 있으며, 할 수 있는 작업을 확장하고 있습니다.
그리고 새로운 에이전트 프레임워크가 속속히 출시되고 있어서 향후에는 특정 프레임워크으로 귀결될 가능성이 매우 높습니다.
Q.실제로 에이전트가 필요한가요?
A. 에이전트가 필요한지 판단하기 위한 세 가지 기준은 다음과 같습니다.
반복적인 흐름: 애플리케이션이 반복적인 작업을 수행하는가?
피드백에 따른 적응: 이전 작업이나 피드백에 따라 흐름을 조정해야 하는가?
이 기준을 만족하면 에이전트가 유용할 수 있습니다.
마치며
아직까지는 에이전트 성과가 나오지 않는 게 현실입니다.
앞으로는 이를 크게 개선하려는 움직임들이 있을 것이고, 조심스럽게 2025년에는 에이전트가 활성화되는 시기가 되었으면 하는 바램입니다.
참고 사이트
https://langchain-ai.github.io/langgraph/
https://arize.com/blog/llamaindex-workflows-a-new-way-to-build-cyclical-agents/
