RAG를 적용했는데도 답변이 엉뚱하게 나오거나, 문서에 분명히 있는 내용을 제대로 찾지 못하는 경우가 있습니다. 질문이 조금만 복잡해져도 답변의 정확도가 떨어지거나 결과가 일관되지 않기도 합니다. 이럴 때 많은 사람이 임베딩 모델이나 벡터 DB, 프롬프트부터 바꾸려고 하지만, 실제 원인은 LLM에 어떤 정보를 얼마나 전달하고 있는지에 있을 수 있습니다.
RAG 시스템은 관련 문서를 많이 넣는다고 해서 반드시 성능이 좋아지는 것은 아닙니다. 모델이 한 번에 처리할 수 있는 컨텍스트 창에는 한계가 있고, 그 안에 들어가는 토큰 수는 비용과 응답 품질에도 영향을 줍니다. 정보가 지나치게 많거나 같은 내용이 반복되거나, 질문과 관련성이 낮은 청크가 섞이면 핵심 근거가 묻히면서 답변이 오히려 부정확해질 수 있습니다.
RAG에서 인지 부하가 생기는 순간
인지 부하는 처리해야 할 정보가 너무 많거나 복잡해 중요한 내용을 가려내기 어려워지는 상태를 말합니다. 보통 사람의 사고 과정에 적용되는 개념이지만, LLM 기반 시스템에서도 비슷한 현상이 나타납니다.
컨텍스트 안에 불필요한 문장과 중복 청크가 많거나, 하나의 문서 단위가 지나치게 크거나, 서로 충돌하는 정보가 함께 들어가면 모델은 질문에 필요한 근거를 안정적으로 활용하기 어려워집니다.
사내 문서 검색 챗봇에서 사용자가 “환불 예외 조건은 어떻게 되나요?”라고 질문하는 상황을 떠올려보겠습니다. 검색 결과에 환불 정책뿐 아니라 결제 정책, 고객 등급 정책, 과거 공지까지 한꺼번에 포함되면 답변은 길어질 수 있습니다. 그렇다고 정확도가 함께 높아지는 것은 아닙니다. 핵심 조항보다 주변 설명에 끌려가거나, 현재 정책과 오래된 내용을 섞어 답할 가능성이 커질 수 있습니다.
청킹은 문서를 일정한 크기로 자르는 작업이 아닙니다
청킹은 RAG 품질에 큰 영향을 주는 단계입니다. 청크가 너무 작으면 질문에 답하는 데 필요한 앞뒤 문맥이 사라지고, 반대로 너무 크면 검색 정확도가 떨어지면서 컨텍스트 공간도 비효율적으로 사용하게 됩니다.
그래서 문단, 의미 단위, 제목과 하위 항목의 관계, 문서의 계층 같은 기준을 함께 살펴봐야 합니다. 모든 문서를 같은 글자 수나 토큰 수로 나누는 방식만으로는 문서마다 다른 맥락을 제대로 담기 어렵습니다.
기술 문서에서는 제목과 하위 항목이 어떻게 이어지는지가 중요합니다. 정책 문서라면 조건과 예외 조항이 떨어지지 않도록 묶어야 하고, FAQ 문서는 질문과 답변이 서로 분리되지 않게 만드는 편이 좋습니다. 결국 중요한 것은 청크의 크기보다, 하나의 청크만으로도 특정 질문에 답할 수 있을 만큼 의미가 온전하게 담겨 있는지입니다.
컨텍스트 창을 관리할 때 살펴볼 기준
먼저 검색 결과를 가능한 한 많이 넣기보다, 현재 질문과 직접 연결되는 근거를 골라내야 합니다. 같은 내용을 담은 청크가 여러 개 검색됐다면 중복을 줄여 컨텍스트 공간이 반복해서 낭비되지 않도록 해야 합니다.
문서가 길다면 전체 내용을 그대로 넣는 대신 요약본과 원문 근거를 함께 활용하는 방식도 생각해볼 수 있습니다. 멀티턴 대화에서는 이전 대화가 계속 누적되면서 현재 질문의 초점을 흐리고 있지는 않은지도 확인해야 합니다.
실제 서비스에서는 질문의 복잡도에 따라 청크 수와 크기, 요약 수준을 다르게 조절할 필요가 있습니다. 단순한 사실을 확인하는 질문과 여러 조건을 비교해야 하는 질문은 필요한 정보의 범위가 다르기 때문입니다. 모든 질문에 같은 검색 개수와 같은 프롬프트를 적용하면, 단순 질문에서는 정보가 과해지고 복잡한 질문에서는 근거가 부족해질 수 있습니다.
성능은 최종 답변만 보고 판단하기 어렵습니다
RAG를 개선할 때는 답변이 자연스러워 보이는지만 확인해서는 부족합니다. 검색된 청크 안에 실제 정답 근거가 포함돼 있는지, 모델이 그 근거를 빠뜨리거나 왜곡하지 않았는지, 응답 시간이 지나치게 늘지는 않았는지, 사용한 토큰 비용이 적절한지도 함께 봐야 합니다.
재현율과 정확도, 응답 지연 시간, 토큰 사용량, 사용자 피드백을 함께 기록하면 어떤 변경이 실제 개선으로 이어졌는지 판단하기 쉬워집니다. 특히 청킹 방식을 바꿀 때는 동일한 질문 세트를 기준으로 전후 결과를 비교하는 것이 중요합니다. 그래야 성능 변화가 프롬프트 덕분인지, 검색 품질 때문인지, 청크 구성이 나아졌기 때문인지 구분할 수 있습니다.
처음에는 이 세 가지부터 확인해보는 편이 좋습니다
RAG 답변 품질이 들쭉날쭉하다면 먼저 상위 검색 결과에 질문과 관련 없는 청크가 자주 섞이는지 살펴볼 필요가 있습니다. 다음으로 하나의 청크 안에 서로 다른 주제가 함께 들어가 있지는 않은지 확인해야 합니다. 마지막으로 컨텍스트에 전달되는 정보가 지나치게 길거나 같은 내용이 반복되고 있지는 않은지도 점검해보는 것이 좋습니다.
이 세 가지 문제만 줄여도 RAG 시스템의 응답은 한층 안정될 수 있습니다. 이후에는 문서 유형에 맞는 청킹 방식, 요약과 메타데이터 활용, 검색 결과 재정렬, 프롬프트 재구성, 성능 평가 자동화처럼 개선 범위를 조금씩 넓혀가면 됩니다.
RAG는 검색 기술과 생성 모델을 연결해 답변을 만드는 방식이지만, 실제 품질은 정보를 많이 넣는 데서 결정되지 않습니다. 질문에 필요한 근거를 모델이 이해하기 쉬운 형태로 전달하는 과정이 훨씬 중요합니다.
컨텍스트와 청크를 인지 부하의 관점에서 살펴보면, 단순히 모델이나 프롬프트를 바꾸는 데서 벗어나 검색부터 답변 생성까지 이어지는 전체 흐름을 더 안정적으로 다듬을 수 있습니다.
더 깊게 배워보고 싶다면
이 글에서 다룬 RAG 청킹, 컨텍스트 창 관리, 인지 부하 기반 성능 개선을 실제 시스템 설계 흐름 안에서 더 살펴보고 싶다면 아래 강의도 참고해볼 만합니다.
RAG 성능의 한계를 뚫는 인지 부하 관리 기술(부제: 컨텍스트 엔지니어링 완전 정복)
이 링크를 통해 수강하면 작성자가 소정의 수수료를 받을 수 있습니다.
