"모델을 GPT-4o로 바꿨는데도 답변이 이상해요."

RAG 시스템 운영하다 보면 이 말을 정말 자주 듣는다. 프롬프트 튜닝하고, 모델 업그레이드하고, 리랭커 달고. 그런데 정작 답변 품질이 안 올라간다. 왜?

2026년 초 여러 벤치마크에서 반복적으로 확인된 수치가 하나 있다. RAG 실패의 80%는 LLM이 아니라 인제스천·청킹 레이어에서 발생한다. 대부분의 팀이 프롬프트를 만지작거리는 동안, 검색 레이어는 세 번에 한 번꼴로 엉뚱한 컨텍스트를 가져다주고 있었던 거다.

시맨틱 청킹의 함정

"의미 단위로 쪼개야 당연히 좋지 않나?" 나도 그렇게 생각했다. 그런데 올해 2월 Vecta가 학술 논문 50건을 대상으로 7가지 청킹 전략을 벤치마크한 결과가 좀 충격적이다.

전략 정확도 평균 청크 크기
Recursive 512토큰 69% 512 토큰
시맨틱 청킹 54% 43 토큰

시맨틱 청킹의 리콜 자체는 91.9%로 높았다. 검색은 잘 됐다는 뜻이다. 문제는 가져온 청크가 평균 43토큰 — 한국어 기준 대략 문장 두세 개 — 이라 LLM이 답변을 조합할 맥락이 턱없이 부족했다는 것. 검색은 됐는데 답변이 안 되는, 꽤 짜증나는 상황이 벌어진다.

실제로 이 문제를 겪는 전형적인 시나리오가 있다. 사내 기술 문서에 RAG를 붙였는데, 사용자가 "배포 프로세스 알려줘"라고 물으면 CI/CD 파이프라인 설명 중간에서 한 문장만 뽑혀온다. "GitHub Actions에서 빌드 후 ArgoCD로 배포합니다." 맞는 말이긴 한데, 앞뒤에 있던 환경 분기 조건이나 승인 절차는 날아가버렸다. 사용자는 이걸 보고 "RAG가 멍청하다"고 판단하지만, 실제로는 청킹이 컨텍스트를 너무 잘게 썰어놓은 거다.

프로포지션 기반 청킹도 같은 덫에 빠진다. 문장을 독립적 명제 단위로 분해하면 검색 정밀도는 올라가지만, 한 명제가 원래 속해 있던 문단의 흐름을 완전히 잃는다. 테이블이나 리스트가 포함된 문서에서는 특히 심하다 — 행 하나가 청크 하나가 되면서 표 전체의 비교 맥락이 소멸한다. 리콜 숫자가 높다고 RAG가 잘 작동하는 게 아니다. LLM에 건네주는 컨텍스트의 밀도와 연결성이 최종 답변 품질을 결정한다.

단순한 게 이기는 이유

Recursive character splitting. 문단·문장·단어 순서로 재귀적으로 쪼개는, 별 거 없는 방법이다. 512토큰에 50~100토큰 오버랩이면 대부분의 유스케이스에서 end-to-end 정확도가 가장 높다. 청크가 충분히 크니까 LLM이 맥락을 잡고, 오버랩이 문맥 단절을 메운다.

비용도 계산해 봐라

시맨틱이나 프로포지션 기반 청킹은 같은 코퍼스에서 벡터를 3~5배 더 생성한다. Pinecone이든 Weaviate든 벡터 수가 곧 비용이다. 문서 10만 건짜리 코퍼스라면 인덱스 크기 차이가 월 청구서에 바로 드러난다. "더 똑똑한 청킹"이 반드시 더 나은 결과를 의미하지 않는데, 비용은 확실히 더 나간다. 정확도도 낮고 비용도 높으면 뭘 위한 선택인지 모르겠다.

그래서 뭘 해야 하나

프롬프트나 모델을 건드리기 전에 이것부터 확인하자.

인제스천 레이어를 들여다봐라. 파싱이 제대로 됐는지, OCR 결과가 깨지진 않았는지, 메타데이터 추출은 정상인지. 여기가 무너지면 아래 레이어를 아무리 고쳐도 소용없다.

512토큰 + 10~20% 오버랩으로 시작하라. NVIDIA 벤치마크에서도 팩토이드 쿼리는 256512, 분석형 쿼리는 5121024가 적정이었다. 2,500토큰을 넘기면 "context cliff"가 발생해서 오히려 품질이 떨어진다.

50~100개 쿼리-답변 쌍으로 평가 세트를 만들어라. 시맨틱 청킹이 정말로 너의 코퍼스에서 더 나은지는 벤치마크해봐야 안다. 감으로 결정하지 마라.

결국 RAG에서 가장 ROI가 높은 작업은 화려한 아키텍처 설계가 아니라 인제스천 파이프라인을 지루하게 디버깅하는 일이다. 재미없지만 진짜다.