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는 중요한 protocol layer다. Model Context Protocol documentation은 MCP를 모델과 도구 및 데이터 소스를 연결하는 표준으로 설명한다.
하지만 MCP만으로 storage, permissions, audit, recovery가 해결되지는 않는다.
모든 것이 live API call이면 다음 문제가 남는다:
MCP는 access protocol이다. 그 자체가 memory, storage, permissioning, audit, recovery는 아니다.
puppyone으로 에이전트를 위한 거버넌스 컨텍스트 계층 구축Get startedAgents Filesystem은 인간이 아니라 AI agents를 위해 설계된 file workspace다.
전통적인 파일시스템은 사람이 무엇이 안전한지, 최신인지, commit해야 하는지 판단한다고 가정한다. 에이전트는 다르게 작동한다. 보이는 것을 읽고, 허용된 곳에 쓰고, 파일을 reasoning loop의 일부로 사용한다.
프로덕션 Agents Filesystem에는 다섯 가지 능력이 필요하다:
| 능력 | 필요한 이유 |
|---|---|
| 통합 컨텍스트 | SaaS data, repo docs, tickets, specs, 과거 outputs를 하나의 file space에서 접근한다. |
| Scoped access | 각 에이전트는 허용된 path만 읽고 쓴다. |
| Native interfaces | Bash, MCP, REST, CLI, sandbox mounts로 접근한다. |
| Durable writes | plans, scratch files, reports, generated code가 session 이후에도 남는다. |
| Operational traces | reads, 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에서는:
에이전트가 folder를 삭제하거나 policy를 덮어쓰거나 dataset을 망가뜨려도 팀은 inspect하고 revert할 수 있다. Git이 code collaboration에 준 diff와 rollback의 가치를 agent context에도 가져와야 한다.
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은 multi-agent collaboration을 위한 file workspace다. 이 구조에서 puppyone은 Agents Filesystem과 Versioned Control Filesystem 계층을 제공한다.
실제로:
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.
| 질문 | 아니오라면 |
|---|---|
| 모든 에이전트가 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될 수 있어야 한다.
아니다. MCP는 tools와 data에 접근하는 protocol이다. Agents Filesystem은 files, artifacts, permissions, versions, audit trails가 존재하는 context/storage layer다.
그렇다. vector database는 semantic retrieval에 유용하지만 path permissions, rollback, diff, sandbox mounts가 있는 read/write workspace는 아니다.
에이전트가 사용하는 filesystem에 version control이 내장되어야 하기 때문이다. agent가 commit을 기억하는 것에 의존하면 안 된다.
에이전트가 isolated experiment에서 shared workflow로 이동할 때다. 여러 에이전트, 여러 data sources, sensitive files, long-running tasks, reusable artifacts, human review가 있다면 필요하다.