
솔직히 말해봅시다. 우리는 그동안 "상태(State)는 악(Evil)"이라고 세뇌당했습니다.
서버는 언제든 죽었다 살아나도 똑같아야 한다며 Stateless 아키텍처를 찬양했고, 모든 컨테이너를 일회용품 취급했죠. 웹 서버 트래픽을 처리할 때는 그게 정답이었습니다.
하지만 최근 AI 에이전트(Agent)를 개발하면서 뭔가 잘못됐다는 걸 느꼈을 겁니다.
코드를 실행할 때마다 npm install이나 pip install을 반복하며 수십 초를 날려먹고 있다면, 당신은 지금 '기술 부채'를 쌓고 있는 겁니다. 오늘은 Fly.io가 내놓은 Sprites라는 개념을 통해, 왜 우리가 AI 에이전트 인프라를 '실제 컴퓨터'처럼 다뤄야 하는지 이야기해보려 합니다.
핵심 요약
- AI 에이전트에게 매번 '깨끗한 방(Stateless)'을 주는 건 비효율의 극치입니다.
- Fly.io의 Sprites는 1초 만에 깨어나는 '영속적(Durable) VM'입니다.
- 매번 빌드하지 말고, 상태를 저장(Checkpoint)하고 필요할 때만 복구하세요.
1. 우리는 왜 '일회용 샌드박스'에 집착했나
개발자들은 지난 10년간 "내 컴퓨터에선 되는데요?"라는 말을 없애기 위해 고군분투했습니다. 그 결과물이 도커(Docker)와 쿠버네티스입니다.
모든 환경을 격리하고, 쓰고 나면 버립니다. 깔끔하죠. 그런데 이 방식을 AI 에이전트에게 강요하면서 문제가 터졌습니다.
Claude 같은 LLM 에이전트는 '5살짜리 천재'와 같습니다. 엄청나게 똑똑하지만, 매번 작업을 시작할 때마다 책상(환경)을 싹 치워버리면 일을 못 합니다.
에이전트가 코드를 수정하고 테스트를 돌리려는데, node_modules부터 다시 깔고 있다면 그건 리소스 낭비입니다. 업계에서는 이걸 해결하겠다고 일시적(Ephemeral) 샌드박스를 최적화하느라 수천만 달러를 쓰고 있는데, 솔직히 말해 스톡홀름 신드롬입니다.
불편한 도구에 우리를 맞추고 있는 겁니다.
2. Sprites: 죽지 않는 가벼운 VM
Fly.io에서 내놓은 해답은 단순합니다. "그냥 컴퓨터를 줘라."
Sprites는 겉보기엔 가벼운 마이크로 VM이지만, 껐다 켜도 데이터가 날아가지 않습니다. EC2 인스턴스와 비슷하지만, 생성과 부팅이 1초 단위로 끝납니다.
기존 방식 (Stateless)
- 컨테이너 시작
- apt-get install ffmpeg (지루하게 오래 걸림)
- 작업 수행
- 컨테이너 삭제 (데이터 증발)
Sprites 방식 (Stateful)
- VM 생성:
sprite create(1초 소요) - apt-get install ffmpeg (최초 1회만 수행)
- 체크포인트 생성:
sprite-env checkpoints create - 작업 안 하면 자동 절전 (비용 0에 수렴)
며칠 뒤에 다시 돌아와서 ffmpeg를 실행하면?
sprite@sprite:~# ffmpeg
ffmpeg version 7.1.1...설치 과정 없이 즉시 실행됩니다. 내가 떠난 그 상태 그대로 남아있기 때문입니다.
3. '체크포인트'는 인프라를 위한 Git이다
개발하다 보면 멍청한 실수를 합니다. rm -rf를 잘못 날리거나, 라이브러리 버전을 꼬이게 만들죠.
일반적인 VM이라면 다시 세팅하느라 밤을 새웠겠지만, Sprites는 체크포인트 복원(Restore) 기능을 제공합니다.
sprite checkpoint restore v1
이 명령어 한 번이면, 망가지기 전 상태로 1초 만에 되돌아갑니다. 이건 단순한 백업이 아닙니다. 개발 프로세스의 일부입니다.
Git으로 코드를 되돌리듯, 인프라의 상태를 즉시 되돌리는 겁니다.
4. 에이전트에게는 '기억'이 필요하다
우리는 에이전트가 데이터를 저장하게 하려고 S3나 Redis를 억지로 붙여왔습니다. 샌드박스가 언제 날아갈지 모르니 외부 저장소를 덕지덕지 붙인 겁니다.
하지만 샌드박스 자체가 영속성(Durability)을 가진다면?
에이전트는 그냥 로컬 파일 시스템에 파일을 쓰면 됩니다. 복잡한 네트워크 호출도, 인증 키 관리도 필요 없습니다.
이게 바로 '단순함이 이기는' 구조입니다.
마치며: 도구에 매몰되지 마십시오
저는 유행하는 기술 스택을 무작정 도입하는 걸 극도로 싫어합니다. 하지만 Stateless가 만능이 아니라는 점은 인정해야 합니다.
웹 서버는 Stateless가 맞습니다. 하지만 작업의 맥락(Context)을 유지해야 하는 AI 에이전트에게는 Stateful한 환경이 압도적으로 유리합니다.
매번 환경을 초기화하느라 에이전트의 응답 속도를 깎아먹고 있다면, 이제는 '영속적 VM'을 고려해야 할 때입니다.
코드는 부채입니다. 그리고 불필요한 인프라 세팅 시간 또한 명백한 부채입니다. 갚으세요.


