AI 에이전트 메모리 유형별 비용 및 저장 전략

에이전트 메모리 유형 3가지

에이전트 메모리 유형은 세 가지로 나뉘며, 각 유형은 비용을 지불하는 하드웨어 자원을 서로 다르게 점유합니다. 의미 기억(semantic memory)은 사실 관계를, 일화 기억(episodic memory)은 발생한 사건을, 절차 기억(procedural memory)은 작업을 수행하는 방법을 저장합니다. 아래 표는 각 유형을 서버 예시와 함께 정의합니다. 그 뒤에 이어지는 내용은 보통 문서화되지 않는 부분으로, 각 유형을 저장하는 데 드는 비용과 재구축 비용에 관한 것입니다.

[
  {
    "label": "Semantic",
    "what_it_holds": "Facts the agent should treat as currently true",
    "server_example": "The database listens on 10.8.0.4:5432 and the nightly dump runs at 03:15 UTC"
  },
  {
    "label": "Episodic",
    "what_it_holds": "A record of one past event or session",
    "server_example": "On 2026-08-11 the deploy failed because the disk was full, and rotating logs fixed it"
  },
  {
    "label": "Procedural",
    "what_it_holds": "How to carry out a task, as steps the agent can run",
    "server_example": "The restore runbook: stop the service, load the dump, run migrations, start the service"
  }
]

이 명칭들은 인간 심리학에서 차용되었으며 그 의미는 다소 느슨하게 적용됩니다. 이 분류가 유용한 실질적인 이유는 세 가지 유형의 크기와 복구 경로가 서로 다르기 때문입니다. 따라서 이들을 모두 하나의 벡터 저장소(vector store)에 넣으면 각 유형의 효율성이 모두 떨어지게 됩니다.

의미 기억은 용량이 작으므로 직접 편집하는 것이 좋습니다

서버에 관한 수백 개의 사실 정보는 수십 킬로바이트의 텍스트에 불과합니다. 여기서 문제는 저장 공간이 아니라 수정입니다. 의미 기억에 잘못된 사실이 저장되면 에이전트가 이후 내놓는 모든 답변이 틀리게 되므로, 저장소는 특정 사실을 이름으로 검색하여 수정하고 이전 값이 완전히 삭제되었음을 보장할 수 있어야 합니다.

이러한 요구 사항은 키 기반 저장소를 가리킵니다. 기본 키(primary key)를 가진 Postgres 테이블이나 git으로 관리되는 작은 markdown 파일 디렉터리가 적합합니다. 두 방식 모두 쿼리를 실행하여 값을 확인하고 즉시 수정할 수 있습니다. 유사도 검색(similarity search)은 키가 아닌 유사성을 기준으로 데이터를 가져오기 때문에 이러한 작업에 적합하지 않습니다. "데이터베이스 포트 변경"이라는 작업이 "데이터베이스 포트를 언급하는 모든 청크 찾기"로 변질되며, 모든 항목을 찾았는지 증명할 방법이 없기 때문입니다. 사실 정보는 키 기반으로 유지하십시오. 느슨한 회상(loose recall)이 필요하다면 임베딩을 병행할 수 있지만, 키 기반 복사본을 진실의 원천(source of truth)으로 삼아야 합니다.

오래된 사실은 스스로 갱신되지 않습니다. 포트가 변경되어도 행은 그대로 남아 있으므로, 에이전트는 6월에나 맞았던 번호를 계속 답변하게 됩니다. 에이전트 메모리를 위한 노후화 및 정리 정책은 이 페이지의 나머지 절반을 구성하며, 테이블이 작을 때 설계하는 것이 훨씬 비용 효율적입니다.

에피소드 메모리가 무한히 증가하는 이유

에피소드 메모리는 로그이며, 로그는 계속 증가합니다. 모든 세션, 모든 도구 호출, 실패한 모든 명령어가 에피소드 후보가 됩니다. 턴마다 한 행씩 기록하는 에이전트는 한 달이면 사람이 읽을 수 있는 양보다 훨씬 많은 행을 작성하게 됩니다. 디스크 비용뿐만 아니라, 임베딩된 모든 에피소드는 검색 시 탐색해야 하는 인덱스에 포함된다는 점도 문제입니다.

데이터베이스 테이블을 생성하는 날에 보존 규칙을 결정하십시오. 삭제 작업이 여전히 자유로울 때 정해야 합니다. 두 가지 질문으로 대부분의 문제를 해결할 수 있습니다. 첫째, 무엇을 기록할 가치가 있는가입니다. 세션 요약은 보통 가치가 있지만, ls -la의 전체 출력은 그렇지 않은 경우가 많습니다. 둘째, 각 에피소드 유형을 얼마나 오래 보관할 것인가입니다. 예를 들어 원시 에피소드는 30일, 세션 요약은 1년 동안 보관하는 식입니다.

