에이전트 인프라 영역에서 흥미로운 일이 벌어지고 있다. 그리고 이는 대부분의 사람들이 예상했던 것과는 다르다. 지난 2년간, 에이전트에게 지식에 접근할 수 있는 능력을 부여하는 지배적인 패러다임은 검색 증강 생성(Retrieval-Augmented Generation, RAG)이었다. 문서를 임베딩하고 벡터 데이터베이스에 저장한 뒤, 추론 시점에 모델이 이를 쿼리하도록 하는 것이다. RAG는 작동했다. 충분히 괜찮았다. 하지만 "충분히 괜찮음"은 유통기한이 있고, 2026년에 그 유통기한이 만료되고 있다.
\n\n업계 전반에 걸쳐 새로운 패턴이 등장하고 있으며, 이는 여러 방향에서 동시에 수렴하고 있다. Mintlify는 전체 RAG 파이프라인을 가상 파일시스템으로 교체한 결과, 세션 생성 시간이 46초에서 100밀리초로 단축되었다 [1]. Turso는 AgentFS를 구축했는데, 이는 SQLite 기반 파일시스템으로 각 에이전트에게 독자적인 copy-on-write 샌드박스를 제공한다 [2]. 엔터프라이즈 콘텐츠 거대 기업 Box는 전체 플랫폼을 AI 에이전트를 위한 가상 파일시스템 레이어로 재편하고 있음을 발표했다 [3]. 그리고 ByteDance는 OpenViking을 오픈소스로 공개했는데, 이는 모든 에이전트 메모리, 리소스, 스킬을 계층적 파일시스템으로 조직화하는 컨텍스트 데이터베이스이다 [4].
\n\n이들은 틈새 실험이 아니다. 이는 근본적인 전환의 신호이다. 파일시스템은 에이전트 인지의 보편적 인터페이스가 되고 있으며, 데이터베이스는 조용히 그 기반이 되어가고 있다.
\n\nRAG는 2023년의 올바른 답이었다. 산더미 같은 문서, 제한된 컨텍스트 윈도우를 가진 모델, 그리고 쿼리 시점에 관련 청크를 끌어올릴 방법이 필요했다. 벡터 임베딩과 유사도 검색은 그 문제를 우아하게 해결했다.
\n\n하지만 에이전트는 챗봇이 아니다. 에이전트는 하나의 질문을 던지고 떠나지 않는다. 탐험한다. 파일을 읽고, 참조를 발견하고, 따라가고, 또 다른 파일을 읽고, 명령을 실행하고, 출력을 작성한다. 이는 검색(retrieval) 문제가 아니다. 탐색(navigation) 문제이다.
\n\nRAG 파이프라인은 이에 어려움을 겪는데, 세 가지 이유가 있다. 첫째, 설계상 상태를 유지하지 않는다(stateless). 모든 쿼리는 독립적이며, "방금 이 디렉터리를 보고 있었는데, 이제 인접한 파일을 보여줘"라는 개념이 없다. 둘째, 구조를 평탄화한다. 섹션, 페이지, 코드 예제의 명확한 계층 구조를 가진 문서 사이트가 익명의 512토큰 청크로 찢겨나가면서 조직적 맥락을 잃어버린다. 셋째, 규모가 커질수록 비용이 많이 든다. 임베딩 연산, 벡터 인덱스 유지보수, 재랭킹은 모두 코퍼스가 커짐에 따라 지연 시간과 비용이 누적된다.
\n\n파일시스템은 이 세 가지를 모두 해결한다. 본질적으로 상태를 유지한다(에이전트에게 작업 디렉터리가 있다). 구조를 보존한다(디렉터리, 하위 디렉터리, 파일). 그리고 연산이 단순하기 때문에 빠르다: ls, cat, grep, find. 이것들은 새로운 추상화가 아니다. 이들은 컴퓨팅 역사상 가장 많은 전투를 겪고 검증된 인터페이스이다.
이 순간이 중요한 이유는 파일시스템 패턴이 매우 다른 맥락에서 독립적으로 등장하고 있기 때문이다.
\n\nMintlify의 ChromaFs는 아마도 가장 교훈적인 예시일 것이다. Mintlify는 수천 개 기업의 문서 어시스턴트를 지원한다. 이들의 원래 아키텍처는 교과서적인 RAG였다. 문서를 청크로 나누고, 임베딩하고, 쿼리 시점에 검색하는 것이다. 이를 ChromaFs로 교체했을 때, 이 가상 파일시스템은 UNIX 명령을 가로채어 Chroma 데이터베이스 쿼리로 변환한다. 결과는 극적이었다. 세션 생성 시간이 46초에서 100밀리초로, 460배 개선되었다. 대화당 한계 비용은 $0.0137에서 사실상 제로로 떨어졌다 [1]. 핵심 통찰은 다음과 같다. 에이전트는 이미 파일시스템을 탐색하는 법을 알고 있다. 올바른 벡터 쿼리를 작성하는 법을 가르치는 것에 비해, cat /auth/oauth.mdx를 사용하도록 가르치는 것은 사소한 일이다.
Turso의 AgentFS는 다른 문제를 공략한다. 에이전트 격리(isolation)와 감사 가능성(auditability)이다. 각 에이전트는 copy-on-write 의미론을 가진 SQLite 기반 파일시스템을 독자적으로 갖는다. 호스트 파일시스템은 읽기 전용 베이스 레이어이고, 에이전트는 SQLite 델타 레이어에 기록한다. 모든 파일 연산, 도구 호출, 상태 변화가 기록된다. 전체 에이전트 런타임, 파일, 상태, 히스토리가 단일한 휴대용 SQLite 파일에 담긴다 [2]. 이는 단순한 파일시스템이 아니다. 감사 가능하고 재현 가능한 실행 환경이다.
\n\nBox의 엔터프라이즈 VFS는 전략적으로 가장 중요하다. Box의 CEO Aaron Levie는 명확히 밝혔다. 에이전트가 엔터프라이즈에서 지식 노력을 수행하려면 파일시스템이 필요하다고 [3]. 하지만 Box는 문자 그대로의 파일시스템을 제안하는 것이 아니다. 이들은 객체 스토리지, 관계형 데이터베이스, 또는 자체 콘텐츠 플랫폼으로 뒷받침될 수 있는 "동적 데이터 전달 계약(dynamic data delivery contract)"을 제안한다. 파일시스템은 인터페이스이고, 백킹 스토어는 데이터에 맞는 것이면 무엇이든 된다. Box의 전략이 흥미로운 점은 거버넌스 레이어이다. 권한, 감사 추적, 규정 준수 경계가 콘텐츠 플랫폼에서 에이전트로 자동으로 이어진다.
\n\nByteDance의 OpenViking은 이 패턴을 가장 멀리까지 확장한다. 이는 모든 에이전트 컨텍스트, 메모리, 리소스, 스킬, 지식을 표준 파일시스템 의미론을 사용하는 viking:// 프로토콜 아래 조직화한다. 에이전트는 ls와 find로 탐색한다. 하지만 영리한 부분은 계층적 접근 모델이다. 모든 컨텍스트 조각이 세 개의 레이어로 처리된다. L0는 빠른 검색을 위한 한 문장 요약이다. L1은 계획을 위한 핵심 정보가 담긴 개요이다. L2는 심층 읽기를 위한 전체 콘텐츠이다 [4]. 에이전트는 L0로 시작하여 더 많은 정보가 필요할 때 L1으로 파고들고, 상세한 작업을 할 때만 L2를 로드한다. LoCoMo 벤치마크에서 이는 토큰 소비를 2,460만 개에서 420만 개로 줄이면서 작업 완료율을 52%로 높였다 [4].
이 네 가지를 연결하는 패턴은 내가 VFS 이중성(VFS duality)이라 부르는 것이다. 파일시스템은 인터페이스로서 승리하고, 데이터베이스는 기판(substrate)으로서 승리한다. 이는 양자택일의 선택이 아니다. 계층적 아키텍처이다.
\n\n파일시스템이 인터페이스로서 승리하는 이유는 간단하다. LLM은 인터넷으로 학습되었고, 인터넷은 파일, 디렉터리, 경로, 명령줄 도구로 생각하는 개발자들에 의해 만들어졌다. 모델들은 코드베이스를 탐색하고, 파일을 읽고, 셸 명령을 실행하는 개발자들의 수십억 예시를 보았기 때문에 이러한 원시 요소들에 대해 유난히 능숙하다. 에이전트에게 파일시스템을 제공할 때, 당신은 그 훈련 데이터가 살아있는 곳에서 그것을 만나는 것이다.
\n\n데이터베이스가 기판으로서 승리하는 이유도 마찬가지로 명확하다. 에이전트 메모리를 공유하거나, 감사하거나, 여러 에이전트가 쿼리하거나, 동시성 하에서 신뢰할 수 있게 만들어야 하는 순간, 데이터베이스의 보장이 필요하다. ACID 트랜잭션, 접근 제어, 의미론적 검색(semantic search), 버전 히스토리: 이들은 데이터베이스가 수십 년 동안 해결해온 어려운 문제들이다. 이를 문자 그대로의 파일시스템 위에 재구현하는 것은 고통으로 가는 길이다.
\n\nVFS 패턴은 둘 다 제공한다. 에이전트는 파일과 디렉터리를 본다. 시스템은 테이블, 인덱스, 접근 제어 목록을 본다. ChromaFs는 모든 것을 Chroma에 저장하지만 파일로 노출한다. AgentFS는 모든 것을 SQLite에 저장하지만 POSIX 파일시스템으로 노출한다. OpenViking은 자체 저장 엔진을 사용하지만 viking:// 경로로 노출한다. Box는 엔터프라이즈 콘텐츠 플랫폼을 사용하지만 탐색 가능한 트리로 노출한다.
이에 대한 자연스러운 반론은 다음과 같다. 그냥 실제 파일시스템을 사용하면 되지 않는가? POSIX는 바로 거기에 있다. 모든 운영체제가 이를 탑재하고 있다. 왜 추상화 레이어를 추가하는가?
\n\n나는 이 질문에 경험적으로 답하고 싶었다. 그래서 markdownfs를 구축했다. 이는 Rust로 처음부터 만든 가상 파일시스템으로, 에이전트 워크로드 전용으로 설계되었다 [6]. 이는 전체 UNIX 스타일 명령어 집합(ls, cat, grep, find, chmod, chown)을 지원하고, 콘텐츠 주소 지정 저장소(content-addressable storage)를 사용하는 Git 스타일 버전 관리, 다중 사용자 권한 부여를 지원하며, 세 가지 접근 방법을 노출한다. CLI/REPL, HTTP/REST API, 그리고 Claude나 Cursor 같은 에이전트가 직접 연결할 수 있는 MCP 서버이다.
아키텍처는 단순하다. SHA-256 해싱을 사용하는 콘텐츠 주소 지정 blob 저장소로 뒷받침되는 인메모리 inode 테이블이며, 안전한 동시 접근을 위해 tokio::RwLock을 사용한다. 파일은 자동으로 중복 제거된다. 버전 관리는 Git과 동일한 커밋/되돌리기(commit/revert) 모델을 사용하지만 파일시스템 레벨에서 이루어진다. 지속성은 원자적인 bincode 스냅샷을 통해 처리된다.
표준 에이전트 연산(파일 생성, 읽기, 쓰기, 디렉터리 목록, grep, find, 이동, 복사, 삭제)에 대해 markdownfs를 네이티브 파일시스템과 벤치마킹했을 때, markdownfs는 전반적으로 평균 130배 빨랐다. 이유는 우연한 것이 아니라 구조적인 것이다. 인메모리 연산은 디스크 I/O를 완전히 제거한다. 콘텐츠 주소 지정 저장소는 중복 파일을 한 번만 저장한다. 제로 카피 읽기(zero-copy reads)는 에이전트가 직렬화 오버헤드 없이 데이터를 얻게 한다. 그리고 전체 파일시스템 상태가 단일 프로세스에 존재하기 때문에, 시스템 호출 경계를 넘나들 필요가 없다.
\n\n에이전트가 가장 빈번하게 수행하는 연산에 대해서는 비교가 특히 극명하다:
\n\n| 연산 | \nVFS가 우위인 이유 | \n
|---|---|
| 반복 읽기 (에이전트가 컨텍스트를 다시 읽는 경우) | \nIn-memory, zero-copy. 디스크 탐색(disk seeks) 없음, 페이지 캐시 미스(page cache misses) 없음. | \n
| 파일 전체 grep (에이전트가 패턴을 검색하는 경우) | \n모든 콘텐츠가 인메모리에 있음. 디렉터리 순회(directory traversal) 없음, 파일 핸들 관리(file handle management) 없음. | \n
| 빠른 파일 생성 (에이전트가 작업 산출물을 생성하는 경우) | \n파일시스템 저널링(filesystem journaling) 없음, 디스크상의 inode 할당(inode allocation) 없음, fsync 없음. | \n
| 디렉터리 목록 (에이전트가 구조를 탐색하는 경우) | \nBTreeMap lookup vs. readdir syscalls. | \n
하지만 성능이 진짜 논거는 아니다. 진짜 논거는 네이티브 파일시스템이 할 수 없는 것이다. POSIX 파일시스템은 의미론적 검색(semantic search)의 개념이 없다. 내장된 버전 관리가 없다(그건 Git이 필요하다). 계층적 접근 모델(tiered access model)이 없다(파일 전체를 얻거나 아예 못 얻거나 둘 중 하나다). 콘텐츠 중복 제거(content deduplication)가 없다. 에이전트 연산의 감사 추적(audit trail)이 없다. 그리고 결정적으로 MCP 인터페이스가 없다. 이는 에이전트가 생태계가 수렴하고 있는 표준 프로토콜을 통해 이에 접근할 수 없다는 뜻이다.
\n\nVFS는 단지 더 빠른 것이 아니다. 더 풍부한 원시 요소(richer primitive)이다. 익숙한 ls와 cat 인터페이스를 제공하면서, 에이전트가 실제로 필요로 하는 기능을 추가한다. 버전 관리, 권한, 검색, 중복 제거, 그리고 MCP나 HTTP를 통한 프로토콜 네이티브 접근이다.
분명히 하자면, RAG는 죽지 않았다. 벡터 검색은 에이전트가 진정으로 무엇을 찾고 있는지 모르는 퍼지(fuzzy)하고 의미론적인 쿼리에 여전히 가치가 있다. 하지만 솔직한 평가는 RAG가 과도하게 적용되었다는 것이다. 팀들이 RAG 파이프라인을 배포한 많은 사용 사례, 문서 검색, 코드베이스 탐색, 엔터프라이즈 지식 관리는 파일시스템 인터페이스가 더 적합하다.
\n\n증거는 놀랍다. Mintlify의 460배 가속은 RAG를 보강하는 것이 아니라 파일시스템으로 교체함으로써 얻어졌다 [1]. Letta의 연구에 따르면, 단순한 파일시스템 연산을 사용하는 에이전트는 메모리 벤치마크에서 74%의 정확도를 달성하여 전문 검색 도구와 경쟁력을 갖춘다. 그리고 에이전틱 키워드 검색(agentic keyword search) 방식은 벡터 데이터베이스 없이도 RAG 성능의 90% 이상을 달성할 수 있다 [5].
\n\n미래는 하이브리드일 가능성이 높다. 개방형 의미론적 검색에는 RAG를. 구조화된 탐색과 작업 실행에는 파일시스템을. 하지만 무게 중심은 파일시스템으로 이동하고 있으며, 전략적 함의는 상당하다.
\n\n에이전트 인프라를 구축하고 있다면, VFS 전략이 필요하다. 이유는 다음과 같다.
\n\nSaaS 기업을 위해서: Box가 주는 교훈은 파일시스템이 에이전트를 위한 통합 표면(integration surface)이 되어가고 있다는 것이다. 플랫폼의 콘텐츠가 파일시스템으로 탐색할 수 없다면, 에이전트는 당신을 우회할 것이다. 파일시스템과 유사한 인터페이스를 통해 데이터를 노출하는 SaaS 기업은 에이전트 워크플로우의 일부가 될 것이다. 그렇게 하지 않는 기업은 에이전트에게 보이지 않게 되고, 이는 사용자에게 보이지 않게 된다는 뜻이다.
\n\n인프라 벤더를 위해서: 데이터베이스는 사라지지 않는다. 파일시스템 아래로 이동할 뿐이다. 이는 사실 데이터베이스 기업에게 좋은 소식이다. Turso는 이를 이해하고 SQLite 위에 AgentFS를 구축했다. 에이전트가 하나씩 실행될 때마다 새로운 데이터베이스가 생성된다. 세상이 더 많은 에이전트를 실행할수록, 세상은 더 많은 데이터베이스를 필요로 한다. 하지만 데이터베이스는 파일시스템 추상화 뒤로 사라져야 한다.
\n\n엔터프라이즈를 위해서: 거버넌스 이야기가 중요하다. Box의 제안은 사실 파일시스템에 관한 것이 아니다. VFS 레이어를 통해 콘텐츠에 접근할 때, 이들의 권한 모델, 감사 추적, 규정 준수 인프라가 에이전트로 자동 확장된다는 사실에 관한 것이다 [3]. 이는 모든 CISO가 묻는 질문에 대한 답이다. "어떻게 에이전트가 우리 콘텐츠에 접근하도록 하면서도 보안 악몽을 만들지 않을 수 있는가?"
\n\n에이전트 인프라 스택은 명확한 단계를 거쳐 진화해왔다. 도구(MCP), 스킬, 컨텍스트 그래프. 가상 파일시스템은 이 흐름 속에서 이 셋 모두를 위한 전달 메커니즘(delivery mechanism)으로 자리 잡는다. MCP 도구는 파일시스템을 통해 호출된다. 스킬은 파일로 저장된다. 컨텍스트 그래프는 디렉터리 트리로 탐색된다. 파일시스템은 이 레이어들을 대체하지 않는다. 단일하고 익숙한 인터페이스 뒤에서 이들을 통일한다.
\n\n이것이 진짜 통찰이다. 파일시스템은 새로운 아이디어가 아니다. 이는 컴퓨팅에서 가장 오래된 추상화이다. 하지만 그것이 바로 에이전트에 작동하는 이유이다. 우리가 매 분기마다 새로운 패러다임을 발명하는 세상에서, 가장 강력한 움직임은 우리가 가장 검증된 인터페이스로 되돌아가 그 뒤에 현대적인 데이터베이스를 두는 것일지도 모른다.
\n\n이것을 이해하는 기업들, Mintlify, Turso, Box, ByteDance는 새로운 것을 만들고 있는 것이 아니다. 이들은 오래된 것을 인식하고 그것에 새로운 역할을 부여하고 있다.
\n\n참고 문헌:
\n\n[1] Mintlify. (2026, April 2). How we built a virtual filesystem for our Assistant. Mintlify Blog.
\n\n[2] Turso. (2026). The Missing Abstraction for AI Agents: The Agent Filesystem. Turso Blog.
\n\n\n\n[4] Volcengine. (2026). OpenViking: An open-source context database for AI Agents. GitHub.
\n\n\n\n", "source_hash": "sha256:b576661fe0d14759bc1b074608bc4208873bd898abf89987b9d7e9a126ba21b9", "model": "moonshotai/kimi-k2.6", "generated_at": "2026-08-07T07:23:31.794930+00:00" }