사내 문서를 AI의 지식으로 바꾸는 법: 마크다운부터 RAG까지

사내 문서를 답변에 활용하는 챗봇을 만들기로 했다고 해볼게요. 첫 회의에서 벡터 데이터베이스나 모델부터 정하기 쉽지만, 먼저 정할 것은 어떤 질문에 어떤 문서를 근거로 답할지예요. RAG는 모델이 사내 지식을 이미 알고 있다고 가정하는 방식이 아니라, 질문에 맞는 자료를 찾아 답변 맥락으로 제공하는 구조입니다. 검색이 잘못되거나 문서가 낡으면 답변도 흔들려요.

이 글은 기업용 RAG 시리즈의 첫 편이에요. 마크다운으로 지식을 정리하고 도구를 고르는 기준을 다룹니다. 이어지는 2편에서는 파싱·청킹·하이브리드 검색을 설계하고, 3편에서는 접근 권한과 에이전트 메모리를 살펴봅니다.

RAG가 지식을 찾아 답변에 연결하는 방식

언어 모델만으로 사내 규정이나 제품 문서를 물으면, 학습 시점에 없던 정보나 비공개 내용을 정확히 답하기 어렵습니다. RAG는 질문과 관련된 문서 조각을 검색해 모델에 함께 전달합니다. 답변에 출처를 붙이고 사람이 원문을 확인할 수 있게 만들면 검토도 쉬워져요. 다만 RAG가 환각을 없애거나 문서의 진실성을 보증하지는 않습니다. 검색된 근거가 틀렸거나 질문과 맞지 않으면 그 한계가 답변에 이어집니다.

파인튜닝은 예시를 바탕으로 모델의 가중치를 조정해 특정 작업이나 응답 패턴을 익히게 하는 접근입니다. RAG는 외부 자료를 답변 시점의 근거로 찾아 넣어요. 최신 사실을 갱신해야 한다면 RAG가 편리할 수 있고, 반복되는 작업 형식이나 표현 방식을 익히게 할 때는 파인튜닝을 검토할 수 있습니다. 두 방식은 목적에 따라 함께 쓰일 수도 있어요. 어느 쪽도 데이터 품질이나 검증을 대신하지 않습니다.

그래서 첫 목표는 “모든 사내 문서에 답하는 AI”가 아니어도 됩니다. 예를 들어 최신 정책을 찾기 어렵다는 문제를 골라, 정책 문서 몇 종류와 실제 질문을 모으고 답변에 근거 링크가 필요한지 정해보세요. 반복해서 들어오는 질문, 정답을 확인할 담당자, 잘못 답했을 때의 영향도 함께 적으면 파일럿의 범위가 구체적이 됩니다.

마크다운으로 문서 원본 관리하기

마크다운은 제목, 목록, 표 같은 구조를 평문으로 표현합니다. 파일을 열어 내용을 확인하기 쉽고, Git으로 변경 이력을 남기거나 다른 도구로 옮기기도 편해요. 간단한 팀 위키나 문서 원본을 정리하는 단계에서는 유용한 선택입니다. Obsidian 같은 편집기로 문서 사이에 링크를 붙이고 Git으로 변경 이력을 관리하는 식으로 시작할 수도 있어요. 에이전트가 요약이나 새 문서를 작성한다면, 공식 원본과 자동 생성된 내용을 구분하고 검토 후 반영하는 흐름을 두면 됩니다.

다만 마크다운이라고 파싱이 필요 없는 것은 아니에요. RAG 시스템은 파일을 읽어 문서 구조를 해석하고, 검색 가능한 단위로 나눈 뒤, 각 단위에 제목·출처·날짜 같은 정보를 붙여 인덱싱합니다. 헤더가 엉켜 있거나 표가 복잡하면 평문 파일도 검색에 적합하지 않을 수 있어요. 문서가 검색 결과에서 어떻게 잘렸는지 직접 살펴보는 과정은 계속 필요합니다.

원본 파일을 지식의 기준으로 둘지, RAG 제품 안에서 편집한 내용을 기준으로 둘지도 정해야 해요. 여러 저장소에서 문서를 가져오는 구조라면 원본이 어디인지, 수정과 삭제가 언제 검색 인덱스에 반영되는지, 실패를 누가 알아차리는지 정합니다. 동기화 간격과 권한 회수 반영 시점은 제품 설정과 커넥터에 따라 달라질 수 있어요. “연결했다”는 말만으로 최신성이나 삭제 반영이 보장되지는 않습니다.

