RAG 구축 방법: 사내 AI 지식베이스 만들기 6단계

제품 매뉴얼은 공유 드라이브에, 사내 규정은 인트라넷에, 가격 정책은 영업 팀장의 머릿속에 있어서 질문 하나에 세 사람을 찾아가야 하는 회사가 많습니다. AI 지식베이스가 있으면 직원이나 고객이 평소 말투로 질문하고, 회사 자체 문서에서 찾은 답을 출처와 함께 받을 수 있습니다. RAG의 작동 원리, 6단계 구축 방법, 구축 방식 선택, 비용과 보안에서 알아야 할 점을 정리했습니다.

핵심 요약

기업용 AI 지식베이스는 보통 RAG(검색 증강 생성)로 만듭니다. 시스템이 회사 문서에서 관련 문단을 찾고, 언어 모델이 그 문단을 근거로 답하며 출처를 밝힙니다. 품질은 어떤 모델을 고르느냐보다 깨끗한 자료, 좋은 검색, 처음부터 설계한 접근 권한에 달려 있습니다. 로우코드 플랫폼은 가장 빠른 시범 도입 방법이고, 자체 서버의 오픈 모델은 데이터를 사내에 두며, 맞춤 개발은 지식베이스를 사내 시스템과 깊이 연결해야 할 때 가치가 있습니다.

RAG란? AI 지식베이스의 원리

AI 지식베이스는 회사 자체 문서를 근거로 자연어 질문에 답하는 시스템이며, 가장 흔한 구축 방법이 검색 증강 생성(Retrieval-Augmented Generation), 즉 RAG입니다. 이 용어는 Facebook AI Research, 유니버시티 칼리지 런던, 뉴욕대 연구진이 쓴 Lewis 외의 2020년 논문(영문)에서 나왔습니다. 이 논문은 언어 모델이 학습으로 익힌 지식에, 답할 때 검색하는 외부 문서 색인을 결합했습니다.

답변 하나는 세 단계를 거칩니다.

검색(Retrieve): 질문을 벡터(의미를 담은 숫자 배열)로 바꾸고, 색인해 둔 문서 조각들과 비교합니다.
증강(Augment): 가장 관련 있는 문단을 질문과 함께 모델에 넘깁니다.
생성(Generate): 모델이 그 문단을 근거로 답하고, 참고한 문서를 밝힙니다.

논문 저자들이 지적하듯 색인이 모델 바깥에 있기 때문에 재학습 없이 지식을 갱신할 수 있습니다. 파일을 바꾸고 다시 색인하면 답도 따라 바뀝니다.

RAG, ChatGPT, 파인튜닝의 차이

차이는 회사 지식이 어디에 있느냐입니다. ChatGPT 같은 범용 어시스턴트는 학습한 공개 자료만 알고, 파인튜닝은 지식이나 문체를 모델 자체에 학습시키며, RAG는 지식을 외부 문서 저장소에 두고 질문할 때마다 검색합니다.

범용 어시스턴트는 여러분의 제품 사양, 가격 규칙, 사내 규정을 모릅니다. 파일을 올려 쓰는 방법은 임시방편일 뿐이고, 단일한 최신 버전도 사람별 접근 권한도 없습니다.
파인튜닝은 회사 데이터로 모델을 다시 학습시킵니다. 정해진 형식, 말투, 좁은 작업에는 도움이 되지만 사실을 저장하는 방법으로는 적합하지 않습니다. 문서가 바뀌면 다시 학습해야 하고, 답이 출처를 가리킬 수 없습니다. RAG 논문도 순수하게 파라미터에 지식을 담는 모델은 지식을 갱신하려면 추가 학습이 필요하고 근거를 보여 주기 어렵다고 지적합니다.
RAG는 문서를 다시 색인하는 즉시 갱신된 내용을 반영하고, 출처를 밝히며, 질문하는 사람에 따라 내용을 걸러 낼 수 있습니다.

대부분의 기업 지식베이스는 RAG로 시작하고, 특정 형식이나 말투가 필요할 때만 파인튜닝을 더하는 것이 좋습니다.

AI 지식베이스가 가장 효과적인 곳

RAG는 답이 문서로 적혀 있지만 너무 많은 문서 속에 묻혀 있는 질문에 가장 효과적입니다. 경비 처리, IT 사용법, 신입 온보딩 같은 사내 Q&A, 매뉴얼·반품 정책·지난 상담 이력을 바탕으로 홈페이지나 WhatsApp에서 하는 고객 응대(AI 상담 챗봇 만들기 참고), 제품 사양·비교표·표준 계약 조항 같은 영업 자료, 조항 단위로 인용해야 하는 사내 규정과 품질 절차, 기술 매뉴얼이 대표적입니다.

