「Gemini 2.5가 1M 토큰에 대응했다」「Claude의 컨텍스트 윈도가 확대되었다」. 이런 뉴스를 접한 IT 담당자들로부터 최근 자주 다음과 같은 상담을 받습니다.

「RAG는 이제 필요 없는 거 아닌가요? 전부 프롬프트에 넣어 버리면 된다고 들었는데요」

확실히 롱 컨텍스트 LLM(긴 문장을 한 번에 읽어들일 수 있는 대규모 언어 모델)의 진화는 눈부시며, SNS나 블로그에서도 「RAG 불필요」「RAG 필요 없다」라는 주장이 늘고 있습니다. 그러나 이 주장을 그대로 받아들여 의사 결정을 하면, 실제 운영에서 발이 걸리는 기업이 끊이지 않습니다.

이 글에서는 「RAG 불필요론」이 등장한 배경을 정리한 다음, 자사의 유스케이스에서 정말로 RAG가 불필요한지를 6가지 판단 축으로 가려내는 방법을 사내 지식 AI를 검토 중인 정보 시스템 담당자·경영층 대상으로 해설합니다.

이 글에서 알 수 있는 것

「RAG 불필요」라는 주장이 확산된 배경
정말로 RAG가 불필요한 경우(개인·소규모 지식)의 조건
기업 지식 용도에서 여전히 RAG가 필요해지는 6가지 판단 축
롱 컨텍스트·RAG·skill 모드 -- 어느 것을 선택해야 할지의 판단 흐름
Monoshiri AI의 위치와, 기업 지식 AI 선정에서 실패하지 않는 요령

왜 지금 「RAG 불필요」라고 말해지는가

「RAG 불필요론」이 확산되고 있는 데에는 분명한 기술적 이유가 있습니다. 우선 무엇이 변했는지 정리해 봅니다.

1. 컨텍스트 윈도가 세 자릿수 확대되었다

불과 몇 년 전까지만 해도 대규모 언어 모델이 한 번에 다룰 수 있는 정보량은 수천 토큰(한국어로 수천 자) 정도였습니다. 그것이 2024~2026년에 걸쳐 급속히 확대되어, 현재는 주요 모델의 다수가 100만(1M)~200만(2M) 토큰에 대응하고 있습니다.

1M 토큰은 한국어 환산으로 원고지 3,500장, 책 10~15권 분량에 해당합니다. 「제품 매뉴얼 한 권 정도라면 통째로 프롬프트에 붙여 질문할 수 있는」 시대가 된 것은 분명합니다.

2. 프롬프트 캐시로 「전부 투입」의 비용이 낮아졌다

주요 LLM 제공사는 프롬프트 캐시(같은 프롬프트를 재전송할 때 요금을 할인하는 구조)를 제공하고 있습니다. 이로 인해 고정된 사내 문서를 매번 프롬프트에 싣는 운영이라도, 캐시 히트 시의 비용은 본래의 1/10 수준까지 압축할 수 있게 되었습니다.

3. 「RAG 구현은 어렵다」는 이미지가 정착했다

RAG는 개념 자체는 단순하지만, 본격 운영에는 다음과 같은 노하우가 필요합니다.

문서의 청크 분할 설계
벡터 DB의 선정과 인덱스 설계
검색 정확도 튜닝(재랭킹, 하이브리드 검색 등)
문서 갱신 시의 재벡터화 파이프라인

이를 자체 개발하려다 좌절한 경험을 가진 기업이 적지 않습니다. **「번거로운 RAG를 건너뛰고, 롱 컨텍스트로 단순하게 끝내고 싶다」**는 심리가 작동하는 것은 자연스러운 일입니다.

결론: 정말로 RAG가 불필요한 경우는 「3가지 조건」을 충족하는 경우

먼저 결론부터 말씀드립니다. 「RAG 불필요」가 성립하는 것은 다음의 3가지 조건을 모두 충족하는 경우에 한정됩니다.

대상 문서가 1M 토큰 이내에 들어간다(책 10~15권 이내)
모든 사용자가 동일한 문서 세트를 참조해도 된다(권한 분리가 불필요)
문서의 갱신 빈도가 낮거나, 갱신 시 전체 프롬프트 재생성의 비용을 허용할 수 있다

이 3가지 조건에 들어맞는 전형적인 예는 개인 개발자가 사용하는 기술서의 Q&A, 특정 프로젝트의 수십 개 파일을 대상으로 한 분석, 제품 매뉴얼 한 권에 대한 질의응답 등입니다.

뒤집어 말하면 기업의 사내 지식 용도의 대부분은 이 3가지 조건 중 어느 하나에 걸립니다. 여기서부터는 왜 기업 용도에서 RAG가 여전히 필요한지를 6가지 판단 축으로 나누어 살펴보겠습니다.

