AI Agent Infrastructure에 Agents Filesystem과 Versioned Control Filesystem이 필요한 이유

2026년 4월 21일Lin Ivan

핵심 요점

  • AI Agent Infrastructure의 병목은 모델 성능만이 아니다. 컨텍스트, 도구 접근, 파일, 권한, 실행 환경, 복구가 핵심이다.
  • Cloudflare의 내부 스택은 프로덕션 에이전트 시스템의 형태를 보여준다: 인증, MCP servers, sandbox, AGENTS.md, 서비스 카탈로그, AI code review.
  • 대부분의 팀은 그 전체 플랫폼을 즉시 재구축할 필요는 없다. 하지만 초기에 Agents Filesystem 계층은 필요하다.
  • Versioned Control Filesystem은 에이전트가 파일을 변경하기 때문에 중요하다. 모든 쓰기에는 identity, diff, history, rollback, audit가 필요하다.
  • puppyone은 SaaS ingestion, MCP access, scoped permissions, sandbox mounts, version history, audit logs를 갖춘 agent용 file workspace로 이 계층을 제공한다.

Cloudflare의 교훈: 에이전트 주변의 인프라가 먼저 필요하다

Cloudflare는 내부 AI 엔지니어링 스택을 공개했다: The AI engineering stack we built internally. 이 글의 핵심은 특정 모델이 아니라, AI 도입을 prompt 문제가 아닌 infrastructure 문제로 다룬다는 점이다.

그 스택은 인증, 중앙 LLM routing, MCP servers, sandbox 실행, 장기 agent session, service catalog, AGENTS.md, engineering standards, AI code review를 연결한다.

프로덕션 문제인프라 대응
다양한 AI client와 provider중앙 routing, policy, cost tracking
에이전트가 내부 도구를 필요로 함MCP servers와 portal
에이전트가 코드를 안전하게 실행해야 함sandbox runtime
에이전트가 repo context를 필요로 함AGENTS.md와 engineering standards
에이전트가 조직 지식을 필요로 함service catalog와 dependency graph
에이전트 output을 리뷰해야 함standards와 연결된 AI code review

이것이 프로덕션 AI Agent Infrastructure다. 더 긴 context window를 가진 chatbot이 아니라, 에이전트가 올바른 context를 찾고, 올바른 tool을 쓰고, 경계 안에서 행동하며, 리뷰 가능한 trace를 남기는 환경이다.

"MCP만 추가"로는 부족하다

MCP는 중요한 protocol layer다. Model Context Protocol documentation은 MCP를 모델과 도구 및 데이터 소스를 연결하는 표준으로 설명한다.

하지만 MCP만으로 storage, permissions, audit, recovery가 해결되지는 않는다.

모든 것이 live API call이면 다음 문제가 남는다:

  • tool schema가 작업 전 context를 소모한다;
  • 에이전트가 plan, scratch files, reports, transformed data를 저장할 durable한 위치가 없다;
  • 두 run 사이의 diff를 보기 어렵다;
  • SaaS, repo, database마다 glue code가 필요하다;
  • output이 chat thread, temporary sandbox, 관리되지 않는 folder에 남는다.

MCP는 access protocol이다. 그 자체가 memory, storage, permissioning, audit, recovery는 아니다.

puppyone으로 에이전트를 위한 거버넌스 컨텍스트 계층 구축Get started

Agents Filesystem이란 무엇인가

Agents Filesystem은 인간이 아니라 AI agents를 위해 설계된 file workspace다.

전통적인 파일시스템은 사람이 무엇이 안전한지, 최신인지, commit해야 하는지 판단한다고 가정한다. 에이전트는 다르게 작동한다. 보이는 것을 읽고, 허용된 곳에 쓰고, 파일을 reasoning loop의 일부로 사용한다.

프로덕션 Agents Filesystem에는 다섯 가지 능력이 필요하다:

능력필요한 이유
통합 컨텍스트SaaS data, repo docs, tickets, specs, 과거 outputs를 하나의 file space에서 접근한다.
Scoped access각 에이전트는 허용된 path만 읽고 쓴다.
Native interfacesBash, MCP, REST, CLI, sandbox mounts로 접근한다.
Durable writesplans, scratch files, reports, generated code가 session 이후에도 남는다.
Operational tracesreads, writes, diffs, permission errors가 보인다.

이것은 단순 공유 폴더가 아니다. Dropbox, S3, Git, local disk, vector database는 각각 일부만 해결한다. agent identity, per-agent permissions, MCP distribution, sandbox mounts, automatic version history를 함께 제공하지는 않는다.

파일 안전성의 자세한 내용은 filesystem design for AI agents를 참고하라.

버전 관리는 파일시스템 계층에 있어야 한다

