한글·워드 문서 파싱, JSON 등 구조화 데이터로 변환하는 방법

한글 문서 파싱과 워드 문서 파싱(Document Parsing)은 사내 문서를 RAG(Retrieval-Augmented Generation, 검색 증강 생성)나 LLM에 연결하려 할 때 가장 먼저 직면하는 과제입니다. 수십 년간 쌓인 한글·워드 문서에는 법령·정책·업무 맥락이 그대로 담겨 있지만, 파일을 가공 없이 그대로 입력하면 표와 각주 같은 구조 정보가 손상되어 잘못된 답변으로 이어집니다. 공공 문서를 AI 원료로 쓰려는 수요가 커지는 지금, 문서를 JSON 등 구조화 데이터로 정확히 바꾸는 방법을 이 글에서 포맷별로 정리했습니다.

한글·워드 문서, 정확한 파싱이 중요한 이유

문서 파싱이 정확하지 않을 때 RAG 답변이 부정확해지는 이유

문서 파싱 단계에서 오류가 생기면 RAG 답변도 부정확해지는 이유는 문서 구조가 손상된 채 글자만 추출되면 뒤따르는 청킹(Chunking, 문서를 조각으로 나누는 단계) 기준까지 어긋나 검색 정확도가 떨어지고 근거가 빈 답변으로 이어지기 때문입니다.

한글 문서 파싱이 특히 까다로운 건 HWP·HWPX가 글자만 나열된 파일이 아니라는 데 있습니다. 한컴테크의 HWP 포맷 분석을 보면 HWP는 파일 하나 안에 여러 폴더와 데이터 묶음이 든 형식이라, 표·각주·문단 계층이 서로 다른 자리에 나뉘어 저장됩니다. 이 구조를 무시하고 글자만 추출하면 표가 한 줄로 뒤섞여 정리되고 각주가 사라집니다.

이렇게 잃어버린 구조는 검색 품질을 직접 떨어뜨립니다.  DLA(Document Layout Analysis, 문서 구조 분석) 연구에서는 문서를 의미 있는 영역 단위로 먼저 나눈 뒤 검색에 넣었더니, 영역을 나누지 않은 기존 방식 대비 텍스트 기반 RAG 정확도가 최대 9.4포인트, 이미지까지 함께 보는 RAG 정확도가 최대 10.4포인트 올랐다고 나타났습니다. 즉, ‘구조를 어떻게 잘 보존하느냐’가 답변 정확도를 결정합니다.

정확한 문서 파싱을 위해 필요한 조건

정확한 문서 파싱을 위해 필요한 조건은 DLA·TSR(Table Structure Recognition, 표 구조 인식)·OCR(Optical Character Recognition, 광학 문자 인식) 세 기술이 함께 작동하는 것입니다.

DLA는 딥러닝으로 문서 안의 텍스트·이미지·표·그래픽을 구분하고 읽는 순서까지 잡아주는 기술입니다. TSR은 표의 셀과 행·열 관계를 복원하고, OCR은 스캔본이나 이미지 속 글자를 기계가 읽을 수 있는 형태로 바꿉니다. OCR이 ‘무엇이 적혀 있는지’를 읽는 기술이라면 파싱은 ‘어떤 구조로 놓여 있는지’를 이해하는 단계입니다.

셋 중 하나만 빠져도 결과가 흔들립니다. 문서 파싱 기술 정리 연구는 문서 파싱을 DLA에 텍스트·표·수식 인식을 결합한 모듈형 방식과, 이미지와 언어를 함께 보는 통합 모델 방식으로 나눠 설명합니다. 어느 쪽이든 구조를 읽는 단계와 글자를 읽는 단계가 함께 이루어져야 한다는 점은 같습니다.

한글(HWP·HWPX) 문서 파싱 방법

HWP 파일에서 텍스트와 표 데이터를 추출하는 방법

HWP·HWPX 파일에서 텍스트와 표 데이터를 추출하는 방법은, PDF로 바꾸지 않고 원본 파일을 직접 파싱해 표 구조·각주·메타데이터를 그대로 보존하는 것입니다.

