에이전트 메모리(agent memory) 설계: 상태 저장부터 비용 계산까지

에이전트 메모리(agent memory)를 도입하기 전에 먼저 어떤 정보가 사라지는지 확인해야 합니다. 지금 프롬프트에 필요한 내용인지, 아직 끝나지 않은 작업의 진행 상태인지, 다음 주에도 필요한 지식인지에 따라 해법이 달라집니다. Anthropic의 Claude Managed Agents는 활성 세션 실행 시간당 $0.08에 모델 토큰 비용을 더해 과금하지만, 정보를 저장하는 일과 필요한 정보를 다시 불러오는 일은 별도로 설계해야 합니다. 우선 세션 상태를 저장하고 짧은 지침 파일을 두는 것부터 시작합니다. 새 세션에서 이전 작업의 일부 사실을 활용해야 할 때 장기 저장소를 추가합니다.

에이전트 메모리(agent memory)란? 남겨야 할 정보부터 정합니다

에이전트 메모리는 에이전트가 이후 작업으로 가져가 다시 활용할 수 있는 정보입니다. 핵심은 현재 모델 요청에서 볼 수 있는 정보와, 다음 요청을 위해 어딘가에 저장해 둔 정보를 구분하는 데 있습니다.

재시작한 에이전트가 고객을 기억하지 못한다면 프롬프트 한도를 늘려도 그 고객의 이력이 돌아오지 않습니다. 환불 처리의 어느 단계까지 끝냈는지 잊었다면, 고객 선호도를 검색하는 저장소만으로는 거래 진행 상태를 정확히 복원할 수 없습니다. 제품을 고르기 전에 무엇이 누락됐는지부터 파악해야 합니다.

운영 관점에서 메모리를 다음 네 가지로 나누면 선택이 쉬워집니다. 서로 경쟁하는 정의가 아니라, 필요에 따라 함께 사용할 수 있는 구성 요소입니다.

토큰은 모델이 처리하고 API가 사용량을 계산하는 작은 텍스트 단위입니다. 체크포인트는 워크플로의 진행 상황을 저장한 기록입니다. 임베딩은 의미 기반 검색에 쓰이는 콘텐츠의 수치 표현입니다. 어떤 용어를 쓰더라도 핵심 질문은 같습니다. 무엇을 저장하고, 언제 읽어야 할까요?

컨텍스트 윈도우는 지금 작업할 정보를 펼쳐 놓는 공간입니다

컨텍스트 윈도우에는 이번 요청에서 모델이 사용할 수 있는 정보가 담깁니다. 고객의 최신 메시지, 관련 문의 내역, 환불 정책을 넣으면 모델이 이를 함께 살펴볼 수 있습니다. 이전에 고객에게 했던 약속을 빼면 그 약속을 지킬 만한 확실한 근거도 없어집니다.

기록 보관실 안의 책상을 떠올리면 이해하기 쉽습니다. 책상이 아무리 커도 선반의 문서는 책상 밖에 있습니다. 큰 책상은 작업 공간을 넓혀 줄 뿐, 어떤 기록을 올릴지는 여전히 누군가가 정해야 합니다.

운영 비용은 반복되는 텍스트까지 포함해 모델에 제공하는 내용에 따라 발생합니다. 따라서 이번 판단에 필요한 근거만 담은 프롬프트가 유용한 최적화입니다. 정확성이 중요하다면 식별자, 제약 조건, 툴 결과를 그대로 남겨야 합니다. 주문 ID를 빠뜨린 짧은 요약은 오히려 손해입니다.

세션 상태는 같은 작업을 계속 이어 갈 수 있게 합니다

세션 상태는 “이 작업을 어디까지 처리했는가?”에 답합니다. 환불 에이전트라면 문의 ID, 대화 이력, 승인 상태, 환불 요청이 제출됐는지 보여 주는 툴 결과 등이 여기에 들어갑니다. Google의 Sessions 문서는 대화 이벤트와 해당 상호작용 안에서 쓰이는 임시 상태를 구분합니다.

대화 내용을 저장하는 것도 유용하지만, 에이전트를 실행하는 앱은 업무 진행 상태를 구조화된 레코드로 따로 저장해야 합니다. 실제로 돈이 이동했는지는 결제 시스템이 판단해야 합니다. 대화의 표현만 보고 모델이 이를 추론하게 하면 피할 수 있는 중복 처리 위험이 생깁니다.

문제가 “연결이 끊기면 에이전트가 어디까지 했는지 잊는다”라면 세션 상태부터 도입합니다. 재시작 후에도 상태가 남는지는 저장 위치에 달려 있습니다. 워커 프로세스 안의 변수는 프로세스가 종료되면 사라집니다. 반면 영구 저장소에 둔 상태는 다음 워커가 불러올 수 있습니다.

