폐쇄망 RAG 전처리 방법 – 온프레미스 구축 가이드
폐쇄망 RAG(Retrieval-Augmented Generation, 검색 증강 생성) 전처리는 금융·공공·국방처럼 망분리 환경에서 AI를 도입하려는 담당자가 초기에 확인해야 할 과제입니다. 문서를 검색해 AI 답변의 근거로 쓰려면 먼저 문서를 파싱하고 전처리해야 하는데, 외부 클라우드 API를 호출하면 문서나 임베딩 데이터가 외부 서버로 전송될 가능성이 생기기 때문입니다. 특히 물리적 망분리 환경에서는 외부 API 활용이 제한될 수 있어, 문서를 밖으로 내보내지 않고 내부망 안에서 전처리를 마칠 수 있는 온프레미스 방식이 현실적인 선택지가 됩니다.
폐쇄망에서 RAG 전처리가 제한되는 이유
폐쇄망에서 RAG 전처리가 제한되는 이유는 전처리에 일반적으로 사용하는 외부 클라우드 API가 문서와 임베딩 데이터를 외부 서버로 보내는 구조이기 때문입니다. 망분리 환경에서는 이런 외부 통신 자체가 제한되는 경우가 많습니다.
RAG(Retrieval-Augmented Generation, 검색 증강 생성)는 질문과 관련된 문서를 찾아 LLM 답변의 근거로 쓰는 방식입니다. 이를 위해 문서 파싱(Document Parsing), OCR(Optical Character Recognition, 광학 문자 인식), 임베딩 같은 작업이 필요한데, 일부 조직은 이 과정을 외부 API로 처리하기도 합니다. 하지만 폐쇄망에서는 외부 API 호출이 차단되거나 별도 보안 검토 대상이 될 수 있습니다.
국내 금융권은 2013년 전산대란을 계기로 물리적 망분리 체계가 본격화됐습니다. 시중은행의 영업점 창구와 인터넷뱅킹 서버가 마비된 사고 이후, 업무망과 인터넷망을 물리적으로 분리하는 규제가 자리 잡았습니다. 공공·국방처럼 보안 수준이 높은 곳도 외부 통신과 민감 문서 반출을 엄격히 관리하고 있습니다.
이렇게 외부 통신이 제한되면서 폐쇄망은 클라우드 기반 생성형 AI·SaaS를 활용하기 어려운 환경이 됩니다. RAG는 문서를 먼저 파싱하고 전처리해야 검색과 답변 단계로 넘어갈 수 있습니다. 따라서 폐쇄망 담당자에게 전처리는 단순한 기술 선택이 아니라, RAG 도입 전에 먼저 해결해야 할 과제입니다.
폐쇄망 RAG 전처리의 3가지 난관
폐쇄망에서 RAG 전처리를 구축할 때 확인해야 할 지점은 크게 세 가지입니다. 외부 전처리 API를 쓸 수 없다는 점, 전처리 파이프라인 전체를 내부망에 직접 구축해야 한다는 점, 그리고 정형·비정형 문서가 섞여 단일 방식으로는 처리되지 않는다는 점입니다.
외부 전처리 API 사용 불가 – 문서가 외부로 나가는 문제
클라우드 문서 파싱·OCR·임베딩 API는 대부분 문서를 외부 서버로 전송해 처리합니다. 폐쇄망에서는 이렇게 문서를 밖으로 보내는 방식이 보안 정책·컴플라이언스 요건에 걸릴 수 있고, 네트워크상으로도 차단되는 경우가 많습니다.
문서 파싱·OCR·임베딩을 처리하는 클라우드 서비스는 많지만, 폐쇄망에서는 외부 API 호출 자체가 문제가 될 수 있습니다. 민감한 내부 문서가 외부 서버로 전송되는 순간, 조직 보안 정책이나 규제 요건에 위배될 수 있기 때문입니다. 결국 폐쇄망에서는 성능 좋은 외부 서비스를 고르는 것보다, 내부망 안에서 문서를 처리할 수 있는 구조를 먼저 갖추는 것이 중요합니다.
전처리 파이프라인 전체를 내부망에 구축하는 부담
외부 API를 쓰기 어렵다면 OCR, DLA(Document Layout Analysis, 문서 구조 분석), TSR(Table Structure Recognition, 표 구조 인식) 같은 문서 파싱 기능을 내부망 안에서 직접 구성하는 것이 좋습니다.
여기에 청킹·임베딩 등 후속 RAG 파이프라인까지 연결해야 하므로, 오픈소스를 하나하나 조합하는 방식은 구축 기간이 길어지고 유지보수 부담도 커질 수 있습니다.
문서에서 글자를 읽는 OCR, 제목·본문·표 영역을 구분하는 DLA, 표의 행과 열 관계를 복원하는 TSR은 각각 역할이 다른 기술입니다. 여기에 청킹·임베딩까지 서로 다른 도구로 연결하면 버전 충돌이나 연동 오류가 생기기 쉽고, 운영 중 관리 부담도 커질 수 있습니다. 그래서 문서 파싱과 구조화 기능을 하나의 파이프라인으로 묶어 두면, 청킹 단계로 넘어가기 전 구축·운영 부담을 줄이는 데 도움이 됩니다.
정형·비정형 문서가 섞여 단일 방식으로 처리하기 어려운 문제
정형과 비정형 문서 유형이 섞여 있는 환경에서는 하나의 추출 방식만으로 모든 문서를 처리하기 어렵습니다.
공문·계약서·신청서처럼 항목과 형식이 일정한 정형 문서는 스키마·규칙 기반으로 필요한 항목을 추출하는 편이 빠르고 안정적입니다. 반면 표·이미지·계층 구조가 복잡한 문서는 OCR, DLA, TSR을 함께 활용해 구조 정보를 보존해야 합니다.
특히 HWP·HWPX처럼 원본 구조가 중요한 문서를 PDF로 변환한 뒤 다시 추출하면, 표 구조나 계층 정보가 손실될 수 있습니다. 한컴테크의 분석에서도 PDF를 거쳐 학습용 데이터로 변환할 경우 표 구조가 손상되어 텍스트가 뒤섞이는 등 원본 문서의 구조가 손실될 수 있다고 설명합니다.
따라서 폐쇄망 RAG 전처리에서는 문서 유형에 따라 추출 방식을 나누고, 내부망 안에서 문서 파싱과 구조화 과정을 처리할 수 있어야 합니다. 이때 검토할 수 있는 방식이 온프레미스 구축입니다.
온프레미스 RAG 전처리 구축 방법
온프레미스는 서버와 소프트웨어를 고객사 내부에 직접 설치해 운영하는 방식입니다. 온프레미스로 RAG 전처리를 구축하면 문서가 내부망을 벗어나지 않고, 문서 파싱과 구조화부터 청킹, 임베딩, 벡터DB 저장까지 이어지는 검색 준비 과정을 내부망 안에서 구성할 수 있습니다.
폐쇄망에서 온프레미스 방식으로 RAG 전처리를 설계할 때는 두 가지를 먼저 확인해야 합니다. 하나는 문서가 밖으로 나가지 않도록 내부망 안에서 처리를 완결하는 구조를 잡는 일이고, 다른 하나는 문서 유형에 맞춰 처리 방식을 나누는 일입니다.
문서가 외부로 나가지 않는 내부망 완결 구조
내부망 완결 구조란 문서 파싱, 구조화, 청킹, 임베딩, 벡터 DB 저장으로 이어지는 RAG 준비 과정을 내부망 서버 안에서 처리해, 문서와 그 임베딩이 외부로 전송되지 않도록 만든 구성입니다.
여기서 놓치기 쉬운 점은, 보호할 대상이 문서 원문만은 아니라는 것입니다. 임베딩까지 암호화 대상으로 다룬 Privacy-Aware RAG 연구는 문서 원문뿐 아니라 그에 대응하는 임베딩도 저장 전에 함께 보호해야 한다고 봅니다. 임베딩만 유출돼도 원래 문서의 민감 정보를 추론할 수 있다고 보기 때문입니다. 그래서 폐쇄망 RAG 전처리에서는 외부 전송 여부뿐 아니라 저장 방식과 검색 환경까지 함께 관리해야 합니다.
정형 문서 – 스키마 기반으로 효율적인 처리
정형 문서는 공문·법률·의료 문서처럼 항목과 형식이 일정합니다. 사전에 정의한 스키마(Schema)에 맞춰 규칙 기반으로 추출하면 빠르고 안정적으로 구조화 데이터를 얻을 수 있습니다.
형식이 반복되는 문서마다 복잡한 AI 모델을 적용하는 것은 비효율적입니다. 필드 위치와 형식이 고정되어 있는 만큼, 규칙 기반으로 필요한 항목을 추출하는 편이 처리 속도가 빠르고 결과도 일관됩니다.
비정형 문서 – AI OCR·문서 구조 분석으로 정밀 처리
비정형 문서는 그림·표·이미지가 섞여 형식이 일정하지 않습니다. OCR로 글자를 읽고 DLA·TSR로 제목·본문·표 영역과 표의 구조를 함께 추출해야, 이후 청킹 단계에서 문서 구조를 활용할 수 있습니다.
표의 헤더와 값, 제목과 본문의 관계가 함께 남아 있어야 이후 청킹과 검색에서 맥락이 끊기지 않습니다. 반대로 계층 구조가 사라진 채 텍스트만 나열되면, 해당 문장이 어느 표나 항목에 속하는지 알기 어려워 검색 근거로서의 가치가 떨어질 수 있습니다.
온프레미스가 폐쇄망의 해법이지만, 모든 조직이 처음부터 온프레미스를 구축해야 하는 것은 아닙니다. 배포 방식을 비교해 상황에 맞게 골라야 합니다.
온프레미스와 SaaS API 배포 방식 비교
온프레미스는 내부 서버에 직접 설치해 문서를 외부로 보내지 않는 방식이고, SaaS API는 별도 설치 부담을 줄이고 API 호출량·사용량 기준으로 이용하는 방식입니다. 폐쇄망·민감 데이터 환경은 온프레미스가, 빠른 파일럿이나 소규모 테스트는 SaaS API가 적합합니다.
온프레미스와 SaaS API 배포 방식 비교표
| 비교 항목 | 온프레미스 | SaaS API |
| 데이터 보안 | 내부망 완결, 외부 전송 없이 운영 | 외부 API 호출로 처리 |
| 초기 비용 | 서버 인프라 구축 필요 | 서버 구축 비용 없이 사용 |
| 과금 방식 | 솔루션 도입 비용 | 사용량에 따라 과금 |
| 도입 속도 | 컨테이너 설치 후 내부 환경에 맞춰 구축 | API 연동으로 빠르게 시작 |
| 적합 환경 | 공공·대기업 등 민감 데이터 처리 | 파일럿·소규모 테스트, 빠른 적용 |
폐쇄망 내부 문서를 바로 SaaS API로 테스트하기 어렵다면, 비식별 샘플이나 외부 반출이 가능한 문서로 전처리 품질을 먼저 확인한 뒤 온프레미스를 검토하는 경로도 있습니다. SaaS API는 페이지 단위 과금이라 파일럿 단계의 부담을 줄일 수 있고, 민감 데이터를 상시 처리한다면 처음부터 내부망에서 완결되는 온프레미스가 적합합니다.
한컴 데이터 로더의 폐쇄망 온프레미스 전처리 방식
한컴 데이터 로더는 고객사 내부 서버에 컨테이너 기반으로 설치되는 온프레미스 문서 파싱 솔루션입니다. HWP·HWPX·PDF·OOXML 문서를 구조화 데이터로 변환하며, 문서 데이터가 외부로 전송되지 않아 폐쇄망 환경에서도 안전하게 사용할 수 있습니다.
온프레미스 중심, API SaaS까지 선택 가능한 배포 방식
한컴 데이터 로더는 도입 환경에 따라 온프레미스와 API SaaS 방식을 선택할 수 있습니다. 이 중 온프레미스 방식은 고객사 내부 서버에 설치·운용돼 문서가 외부로 나가지 않고, 인터넷이 제한된 폐쇄망에서도 운영할 수 있어 공공·금융처럼 보안 수준이 높은 환경에 적합합니다.
또한, OCR·DLA·TSR을 각각 따로 구축할 필요 없이 하나의 파이프라인에서 연동해, 도구 간 연동 오류나 관리 복잡성을 줄입니다. 오픈소스로 직접 구성하면 표의 헤더-값, 제목-본문 관계가 끊겨 벡터DB나 임베딩 모델을 바꿔도 검색 품질이 개선되지 않는 문제가 생길 수 있습니다.
이처럼 DLA·TSR로 이 관계를 보존한 구조화 데이터를 만들어, 폐쇄망 환경에서도 이후 청킹 단계에서 활용할 수 있는 입력 데이터로 추출됩니다.
문서 특성에 맞춘 구조화 데이터 변환과 공공기관 적용 사례
한컴 데이터 로더는 문서 포맷과 특성에 따라 필요한 처리 방식을 유연하게 적용해, 추출 결과를 AI 최적화 JSON 등 구조화 데이터로 변환합니다.
문서 포맷에 따라 적용하는 처리 방식도 다릅니다. HWP·HWPX는 PDF로 변환하지 않고 원본을 직접 파싱하고, PDF·이미지는 AI OCR·DLA·TSR을 적용하며, OOXML은 텍스트 추출을 중심으로 처리합니다.
원본 직접 파싱은 속도에서도 차이가 큽니다. 한컴테크의 테스트 결과, HWPX에서 직접 추출하는 것(9.5초) 대비 PDF로 변환한 뒤 추출하는 것(150.3초)은 약 15.8배 더 오래 걸렸습니다. 이렇게 확보한 구조화 데이터는 문서 계층 구조와 좌표 정보, 표 안의 표나 병합 셀 같은 복잡한 표까지 담아냅니다.
공공 영역 적용 사례도 있습니다. ZDNet Korea 보도에 따르면 한컴 데이터 로더는 삼성SDS 컨소시엄을 통해 행정안전부 ‘범정부 초거대 AI 공통기반 사업’에 공급돼, 정부 부처와 지자체가 보안 우려 없이 생성형 AI를 활용하도록 공공 문서를 구조화 데이터로 변환하는 추출·구조화 역할을 맡았습니다.
폐쇄망에서 RAG 전처리를 풀어 가는 관건은 하나입니다. 문서를 외부로 내보내지 않고 내부망 안에서 파싱하고 구조화하는 것입니다. 여기에 상황에 맞게 온프레미스와 SaaS API를 고르고, 정형·비정형 문서를 유형별로 나눠 처리하면 폐쇄망이라는 제약 안에서도 RAG 준비 과정을 안정적으로 꾸릴 수 있습니다. 내부망 문서를 AI가 쓸 수 있는 데이터로 바꾸는 첫 단계, 문서 파싱부터 점검하는 것이 먼저입니다.
🖥️한컴 데이터 로더
폐쇄망 RAG 구축에서 가장 먼저 확인해야 할 것은 문서를 외부로 내보내지 않고 내부망 안에서 파싱·구조화할 수 있는지입니다. 한컴 데이터 로더는 HWP·HWPX·PDF·OOXML을 구조화 데이터로 전환하는 문서 파싱 솔루션으로, 온프레미스 방식으로 고객사 내부 서버에 설치해 폐쇄망 환경에서도 문서 전처리 기반을 마련할 수 있습니다.
추출된 구조화 데이터는 필요에 따라 한컴피디아와 연계해 청킹·임베딩·검색·답변 생성까지 이어지는 RAG 파이프라인에 활용할 수 있습니다. 폐쇄망에서 RAG 전처리 방식을 검토하고 있다면, 먼저 실제 문서로 파싱 결과를 확인할 수 있습니다.
👉 한컴 데이터 로더 라이브 데모에서 파싱 결과 확인하기
폐쇄망 RAG 전처리 관련 자주 묻는 질문 FAQ
온프레미스와 SaaS API 중 무엇을 골라야 하나요?
민감 데이터를 다루는 폐쇄망 환경은 온프레미스가, 빠른 파일럿이나 소규모 테스트는 SaaS API가 적합합니다. SaaS API로 전처리 품질을 먼저 검증한 뒤 온프레미스로 전환하는 경로도 가능합니다.
정형 문서와 비정형 문서는 전처리 방식이 어떻게 다른가요?
정형 문서는 형식이 일정해 스키마 기반 규칙으로 빠르게 처리하고, 비정형 문서는 AI OCR·DLA로 구조를 보존해 처리합니다. 문서가 섞여 있으면 두 방식을 병행할 수도 있습니다.
한컴 데이터 로더는 폐쇄망에 설치할 수 있나요?
네, 컨테이너 기반 온프레미스로 내부 서버에 설치돼 문서가 외부로 나가지 않습니다. 인터넷이 차단된 공공·금융 등 보안 수준이 높은 환경에서도 운영할 수 있습니다.
