RAG에 가장 좋은 청크 크기는 무엇인가요?

보편적인 답은 없지만, 오버랩 10~20%에 400~512 토큰이 좋은 출발점입니다. 그런 다음 쿼리 유형에 맞게 조정하세요: 정확한 사실 조회에는 128~256 토큰, 분석이나 요약 쿼리에는 512~1024 토큰. 단일 기본값을 믿기보다, 자신의 질문에 대해 몇 가지 크기를 벤치마크하세요.

청크의 오버랩은 어느 정도여야 하나요?

청크 크기의 10~20% — 500 토큰 청크에서 약 50~100 토큰입니다. 오버랩은 경계에서 의미가 끊기는 것을 막아 줍니다; 너무 적으면 분할 지점에서 컨텍스트가 조각나고, 너무 많으면 인덱스가 부풀고 거의 중복된 검색이 발생합니다. NVIDIA는 재무 문서에서 약 15%가 최적임을 확인했습니다.

semantic chunking이 fixed-size보다 나은가요?

일관적으로 그렇지는 않습니다. Semantic chunking은 주제별로 문장을 묶어 더 좋아 보이지만, 벤치마크를 보면 recursive나 fixed-size chunking 대비 이점이 일관적이지 않고 추가 임베딩 연산 비용을 정당화하지 못하는 경우가 많습니다. fixed-size와 recursive chunking은 여전히 강력하고 저렴한 베이스라인입니다 — 거기서 시작하고, 평가에서 실제 향상이 확인될 때만 semantic으로 옮겨 가세요.

late chunking이란 무엇이며 언제 사용해야 하나요?

Late chunking은 먼저 롱컨텍스트 임베딩 모델로 전체 문서를 임베딩한 뒤 토큰 임베딩을 청크로 풀링합니다 — 그래서 각 청크의 벡터는 자기 텍스트만이 아니라 문서 전체의 컨텍스트를 담습니다. 앞선 컨텍스트가 없으면 구절의 의미가 통하지 않는, 장거리 의존성이 있는 긴 문서에 사용하세요.

contextual retrieval이 실제로 정확도를 높이나요?

네, 측정 가능한 방식으로 높입니다. Anthropic은 각 청크에 LLM이 생성한 컨텍스트 노트를 덧붙이면 contextual 임베딩으로 top-20 검색 실패를 35%, contextual BM25와 결합 시 49%, 리랭킹 추가 시 67% 줄였다고 보고했습니다 — 프롬프트 캐싱을 쓰면 백만 문서 토큰당 약 $1.02입니다. 구절을 하나라도 놓치면 비용이 큰 고위험 코퍼스에서 가장 가치가 있습니다.

parent-document(small-to-big) retrieval이란 무엇인가요?

매칭 방식과 반환 내용을 분리하는 기법입니다. 정확한 매칭을 위해 작은 자식 청크를 인덱싱하되, 하나가 매칭되면 주변 컨텍스트를 갖도록 모델에 더 큰 부모 섹션을 넘깁니다. 이렇게 하면 어느 쪽도 희생하지 않고 작은 청크의 리콜과 큰 청크의 일관성을 모두 얻을 수 있습니다.

어떤 청킹 전략부터 시작해야 하나요?

약 500 토큰, 15% 오버랩의 recursive chunking입니다. 자연스러운 경계를 지키고, 저렴하며, 대부분의 콘텐츠에 강력한 베이스라인이 됩니다. PDF와 매뉴얼에는 structure-aware 분할을 더하고, 답변에 더 많은 컨텍스트가 필요할 때는 parent-document retrieval을, 추가 비용이 정당화되는 경우에만 contextual retrieval을 사용하세요.

← Resources

By Priya Shah — Senior Engineer, RAG + Knowledge · 2026-05-22 · TUTORIAL

RAG를 위한 청킹 전략: 크기, 오버랩, 그리고 실제로 효과적인 방법

청킹은 리트리벌이 시작되기도 전에 RAG 품질의 상한선을 정해 버립니다. 이 가이드는 실무에서 주류를 이루는 6가지 전략을 비교하고, 구체적인 크기와 오버랩 수치를 제시하며, 어떤 쿼리 유형에 어떤 전략이 적합한지 설명합니다.

청킹이 RAG 품질을 좌우하는 이유

청크는 리트리버가 실제로 가져오는 단위이므로, 청크 경계가 이후 모든 처리의 상한선을 정합니다. 청크가 너무 작으면 각 임베딩에 신호가 충분치 않아 안정적으로 찾을 수 없고, 너무 크면 관련 구절의 신호가 평균에 묻혀 벡터가 희석되면서 더 이상 쿼리와 일치하지 않습니다. 청킹이 잘못되면 어떤 리랭커나 더 큰 모델로도 리콜을 살릴 수 없습니다 — 애초에 올바른 구절이 검색되지 않았기 때문입니다. 그래서 보통 모델 선택보다 청킹을 먼저 튜닝합니다.