장기 저장소는 필요한 지식을 이후 작업으로 전달합니다

장기 저장소는 “새 작업을 시작할 때 이 에이전트가 무엇을 알고 있어야 하는가?”에 답합니다. 재방문 고객은 전화보다 이메일을 선호할 수 있습니다. 프로젝트에는 특정 연동을 거절한 이유를 설명하는 결정 사항이 있을 수 있습니다. 이런 사실은 대화가 끝난 뒤에도 남겨 둘 가치가 있습니다.

저장소는 고객 ID로 조회하는 단순한 레코드여도 됩니다. “이 고객사는 지난번에 무엇을 문제 삼았는가?”처럼 질문을 예측하기 어려울 때 의미 기반 검색이 유용해집니다. 이미 정해진 언어 선호도를 가져오는 데까지 그런 장치가 필요한 것은 아닙니다.

업무 기록은 계속 공식 근거로 삼아야 합니다. “이메일을 선호한다”는 기억해 둔 선호도일 수 있습니다. 하지만 판단에 “청구서 대금을 납부했다”는 사실이 필요하다면 청구 시스템에서 확인해야 합니다. 메모리는 관련 기록을 찾도록 안내할 수 있지만, 그 기록을 대신해서는 안 됩니다.

파일과 스킬은 지침과 교훈을 남깁니다

반복되는 문제가 “코딩 에이전트가 우리 프로젝트의 규칙을 잊는다”라면 파일만으로도 충분한 경우가 많습니다. Anthropic의 Claude Code 문서에서 CLAUDE.md는 명시적인 지침을, 지원되는 AGENTS.md 파일은 저장소 지침을 제공합니다. 자동 메모리에는 에이전트가 수정 사항과 선호도를 바탕으로 작성한 메모가 담깁니다.

스킬은 재사용할 수 있는 절차이며, 보통 지침 파일과 보조 자료로 구성됩니다. “릴리스를 준비하는 방법”은 스킬에 적합합니다. “고객이 배송 선호도를 바꿨다”는 고객 상태에 속합니다. 과거 실패를 설명하는 메모는 일반적인 교훈인지 특정 고객에 관한 사실인지에 따라 어느 쪽에도 도움이 될 수 있습니다.

Claude Code는 스킬을 사용할 때 본문을 불러옵니다. 사용 가능한 스킬의 이름과 설명은 목록 공간을 차지합니다. 그래서 파일 저장 비용이 저렴하더라도 파일을 활용하는 데는 운영 비용이 듭니다. 자세한 내용은 Claude Code 스킬의 컨텍스트 비용을 줄이는 방법에서 확인할 수 있습니다.

항상 적용할 지침은 짧게 유지하고, 가끔 쓰는 절차는 스킬로 옮깁니다. 문서에 적힌 지침은 모델을 안내하는 역할을 한다는 점도 기억해야 합니다. 권한과 금지된 동작은 앱의 제어 장치로 강제해야 합니다.

에이전트 메모리가 있어도 프롬프트는 매번 구성해야 합니다

영구 저장소는 필요한 정보가 다음 요청에 들어갈 때에만 도움이 됩니다. 모든 것을 저장하고 전부 다시 불러오면, 영속성을 확보한 대가로 비싼 대화 이력 재처리를 하게 됩니다.

무엇을 저장할지와 무엇을 읽을지를 따로 설계합니다

쓰기 경로는 어떤 정보가 다음에 사용할 메모리가 될지 결정합니다. 고객 지원 대화가 끝난 뒤 확정된 연락 방식과 출처를 저장하되, 일시적인 불만은 문의 이력에만 남길 수 있습니다. 앱이 구조화된 필드에 직접 기록할 수도 있고, 추출 모델이 대화에서 저장 후보가 될 사실을 뽑을 수도 있습니다.

읽기 경로는 현재 작업에 필요한 정보를 결정합니다. 고객을 인증하고 적절한 범위를 정한 다음, 필요한 사실을 검색합니다. 만료됐거나 새 기록으로 대체된 항목은 제외하고 선별한 내용을 프롬프트에 넣습니다. 답변이 잘못됐을 때 원인을 추적할 수 있도록 어떤 메모리를 사용했는지도 기록합니다.

Google의 Memory Bank 개요는 대화에서 메모리를 생성하고 검색된 메모리를 프롬프트에 넣는 방식을 설명합니다. 오래 보관하는 지식과 현재 작업의 컨텍스트는 여전히 별개입니다.

재방문 고객을 위한 프롬프트에는 오늘의 문의, 선호하는 연락 방식, 현재 정책이 들어갈 수 있습니다. 그 선호도를 알게 된 모든 대화까지 필요한 경우는 드뭅니다. 직접 데이터베이스를 운영하든 관리형 서비스를 구매하든, 어떤 정보를 고를지가 설계의 핵심입니다.

