유형별 메모리 구조화로 검색 토큰을 약 40% 절감할 수 있습니다.

평면적(flat) 메모리 저장소가 한계에 부딪히는 이유

대부분의 초보자용 튜토리얼은 모든 새로운 정보를 단일 리스트에 추가하고 매 턴마다 그 리스트를 모델에 다시 전달하는 방식으로 LLM 에이전트에게 "기억"하는 법을 가르칩니다. 코드는 말 그대로 세 줄뿐이며 작동하는 데모를 만들어냅니다. 하지만 실제로는 리스트가 걷잡을 수 없이 커집니다. 이때 두 가지 증상이 나타납니다.

  • 에이전트가 오래된 데이터를 여전히 유효한 것으로 취급합니다. 예를 들어, 몇 시간 전에 만료된 ETA(도착 예정 시간)를 제공하는 식입니다.
  • 답변에 전혀 영향을 주지 않는 사소한 정보들로 컨텍스트 창이 가득 차게 되어, API 비용이 증가하고 응답 속도가 느려집니다.

단순한 벡터 저장소나 간단한 키-값(key-value) 캐시는 사용자의 직함과 일시적인 프로젝트 상태를 구분하지 못합니다. 에이전트가 시맨틱 검색(semantic search)을 수행할 때, 데이터가 더 이상 관련이 없음에도 불구하고 쿼리에 동일한 단어가 포함되어 있다는 이유만으로 유사도 알고리즘이 오래된 ETA를 결과로 내놓을 수 있습니다.

구조화된 메모리: 네 개의 버킷, 하나의 목적

해결책은 메모리를 하나의 거대한 덩어리(monolith)로 취급하는 것을 멈추고, 각 항목을 다음 네 가지 카테고리 중 하나로 분류하기 시작하는 것입니다.

  • 사용자 정보(User facts) – 사용자의 역할, 선호 언어, 보안 등급과 같이 변하지 않는 속성입니다. 이러한 정보는 거의 바뀌지 않으므로 전체 세션 동안 캐싱할 수 있습니다.
  • 피드백(Feedback) – 에이전트가 반드시 준수해야 하는 명시적인 규칙입니다. 예: "데이터베이스 비밀번호를 절대 공개하지 말 것" 또는 "규정 준수 질의 시 유머를 피할 것". 이 규칙들은 행동을 제어하므로 검색 가능한 풀(pool)보다는 시스템 프롬프트에 포함되어야 합니다.
  • 프로젝트 상태(Project state) – 현재 ETA, 작업 진행 상황 또는 임시 토큰과 같이 빠르게 변하는 데이터입니다. 이 버킷에는 만료 확인이 필요합니다. 타임스탬프가 정의된 범위를 벗어나면 해당 항목은 삭제되어야 합니다.
  • 참조(References) – 외부 서비스, 문서 ID 또는 API 엔드포인트에 대한 포인터입니다. 이는 표시할 콘텐츠가 아니라 필요할 때 최신 데이터를 가져오기 위한 경로입니다.

Mem0를 사용하면 개발자는 각 메모리 레코드에 임의의 메타데이터를 첨부할 수 있습니다. "kind" 필드를 기준으로 인덱싱하면, LLM이 결과를 어떻게 사용할지 결정하기 전에 쿼리를 통해 관련 버킷을 먼저 필터링할 수 있습니다.

Mem0를 활용한 2단계 검색

  1. 유형별 메모리 추출 – 짧은 필터 쿼리를 통해 Mem0에 "모든 피드백" 또는 "최근 일정 기간 내의 프로젝트 상태 항목"을 요청합니다. 결과 세트는 이미 적절한 카테고리로 걸러진 상태입니다.
  2. LLM이 결정하도록 함 – 필터링된 스니펫(snippets)을 사용자의 현재 질문과 함께 프롬프트에 삽입합니다. 이제 모델은 관련 없는 사실들을 뒤질 필요 없이 해당 정보들을 바탕으로 추론할 수 있습니다.

구체적인 예시: "데이터베이스를 조롱하지 말 것"이라는 규칙이 시맨틱 매칭을 통해 나타나기를 기다리는 대신, 개발자는 세션 시작 시 해당 규칙을 시스템 프롬프트에 직접 주입하고 전체 상호작용 동안 캐싱합니다. 사용자의 쿼리에 데이터베이스에 대한 명시적인 언급이 없더라도, 모델은 이미 해당 제약 사항을 알고 있습니다.

비용을 절감하는 실용적인 팁

  • 피드백 규칙 캐싱 – 매 턴마다 다시 검색하는 대신 세션당 한 번 규칙 세트를 저장하고 재사용합니다. 이를 통해 매 라운드 토큰 사용량을 줄일 수 있습니다.
  • 관련 없는 경우 프로젝트 상태 검색 건너뛰기 – 사용자가 순수하게 개념적인 질문(예: "지도 학습과 강화 학습의 차이점은 무엇인가요?")을 하는 경우, ETA나 작업 진행 상황 데이터를 가져올 필요가 없습니다.

이 두 가지 습관을 적용하면 단순한 평면적 메모리 방식에 비해 토큰 사용량을 약 40% 줄일 수 있습니다. 이러한 절감 효과는 특히 많은 대화가 오가는 에이전트의 경우 API 비용 절감과 빠른 응답 속도로 직결됩니다.

수혜자와 우려 사항

승자 – 고객 지원 봇, 내부 워크플로우 어시스턴트 또는 멀티 턴(multi-turn) LLM 인터페이스를 구축하는 팀입니다. 이들은 더 신뢰할 수 있는 답변을 얻고, 오래된 데이터로 인한 당혹스러운 실수를 방지하며, 예산을 더욱 효율적으로 사용할 수 있습니다.

핵심 요약

긴 세션 동안 성능을 유지하는 LLM 에이전트를 원한다면, 모든 사실을 단일 컨텍스트 창에 쑤셔 넣는 것을 멈추십시오. 각 메모리에 사용자 정보, 피드백, 프로젝트 상태 또는 참조 태그를 달고, 필요한 경우 만료 정책을 적용하며, Mem0와 같은 도구가 복잡한 작업을 처리하도록 맡기십시오. 그 결과 더 신선한 답변, 불필요한 토큰 감소, 그리고 눈에 띄는 운영 비용 절감을 얻을 수 있습니다.