RAG는 죽었다? 가상 파일시스템으로 AI 문서 검색을 대체하는 팀들의 이야기

RAG(Retrieval-Augmented Generation)는 지난 2년간 AI 애플리케이션의 사실상 표준 아키텍처였습니다. 그런데 최근 일부 팀들이 벡터 DB와 청킹 파이프라인을 걷어내고, 그 자리에 가상 파일시스템을 올리고 있습니다. 단순한 실험이 아니라, 프로덕션에서 돌아가는 문서 어시스턴트의 핵심 구조를 바꾸는 수준의 이야기입니다.

RAG가 약속한 것과 현실의 간극

RAG의 핵심 아이디어는 단순합니다. 사용자 질문이 들어오면 벡터 DB에서 관련 문서 조각을 검색하고, 그걸 LLM 컨텍스트에 넣어서 답변을 생성하는 것입니다. 이론적으로는 완벽해 보이지만, 실제로 운영해 본 팀들은 하나같이 같은 문제를 이야기합니다.

첫째, 청킹(chunking)이 생각보다 훨씬 어렵습니다. 문서를 500토큰 단위로 자르면 문맥이 끊기고, 2000토큰으로 자르면 검색 정확도가 떨어집니다. 표, 코드 블록, 중첩된 리스트 같은 구조화된 콘텐츠는 어떤 크기로 잘라도 정보가 훼손됩니다.

둘째, 검색 품질의 한계입니다. 임베딩 기반 유사도 검색은 의미적으로 비슷한 문서를 찾는 데는 괜찮지만, 정확히 필요한 정보를 찾는 데는 자주 실패합니다. “배포 가이드에서 환경변수 설정 부분"처럼 구체적인 요청에 대해 엉뚱한 청크가 상위에 올라오는 경험, RAG를 써본 분이라면 익숙할 겁니다.

셋째, 파이프라인 복잡도입니다. 임베딩 모델 선정, 벡터 DB 운영, 청킹 전략 최적화, 리랭킹 모델 추가, 하이브리드 검색 구현. RAG를 제대로 하려면 본 서비스보다 검색 파이프라인에 더 많은 엔지니어링이 들어갑니다.

가상 파일시스템이라는 발상의 전환

가상 파일시스템 접근법은 완전히 다른 전제에서 출발합니다. 문서를 잘라서 벡터로 바꾸는 대신, AI에게 파일시스템처럼 문서 구조를 탐색할 수 있는 도구를 줍니다.

구체적으로 이런 식입니다. AI 에이전트가 ls docs/ 같은 명령으로 문서 디렉토리 구조를 확인하고, read docs/deployment/env-setup.md로 필요한 파일을 직접 읽고, grep "DATABASE_URL" docs/로 특정 키워드를 검색합니다. 사람이 문서를 찾는 방식과 거의 동일합니다.

핵심은 검색을 한 번에 끝내는 것이 아니라, AI가 반복적으로 탐색하고 좁혀나가도록 하는 것입니다. 처음에 디렉토리 구조를 보고, 관련 있어 보이는 폴더를 열고, 목차를 확인하고, 필요한 섹션만 읽는 과정을 AI 스스로 수행합니다.

왜 지금 이 접근법이 가능해졌는가

이 아키텍처가 갑자기 주목받는 데는 기술적 배경이 있습니다.

컨텍스트 윈도우의 폭발적 확장이 가장 큰 요인입니다. 2024년 초만 해도 대부분의 모델이 8K~32K 토큰을 지원했습니다. 지금은 100만 토큰 이상을 처리하는 모델이 상용화되어 있습니다. 긴 문서를 통째로 읽어도 컨텍스트가 부족하지 않다는 뜻입니다.

도구 사용(Tool Use) 능력의 성숙도 중요합니다. 최신 LLM들은 파일 읽기, 검색, 디렉토리 탐색 같은 도구를 능숙하게 활용합니다. 한 번에 정답을 찾지 못하면 다른 전략으로 전환하는 판단력도 갖추고 있습니다.

