RAG에서 chunking은 왜 중요할까라는 질문은 검색형 AI를 붙여 본 팀이 아주 빨리 만나게 되는 질문입니다. 많은 사람이 임베딩 모델이나 벡터 DB부터 떠올리지만, 실제로는 문서를 어떻게 자르느냐가 검색 결과의 질, 근거 보존, 최종 답변 안정성까지 직접 흔듭니다.
같은 문서라도 chunking이 다르면 완전히 다른 검색 시스템처럼 동작할 수 있습니다. 이번 글에서는 chunking이 왜 retrieval 품질을 좌우하는지, chunk size와 overlap을 어떻게 봐야 하는지, fixed-size와 structure-aware, semantic chunking 차이를 실무 기준으로 설명하겠습니다.
먼저 결론
- chunking은 문서를 잘게 자르는 작업이 아니라 검색 가능한 의미 단위를 만드는 일이다
- chunk가 너무 크면 잡음이 많아지고, 너무 작으면 답에 필요한 문맥이 끊긴다
- overlap은 경계 손실을 줄이지만 중복 저장과 검색 노이즈도 같이 늘린다
- 문서 구조를 무시하면 제목과 본문, 표와 설명, 규칙과 예외가 서로 떨어져 검색될 수 있다
- 정답 chunk size는 없고 문서 형태·질의 유형·모델 한계를 같이 봐야 한다
RAG 품질은 검색기가 무엇을 찾느냐보다 먼저, 인덱스에 무엇을 하나의 단위로 넣어 두었느냐에서 갈리는 경우가 많습니다.
RAG에서 chunking은 왜 중요할까
RAG는 질문과 비슷한 내용을 문서 저장소에서 찾아서, 그 결과를 모델 입력에 넣는 구조입니다. 그런데 검색기는 보통 문서 전체를 직접 비교하지 않고, 문서를 chunk 단위로 쪼갠 뒤 그 chunk들을 검색 대상으로 삼습니다. 즉 검색기가 실제로 찾는 대상은 원문 문서가 아니라 원문에서 잘라 만든 조각입니다.
이 지점이 중요합니다. 문서를 잘못 자르면 검색 시스템은 애초에 찾을 수 없는 단위만 보게 됩니다. 예를 들어 제목은 앞 chunk에 있고 예외 조건은 다음 chunk에 잘려 나가면, 사용자의 질문은 제목 없는 설명 조각이나 설명 없는 규정 조각만 건드릴 수 있습니다.
이런 체감은 이미 다룬 RAG는 왜 기대보다 자주 실망스러울까 글과도 이어집니다.
chunking의 첫 번째 역할은 토큰 제한 회피다
chunking이 필요한 가장 기본 이유는 모델 입력 한계입니다. Microsoft Learn의 Azure AI Search 문서는 큰 문서를 chunk로 나누면 embedding 모델과 chat completion 모델의 최대 입력 토큰 제한을 넘지 않게 하고 truncation으로 인한 정보 손실을 줄이는 데 도움이 된다고 설명합니다. OpenAI Retrieval 가이드도 vector store에 파일이 들어갈 때 chunked, embedded, indexed 된다고 설명합니다.
하지만 여기서 멈추면 설명이 반만 맞습니다. 문서가 토큰 제한 안에 들어와도 chunking은 여전히 중요합니다. Azure 문서도 문서 전체가 모델 한도 안에 있더라도, 한 문서 안에 여러 주제가 섞여 있으면 더 잘게 나누는 편이 검색 품질에 유리할 수 있다고 설명합니다.
chunk가 너무 크면 생기는 문제
- 질문과 무관한 잡음이 같이 들어온다
- reranking과 generation 단계가 더 어려워진다
- 긴 문맥 안에 필요한 문장이 묻히면서 lost in the middle 체감이 커진다
큰 chunk는 앞뒤 맥락을 더 많이 보존한다는 장점이 있습니다. 하지만 FAQ, 정책, 매뉴얼처럼 세부 항목이 많은 문서에서는 질문과 무관한 정보까지 함께 묶이기 쉽습니다. 그러면 임베딩 벡터가 더 넓고 흐릿한 의미를 가지게 되고, 딱 맞는 문단보다 이것저것 섞인 큰 chunk가 상위에 뜰 수 있습니다.
Pinecone의 chunking 가이드는 long context 모델을 쓰더라도 긴 문맥 안에 묻힌 중요한 정보가 잘 안 잡히는 문제가 있다고 설명합니다. 즉 컨텍스트가 길면 다 해결된다고 보기보다, 질문에 필요한 정보가 눈에 띄는 단위로 올라오게 만드는 편이 더 중요합니다.
chunk가 너무 작으면 생기는 문제
반대로 chunk를 너무 작게 잡으면 이번에는 문맥이 잘립니다. 정의와 조건, 예외와 주의사항이 서로 다른 chunk로 떨어지면 검색기는 정의만 건지거나 예외만 건질 수 있습니다. 모델은 일부만 보고 전체 규칙처럼 말하기 쉬워집니다.
특히 제목 없는 본문 조각이 늘어나는 것이 위험합니다. 예를 들어 ‘이 경우에는 적용되지 않습니다.’ 같은 문장은 앞 문단을 모르고 보면 거의 의미가 없습니다. 사람이 봐도 혼란스러운 조각이면 검색기도 잘못 찾고 모델도 잘못 씁니다.
Pinecone 가이드가 말한 ‘사람이 주변 문맥 없이 봐도 말이 되는 chunk가 좋다’는 기준은 이 문제를 가장 실무적으로 잘 설명합니다.
chunk size와 overlap은 왜 함께 봐야 할까
chunk size만큼 자주 같이 나오는 것이 overlap입니다. overlap은 앞 chunk의 일부를 다음 chunk에도 겹쳐 넣는 방식입니다. 경계 근처 문맥이 끊어지는 문제를 줄여준다는 장점이 있습니다.
Azure AI Search 문서도 overlap이 continuity와 context 유지에 도움이 된다고 설명하며, 시작값으로 512 tokens와 25% overlap을 제안합니다. 다만 이 숫자는 출발점이지 정답이 아닙니다. 문서 밀도와 질문 유형에 따라 달라질 수 있습니다.
- 장점: 경계 손실 완화, 연결 문맥 보존, 회수율 개선 가능
- 비용: 저장량 증가, 중복 검색, generation context 낭비, reranking 부담 증가
overlap은 경계 문제를 줄이는 대신 중복 문제를 키웁니다.
fixed-size chunking은 왜 많이 쓰일까
가장 흔한 방식은 fixed-size chunking입니다. token 수나 character 수를 기준으로 일정 길이마다 자르는 방식입니다. 구현이 쉽고 운영이 단순하며, 모델 한도에 맞추기 편하다는 장점이 있습니다. OpenAI Retrieval의 static chunking 설정도 이런 축에 가깝고, Azure 문서도 fixed-size chunk를 일반적인 출발점으로 다룹니다.
LangChain 역시 대부분의 use case에서 RecursiveCharacterTextSplitter 같은 현실적인 기본 전략부터 시작하라고 안내합니다. 다만 fixed-size 방식은 제목과 본문, 표와 설명, 규칙과 예외가 끊어질 수 있다는 한계가 있습니다.
structure-aware chunking은 무엇이 다를까
structure-aware chunking은 문서의 자연스러운 구조를 따라 자르는 접근입니다. Markdown은 헤더 기준으로, HTML은 section이나 list 기준으로, 코드 문서는 함수와 클래스 기준으로 나누는 식입니다. LangChain 문서도 Markdown, HTML, JSON, code처럼 구조가 있는 문서는 그 구조를 활용한 splitter를 따로 제공합니다.
- 제목 없는 조각이 줄어든다
- 규칙과 예외, 표와 설명 같은 관계가 덜 끊긴다
- 사람이 읽는 문맥 단위를 더 잘 보존한다
사내 위키, 기술 문서, 매뉴얼처럼 제목-본문 관계가 중요한 자료라면 고정 길이 절단보다 구조 기반 분할이 훨씬 검색 친화적일 가능성이 큽니다.
semantic chunking은 언제 생각할까
semantic chunking은 문장 수나 헤더보다 의미 응집도를 더 강하게 보려는 접근입니다. 쉽게 말해 ‘이 문단 묶음이 하나의 주제를 설명하고 있는가’를 중심으로 자르는 방식입니다. Azure 문서도 semantic chunking을 별도 기법으로 설명합니다.
이 방식은 PDF처럼 형식은 있지만 구조가 엉성한 문서, 한 페이지 안에 주제가 자주 바뀌는 자료, 제목보다 문단 의미 흐름이 더 중요한 리포트형 문서에서 특히 매력적입니다. 다만 구현과 파이프라인이 더 복잡하고, 품질 평가 없이 도입하면 복잡도만 늘 수 있습니다.
그래서 semantic chunking은 무조건 상위 전략이라기보다, fixed-size나 structure-aware로 놓치던 문제가 분명할 때 다음 단계로 보는 편이 안전합니다.
실무에서 먼저 점검할 체크리스트
- 검색 결과 상위 chunk를 사람이 직접 읽어 보면 독립적으로 이해가 되는가
- 제목과 본문, 표와 설명, 규칙과 예외가 서로 다른 chunk로 찢어지고 있지 않은가
- 같은 질문에 중복된 overlap chunk만 여러 개 올라오고 있지 않은가
- 너무 큰 chunk 때문에 질문과 무관한 내용이 함께 딸려오지 않는가
- 너무 작은 chunk 때문에 답에 필요한 조건 문장이 빠지고 있지 않은가
- 문서 타입마다 같은 splitter를 기계적으로 쓰고 있지 않은가
- retrieval과 generation을 같이 보지 말고 먼저 retrieval 자체를 따로 평가했는가
이 체크리스트는 RAG 평가셋은 어떻게 만들어야 할까 글과도 이어집니다. chunking은 감으로 정하기 쉬운 주제지만, 실제로는 retrieval 평가 없이 좋아졌다고 말하기 어렵습니다.
실무 출발점은 어떻게 잡으면 좋을까
- 먼저 fixed-size 또는 recursive splitter로 baseline을 만든다
- 문서 구조가 뚜렷하면 header/section 기반으로 바꿔 본다
- 경계 손실이 보이면 overlap을 조금씩 늘려 본다
- 중복 검색이 많아지면 overlap을 줄이거나 reranking을 같이 본다
- retrieval 실패 사례를 모아서 chunk 단위에서 어디가 잘렸는지 직접 확인한다
이 순서가 좋은 이유는 복잡도를 천천히 올릴 수 있기 때문입니다. 처음부터 semantic chunking과 다단계 파이프라인을 넣으면, 오히려 어느 단계가 좋아졌는지 나빠졌는지 구분이 안 됩니다. 이 점은 프롬프트 엔지니어링은 왜 자꾸 과장될까 글에서 말한 복잡도를 너무 빨리 올리지 말자는 운영 감각과도 닿아 있습니다.
마무리
RAG chunking은 문서를 예쁘게 쪼개는 전처리가 아닙니다. 검색 시스템이 무엇을 하나의 의미 단위로 기억할지 결정하는 핵심 설계입니다. chunk가 너무 크면 잡음이 늘고, chunk가 너무 작으면 문맥이 끊기고, overlap이 과하면 중복이 늘고, 문서 구조를 무시하면 근거가 반쪽만 남습니다.
모델이 똑똑해지기 전에, 검색기가 제대로 찾을 수 있는 조각을 먼저 만들어야 합니다.
공식·권위 자료 기준으로는 OpenAI Retrieval 문서, Microsoft Learn의 Azure AI Search chunking 문서, LangChain text splitter 문서가 좋은 출발점입니다. 실무에서는 ‘몇 토큰이 정답인가’보다, 이 chunk가 질문에 답할 수 있는 독립적인 근거 단위인가를 계속 확인하는 편이 더 중요합니다.