메모리의 내용 분류와 저장 위치는 다른 문제입니다

일화 기억은 과거 사건, 의미 기억은 사실, 절차 기억은 어떤 일을 수행하는 방법을 뜻합니다. 이런 내용 분류는 유용할 수 있지만, 같은 사건도 데이터베이스 행, 텍스트 메모, 대화 기록 등 여러 곳에 저장할 수 있습니다.

검색 증강 생성, 즉 RAG는 모델이 답하기 전에 관련 자료를 찾아 제공하는 방식입니다. 정책 문서를 조회할 때도, 기억해 둔 선호도를 조회할 때도 검색을 사용할 수 있습니다. 메모리를 운영하려면 여기에 무엇을 보관하고 갱신하고 지울지에 대한 결정이 더 필요합니다. RAG도 바뀌는 출처를 활용할 수 있으며, 본질적으로 정적인 문서 모음만을 뜻하지는 않습니다.

메모리는 모델의 내부 매개변수를 바꾸는 학습과도 다릅니다. 저장된 메모를 읽으면 모델이 현재 작업에 쓸 정보를 얻습니다. 그렇다고 기본 모델이 그 내용을 영구적으로 학습했다는 뜻은 아닙니다.

주요 제공업체는 어떤 메모리 기능을 제공하나요?

제공업체의 기본 서비스로도 상당 부분의 저장 작업을 처리할 수 있지만, 지원 범위는 서로 다릅니다. 아래 기능과 가격은 2026년 10월 5일 각 제공업체의 공개 문서와 가격 페이지를 기준으로 확인했습니다.

따라서 구현을 시작할 때는 이미 쓰고 있는 실행 환경의 대화·메모리 서비스부터 살펴보는 것이 좋습니다. 검색, 이식성, 수정, 제어에 관한 구체적인 요구를 기존 서비스가 충족하지 못할 때 별도 업체를 검토합니다.

Claude 메모리: 앱 기능, 세션, 저장소를 구분해야 합니다

Anthropic의 Claude는 사용자용 앱의 메모리와, 개발자가 Claude Managed Agents에서 사용하는 별도의 저장 기능을 제공합니다. Claude 앱의 메모리는 대화 중 개별 주제를 저장하며, 프로젝트에는 별도의 메모리 공간과 요약이 있습니다. 현재 도움말 페이지에 따르면 Free, Pro, Max에서는 메모리가 기본으로 켜져 있고, Team과 Enterprise에서는 소유자가 사용 여부를 제어합니다. 이 앱 기능만으로 개발 중인 앱의 고객 상태 저장 구조까지 설명할 수는 없습니다.

Managed Agents의 세션은 상호작용이 이어져도 이력을 유지합니다. 이후 세션에서도 사용할 지식은 메모리 저장소를 연결해 보관합니다. 저장소는 에이전트가 /mnt/memory/에서 읽고 쓰는 텍스트 문서 모음이며, 세션을 생성할 때 연결합니다. 세션당 8개 저장소, 저장소당 10,000개 메모리를 지원합니다. 저장소가 가득 차면 새 메모리를 쓰는 작업은 실패하지만 기존 메모리는 계속 읽고 수정할 수 있습니다. 공유 참조 저장소는 read_only로 설정할 수 있습니다. 이는 문서에 명시된 저장소 한도이므로, 데이터가 늘어나 쓰기 작업이 실패하기 전에 저장소를 나누고 불필요한 항목을 정리해야 합니다.

Claude 가격 페이지에는 활성 세션 실행 시간당 $0.08에 표준 토큰 요율이 추가된다고 나옵니다. 메모리 저장소에 대한 별도 저장 요율은 기재돼 있지 않습니다. 상세 가격 문서에 따르면 실행 시간은 running 상태에서 누적되며, idle, rescheduling, terminated 상태의 시간은 제외됩니다.

따라서 세션이 존재하는 시간보다 에이전트가 실제로 작업하는 시간을 기준으로 예산을 잡아야 합니다. 영구 저장된 파일을 모델에 무료로 입력할 수 있다고 생각하거나, 연결된 저장소가 어떤 문서에 주목할지 자동으로 판단한다고 가정해서는 안 됩니다.

OpenAI 대화 상태: 대화가 저장돼도 컨텍스트 처리 비용은 발생합니다

OpenAI의 Conversations API는 Responses API에 영구적인 대화 스레드를 제공합니다. Responses API는 모델 응답과 툴 상호작용을 생성합니다. 대화 ID는 여러 세션, 기기, 작업에서 재사용할 수 있으며, 대화에는 메시지, 툴 호출, 툴 출력이 담길 수 있습니다. 다른 방법으로는 previous_response_id를 사용해 응답을 연결할 수 있습니다. 대화 상태 가이드에 따르면 응답 체인의 이전 입력에도 계속 요금이 부과됩니다. 또한 기본적으로 30일 동안 저장되는 응답 객체와, 그 30일 만료가 적용되지 않는 대화 객체·항목을 구분합니다.

