파일시스템이 주목받는 이유

(madalitso.me)

14P by GN⁺ 23시간전 | ★ favorite | 댓글 1개

최근 AI 에이전트 생태계에서 파일시스템이 다시 주목받으며, 데이터베이스와는 다른 지속적 맥락 관리 수단으로 부상
LLM의 컨텍스트 윈도우는 지속적 기억이 아닌 지워지는 화이트보드에 가까우며, 파일시스템은 이를 가장 단순하게 해결하는 영속적 저장 수단
Claude Code, Cursor 등은 파일 기반 컨텍스트 저장을 통해 장기 기억을 구현하며, CLAUDE.md, aboutme.md 같은 파일이 에이전트의 정체성과 환경 정보를 담는 역할 수행
파일시스템 기반 컨텍스트 관리가 핵심 화두로 부상하며, LlamaIndex·LangChain·Oracle·Archil 등 주요 기업들이 관련 글과 제품을 잇달아 발표
CLAUDE.md, AGENTS.md, .cursorrules 등 에이전트 컨텍스트 파일이 난립하는 가운데, Anthropic의 Agent Skills(SKILL.md) 포맷이 Microsoft·OpenAI·GitHub·Cursor 등에 채택되며 상호운용성을 확보
ETH Zürich 연구에 따르면 컨텍스트 파일이 오히려 태스크 성공률을 낮추고 추론 비용을 20% 이상 증가시킬 수 있어, 최소한의 요구사항만 기술해야 함
파일은 특정 앱에 종속되지 않으며, AI 에이전트 시대에 도구 간 전환·워크플로 결합·연속성 유지를 가능하게 하는 개방형 인터페이스로 자리 잡고 있음

Everyone is talking about files : 모든 곳에서 파일을 이야기하고 있음

LlamaIndex는 "Files Are All You Need"를 발표했고, LangChain은 에이전트가 파일시스템을 컨텍스트 엔지니어링에 활용하는 방법 을 다룸
Oracle(네 그 오라클이요!)은 파일시스템과 데이터베이스의 에이전트 메모리 관리 비교 글을 게시했으며, Dan Abramov는 AT Protocol 기반 소셜 파일시스템을 제안
Archil은 에이전트가 POSIX 파일시스템을 원하기 때문에 클라우드 볼륨을 구축 중
LlamaIndex의 Jerry Liu는 "수백 개 도구를 가진 에이전트 하나" 대신, 파일시스템과 5~10개 도구만으로 100개 이상의 MCP 도구를 가진 에이전트보다 더 범용적일 수 있다고 주장
Karpathy는 Claude Code가 작동하는 이유를 사용자의 컴퓨터·환경·데이터·컨텍스트 위에서 직접 실행되기 때문이라고 지적하며, OpenAI가 클라우드 컨테이너 배포에 집중한 것은 잘못된 방향이었다고 평가
현재 코딩 에이전트가 실질적 AI 활용 사례의 대부분을 차지하며, Anthropic은 CLI 도구인 Claude Code가 수익의 상당 부분을 견인하면서 흑자 근접 중

컨텍스트 윈도우는 기억이 아님

인간의 기억은 장기 저장·선택적 회상·불필요한 정보 망각 기능을 포함하지만, LLM의 컨텍스트 윈도우는 계속 지워지는 화이트보드에 가까움
Claude Code 사용 시 "context left until auto-compact" 알림이 다가오면, 에이전트가 축적한 코드베이스·선호도·결정 사항 등의 컨텍스트가 압축되거나 소실
파일시스템은 이를 가장 단순한 방식으로 해결: 기록을 파일에 쓰고, 필요할 때 다시 읽음
- CLAUDE.md는 프로젝트에 대한 영속적 컨텍스트 제공
- Cursor는 과거 채팅 기록을 검색 가능한 파일로 저장
- aboutme.md 파일은 선호도·기술·작업 스타일을 담은 이동 가능한 신원 기술자 역할을 하며, API 조율 없이 앱 간 이동 가능

ETH Zürich 연구: 컨텍스트 파일의 역설

ETH Zürich의 최근 논문은 리포지토리 수준의 컨텍스트 파일이 실제로 코딩 에이전트의 태스크 완수에 도움이 되는지 평가
결과는 반직관적: 여러 에이전트와 모델에 걸쳐 컨텍스트 파일이 태스크 성공률을 오히려 낮추고, 추론 비용은 20% 이상 증가
- 컨텍스트 파일을 받은 에이전트는 더 넓게 탐색하고, 더 많은 테스트를 실행하고, 더 많은 파일을 순회했지만, 정작 수정이 필요한 코드에 도달하는 것은 지연
- 파일이 에이전트가 지나치게 진지하게 따르는 체크리스트처럼 작동
논문의 결론은 "컨텍스트 파일을 쓰지 말라"가 아니라, 불필요한 요구사항이 태스크를 어렵게 만들며 컨텍스트 파일은 최소 요구사항만 기술해야 함
문제는 파일시스템의 영속 계층 자체가 아니라, CLAUDE.md를 2,000단어짜리 온보딩 문서처럼 작성하는 관행

