AI 에이전트와 파일 시스템으로의 회귀

최근 IT 생태계를 지켜보며 가장 흥미로운 변화 중 하나를 꼽으라면, 단연 인공지능 에이전트들이 다시 '파일 시스템’이라는 고전적인 기술에 주목하기 시작했다는 점이다. 불과 얼마 전까지만 해도 모든 데이터는 벡터 데이터베이스에 들어가야 하고, 모든 지식은 그래프 형태로 구조화되어야 한다는 목소리가 높았다. 하지만 아이러니하게도 가장 진보된 AI 기술을 다루는 사람들이 지금 가장 열광하는 것은 우리가 수십 년 전부터 사용해 온 폴더와 파일의 구조다. 인프라와 데이터베이스의 역사는 돌고 돈다는 말이 있는데, 이번 파일 시스템의 부상은 단순한 회귀가 아니라 AI 시대에 맞는 새로운 정의라고 봐도 무방할 것 같다.

AI 에이전트 기술이 발전하면서 우리는 한 가지 흥미로운 사실을 발견하게 되었다. 라마인덱스(LlamaIndex) 같은 곳에서 '파일이면 충분하다(Files Are All You Need)'라는 제목의 글을 올리는가 하면, 랭체인(LangChain)에서도 에이전트가 파일 시스템을 이용해 컨텍스트 엔지니어링을 수행하는 방법에 대해 논의하기 시작했다. 오라클 같은 전통적인 데이터베이스 강자들도 에이전트 메모리를 구축할 때 데이터베이스와 파일 시스템을 비교하는 글을 내놓고 있다. 심지어 리액트의 창시자로 유명한 댄 아브라모프는 AT 프로토콜을 이용한 소셜 파일 시스템에 대해 이야기했고, 많은 개발자가 에이전트 전용 POSIX 파일 시스템 환경을 구축하는 데 열을 올리고 있다.

라마인덱스의 제리 리우가 지적한 지점은 매우 날카롭다. 과거에는 수백 개의 도구를 가진 하나의 에이전트를 만들려고 노력했다면, 이제는 파일 시스템에 접근할 수 있고 5개에서 10개 정도의 핵심 도구만 가진 에이전트로 방향이 바뀌고 있다. 파일 시스템과 코드 인터프리터, 그리고 웹 브라우저만 있다면 수백 개의 API 도구를 연결한 에이전트보다 훨씬 더 범용적이고 강력한 성능을 발휘한다는 것이다. 이는 안드레아 카파시가 클로드 코드를 언급하며 했던 말과도 일맥상통한다. 클로드 코드가 강력한 이유는 사용자의 컴퓨터 환경과 데이터, 그리고 그 맥락이 담긴 파일 시스템에서 직접 실행되기 때문이다. 웹 브라우저 속의 챗봇이 아니라, 내 컴퓨터 안에서 숨 쉬며 파일을 읽고 쓰는 실체적인 도구가 된 셈이다.

이런 흐름이 상업적으로도 의미가 있다는 증거는 명확하다. 현재 AI의 가장 큰 사용 사례 중 하나는 코딩 에이전트다. 앤스로픽이 수익성을 확보해가는 과정에서 클로드 코드가 큰 역할을 하고 있다는 분석이 지배적인데, 이것은 챗봇이 아니라 CLI 도구다. 즉, 사용자의 파일 시스템에 직접 접근해 파일을 읽고 수정하는 도구가 시장을 선도하고 있다는 뜻이다. 여기서 우리는 컨텍스트 윈도우와 메모리의 차이에 대해 깊게 고민해볼 필요가 있다. 인간의 심리학적 관점에서 메모리는 장기 저장과 선택적 회상, 그리고 불필요한 것을 잊는 능력을 포함한다. 하지만 현재 LLM의 컨텍스트 윈도우는 누군가 주기적으로 지워버리는 화이트보드와 비슷하다.

클로드 코드를 사용하다 보면 컨텍스트가 꽉 차서 압축된다는 알림을 볼 때가 있다. 이때 그동안 쌓아온 코드베이스의 맥락이나 작업 선호도, 이전의 의사결정들이 사라질까 봐 걱정하게 된다. 파일 시스템은 이 문제를 아주 원초적이고 확실하게 해결해준다. 그냥 적어두면 된다. 파일에 기록하고, 필요할 때 다시 읽는 것이다. 클로드의 CLAUDE.md 파일이나 커서(Cursor)의 채팅 히스토리 저장 방식이 바로 이런 것이다. 프로젝트에 대한 영구적인 맥락을 파일로 관리함으로써, 애플리케이션 간의 복잡한 API 조정 없이도 어떤 에이전트든 그 파일을 읽고 즉시 작업에 투입될 수 있다.

물론 모든 것이 파일 시스템으로 해결된다고 믿는 것은 위험하다. ETH 취리히에서 발표한 최근 논문을 보면 재미있는 결과가 나온다. 저장소 수준의 컨텍스트 파일이 실제로 코딩 에이전트의 작업 성공률을 높여주는지 실험했는데, 결과는 다소 의외였다. 컨텍스트 파일을 제공했을 때 오히려 작업 성공률이 낮아지고 추론 비용은 20% 이상 증가했다는 것이다. 에이전트들이 파일에 적힌 가이드라인을 너무 진지하게 받아들인 나머지, 불필요하게 더 많은 파일을 탐색하고 테스트를 실행하며 시간을 낭비했기 때문이다. 하지만 이 논문의 결론은 파일 시스템을 쓰지 말라는 것이 아니다. 컨텍스트 파일에는 아주 최소한의 요구사항과 제약 조건만 담아야 한다는 것이 핵심이다. 파일 시스템이라는 저장 계층이 문제가 아니라, 그 안에 무엇을 어떻게 담느냐의 문제라는 뜻이다.