HWP는 파일 하나 안에 여러 폴더와 파일이 담긴 CFB(Compound File Binary File Format, 복합 파일 이진 형식)입니다. 한컴테크의 Python HWP 파싱 사례를 보면 문서의 버전 정보, 글꼴 같은 공통 속성, 실제 본문, 문서에 삽입된 이미지가 각각 다른 자리에 나뉘어 저장됩니다. 각 데이터에는 종류를 알려주는 꼬리표(Tag)와 크기 정보가 붙어 있고 대부분 압축된 채로 들어 있어, 기계가 읽으려면 이 구조를 하나씩 풀어 해석하는 과정을 거쳐야 합니다.

원본을 직접 파싱하면 이 과정에서 문서 속성 정보를 원래 모습대로 추출할 수 있습니다. 반대로 PDF로 한 번 변환한 뒤 추출하면 표의 구조가 손상되고 텍스트가 뒤섞이게 되니, 원본 직접 파싱이 구조 손실을 줄이는 안정적인 방법입니다.

💡 HWP 원본 파싱이 실제로 어떻게 동작하는지 궁금하다면? 

한컴 데이터 로더 라이브 데모에서 직접 확인할 수 있습니다.

한글 문서 파싱이 어려운 이유

한글 문서 파싱이 어려운 이유는, HWP·HWPX가 국내 업무 환경에 최적화된 독자 포맷이라 문단 중심의 계층 구조를 이해해야 제대로 읽히기 때문입니다.

가장 큰 문제는 도구가 부족하다는 점입니다. 한컴테크가 오픈소스 생태계 현황을 파악한 이후로도 뷰어·에디터 형태의 오픈소스는 계속 늘고 있지만, 대부분 문서를 열람하거나 단순 텍스트를 추출하는 데 머물러 있어 표나 메타데이터 같은 구조 정보까지 온전히 다루는 도구는 여전히 드뭅니다.

그래서 다수의 개발자가 HWP·HWPX를 PDF로 변환한 뒤 추출하는 ‘이중 변환’을 택하는데, 이 과정에서 의미 구조 태그가 손상되고 표·개체가 소실되며 텍스트 순서가 뒤바뀌는 손실이 발생합니다. 처리 속도도 저하되어, 같은 분석에서 이중 변환은 원본을 직접 추출할 때(9.5초)보다 약 15.8배 더 오래 걸린 것으로 나타났습니다. 결국 한글 문서는 원본 구조를 직접 다룰 수 있느냐에 따라 파싱 품질과 속도가 결정됩니다.

워드 문서 파싱 방법

워드·엑셀·파워포인트 파싱에서 주의할 점

워드·엑셀·파워포인트, 곧 OOXML 문서를 파싱할 때 주의할 점은, 이들은 이미 XML로 구조화된 포맷이라 DLA·TSR을 적용하지 않고 텍스트 추출 방식으로 처리한다는 점입니다.

OOXML은 파일 내부에 글의 내용과 서식이 XML 태그로 정리돼 있어, 이 구조 정보를 그대로 활용해 텍스트·표·이미지를 추출할 수 있습니다. 다만 좋은 추출 품질을 위해서는 워드 문서 역시 HWP·HWPX와 마찬가지로 DLA 단계를 함께 거치는 편이 안정적입니다.

주의할 점은 처리 방식이 단순하다고 결과 품질까지 보장되지는 않는다는 것입니다. Databricks 기술 문서는 파싱과 청킹을 RAG의 가장 앞단 최적화 계층으로 꼽으며, 이 단계에서 데이터가 얼마나 깨끗하고 구조적으로 정리되느냐가 이후 검색 품질을 좌우한다고 설명합니다. 이처럼 텍스트 추출 방식이라도 표의 행·열이 어긋나지 않게 정리하는 후처리가 중요합니다.

한눈에 살펴보는 한글 HWP와 워드 파싱의 차이

한글(HWP·HWPX)과 워드 파싱의 가장 큰 차이는 처리 방식입니다. HWP는 이진 바이너리 파일, HWPX는 워드와 마찬가지로 XML 기반 파일 포맷이지만, 한컴 데이터 로더는 HWP·HWPX 모두 원본 파일을 직접 파싱해 구조를 보존하고, 워드는 텍스트를 추출하는 방식으로 처리합니다.

구분	HWP·HWPX	워드
처리 방식	원본 바이너리 직접 파싱	텍스트 추출
구조 보존 범위	표 구조·각주·메타데이터 보존	텍스트·표·이미지 기본 인식
PDF 변환 필요 여부	불필요	해당 없음
DLA·TSR 적용 여부	적용	미적용