파일 포맷이 곧 API — 그러나 어떤 파일?

현재 CLAUDE.md, AGENTS.md, copilot-instructions.md, .cursorrules 등이 공존하며, 에이전트에 영속적 파일시스템 기반 컨텍스트가 필요하다는 점은 합의되었으나 파일 이름과 내용 형식은 미합의
Dan Abramov의 소셜 파일시스템 글에서 핵심 설계: AT Protocol은 사용자 데이터를 개인 리포지토리 내 파일로 취급하며, 앱들이 "포스트"가 무엇인지 합의할 필요 없이 도메인 네임 기반 네임스페이스로 충돌 방지
- 모든 앱의 데이터베이스는 파생 데이터, 즉 모든 사용자 폴더의 캐시된 구체화 뷰가 됨
Anthropic은 Agent Skills를 오픈 표준으로 발표: SKILL.md 포맷을 Microsoft, OpenAI, Atlassian, GitHub, Cursor가 채택
- Claude Code용으로 작성한 스킬이 Codex, Copilot에서도 작동 — 파일 포맷이 곧 API
NanoClaw는 경량 개인 AI 어시스턴트 프레임워크로, "기능 대신 스킬" 모델 채택
- Telegram 지원이 필요하면 Telegram 모듈이 아닌 /add-telegram 스킬(마크다운 파일)이 Claude Code에 통합 방법을 가르침
- 스킬은 파일이므로 이동 가능하고, 감사 가능하며, 조합 가능 — MCP 서버나 플러그인 마켓플레이스 불필요
이것이 조율 없는 상호운용성: 두 앱이 마크다운을 읽을 수 있으면 컨텍스트 공유가 가능하고, SKILL.md 포맷을 이해하면 기능 공유가 가능하며, 파트너십 계약이나 표준화 기구 회의 없이 파일 포맷 자체가 조율 역할 수행

병목의 이동

전통적 데이터 아키텍처는 스토리지가 병목이라는 가정 하에 설계되었으나, 처리 능력이 스토리지 I/O를 앞지르면서 스토리지와 컴퓨트의 분리(S3 + 임시 컴퓨트 클러스터)로 패러다임 전환
AI 에이전트에서도 유사한 현상 발생: 병목은 모델 성능이나 컴퓨트가 아닌 컨텍스트
- 모델은 충분히 똑똑하지만 건망증이 있음
- 파일시스템은 에이전트가 실행되는 바로 그 지점(개발자의 머신, 환경, 데이터가 이미 존재하는 곳)에서 영속적 컨텍스트를 관리하는 가장 효과적인 방법

파일시스템은 이미 그래프

트위터에서 "파일시스템을 쓰면서 에이전트에 그래프가 필요 없다고 말하는 사람들은 그래프를 쓰고 있다는 사실을 부정하는 것"이라는 지적
- 파일시스템은 디렉터리·하위디렉터리·파일로 구성된 트리 구조, 즉 방향성 비순환 그래프(DAG)
- 에이전트가 ls, grep, 파일 읽기, 참조 따라가기를 할 때 이미 그래프를 순회 중
Oracle 글의 Richmond는 가장 날카로운 구분 제시: 파일시스템은 인터페이스로서 승리하고, 데이터베이스는 기반 계층으로서 승리
- 동시 접근, 대규모 시맨틱 검색, 중복 제거, 최신성 가중치 등이 필요해지면 결국 자체 인덱스를 구축하게 되며, 이는 사실상 데이터베이스
파일 인터페이스는 보편적이고 LLM이 이미 이해하기 때문에 강력하고, 데이터베이스 기반 계층은 실제 운영에 필요한 보장을 제공하기 때문에 강력
미래는 파일 대 데이터베이스가 아니라, 파일이 인간과 에이전트가 상호작용하는 인터페이스이고 그 아래에 유즈케이스에 맞는 기반 계층이 위치하는 구조

이것은 개인 컴퓨팅의 재정의