동기화에는 원본의 고유 문서 ID와 버전, 각 청크의 소속 정보를 남겨두는 편이 좋아요. 웹훅이나 변경분 폴링으로 수정 사항을 감지하고, 새 버전의 청크가 준비되면 검색 대상을 교체합니다. 원본 삭제나 권한 회수는 검색에서 우선 제외하고 관련 인덱스와 캐시를 정리해야 해요. 실패한 작업의 재시도와 정기 대조까지 있어야 누락된 변경을 찾을 수 있습니다.

인원수보다 운영 요구가 전환 시점을 정한다

팀원이 몇 명인지 하나만으로 아키텍처 전환 시점을 정하기는 어렵습니다. 대신 동시 편집이 잦은지, 원본 저장소가 늘어나는지, 폴더별 권한 변경을 검색에도 반영해야 하는지, 삭제된 문서가 언제 사라져야 하는지 살펴보세요. 감사 기록이나 장애 대응이 필요해지는 것도 운영 방식을 재검토할 신호입니다.

마크다운 파일을 Git으로 관리하는 방식은 변경 이력을 명확히 보여주지만, 사용자가 파일을 읽을 수 있는지 판단하는 권한 체계나 다양한 시스템의 동기화까지 자동으로 해결하지 않습니다. 파일 기반 출발점에서 서비스로 옮길 때는 사용자 인증, 권한 변경 전파, 검색 기록, 문서 삭제, 백업과 복구를 함께 설계해야 해요.

도구별 중심 기능과 배포 조건 비교

RAGFlow는 문서 파싱과 청킹, 지식 검색을 구성하고 답변 근거를 다루는 RAG 엔진에 무게를 둡니다. 스캔 문서와 복잡한 레이아웃을 포함한다면 실제 보유 문서로 파싱 결과를 확인해볼 만해요. Dify는 지식 검색을 앱의 워크플로 안에 넣어 다른 단계나 도구 호출과 연결하는 데 초점을 둡니다.

AnythingLLM은 워크스페이스와 사용자 접근을 포함한 문서 기반 채팅 환경을 제공합니다. Open WebUI는 대화 인터페이스와 지식 베이스 기능을 함께 두고, 지식 접근 범위를 설정할 수 있어요. MaxKB는 문서나 웹사이트를 지식으로 연결하는 앱 구축 흐름을 제공합니다. 기능은 버전과 배포 형태에 따라 달라지므로, 이 설명을 제품 순위나 적합성 보장으로 읽기보다 파일럿 후보를 고르는 출발점으로 삼아주세요.

오픈소스라는 말도 라이선스를 대신하지 않습니다. 2026년 10월 확인한 저장소 기준으로 RAGFlow는 Apache-2.0, AnythingLLM은 MIT, MaxKB는 GPLv3로 표시되어 있고, Dify는 추가 조건이 포함된 수정 Apache 라이선스를 사용합니다. Open WebUI는 버전에 따라 브랜딩 관련 조건을 두고 있어요. 배포하거나 수정해 제공하기 전에 사용할 버전과 포함 구성요소의 라이선스를 직접 확인해야 합니다. 관리형 API나 호스팅 서비스는 셀프 호스팅 소프트웨어와 계약·비용·데이터 처리 조건이 다를 수 있습니다.

작은 파일럿에서 동기화와 삭제까지 확인하기

도구를 시험할 때는 “답변이 그럴듯한가”만 보지 마세요. 실제 질문을 모아 근거 문서가 검색되는지, 답변에 출처가 표시되는지, 권한이 없는 문서가 노출되지 않는지 확인합니다. 일부러 오래된 문서와 최신 개정본을 함께 두고 어느 쪽이 선택되는지도 살펴보세요. 동기화 실패와 문서 삭제가 운영 화면이나 로그에서 어떻게 보이는지 확인하면 도입 후의 부담을 가늠할 수 있어요.

기준은 도구의 기능 목록보다 우리 문서와 질문에서 작동하는지입니다. 시리즈 다음 편에서는 문서를 검색 가능한 단위로 나누고, 한국어 질의에 맞춰 검색 결과를 평가하는 방법을 살펴봅니다. 권한과 사용자별 기억은 마지막 편에서 별도로 이어집니다.