RAG 가 사라지지 않는 이유

1M 토큰 컨텍스트가 나왔을 때, 우리가 실제로 테스트한 것

작년 하반기 Gemini 1.5 Pro가 100만 토큰 컨텍스트를 발표했을 때 팀 슬랙에는 꽤 진지한 스레드가 열렸다. "이제 정산 규칙 문서 전부를 프롬프트에 때려박아도 되지 않나?" 농담이 아니었다. 우리는 실제로 돌려봤다.

테스트 대상은 우리가 운영 중인 가맹점 정산 정책 문서였다. 수수료 체계, 예외 처리 규칙, 분쟁 절차를 포함해 약 800페이지 분량, 토큰으로 환산하면 약 180만 토큰이다. 이걸 통째로 컨텍스트에 넣고 특정 정산 질의를 던졌을 때 응답 품질은 나쁘지 않았다. 그런데 호출당 비용은 RAG 방식 대비 약 40배였고, 응답 지연은 12초에서 34초로 치솟았다. 우리 정산 자동화 파이프라인의 내부 SLA는 5초다. 그 숫자를 보는 순간 논의는 사실상 끝났다.

결제·정산 현장에서 비용은 "비싸다"가 아니라 "불가능하다"의 문제

일반 챗봇 서비스라면 호출당 비용이 40배 올라도 "좀 비싸네" 수준에서 끝날 수 있다. 결제·정산 파이프라인은 다르다. 하루 수만 건의 정산 이벤트가 흐르고, 각 이벤트마다 LLM 판단이 필요한 예외 케이스가 발생한다. 월 10만 건의 예외 처리를 가정하고 Claude Sonnet 3.5 기준으로 단순 계산해보면, RAG 방식(평균 컨텍스트 4,000토큰)의 월 비용은 약 900만 원이다. 반면 180만 토큰 풀 컨텍스트 방식은 같은 조건에서 약 3억 6천만 원이 나온다. 이건 스타트업이 "좀 비싸도 정확도를 위해 감수하자"고 선택할 수 있는 규모가 아니다.

지연 문제도 마찬가지다. 정산 시스템에서 응답이 5초 안에 나오지 않으면 다음 배치 처리가 블로킹된다. 대용량 컨텍스트 호출의 첫 토큰 응답 시간(TTFT)은 평균 8–15초 수준이다. 벡터 검색 + 소형 컨텍스트 조합의 TTFT는 1–2초대를 유지한다. 우리에게 이것은 기술 선호의 문제가 아니라 시스템이 운영 가능한지 여부의 문제다.

Lost in the Middle: 예외 조항은 정확히 문서 중간에 있었다

컨텍스트가 크면 모델이 더 잘 볼 것이라는 직관은 연구로도 실무로도 틀렸다. 2023년 Liu et al.의 "Lost in the Middle" 논문이 실증했듯, 대형 언어 모델은 긴 컨텍스트에서 앞부분과 끝부분의 정보는 잘 참조하지만 중간에 위치한 정보는 놓치는 경향이 있다. 이 현상은 컨텍스트 길이가 늘어날수록 오히려 강화된다.

우리가 직접 겪은 사례가 있다. 온라인 게임 아이템 환불 업종에 적용되는 예외 수수료 규정이 정산 정책 문서 478페이지 중간 어딘가에 박혀 있었다. 전체 문서를 컨텍스트로 넣고 해당 업종의 수수료를 질의했을 때, 모델은 이 예외 조항을 무시하고 일반 수수료율로 답변했다. 동일한 질의를 RAG로 처리했을 때는 벡터 검색이 해당 절을 top-3 청크 안에 정확히 올려줬고, 모델은 예외 조항을 적용한 올바른 답변을 냈다. 정산 오류 한 건의 수동 수정 비용이 평균 15분임을 감안하면, 이 차이는 단순한 정확도 수치 문제가 아니다.

RAG가 진짜 잘하는 것: 데이터가 살아 움직이는 환경

RAG의 본질적 강점은 데이터가 자주 바뀌는 환경에서 두드러진다. 결제·정산 도메인은 이 특성이 극단적으로 강하다. 카드사 수수료율은 분기마다 바뀌고, PG사 계약 조건은 수시로 갱신되며, 금융당국 가이드라인은 개정 예고 없이 업데이트된다. 이 변경들을 파인튜닝으로 반영하려면 사이클당 수백만 원과 수 주의 리드타임이 필요하다. RAG 인덱스를 업데이트하는 데는 문서 하나에 수 초면 충분하다.