두 포맷 모두 구조화 데이터로 바꿀 수 있지만, HWP·HWPX는 원본 구조까지 보존하는 방식이고 워드는 이미 정리된 텍스트를 추출하는 방식에 가깝습니다.

포맷별 출력 결과와 RAG 연계

한글(HWP·HWPX) 문서, JSON으로 변환되는 과정

한글(HWP·HWPX) 문서가 JSON으로 변환되는 과정은 사용 환경에 따라 달라집니다. 스튜디오에서는 JSON으로 출력하고 뷰어에서 결과를 확인할 수 있으며, 솔루션에서는 JSON과 Clientinfo로, API SaaS에서는 JSON으로 출력됩니다.

사용 환경	입력 포맷	출력 형식
스튜디오	PDF	JSON·HTML
스튜디오	HWP·HWPX	JSON
솔루션	PDF AI·HWP·HWPX	JSON·Clientinfo
솔루션	OOXML·PDF	Clientinfo
API SaaS	PDF·HWP·HWPX	JSON

표에서 보듯 한글 문서는 스튜디오·솔루션·API SaaS 어느 환경에서도 JSON을 얻을 수 있습니다. 데이터 로더 스튜디오는 자동 추출 결과를 원본 문서와 나란히 비교하며 검토할 수 있는 확장 솔루션으로, 사용자는 계층·카테고리·읽기 순서 등을 직접 확인하고 필요한 부분을 후보정할 수 있습니다. 여기서 나온 JSON에는 문서의 계층 정보가 함께 담깁니다.

이렇게 출력된 구조화 데이터의 품질이 왜 중요한지는 OCR과 RAG 연계 연구에서도 확인할 수 있습니다. 추출 단계에서 발생한 오류가 이후의 검색·답변까지 그대로 전달되어, 앞단 품질이 전체 결과의 상한선을 정한다고 말합니다.

💡 스튜디오·솔루션·API SaaS 환경별로 어떤 기능 차이가 있는지 궁금하다면? 

한컴 데이터 로더 제품 소개 페이지에서 자세히 확인할 수 있습니다.

워드 문서의 출력 형식, Clientinfo 방식이 다른 이유

워드 문서가 JSON으로 바로 변환되지 않고 Clientinfo 형식으로 출력되는 이유는 출력 형식이 입력 포맷만이 아니라 사용 환경과 입력 포맷의 조합에 따라 결정되기 때문입니다. 솔루션 환경에서는 OOXML과 PDF 문서가 Clientinfo 형식의 텍스트 기반 데이터로 출력됩니다.

앞의 표를 다시 보면 HWP·HWPX는 스튜디오, 솔루션, API SaaS 어디서든 JSON으로 출력됩니다. 반면 워드 문서는 솔루션 환경에서 Clientinfo 형식의 텍스트 기반 데이터로 출력됩니다. 즉, 워드 문서가 처리되지 않는다는 의미가 아니라 사용 환경에 따라 제공되는 출력 형식이 다르다는 뜻입니다.

따라서 ‘워드 문서를 넣으면 곧바로 JSON이 출력된다’고 기대했다면 실제 출력 형식은 환경에 따라 달라질 수 있다는 점을 확인해 둘 필요가 있습니다. RAG 파이프라인을 설계할 때는 다루려는 문서 포맷뿐 아니라 사용 환경에서 어떤 출력 형식을 제공하는지도 함께 확인하는 것이 좋습니다.

표(병합 셀·다단 헤더)를 JSON으로 정확하게 변환하는 방법

표의 병합 셀이나 다단 헤더를 JSON으로 정확하게 변환하는 방법은, TSR로 셀 사이의 관계를 복원해 셀·행·열 단위로 Markdown·JSON·HTML로 내보내는 것입니다.

표는 문서에서 구조가 가장 쉽게 손상되는 요소입니다. 여러 칸이 하나로 합쳐진 병합 셀, 머리글이 두 줄로 나뉜 다단 헤더, 표 안에 다시 표가 들어간 중첩 표는 글자만 추출하면 행과 열이 어긋납니다. TSR은 이런 표에서 셀의 위치와 관계를 다시 계산해 원래 구조대로 복원합니다.

