클라우드플레어 「computer」, 파일이 사라지지 않는 이유는 SQLite다

클라우드플레어가 2026년 8월 3일 얼리 프리뷰로 낸 에이전트 런타임 GitHub cloudflare/computer 저장소는 파일시스템을 디스크가 아니라 SQLite 데이터베이스로 만들었습니다. 에이전트가 파일 하나를 쓰면, 그건 디스크의 조각이 아니라 SQLite 테이블의 행 하나가 됩니다. MIT 라이선스의 이 TypeScript 프로젝트는 2026년 9월 6일 기준 별 9,075개를 받았습니다.

이 글은 그 선택의 이유를 따라갑니다. 왜 평범한 디스크로는 안 됐는지, SQLite로 파일시스템을 만든다는 게 뭘 바꾸는지를 봅니다. 컨테이너 대신 컴퓨터를 주는 전체 그림은 앞선 글에서 다뤘으니, 이번엔 저장 장치 하나만 뜯어봅니다.

왜 파일이 두 세계에 걸쳐 있어야 했나

Cloudflare Computer는 작업 무게에 따라 실행 환경을 나눕니다. 가벼운 작업은 V8 isolate에서, 무거운 작업만 Linux 컨테이너에서 돌립니다.

클라우드플레어 체인지로그는 이를 isolate와 리눅스 컨테이너 사이의 동적 조율이라 부릅니다. 문제는 이 둘이 원래 전혀 다른 세계라는 데 있습니다.

V8 isolate는 애초에 디스크가 없습니다. How Workers works 문서에 따르면 Workers의 isolate는 파일시스템 접근도 시스템 콜도 원천적으로 막혀 있습니다. 보안을 언어 수준에서 강제하는 방식이라고 이 문서는 설명합니다.

컨테이너는 진짜 리눅스라 진짜 디스크가 있습니다. 다만 그 디스크는 컨테이너 인스턴스가 살아 있는 동안만 존재하고, 인스턴스가 내려가면 같이 사라집니다.

그러니 isolate에서 쓴 파일을 컨테이너에서 곧바로 열려면 제3의 저장소가 필요합니다. isolate엔 애초에 붙을 디스크가 없고, 컨테이너의 디스크는 세션이 끝나면 증발하니까요.

Cloudflare가 공개한 실행 구조

SQLite로 파일시스템을 만든다는 것의 실제 의미

클라우드플레어가 고른 제3의 저장소는 Durable Object 안에 내장된 SQLite입니다. 공식 블로그는 Cloudflare Computer를 “Durable Object 안에 사는 가상 파일시스템”이라 소개하고, 그 Durable Object가 SQLite로 상태의 원본을 들고 있다고 밝힙니다.

이게 새로 발명한 기술은 아닙니다. Durable Object의 SQLite 저장 백엔드는 2024년에 정식 출시됐습니다. 체인지로그 문서에 따르면 2026년 7월부터는 새로 만드는 모든 Durable Object가 이 SQLite 백엔드를 씁니다.

Cloudflare Computer는 이미 검증된 저장 계층 위에 파일시스템 모양을 얹었습니다. 파일 하나가 곧 SQLite 테이블의 행 하나입니다.

read·write·edit·ls 같은 표준 도구를 에이전트가 부르면, 실제로는 그 Durable Object 안 SQLite에 대한 SQL 쿼리가 됩니다. SQLite-backed Durable Object Storage 문서는 이 저장소를 단순 키-값이 아니라 테이블과 인덱스를 갖춘 SQL 인터페이스라고 설명합니다.

두 실행 환경이 이 파일을 보는 방식은 다릅니다. isolate는 Workers RPC로 Durable Object에 직접 말을 걸고, 컨테이너는 computerd라는 데몬이 그 SQLite 상태를 FUSE로 마운트합니다.

사본 둘이 아니라 같은 데이터베이스 하나를 봅니다.

FUSE는 “Filesystem in Userspace”의 줄임말로, 커널 모듈 없이도 사용자 프로그램이 파일시스템처럼 행동하게 해 주는 리눅스 기능입니다. ls나 cat 명령이 실제로는 computerd를 거쳐 SQLite 쿼리로 바뀌지만, 리눅스 프로세스는 그 사실을 모릅니다.

FUSE 마운트가 SQLite로 바뀌는 흐름

왜 하필 SQLite였나 — 지연시간과 복구

디스크 대신 데이터베이스를 쓰면 느려질 것 같지만 실제론 반대입니다. Zero-latency SQLite storage in every Durable Object 글은 이 SQLite가 별도 서버가 아니라 코드와 같은 스레드에서 라이브러리처럼 실행된다고 설명합니다.

쿼리가 네트워크를 타지 않습니다. 데이터가 메모리에 캐시돼 있으면 지연시간은 사실상 0에 가깝다고 이 글은 밝힙니다. 파일 하나 읽을 때마다 네트워크 왕복이 걸렸다면 도구 호출마다 느려졌을 텐데, 그 비용을 없앤 셈입니다.

덤으로 붙는 게 point-in-time recovery입니다. 같은 문서는 SQLite 기반 Durable Object가 기본으로 지난 30일 내 임의 시점 복원을 지원한다고 설명합니다.

변경 이력을 계속 쌓아 두는 저장 구조의 부수 효과라고 합니다. 다만 이 복구 기능이 Cloudflare Computer의 파일에도 똑같이 열려 있는지는 이번 조사로 확인하지 못했습니다.

