블로그로 돌아가기
AX2026년 4월 4일107

RAG를 걷어내고 가상 파일시스템을 올렸더니 460배 빨라졌다

Mintlify의 RAG 대체 가상 파일시스템 사례를 분석하고, 기업 AI 문서 시스템 아키텍처 선택 기준을 정리했다.

RAG, 정말 최선의 선택일까?

요즘 기업 AI 시스템 하면 빠지지 않는 게 RAG(Retrieval-Augmented Generation)다. 사내 문서를 벡터DB에 넣고, 질문이 들어오면 관련 문서를 검색해서 LLM에 넘기는 구조. 2024년부터 거의 공식처럼 자리잡았다.

그런데 최근 Mintlify가 흥미로운 실험 결과를 공개했다. 자사 AI 문서 어시스턴트에서 기존 RAG 파이프라인을 걷어내고 가상 파일시스템(Virtual Filesystem)으로 대체했더니, 세션 시작 속도가 460배 빨라지고 인프라 비용이 사실상 0에 수렴했다는 것이다.

Mintlify는 왜 RAG를 버렸나?

Mintlify는 개발자 문서 플랫폼이다. 월 85만 건의 AI 어시스턴트 대화를 처리하는데, 처음에는 샌드박스 환경에서 AI가 실제 파일시스템에 접근하는 방식을 썼다. 문제는 비용과 속도였다.

  • 샌드박스 세션 생성: 46초 (사용자는 로딩 스피너를 보며 기다림)
  • 월 인프라 비용: 연 $70,000 이상 예상
  • 대화당 한계 비용: $0.0137

작은 금액 같지만 월 85만 건이면 이야기가 달라진다. 무엇보다 46초라는 대기 시간은 프론트엔드 서비스에서 치명적이었다.

가상 파일시스템이란?

Mintlify가 만든 ChromaFs는 기존 Chroma 벡터 데이터베이스 위에 Unix 파일시스템 인터페이스를 씌운 것이다. AI 에이전트가 `grep`, `cat`, `ls`, `find` 같은 명령어를 쓰면, 실제 파일시스템이 아니라 데이터베이스 쿼리로 변환되어 실행된다.

항목기존 샌드박스 방식ChromaFs 가상 파일시스템
세션 시작~46초~100ms
한계 비용$0.0137/대화~$0
격리 방식컨테이너 격리세션 토큰 기반 접근 제어
쓰기 권한있음 (보안 리스크)읽기 전용 (안전)
확장성컨테이너 수 비례DB 인프라 재사용

핵심 아이디어는 간단하다. AI 에이전트가 문서를 탐색하는 데 실제 파일시스템이 필요하지 않다는 것. 에이전트는 파일을 읽고 검색하기만 하면 되지, 새 파일을 만들거나 수정할 필요가 없다. 그렇다면 무거운 컨테이너 대신 가벼운 추상화 레이어로 충분하다.

기업 AX에 주는 시사점은?

이 사례가 중요한 이유는 "RAG가 유일한 답은 아니다"는 메시지 때문이다. 많은 기업이 AI 도입 시 거의 자동으로 "벡터DB + RAG" 아키텍처를 선택하는데, 용도에 따라 더 효율적인 접근이 있을 수 있다.

RAG가 적합한 경우

  • 비정형 데이터가 대량으로 존재하고, 의미 기반 검색이 핵심인 경우
  • 문서 간 관계보다 개별 청크의 유사도가 중요한 경우
  • 실시간 업데이트 빈도가 낮은 정적 지식 베이스

가상 파일시스템이 유리한 경우

  • 문서가 이미 구조화되어 있고 (마크다운, API 문서 등)
  • 파일 경로나 디렉토리 구조 자체가 의미를 갖는 경우
  • 에이전트가 "탐색(navigation)" 패턴으로 정보를 찾는 경우
  • 세션 시작 속도와 비용이 중요한 프론트엔드 서비스

하이브리드 접근도 가능하다

Mintlify의 ChromaFs가 보여주는 건 양자택일이 아니다. ChromaFs 내부에서 `grep` 명령은 Chroma의 벡터 검색으로 후보 파일을 먼저 걸러내고, Redis 캐시를 거쳐 정규식으로 정밀 매칭하는 2단계 필터링을 쓴다. 벡터 검색의 장점은 살리면서도, 파일시스템이라는 직관적인 인터페이스를 에이전트에게 제공하는 셈이다.

실제로 나무숲 팀이 기업 사내 문서 시스템을 구축할 때도 비슷한 고민을 많이 한다. 클라이언트 문서가 이미 Notion이나 Confluence에 잘 정리되어 있으면, 무조건 청킹 → 임베딩 → 벡터DB 파이프라인을 태우는 것보다 기존 구조를 활용하는 편이 더 정확하고 빠른 경우가 많다.

실무 도입 시 체크리스트

기업에서 문서 AI 시스템을 설계할 때 이 사례를 참고한다면:

  1. 문서 구조 분석부터: 벡터DB에 넣기 전에, 기존 문서가 어떤 구조로 되어 있는지 먼저 파악하자. 구조화된 문서라면 그 구조 자체가 검색 성능을 높여준다.
  1. 에이전트 행동 패턴 정의: AI가 문서를 어떻게 찾을지 시나리오를 먼저 그려보자. 키워드 검색인지, 경로 탐색인지, 의미 기반 검색인지에 따라 최적 아키텍처가 달라진다.
  1. 비용 모델 시뮬레이션: 예상 트래픽 기준으로 RAG vs 대안 접근의 비용을 비교하자. Mintlify 사례처럼 트래픽이 크면 아키텍처 선택이 곧 비용 차이로 직결된다.
  1. 읽기 전용 여부 확인: 에이전트가 데이터를 수정할 필요가 없다면, 읽기 전용 설계로 보안과 성능을 동시에 잡을 수 있다.

정리하며

RAG는 강력한 도구지만 만능은 아니다. Mintlify의 가상 파일시스템 사례는 "내 데이터와 용도에 맞는 아키텍처를 선택하라"는 본질적인 메시지를 던진다. 460배 속도 개선과 비용 제로라는 숫자는 아키텍처 선택이 얼마나 큰 차이를 만드는지 보여주는 좋은 사례다.

AI 기반 사내 문서 시스템이나 검색 시스템 구축을 고려하고 있다면, 나무숲(TreeSoop)에서 최적의 아키텍처를 함께 설계해드립니다.

👉 카카오톡 문의하기