Claude API 한국어 RAG 청크 사이즈 512 vs 1024 검색 정확도 비교

RAG 파이프라인을 직접 구축해 본 개발자라면 한 번쯤 이런 상황 겪어봤을 거예요. 문서를 열심히 나눠 넣었는데 검색 결과가 완전히 엉뚱하게 나오는 것. 원인을 파고들면 대부분 청크 사이즈 문제더라고요. 특히 한국어는 영어보다 훨씬 민감하게 반응해요.

Claude API 기반 한국어 RAG 시스템이 빠르게 늘어나는 지금, 청크 사이즈 512 vs 1024 선택은 이론적 논쟁이 아니에요. 실제 프로덕션 환경에서 성능 차이가 명확하게 드러거든요.

핵심 요약

• 한국어 평균 문장 길이(40~60 토큰)를 고려하면, 청크 512는 문장 경계를 더 자주 보존하고 검색 정밀도가 높아지는 경향이 있다.
• 청크 1024는 맥락 정보를 더 많이 담지만, 한국어 형태소 특성상 노이즈도 함께 늘어나 top-1 검색 정확도가 낮아질 수 있다.
• kt cloud 기술 블로그(2025년 11월)에 따르면, 도메인 문서 특성에 따라 청크 전략을 달리 적용하는 것이 단일 사이즈 고정보다 효과적이다.
• 오버랩(overlap) 설정과 청크 사이즈는 서로 연동되어야 하며, 512 기준 64~128 토큰 오버랩이 현장에서 가장 자주 권장된다.
• FAQ, 약관, 보고서 등 문서 유형별로 최적 청크 사이즈가 다르기 때문에, 하나의 설정을 전체 파이프라인에 고정하는 건 피하는 게 나아요.

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

RAG는 간단히 말하면 이래요. 문서를 잘게 잘라서 벡터 DB에 넣고, 질문이 들어오면 가장 비슷한 조각을 꺼내서 LLM에게 넘겨주는 구조예요.

여기서 ‘잘게 자른다’는 기준이 청크 사이즈예요. 토큰 단위로 512개씩 자를지, 1024개씩 자를지를 결정하는 거죠. 얼핏 보면 별것 아닌 숫자 하나 같지만, 검색 정확도와 응답 품질 전체에 영향을 미쳐요.

한국어가 까다로운 이유가 있어요. 한국어는 교착어라서 조사와 어미가 단어에 붙는 구조예요. 영어 “run quickly"는 두 토큰인데, 한국어 “빠르게 달린다"는 형태소 분리 방식에 따라 4~6 토큰으로 처리될 수 있거든요. 같은 글자 수라도 토큰 수가 달라지는 경우가 자주 생겨요.

kt cloud 기술 블로그(2025년 11월) 청킹 전략 분석에 따르면, 영어 기준 청크 설정을 한국어 문서에 그대로 가져오면 의미 단위가 어중간하게 잘리는 현상이 빈번하게 발생해요. 문장 하나가 두 청크에 걸쳐 나뉘면, 어느 청크도 그 문장의 완전한 의미를 담지 못하는 셈이에요.

실험 결과: 512 vs 1024의 실질적 차이

검색 정밀도: 512가 앞서는 경향

짧은 질문에 대한 top-1 검색 정확도를 놓고 보면, 청크 512가 일반적으로 더 나은 결과를 보여요. 이유는 단순해요.

512 토큰은 한국어 기준으로 약 3~5문장이에요. 하나의 주제 단위를 비교적 깔끔하게 담을 수 있는 크기죠. 반면 1024 토큰은 두 개 이상의 소주제가 섞이는 경우가 많아요. 임베딩 벡터가 두 가지 의미를 동시에 표현하다 보니, 특정 주제로 좁혀 검색할 때 거리 계산이 흐릿해지는 거예요.

예를 들어 “연차 신청 절차"를 물었을 때, 청크 1024에 “연차 신청 절차"와 “병가 처리 방법"이 함께 들어가 있다면, 이 청크의 임베딩은 두 주제의 중간 어딘가를 가리키는 벡터가 돼요. 검색 정밀도가 떨어질 수밖에 없죠.

맥락 보존: 1024가 유리한 경우

그렇다고 1024가 무조건 나쁜 건 아니에요.

계약서나 기술 명세서처럼 앞뒤 문맥이 연결되어야 의미가 살아나는 문서에선 1024 청크가 더 적합해요. 512로 자르면 중요한 단서가 이전 청크에 있는데 검색엔 다음 청크가 걸리는 상황이 생기거든요.

