LLM 에이전트 메모리, 추가 생성 없이도 되는가 — Zero-Mem이 던진 질문

장시간 대화나 여러 세션에 걸쳐 일관되게 동작해야 하는 LLM 에이전트에게 '메모리'는 선택이 아니라 필수 기능이 됐다. 과거 상호작용을 기억하지 못하면 같은 질문에 매번 다른 답을 내놓거나, 앞서 사용자가 알려준 정보를 잊어버린다. 문제는 이 메모리를 운용하는 방식이다. 오늘날 많은 메모리 시스템은 과거 대화를 요약·정리해 중간 기록을 만들고, 질의가 들어오면 다시 LLM을 호출해 관련 기록을 추려낸다. 즉 최종 답변을 생성하기 전 단계에서도 LLM이 반복적으로 개입한다.

최근 공개된 Zero-Mem 연구는 바로 이 지점을 문제 삼는다. 메모리를 읽고 정리하는 과정마다 LLM을 부르면 토큰 비용과 지연 시간이 계속 쌓인다. 게다가 요약 과정에서 세부 정보가 누락되거나 여러 사실이 하나로 뭉개지면, 정작 근거가 되어야 할 원본 증거가 흐려진다. 연구진의 질문은 단순하다. 구조화된 메모리 접근에 과연 '생성'이 반드시 필요한가.

제로 토큰 메모리라는 발상

Zero-Mem이 내세우는 개념은 '제로 토큰 메모리 연산(zero-token memory operations)'이다. 최종 질의응답(final QA)을 제외한 어떤 단계에서도 LLM을 호출하지 않고, LLM 입력·출력 토큰을 소비하지 않는다는 뜻이다. 인코더 연산은 별도로 계산에 넣는다는 단서를 달았지만, 핵심은 메모리를 다루는 모든 중간 과정에서 생성형 모델을 걷어냈다는 점이다. 오직 마지막에 답을 만들어내는 리더(reader)만이 LLM을 사용한다.

이를 위해 Zero-Mem은 과거 상호작용의 원본 기록(trace)을 그대로 보존하고, 이를 두 가지 상호 보완적인 방식으로 조직한다. 하나는 '엔티티-컨텍스트 그래프'로, 여러 대화에 흩어진 개체들 사이의 연결 관계를 드러낸다. 다른 하나는 '시간적 계층 구조'로, 대화의 국소성과 세션 상태, 즉 어떤 이야기가 언제 어떤 맥락에서 오갔는지를 보존한다. 그래프가 '무엇이 무엇과 연결되는가'를 본다면, 시간 계층은 '어떤 흐름 속에 있었는가'를 본다.

질의에 따라 두 관점을 저울질한다

질의가 들어오면 Zero-Mem은 두 관점의 비중을 상황에 맞게 저울질하고, 양쪽 모두에서 근거를 검색한 뒤 각 구조를 따라 필요한 관계나 주변 맥락을 복원한다. 이후 결정론적 보정(deterministic calibration) 단계에서 서로 충돌하는 증거를 먼저 걸러내고, 리더가 내놓는 답이 검색된 원본 기록에 확실히 근거하도록 붙잡아 둔다. 답변을 만드는 순간까지 요약본이 아니라 실제 대화 흔적을 붙들고 간다는 점이 이 접근의 핵심 성격이다.

성능 면에서 연구진은 장기 메모리형 질의응답과 롱컨텍스트 질의응답 벤치마크 전반에서 경쟁력 있는 결과를 냈다고 밝힌다. 같은 최종 QA 리더와 동일한 컨텍스트 예산을 놓고 비교했을 때, 메모리 연산에 드는 시간 비용을 가장 빠른 비교 대상 대비 57.6% 줄였다는 수치를 제시한다. 즉 정확도를 크게 희생하지 않으면서도 메모리 운용 단계의 LLM 호출과 토큰 소비를 없앴다는 주장이다. 아블레이션 실험은 두 관점 각각의 기여와, 질의에 따라 둘을 조율하는 방식의 효과를 뒷받침한다고 덧붙인다.

한국 실무자에게 주는 함의와 한계

실무 관점에서 이 연구가 흥미로운 이유는 비용 구조에 직접 닿기 때문이다. 대화형 에이전트를 운영하다 보면 사용자 눈에 보이지 않는 메모리 정리·검색용 LLM 호출이 토큰 청구서의 상당 부분을 차지하고, 응답 지연의 원인이 되기도 한다. 메모리 운용에서 생성형 호출을 제거할 수 있다면 운영 비용과 응답 속도 양쪽에서 여유가 생긴다. 원본 기록을 그대로 보존한다는 설계도, 요약 과정에서 근거가 훼손돼 사후 감사나 디버깅이 어려워지는 문제를 겪어본 팀이라면 눈여겨볼 만하다.

다만 신중하게 읽을 대목도 있다. '제로 토큰'이라고 해도 인코더 계산 비용은 별도로 존재하므로, 임베딩 생성과 그래프·시간 구조 유지에 드는 자원은 여전히 시스템 설계에서 고려해야 한다. '경쟁력 있는 성능'이라는 표현은 최고 기록이 아니라 견줄 만한 수준이라는 뜻으로, 정확도가 최우선인 과제에서는 트레이드오프를 직접 검증해야 한다. 벤치마크 환경과 실제 서비스의 대화 분포가 다를 수 있다는 점도 마찬가지다. 코드와 구현 세부는 동료 평가 이후 공개 예정이라고 밝혀, 현재로서는 재현과 검증에 제약이 있다. 그럼에도 '과거를 다루기 위해 반드시 과거의 중간 표현을 새로 생성할 필요는 없다'는 문제 제기 자체는, 메모리 아키텍처를 고민하는 팀이 자신의 파이프라인을 되돌아보게 만들기에 충분하다.