−25%

Windows 연간 결제, 10월 31일까지. 요금제 보기

EQVPS
시작하기

VPS에서 AI 에이전트 기억용 벡터 데이터베이스 호스팅하기

2026년 6월 15일 · 2 분 읽기 · EQVPS Team

기억 없는 AI 에이전트는 대화마다 자기소개를 다시 하는 데 발이 묶입니다. 해법은 벡터 데이터베이스입니다 — 당신의 문서, 메모, 지난 채팅의 임베딩을 저장해 에이전트가 필요할 때 관련 부분을 떠올릴 수 있게 합니다(그것이 RAG의 "R"). 그것을 관리형 서비스로 빌릴 수도, VPS에서 직접 돌려 데이터 — 흔히 당신의 사적 데이터 — 를 당신이 통제하는 박스에 둘 수도 있습니다. 여기 그 방법과, RAM으로 실제 얼마가 드는지를 적습니다.

두 가지 좋은 선택

별난 건 필요 없습니다. 두 경로가 거의 모두를 커버합니다:

pgvector — Postgres 확장. 이미 Postgres를 돌리고 있다면(또는 기꺼이) 이미 가진 데이터베이스에 벡터 검색을 더합니다. 서비스 하나, 백업 하나, 아는 SQL. 큰 차이로 가장 품이 덜 드는 출발.

Qdrant — 목적 특화 벡터 엔진. 벡터가 많거나(낮은 수백만+) 빠른 메타데이터 필터링과 전용 API를 원할 때 손을 뻗습니다. 돌릴 별도 서비스지만, 바로 이 일을 위해 만들어졌습니다.

발판을 다지는 대부분의 에이전트에는 pgvector가 알맞은 첫 답입니다. 그것을 넘어 자랐을 때 Qdrant로, 그 전엔 아닙니다.

RAM의 현실(사람들이 과소평가하는 부분)

벡터 검색이 빠른 것은 인덱스가 메모리에 살기 때문 — 그래서 디스크가 아니라 RAM이 진짜 제약입니다. 대략적 안내:

  • 수십만 임베딩 — 2 GB에서 편안.
  • 낮은 수백만 — 4 GB 이상을 계획하고 인덱스를 튜닝.
  • 디스크는 쉬운 부분: 100만 임베딩은 겨우 몇 GB이므로, 25~45 GB가 진지한 스토어를 커버합니다.

그러니 파일이 아니라 인덱스에 맞춰 크기를. (일반 사이징 가이드와 같은 논리 — 무거운 것은 측정하기 전엔 뻔하지 않습니다.)

빠른 시작: pgvector

Postgres가 있는 박스에서(Docker가 가장 쉬움 — n8n 자체 호스팅과 같은 패턴):

CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE memory (
  id bigserial PRIMARY KEY,
  content text,
  embedding vector(1536)        -- 당신 임베딩 모델의 차원에 맞추세요
);

-- 데이터가 생긴 뒤, 빠른 검색을 위해 인덱스를 만드세요:
CREATE INDEX ON memory USING hnsw (embedding vector_cosine_ops);

당신의 에이전트는 content + 그 임베딩을 삽입하고, 가장 가까운 기억을 끌어오려 ORDER BY embedding <=> $query_embedding LIMIT 5로 쿼리합니다. 그것이 전체 루프입니다.

Qdrant가 좋은가요? HTTP/gRPC API를 노출하는 단일 Docker 컨테이너로, 벡터 크기로 컬렉션을 만들고 포인트를 upsert합니다. 같은 발상, 전용 엔진.

에이전트와 박스를 공유할 수 있나

네 — 소~중 기억 스토어에는 벡터 DB를 에이전트와 같은 VPS에서 돌리세요. 더 간단하고 지연은 사실상 0입니다. 한쪽이 다른 쪽을 RAM에서 밀어내기 시작할 때만 별도 서버로 나누세요. 그것은 나중의, 있어 반가운 문제의 결정이지 첫날의 것이 아닙니다.

