RAG 청킹 품질 높이는 법 – 문서 계층 구조를 살린 전처리 전략

RAG(Retrieval-Augmented Generation, 검색 증강 생성) 청킹 품질이 낮으면 문서를 업로드했을 때 잘못된 답변이 나올 수 있습니다.

문서가 파싱과 청킹을 거쳐 검색 가능한 단위로 정리될 것 같지만, 실제 결과를 보면 제목과 본문이 분리되고 표의 헤더와 값이 다른 청크로 나뉘는 경우가 많습니다. 

이렇게 문서 계층 구조가 빠진 상태로 청킹되면 검색 단계에서 정답과 상관없는 청크를 가져오거나, 정답이 담긴 청크를 놓치게 됩니다. 이번 글에서는 청킹이 제대로 되지 않는 원인을 유형별로 짚고, 문서 구조를 살린 RAG 전처리로 청킹 품질을 높이는 방법을 정리했습니다. 

RAG 청킹 품질이 답변 정확도를 좌우하는 이유

청킹(Chunking)은 긴 문서를 검색에 쓸 작은 단위로 나누는 전처리 작업이고, 이 단계에서 문서를 어떻게 나누느냐가 RAG(Retrieval-Augmented Generation, 검색 증강 생성) 답변의 정확도에 직접적인 영향을 줍니다.

RAG는 문서에서 질문과 관련된 내용을 검색해 대규모 언어 모델(LLM) 답변의 근거로 활용하는 방식입니다. 검색의 최소 단위는 청크이므로, 청크 품질은 검색 품질과 답변 정확도에 직접 영향을 줍니다. 청크가 의미 단위로 나뉘어야 질문에 맞는 근거를 찾을 수 있고, 그래야 답변의 맥락도 안정적으로 유지됩니다. 

청크가 너무 크면 여러 주제가 섞여 검색 노이즈가 늘고, 너무 작으면 앞뒤 맥락이 끊깁니다. 결국 청킹의 핵심은 문서를 단순히 일정 길이로 자르는 것이 아니라, 의미가 보존되는 단위로 나누는 데 있습니다. 이 단계에서 문맥이 끊기면 임베딩이나 벡터 DB를 조정해도 검색 품질을 충분히 보완하기 어렵습니다.

RAG 청킹 품질 저하 원인 – 고정 크기 청킹·문서 구조 무시

RAG 청킹 품질이 낮아지는 대표적인 원인은 문서 구조를 반영하지 못한 채 텍스트를 나누기 때문입니다. 

글자 수나 토큰 수만 기준으로 자르는 고정 크기 청킹, 제목과 본문의 계층 관계를 놓치는 분할, 표의 행·열 관계와 목록의 상위·하위 관계가 끊기는 경우가 대표적입니다. 결국 문서를 의미 구조가 있는 콘텐츠가 아니라 순서대로 이어진 텍스트처럼 다루면, 검색 단계에서 필요한 맥락이 빠진 청크가 만들어질 수 있습니다. 

고정 크기 청킹이 문맥을 끊는 이유

고정 크기 청킹은 글자 수나 토큰 수만 기준으로 문서를 일정 길이로 자르는 가장 단순한 방식으로, 구현은 쉽지만 의미 단위를 고려하지 않아 문장이나 표가 중간에서 끊기고 정보가 두 청크에 걸쳐 흩어집니다.

가령 정해진 글자 수마다 기계적으로 분할하면, 내용의 의미 단위와 관계없이 하나의 문단이 여러 청크로 분리되거나 표의 헤더와 데이터가 서로 다른 청크에 포함될 수 있습니다. 길이만 보면 어디까지가 하나의 의미 단위인지 알 수 없어, 자르는 지점이 문장이나 표 한가운데를 지나가기 때문입니다. 

정답에 필요한 문장이 두 청크로 나뉘어 저장되면 검색이 그중 한쪽만 가져오게 되어, 근거가 부족한 답이 나올 수 있습니다.Microsoft에서는 문서를 자르기 전에 구조부터 파악해야 청크 전략을 정할 수 있다고 설명합니다.

문서 계층 구조 손실의 문제점

