RAG(Retrieval-Augmented Generation, 검색 기반 응답 생성)는 AI가 문서에서 답을 찾아주는 방식으로, 요즘 AI 도구에 거의 기본으로 들어가 있는 구조예요. 근데 Mintlify라는 개발자 문서 플랫폼이 이 RAG를 버리고 가상 파일시스템으로 교체했다는 글을 읽었는데, 왜 그랬는지 들어보면 꽤 납득이 되거든요.
※ 이 글은 Mintlify 엔지니어링 블로그의 내용을 바탕으로 한국어로 재구성한 글입니다.
원문은 Mintlify 엔지니어링 블로그에 올라온 We replaced RAG with a virtual filesystem for our AI documentation assistant인데, 기술 글이지만 문제 정의가 명확해서 초보자도 흐름 따라가기 어렵지 않아요.
RAG vs 가상 파일시스템 — 핵심 차이
RAG의 한계, 어디서 막히나
RAG 방식은 질문이 들어오면 관련 텍스트 조각(chunk)을 검색해서 AI에게 넘겨주는 구조예요. 문서를 미리 잘게 잘라두고, 질문과 가장 비슷한 조각 몇 개를 골라서 보여주는 거죠.
문제는 답이 여러 페이지에 걸쳐 있을 때예요. 예를 들어 A 페이지에 개념이 있고, B 페이지에 실제 문법이 있다면, 조각 검색으로는 두 내용을 같이 가져오기가 어렵거든요. 또 정확한 코드 문법처럼 딱 맞는 표현이 필요한 경우, 검색 결과 상위 몇 개 안에 그게 없으면 그냥 틀린 답을 내거나 모른다고 해요.
Mintlify 팀이 겪은 것도 이거였어요. 어시스턴트가 문서 전체 구조를 훑으면서 답을 조합하는 게 아니라, 검색에 걸린 조각만 보고 답을 내다 보니 한계가 명확했던 거죠.
아이디어: 문서를 파일시스템처럼 탐색하게 만들기
Mintlify 팀이 주목한 건 AI 에이전트가 코드베이스를 탐색하는 방식이었어요. 개발자가 코드를 볼 때처럼 ls(디렉토리 목록 보기), cat(파일 내용 읽기), grep(특정 문자열 찾기), find(파일 위치 찾기) 같은 UNIX 명령어로 AI 에이전트가 직접 문서를 탐색하게 하면 어떨까 하는 발상이에요.
문서 페이지 하나를 파일 하나로, 섹션을 디렉토리 구조로 매핑하면 에이전트가 필요한 곳을 직접 찾아다닐 수 있다는 거죠. 검색 결과 상위 몇 개에 의존하는 게 아니라, 구조 전체를 탐색하는 방식으로요.
진짜 파일시스템 대신 가상 파일시스템을 만든 이유
가장 단순한 구현은 실제 파일시스템을 쓰는 거예요. 샌드박스(격리된 가상 환경)를 띄우고 GitHub 레포를 클론(복제)해서 에이전트가 그 안에서 돌아다니게 하는 방식이죠. 실제로 Mintlify 팀도 비동기 백그라운드 작업에는 이 방식을 쓰고 있어요.
근데 사용자가 앞에서 기다리는 프론트엔드 어시스턴트에는 이게 안 맞았어요. 세션 생성 시간(GitHub 클론 포함)이 p90 기준으로 약 46초였거든요. 로딩 스피너 보면서 46초 기다리는 건 사용자 입장에서 그냥 안 되는 수준이죠.
비용 문제도 있었어요. 원문에 나온 수치를 그대로 옮기면:
- 월 85만 건의 대화 처리
- 최소 사양(1 vCPU, 2GiB RAM, 5분 세션) 기준
- Daytona 샌드박스 단가($0.0504/h per vCPU, $0.0162/h per GiB RAM) 적용 시
- 연간 $70,000 이상
세션 시간이 길어지면 이 비용이 두 배로 뛰고요. 정적인 문서를 읽기만 하는데 마이크로 VM을 매번 띄우는 건 인프라 낭비가 너무 심했던 거예요.
세션 생성 시간 개선 결과
| 항목 | 기존 (실제 파일시스템) | 변경 후 (가상 파일시스템) |
|---|---|---|
| 세션 생성 시간 (p90) | 약 46초 | 약 100ms |
| 대화당 추가 컴퓨팅 비용 | 연간 $70,000 이상 | 0 (기존 인프라 재활용) |
▲ 가상 파일시스템 전환 후 성능·비용 변화
ChromaFs: 가상 파일시스템의 실제 구현
Mintlify 팀이 만든 건 ChromaFs예요. 이미 검색 인프라로 쓰고 있던 Chroma 데이터베이스(벡터 기반 문서 검색 DB) 위에 파일시스템 인터페이스를 얹은 거예요.
작동 방식은 이래요. 에이전트가 grep "API key" 같은 UNIX 명령어를 입력하면, ChromaFs가 그걸 가로채서 Chroma DB 쿼리로 변환해요. 에이전트 입장에서는 파일시스템을 탐색하는 것처럼 느끼지만, 실제로는 이미 인덱싱된 문서 DB를 조회하는 거죠.
이 구조의 핵심은 just-bash라는 오픈소스 도구예요. Vercel Labs가 만든 TypeScript 기반 bash 재구현체인데, grep, cat, ls, find, cd를 지원하고 IFileSystem이라는 인터페이스를 외부에 열어두고 있어요. ChromaFs는 이 인터페이스를 구현해서, 명령어 파싱이나 파이프 처리는 just-bash가 담당하고 실제 데이터 조회만 Chroma DB로 연결하는 구조예요.
새로운 인프라를 별도로 구축한 게 아니라 기존에 쓰던 것 위에 얹은 구조라서, 대화당 추가 컴퓨팅 비용이 사실상 0에 가까워요.
ChromaFs 구조 — 명령어에서 DB 쿼리까지
이 방식이 시사하는 것
RAG는 지금도 많은 AI 서비스의 기본 구조예요. 근데 이 사례가 보여주는 건, RAG가 항상 최선은 아니라는 거예요. 특히 문서 구조가 중요하거나, 정확한 문법/코드가 필요한 답변이 많다면 RAG보다 더 적합한 방식이 있을 수 있다는 거죠.
AI 에이전트에게 파일시스템처럼 탐색할 수 있는 인터페이스를 주면, 검색 결과 몇 개에 의존하지 않고 스스로 필요한 정보를 찾아다닐 수 있어요. 이게 가능한 이유는 grep이나 find 같은 명령어가 에이전트에게 이미 익숙한 인터페이스이기 때문이기도 하고요.
초보자 관점에서 이 글의 핵심을 정리하면 이렇게 돼요:
- RAG는 “관련 조각 검색 → AI에게 전달” 구조
- 가상 파일시스템은 “AI 에이전트가 직접 문서 구조를 탐색” 구조
- 성능과 비용을 함께 잡으려면 기존 인프라를 재활용하는 설계가 중요
- 실제 파일시스템 없이도 그 인터페이스만 구현하면 에이전트는 차이를 모른다
자주 묻는 질문
Q. RAG를 완전히 버려야 한다는 건가요?
아니에요. Mintlify 팀도 기존 Chroma DB 인프라는 그대로 두고, 그 위에 파일시스템 인터페이스를 추가한 거예요. RAG 자체를 부정하는 게 아니라, 사용 방식을 바꾼 거죠.
Q. ChromaFs는 오픈소스인가요?
원문에 오픈소스 여부는 명시되지 않았어요. just-bash는 Vercel Labs에서 공개한 도구이고, ChromaFs는 Mintlify가 자체 구현한 거예요.
Q. 이 방식은 Mintlify 같은 규모에서만 가능한가요?
원문 기준으로는 월 85만 건 대화 규모에서 비용 문제가 촉발됐어요. 소규모라면 기존 샌드박스 방식도 충분할 수 있어요. 다만 설계 아이디어 자체는 규모와 무관하게 참고할 만해요.
RAG 얘기는 요즘 어디서든 나오는데, 이렇게 실제 운영 비용과 성능 수치가 붙어있는 사례는 흔치 않아서 읽는 내내 구체적으로 느껴졌어요. 개념보다 숫자가 먼저 나오니까 이해가 훨씬 빠르더라고요.
썸네일 사진: Steve Johnson on Unsplash