자사에 RAG가 필요한지를 판단하는 6가지 축

「RAG 불필요론」을 그대로 받아들이지 말고, 자사의 유스케이스에 비추어 보기 위한 체크리스트입니다. 한 가지라도 해당된다면, 롱 컨텍스트 단독 운영은 위험 신호로 간주하시기 바랍니다.

축 1: 문서량 -- 전사의 문서가 애초에 1M에 들어가는가

먼저 자사의 사내 문서를 모두 합치면 몇 토큰이 되는지를 거칠게라도 좋으니 어림잡아 보시기 바랍니다.

문서의 종류	토큰 수 어림
취업규칙·인사 규정	5만~20만
업무 매뉴얼(부서 단위)	10만~50만
제품 문서	수십만~수백만
회의록·사내 위키	수백만~수천만
고객 대응 이력·서포트 티켓	수천만~억 단위

중견 기업 한 곳의 사내 문서 총량은 회의록이나 Slack 로그를 포함하면 수천만~수억 토큰에 달하는 것이 보통입니다. 1M이나 2M로는 「전부 먹이기」에 턱없이 부족합니다.

「그렇다면 관련된 문서만 프롬프트에 실으면 되겠네」라고 말하지만, 그것은 결국 RAG의 사고방식 그 자체입니다. 어떤 형태로든 「관련 문서를 골라내는 구조」가 필요해집니다.

축 2: 권한 분리 -- 모두가 같은 문서를 봐도 되는가

기업 지식에는 사용자나 부서별로 접근 권한이 다른 것이 보통입니다.

인사부만 볼 수 있는 급여·평가 자료
경리부만 볼 수 있는 재무 정보
프로젝트 멤버 한정의 기밀 자료
임원 한정의 경영 자료

롱 컨텍스트 운영에서는 사용자별로 다른 문서 세트를 프롬프트로 조립할 필요가 있습니다. 여기에는 3가지 문제가 있습니다.

캐시 효율의 저하: 사용자별로 프롬프트가 바뀌면 프롬프트 캐시의 히트율이 떨어진다
권한 로직의 복잡화: 「이 정보를 실어도 되는가」의 판단이 프롬프트 생성 계층에 섞여 들어간다
정보 유출 리스크: 권한 판정의 실수가 곧바로 기밀 정보의 유출로 이어진다

검색 단계에서 사용자 권한에 따라 필터링할 수 있는 RAG형 쪽이, 설계상 훨씬 자연스럽습니다. 이는 기술 선정이라기보다 기업 정보 시스템의 기본 원칙의 문제입니다.

축 3: 갱신 빈도 -- 문서는 얼마나 자주 바뀌는가

사내 문서는 정적이지 않습니다. 규정 개정, 신제품 발표, 회의록 추가, FAQ 갱신 -- 매일같이 무언가가 바뀝니다.

방식	문서 1건 추가 시의 동작
RAG	추가분만 벡터화하여 인덱스에 등록(수 초)
롱 컨텍스트 전량 투입	프롬프트 전체를 다시 만들고 캐시도 재구축

차분 갱신에 강한가 약한가는 운영 비용에 직결됩니다. 일 단위·시간 단위로 문서가 갱신되는 환경에서는 RAG의 우위성은 흔들리지 않습니다.

축 4: 쿼리 빈도 -- 하루에 몇 건의 질문이 오는가

사내 지식 AI는 도입이 진행될수록 쿼리 수가 늘어납니다. 처음에는 하루 수십 건이었던 것이 정착되면 수백~수천 건/일로 늘어납니다.

여기서 영향을 미치는 것이 1쿼리당 입력 토큰 수입니다. 가령 사내 문서를 1M(=100만) 토큰분 프롬프트에 싣는다면,

쿼리당: 수십 원~수백 원(모델에 따라 다름)
하루 1,000쿼리의 경우: 월 수십만 원~수백만 원
프롬프트 캐시로 할인을 받아도, 첫 호출이나 갱신 후의 재캐시에는 풀 비용이 든다

RAG라면 관련 청크만 보내기 때문에 쿼리당 수천~수만 토큰으로 끝납니다. 비용 차이는 문자 그대로 자릿수가 다릅니다.

축 5: 핀 포인트 질문의 정확도 -- "Lost in the Middle"을 허용할 수 있는가

롱 컨텍스트라면 「전부 읽어 줄 것이다」라고 생각하기 쉽지만, LLM은 프롬프트의 앞과 끝에 강하게 주목하고 가운데 부분의 정보를 놓치기 쉽다는 점이 여러 연구에서 지적되고 있습니다. 이를 "Lost in the Middle"이라고 부릅니다.