문서는 제목에서 소제목, 본문으로 이어지는 계층 구조를 갖습니다. 이 구조를 반영하지 않고 자르면, 청크만 봐서는 해당 내용이 어느 섹션에 속하는지 알기 어려운 조각이 될 수 있습니다.

예를 들어 ‘3.2 환불 정책’이라는 소제목이 본문과 다른 청크로 분리되면, 남은 본문 청크에서는 이 내용이 환불 정책에 관한 설명이라는 단서가 약해집니다. 제목은 본문의 주제를 알려주는 기준이기 때문에, 제목과 본문의 연결이 끊기면 같은 문장이라도 어느 주제의 설명인지 판단하기 어려워집니다. 이 경우 사용자가 환불 기간을 물어도 해당 본문 청크의 검색 관련도가 낮게 평가되어, 검색 결과 상위에 오르지 못할 수 있습니다.

계층 구조를 유지한 채 문서를 나누는 일은 생각보다 까다롭습니다. 실제로 널리 쓰이는 오픈소스 분할 도구에서도 마크다운 헤더를 기준으로 자를 때 문단 구분이 약해져, 후속 분할과 분석에 영향을 줄 수 있다는 이슈가 보고된 바 있습니다.

표 목록에서 행·열 정보가 누락되는 이유

표와 목록은 각각의 요소가 어떤 관계에 놓여 있는지에 따라 의미가 정해지는 구조입니다. 표는 헤더와 값, 행과 열의 관계가 유지되어야 하고, 목록은 상위 항목과 하위 항목의 연결이 유지되어야 합니다. 길이 기준으로만 문서를 자르면 이 관계가 서로 다른 청크로 분리되어, 데이터가 무엇을 뜻하는지 파악하기 어려워질 수 있습니다.

예를 들어 ‘2026년 1분기 매출’이라는 헤더와 그 아래 숫자가 다른 청크로 나뉘면, 숫자만 담긴 청크는 해당 값이 어떤 항목의 수치인지 설명하기 어렵습니다. 표는 헤더와 값이 함께 있을 때 의미가 분명해지지만, 텍스트를 순서대로만 나누는 방식은 셀의 위치 관계와 헤더 연결을 충분히 반영하지 못합니다.

이때 필요한 기술이 TSR(Table Structure Recognition, 표 구조 인식)입니다. TSR은 표 안의 행·열 구조와 헤더-값 관계를 인식해, 표 데이터를 의미 있는 단위로 구조화하는 기술입니다. 이 과정이 충분하지 않으면 검색 단계에서 헤더가 빠진 숫자 청크를 가져올 수 있고, 대규모 언어 모델(LLM)은 해당 수치가 어떤 항목을 가리키는지 잘못 해석할 수 있습니다. 특히 긴 표나 복잡한 표는 헤더 정보와 행·열 관계를 청크 단위에서 함께 참조할 수 있도록 전처리하는 것이 중요합니다.

세 유형의 원인은 결국 하나로 정리됩니다. 문서가 가진 구조 정보를 충분히 반영하지 않은 채 길이 기준으로만 자른다는 점입니다. 따라서 청킹 품질을 높이려면 자르기 전에 문서 계층 구조와 표 관계를 먼저 구조화해 두는 과정이 필요합니다.

문서 구조 기반 청킹의 맥락 손실을 줄이는 방식

문서 계층 구조 기반 청킹은 제목·소제목·본문·표 같은 문서의 구조 요소를 경계로 삼아 나누는 방식입니다.

문서의 길이가 아니라 의미 단위로 자르기 때문에 제목과 본문이 같은 청크에 묶이고 표의 헤더와 값이 함께 유지됩니다.

각 청크에 해당 조각이 어느 섹션에 속하는지 제목 경로를 함께 담아 두면, 검색 시 본문뿐 아니라 맥락까지 함께 활용할 수 있습니다. RAG 프로세스는 ‘문서 업로드 → 파싱(Parsing) → 청킹 → 임베딩 → 벡터DB 저장 → 검색 → 답변 생성’ 순으로 진행됩니다. 

여기서 임베딩은 텍스트를 의미가 담긴 숫자 벡터로 바꾸는 작업이고 벡터DB는 그 벡터를 저장·검색하는 저장소입니다. 만약 청킹 단계에서 계층 정보를 잃으면 이후 임베딩과 검색 품질에도 영향을 주게 됩니다.

