RAG 시스템 청크 크기, 왜 중요할까? 최적화 전 알아야 할 기본 개념과 원리

RAG 시스템에서 청크 크기가 왜 중요한가 — 최적화 전에 알아야 할 기본 원리

RAG를 처음 구현해보면 결과가 생각보다 별로일 때가 있다. 문서는 다 넣었고 임베딩도 됐는데, 엉뚱한 내용을 가져오거나 답변이 어딘가 어긋난다. 이 시점에서 대부분은 프롬프트를 손보거나 모델을 교체할 생각을 먼저 한다. 그런데 실제로 파고들면 원인의 상당 부분이 청크 설정에 있는 경우가 많다.

이 글은 RAG 파이프라인에서 청크 크기가 어떤 역할을 하는지, 왜 이 값 하나가 검색 품질과 비용을 동시에 좌우하는지를 다룬다. 최적화 수치보다는 "왜 이게 중요한가"를 먼저 이해하는 것이 목적이다. 수치를 바꾸기 전에 원리를 알고 있어야 실험 결과도 해석할 수 있기 때문이다.

---

RAG 파이프라인에서 청킹이 하는 역할

RAG는 크게 두 단계로 나뉜다. 문서를 저장하고 검색하는 인덱싱 단계와, 질문이 들어오면 관련 문서를 찾아 LLM에 전달하는 추론 단계다.

청킹은 인덱싱 단계에서 일어난다. PDF나 웹 문서 같은 원본 텍스트를 작은 단위로 잘라서 각각을 벡터로 변환(임베딩)한 뒤 벡터 DB에 저장한다. 이 과정에서 "얼마나 크게 자를 것인가"가 바로 청크 크기(chunk size)다.

중요한 건 청크 하나가 벡터 하나에 대응된다는 점이다. 사용자가 질문을 입력하면 시스템은 그 질문을 벡터로 변환하고, 저장된 청크 벡터들과 유사도를 비교해서 가장 가까운 청크 몇 개를 가져온다. LLM은 이 청크들만 보고 답변을 생성한다.

여기서 문제가 시작된다. 청크가 너무 작으면 하나의 청크에 맥락이 부족해서 LLM이 불완전한 정보로 답을 내야 한다. 반대로 너무 크면 하나의 청크에 관련 없는 내용이 섞여서 유사도 계산이 흐릿해진다. 유사도가 흐릿해지면 검색 단계에서 실제 답이 있는 청크가 상위에 오르지 못하는 상황이 생긴다.

쉽게 말하면, 청크 크기는 검색 엔진의 색인 단위를 결정하는 것과 비슷하다. 너무 세세하게 쪼개면 각 항목이 문맥을 잃고, 너무 뭉뚱그리면 검색이 뭉개진다.

---

청크 크기가 검색 정확도에 미치는 영향 — 작을수록 좋은 게 아니다

직관적으로는 작은 청크가 정밀한 검색을 가능하게 할 것 같다. 그런데 실제로 해보면 꼭 그렇지 않다.

청크가 작아지면 벡터 DB에 저장되는 벡터 수가 기하급수적으로 늘어난다. 문서 하나를 256토큰짜리로 쪼개면 512토큰 청크에 비해 2배 이상의 벡터가 생긴다. 검색 시 전체 벡터와 유사도를 비교해야 하므로 검색 속도가 느려지고, 리랭킹(reranking)을 사용할 경우 비용이 기하급수적으로 올라간다.

더 심각한 건 문맥 단절 문제다. 예를 들어 "A 제품의 가격은 100달러이고, 이는 경쟁사 대비 30% 저렴하다"는 문장이 있다고 하자. 이걸 너무 작게 자르면 "A 제품의 가격은 100달러이고"와 "이는 경쟁사 대비 30% 저렴하다"가 다른 청크로 분리될 수 있다. "경쟁사 대비 저렴한 이유"를 묻는 질문에는 두 문장이 함께 있어야 하는데, 하나만 검색되면 LLM은 절반의 정보로 답해야 한다.

반대로 청크가 너무 크면 유사도 희석(dilution) 문제가 생긴다. 1000토큰짜리 청크에 실제 답변과 관련 없는 내용이 800토큰이면, 이 청크의 임베딩 벡터는 답변 핵심 내용보다 잡음이 많은 상태가 된다. 질문 벡터와의 유사도 점수가 낮아지고, 정작 필요한 청크가 검색 결과 상위에 오르지 못한다.

