1P by GN⁺ | ★ favorite | 댓글 1개
  • 강한 실적에도 사업 정체성이 흔들리자 Fly.io는 추가 자금을 조달하고 전 Docker CEO Scott Johnston에게 경영을 맡기며 Sprites를 핵심 사업으로 전환함
  • AI로 누구나 맞춤형 소프트웨어를 만들 수 있게 되면서, 사용자 가까이 배포하는 퍼블릭 클라우드와 인간 개발자 중심의 편의성만으로는 차별화하기 어려워짐
  • Sprites는 필요할 때 수백·수천 개를 생성해 오래 유지할 수 있는 에이전트용 컴퓨터로, 각각 100GB 영구 디스크와 유휴 시 과금이 멈추는 종량제를 제공함
  • 새 Sprites에는 더 빠르고 안정적인 Sprite Block Device와 디스크 포킹, 자격 증명을 노출하지 않고 외부 시스템을 호출하는 Connectors가 추가됨
  • Fly.io는 인간이 설계한 고정 기능 애플리케이션 플랫폼과 에이전트 중심의 미래를 동시에 좇지 않고 후자에 집중하되, Fly Machines와 기존 PaaS 기능은 계속 유지

강한 실적 속에서 드러난 정체성 위기

  • Theo Browne는 2026년 새 애플리케이션을 호스팅하기 가장 좋은 곳을 평가하며 Fly.io를 긍정적으로 다뤘지만, 자신이 지켜보는 공급자 중 연말까지 존속할 가능성을 가장 확신하기 어렵다고 평가함
  • 당시 Fly.io는 회사 역사상 최고의 재무 실적을 포함해 강한 분기 실적을 이어가고 있었으나, 무엇을 만들고 어디로 향할지에 관한 정체성 문제는 풀리지 않은 상태였음
  • Fly.io는 상당한 추가 자금을 조달하고 Sprites 새 버전을 출시해 회사의 역량을 집중하는 한편, Scott Johnston을 CEO로 선임함

기존 제품·시장 적합성의 전제가 바뀜

  • Fly.io는 두 가지 원칙에서 출발함
    • 인터넷 애플리케이션은 사용자 가까이에 배포할수록 빨라짐
    • 복잡한 클라우드 인프라 대신 개발자에게 AWS의 유연성Heroku의 사용성을 함께 제공해야 함
  • 두 원칙은 여전히 중요하지만, AI가 소프트웨어 개발을 바꾸면서 이전만큼 결정적인 요소는 아니게 됨
  • 코딩 에이전트를 더 똑똑한 컴파일러처럼 기존 개발 과정에 통합하는 것만으로는 변화의 크기를 포착하기 어려움
  • 스프레드시트가 등장하기 전에는 오늘날의 Excel 문서에 해당하는 작업도 프로그래머가 만든 프로그램이어야 했지만, 스프레드시트 수식은 수많은 업무 담당자를 프로그래머로 바꿈
  • AI는 이보다 더 큰 변화를 일으켜 거의 누구나 거의 모든 종류의 프로그램을 만들 수 있는 방향으로 나아감
  • 기존 퍼블릭 클라우드는 엄격한 표준과 CI/CD 절차를 거친 고정 기능 애플리케이션을 수백만 명에게 배포하도록 설계됨
  • 앞으로 수백만 사용자를 대상으로 하는 프로그램도 존재하겠지만, 수백만 독자가 보는 스프레드시트처럼 일반적인 형태는 아닐 수 있음
  • 2020년식 퍼블릭 클라우드 설계에 계속 베팅하는 것은 개인화되고 적응하는 소프트웨어의 확산에 반대편으로 베팅하는 것과 같음
  • Fly.io는 친구와 가족이 개발자를 기다리지 않고 컴퓨터로 원하는 일을 직접 수행할 수 있는 세계를 선택함