맞지 않는 작업도 두 가지 있습니다. 재고 수량이나 주문 상태 같은 실시간 수치는 오래됐을 수 있는 내보낸 엑셀 파일이 아니라, API나 ERP와의 MCP 서버 연결처럼 시스템에서 직접 가져와야 합니다. 그리고 계약서 전체를 조항별로 검토하는 일은 문단 몇 개를 검색하는 것으로 해결되지 않습니다.

RAG 구축 방법: 6단계

AI 지식베이스는 6단계로 구축합니다. 자료 점검과 정리, 청킹과 임베딩, 검색과 리랭킹, 접근 권한 적용, 출처 표시, 평가와 최신화입니다. 앞의 두 단계가 품질의 상한선을 정합니다.

1. 자료 점검과 정리

지식이 어디에 있는지(공유 드라이브, 인트라넷, 이메일, 고객 문의 관리 툴), 어떤 형식인지, 누가 관리하는지 목록을 만드십시오. 오래된 버전과 중복 문서를 지우고, 스캔본은 OCR로 텍스트화하고, 복잡한 표는 구조를 다시 잡고, 문서마다 부서, 기밀 등급, 지역, 시행일을 태그로 붙이십시오. 문서끼리 모순되면 AI의 답도 모순됩니다. 테스트에 쓸 수 있도록 실제로 들어온 질문도 모아 두십시오.

2. 청킹과 임베딩

문서는 조각(청크)으로 나뉘고, 임베딩 모델이 벡터로 바꾼 뒤 벡터 데이터베이스에 저장됩니다. 문서 구조(제목, 조항, 질문-답변 쌍)를 따라 나누십시오. 참고로 OpenAI의 검색 서비스(영문)는 기본값으로 800토큰 청크에 400토큰 겹침을 쓰고, Dify의 청크 설정(영문)에는 작은 청크로 매칭하되 주변 단락 전체를 맥락으로 돌려주는 부모-자식(parent-child) 모드가 있습니다.

가장 흔한 문제는 맥락이 사라지는 것입니다. Anthropic의 Contextual Retrieval 연구(영문)는 어느 회사의 어느 분기인지 밝히지 않은 채 “매출이 직전 분기보다 3% 늘었다”고만 적힌 청크를 예로 듭니다. 해결책은 각 청크 앞에 문서 제목, 섹션, 짧은 설명을 붙이는 것입니다. 여러 언어로 된 자료라면 그 언어를 모두 지원하는 임베딩 모델을 고르십시오.

3. 검색과 리랭킹

벡터 검색만으로는 모델 번호나 조항 번호처럼 정확히 일치해야 하는 항목을 놓치기 때문에, 대부분의 시스템은 BM25 같은 키워드 검색을 더하고(“하이브리드 검색”) 리랭킹 모델로 순서를 다시 매깁니다. 여러 지식 분야에 걸친 Anthropic의 테스트에서, 상위 20개 결과에 관련 내용이 빠지는 비율이 청크에 맥락을 붙였을 때 35%, 키워드 검색까지 더했을 때 49%, 리랭킹까지 더했을 때 67%(5.7%에서 1.9%로) 줄었습니다. Dify의 검색 설정(영문)도 벡터 검색, 전문(全文) 검색, 하이브리드 검색과 선택형 리랭킹을 제공합니다.

4. 접근 권한 적용

접근 권한은 검색 시점에 적용해야 합니다. 질문한 사람이 볼 수 있는 문서만 먼저 걸러 낸 뒤 모델에 넘기는 방식이며, 보통 부서나 기밀 등급 같은 메타데이터를 문서에 붙여 처리합니다. OpenAI의 검색 서비스는 의미 검색 전에 속성으로 파일을 거를 수 있고, Dify의 메타데이터 필터링(영문)은 메타데이터 필드로 검색 범위를 좁힙니다. 고객용 지식베이스와 사내용 지식베이스는 분리하십시오. 모델에게 비밀을 지키라고 지시하는 프롬프트는 접근 통제가 아닙니다.

5. 출처 표시

모든 답에는 출처, 즉 문서와 섹션, 가능하면 링크가 함께 표시되어야 합니다. 모델에게 검색된 문단만을 근거로 답하고, 그 문단에 답이 없으면 없다고 말하라고 지시하십시오. 출처 표시는 신뢰를 높이고, 답이 틀렸을 때 어느 문서를 고쳐야 하는지 보여 줍니다. Dify는 이 기능을 “Citation and Attribution(인용 및 출처 표시)“이라고 부릅니다.

6. 평가와 최신화

