RAG 의 사망 선고는 매해 발표된다

왜 이 논쟁은 결제·정산 팀에게 남의 이야기가 아닌가

GPT-4 Turbo의 128k, Gemini 1.5의 100만 토큰, 그리고 최근 Claude의 200k 컨텍스트까지. 긴 컨텍스트 윈도우가 발표될 때마다 어김없이 같은 글이 올라온다. "이제 문서 전체를 프롬프트에 넣으면 되니까 RAG는 필요 없다." 반론이 달리고, 한 달쯤 지나면 조용해진다. 그리고 다음 모델이 나오면 똑같이 반복된다.

우리 팀이 이 주기를 몇 번 겪으면서 피부로 느낀 것은 하나다. 이 논쟁이 추상적인 ML 커뮤니티 토론으로 끝나지 않는다는 점이다. 결제 시스템을 운영하는 입장에서는 이 선택이 실제 운영 비용, 오류 응답률, 그리고 규정 준수 리스크에 직결된다. PG사 정책 문서, 카드사 수수료 테이블, 정산 규칙 명세서, 금감원 가이드라인 — 이 모든 문서가 동시에 살아있는 시스템이라면, "그냥 다 넣으면 되지"라는 말은 실제 운영 앞에서 금방 무너진다.

컨텍스트 길이와 검색 정확도는 전혀 다른 문제다

100만 토큰 컨텍스트 윈도우가 있다고 해서 모델이 그 안에서 원하는 정보를 정확하게 찾아낸다는 보장은 없다. Stanford의 "Lost in the Middle" 연구(Liu et al., 2023)는 이를 실험적으로 확인했다. 긴 컨텍스트에서 관련 정보가 중간부에 위치할 때 모델의 활용 비율은 앞뒤에 비해 현저히 낮아진다. 문서가 길어질수록 이 효과는 더 뚜렷해진다.

결제 현장에서 이게 어떤 의미인지 구체적으로 보면, 우리가 운영하는 오류 코드 응답 자동화 시스템을 예로 들 수 있다. PG사별 에러 코드 테이블, 재시도 정책, 사용자 안내 문구 기준이 하나의 문서 묶음으로 존재한다. 전체를 프롬프트에 넣고 "이 오류 코드의 원인과 대응 방법은?"이라고 물으면, 모델은 종종 컨텍스트 앞쪽에 위치한 다른 PG사 규칙을 우선 참조한다. RAG는 이 검색 단계에서 이미 관련 청크를 골라낸다. 노이즈를 줄이고 정확한 조각만 모델에 전달하는 것이 핵심이다. 이 역할은 컨텍스트 윈도우가 아무리 커져도 대체되지 않는다.

비용 계산을 실제로 해보면 이야기가 달라진다

"100만 토큰을 넣을 수 있다"는 것과 "매 요청마다 100만 토큰을 쓰는 게 합리적이다"는 전혀 다른 명제다. 우리 팀이 문서 기반 질의 시스템을 구성할 때 실제로 측정한 수치를 예로 들면, 정산 규칙 문서 전체(약 80,000 토큰)를 매 요청에 포함시키는 방식과 RAG로 관련 청크 3~~5개(평균 1,200 토큰)만 선별하는 방식을 비교했을 때 입력 토큰 기준으로 약 40~~60배 차이가 났다. Claude Sonnet 기준으로 입력 토큰 단가를 적용하면, 월 10만 건 요청 시스템에서 이 차이는 월 수백만 원 단위의 비용 격차로 이어진다.

프롬프트 캐싱을 쓰면 어느 정도 완화되지만, 문서가 자주 갱신되는 환경에서는 캐시 히트율이 급격히 떨어진다. 카드사 수수료 테이블은 분기마다 바뀌고, 정산 규칙은 새로운 가맹점 계약이 생길 때마다 추가된다. 정적인 문서가 아니라 살아있는 문서를 다루는 실서비스에서는 "전체 넣기 + 캐싱"이라는 조합도 결국 한계에 부딪힌다.

RAG가 오히려 독이 되는 상황도 분명히 있다

그렇다고 RAG를 항상 써야 한다고 말하는 것은 아니다. 구현이 제대로 되지 않은 RAG는 긴 컨텍스트 직접 입력보다 나쁜 결과를 낸다. 이 점은 팀 내에서도 쓴맛을 본 경험이 있다.

