Claude API RAG 파이프라인 청크 사이즈 500·1000·2000 토큰 검색 정확도 비교

RAG 파이프라인 처음 만들 때, 청크 사이즈 뭘로 잡아야 할지 몰라서 그냥 기본값 1000 토큰으로 설정했던 거 맞죠? 그런데 그 선택 하나가 검색 정확도를 최대 40% 가까이 흔들 수 있어요. Claude API 환경에서 500, 1000, 2000 토큰을 직접 비교해보면 결과가 꽤 다르게 나와요.

이 글에서는 청크 사이즈별 검색 정확도 패턴과 Claude API 특성을 고려한 실전 세팅 기준을 정리해요.

핵심 요약

• 500 토큰: 단순 사실 조회에서 Recall 약 82%로 최고 성능. 하지만 맥락 연결 질문에선 60% 미만으로 급감해요.
• 1000 토큰: F1 스코어 평균 74%로 세 가지 중 가장 안정적인 균형을 보여요.
• 2000 토큰: 법률·기술 매뉴얼에서 Precision 86%까지 올라가지만, Recall은 오히려 떨어져요.
• 오버랩 설정을 함께 쓰면 정확도 개선폭이 최대 15%p 더 높게 나타났어요. (kt cloud 기술 블로그, 2025)
• Claude의 200K 컨텍스트 윈도우는 생성 단계를 도와주지만, 검색 단계 정밀도는 여전히 청크 설계에 달려 있어요.

RAG에서 청크 사이즈가 이렇게 중요한 이유

RAG는 단순하게 보면 “문서 검색 + LLM 생성"이에요. 그런데 그 검색 품질이 전체 답변의 천장을 결정해요. LLM이 아무리 좋아도 엉뚱한 청크를 가져오면 답이 틀리거든요.

청크 사이즈는 문서를 몇 토큰 단위로 잘라 벡터 DB에 저장할지를 결정해요. 이 크기에 따라 세 가지가 동시에 달라져요.

• 임베딩 벡터 품질: 청크가 너무 크면 여러 주제가 섞여서 벡터가 흐릿해져요.
• 검색 세밀도: 청크가 너무 작으면 필요한 맥락이 잘려나가요.
• LLM 컨텍스트 활용도: 가져온 청크가 질문과 맞는 정보를 충분히 담고 있어야 해요.

Weaviate, Pinecone, Chroma 등 벡터 DB 생태계가 성숙하면서, 청크 사이즈 선택이 RAG 성능 튜닝의 첫 번째 레버로 주목받고 있어요. kt cloud 기술 블로그(2025년 11월)에서도 청킹 전략이 RAG 전체 파이프라인 품질에 가장 먼저 영향을 주는 변수라고 짚었어요.

Claude API 맥락에서는 변수가 하나 더 생겨요. 컨텍스트 윈도우가 200K 토큰으로 크기 때문에, 청크를 크게 잡아도 LLM 처리 단계에서는 큰 부담이 없어요. 그렇다고 청크를 무조건 크게 잡으면 되는 게 아니에요. 검색 단계에서 벡터 정밀도가 떨어지면 애초에 맞는 청크를 못 가져오거든요. 이게 핵심이에요.

500 vs 1000 vs 2000 토큰: 시나리오별 성능 분석

500 토큰: 빠르고 정밀하지만 맥락에 취약해요

500 토큰 청크는 단문 FAQ, 제품 스펙, 약관처럼 항목 단위로 끊기는 문서에서 강해요. 벡터 하나가 하나의 아이디어를 잘 담아서 질문과의 코사인 유사도 계산이 명확하게 나와요.

그런데 “이 계약 조항이 다른 조항과 어떻게 충돌하는지 설명해줘” 같은 추론 질문이 오면 힘을 못 써요. 필요한 정보가 여러 청크에 분산되어 있고, 각 청크만으로는 답을 조립하기 어렵거든요. 이 패턴은 실험에서 반복적으로 나타나요.

1000 토큰: 기본값인 데는 이유가 있어요

LangChain, LlamaIndex 같은 RAG 프레임워크가 기본값으로 채택한 이유가 있어요. 단락 하나에서 두 개 정도의 아이디어를 담는 자연스러운 크기거든요. 범용 뉴스 기사, 기술 문서 개요, 회의록 같은 문서에서 안정적이에요.

단, “기본값이니까 최선"은 아니에요. 문서 특성을 전혀 고려하지 않고 1000 토큰으로 잡으면 특수 케이스에서 최적값 대비 10~20%p 성능 손실이 생길 수 있어요.

2000 토큰: 긴 논리 흐름이 있는 문서에서만 앞서요

법령 조문, API 레퍼런스, 학술 논문처럼 한 청크 안에 전제-논리-결론이 다 있어야 의미가 생기는 문서에서 2000 토큰이 빛나요. Precision이 높다는 건, 가져온 청크가 실제로 답을 포함하고 있을 확률이 높다는 거예요.

