[AI] 벡터 DB Qdrant vs Chroma: 1년 사용 후기 및 마이그레이션 고려사항

벡터 DB 비교를 진지하게 해야 하는 시점이 생각보다 빨리 오더라고요. 처음엔 RAG(Retrieval-Augmented Generation, 검색 증강 생성) PoC(개념 검증)만 돌리면 끝날 줄 알았는데, 문서 수가 늘고 메타데이터 필터가 복잡해지고 운영 환경이 붙기 시작하면 이야기가 달라집니다. 저도 홈랩과 업무성 PoC에서 Qdrant와 Chroma를 번갈아 써보면서, “둘 다 벡터 데이터베이스인데 왜 이렇게 운영 감각이 다르지?” 싶었던 순간이 꽤 많았습니다. 특히 1년 정도 굴려보니 단순 기능 비교보다, 마이그레이션과 운영 난이도에서 체감 차이가 더 크게 오더라고요.

이번 글은 Qdrant, Chroma를 실제 운영 관점에서 어떻게 봐야 하는지 정리한 글입니다. 성능 수치 뻥튀기나 벤치마크 놀이는 일부러 뺐습니다. 대신 어떤 팀에 어떤 선택이 맞는지, 그리고 나중에 옮길 때 어디서 삽질하기 쉬운지 중심으로 적어보겠습니다. 혹시 지금 “일단 Chroma로 시작하고 나중에 Qdrant로 옮기면 되겠지” 혹은 반대로 “Qdrant가 더 본격적이니 무조건 그게 답 아닌가?” 고민하고 계시면 꽤 현실적인 판단 기준이 되실 겁니다.

Qdrant와 Chroma가 애플리케이션, 임베딩 모델, 메타데이터 필터, 저장소 계층에서 어떻게 연결되는지 한눈에 보여주는 개요도입니다.

1. 벡터 데이터베이스, 쉽게 말해 뭐가 다른 걸까요?

쉽게 말해 벡터 데이터베이스(Vector Database, 벡터 유사도 검색용 저장소)는 텍스트나 이미지에서 뽑아낸 임베딩(Embedding, 의미를 숫자 배열로 바꾼 값)을 저장하고, 비슷한 의미를 가진 데이터를 빠르게 찾는 데 특화된 저장소입니다. 일반 RDBMS(관계형 데이터베이스)로도 못 하는 건 아니지만, 문서 수가 늘어나고 의미 기반 검색이 들어가면 관리 포인트가 확 늘어납니다.

근데 여기서 중요한 포인트가 있습니다. 벡터 검색만 되면 끝이 아니거든요. 실제 서비스에서는 메타데이터 필터링, 컬렉션 설계, 백업, 복구, 멀티테넌시(Multitenancy, 여러 고객/조직을 분리 운영하는 구조), 클라이언트 연결 방식까지 같이 봐야 합니다. 제가 처음엔 이걸 가볍게 봤다가 나중에 마이그레이션에서 삽질 좀 했습니다 ㅎㅎ

Qdrant와 Chroma의 결 차이

제 경험상 정리하면 이렇습니다. Chroma는 시작이 빠르고, Qdrant는 운영이 길어질수록 편해집니다. 물론 예외는 있습니다. 데이터가 작고 단일 앱 내부에서만 쓰는 경우엔 Chroma가 정말 편합니다. 반대로 여러 워커가 붙고 백업과 복구를 신경 써야 하면 Qdrant 쪽이 마음이 놓이더라고요.

2. Qdrant vs Chroma를 나눠보는 기준

벡터 DB 비교를 할 때 제가 실제로 보는 기준은 딱 다섯 가지입니다.

• 데이터 영속성(Persistence, 디스크에 안전하게 남는가)
• 필터링 모델(메타데이터 검색이 얼마나 자연스러운가)
• 운영 기능(백업, 복구, 재배치, 멀티테넌시)
• 클라이언트 연결 방식(앱 안에서 바로 쓰는지, 서버를 두는지)
• 마이그레이션 비용(나중에 옮길 때 고생하는 포인트가 뭔지)

