이거 봤어? 재밌는 거 있어서— AI 어시스턴트 개발팀이 RAG(검색 증강 생성) 대신 가상 파일 시스템을 도입했다는 기사다. `mintlify.com` 블로그에 올라온 이 글은 기존 RAG가 수많은 한계를 가지고 있었음을 솔직히 고백한다. 예를 들어, 답변이 여러 페이지에 걸쳐 있거나 정확한 구문이 필요할 때 RAG는 길을 잃는다는 것이다. 이들이 선택한 `ChromaFs`라는 가상 파일 시스템은 세션 생성 시간을 기존 46초에서 단 100밀리초로 단축하며, 월 85만 건의 대화에도 추가 컴퓨팅 비용이 거의 들지 않는다는 놀라운 수치를 보여준다. 이는 AI 에이전트가 단순히 정보를 "검색"하는 것을 넘어, 마치 개발자가 코드를 탐색하듯 문서를 "구조적으로 탐색"하게 만드는 새로운 접근 방식의 가능성을 열어준다.

RAG의 한계를 넘어선 구조적 탐색

그동안 AI 어시스턴트나 챗봇을 개발하면서 RAG는 거의 표준처럼 여겨져 왔다. 거대 언어 모델(LLM)의 환각 현상을 줄이고 최신 정보를 제공하기 위한 가장 효과적인 방법으로 꼽혔다. 하지만 `mintlify.com` 기사는 RAG가 가진 본질적인 한계를 명확히 지적한다. "에이전트가 단지 쿼리와 일치하는 텍스트 덩어리만 검색할 수 있다면, 답변이 여러 페이지에 걸쳐 있거나 사용자가 상위 K개 결과에 없는 정확한 구문을 필요로 할 때 꼼짝없이 갇힌다."는 대목은 우리에게 익숙한 RAG의 답답함을 그대로 보여준다.

이들은 문제의 해결책을 "파일 시스템"에서 찾았다. 에이전트가 `grep`, `cat`, `ls`, `find`와 같은 유닉스 명령어를 사용할 수 있다면, 문서 페이지를 파일로, 섹션을 디렉터리로 취급하여 원하는 정보를 정확하게 검색하고 전체 페이지를 읽으며 문서 구조를 직접 탐색할 수 있다는 아이디어다. 물론 실제 파일 시스템을 에이전트에 통째로 제공하는 것은 막대한 비용과 지연 시간을 초래한다. 그래서 이들은 기존 Chroma 데이터베이스 위에 `ChromaFs`라는 가상 파일 시스템을 구축했다. Vercel Labs의 `just-bash`를 기반으로 `ChromaFs`는 유닉스 명령어를 가로채 데이터베이스 쿼리로 변환한다. 이 덕분에 에이전트는 마치 실제 파일 시스템을 다루는 듯한 착각 속에서 문서를 탐색할 수 있으며, 실제로는 기존 인프라를 재사용하여 비용을 절감하는 이점을 얻는다.

이것이 우리에게 던지는 메시지는 분명하다. 단순히 임베딩 기반의 시맨틱 검색만으로는 AI 에이전트가 복잡한 정보를 이해하고 활용하는 데 한계가 있다는 점이다. 사람들은 어떤 정보를 찾을 때 키워드 검색만 하는 것이 아니라, 목차를 보거나 특정 섹션을 넘겨보고, 전체 문맥을 읽어 내려가는 등 구조적인 탐색 과정을 거친다. 우리의 AI 에이전트도 그런 "사서"와 같은 탐색 능력을 가져야 한다는 이야기다. 만약 당신이 AI 문서 어시스턴트를 개발하고 있다면, 단순히 검색 품질 향상에만 집중할 것이 아니라, 에이전트가 문서를 탐색하는 "방식" 자체를 재고해야 한다. 기존 RAG 워크플로우를 보완하거나 대체할 수 있는 구조적 탐색 도구를 직접 구축하거나, 유사한 철학을 가진 오픈소스 라이브러리를 탐색해 보는 것이 오늘 당장 시도해 볼 수 있는 구체적인 행동이다.

AI 에이전트의 자기 수정 능력: 단순 모델 성능 이상의 가치

구조적 탐색의 중요성과 함께 `furtherai.com` 기사는 AI 에이전트의 또 다른 지능을 강조한다. 바로 "자기 수정" 능력이다. FurtherAI는 상업 보험 분야에서 가장 까다로운 문서 중 하나인 손실 발생 보고서(loss runs)에서 데이터를 추출하는 AI 에이전트를 개발하면서, 추출 모델 자체를 개선하는 것보다 에이전트가 스스로 오류를 확인하고 수정하도록 만드는 데 집중했다. 그 결과, 로우 카운트(row count) 정확도를 80%에서 95%로 끌어올렸다.

상업 보험 손실 발생 보고서는 그야말로 난이도 최상의 문제다. 수백 가지 형식의 문서는 물론, 200페이지가 넘는 문서에 데이터가 여러 섹션에 흩어져 있고, 동일한 보험 청구 번호가 여러 테이블에 나타나며, 때로는 공백 셀이 "위와 동일"을 의미하는 등 수많은 예외 상황과 암묵적 규칙들이 존재한다. OCR(광학 문자 인식)은 병목 현상이 아니었다. 진짜 문제는 문서가 "무엇을 소통하려 하는지"를 에이전트가 추론해야 한다는 것이었다.

