RAG 실패의 진짜 원인, 청크 분할

왜 이 이슈가 다시 중요해졌나

최근 AI 트렌드 X에서 반복해서 보이는 메시지는 단순합니다. RAG 실패의 상당수는 모델 성능 문제가 아니라 문서를 어떻게 자르느냐에서 시작된다는 점입니다. 특히 정책 문서, 금융 문서, 내부 위키처럼 조항과 예외가 촘촘한 자료는 토큰 기준으로만 잘라 놓으면 핵심 문맥이 쉽게 끊깁니다.

이 글은 원문의 문제의식을 바탕으로, 실제 구현에서 무엇을 점검해야 하는지 정리한 큐레이션입니다.

원문과 한국어 해설

Most RAG failures I have seen are not model failures.

They are chunking failures.

The model is fine. The retrieval is broken. And the retrieval is broken because someone split documents at arbitrary token boundaries without thinking about what the document actually means.

한국어로 풀면 이렇습니다. 대부분의 RAG 실패는 모델이 못해서가 아니라 청크를 잘못 나눠서 생긴다는 뜻입니다. 검색 자체는 그럴듯하게 맞아도, 문서의 의미 경계를 무시한 분할이면 답변에 필요한 앞뒤 문맥이 빠져 버립니다.

청크 분할이 망가지면 생기는 일

아래 표처럼 문제는 단순히 검색 누락에 그치지 않습니다.

분할 방식	장점	실제 위험
고정 토큰 길이	구현이 쉽다	조항, 정의, 예외가 잘린다
문단 단위	읽기 편하다	짧은 문단끼리 문맥이 끊길 수 있다
의미/구조 단위	검색 품질이 좋다	설계와 전처리가 더 필요하다

문제를 더 악화시키는 것은 오버랩입니다. 오버랩을 크게 잡으면 일부 문맥은 살지만, 중복이 늘어 검색 랭킹이 흔들리고 인덱스 비용도 올라갑니다. 결국 핵심은 더 많이 자르는 것이 아니라 더 잘 자르는 것입니다.

실무에서 먼저 바꿀 것

RAG를 다시 설계할 때는 아래 순서로 보는 편이 안전합니다.

1) 문서의 구조를 먼저 보세요

헤딩, 조항, 목록, 표, 코드블록처럼 의미가 분명한 경계를 우선 활용해야 합니다. 벡터 임베딩은 의미를 근사할 뿐, 잘못 잘린 조항을 다시 복원해 주지는 못합니다.

2) 청크 크기는 정답이 아니라 탐색점입니다

작으면 검색 정밀도는 좋아질 수 있지만 문맥이 부족하고, 크면 문맥은 늘어나지만 잡음이 섞입니다. 문서 유형별로 다르게 잡아야 합니다. 예를 들어 FAQ는 짧게, 정책 문서는 조항 단위로, 기술 문서는 함수나 섹션 단위로 보는 식이 더 낫습니다.

3) 검색 후 재정렬을 함께 보세요

좋은 청크 전략은 retrieval top-k만 높이는 게 아니라, 재정렬 단계에서 필요한 근거를 더 잘 남기게 만듭니다. 반대로 청크가 엉망이면 reranker가 아무리 좋아도 후보군 자체가 흐트러집니다.

빠른 점검 체크리스트

• 질문과 답이 같은 청크 안에 함께 들어 있는가
• 정의와 예외가 분리되어 있지 않은가
• 표와 본문이 따로 떨어져 있지 않은가
• 조항 번호나 섹션 헤딩이 검색 힌트로 남아 있는가
• 실패 사례를 샘플로 재현해 보았는가

이 다섯 가지를 확인하면, 모델 탓으로 넘기기 전에 인덱스 설계부터 손볼 수 있습니다. RAG는 결국 검색 시스템입니다. 검색 시스템이 의미 경계를 잃으면, 아무리 좋은 LLM도 정확한 답을 안정적으로 내기 어렵습니다.