에이전트 패러다임의 확산도 빠질 수 없습니다. AI를 단발성 질의응답 기계가 아니라, 여러 단계를 거쳐 작업을 수행하는 에이전트로 바라보는 시각이 자리 잡으면서, 다단계 문서 탐색도 자연스럽게 수용되고 있습니다.

RAG 대비 실질적인 장점은 무엇인가

가상 파일시스템 접근법이 주목받는 가장 큰 이유는 구현과 유지보수의 단순함입니다.

벡터 DB가 필요 없습니다. 임베딩 파이프라인이 필요 없습니다. 문서가 업데이트되면 파일만 바꾸면 됩니다. 재인덱싱 같은 건 존재하지 않습니다. 기존에 RAG 파이프라인을 구축하는 데 들었던 인프라 비용과 엔지니어링 시간이 대폭 줄어듭니다.

문서의 원본 구조가 보존된다는 점도 중요합니다. 청킹 과정에서 손실되던 표, 코드 블록, 문서 간 상호 참조가 그대로 유지됩니다. AI가 “이 문서의 3번째 섹션을 보세요"라고 안내할 수 있다는 건, 사용자가 실제로 원본 문서를 찾아가 확인할 수 있다는 뜻이기도 합니다.

디버깅도 훨씬 직관적입니다. RAG에서 잘못된 답변이 나오면 임베딩 품질, 청킹 전략, 리랭킹 로직을 모두 의심해야 합니다. 가상 파일시스템에서는 AI가 어떤 파일을 읽었는지 로그만 보면 됩니다.

그래도 RAG가 더 나은 경우

물론 만능은 아닙니다.

문서량이 수만 건 이상으로 대규모인 경우, AI가 일일이 탐색하는 것보다 벡터 검색이 훨씬 효율적입니다. 파일시스템 탐색은 여러 번의 LLM 호출을 수반하기 때문에 레이턴시와 비용이 올라갑니다.

잘 정리된 디렉토리 구조가 전제 조건이기도 합니다. 파일명이 document_final_v3_수정.docx인 문서들이 한 폴더에 수백 개 들어있다면, 파일시스템 탐색은 오히려 재앙이 됩니다. 이 접근법은 문서가 논리적으로 구조화되어 있을 때 빛을 발합니다.

실시간 응답이 중요한 챗봇 시나리오에서도 주의가 필요합니다. 탐색에 여러 단계가 걸리면 사용자 체감 응답 시간이 길어질 수 있습니다. 반면 RAG는 검색 한 번, 생성 한 번으로 끝나니까요.

결국 문서의 규모, 구조화 수준, 응답 시간 요구사항에 따라 적합한 아키텍처가 달라집니다. 현실적으로는 대규모 1차 필터링에 RAG를 쓰고, 좁혀진 범위에서 파일시스템 탐색을 하는 하이브리드 접근이 가장 실용적일 수 있습니다.

이것이 시사하는 AI 아키텍처의 방향

더 큰 그림에서 보면, 이 흐름은 AI 시스템 설계 철학의 변화를 반영합니다. 데이터를 AI에 맞게 전처리하는 시대에서, AI가 원본 데이터를 직접 다루는 시대로 이동하고 있다는 것입니다.

RAG는 LLM의 컨텍스트 윈도우가 작고, 도구 사용 능력이 미숙하던 시절의 해법이었습니다. 그 제약 조건이 빠르게 사라지고 있는 지금, 아키텍처도 함께 진화하는 것이 자연스럽습니다.

RAG가 완전히 사라지지는 않을 겁니다. 하지만 “일단 RAG부터 깔고 보자"는 관성에서 벗어나, 정말 내 문제에 RAG가 최선인지 한 번쯤 질문해볼 시점은 분명히 왔습니다. 여러분의 프로젝트에서는 어떤 접근법이 더 맞을까요?