문서 관리 솔루션이 놓치는 3가지 레이어 | 기업 문서 스캔부터 사내 RAG 구축까지

기업 문서 스캔, 문서 전자화, 문서 관리솔루션 구축, 그리고 사내 RAG 구축. 많은 기업이 이 여정을 단계적으로 밟아 왔습니다. 종이 문서를 스캔해 디지털로 전환하고, 검색 가능한 아카이브를 만들고, 마지막으로 AI 챗봇을 올리는 순서입니다.

그런데 마지막 단계에서 대부분의 프로젝트가 멈춥니다. 모델 성능은 충분한데도 전사 배포로 이어지지 않습니다. 문제는 AI 모델이 아니라, 그 앞단에 깔린 데이터 레이어의 구조에 있습니다.

문서 전자화는 완료됐는데, 기업 문서 활용은 왜 멈춰 있는가

문서를 디지털로 바꾸는 일과, 그 문서를 AI로 활용하는 일은 전혀 다른 과제입니다. 전자화의 결과물은 "검색 가능한 PDF"에 가깝고, 활용의 전제는 "AI가 이해할 수 있는 데이터"입니다. 이 간극에서 대부분의 사내 RAG 구축 프로젝트가 POC를 넘어서지 못합니다.

현장에서 실제로 들리는 질문은 세 갈래로 좁혀집니다.

• 인프라팀: "AI 도입을 위해 사내 파일 서버, NAS, 클라우드 데이터를 한 군데로 다 복사해야 하나요?"

• 현업팀: "파일 이름과 폴더만 보고 AI가 제대로 답할 수 있나요?"

• 보안팀: "권한이 없는 문서를 챗봇으로 우회해서 조회하는 상황을 어떻게 막나요?"

세 질문 모두 기술의 문제가 아니라 아키텍처의 문제입니다. 그리고 이 세 질문이 해결되지 않으면 사내 RAG 구축은 POC 단계에서 종료됩니다.

사내 RAG 구축을 가로막는 3가지 현실

① 분산된 데이터를 한 곳에 모을 수 없다

기업의 문서 자산은 한 곳에 있지 않습니다. 사내 파일 서버(Windows/Linux), NAS와 외장 스토리지(Synology, QNAP 등), 클라우드 스토리지(AWS S3, Azure 등), 기업 문서 스캔으로 축적된 이미지·PDF, 그리고 레거시 ECM/EDMS 시스템까지 분산되어 있는 것이 일반적입니다.

이 데이터를 "AI 도입을 위해 한 곳으로 복사"하는 것은 현실적으로 거의 불가능합니다. 보안 등급별 망 분리, 저장소마다 다른 접근 프로토콜(SMB, S3 API, 레거시 전용 API), 데이터 이중화에 따른 비용과 동기화 문제, 원본 변경 추적의 불가능성까지. 단순한 기술 이슈가 아니라 거버넌스와 규제의 문제가 얽혀 있습니다.

클라우드 스토리지 시대를 거치며 IT 업계가 배운 교훈이 하나 있습니다. ‘데이터는 옮기는 것이 아니라 연결하는 것’이라는 점입니다. 그러나 대부분의 RAG 구축 프로젝트는 여전히 "중앙에 새 벡터 DB를 만들고 전사 문서를 모은다"는 전제로 설계됩니다. 이 전제부터 바꾸지 않으면 첫 단계를 넘기 어렵습니다.

② 기업 문서 스캔만으로는 메타데이터가 부족하다

기업 문서 스캔과 문서 전자화 작업이 완료되어도, 파일 시스템에 남는 정보는 파일명·확장자·수정일 정도입니다. 이 수준의 메타데이터만으로 AI가 할 수 있는 일은 "파일명 유사 검색" 이상이 되기 어렵습니다.

AI가 실제로 문서를 활용하려면 다음과 같은 정보가 필요합니다.

• 문서 본문 텍스트(OCR 결과)

• 문서 타입(계약서, 영수증, 사규, 품의서 등)

• 관련 엔티티(고객명, 제품명, 프로젝트 코드)

• 작성 부서, 작성일, 버전, 결재 상태

이 메타데이터가 사전에 구조화되어 있지 않은 상태에서 AI를 붙이면, 답변 품질은 기대 이하로 떨어집니다. 문서를 "읽을 수 있게" 만드는 것과 "이해할 수 있게" 만드는 것은 다른 일입니다. 기업 문서 스캔과 AI-OCR은 전자의 문제를 해결하지만, 후자는 별도의 메타데이터 부여 레이어가 필요합니다.

③ 권한 없는 문서가 답변에 섞여 나온다

세 번째 난제는 전사 배포 단계에서 가장 치명적입니다. 일반적인 RAG는 다음과 같이 작동합니다.

1. 구축 시점에 사내 문서를 모두 벡터 DB에 임베딩

