“회사 매뉴얼 PDF 2,400개, 직원 1,200명. 원하는 정보 찾는 데 평균 7분. RAG 챗봇 도입 후 28초로 단축. 구축비 4,800만원, 6개월 만에 ROI 회수.” 국내 중견 제조사 P사의 실제 이야기다. 비결은? 벡터DB로 ChromaDB를 썼다. 월 사용료 $0. 같은 워크로드를 Pinecone에 올렸다면 월 $720이었을 텐데, 무료로 해결한 셈이다.
핵심 요약: RAG(검색증강생성)는 LLM이 답변하기 전에 사내 문서에서 관련 내용을 먼저 검색하게 하는 기술이다. ChromaDB를 로컬에 설치하면 벡터DB 비용이 $0다. 임베딩+LLM API 비용만 내면 월 $5~50으로 사내 문서 검색 챗봇을 돌릴 수 있다. 단, 문서가 500만 건을 넘으면 Weaviate나 Pinecone으로의 마이그레이션을 고려해야 한다.
RAG, 왜 지금 다들 하는가
ChatGPT에 “우리 회사 연차 규정 알려줘”라고 물어보면 “죄송합니다, 내부 정보는 알 수 없습니다”라는 답이 돌아온다. LLM은 학습 시점 이후의 데이터도, 사내 문서도 모른다.
RAG는 이 간극을 메운다. 사용자 질문 → 사내 문서 검색 → 관련 문단 추출 → LLM에 “이 문서를 근거로 답해”라고 주입. 결과적으로 환각(hallucination)이 줄고, 답변 근거를 문서로 제시할 수 있다. 정책이 바뀌면 문서만 교체하면 된다. 모델 재학습 불필요.
2026년 현재 국내 기업의 60% 이상이 RAG 아키텍처를 도입 중이거나 검토 중이다. 파인튜닝보다 5~10배 저렴하고, 감사 대응에 필요한 출처 추적이 가능하기 때문이다.
같은 워크로드, 100배 비용 차이
벡터DB 선택이 RAG 운영비를 결정한다. DevOpsNess가 실제 운영 환경에서 28만 개 문서를 4개 벡터DB로 비교한 결과:
| 벡터DB | 월 비용 | p50 지연 | p95 지연 | Recall@10 |
|---|---|---|---|---|
| Chroma (로컬) | $0 | 18ms | 40ms | 94% |
| pgvector (기존 Postgres) | $80 | 45ms | 110ms | 93% |
| Weaviate (자체 호스팅) | $290 | 22ms | 60ms | 95% |
| Pinecone (관리형) | $720 | 35ms | 80ms | 96% |
Recall(검색 정확도)은 93~96%로 큰 차이가 없다. DevOpsNess의 K. Urbonas는 이렇게 정리한다: "Recall 차이는 오차범위 내다. 선택은 검색 품질이 아니라 운영 비용과 ops 프로필의 문제다." Pinecone은 인프라 관리 부담이 0에 가깝지만, 대신 월 $720을 지불한다. ChromaDB는 공짜지만 직접 서버를 관리해야 한다.
더 놀라운 건 규모가 커질수록 격차가 벌어진다는 점이다. 한 부동산 AI 기업은 Pinecone에서 월 $4,200을 내다가 Weaviate 자체 호스팅으로 전환해 월 $192로 낮췄다. 연간 $48,096 절감. ChromaDB로 시작했으면 초기 비용은 $0이었을 것이다.
월 $5로 시작하는 RAG 스택
실제 구축에 필요한 모든 구성요소와 비용을 정리하면 이렇다:
소규모·PoC 구성 (월 $10~50)
| 구성요소 | 도구 | 월 비용 |
|---|---|---|
| 임베딩 모델 | OpenAI text-embedding-3-small | $0.02/1M 토큰 |
| 벡터DB | ChromaDB (로컬) | $0 |
| LLM | GPT-4o-mini | $0.15/1M 입력 토큰 |
| 프레임워크 | LangChain | $0 (오픈소스) |
직원 100명, 하루 질문 1,000건, 문서 5,000페이지 기준으로 계산하면 월 총비용 약 $8다. LLM을 GPT-4o로 올려도 월 $40~80 수준. ERP 사용 기업이라면 영림원 K-System 매뉴얼·릴리즈 노트만 수천 페이지인데, 이런 문서 검색에 RAG를 붙이면 내부 헬프데스크 문의가 확 줄어든다. Pinecone Starter만 써도 월 $70인 걸 감안하면, ChromaDB의 비용 우위는 압도적이다.
중규모 프로덕션 구성 (월 $200~500)
10만~100만 개 문서 청크, SLA 95% 안정 운영 기준. 이쯤 되면 ChromaDB의 한계가 보이기 시작하지만, 그래도 Weaviate 자체 호스팅($96~290/월)이나 Pinecone($700+/월)보다 저렴하다.
한국 기업이 실제로 겪은 일
✅ 성공: 중견 제조사 사내 매뉴얼 RAG
- 직원 1,200명, PDF 2,400건(8만 청크)
- 스택: text-embedding-3-large + Postgres+pgvector + Claude Sonnet
- 소요 기간: 8주, 구축비 4,800만원
- 검색 시간 7분 → 28초, 정확도 92%, ROI 6개월
- 성공 포인트: 도입 전 PDF 전수 정리(중복·구버전 30% 삭제), 출처 페이지 번호 제시로 안전 감사 대응 가능
❌ 실패: 중소 IT 사내 RAG
- 직원 80명, Confluence 600건
- 스택: 무료 MiniLM + Pinecone Free + GPT-4o-mini
- 소요 기간: 4주, 구축비 1,200만원
- 정확도 41%, 사용률 12%에서 6%로 하락 → 4개월 만에 운영 중단
- 실패 원인: 5년 치 중복·구버전 문서 정리 없이 그대로 임베딩, MiniLM의 한국어 정확도 미검증, 평가 데이터셋 없이 운영 시작
두 사례가 말해주는 건 단순하다. 문서 정리가 선행되지 않으면 RAG는 실패한다. AI를 붙이기 전에, 답변의 근거가 될 문서부터 깨끗하게 만들어야 한다. 이건 기술 문제가 아니라 데이터 거버넌스 문제다.
ChromaDB, 어디까지 버티나
ChromaDB의 약점은 명확하다. RankSquire의 2026년 3월 벤치마크에 따르면:
| 벡터 수 | ChromaDB p99 | Weaviate p99 (같은 서버) |
|---|---|---|
| 50만 | 8ms ✅ | — |
| 100만 | 42ms ✅ | 18ms |
| 500만 | 185ms ⚠️ | 22ms |
| 1,000만 | 340ms ❌ | 42ms |
| 5,000만 | 800ms+ ❌ | 68ms |
핵심은 500만 벡터다. 이 지점을 넘으면 지연시간이 급격히 증가하고, 16GB RAM 서버에서 OOM(Out of Memory) 위험이 현실화된다. 실제로 한 부동산 AI 기업은 ChromaDB 1,000만 벡터에서 14GB RAM을 소진해 OOM 킬을 당했고, 47분간 서비스가 중단됐다.
ChromaDB 마이그레이션 시그널: p99 지연이 1,000회 연속 쿼리에서 100ms를 넘으면 Weaviate나 pgvector로 옮길 때다. 그 전까지는 ChromaDB로 충분하다.
오늘 당장 시작하는 3단계
1. 문서 정리부터 (1~3일)
중복 문서 삭제, 구버전 폐기, PDF 메타데이터 통일. 이 단계를 건너뛰면 정확도 41%의 실패 사례를 그대로 따라가는 셈이다.
2. ChromaDB + LangChain으로 PoC (1~2일)pip install chromadb langchain openai 세 줄이면 환경 구성 끝. 문서 50개만 올려서 동작 확인. 비용 $0.
3. 100명 파일럿 후 확장 판단 (2~4주)
실제 직원들이 사용하면서 정확도, 지연시간, 사용률을 측정한다. 만족도 80% 이상이면 프로덕션 전환. 이때도 ChromaDB로 충분한지, Weaviate나 pgvector로 갈지 데이터로 판단한다.
한 줄 요약: ChromaDB는 무료로 시작해서 500만 건까지 버티는 실용적인 벡터DB다. Pinecone 월 $720을 아끼고 싶다면, 지금 당장 pip install chromadb부터 시작하라. 단, 중복 문서 정리부터 먼저다.