에이전트 격리의 최첨단은 읽기 전용 샌드박스라는 통념에 반기를 들며, Fly.io가 새로 만든 ‘Sprite’로 내구성 있는(지속되는) 컴퓨터를 즉시 만들고 체크포인트/복원을 통해 개발·에이전트 워크플로를 바꾸자는 주장.
URL: https://fly.io/blog/code-and-let-live/
Code And Let Live · The Fly Blog
Author
이름: Kurt Mackey @mrkurt
이미지: Annie Ruygt 제공
에이전트 격리의 최첨단은 읽기 전용 샌드박스다. Fly.io에서는 수년 동안 그 이야기를 팔아 왔고, 이제 결론을 내리겠다. 일회성(에페머럴) 샌드박스는 구식이다. 샌드박스를 쓸 때마다 죽이지 말자.
내 주장은 우리가 새로 만든 뭔가를 보여주지 않으면 말이 안 될 거다. 우리 모두 성인이고, 여긴 회사고, 우리는 우리가 하는 일을 이야기한다. 자, 시작.
그래서 코드를 좀 돌리고 싶다. 내가 하는 일은 sprite create를 실행하는 거다. 동작하는 동안 그 뒤에서 무슨 일이 벌어지는지 설명해 볼—
text✓ Created demo-123 sprite in 1.0s ● Connecting to console... sprite@sprite:~#
젠장, 벌써 들어와 있잖아.
이건 우리가 이제 소유하게 된 리눅스 컴퓨터의 루트 셸이다. 이미 존재하던 호스트에 ssh로 접속하는 데 걸릴 법한 시간과 비슷한 시간 안에 온라인이 됐다. 우리는 이런 걸 “Sprite”라고 부른다.
Sprite에 FFmpeg를 설치해 보자:
textsudo apt-get install -y ffmpeg >/dev/null 2>&1
Sprite를 만드는 것과는 달리, apt-get으로 ffmpeg를 설치하는 건 끔찍하게 느리다. 다시는 이 짓을 하고 싶지 않으니:
textsprite@sprite:~# sprite-env checkpoints create # ... {"type":"complete","data":"Checkpoint v1 created successfully", "time":"2025-12-22T22:50:48.60423809Z"}
이건 즉시 끝난다. 측정할 생각조차 안 했다.
커피를 사러 잠깐 자리를 비운다. 시간이 흐른다. Sprite는 내 비활동을 감지하고 잠든다. 커피숍에서 고등학교 동창을 만난다. 하루를 같이 보내게 된다. 시간이 더 흐른다. 며칠도. 나중에 돌아와서:
text> $ sprite console sprite@sprite:~# ffmpeg ffmpeg version 7.1.1-1ubuntu1.3 Copyright (c) 2000-2025 the FFmpeg developers Use -h to get full help or, even better, run 'man ffmpeg' sprite@sprite:~#
전부 내가 두고 간 그대로다. Sprite는 지속된다(durable). 시작 용량 100GB, 번거로운 의식 같은 것도 없다. 며칠 더 두든, 몇 달 두든 상관없다. 그냥 된다.
어떤 애플리케이션을 그럴듯하게 세워 둔다고 치자. 패키지도 더 설치한다. 그러다: 재앙. 아마도 무심코 전역 pip3 install을 했거나. 아니면 rm -rf $HMOE/bin. 혹은 dd if=/dev/random of=/dev/vdb. 뭐가 됐든 전부 망가졌다. 그래서:
text> $ sprite checkpoint restore v1 Restoring from checkpoint v1... Container components started successfully Restore from v1 complete > $ sprite console sprite@sprite:~#
Sprite에는 체크포인트와 복원이 1급 기능으로 있다. 텍스트만 봐서는 모르겠지만, 복원은 대략 1초 정도 걸렸다. 가볍게, 대화형으로 쓸 만큼 충분히 빠르다. 비상 탈출구가 아니라, Sprite를 쓰는 평범한 흐름의 일부로 의도된 기능이다. git 같은데, 전체 시스템에 대해 하는 느낌.
이게 EC2 인스턴스랑 뭐가 다르냐고 묻는다면, 좋다. 우리가 노리는 게 그거다. 다만:
이런 속성 조합은 흔치 않아서 이미 이름이 붙어 있지 않다. 그래서 우리가 이름을 붙이기로 했다: “Sprites”. Sprites는 BIC 일회용 펜 같은 일회용 클라우드 컴퓨터다.
우리가 만든 건 이거다. 직접 가서 써 볼 수 있다. 동작 방식에 대해 1000단어쯤 더 썼는데, 제품 얘기는 이제 그만하고 싶어서 잘랐다. 이제 내 요점으로 가자.
수년 동안, 우리는 매우 다른 두 종류의 사용자를 동일한 추상화로 만족시키려 했다. 작동하지 않았다.
전문 소프트웨어 개발자는 상태 없는(stateless) 인스턴스를 만들도록 훈련받는다. 영속 데이터는 DB 서버에만 두고, 배포는 stateless로 만들면 단순함, 유연한 수평 확장, 장애 영향 반경 감소를 얻는다. 좋은 아이디어고, 너무 널리 퍼져서 오늘날 클라우드에서 코드를 실행할 수 있는 대부분의 곳은 stateless 컨테이너처럼 보인다. Fly의 대표 제품인 Fly Machines도 stateless 컨테이너처럼 보인다.
문제는 Claude가 프로 개발자가 아니라는 거다. Claude는 초생산적인 다섯 살짜리 신동이다. 소름끼칠 만큼 똑똑하고, 가능한 모든 전기 콘센트에 손가락을 넣고 싶어 하며, 스스로 감전하게 놔두는 방법을 찾았을 때 가장 잘 일한다.
(가끔은 컨테이너를 탈출하면서!)
에이전트가 필요하다면, 컨테이너화를 우회해서 일을 하기도 한다. 하지만 그렇다고 해서 에이전트에게 도움이 되는 건 아니다. 에이전트는 컨테이너를 원하지 않는다. “샌드박스”도 원하지 않는다. 컴퓨터를 원한다.
누가 얼마 전에 나에게 물었다. 내가 말하는 게, 에이전트에 사운드 카드와 USB 포트 같은 게 필요하다는 뜻이냐고. 그리고, 어쩌면? 모르겠다. 오늘은 그 얘긴 아니다.
잠시 뒤에 왜 그런지 설명하겠다. 하지만 먼저 “컴퓨터”가 대체 뭐냐는 걸 설명해야 할 것 같다. 우리 모두 동의하는 건:
현재의 에이전트 샌드박스는 이 둘 다 없으니, 정의는 여기서 멈추고 다시 요점으로 돌아갈 수 있다.
여기서 시작하자: 실제 컴퓨터가 있으면, Claude는 내가 PR을 집어 들 때마다 내 개발 환경 전체를 다시 만들 필요가 없다.
겉보기엔 사소해 보이지만 node_modules 같은 걸 다시 빌드하는 건 너무 거대한 고통이라서, 업계는 일회성 샌드박스를 스냅샷/복원하는 방법을 알아내느라 수천만 달러를 쓰고 있다.
나는 그 문제가 풀기 어렵다고 말하는 게 아니다. 불필요하다고 말하는 거다. 그걸 해결하려 애쓰는 대신, 그냥 실제 컴퓨터를 쓰면 된다. PR 하나 처리하고, 리뷰하고 푸시한 다음, 재부팅 없이 다음 PR로 가면 된다.
사람들은 매번 변경셋을 시작할 때 새 빌드 환경에서 시작하는 게 왜 좋은지 합리화할 거다. 스톡홀름 신드롬이다. 네가 직접 기능 브랜치를 시작할 때마다, 완전히 새로운 개발 환경을 만들어서 하냐?
에이전트가 이렇게 노력을 낭비하는 이유는 아무도 에이전트가 올 줄 몰랐기 때문이다. 읽기 전용 일회성 샌드박스는, 에이전트를 “그나마” 제정신으로 쓰기 위해 벽에 걸려 있던 유일한 도구였다.
에이전트에게 현실적인 데이터에 접근하게 하려고 실제 인프라를 세팅해 본 적 있나? 사람들은 그렇게 한다. 매 프롬프트마다 깨끗한 상태에서 시작한다는 걸 알기 때문에, 에이전트가 대화할 수 있도록 샌드박스 밖에 S3 버킷, Redis 서버, 심지어 RDS 인스턴스까지 마련한다. 파일 하나 쓰고 그게 그대로 남아 있을 거라고 믿을 수 없어서, 그걸 우회하기 위한 인프라를 만드는 거다. 역겹다.
일회성은 시간 제한을 의미한다. 제공자들은 에이전트가 만들어낼 것으로 예상되는 워크로드를 처리하도록 샌드박스 시스템을 설계한다. 오늘날 에이전트가 하는 대부분의 일은 시간이 많이 걸리지 않는다. 사실 최전선 모델이 토큰을 처리하는 속도만큼만 제한되는 경우가 많다. 테스트 스위트는 빠르게 돈다. 샌드박스에서 돌아가는 에이전트 실행의 99퍼센타일은 아마 15분도 안 걸릴 거다.
하지만 어떤 기능 요청에서는 계산/네트워크 시간이 토큰 처리 시간을 압도한다. 나는 Sprites API용 문서 사이트를 만들 때, Claude Sprite가 코드와 우리 API와 상호작용하면서 예제를 하나씩 만들고 테스트하게 했다. 어떤 API는 클라이언트 상호작용 시간만으로도 샌드박스 예산을 초과할 수 있다.
지금 접근의 한계는 사람들이 상태를 “플랜 파일”로 왕복시키는 방식에서도 보인다. 겉으로는 산문(prose)처럼 보이지만, 실제로는 끔찍하게 인코딩된 키-값 저장소인 경우가 많다.
실제 컴퓨터에서 돌아가는 에이전트는 애플리케이션의 전체 라이프사이클을 활용할 수 있다. Chris McCord가 Phoenix.new를 만들 때 우리는 이걸 봤다. Phoenix.new 앱 뒤의 에이전트는 Fly Machine에서 실행되며, 그 에이전트는 자신이 생성한 Phoenix 앱의 로그를 볼 수 있다. 사용자가 예외를 발생시키는 일을 하면, Phoenix.new는 이를 감지하고 무슨 일이 있었는지 파악하기 시작한다.
Chris가 그걸 세팅하는 데는 너무 많은 작업이 필요했다. 그가 자신의 에이전트를 직접 썼기 때문에 가능한 부분도 있었다. Claude로도 MCP 서버나 로그를 끌어오는 다른 구성으로 오늘 당장 할 수 있다. 하지만 사실 필요한 건, 에이전트가 코드 쓰기를 끝냈다고 해서 샌드박스에 총을 쏴 버리지 않는 것뿐이다.
여기서부터 내가 당신을 잃는 지점이다. 왜냐하면 여기서부터는 내 팀도 대부분 나를 안 믿기 때문이다.
소프트웨어 개발의 본질은 우리 발밑에서 바뀌고 있고, 나는 이것이 단지 프로 개발자가 소프트웨어를 배송하는 방식을 재구성하는 정도로 끝날 거라고 믿는 건 자기기만이라고 생각한다.
나는 아이가 있다. 애들에겐 기기가 있다. 나는 그걸 좀 통제하고 싶었다. 그래서 많은 당신이 같은 상황에서 하듯이: 나는 바이브 코딩으로 MDM을 만들었다.
이건 Claude로 만들었다. SQLite를 백엔드로 쓰는 Go 애플리케이션이고 Sprite에서 돌아간다. Sprite가 내보내는 Anycast URL은 MDM 등록 URL로 작동한다. Claude는 APNS 푸시 인증서의 모든 골치 아픈 문제도 해결해 줬다. 전부 그냥 된다.
“FTP로 PHP 파일 수정하기: 우리가 틀렸던 게 아니라, 시대를 앞서갔던 거야!”
나는 이걸 한 달 동안 계속 Sprite 위에서 돌리고 있는데, 그만둘 이유가 전혀 없다. 나에게 중요한 현실 문제를 해결해 주는 소프트웨어다. 내 필요가 바뀌면 진화할 수도 있고, 그때 Claude에게 바꾸라고 하면 된다. 아니면 안 바뀔 수도 있다. 이 앱에서는 dev가 prod이고, prod가 dev다.
우리가 이런 것들을 어떻게 만들었는지 정리해 쓸 때 더 다루겠지만, 어떤 이유들 때문에 Sprites 위에 수백만 명에게 서비스할 앱을 배포하고 싶진 않을 거다. 하지만 대부분의 앱은 수백만 명에게 서비스하고 싶어 하지 않는다. 가장 중요한 일상용 앱들은, 불균형하게도, 백만 명 규모의 청중을 갖지 않을 가능성이 높다. 백만 명 규모의 중요한 앱도 일부 있지만, 그 대부분은 시민사회를 파괴하고, 뇌를 녹이고, 치즈버거 하나를 위해 개인 운전기사를 붙인다.
사람들에게 실제 문제를 해결해 주는 애플리케이션은, 그 문제를 해결받는 사람들이 소유하게 될 것이다. 그리고 대체로, 그들은 기능 개발을 위해 프로 개발자 길드가 문지기 역할을 할 필요가 없다. 그냥 요청하고, 얻을 거다.
우리가 모두 풀고 있는 문제는 프로 개발자를 안전하게 가속하는 것보다 더 크다. 샌드박스는 우리를 뒤로 잡아끈다.
당연히 나는 여기서 뭔가를 팔려고 한다. 하지만 그렇다고 내가 틀린 건 아니다. 내가 하는 주장이 바로, 우리가 내가 팔고 있는 그 특정한 것을 만든 이유다.
원한다면 지금 당장 Sprite 수십 개를 만들 수 있다. 1초면 된다.
여기까지 오기까지 오래 걸렸다. 우리는 수년 동안 스스로를 속였다. 우리는 마이크로 VM으로 수평 확장하는 프로덕션 애플리케이션용 플랫폼을 만들었고, 그 VM은 너무 빨리 부팅돼서, 정확히 올바른 방식으로 쥐면 꽤 괜찮은 코드 샌드박스를 만들 수 있었다. 하지만 이건 늘 사각 못을 둥근 구멍에 넣는 격이었다.
Sprites가 어떻게 동작하는지에 대해 할 말이 많다. Fly Machines와 관련이 있지만 중요한 면에서 확연히 다르다. 완전히 새로운 스토리지 스택이 있다. 오케스트레이션도 다르게 된다. Dockerfile도 없다.
하지만 지금은, 내가 말하는 것을 생각해 봤으면 한다. Sprite를 실제로 부팅하든 말든, 질문해 보자: 코딩 에이전트를 어디서든 돌릴 수 있다면, K8s 클러스터 안의 클라우드 읽기 전용 샌드박스처럼 보이길 바라겠나, 아니면 손가락 튕기듯 불러낼 수 있는 완전한 EC2 인스턴스처럼 보이길 바라겠나?
답은 뻔하다고 생각한다. 샌드박스의 시대는 끝났다. 일회용 컴퓨터의 시간이 왔다.
마지막 업데이트 • 2026년 1월 9일
작성자: Kurt Mackey @mrkurt
이전 글 ↓ Litestream VFS
Copyright © 2026 Fly.io
