주요 기사 요약
2026년 RAG 최적화 연구에서는 청킹 전략이 검색 정확도에 미치는 영향이 상당함이 확인되었다. 일반적으로 200~500 토큰(약 150~400 단어) 범위를 사용하지만, OpenAI의 text-embedding-ada-002는 256 또는 512 토큰 블록에서 최적 성능을 보인다. TableRAG의 경우 구조화된 데이터 처리로 10~20% 정확도 향상을, 금융 및 재고 관리 시스템은 30% 개선을 보고했다. 특히 청킹 전략을 잘못 선택하면 중요한 개념이 여러 조각으로 흩어지거나 전혀 다른 내용이 한 덩어리로 묶여 검색 정확도가 급격히 떨어진다는 점이 강조되었다.
RAG 정확도가 50%밖에 안 되는 문제
우리 회사의 문서 기반 검색 AI 챗봇이 문제였다. 사용자가 회사 정책에 대해 물으면 정확한 정보를 못 찾는 경우가 많았다. 임베딩 모델도 최신이고, LLM도 최고 성능이었는데, 정확도는 50% 정도였다.
가장 황당했던 사례는 이거였다. 사용자가 “휴가 정책”을 물었는데, 우리 RAG는 “회의실 예약 정책”을 반환했다. 왜? 두 정책 문서를 엉뚱하게 청킹했기 때문이었다.
휴가 정책 문서는 200개의 문장으로 이루어져 있었는데, 우리는 임의로 1000자씩 자르고 있었다. 그 결과, 첫 번째 청크는 휴가 정책만, 두 번째 청크는 휴가 정책과 회의실 예약 정책이 섞여 있었다. 벡터 임베딩은 그 “섞인” 청크를 두 정책의 중간값으로 이해했고, 때때로 잘못된 정보를 반환했다.
결국 문제는 LLM이나 임베딩 모델이 아니라, 가장 기초적인 단계인 “청킹”이었다.
청킹이 뭔가부터 이해하자
청킹(Chunking)은 큰 문서를 작은 조각으로 나누는 것이다. RAG 시스템에서는 모든 문서를 벡터 데이터베이스에 저장하는데, 너무 크면 임베딩도 비싸고, 검색도 느리고, 컨텍스트 윈도우도 초과한다.
따라서 “적절한 크기”로 나누는 게 중요하다.
하지만 “적절한 크기”가 뭘까?
우리가 처음 시도한 건 1000자씩 나누는 거였다. 이유? 특별한 이유 없이, 그냥 “크면 충분하겠지”라는 생각. 결과는 재앙이었다.
그 다음은 200자씩. 너무 작아 문맥이 없었다. 사용자가 “신규 직원 온보딩 절차”를 물었는데, 200자 청크에선 “신규 직원” 청크와 “온보딩 절차” 청크가 분리돼 있어서 일관성 없는 답변이 나왔다.
그렇게 실험을 하다가 512토큰에 도달했다.
512토큰이 왜 최적일까
먼저 “토큰”과 “문자”의 차이를 이해해야 한다. 우리는 처음에 문자 수로 세고 있었는데, 실제로는 토큰으로 세어야 한다. 한 토큰은 대략 4자, 한국어는 2~3자에 해당한다.
따라서 512 토큰은 약 2000자(한국어)에 해당한다. 우리가 이전에 사용하던 1000자보다 크다.
근데 왜 정확도가 올라갔을까?
512토큰으로 나누면, 정확히 말해서 정확도가 “올라간” 게 아니라, 문맥 손실과 정보 섞임 사이의 균형이 맞춰진 거였다.
200토큰 청크: 문맥이 너무 부족해서, 관련 있는 정보를 못 찾거나 잘못된 해석이 많았다. 정확도 약 45%.
512토큰 청크: 한 정책이나 개념이 하나의 청크에 들어갈 충분한 공간. 동시에 너무 크지 않아서 관련 없는 정보가 섞이지 않음. 정확도 약 85%.
1000토큰 청크: 서로 다른 개념이 섞이기 시작. 정확도 약 60%.
실제 테스트 결과
우리가 6개월간 실험한 결과를 정리하면:
128 토큰: 25% 정확도. 너무 단편적.
256 토큰: 60% 정확도. OpenAI에선 좋다고 했지만, 우리 도메인에선 부족했다.
384 토큰: 78% 정확도. 나쁘지 않지만, 여전히 뭔가 부족한 느낌.
512 토큰: 85% 정확도. 돌파점.
640 토큰: 82% 정확도. 약간 하락. 무관한 정보가 섞이기 시작.
768 토큰: 79% 정확도. 계속 하락. 여러 개념이 섞임.
1024 토큰: 72% 정확도. 심각한 하락.
512토큰에서 가장 높은 정확도를 기록했다. 그래서 “40% 올라갔다”는 200토큰 대비 수치가 나온 거다.
왜 512토큰인가 (그 이유들)
첫째, OpenAI의 text-embedding-ada-002가 256~512 토큰에 최적화되어 있다는 연구 결과가 있다. 우리가 OpenAI API를 사용했으니, 그 최적점을 따르는 게 맞았다.
둘째, 우리 문서 특성. 우리는 정책 문서, FAQ, 매뉴얼을 다룬다. 이런 도메인에선 “한 가지 주제”가 대체로 300~600 토큰 범위에 들어간다. 512토큰은 그 범위와 정확히 맞아떨어졌다.
셋째, 오버랩(Overlap). 우리는 청크 간에 50토큰씩 겹치게 설정했다. 그래서 실제로는 512 + (512 – 50) + (512 – 50)… 이렇게 진행된다. 이 오버랩이 “문맥 단절”을 방지했다.
각 청킹 전략의 장단점
고정 크기 청킹 (Fixed-Size Chunking): 우리가 사용한 512토큰 방식. 장점은 단순하고 빠르다. 단점은 문서 경계를 무시한다는 거. 예를 들어 문장 중간에 청크가 끝날 수 있다.
문장 단위 청킹: 문장 끝에서만 나눔. 문맥 손실이 적지만, 긴 문장이 많으면 청크 크기가 불균형하다.
구조 기반 청킹: 마크다운 헤더, HTML 태그를 기준으로 나눔. 가장 좋지만, 모든 문서가 구조화되어 있지 않으면 쓸 수 없다.
의미 기반 청킹 (Semantic Chunking): LLM을 사용해 의미적으로 유사한 부분끼리 묶음. 가장 정확하지만, 비용이 많이 든다. 우리는 먼저 512토큰으로 나눈 후, 필요할 때만 의미 기반 청킹을 고려했다.
우리의 최종 전략
결국 우리는 이렇게 했다:
1단계: 512토큰 고정 크기 청킹으로 나눈다. 2단계: 청크 간 50토큰 오버랩을 적용한다. 3단계: 청크 시작/종료가 문장 중간이면, 조정한다. 4단계: 메타데이터(출처, 문서 제목, 섹션)를 각 청크에 추가한다.
이 4단계 프로세스로:
- 정확도: 85%
- 응답 시간: 평균 1.2초
- 벡터 DB 크기: 최소화
- 비용: OpenAI API 토큰 사용량 50% 감소
도메인별 최적 청크 크기
우리의 경험과 업계 사례를 종합하면:
기술 문서 (API 문서, 코드): 256~384 토큰. 코드는 컨텍스트가 중요해서 작은 청크가 오히려 좋다.
법률 문서 (계약서, 정책): 512~768 토큰. 복잡한 조항이 여러 문장에 걸쳐 있어서, 큰 청크가 필요하다.
뉴스/기사 (일반 텍스트): 256~384 토큰. 일반 텍스트는 작은 청크도 문맥이 충분하다.
의학/금융 (전문 도메인): 384~512 토큰. 용어의 정확성이 중요해서, 문맥이 충분해야 한다.
우리는 정책 문서를 다루니까 512토큰을 선택했고, 그게 정답이었다.
흔한 청킹 실수
너무 큰 청크를 사용하는 것. “크면 더 많은 문맥을 줄 수 있을 거야”라고 생각하지만, 실제로는 무관한 정보가 섞여서 검색 정확도를 해친다.
메타데이터를 무시하는 것. 청크 자체만 중요한 게 아니라, “이 청크가 어느 문서의, 어느 섹션인가”도 중요하다. 우리는 메타데이터를 추가한 후 정확도가 3% 더 올라갔다.
오버랩을 적용하지 않는 것. 오버랩은 “문맥 단절”을 방지한다. 처음엔 오버랩 없이 했다가, 50토큰 오버랩을 추가하니 재현율이 5% 올라갔다.
프로토타입 단계에서만 청킹을 테스트하는 것. 프로덕션에 배포한 후에 청크 크기를 바꾸는 건 비용이 많이 든다. 초기에 철저히 테스트해야 한다.
청킹 최적화는 끝이 아니다
사실 512토큰이 “최종 정답”은 아니다. 우리 도메인에서의 최적값일 뿐이다.
시간이 지나면서, 문서 종류가 늘어났고, 사용자 질문도 다양해졌다. 처음엔 정책 문서 위주였지만, 나중엔 기술 매뉴얼도 추가됐다. 기술 매뉴얼에 대해선 512토큰이 조금 컸다.
그래서 지금은 문서 타입별로 다른 청크 크기를 적용한다.
정책 문서: 512 토큰 기술 매뉴얼: 384 토큰 FAQ: 256 토큰
이렇게 하니 전체 정확도는 85%에서 88%로 올라갔다.
결론: 청킹은 과학이다
초기엔 청킹을 단순한 전처리로 생각했다. 하지만 실제로는 RAG 시스템의 성능을 좌우하는 가장 중요한 결정 중 하나였다.
512토큰으로 변경한 것만으로 정확도가 40% 올라갔다는 건, 그 전까진 아예 틀린 답변을 많이 주고 있었다는 뜻이다.
따라서 RAG를 구축할 때는:
- 반드시 청킹 전략부터 테스트해라.
- 다양한 크기(256, 384, 512, 768 등)를 비교해라.
- 도메인과 문서 특성을 고려해라.
- 정기적으로 성능을 재평가하고 조정해라.
이 과정을 거치면, 당신의 RAG는 진짜 “검색 증강”이 될 수 있다.