Qdrant는 컬렉션(Collection, 벡터를 담는 논리 단위)과 포인트(Point, 벡터+메타데이터 단위) 개념이 비교적 명확하고, payload(페이로드, 메타데이터) 필터를 중심으로 운영 설계를 하게 됩니다. 문서상으로도 필터링, 하이브리드 쿼리(Hybrid Queries, 벡터 검색과 다른 검색 조건 결합), 스냅샷, 데이터 마이그레이션이 잘 드러납니다. 반면 Chroma는 클라이언트 관점이 더 앞에 나옵니다. `Client()`, `PersistentClient()`, `HttpClient()` 흐름이 명확해서 개발자가 바로 붙이기 편합니다.

이 차이가 실제론 꽤 큽니다. 개발 초기엔 Chroma가 “드디어 됐다!” 싶은 속도를 주고, 운영 단계에선 Qdrant가 “이거 복구 시나리오까지 생각해놨네” 하는 안정감을 줍니다.

3. 실전 구현: 둘 다 같은 조건으로 빠르게 띄워보기

말로만 비교하면 감이 잘 안 오니까, 가장 단순한 방식으로 둘 다 띄워보겠습니다. 제가 실험할 때도 항상 같은 문서 샘플, 같은 메타데이터 구조로 먼저 맞춰봅니다. 그래야 나중에 마이그레이션 판단이 쉬워지거든요.

3-1. Qdrant 실행

docker pull qdrant/qdrant

docker run -p 6333:6333 -p 6334:6334 \
  -v "$(pwd)/qdrant_storage:/qdrant/storage:z" \
  qdrant/qdrant

Qdrant는 이렇게 독립 서비스로 띄우는 흐름이 자연스럽습니다. REST API는 `6333`, gRPC는 `6334`를 기본으로 씁니다. 운영 생각이 조금이라도 있으면 저는 처음부터 볼륨 마운트를 잡아둡니다. 안 그러면 테스트는 쉬운데 나중에 데이터 보존 흐름이 꼬이더라고요.

3-2. Chroma 실행

docker pull chromadb/chroma

docker run -p 8000:8000 chromadb/chroma

Chroma는 서버 모드도 가능하지만, 로컬 실험에서는 Python `Client()`나 `PersistentClient()`로 바로 붙는 맛이 좋습니다. 빠르게 아이디어 검증할 때 이 장점이 꽤 큽니다.

3-3. Docker Compose로 같이 올리기

services:
  qdrant:
    image: qdrant/qdrant
    ports:
      - "6333:6333"
      - "6334:6334"
    volumes:
      - ./qdrant_storage:/qdrant/storage

  chroma:
    image: chromadb/chroma
    ports:
      - "8000:8000"

처음엔 각각 따로 띄웠었는데, 나중엔 결국 이렇게 같이 올려놓고 같은 데이터셋으로 비교하게 되더라고요. 벡터 DB 비교는 이 습관이 정말 중요합니다.

로컬 홈랩 환경에서 Qdrant와 Chroma를 나란히 띄우고 같은 샘플 데이터를 넣는 실습 구성을 표현한 이미지입니다.

4. 같은 데이터를 넣어보면 차이가 더 선명합니다

아래 예시는 기능을 뽐내기보다는, 실제 마이그레이션 전 체크해야 하는 최소 단위를 보여주기 위한 코드입니다. 핵심은 문서, ID, 메타데이터 키 구조를 처음부터 고정하는 겁니다.

4-1. Chroma 예시

import chromadb

client = chromadb.PersistentClient(path="./chroma_data")
collection = client.get_or_create_collection(name="docs")

collection.add(
    ids=["doc-1", "doc-2"],
    documents=[
        "nginx ingress timeout troubleshooting",
        "qdrant payload filtering notes"
    ],
    metadatas=[
        {"service": "ingress", "env": "lab"},
        {"service": "vector-db", "env": "lab"}
    ]
)

result = collection.query(
    query_texts=["vector database filter"],
    n_results=2,
    where={"env": "lab"}
)

print(result)

