사내 RAG 시스템 구축에 앞서 우리 회사 문서 구조부터 점검해야 하는 이유

사내 RAG 시스템 구축이란 우리 회사가 가진 문서를 검색 가능한 형태로 색인해 두고, 질문이 들어오면 관련 문서를 찾아 그 내용을 근거로 답하게 만드는 작업을 말합니다. 많은 조직이 "어떤 LLM을 쓸까"부터 고민하지만, 제가 여러 사내 문서봇 프로젝트를 지켜보며 확인한 것은 품질을 가르는 진짜 변수가 모델이 아니라 문서라는 점입니다. 이 글은 도입 검토 단계에서 우리 자료가 RAG에 맞는 구조인지 점검하는 방법을 정리합니다.

안녕하세요, AI AGENT 와 업무 자동화를 연구하는 기업, 플로우드를 운영하는 유성철입니다.

사내 RAG 시스템 구축, 왜 모델 선택보다 문서가 먼저일까?

RAG(검색증강생성, Retrieval-Augmented Generation)는 2020년 메타 AI 연구진(Lewis 외)이 제안한 개념으로, 사전학습된 언어모델에 외부 지식 검색을 결합해 더 정확하고 최신인 답을 만드는 구조입니다. 즉 모델이 "기억"으로만 답하는 게 아니라, 매번 관련 문서를 찾아 그 근거 위에서 답을 씁니다.

RAG는 결국 검색이 8할이다

그래서 RAG의 답변 품질은 검색 품질에 종속됩니다. 현업 분석들이 공통적으로 지적하는 원칙이 "쓰레기를 넣으면 쓰레기가 나온다(garbage in, garbage out)"인데, 여러 실무 정리(Towards Data Science, kapa.ai)는 어떤 LLM을 쓰든 검색 품질이 가장 결정적이며, 정제 안 된 원본을 그대로 벡터DB에 넣으면 초기 테스트는 통과해도 실전에서 무너진다고 봅니다.

결론적으로 RAG의 성패는 모델이 아니라 문서 구조에서 갈립니다.

RAG는 우리 회사 문서를 어떻게 읽고 답을 찾을까?

점검 기준을 세우려면 RAG가 문서를 다루는 순서를 알아야 합니다. 크게 문서를 잘게 나누고(청킹), 숫자 벡터로 바꾼 뒤(임베딩), 질문과 가까운 조각을 찾아(검색) 모델에 넘기는 흐름입니다.

문서를 잘게 나누는 ‘청킹’이라는 첫 관문

RAG는 문서를 통째로 쓰지 않고 작은 조각(청크)으로 잘라 색인합니다. 문제는 이 자르는 방식입니다. 여러 청킹 가이드(RAGFlow 정리, kapa.ai)에 따르면, 글자 수만 세어 기계적으로 자르면 표가 페이지 중간에서 끊기거나 머리말·꼬리말이 본문에 섞여 저품질 조각이 대량으로 만들어집니다. 반대로 제목·문단 같은 자연 경계에서 자르면 조각이 하나의 완결된 의미 단위가 됩니다.

임베딩과 유사도 검색의 원리

잘린 조각은 임베딩 모델을 거쳐 숫자 벡터가 되고, 질문도 같은 방식으로 벡터가 됩니다. 검색은 질문 벡터와 가장 가까운(코사인 유사도가 높은) 상위 몇 개 조각을 골라 오는 방식입니다(Karpukhin 외, 2020). 조각 크기는 사실 검색용으로 보통 200~500단어 안팎이 균형점으로 알려져 있습니다(청킹 실무 가이드, 2026).

어떤 문서가 RAG에 강하고, 어떤 문서가 발목을 잡을까?

이 원리를 뒤집으면 어떤 문서가 검색에 유리한지 보입니다. 핵심은 "기계가 구조를 알아볼 수 있는가"입니다.

구조가 살아 있는 문서의 공통점

구조 기반 청킹은 마크다운·HTML처럼 형식이 살아 있는 문서에서 잘 작동하고, 제목·표·목록이 자연스러운 자르기 기준이 됩니다(청킹 전략 분석). 마크다운의 ## 제목을 의미 경계로 삼으면 각 조각이 자족적인 단위가 된다는 연구 사례도 있습니다(arXiv, 2025).

