공문서·법령 RAG 검색 실패 원인과 해결 – 한국어 문서 계층 구조 인식법
공문서·법령 RAG(Retrieval-Augmented Generation, 검색 증강 생성) 프로세스 구축은 일반 문서 검색보다 까다롭습니다. 조·항·호·목 계층과 표 구조가 손상되는 순간, AI는 질문과 다른 조항을 근거로 답할 수 있기 때문입니다.
행정기관 전자문서가 AI가 읽기 쉬운 개방형 문서인 HWPX 중심으로 바뀌고 있습니다. 2026년 5월부터 중앙·지방 온나라 문서시스템에는 개방형 문서만 첨부하도록 의무화됐습니다. 공문서를 AI가 활용할 수 있는 형태로 전환하는 흐름은 커지고 있지만, 실제 RAG 구축에서는 조·항·호·목 계층과 공문 표 구조를 어떻게 보존하느냐가 검색 정확도를 좌우합니다.
이 글에서는 공문서·법령 RAG 검색이 실패하는 원인과, 한국어 문서 계층 구조를 보존해 검색 정확도를 높이는 방법을 정리했습니다.
공문서·법령 RAG 검색이 부정확한 이유
공문서·법령 RAG에서 검색이 어려운 이유는 이 문서들이 조·항·호·목 계층과 다단·표 구조를 가지고 있기 때문입니다. 문서 파싱과 청킹 과정에서 이 구조가 제대로 반영되지 않으면, 질문과 맞지 않는 조항이나 불완전한 근거가 검색될 수 있습니다.
한국 공문서에는 세 가지 특징이 겹쳐 있습니다. 국내 업무 환경에 최적화된 HWP·HWPX 포맷, 한국법제연구원이 정리한 편·장·절·관과 조·항·호·목 법령 계층, 그리고 공문 특유의 다단·병합 표입니다. 특히 조·항·호·목은 조항의 의미를 구분하는 기준이 되기 때문에, “제3조 제2항”처럼 위치를 정확히 짚어야 답변의 근거도 명확해집니다. 이런 구조가 손상된 채 저장되면, 검색 모델이나 임베딩을 바꿔도 질문에 맞는 근거를 찾기 어려울 수 있습니다.
공공기관의 AI 도입 수요도 커지고 있습니다. 디지털플랫폼정부위원회는 공공부문 초거대 AI 가이드라인을 개정하면서 RAG를 데이터 학습 방식으로 추가하고, 벡터 데이터베이스(Vector DB) 구축 같은 고려사항을 담았습니다. 문서를 AI가 읽기 쉬운 개방형 포맷으로 옮기는 제도가 자리 잡는 가운데, 실무에서는 HWP·HWPX 포맷과 법령 계층을 어떻게 안정적으로 인식할지가 중요한 과제로 남아 있습니다.
공문서·법령 RAG에서 검색이 어려운 3가지 원인
공문서·법령 RAG에서 검색이 어려운 원인은 크게 세 가지입니다. HWP·HWPX를 정확히 읽으려면 전용 파서가 필요하다는 점, 조·항·호·목 계층이 청킹 과정에서 끊길 수 있다는 점, 공문의 다단·병합 표 구조가 유지되기 어렵다는 점입니다. 세 가지 모두 한국어 문서 구조가 파싱·청킹 과정에 충분히 반영되지 않을 때 생기는 문제입니다.
HWP·HWPX, 전용 파서가 필요한 국내 업무 환경의 문서 포맷
HWP·HWPX는 국내 공공·기업 문서에서 널리 쓰이는 포맷이지만, 주요 글로벌 LLM에 전용 파서가 기본으로 연동돼 있는 것은 아닙니다. 문서 파서(Document Parser)는 파일 구조를 해석해 텍스트와 표, 레이아웃 정보를 추출하는 역할을 하기 때문에, HWP·HWPX를 정확히 읽으려면 해당 구조를 해석할 수 있는 전용 파서가 필요합니다.
기사에 따르면 “한글 문서는 AI가 못 읽는다.”는 통념을 절반의 사실로 봤습니다. 핵심은 AI가 HWP·HWPX를 무조건 못 읽는다는 것이 아니라, 어떤 파서를 연동했는지에 따라 텍스트와 표·레이아웃을 이해하는 정도가 달라진다는 점입니다. 문서 구조가 파싱 단계에서 제대로 추출되지 않으면, 이후 청킹과 검색 단계에서도 정확한 근거를 찾기 어려워질 수 있습니다.
조·항·호·목 계층 – 청킹으로 인한 계층 손실
법령과 공문은 조·항·호·목 단위로 의미가 이어집니다. 그런데 글자 수나 토큰 수만 기준으로 청킹하면 하나의 조문이 여러 조각으로 나뉘거나, 상위 조와 하위 항의 연결이 끊길 수 있습니다.
예를 들어 “제3조”라는 제목과 그 아래 항이 서로 다른 청크로 나뉘면, 검색 단계에서 조항의 맥락이 충분히 반영되지 않을 수 있습니다. 이 경우 사용자가 특정 조항을 물어도 불완전한 조문이나 질문과 다른 조항이 근거로 검색될 수 있습니다.
실제 법령 AI 프로젝트에서도 조문이 청크 경계에서 잘리면 “전항의 경우”, “다만” 같은 단서가 끊겨 의미가 달라질 수 있다는 문제가 확인됐습니다. 이 때문에 조·항 단위를 유지한 채 청킹하는 방식이 중요합니다.
공문 다단·병합 표 – 읽기 순서·행열 관계가 손상되는 문제
공문서에는 다단 구성과 병합 셀·중첩 표가 자주 포함됩니다. 이 구조가 제대로 인식되지 않으면 읽기 순서가 달라지거나, 표의 머리글과 값의 관계가 끊길 수 있습니다.
표는 머리글과 값의 관계가 유지되어야 의미를 이해할 수 있습니다. 예를 들어 “항목”과 “금액”이라는 머리글이 그 아래 숫자와 연결되어야 해당 값이 무엇을 뜻하는지 알 수 있습니다. Microsoft Learn의 RAG 준비 단계 안내에서도 여러 단으로 구성된 콘텐츠는 단일 단과 같은 방식으로 구문 분석하지 않는 편이 좋고, 중첩 표처럼 복잡한 표는 전처리에서 별도 처리가 필요하다고 설명합니다. 이런 구조가 보존되지 않으면 검색 단계에서 맥락이 부족한 숫자나 표 조각이 근거로 사용될 수 있습니다.
세 원인의 핵심은 같습니다. 한국어 문서의 포맷, 계층, 표 구조가 파싱·청킹 과정에 충분히 반영되지 않았다는 점입니다. 따라서 청킹 전에 원본 문서를 정확히 파싱하고, 조·항 계층을 인식하며, 표의 행·열 관계를 복원하는 과정이 필요합니다.
한국어 문서 계층 구조를 인식하는 방법
한국어 문서 계층 구조를 인식하려면 세 가지 과정이 필요합니다. HWP·HWPX를 원본 그대로 직접 파싱하고, 문서의 제목·조·항 계층을 메타데이터로 남기고, 다단·병합 표의 행·열 관계를 복원하는 것입니다.
이는 앞서 살펴본 세 가지 원인에 각각 대응하는 방법입니다.
HWP·HWPX 원본 직접 파싱으로 텍스트·구조 살리기
HWP·HWPX를 PDF 등으로 변환하지 않고 원본 그대로 파싱하면, 변환 과정에서 생길 수 있는 손실을 줄이고 텍스트와 문단·표 구조를 함께 추출할 수 있습니다.
HWP 문서는 내부적으로 여러 계층으로 구성되어 있습니다. 한컴테크가 정리한 파싱 구조를 보면, 최상위 Document 아래에 SectionList가 있고 그 아래 문단을 담는 ParaList가 이어집니다. 원본을 직접 파싱하면 이 계층 정보를 유지한 채 데이터를 추출할 수 있습니다. 반대로 PDF로 변환한 뒤 다시 읽으면 문단 계층이나 표 구조가 손실될 수 있습니다.
DLA로 제목·조·항 계층 인식하고 메타데이터로 보존
DLA(Document Layout Analysis, 문서 구조 분석)은 문서에서 제목·본문·표 영역과 계층 정보를 인식하는 기술입니다. 조·항·호·목 계층을 파악해 각 청크에 “이 내용이 어느 조·항에 속하는지”를 메타데이터로 남기면, 청킹 이후에도 조문 맥락을 함께 활용할 수 있습니다.
예를 들어 “제2장 > 제3조 > 제2항”이라는 제목 경로를 각 청크에 함께 남겨 두면, 검색 단계에서 본문뿐 아니라 해당 청크가 속한 조항 맥락까지 함께 활용할 수 있습니다. HiChunk 연구에서도 문서의 계층 구조를 반영해 청킹했을 때 답변에 필요한 근거 문장을 검색하는 성능이 74.1%에서 81.0%로 향상된 사례를 보고했습니다.
공문서·법령 RAG에서는 이 지점이 중요합니다. 청크 안에 본문만 남고 조·항 위치가 사라지면, 검색 결과가 맞는 문장처럼 보여도 실제로는 다른 조항의 근거일 수 있기 때문입니다. 따라서 청킹 전에 문서 계층을 인식하고, 그 정보를 메타데이터로 남기는 과정이 필요합니다.
TSR로 다단·병합 표의 행·열 복원
TSR(Table Structure Recognition, 표 구조 인식)은 표 이미지 안의 행·열 구조와 병합 셀을 인식해 표의 구조를 복원하는 기술입니다. 표의 구조가 보존되면 공문서의 표에서도 머리글과 값의 연결 관계를 유지하는 데 도움이 됩니다.
이미지로 스캔된 공문이라면 OCR(Optical Character Recognition, 광학 문자 인식)이 셀 안의 글자를 읽고, TSR이 해당 글자가 어느 행·열에 속하는지 파악합니다. 이렇게 행·열 관계가 복원되어야 검색 단계에서 머리글과 값을 함께 근거로 활용할 수 있습니다.
세 과정의 결과는 곧 구조화 데이터로 이어집니다. 한국어 문서의 계층과 표 관계가 보존된 데이터가 있어야, 이후 청킹 단계에서 조문 맥락을 유지하기 쉬워집니다.
계층 구조를 살린 구조화 데이터가 RAG 검색을 되살리는 원리
조·항·호 계층과 표의 행·열 관계가 유지된 구조화 데이터로 문서를 변환하면, 이후 청킹 단계에서 조문 맥락을 기준으로 문서를 나누기 쉬워집니다. 구조가 보존된 데이터가 있어야 검색 단계에서도 질문과 맞는 조항과 표 정보를 근거로 활용할 수 있습니다.
반대로 파싱 단계에서 계층과 표 구조가 사라지면, 임베딩 모델이나 벡터DB를 바꿔도 검색 정확도가 크게 개선되지 않을 수 있습니다. 입력 데이터 자체에 조문 위치와 표 관계가 남아 있지 않으면, RAG도 불완전한 근거를 바탕으로 답변하게 되기 때문입니다.
💡 공문서·법령이 실제로 어떻게 구조화되는지 확인하고 싶다면, 한컴 데이터 로더 라이브 데모에서 문서 파싱 결과를 확인할 수 있습니다.
공문서·법령 RAG 전처리에 한컴 데이터 로더가 필요한 이유
🖥️한컴 데이터 로더
공문서·법령 RAG에서 검색 정확도가 떨어지는 이유는 청킹이나 임베딩 단계에만 있지 않습니다. 그보다 앞서 HWP·HWPX 원본 구조, 조·항·호·목 계층, 표의 행·열 관계가 제대로 추출되지 않으면 검색에 활용할 근거 자체가 불완전해집니다.
한컴 데이터 로더는 HWP·HWPX·PDF·OOXML을 AI가 활용할 수 있는 구조화 데이터로 변환하는 문서 파싱(Document Parsing) 솔루션입니다. 청킹을 직접 수행하는 도구가 아니라, 청킹과 임베딩 단계에서 활용할 수 있도록 문서의 계층과 표 구조를 보존해 추출·파싱하는 역할을 합니다.
HWP·HWPX 원본 직접 파싱과 계층·표 구조화
한컴 데이터 로더는 HWP·HWPX를 PDF로 변환하지 않고 원본 그대로 직접 파싱합니다. 이를 통해 문단 계층, 조문 구조, 표 정보처럼 공문서·법령 RAG에서 중요한 구조 정보를 더 안정적으로 추출할 수 있습니다.
PDF와 이미지는 OCR, DLA, TSR을 기반으로 처리하고, OOXML은 텍스트 추출을 중심으로 처리합니다. 포맷과 문서 특성에 따라 필요한 방식을 적용하기 때문에, 모든 문서에 같은 방식의 전처리를 강제로 적용하지 않습니다.
추출 결과는 JSON 등 구조화 데이터로 제공되며, 문서 계층 정보와 좌표, 병합 셀이나 표 안의 표처럼 복잡한 표 구조까지 함께 활용할 수 있습니다. 즉 한컴 데이터 로더는 공문서·법령 RAG에서 문제가 되는 “조문 위치가 사라지는 문제”와 “표의 머리글과 값이 분리되는 문제”를 줄일 수 있는 전처리 기반을 마련합니다.
공공·법령 문서 처리와 한컴피디아 연계
한컴 데이터 로더는 서식이 일정한 정형 문서와 표·이미지가 섞인 비정형 문서를 문서 유형에 맞게 처리할 수 있습니다. 규정·공문처럼 양식이 반복되는 문서는 규칙 기반으로 처리하고, 표·이미지가 포함된 문서는 AI 기반 분석을 활용해 구조 정보를 함께 추출하는 방식입니다.
공공 적용 사례도 있습니다. 디지털데일리에 따르면 경기도교육청 AI 디지털 플랫폼 구축 사업에서 한컴 데이터 로더는 2,800여 개 학교 홈페이지와 4만여 건의 안내자료, 7,000여 건의 지침·법령 데이터를 AI가 학습할 수 있는 형태로 변환하는 역할을 맡았습니다. HWP·HWPX·PDF 문서를 텍스트와 레벨 정보, 좌표, 복잡한 표까지 구조화한 사례입니다.
이렇게 추출·파싱한 구조화 데이터는 이후 청킹·임베딩·검색·질의응답 단계에서 활용할 수 있습니다. 필요에 따라 한컴피디아와 연계하면, 한컴 데이터 로더가 만든 구조화 데이터를 기반으로 문서 기반 RAG 파이프라인까지 이어갈 수 있습니다.
공문서·법령 RAG 관련 자주 묻는 질문 FAQ
TSR로 다단·병합 표의 행·열 복원
TSR(Table Structure Recognition, 표 구조 인식)은 표 이미지 안의 행·열 구조와 병합 셀을 인식해 표의 구조를 복원하는 기술입니다. 표의 구조가 보존되면 공문서의 표에서도 머리글과 값의 연결 관계를 유지하는 데 도움이 됩니다.
이미지로 스캔된 공문이라면 OCR(Optical Character Recognition, 광학 문자 인식)이 셀 안의 글자를 읽고, TSR이 해당 글자가 어느 행·열에 속하는지 파악합니다. 이렇게 행·열 관계가 복원되어야 검색 단계에서 머리글과 값을 함께 근거로 활용할 수 있습니다.
세 과정의 결과는 곧 구조화 데이터로 이어집니다. 한국어 문서의 계층과 표 관계가 보존된 데이터가 있어야, 이후 청킹 단계에서 조문 맥락을 유지하기 쉬워집니다.
계층 구조를 살린 구조화 데이터가 RAG 검색을 되살리는 원리
조·항·호 계층과 표의 행·열 관계가 유지된 구조화 데이터로 문서를 변환하면, 이후 청킹 단계에서 조문 맥락을 기준으로 문서를 나누기 쉬워집니다. 구조가 보존된 데이터가 있어야 검색 단계에서도 질문과 맞는 조항과 표 정보를 근거로 활용할 수 있습니다.
반대로 파싱 단계에서 계층과 표 구조가 사라지면, 임베딩 모델이나 벡터DB를 바꿔도 검색 정확도가 크게 개선되지 않을 수 있습니다. 입력 데이터 자체에 조문 위치와 표 관계가 남아 있지 않으면, RAG도 불완전한 근거를 바탕으로 답변하게 되기 때문입니다.
💡 공문서·법령이 실제로 어떻게 구조화되는지 확인하고 싶다면, 한컴 데이터 로더 라이브 데모에서 문서 파싱 결과를 확인할 수 있습니다.
공문서·법령 RAG 전처리에 한컴 데이터 로더가 필요한 이유
🖥️한컴 데이터 로더
공문서·법령 RAG에서 검색 정확도가 떨어지는 이유는 청킹이나 임베딩 단계에만 있지 않습니다. 그보다 앞서 HWP·HWPX 원본 구조, 조·항·호·목 계층, 표의 행·열 관계가 제대로 추출되지 않으면 검색에 활용할 근거 자체가 불완전해집니다.
한컴 데이터 로더는 HWP·HWPX·PDF·OOXML을 AI가 활용할 수 있는 구조화 데이터로 변환하는 문서 파싱(Document Parsing) 솔루션입니다. 청킹을 직접 수행하는 도구가 아니라, 청킹과 임베딩 단계에서 활용할 수 있도록 문서의 계층과 표 구조를 보존해 추출·파싱하는 역할을 합니다.
HWP·HWPX 원본 직접 파싱과 계층·표 구조화
한컴 데이터 로더는 HWP·HWPX를 PDF로 변환하지 않고 원본 그대로 직접 파싱합니다. 이를 통해 문단 계층, 조문 구조, 표 정보처럼 공문서·법령 RAG에서 중요한 구조 정보를 더 안정적으로 추출할 수 있습니다.
PDF와 이미지는 OCR, DLA, TSR을 기반으로 처리하고, OOXML은 텍스트 추출을 중심으로 처리합니다. 포맷과 문서 특성에 따라 필요한 방식을 적용하기 때문에, 모든 문서에 같은 방식의 전처리를 강제로 적용하지 않습니다.
추출 결과는 JSON 등 구조화 데이터로 제공되며, 문서 계층 정보와 좌표, 병합 셀이나 표 안의 표처럼 복잡한 표 구조까지 함께 활용할 수 있습니다. 즉 한컴 데이터 로더는 공문서·법령 RAG에서 문제가 되는 “조문 위치가 사라지는 문제”와 “표의 머리글과 값이 분리되는 문제”를 줄일 수 있는 전처리 기반을 마련합니다.
공공·법령 문서 처리와 한컴피디아 연계
한컴 데이터 로더는 서식이 일정한 정형 문서와 표·이미지가 섞인 비정형 문서를 문서 유형에 맞게 처리할 수 있습니다. 규정·공문처럼 양식이 반복되는 문서는 규칙 기반으로 처리하고, 표·이미지가 포함된 문서는 AI 기반 분석을 활용해 구조 정보를 함께 추출하는 방식입니다.
공공 적용 사례도 있습니다. 디지털데일리에 따르면 경기도교육청 AI 디지털 플랫폼 구축 사업에서 한컴 데이터 로더는 2,800여 개 학교 홈페이지와 4만여 건의 안내자료, 7,000여 건의 지침·법령 데이터를 AI가 학습할 수 있는 형태로 변환하는 역할을 맡았습니다. HWP·HWPX·PDF 문서를 텍스트와 레벨 정보, 좌표, 복잡한 표까지 구조화한 사례입니다.
이렇게 추출·파싱한 구조화 데이터는 이후 청킹·임베딩·검색·질의응답 단계에서 활용할 수 있습니다. 필요에 따라 한컴피디아와 연계하면, 한컴 데이터 로더가 만든 구조화 데이터를 기반으로 문서 기반 RAG 파이프라인까지 이어갈 수 있습니다.
공문서·법령 RAG 관련 자주 묻는 질문 FAQ
TSR로 다단·병합 표의 행·열 복원
TSR(Table Structure Recognition, 표 구조 인식)은 표 이미지 안의 행·열 구조와 병합 셀을 인식해 표의 구조를 복원하는 기술입니다. 표의 구조가 보존되면 공문서의 표에서도 머리글과 값의 연결 관계를 유지하는 데 도움이 됩니다.
이미지로 스캔된 공문이라면 OCR(Optical Character Recognition, 광학 문자 인식)이 셀 안의 글자를 읽고, TSR이 해당 글자가 어느 행·열에 속하는지 파악합니다. 이렇게 행·열 관계가 복원되어야 검색 단계에서 머리글과 값을 함께 근거로 활용할 수 있습니다.
세 과정의 결과는 곧 구조화 데이터로 이어집니다. 한국어 문서의 계층과 표 관계가 보존된 데이터가 있어야, 이후 청킹 단계에서 조문 맥락을 유지하기 쉬워집니다.
계층 구조를 살린 구조화 데이터가 RAG 검색을 되살리는 원리
조·항·호 계층과 표의 행·열 관계가 유지된 구조화 데이터로 문서를 변환하면, 이후 청킹 단계에서 조문 맥락을 기준으로 문서를 나누기 쉬워집니다. 구조가 보존된 데이터가 있어야 검색 단계에서도 질문과 맞는 조항과 표 정보를 근거로 활용할 수 있습니다.
반대로 파싱 단계에서 계층과 표 구조가 사라지면, 임베딩 모델이나 벡터DB를 바꿔도 검색 정확도가 크게 개선되지 않을 수 있습니다. 입력 데이터 자체에 조문 위치와 표 관계가 남아 있지 않으면, RAG도 불완전한 근거를 바탕으로 답변하게 되기 때문입니다.
💡 공문서·법령이 실제로 어떻게 구조화되는지 확인하고 싶다면, 한컴 데이터 로더 라이브 데모에서 문서 파싱 결과를 확인할 수 있습니다.
공문서·법령 RAG 전처리에 한컴 데이터 로더가 필요한 이유
🖥️한컴 데이터 로더
공문서·법령 RAG에서 검색 정확도가 떨어지는 이유는 청킹이나 임베딩 단계에만 있지 않습니다. 그보다 앞서 HWP·HWPX 원본 구조, 조·항·호·목 계층, 표의 행·열 관계가 제대로 추출되지 않으면 검색에 활용할 근거 자체가 불완전해집니다.
한컴 데이터 로더는 HWP·HWPX·PDF·OOXML을 AI가 활용할 수 있는 구조화 데이터로 변환하는 문서 파싱(Document Parsing) 솔루션입니다. 청킹을 직접 수행하는 도구가 아니라, 청킹과 임베딩 단계에서 활용할 수 있도록 문서의 계층과 표 구조를 보존해 추출·파싱하는 역할을 합니다.
HWP·HWPX 원본 직접 파싱과 계층·표 구조화
한컴 데이터 로더는 HWP·HWPX를 PDF로 변환하지 않고 원본 그대로 직접 파싱합니다. 이를 통해 문단 계층, 조문 구조, 표 정보처럼 공문서·법령 RAG에서 중요한 구조 정보를 더 안정적으로 추출할 수 있습니다.
PDF와 이미지는 OCR, DLA, TSR을 기반으로 처리하고, OOXML은 텍스트 추출을 중심으로 처리합니다. 포맷과 문서 특성에 따라 필요한 방식을 적용하기 때문에, 모든 문서에 같은 방식의 전처리를 강제로 적용하지 않습니다.
추출 결과는 JSON 등 구조화 데이터로 제공되며, 문서 계층 정보와 좌표, 병합 셀이나 표 안의 표처럼 복잡한 표 구조까지 함께 활용할 수 있습니다. 즉 한컴 데이터 로더는 공문서·법령 RAG에서 문제가 되는 “조문 위치가 사라지는 문제”와 “표의 머리글과 값이 분리되는 문제”를 줄일 수 있는 전처리 기반을 마련합니다.
공공·법령 문서 처리와 한컴피디아 연계
한컴 데이터 로더는 서식이 일정한 정형 문서와 표·이미지가 섞인 비정형 문서를 문서 유형에 맞게 처리할 수 있습니다. 규정·공문처럼 양식이 반복되는 문서는 규칙 기반으로 처리하고, 표·이미지가 포함된 문서는 AI 기반 분석을 활용해 구조 정보를 함께 추출하는 방식입니다.
공공 적용 사례도 있습니다. 디지털데일리에 따르면 경기도교육청 AI 디지털 플랫폼 구축 사업에서 한컴 데이터 로더는 2,800여 개 학교 홈페이지와 4만여 건의 안내자료, 7,000여 건의 지침·법령 데이터를 AI가 학습할 수 있는 형태로 변환하는 역할을 맡았습니다. HWP·HWPX·PDF 문서를 텍스트와 레벨 정보, 좌표, 복잡한 표까지 구조화한 사례입니다.
이렇게 추출·파싱한 구조화 데이터는 이후 청킹·임베딩·검색·질의응답 단계에서 활용할 수 있습니다. 필요에 따라 한컴피디아와 연계하면, 한컴 데이터 로더가 만든 구조화 데이터를 기반으로 문서 기반 RAG 파이프라인까지 이어갈 수 있습니다.
공문서·법령 RAG 관련 자주 묻는 질문 FAQ
공문서·법령을 RAG에 넣으면 왜 검색이 잘 안 되나요?
공문서·법령은 조·항·호·목 계층과 표 구조가 함께 유지되어야 의미를 정확히 이해할 수 있습니다. 이 구조가 파싱·청킹 과정에서 끊기면 검색 단계에서 질문과 맞지 않는 조항이나 불완전한 근거가 선택될 수 있습니다. 따라서 임베딩 모델이나 벡터DB를 바꾸기 전에, 원본 문서 구조가 제대로 추출됐는지 먼저 확인해야 합니다.
HWP는 왜 AI가 바로 못 읽나요?
HWP는 문서 내부 구조를 해석할 수 있는 전용 파서가 필요합니다. 주요 글로벌 LLM에 HWP 전용 파서가 기본으로 연동되어 있는 것은 아니기 때문에, 별도 파서 없이 처리하면 텍스트와 표·레이아웃 구조가 충분히 반영되지 않을 수 있습니다. 즉 AI가 HWP를 무조건 못 읽는 것이 아니라, 형식에 맞는 문서 파서(Document Parser)를 연동해야 정확하게 활용할 수 있습니다.
법령의 조·항·호·목 계층을 어떻게 살리나요?
원본 파일 자체의 구조를 분석해 제목, 조, 항, 호, 목의 계층을 1차로 인식하고, 필요한 경우 DLA로 계층 인식을 보완합니다. 각 청크에 해당 내용이 어느 조항에 속하는지 메타데이터로 남기면, 예를 들어 “제2장 > 제3조 > 제2항” 같은 제목 경로가 함께 저장되어 이후 검색 단계에서도 본문뿐 아니라 조문 맥락을 함께 활용할 수 있습니다.
한컴 데이터 로더가 청킹까지 해 주나요?
한컴 데이터 로더는 청킹을 직접 수행하지 않습니다. 한컴 데이터 로더는 HWP·HWPX·PDF·OOXML 문서를 추출·파싱해 계층과 표 구조가 보존된 구조화 데이터로 변환하는 역할을 합니다. 이렇게 만들어진 구조화 데이터는 이후 청킹·임베딩·검색 단계에서 활용할 수 있으며, 필요에 따라 한컴피디아와 연계해 RAG 파이프라인에 사용할 수 있습니다.
공문서·법령 RAG 검색 정확도를 높이는 문서 파서
공문서·법령 RAG의 검색 정확도는 청킹 전에 문서 구조가 얼마나 잘 추출됐는지에서 시작됩니다. 조문 계층과 표 관계가 구조화 데이터에 남아 있어야, 이후 검색 단계에서도 질문에 맞는 근거를 안정적으로 활용할 수 있습니다.
한컴 데이터 로더는 HWP·HWPX·PDF·OOXML 문서를 AI가 활용할 수 있는 구조화 데이터로 변환하는 문서 파싱(Document Parsing) 솔루션입니다. 한컴 데이터 로더 라이브 데모에서 직접 문서를 업로드해 파싱 결과를 확인하고, 자사의 RAG 전처리 환경에 맞는 도입 방식을 검토할 수 있습니다.
👉 설치 없이 문서 넣어서, 파싱 결과 확인해 보기 (라이브 데모)
참고 자료
- arXiv, Lu et al., 「HiChunk: Evaluating and Enhancing Retrieval-Augmented Generation with Hierarchical Chunking」, 2025
- Microsoft Learn, 「Azure RAG 솔루션 개발 – 준비 단계」, 2026
- 한국법제연구원, 「법령 조문체계(편·장·절·관 / 조·항·호·목)」
- 단비뉴스, 안소현·김예은, 「한글 문서는 AI가 못 읽는다?」, 2026
- 한컴테크, 「한/글 문서 파일 형식: Python을 통한 HWP 포맷 파싱하기 (2)」, 2025