Chroma는 여기까지 오는 속도가 정말 빠릅니다. `PersistentClient`만 써도 디스크에 저장되고, 메타데이터 필터 문법도 직관적입니다. 제가 처음 RAG 프로토타입 만들 때는 솔직히 이 편의성이 꽤 크게 느껴졌습니다.

4-2. Qdrant 예시

from qdrant_client import QdrantClient
from qdrant_client.models import Distance, VectorParams

client = QdrantClient(url="http://localhost:6333")

client.create_collection(
    collection_name="docs",
    vectors_config=VectorParams(size=4, distance=Distance.COSINE)
)

curl -X PUT http://localhost:6333/collections/docs/points \
  -H 'Content-Type: application/json' \
  -d '{
    "points": [
      {
        "id": 1,
        "vector": [0.05, 0.61, 0.76, 0.74],
        "payload": {"service": "ingress", "env": "lab"}
      },
      {
        "id": 2,
        "vector": [0.19, 0.81, 0.75, 0.11],
        "payload": {"service": "vector-db", "env": "lab"}
      }
    ]
  }'

Qdrant는 시작이 조금 더 “DB를 세팅한다”는 느낌입니다. 대신 구조가 또렷합니다. payload 필터, 컬렉션 설정, 나중에 붙일 인덱스 전략까지 그림이 잘 나옵니다. 실제로 써보니까 검색 품질보다도 운영 설계를 앞당겨 생각하게 만드는 쪽은 Qdrant였습니다.

4-3. 필터링 관점 차이

Chroma는 `where` 문법이 친숙하고, OR 조건이나 배열 포함 조건도 비교적 읽기 쉽습니다. Qdrant는 `must`, `should`, `match`, `range` 중심의 필터 모델이라 처음엔 약간 더 장비 만지는 느낌이 납니다. 근데 조건이 복잡해질수록 저는 Qdrant 쪽이 더 예측 가능하더라고요.

특히 Qdrant는 필터링 성능을 위해 payload index를 고려하라는 흐름이 명확합니다. 이건 운영 단계에서 꽤 중요합니다. 개발할 땐 그냥 되면 됐지 싶었는데, 데이터가 쌓이면 이 차이가 바로 체감됩니다.

5. 마이그레이션 고려사항: 여기서 진짜 차이가 납니다

이 섹션이 사실 핵심입니다. 벡터 데이터베이스를 바꾼다는 건 단순 dump/import가 아니더라고요. 임베딩 모델, ID 체계, 메타데이터 스키마, 필터 문법, 컬렉션 설정이 다 얽혀 있습니다.

1. 임베딩 차원 수를 먼저 확인하세요. Qdrant는 컬렉션 생성 시 벡터 크기를 정하게 되고, 다른 차원의 임베딩을 넣으면 바로 문제가 납니다. 마이그레이션 전에 현재 임베딩 모델의 차원 수를 먼저 고정해두는 게 좋습니다.
2. ID 전략을 통일하세요. 숫자 ID인지 문자열 ID인지, 외부 문서 ID를 그대로 쓸지 내부 생성 ID를 쓸지 먼저 정해야 합니다. 나중에 재색인(reindex)할 때 이게 꼬이면 검증이 매우 힘들어집니다.
3. 메타데이터 키를 평평하게 유지하세요. `service`, `env`, `owner`, `source`처럼 자주 쓰는 키를 정규화해두면 Chroma에서 Qdrant로 옮길 때도 덜 아픕니다.
4. 필터 의미가 같은지 꼭 재검증하세요. 같은 조건처럼 보여도 결과가 미묘하게 다를 수 있습니다. Chroma는 버전 변화로 `where` 동작이 바뀐 항목들이 있었고, Qdrant는 필터 구조가 더 명시적이라 쿼리 변환 시 검증이 필요합니다.
5. 백업 방식과 이전 방식은 구분해서 보세요. Qdrant는 snapshot 기반 복구가 강하고, 별도 migration tool은 스트리밍 전송과 재개(resume)에 강점이 있습니다. 목적이 같아 보이지만 실제 용도는 꽤 다릅니다.