모든 에피소드 행에 created_at 타임스탬프와 source 열을 추가하십시오. created_at가 없으면 기간에 따른 삭제가 불가능합니다. source가 없으면 특정 잘못된 출처에서 유입된 모든 데이터를 삭제할 수 없습니다. 이는 웹 페이지나 티켓이 메모리에 명령어를 작성하고 있다는 사실을 발견한 날에 반드시 필요한 기능입니다.

DELETE FROM episodes WHERE created_at < now() - interval '30 days';

systemd 타이머를 사용하여 이를 실행하고, 이후 행 개수와 테이블 크기가 실제로 변하는지 확인하십시오. 아무도 실행하지 않는 보존 정책은 주석에 불과합니다.

psql -d agentmem -c "SELECT count(*) FROM episodes;"
psql -d agentmem -c "SELECT pg_size_pretty(pg_total_relation_size('episodes'));"

절차적 기억은 저장소에 보관해야 합니다

절차적 기억은 에이전트가 작업을 수행하는 방식입니다. 셸 스크립트, 스킬 파일, 번호가 매겨진 단계로 구성된 런북 등이 이에 해당합니다. 이는 코드이며, 코드는 코드의 본거지인 git 저장소에 있어야 합니다. 그래야 코드 리뷰, 버전 관리, 그리고 읽을 수 있는 diff를 활용할 수 있습니다.

런북을 임베딩된 청크로 저장하면 근사치 복사본만 얻게 됩니다. 검색 결과는 점수가 가장 높은 청크를 반환하므로, 에이전트는 2단계와 5단계를 수행할 수 있지만 3단계는 나타나지 않을 수 있습니다. 또한 어떤 버전의 절차가 실행되었는지 기록되지 않습니다. git을 사용하면 git log가 이 두 가지 문제를 모두 해결합니다. 저장 비용은 거의 0에 가까우며, 이것이 바로 벡터 저장소 비용을 지불하지 말아야 할 또 다른 이유입니다.

임베딩의 실제 디스크 점유 비용

[
  {
    "label": "bge-small-en-v1.5 (384 dims)",
    "bytes_per_vector": 1544,
    "mib_per_100k_rows": 147.2
  },
  {
    "label": "bge-base-en-v1.5 (768 dims)",
    "bytes_per_vector": 3080,
    "mib_per_100k_rows": 293.7
  },
  {
    "label": "bge-large-en-v1.5 (1024 dims)",
    "bytes_per_vector": 4104,
    "mib_per_100k_rows": 391.4
  },
  {
    "label": "text-embedding-3-small (1536 dims)",
    "bytes_per_vector": 6152,
    "mib_per_100k_rows": 586.7
  },
  {
    "label": "text-embedding-3-large (3072 dims)",
    "bytes_per_vector": 12296,
    "mib_per_100k_rows": 1172.6
  }
]

pgvector는 vector을 차원당 4바이트와 8바이트 헤더로 저장합니다. 이 계산식은 고정되어 있으므로 데이터를 로드하기 전에 미리 용량을 계획할 수 있습니다. 384차원 벡터 하나는 1544 바이트이며, 100,000개의 청크는 147.2 MiB의 벡터 용량을 차지합니다. 동일한 말뭉치를 3,072차원으로 임베딩하면 행당 12296 바이트가 되어 1172.6 MiB가 됩니다. 같은 텍스트임에도 저장 공간은 거의 8배가 늘어납니다.

이는 벡터 컬럼만의 용량입니다. 청크 텍스트, 기본 키, 행 오버헤드, 그리고 인덱스가 추가로 필요하며, 많은 사용자가 인덱스 용량을 간과합니다. HNSW(pgvector가 생성하는 그래프 인덱스인 hierarchical navigable small world)는 연결된 벡터의 복사본을 별도로 유지하므로, 인덱싱된 저장소는 위에서 계산한 수치의 두 배를 훌쩍 넘기게 됩니다. 추측하지 말고 직접 측정하십시오.

SELECT pg_size_pretty(pg_total_relation_size('memories')) AS total,
       pg_size_pretty(pg_relation_size('memories_embedding_idx')) AS idx;

검색 속도는 RAM이 결정합니다. 그래프는 메모리에 있을 때만 빠르게 탐색할 수 있기 때문입니다. 인덱스 크기가 Postgres가 수용할 수 있는 메모리보다 커지면 검색 시 디스크 읽기가 발생하며 지연 시간이 증가합니다. 인덱스 생성 과정에는 maintenance_work_mem이라는 자체 제한이 있으며, 그래프가 이 크기를 초과하면 생성 속도가 느려지며 관련 메시지가 출력됩니다.