2. 질의 시 유사도가 높은 청크를 검색

3. 검색된 청크를 LLM 컨텍스트에 주입해 답변 생성

위 과정 어디에도 사용자의 접근 권한은 반영되지 않습니다. 이는 실제 배포 환경에서 심각한 유출 시나리오로 이어집니다.

흔히 시도되는 대응책은 두 가지입니다. 답변이 생성된 뒤 사후 필터링으로 차단하거나, 사용자 그룹별로 별도 벡터 인덱스를 구축하는 방식입니다.

그러나 사후 필터링은 재생성 비용이 발생하고 완전한 차단을 보장하지 못하며, 사용자별 인덱스 분리는 관리 폭증과 실시간 권한 변경 반영 불가라는 문제를 낳습니다.

근본 해법은 검색 단계부터 권한을 인식하는 구조입니다. 사용자가 질의를 던지는 순간, 검색 레이어가 질의자의 소속·역할· 계정 상태를 참조해 접근 가능한 문서 범위 안에서만 검색을 수행해야 합니다.

문서 관리 솔루션이 갖춰야 할 3개 레이어

① 저장소 가상화 : 데이터를 옮기지 않고 연결한다

사내 파일 서버, NAS, 클라우드 스토리지, 기업 문서 스캔 이미지, 레거시 ECM까지 원본 위치에 그대로 둔 상태로 단일 인터페이스에 연결합니다.

사용자 관점에서는 여러 저장소가 하나의 드라이브처럼 보이지만, 물리적 데이터는 이동하지 않습니다. 기존 비즈니스 인프라와 워크플로우를 그대로 유지할 수 있고, 원본의 권한 체계와 업데이트가 실시간으로 반영됩니다. 데이터 복제와 이중화에 드는 비용·리스크 없이 사내 RAG 구축의 전제 조건을 충족할 수 있습니다.

② AI-OCR과 메타데이터 : 문서에 구조와 의미를 부여한다

두 번째는 문서를 AI가 이해 가능한 형태로 변환하는 단계입니다. AI OCR 엔진 또는 VLM 기반 AI-OCR로 이미지·PDF·스캔본까지 텍스트를 추출하고, 동시에 문서 타입·엔티티·속성을 자동으로 부여합니다.

이는 기업 문서 스캔의 결과물이 "검색 가능한 PDF"에서 "구조화된 자산"으로 전환되는 지점입니다. 같은 문서라도 "계약서이며, 거래처는 A사이고, 담당 부서는 법무팀이며, 2026년 3월 체결되었다"는 속성이 붙어 있어야 RAG가 의미 있는 답변을 생성할 수 있습니다.

③ 동적 권한 제어 : 검색 단계에서 권한을 인식한다

마지막으로, 엔터프라이즈 사내 RAG 구축의 분수령입니다. 라이브러리·폴더·파일 단위의 세분화된 접근 제어가 검색 레이어 자체에 ‘내장’되어야 합니다.

질의자의 그룹·역할·계정 상태를 검색이 직접 참조하고, 원본 저장소의 권한 체계와 동기화되어 권한 변경이 즉시 반영됩니다. 별도 재인덱싱이 필요 없습니다. RAG가 답변을 생성할 때 질의자가 접근 권한을 가진 문서만 참조하므로, 같은 모델과 같은 문서 풀을 공유해도 유출 리스크 없이 전사 배포가 가능해집니다.

문서 전자화에서 기업 문서 활용까지,
하나의 플랫폼에서

엔터프라이즈 AI의 경쟁력은 결국 모델이 아니라 데이터 레이어에서 결정됩니다. 아무리 좋은 LLM을 붙여도, 그 모델이 읽는 데이터가 분산되어 있고, 의미가 없고, 권한이 뚫려 있다면 결과물은 POC 수준을 넘지 못합니다.

악어디지털은 다수의 문서 전자화 프로젝트를 수행하고 디지털화 센터에서 연간 1.2억 장 이상의 문서를 처리해 왔습니다. 이 현장 경험은 Mingo의 데이터 온톨로지 레이어 설계에 그대로 반영되어 있습니다.

AI 문서 플랫폼 Mingo는 기업 문서 스캔부터 사내 RAG 구축까지 전 과정을 단일 플랫폼에서 완결합니다. 고로 별도 시스템 구축이나 개발 리소스 투입 없이, SaaS 구독형과 온프레미스 설치형 모두 대응 가능합니다. 문서 전자화의 끝에서 기업 문서 활용을 시작하는 가장 빠른 경로입니다.

🔖 추천 콘텐츠

• 비정형 데이터의 역습 : 왜 문서 디지털화가 AI 도입의 첫 단추인가

• 제조업 문서 관리, 공유폴더와 캐비닛만으로 괜찮을까? 도면·BOM·성적서 접근 권한 관리 가이드