이를 완화하는 게 오버랩(overlap)이에요. 인접 청크 사이에 토큰을 겹쳐서 잘림 현상을 줄이는 방법이죠. 그런데 512 기준 오버랩 128을 설정하면 실질 청크 정보는 384 토큰, 1024 기준 오버랩 128이면 896 토큰이에요. 저장 공간과 임베딩 비용도 달라지는 셈이에요.

문서 유형별 비교

kt cloud 분석에서도 같은 결론이 나왔어요. 단일 청크 사이즈를 파이프라인 전체에 고정하는 것보다, 문서 유형에 따라 동적으로 청크 전략을 달리 적용하는 게 검색 품질을 확실히 높여줬다는 거예요.

Claude API 임베딩과 청크 사이즈의 관계

Claude API는 텍스트 생성을 처리하고, 임베딩은 Anthropic이 공식 파트너로 권장하는 Voyage AI 모델(voyage-3, voyage-multilingual-2 등)을 별도로 사용하는 구조예요.

voyage-multilingual-2는 한국어 포함 다국어에 특화된 임베딩 모델로, 최대 입력 길이가 2,048 토큰이에요. 청크 1024라도 임베딩 처리에는 문제가 없어요. 그런데 한국어 특화 성능 측면에서, 같은 모델로 512와 1024를 비교했을 때 짧은 단일 주제 쿼리에 대한 코사인 유사도 분포가 512 청크에서 더 뾰족하게 나타나는 경향이 보고되고 있어요.

실제 프로덕션에서 어떻게 접근할까요?

핵심 문제부터 짚을게요. 단일 청크 사이즈로 다양한 문서를 처리하면 어느 한쪽에서는 반드시 성능 손해를 봐요.

시나리오 1: 사내 규정 문서 검색 시스템 직원이 “육아휴직 신청 조건"을 물어볼 때, 규정 문서가 긴 조항으로 구성되어 있다면 512 청크가 조항 하나를 깔끔하게 담아낼 가능성이 높아요. 권장 설정은 chunk_size=512, overlap=64. 청크 메타데이터에 원본 조항 번호를 함께 저장하면 재현성도 확보돼요.

시나리오 2: 기술 매뉴얼 + 일반 FAQ 혼합 DB 두 문서를 같은 파이프라인에서 처리한다면, 문서 유형을 태깅해서 청크 사이즈를 분기하는 게 나아요. FAQ는 512, 매뉴얼은 768~1024로 구분 처리하는 하이브리드 접근이에요.

시나리오 3: 실시간 고객 상담 로그 검색 발화 단위가 짧고 맥락이 빠르게 전환되는 상담 로그는 256~512가 적합해요. 오버랩을 늘리기보다 슬라이딩 윈도우 방식으로 턴(turn) 단위를 보존하는 설계가 더 효과적이에요.

앞으로 주시할 신호 두 가지도 있어요. 첫째, Anthropic이 한국어 특화 임베딩 가이드라인을 별도로 제시할 가능성이에요. Voyage AI 파트너십 강화 흐름을 보면, 다국어 청킹 모범 사례 문서가 공식 릴리즈될 가능성이 있어요. 둘째, 자동 청크 사이즈 조정 기능을 탑재한 RAG 프레임워크가 늘어나는 추세예요. LlamaIndex와 LangChain 모두 2025년 하반기부터 semantic chunking 기능을 실험적으로 제공하기 시작했고, 고정 토큰 방식보다 한국어에서 실질적으로 나은지 검증 데이터가 쌓이고 있어요.

결론: 숫자 하나가 아니라 문서를 먼저 봐야 해요

결론은 명확해요.

• 짧고 독립적인 의미 단위를 가진 문서엔 512가 검색 정밀도를 높여줘요.
• 맥락이 연결되는 긴 서술형 문서엔 768~1024가 더 잘 맞아요.
• 오버랩은 청크 사이즈의 10~20%가 기준점이에요.
• 한국어 형태소 특성을 고려한 문장 경계 보존이 고정 토큰 분할보다 더 중요해요.

6~12개월 안에 semantic chunking이 프로덕션 레디 수준으로 올라온다면, 지금 같은 수동 청크 사이즈 튜닝 고민 자체가 줄어들 거예요. 그런데 지금 당장 배포해야 하는 시스템이 있다면, 문서 유형별 청크 분기부터 먼저 적용해보세요.

문서 유형에 맞는 청크 사이즈를 A/B 테스트로 돌려보면, 생각보다 빠르게 답이 나와요.

참고자료

1. [Tech Series] kt cloud AI 검색 증강 생성(RAG) #3 : 청킹(Chunking) 전략과 최적화
2. Claude API 인터넷 검색 완벽 가이드: 네이티브 web_search 도구와 3가지 구현 방식 비교 (2026) - Apiyi.com Blog

Photo by Bernd 📷 Dittrich on Unsplash