인간 개발자 경험보다 에이전트의 요구

  • 클라우드 인프라가 개발자에게 어렵다는 문제는 여전하지만, 에이전트가 작업을 대신하면서 세심하게 설계된 인간용 개발자 경험의 중요성은 줄어듦
  • 명시적인 환경에서 더 잘 작동하는 에이전트에는 의견이 강한 기본값과 선별된 개발자 경험이 오히려 불리할 수도 있음
  • 사람들은 문서를 읽고 새 CLI를 시행착오로 익히는 대신 에이전트에 맡기기 시작함
  • 에이전트는 로컬에서 만든 사이트를 Fly.io에 배포하라는 요청을 한 번에 처리할 수 있지만, AWS 배포도 한 번에 처리할 수 있어 기존 사용성만으로는 차별화하기 어려움
  • 가장 빠르게 성장하는 고객이 로봇이라는 관찰 이후, Fly.io는 기존 제품을 에이전트용으로 재해석하는 대신 에이전트가 실제로 원하는 환경을 찾기 시작함

에이전트가 원하는 컴퓨터

  • 코딩 에이전트는 기본적으로 개발자 워크스테이션에서 실행되도록 만들어짐
  • 신뢰할 수 있는 샌드박스라도 물리적인 노트북에서 실행하면 덮개를 닫는 순간 작업이 중단되므로, 사용자는 결국 에이전트 샌드박스를 클라우드로 옮기게 됨
  • 기존 퍼블릭 클라우드 서버는 에이전트 작업에 지나치게 큰 약속을 요구함
    • 전통적인 반려동물형 서버나 가축형 서버보다 더 일시적이어야 함
    • 원하는 순간 생성하고 필요한 기간만 유지하면서 적은 비용으로 운영할 수 있어야 함
  • Sprites는 이런 요구에 맞춘 반일회성 컴퓨터
    • 수백 또는 수천 개를 빠르게 생성할 수 있음
    • 각 Sprite에 100GB 영구 디스크가 제공됨
    • 사용량에 따라 과금되지만 아무 작업도 하지 않을 때는 계량이 멈추며, 유휴 상태를 자체적으로 판단함
    • 애플리케이션을 호스팅하고 인터넷을 통해 동료와 공유할 수 있음
  • 업계는 샌드박스에 집중하지만, 에이전트에 필요한 것은 샌드박스가 아니라 지속성과 활용성을 갖춘 컴퓨터
  • Sprites를 즉시 생성해 직접 사용할 수 있음

Sprites를 회사의 중심으로 전환

  • 초기 Sprites는 Fly.io 내부의 소규모 비공식 팀이 만든 프로젝트였으며, Fly.io의 기본 웹사이트에서 호스팅하지도 않았음
  • 앞으로는 에이전트용 컴퓨터(Computers for Agents) 가 회사의 핵심 초점이 되며, Sprites도 더 이상 소수 인력만 담당하는 프로젝트가 아님
  • Fly Machines와 기존 서비스형 플랫폼(PaaS) 기능은 폐기하지 않고 계속 제공함
  • 새 Sprites는 확장과 오케스트레이션을 개선하고 두 가지 주요 하위 시스템을 도입해 목표한 기능 구성을 완성함

Sprite Block Device와 디스크 포킹

  • 기존 스토리지 스택은 JuiceFS를 바탕으로 만들고 Litestream을 연결한 구조였음
  • Ben Johnson과 Tim Newsham이 스토리지 스택을 기초부터 다시 구축한 Sprite Block Device(SBD) 는 이전보다 빠르고 안정적이며, 즉시 체크포인트·복원 기능도 유지함
  • SBD의 핵심 확장인 드라이브 포킹을 사용하면 템플릿 Sprite 하나를 만든 뒤 이를 효율적으로 수백만 번 복제할 수 있음