영구 대화 스레드는 작업의 연속성을 유지합니다. 하지만 서로 관련 없는 다음 대화에서 어떤 사실을 활용할지 결정하는 일은 여전히 앱의 몫입니다. 고객과 대화 ID를 연결한 정보도 영구적으로 저장해야 합니다. 다음 워커가 올바른 ID를 찾지 못하면 저장된 스레드도 도움이 되기 어렵습니다.

OpenAI 가격 페이지는 Responses API에 모델 사용료와 별개의 요금을 부과하지 않는다고 명시하며, Conversations에 대한 별도 요율도 기재하지 않습니다. 대표적인 예로 GPT-6.1 Sol의 짧은 컨텍스트 표준 요율은 입력 토큰 100만 개당 $2, 출력 토큰 100만 개당 $10입니다. 모델, 처리 방식, 컨텍스트 길이, 툴에 따라 청구액이 달라집니다.

앱이 무엇을 영구적으로 저장해야 할지 정한 다음, 대화 저장을 넘어 실행 환경을 선택하려면 OpenAI Agents API와 Agents SDK 비교를 참고합니다.

Google Sessions와 Memory Bank: 대화 상태와 장기 보관할 사실을 분리합니다

Google의 Gemini Enterprise Agent Platform은 Sessions와 Memory Bank를 구분합니다. Sessions는 상호작용 이력과 대화 상태를 보관합니다. Memory Bank는 이후 세션에서 쓸 사실을 생성하고 관리하며, 범위, 만료, 변경 이력을 지원합니다.

Google의 검색 문서에 따르면 메모리의 범위는 요청의 범위와 정확히 일치해야 합니다. 범위는 메모리에 부여한 식별 정보와 그룹 구분이며, 생성 후에는 바꿀 수 없습니다. 올바른 식별 정보를 전달하고 누가 사용할 수 있는지 강제하는 책임은 여전히 개발자에게 있습니다.

현재 가격 페이지에는 Sessions와 Memory Bank의 저장 비용이 GiB·월당 $0.30으로 나옵니다. Memory Bank의 변경 이력도 저장 용량에 포함됩니다. 읽기는 300만 회당 $0.085, 쓰기는 100만 회당 $0.085이며, Agent Compute를 통해 사용량에 비례해 과금됩니다. 메모리 생성과 임베딩 토큰은 별도입니다. 이 가격 체계는 2026년 9월 1일부터 적용됩니다.

개발자에게는 단순히 대화 로그를 담아 두는 공간을 넘어, 메모리의 생성부터 만료까지 관리하는 호스팅 서비스입니다. 운영자는 생성 토큰과 변경 이력 보관도 예산에 넣어야 합니다. Google 실행 환경의 “Agent Memory (RAM)” 항목은 컴퓨터의 작업용 메모리를 뜻하며, 기억해 둔 고객 정보와는 다른 자원입니다.

에이전트 메모리 운영 비용은 어떻게 계산하나요?

비용을 절감한다고 판단하기 전에 쓰기와 읽기의 전체 과정을 계산해야 합니다. 메모리는 반복 입력을 줄일 수 있지만 추출, 검색, 유지 관리 비용을 추가합니다. 저장 공간이 저렴하다는 이유만으로 비교가 끝나지는 않습니다.

비용은 다음과 같이 계산하면 유용합니다.

월간 메모리 비용 = 추출·갱신 + 저장 + 검색 + 검색 결과 입력 토큰 + 추가 실행 시간 + 운영 업무.

운영 업무에는 수정, 보관 기간 변경, 쓰기 실패 대응, 문제 조사 등이 들어갑니다. 업체 청구서에 없더라도 추적해야 합니다. 임의의 시간당 요금을 만들어 끼워 넣지 말고, 실제 인건비와 장애 대응 비용을 사용합니다.

월간 예산 예시로 비용이 역전되는 지점을 계산합니다

커스텀 에이전트가 이전 이력을 활용하는 작업을 월 10,000회 처리한다고 가정합니다. 현재는 매번 과거 입력 토큰 10,000개를 다시 처리합니다. 정보를 선별하는 설계에서는 실행당 기억해 둔 토큰 1,000개를 제공하고, 매 실행 후 메모리 추출에 입력 토큰 2,000개와 출력 토큰 200개를 사용합니다.

이는 계산을 위한 워크로드 가정이며 측정된 성능이 아닙니다. Claude Sonnet 5.5의 표준 요율은 입력 토큰 100만 개당 $2, 출력 토큰 100만 개당 $10입니다.

