AI 에이전트는 왜 RAG가 필요한가…장기 기억이 만드는 성능 차이

AI 에이전트는 작업과 관련된 맥락 정보를 많이 확보할수록 더 뛰어난 성능을 발휘한다.

하지만 에이전트의 메모리에는 한계가 있다. 에이전트가 기반으로 하는 대규모 언어 모델(LLM)은 상태를 유지하지 않는(stateless) 구조이기 때문이다. 메모리가 한계에 이르면 에이전트는 오류를 일으키거나 응답이 멈추고, 사실과 다른 내용을 생성하기도 한다. 메모리를 잘라내거나 압축하는 기법으로 이를 어느 정도 보완할 수는 있지만, 근본적인 해결책은 아니다.

이 같은 메모리 한계를 극복하는 보다 효과적인 방법은 에이전트 외부에 지속적으로 유지되는 메모리를 두는 것이다. 에이전트 내부 메모리는 현재 작업을 처리하는 데만 사용하고, 장기적으로 보관해야 할 정보나 큰 맥락은 별도의 저장 서비스에 보관한 뒤 필요할 때 불러오는 방식이다.

이러한 접근 방식을 검색 증강 생성(Retrieval-Augmented Generation, RAG)이라고 한다. RAG는 에이전트와 LLM의 활용 범위를 그대로 유지하면서 기능을 확장해 주는 기술로, 이제는 에이전트와 LLM만큼 중요한 핵심 기술로 자리 잡고 있다.

RAG의 기본 원리

대규모 언어 모델(LLM)에는 입력 데이터를 처리하기 위한 일정 크기의 작업 메모리인 ‘컨텍스트 윈도(context window)’가 있다. 컨텍스트 윈도의 최대 크기는 모델마다 다르며, 이 공간이 클수록 더 많은 정보를 처리할 수 있다. 예를 들어 분석용 코드가 담긴 파일을 처리하거나 보다 복잡한 대화를 이어갈 수 있다.

RAG의 기본 개념은 단순하다. 현재 대화에 필요한 정보는 LLM의 컨텍스트 윈도에 유지하고, 그 외의 정보는 영구 저장소인 RAG에 보관하는 것이다. 즉, 컨텍스트 윈도는 단기 메모리 역할을 하고, RAG는 장기 메모리 역할을 담당한다.

RAG 저장소는 여러 형태로 구현할 수 있다. 2024년 발표된 논문 ‘언어 에이전트를 위한 인지 아키텍처(Cognitive Architectures for Language Agents)’에서는 이를 상세하게 설명하고 있는데, 주요 유형을 살펴보면 다음과 같다.

RAG 메모리의 유형

RAG 저장소는 크게 에피소드 메모리(Episodic Memory), 의미 메모리(Semantic Memory), 절차 메모리(Procedural Memory)의 세 가지 방식으로 구성된다.

에피소드 메모리: 작업 흐름과 프로세스

에피소드 메모리는 LLM이 과거 특정 시점에 생성한 데이터를 저장한다. 여기에는 LLM이 내린 의사결정과 그 결과가 포함된다.

이러한 경험은 시간순으로 정리돼 논문에서 ‘이력 이벤트 흐름(history event flows)’이라고 부르는 형태를 이룬다. 즉, 특정 결과가 생성되기까지의 과정을 기록하는 것이다. 이를 통해 LLM은 과거 수행했던 의사결정이나 작업 절차를 다시 구성하고, 그 경험을 향후 작업에 활용할 수 있다.

의미 메모리: 사실과 지식

의미 메모리는 논문에서 설명하듯 ‘세상과 에이전트 자신에 대한 구조화된 정보’를 저장한다.

예를 들어 사용자 선호도를 단순한 키-값(key-value) 저장소에 보관할 수도 있고, 벡터 임베딩과 같은 보다 복잡한 방식으로 저장할 수도 있다. 핵심은 에이전트가 이러한 ‘세계 지식’을 필요할 때 즉시 조회하고 그대로 활용할 수 있도록 하는 것이다.

의미 메모리는 관리 가능해야 한다는 점도 중요하다. 논문에서는 위키피디아처럼 여러 사용자가 수정할 수 있는 외부 정보원은 예기치 않게 내용이 바뀔 수 있지만, 특정 시점의 데이터를 저장한 오프라인 버전은 이러한 문제가 발생하지 않는다고 설명한다.

절차 메모리: 작업과 역량

절차 메모리는 겉으로 보기에는 에피소드 메모리와 비슷하다. 추론 과정이나 학습 절차 등을 저장하기 때문이다.

하지만 절차 메모리의 목적은 특정 작업을 수행했다는 사실이 아니라, 그 작업을 수행하는 절차 자체를 재현하는 데 있다. 덕분에 LLM은 동일한 작업을 수행할 때마다 절차를 처음부터 다시 찾아내거나 새로 만들 필요 없이 반복적으로 실행할 수 있다.

이들 메모리에는 한 가지 공통점이 있다. 모두 쓰기(write)보다 읽기(read)에 더 적합하다는 점이다. 예를 들어 의미 메모리는 새로운 사실을 저장할 수는 있지만 자주 갱신할 필요는 없다. 반면 에이전트가 절차 메모리를 자유롭게 수정하도록 허용하면 논문에서 지적한 것처럼 “버그가 발생하거나 에이전트가 설계자의 의도를 벗어나는 행동을 할 수 있다.”

RAG 구현

RAG는 에이전트 측면에서는 일반적인 구조로 자리 잡았지만, RAG 저장소를 구현하는 방식은 하나로 정해져 있지 않다. 저장 계층으로는 일반적으로 벡터 데이터베이스를 사용하지만, 최근에는 다양한 데이터베이스가 벡터 기능을 지원하고 있다.

메모리를 저장하는 위치도 다양하다. LLM 서비스를 제공하는 업체는 서버 측 기능의 일부로 RAG를 제공할 수 있다. 반면 로컬에서 실행하는 LLM은 모델이 구동되는 동일한 시스템에서 RAG 저장 서비스를 함께 운영할 수도 있다. 다만 이 경우 더 많은 저장 공간과 연산 자원이 필요하다는 단점이 있다.

RAG 저장소는 별도의 관리도 필요하다. 에이전트의 목적과 활용 사례에 따라 저장 데이터를 관리하는 방식이 달라질 수 있다. 예를 들어 오래된 데이터는 주기적으로 삭제하거나 최신 데이터 또는 자주 조회되는 데이터보다 중요도를 낮게 설정할 수 있다.

여러 에이전트가 하나의 RAG 저장소를 공유할 수도 있지만 무분별하게 공유해서는 안 된다. 최소한 각 에이전트는 독립된 컨텍스트에서 동작해야 하며, 서로 다른 에이전트의 데이터와 활용 사례가 서로 영향을 주지 않도록 해야 한다. 보다 발전된 방식으로는 마이크로소프트(MS)의 오토젠(AutoGen)과 같은 도구를 활용해 여러 에이전트가 공유하는 RAG 컨텍스트를 구축할 수도 있다.
dl-ciokorea@foundryco.com