2026년 벤치마크 데이터에 따르면, 동일한 문서와 임베딩 모델을 사용해도 청킹 전략만 달라지면 Recall(재현율)이 최대 9%p까지 차이가 난다. 적은 것 같지만, 실무에서 10만 건 이상의 문서를 다룰 때는 검색 실패율의 차이가 상당하다.

---

주요 청킹 전략 3가지 — 무엇을 기준으로 선택하는가

청킹 방식은 크게 세 가지로 나뉜다. 각각 적합한 상황이 다르고, 비용과 구현 복잡도도 다르다.

고정 크기 청킹 (Fixed-size Chunking)

가장 단순한 방식이다. 텍스트를 N 토큰 단위로 기계적으로 자른다. 문장 중간에서 잘릴 수 있다는 단점이 있지만, 구현이 쉽고 예측 가능하다는 장점이 있다.

LangChain의 CharacterTextSplitter나 LlamaIndex의 기본 설정이 여기에 해당한다. 처음 RAG를 구성할 때 대부분 이 방식으로 시작한다.

권장 시작값은 256~512 토큰이다. 사실 지식 조회형(factoid) 질문에는 256토큰 수준이, 문맥이 많이 필요한 분석형 질문에는 512~1024토큰이 더 잘 맞는 경향이 있다.

재귀 청킹 (Recursive Chunking)

단락 → 문장 → 단어 순으로 구조를 따라가며 자르는 방식이다. LangChain의 RecursiveCharacterTextSplitter가 대표적이다. 문서 구조를 어느 정도 존중하면서도 크기를 제어할 수 있어서 실무에서 가장 많이 쓰이는 방식 중 하나다.

2026년 벤치마크에서도 재귀 청킹은 비용 대비 성능 측면에서 상위권이었다. 복잡한 전략을 도입하기 전에 재귀 청킹부터 튜닝하는 게 대부분의 케이스에서 효율적이다.

시맨틱 청킹 (Semantic Chunking)

문장 간 의미 유사도를 계산해서, 의미가 바뀌는 지점을 청크 경계로 삼는 방식이다. 직관적으로는 가장 이상적이어 보인다. 내용이 바뀌는 지점을 정확히 잡으니까.

그런데 실제 적용 결과가 항상 좋지는 않다. 한 사례에서는 시맨틱 청킹을 적용하자 벡터 수가 4.2배 증가했고, 청크 평균 크기가 38토큰으로 줄면서 검색 정확도가 오히려 12% 하락했다. 너무 잘게 쪼개지면서 문맥 단절이 심해진 것이다. 또한 고정 크기 방식보다 약 14배 느리다는 측정 결과도 있다.

시맨틱 청킹이 효과적인 경우는 문서 내에서 주제가 뚜렷하게 전환되는 경우(예: 법률 문서의 조항별 구분, 기술 문서의 섹션 구분)다. 단순한 Q&A나 일반 텍스트에는 재귀 청킹으로 충분한 경우가 많다.

---

오버랩(Overlap)은 왜 존재하는가

청크를 자를 때 인접한 청크 사이에 일부 텍스트를 겹쳐서 저장하는 것을 오버랩(overlap)이라고 한다. 500토큰 청크에 100토큰 오버랩을 설정하면, 이전 청크의 마지막 100토큰이 다음 청크의 앞부분에 반복해서 들어간다.

오버랩이 필요한 이유는 청크 경계 문제 때문이다. "A라는 조건이 충족되면 B가 일어난다"는 문장이 두 청크에 걸쳐 잘린다면, "B가 일어난다"는 청크는 A라는 조건을 모른다. 이 청크만 검색됐을 때 LLM은 B의 조건을 알 수 없다. 오버랩은 이 경계 손실을 완충하는 역할을 한다.

일반적으로 권장되는 오버랩 비율은 청크 크기의 10~20%다. 500토큰 청크라면 50~100토큰 오버랩이 시작점이다.