• 이력 재처리: 10,000회 × 10,000토큰 = 입력 토큰 1억 개로, 월 $200입니다.
• 선별한 컨텍스트: 10,000 × 1,000 = 입력 토큰 1,000만 개로, 월 $20입니다.
• 추출: 입력 토큰 2,000만 개는 $40, 출력 토큰 200만 개는 $20입니다. 합계는 월 $60입니다.

선별 설계의 비용은 나머지 비용을 더하기 전 월 $80부터 시작합니다. 따라서 이력 재처리 기준 비용인 월 $200을 넘기 전까지 추가 저장, 검색, 실행 시간, 재시도, 유지 관리에 쓸 수 있는 금액은 월 $120입니다. 두 방식 모두 공통으로 드는 기본 작업과 답변 생성 비용은 제외했습니다.

계산해야 할 손익분기점은 여기에 있습니다. 줄어든 이력 재처리 비용이 메모리로 인해 추가되는 전체 비용보다 커야 합니다. 추출 과정에서 원래 대화 전체를 읽어야 한다면, 가정한 추출 입력량을 실제 양으로 바꿉니다. 가끔 생기는 변경 사항만 새 메모리로 저장하면 된다면 그에 맞는 낮은 쓰기 빈도로 계산합니다.

캐시 요율의 출처는 Anthropic 가격 문서입니다. 캐시는 반복 처리 비용을 줄일 수 있습니다. 하지만 기억해 둔 사실이 최신인지, 이 사용자에게 속하는지는 판단하지 않습니다.

활성 실행 시간과 저장 비용은 별도로 계산합니다

Claude Managed Agents 실행 10,000회가 각각 활성 시간 6분을 사용한다고 가정합니다. 토큰과 그 밖의 해당 사용료를 제외한 실행 비용은 1,000세션·시간 × $0.08 = 월 $80입니다. 이 계산에는 공개된 실행 시간 요율을 사용했습니다. 여섯 분은 가정한 활성 시간이며 관측된 벤치마크가 아닙니다. 같은 실행 환경을 사용하는 메모리 설계를 비교할 때는 추가로 발생한 실행 시간만 더합니다.

Google의 현재 과금 기준으로, 무료 제공량을 소진한 뒤 과금 대상 저장량 10GiB·월, 과금 대상 읽기 300만 회, 과금 대상 쓰기 100만 회를 사용한다고 가정합니다. 저장과 처리 비용의 소계는 $3.00 + $0.085 + $0.085 = 월 $3.17입니다. 메모리 생성 토큰, 임베딩, 에이전트 추론, 실행 시간은 제외합니다. Google의 가격 페이지에는 계정당 월 무료 제공량으로 저장량 1GiB·월과 Agent Compute 50시간이 포함돼 있습니다. 이 예시는 무료 제공량을 이미 모두 사용했다고 가정합니다. GiB는 대략 10억 바이트에 해당하는 이진 저장 단위입니다.

이 계산만으로 어느 제공업체의 메모리 서비스 전체가 더 저렴하다고 판단할 수는 없습니다. 각 청구 항목이 측정하는 작업이 다르기 때문입니다. 에이전트가 얼마나 자주 읽고 쓰는지, 사실을 다시 생성하는지, 컨텍스트에 불러오는지까지 포함해 실제로 운영할 워크플로의 비용을 계산합니다.

에이전트 메모리 관리: 자주 생기는 문제와 해결 방법

실서비스에서 부딪히는 핵심 과제는 어떤 사실을 신뢰할 수 있는 컨텍스트로 받아들일지 제어하는 일입니다. 저장소는 유용한 지식을 보관하는 것만큼이나 잘못된 사실을 보관하고, 다른 고객의 기록을 반환하고, 악의적인 지침을 오래 남길 수도 있습니다.

오래된 사실: 출처와 유효 기간을 남기고 다시 확인합니다

고객의 청구 담당자가 바뀌었는데 에이전트가 계속 이전 담당자의 정보를 쓴다고 가정해 보겠습니다. 새 메시지만 저장하고 이전 메모리를 대체하지 않으면, 유효해 보이는 답이 두 개 남습니다.

해결하려면 정보가 누구에게 속하는지, 출처가 무엇인지, 언제 관찰됐는지, 언제 유효하거나 만료되는지를 저장해야 합니다. 수정 사항은 특정 레코드에 반영합니다. 대체된 사실은 비활성화하고, 어느 버전이 질문과 더 비슷해 보이는지 검색이 결정하도록 두지 않습니다. **TTL(time to live)**이라고도 하는 만료 시간은 사실을 사용할 수 있는 기간을 제한하지만, 그 전에 일어나는 모든 변화를 감지하지는 못합니다.