기하학적으로 뒤틀린 표까지 인식하려는 시도는 연구로도 이어져 왔습니다. 표 구조 인식 연구는 셀을 가르는 분리선을 직접 추정하는 방식으로 병합 셀이 있는 복잡한 표의 구조를 복원해, 여러 표 인식 벤치마크에서 높은 성능을 보고했습니다. 한글 문서는 원본 바이너리에 표 구조가 이미 담겨 있어 직접 파싱으로 보존하고, PDF나 이미지 속 표는 TSR 기술로 복원하는 방식으로 경로가 나뉩니다.

문서 추출부터 답변 생성까지, RAG 프로세스

문서 추출부터 답변 생성까지 이어지는 RAG 프로세스는 일곱 단계로 정리되고, 한컴 데이터 로더는 이 가운데 앞의 두 단계인 문서 추출과 파싱까지를 담당합니다.

1. 문서 추출 – 원본 문서에서 내용을 꺼냅니다
2. 파싱 – 제목·본문·표 구조를 구분해 구조화 데이터로 정리합니다
3. 청킹 – 문서를 검색에 알맞은 조각으로 나눕니다
4. 임베딩 – 각 조각을 숫자 벡터로 바꿉니다
5. 벡터DB 저장 – 벡터를 검색용 데이터베이스에 담습니다
6. 검색 – 질문과 가까운 조각을 찾습니다
7. LLM 답변 – 찾은 조각을 근거로 답을 만듭니다

위 3번부터 7번까지, 즉 청킹부터 답변 생성까지는 자사 RAG 솔루션 한컴피디아가 맡는 영역입니다. 데이터 로더가 추출·파싱한 계층 정보는 이후 한컴피디아가 문서를 의미 단위로 나눌 때 그 기준이 됩니다. Microsoft 기술 문서도 레이아웃 정보를 먼저 추출한 뒤 의미 기반으로 청킹해 표·문단을 한 덩어리로 유지하는 흐름을 소개하는데, 앞단에서 구조를 정확히 설정할수록 뒤 단계가 용이해진다는 점은 두 사례 모두 동일합니다.

문서 파싱 솔루션, 고르는 기준

RAG를 위한 문서 전처리 도구, 무엇을 기준으로 골라야 할까

RAG를 위한 문서 전처리 도구는 구조 보존 정확도, 표·이미지 같은 복합 요소 처리 능력, 배포 환경의 유연성 세 가지를 기준으로 고르면 됩니다.

먼저 구조 보존 정확도는 표·각주·문단 계층을 원본대로 보존하는지를 봅니다. 문서 종류가 다양할수록 이 차이가 벌어지는데, 문서 파싱 벤치마크 연구는 논문·교과서·필기·신문 등 아홉 가지 문서와 열아홉 개 레이아웃 항목으로 나눠 평가해야 파싱 성능을 공정하게 비교할 수 있다고 설명합니다. 특정 문서에서만 우수한 도구는 실제 업무 문서에서는 성능이 불안정해질 수 있다는 뜻입니다.

다음은 복합 요소 처리 능력입니다. 병합 셀 표, 스캔 이미지, 여러 단으로 나뉜 문서까지 다루려면 DLA·OCR·TSR이 함께 필요합니다. 마지막은 배포 환경입니다. 문서를 외부로 보낼 수 없는 공공·금융이라면 내부 서버에 설치하는 온프레미스가, 빠른 파일럿이 목적이라면 사용한 만큼 과금되는 SaaS API 방식이 맞습니다.

한컴 데이터 로더는 HWP·HWPX·PDF·OOXML을 이 세 기준에 맞춰 구조화 데이터로 전환하고, 온프레미스와 SaaS API 배포를 모두 지원합니다.

💡 입력 포맷별로 정확히 어떤 출력이 나오는지 한눈에 정리한 가이드가 궁금하다면? 

한컴 데이터 로더 시작 가이드에서 확인할 수 있습니다.

실제 도입 사례로 보는 문서 파싱의 효과

문서 파싱의 효과는 경기도교육청 사례에서 잘 드러납니다. 디지털데일리 보도에 따르면 한컴 데이터 로더는 약 2,800개 학교 홈페이지와 4만여 건의 안내자료, 7,000여 건의 법령·지침을 AI가 학습할 수 있는 구조화 데이터로 변환했습니다.