검색을 방해하는 문서 유형

반대로 구조 단서가 없는 줄글 뭉치는 일관된 자르기가 어렵고, 스캔·손글씨 PDF는 텍스트 추출 단계에서부터 오류가 섞입니다.

우리 회사 자료의 RAG 적합도, 어떻게 점검할까?

이제 우리 문서함을 실제로 열어 점검할 차례입니다. 아래 다섯 항목은 구축 견적을 받기 전에 운영자가 직접 확인할 수 있습니다.

문서 단위로 던져야 할 질문

문서를 어떻게 정비해야 검색이 잘 될까?

점검에서 구멍이 보였다면, 전면 재작성보다 검색에 영향이 큰 것부터 손대는 편이 효율적이라고 생각합니다.

제목·구조부터 살리고, 표·목록은 형태를 지켜서

제목이 없는 긴 문서에는 소제목을 넣어 위계를 만들고, 중복·구버전은 최신본만 남깁니다. 표와 목록은 이미지가 아닌 텍스트로 두고, 문서마다 작성일·출처를 붙입니다. 조각을 나눌 때 앞뒤를 조금 겹치게 하는 것(오버랩 10~20% 권장)도 경계에서 맥락이 끊기는 것을 막아 줍니다(청킹 전략 분석). 한 분석에서는 의미 단위로 자르는 방식이 단순 방식보다 검색 재현율(recall)을 최대 9%가량 높였다고 보고하기도 했습니다(Firecrawl, 2026). 정비는 자주 쓰는 문서 묶음부터 우선순위를 두길 권장합니다.

사내 RAG 시스템 구축은 어떤 순서로 준비해야 할까?

문서가 어느 정도 정비됐다면, 구축은 작은 범위에서 검증하며 넓히는 순서가 안전합니다.

도입 전 흔히 하는 착각은 무엇일까?

마지막으로, 사내 RAG 시스템 구축을 검토할 때 자주 빠지는 오해 두 가지를 짚겠습니다.

임베딩도 시간이 지나면 낡는다

한 번 색인하면 끝이라는 생각은 위험합니다. 문서 내용이 바뀌었는데 벡터를 갱신하지 않으면, 오래된 임베딩이 낡은 답을 계속 내놓는 ‘임베딩 부패(embedding rot)’가 생깁니다(현업 운영 사례). 2026년 들어 사내 지식봇 수요가 빠르게 늘고 있지만, 제가 보기에 성공과 실패를 가르는 지점은 여전히 화려한 모델이 아니라 이런 기본기입니다.

자주 묻는 질문

정리하며

사내 RAG 시스템 구축은 모델을 고르는 일이 아니라 우리 문서를 검색 가능한 상태로 만드는 일에 더 가깝습니다. 제목·표·최신성·메타정보라는 기본기가 갖춰진 문서는 평범한 모델로도 좋은 답을 내고, 그렇지 않은 문서는 최신 모델로도 오답을 냅니다. 결국 가장 확실한 투자는 더 비싼 모델이 아니라, 구축 전에 문서 구조를 점검하고 정비하는 일이다. 작은 범위에서 실제 질문으로 검증하며 넓혀 가는 순서를 지킨다면, 도입은 실패가 아니라 점진적 개선의 과정이 된다고 생각합니다.

참고 출처

• Lewis 외, "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks", Meta AI(FAIR)·NeurIPS, 2020.
• Karpukhin 외, "Dense Passage Retrieval for Open-Domain QA", 2020.
• Towards Data Science, "Six Lessons Learned Building RAG Systems in Production"(검색 품질이 최우선·임베딩 부패), 2025.
• kapa.ai, "RAG Gone Wrong: 7 Most Common Mistakes"(고정 청킹·데이터 정제), 2026.
• 청킹 전략·문서 구조 분석 종합(구조 기반 청킹, 청크 크기 200~500단어, 오버랩 10~20%, 의미 청킹 recall 최대 9% — Airbyte·Latenode·Firecrawl), 2026.
• arXiv, 마크다운 ## 기준 의미 청킹 사례 연구, 2025.
• RAGFlow 개발 노트(문서 구조 이해·"맥락 품질을 먼저"), 2026.