RAG 파이프라인 문서 파싱 솔루션, 도입 전 확인해야 할 기준 5가지
RAG 파이프라인 품질이 기대만큼 나오지 않는다면, 원인은 LLM이 아니라 가장 앞단인 문서 파싱일 가능성이 큽니다. 표의 행·열 관계가 손실되고 계층 구조가 사라진 채 임베딩에 들어가면, 성능이 뛰어난 모델을 사용하더라도 검색 품질을 올리기 어렵습니다.
이 글에서 문서 파싱 솔루션 도입 전 반드시 확인해야 할 기준 5가지와 현장에서 자주 놓치는 함정을 정리해 드리겠습니다.
RAG 파이프라인 성능, 문서 파싱에서 시작
파싱은 RAG 파이프라인의 가장 앞단에 위치하지만, 전체 검색 품질에 미치는 영향은 가장 큽니다. 문서를 어떻게 구조화하느냐에 따라 청킹, 임베딩, 검색 정확도가 연쇄적으로 달라지기 때문입니다.
RAG 파이프라인에서 텍스트 추출만으로는 왜 부족한가요?
텍스트만 추출하면 표의 행과 열 관계, 제목과 본문 위계, 이미지 맥락이 모두 사라집니다. 표 구조가 손실되면 LLM이 수치를 잘못 해석하고, 계층 구조가 손실되면 청킹이 어긋나 관련 없는 청크가 검색됩니다.
비정형 문서를 구조화 데이터로 변환하는 과정은 단순히 텍스트를 추출하는 것을 넘어, 문서의 구조와 맥락까지 함께 보존하는 작업입니다. 글자를 추출하는 것과 문서의 논리 구조를 살려내는 것은 전혀 다른 작업이고, 이 차이가 RAG 검색 품질 전체를 좌우합니다.
RAG 파이프라인 문서 파싱 이후 청킹, 임베딩, 검색 연결 흐름
RAG 프로세스는 문서추출 → 파싱 → 청킹 → 임베딩 → 벡터DB 저장 → 검색 → LLM 답변 순서로 동작합니다.
각 단계가 직렬로 연결되어 있어 파싱 단계에서 생긴 품질 문제를 이후 단계에서 되돌리기 어렵습니다. 출력 포맷(JSON/HTML)에 따라 청킹 전략까지 달라지기 때문에, 파싱 방식 선택이 파이프라인 전체 설계에 영향을 줍니다.
문서 파싱 방법에 따라 달라지는 RAG 파이프라인 전 단계 품질
AI가 읽기 어려운 방식으로 파싱되면 청킹 경계가 어긋나고 임베딩 품질이 낮아지면 검색 결과도 정확하지 않게 됩니다. 좋은 LLM을 쓰더라도, 파싱이 잘못된 데이터를 입력받으면 원래 가진 성능을 제대로 발휘하지 못합니다.
Revolutionizing Retrieval(2024) 연구에서는 구조 인식 파서를 적용한 RAG 시스템이 일반 파서 기반 시스템보다 더 높은 답변 정확도를 보였으며, 약 47%의 질문에서 성능 향상이 확인되었습니다. 이는 RAG 성능 개선이 반드시 LLM 교체나 모델 고도화에서만 시작되는 것이 아니라, 문서 파싱 및 구조 분석 품질 개선만으로도 큰 효과를 얻을 수 있음을 보여주는 결과입니다.
RAG 파이프라인 문서 파싱 솔루션 선택 기준
문서 파싱 솔루션을 고를 때 반드시 확인해야 할 기준은 지원 포맷 범위, 구조 추출 정확도, 계층 구조 보존, 보안 환경 대응, 파이프라인 연동 방식 5가지입니다. 하나라도 도입 환경과 맞지 않으면 구축 후 전면 재작업으로 이어질 수 있습니다.
✅ 문서 파싱 솔루션의 지원 포맷 범위, PDF부터 HWP·HWPX, Office까지
도입 환경에서 쓰는 모든 문서 포맷을 네이티브로 지원하는지부터 확인해야 합니다. 특히 HWP·HWPX는 단순 변환이 아니라 원본 구조를 그대로 읽어내는지가 관건입니다.
PDF로 변환해 처리하는 우회 방식은 서식, 각주, 수식이 함께 손실되고, 한 번 손실된 정보는 이후 단계에서 복구할 수 없습니다. 한국 공공·기업 환경에서는 HWP·HWPX 문서의 활용 비중이 높은 만큼, 해당 포맷을 얼마나 정확하게 처리할 수 있는지가 솔루션 선택 시 가장 먼저 확인해야 할 요소입니다.
이 지점에서 한컴 데이터 로더는 명확한 차별점을 갖습니다. HWP SDK 원천 기술을 기반으로 파싱하므로 PDF로 변환하지 않고 HWP 문서의 원본 구조를 그대로 추출합니다. 또한 변경 추적, 각주, 수식, 들여쓰기 등 문서 레이아웃과 서식 정보의 손실을 최소화합니다.
✅ 문서 파싱 솔루션의 구조 추출 정확도, 문서 레이아웃 분석과 표·이미지 처리
OCR(Optical Character Recognition, 광학 문자 인식)만으로는 부족합니다. 다단 레이아웃, 병합 셀, 중첩 표가 포함된 문서를 제대로 처리하려면 DLA(Document Layout Analysis, 문서 구조 분석), TSR(Table Structure Recognition, 표 구조 인식), OCR이 단일 파이프라인 안에서 함께 작동해야 합니다.
세 기술이 분리되어 있으면 다단 레이아웃과 캡션이 혼동되고, 병합 셀의 행·열 관계가 손실되어 표 안의 수치를 LLM이 정확하게 해석하지 못합니다.
한컴 데이터 로더는 DLA·TSR·OCR을 외부 의존 없이 단일 파이프라인으로 통합해 처리합니다.
※ 이미지 캡셔닝 기능은 현재 PoC 단계로, 상용 출시 일정은 추후 안내될 예정입니다.
✅ RAG 파이프라인 청킹 품질을 결정하는 문서 계층 구조 보존
제목, 소제목, 본문 계층이 파싱 단계에서 보존돼야 청킹이 의미 단위로 이루어지고 검색 정확도가 올라갑니다. 계층이 손실되면 ‘3조 2항’과 같은 조건 논리가 여러 청크로 쪼개져 LLM이 맥락 없이 단편적인 내용만 읽게 됩니다. 들여쓰기 기반 위계가 중요한 한국어 공문서나 법령일수록 그 차이가 크게 나타납니다.
한컴 데이터 로더의 Level 추론 엔진은 문단 스타일, 들여쓰기, 번호 체계를 분석해 계층 레벨을 자동 태깅합니다. 한국어 공문서·보고서 특유의 위계 구조를 인식하도록 설계되어 있어, 국내 공공·행정 문서 처리에 특화된 구조로 볼 수 있습니다.
✅ 문서 파싱 솔루션의 보안 환경 및 배포 방식
문서를 외부 클라우드로 보내지 않고 내부망에서 처리할 수 있는 방식인지부터 확인해야 합니다. 클라우드 API 방식은 문서 외부 전송이 구조적으로 수반되기 때문에, 공공·금융·법무처럼 망분리 환경이 필요한 조직은 도입 자체가 불가능한 경우가 많습니다. 온프레미스 내재화 지원 여부가 도입 검토의 첫 번째 관문이 될 수 있습니다.
한컴 데이터 로더는 Docker REST API로 내부망에 완전 내재화되어, 문서의 외부 유출을 방지하는 구조로 설계되어 있습니다. SaaS 형태로 제공되는 데이터 로더 API는 별도의 설치 과정 없이 API 연동만으로 바로 사용할 수 있어, 보안 요건이 비교적 유연한 환경이나 파일럿 테스트를 진행하려는 경우에 적합합니다.
✅ RAG 파이프라인 연동 방식 확인
파싱 결과물이 JSON, HTML 구조화 포맷으로 출력되는지, REST API와 Docker 지원 여부를 확인합니다. 출력 포맷이 맞지 않으면 파이프라인 연동에 별도 개발 공수가 발생하고, 도입 일정과 비용 모두에 영향을 줍니다.
💡 HWP·HWPX 원본 직접 파싱, DLA·TSR·OCR 단일 파이프라인, 온프레미스 완전 내재화
이 세 가지를 하나로 해결하고 싶다면? 👉 한컴 데이터 로더 살펴보기
RAG 파이프라인 문서 파싱 솔루션 도입 전 주의사항
포맷 지원, 온프레미스 의존 구조, 실제 문서 테스트 결과를 직접 확인해야 합니다. 스펙에 나와 있는 기능이라도 실제로 적용해 보면 다르게 작동하는 경우가 많고, 이 차이를 도입 후에 발견하면 처음부터 다시 작업해야 할 수도 있습니다.
HWP·HWPX 파싱 지원 표기와 실제 처리 방식의 차이 확인하기
대부분 솔루션이 HWP·HWPX 지원을 표기하지만, 실제로는 PDF로 변환해 처리하는 우회 방식을 씁니다. 변환 과정에서 표가 이미지로 바뀌어 TSR이 작동하지 않고, 각주·들여쓰기 같은 서식도 손실되어 이후 복구할 수 없습니다. ‘HWP·HWPX 지원’이라는 표기만으로는 원본 직접 파싱인지 변환 우회인지 알 수 없으니, 처리 방식을 반드시 직접 확인해야 합니다.
온프레미스 문서 파싱 솔루션 도입 전 외부 의존 여부 확인하기
온프레미스라고 홍보하면서도, 실제로는 내부에서 외부 OCR API나 클라우드 모델을 가져다 쓰는 솔루션도 있습니다. 이 경우 문서가 내부망을 벗어나게 되어 보안 요건을 충족하지 못하게 됩니다. OCR, DLA, TSR 엔진이 모두 내재화되어 있는지 기술 구조를 직접 확인하는 것이 중요합니다.
문서 파싱 솔루션 스펙만 보고 도입했을 때 생기는 문제점
스펙에 적힌 대로 기능을 지원하더라도, 실제 보유한 문서에 적용해 보면 추출 품질이 기대와 다를 수 있습니다. 병합 셀이 많은 표, 다단 레이아웃, 스캔본이 섞인 PDF는 표준 테스트 문서와 결과 차이가 크게 납니다.
반드시 실제로 보유한 문서 샘플로 테스트해 보고, 파일럿 기간도 넉넉하게 확보해야 이후 재작업해야 하는 위험을 줄일 수 있습니다. 파싱 품질이 낮은 상태로 RAG를 구축하면 이후 청킹·임베딩·검색 전 단계를 다시 해야 하는 상황이 생깁니다.
한컴 데이터 로더로 RAG 파이프라인 문서 파싱 시작하기
한컴 데이터 로더는 HWP·HWPX·PDF·OOXML 등을 구조화 데이터로 전환하는 문서 파싱 솔루션으로, RAG 파이프라인 구축 시 문서 전처리 단계의 부담을 한 번에 해소합니다.
HWP·HWPX·PDF 원본 파싱과 문서 구조 분석 단일 파이프라인
한컴 데이터 로더는 HWP SDK 원천기술로 PDF 변환 없이 원본에서 직접 추출하고, DLA, TSR, OCR을 단일 파이프라인으로 처리합니다. HWP3.0부터 HWP5.0까지 지원하며 다양한 레이아웃 요소를 손실 없이 보존하고, 포맷에 따라 적용되는 기술 범위가 달라집니다.
| 포맷 | 처리 방식 | OCR | DLA | TSR |
| HWP·HWPX | 원본 바이너리 직접 파싱 | ✔ (선택 적용) | ✔ (선택 적용) | ✔ (선택 적용) |
| 원본 가공 추출 + OCR 연동 | ✔ | ✔ | ✔ | |
| OOXML (DOCX·XLSX·PPTX) | 텍스트 및 기본 구조 추출 | – | – | – |
| PNG·JPG·BMP | OCR + DLA 기반 인식 | ✔ | ✔ | ✔ |
입력 포맷별 출력 포맷 및 기술 적용 범위가 상이합니다. OOXML(DOCX·XLSX·PPTX)은 문서 구조 정보를 포함하는 포맷으로, 일반적으로 텍스트와 기본 구조를 추출할 수 있습니다. 정확한 포맷별 안내는 한컴 데이터 문의하기를 통해 확인할 수 있습니다.
문단 계층 자동 판단으로 RAG 청킹 품질을 높이는 Level 추론 엔진
한컴 데이터 로더는 문단 스타일과 들여쓰기, 번호 체계를 분석해 계층 레벨을 자동으로 태깅함으로써, 청킹 과정에서도 의미 단위를 유지할 수 있도록 돕습니다. 한국어 공문서, 법령, 보고서의 들여쓰기 위계 인식에 최적화되어 있어, 글로벌 솔루션이 약한 한국 문서 영역에서 특히 강점을 발휘합니다.
Docker REST API 기반 온프레미스 완전 내재화와 보안 환경 대응
한컴 데이터 로더는 Docker REST API로 내부망에 완전 내재화되어 외부 전송 없이 보안 요건을 충족합니다. 망분리, 폐쇄망 환경에서도 그대로 운용할 수 있고, SaaS API 방식은 별도 설치 없이 즉시 연동해 사용할 수 있어 빠른 파일럿이나 소규모 테스트에 적합합니다.
추출 결과 검수부터 후보정까지, 데이터 로더 스튜디오
한컴 데이터 로더 스튜디오로 자동 추출 정확도가 낮은 문서를 검토하고 보정할 수 있습니다. 원본과 추출 결과를 나란히 비교·검수·편집하고, 고객사 양식에 특화된 추출 패턴을 학습시킬 수 있어 비표준 문서가 많을수록 효과가 큽니다.
데이터 추출부터 RAG 검색까지, 한컴피디아 연계로 완성되는 단일 스택
한컴 데이터 로더로 문서를 추출하고, 한컴피디아가 청킹·임베딩·벡터DB 저장부터 RAG 검색·질의응답까지 이어받아 단일 스택으로 구성할 수 있습니다. 자체 RAG 개발 여건이 부족한 고객사도 맞춤형 시스템을 갖출 수 있습니다.
문서 파싱 솔루션 관련 자주 묻는 질문
클라우드 기반 문서 파싱 API와 온프레미스 솔루션, 어떤 차이가 있나요?
클라우드 API는 문서를 외부 서버로 전송해 처리하고, 온프레미스는 내부망에 직접 설치해 외부 전송이 없습니다. 망분리 환경이 필요한 조직은 온프레미스 내재화 지원 여부가 도입 가능성을 결정합니다.
RAG 파이프라인에서 문서 파싱 솔루션은 왜 필요한가요?
LLM은 PDF, HWP·HWPX, Microsoft Office 문서를 그대로 읽지 못합니다. 문서 파싱 솔루션이 비정형 문서를 AI가 이해할 수 있는 구조화 데이터로 변환하는 역할을 합니다. 파싱 없이 구축하면 표, 이미지, 계층 구조가 손실된 채로 임베딩되어 검색 정확도가 낮아지게 됩니다.
문서 파싱 솔루션 선택 시 가장 먼저 확인해야 할 기준은 무엇인가요?
처리할 문서 포맷과 보안 환경을 먼저 확인해야 합니다. HWP·HWPX 환경이면 원본 직접 파싱 지원 여부, 폐쇄망 환경이면 온프레미스 내재화 가능 여부를 우선적으로 검토해야 합니다.
RAG 파이프라인, 문서 파싱 솔루션 선택하기 전에 꼭 확인하세요
RAG 품질을 높이고 싶다면 LLM보다 파싱을 먼저 봐야 합니다. 포맷 지원부터 구조 추출, 보안 환경까지 파싱 기준 하나가 맞지 않으면 이후 모든 단계에서 품질이 손실되고, 구축 후 전면 재작업으로 이어질 수 있습니다.
국내 환경에서는 이 기준 자체가 다르게 작동합니다. HWP·HWPX 원본 파싱이 가능해야 하고, 망분리·폐쇄망에서도 운용할 수 있어야 합니다. 글로벌 솔루션 대부분은 이 두 조건 앞에서 막히고, 결국 변환 우회나 클라우드 의존으로 이어져 정보 손실과 보안 리스크를 함께 떠안게 됩니다. 국내 기업·공공 환경에는 처음부터 이 조건을 전제로 설계된 솔루션이 필요합니다.
한컴 데이터 로더는 바로 그 필요에서 출발한 솔루션입니다.
- HWP·HWPX 원본 직접 파싱: HWP SDK 원천 기술 기반, PDF로의 변환 없이 원본 그대로의 레이아웃과 서식 요소 보존
- DLA·TSR·OCR 단일 파이프라인: 외부 의존 없이 완전 내재화, 복잡한 표·다단 레이아웃 정확 추출
- Level 추론 엔진: 한국어 공문서·법령 특유의 들여쓰기 위계 자동 태깅으로 청킹 품질 확보
- Docker REST API 온프레미스: 망분리·폐쇄망 환경에서 외부 전송 없이 완전 내재화 운용
국내 문서 환경에 맞는 파싱 솔루션, 한컴 데이터 로더로 시작해 보십시오.
참고자료
- Lewis et al., 「Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks」, NeurIPS 2020
- Lin, 「Revolutionizing Retrieval-Augmented Generation with Enhanced PDF Structure Recognition」, arXiv:2401.12599, 2024
- Zhang et al., 「Document Parsing Unveiled: Techniques, Challenges, and Prospects for Structured Information Extraction」, arXiv:2410.21169, 2024
- AWS, 「검색 증강 생성(RAG)이란 무엇인가요?」
- IBM, 「RAG, 검색 증강 생성이란 무엇인가요?」