「X의 신청 마감은 언제인가?」와 같은 핀 포인트 사실 추출에서 정확도 저하가 두드러진다
프롬프트가 길어질수록 열화가 가속화된다
1M 대응 모델이라도 실질적으로 고정밀도를 유지할 수 있는 것은 수십만 토큰 수준이라는 지적이 있다

「특정 한 문장을 끄집어내는」 작업은, 관련된 몇 페이지만 보내는 RAG 쪽이 안정적인 것이 실정입니다.

축 6: 감사와 설명 책임 -- 「왜 그렇게 답했는지」를 제시할 수 있는가

업무에서 AI를 사용할 때, 특히 법무·인사·경리처럼 정확성이 업무의 전제가 되는 부서에서는 **「AI가 어느 문서의 어디를 근거로 답했는지」**를 사후에 추적할 수 있는 것이 중요합니다.

롱 컨텍스트 전량 투입: 「전부 읽었습니다」라고밖에 말할 수 없어 근거 위치의 특정이 모호
RAG: 검색에서 히트한 청크의 출처를 명시할 수 있다
skill 모드(후술): 목차에서 따라간 경로가 그대로 이력으로 남는다

감사·설명 책임이 요구되는 업무일수록, 근거의 추적 가능성이 기술 선정의 최우선 축이 됩니다.

당신의 조직은 어느 쪽을 선택해야 하는가 -- 판단 흐름

여기까지의 축을 바탕으로, 자사의 유스케이스에 맞는 접근 방식을 선택하는 판단 흐름을 정리합니다.

패턴 A: 롱 컨텍스트 단독으로 충분한 경우

다음의 모든 조건에 해당하는 경우, RAG 없이 롱 컨텍스트 운영으로 충분합니다.

대상 문서가 1M 토큰 이내(예: 제품 매뉴얼 한 권, 계약서 몇 통, 특정 프로젝트의 회의록)
모든 사용자가 같은 문서를 참조해도 된다
문서의 갱신 빈도가 월 수 회 이하
쿼리 수가 하루 수십 건 이하
「전체를 조망한 분석」이 중심인 질문

전형적인 예: 개인 이용, 소규모 지식의 분석, 특정 문서에 대한 심층 질문

패턴 B: RAG가 필수인 경우

다음의 어느 하나에 해당하는 경우, RAG(또는 동등한 검색적 접근)는 거의 필수입니다.

문서량이 수천 건·수백만 토큰을 넘는다
부서별·프로젝트별 권한 분리가 필요
문서가 일 단위 이상의 빈도로 추가·갱신된다
전 직원이 일상적으로 질문한다(쿼리 수가 많다)
「특정 규정의 몇 조」와 같은 핀 포인트 질문이 중심

전형적인 예: 기업의 사내 지식 베이스, 고객 지원의 FAQ, 제품 문서 검색

패턴 C: 사내 지식에 최적화된 제3의 길

사실 기업의 사내 지식 용도에서는 「RAG vs 롱 컨텍스트」의 이항 대립만으로는 답이 나오지 않는 경우가 많은 것이 실정입니다.

RAG는 대량 문서에 강하지만, 환각의 리스크가 남는다
롱 컨텍스트는 비용과 권한 분리에서 막힌다
양쪽의 장점만 가져오고 싶다

그래서 최근 주목받고 있는 것이 문서 본래의 장·절·항과 같은 계층 구조를 활용하는 방식입니다. Monoshiri AI가 채택하고 있는 **skill 모드(Corpus2Skill)**가 그 대표적인 예이며, AI에게 「목차」를 건네어 필요한 문서만 스스로 읽으러 가게 하는 구조입니다.

자세한 기술 판단과 이행 경위는 RAG를 그만뒀습니다 -- Monoshiri AI가 Corpus2Skill로 전면 이행한 이유에서 공개하고 있습니다.

자주 있는 오해와 올바른 이해

「RAG 불필요」를 주장하는 논조에는 종종 오해가 포함되어 있습니다. 대표적인 것을 정리합니다.

오해 1: 「컨텍스트가 커지면 검색은 필요 없어진다」

올바르게는: 컨텍스트가 아무리 커져도, 기업 전체의 문서량은 그것을 웃도는 속도로 계속 늘어납니다. 더불어 권한 분리·비용·Lost in the Middle의 문제는 컨텍스트 확대로는 해소되지 않습니다.

오해 2: 「RAG는 환각이 많아 쓸모가 없다」

올바르게는: 환각은 RAG의 설계와 운영의 문제이며, 적절한 검색 정확도·출처 명시·「해당 없음」을 반환하는 설계를 넣으면 억제할 수 있습니다. RAG의 구조적인 약점을 인지하면서, 보완하는 접근(하이브리드형, skill 모드 등)을 선택하는 것이 옳습니다.