에이전트는 context를 검색만 하지 않는다. 변경한다.

회의를 요약하고, migration plan을 만들고, dataset을 변환하고, 문서를 고치고, report를 생성하고, pull request를 연다. 에이전트가 write를 한다면 system에는 recovery model이 필요하다.

그래서 Versioned Control Filesystem이 중요하다. 더 자연스러운 표현은 "version-controlled filesystem"이지만, 핵심은 같다. 버전 관리는 에이전트가 commit을 기억하는지에 의존해서는 안 된다. storage layer에 들어가야 한다.

에이전트용 Versioned Control Filesystem에서는:

  • every write가 versioned change가 된다;
  • change가 agent, user, Access Point, workflow에 attribution된다;
  • diff를 inspect할 수 있다;
  • folder를 known state로 rollback할 수 있다;
  • risky run은 checkpoint에서 시작할 수 있다;
  • permission boundary를 audit할 수 있다.

에이전트가 folder를 삭제하거나 policy를 덮어쓰거나 dataset을 망가뜨려도 팀은 inspect하고 revert할 수 있다. Git이 code collaboration에 준 diff와 rollback의 가치를 agent context에도 가져와야 한다.

AI Agent Infrastructure 참조 아키텍처

User / workflow request
  -> agent client / orchestration
  -> model routing and policy
  -> MCP and tool access
  -> Agents Filesystem
       - synced SaaS context
       - repo and project context
       - generated artifacts
       - per-agent permissions
       - version history and audit logs
  -> sandbox execution
  -> review, approval, deployment

Agents Filesystem은 중앙에 있다. context가 operational object가 되는 곳이기 때문이다. sources, MCP, sandbox, review를 연결한다. 이 계층이 없으면 local folder, vector index, 여러 MCP servers, wiki, object bucket, manual audit note가 흩어진다.

puppyone의 위치

puppyone은 multi-agent collaboration을 위한 file workspace다. 이 구조에서 puppyone은 Agents Filesystem과 Versioned Control Filesystem 계층을 제공한다.

실제로:

  • Notion, GitHub, Google Drive, Gmail, Airtable, Linear, databases를 Context Space로 동기화한다;
  • context를 Markdown, JSON, folders, raw files로 표현한다;
  • Access Points가 에이전트별 readable/writable path를 정의한다;
  • MCP endpoints가 Claude, Cursor 등 MCP clients에 같은 workspace를 노출한다;
  • sandbox mounts에는 authorized files만 포함된다;
  • version history와 rollback이 agent writes를 복구 가능하게 만든다;
  • audit logs가 누가 무엇을 언제 만졌는지 보여준다.

puppyone은 Cloudflare stack의 모든 계층을 대체하지 않는다. model policy, runtime isolation, CI, review, internal standards는 여전히 필요하다. 하지만 Agents Filesystem이 있으면 context와 artifacts가 흩어지지 않는다.

관련 글: MCP in Agentic AI, AI audit best practices for secure agent deployments.

자체 stack 점검표

질문아니오라면
모든 에이전트가 copy-paste 없이 context를 찾는가?ingestion과 normalization이 필요하다.
각 에이전트가 허용된 files/tools만 보는가?scoped permissions가 필요하다.
generated files가 session 이후에도 남는가?durable artifact storage가 필요하다.
두 run 사이의 변경을 diff할 수 있는가?versioned filesystem history가 필요하다.
잘못된 write를 rollback할 수 있는가?checkpoints와 restore가 필요하다.
sandbox가 authorized context만 mount하는가?filesystem-aware access control이 필요하다.
사람이 chat log가 아닌 artifact를 review하는가?file-based workflows가 필요하다.

이것이 ai agent infrastructure 검색 의도다. 에이전트가 안전하게 read, write, execute, collaborate, review될 수 있어야 한다.

버전 관리 file workspace 위에서 agent infrastructure 시작하기Get started

FAQs

Q1: Agents Filesystem은 MCP와 같은가?

아니다. MCP는 tools와 data에 접근하는 protocol이다. Agents Filesystem은 files, artifacts, permissions, versions, audit trails가 존재하는 context/storage layer다.

Q2: vector database와 다른가?

그렇다. vector database는 semantic retrieval에 유용하지만 path permissions, rollback, diff, sandbox mounts가 있는 read/write workspace는 아니다.

Q3: 왜 Versioned Control Filesystem이라고 부르나?

에이전트가 사용하는 filesystem에 version control이 내장되어야 하기 때문이다. agent가 commit을 기억하는 것에 의존하면 안 된다.

Q4: 언제 도입해야 하나?

에이전트가 isolated experiment에서 shared workflow로 이동할 때다. 여러 에이전트, 여러 data sources, sensitive files, long-running tasks, reusable artifacts, human review가 있다면 필요하다.