ChatGPT에게 자사 매뉴얼을 읽히고 싶다.

그럴 때 자주 사용되는 것이 RAG (Retrieval-Augmented Generation)입니다.

RAG는 "AI에게 지식을 암기시키는" 것이 아니라, "필요한 문서를 검색한 후 답변하는" 구조입니다.

본 기사에서는 DIY·가전 수리 정리 사이트에서 구현한 RAG를 예로 들어, 벡터 DB (Vector DB)를 사용한 검색 흐름을 소개합니다.

그 검색에 자주 사용되는 것이 문장을 Embedding (임베딩/벡터)으로 변환하고, 그 벡터를 저장·검색할 수 있는 벡터 DB (Vector DB)입니다.

DIY·가전 수리 정리 사이트(이하, 정리 사이트)에서는 수리 가이드를 벡터로 저장하여 의미 검색으로 후보를 내고, 채팅에서는 그 후보가 표시되도록 수리 상담 채팅으로서 구현하고 있습니다.

"문서를 찾은 뒤에 대답하는" 수법이 됩니다.

예를 들어:

일반적인 키워드 검색… 책장에서 "배터리"라고 적힌 책만 찾음 -
벡터 검색… "전원이 금방 꺼져"라고 질문하면, 의미 검색을 통해 배터리 관련 책을 연상하여 찾음 -
RAG… 그 책을 펼친 뒤, "이 페이지가 참고가 될 것 같습니다"라고 안내함 -

문장을 그대로 비교하는 것은 어렵기 때문에, 일단 **수치 열 (벡터 / embedding)**로 변환합니다.

OpenAI의 Embeddings API를 사용함으로써 텍스트를 벡터화할 수 있습니다.

"화면이 깜깜해" → [0.12, -0.44, 0.87, …]
"액정이 안 나와" → [0.11, -0.41, 0.90, …] ← 벡터끼리의 거리가 가까움
"배터리 교체" → [-0.55, 0.22, 0.03, …] ← 멂

이 "의미가 가까움/멂"을 고속으로 찾는 것이 **벡터 DB (또는 벡터 검색 기능이 있는 DB)**의 기능입니다.

대표 서비스:

• Pinecone / Qdrant / Weaviate 등의 전용 벡터 DB
• MongoDB Atlas의 Vector Search (기존 MongoDB 상에서 벡터 검색)

"벡터 DB를 사용한다 = RAG"는 아니지만, 의미로 문서를 찾는 RAG에서는 거의 필수적인 부품입니다.

【사전 준비: 문서를 벡터 DB로】
문서 → 텍스트 정형 / 분할 → 임베딩 (embedding) → 벡터 DB에 저장
【질문이 왔을 때】
...

흐름을 기억하려면 이 세 단어만 있으면 충분합니다.

넣기 (문서를 벡터화하여 저장) -
찾기 (질문에 가까운 문서를 벡터 DB에서 취득) -
답하기 (찾은 문서를 바탕으로 안내·생성) -

정리 사이트에서는 채팅으로 수리 가이드의 문서 검색을 수행하고 있습니다.

구성은 다음과 같습니다.

채팅에 질문
│
▼
...

기본 데이터는 MongoDB Atlas에 등록되어 있습니다.

벡터 검색용 데이터는 MongoDB Atlas의 Vector Search를 사용하고 있습니다.

채팅에서는 2단계로 API를 호출하고 있습니다.

포인트는, 채팅에서도 "절차의 전문을 LLM에게 쓰게 하지 않는" 설계로 하고 있다는 점입니다.

일반적인 RAG에서는 검색 결과(Search Results)를 그대로 LLM에게 전달하여 장문 답변을 생성하는 사례가 많이 보입니다. 하지만 이번에는 수리 절차 그 자체는 가이드 페이지로 유도하고, LLM에는 "왜 이 가이드가 참고가 되는지"에 대한 100자 정도의 보충 설명만 생성하도록 했습니다.

상세 내용은 가이드 페이지와 원본 영상으로 유도하고, LLM은 "왜 그 가이드가 참고가 되는지"에 대한 짧은 보충 설명에 머무르게 합니다.

= 검색이 주연, 생성은 조연.

이번에는 MongoDB를 이미 이용하고 있었기 때문에,

새롭게 Pinecone이나 Qdrant를 도입하지 않고,

Atlas Vector Search를 이용했습니다.

• 기존 컬렉션(Collection)을 그대로 사용할 수 있음

• 인프라가 늘어나지 않음

• 집계 파이프라인(Aggregation Pipeline)으로 완결됨

• 벡터 검색 전용 DB만큼 고기능은 아님

• 고도의 검색 튜닝은 제한적임

【넣기】 수리 가이드 문서를 벡터화하여 저장
repair_pages (MongoDB)
↓ 임베딩(Embedding)용 텍스트 생성
...

넣기

OpenAI를 통해 기존 데이터를 벡터화하여 벡터 DB에 등록합니다.

찾기

제한 사항을 두고 있습니다.

• 질문 속도 제한 (IP당 20 req / 분) (남용 방지 목적)
• 메시지 길이 상한 500자까지 수락
• 관련 가이드 취득 (기본 최대 5건, 상한 10건)

답하기

관련 가이드의 유무에 따라 내용이 달라집니다.

• 가이드 없음

• 정형 문구 "찾을 수 없었습니다..."를 반환

• 가이드 있음

• 도입 문구 + LLM에 의한 짧은 보충 설명 (100자 이내) + "아래의 가이드를 확인해 주세요"

프롬프트(Prompt) 상의 제약

• 작업 절차의 상세 내용은 쓰지 않음
• "찾을 수 없었습니다" 등 부정적인 표현은 쓰지 않음 (히트 시에만 보충 생성)
• 상세 내용은 가이드 페이지 측에서 확인하도록 유도

이는 "RAG로 장문 답변을 생성하는 것"이 아니라, 검색 결과의 안내를 LLM으로 조금 더 자연스럽게 만드는 형태입니다. 잘못된 정보(Hallucination) 리스크와 책임 범위를 억제하기 위한 판단입니다.

정리 사이트에서는 검색 결과를 LLM으로 보충하는 심플한 구성이지만, 충분히 실용적인 채팅을 구축할 수 있었습니다.

수리 사이트처럼 잘못된 정보가 리스크가 되는 서비스에서는, LLM에게 절차를 쓰게 하는 것이 아니라 검색 결과에 대한 안내 역할로 한정하는 설계가 유효하다고 생각합니다.

또한, 구현해 보면서 "RAG의 주역은 LLM이 아니라 검색"이라는 것을 느꼈습니다.

벡터 DB가 대응하는 데이터베이스의 선정도 중요한데, 이번에는 이미 MongoDB Atlas를 이용하고 있었기 때문에 Vector Search를 그대로 이용할 수 있었고, 추가로 벡터 DB를 구축할 필요가 없었습니다.

이 메커니즘은 수리 사이트뿐만 아니라, 사내 문서 검색이나 FAQ, 제품 매뉴얼 검색 등에도 응용할 수 있습니다. 문서를 적절하게 텍스트화하고, 임베딩(Embedding)을 생성하여 벡터 DB에 등록하면 동일한 사고방식으로 RAG를 구축할 수 있습니다.

이번에는 DIY·가전 수리 정리 사이트의 RAG 구현을 소개했습니다.

AI를 활용한 Web 시스템이나 RAG, OpenAI API를 이용한 기능 개발도 진행하고 있습니다. 유사한 시스템 개발에 관심이 있으시다면 프로필을 통해 언제든 편하게 문의해 주세요.

실제 동작은 여기서 확인하실 수 있습니다.