"RAG는 이제 한물갔다. 1M 토큰 컨텍스트에 전부 넣어 버리면 그만이다." 최근 AI 업계에서는 이런 논의를 접할 기회가 부쩍 늘었습니다. 주요 생성형 AI가 잇따라 롱 컨텍스트에 대응하면서, 이론적으로는 사내 문서를 통째로 프롬프트에 실어 질문할 수 있는 시대에 들어선 것입니다.

그렇다면 RAG(검색 증강 생성)는 이제 필요 없어진 것일까요? 이 글에서는 이 논의를 정면으로 다루고, 기술적 관점과 구체적인 수치를 통해 **기업 지식 베이스 용도에서는 "용도에 따라 나누어 쓰는 것이 현시점의 최적해"**라는 결론을 해설합니다.

이 글에서 알 수 있는 것

Long Context 혁명과 "RAG 불필요론"이 등장한 배경
"전부 먹이면 된다"는 논리가 기업 지식 베이스에서 부딪치는 다섯 가지 벽
Long Context가 진정으로 빛나는 영역
하이브리드형이라는 현실해와 설계 시의 판단 축

Long Context 혁명 -- AI에게 "전부 읽게 한다"가 현실이 되다

최근 1~2년 사이, 대규모 언어 모델(LLM)의 컨텍스트 윈도(=한 번의 주고받음에서 다룰 수 있는 정보량)는 극적으로 확대되었습니다.

주요 생성형 AI가 100만(1M)~200만(2M) 토큰 수준의 Long Context에 대응
한국어 텍스트로 환산하면 1M 토큰은 원고지 약 3,500장, 책 10~15권 분량
이미지·표·PDF까지 멀티모달로 읽어들이는 모델도 증가

불과 몇 년 전에는 상상조차 할 수 없었던 규모입니다. GPT-3 시대(2020년)의 컨텍스트 윈도가 4,000 토큰 수준이었다는 점을 생각하면, 거의 세 자릿수에 가까운 스케일업이 일어난 셈입니다.

이런 급속한 진화를 배경으로 AI 커뮤니티에서는 자연스럽게 이런 목소리가 나오기 시작했습니다. "그렇게 많이 읽을 수 있다면 사내 문서를 전부 프롬프트에 넣어 버리면 되지, 굳이 RAG로 검색할 필요가 있을까?"

RAG의 원리와 기본 개념은 RAG란 무엇인가에서 상세히 설명하고 있습니다. 이 글에서는 그 지식을 전제로, "RAG 불필요론"이 과연 성립하는지를 검토해 봅니다.

"전부 먹이면 된다"는 논리의 실상 -- 이론과 현실의 간극

결론부터 말하면, 개인 용도나 소규모 문서 집합이라면 Long Context에 전부 넣어 버리는 운영은 충분히 현실적입니다. 그러나 기업 지식 베이스 용도로 시선을 돌리면 여러 겹의 벽에 부딪치게 됩니다. 여기서는 대표적인 다섯 가지를 살펴봅니다.

벽 1: 비용 -- 매 쿼리마다 100MB를 계속 보낼 것인가

Long Context의 가장 큰 약점은 비용입니다. 프롬프트에 실은 토큰은 원칙적으로 매번 과금되기 때문입니다.

사내 문서를 100MB(텍스트 환산으로 약 50MB = 2,500만 자) 보유한 기업을 가정해 봅시다. 이는 토큰 환산으로 약 1,600만 토큰 규모입니다. 현재의 1M 컨텍스트에는 담기지 않지만, 앞으로 2M, 5M으로 확장된다고 가정해 계산해 보겠습니다.

시나리오	쿼리당 입력 토큰	쿼리당 비용 감각	월 1만 쿼리의 경우
RAG(관련 청크만)	수천~수만	몇십 원 미만	수십만 원
Long Context 전량 투입	100만~1,600만	수천~수만 원	수천만~수억 원

프롬프트 캐시(동일 프롬프트의 재전송에 할인을 적용하는 방식)를 활용하면, 캐시 히트 시의 비용을 원래의 1/10 수준까지 압축할 수 있습니다. 다만 그래도 하루 수백만 원 단위의 비용은 쉽게 사라지지 않습니다. 캐시가 듣지 않는 첫 호출이나, 문서 갱신 후 재캐시에는 풀 비용이 드는 점도 놓칠 수 없습니다.

"관련된 몇 페이지만 보내는 RAG"와 "매번 전부를 보내는 Long Context"는 비용의 자릿수가 말 그대로 다릅니다.

벽 2: 용량 -- 1M~2M으로도 중견 기업의 전 문서는 담기지 않는다

애초에 Long Context에 전사의 문서가 담기는지 자체가 문제입니다.

1M 토큰 ≒ 책 10~15권
중견 기업 한 곳의 사내 문서는 일반적으로 PDF 1,000~~5,000건, 수천만~~수억 토큰 규모
회의록·Slack 로그·고객 메일까지 포함하면 자릿수가 한 단계 더 늘어납니다

