Fly.io가 추가 자금 조달, Sprites의 새 버전 출시, 그리고 에이전트를 위한 컴퓨터에 회사의 초점을 맞추는 이유를 설명합니다.
이미지 제공: Annie Ruygt
우리는 Fly.io입니다. 인터넷에 앱을 올리는 우리가 가장 좋아하는 방법이자, 프런티어 에이전트 코딩 하네스가 안전하게 마음껏 돌아가도록 하는 우리가 가장 좋아하는 퍼블릭 클라우드 플랫폼입니다. 이 글은 우리 회사, 미래, 그리고 지금 바로 확인할 수 있는 에이전트를 위한 컴퓨터인 Sprites에 관한 이야기입니다.
이 글은 좀 복잡합니다. 그러니 한 가지 약속해 주세요. 이 도입부를 지나서 읽기 시작했다면, 끝까지 전부 읽는 겁니다. 명예의 문제예요.
몇 달 전, Theo Browne가 “2026년에 새 애플리케이션을 호스팅하기에 가장 좋은 곳”을 평가하는 영상을 올렸습니다. Theo는 우리에 대해 좋은 말을 자주 해주는 편입니다. 이번에도 그랬습니다. 하지만 마지막에는, 자신이 주목하는 제공업체들 가운데 우리가 연말까지 살아남아 있을지 가장 확신이 서지 않는 곳이라고 결론지었습니다.
이런, 씨발.
Theo의 말은 우리를 놀라게 했습니다. 우리는 회사 역사상 최고의 재무 월들을 포함한 강한 분기들의 흐름 한가운데 있었기 때문입니다. 하지만 그 평가는 계속 제 머릿속을 맴돌았습니다. 우리가 무엇을 하고 있고, 회사로서 어디로 가고 있는지에 관한 제 가장 예민한 신경을 정통으로 건드렸습니다.
솔직히 말하면, 이 일이 이렇게 올 줄 알았어야 했습니다. Fly.io는 올해 꾸준히 잘 달려왔지만, 저는 조금 타성에 젖어 회사가 해결되지 않은 정체성 위기 속에서 그을린 채 남아 있도록 내버려 두고 있었습니다.
잠시 후에 더 과하게 털어놓을 예정이지만, 궁금증만 남기고 끝내지는 않겠습니다. 그래서 말하자면, 우리는 추가로 꽤 많은 자금을 조달했습니다. Sprites의 새로운 버전을 출시하고, 회사의 초점을 그것들과 그것이 해결하는 문제에 맞추고 있습니다. 그리고 Scott Johnston을 CEO로 투입합니다.
저는 아마 이제는 더 이상 중요하지 않을 두 가지 분명한 원칙으로 Fly.io를 시작했습니다.
첫 번째는 인터넷 애플리케이션은 빠를 때 가장 잘 작동하며, 그것은 사용자 가까이에 배포될 때 가능하다는 것이었습니다. 저는 Ars Technica에서 오랫동안 일하며 이를 배웠고, Fly.io를 시작한 것도 부분적으로는 제 스스로의 갈증을 해소하기 위해서였습니다. 그것은 회사의 첫 몇 년 동안 우리의 만트라였습니다.
두 번째는 클라우드 인프라가 너무 복잡하다는 것이었습니다. 개발자에게는 AWS의 유연성과 Heroku의 사용성이 함께 있는 플랫폼이 필요합니다. Fly.io를 시작했을 때는 그 두 가지를 동시에 가질 수 없었고, 지금은 여기서도 다른 곳에서도 가능합니다.
이걸 읽으면 “당연하지, 물론 이런 것들이 중요하지”라고 말하게 됩니다. 하지만 저는 분명한 이유 때문에 그것들이 여러분이 생각하는 것보다 덜 중요하다고 말하러 왔습니다. 이제는 모두가 오직 그 이유만 이야기하니까요. AI가 소프트웨어 개발을 완전히 바꿔 놓았습니다. 딩고가 정말로 우리 아기를 먹어버린 셈입니다.
† 지난 18개월 동안, 제가 이 말을 할 때마다 그 말은 더더욱 사실이 되어 왔습니다.
제 생각에 아직 이 사실이 완전히 체감되지는 않은 것 같습니다[†]. 우리는 여전히 코딩 에이전트를 마치 충분히 똑똑한 컴파일러인 것처럼 우리 직업에 통합하려고 애쓰고 있습니다. 하지만 AI는 C 코드를 배포하던 것과 Ruby를 배포하는 것의 차이 같은 수준이 아닙니다. 훨씬 더 큽니다.
Dan Bricklin이 스프레드시트를 발명하기 전에는, 세상의 모든 “Excel 문서”가 컴퓨터 프로그래머가 만든 컴퓨터 프로그램이었다는 사실을 모두 잊고 있습니다. 불과 몇 년 만에 모든 비즈니스 전문가가 세상에서 가장 중요한 프로그래밍 언어인 스프레드시트 수식을 사용하는 프로그래머가 되었습니다. AI는 그와 비슷하지만 더 거대합니다. 아마 거의 누구나 거의 모든 종류의 컴퓨터 프로그램을 만들 수 있게 될 것입니다.
이제 전통적인 퍼블릭 클라우드 인프라를 생각해 봅시다. 우리는 엄격한 기준에 따라 까다로운 CI/CD 레일 위에서 만들어진 고정 기능 애플리케이션을 수백만 명의 사용자에게 전달합니다. 하지만 수백만 명의 사용자를 대상으로 하는 컴퓨터 프로그램은 곧 백만 명의 독자를 둔 스프레드시트와 비슷한 것이 될 것입니다. 그런 것들은 존재합니다! 하지만 일반적인 형태는 아닙니다.
2020년의 의견이 강하게 반영된 퍼블릭 클라우드 설계에 베팅하는 것은 개인화되고 적응적인 소프트웨어에 반대하는 쪽에 베팅하는 것과 같습니다. 저는 그게 좋은 베팅이라고 생각하지 않습니다. 설령 그렇다고 생각하더라도, 그런 베팅을 하고 싶지는 않습니다. 저는 제 친구들과 가족이 제가 모든 것을 대신 만들어주기를 기다리지 않고도 컴퓨터가 자신이 원하는 일을 정확히 하게 만들 수 있는 세상을 원합니다.
이제 두 번째 창업 원칙으로 넘어가겠습니다. 진지한 클라우드 인프라는 개발자들이 잘 사용하기에 너무 어렵다는 것입니다. 그리고 여전히 사실입니다! 하지만 이것도 이제는 더더욱 명백하게 중요하지 않습니다.
† 실제로는, 신중하게 다듬어진 인간 개발자 경험과 강한 기본값을 갖는 것이 이제 더 나쁠 가능성도 있습니다. 에이전트는 모든 것이 명시적일 때 가장 잘 작동합니다.
대략적으로 말해, 이제는 아무도 문서를 읽지 않습니다. 새로운 CLI를 익히고 시행착오로 사용법을 파악하는 일도 하지 않습니다[†]. 그게 바로 에이전트의 역할입니다. 에이전트는 Fly.io 배포를 한 번에 끝낼 수 있습니다. 로컬에서 사이트를 만들고 “이제 이걸 Fly.io에서 돌아가게 해”라고만 하면 훌륭하게 작동합니다. 하지만 에이전트는 AWS 배포도 한 번에 끝낼 수 있습니다. 우리는 여기서 뭘 하고 있는 걸까요? 무슨 일이 벌어지고 있는 걸까요?
저는 작년에 가장 빠르게 성장하는 고객이 모두 로봇이었다는 글에서 이 이야기를 쓴 적이 있습니다. 그리고 나서 우리가 이미 만든 것을 사후적으로 끼워 맞추는 일을 멈추고, 로봇 고객이 실제로 원하는 것이 무엇인지 파악하는 데 착수했습니다. 제가 도달한 결론은 이렇습니다.
첫째: 코딩 에이전트는 개발자 워크스테이션에서 실행되기를 기대합니다.
둘째: 신뢰할 수 있는 샌드박스 안이라고 해도, 물리적인 개발용 노트북에서 에이전트를 돌리는 건 짜증납니다. 노트북은 뚜껑을 닫으면 멈추기 때문입니다. 올해 MacBook을 펼친 채로 계단을 오르내린 적 있는 분, 손 들어보세요. 손이 안 올라가 있나요? 아마 집에 계단이 없을 겁니다. 그래서 결국 사람들은 모두 클라우드에서 에이전트 샌드박스를 돌리게 됩니다.
셋째: 퍼블릭 클라우드는 에이전트를 실행하기에 성가신 장소입니다. 우리는 서버를 “반려동물”이나 “가축”으로 나누어 말하지만, 에이전트에게는 가축 떼의 소 한 마리조차도 너무 큰 헌신입니다. 그러니까, 잘 모르겠지만, 반쯤 일회용인 소가 필요합니다. 정확히 원할 때 존재하게 되고, 정확히 원하는 만큼만 남아 있고, 비용도 많이 들지 않는 소 말입니다. 그래서 비유는 쓰기 어려운 겁니다.
올해 초, 우리 팀은 시스템 엔지니어링, 어쩌면 컴퓨터 과학 전체에서 하나의 돌파구라고 제가 믿는 것을 만들어냈습니다. 우리는 반쯤 일회용인 소를 출시했습니다. 우리는 그것을 Sprites라고 부릅니다.
Sprites는 제가 보기에 로봇들이 찾고 있는 것에 딱 맞게 수축 포장한 결과, 다소 이상한 형태를 갖게 되었습니다. 수백 개, 수천 개를 빠르게 만들 수 있지만, 그 모두가 100GB의 영구 디스크 드라이브를 가지고 있습니다. 클라우드의 모든 것처럼 사용량 기반 과금이 적용되지만, 아무 일도 하지 않을 때는 계량기가 돌아가지 않고, 언제 유휴 상태인지도 영리하게 판단합니다. 그리고 그 위에 앱을 호스팅해 인터넷을 통해 동료들과 공유할 수 있습니다.
이런 특징들의 잡동사니는 에이전트에 관한 하나의 제안으로 이어집니다. 업계는 샌드박스에 집착합니다. 하지만 로봇은 샌드박스를 원하지 않습니다. 그들이 원하는 것은 컴퓨터입니다. 우리의 반쯤 일회용인 소가 바로 그것입니다. 에이전트를 위한 컴퓨터 말입니다.
정말, 1분 정도밖에 안 걸립니다 ✨
저는 Sprites 출시가 전개된 방식이 마음에 듭니다. 하지만 솔직히 말해, Sprites는 비밀 프로젝트였습니다. 메인 Fly.io 웹사이트에조차 호스팅하지 않았으니까요! 이상한 선택이었습니다. 합리화하려는 건 아닙니다. 우리는 정체성 위기 한가운데 있었습니다. 하지만 이제 구름은 걷혔고, 앞으로 에이전트를 위한 컴퓨터가 우리 회사의 초점이 됩니다.
† (이게 얼마나 사실인지 감을 드리자면: 전체 코드베이스에 git blame을 돌려 보면 제 이름이 누구보다도 많이 나옵니다)
Fly Machines와 우리의 Platform As A Service 기능들이 사라지는 일은 없습니다. 하지만 Sprites는 Fly.io 내부의 아주 작은 최소 인원 팀이 만든 제품이었고[†], 이제는 더 이상 그렇지 않습니다.
보통이라면 우리가 출시한 어떤 신제품이든 그것을 어떻게 만들었는지에 대해 수천 단어짜리 심층 기술 글을 썼을 것입니다. Sprites도 그렇게 할 예정입니다. 하지만 저는 이미 이 글을 꽤 길게 썼고, 나눌 다른 이야기들도 있습니다. 그래서 지금은 짧게 하겠습니다.
확장성과 오케스트레이션에 관해 우리가 해온 막후 작업에 더해, 새로운 Sprites는 우리가 하려는 일에 대해 드디어 “기능 완성형”이라고 부를 만한 수준에 이르게 해주는 두 가지 큰 하위 시스템을 도입합니다.
첫 번째는 Sprite Block Device(SBD)입니다. 원래 Sprites 저장소 스택은 제가 JuiceFS에서 개인적으로 파생시켜 Ben Johnson의 Litestream을 이용해 우리 시스템에 연결한 도깨비 같은 장치였습니다. Ben과 Tim Newsham이 그 전체 스택을 뼈대만 남기고 뜯어낸 뒤 다시 지었다는 소식을 듣고 여러분도 기뻐하실 겁니다. 더 빠르고, 더 신뢰할 수 있으며, 여전히 즉시 체크포인트 및 복원을 수행합니다.
더 중요한 것은, SBD가 드라이브 포킹을 가능하게 한다는 점입니다. 템플릿 Sprite를 하나 만든 뒤, 그것을 효율적으로 수백만 번 복제할 수 있습니다.
Sprites의 또 다른 큰 새 요소는 Connectors입니다. Connectors는 핵심 플랫폼을 보호하기 위해 우리가 해온 작업을 바탕으로 합니다. 이것은 Sprites가 에이전트에게 빼돌릴 만한 유용한 것을 주지 않으면서도 다른 시스템에 인증된 요청을 보낼 수 있게 해줍니다. Connectors는 재미있는 보안 특성을 갖고 있을 뿐 아니라, 계정과 API 키를 수동으로 관리하는 것보다 훨씬 더 사용하기 편합니다.
이것들은 우리가 가장 많이 요청받은 기능들입니다. 우리가 이들을 위해 특별한 제품을 출시한 지 여러 달이 지났는데도 많은 에이전트 회사들이 여전히 Fly Machines를 쓰고 있는 이유이기도 합니다. 그래서 저는 충분히 자신 있게 이렇게 베팅할 수 있습니다. Transformer 모델이 컴퓨터 과학에 한 일보다 더 기묘한 일을 하는 새로운 우주 외계 기술 같은 것이 등장하지 않는 한, Sprites는 미래의 고객들, 그리고 기존 고객의 아주 큰 부분에게도 올바른 선택입니다. 그리고 이야기는 여기로 이어집니다.
스스로를 복제할 수 있는 이상한 베타 Sprite를 원하시나요? 발가락 하나쯤은 구해드릴 수 있습니다.✨
이 일은 어느 정도 예고되어 왔지만, Fly.io가 지금 있는 단계에서는 제가 CEO로 있으면서 뽑아낼 수 있는 좋은 것들은 대부분 다 뽑아낸 것 같습니다. 그래서 저는 그 일을 그만두려 합니다.
스타트업의 첫 몇 년 동안은 과학 프로젝트를 운영하게 됩니다. 제품-시장 적합성을 찾기 위한 실험 주도형 탐색입니다. 여기서 일해본 사람이라면 누구나 증언하겠지만, 우리는 비관리형 Postgres(절대 하지 마세요)부터 글로벌 CDN과 사용자 모드 WireGuard까지 수십 가지를 시도했습니다. 회사의 더 깊은 조직 구조 안에서는, 아래에서 위로 올라오는 엔지니어링 조직을 만들고, 제품 로드맵을 피했으며, 12개국이 넘는 나라에 구성원이 있는 완전 원격 팀을 꾸렸습니다.
어떤 실험은 성과를 냈고, 어떤 실험은 학습 기회였습니다. 지난 8년 동안 그것들을 운영하는 일이 제 인생의 전부였습니다. 하지만 Fly.io에는 이제 이런 종류의 과학 프로젝트가 더 이상 필요하지 않습니다.
지난 여러 달 동안, 거슬러 올라가면 2025년까지 이어지도록, 저는 Scott Johnston과 Fly.io가 그가 플레이를 지휘한다면 어떤 모습일지에 대해 이야기해 왔습니다. Scott은 Docker의 CEO였고, Docker 자체의 엔터프라이즈 대 개발자 정체성 위기로 시작해 사업의 문을 완전히 날려버리는 결과로 끝난 매우 어려운 시기를 이끌었습니다. Fly.io의 주주로서 저는 Fly.io의 현재 생애 주기 단계에서는 제 플레이북보다 그의 플레이북이 더 마음에 들었습니다. 그리고 Fly.io의 CEO로서 저는 이 일을 그가 하는 전망이, 제가 하는 전망보다 더 마음에 들었습니다. 우리는 이 문제를 풀어내는 데 많은 시간을 썼고, 결국 이사회와 저는 그가 이 일을 맡도록 설득했습니다.
이런 종류의 글에서 이 문단은 보통 제가 Scott이 왜 Fly.io에 완벽하게 맞는 사람인지 말하고 그의 지난 모험들을 되짚어야 하는 부분입니다. 실제로도 그는 그렇고, 그의 경력은 장엄했습니다. 하지만 여러분은 여기서 제가 무슨 말을 할지 이미 알고 있습니다. 그래서 재미가 없습니다. Scott은 원할 때 자기 소개를 아주 잘할 수 있습니다. 부끄러움도 없는 사람이고요.
그 사이 저는 지쳐 있는 창업자 CEO들이 다들 현명하게 하듯이, 제품 디자인 논의에 무작위로 낙하산 투입되는 자문 역할로 옮길 것입니다. 그건 제 일에서 재미있는 부분입니다. 동시에 이사회 의석을 이용해 Scott을 귀찮게 할 겁니다. 그가, 저에게는 재미없던 제 일의 부분을 저보다 더 잘 해낼 테니까요.
Scott이 분명 자세히 설명하게 될 것 중 하나는 우리가 방금 진행한 자금 조달입니다. 그것도 Theo Browne가 자기 영상에서 지적한 부분이었습니다(저 화 안 났습니다, 화난 것처럼 들리나요?). 몇 년 동안 신규 투자 유치 발표가 없었다는 거죠. 답은 이렇습니다. 우리는 엄청나게 많은 돈을 조달했고, 더 필요하지 않았습니다. 원래 계획만 고수하고, AI가 땅을 갈라 우리 모두를 통째로 삼켜버리지 않는다면, 우리는 아예 추가 자금이 영원히 필요 없을 수도 있는 경계선에서 운영해 왔습니다. 하지만 당연히, 이제 그건 더 이상 우리의 게임 플랜이 아닙니다.
솔직히, 이 글이 어떻게 받아들여질지 저도 압니다. 누구도 화나게 하지 않고 이 글을 쓸 수도 있겠지만, 그러면서도 읽을 가치가 있게 쓰는 방법은 모르겠습니다.
우리는 업계의 미래에 대해 아주 구체적이고, 아마도 논쟁적인 베팅을 하고 있습니다. 몇 년 안에 에이전트가 거의 모든 소프트웨어가 어떻게 만들어지고 배포되는지를 결정하게 될 것이라는 베팅입니다. 소프트웨어는 훨씬 더 개인적이 되고, 대상 사용자는 더 작아지며, 훨씬 더 유연하고 미끄럽게 변할 것입니다.
저는 이 모든 것이 기대됩니다. 이런 전환기 동안 이 분야에서 일할 수 있다는 사실이 조금은 얼떨떨하기도 합니다. 하지만 그런 전환이 이 분야의 다른 전문가들을 얼마나 불편하게 만드는지 보지 못할 정도로 둔감할 수는 없습니다.
연중반쯤에 우리는 두 갈래 길 중 하나를 택할 수 있었습니다.
스타트업에서 가장 위험한 다섯 단어 중 하나는 “¿Por qué no los dos?”입니다. 우리는 둘 중 하나를 합니다. 둘 다 어정쩡하게 끌고 가지는 않습니다. 그리고 실패한다면, 온전히 우리 엉덩이 전체를 걸고 실패합니다. 다만 앞으로는 제 엉덩이의 대부분만 걸리겠지만요.
Fly.io의 현재 단계에서 팀과 회사, 고객 기반의 방향타를 잡는다는 건 엄청난 일입니다. 우리는 몇 달 동안 우선순위에 대한 큰 결정을 미뤄왔습니다. Theo, 당신은 그걸 알아챘더군요. 좋은 지적이었습니다! 저는 더 빨리, 더 분명하게 결정할 수도 있었습니다. 대신 Sprites를 출시했죠. Sprites는 우리 앞에 놓여 있던 질문에 대한 답입니다. 그것들을 만드는 데 시간을 쓴 것이 기쁘고, Scott을 영입해 그것들을 우리의 핵심 사업으로 바꾸게 된 것도 기쁩니다.