단, 2026년 초 발표된 체계적 분석에서는 오버랩이 측정 가능한 성능 향상을 가져오지 못하고 인덱싱 비용만 올렸다는 결과도 있었다. 이는 사용하는 문서 유형과 질문 패턴에 따라 다르게 작용한다는 뜻이다. 오버랩을 맹목적으로 크게 잡기보다, 실제 검색 Recall을 측정하면서 조정하는 편이 낫다.

오버랩을 너무 크게 잡으면 벡터 수가 늘어나고 저장 비용과 검색 비용이 같이 올라간다. 처음에는 10% 정도에서 시작하고, 청크 경계에서 문맥이 잘리는 오류가 자주 보이면 늘리는 방식으로 접근하면 된다.

---

2026년 벤치마크가 말하는 것 — 복잡한 전략이 항상 답이 아니다

최근 여러 벤치마크에서 반복적으로 확인되는 패턴이 하나 있다. 구현 복잡도가 높은 전략이 항상 더 나은 결과를 내지는 않는다는 것이다.

2026년 기준으로 30개 이상의 청킹 실험을 진행한 결과에서 "청킹 전략보다 청크 크기가 더 중요하다"는 결론이 나오기도 했다. 시맨틱 청킹 같은 고급 전략보다, 적절한 크기의 고정 크기 또는 재귀 청킹이 더 나은 결과를 보이는 경우가 반복적으로 관찰됐다.

구체적인 수치를 보면, 재귀 청킹은 400토큰 기준으로 85~90%의 Recall을 기록했고, 시맨틱 청킹은 91~92%의 Recall을 보였다. 차이는 존재하지만, 시맨틱 청킹의 14배 높은 처리 비용과 구현 복잡도를 고려하면 단순히 Recall 수치만으로 우열을 따리기 어렵다.

또한 최근 연구에서 고정 크기 200단어 수준의 청크가 시맨틱 청킹과 동등하거나 더 나은 성능을 보인 실제 데이터셋 사례도 보고됐다.

이 결과가 의미하는 건, 처음부터 복잡한 전략을 도입하려 하지 말고 단순한 방식에서 측정을 시작하라는 것이다. 성능 지표가 명확히 개선을 요구할 때 다음 단계로 넘어가는 게 현실적이다.

검색 품질 측정 지표로는 Recall@k(상위 k개 결과 안에 정답이 있는 비율)와 MRR(Mean Reciprocal Rank)을 기준으로 잡는 경우가 많다. 이 지표를 확인하지 않고 전략만 바꾸면 뭐가 개선됐는지 알 수가 없다.

---

질문 유형에 따라 최적 청크 크기가 다르다

모든 RAG 시스템에 맞는 단 하나의 청크 크기는 없다. 중요한 변수 중 하나가 어떤 종류의 질문이 들어오는가다.

사실 조회형 질문 — "A 제품의 출시일은?", "B 기능은 어디에 있나?" 같은 간단한 질문은 작은 청크가 유리하다. 64~256토큰 수준의 정밀한 청크가 노이즈를 줄이고 정확한 위치를 찾게 해준다.

분석형·맥락 의존 질문 — "이 기술의 장단점은?", "A와 B의 차이는?" 같은 질문은 충분한 문맥이 필요하다. 512~1024토큰 수준의 청크가 LLM에 더 풍부한 정보를 제공한다.

이 두 유형이 섞여 들어오는 시스템이라면, 단일 청크 크기로 모두를 커버하려 하지 말고 질문 유형을 분류해서 다른 인덱스에 라우팅하는 방식을 고려해볼 수 있다. 또는 계층형 청킹(부모-자식 청크 구조)을 사용해서 작은 청크로 검색하고 큰 문맥을 LLM에 전달하는 방식도 실무에서 쓰인다.

도메인 특성도 영향을 미친다. 법률 문서처럼 조항 단위로 명확히 구분되는 문서는 구조 기반 청킹이 유리하고, 일반 웹 문서나 대화 로그는 고정 크기나 재귀 방식이 무난하다.

결국 청크 크기를 결정할 때 가장 먼저 확인해야 할 것은 "우리 시스템에 어떤 질문이 주로 들어오는가"다. 이걸 파악하지 않으면 어떤 수치를 넣어도 실험 결과 해석이 어렵다.

---

실전 설정 시작점 — 처음 구성할 때 무엇부터 해야 하나