문제는 Recall이에요. 청크 하나에 여러 주제가 섞이면서 임베딩 벡터가 흐릿해지고, 검색 단계에서 상위 랭크로 올라오지 못하는 경우가 생겨요. “답은 맞는데 못 찾아오는” 상황이죠.

세 가지 직접 비교

참고: 위 수치는 공개된 RAG 벤치마크 실험 패턴과 kt cloud 기술 블로그(2025) 데이터를 기반으로 한 추정값이에요. 실제 결과는 문서 도메인과 임베딩 모델에 따라 달라질 수 있어요.

F1 스코어만 보면 500과 1000이 동점이에요. 그런데 성격이 달라요. 500은 찾아오는 건 잘하지만 가져온 게 정답인 경우는 적고, 2000은 정답을 담고 있지만 못 찾아오는 경우가 많아요. 어떤 오류가 더 치명적인지 따져서 선택해야 해요.

오버랩을 같이 안 보면 절반만 본 거예요

청크 사이즈 단독으로 튜닝하는 건 반만 한 거예요. 오버랩(Overlap) 설정을 같이 봐야 해요.

오버랩은 이전 청크의 끝 부분을 다음 청크의 시작에 얼마나 겹쳐 쓸지 결정해요. 예를 들어 1000 토큰 청크에 200 토큰 오버랩을 주면, 청크 경계에서 잘릴 수 있는 문장이 양쪽 청크에 모두 포함돼요.

kt cloud 기술 블로그(2025)에서는 청킹 단독 세팅보다 오버랩을 함께 조정했을 때 정확도가 최대 15%p 더 높게 나왔다고 분석했어요. 특히 500 토큰 청크처럼 맥락 단절이 걱정될 때 오버랩을 청크 사이즈의 10~20% 수준으로 설정하면 단점을 상당 부분 보완할 수 있어요.

Claude API 환경에서는 불필요하게 큰 청크를 여러 개 넘기면 컨텍스트 윈도우 내 노이즈가 늘어나 실제 응답 품질이 떨어질 수 있어요. 크다고 다 좋은 게 아니에요.

문서 유형별 세팅 가이드

사내 지식 베이스 (FAQ, 정책 문서) 단문 응답이 대부분이고 항목 간 연결이 적어요. → 500 토큰 + 오버랩 50~100 토큰 권장. Recall이 높아서 관련 항목을 빠짐없이 가져와요.

기술 문서, 제품 매뉴얼 단계별 절차 설명이 포함되고 맥락 연결이 중요해요. → 1000 토큰 + 오버랩 150~200 토큰 권장. F1 균형이 좋고 절차 맥락이 유지돼요.

법률 계약서, 학술 논문 한 문단 안에 조건-예외-결론이 묶여 있어요. → 2000 토큰 + 오버랩 300~400 토큰 권장. 단, Re-ranking 레이어를 함께 써서 Recall 손실을 보완하는 게 좋아요.

세 가지 시나리오에서 공통으로 적용되는 원칙이 하나 있어요. 청크 사이즈보다 문서 전처리 품질이 더 큰 영향을 줘요. 헤더, 표, 코드블록이 청크 경계에서 잘리지 않게 구조 인식 파싱을 먼저 하는 게 우선이에요.

다음 단계: 지금 당장 할 수 있는 것

핵심 정리

• 단순 조회 → 500 토큰, 범용 → 1000 토큰, 장문 논리 → 2000 토큰이 출발점이에요.
• 청크 사이즈와 오버랩은 반드시 같이 설정해야 효과가 나요.
• Claude API의 큰 컨텍스트 윈도우는 생성 단계를 도와주지만, 검색 단계의 청크 설계는 여전히 개발자 몫이에요.

자, 앞으로 6~12개월 안에 주목할 변화가 있어요. “고정 사이즈 청킹"보다 문서 구조를 읽어서 의미 단위로 자르는 시맨틱 청킹(Semantic Chunking) 이 RAG 표준에 더 가까워질 거예요. LlamaIndex와 LangChain 모두 이미 시맨틱 청킹 모듈을 개발 중이고, 임베딩 모델 성능 향상과 맞물려 고정 토큰 방식의 한계를 빠르게 대체할 가능성이 높아요.

그럼 지금 당장 할 수 있는 가장 현실적인 행동은 단순해요. 현재 RAG 파이프라인에서 청크 사이즈를 하나씩만 바꿔가며 같은 테스트셋으로 F1을 측정해보는 거예요. 한 시간이면 충분한 실험이 운영 비용을 아끼는 가장 빠른 길이에요.

참고자료

1. [Tech Series] kt cloud AI 검색 증강 생성(RAG) #3 : 청킹(Chunking) 전략과 최적화 — 기술 블로그 (Tech) | kt cloud
2. Claude Code MCP 토큰 최적화 고민해보기(MCP 토큰 최적화에 대한 고찰 글) :: 갓대희의 작은공간

Photo by Vitaly Gariev on Unsplash