지연시간과 복구 개념

그래서 실제로 무슨 차이가 나나

여기서부터가 이 선택이 쓰는 사람에게 만드는 차이입니다. 첫째, 세션이 끊겨도 파일이 남습니다.

Durable Object 저장소는 요청이 끝난다고 지워지는 임시 메모리가 아닙니다. 그 객체가 존재하는 한 저장된 파일도 같이 남습니다.

둘째, 가벼운 작업과 무거운 작업을 오가도 파일이 하나로 보입니다. 에이전트가 isolate에서 설정 파일을 고치고 곧이어 컨테이너로 넘어가 그 파일을 읽는 빌드 명령을 돌려도, 파일을 따로 옮길 필요가 없습니다. 애초에 사본이 둘로 나뉜 적이 없으니까요.

셋째, git 저장소나 클라우드 스토리지에서 파일을 불러와 이 파일시스템 위에 얹을 수 있다고 체인지로그는 밝힙니다. 빈 디스크가 아니라 프로젝트 파일이 이미 채워진 채로 시작합니다.

두 실행 환경에서 같은 파일이 보이는 모습

시작하기 전에 확인할 것 — 계정과 요금제

이 런타임을 만져 보려면 클라우드플레어 계정이 필요합니다. 다만 계정 종류별로 무엇이 다른지는 공식 문서에서 확인하지 못했습니다.

isolate 백엔드만 쓴다면 Workers 무료 플랜 안에서도 실험해 볼 여지가 있어 보이지만, 이 부분은 추정입니다. 컨테이너 백엔드는 사정이 분명합니다.

Cloudflare Containers Pricing 문서에 따르면 컨테이너를 쓰려면 월 5달러 Workers 유료 플랜이 있어야 합니다. 무료 플랜에는 컨테이너 자체가 없습니다.

유료 플랜에는 매달 메모리 25 GiB-시간, vCPU 375분, 디스크 200 GB-시간이 기본 포함됩니다. 이 한도를 넘으면 GB초·vCPU초 단위로 추가 요금이 붙고, Workers와 Durable Object 사용료는 별도로 청구됩니다. 이 수치는 2026년 9월 6일 공식 페이지 기준입니다.

컨테이너 요금제 포함 한도

직접 확인해 보는 법

정확한 실행 명령은 각 예제 폴더의 안내를 따라야 합니다. 이번 조사로는 명령어 하나하나까지는 확인하지 못했습니다.

다만 저장소 구조를 보면 순서는 이렇습니다.

GitHub cloudflare/computer 저장소를 내려받고 @cloudflare/computer 패키지를 설치합니다.
examples 폴더의 컨테이너 예제를 열어 Container 백엔드로 파일 하나를 씁니다.
같은 워크스페이스를 Isolate Shell 백엔드로 열어 ls를 실행합니다.
프로세스를 껐다가 같은 워크스페이스 ID로 다시 접속해 파일이 남아 있는지 봅니다.

3번에서 방금 컨테이너로 쓴 파일이 그대로 보이면, 두 백엔드가 같은 SQLite를 보고 있다는 신호입니다. 4번에서 재접속 후에도 파일이 남아 있으면, 그게 이 글에서 말한 상태 영속성입니다.

워크스페이스 재접속 확인

얼리 프리뷰라 안 되는 것들

이 런타임은 2026년 8월 3일 나온 얼리 프리뷰입니다. InfoQ 보도는 클라우드플레어가 이를 실험과 탐색, 프로토타입에만 적합한 상태라고 밝혔다고 전합니다.

실험과 탐색, 프로토타입에만 적합한 프리뷰입니다.

API가 안정되지 않았다는 뜻이니, 지금 짠 코드가 다음 버전에서 그대로 돌아간다는 보장은 없습니다. 이번 조사로는 “Cloudflare Computer 전용 요금제”는 찾지 못했습니다.

요금은 사실 Workers, Durable Object, Containers 각각의 것을 조합해 계산해야 합니다. 실제 청구 항목이 무엇 무엇인지는 공식 문서에서 직접 따져 봐야 합니다.

프리뷰 단계 표시

이럴 땐 쓰지 마라

지금 당장 고객이 쓰는 서비스 뒤에 이 런타임을 놓는 건 이르다고 봅니다. 클라우드플레어 스스로 API가 프리뷰 단계라 바뀔 수 있다고 밝혔으니까요. 프로덕션 트래픽보다는 사이드 프로젝트나 사내 프로토타입에 먼저 얹어 보는 쪽이 관행에 가깝습니다.

다른 클라우드의 얼리 프리뷰 서비스들도 대개 같은 취급을 받습니다. 이 제품만 유별나게 조심할 필요는 없습니다.

프로토타입 단계의 도구

마무리

Cloudflare Computer가 파일시스템을 SQLite로 만든 이유는 isolate엔 디스크가 없고, 컨테이너의 디스크는 세션이 끝나면 사라지기 때문입니다. 그 사이를 잇는 제3의 저장소로, 이미 검증된 Durable Object의 SQLite 저장소를 골랐습니다.

그 결과 파일은 디스크 조각이 아니라 데이터베이스의 행이 됐고, 대화가 끊겨도 남고 실행 환경을 오가도 하나로 보입니다. 다만 2026년 8월 3일 기준 얼리 프리뷰라, API도 요금 구조도 아직 굳어지지 않았습니다.

참고한 자료