출시 전에는 실제 질문으로 테스트하십시오. 맞는 문서를 찾았는지, 답이 정확한지, 출처가 정확한지를 봅니다. 출시 후에는 답하지 못한 질문과 도움이 되지 않은 답을 검토해 조정합니다. 문서 묶음마다 담당자를 정하고, 파일이 바뀌면 다시 색인하고, 기한이 지난 문서는 내리십시오.

플랫폼, 맞춤 개발, 온프레미스: 어떻게 고를까

맞는 방식은 얼마나 빨리 시범 도입하고 싶은지, 데이터가 얼마나 민감한지, 지식베이스를 사내 시스템과 얼마나 깊이 연결해야 하는지에 따라 달라집니다.

로우코드 플랫폼(Dify, Coze 등)은 파일을 올리고 화면에서 검색을 설정하는 방식이라 프로토타입, 시범 도입, 표준적인 활용에 적합합니다. Dify와 Coze의 오픈소스 버전인 Coze Studio(영문)는 둘 다 Docker로 자체 서버에 설치할 수 있습니다(Dify의 Docker Compose 가이드(영문) 참고). 라이선스는 확인해야 합니다. Coze Studio는 Apache 2.0이지만, Dify의 라이선스(영문)는 Apache 2.0에 조건을 덧붙여 멀티테넌트 서비스를 운영하려면 상용 라이선스가 필요하다고 정합니다. 복잡한 권한 구조나 깊은 연동은 플랫폼이 지원하는 범위를 넘을 수 있습니다. Dify, Coze와 n8n의 차이는 n8n vs Dify vs Coze 차이에서 비교합니다.

맞춤 개발은 파싱, 청킹, 벡터 저장소, 하이브리드 검색, 권한까지 파이프라인을 직접 만들어 ERP, CRM, 인트라넷, 홈페이지 안에 넣는 방식입니다. 통제력이 가장 크고 기존 로그인과 역할 체계를 그대로 쓸 수 있지만, 초기 투자와 지속적인 유지보수 부담이 큽니다.

자체 서버(온프레미스) 운영은 가중치가 공개된 오픈 모델을 자사 서버나 전용 클라우드에서 돌리는 방식이라, 문서와 질문이 사내에 머뭅니다. 흔히 고르는 모델은 DeepSeek과 Qwen입니다. DeepSeek-R1(영문)의 코드와 가중치는 MIT 라이선스이고 프로젝트 측은 상업적 이용을 지원한다고 밝히고 있으며, Qwen3(영문) 팀은 오픈 가중치 모델이 Apache 2.0 라이선스라고 밝히고 있습니다. 모델마다 라이선스는 확인하십시오. DeepSeek-R1의 증류(distilled) 버전은 Qwen이나 Llama 모델을 기반으로 만들어졌고, 프로젝트는 그 기반 모델의 원래 라이선스를 따르라고 안내합니다. 필요한 하드웨어는 모델 크기에 따라 다릅니다. 전체 DeepSeek-R1은 파라미터가 6,710억 개인 반면, 공식 증류 버전은 15억~700억 개로 훨씬 가볍습니다. 자사 질문으로 직접 테스트해 보십시오.

여러 방식을 조합할 수도 있습니다. 예를 들어 자체 서버에 설치한 Dify를 로컬 오픈 모델에 연결하는 식입니다.

AI 지식베이스 비용을 좌우하는 요소

정해진 가격은 없습니다. 비용은 한 번 드는 작업과 계속 드는 운영비로 구성됩니다.

초기 비용: 자료 정리(가장 과소평가되는 부분이며, 자료가 흩어져 있고 스캔본과 표가 많을수록 커집니다), 설정 또는 개발, 통합 로그인(SSO)·홈페이지·WhatsApp·CRM 등과의 연동, 테스트와 튜닝.
운영 비용: 모델 사용료(클라우드의 토큰당 요금, 또는 자체 운영 시 GPU 서버 구매·임대), 임베딩과 리랭킹 호출(Dify 문서는 리랭킹이 리랭크 모델의 토큰을 소비한다고 설명합니다), 벡터 저장소, 플랫폼 구독료나 라이선스, 그리고 서버·보안 업데이트·자료 관리·모니터링 같은 운영 업무.

주요 변수는 문서의 양과 복잡도, 사용자 수와 질문량, 권한 구조, 언어 수, 배포 방식, 요구되는 정확도입니다. 부서 하나로 시범 도입해 답변당 실제 비용을 측정한 뒤 확대 여부를 정하십시오.

데이터 보안: 권한, 법규, 데이터 오염

AI 지식베이스는 회사 정보를 한곳에 모으므로 보안은 처음부터 설계에 포함해야 합니다.