즉, 1M~2M로는 "전부 먹이기"에 턱없이 부족한 것이 현실입니다. Long Context는 분명 큰 진보이지만, "기업 지식을 통째로 담아 두는 스토리지"로서는 아직 작습니다.

벽 3: 권한 분리 -- 모두가 같은 문서를 볼 수 있는 것은 아니다

기업 지식 베이스에는 사용자나 부서별로 접근 권한이 다르다는 큰 전제가 있습니다.

인사부만 볼 수 있는 급여·평가 자료
특정 프로젝트의 기밀 자료
임원·경영진에게만 공개되는 경영 자료

Long Context 방식에서는 이론적으로 사용자마다 다른 문서 세트를 프롬프트로 조립해야 합니다. 하지만 이는,

사용자별로 캐시가 갈라져 비용 효율이 떨어진다
권한 체크 로직이 프롬프트 생성 계층에 섞여 들어가 설계가 복잡해진다
"이 정보를 실어도 되는가?"의 판단 실수가 곧바로 정보 유출로 이어진다

와 같은 과제를 안게 됩니다. 권한과 접근 제어가 전제인 기업 용도에서는 검색 단계에서 필터링할 수 있는 RAG형 쪽이 훨씬 자연스럽습니다. Monoshiri AI가 채택한 폴더 단위의 접근 제어 구조에 대해서도 보안 정책에서 공개하고 있습니다.

벽 4: Lost in the Middle -- 길수록 정확도가 떨어지는 현상

"Long Context에 넣으면 AI가 제대로 읽어 주겠지"라고 생각하기 쉽지만, 실제로는 LLM이 프롬프트의 앞과 끝에 강하게 주목하고 가운데 부분의 정보를 놓치기 쉽다는 사실이 여러 연구에서 지적되고 있습니다. 이 현상을 "Lost in the Middle"이라고 부릅니다.

특히 특정 사실 하나를 콕 집어 찾는 질문("X의 신청 마감은 언제인가?" 등)에서 성능 저하가 두드러집니다
문서 수·문서 길이가 늘어날수록 정확도 저하가 가속화되는 경향
모델에 따라서는 1M 컨텍스트에 대응하더라도, 실질적으로 고정밀로 다룰 수 있는 것은 수십만 토큰 수준이라는 지적도 있습니다

RAG는 관련도가 높은 몇 페이지만 프롬프트에 싣기 때문에, 구조적으로 Lost in the Middle의 영향을 덜 받습니다. "대량의 문서에서 특정 문장을 끄집어내는" 작업에서는 오히려 RAG가 강한 것입니다.

벽 5: 업데이트 -- 문서를 한 건 추가할 때마다 무엇을 하는가

기업 지식은 매일처럼 업데이트됩니다. 규정 개정, 신제품 출시, 회의록 추가. 문서를 한 건 추가할 때마다 무슨 일이 벌어지는지 비교해 봅시다.

방식	문서 추가 시의 동작
RAG	추가분만 벡터화하여 인덱스에 등록
Long Context 전량 투입	프롬프트 전체를 다시 만들고 캐시도 재구축

**"차분(差分)만 처리할 수 있는가"**는 운영 비용에 직결되는 중요한 관점입니다. RAG는 차분 업데이트에 강하고, Long Context 전량 투입은 차분 업데이트에 약하다는 분명한 구조적 차이가 있습니다.

Long Context가 진정으로 빛나는 영역

여기까지 Long Context의 과제를 살펴봤지만, "쓸모없다"는 이야기가 아닙니다. 오히려 RAG가 약한 영역에서 Long Context는 압도적인 힘을 발휘합니다.

1. 소규모로 완결되는 지식

수 건~수십 건의 문서로 이루어진 지식은 Long Context에 전부 넣어 버리는 것이 가장 빠르고 가장 강력합니다. 예를 들어 제품 매뉴얼 한 권, 계약서 한 통, 회의록 하나를 대상으로 하는 질의응답에서는, 검색 인덱스를 만드는 것보다 프롬프트에 붙여 넣는 편이 빠르고 정확도도 안정적입니다.

2. 문서 내부의 깊은 추론·교차 분석

하나의 긴 문서 안에서 "A장과 B장을 대조해 모순을 지적해 달라" "전체를 요약해 달라" 같은 작업은 문서 전체를 동시에 볼 필요가 있기 때문에, RAG의 청크 분할 방식으로는 불리해집니다. Long Context의 독무대입니다.

3. 여러 문서를 가로지르는 통합 분석

관련된 10~30건 정도의 문서를 교차 대조하여 "이들에 공통된 패턴을 추출해 달라" 같은 분석형 작업도 Long Context가 적합합니다.

정밀 검색형 작업은 RAG, 전체 조망형 작업은 Long Context -- 이렇게 정리하면 두 방식의 역할 분담이 눈에 들어옵니다.

현실해는 하이브리드 -- 세 가지 방식의 혼합 활용

이러한 특성을 감안해, 실무에서는 다음 세 가지 방식을 조합하는 설계가 주류가 되어 가고 있습니다.