처음 RAG를 구성하면서 청크 설정에서 막히는 분들을 위해 현실적인 시작 지점을 정리한다.

시작 설정 (대부분의 케이스에서 무난함)
- 청크 크기: 512 토큰
- 오버랩: 50~100 토큰 (약 10%)
- 전략: RecursiveCharacterTextSplitter
- Top-k: 3~5개

이 설정은 LangChain이나 LlamaIndex 기본값에 가깝고, 80% 이상의 범용 RAG 시나리오에서 합리적인 출발점이 된다.

성능 측정 없이 전략을 바꾸지 않는다

가장 자주 하는 실수가 "뭔가 안 좋은 것 같으니 시맨틱 청킹으로 바꿔보자"는 결정이다. 측정 없이 전략을 교체하면 개선됐는지 아닌지를 알 수 없다. Recall@3 또는 Recall@5 기준 수치를 먼저 뽑아두고, 전략 변경 후 같은 기준으로 비교한다.

오버랩은 신중하게

오버랩을 20~30%까지 올리면 인덱싱 비용과 저장 용량이 같이 올라간다. 대용량 문서를 다룰 경우 오버랩이 예상 외로 큰 비용 요인이 된다. 10% 시작 후 검색 Recall을 확인하며 필요할 때만 조정한다.

청크 크기를 바꿀 때는 리인덱싱이 필요하다

청크 크기를 변경하면 전체 문서를 다시 청킹하고 임베딩해야 한다. 운영 환경에서는 이 비용이 상당하다. 프로덕션 전환 전에 작은 샘플 데이터로 먼저 실험하는 것을 권장한다.

임베딩 모델과 함께 고려한다

청크 크기는 임베딩 모델의 최대 입력 길이 제한도 함께 봐야 한다. text-embedding-3-small 같은 모델은 8191 토큰까지 지원하지만, 512토큰 이상으로 크게 설정하면 임베딩 품질이 낮아지는 경향이 있다고 알려져 있다. 사용하는 임베딩 모델 문서에서 권장 입력 길이를 확인하는 게 좋다.

---

정리 — 청크 크기는 설정값이 아니라 실험 변수다

RAG에서 청크 크기가 중요한 이유는 단순히 검색 품질에만 영향을 미치는 게 아니기 때문이다. 저장 비용, 검색 속도, 임베딩 비용, LLM에 전달되는 문맥의 품질 모두가 이 값에 연결되어 있다.

핵심만 요약하면 이렇다.

• 청크가 너무 작으면 문맥이 끊기고, 너무 크면 유사도가 희석된다
• 시작은 512 토큰 + 10% 오버랩 + 재귀 청킹으로 충분하다
• 복잡한 전략(시맨틱 청킹 등)은 측정 결과가 요구할 때 도입한다
• 질문 유형에 따라 최적값이 다르다 — 사실 조회는 작은 청크, 분석형은 큰 청크
• 청크 크기를 바꾸기 전에 현재 Recall 수치를 먼저 측정한다

다음 단계로 RAG 성능을 더 올리고 싶다면, 청크 설정을 고정한 뒤 리랭킹(reranking)이나 하이브리드 검색(BM25 + 벡터) 조합을 실험해보는 것이 순서상 자연스럽다. 기반이 되는 청킹이 안정적이어야 다음 레이어의 효과를 제대로 측정할 수 있다.

---

Sources:
- RAG 파이프라인 고도화 전략: 청킹, 리랭킹, 하이브리드 검색 최적화
- LLM RAG 파이프라인: 청킹 전략과 임베딩 최적화 실전 2026
- kt cloud AI 검색 증강 생성(RAG) #3: 청킹 전략과 최적화
- Best Chunking Strategies for RAG (and LLMs) in 2026
- Document Chunking for RAG: 9 Strategies, Chunk Size & Overlap (2026)
- RAG Chunking Strategies: Semantic vs Fixed-Size vs Recursive
- RAG Chunking Strategies: A 2026 Retrieval Playbook
- RAG 제대로 쓰기: 청킹부터 검색 최적화까지, 2주 삽질의 기록
- RAG Chunk Size Guide: Find The Best Setting | LlamaIndex
- Chunking Strategies for RAG: Best Practices and Key Methods | Unstructured