이 사업은 LG CNS 컨소시엄이 주관한 ‘AI·데이터 중심의 경기교육 디지털플랫폼 구축’으로, 전국 시도교육청 가운데 처음 추진된 대규모 AI 플랫폼입니다. 한컴 데이터 로더는 HWP·HWPX·PDF 문서를 파싱해 AI 학습 데이터로 만드는 앞단을 맡았고, 이후 질의응답과 문서작성 지원은 자사 RAG 솔루션 한컴피디아와 한컴어시스턴트로 이어졌습니다. 아이티데일리 보도처럼 쌓여 있던 공공 문서를 AI가 쓸 수 있는 자산으로 바꾸는 ‘데이터화’가 실제로 구현된 사례입니다.

💡 문서 파싱은 그 자체가 목적이 아니라 RAG 구축의 첫 시작입니다. 

문서를 구조화하는 단계부터 다음 단계인 RAG 검색·답변까지 함께 고민 중이라면, 한컴 데이터 로더에 상담할 수 있습니다.

자주 묻는 질문

한글·워드 문서 파싱, 포맷에 맞는 방식이 RAG 품질을 가른다

한글 문서 파싱과 워드 문서 파싱은 접근이 다릅니다. HWP·HWPX는 원본 바이너리를 직접 파싱해 표·각주·메타데이터까지 보존하고, 워드는 이미 구조화된 텍스트를 추출하며, 출력은 환경에 따라 JSON이나 Clientinfo로 나뉩니다. 어느 경우든 파싱 단계에서 구조를 얼마나 정확히 보존하느냐가 이후 RAG 검색·답변의 품질을 결정합니다.

문서 파싱은 단순히 글자를 추출하는 작업이 아니라, 쌓여 있는 문서를 AI가 쓸 수 있는 데이터로 바꾸는 첫 단계로 봐야 합니다. 포맷마다 다른 처리 방식을 하나의 파이프라인으로 다룰 수 있느냐가 결국 도구 선택의 기준이 되기 때문입니다.

한컴 데이터 로더는 HWP·HWPX·PDF·OOXML을 구조화 데이터로 전환하는 문서 파싱 솔루션입니다. 추출된 데이터는 자사 RAG 솔루션 한컴피디아와 연계해 문서 수집부터 검색·답변까지 한컴 단일 스택으로 구축할 수 있습니다. 에이전트가 신뢰할 수 있는 문서 전처리, 한컴 데이터 로더로 시작할 수 있습니다.

👉 한컴 데이터 로더 둘러보기 

👉 한컴 데이터 로더 API 가이드 보기 

---

참고 자료

1. arXiv, Dong et al., 「SCAN: Semantic Document Layout Analysis for Textual and Visual Retrieval-Augmented Generation」, 2025
2. arXiv, Zhang et al., 「Document Parsing Unveiled: Techniques, Challenges, and Prospects for Structured Information Extraction」, 2024
3. arXiv, Zhang et al., 「OCR Hinders RAG: Evaluating the Cascading Impact of OCR on Retrieval-Augmented Generation」, 2024
4. arXiv, Lin et al., 「TSRFormer: Table Structure Recognition with Transformers」, 2022
5. arXiv, Ouyang et al., 「OmniDocBench: Benchmarking Diverse PDF Document Parsing with Comprehensive Annotations」, 2024
6. Databricks, 「Build an unstructured data pipeline for RAG」
7. Microsoft, 「Complex Data Extraction using Document Intelligence and RAG」
8. 한컴테크, 정우진, 「한/글 문서 파일 형식: HWP 포맷 구조 살펴보기」, 2025
9. 한컴테크, 정우진, 「한/글 문서 파일 형식: Python을 통한 HWP 포맷 파싱하기 (1)」, 2025
10. 한컴테크, 윤영길, 「AX 시대를 위한 한글 문서: 오픈소스 생태계 현황 분석과 활성화 전략」, 2025
11. 디지털데일리, 이안나, 「한컴, 경기도교육청 AI 플랫폼 구축사업 참여」, 2025
12. 뉴시스, 송혜리, 「한컴, AI 기반 ‘경기교육 디지털플랫폼 구축’ 사업 참여」, 2025
13. 아이티데일리, 「[AI 솔루션 컨퍼런스] 한컴 “쌓인 공공 문서를 AI 자산으로…핵심은 ‘데이터화'”」, 2025