AI의 기억은 저장한 뒤부터 어려워진다

노트북은 수년치 메일을 한 글자도 빠뜨리지 않고 보관합니다. 그런데 그 안에서 작동하는 AI 에이전트는 어제 바뀐 납기일을 틀릴 수 있습니다.

프로젝트 납기일이 8월 10일에서 8월 18일로 바뀌었다고 해보겠습니다. 예전 메일에는 8월 10일이 남아 있고, 업무 시스템에는 새 날짜가 반영됐습니다. 다음 날 AI 에이전트가 예전 메일을 찾아 8월 10일이라고 답한 뒤 그 날짜로 배송까지 예약합니다.

기록은 사라지지 않았고 검색은 관련 메일을 찾아냈습니다. 문제는 그다음입니다. AI가 오래된 기록과 지금 유효한 값을 구분하지 못한 채 검색 결과를 행동에 사용했습니다.

사람은 지난 경험에서 의미와 패턴을 뽑아 다음 판단에 씁니다. 대신 문장과 숫자를 원문 그대로 오래 보존하는 데는 약합니다. 컴퓨터는 원문과 변경 이력을 정확히 남길 수 있습니다. 오래 일하는 AI에는 두 능력이 모두 필요합니다.

AI 장기기억은 대화와 문서, 업무 상태와 실행 결과를 요청 사이에 보존하고, 현재 상황에 맞는 내용을 골라 다음 판단과 행동에 다시 쓰는 기능입니다.

AI의 기억 문제는 저장한 뒤부터 시작됩니다.

컴퓨터는 저장하고, AI는 골라 쓴다

일반적인 LLM 서비스에서는 애플리케이션이 대화와 문서를 보관합니다. 모델이 과거 기록을 참고하려면 애플리케이션이 필요한 내용을 찾아 이번 요청의 컨텍스트에 넣어 줘야 합니다. RAG는 관련 문서를 찾아 모델에 건네는 방법이고, 긴 컨텍스트는 찾아온 내용을 넓게 펼쳐 놓을 공간입니다. 현재의 LLM은 거대한 기억 창고를 가진 존재보다 요청마다 새 책상을 받는 독자에 가깝습니다.

애플리케이션이 기록을 통째로 올리면 모델은 이번 요청에서 그 내용을 다시 읽어야 합니다. 입력이 길수록 답변을 시작하기 전의 연산과 요청 하나가 차지하는 GPU 메모리가 늘어납니다.

RAG와 긴 컨텍스트는 유용하지만 기록을 많이 보여 주는 것만으로 기억이 좋아지지는 않습니다. LongMemEval은 정답의 근거가 담긴 대화만 모델에 제공했을 때와 관련 없는 대화까지 약 11만 5천 토큰으로 함께 제공했을 때를 비교했습니다. 전체 이력을 그대로 읽은 다섯 모델의 정확도는 필요한 대화만 읽었을 때보다 상대적으로 30.3–55.1% 낮았습니다.

긴 컨텍스트에도 선별은 필요합니다. 책상이 아무리 넓어도 오늘 처리할 서류와 폐기할 초안을 뒤섞어 놓으면 일을 그르칠 수 있습니다.

알맞은 기록을 찾은 뒤에는 그 내용을 행동에 옮겨야 합니다. Mem2ActBench는 장기기억 시스템 일곱 가지를 400개의 도구 사용 과제로 시험했습니다. 과제는 알맞은 도구를 고르고 인자 값을 채우도록 만들었으며, 시험한 시스템들은 기억 속 선호와 작업 상태를 인자에 충분히 반영하지 못했습니다. 납기일을 8월 18일이라고 답하면서 배송 예약에는 8월 10일을 넣는 식의 오류입니다.

AI 장기기억에는 기록을 남기는 일, 필요한 기록을 찾는 일, 지금 유효한 값을 가리는 일, 그 값을 행동에 쓰는 일이 모두 들어갑니다. 행동의 결과까지 다시 기록해야 다음 요청에서 같은 실수를 피할 수 있습니다.

8월 10일도 남기고, 8월 18일로 행동한다

8월 10일은 과거에 맞았고, 8월 18일은 지금 맞습니다. 두 날짜를 함께 보존해야 변경 이유를 확인할 수 있습니다. 오늘의 배송에는 현재 값인 8월 18일을 써야 합니다.