솔직한 주의점

  • RAM이 벽이고, 조용합니다. 검색은 인덱스가 메모리에 들어가는 동안 빠르다가, 그 뒤 저하됩니다. 메모리를 보고 물기 전에 크기를 올리세요 — 느린 쿼리가 알려주길 기다리지 마세요.
  • 임베딩은 만드는 데 토큰이 듭니다. 임베딩하는 문서마다 임베딩 모델로의 API 호출입니다. 스토어는 호스팅에 싸고; 벡터를 생성하는 것이 반복 비용입니다 — 에이전트를 돌리는 데 실제 얼마가 드는지와 관련.
  • 백업하세요. 에이전트의 기억은 다른 것과 같은 데이터입니다. 중요하면 스냅샷을.

그 안에서, 자체 호스팅 벡터 스토어는 사적 데이터를 제3자에게 건네지 않고 에이전트에게 지속되는 기억을 주는 깔끔한 방법입니다. 2 GB 박스의 pgvector로 시작하고, RAM에 눈을 두고, 숫자가 말할 때만 Qdrant나 더 큰 요금제로 자라나세요.

FAQ

pgvector냐 Qdrant냐 — 무엇을 자체 호스팅해야 하나요?

이미 Postgres를 돌리고 있다면(또는 앱 데이터와 임베딩 둘 다에 하나의 데이터베이스를 원한다면) pgvector가 가장 품이 덜 드는 선택입니다 — 그냥 확장 기능입니다. 수백만 벡터가 있거나 빠른 필터링을 갖춘 목적 특화 엔진을 원한다면 Qdrant가 별도 서비스의 값어치가 있습니다. 막 시작하는 대부분의 에이전트에는 Postgres 위 pgvector면 충분합니다.

벡터 데이터베이스에 RAM이 얼마나 필요한가요?

짐작보다 많습니다, 좋은 검색은 인덱스를 메모리에 두길 원하니까요. 대략적 규칙: 수십만 임베딩은 2 GB에 편안히 들어가고; 낮은 수백만에 이르면 4 GB 이상을 계획하고 인덱스를 튜닝하세요. 2 GB에서 시작하고, 메모리를 보고, 검색이 느려지면 크기를 올리세요.

관리형 대신 벡터 스토어를 자체 호스팅하는 이유는?

사람들이 실제로 하는 두 가지 이유: 임베딩에는 흔히 당신의 사적 데이터가 담기고(메모, 문서, 고객 콘텐츠), 자체 호스팅 스토어는 그것을 당신이 통제하는 서버에 둡니다. 그리고 정액입니다 — 관리형 벡터 서비스는 벡터와 쿼리로 청구하지만, VPS는 쿼리별 계량 없는 월 하나의 숫자입니다.

벡터 DB와 제 에이전트가 같은 VPS에서 돌 수 있나요?

네, 소~중 워크로드에는 — 에이전트와 pgvector/Qdrant 인스턴스를 한 박스에 동거시키는 것은 간단하고 지연을 거의 0으로 줄입니다. 한쪽이 다른 쪽을 RAM으로 굶기기 시작할 때만 별도 서버로 나누세요. 그것은 나중의, 있어 반가운 문제의 결정이지 첫날의 걱정이 아닙니다.

임베딩은 디스크를 많이 먹나요?

단일 임베딩은 몇 킬로바이트이므로, 100만 개는 인덱스 오버헤드에 더해 몇 기가바이트 — 의미는 있지만 거대하지 않습니다. 25~45 GB 디스크가 대부분의 에이전트에 상당한 기억 스토어를 커버합니다. 디스크가 아니라 RAM이 대개 처음 부딪히는 한계입니다.

댓글

아직 댓글이 없습니다. 첫 번째가 되세요.

댓글 남기기

댓글은 표시되기 전에 검토됩니다.