파일시스템은 AI 시대에 개인 컴퓨팅의 의미를 재정의할 수 있음
- 데이터·컨텍스트·선호도·스킬·기억이 사용자가 소유한 포맷으로 존재하고, 어떤 에이전트든 읽을 수 있으며, 특정 애플리케이션에 잠기지 않는 구조
- aboutme.md는 오늘의 OpenClaw/NanoClaw에서도, 내일의 새 도구에서도 작동
- 스킬 파일은 이동 가능하고, 프로젝트 컨텍스트는 도구를 넘어 유지
이것은 모든 것이 폐쇄적 SaaS 앱과 독점 데이터베이스로 이동하기 전, 개인 컴퓨팅이 원래 지향하던 모습
- 파일은 원래의 개방 프로토콜이며, AI 에이전트가 컴퓨팅의 주요 인터페이스가 되면서 도구 전환·워크플로 결합·애플리케이션 간 연속성 유지를 누구의 허가 없이도 가능하게 하는 상호운용 계층
다만 이상주의적 측면 존재: 개방 포맷의 역사에는 문서상으로 승리하고 실제로는 실패한 표준이 다수
- 기업들은 자사 컨텍스트 파일을 미묘하게 다르게 만들어 전환 비용을 유지할 유인이 강함
- CLAUDE.md와 AGENTS.md와 .cursorrules가 하나의 범용 포맷이 아닌 공존 상태인 것 자체가 파편화가 기본값임을 보여줌
- ETH Zürich 논문은 포맷이 존재하더라도 좋은 컨텍스트 파일 작성이 어렵고, 나쁜 컨텍스트 파일은 없는 것보다 못하다는 점을 상기
Dan Abramov의 핵심 메시지:

우리의 기억·생각·디자인은 그것을 만든 소프트웨어보다 오래 살아남아야 함
- 이것은 기술적 주장이 아닌 가치의 문제이며, 파일시스템은 최고의 기술이어서가 아니라 이미 사용자에게 속한 유일한 기술이기 때문에 이 역할에 적합

▲

GN⁺ 23시간전 [-]

Hacker News 의견들

파일은 사용자가 데이터를 직접 소유할 수 있게 해주는 근본적인 자유의 형태임
이는 기밀성, 무결성, 가용성의 주권을 가능하게 함
디지털 자유의 핵심 축으로서, FOSS 라이선스와 동등하게 인식되어야 함
- LLM의 추론 능력 덕분에 이제는 파일 구조를 걱정하지 않아도 됨
  자연어 자체가 파일 안에 존재하고, 가독성이 곧 스펙이 됨
  읽기 쉬운 사람이면 누구나 파일에 쓸 수 있고, REPL처럼 즉시 실행할 수 있음
- 그래서 Apple 같은 대형 기술 기업들이 파일 개념을 없애려는 시도가 불편함
  데이터가 앱에 묶여 독립적으로 존재하지 못하게 만들고, 가져오기/내보내기도 어렵게 함
  나는 이런 문제를 해결하기 위해 백업에서 데이터를 세분화된 파일 단위로 추출해 개인 디지털 라이브러리로 옮기는 도구를 만들고 있음
  불변 데이터는 보관으로 충분하지만, 수정 가능한 데이터는 다시 ‘살아있는’ 형태로 앱에서 편집 가능하게 만드는 게 가장 큰 과제임
- 설정 파일은 Windows Registry 같은 중앙 저장소보다 훨씬 낫다고 생각함
  임시 변경과 공유가 쉽고, 설정의 의미가 명확히 정의됨
  Windows가 파일을 3등 시민처럼 취급하는 점이 마음에 들지 않음
SaaS 관점에서도 같은 생각을 함
코드가 일시적이고 도메인 특화될수록, 데이터(파일)는 표준적이고 지루할 정도로 안정적이어야 함
특정 앱만 읽을 수 있는 포맷은 기술 부채이며, 결국 프로젝트를 망하게 함
JPEG처럼 1995년 파일도 여전히 열 수 있는 이유는 소프트웨어에 종속되지 않기 때문임
- 10년 넘은 내 사진 관리 시스템은 파일 시스템과 EXIF를 진실의 원천으로 삼고 있음
  여러 번 검증된 올바른 접근임
  Google Photos나 Immich 같은 추상화 계층은 편의용일 뿐, 핵심은 파일임
  업무에서도 markdown과 csv 파일로 연구와 문서를 관리함
  elodie 프로젝트 링크
- 요즘 사진 관리의 문제는 편집, 태그, 앨범 정보가 전부 외부 메타데이터로 저장된다는 점임
  플랫폼을 옮기면 모든 편집 내역이 사라짐
  되돌리기 기능은 편리하지만, 이런 변경이 이식 가능하도록 표준화되길 바람
Bell Labs의 Plan 9을 언급하고 싶음
Plan 9 from Bell Labs
- 나는 agenc라는 에이전트 오케스트레이터를 만들고 있음
  Claude에게 선행 연구를 물었더니 Plan 9을 제시했는데, 지금 우리가 필요한 개념이 바로 그것임
  에이전트 권한 최소화라는 철학이 기업 보안 모델과 동일함
  단지 Plan 9이 너무 일찍 나왔을 뿐임