여기서 제가 가장 많이 놓쳤던 건 필터 문법보다 필터 의미였습니다. 예를 들어 Chroma 쪽은 버전에 따라 `where`의 일부 연산자 동작이 바뀐 적이 있습니다. 또 오래된 저장 구조를 쓰던 환경에서는 `chroma-migrate`로 데이터 레이아웃을 올려야 하는 케이스도 있었습니다. 예전 방식에서 `duckdb`/`clickhouse` 기반 메타데이터 저장을 쓰다가 `sqlite` 기반으로 넘어가는 변화가 있었기 때문에, 오래된 로컬 데이터면 이 부분을 꼭 체크하셔야 합니다.

pip install chroma-migrate
chroma-migrate

이거 저도 처음엔 “에이, 그냥 패키지 업그레이드면 끝나겠지” 했었는데 아니더라고요. 버전 점프가 큰 환경은 특히 조심하셔야 합니다.

반대로 Qdrant 쪽은 마이그레이션 관점 문서가 꽤 명확합니다. 같은 클러스터 복구나 로컬 백업이면 snapshot이 맞고, 다른 환경으로 옮기거나 중간에 끊겨도 다시 이어가야 하는 흐름이면 migration tool 쪽이 더 자연스럽습니다. 컬렉션 설정을 바꾸면서 옮길 수 있다는 점도 운영에서는 꽤 실용적입니다.

6. ⚠️ 실제로 겪었던 문제와 해결법

6-1. Chroma는 빠른데, 버전 변화 체크를 안 하면 발목을 잡습니다

Chroma는 진입 속도가 빠른 대신, 오래 유지된 로컬 테스트 환경을 운영 비슷하게 끌고 가면 예상 못 한 차이를 만날 수 있습니다. 예를 들어 `get_or_create_collection`의 동작이나, `where` 관련 연산자의 의미가 버전에 따라 바뀐 부분은 꼭 확인하셔야 합니다. 특히 빈 딕셔너리나 빈 리스트 필터를 관성적으로 넘기던 코드가 나중에 깨질 수 있습니다.

해결 팁은 간단합니다. 업그레이드 전후로 샘플 질의를 고정해두고, 결과 ID 집합이 같은지 비교하세요. 사람 눈으로 보면 비슷한데 실제 검색 결과가 달라지는 케이스가 있거든요.

6-2. Qdrant는 필터 인덱스를 늦게 보면 운영 때 아쉽습니다

Qdrant는 payload 필터를 많이 쓸 예정이라면, 어떤 필드를 자주 거를지 초기에 정하는 게 좋습니다. 저도 처음엔 벡터 검색만 잘 되면 된다고 생각했는데, 실제로는 `env=prod`, `service=api`, `tenant=team-a` 같은 필터가 계속 붙더라고요. 그때서야 필드 전략을 다시 손보면 좀 번거롭습니다.

해결 팁은 검색 패턴을 먼저 적는 겁니다. 어떤 메타데이터 조합을 가장 자주 쓰는지 적고 시작하면 payload 설계가 훨씬 안정적입니다.

6-3. 마이그레이션은 데이터보다 검증이 더 오래 걸립니다

이건 진짜입니다. 데이터 옮기는 명령어 자체보다, 옮긴 뒤에 “제대로 됐는지” 확인하는 시간이 더 깁니다. 총 문서 수, ID 누락, 대표 질의 결과, 메타데이터 필터 결과를 전부 비교해야 하거든요. 처음엔 이게 뭔가 싶었는데, 한 번만 대충 하고 나면 꼭 나중에 후회합니다.

컬렉션 설계, 메타데이터 키 정리, 필터 의미 검증, 백업과 이전 전략 분리를 한 장에 정리한 마이그레이션 흐름도입니다.

7. 검증과 결과: 어떤 상황에서 무엇이 더 편했나

제가 실제로 써보니까 결론은 꽤 선명했습니다.

