LangGraph 에 대해 살펴보기 위해 공식 문서를 읽어보려고 합니다.
어떤 프로젝트이든 공식 문서가 가장 핵심적이고 정확한 내용들을 다루고 있다고 생각하는데요.
(물론 문서가 부실한 프로젝트도 있긴 합니다..)
LangGraph 는 문서도 잘 되어 있고 예제 코드도 많이 있어서 시간이 되시는 분들은 공식 문서를 직접 보시면 좋을것 같습니다.
이 글은 공식 문서를 기반으로 하되 개인적으로 궁금한 것들을 추가로 조사해서 정리한 내용입니다.
GoGo!!
Overview
공식 문서 첫 페이지를 보면 뭔가 추상적이지만 LangGraph 의 핵심적인 특징을 표현한 문단이 나옵니다.
LangGraph is a library for building stateful, multi-actor applications with LLMs, used to create agent and multi-agent workflows. Compared to other LLM frameworks, it offers these core benefits: cycles, controllability, and persistence. LangGraph allows you to define flows that involve cycles, essential for most agentic architectures, differentiating it from DAG-based solutions. As a very low-level framework, it provides fine-grained control over both the flow and state of your application, crucial for creating reliable agents. Additionally, LangGraph includes built-in persistence, enabling advanced human-in-the-loop and memory features.
LangGraph 는 LLM 기반의 에이전트 시스템을 개발하기 위한 라이브러리입니다.
단일 에이전트를 구성하거나 혹은 멀티 에이전트를 조합하기 위한 방법들을 제공하고 있습니다.
에이전트라는 개념상 특정 흐름에 따라 수행하고 끝나는 것이 아니기 때문에 (differentiating it from DAG-based solutions)
실행 흐름이 반복될 수 있고 (cycles)
이 과정에서 흐름을 제어할 수 있어야 하고 (controllability)
이를 위해 현재 상태가 어딘가에 유지되고 활용될 수 있어야 합니다 (stateful & persistence)
대강 느낌은 오는데
근데 에이전트 시스템이 구체적으로 뭘까요?
Agent 시스템이란?
여기서 에이전트 시스템이라함은 전반적인 실행 흐름이 LLM 에 의해 제어되는 시스템이라고 볼수 있습니다.
실행 흐름을 제어한다는 것은 예를 들면 어떤 tool 을 호출할지 결정하는 것, 생성한 응답이 충분한지 혹은 추가 작업을 더 수행할지를 결정하는 것, 대화를 종료할지 혹은 계속할지를 결정하는 것 등입니다.
즉 개발자가 코딩한 로직에 의해 LLM 이 호출되는 것과 다르게 에이전트 시스템은 LLM 호출과 응답 처리 자체도 LLM 의 판단에 의해 수행되는 형태입니다. (물론 전반적인 에이전트 구성은 개발자의 몫입니다.)
에이전트 시스템을 구성하기 위해 필요한 주요 요소들은 Tool, Action, Memory, Planning 등이 있습니다.
- Tool: LLM 외부의 작업을 수행하기 위한 도구들 (예: 검색 호출, DB 작업, 외부 API 조회 등)
- Action: 특정 상태에서 다음에 진행할 작업을 결정
- Memory: 전반적인 작업 진행 상태 및 사용자와의 대화를 유지하기 위한 저장소
- Planning: 전체 태스크 진행을 위한 계획 수립
아직까지 컨셉적인 설명이 많아서 잘 와닿지 않는 느낌이네요.
구체적인 예시를 보면 좀더 와닿을 것 같으니까 에이전트 시스템의 예시는 어떤게 있는지 살펴보겠습니다.
UseCase
LangGraph 입장에서도 제일 적합한 예시들을 작성했을테니 LangGraph 문서의 유즈케이스들을 살펴보겠습니다.
ChatBot - Customer Support
에이전트 시스템의 가장 대표적인 예시로는 고객 센터가 있습니다.
예를 들어 항공사 고객 센터의 경우 고객의 요청을 받아서 항공편을 조회 & 예약하거나 연계된 호텔, 렌트카, 투어 정보를 제공할 수 있는데요.
각각을 별도의 에이전트로 만들고 맨 앞에서 고객을 직접 응대하는 라우팅 에이전트를 둠으로써 멀티 에이전트 방식으로 고객 센터 챗봇을 구현할 수 있습니다.
어떻게 보면 반복적인 태스크가 많지만 고객을 직접 응대해야 하기 때문에 만만치 않은 분야인데요.
고객센터 챗봇이야말로 에이전트 시스템을 활용할 수 있는 가장 대표적인 예시라고 생각합니다.
RAG - Agentic RAG
LLM 에 도메인 지식을 조합하는 RAG 는 할루시네이션을 많이 줄여주지만 한계점도 많이 있는데요.
에이전트 방식으로 RAG 를 구성함으로써 쿼리를 확장하거나 재검색을 수행하는 등 결과의 퀄리티를 높일 수 있습니다.
(물론 수행 시간이 늘어나는 점은 고려가 필요합니다..)
Collaborative Multi-Agents
딱히 와닿는 유즈케이스가 안보여서 다른 문서를 찾아보았는데요.
특정 태스크를 수행하기 위해 협업하는 멀티 에이전트 시스템을 구성할 수 있습니다.
예를 들면 특정 나라의 최근 5년 GDP 를 보여주는 태스크를 위해서 아래와 같이 구성할 수 있습니다.
Researcher 에이전트는 외부 검색을 통해 데이터를 수집하는 역할을 합니다.
Chart Generator 에이전트는 주어진 데이터를 분석하고 차트를 생성하는 역할을 합니다.
Router 에이전트는 Research 와 Chat Generator 사이의 라우팅이나 결과물에 대한 검증인 역할을 합니다.
그 외에도 LangGraph git 에 많은 수의 examples 들이 포함되어 있는데요.
(위치: https://github.com/langchain-ai/langgraph/tree/main/examples)
주요 예제들은 나중에 코드들을 살펴볼 예정입니다.
근데 몇개만 살펴봐도 뭔가 복잡한 구조처럼 보이는데요.
이런 복잡한 멀티 에이전트 방식이 꼭 필요한 것일까요?
Multi-agent System
멀티 에이전트 시스템에 대해 좀더 알아보겠습니다.
랭체인 블로그에 있는 자료를 참고했습니다.
(출처: https://blog.langchain.dev/langgraph-multi-agent-workflows/)
멀티 에이전트 시스템에서 각 에이전트는 독립된 Prompt, LLM, Tools, 비즈니스 로직(State 포함)을 가집니다.
객체지향에서 모듈의 개념과 비슷한것 같습니다.
여기서 핵심은 독립된 Prompt 와 Tools 을 가진다는 것인데요.
이렇게 특정 태스크에 포커스된 형태로 LLM 을 활용하는 것이 결과의 퀄리티가 더 좋다고 합니다.
그리고 모듈화의 장점인 모듈 단위 평가 및 개선이 가능하게 됩니다.
하지만 수행 시간이 오래 걸릴 것 같은데 이에 대한 언급은 없네요.
실제 서비스에서는 이 부분도 무시할 수 없기 때문에 잘 따져봐야 할것 같습니다.
멀티 에이전트 시스템을 설계할 때 고려할 점은 1) 각 에이전트의 역할 및 태스크 2) 에이전트간의 연결입니다.
여기서 각 에이전트를 노드, 에이전트 간의 연결 관계를 엣지라고 보면
노드와 엣지 즉 그래프 구조가 됩니다.
그래서 LangGraph 가 그래프 구조를 기반으로 에이전트 시스템을 구성하도록 되어 있습니다.
이제 다시 LangGraph 로 돌아가서 살펴보겠습니다.