문서의 계층 구조를 어느 수준까지 보존해 추출할지도 중요합니다. 계층별 청킹을 비교한 HiChunk 연구에 따르면, 계층을 1단계에서 3단계로 늘릴수록 답변에 필요한 근거 문장을 빠짐없이 검색하는 성능이 점진적으로 향상됐으며, 3단계 이후에는 큰 변화가 나타나지 않았습니다. 

반면, 계층을 1단계로 제한하면 하나의 청크가 포함하는 의미 범위가 지나치게 넓어져 RAG 검색 성능이 저하됐습니다.

구조 기반 청킹을 위한 RAG 전처리 방법

문서 계층 구조를 살리려면 자르기 전에 세 가지 전처리가 필요합니다. 

문서에서 제목·본문·표 영역을 구분하고, 각 청크에 제목 경로를 메타데이터로 붙이고, 구조가 살아 있는 형태로 변환하는 작업입니다. 이렇게 전처리 과정을 거쳐야 이후 청킹 단계에서 문서의 의미와 맥락을 보존할 수 있습니다.

DLA로 제목·본문·표 영역 구분

DLA(Document Layout Analysis, 문서 구조 분석)는 AI 딥러닝 기술을 활용해 문서 내 텍스트·이미지·표·그래픽 등 다양한 요소를 구분하고, 각 요소의 위치와 관계를 정확히 파악하는 구조 분석 기술입니다.

청킹 전에 이 구조를 파악해 두면 제목과 본문이 잘못 묶이거나, 표가 본문과 분리되는 문제를 줄일 수 있습니다.

표가 포함된 문서라면 TSR도 함께 확인해야 합니다. TSR은 표의 행·열 관계를 복원해 헤더와 값이 끊기지 않도록 돕습니다.

제목 계층을 메타데이터로 보존

제목 계층을 메타데이터로 보존한다는 것은 각 청크에 이 조각이 어느 제목 아래 있는지를 함께 저장한다는 뜻으로, ‘문서명 > 3장 > 3.2 환불 정책’ 같은 제목 경로를 청크에 붙여 두면 본문만 담긴 청크도 어느 맥락에 속하는지 알 수 있습니다.

메타데이터는 데이터에 함께 저장되는 부가 정보입니다. 제목을 삭제하지 않고 유지하면 검색 단계에서 본문과 제목 맥락이 함께 반영되어, 환불 기간을 물었을 때 제목 경로에 환불 정책이 든 청크가 먼저 검색됩니다. Databricks에서는 계층적 청킹이 문서의 대·소 섹션과 문단 구조를 여러 단계로 보존한다고 설명합니다.

구조화 데이터로 변환해 청킹·임베딩에 연결

구조화 데이터로 변환한다는 것은 문서를 JSON·HTML·마크다운처럼 구조 정보를 담을 수 있는 형식으로 바꾸는 작업으로, 이렇게 두면 청킹 도구가 제목 계층과 표 구조를 훨씬 수월하게 인식합니다.

문서 구조가 보존된 상태로 청킹이 진행되면, 각 청크가 어떤 제목 아래에 있는지, 표 안의 값이 어떤 항목과 연결되는지 함께 활용할 수 있습니다. 반대로 구조 정보 없이 텍스트만 잘라내면 의미가 끊긴 청크가 만들어질 수 있습니다. 

결국 구조화 데이터 변환은 청킹과 임베딩 단계에서 문서의 맥락을 더 잘 활용하기 위한 준비 작업이라고 볼 수 있습니다.

청킹 단계에서 제목이나 표를 기준으로 문서를 나누려면, 입력 데이터에 제목·본문·표의 구분이 먼저 남아 있어야 합니다. 

문서 구조가 사라진 뒤에는 제목과 본문, 표와 데이터를 정확히 다시 연결하기 어렵기 때문입니다. 

한컴 데이터 로더는 이 앞단에서 문서를 구조 정보가 보존된 데이터로 변환하는 문서 파싱(Document Parsing) 솔루션입니다. 

💡 문서 구조를 살린 전처리가 실제로 어떤 차이를 만드는지, 한컴 데이터 로더 라이브 데모에서 직접 문서를 올려 확인해 볼 수 있습니다.

