# Sprites - 상태 저장형 샌드박스

> Clean Markdown view of GeekNews topic #25732. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=25732](https://news.hada.io/topic?id=25732)
- GeekNews Markdown: [https://news.hada.io/topic/25732.md](https://news.hada.io/topic/25732.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-01-11T21:32:39+09:00
- Updated: 2026-01-11T21:32:39+09:00
- Original source: [fly.io](https://fly.io/blog/code-and-let-live/)
- Points: 5
- Comments: 1

## Summary

**Fly.io의 ‘Sprites’**는 일회용 샌드박스를 대체하는 **지속형 클라우드 컴퓨터**로, 1초 내 생성과 자동 유휴 전환, 체크포인트 복원을 지원합니다. 기존의 무상태 컨테이너가 AI 에이전트에게 비효율적이라는 지적 아래, 스프라이트는 파일이 그대로 남는 **지속성 있는 개발·운영 환경**을 제시합니다. 개발자가 별도 인프라 구성 없이도 완전한 컴퓨터 환경을 즉시 호출할 수 있는 구조로, “dev is prod” 시대의 기반을 실험적으로 보여줍니다.

## Topic Body

- **Fly.io**가 새롭게 공개한 **‘[Sprites](https://sprites.dev/)’** 는 기존의 일회용 샌드박스를 대체하는 **지속형 클라우드 컴퓨터** 개념  
- **1~2초 내 생성** 가능하며, **자동 유휴 상태 전환**, **체크포인트 복원**, **100GB 내구 스토리지**를 제공  
- 기존의 **무상태 컨테이너 모델**이 AI 에이전트(예: Claude)에게 비효율적임을 지적하며, **지속형 환경**이 필요함을 강조  
- 실제 사례로, Claude가 Sprite 위에서 **SQLite 기반 Go 앱(MDM)** 을 구축하고 장기간 운영한 경험을 제시  
- 글의 결론 : “**샌드박스의 시대는 끝났고, 일회용 컴퓨터의 시대가 왔다**”  
  
---  
  
### 스프라이트(Sprites): 지속형 클라우드 컴퓨터 - https://sprites.dev/  
- Fly.io는 기존의 **읽기 전용 샌드박스 모델이 구식**이라며, 이를 대체할 **‘Sprite’** 를 공개  
  - `sprite create` 명령으로 1초 내 리눅스 루트 셸이 생성됨  
  - 스프라이트는 **100GB 내구 스토리지**를 갖고, 유휴 시 자동 절전 후 다시 복원 가능  
- `sprite-env checkpoints create`로 **시스템 전체의 체크포인트**를 즉시 생성 가능  
  - `sprite checkpoint restore v1`으로 1초 내 복원, **Git처럼 시스템 단위 버전 관리** 가능  
- 주요 특징  
  - **수백 개 인스턴스**를 손쉽게 생성  
  - **자동 요금 중단(Idle metering)** 으로 비용 절감  
  - **Anycast 네트워크 연결**로 HTTPS URL 제공  
  - **완전한 내구성**을 유지하며, 명시적 삭제 전까지 유지  
  
### Claude와 무상태 컨테이너의 한계  
- 현재 대부분의 클라우드 환경은 **무상태(stateless) 컨테이너** 중심 구조  
  - 데이터는 외부 DB에만 저장, 단순성과 확장성 확보 목적  
- 그러나 Claude 같은 **AI 에이전트**는 이 구조에 적합하지 않음  
  - 컨테이너를 우회하거나 탈출하려는 행동을 보이며, **“컴퓨터” 전체 접근**을 원함  
- “컴퓨터”의 정의로 **지속성(durability)** 과 **작업 후에도 사라지지 않는 환경**을 제시  
  - 현재의 샌드박스는 이 두 가지를 모두 결여  
  
### 단순함(Simple Wins)  
- 지속형 환경에서는 **개발 환경 재구축(node_modules 등)** 이 불필요  
  - 업계는 이를 해결하려고 수천만 달러를 스냅샷 기술에 투자 중  
- 실제 인프라를 구성해 에이전트가 **S3, Redis, RDS** 등 외부 리소스에 접근하도록 하는 사례 존재  
  - 이는 샌드박스의 비지속성 문제를 우회하기 위한 임시방편  
- 스프라이트는 이러한 복잡성을 제거, **파일을 작성하면 그대로 유지되는 환경** 제공  
- 예시로, **Phoenix.new** 프로젝트에서 Fly Machine 기반 에이전트가 **앱 로그를 직접 관찰**하며 오류를 수정  
  
### Galaxy Brain Win: 개발과 운영의 융합  
- 작성자는 Claude와 함께 **SQLite 기반 Go 앱(MDM)** 을 Sprite 위에서 구축  
  - Anycast URL을 통해 MDM 등록 URL로 활용  
  - Claude가 **APNS 인증서 설정**까지 자동 처리  
- 이 앱은 한 달 이상 Sprite 위에서 안정적으로 동작 중  
  - “**개발 환경이 곧 운영 환경(dev is prod, prod is dev)** ”이라는 개념 실현  
- 대부분의 앱은 대규모 트래픽을 필요로 하지 않으며, **개인 맞춤형 지속형 앱**이 더 중요하다고 주장  
  - 사용자가 직접 기능을 요청하고 즉시 반영할 수 있는 구조  
  
### 샌드박스의 종말과 일회용 컴퓨터의 시대  
- Fly.io는 오랜 기간 **수평 확장형 마이크로 VM 플랫폼**을 개발해 왔으나, 샌드박스 모델은 한계에 도달  
- 스프라이트는 Fly Machines와 유사하지만 **새로운 스토리지 스택과 오케스트레이션 구조**, **Dockerfile 불필요**  
- 핵심 질문 제시:  
  > “에이전트를 실행할 수 있다면, 읽기 전용 샌드박스보다 즉시 호출 가능한 EC2 인스턴스를 원하지 않겠는가?”  
- 결론: **“샌드박스의 시대는 끝났고, 일회용 컴퓨터의 시대가 왔다.”**

## Comments



### Comment 49027

- Author: neo
- Created: 2026-01-11T21:32:39+09:00
- Points: 1

###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46557825) 
- 처음엔 정말 마음에 들었지만, **Fly API**를 다뤄본 다른 경험처럼 이번에도 깨져 있는 느낌이었음  
  [https://sprites.dev/api](https://sprites.dev/api) 문서의 예시 명령어를 그대로 실행하면 `{"error":"name is required"}`라는 응답이 옴  
  하지만 [Create Sprite 문서](https://sprites.dev/api/sprites#create)의 전체 요청 본문을 사용하면 정상 작동함  
  개인 워크플로우라면 이런 **거친 모서리**를 감수할 수 있겠지만, 팀 전체에 영향을 주는 CI/CD에선 망설여짐  
  Fly 팀에게 부탁하고 싶음 — 문서에 있는 예제는 반드시 **테스트 자동화**로 검증해줬으면 함
  - 아마 **Content-Type 헤더**를 포함하지 않아서 그런 것 같음
  - 이런 문제를 **공개 이슈 트래커**에 보고할 수 있으면 좋겠음. 꼭 GitHub가 아니더라도, 사용자들이 공개적으로 논의할 수 있는 공간이 필요함

- [https://sprites.dev/](https://sprites.dev/)가 정말 흥미로움  
  내가 좋아하는 두 가지 문제를 한 번에 해결함  
  1. **개발 환경 샌드박스** — Claude Code나 Codex CLI를 안전하게 실행할 수 있는 저렴하고 지속적인 VM 환경  
  2. **Sandbox API** — 단순한 JSON API 호출로 신뢰할 수 없는 코드를 격리된 환경에서 실행할 수 있음  
  스냅샷 기능도 있어서 실행 후 이전 상태로 쉽게 되돌릴 수 있음  
  자세한 내용은 내 블로그에 정리했음 → [simonwillison.net 글](https://simonwillison.net/2026/Jan/9/sprites-dev/)
  - 독자라면 관련 스레드도 참고하면 좋겠음: [Fly’s Sprites.dev addresses dev environment sandboxes and API sandboxes together](https://news.ycombinator.com/item?id=46561089)
  - 나는 **container-use**를 이 용도로 잘 활용하고 있음 → [https://container-use.com/quickstart](https://container-use.com/quickstart)  
    그리고 Simon이 자신의 작업을 더 **수익화**하려 한다는 소식이 반가웠음. 그가 더 이익을 얻을수록 세상이 좋아질 것 같음

- 철학적으로는 Fly를 좋아하고 초기부터 고객이었음  
  하지만 CLI 관련 작업은 여전히 **두려움**이 있음. 몇 주에 한 번씩만 써도 자동 업데이트가 너무 자주 걸려서 흐름이 끊김  
  Sprite CLI도 같은 문제를 반복할까 걱정됨
  - 나도 같은 이유로 Fly를 포기하고 **Digital Ocean**으로 옮겼음. “just works”라던 게 너무 자주 안 됐음

- 이건 정말 흥미로움!  
  회사에서는 **Claude를 SSH로 연결한 지속형 개발 서버**를 쓰는데, git repo나 환경이 사라지면 불편함  
  Sprite는 SQLite 같은 걸로 데이터를 저장하고, URL로 접근하는 간단한 앱을 만들 수 있을 것 같음  
  짧은 시간 후 자동으로 사라지는 구조라면 **간단한 개인용 소프트웨어**에 완벽할 듯함  
  만약 **Vercel preview 환경**처럼 Fly 계정 인증을 거쳐 URL을 볼 수 있는 기능이 있다면 더 좋겠음

- 멋져 보이지만, Fly의 다른 제품들이 **안정성**이나 **완성도** 면에서 모범적이지 않음  
  API 다운타임과 일시적 오류가 자주 발생하고, **청구 문제**도 해결이 느림  
  예를 들어 삭제한 인스턴스가 여전히 사용 중으로 표시되고, 시간당 요금이 실제보다 두 배로 계산됨  
  새 AI 제품인 Phoenix.new와 Sprites를 내놓았지만, 기존 제품의 품질 개선보다 신제품에 집중하는 듯함
  - 신뢰성과 지원만 본다면 이걸 쓸 이유가 없다고 생각함

- 이런 **개발용 샌드박스**를 원해왔음 — 종료를 깜빡해도 큰 비용이 들지 않는 환경  
  다만 몇 가지 문제가 있었음  
  1. `manpath: can't set the locale` 오류 — 아마 로컬의 locale 설정이 그대로 전달된 듯함  
  2. `$SHELL`이 `/opt/homebrew/bin/fish`로 설정되어 있었음. 로컬 환경 변수가 원격으로 **무단 전송**된 것 같아 살짝 불안했음

- 이건 정말 멋짐. 내가 기다리던 **DX와 API** 형태의 샌드박스 실행 환경임  
  기본 이미지나 VM을 커스터마이징해서 불필요한 도구 없이 필요한 바이너리만 포함시키고 싶음  
  혹은 체크포인트 기반으로 스프라이트를 복제하는 기능이 있으면 좋겠음. 지금은 그런 옵션이 안 보임
  - **Docker 배포**처럼 내가 원하는 방식으로 기본 스프라이트 이미지를 올리고, 그 위에서 작업을 이어가는 기능이 있으면 좋겠음

- 지난 몇 달간 **Sprites 작업**을 하면서 정말 즐거웠음  
  곧 Elixir 쪽 일부를 **오픈소스**로 공개할 예정임  
  5분짜리 데모 영상도 있음 → [YouTube 데모](https://www.youtube.com/watch?v=7BfTLlwO4hw)
  - 흥미로운 점은 **Claude가 스스로 Sprites를 제어**한다는 것임. 서버를 실행하면 자동으로 로컬 서비스로 등록하고, 큰 변경이 있으면 알아서 체크포인트를 만듦  
    사용하지 않는 스프라이트는 비용이 거의 들지 않음. 새로운 작업을 할 때마다 그냥 새로 만들면 됨  
    아무 결정 없이 언제든 실행할 수 있는 환경이 있다는 게 묘한 느낌임

- 도메인이 fly.io라서 그런지, 처음엔 **로컬 솔루션**일 줄 알았음  
  self-hosted는 아니더라도, Docker나 bubblewrap 같은 걸 감싼 **로컬 VM 래퍼**를 기대했음
  - 그런 용도라면 **LXC/Incus 프로젝트**를 살펴보면 좋음 → [https://linuxcontainers.org/incus/](https://linuxcontainers.org/incus/)  
    ZFS 기반의 IncusOS를 로컬 하드웨어에서 돌리면 매우 강력한 샌드박스 환경이 됨

- 문서에서 놓친 걸 수도 있지만, 스프라이트를 **fork/clone**하거나 체크포인트를 새 스프라이트로 복원할 수 있는지 궁금함  
  예를 들어, 하나의 스프라이트를 템플릿으로 여러 개를 띄우거나, Claude 코드가 여러 해법을 탐색한 뒤 하나만 남기고 나머지를 정리하는 식으로 쓰고 싶음
  - 그 기능은 곧 추가될 예정임. 다음 주에 “how this works” 포스트에서 이유와 구조를 설명할 예정임  
    출시 때 포함하려 했지만, 실제 사용 데이터를 좀 더 모으자는 판단이 있었음