2026 개정판 · 1차 8월 8일 공개전체 커리큘럼 →
TECH 으로 돌아가기
TECH HACKER NEWS 오늘 6분 읽기 49 READS

LLM 에이전트의 기억, 토큰 없이 다룬다 — Zero-Mem 논문이 던지는 질문

LLM 에이전트의 기억, 토큰 없이 다룬다 — Zero-Mem 논문이 던지는 질문
SOURCE IMAGE · HACKER NEWS
LLM 에이전트의 기억, 토큰 없이 다룬다 — Zero-Mem 논문이 던지는 질문

요즘 LLM으로 에이전트를 만들어 본 분들이라면 공통적으로 부딪히는 벽이 하나 있어요. 바로 '기억' 문제인데요. 에이전트가 이전 대화나 작업 내용을 기억하게 하려면 결국 그 기억을 텍스트로 만들어서 프롬프트에 다시 넣어줘야 하거든요. 문제는 이 방식이 생각보다 돈과 시간을 많이 잡아먹는다는 거예요. 이번에 arXiv에 올라온 Zero-Mem이라는 논문은 바로 이 지점을 겨냥해요. 제목 그대로 '토큰을 소비하지 않는 메모리 연산'을 LLM 에이전트에서 가능하게 하겠다는 연구예요.

에이전트의 기억은 왜 비쌀까요

먼저 배경부터 짚고 갈게요. LLM은 '컨텍스트 윈도우'라는 작업 공간 안에 들어온 내용만 볼 수 있어요. 이게 뭐냐면, 모델이 한 번의 요청에서 읽을 수 있는 텍스트의 최대 분량이라고 생각하시면 돼요. 사람으로 치면 책상 위에 펼쳐놓을 수 있는 서류의 양이 정해져 있는 셈이죠. 대화가 길어지거나 에이전트가 수십 번의 도구 호출을 반복하면 이 책상이 금방 꽉 차버려요.

그래서 지금까지는 크게 두 가지 방법을 써왔어요. 하나는 오래된 대화를 요약해서 짧게 줄인 다음 다시 넣어주는 방식이고, 다른 하나는 RAG처럼 기억을 벡터 데이터베이스에 저장해뒀다가 필요할 때 검색해서 프롬프트에 붙여주는 방식이에요. MemGPT처럼 운영체제의 메모리 관리에서 영감을 받아 계층형 메모리를 만든 프로젝트도 있고요. 그런데 이 방법들에는 공통된 한계가 있어요. 어떤 방식을 쓰든 기억이 결국 '토큰'이 되어 컨텍스트 안으로 들어간다는 거예요. 토큰이 늘어나면 API 비용이 올라가고, 응답 속도도 느려지고, 정작 현재 작업에 쓸 컨텍스트 공간은 줄어들죠. 기억을 많이 넣을수록 머리가 무거워지는 아이러니한 상황인 거예요.

Zero-Mem이 던지는 아이디어

Zero-Mem이 제안하는 방향은 이 메모리 읽기/쓰기 작업을 토큰 바깥에서 처리하자는 거예요. LLM 내부에는 KV 캐시라는 게 있는데요, 이게 뭐냐면 모델이 텍스트를 읽으면서 계산해 둔 중간 결과를 저장해두는 내부 창고예요. 어텐션이라는 메커니즘이 이 창고를 참조하면서 다음 단어를 만들어내죠. 기억을 매번 텍스트로 변환해서 모델이 처음부터 다시 읽게 하는 대신, 이런 내부 표현 수준에서 기억을 직접 다루면 프롬프트에 토큰을 한 개도 추가하지 않고 메모리 연산을 할 수 있다는 게 핵심 발상이에요. 텍스트를 다시 읽어들이는 프리필(prefill) 과정 자체가 사라지니까 비용과 지연시간이 동시에 줄어드는 구조고요.

비유하자면 기존 방식이 매번 서랍에서 메모지를 꺼내 책상 위에 펼쳐놓고 처음부터 다시 읽는 거라면, 이 접근은 읽었던 내용이 이미 머릿속에 정리된 상태로 바로 떠오르게 만드는 것에 가까워요.

업계 흐름에서 보면

에이전트 메모리는 지금 가장 뜨거운 연구 주제 중 하나예요. MemGPT에서 출발한 Letta, LangGraph의 장기 메모리 기능, ChatGPT의 메모리 기능까지 모두 이 문제를 풀고 있지만, 전부 '텍스트를 다시 넣는' 방식이라는 공통점이 있어요. 프롬프트 캐싱이라는 기법도 있긴 한데, 이건 똑같은 앞부분을 재활용해서 비용을 아끼는 것이지 임의의 기억을 자유롭게 넣었다 뺐다 할 수 있는 건 아니거든요. 토큰 바깥에서 메모리를 다루려는 시도는 이 흐름에서 한 단계 더 깊이 들어간 접근이라고 볼 수 있어요.

한국 개발자에게 주는 시사점

에이전트 서비스를 운영해보면 토큰 비용의 상당 부분이 시스템 프롬프트와 메모리 재주입에서 나온다는 걸 체감하게 돼요. 이런 연구가 상용 API에 바로 적용되긴 어렵겠지만 (모델 내부에 접근해야 하니까요), 오픈소스 모델을 직접 서빙하는 팀이라면 이런 방향의 기법을 실험해볼 여지가 있어요. 당장은 프롬프트 캐싱과 메모리 요약 주기를 잘 설계하는 게 현실적인 답이지만, '기억은 반드시 토큰이어야 하는가'라는 질문 자체를 알아두는 것만으로도 아키텍처 설계의 시야가 넓어지거든요.

한줄 정리: 에이전트의 기억을 토큰으로 넣지 말고 모델 내부 표현 수준에서 직접 다루자는 연구가 나왔어요. 여러분은 에이전트 메모리를 어떻게 관리하고 계세요? 요약 재주입, RAG, 아니면 그냥 긴 컨텍스트 윈도우에 맡기시나요?


🔗 출처: Hacker News

SOURCE · HACKER NEWS
원문 전체 보기 → https://arxiv.org/abs/2607.29377
SHARE
NEXT · CHOOSE

변화를 읽었다면,
내가 만들 수익 구조를 고릅니다.

정보를 더 모으는 데서 멈추지 않고, 광고·외주·판매·중개·구독 중 내 상황에 맞는 출발점을 정해보세요.

21가지 수익 구조 살펴보기
처리 중...