오해 3: 「롱 컨텍스트라면 환각이 일어나지 않는다」

올바르게는: Lost in the Middle 현상으로 인해, 긴 문장의 가운데 부분 정보를 놓치는 경우는 여전히 발생합니다. 「전부 넣었으니 완벽」은 아닙니다.

오해 4: 「RAG는 이미 성숙한 기술이라 진보하지 않는다」

올바르게는: RAG 주변은 지금도 급속히 진화하고 있으며, Agentic RAG, Cache-Augmented Generation, Corpus2Skill과 같은 신세대의 파생 형태가 잇따라 등장하고 있습니다. 「RAG 불필요」가 아니라 「RAG의 형태가 진화하고 있다」고 이해해야 합니다.

Monoshiri AI의 위치 -- 「RAG vs 불필요」를 넘어서

Monoshiri AI 자체도 서비스 시작 시에 RAG·롱 컨텍스트·하이브리드의 모두를 검증했습니다. 그 결과, **사내 지식 특유의 구조(규정·매뉴얼·FAQ의 장 구성·계층)를 최대한 살리는 skill 모드(Corpus2Skill)**에 도달했습니다.

skill 모드는 다음과 같은 점에서 기업 지식 용도에 최적화되어 있습니다.

정확성: 목차에서 따라가기 때문에, 검색 미스로 인한 환각이 일어나기 어렵다
비용: 필요한 문서만 읽기 때문에, 롱 컨텍스트 전량 투입의 비용 폭발을 회피
권한: 폴더 단위의 접근 제어와 정합성이 맞다
갱신: 새 문서를 추가하면 목차도 자동 갱신
감사: 「어느 문서의 어디를 읽었는지」가 이력으로 남는다

즉, Monoshiri AI에서는 **「RAG가 불필요」가 아니라 「RAG도 롱 컨텍스트도 뛰어넘는, 사내 지식 용도에 특화된 방식」**을 채택하고 있는 것입니다.

Monoshiri AI의 주요 기능은 기능 목록, 요금 체계는 요금제에서 공개하고 있습니다. 다른 AI 지식 SaaS와의 차이는 비교 페이지도 참조해 주세요.

「RAG 불필요」를 판단하기 전에 해야 할 3단계

마지막으로 자사에서 실제로 「RAG 불필요 or 필요」를 판단할 때의 실무 단계를 정리합니다.

1단계: 문서량을 어림잡는다

사내 문서의 총 토큰 수를 거칠게라도 좋으니 산출해 주세요. 총 글자 수 ÷ 1.5로 대략적인 토큰 수가 됩니다. 1M 토큰에 들어가는지가 첫 번째 분기점입니다.

2단계: 권한 요건을 정리한다

부서별·직급별·프로젝트별로 누가 어느 문서에 접근해도 되는지를 표로 정리해 주세요. 한 가지라도 분리가 필요하다면, 롱 컨텍스트 단독은 위험합니다.

3단계: 예상 쿼리 수와 비용을 시산한다

도입 후의 예상 이용 사용자 수 × 하루당 쿼리 횟수를 어림잡아, 롱 컨텍스트·RAG·skill 모드 각각으로 월 비용을 비교해 주세요. 스케일할수록 차이가 벌어집니다.

마무리

이 글에서는 「RAG 불필요론」을 6가지 판단 축으로 검증했습니다. 요점을 정리합니다.

「RAG 불필요」가 성립하는 것은, 문서량·권한·갱신 빈도의 3조건을 모두 충족하는 개인·소규모 지식에 한정된다
기업 지식 용도의 대부분은, 문서량·권한·갱신·쿼리 빈도·핀 포인트 정확도·감사의 6축 중 어느 하나에서 RAG적인 구조가 필요해진다
「RAG vs 롱 컨텍스트」는 이항 대립이 아니라, 용도에 따라 나누어 쓰거나 통합하는 것이 현실적인 답
사내 지식에 특화한다면, 양자를 뛰어넘는 skill 모드(Corpus2Skill) 같은 제3의 길도 있다
판단은 감각이 아니라, 문서량·권한·쿼리 수·비용의 시산으로 하는 것이 철칙

「RAG 불필요」라는 캐치한 주장은 AI 트렌드의 한 단면을 잘라낸 것입니다. 자사의 유스케이스에 맞는지 여부는, 자사의 문서량과 요건으로 판단할 수밖에 없습니다. 이 글의 6가지 축이 그 판단의 출발점이 되기를 바랍니다.

「RAG 불필요」는 정말일까? 사내 지식 AI에서 검토해야 할 판단 축