요즘 AI 에이전트 생태계에서 뜬금없이 주목받는 기술이 있습니다. 바로 파일시스템입니다.
LlamaIndex는 “Files Are All You Need”를 발표했고, LangChain은 에이전트가 파일시스템을 컨텍스트 엔지니어링에 활용하는 방법을 다뤘습니다. Oracle, Dan Abramov도 비슷한 맥락의 글을 냈죠. 전 세계 개발자 커뮤니티가 1970년대에 설계된 기술에 새삼 열광하는 이유가 뭘까요?
최근 나온 “Filesystems are having a moment”라는 글이 이 흐름을 잘 정리하고 있습니다. Weaviate(벡터 DB 회사) 출신 개발자가 썼다는 점이 흥미롭죠. 벡터 DB를 팔던 사람이 “파일로 돌아가자”는 이야기를 하는 셈이니까요. 오늘은 이 글의 핵심 주장을 살펴보겠습니다.
왜 지금 파일시스템인가 — 컨텍스트가 병목이 됐다
원글의 핵심 논지는 하나입니다. “AI 에이전트의 현재 병목은 모델 성능이나 컴퓨트가 아니라, 컨텍스트다.”
Claude Code를 써본 분이라면 익숙한 장면이 있을 겁니다. “context left until auto-compact” 알림이 슬금슬금 줄어드는 것. 에이전트가 그동안 쌓아올린 코드베이스 이해, 내가 내린 결정들, 작업 히스토리 — 이것들이 컨텍스트 한계에 다다르면 압축되거나 그냥 사라집니다.
LLM의 컨텍스트 윈도우는 인간의 기억과 다릅니다. 인간은 중요한 정보를 장기 기억으로 넘기고, 불필요한 것은 잊고, 필요할 때 선택적으로 떠올립니다. 컨텍스트 윈도우는 그 어느 것도 아닙니다. 누군가 계속 지우는 화이트보드에 가깝습니다.
파일시스템은 이 문제를 가장 단순하게 해결합니다. 기록을 파일에 쓰고, 필요할 때 읽으면 됩니다. CLAUDE.md가 프로젝트 맥락을 유지하고, Cursor가 채팅 히스토리를 검색 가능한 파일로 저장하고, aboutme.md가 사용자의 선호와 작업 스타일을 어디서든 들고 다닐 수 있는 신원 기술자 역할을 하는 것처럼요.
Karpathy도 이와 비슷한 관찰을 했습니다. Claude Code가 잘 작동하는 이유는 그것이 사용자의 컴퓨터 위에서, 사용자의 환경과 데이터와 함께 실행되기 때문이라고요. 에이전트가 힘을 발휘하려면 데이터가 있는 곳에 있어야 한다는 뜻이기도 합니다.
ETH Zürich 논문이 던진 찬물 — 파일이 항상 도움이 되진 않는다
그런데 원글 자체가 흥미로운 역설을 인정합니다. ETH Zürich의 최근 논문이 코딩 에이전트를 대상으로 컨텍스트 파일의 효과를 실제로 측정해봤더니, 결과가 반직관적이었습니다.
컨텍스트 파일을 받은 에이전트는 더 많이 탐색하고, 더 많은 테스트를 돌리고, 더 많은 파일을 뒤졌습니다. 그런데 정작 수정이 필요한 코드에 도달하는 건 더 느렸습니다. 파일이 에이전트에게 일종의 체크리스트로 작동하면서 오히려 탐색을 과도하게 만든 것입니다. 태스크 성공률은 낮아지고, 추론 비용은 20% 이상 높아졌습니다.
논문의 결론은 “파일을 쓰지 말라”가 아닙니다. 에이전트가 스스로 발견할 수 없는 최소한의 정보만 담아야 한다는 것입니다. “uv를 패키지 관리에 쓸 것”, “테스트는 반드시 --no-cache로 실행” 같은 비직관적 제약만요. “이 서비스는 repository 패턴을 사용합니다” 같은 내용은 개발자에게는 당연히 유용해 보이지만, 모델에게는 노이즈일 수 있습니다.
결국 CLAUDE.md를 2,000단어짜리 온보딩 문서처럼 쓰는 관행이 문제인 것이지, 파일시스템이라는 개념 자체가 나쁜 건 아닙니다. 더 근본적인 지적도 있습니다. 에이전트가 맥락 파일을 필요로 한다면, 그건 코드베이스 구조 자체가 혼란스럽다는 신호이기도 합니다. 디렉터리 구조가 직관적이라면, 에이전트에게 굳이 설명할 필요가 없으니까요.
파일 포맷이 API다 — 그런데 어떤 파일?
파일시스템 기반 컨텍스트의 방향 자체는 큰 이견이 없습니다. 문제는 파편화입니다. 지금은 CLAUDE.md, AGENTS.md, copilot-instructions.md, .cursorrules가 공존하고, 표준이 없습니다.
원글은 이 상황에서 AT Protocol의 설계 철학을 빌려옵니다. AT Protocol은 앱들이 “포스트”가 무엇인지 합의할 필요 없이, 도메인 기반 네임스페이스만으로 충돌을 막습니다. 표준화가 아니라 공존의 전략입니다. 에이전트 컨텍스트 파일도 하나의 포맷으로 수렴할 필요 없이, 충돌하지 않고 공존하면 된다는 시각이죠.
실제로 Anthropic의 SKILL.md 포맷은 Microsoft, OpenAI, GitHub, Cursor 등이 채택하면서 사실상 공용 표준으로 자리잡고 있습니다. Claude Code용으로 작성한 스킬이 Codex와 Copilot에서도 작동한다면, 파일 포맷이 곧 API인 셈입니다. 플랫폼 간 파트너십 계약이나 표준화 회의 없이도요.
다만 개방 포맷의 역사는 문서상으로 승리하고 실제로 실패한 표준으로 가득합니다. 기업들에게는 자사 컨텍스트 파일을 미묘하게 다르게 만들어 전환 비용을 유지할 유인이 항상 있습니다. 지금 파편화된 파일들이 공존하는 현실 자체가 그 증거이기도 합니다.
사실 이 아이디어, 40년 전에 이미 있었다
“파일 위의 텍스트가 가장 강력한 인터페이스다”라는 논지는 새로운 이야기가 아닙니다. Bell Labs의 Plan 9이 이미 이 철학을 바탕으로 설계된 OS였습니다. 모든 것을 파일로 추상화하고, 프로세스도 네트워크도 파일 인터페이스로 다루는 구조. 너무 일찍 나왔을 뿐이라는 말이 나오는 이유가 있습니다.
기술적으로도 몇 가지 짚어볼 부분이 있습니다. 원글은 파일시스템을 “DAG(방향성 비순환 그래프)”라고 표현했는데, 엄밀히는 심볼릭 링크로 사이클이 생길 수 있어 순환 그래프에 가깝습니다. “그래프를 쓰면서 그래프가 아니라고 하는 사람들”을 지적한 원글의 논지를 스스로 뒷받침하는 셈이기도 하죠.
또 자주 간과되는 사실이 있습니다. NTFS는 겉으로는 파일 트리처럼 보이지만 내부적으로는 MFT라는 B+트리 기반 데이터베이스로 동작합니다. “파일시스템은 인터페이스로 승리하고, 데이터베이스는 기반으로 승리한다”는 원글의 표현이 사실 현재 OS에서도 이미 구현된 방식입니다.
파일이 실제로 유용하려면 검색이 가능해야 합니다. 규모가 커지면 파일 탐색은 금방 한계에 부딪힙니다. 코드베이스는 DRY 원칙 덕분에 자연스럽게 잘 정돈된 그래프 구조가 형성되지만, 비코드 데이터는 그렇지 않습니다. 코딩 에이전트에게 파일시스템이 잘 맞는다고 해서 다른 도메인에도 똑같이 적용되는 건 아닐 수 있습니다.
결국 파일 대 데이터베이스가 아니다
이 논의를 한 줄로 정리하면 이렇습니다. 파일시스템과 데이터베이스는 경쟁 관계가 아닙니다. 레이어가 다릅니다.
파일시스템이 주목받는 이유는 그것이 기술적으로 가장 뛰어나서가 아닙니다. LLM이 이미 파일을 이해하고, 인간도 파일을 이해하고, 특정 플랫폼에 종속되지 않기 때문입니다. 그리고 무엇보다 — 이미 사용자의 것이기 때문입니다.
동시 접근, 대규모 시맨틱 검색, 트랜잭션 보장이 필요해지는 순간, 파일 뒤에는 어차피 데이터베이스가 필요합니다. 이건 파일시스템의 실패가 아니라 역할 분담입니다. 파일이 인간과 에이전트가 상호작용하는 인터페이스가 되고, 그 아래를 데이터베이스가 받쳐주는 구조가 자연스럽게 형성되고 있습니다.
다만 이상과 현실 사이에는 항상 마찰이 있습니다. “모든 데이터를 파일로 소유하자”는 비전은 아름답지만, 실제로 그 파일들을 관리하고 검색하고 버전을 유지하는 건 복잡한 일입니다. 지금도 사람들은 대부분 CLAUDE.md를 온보딩 문서처럼 써서 오히려 에이전트를 느리게 만들고 있습니다.
파일시스템이 “AI 시대의 개방형 인터페이스”가 되려면, 기술보다 습관과 표준이 먼저 따라와야 할지도 모릅니다.
참고 글