같은 사건에 관한 기억도 쓰임에 따라 나눠야 합니다. 회의 녹취와 메일은 원문과 이력으로 남깁니다. 누가 언제 날짜를 바꿨는지 확인할 때 필요합니다. 업무 시스템에 확정된 8월 18일은 현재 상태이며, 오늘 납기일을 답하거나 배송을 예약할 때 기준으로 삼습니다.

여기에 절차와 패턴이 더해집니다. 여러 프로젝트에서 익힌 출하 순서와 점검 방법이 여기에 해당합니다. 반드시 지켜야 할 순서는 워크플로와 규칙으로 실행하고, 반복된 경험의 공통점은 모델이나 별도의 신경망 메모리에 익힐 수 있습니다.

에이전트가 납기일을 물으면 먼저 현재 상태를 확인하고, 이유가 필요할 때 원문과 이력을 찾으면 됩니다. 배송을 예약한 뒤에는 예약 번호와 실행 결과를 다시 기록합니다. 어느 저장소를 읽을지, 여러 값 가운데 무엇을 우선할지, 결과를 어디에 쓸지 조정하는 기능을 이 글에서는 AI 메모리 제어라고 부르겠습니다. 현재의 AI 서비스에서는 데이터베이스, 검색 시스템, 에이전트 소프트웨어와 모델이 이 일을 나눠 수행합니다.

프롬프트에는 지금 필요한 기억만 올린다

현재 LLM은 컨텍스트에 들어온 토큰을 바탕으로 계산합니다. 배송 예약을 처리할 때 모델에 필요한 정보는 수년치 메일 전체가 아닙니다. 확정 납기일 8월 18일, 그 값을 확인한 업무 시스템, 변경 사유가 담긴 문서 주소면 충분합니다. 출하 절차도 필요한 단계만 꺼내면 됩니다.

이처럼 외부에서 기억을 정리한 뒤 작은 묶음으로 건네는 방식은 지금도 구현할 수 있습니다. 데이터베이스가 현재 값을 조회하고, 검색 시스템이 근거 문서를 찾고, 워크플로가 필수 절차를 불러옵니다. 메모리 제어는 이 결과를 모아 모델에 전달합니다. 모델이 답하거나 도구를 호출한 뒤에는 실행 결과를 다시 업무 시스템과 이력에 기록합니다.

최근에는 대화 속에서 값이 바뀐 시점을 추적하고, 실행 중 들어오는 정보로 별도의 신경망 메모리를 갱신하며, 검색 결과를 프롬프트와 다른 계산 경로로 전달하는 방법도 연구되고 있습니다. 어느 방법을 택하든 저장과 갱신, 삭제, 행동 반영은 시스템 전체에서 함께 다뤄야 합니다.

정확한 숫자와 문구는 원문을 확인하고 명시적으로 고칠 수 있어야 합니다. 신경망 메모리는 비슷한 상황에 적응하는 데 쓸 수 있지만 계약 문구나 재고 수량을 보관하는 데이터베이스를 대신하기 어렵습니다. 오래 남는 기억에는 출처와 권한도 따라야 합니다. 문서에 숨긴 공격 지시가 거짓 기억으로 저장된 뒤 다른 대화에서 에이전트의 행동을 바꾼 장기기억 오염 공격도 보고됐습니다.

결국 컨텍스트에는 이번 판단에 필요한 내용만 올리고, 원문과 현재 상태는 외부 데이터 계층에 남기는 편이 실용적입니다. 반복된 경험의 패턴은 신경망 메모리에 익힐 수 있습니다. 프롬프트는 기억 창고보다 작업대에 가깝습니다.

기억에도 GPU 비용이 든다

대화 파일을 저장 장치에 복사하는 데는 큰 연산이 필요하지 않습니다. 그러나 대화에서 사람과 일정, 선호와 결정 사항을 뽑고, 기존 기억과 충돌하는지 판단한 뒤 요약과 색인을 고치는 작업에는 모델을 여러 번 호출할 수 있습니다. 답변하기 전부터 GPU가 일하는 셈입니다.

2026년 공개된 Omri 연구진의 시스템 분석은 10개의 장기기억 시스템에 약 180만 토큰의 대화 이력을 넣고 300개 질문에 답하게 했습니다.

