Chroma에서 Pinecone으로 바꾸면 무엇이 달라질까?
LangChain RAG의 Vector Store를 Chroma에서 Pinecone으로 바꿀 때 달라지는 실행 위치, 인증, Index 설계, 데이터 이전과 운영 책임을 쉽게 설명합니다.
LangChain으로 사내 문서 RAG 챗봇 만들기 5/9
문서를 준비하는 단계부터 검색, 대화 화면, 배포와 평가까지 하나씩 연결하는 학습 기록
이전 글 — LangChain 없이 RAG를 만들면 무엇이 불편할까?
교실 책상 위에 축제 안내 카드를 정리해뒀습니다. 혼자 실험할 때는 빠르고 편합니다. 그런데 여러 반이 동시에 검색해야 하고, 앱 서버를 새로 띄워도 같은 자료를 찾아야 한다면 책상 서랍만으로는 부족할 수 있습니다.
Chroma와 Pinecone은 모두 Vector Store 역할을 할 수 있지만 운영 경계가 다릅니다. LangChain 코드의 모양은 비슷하게 유지할 수 있어도, 데이터가 있는 위치와 인증·비용·장애 책임은 달라집니다.
Pinecone으로 바꾼다고 RAG 정확도가 자동으로 높아지지는 않습니다. 같은 문서와 Embedding을 넣어도 검색 설정과 데이터 품질을 다시 검증해야 합니다.
이 글은 시리즈 순서에 맞춰 2026년 6월 4일에 배치했습니다. API는 2026년 8월 16일 LangChain과 Pinecone 공식 문서를 기준으로 확인했습니다. Pinecone 계정이나 Index를 만들고 실제 데이터를 적재하지는 않았습니다.
Chroma와 Pinecone은 무엇이 다를까?
Chroma는 로컬 프로세스나 별도 서버 형태로 사용할 수 있습니다. 앞 글에서는 persist_directory를 지정해 한 컴퓨터 디렉터리에 저장하는 가장 작은 실습 구조를 사용했습니다.
Pinecone은 관리형 Vector Database입니다. 애플리케이션이 네트워크를 통해 Pinecone의 Index에 데이터를 쓰고 검색합니다. 서버 운영의 일부를 서비스에 맡기는 대신 계정, API Key, 네트워크와 사용량 관리가 생깁니다.
| 기준 | 로컬 Chroma 실습 | Pinecone 연결 |
|---|---|---|
| 실행 위치 | 애플리케이션과 같은 PC에 둘 수 있음 | 외부 관리형 서비스 |
| 연결 | 로컬 프로세스·파일 또는 서버 | 네트워크와 API Key |
| 여러 인스턴스 공유 | 별도 서버·동시성 설계 필요 | 같은 Index를 여러 앱이 조회 가능 |
| 운영 책임 | 저장 파일·백업·프로세스를 직접 관리 | 서비스 설정·비용·권한·장애 대응 필요 |
| 오프라인 | 로컬 구성에 따라 가능 | 네트워크 없이는 사용할 수 없음 |
이 표는 누가 무조건 우수하다는 순위가 아닙니다. 학습용 노트북과 여러 서버가 사용하는 서비스는 조건이 다릅니다.
바뀌지 않는 것부터 찾자
Vector Store를 바꿔도 RAG의 기본 질문은 같습니다.
- 어떤 원본 문서를 읽을 것인가?
- 어느 경계로 Chunk를 나눌 것인가?
- 어떤 Embedding Model을 사용할 것인가?
- 어떤 metadata와 문서 ID를 보관할 것인가?
- 정답 조각이 실제로 검색되는가?
LangChain의 장점은 이 공통 역할을 유지하는 데 있습니다. Chroma와 Pinecone 모두 add_documents, similarity_search, as_retriever 같은 익숙한 흐름으로 연결할 수 있습니다.
그러나 “메서드 이름이 비슷하다”와 “운영 특성이 같다”는 다른 말입니다.
Pinecone 연결 흐름
로컬 서랍에서 원격 Vector Index로
문서는 같은 Embedding 기준으로 변환되지만, Pinecone을 선택하면 인증과 네트워크 경계가 검색 흐름에 추가됩니다.
Vector Store는 바뀌어도 RAG 단계는 유지인증·네트워크·Index 설정·비용·데이터 이전은 새로 설계하고 평가해야 합니다.
현재 단계: 원본 준비
Index를 만들기 전에 Embedding을 정해야 하는 이유
Embedding Model은 텍스트를 일정 길이의 숫자 배열로 만듭니다. Pinecone Index는 저장할 벡터의 차원과 검색 방식을 알아야 합니다.
예를 들어 Index가 기대하는 차원과 Embedding 결과의 차원이 다르면 데이터를 넣을 수 없습니다. 차원 수는 모델마다 다르므로 인터넷 예제의 숫자를 그대로 복사하면 안 됩니다.
검색 Metric도 중요합니다. Cosine, dot product 같은 방식은 벡터를 비교하는 규칙입니다. 어떤 규칙을 쓸지는 Embedding Model의 안내와 평가 결과를 함께 봐야 합니다.
Embedding Model을 나중에 바꾸면 기존 벡터와 같은 공간이 아닐 수 있습니다. 이 경우 원본 문서를 새 모델로 다시 Embedding하고 별도 Index에서 검증한 뒤 전환하는 편이 안전합니다.
LangChain 연결 코드는 어떻게 달라질까?
현재 공식 연동은 langchain-pinecone 파트너 패키지의 PineconeVectorStore를 사용합니다. 다음 코드는 이미 만든 Pinecone Index에 연결하는 최소 학습 예제입니다.
python -m pip install -U langchain-pinecone langchain-openaiimport os
from pinecone import Pinecone
from langchain_openai import OpenAIEmbeddings
from langchain_pinecone import PineconeVectorStore
pc = Pinecone(api_key=os.environ["PINECONE_API_KEY"])
index = pc.Index(os.environ["PINECONE_INDEX_NAME"])
embeddings = OpenAIEmbeddings(
model="<Index 차원과 맞는 Embedding 모델 이름>"
)
vector_store = PineconeVectorStore(
index=index,
embedding=embeddings,
)API Key는 코드에 직접 넣지 않습니다. Index 생성 시 차원, Metric, Cloud와 Region을 선택하는 과정은 계정과 환경마다 다르므로 이 예제에서 생략했습니다.
공식 예제처럼 문서 ID를 명시해 넣을 수 있습니다.
from langchain_core.documents import Document
documents = [
Document(
page_content="축제 음식 판매는 오후 6시까지 운영한다.",
metadata={
"source": "festival-guide.txt",
"year": 2026,
"status": "active",
},
)
]
vector_store.add_documents(
documents=documents,
ids=["festival-guide-2026-hours-001"],
)고정 ID는 같은 조각을 갱신하거나 삭제할 때 기준이 됩니다. ID를 매번 무작위로 새로 만들면 재적재할 때 중복이 쌓일 수 있습니다.
이 코드는 공식 문서를 바탕으로 연결 지점을 단순화했습니다. 이 블로그 저장소에는 Python 패키지나 API Key를 추가하지 않았고, Index 생성·적재·검색을 실행하지 않았습니다.
검색은 같은 모양으로 시작할 수 있다
results = vector_store.similarity_search(
"축제 음식 판매는 몇 시까지야?",
k=3,
filter={"status": "active"},
)
for document in results:
print(document.metadata)k=3은 코드 흐름을 보여주는 가정입니다. 최적값이 아닙니다. Filter 문법과 지원 범위는 Vector Store 구현과 버전에 따라 확인해야 합니다.
특히 Filter가 인증을 대신하지는 않습니다. 서버가 확인한 사용자와 Tenant 정보를 바탕으로 검색 범위를 만들어야 합니다. 브라우저가 보낸 tenantId를 그대로 믿으면 다른 조직 문서가 섞일 수 있습니다.
Chroma 데이터를 그대로 복사하면 될까?
파일을 복사하는 방식으로는 충분하지 않습니다. 두 저장소의 내부 형식이 다르기 때문입니다. 가장 안전한 기준은 원본 문서입니다.
- 원본 문서와 버전을 확정합니다.
- 같은 Chunking 규칙으로 조각을 재생성합니다.
- 목표 Index와 맞는 Embedding Model로 변환합니다.
- 안정적인 ID와 metadata로 Pinecone에 적재합니다.
- 샘플 개수와 ID를 비교합니다.
- 고정 평가 질문으로 검색 결과를 비교합니다.
- 읽기 트래픽을 단계적으로 전환합니다.
이 과정에서 Chroma와 Pinecone 검색 결과가 완전히 같은 순서일 것이라고 가정하면 안 됩니다. Index 설정과 검색 구현이 다를 수 있으므로 정답 문서가 상위 결과에 들어오는지를 업무 기준으로 평가해야 합니다.
운영에서 새로 생기는 질문
네트워크가 끊기면 어떻게 할까?
Pinecone 검색은 외부 네트워크에 의존합니다. Timeout과 오류 메시지, 재시도 범위, 검색 실패 시 답변 거절 또는 대체 경로를 정해야 합니다.
비용은 호출 횟수만 보면 될까?
저장량, 쓰기와 검색 사용량, Embedding 비용, 데이터 이동과 운영 인력을 함께 봐야 합니다. 가격은 바뀔 수 있으므로 글에 고정 수치를 적지 않고 공식 가격·사용량 화면에서 확인해야 합니다.
문서를 삭제하면 즉시 모두 사라질까?
원본 삭제와 Vector Store 삭제는 별도 작업일 수 있습니다. 백업, 로그와 모델 제공자에게 전달된 Context까지 포함한 보존 정책을 확인해야 합니다.
관리형이면 보안도 자동인가?
아닙니다. API Key 보관, 최소 권한, 네트워크 경계, metadata 기반 범위와 서버 측 인가가 필요합니다. 검색된 문서가 외부 Chat Model로 다시 전송되는지도 별도 경계입니다.
선택 기준은 팀의 조건이다
| 질문 | Chroma를 먼저 검토할 상황 | Pinecone을 먼저 검토할 상황 |
|---|---|---|
| 실험 범위 | 한 PC의 작은 학습 | 여러 앱·인스턴스가 같은 Index 사용 |
| 네트워크 | 오프라인 또는 로컬 우선 | 외부 관리형 서비스 사용 가능 |
| 운영 인력 | 직접 저장 구조를 단순하게 유지 | Vector DB 운영 일부를 맡기고 싶음 |
| 데이터 정책 | 로컬 경계가 필수 | 승인된 외부 전송과 통제가 가능 |
| 확장 요구 | 작은 자료와 낮은 동시성 | 관리형 확장·관측 기능이 필요 |
둘을 개발용과 운영용으로 나눠 쓸 수도 있습니다. 다만 환경마다 결과가 달라지지 않도록 같은 원본, ID 규칙과 평가 Dataset을 유지해야 합니다.
세 줄 요약
- LangChain은 Chroma와 Pinecone을 비슷한 Vector Store 흐름으로 연결하지만 실행 위치와 운영 책임까지 같게 만들지는 않습니다.
- Pinecone 전환에는 API Key와 네트워크뿐 아니라 Embedding 차원·Metric·문서 ID·metadata와 재색인 계획이 필요합니다.
- 저장소를 바꾼 뒤에는 검색 순위가 같다고 가정하지 말고 고정 질문으로 정답 문서가 실제로 검색되는지 다시 평가해야 합니다.
다음 편 예고
Vector Database를 정해도 검색 품질은 문서를 넣는 방식에 따라 크게 달라집니다. 같은 질문을 “운영 반영”이라고 할 수도 있고 문서에는 “프로덕션 배포”라고 적혀 있을 수 있습니다.
다음 편 — 문서 전처리와 키워드로 검색 품질 높이기에서 검색 전에 텍스트를 어떻게 정리할지 살펴봅니다.