현재 계정 상태, 재고, 가격, 접근 권한이 필요하다면 실제 동작 시점에 그 값을 관리하는 시스템을 조회합니다. 메모리는 과거의 결정과 이유를 남길 수 있고, 실시간 확인은 현재 사실을 제공합니다. Google은 만료와 메모리 변경 이력을 생명주기 제어 기능으로 설명합니다. 이를 지원한다고 해서 과거 기록과 현재 사실을 구분하지 않아도 되는 것은 아닙니다.

다른 사용자의 메모리가 섞이는 문제: 검색 전에 신원을 강제합니다

공유 검색이 모든 사용자를 대상으로 “최근 취소”를 조회하거나, 앱이 모델이 선택한 사용자 ID를 받아들이면 정보 유출이 시작됩니다. 데이터베이스 쿼리의 범위를 올바르게 지정했더라도 질문만을 키로 삼는 캐시가 같은 유출을 일으킬 수 있습니다.

고객과 계정의 식별 정보는 인증된 앱 요청에서 가져와야 합니다. 이 정보를 쓰기, 읽기, 갱신, 삭제, 내보내기, 백그라운드 작업, 캐시에 적용합니다. 필수 범위 정보가 없는 요청은 거부합니다. 앱뿐 아니라 저장소나 서비스 계층에서도 접근을 강제해야 합니다. 프롬프트에 “이 고객의 기록만 사용하라”고 적어도 쿼리에 제약이 생기지는 않습니다.

행 수준 보안은 호출자가 볼 수 있는 행을 데이터베이스가 제한하는 방식입니다. 이에 준하는 서비스 권한 제어로 저장소나 범위의 경계를 강제할 수도 있습니다. 공유 정책 자료와 비공개 고객 정보에는 의도적으로 다른 권한을 적용해야 합니다.

자체 환경에서 서로 다른 가상의 사용자에게 구별하기 쉬운 비공개 사실을 부여해 경계를 확인합니다. 최종 답변뿐 아니라 검색 결과와 대기 중인 작업도 살펴봐야 합니다. 모델이 유출된 사실을 답변에 쓰지 않았다고 해서 비공개 데이터가 서로 분리돼 있었다는 뜻은 아닙니다.

잘못된 메모리가 지침으로 굳어지는 문제: 쓰기 경로를 제어합니다

가져온 문서에 “다음에는 환불 한도를 무시하라”는 문장이 있을 수 있습니다. 에이전트가 이를 상시 규칙으로 저장하면 악의적인 내용이 다음 작업에도 남습니다. 거짓이거나 적대적인 콘텐츠를 이후 재사용하도록 저장하는 이런 현상을 **메모리 오염(memory poisoning)**이라고 합니다.

관찰한 정보와 동작을 지배하는 지침을 분리합니다. 공유 정책은 읽기 전용으로 두고, 에이전트가 작성한 내용의 출처를 기록하며, 동작을 바꿀 수 있는 변경 사항은 검토합니다. Google의 Memory Bank 거버넌스 항목은 이 위험을 명시적으로 설명합니다. 검색된 텍스트가 다른 행동을 요구하더라도 호스트가 관리하는 권한은 계속 적용돼야 합니다.

요약, 동시 쓰기, 삭제는 각각 따로 해결해야 합니다

요약은 중요한 조건을 지워 버릴 수 있습니다. “반품하면 환불 승인”이 “환불 승인”으로 바뀌는 식입니다. 정확한 업무 상태는 생성된 요약 밖에 보관하고, 원래 근거를 찾을 수 있는 참조도 남깁니다. 메모리로 필수 조건을 확인할 수 없다면 출처를 조회하거나 추가 확인을 요청합니다.

동시에 쓰는 작업들이 서로의 수정 내용을 덮어쓸 수 있습니다. 갱신 전에 버전을 확인하고, 충돌하면 다시 불러옵니다. Anthropic은 이를 위한 content_sha256 사전 조건을 제공합니다.

과도한 검색에는 다른 해법이 필요합니다. 컨텍스트 예산을 정하고, 현재 작업에 적용할 수 있으며 사용 권한이 있는 사실을 우선합니다. 가져오는 텍스트가 늘면 토큰이 늘고 모순도 함께 남을 수 있습니다. 정확한 필드 값은 정확한 키로 조회하고, 넓은 범위의 검색은 실제로 필요할 때 도입합니다.

삭제는 파생 데이터까지 따라가야 합니다. 보관 정책에 맞춰 관련 요약, 검색 항목, 캐시, 보관된 이력을 삭제하거나 무효화합니다. Anthropic의 메모리 버전 문서에 따르면 현재 메모리를 삭제해도 보관된 버전은 삭제되지 않습니다. 과거 콘텐츠는 별도의 제거 경로로 처리해야 합니다.

