> 지난 포스팅에서는 VectorDB의 종류와 선택 기준을 다뤘습니다. 이제 도구는 준비되었으니, 실제로 **RAG(Retrieval-Augmented Generation)** 시스템을 구축해볼 차례입니다. 하지만 막상 구현해보면 생각보다 정확도가 나오지 않아 당황하게 됩니다. 오늘은 실전에서 자주 겪는 문제점들과 그 품질을 높이는 핵심 팁들을 공유합니다.

![AI Technology](https://images.unsplash.com/photo-1677442136019-21780ecad995?q=80&w=1932&auto=format&fit=crop)
*이미지 출처: Unsplash*

# 1. 문서 청킹(Chunking)의 딜레마

RAG의 첫 단계는 긴 문서를 작은 조각(Chunk)으로 자르는 것입니다. 하지만 이 "자르는 기준"이 매우 까다롭습니다.

- **문제점**: 너무 작게 자르면 문맥(Context)이 잘려서 의미를 잃고, 너무 크게 자르면 불필요한 노이즈 정보까지 포함되어 검색 정확도가 떨어집니다.
- **해결책**:
 - **의미 기반 청킹(Semantic Chunking)**: 단순히 글자 수로 자르지 말고, 문단이나 섹션 단위로 의미가 이어지도록 자릅니다.
 - **Overlap(중첩)**: 자를 때 앞뒤 문장을 10~20% 정도 겹치게 하여 문맥이 끊기는 것을 방지합니다.

# 2. 키워드 검색의 부재 (Hybrid Search)

VectorDB는 "의미"를 잘 찾지만, "정확한 단어"를 찾는 데는 약할 수 있습니다.

- **문제점**: 사용자가 "제품 모델명(ABC-123)"이나 "특정 에러 코드"를 검색했는데, VectorDB는 의미가 비슷한 엉뚱한 문서를 가져올 수 있습니다.
- **해결책**:
 - **하이브리드 검색(Hybrid Search)**: 전통적인 키워드 검색(BM25)과 벡터 검색(Dense Retrieval)을 섞어 사용합니다.
 - **Reciprocal Rank Fusion (RRF)**: 두 검색 결과의 순위를 적절히 섞어 최종 순위를 재조정합니다.

# 3. 검색 결과의 순위 문제 (Reranking)

벡터 검색으로 상위 10개를 가져왔다고 해서, 그 1번이 무조건 정답은 아닙니다.

- **문제점**: 임베딩 모델은 범용적이기 때문에, 우리 도메인의 특수한 뉘앙스를 완벽히 구분하지 못할 수 있습니다.
- **해결책**:
 - **리랭커(Reranker) 도입**: 초벌 검색으로 50~100개를 빠르게 가져온 뒤, 더 정교한(하지만 느린) Cross-Encoder 모델을 사용해 순위를 다시 매깁니다.
 - 이 과정을 거치면 LLM에게 전달되는 문서(Context)의 품질이 비약적으로 상승합니다.

# 마치며: 은탄환은 없다

RAG는 단순히 DB만 붙인다고 완성되는 것이 아닙니다. 데이터의 전처리부터 검색 전략, 그리고 프롬프트 엔지니어링까지 꼼꼼하게 튜닝해야 원하는 성능을 얻을 수 있습니다.

이 시리즈를 통해 VectorDB의 개념부터 도구 선택, 그리고 실전 팁까지 알아보았습니다. 여러분의 AI 서비스 구축에 도움이 되었기를 바랍니다! 🚀

RAG(검색 증강 생성) 시스템 구축 시 마주하는 3가지 난관과 해결책

# 들어가며

지난 포스팅에서 우리는 VectorDB가 무엇이고 왜 AI 시대에 필수적인지 알아보았습니다. 개념을 이해했다면 이제 **"그래서 도대체 무엇을 써야 하는데?"** 라는 질문에 부딪히게 됩니다.

시중에는 수많은 VectorDB가 존재하며, 각각의 장단점이 뚜렷합니다. 이번 글에서는 대표적인 VectorDB들을 유형별로 살펴보고, 여러분의 프로젝트에 딱 맞는 도구를 선택하는 기준을 제시해 드립니다.

---

# 전용 VectorDB (Specialized)

벡터 검색만을 위해 처음부터 설계된 데이터베이스들입니다. 성능과 특화 기능이 뛰어납니다.

## 1. Pinecone
- **특징**: 완전 관리형(SaaS) 서비스입니다. 인프라 관리가 전혀 필요 없습니다.
- **장점**: 구축이 매우 쉽고 빠릅니다. 스케일링이 자동화되어 있어 운영 부담이 적습니다.
- **단점**: 오픈소스가 아니며, 데이터 양이 많아지면 비용이 비싸질 수 있습니다. 데이터를 외부에 저장해야 한다는 보안 우려가 있을 수 있습니다.
- **추천**: 빠르게 프로토타입을 만들어야 하거나, 인프라 운영 인력이 부족한 스타트업.

## 2. Milvus
- **특징**: 대규모 데이터를 처리하기 위해 설계된 고성능 오픈소스 VectorDB입니다.
- **장점**: 수십억 개의 벡터를 처리할 수 있는 확장성(Scalability)을 자랑합니다. 기능이 매우 풍부합니다.
- **단점**: 쿠버네티스(k8s) 기반으로 운영하는 것이 권장될 정도로 배포와 관리가 복잡할 수 있습니다.
- **추천**: 대규모 트래픽과 데이터를 다루는 엔터프라이즈 환경.

## 3. Chroma
- **특징**: 개발자 경험(DX)을 최우선으로 하는 오픈소스 DB입니다.
- **장점**: `pip install chromadb` 하나면 설치 끝. 로컬 파일 기반으로 가볍게 시작할 수 있고 사용이 매우 직관적입니다.
- **단점**: 대규모 분산 처리는 Pinecone이나 Milvus에 비해 아직 성숙도가 낮을 수 있습니다.
- **추천**: 개인 프로젝트, 사이드 프로젝트, 로컬 테스트 환경.

---

# 통합형 VectorDB (Integrated)

기존에 쓰던 데이터베이스에 벡터 검색 기능을 추가한 형태입니다. 새로운 인프라를 도입하지 않아도 된다는 강력한 장점이 있습니다.

## 1. pgvector (PostgreSQL)
- **특징**: 전 세계에서 가장 사랑받는 RDBMS인 PostgreSQL의 확장 플러그인입니다.
- **장점**: 기존의 관계형 데이터와 벡터 데이터를 **하나의 쿼리(SQL)**로 조인해서 가져올 수 있습니다. 트랜잭션, 백업 등 RDBMS의 안정성을 그대로 누립니다.
- **단점**: 전용 DB에 비해 벡터 검색 성능(인덱싱 속도 등)이 약간 떨어질 수 있습니다.
- **추천**: 이미 PostgreSQL을 쓰고 있고, 메타데이터 필터링이 복잡하게 필요한 서비스.

## 2. Elasticsearch / OpenSearch
- **특징**: 검색 엔진의 제왕들답게 강력한 벡터 검색 기능을 탑재했습니다.
- **장점**: 기존의 키워드 검색(BM25)과 벡터 검색(Dense Retrieval)을 결합한 **하이브리드 검색(Hybrid Search)** 구현에 최적화되어 있습니다.
- **단점**: 리소스를 많이 잡아먹고(Memory Heavy), 운영 난이도가 꽤 높습니다.
- **추천**: 기존에 검색 엔진을 이미 운영 중이거나, 키워드 검색과 벡터 검색을 정교하게 섞어야 하는 경우.

---

# 선택 가이드: 요약

결국 정답은 없습니다. 상황에 맞춰 골라보세요.

1. **"나는 인프라 관리 귀찮고, 돈으로 시간을 사겠다."** 👉 **Pinecone**
2. **"나는 PostgreSQL 덕후고, 기존 데이터랑 같이 조회해야 한다."** 👉 **pgvector**
3. **"토이 프로젝트 중인데, 지금 당장 내 노트북에서 돌리고 싶다."** 👉 **Chroma**
4. **"수천만 건 이상의 데이터를 다루는 대형 서비스를 만든다."** 👉 **Milvus**

---

# 마치며

도구를 선택했다면, 이제 데이터를 어떻게 벡터로 변환(Embedding)하고 어떻게 검색 품질을 높일지 고민할 차례입니다.
다음 포스팅에서는 **"RAG(검색 증강 생성) 시스템을 실제로 구현할 때 겪게 되는 문제점과 해결 팁"**에 대해 다뤄보겠습니다.

어떤 VectorDB를 써야 할까? (Pinecone, Milvus, Chroma, pgvector 비교)

> 최근 ChatGPT와 같은 생성형 AI(Generative AI)가 급부상하면서, 함께 주목받고 있는 기술이 있습니다. 바로 VectorDB(벡터 데이터베이스)입니다. 
기존의 관계형 데이터베이스(RDBMS)가 있는데 왜 새로운 형태의 데이터베이스가 필요해진 걸까요? 
오늘은 개발자 관점에서 VectorDB의 핵심 개념과 특징, 그리고 왜 지금 이 기술이 중요한지에 대해 정리해 보겠습니다.

# VectorDB란?

1. **VectorDB**는 텍스트, 이미지, 오디오와 같은 비정형 데이터를 **벡터(Vector)** 형태, 즉 고차원의 숫자 배열로 변환하여 저장하고 검색하는 데 특화된 데이터베이스입니다.

2. 전통적인 데이터베이스가 `WHERE title = '검색어'`와 같이 키워드 일치(Exact Match)를 찾는다면, VectorDB는 데이터의 의미적 유사성(Semantic Similarity)을 기반으로 검색을 수행합니다.
 

# 핵심 원리: 벡터 임베딩 (Vector Embedding)

컴퓨터는 "사과"라는 단어의 맛이나 모양을 이해하지 못합니다. 대신 AI 모델을 통해 이 데이터를 다차원 공간의 좌표(숫자 리스트)로 변환하는데, 이것을 임베딩(Embedding)이라고 합니다.

* **의미 공간(Semantic Space):** 의미가 비슷한 데이터들은 벡터 공간상에서 서로 가까운 거리에 위치하게 됩니다.
* **예시:**
 * '왕(King)' - '남자(Man)' + '여자(Woman)' = '여왕(Queen)'
 * '강아지'는 '고양이'와 가깝게, '자동차'와는 멀리 위치합니다.

> ![maxresdefault](https://librarian-blog-images.s3.ap-northeast-2.amazonaws.com/b1f67aaf-ccd0-457b-85a2-4688859f7f8d_maxresdefault.jpg)

 

# 기존 DB(RDBMS) vs VectorDB

가장 큰 차이점은 데이터를 바라보는 관점과 검색 방식에 있습니다.

| 특징 | 관계형 데이터베이스 (RDBMS) | 벡터 데이터베이스 (VectorDB) |
| :--- | :--- | :--- |
| **저장 단위** | 행(Row)과 열(Column) | 고차원 벡터 (Embeddings) |
| **검색 방식** | 키워드 매칭, 정확한 값 비교 | 유사도 검색 (Similarity Search) |
| **쿼리 예시** | `SELECT * FROM items WHERE name LIKE '%아이폰%'` | "최신 스마트폰 추천해줘" (의미 기반 검색) |
| **결과** | '아이폰' 단어가 포함된 결과만 반환 | 갤럭시, 픽셀 등 문맥상 유사한 결과 포함 |

 

# 왜 지금 VectorDB인가? (feat. RAG)

VectorDB가 필수 인프라로 떠오른 가장 큰 이유는 **LLM(거대언어모델)의 한계**를 보완해주기 때문입니다.

* **RAG (검색 증강 생성):** LLM은 학습하지 않은 최신 정보나 기업 내부의 사내 데이터는 알지 못합니다. 또한 사실이 아닌 정보를 진실인 것처럼 말하는 '환각(Hallucination)' 현상이 발생하기도 합니다.
* **해결책:** VectorDB에 우리만의 지식 데이터를 벡터화하여 저장해 둡니다. 사용자가 질문을 하면 VectorDB에서 가장 유사한 근거 자료를 찾아와 LLM에게 전달하고, LLM은 그 정보를 바탕으로 정확한 답변을 생성합니다.


 

# 마치며

VectorDB는 단순한 저장소를 넘어, AI가 데이터의 맥락(Context)을 이해하도록 돕는 핵심 기술입니다.

다음 포스팅에서는 VectorDB의 종류와 구체적인 내용들을 좀 더 심도있게 다뤄보겠습니다.

VectorDB

이 주제의 기록

RAG(검색 증강 생성) 시스템 구축 시 마주하는 3가지 난관과 해결책

어떤 VectorDB를 써야 할까? (Pinecone, Milvus, Chroma, pgvector 비교)

AI 시대의 필수 데이터베이스, VectorDB(벡터 DB)란 무엇인가?