NOTICE:  hnsw graph no longer fits into maintenance_work_mem after 61440 tuples
HINT:  Increase maintenance_work_mem to speed up builds.

동일한 말뭉치의 용량을 줄이는 방법은 두 가지가 있습니다. 첫째, 더 작은 모델을 선택하십시오. 384차원은 1,536차원보다 비용이 4분의 1 수준이며, 개인적인 메모를 찾는 용도라면 정확도 차이는 대개 감수할 만한 수준입니다. 둘째, 반정밀도(half precision)로 저장하십시오. halfvec 타입은 차원당 2바이트와 동일한 8바이트 헤더를 사용하므로, 컬럼과 인덱스 전체 용량을 거의 절반으로 줄여줍니다.

모델을 선택하기 전에 알아두어야 할 제한 사항이 하나 있습니다. 2026년 8월 기준으로 vector 컬럼은 최대 2,000차원까지만 인덱싱할 수 있습니다. 따라서 3,072차원 임베딩은 컬럼에는 저장할 수 있지만 인덱스 생성은 거부됩니다.

ERROR:  column cannot have more than 2000 dimensions for hnsw index

halfvec은 최대 4,000차원까지 인덱싱할 수 있으므로, 일반적인 해결책은 캐스팅된 값을 인덱싱하는 것입니다.

CREATE INDEX ON memories USING hnsw ((embedding::halfvec(3072)) halfvec_cosine_ops);

pgvector가 별도의 메모리 서비스를 능가하는 경우

서버에서 이미 Postgres를 실행 중이라면, 벡터는 하나의 패키지와 하나의 문장으로 해결됩니다.

psql -V
sudo apt install postgresql-16-pgvector

CREATE EXTENSION vector;

패키지 이름에 포함된 숫자는 Postgres 메인 버전입니다. Ubuntu 24.04에서는 16이므로, 입력하기 전에 psql -V를 먼저 읽어 보십시오.

데이터베이스 내부에 메모리를 유지하면 메모리와 애플리케이션 데이터를 동시에 포함하는 단일 백업, 단일 커넥션 풀, 그리고 트랜잭션의 이점을 얻을 수 있습니다. 즉, 사실 정보와 이를 설명하는 행이 함께 커밋되거나 함께 실패합니다. 별도의 서비스는 이를 보장할 수 없습니다.

다음 중 하나에 해당한다면 전용 메모리 서비스로 이전하십시오. 검색 부하가 애플리케이션과 경쟁하여 별도의 장비가 필요한 경우, 여러 호스트의 여러 에이전트가 하나의 메모리를 공유해야 하는 경우, 또는 완성된 제품이 제공하는 추출 및 중복 제거 로직이 필요한 경우입니다. 이것이 바로 자체 호스팅 Mem0 메모리 서버를 사용하는 이유입니다. 단일 에이전트와 수백만 개 미만의 청크로 구성된 코퍼스라면, 이미 운영 중인 서버의 pgvector가 운영 부담도 적고 고장 날 확률도 낮습니다. 엔진 선택 자체와 각 엔진이 RAM에서 요구하는 사항은 VPS에서 벡터 데이터베이스 실행하기에서 다룹니다.

모델 변경 시 재임베딩 비용

서로 다른 모델에서 생성된 벡터는 비교할 수 없습니다. 따라서 새로운 모델로 새로운 메모리를 임베딩하면서 기존 행을 그대로 둘 수는 없습니다. 서로 다른 좌표계 사이에서 계산된 거리는 아무런 의미가 없는 숫자이므로, 혼합된 테이블은 무의미한 결과를 반환합니다. 모델을 변경한다는 것은 전체 코퍼스를 재임베딩해야 함을 의미합니다.

이 비용은 네 가지 부분으로 구성됩니다. 토큰 비용(API 요금 또는 자체 장비의 CPU 및 GPU 사용 시간), 작업이 실행되는 동안의 실제 소요 시간, 백필(backfill) 과정에서 두 컬럼을 동시에 유지하기 위한 디스크 공간, 그리고 마지막에 수행하는 인덱스 재구축 비용입니다. 안전한 작업 순서는 새로운 컬럼을 추가하고, 배치 단위로 백필을 수행한 뒤, 쿼리를 교체하고, 마지막으로 이전 컬럼과 해당 인덱스를 삭제하는 것입니다.

공개된 수치를 신뢰하기보다는 자체 하드웨어에서 속도를 직접 측정하십시오. 소규모 VPS에서 CPU만 사용하는 임베딩은 GPU에서 동일한 모델을 실행하는 것보다 훨씬 느리기 때문입니다. 대표적인 청크 하나를 측정하여 전체 코퍼스 크기만큼 곱하십시오.