이제 우리는 '파일 형식이 곧 API’가 되는 시대를 살고 있다. 현재는 CLAUDE.md, .cursorrules, copilot-instructions.md 등 각자 다른 이름을 사용하고 있지만, 점차 표준화의 움직임이 보인다. 앤스로픽은 에이전트 스킬(Agent Skills)이라는 오픈 표준을 발표했고, 마이크로소프트와 오픈AI, 깃허브 등이 이를 채택하고 있다. 특정 앱을 위한 플러그인을 개발하는 것이 아니라, 어떤 에이전트라도 이해할 수 있는 마크다운 형식의 스킬 파일을 만드는 방식이다. 이는 별도의 API 파트너십이나 표준화 기구의 복잡한 절차 없이도 이루어지는 상호운용성이다. 두 앱이 마크다운을 읽을 수 있고 공통된 파일 형식을 이해한다면, 협업은 이미 시작된 것이나 다름없다.

인프라의 역사에서도 비슷한 일이 있었다. 과거에는 저장 장치가 병목이었기 때문에 모든 계산이 저장 장치의 속도에 맞춰져 있었다. 하지만 연산 능력이 급격히 발달하면서 저장과 연산을 분리하는 아키텍처가 대세가 되었다. 지금 AI 에이전트의 병목은 모델의 지능이나 연산 속도가 아니라 바로 컨텍스트다. 모델은 이미 충분히 똑똑하지만 너무나 잘 잊어버린다. 파일 시스템은 에이전트가 실행되는 바로 그 지점에서 영구적인 컨텍스트를 관리할 수 있는 가장 효과적인 수단이 된다. 클라우드에 복잡하게 얽혀 있는 데이터베이스보다 내 컴퓨터의 로컬 파일이 에이전트에게는 훨씬 가깝고 확실한 기억 장치인 셈이다.

일각에서는 파일 시스템을 사용하는 것이 결국 그래프를 사용하는 것과 다를 바 없다고 조롱 섞인 말을 던지기도 한다. 실제로 파일 시스템은 디렉터리와 파일로 구성된 트리 구조이며, 이는 일종의 방향성 비순환 그래프(DAG)다. 에이전트가 명령어를 실행하고 파일을 읽으며 참조를 따라가는 과정은 그래프를 탐색하는 행위다. 오라클의 리치먼드가 지적했듯이, 파일 시스템은 '인터페이스’로서 승리하고 있고 데이터베이스는 '기질(Substrate)'로서 기능하고 있다. 대규모 시맨틱 검색이나 중복 제거, 동시 접속 관리가 필요해지면 결국 그 뒷단에는 데이터베이스 기술이 들어갈 수밖에 없다. 하지만 중요한 것은 인간과 에이전트가 소통하는 인터페이스가 다시 파일이라는 직관적인 도구로 돌아왔다는 점이다.

이 현상이 시사하는 바는 단순한 기술적 효율성 그 이상이다. 이것은 AI 시대의 개인용 컴퓨팅(Personal Computing)이 나아가야 할 방향을 보여준다. 나의 데이터, 나의 선호도, 나의 기술과 기억이 특정 서비스의 데이터베이스에 갇혀 있는 것이 아니라, 내가 소유하고 제어할 수 있는 파일 시스템 안에 존재한다는 것은 매우 강력한 의미를 갖는다. 내가 쓰는 도구가 바뀌더라도 나의 ‘aboutme.md’ 파일이나 스킬 파일들은 그대로 유지되며, 새로운 에이전트는 그 파일을 읽고 나를 즉시 파악할 수 있다. 서비스 제공자의 허락이나 API 키 없이도 나의 디지털 자산이 도구와 도구 사이를 자유롭게 이동하는 것이다.

비록 파편화의 위험이나 질 낮은 컨텍스트 파일로 인한 성능 저하 같은 숙제가 남아 있지만, 파일 시스템이 가진 보편성과 소유권의 가치는 대체하기 어렵다. 기술은 복잡해질수록 다시 단순한 것으로 돌아가려는 성질이 있다. 에이전트가 복잡한 데이터베이스 쿼리를 날리는 대신 단순한 텍스트 파일을 읽고 쓰는 모습은, 우리가 잊고 있었던 컴퓨팅의 본질을 일깨워준다. 댄 아브라모프의 말처럼 우리의 기억과 설계가 우리가 사용하는 소프트웨어보다 오래 살아남아야 한다는 가치에 가장 부합하는 기술은 바로 파일 시스템이다. 그것이 완벽한 기술이라서가 아니라, 이미 우리에게 속해 있고 우리가 가장 잘 다룰 수 있는 기술이기 때문이다.


관련 글

AI 에이전트와 파일 시스템으로의 회귀

https://futurecreator.cloud/posts/1475021047/

Author

Eric Han

Posted on

2026/03/11

Updated on

2026/03/12

Licensed under

Comments