실무를 지배하는 6가지 전략

현재 실무는 크게 6가지 접근법으로 모입니다:

Fixed-size: 오버랩을 둔 동일한 토큰/문자 범위. 가장 오래되고, 가장 저렴하며, 재현 가능하고 — 놀라울 만큼 강력한 베이스라인입니다.
Recursive: 경계를 지키면서 크기 한도 안에 맞추기 위해 구분자 우선순위(단락 → 줄 → 문장)로 분할. 권장 기본값.
Semantic: 임베딩 유사도로 문장을 묶어 각 청크가 하나의 주제가 되도록 함. recursive 대비 이점이 일관적이지 않고 추가 임베딩 연산 비용이 듭니다.
Structure-aware: 문서 구조(제목, 섹션, 페이지, Markdown)로 분할. PDF, 매뉴얼, 재무 문서에 가장 적합.
Late chunking: 먼저 롱컨텍스트 모델로 전체 문서를 임베딩한 뒤 토큰 임베딩을 청크로 풀링 — 각 청크가 전역 컨텍스트를 담습니다.
Contextual retrieval: 인덱싱 전에 각 청크 앞에 LLM이 생성한 컨텍스트 설명을 덧붙입니다.

recursive로 시작하고, 문서나 쿼리 유형이 요구할 때 다른 전략으로 넘어가세요.

청크 크기와 오버랩: 구체적인 수치

보편적으로 최적인 크기는 없지만, 좋은 출발점은 있습니다. 오버랩 10–20%(500 토큰 청크에서 약 50–100 토큰)로 400–512 토큰 안팎에서 시작하세요. 그런 다음 크기를 쿼리 유형에 맞춥니다: 작은 청크(128–256 토큰)는 정확한 사실·키워드 조회에 유리하고, 큰 청크(512–1024 토큰)는 내러티브 흐름이 중요한 분석·요약 쿼리에 유리합니다.

오버랩은 경계에서 의미가 끊기는 것을 막아 줍니다 — 너무 적으면 컨텍스트가 조각나고, 너무 많으면 인덱스가 부풀고 검색이 중복됩니다. NVIDIA 벤치마크에서는 재무 문서에 약 15% 오버랩이 최적이었으며, 페이지 단위 청킹이 혼합 코퍼스 전반에서 가장 높고 일관된 정확도를 보였습니다. 팩토이드 쿼리는 256–512 토큰에서, 분석 쿼리는 1024+ 에서 정점을 찍었습니다.

고급: contextual retrieval과 late chunking

두 가지 새로운 기법이 같은 문제를 공략합니다 — "revenue increased 15%"라고만 적힌 청크는 어느 회사의 어느 분기인지 알 수 없다면 쓸모가 없습니다.

Anthropic의 Contextual Retrieval은 임베딩과 BM25 인덱싱 양쪽 모두에 앞서, LLM이 생성한 50–100 토큰의 컨텍스트 노트를 각 청크에 덧붙입니다. 5.7%의 베이스라인 top-20 실패율 대비, contextual 임베딩은 실패를 35% 줄였고, contextual BM25를 더해 49%, 리랭킹을 더해 67%까지 줄였습니다 — 프롬프트 캐싱을 쓰면 백만 문서 토큰당 약 $1.02입니다.

Jina의 late chunking은 파이프라인을 뒤집습니다: 롱컨텍스트 모델(최대 약 8,192 토큰)로 전체 문서를 임베딩한 뒤, 컨텍스트화된 토큰 임베딩을 청크로 풀링하여 각 청크 임베딩이 이미 청크 간 컨텍스트를 담도록 합니다. 장거리 의존성이 있는 긴 문서에 사용하세요.

부모 문서 검색과 메타데이터

거의 모든 상황에서 효과를 보는 두 가지 보완책이 있습니다. Parent-document("small-to-big") retrieval은 검색 세분성과 생성을 분리합니다: 정확한 매칭을 위해 작은 자식 청크(≈100–500 토큰)를 인덱싱하되, 모델에는 주변 컨텍스트를 갖도록 더 큰 부모 섹션(≈500–2,000 토큰)을 돌려줍니다. 그리고 메타데이터 보강 — 각 청크에 소스, 섹션 제목, 페이지 번호, 타임스탬프를 붙이는 것 — 은 필터링을 개선하고, 인용을 가능하게 하며, 청크 크기와 무관하게 검색 정밀도를 끌어올립니다.

osFoundry에서 선택하고 조정하기