• 빠른 PoC와 로컬 실험: Chroma가 더 편했습니다
• 장기 운영과 복구 시나리오: Qdrant가 더 편했습니다
• 앱 코드 안에서 바로 돌려보기: Chroma가 부담이 적었습니다
• 서비스로 분리하고 운영 규칙을 붙이기: Qdrant가 잘 맞았습니다

Chroma는 `PersistentClient` 하나로 시작할 수 있어서 개발 속도가 정말 좋습니다. 문서 몇천 개 수준에서 빠르게 실험하고, 애플리케이션 코드 안에서 검색 레이어를 붙이는 경험은 상당히 부드럽습니다. 반면 Qdrant는 처음부터 서비스 경계가 뚜렷해서, 팀이 붙고 환경이 나뉘고 복구 전략이 필요해질수록 강점이 살아납니다.

그리고 벡터 DB 비교에서 자주 놓치는 포인트가 하나 더 있습니다. 지금 편한 도구와 나중에 덜 아픈 도구가 다를 수 있다는 겁니다. 이 차이를 미리 받아들이면 선택이 훨씬 쉬워집니다.

문서 수, 필터 사용 빈도, 운영 편의성, 마이그레이션 리스크를 비교하는 대시보드 스타일의 결과 시각화입니다.

8. 자주 묻는 질문 정리

Q. Chroma로 시작했다가 나중에 Qdrant로 옮겨도 될까요?

네, 충분히 가능합니다. 다만 임베딩 차원, ID 체계, 메타데이터 키 구조를 초기에 잘 잡아두셔야 합니다. 이걸 대충 두면 나중에 옮기는 비용이 확 올라갑니다.

Q. Qdrant가 무조건 더 좋은가요?

그건 아닙니다. 운영형 요구사항이 아직 없고, 개발 생산성이 더 중요하면 Chroma가 오히려 더 좋은 선택일 수 있습니다. 특히 로컬 실험과 앱 내장형 흐름은 Chroma가 꽤 강합니다.

Q. 백업은 어떻게 생각하면 좋을까요?

Qdrant는 snapshot 관점이 분명해서 백업/복구 시나리오를 잡기 좋습니다. Chroma는 사용 모드에 따라 로컬 저장 경로와 업그레이드 절차를 더 꼼꼼히 봐야 합니다.

Q. 이전 글이나 다음 글과 연결해서 보면 좋은 주제는요?

이전 글에서 다뤘던 Docker Compose 운영 패턴과 같이 보시면 이해가 빠릅니다. 다음 글에서는 RAG 파이프라인에서 재색인 전략과 임베딩 교체 시 주의점을 따로 다뤄볼 예정입니다.

PoC, 운영, 백업, 필터링, 마이그레이션 기준으로 Qdrant와 Chroma 선택 포인트를 요약한 인포그래픽입니다.

9. 마무리: 결국 중요한 건 지금의 편의성과 미래의 운영 비용 균형입니다

정리해보면 이렇습니다. Chroma는 시작이 빠르고, Qdrant는 운영이 길어질수록 강합니다. 제가 직접 해보니 둘 중 하나가 절대적으로 우월하다기보다는, 팀의 현재 단계가 어디냐에 따라 답이 달라졌습니다. 혼자 혹은 소규모로 빠르게 실험할 때는 Chroma가 진짜 편하더라고요. 반대로 운영 환경 냄새가 나기 시작하면 Qdrant 쪽이 훨씬 안심됐습니다.

혹시 지금 벡터 DB 비교 때문에 머리가 복잡하시면, 먼저 스스로에게 이렇게 물어보시면 됩니다. “나는 지금 빠르게 검증해야 하나, 아니면 나중에 덜 아파야 하나?” 이 질문에 답이 나오면 선택도 꽤 선명해집니다. 그리고 무엇을 고르든, 메타데이터 스키마와 검증 시나리오부터 잡아두는 것, 이건 진짜 강력 추천드립니다.

다음 글에서는 Qdrant와 Chroma 위에 RAG 파이프라인을 얹을 때, 재색인 전략과 문서 chunking(청킹, 문서를 작은 단위로 나누는 방식)이 검색 품질에 어떤 차이를 만드는지 이어서 정리해보겠습니다.