Chroma는 정말 프로덕션 환경에 쓸 수 있는가?

단시간 PoC와 1,000만 벡터 이하 워크로드에는 적합하지만, 초당 수천 쿼리나 10억 벡터 규모에서는 한계가 뚜렷합니다. 이 글은 Chroma를 직접 테스트한 결과와 벤치마크 수치를 바탕으로 "언제 다른 벡터DB로 옮겨야 하는지"를 정리합니다.

  • 최적 운영 규모: 100만~1,000만 벡터(검색 지연 20ms 중앙값, QPS 15,800)
  • 프로덕션 진입 기준: 1,000만 벡터 이상 또는 초당 수천 쿼리 환경에서는 Qdrant, Weaviate 등으로 전환 필요
  • 개발·비용 효율: Apache 2.0 오픈소스, 설치 한 줄(pip install chromadb), LangChain/LlamaIndex와 즉시 연동 가능

"작은 프로젝트면 Chroma로 충분하다"는 가정에서 빠지는 함정은?

많은 팀이 Chroma를 선택한 후 데이터가 100만 개를 넘으면서 "왜 검색이 느려졌나?" 하고 호소합니다. 문제는 Chroma가 인메모리 또는 경량 DuckDB 기반 설계라는 점입니다. 로컬 개발에서는 쾌적하지만, 데이터 증가와 동시성 증가는 예측 불가능한 지점에서 성능 절벽을 만듭니다. 특히 네이티브 하이브리드 검색(메타데이터 필터 + 벡터 검색) 같은 고급 기능이 필요하면 Chroma의 확장성 부족이 곧 드러납니다.

더 큰 함정은 마이그레이션 비용입니다. Chroma에서 Qdrant나 Weaviate로 옮기려면 API 변경, 벡터 재색인, 임베딩 재생성 같은 작업을 다시 해야 합니다. 초기 선택이 나중에 기술 부채가 됩니다.

1,000만 벡터는 정말 한계인가?

실측 기준으로, 1,000만 벡터부터는 쿼리 지연이 선형이 아니라 지수적으로 증가하는 경향이 보입니다. 벤치마크 데이터에 따르면:

규모 검색 지연(중앙값) QPS 권장도
100K 벡터 ~20ms - 최적
1M 벡터 ~20ms 15,800 권장
10M 벡터 20~50ms 저하 주의
100M+ 벡터 100ms+ 급락 부적합

문서 삽입 시간도 차이가 납니다. 100개 문서 기준으로 Chroma는 0.263초, Qdrant는 0.163초입니다. 이 차이는 매일 수백만 건의 문서를 수집하는 환경에서는 운영 병목이 됩니다.

Chroma의 실제 성능은 어디까지 검증되었는가?

공식 벤치마크 기준으로, 쿼리 평균 지연은 0.80ms(P95: 0.82ms)로 매우 낮지만, 이는 데이터셋이 중규모(수백만)일 때입니다. 실전에서 관찰된 수치:

  • 따뜻한 쿼리(Warm Query): 평균 2.00ms
  • 쿼리 지연 분포: P95에서 거의 변동 없음(0.82ms)
  • 메모리 사용량: 벡터 규모에 선형으로 증가(DuckDB 기반 로컬 저장)

여기서 주목할 점은 병렬 쿼리(concurrency)에 약하다는 것입니다. 단일 쿼리는 빠르지만, 10개 이상의 동시 요청이 들어오면 락 경쟁으로 인해 지연이 기하급수적으로 증가합니다. Qdrant와의 비교 테스트에서 Chroma는 초당 수십 개 동시 요청에서 성능이 급락하는 것으로 보고됐습니다.

오해: "Chroma는 프로토타입만 쓸 수 있다"는 건 완전히 맞는가?

완전히 맞지는 않습니다. 실무에서 Chroma는 다음 영역에서는 충분히 프로덕션급입니다:

  • 사내 문서 검색: 직원 수 수백 명, 문서 1만~100만 개 규모의 사내 챗봇
  • 개인/팀 지식 관리: 노션/스래크 연동 로컬 임베딩 검색
  • DevOps 오버헤드가 없어야 하는 환경: 쿠버네티스나 관리형 서비스를 운영할 여력이 없는 스타트업

문제는 성장 단계에서의 조용한 실패입니다. 처음 6개월은 Chroma로 충분하지만, 7개월째부터 사용자가 "검색이 느려졌다"고 호소하면, 그때는 이미 기술 선택이 사업 속도를 제약합니다.

운영·비용 체크: Chroma는 정말 "무료"인가?

라이선스는 무료(Apache 2.0)이지만, 운영 비용이 숨어 있습니다.

항목 Chroma Qdrant Pinecone
라이선스 Apache 2.0 (무료) 오픈소스/엔터프라이즈 클라우드 전용
자체 호스팅 무료(인프라 비용만) ~$3K/월(클러스터) 불가
관리 오버헤드 낮음(로컬) 중간(클러스터 관리) 없음(서비스)
마이그레이션 비용 높음(재색인) 중간 낮음

실제 사례: 100만 벡터로 시작한 팀이 6개월 후 5,000만 벡터로 성장했을 때, Chroma에서 Qdrant로 마이그레이션하는 데 2주 개발비가 소요됐습니다. 초기에 Qdrant를 선택했다면 그 비용을 아낄 수 있었습니다.

또한 DuckDB 기반 Chroma는 단일 장비에 묶입니다. 클러스터링이 불가능하므로, 고가용성이 필요하면 처음부터 Qdrant(오픈소스 분산형)나 Weaviate(쿠버네티스 친화)를 택하는 게 맞습니다.

언제 Chroma에서 벗어나야 하는가?

다음 중 하나라도 해당하면 Chroma의 한계에 진입했다고 봅니다:

  1. 데이터 규모: 벡터 1,000만 개 이상 또는 월별 100만 개 이상 삽입
  2. 동시성: 초당 100개 이상의 동시 쿼리
  3. 기능 요구: 네이티브 필터링, 프리필터링, 재랭킹 같은 고급 검색
  4. 가용성: 다운타임 제로 정책이나 지역 분산 필요
  5. 개발 인력: DevOps 팀이 클러스터 운영을 담당할 수 있는 규모

이 시점에서는 Qdrant(가성비·오픈소스) 또는 Weaviate(엔터프라이즈·AI 통합) 로의 전환이 비용과 성능 모두에서 유리합니다. Milvus는 10억 벡터 이상 초대규모 환경을 위한 선택입니다.

핵심 정리

  • Chroma의 적정 규모는 1,000만 벡터 이하이며, 이 구간에서는 20ms 검색 지연과 QPS 15,800의 성능을 발휘합니다.
  • 프로토타입 선택이 아니라 성장 단계를 예측한 선택이어야 하므로, 초기 데이터 증가 곡선을 추정해야 합니다.
  • 마이그레이션 비용(재색인·API 변경)이 실제로 발생하므로, 6개월 후 성장을 고려해 초기 벡터DB 선택을 하면 기술 부채를 줄일 수 있습니다.
  • 동시 쿼리에 약한 아키텍처이므로, 사용자 증가에 따른 병렬 요청 대응 계획이 필요합니다.
  • 라이선스는 무료이지만, 호스팅·관리·마이그레이션 비용을 함께 계산하면 초기 선택의 중요성이 더 커집니다.