AI 에이전트의 오래된 고민, '얘를 어디서 일 시키지?'
AI 에이전트한테 일을 시켜보신 분이라면 한 번쯤 부딪히는 벽이 있어요. 에이전트가 코드를 짜는 것까지는 좋은데, 그 코드를 어디서 실행시키느냐는 문제거든요. 파일을 만들고, 스크립트를 돌리고, git으로 커밋하는 작업을 하려면 에이전트에게 '컴퓨터'가 필요한데, 내 로컬 머신을 통째로 내주자니 무섭고, 클라우드에 컨테이너를 띄우자니 부팅 시간과 비용이 부담스럽죠. 게다가 컨테이너가 꺼지면 작업하던 파일이 다 날아가는 것도 골치 아픈 문제예요.
그동안 업계는 이 문제를 'AI 전용 샌드박스'로 풀어왔어요. 샌드박스라는 건, 쉽게 말해서 에이전트가 마음껏 어질러도 되는 격리된 놀이터예요. 그런데 이번에 Cloudflare가 공개한 오픈소스 프로젝트 'Cloudflare Computer'는 이 놀이터를 짓는 방식 자체를 뒤집었어요. 이름부터 직관적이죠. 'Give your agent a computer', 즉 에이전트에게 컴퓨터를 주자는 거예요.
핵심 아이디어: '파일'과 '실행'을 분리한다
Cloudflare Computer의 정체는 한 문장으로 요약돼요. Durable Object 안에 사는 가상 파일시스템이에요. 여기서 낯선 용어가 두 개 나오는데, 하나씩 풀어볼게요.
Durable Object가 뭐냐면, Cloudflare 엣지 네트워크 위에서 돌아가는 '상태를 기억하는 미니 서버'예요. 보통 서버리스 함수는 호출이 끝나면 기억을 다 잃는데, Durable Object는 전 세계에서 딱 하나의 인스턴스로 존재하면서 자기만의 저장소(SQLite)를 갖고 있거든요. Cloudflare Computer는 바로 이 SQLite 안에 파일시스템 전체를 넣어버렸어요. 즉, 에이전트의 홈 디렉토리가 사실은 데이터베이스인 셈이에요.
그리고 이 파일시스템 위에 workspace.runtime.exec(source, { backend })라는 단일 실행 창구를 뚫어놨어요. 실행 환경(백엔드)은 갈아끼울 수 있는 부품이고요. 현재 세 가지 백엔드가 제공돼요.
- Container 백엔드: SQLite에 든 파일 상태를 샌드박스 컨테이너 안에 FUSE 마운트로 투영해요. FUSE가 뭐냐면, 프로그램이 '진짜 폴더인 척' 파일시스템을 흉내 내게 해주는 리눅스 기술이에요. 컨테이너 안의
computerd라는 데몬이 이 마운트를 담당하고, 변경 사항은 capnweb이라는 RPC 채널로 다시 SQLite에 동기화돼요. 완전한 리눅스 환경이라 진짜 바이너리도 돌리고 네트워크도 써요. - Isolate shell 백엔드:
just-bash라는 셸 구현을 Dynamic Worker(가볍게 즉석 생성되는 워커) 안에서 돌려요. 컨테이너 없이 Workers RPC로 원본 Workspace에 바로 접근하니까, 별도 저장소도 동기화 왕복도 없어요. 그만큼 빠르고 가볍죠. - Isolate JavaScript 백엔드: ES 모듈을 새 Worker에서 실행하는데,
node:fs/promises가 Workspace 파일시스템으로 연결돼 있고,ws:git,ws:artifacts같은 신뢰된 모듈로 버전 관리와 산출물 처리까지 할 수 있어요.
왜 이 설계가 영리한가: 구글 드라이브 비유
기존 샌드박스 서비스들(E2B, Modal, Daytona 같은)은 대체로 '컨테이너가 곧 상태'인 구조예요. 비유하자면 작업물을 책상 서랍에 넣어두는 방식이에요. 그 책상(컨테이너)이 치워지면 서랍 속 내용물을 스냅샷으로 백업했다가 복원해야 하죠. 무겁고, 느리고, 컨테이너를 계속 켜두면 돈이 줄줄 새요.
Cloudflare Computer는 반대예요. 작업물은 클라우드 금고(Durable Object의 SQLite)에 두고, 책상은 그때그때 아무거나 빌려 쓰는 방식이에요. 구글 드라이브에 문서를 올려두면 노트북에서든 폰에서든 이어서 작업할 수 있는 것처럼, 같은 파일 상태를 놓고 가벼운 작업은 밀리초 만에 뜨는 isolate에서, pandoc이나 ffmpeg 같은 진짜 바이너리가 필요한 무거운 작업만 컨테이너에서 처리하면 되거든요. 실행 환경은 소모품이고 상태가 본체라는 발상의 전환이에요.
물론 공짜 점심은 아니에요. Container 백엔드는 FUSE와 RPC 동기화를 거치니까 디스크 I/O가 아주 많은 작업에선 오버헤드가 있을 수밖에 없고요. 무엇보다 저장소가 대문짝만하게 경고하듯 지금은 프리뷰 전용이에요. API가 언제든 바뀔 수 있고, docs 폴더의 스펙 문서도 '현재 코드의 설명이 아니라 앞으로의 방향'이라고 못 박고 있어요. 프로덕션 투입은 절대 금물이고, 실험과 프로토타입용이에요. Cloudflare 플랫폼에 종속된다는 점도 조직에 따라서는 고려 대상이겠죠.
업계 맥락에서 보면, Cloudflare는 Workers AI, Agents SDK, Sandbox SDK에 이어 이 프로젝트까지 내놓으면서 '에이전트 인프라 풀스택'을 착실히 쌓고 있어요. 에이전트의 두뇌(모델)는 어디서 오든, 손발과 작업 공간은 자기 엣지 네트워크 위에 올리겠다는 그림이 뚜렷하게 보여요.
한국 개발자에게 주는 시사점
구체적인 시나리오로 감을 잡아볼게요. 사내 문서 자동화 에이전트를 만든다고 해보죠. 마크다운 보고서를 조립하는 단계는 Isolate JavaScript 백엔드로 즉시 처리하고, 최종 PDF 변환처럼 네이티브 도구가 필요한 순간에만 Container 백엔드를 깨우는 식으로 설계할 수 있어요. 사용자마다 Durable Object 하나씩을 배정하면 '고객별 격리된 작업 공간'이 자연스럽게 만들어지고, 대화가 끝나도 파일이 SQLite에 남아 있으니 다음 세션에서 이어가기도 쉽고요. 코드리뷰 봇이 ws:git으로 브랜치를 다루는 그림도 그려볼 수 있겠죠.
지금 시작한다면 이런 로드맵을 추천해요.
1. Cloudflare Workers 기본기: Wrangler로 워커 하나 배포해보기. 반나절이면 돼요.
2. Durable Objects 이해: '전 세계에 하나뿐인 상태 저장 객체'라는 개념과 SQLite 스토리지 API 익히기. 이게 이 프로젝트의 심장이거든요.
3. @cloudflare/computer 설치: 패키지 README의 예제로 fs 표면과 runtime 표면을 직접 만져보기.
4. 에이전트 연결: Agents SDK나 직접 만든 에이전트 루프에 workspace.runtime.exec를 도구로 붙여보기.
주의할 점은 다시 강조할게요. 프리뷰 단계라 사이드 프로젝트나 사내 실험용으로만 쓰고, 실제 서비스 설계에서는 '이런 방향이 오는구나' 정도의 레퍼런스로 삼는 게 안전해요. 다만 저장소가 피드백을 적극적으로 받고 있으니, 지금 만져보고 의견을 내면 설계에 목소리를 반영할 기회이기도 해요.
마무리: 에이전트의 '홈 디렉토리' 표준 경쟁이 시작됐다
에이전트에게 파일시스템은 단순한 작업 공간이 아니라 장기 기억이에요. 대화 컨텍스트는 휘발되지만 파일은 남으니까요. Cloudflare Computer는 그 기억을 실행 환경에서 떼어내 데이터베이스에 넣고, 실행은 상황 따라 골라 쓰는 구조를 제안했어요. 이 '상태와 컴퓨트의 분리'가 표준이 된다면, 앞으로 에이전트 플랫폼 경쟁은 '누가 더 좋은 샌드박스를 띄우느냐'가 아니라 '누가 에이전트의 홈 디렉토리를 차지하느냐'로 옮겨갈 수도 있어요.
여러분은 지금 에이전트에게 코드 실행을 어떻게 시키고 계세요? 로컬 실행의 아슬아슬함을 감수하고 있나요, 아니면 컨테이너 샌드박스의 비용을 치르고 있나요? 상태와 실행을 분리하는 이 접근이 여러분 워크로드에도 맞을지, 댓글로 의견 나눠주세요.
🔗 출처: GitHub