사내 문서를 찾는 데 시간이 얼마나 드나요?
생각보다 많습니다. McKinsey Global Institute의 2012년 보고서는 지식 근로자가 업무 시간의 약 20%를 사내 정보를 찾거나 도움 줄 동료를 찾는 데 쓴다고 추정했습니다. 오래된 조사라 지금 회사에 그대로 적용할 수는 없지만, 위키 검색으로 못 찾아 결국 옆 사람에게 묻는 일은 지금도 흔합니다.
예를 들어 직원 50명, 평균 연봉 5,000만 원인 회사에서 업무 시간의 5%만 문서 찾기에 쓴다고 가정해도 연 1억 2,500만 원어치 시간입니다. RAG(Retrieval-Augmented Generation) 시스템은 이 시간을 줄이기 위한 방법입니다.
RAG란 무엇인가요?
RAG는 질문과 관련된 문서를 먼저 검색(Retrieval) 하고, 찾은 내용을 근거로 LLM이 답변을 생성(Generation) 하는 방식입니다.
문서 링크 목록을 주는 대신 문서 내용을 요약해 답하고, 어떤 문서의 어느 부분을 근거로 했는지 출처를 함께 보여 줍니다. 모델을 다시 학습시키지 않으므로 문서가 바뀌면 인덱스만 갱신하면 됩니다.
| 구분 | 키워드 검색 | FAQ 챗봇 | RAG 시스템 |
|---|---|---|---|
| 검색 방식 | 키워드 매칭 | 사전 등록 Q&A | 하이브리드 검색 + 리랭킹 |
| 답변 형태 | 문서 목록 | 고정 답변 | 출처가 달린 자연어 답변 |
| 유지보수 | 태그·메타데이터 관리 | Q&A 수동 갱신 | 문서 변경 시 재색인 |
| 한계 | 표현이 다르면 못 찾음 | 등록된 질문만 대응 | 검색 품질이 답변 품질을 좌우 |
RAG 시스템은 어떻게 구성되나요?
수집·전처리, 색인, 검색, 생성의 4단계로 구성됩니다. 2026년 기준으로 각 단계에서 기본으로 챙기는 항목은 다음과 같습니다.
1. 수집·전처리
Notion, Confluence, Google Drive, SharePoint, PDF, 사내 위키 등에서 문서를 가져와 텍스트를 추출하고 청크로 나눕니다. 이때 문서별 접근 권한, 작성일, 부서 같은 메타데이터를 반드시 함께 저장합니다. 스캔 PDF와 표가 많은 문서는 파싱 품질이 전체 성능을 좌우하므로 따로 점검합니다.
2. 색인: 하이브리드 + 문맥 보강
임베딩 벡터 색인과 BM25 같은 키워드 색인을 함께 만듭니다. 벡터 검색은 표현이 달라도 의미가 비슷한 문서를 찾고, 키워드 검색은 제품 코드, 사람 이름, 조항 번호처럼 정확히 일치해야 하는 단어를 잘 찾습니다.
Anthropic이 2024년 공개한 Contextual Retrieval은 각 청크 앞에 "이 청크가 문서 전체에서 어떤 내용인지"를 짧게 붙여 색인하는 방법입니다. Anthropic 실험에서는 문맥 임베딩과 문맥 BM25를 함께 쓰면 검색 실패율이 49% 줄었고, 리랭킹까지 더하면 67% 줄었습니다.
3. 검색: 권한 필터 + 리랭킹
검색 시 질문한 사람의 권한으로 볼 수 있는 문서만 대상으로 필터링합니다(permission-aware retrieval). 이후 리랭커 모델로 후보 문서를 다시 정렬해 상위 몇 개만 LLM에 넘깁니다.
4. 생성: 출처 표시와 거절
LLM에는 "제공된 문서에 근거가 없으면 모른다고 답하라"고 지시하고, 답변 문장마다 출처 문서를 연결합니다. 사용자가 원문을 바로 확인할 수 있어야 신뢰가 쌓입니다.
권한 설계를 나중에 하면 안 됩니다. 인사·급여·계약 문서까지 한 인덱스에 넣고 권한 필터 없이 검색하면, 볼 수 없는 문서 내용이 답변으로 노출될 수 있습니다. 개인정보가 포함된 문서는 개인정보보호법상 안전조치 대상이므로 수집 범위부터 정해야 합니다.
벡터 DB는 무엇을 골라야 하나요?
이미 PostgreSQL을 쓰고 문서 규모가 크지 않다면 pgvector, 운영 부담을 줄이려면 관리형, 셀프 호스팅이 필요하면 Qdrant·Weaviate가 일반적인 선택입니다.
| 항목 | Pinecone | Weaviate | Qdrant | Chroma | pgvector |
|---|---|---|---|---|---|
| 유형 | 관리형 SaaS | 오픈소스 + 클라우드 | 오픈소스 + 클라우드 | 오픈소스 | PostgreSQL 확장 |
| 하이브리드 검색 | 지원 | 지원 | 지원 | 제한적 | 전문 검색과 조합 |
| 셀프 호스팅 | 불가 | 가능 | 가능 | 가능 | 가능 |
| 추천 상황 | 운영 인력이 없을 때 | 하이브리드 검색 중심 | 성능·필터링 중시 | 프로토타입 | 기존 PostgreSQL 활용 |
요금은 수시로 바뀌므로 공식 요금표를 확인해야 합니다. 2026년 10월 공식 요금표 기준으로 Pinecone Standard는 월 최소 $50부터 사용량 과금이 붙고, Qdrant Cloud는 1GB RAM 단일 노드 무료 등급을 제공합니다. pgvector는 기존 DB 비용 외 추가 라이선스 비용이 없습니다.
실전 추천: 첫 단계는 pgvector + PostgreSQL 전문 검색으로 하이브리드 검색을 구성해도 충분한 경우가 많습니다. 문서량과 동시 사용자가 늘어 응답 속도가 문제가 될 때 전용 벡터 DB로 옮겨도 늦지 않습니다.
청킹은 어떻게 나눠야 하나요?
문서 구조를 살려서 나누는 것이 기본입니다. 청킹 방식은 검색 품질에 큰 영향을 주며, 정답은 문서 종류마다 다르므로 평가로 정해야 합니다.
- 1고정 길이 청킹: 가장 간단하지만 문장·표가 중간에 끊깁니다.
- 2문단·제목 기반 청킹: 제목과 문단 경계를 따라 나눕니다. 대부분의 사내 문서에 적합한 출발점입니다.
- 3시맨틱 청킹: 문장 간 의미 변화를 기준으로 나눕니다. 구현이 복잡하고 효과는 문서에 따라 다릅니다.
- 4계층형(부모-자식) 청킹: 작은 청크로 검색하고, LLM에는 그 청크가 속한 상위 섹션을 넘깁니다. 정확도와 문맥을 함께 챙길 수 있습니다.
청크 길이는 수백 토큰 수준에서 시작해 평가 결과를 보며 조정하세요. 표는 행이 잘리지 않도록 표 단위로 청크를 만들고, 청크마다 문서 제목과 섹션 제목을 붙여 두면 검색 품질이 안정됩니다.
성과는 어떻게 측정하나요?
도입 전에 평가 질문 세트를 먼저 만듭니다. 실제 직원 질문 50~100개와 정답 문서를 짝지어 두고, 다음 지표를 정기적으로 측정합니다.
- 검색 정확도: 정답 문서가 상위 몇 개 안에 들어오는 비율(Recall@k)
- 답변 정확도·근거성: 답변이 출처 문서 내용과 일치하는지
- 거절 정확도: 근거가 없는 질문에 모른다고 답하는지
- 현업 지표: 질문 수, 재질문 비율, 담당자에게 넘어간 문의 수
모델이나 청킹을 바꿀 때마다 같은 세트로 다시 측정해야 개선인지 퇴보인지 판단할 수 있습니다.
구축 비용은 얼마나 드나요?
비용은 크게 구축비, 색인 비용, 운영비로 나뉩니다. 구축비는 연결할 문서 소스 수, 권한 연동 범위, 파싱이 어려운 문서 비율에 따라 가장 크게 달라집니다.
| 항목 | 비용을 좌우하는 요소 |
|---|---|
| 초기 구축 | 문서 소스 수, 권한 연동, 스캔·표 문서 비율, 사용 채널(Slack·웹 등) |
| 임베딩 생성 | 문서 총량. OpenAI text-embedding-3-small은 2026년 10월 공식 요금표 기준 100만 토큰당 $0.02 |
| 벡터 DB | 관리형 요금 또는 서버 비용 |
| LLM API | 질문 수 × 질문당 토큰. 사용량이 늘수록 증가 |
| 유지보수 | 재색인, 평가 재실행, 프롬프트·모델 교체 |
임베딩 API 자체 비용은 대체로 작고, 실제 비용은 문서 정리와 파싱, 권한 연동 작업에서 발생합니다. 운영 중 가장 크게 늘어나는 항목은 LLM API 비용입니다.
LLM 비용 관리: 직원들이 많이 쓸수록 비용이 늘어납니다. 자주 묻는 질문 답변 캐싱, 프롬프트 캐싱, 쉬운 질문은 작은 모델로 보내는 라우팅, 리랭킹으로 LLM에 넘기는 문서 수 줄이기가 대표적인 절감 방법입니다.
결론
RAG는 모델 선택보다 문서 품질, 검색 설계, 권한, 평가가 성패를 가릅니다. 하나의 문서 소스(예: Notion)와 하나의 채널(예: Slack 봇)로 시작해, 평가 질문 세트로 정확도를 확인한 뒤 범위를 넓히세요.
미라클스튜디오는 RAG 구축 후 납품 후 90일 무상 하자 보수를 제공하고, 대금 정산 후 소스코드를 이관해 드립니다. 30분 무료 상담에서 우리 회사 문서에 맞는 구성을 함께 정리해 드립니다.