1. 고전적 RAG -- 대규모 지식의 검색·응답 기반

전통적인 RAG는 **"대량의 문서에서 몇 페이지만 뽑아 답변한다"**는 유스케이스에서, 지금도 가장 비용 대비 효과가 뛰어난 선택지입니다. 시맨틱 검색의 구조는 사내 문서를 AI로 검색하는 방법에서 해설하고 있습니다.

2. Long Context 활용 -- 소규모·심층 용도

대상 문서가 이미 좁혀져 있고, 문서 내부의 깊은 추론이 필요한 상황에서는 Long Context를 그대로 사용하는 것이 지름길입니다.

3. 하이브리드형(Agentic RAG / RAG + Long Context / CAG)

최근 특히 주목받고 있는 것이 하이브리드형입니다. 대표적인 발전 형태로는,

Agentic RAG: AI 에이전트가 "우선 검색 → 부족하면 추가 검색 → 필요하면 전문을 읽으러 간다"와 같이 자율적으로 판단하는 패턴
RAG + Long Context: RAG로 관련 문서군을 좁힌 뒤, 그 내용은 Long Context로 통째로 읽게 하는 패턴(청크 분할의 부작용을 억제할 수 있음)
Cache-Augmented Generation(CAG): 자주 쓰이는 문서군을 미리 프롬프트 캐시에 실어 두고, 검색 단계를 생략하면서 비용을 억제하는 패턴

이 있습니다. 이들은 "RAG냐 Long Context냐"가 아니라 양자를 통합한 설계로 이해하는 것이 정확합니다.

기업 지식 베이스를 설계할 때의 다섯 가지 판단 축

그렇다면 자사의 지식 베이스를 설계할 때 무엇을 기준으로 삼으면 좋을까요. 다음 다섯 가지 축으로 정리해 보시기를 권장합니다.

1. 문서량

규모	권장 방식
수 건~수십 건	Long Context 중심
수백 건~수천 건	RAG 중심, 필요에 따라 하이브리드
수만 건 이상	RAG 필수

2. 권한 분리의 필요성

부서별·직급별로 접근 권한을 나누어야 하는 경우에는, 검색 단계에서 필터링할 수 있는 RAG형이 사실상 필수가 됩니다.

3. 업데이트 빈도

일 단위·시간 단위로 문서가 추가·갱신되는 환경에서는 차분 업데이트에 강한 RAG가 운영에 유리합니다.

4. 비용 허용도

질의 건수가 많은(예: 전 직원이 매일 사용) 경우, 매 쿼리마다 대량 토큰을 보내는 Long Context 운영은 예산을 압박하기 쉽기 때문에 신중한 추산이 필요합니다.

5. 질문 유형

"특정 사실 하나를 끄집어내는" 질문이 중심 → RAG가 유리
"문서 전체를 조망하는" 질문이 중심 → Long Context가 유리
두 가지가 혼재 → 하이브리드형

Monoshiri AI가 RAG를 기반으로 삼는 것은, 기업 지식 베이스라는 유스케이스에 대해 이 축들을 모두 놓고 봤을 때 현시점에서 RAG가 가장 균형 잡힌 선택지이기 때문입니다. 다만 Long Context의 진화는 앞으로도 이어지리라 보고 있기에, 적절한 장면에서 양자를 조합할 수 있는 유연성을 중시해 설계하고 있습니다. 요금 체계는 요금제, 주요 기능은 기능 목록을 참조해 주세요.

마무리

이 글에서는 Long Context 시대의 "RAG 불필요론"의 타당성과, 기업 지식 베이스의 설계 방침에 대해 전해 드렸습니다. 요점을 정리해 봅니다.

Long Context는 분명 혁명적이지만, 기업 지식 베이스 용도에서는 비용·용량·권한·정확도·업데이트의 다섯 가지 벽이 존재한다: "전부 먹이면 된다"는 논리는 개인 용도나 소규모 문서 집합에는 들어맞지만, 기업 전체의 문서에는 현시점에서는 맞지 않는다
RAG와 Long Context는 대립이 아니라 보완 관계: 정밀 검색형은 RAG, 전체 조망형은 Long Context가 강점
현실해는 하이브리드형: Agentic RAG, RAG + Long Context, Cache-Augmented Generation 등 양자를 통합하는 설계가 주류가 되어 가고 있다
설계 시의 판단 축은 다섯 가지: 문서량, 권한 분리, 업데이트 빈도, 비용 허용도, 질문 유형. 자사 요건을 이 다섯 축으로 정리하면 최적해가 보이기 시작한다

AI 기술의 진화 속도는 빨라, 몇 년 뒤에는 지금의 상식이 다시 뒤바뀔 가능성도 충분히 있습니다. 그래도 "자사의 유스케이스에 어떤 기술이 가장 적합한가"를 판단하는 시각은 어떤 시대에도 변함없이 중요합니다. 이 글이 그 판단의 단서가 된다면 다행이겠습니다.

RAG는 이제 한물갔나? 롱 컨텍스트 시대의 지식 베이스 설계