청크 분할 전략이 잘못되면, 문서의 맥락이 끊긴 조각이 검색되어 모델이 반쪽짜리 규칙을 기반으로 답변한다. 예를 들어 정산 정책 문서에서 "취소 건의 수수료 처리" 항목이 두 문단에 걸쳐 있을 때, 청크 경계가 중간에 잘리면 앞 문단만 검색되어 "취소 수수료 없음"이라는 불완전한 답변이 나온다. 실제 규정은 "당일 취소는 없음, 익일 이후 취소는 1.5% 부과"였는데 말이다. 이런 오류는 사용자 민원이나 정산 오류로 이어질 수 있다.

임베딩 모델 선택과 재순위(reranking) 알고리즘도 마찬가지다. 작은 팀에서 RAG 파이프라인을 정교하게 구성하고 유지하는 비용은 실제로 크다. 문서 규모가 작고(10,000 토큰 이하), 업데이트 빈도가 낮고(월 1회 미만), 요청 볼륨도 낮다면(일 1,000건 이하) — 잘 정리된 시스템 프롬프트에 내용을 직접 포함시키는 것이 더 단순하고 안정적이다. 복잡성을 도입하는 데는 그만한 이유가 있어야 한다.

HEDVION 팀이라면 이렇게 적용한다 — 실제 시나리오

우리 팀이 최근 구성한 "정산 이의제기 자동 응답 시스템"을 예로 들면 의사결정 흐름이 명확해진다. 가맹점에서 정산 내역에 이의를 제기할 때, 시스템이 관련 정산 규칙, 수수료 기준, 과거 유사 처리 사례를 참조해 초안 응답을 생성한다.

처음에는 "전체 정책 문서를 시스템 프롬프트에 넣자"는 의견도 있었다. 문서 전체가 약 45,000 토큰이었고, 당시 컨텍스트 창은 충분했다. 하지만 실제로 돌려보니 두 가지 문제가 바로 나타났다. 첫째, 응답 생성 비용이 쿼리당 약 150원대로 나왔고, 월 이의제기 건수 기준으로 환산하면 허용 범위를 초과했다. 둘째, 문서 중간에 위치한 특수 가맹점 예외 규정이 자주 누락되거나 일반 규정과 혼용되었다.

RAG로 전환한 뒤 — 규칙 유형별 청크 분할, 가맹점 카테고리 메타데이터 필터링, BM25 + 임베딩 하이브리드 검색 적용 — 쿼리당 비용은 약 8원대로 내려왔고, 예외 규정 참조 정확도는 내부 테스트 기준 약 31%p 개선되었다. 파이프라인 구축에 약 3주가 들었지만, 그 이후 운영 비용과 오류율을 감안하면 투자 회수는 두 달 안에 이루어졌다.

지금 당장 쓸 수 있는 의사결정 기준

"RAG를 써야 하나, 긴 컨텍스트로 그냥 넣어야 하나"를 팀에서 결정할 때 우리가 실제로 사용하는 체크리스트다. 세 가지 중 하나라도 해당하면 RAG 파이프라인을 구성한다.

1. 참조 문서 규모가 쿼리당 합리적 토큰 예산을 초과하는가? "합리적 예산"은 서비스 단가 역산으로 계산한다. 쿼리당 허용 비용이 10원이라면, 허용 입력 토큰은 모델 단가 기준으로 역산 가능하다. 전체 문서가 그 한계를 넘으면 RAG가 필요하다.

2. 문서가 자주 갱신되어 정적 프롬프트 관리가 실질적으로 어려운가? 월 2회 이상 내용이 바뀌는 문서라면, 시스템 프롬프트 버전 관리 비용이 RAG 파이프라인 구축 비용보다 빠르게 커진다.

3. 검색 정확도가 응답 품질에 직접 영향을 주고, 그 오류의 결과가 민감한가? 결제 오류 안내, 정산 규정 해석, 규정 준수 판단처럼 오답의 비용이 높은 경우라면 RAG의 검색 단계가 제공하는 노이즈 제거 효과가 결정적이다.

셋 다 해당하지 않으면 시스템 프롬프트 직접 포함으로 시작하고, 필요할 때 전환한다. 기술의 사망 선고는 보통 실제보다 과장된다. RAG도 사라지지 않는다. 다만 왜 쓰는지 모르고 쓰거나, 반대로 쓸 이유가 있는데 "요즘 컨텍스트 길어졌다"는 이유로 포기하는 것 — 그 두 가지 실수를 피하는 것이 지금 우리 팀의 기준이다.