어떤 에이전트 메모리 시스템이 필요한가요?

어떤 정보가 어떤 경계를 넘어 남아 있어야 하는지 명확할 때 도입합니다. 기억이 끊길 때마다 새 서비스를 구매하지 않아도 작업의 연속성을 개선할 수 있습니다.

개발자는 끝나지 않은 작업의 진행 상태를 잃는다면 영구 세션 기록부터 시작합니다. 이후 세션에서 정해진 선호도가 필요하다면 사용자별 작은 레코드를 추가합니다. 알고 있는 키만으로 필요한 사실을 안정적으로 고를 수 없을 때 의미 기반 검색을 도입합니다. 프로젝트 지침과 절차가 반복적으로 필요하다면 파일과 스킬이 가장 직접적인 해법입니다.

운영자는 상태 손실 때문에 작업이 반복되거나, 오래된 답변이 나오거나, 같은 동작이 중복 실행된다면 바로 대응해야 합니다. 수정 사항과 함께 불러온 토큰, 쓰기 빈도, 검색 결과를 기록합니다. 만료와 삭제의 담당자가 없다면 장기 메모리 자동 추출은 미루고, 먼저 어떤 사실을 남겨야 하는지 정합니다.

구매 담당자는 상태가 어디에 저장되는지, 어떻게 확인하고 수정하는지, 어떤 경계를 넘어 유지되는지, 접근을 어떻게 강제하는지 업체에 물어야 합니다. 관리형 제품은 팀이 직접 맡아야 할 생명주기 관리 업무를 줄여 줄 때 유용합니다. 이식성, 삭제, 실제 워크로드의 청구액을 기준으로 구매를 결정해야 합니다.

상태를 저장하지 않는 작업이 매번 필요한 최신 입력을 모두 받고, 이후 작업에서 과거 이력이 필요하지 않다면 메모리 도입의 영향을 받지 않습니다. 감사 로그를 남기는 일은 여전히 유용할 수 있지만, 그 로그를 다음 프롬프트에 자동으로 넣을 필요는 없습니다.

작은 해법으로 충족할 수 없는 구체적인 요구가 생기면 선택을 바꿉니다. 고객 선호도 필드는 긴 이력에서 관련 사건을 찾아야 할 때 한계에 도달합니다. 세션 대화 기록은 새 요청마다 무관한 과거 작업을 훑어야 할 때 한계가 드러납니다. 운영 절차서는 필요한 지식이 고정된 절차가 아니라 계속 바뀌는 고객 상태일 때 충분하지 않습니다.

AI 에이전트 메모리 툴: Mem0, Zep, Letta는 어디에 쓰나요?

Mem0는 전달받은 메시지에서 사실을 추출하고, 지정한 사용자의 메모리를 검색하는 연동 솔루션입니다. 빠른 시작 문서는 add에 user_id를 지정하고, 일치하는 필터로 검색한 다음, 반환된 메모리를 모델에 전달하는 과정을 보여 줍니다. 마지막 단계가 연동의 핵심 경계입니다. 저장된 사실도 답변하는 에이전트에 실제로 전달해야 합니다.

이 설명은 구조를 이해하는 데 사용하면 됩니다. Mem0가 해당 워크로드에 가장 적합한 제품이라는 근거는 아닙니다.

Zep은 시간에 따른 사실, 관계, 출처를 연결한 네트워크인 Context Graph를 구성합니다. Zep 문서는 사실이 유효해지거나 무효해지는 시각을 기록한다고 설명합니다. 또한 출처를 추적할 수 있어도 정확성이 보장되는 것은 아니라고 명시합니다. 계속 바뀌는 고객사 관계는 이런 구조를 활용할 수 있는 사례이지만, 출처 자체가 신뢰할 만해야 합니다.

그래프는 정보가 어떻게 연결되는지를 나타냅니다. 호출자가 어떤 기록에 접근할 수 있는지 정하는 개발자의 책임까지 없애 주지는 않습니다.

Letta는 에이전트의 프롬프트 앞에 붙는 지속적인 영역인 메모리 블록을 제공합니다. 메모리 블록 문서에 따르면 블록은 검색 없이 항상 보이며, 읽기 전용으로 설정할 수 있습니다. 안정적인 작업용 프로필은 이 방식에 적합할 수 있습니다. 다만 항상 보이는 내용은 컨텍스트를 차지하므로 블록에는 필요한 내용만 담아야 합니다.

제품 추천, 배포 방식, 요금제 비교는 2026년 AI 에이전트용 영구 메모리 시스템 추천에서 확인할 수 있습니다. 이 글에서 필요한 구성 요소를 정한 다음, 그 요구를 기준으로 툴을 비교합니다.

에이전트 메모리, 어떤 약속이 과장됐을까요?

