PDF 문서를 RAG용 데이터로 변환하는 청킹 전략과 주의점

RAG 시스템의 성능은 결국 벡터 데이터베이스에 저장된 지식의 품질에 크게 좌우된다. 기업 보고서, 연구 논문, 기술 매뉴얼처럼 중요한 정보 상당수가 PDF 형태로 존재하지만, PDF는 RAG를 구축할 때 다루기 까다로운 형식으로 꼽힌다. 단순히 텍스트만 뽑아내면 문장이 중간에 끊기거나 표가 뒤섞이고 머리글과 바닥글이 본문 사이에 끼어드는 문제가 흔히 발생한다.

이렇게 지저분해진 텍스트를 글자 수 기준으로만 기계적으로 잘라내는 고정 크기 청킹을 그대로 적용하면, 원래 문맥이 무너진 조각들만 남는다. 검색 단계에서 관련 있는 청크를 찾기 어려워지고, 결국 답변 품질도 함께 떨어진다. PDF를 RAG용 데이터로 바꾸는 작업은 단순한 텍스트 추출이 아니라 문서의 구조를 이해하는 작업에 가깝다.

PDF 처리가 어려운 이유와 청킹의 의미

PDF가 시각적 표현을 위한 형식이라는 점

PDF는 정보의 의미 구조를 담기 위한 형식이 아니라, 화면에 보이는 모습을 그대로 보존하기 위한 형식에 가깝다. 사람 눈에는 완성된 문서처럼 보이지만, 컴퓨터 입장에서는 특정 좌표에 텍스트나 이미지 조각이 흩어져 있는 집합일 뿐이다. 이 때문에 여러 단으로 나뉜 구성이나 복잡한 표, 페이지를 넘나드는 문장을 정확히 인식하기가 쉽지 않다.

청킹이 하는 역할

청킹은 대용량 문서를 벡터 데이터베이스에 저장하기 전에 의미 있는 작은 단위로 나누는 과정이다. 목표는 검색하기 좋을 만큼 작으면서도, 그 자체만으로 충분한 문맥을 담을 만큼은 큰 조각을 만드는 데 있다. 이렇게 만들어진 조각의 품질이 이후 검색과 답변 생성 전체의 품질을 좌우한다.

청킹 방식에 따른 차이

청킹 방식은 크게 세 갈래로 나뉜다. 문맥을 고려하지 않고 정해진 글자 수로만 자르는 방식, 문단이나 줄바꿈 같은 구분자를 순서대로 활용해 자르는 방식, 그리고 문서의 논리적 구조 자체를 기준으로 나누는 방식이다. 뒤로 갈수록 준비 과정은 복잡해지지만, 검색 결과의 정확도와 문맥 유지 측면에서는 더 나은 결과를 기대할 수 있다.

실제로 적용할 수 있는 청킹 전략

구조를 이해하는 도구로 먼저 추출하기

지저분한 텍스트로는 이후 어떤 청킹 방식을 쓰더라도 좋은 결과를 얻기 어렵다. 단순 텍스트 추출 라이브러리를 넘어, 문서의 구조까지 함께 파악하는 도구를 활용하는 편이 좋다. 텍스트와 표, 이미지의 위치 정보를 함께 얻을 수 있는 추출 도구를 쓰면 이후 단계에서 표와 본문을 구분하기 쉬워지고, 문서를 제목과 단락, 목록, 표 같은 구성 요소 단위로 인식해 마크다운이나 JSON처럼 구조화된 형태로 변환해주는 도구를 쓰면 청킹 이전 단계에서 이미 상당한 품질 차이가 만들어진다.

문서 구조를 기준으로 청킹 방식 고르기

구조화된 텍스트를 확보했다면 그다음은 의미 단위로 나누는 작업이다. 정해진 글자 수로만 자르는 방식은 가장 간단하지만 문장이 중간에 끊기거나 서로 다른 주제가 한 조각에 섞이기 쉬워 품질이 떨어진다. 겹치는 구간을 조금 두어 단점을 완화할 수는 있지만 근본적인 해결책은 되지 못한다. 문단이나 줄바꿈, 공백 같은 구분자를 계층적으로 활용해 나누는 방식은 이보다는 낫지만, 문서의 논리적 구조까지 완전히 반영하지는 못한다.

의미 단위 청킹을 실제로 구현하는 방법

가장 바람직한 방향은 문서의 논리적 구조를 기준으로 청킹하는 방식이다. 구조화된 형태로 추출한 각 요소, 예를 들어 단락이나 목록 항목, 표를 그대로 하나의 청크로 삼는 방법이 효과적이다. 문서를 깨끗한 마크다운으로 변환했다면 제목 기호를 기준으로 나누는 방법도 있는데, 이는 문서의 장이나 절 단위로 청크를 만들어 계층 구조를 자연스럽게 유지하는 데 도움이 된다.

주의해야 할 점

표는 PDF 처리 과정에서 가장 다루기 어려운 요소로 꼽힌다. 단순 텍스트 추출은 표의 행과 열 구조를 완전히 무너뜨리기 쉬우므로, 표를 인식해 표 형식 그대로 추출할 수 있는 도구를 사용하는 편이 좋다. 추출된 표 하나가 통째로 하나의 청크가 되도록 관리하고, 표의 행이 청크 경계에서 잘리지 않도록 신경 써야 한다.

청크를 만들 때 원본 문맥 정보를 함께 버리지 않는 것도 중요하다. 원본 파일명, 페이지 번호, 해당 청크가 속한 섹션 제목 같은 정보를 메타데이터로 함께 저장해두면, 나중에 답변의 출처를 보여주거나 특정 문서 및 섹션으로 검색 범위를 좁히는 데 유용하게 쓸 수 있다.

모든 상황에 맞는 하나의 최적 청크 크기는 존재하지 않는다는 점도 기억해야 한다. 데이터의 종류, 사용하는 임베딩 모델의 특성, 서비스가 요구하는 응답 형태에 따라 적절한 크기는 달라진다. 일반적으로 작은 청크는 검색 정확도를 높이는 데 유리하지만 문맥이 부족해질 수 있고, 큰 청크는 문맥은 풍부하지만 관련 없는 내용이 함께 섞여 들어갈 위험이 있다. 직접 여러 크기로 실험하며 서비스에 맞는 지점을 찾아가는 과정이 필요하다.

정리

PDF를 RAG용 데이터로 바꾸는 작업은 단순한 텍스트 추출이 아니라 문맥을 고려한 청킹의 과정으로 봐야 한다. 구조를 이해하는 도구로 문서를 정리하고, 고정된 글자 수가 아니라 단락이나 섹션 같은 의미 단위를 기준으로 나누며, 각 청크에 파일명과 페이지, 섹션 제목 같은 메타데이터를 함께 저장하는 흐름을 갖추면 검색 품질을 눈에 띄게 개선할 수 있다. 고정 크기 청킹에서 벗어나 구조를 반영한 청킹으로 전환하는 것만으로도 RAG 시스템의 안정성을 크게 끌어올릴 수 있다.