- 새로운 파일 시스템으로는 GeFS를 살펴볼 만함
Plan 9과 UNIX가 옳았다는 걸 다시금 깨닫게 됨
가장 강력한 인터페이스는 파일 시스템 위의 텍스트 파일임
이제 9p2026을 다시 만들어야 할 때임
다만 글의 일부 기본 개념은 틀림 — 파일 시스템은 트리가 아니라 순환 가능한 그래프임
- Plan 9의 핵심 기능이 무엇인지, FUSE로 붙일 수 있는지, 아니면 더 깊은 마법이 필요한지 궁금함
나에게도 깊이 공감되는 이야기임
지난 1년간 10여 개 SaaS에서 개인 데이터를 하나의 디렉터리 구조로 옮겼음
조직화된 파일 시스템이 단일 사용자에게는 충분하며, 데이터 단편화를 없앰
앞으로는 파일 시스템을 불투명하게 만들지 않으면서도 안전한 다중 사용자 쓰기를 지원하는 새로운 데이터베이스가 등장할 것 같음
QMD가 검색을 위해 하는 역할과 비슷한 느낌임
지금은 AI 활용이 아직 미성숙한 시점임
프로덕션 시스템은 일관되고 확장 가능한 데이터 구조 위에서 돌아가겠지만, 그걸 만드는 에이전트는 파일 시스템 기반 기술을 사용할 것임
UI는 데스크톱에서 벗어나 음성·시각 인터페이스로 진화할 것 같음
예를 들어 화상통화에서 표정과 억양을 읽어 더 많은 맥락을 얻는 식임
- 최근 본 AI 데모 영상에서는 음성과 몸짓에서 맥락을 추출해 텍스트로 변환한 뒤 LLM에 입력함
  완전한 멀티모달은 아니지만 매우 흥미로웠음
- 그래도 텍스트 입력은 사라지지 않을 것 같음
  글쓰기는 생각을 정리하게 해주고, 말처럼 즉흥적이지 않음
  음성 인식(STT)이 아무리 좋아져도 인간 지능은 여전히 글쓰기 중심으로 작동함
파일은 찾을 수 있을 때만 유용함
즉, 검색과 인덱스가 필수인데, 규모가 커지면 깨지기 시작함
그래서 ‘에이전트가 다루는 지식베이스의 크기’가 핵심 질문임
나는 이 주제를 “a good agentic KB” 글에서 1차 원리로 분석해봄
코드베이스처럼 잘 정리된 여러 파일에서는 코딩 에이전트가 정보를 잘 찾음
하지만 엉망인 데이터는 파일 시스템 구조화가 훨씬 어려움
벡터 DB에서 의미 기반 검색을 하는 것보다 복잡함
코드베이스는 DRY 원칙 덕분에 자연스럽게 그래프 구조를 유지하지만, 비코드 데이터는 그렇지 않음
그래서 파일 시스템이 장기적으로 좋은 맥락 구조임에는 동의하지만, 아직 검색을 완전히 대체하지는 못함
파일 시스템은 형편없는 추상화라고 생각함
디렉터리 트리라는 의식적인 구조에 파일을 매달아야 하는 건 비효율적임
관계형 모델이나 고유 식별자 기반 구조가 더 낫다고 봄
- 파일 시스템의 장점은 변경의 지역성 보존임
  한 브랜치의 변경이 다른 브랜치에 영향을 주지 않음
  반면 데이터베이스는 UPDATE나 DELETE가 전체에 영향을 줄 수 있어 위험함
  그래서 현대 OS처럼 트리 구조에 DB 인덱스를 얹는 절충형이 이상적임
- NTFS는 내부적으로 MFT 데이터베이스를 사용함
  파일 이름을 b+tree로 인덱싱하고, 파일 데이터도 MFT에 저장함
  디렉터리는 단지 ‘directory=true’ 속성을 가진 행일 뿐임
  WinFS처럼 완전한 관계형 접근은 성능 문제로 실패했고, Skydrive가 그 자리를 대체함
- 대부분의 파일 시스템에서 파일은 inode로 고유 식별되며, 여러 링크로 참조 가능함
  이 점을 자주 잊는 듯함
- UUID는 인간에게 불투명하지만, 에이전트에게는 완벽히 구분되는 식별자임
  결국 S3 스타일의 blob 저장소에 좋은 인덱스를 얹고, 디렉터리는 태그처럼 온디맨드 생성되는 방향으로 갈 것 같음
  “Q3 관련 자료는 이 디렉터리에 있다” 같은 그룹핑 기능만 남는 식임

답변달기