빠른 결정 가이드: recursive가 안전한 기본값; 구조화된 문서에는 structure-aware 또는 페이지 단위; 주제가 밀집된 산문에는 semantic; 롱컨텍스트 임베더를 쓰는 긴 문서에는 late chunking; 컨텍스트 손실이 치명적인 고위험 코퍼스에는 contextual retrieval; 정밀도와 컨텍스트가 모두 필요할 때는 parent-document.

osFoundry는 이 모든 것을 코드가 아니라 설정으로 다룹니다. Auto-chunking은 합리적인 recursive 기본값을 제공하고, 커스텀 RAG 파이프라인에서는 지식 기반별로 크기, 오버랩, 전략을 조정할 수 있으며, 리랭킹과 parent-document retrieval은 파이프라인 스테이지 토글로 제공됩니다. 스테이지가 구성 가능하므로, 스택의 나머지를 고정한 채 자신의 쿼리 분포(팩토이드 대 분석)에 대해 청킹 설정을 A/B로 비교할 수 있습니다 — 이것이 바로 연구가 권장하는 튜닝 가능한 매개변수 워크플로우입니다.

Frequently asked questions

RAG에 가장 좋은 청크 크기는 무엇인가요?: 보편적인 답은 없지만, 오버랩 10~20%에 400~512 토큰이 좋은 출발점입니다. 그런 다음 쿼리 유형에 맞게 조정하세요: 정확한 사실 조회에는 128~256 토큰, 분석이나 요약 쿼리에는 512~1024 토큰. 단일 기본값을 믿기보다, 자신의 질문에 대해 몇 가지 크기를 벤치마크하세요.
청크의 오버랩은 어느 정도여야 하나요?: 청크 크기의 10~20% — 500 토큰 청크에서 약 50~100 토큰입니다. 오버랩은 경계에서 의미가 끊기는 것을 막아 줍니다; 너무 적으면 분할 지점에서 컨텍스트가 조각나고, 너무 많으면 인덱스가 부풀고 거의 중복된 검색이 발생합니다. NVIDIA는 재무 문서에서 약 15%가 최적임을 확인했습니다.
semantic chunking이 fixed-size보다 나은가요?: 일관적으로 그렇지는 않습니다. Semantic chunking은 주제별로 문장을 묶어 더 좋아 보이지만, 벤치마크를 보면 recursive나 fixed-size chunking 대비 이점이 일관적이지 않고 추가 임베딩 연산 비용을 정당화하지 못하는 경우가 많습니다. fixed-size와 recursive chunking은 여전히 강력하고 저렴한 베이스라인입니다 — 거기서 시작하고, 평가에서 실제 향상이 확인될 때만 semantic으로 옮겨 가세요.
late chunking이란 무엇이며 언제 사용해야 하나요?: Late chunking은 먼저 롱컨텍스트 임베딩 모델로 전체 문서를 임베딩한 뒤 토큰 임베딩을 청크로 풀링합니다 — 그래서 각 청크의 벡터는 자기 텍스트만이 아니라 문서 전체의 컨텍스트를 담습니다. 앞선 컨텍스트가 없으면 구절의 의미가 통하지 않는, 장거리 의존성이 있는 긴 문서에 사용하세요.
contextual retrieval이 실제로 정확도를 높이나요?: 네, 측정 가능한 방식으로 높입니다. Anthropic은 각 청크에 LLM이 생성한 컨텍스트 노트를 덧붙이면 contextual 임베딩으로 top-20 검색 실패를 35%, contextual BM25와 결합 시 49%, 리랭킹 추가 시 67% 줄였다고 보고했습니다 — 프롬프트 캐싱을 쓰면 백만 문서 토큰당 약 $1.02입니다. 구절을 하나라도 놓치면 비용이 큰 고위험 코퍼스에서 가장 가치가 있습니다.
parent-document(small-to-big) retrieval이란 무엇인가요?: 매칭 방식과 반환 내용을 분리하는 기법입니다. 정확한 매칭을 위해 작은 자식 청크를 인덱싱하되, 하나가 매칭되면 주변 컨텍스트를 갖도록 모델에 더 큰 부모 섹션을 넘깁니다. 이렇게 하면 어느 쪽도 희생하지 않고 작은 청크의 리콜과 큰 청크의 일관성을 모두 얻을 수 있습니다.
어떤 청킹 전략부터 시작해야 하나요?: 약 500 토큰, 15% 오버랩의 recursive chunking입니다. 자연스러운 경계를 지키고, 저렴하며, 대부분의 콘텐츠에 강력한 베이스라인이 됩니다. PDF와 매뉴얼에는 structure-aware 분할을 더하고, 답변에 더 많은 컨텍스트가 필요할 때는 parent-document retrieval을, 추가 비용이 정당화되는 경우에만 contextual retrieval을 사용하세요.