👉 한컴 데이터 로더, 라이브 데모 사용하러 가기

한컴 데이터 로더의 계층 구조 기반 전처리 방식

한컴 데이터 로더가 문서의 계층 구조와 표 관계를 보존한 구조화 데이터로 제공하면, 이후 청킹 단계에서 제목·본문·표 경계를 기준으로 삼기가 한결 수월해집니다.

 DLA·TSR로 구조를 살린 파싱 – 청킹 품질 개선

한컴 데이터 로더는 자르기 전 단계에서 DLA로 제목·본문·표 영역을 구분하고, TSR로 표의 구조를 복원하여 문서의 맥락을 유지한 구조화된 데이터를 제공합니다.

이렇게 정리된 데이터는 이후 청킹에서 제목·본문, 표의 헤더·값이 같은 단위로 묶이기 쉬워, 검색 품질을 높이는 토대가 됩니다. OCR(Optical Character Recognition, 광학 문자 인식)·DLA·TSR을 각각 다른 도구로 나누지 않고 하나의 파이프라인으로 처리합니다.

오픈소스 여러 개를 이어 붙일 때 생기는 연결 오류나 관리 부담이 줄어드는 점도 B2B  환경에서 유효합니다. 여기에 들여쓰기·번호 체계·글자 크기로 제목·부제목·본문의 위계를 자동 태깅하는 Level 추론 계층 구조 기능까지 더해져, 이 계층 정보가 청킹의 기준이 됩니다.

포맷별 구조화 데이터 변환과 고객 사례

한컴 데이터 로더는 문서 포맷과 특성에 따라 처리 방식을 유연하게 적용해, 텍스트 중심 문서와 이미지 기반 문서, 원본 구조를 직접 읽어야 하는 문서를 구분해 구조화 데이터로 변환합니다.

한컴 데이터 로더는 HWP·HWPX·PDF·OOXML을 구조화 데이터로 전환하는 문서 파싱 솔루션입니다. HWP·HWPX는 원본을 직접 파싱해 계층과 표 구조를 유지한 데이터로 추출합니다.

이러한 한컴 데이터 로더는 경기도교육청 AI 디지털플랫폼 구축 시 활용되었습니다. 2,800여 개 학교 홈페이지와 4만여 건의 안내자료, 7,000여 건의 지침·법령을 HWP·HWPX·PDF에서 계층 정보와 표 안의 표·병합 셀 같은 복잡한 표까지 구조화 데이터로 변환됐습니다.

🖥️한컴 데이터 로더

결국 RAG 청킹 품질은 청킹 단계에서만 결정되지 않습니다. 제목·본문·표·이미지의 관계가 사라진 상태에서는 어떤 청킹 전략을 써도 의미 단위를 안정적으로 나누기 어렵습니다. 

한컴 데이터 로더는 HWP·HWPX·PDF·OOXML 문서를 구조화 데이터로 변환해, 이후 프로세스에 높은 품질의 데이터를 활용할 수 있는 전처리 기반을 마련합니다. 

필요에 따라 추출된 구조화 데이터는 한컴피디아와 연계해 RAG 파이프라인에 활용할 수도 있습니다. 

RAG 답변 품질을 높이고 싶다면, 먼저 원본 문서 구조가 제대로 추출되는지부터 확인할 수 있습니다.

👉 한컴 데이터 로더, 라이브 데모 사용하러 가기

👉 한컴 데이터 로더, 도입 문의하기

RAG 청킹·전처리 관련 자주 묻는 질문 FAQ

---

참고 자료

1. IBM, 「Chunking strategies for RAG tutorial using Granite」
2. arXiv, Lu et al., 「HiChunk: Evaluating and Enhancing Retrieval-Augmented Generation with Hierarchical Chunking」, 2025
3. arXiv, Nguyen et al., 「Enhancing Retrieval Augmented Generation with Hierarchical Text Segmentation Chunking」, 2025
4. Databricks, Debu Sinha, 「The Ultimate Guide to Chunking Strategies for RAG Applications」
5. Microsoft Learn, 「Azure RAG 솔루션 개발 – 준비 단계」