FurtherAI의 접근 방식은 LLM 기반 에이전트 개발에서 중요한 전환점을 제시한다. 우리는 종종 "더 좋은" LLM 모델이나 "더 정교한" 프롬프트 엔지니어링이 모든 것을 해결할 것이라 기대한다. 하지만 이 기사는 복잡한 실세계 문제에서는 기본 추출 모델의 성능 한계를 인정하고, 에이전트가 스스로 데이터를 검증하고, 여러 출처를 교차 확인하고, 문서의 문맥과 구조를 추론하여 잘못된 부분을 고치는 "지능형 워크플로우"를 설계하는 것이 훨씬 효과적임을 보여준다.

당신이 만약 복잡하고 비정형적인 데이터 추출 문제에 직면해 있다면, 추출 모델 자체의 성능 개선에만 매달릴 것이 아니라 에이전트가 자신의 출력을 어떻게 검증하고 수정할 수 있을지 고민해야 한다. 예를 들어, 추출된 데이터에 대한 유효성 검사 규칙을 LLM에 주입하거나, 다른 LLM 에이전트에게 "이 추출 결과에 오류가 없는지 확인해 봐"라고 지시하는 등 다단계의 자기 수정 메커니즘을 설계하는 것이 좋은 시작점이 될 수 있다. 이는 단순한 데이터 추출을 넘어, 데이터의 "신뢰성"을 확보하는 데 필수적인 접근 방식이다.

로컬 AI 배포의 현실: 성능과 실용성의 균형

한편, `gist.github.com`에 올라온 Ollama와 Gemma 4 8B 모델을 Mac mini에서 자동으로 시작하고 실행하는 설정 가이드는 AI 에이전트를 실제 환경에 배포할 때 우리가 고려해야 할 실용적인 제약을 보여준다. 특히 Gemma 4의 26B 모델을 Mac mini에 올렸을 때 발생했던 문제가 인상적이다. 원문에서는 26B 모델이 "Mac mini의 24GB 통합 메모리 거의 전부를 소모하여 시스템 반응이 거의 없었고 동시 요청 시 잦은 스와핑을 유발했다"고 설명한다. 결국 8B 버전으로 내려 사용해야 비로소 "여유롭게 편안하게 작동한다"는 결론에 도달한다.

이것은 우리가 AI를 활용하는 데 있어 "이상"과 "현실" 사이의 균형점을 찾아야 함을 명확히 보여준다. 최신, 최대의 모델이 항상 최적의 선택은 아니라는 것이다. 특히 로컬 환경에서 LLM을 구동할 때는 하드웨어의 물리적 제약이 곧 사용자 경험의 한계로 이어진다. 26B 모델이 더 "똑똑할" 수는 있어도, 시스템 전체를 느리게 만들고 스와핑을 유발한다면 그 가치는 현저히 떨어진다.

당신이 로컬 환경에서 AI 모델을 개발하거나 배포하려 한다면, 단순히 모델의 성능 지표만 보고 선택하지 말아야 한다. 실제 당신의 하드웨어에서 얼마나 원활하게 작동하는지, 응답 시간은 어떤지, 다른 작업에 영향을 미 주지 않는지 등 "실용적인 관점"에서 벤치마킹을 수행해야 한다. 초기 단계에서는 `ollama pull gemma4`와 같이 작고 양자화된 모델부터 시작하여 점차 모델 크기를 늘려가며 최적의 균형점을 찾는 것이 현명한 접근 방식이다. 쾌적한 사용자 경험은 모델의 순수한 성능 지표만큼이나 중요한 고려사항이 된다.

오늘 살펴본 세 가지 기사는 AI의 발전 방향이 단순히 "더 큰 모델"이나 "더 나은 임베딩"만을 향하는 것이 아님을 시사한다. 오히려 AI 에이전트가 정보를 탐색하고, 복잡한 문제를 해결하며, 제한된 자원 속에서 효율적으로 작동하는 "방식"과 "지능형 워크플로우"에 대한 고민이 더 중요해지고 있다. AI가 우리 일상과 업무에 깊숙이 들어오는 오늘, 우리는 어떤 방식으로 에이전트의 지능을 설계하고 그 잠재력을 최대한 끌어낼 수 있을까?

참고

  1. We replaced RAG with a virtual filesystem for our AI documentation assistant. Mintlify Blog. https://www.mintlify.com/blog/how-we-built-a-virtual-filesystem-for-our-assistant
  2. The Hardest Document Extraction Problem in Insurance. FurtherAI Engineering Blogs. https://www.furtherai.com/engineering-blogs/hardest-document-extraction-problem-in-insurance
  3. April 2026 TLDR Setup for Ollama and Gemma 4 26B on a Mac mini. GitHub Gist. https://gist.github.com/greenstevester/fc49b4e60a4fef9effc79066c1033ae5