우리 팀이 운영하는 정산 규칙 RAG 파이프라인은 현재 약 3만 2천 개의 청크를 인덱싱하고 있다. 가맹점 계약서, 수수료 정책, 분쟁 처리 규칙, 규제 문서가 모두 포함된다. 신규 정책이 생기면 담당자가 문서를 업로드하는 즉시 임베딩이 생성되고 인덱스에 반영된다. 모델 재학습 없이 당일 반영, 당일 서비스가 가능한 구조다. 이것이 파인튜닝이나 풀 컨텍스트 방식으로는 흉내 내기 어려운 운영 민첩성이다.

HEDVION 팀의 실전 파이프라인: 두 방식의 경계를 어디서 긋는가

우리가 실제로 쓰는 기준은 다음 두 가지다. 문서 수 100건 이하이고 업데이트 빈도가 월 1회 미만이면 시스템 프롬프트에 직접 넣는다. 그 이상이면 RAG 파이프라인을 거친다. 중간 지점(100–200건, 주 1회 업데이트)에서는 하이브리드를 쓴다 — 불변하는 핵심 규칙은 시스템 프롬프트에 고정하고, 가변적인 세부 정책은 RAG로 실시간 주입하는 방식이다.

실제 파이프라인 구조는 이렇다. 질의가 들어오면 쿼리 리라이팅 단계에서 LLM이 검색에 최적화된 형태로 쿼리를 변환한다. 이후 OpenSearch에서 BM25와 벡터 검색을 결합한 하이브리드 검색으로 top-8 청크를 뽑고, Cohere Rerank v3를 거쳐 top-3으로 압축한 뒤 최종 LLM 호출에 넣는다. 전체 파이프라인의 평균 지연은 2.1초, 프롬프트 토큰은 평균 3,200토큰이다. 180만 토큰 컨텍스트와 우리가 선택한 실제 대안의 차이가 이 숫자들 안에 있다.

지금 당장 써먹을 수 있는 결정 기준 다섯 가지

긴 컨텍스트와 RAG 사이에서 고민 중이라면 다음 순서로 판단하길 권한다.

1. 비용 계산을 먼저 해라. 일일 예상 LLM 호출 수 × 평균 문서 토큰 수를 계산해라. 이 값이 하루 100만 토큰을 넘는다면 풀 컨텍스트 방식은 비용 구조가 성립하지 않는다. 바로 RAG를 검토해야 한다.

2. 데이터 업데이트 주기를 확인해라. 문서가 월 1회 이상 바뀐다면 RAG가 운영 부담을 크게 줄여준다. 변하지 않는 고정 지식이라면 컨텍스트 직접 삽입이나 파인튜닝이 오히려 단순하다.

3. 중요한 정보가 문서 어디에 있는지 확인해라. 미션 크리티컬한 예외 조항이 문서 중간에 있다면, 풀 컨텍스트를 믿지 마라. RAG로 관련 청크를 명시적으로 올려주는 방식이 Lost in the Middle 리스크를 차단한다.

4. 하이브리드를 기본값으로 고려해라. 고정 정책과 가변 데이터가 혼재하는 대부분의 실무 환경에서 두 방식의 조합이 가장 현실적이다. 시스템 프롬프트에 불변 규칙, RAG로 가변 데이터를 동적 주입하는 패턴은 복잡도 대비 효과가 확실하다.

5. 지금 당장 RAG를 시작해야 한다면: 청크 크기 512–1024토큰, 오버랩 10–20%로 시작하고, 리랭킹 단계를 반드시 넣어라. 리랭킹 없이 top-k만 쓰면 관련성 낮은 청크가 섞여 들어가 오히려 환각을 유도한다. Cohere Rerank 또는 BGE-Reranker-v2를 추가하는 것만으로 즉각적인 정확도 개선을 확인할 수 있다. 프레임워크 없이도 OpenAI Embeddings + Qdrant 조합으로 하루 안에 MVP는 만들 수 있다. 복잡한 오케스트레이션보다 청크 전략과 리랭킹에 먼저 시간을 써라.