컨텍스트 100만 토큰 시대, RAG를 걷어내도 될까

"컨텍스트 윈도우가 100만 토큰인데 RAG 파이프라인을 왜 유지해야 하지?" 3월 초, 팀 내 백엔드 개발자가 던진 질문이었다. 솔직히 반박하기 어려웠다. 우리가 쓰는 사내 문서는 전부 합쳐도 15만 토큰이 안 됐고, 청킹-임베딩-벡터DB-리랭킹으로 이어지는 파이프라인의 유지보수 비용은 매달 늘어나고 있었다.

그래서 실험했다. RAG를 걷어내고 롱 컨텍스트에 문서를 통째로 넣었다. 결과부터 말하면 — 2주 만에 다시 RAG를 붙였다. 근데 형태가 완전히 달라졌다.

#롱 컨텍스트만으로 충분했던 것들

사내 정책 문서 QA가 첫 실험 대상이었다. 인사규정, 경비처리 가이드, 보안정책 등 총 12만 토큰 분량. Gemini 1.5 Pro의 컨텍스트에 전부 넣고 질문을 던졌더니, 놀랍게도 RAG 파이프라인보다 답변 품질이 좋았다.

이유는 단순했다. RAG는 관련 청크 5개를 뽑아서 모델에 넘기는데, 정책 문서는 조항 간 상호참조가 많다. "경비 처리 기준은 제3조를 따르되, 해외출장의 경우 별표 2를 참고"하라는 식이다. 청크 단위로 잘라버리면 이 맥락이 날아간다. 전체를 넣으면 모델이 문서 전체를 보고 연결고리를 스스로 찾는다.

응답 시간도 예상보다 나쁘지 않았다. 프롬프트 캐싱을 걸면 첫 요청은 8초 정도 걸리지만 이후 요청은 1.2초 내외. RAG 파이프라인의 임베딩 검색(200ms) + 리랭킹(80ms) + LLM 호출(800ms)보다 살짝 느린 수준이었다.

#무너진 지점

문제는 문서가 늘어나면서 시작됐다. 고객 지원 봇에도 같은 방식을 적용하려 했는데, FAQ 3천 건에 제품 매뉴얼, 이전 티켓 이력까지 합치면 80만 토큰이 넘었다.

여기서 두 가지가 동시에 터졌다.

비용 폭탄. 매 요청마다 80만 토큰을 입력으로 보내면, 프롬프트 캐싱을 써도 월 비용이 기존 RAG 대비 6배였다. 고객 지원 봇은 하루 2천 건 이상 호출되니까 숫자가 순식간에 불어났다.

정확도 하락. 논문에서 말하는 "lost in the middle" 현상을 직접 목격했다. 컨텍스트가 길어질수록 문서 중간에 있는 정보를 놓치는 빈도가 눈에 띄게 올라갔다. 특히 비슷한 내용이 여러 곳에 흩어져 있을 때가 문제였다. 모델이 앞부분에서 찾은 답을 그대로 쓰고 뒷부분의 업데이트된 정보를 무시하는 패턴이 반복됐다. FAQ에서 같은 질문에 대한 답변이 2023년 버전과 2026년 버전으로 둘 다 존재하면, 모델은 먼저 나온 쪽을 참조하는 경향이 강했다.

#결국 안착한 하이브리드 구조

최종 아키텍처를 정리하면 이렇다.

하이브리드 쪽도 예전 구성과 꽤 달라졌다. BM25와 벡터 검색으로 후보 20개를 뽑고, 크로스인코더(bge-reranker-v2-m3)로 리랭킹한 다음, 상위 5개가 아니라 상위 10개를 넣는다. 과거에는 토큰 절약을 위해 5개로 제한했는데, 모델의 컨텍스트 윈도우가 넉넉해진 마당에 굳이 아낄 이유가 없다. 리랭커가 걸러준 10개 청크면 충분한 맥락이 확보되면서도 "lost in the middle" 문제가 발생할 만큼 길지 않다.

리랭킹 지연은 약 80ms. 이 80ms로 검색 정확도가 12% 올라갔으니 프로덕션에서 이걸 안 쓸 이유가 없다.

#"롱 컨텍스트가 더 싸다"는 절반만 맞는 말

온라인에서 이 주장을 꽤 본다. 틀린 말은 아닌데, 성립 조건이 까다롭다. 프롬프트 캐싱이 효과적으로 작동하고, 문서가 자주 바뀌지 않고, 호출 빈도가 낮을 때만 해당된다.

우리처럼 하루 수천 건 호출하는 서비스에서는 RAG의 검색 비용이 LLM 입력 토큰 비용보다 압도적으로 쌌다. 벡터 검색 한 건에 0.001원도 안 드는데, 80만 토큰 입력은 캐싱 적용해도 건당 수십 원이다. 하루 2천 건이면 월 단위로 수백만 원 차이가 난다.

한 가지 팁이 있다면 — 결정하기 전에 실제 트래픽 패턴으로 일주일만 A/B 테스트를 돌려봐라. 우리도 "이론적으로 이쪽이 낫다"는 확신으로 시작했다가 실측치에서 완전히 뒤집어졌다. 특히 캐시 히트율은 예상과 실제가 크게 다를 수 있다. 사용자들이 생각보다 다양한 질문을 던지면 캐시가 자주 무효화되고, 그때부터 비용 계산이 완전히 달라진다.

#그래서 RAG는 죽었나

아니다. 하지만 RAG의 역할이 바뀌고 있다. 예전에는 "모델이 못 보는 정보를 가져다주는 유일한 방법"이었다면, 지금은 "대량 문서에서 관련 부분을 효율적으로 좁혀주는 필터"에 가깝다. 컨텍스트 윈도우가 커진 덕분에 RAG가 가져온 청크를 더 넉넉하게 넣을 수 있고, 그만큼 답변 품질도 올라갔다. 역설적으로, 롱 컨텍스트 시대가 RAG를 죽이는 게 아니라 더 잘 쓸 수 있게 만들어주고 있다.