단어가 겹치는 기록을 찾는 BM25는 기억 구성부터 답변까지 582 kJ, 약 0.16 kWh의 GPU 에너지를 썼습니다. LLM이 도구를 호출해 기억을 정리하는 Letta는 15,429 kJ, 약 4.29 kWh를 썼습니다. 26배가 넘는 차이입니다. 이 실험에서 정답률은 BM25 47.0%, Letta 27.7%였습니다.

평가에는 Qwen3-32B와 Qwen3-Embedding-0.6B, NVIDIA H100 80 GB 한 장을 공통으로 사용했습니다. 다만 기억을 만들고 검색하는 절차는 시스템마다 달랐습니다. 이 수치는 모델 하나의 효율보다 각 메모리 시스템의 전체 처리 과정을 비교한 결과입니다.

BM25와 Letta는 기능 범위가 달라 이 숫자만으로 우열을 정하기 어렵습니다. Letta가 제공하는 기능 가운데 평가에 반영되지 않은 것도 있고, 한 번 만든 기억을 여러 번 사용하면 질문당 구성 비용도 낮아질 수 있습니다. 그래도 메모리 구조만 바뀌어도 GPU 사용량은 크게 달라졌고, 처리 단계를 늘린 Letta의 정확도는 이 평가에서 오히려 낮았습니다. 사용자와 세션이 늘면 기억 구성도 반복됩니다. 그만큼 메모리 구조의 차이가 에너지 비용과 GPU 점유 시간에 더 크게 반영될 수 있습니다.

메모리를 만드는 동안 오간 토큰 가운데 모델이 새로 쓴 출력 토큰의 비중은 시스템별 중앙값으로 4.6%였습니다. 나머지 대부분은 기존 기록을 읽는 입력 토큰이었습니다. 장기기억 인프라의 용량을 정할 때는 답변을 생성하는 decode와 함께 임베딩과 prefill의 부하도 살펴야 합니다.

단순한 검색과 집계는 데이터베이스나 가벼운 검색 엔진에 맡기고, 의미 판단이 필요한 기록에만 큰 모델을 호출하면 비용을 줄일 수 있습니다. 실시간 답변과 기억 정리 작업을 다른 큐와 자원으로 나누는 방법도 있습니다. 다만 갱신이 끝나기 전에 다음 요청을 처리하면 에이전트가 예전 상태를 읽을 수 있습니다. 빠른 응답과 기억의 최신성 가운데 무엇을 우선할지 업무마다 기준을 정해야 합니다. 장기기억을 실제 서비스에 넣으려면 AI 서빙과 AI 인프라 오케스트레이션도 함께 설계해야 합니다.

오래 일하는 AI가 갖춰야 할 것

좋은 기억을 가진 에이전트는 8월 10일을 변경 이력으로 보존하면서도, 오늘의 배송은 8월 18일로 예약합니다.

컴퓨터는 이미 많은 것을 정확히 저장합니다. AI 장기기억의 과제는 그 기록에서 현재 유효한 값을 찾아 근거와 함께 행동에 쓰는 것입니다. 기록이 바뀌면 현재 상태를 고치고, 행동이 끝나면 결과를 다시 남겨야 합니다.

긴 컨텍스트와 RAG는 이 과정에서 계속 중요한 역할을 할 것입니다. 앞으로는 원문과 현재 상태를 관리하는 데이터 계층, 반복된 경험을 익히는 신경망 메모리, 둘 사이에서 읽기와 쓰기를 조정하는 메모리 제어가 함께 발전할 가능성이 큽니다. 언어 모델은 사용자의 요청을 이해하고 결과를 설명하면서 이 구조를 이용하게 됩니다.

장기기억 시스템을 운영하려면 언어 모델 추론과 임베딩, 데이터베이스 조회, 기억 정리와 저장을 알맞은 장치에 배치해야 합니다. 이 선택에 따라 응답시간과 비용이 달라집니다.

매니코어소프트는 새로운 AI 모델과 워크로드를 효율적으로 실행할 인프라와 소프트웨어 구조를 연구·개발하고 있으며, 연구팀도 확대하고 있습니다. AI와 시스템이 만나는 문제를 함께 탐구하고 싶은 연구자와 엔지니어는 coffee@manycoresoft.co.kr로 커피챗을 요청해 주세요.