[LLM] 멀티 에이전트 시스템 구조

#LLM

LLM이나 채팅에 대한 hype이 미친듯이 차오르면서, 실제로 이를 이용한 서비스를 만들어서 제공하는 사례가 꽤 늘고 있다. 보통 간단한 고객문의 시스템이나, 특정 도메인에 최적화된 정보를 제공해주는 helper 같은 것들이다.

여기서는 LLM을 이용해서 전문화된 채팅 시스템을 만들게 될 경우, 고려해야할 부분과 일반적인 구현 방향성에 대해서 간략히 정리해본다.

기본 골격

사실 뭐 이것저것 고려하지 않는다면, LLM을 쓴다고 해서 시스템 구조가 크게 달라지지는 않는다.
그냥 일반적인 외부 API 쓰듯이 서버가 LLM에 요청을 보내고, 응답을 받아와서 적절히 처리하는 것이다.

차이점을 꼽자면, LLM 서비스들 특유의 느린 성능, 불안정성, 비용 등이 기존의 API들과 다른 부분이다.

근데 여기서 "비용"이나 특유의 느린 성능 때문에 아키텍쳐를 기형적으로 가져가야 하는 부분이 있다.
이건 아래에서 이어서 설명하겠다.

프롬프트와 비용

LLM은 입력이 정형적이지 않고, 출력 또한 정형적이지 않다. 양쪽 다 규칙 없는 텍스트다.
LLM에 텍스트 입력을 어떻게 보낼지에 대한 작업을 "프롬프트 엔지니어링"이라고 부른다.

보통 프롬프트는 이런 느낌으로 작성이 된다.

맨 위에 LLM에 원하는 조건들을 쭉 나열한 다음에, 맨 밑에 사용자의 실제 요청을 이어붙이는 식이다.

만약 대화에 필요한 도메인 정보가 있다면, 그 정보에 대한 거대한 텍스트를 프롬프트에 넣을 수도 있다.

이런 것도 RAG라고 부른다.

아무튼, 문제는 사용사례에 따라서 "프롬프트" 텍스트는 커질 수 있는데, 비용이나 처리 속도도 프롬프트 텍스트의 크기에 비례한다는 것이다.
그래서 프롬프트의 크기를 얼마나 줄이고 단순하게 유지하는지에 따라서 실제 품질이나 비용 절감 정도가 달라진다.

Multi Agent 시스템

근데, 만약 이 채팅 시스템에 여러가지 역할을 부여해서 다양한 기능을 제공하고 싶다면 어떻게 해야할까?
그냥 하나의 프롬프트에 각 기능 정의를 다 때려넣을 수도 있겠지만, 그러면 모든 요청이 너무 무겁고, 느리고, 비싸질 것이다. 게다가 결과의 품질 또한 장담할 수 없다.

그래서 이 경우 권장되는 설계 방식 중 하나가 multi agent 구조다. 각 기능 역할을 Agent라는 단위로 추상화하고, 각자 역할에 맞게 전문화된 프롬프트를 관리하도록 하는 것이다. 인프라 수준의 분리는 아니다.

그리고 가장 앞단에서 유저 입력의 컨텍스트를 파악하는 Agent를 하나 두고(가칭 Intro Agent), 그 응답에 따라서 전문화된 Agent에 요청을 다시 또 전달하도록 한다. 일종의 Routing이다.

만약 기존에 쇼핑 서비스가 있고, 여기에 보조용 채팅 시스템을 설계한다면 이런 느낌이 될 수 있다.

그래서 "오늘 날씨 어떄?" 같은 일상적인 대화가 들어왔다면,

Intro Agent가 talk로 판단
Talk Agent에 다시 입력 텍스트 전송
Talk Agent의 응답을 최종 응답으로 사용
정도가 될 것이다.
다른 대화 맥락도 마찬가지다.

이렇게 했을 때의 장점은

각 호출당 프롬프트 크기를 최소화할 수 있다. 가능한 경우 Intro Agent 단에서 빠르게 종료될 수도 있다.
코드베이스 관리나 최적화가 용이해진다. 특정 작업을 건드린다면 그 작업에 해당하는 에이전트 코드만 건드리면 되기 때문이다.
각 Agent별로 다른 모델을 사용해서 비용/성능을 세심하게 튜닝할 수 있다.

정도가 있다.

Multi Agent 라이브러리들

사실 저 Multi Agent 라는게 막 엄청 대단한 것까지는 아닌데, 또 직접 코드 구조를 짜려면 귀찮은 것은 맞아서 라이브러리들이 나온게 몇가지 있다.

Langgraph나 CrewAI, 근래에 나온 Google의 ADK(Agent Development Kit) 등이 이런 코드베이스를 패턴화한 라이브러리다.

그리고 다 파이썬이다.

참조
https://google.github.io/adk-docs/agents/#core-agent-categories