오늘은 회사 내부 문서를 학습시키는 사내 RAG 시스템을 구축하는 과정에서 겪었던 시행착오와 실전 경험을 중심으로 정리한 내용을 소개해 드릴 예정입니다.
사내 RAG는 기업 내부 문서나 노하우를 기반으로 정확한 답변을 제공하기 위해 도입되는 경우가 많습니다. 특히 매뉴얼이나 기획 문서가 여러 팀과 사내 곳곳에 흩어져 있을 때 RAG 기반 검색과 요약 기능은 생산성을 높이는 효과가 큽니다. 하지만 실무에서는 생각보다 많은 기술적 난관과 예기치 못한 문제가 발생합니다. 겉보기에는 단순히 문서를 긁어오고 임베딩을 만들면 끝날 것 같지만 실제로는 데이터 정제부터 구조 설계 모델 튜닝 검색 품질 관리까지 모든 단계에서 걸림돌이 생깁니다. 이번 글에서는 사내 RAG 구축 과정에서 자주 마주치는 문제를 세 가지 주제로 나누어 자세히 설명드리겠습니다.
문서 정제 및 데이터 품질
첫 번째 주제는 문서 정제와 데이터 품질 문제입니다. 많은 분들이 사내 RAG 구축을 시작할 때 가장 먼저 드는 생각은 사내 문서만 긁어 와서 임베딩을 생성하면 된다는 단순한 접근입니다. 하지만 실제 문서들은 일관성이 없고 작성자마다 스타일도 다르며 제목 형식 구조 용어가 제각각입니다. 어떤 문서는 중복된 내용이 다른 표현으로 반복되어 있고 어떤 문서는 이미지 안에 핵심 내용이 포함되어 있어 텍스트로 추출하기 어렵습니다. 심지어 PDF로 만들어진 문서 중에는 스캔 기반 이미지 PDF가 섞여 있어서 텍스트 추출조차 되지 않는 경우가 많습니다. 이 과정에서 OCR을 붙여야 할지 문서를 제외할지 결정해야 하는데 문서 종류가 많을수록 판단 기준이 흔들리기 쉽습니다. 결국 RAG 품질은 데이터 품질에 따라 크게 달라지기 때문에 문서 정제 기준을 명확하게 잡는 것이 중요합니다. 문단 길이를 어느 정도로 쪼갤지 문서 내 불필요한 템플릿 부분을 어떻게 제거할지 같은 세부 로직을 만들지 않으면 임베딩이 무의미하게 커지거나 검색 결과가 전혀 상관없는 내용으로 채워지는 일이 발생합니다. 실제로 특정 키워드만 자주 등장하는 문서들이 검색 상위권을 독점하는 문제가 반복적으로 나타나기도 합니다.
검색 품질과 임베딩 전략
두 번째 주제는 검색 품질과 임베딩 전략의 난관입니다. 많은 팀이 임베딩 모델을 선택하는 단계에서 어려움을 겪습니다. 오픈소스 임베딩 모델은 가벼운 대신 정확도가 낮고 상용 모델은 성능은 좋지만 비용과 데이터 프라이버시 이슈가 발생할 수 있습니다. 사내 데이터 특성상 도메인 용어가 많거나 업무 맥락이 복잡한 경우에는 일반적인 임베딩 모델만으로는 정확한 검색 결과가 나오지 않는 경우가 많습니다. 예를 들어 어떤 팀은 내부 API 사용 가이드 문서가 여러 버전으로 존재하는데 검색 시 오래된 문서가 먼저 나오며 혼란을 주는 문제가 있었습니다. 또 어떤 팀에서는 비슷한 제목을 가진 문서가 많아서 제목 기반 검색이 전혀 도움이 되지 않았습니다. 이 과정에서 문서 메타데이터를 함께 저장할지 임베딩과 별도로 필터링을 적용할지 같은 구조적 고민이 발생합니다. 단순 벡터 검색만으로는 해결되지 않고 키워드 검색과 결합하거나 날짜 작성자 태그 같은 조건 검색을 함께 붙여야 만족스러운 결과가 나오는 경우가 많습니다. 검색 품질을 개선하기 위한 피드백 루프를 만들지 않으면 사용자가 금방 RAG 시스템을 불신하게 되고 제대로 활용되지 않는 결과로 이어집니다. 특히 RAG는 검색 결과의 순서와 맥락 이해가 핵심이기 때문에 적절한 청크 사이즈를 찾는데 많은 시간이 소요됩니다. 청크가 너무 길면 모델이 중요한 정보를 찾지 못하고 너무 짧으면 문맥이 사라져 엉뚱한 답변이 나옵니다. 이 균형을 잡는 것이 실제 구축 과정에서 가장 많은 테스트가 필요한 부분입니다.
유지 관리 및 보안 문제
세 번째 주제는 운영 단계에서의 유지 관리와 보안 문제입니다. RAG 시스템은 구축하고 끝나는 기술이 아니라 지속적으로 문서를 업데이트하고 검색 품질을 관리해야 제대로 기능합니다. 특히 빠르게 변화하는 조직이라면 한 달 사이에 문서가 여러 버전으로 분화하고 새로운 정책이나 규칙이 추가되는 일이 빈번합니다. 이때 새로운 문서가 자동으로 업데이트되는 파이프라인을 구성하지 않으면 RAG는 바로 옛날 정보를 답변하게 됩니다. 또한 문서를 자동 수집하는 과정에서 접근 권한이 문제가 될 수 있습니다. 예를 들어 특정 부서만 볼 수 있는 문서가 전체 검색 시스템으로 흘러들어 올 수 있고 애초에 보안 규정상 외부 모델에 전달하면 안 되는 정보가 임베딩 대상으로 포함되는 사고도 발생할 수 있습니다. 내부 보안 규정을 정확히 이해하지 않고 개발하면 임베딩 데이터베이스에 민감 정보가 그대로 저장되는 위험이 생깁니다. 검색 응답을 생성할 때도 모델이 부적절한 문서를 인용하거나 외부로 공개해서는 안 되는 정보를 추론하는 사례도 발생할 수 있습니다. 이러한 문제를 막으려면 문서 접근 권한 기반 필터링 시스템을 구축해야 하며 실제 사용자 권한에 따라 검색 가능한 데이터 범위를 동적으로 조절하는 방식을 적용해야 합니다. 운영 과정에서는 사용자의 검색 로그를 기반으로 어떤 문서가 문제를 일으키는지 어떤 문서가 불필요한지 지속적으로 평가해야 합니다. 이를 위해 검색 품질 모니터링 지표를 따로 마련하는 것이 필요합니다.
사내 RAG 구축은 겉보기보다 훨씬 많은 준비와 반복 검증이 필요한 프로젝트입니다. 문서 환경이 깔끔하게 정리된 조직이라면 비교적 쉽게 구축할 수 있지만 대부분의 회사에서는 수년간 쌓인 문서가 형식도 목적도 제각각인 경우가 많습니다. 이 말은 곧 RAG 시스템이 단순 기술 적용이 아니라 조직의 문서 구조와 작업 문화를 드러내는 지표가 된다는 의미입니다. 데이터가 정리되어 있지 않으면 검색 품질도 떨어지고 모델이 참고할 수 있는 유의미한 정보도 부족하게 됩니다. 또한 도메인 지식이 요구되는 조직일수록 검색 결과에서 정확성이 매우 중요한데 이 부분을 해결하기 위해서는 임베딩 모델 선택 메타데이터 설계 검색 파이프라인 검증 등 전체 구조를 다시 설계해야 합니다. 비용 측면에서도 검색 요청 수와 임베딩 갱신 비용이 누적되는 만큼 운영 비용 계산을 미리 해두지 않으면 도입 후 부담이 커질 수 있습니다.
결론적으로 사내 RAG 구축 과정에서 가장 중요한 요소는 기술 자체가 아니라 문서 품질 검색 전략 보안 기준 운영 프로세스입니다. 기술은 빠르게 발전하지만 문서 정제와 검색 품질 확보는 자동화만으로 해결되지 않는 영역입니다. 실제로 성공적인 RAG 시스템을 구축하는 팀들은 높은 품질의 문서를 확보하는 것부터 시작하고 검색 품질을 지속적으로 모니터링하며 문제를 개선하는 프로세스를 운영합니다. 또한 보안과 개인정보 이슈를 정확히 고려해 데이터 흐름을 관리하며 문서 접근 권한을 시스템적으로 제어합니다. 사내 RAG는 단순 기술이 아니라 조직 문화를 반영하는 시스템이기 때문에 구축 단계에서 충분한 시간을 들여 설계하고 현실적인 기준을 마련해야 안정적으로 운영할 수 있습니다. 이러한 과정을 통해 완성된 RAG 시스템은 조직 내에서 단순 검색 기능을 넘어 업무 효율성과 지식 공유 문서 관리 체계를 전반적으로 향상시키는 핵심 도구가 될 수 있습니다.