Sprites의 추상화는 아름답지만, 30년 개발 경력에서 이보다 버그 많은 인프라 제품은 처음이었음
데이터가 수시로 사라지고 연결 불가능한 좀비 상태가 됐으며, 시스템 절반은 Sprite가 정상이라 보고 나머지는 죽었다고 판단해 스냅샷조차 불러올 수 없었음
점심이나 하룻밤 사이, 심지어 작업 중에도 결과물이 사라져 2주 만에 포기했고, 터미널 기록을 뒤져 죽은 Sprite에서 작업물을 복사해 살려내야 했음
실행한 Sprite의 절반 이상에서 문제가 생긴 듯하며, 개념은 훌륭하니 안정성을 확보하길 바람

여러 Sprites에서 코드를 실행하도록 조율하는 앱을 운영 중인데, 몇 달 전까지만 해도 서비스가 완전히 망가지거나 데이터가 사라져 지원팀의 복구가 필요할 만큼 불안정했음
다만 최근 두 달 정도는 훨씬 안정적으로 바뀐 것으로 보임
몇 년 전 Fly.io도 실제 용도로 쓰기 어려울 만큼 버그가 많았지만, 지금은 몇몇 프로덕션 워크로드를 매우 안정적으로 운영하고 있어 Sprites도 같은 경로를 밟으리라 봤고 실제로 그렇게 되어가는 중임

이는 Sprite만의 문제가 아니라 Fly.io 플랫폼 전체가 수년간 알려진 문제를 방치해 온 결과임
CEO가 형편없이 운영해 왔다는 점에서는 사임이 오히려 나을 수도 있음

엔터프라이즈 고객이 빠른 개발을 위해 Sprites 도입을 검토하는 과정을 지켜봤지만, 결국 Fly.io를 포기하고 같은 개념을 제공하는 다른 회사로 옮겼음
이유도 심각한 인터페이스 버그와 데이터 손실, 형편없는 지원이었음
다만 시험 기간에 실제 회사 도메인을 쓰지 않았고 Fortune 200 기업이라는 사실도 밝히지 않아 지원 품질에 영향을 줬을 가능성은 있음

Elixir 개발자로서 Fly.io가 성공하길 바랐지만, 멋진 엔지니어링과 운영 안정성 사이에서 균형을 찾지 못해 두 번이나 떠나야 했음
한동안 전 세계 장애가 발생해도 상태 페이지는 모두 정상으로 표시됐고, 포럼 글을 봐야 장애를 알 수 있었으며 회사는 문제 해결에 바빠 상태를 갱신하지 못했다고 답했음
이후 상태 페이지를 갱신하기 시작했지만 “특정 리전 장애” 이후 몇 시간 동안 아무 소식이 없는 일이 반복됐음
유료 지원이 나오자 즉시 가입했으나 빠른 응답을 약속한 이메일 주소는 대부분 아무도 확인하지 않았고, 대규모 장애를 신고해도 다음 날이나 며칠 뒤에야 “어떤 문제가 있나요?”라는 답이 왔음
이런 일이 드물었다면 고객 지원 문제에 그쳤겠지만, 한때는 거의 매달 중대한 장애를 겪었고 잠시 안정되는 듯하다가 다시 반복적으로 무너졌음
결국 모든 서비스를 자체 호스팅으로 되돌렸고 번거롭긴 해도 가동 시간이 크게 좋아졌으며, 장애가 나면 원인을 직접 알 수 있어 훨씬 덜 고통스러움
호스팅 사업을 계속하려면 책임을 받아들이고 운영에 예산을 투입해야 하며, 그렇지 않다면 호스팅을 접고 또 다른 HashiCorp가 되는 편이 나음

상태 페이지는 정상인데 포럼에서만 전 세계 장애를 알 수 있었다는 대목이 AWS인지 Fly인지 구별하기 어려울 정도임

회사 전체를 Sprites에 집중하는 건 Fly.io가 자살을 택한 것처럼 보임 AI 샌드박스는 이미 경쟁이 치열하고 사실상 범용재가 됐으며, 새 CEO는 창의적인 비전을 희생하면서 수익에 집중할 가능성이 큼
틀린 판단이길 바람