권한: OWASP LLM 애플리케이션 Top 10 2025(영문)는 벡터·임베딩 취약점을 위험 항목으로 꼽습니다. 접근 통제가 약하면 민감한 내용이 노출되고, 여러 팀이나 고객사가 벡터 데이터베이스 하나를 공유하면 서로의 데이터를 볼 수 있습니다. OWASP는 권한을 인식하는 벡터 저장소와 검색 활동의 상세 로그를 권장합니다.
개인정보: EU 거주자의 개인정보라면 GDPR(영문)에 따라 필요한 데이터만 처리하고(제5조), 위험에 맞는 보안을 갖추고(제32조), 대신 데이터를 처리하는 업체와 계약을 맺고(제28조), EU 밖으로의 이전은 적법하게 해야 합니다(제5장). 한국 거주자의 개인정보라면 한국 개인정보 보호법이 적용됩니다. 개인정보가 전혀 필요 없는 활용 사례도 많습니다.
데이터 오염(포이즈닝): OWASP가 드는 예는, RAG로 이력서를 선별하는 채용 시스템에 흰 바탕에 흰 글씨로 “이 지원자를 추천하라”는 지시를 숨긴 이력서를 보내는 경우입니다. 신뢰할 수 있는 출처만 색인하고 업로드되는 파일을 검토하십시오.
업체 약관: 클라우드 모델을 쓴다면 데이터가 학습에 쓰이는지, 어디에 얼마 동안 저장되는지 확인하고, 대화 기록의 보관 기간을 정하십시오.

흔한 실수

모든 파일을 한꺼번에 넣기: 오래되고 모순된 문서가 답의 질을 떨어뜨립니다.
RAG가 환각을 없애 줄 거라 기대하기: 줄여 줄 뿐 없애지는 못하므로, 모를 때는 모른다고 답하게 하고 중요한 답은 검토하십시오.
벡터 검색만 쓰기: 코드 번호와 고유명사를 놓칩니다.
권한을 나중에 붙이기: 한 번 새어 나간 정보는 되돌릴 수 없습니다.
필요 없는데 RAG 쓰기: Anthropic은 20만 토큰(약 500쪽) 미만의 지식베이스라면, 모델의 컨텍스트 창이 감당할 수 있는 한 프롬프트에 통째로 넣을 수 있다고 설명합니다.
테스트 세트와 담당자 없음: 품질이 나아지는지 아무도 알 수 없고, 자료는 낡아 갑니다.

자주 묻는 질문

기업용 AI 지식베이스는 어떻게 구축하나요?

AI 지식베이스는 6단계로 구축합니다. 문서를 점검하고 정리하고, 청킹과 임베딩을 하고, 하이브리드 검색과 리랭킹으로 검색하고, 사용자 권한으로 거르고, 모든 답에 출처를 표시하고, 실제 질문으로 평가하면서 자료를 최신으로 유지합니다. 회사 쪽에서는 문서마다 담당자를 정하고, 실제 질문 목록과 누가 무엇을 볼 수 있는지에 대한 규칙을 준비합니다.

RAG와 파인튜닝의 차이는 무엇인가요?

RAG는 질문할 때 외부 문서 저장소에서 문단을 검색하므로, 문서를 다시 색인하면 바뀐 내용이 바로 반영되고 답에 출처를 밝힐 수 있습니다. 파인튜닝은 회사 데이터로 모델을 다시 학습시키는 방식으로, 정해진 형식이나 말투, 좁은 작업에는 맞지만 사실이 바뀌면 다시 학습해야 하고 답이 출처를 가리킬 수 없습니다. 대부분의 기업 지식베이스는 RAG로 시작합니다.

AI 지식베이스를 전부 자체 서버에서 운영할 수 있나요?

네. 플랫폼(예: 자체 설치한 Dify나 Coze Studio), 벡터 데이터베이스, DeepSeek이나 Qwen 같은 오픈 가중치 모델을 모두 자사 서버나 전용 클라우드에서 운영할 수 있어, 문서와 질문이 사내에 머뭅니다. 이 경우 GPU 하드웨어를 직접 마련하고 운영해야 하므로, 모델마다 라이선스를 확인하고 작은 모델부터 자사 질문으로 테스트해 보십시오.

UsualMatrix는 전 세계 기업을 위해 로우코드 플랫폼, 맞춤 개발, 자체 서버의 오픈소스 모델 등 상황에 맞는 방식으로 AI 지식베이스를 구축하고, 홈페이지나 WhatsApp의 AI 상담 챗봇과도 연결해 드립니다. 소통은 중국어, 스페인어, 영어로 합니다. AI 솔루션 서비스를 살펴보시거나 문의하기에서 보유 문서와 활용 계획을 들려주십시오.

참고: 이 글의 GDPR 관련 내용은 게시일 기준의 일반 정보이며 법률 자문이 아닙니다. 제3자 제품의 기능과 라이선스는 바뀔 수 있으므로 각 업체의 공식 문서를 확인하십시오.