ollama pull nomic-embed-text
time curl -s http://localhost:11434/api/embed \
  -d '{"model": "nomic-embed-text", "input": "one representative chunk of your corpus"}' > /dev/null

로컬 임베딩 모델은 메모리 저장소와 동일한 디스크에 가중치를 저장합니다. Ollama가 다운로드한 모델을 저장하는 위치에서 해당 공간이 어디에 할당되는지 확인할 수 있습니다.

이 모든 과정을 가능하게 하는 한 가지 필수 조건은 모든 벡터 옆에 원본 텍스트를 함께 보관하는 것입니다. 벡터만 저장된 저장소는 새로운 모델에 입력할 데이터가 남아 있지 않기 때문에 재임베딩이 불가능합니다. "어떤 텍스트가 이 행을 생성했는가"라는 질문에 답할 수 없다면, 마이그레이션 경로는 텍스트가 처음 생성된 곳부터 다시 전체를 구축하는 것뿐입니다.

메모리가 실행 중일 때 모니터링해야 할 사항

저장소가 채워짐에 따라 비용만 변하는 것이 아닙니다. 오래된 사실은 최신 상태를 유지하지 못하게 되고, 과거의 에피소드들이 유용한 결과를 밀어내는데, 이는 다시 가지치기(pruning) 문제로 이어집니다. 메모리 저장소는 에이전트의 향후 동작에 영향을 미치는 쓰기 가능한 입력값이기도 하므로, 메모리에 쓰기가 허용된 모든 것은 나중에 에이전트를 조종할 수 있습니다. 웹 페이지나 티켓의 텍스트가 메모리에 도달한다면, 쓰기 권한을 확대하기 전에 에이전트 메모리 오염의 작동 원리를 먼저 읽어보아야 합니다. 검색 크기는 모든 요청마다 토큰 비용을 발생시키며, 바로 이 지점이 에이전트 운영 비용을 예측 가능하게 유지하는 방법의 시작점입니다.

FAQ

에이전트 메모리에 벡터 데이터베이스가 꼭 필요한가?

사실 관계 저장에는 필요하지 않습니다. 의미론적 메모리는 크기가 작고 이름으로 직접 수정해야 하는 경우가 많으므로, 값을 확인하고 편집하기 쉬운 키-값 테이블이나 Git으로 관리하는 마크다운 파일 디렉터리가 더 적합합니다. 임베딩은 나열하기 어려울 정도로 방대한 말뭉치에서 의미 기반으로 검색해야 할 때 비용 효율이 발생하며, 이는 주로 에피소드 메모리나 문서 데이터에 해당합니다. 이미 Postgres를 운영 중이라면 CREATE EXTENSION vector을 통해 별도의 서비스 추가 없이 이를 해결할 수 있습니다.

에이전트 메모리 저장소는 디스크를 얼마나 사용하는가?

벡터 크기는 예측 가능하며, pgvector 기준 차원당 4바이트에 8바이트 헤더가 추가됩니다. 768차원일 경우 100,000행당 293.7 MiB를 차지하며, 384차원일 경우 147.2 MiB를 차지합니다. 여기에 청크 텍스트, 행 오버헤드, 그리고 벡터 복사본을 별도로 유지하는 HNSW 인덱스 용량을 더해야 하므로, 최소한 벡터 수치의 2배 이상으로 예산을 잡고 pg_total_relation_size를 사용하여 실제 수치를 측정하십시오.

절차적 메모리는 어디에 저장해야 하는가?

에이전트가 직접 실행하는 스크립트나 스킬 파일 형태로 Git 저장소에 저장해야 합니다. 절차는 정확한 호출과 버전 이력이 필요하지만, 유사도 검색은 이를 제공하지 못합니다. 런북을 청크 단위로 검색하면 점수가 높은 조각들만 반환되는데, 이는 2단계와 5단계만 나오고 3단계가 누락될 수 있음을 의미하며, 어떤 버전이 실행되었는지 기록되지도 않습니다.

임베딩 모델을 변경하면 어떤 비용이 발생하는가?

서로 다른 모델에서 생성된 벡터는 상호 비교가 불가능하므로 말뭉치 전체를 다시 임베딩해야 합니다. 토큰 비용이나 GPU 사용 시간, 기존 컬럼과 새 컬럼을 동시에 유지할 디스크 공간, 그리고 인덱스 재구축 비용을 고려하십시오. 새 컬럼을 추가하고 배치 단위로 데이터를 채운 뒤, 쿼리를 교체하고 마지막으로 기존 컬럼을 삭제하는 순서로 진행합니다. 이 모든 과정은 각 벡터 옆에 원본 텍스트를 보관하고 있을 때만 가능합니다.