사용량 비례 과금을 제외하면 AI 샌드박스는 어느 가상 머신이나 컨테이너 서비스 위에서도 쉽게 구현할 수 있어 이 전략이 이해되지 않음
컨테이너는 일회용이고 작업을 쉽게 다시 실행할 수 있어 데이터 보존도 덜 중요하며, 에이전트가 직접 베어메탈에 환경을 띄우게 할 수도 있음
에이전트는 대부분 GPU를 기다리므로 유사한 워크로드끼리 메모리 중복 제거를 적용하면 적은 하드웨어에서도 수백 개를 실행할 수 있음
AWS는 이미 에이전트를 위한 클라우드이며, 에이전트와 코드형 인프라(IaC)를 사용하면 AWS의 복잡성도 크게 줄어듦
이제 가치는 조율이나 모델 서빙 계층의 하드웨어 마진 몇 bp를 다투는 데 있지 않고, 에이전트가 더 나은 결정을 내리도록 돕는 도구를 만드는 데 있음

최근 LLM 발전으로 개인뿐 아니라 기업과 조직도 정체성 위기를 겪고 있으며, 이 글이 좋은 예시임
AI가 한 번에 만들어낼 수 있는 제품이나 회사를 계속 구축할 가치가 있는지는 의문임
반대로 이전에는 불가능했던 더 크고 야심 찬 일에 도전하도록 압박한다는 흥미로운 결과도 있음
청정에너지처럼 수백 명이 같은 일을 해도 인류에 지속적으로 순이익을 주는 분야에 더 많은 이들이 뛰어들길 바람

Docker가 정말 사업을 폭발적으로 성장시켰다는 뜻인지, 아니면 Boeing처럼 문짝이 날아갔다는 뜻인지 의문임

Sprites는 투자를 받은 스타트업보다는 친구 몇 명이 운영하는 소규모 안정형 사업에 어울려 보임
개발자라면 이미 Docker나 Podman으로 충분히 잘 해결할 수 있음
할머니와 할아버지까지 앱을 만드는 거대한 신규 시장은 Lovable 같은 서비스가 차지할 것이고, 비개발자가 Sprites를 쓸 가능성은 낮음
결국 기존 개발자 중 일부만 확보할 수 있음

에이전트가 소프트웨어 개발 생산성을 100배 높이는 과정에서 내 컴퓨터와 홈 네트워크, 생활까지 망가뜨릴까 두렵기 때문에 이론적으로는 내가 바로 목표 고객임
OpenCode나 Claude Code 등이 보안 재앙이라는 소식이 매일 나오는데, 격리가 그렇게 쉽다면 왜 더 많은 개발자가 컨테이너를 쓰지 않고 이런 사고도 계속되는지 의문임
코드를 더 빨리 작성하겠다는 이유로 집의 환경을 원격 기업 LLM에 개방하고 싶지 않아 에이전트 코딩을 피하고 있지만, 여러 소스 파일을 한꺼번에 분석해야 할 때부터는 분명 손해를 보고 있음

회사 전체의 방향을 Sprites로 바꾼 직후 곧바로 떠나는 건 거칠게 느껴짐
적어도 새 CEO가 직접 방향을 정하며 승부할 기회는 줘야 함

Sprites에 회사의 미래를 걸 만한지는 의문이며, 최종 판단은 새 CEO의 몫임
장기적으로는 이런 격리 실행 환경이 Claude Code나 Codex에 내장되거나 AI 기업이 직접 제공할 가능성이 큼

Sprites는 Claude Code 같은 도구가 코드를 실행할 환경만 제공하는 것이 아니라, 신뢰할 수 없는 코드를 저렴하게 실행해야 하는 제품을 만드는 누구에게나 유용함

Sprites는 매우 훌륭한 추상화임
Git worktree도 비슷한 문제를 해결하지만, Sprites를 이용하면 인스턴스를 빠르게 띄워 서비스를 실행한 뒤 코딩 에이전트에게 넘겨 기능을 개선하게 할 수 있음
여러 에이전트를 병렬로 실행해 결과 중 하나를 고를 수 있고, 포트 수나 로컬 CPU 제약도 받지 않음
RAM 부족이 당분간 계속된다는 점까지 고려하면 Sprites에서 수백 개의 에이전트를 실행할 수 있음

코드를 작성해 준 Claude에게 배포 환경까지 빌리고 싶지는 않으며, 코드만 받은 뒤 관계를 끝내고 다른 곳에 배포할 수 있다는 점이 좋음

Fly.io가 고치고 집중해야 할 것은 신뢰성임
Docker 컨테이너를 띄우자마자 앱이 실행되는 방식은 마음에 들었지만, 서비스가 여러 차례 중단됐고 가격도 매우 비쌌음
지금은 단순히 VPS를 사용 중임