자격 증명 노출을 막는 Connectors

  • Connectors는 Fly.io 핵심 플랫폼을 보호하기 위해 개발한 토큰화된 토큰을 기반으로 함
  • Sprite가 다른 시스템에 인증된 요청을 보내면서도 에이전트에는 유출할 만한 자격 증명을 직접 제공하지 않도록 설계됨
  • 계정과 API 키를 수동으로 관리하는 방식보다 사용하기 편리함
  • SBD의 복제 기능과 Connectors는 고객이 가장 많이 요청한 기능이며, 전용 에이전트 제품 출시 후에도 많은 에이전트 기업이 Fly Machines를 계속 사용한 이유이기도 함
  • Transformer 모델보다 더 낯선 기술 변화가 등장하지 않는 한 Sprites가 미래 고객과 기존 고객 상당수에 적합하다고 판단해 새 베타를 제공함

창업자 CEO의 퇴진

  • 창업 초기 8년 동안 Fly.io는 제품·시장 적합성을 찾는 실험 조직으로 운영됨
    • 관리형이 아닌 Postgres, 글로벌 CDN, 사용자 모드 WireGuard 등 수십 가지를 시도함
    • 상향식 엔지니어링 조직을 만들고 제품 로드맵을 피했으며, 12개가 넘는 국가에서 일하는 완전 원격 팀을 구성함
  • 일부 실험은 성과를 냈고 다른 실험은 학습 기회가 됐지만, 현재 단계의 Fly.io에는 이런 종류의 과학 프로젝트가 더 이상 필요하지 않음
  • 창업자는 CEO로서 제공할 수 있는 강점을 대부분 소진했다고 판단해 자리에서 물러남

Scott Johnston의 CEO 취임

  • 2025년부터 수개월 동안 Scott Johnston에게 Fly.io의 의사결정을 맡기는 방안을 논의함
  • Scott은 Docker CEO 시절 기업 시장과 개발자 시장 사이의 정체성 위기에서 시작된 어려운 시기를 이끌었고, 이후 사업을 크게 성장시킴
  • Fly.io 주주이자 당시 CEO였던 창업자는 현재 회사 단계에는 자신의 방식보다 Scott의 운영 방식이 더 적합하다고 판단해 이사회와 함께 그를 설득함
  • 창업자는 고문과 이사회 구성원으로 남아 제품 설계 논의에 참여하고, Scott은 사업 운영과 실행을 맡음

새 전략을 위한 추가 자금

  • Fly.io는 수년간 신규 투자 유치를 발표하지 않았지만, 이전에 큰 규모의 자금을 조달해 기존 계획대로라면 추가 조달이 필요하지 않을 문턱에서 운영해 왔음
  • AI로 기존 계획이 바뀌면서 새 전략을 추진하기 위한 추가 자금을 조달했으며, 구체적인 규모와 조건은 공개하지 않음
  • Scott Johnston이 향후 자금 조달 내용을 별도로 다룰 예정임

두 미래 중 하나를 선택

  • Fly.io는 수년 안에 에이전트가 거의 모든 소프트웨어의 구축과 배포 방식을 결정할 것으로 내다봄
  • 소프트웨어는 더 개인화되고 대상 사용자는 더 작아지며, 형태는 더 유연하고 유동적으로 바뀔 것으로 봄
  • 이런 변화는 기대를 주는 동시에 업계 종사자들을 불편하게 만들고 있음
  • 회사에는 두 가지 선택지가 있었음
    • 인간이 설계한 고정 기능 풀스택 애플리케이션 플랫폼을 계속 확장하고 개선함
    • 에이전트 중심의 가까운 미래에 맞는 제품을 정교하게 완성함
  • 스타트업이 두 방향을 동시에 추구하면 어느 쪽에도 충분히 집중하기 어려우므로, Fly.io는 에이전트 중심 제품을 선택함
  • 수개월 동안 미뤄진 우선순위 결정을 Sprites가 해소했으며, Scott Johnston은 이를 Fly.io의 핵심 사업으로 전환하는 역할을 맡음

댓글과 토론

Hacker News 의견들
  • 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를 사용 중임