“에이전트가 모든 것을 기억한다”는 제품의 약속만으로는 충분하지 않습니다. 중요한 질문은 사실이 저장 후에도 남는지, 올바른 작업에 반환되는지, 사용할 때도 정확하고 권한에 맞는지입니다.

컨텍스트 윈도우가 커지면 더 많은 자료를 제시할 수 있습니다. 하지만 올바른 고객 기록을 골라 주지는 않습니다. 벡터 저장소는 의미를 기준으로 검색하지만, 예전 선호도가 철회됐는지 본래부터 판단하는 기능은 아닙니다. 에이전트가 작성한 메모는 어떤 주장을 남기지만, 그 주장을 입증하지는 않습니다.

자동 쓰기가 늘면 운영 업무도 늘 수 있습니다. 모든 불만을 지속적인 선호도로 저장하면 에이전트에 왜곡된 고객 프로필이 남습니다. 추출을 반복하는 비용이 구조화된 필드를 조회하는 비용보다 클 수도 있습니다. 짧고, 확인할 수 있고, 정확한 사실을 모아 두는 편이 검색할 수 있는 방대한 이력보다 유용할 수 있습니다.

더 설득력 있는 구매 근거는 구체적입니다. 제품이 필요한 저장·검색 생명주기를 처리하고, 그 제어 방식과 비용을 설명할 수 있어야 합니다. 절약되는 운영 업무의 가치가 충분하다면 그 결과를 구매합니다.

다음 업무에서 할 일: 반복되는 기억 누락 하나부터 해결합니다

반복되는 워크플로 하나를 골라 다음 실행에 정확히 무엇이 필요한지 적습니다. 고객 지원 에이전트라면 끝나지 않은 문의, 재방문 고객이 선호하는 연락 방식, 환불 처리 절차부터 시작합니다.

1. 1

   정보별로 저장 위치를 정합니다

   문의 진행 상황은 세션 상태와 업무 상태에, 확인된 연락 방식은 사용자별 레코드에, 환불 절차는 지침 파일이나 스킬에 둡니다. 현재 결제 상태는 결제 시스템에 남깁니다.

2. 2

   누가 읽고 바꿀 수 있는지 정합니다

   에이전트를 실행하는 앱에서 신원을 확인하고, 모든 동작과 캐시에 범위 제한을 강제합니다. 일반 작업 세션에서는 공유 절차를 읽기 전용으로 둡니다.

3. 3

   저장과 함께 수정·삭제 경로도 만듭니다

   출처와 유효성을 기록합니다. 운영자가 수정할 특정 레코드를 찾을 수 있게 하고, 파생된 사본과 보관된 버전까지 처리하는 삭제 경로를 제공합니다.

4. 4

   정보의 경계와 비용을 측정합니다

   자체 환경에서 재시작 후 작업이 이어지는지, 바뀐 사실이 반영되는지, 사용자별 정보가 분리되는지 확인합니다. 모델 토큰, 쓰기, 읽기, 활성 실행 시간, 수정 업무를 기록합니다. 구체적인 요구가 이 작은 설계의 한계를 넘을 때 메모리 인프라를 추가로 구매합니다.

에이전트 메모리에는 어떤 유형이 있나요?

실서비스 설계에서는 컨텍스트 윈도우, 세션 상태, 장기 저장소, 파일·스킬을 구분합니다. 일화 기억, 의미 기억, 절차 기억은 각각 과거 사건, 사실, 지침이라는 내용 분류입니다. 특정 데이터베이스나 업체를 정해 주는 분류는 아닙니다.

에이전트 메모리에서 스킬은 어떤 역할을 하나요?

스킬은 에이전트가 읽고 적용할 수 있는 재사용 절차입니다. 여러 세션에 걸쳐 방법을 유지할 수 있습니다. 고객에 관한 사실을 파악하고 갱신하려면 별도의 쓰기·읽기 생명주기가 필요합니다.

AI 에이전트 메모리는 어떻게 구성하나요?

유용한 정보를 저장하는 쓰기 경로와, 모델 요청에 넣을 최신 정보 중 사용 권한이 있는 내용을 고르는 읽기 경로를 결합합니다. 영구 저장, 식별 정보, 수정, 만료, 컨텍스트 예산이 모두 이 구조에 포함됩니다.

에이전트 메모리의 실제 예시는 무엇인가요?

끝나지 않은 환불 문의에는 세션 상태가 필요합니다. 재방문 고객의 확인된 언어 선호도에는 영구 레코드가 필요합니다. 환불 운영 절차는 스킬이나 지침 파일에 둡니다. 각각의 정보는 현재 요청에서 필요할 때 컨텍스트 윈도우에 들어갑니다.

에이전트 개발과 운영에 관한 실용적인 가이드를 더 받아 보려면 뉴스레터를 구독하세요.