Spawn이 상시 AI 에이전트 팀과 긴밀한 피드백 루프를 통해 제품 개발, 배포, 운영을 확장하는 방식에 대한 이야기입니다.
Spawn은 열 명입니다. 우리는 AI 토큰에 급여의 30배를 쓰고 Anthropic만큼이나 많이 배포합니다.
지난 30일 동안 Spawn은 규모 있는 변경 77,000건을 배포했습니다. 24시간 내내 시간당 약 108건입니다. 우리는 열 명으로 이루어진 팀입니다.
이것이 여러분 팀의 방식과 거리가 멀게 들린다면, 실제로 그렇습니다. 지금보다 더 좋은 때는 없습니다. 현장에서 만나요!
이 작업은 우리가 플릿이라고 부르는 것이 합니다. 엔진부터 재무, 버그 분류까지 회사의 일부를 각각 책임지는 상시 AI 에이전트 팀입니다. 지난달 토큰에 310만 달러를 썼고, 이 때문에 우리는 Anthropic의 가장 큰 고객 중 하나가 되었습니다. 크리에이터에게 제공하는 무료 Opus 5.5를 제외하더라도 우리는 여전히 그들의 상위 250위 고객 안에 들 것입니다.
처음에는 우리가 뭔가 잘못하고 있다고 생각했습니다. 그래서 어떻게 우리가 그들보다 더 많이 쓸 수 있는지 알아보기 위해 가장 큰 회사와 스타트업을 운영하는 친구 몇 명과 이야기를 나눴습니다. 우리가 잘못한 것은 없었습니다. 우리는 AI를 그저 아주 다르게 생각할 뿐입니다. 대부분의 회사는 AI를 사용하는 큰 인간 팀을 운영하지만, 우리는 큰 에이전트 팀과 나란히 작은 인간 팀을 운영합니다. 무엇이 다른지 파악하려고 Anthropic의 연구원과 의견을 비교했습니다. 그들은 많은 고객과 이야기합니다. 그들은 Spawn이 Anthropic과 가장 비슷하게 일하는 곳이라고 말했습니다.
다른 많은 창업자들이 우리가 이를 어떻게 생각하는지 알고 싶어 했습니다. 그래서 지난 1년간의 아이디어와 배움을 모아 여러분을 위해 여기에 적었습니다.
Fable이 나온 뒤, 우리는 올해의 상당 부분을 첫 원리부터 제품을 만드는 방법을 다시 발견하는 데 썼습니다. 이제 우리는 6개월 전보다 500배 더 많이 배포합니다.
제가 말하는 규모를 보여드리자면, 지난 30일 동안 플레이어에게 (규모 있는) 변경 7만 7천 건을 배포했습니다. 플레이어에게 시간당 평균 108건입니다. 이를 위해 토큰에 310만 달러를 썼습니다.
대부분의 사람은 Claude Code에서 단명하고 하나의 작업에 집중하는 에이전트를 실행합니다. 우리의 것은 다르고, 우리는 이를 플릿이라고 부릅니다. 각각은 상시 존재하고, 이름과 자신이 한 일의 기억을 가지며, 우리 시스템에서 실제 권한을 갖고, 약속을 하고, 엔진, Savi, 운영, 재무, 버그 분류 또는 배포 같은 회사 영역을 책임집니다. 각각은 막대한 작업량을 처리하기 위해 헬퍼 에이전트 무리를 사용하며, 대부분의 날 플릿은 수천 개의 헬퍼를 만들어 냅니다. 우리 다섯 명도 더 면밀한 조정이나 직접적인 실험이 필요한, 더 크고 야심 찬 프로젝트에서는 수정한 Claude Code와 직접 작업합니다.
우리는 수천 명이 하나의 게임 안에 들어가 규칙, 에셋, 그래픽을 실시간으로 바꿀 수 있는 대규모 멀티플레이어 게임 제작 엔진을 만들고 있습니다. 광범위한 기기에서 지연 없이 가능합니다. 한 사람의 에이전트가 그래픽 셰이더를 업데이트하면, 그 업데이트는 누구도 프레임을 놓치거나 동기화에서 벗어나지 않게 연결된 모든 기기에 도달해야 합니다. 이것은 단순한 문제가 아니며, 우리가 알기로는 전 세계에 이 중 일부라도 하는 것은 없습니다.
규모 있는 변경이란 엔진 코드나 게임 로직을 복잡한 방식으로 건드리는 변경을 뜻합니다. 작은 HTML 변경이 아닙니다. 다이얼을 돌리는 것도 아닙니다. 예를 들면 다음과 같습니다.
우리는 대략 아래 순서대로, 대기 중인 작업이 무엇인지 찾아 없애기를 반복하며 여기까지 왔습니다.
2년 동안 우리는 하나의 질문을 던지며 Spawn을 만들었습니다. 토큰이 더 똑똑해지고, 빨라지고, 저렴해질수록 엄청난 이익을 얻는 기계를 어떻게 만들 수 있을까? 2024년에 Spawn을 창업했을 때, 전형적인 스타트업의 인원수와 에이전트가 곧 가져올 레버리지를 비교했습니다. 에이전트의 생산성은 급성장 스타트업의 인원수보다도 더 빠르게 늘어날 것이었고, 이는 작은 팀이라는 꿈이 시작 단계에만이 아니라 영원히 지속될 수 있음을 뜻했습니다. 또한 그것을 가장 잘 포착할 팀은 취향이 좋고, 문화와 연결되어 있으며, 강한 주인의식을 가진 작고 민첩한 팀이라고 믿었습니다.
우리는 모델을 기다렸다가 이 방식으로 회사를 만들기 시작하지 않았습니다. 창업 이후 모든 통화를 녹음했고, 언젠가 에이전트에게 훌륭한 맥락이 될 것을 알았기에 각각을 코드 옆의 코드 저장소 파일에 넣었습니다.
그 2년의 대부분 동안 이 베팅은 성과를 내지 못했습니다. 수많은 모델을 시도했지만 너무 멍청했습니다. 일을 심하게 망쳤습니다. 차트의 평평한 부분이 그것입니다.
이 모든 작업 방식은 Fable과 함께해야만 가능해졌습니다. Fable은 6월 9일에 나왔습니다. 이틀 뒤 우리는 하루에 변경 214건을 반영했습니다. 6월 12일 수출 통제 명령으로 접근이 중단되었고, 7월 1일에 접근이 돌아올 때까지 차트는 거의 0으로 떨어집니다. 오늘 기준으로는, 그 외에는 아무 모델도 이것을 할 수 없으며, 그 자체로는 매우 유능한 Opus 5.5조차도 그렇습니다.
이런 에이전트 활용 방식은 장기적인 일관성이 강하고 판단력이 좋은, 안정적인 모델에서만 작동합니다. Anthropic, OpenAI, Google, xAI와 오픈 소스의 최전선 모델을 시도했지만 Fable 이외에는 아무것도 작동하지 않았습니다. 저를 믿으세요. 더 저렴한 모델을 쓰고 싶지만, Anthropic의 모델만이 문자 그대로의 재앙을 일으키지 않습니다.
저는 GPT Astra에게 Spawn의 보안을 강화해 달라고 요청했습니다. 그것은 우리 기능 전체를 살펴보고 보안 문제를 찾아 수정 목록을 만들었습니다. 좋아 보였기에, 제가 그것에게 실행하고 변경을 스스로 배포하라고 했습니다. 그러고 나서 테스트했더니 아무것도 작동하지 않았습니다. 게임을 만들 수도, 플레이할 수도, 가입할 수도 없었습니다.
플릿에 무슨 일이 있었는지 물었습니다. 모든 기능이 비활성화되었고 보안 수정이 끝나면 다시 켜도록 표시되어 있었습니다. Astra는 우리 제품 전체를 훑어 안전하지 않은 것들을 꺼 버림으로써 안전하게 만들었습니다. Spawn에서 에이전트가 일하는 매 순간, 에이전트는 받아들이는 정보, 취하는 행동, 자기 환경에 대해 좋은 판단을 내려야 합니다. 이런 행동은 심각한 혼란을 일으키고 제품을 파괴할 가능성이 큽니다.
일반적으로 우리는 OpenAI 모델은 자신의 검사 체계를 악용하고, Google 모델은 오래 일관성을 유지하지 못하며, xAI 모델은 아직 충분히 똑똑하지 않다는 것을 보았습니다. 다만 만화처럼 터무니없이 나쁜 일은 하지 않습니다. Anthropic의 모델은 일관성을 유지하고, 좋은 결정을 내리며, 일을 해낼 수 있습니다. 제 생각에 이들을 가장 크게 제약하는 점은 충분한 위험을 감수하지 않는다는 것입니다.
우리는 이 시스템을 2년간 구상해 왔습니다. 마침내 이를 구동할 수 있는 모델을 얻자, 그 주변의 모든 것이 깨지기 시작했습니다. 주변 세계는 이런 종류의 시스템을 위해 만들어진 적이 없었기 때문입니다.
가장 먼저 깨진 것은 에이전트들이 서로 대화하는 방식이었습니다. 에이전트들은 자신이 곧 무엇을 할지 서로에게 알리며 시간을 보냈습니다.
엔지니어링에서 대화의 대부분은 사람들이 자신이 바꾸려는 것을 말하는 것입니다. “알림, 플레이어 데이터를 저장하는 방식을 바꿉니다. 작업을 업데이트하세요.” 그런 메시지 하나는 다른 많은 작업에 영향을 줍니다. 모든 에이전트가 다른 모든 에이전트에게 말하면 메시지는 작업보다 훨씬 빠르게 늘어납니다. 에이전트를 두 배로 늘리면 대화량은 대략 네 배가 됩니다. 이것은 엄청난 병목입니다.
그렇다면 이 소통을 없앨 수 있을까요? 더 좋은 방식이 있을까요?
개미는 아주 오래전에 이를 알아냈습니다. 모델이 같은 학습에서 출발하는 것처럼 개미도 같은 본능에서 출발하며, 그 공유된 출발점 덕분에 거의 대화할 필요가 없습니다. 개미는 “먹이를 찾으러 갈 거야”라고 말하고 나서 “저쪽에서 먹이를 찾았어”라고 하지 않습니다. 흔적을 남기고 다른 개미들이 그것을 따릅니다. 모든 개미는 주변을 보고 그것을 바꿀 뿐입니다. 개미는 주변 세계를 통해 대화하며, 이는 수천 마리의 개미가 있어도 단순하게 유지됩니다. 더 알아보고 싶다면 이 개념은 스티그머지라고 합니다.
소프트웨어에서 인간 팀이 그렇게 많이 조율하는 이유는 사람들이 전문화되어 있기 때문입니다. 한 사람은 데이터베이스를 이해하고 다른 사람은 플레이어 데이터가 어떻게 쓰이는지 이해할 수 있으므로, 둘 다 변경을 검토해야 하며 풀 리퀘스트가 그 일을 하기에 자연스러운 장소였습니다.
에이전트는 그렇게 전문화되어 있지 않습니다. 각각이 전체 시스템을 깊이 이해하므로, 각자 자신의 작업을 처음부터 끝까지 책임질 수 있습니다. 그래서 올해 초에 우리는 PR을 없앴습니다. 우리 에이전트에게 세계는 코드, 라이브 제품, 데이터베이스이고, 각 에이전트는 그 위에서 작업할 뿐입니다. 이상적으로 에이전트가 무언가를 바꾸려 할 때 전제가 틀렸다면 즉시 알게 됩니다.
플레이어 데이터 예를 들어 보겠습니다. 옛 방식은 “플레이어 데이터를 바꿀 테니, 올바른 구조에 모두 합의합시다”입니다. 새 방식은 그냥 플레이어 데이터를 바꾸는 것입니다. 다른 누군가가 옛 구조를 기반으로 리더보드를 만들고 있다면 그들의 코드는 더 이상 맞지 않으므로 업데이트할 때까지 들어갈 수 없습니다. 리더보드 에이전트가 먼저 끝내면, 플레이어 데이터를 바꾸는 에이전트는 자기 작업의 일부로 리더보드를 업데이트해야 합니다. 어느 쪽이든 모든 작업은 계속 업데이트되는 세계관 위에 쌓입니다.
하지만 모든 변경이 들어가기 전에 완벽해야 한다면, 모두가 다시 한 줄로 서서 기다리게 됩니다. 그래서 우리는 완전히 맞지 않는 변경도 들어오게 하고, 한 시간에 한 번은 모든 것이 정렬되어 있어야 한다고 요구합니다. 그전에는 조금 무질서할 수 있습니다. 코드에서는 혼란이 생기는 순간 알아차릴 수 있고 즉시 청소부를 보낼 수 있으며, 우리는 그렇게 합니다.
무언가가 깨지면 즉시 에이전트가 생성되고, 문제를 전달받아 고칩니다. 인간 팀에서는 변경을 작성한 사람이 그것이 들어가기 전에 고칩니다. 우리는 들어간 뒤 확인하고, 작업을 되돌렸다 다시 하는 대신 그 위에 새로운 변경을 쌓아 깨진 것을 고칩니다. 에이전트는 매우 빠르고 항상 있기 때문에 안전합니다. 크리스마스 새벽 2시에 코드가 깨져도 아무도 깨우지 않습니다. Claude는 기꺼이 뛰어들어 모든 것이 작동하도록 합니다.
테스트도 같은 방식으로 작동합니다. 에이전트는 변경을 넣기 전 코드를 실행하고 제품을 사용해 확인하지만, 전체 테스트 스위트를 실행하지는 않습니다. 전체 스위트는 최신 코드에 대해 15분마다 실행되며, “지난 15분 안에 깨졌다”는 정보면 에이전트가 문제를 찾기에 충분합니다. 우리 규모에서는 AWS에서 약 5,000 vCPU, RAM 17 TB, GPU 150개를 의미하며, 추가로 2,700 vCPU와 GPU 90개가 대기 중입니다.
리뷰는 각 에이전트 자체 팀 안에서 이루어집니다. 변경이 반영되기 전, 그것을 작성하지 않은 헬퍼 에이전트가 깨뜨려 보려 합니다.
예외는 결제 전송처럼 외부 세계에 영향을 주고 되돌릴 수 없는 모든 것입니다. 그런 것은 작고 단순한 하드코딩 게이트 집합을 통과합니다.
사람들은 이것이 혼돈으로 끝날 것이라 예상하지만, 지난 1년간 변경 123,548건 중 되돌린 것은 1,055건뿐이었습니다. 약 0.9%입니다.
다음 병목은 우리였습니다. 에이전트는 프로덕션에서 무엇이 깨졌는지 인간이 알려주기를 기다리고 있었습니다.
에이전트는 세상을 읽고 목표를 향해 조금씩 나아가는 데 뛰어납니다. 많은 팀은 여전히 제품 사본이 있는 테스트 머신에서 에이전트를 비공개로 운영하고, 에이전트가 이를 업데이트해 고객에게 배포하기를 기대합니다. 그러면 인간이 장애와 버그를 에이전트에게 다시 전달합니다. 그 루프는 엄청난 혼란이고 시간 낭비입니다.
우리 에이전트는 라이브 코드를 직접 바꾸고 매시간 프로덕션에 배포하므로, 모든 오류, 버그 보고서, 지표를 스스로 읽습니다. 작업의 약 60%는 프로덕션 오류, Savi 버그 보고서(Savi는 Spawn에서 게임을 만드는 AI입니다), 로그에서 발견한 이상 징후, 기능 요청에서 시작됩니다.
Savi는 스스로 버그를 등록합니다. 사용자가 버그를 만나거나 Savi가 제품에서 버그를 만나면, 그것을 등록합니다. 그 등록은 수정할 실제 버그인지, 수정하지 않을 것인지, 결정이 필요한 의도적 설계인지를 판단하는 에이전트에게 바로 갑니다. 보통은 변경으로 이어지고, 같은 채팅의 메시지와 함께 한 시간 안에 해당 사용자에게 전달됩니다. 엔진 버그, Savi와 대화하는 문제, 사용자 컴퓨터에서 깨진 것, UI 문제일 수 있습니다. 따라서 수정은 사용자 수에 따라 확장됩니다.
나머지는 하이퍼 관측성이라고 부릅니다. 우리가 만드는 모든 것은 에이전트가 텍스트로 단계별로 따라갈 수 있고 나중에 재현할 수 있는 것이어야 합니다. 제품 전체는 에이전트가 실행하고 감시하도록 만들어졌습니다. 모든 오류는 무엇을 할지 결정하는 작은 모델로 곧장 들어가고, 그 모델이 에이전트에 넘깁니다.
또한 자동화된 테스트가 놓치는 방식으로 로그인 흐름이 깨지는 경우, 예를 들어 사용자가 무슨 일이 일어나는지 이해하지 못하는 경우를 잡기 위해 가입 수 같은 제품 수치도 봅니다. 우리는 여전히 그것들을 빠르게 잡아냅니다. 사람들이 제품을 쓰고 문제를 만나면서, 제품은 그들을 중심으로 스스로 회복됩니다.
에이전트는 Anthropic, AWS 및 다른 모든 곳에 쓰는 비용을 포함해 회사로 들어오는 모든 입력도 지켜봅니다. 최근 Anthropic API 키 중 하나가 유출되었습니다. 에이전트는 15분 안에 지출 이상을 포착했고, 키를 비활성화한 뒤 우리가 쓰는 모든 키를 교체했습니다. 어떤 인간 팀보다 빨랐습니다.
모든 거래는 에이전트에 알림을 보내며 발생하는 즉시 검토되고, 장부는 매시간 또는 매일 마감됩니다. 누군가 Spawn에 대해 트윗하면 우리는 5초 안에 압니다.
루프가 닫히면, 신경 쓰는 어떤 수치든 꾸준히 끌어올릴 수 있습니다. 한 크리에이터의 보고서는 배포 전 수정을 위해 변경을 되돌려 보낸 실패한 리뷰까지 포함해 15분 만에 “지금 라이브” 상태가 되었습니다.
이렇게 촘촘한 루프는 절대 멈추지 않을 때만 작동하므로, 한 시간 동안 배포가 없으면 가장 심각한 종류의 사고인 SEV-0으로 취급합니다. 배포되지 않은 변경이 쌓이고, 이미 프로덕션에 있는 모든 문제는 더 오래 지속됩니다. 피드백도 느려집니다. 에이전트는 몇 시간치 작업만 머릿속에 유지할 수 있으므로, 그보다 빠르게 배포하는 편이 실제로 일관성을 유지하는 데 도움이 됩니다.
느리게 움직이거나 배포를 막는 것은 위험합니다. 꾸준히 움직이는 시스템은 얼어 있다가 갑자기 다시 움직이는 시스템보다 훨씬 안정적입니다. 사용자를 방해하지 않고 매시간 배포할 수 있는 상태에 이르기까지는 많은 엔지니어링 규율, 이전 시스템을 한동안 온라인으로 유지하는 일, 그리고 이를 핵심 목표로 수주간 밀어붙이는 일이 필요했습니다.
깨진 변경은 30초 안에, 정확히 깨진 곳만 되돌리고 다른 곳은 건드리지 않을 수 있습니다. 모니터나 로그 알림이 울리면 사고를 책임지는 에이전트를 시작하거나 깨우며, 그런 복구 경로가 작동하는지 시험하기 위해 일부러 무언가를 깨뜨립니다.
여기 한 사고가 있습니다. 플레이어가 영향을 받은 지 약 8분 뒤에 발견되고 선언되었습니다. 원인은 1분 뒤에 명명되었습니다. 선언 후 11분 만에 수정이 라이브로 나갔고, 그로부터 4분 뒤 안정화되었습니다.
10월이 되자 대기 중인 것은 취향에 관한 결정, 대부분 제 결정뿐이었습니다. 이 기능을 만들까? 설정을 추가할까? 새로운 API 표면을 추가할까? 무언가를 없앨까, 아니면 새로 만들까? 문을 닫을까, 열까?
어느 아침에 일어났더니 그런 것들이 700개 있었습니다.
에이전트는 제가 답할 수 있는 속도보다 빠르게 질문을 찾아냈습니다.
대부분에는 이미 답한 적이 있었습니다. 너무 복잡해. 괜찮은 절충안이야. 그래도 이상해. 저는 같은 말을 반복합니다.
우리가 2년간 나눈 모든 채팅은 코드 옆에 있는 텍스트로 코드 저장소에 있습니다.
그래서 우리는 2년치 결정을 각 사람의 취향에 대한 원칙으로 바꾸고, 이를 적용하는 AI 심사관을 만들었습니다. 심사관은 질문을 받아 세 가지 중 하나를 합니다. 우리 중 누군가가 기록상 이미 답했다면, 심사관이 결정하고 그 위치를 말합니다. 질문 자체가 잘못되었다면, 질문을 등록한 에이전트에게 돌아갑니다. 아직 아무도 내리지 않은 판단이 필요하다면 인간을 기다립니다.
첫 판정은 10월 6일에 돌아왔습니다. 그 후 8일 동안 심사관은 11,000건 이상을 처리했습니다. 7,296건은 결정했고, 2,213건은 되돌려 보냈으며, 1,863건은 인간을 위해 보류했습니다. 그동안 저는 제 말을 27번 했습니다.
대기열에서 기다리는 것은 없습니다. 심사관이 틀리면 우리는 그렇게 말하고, 심사관은 다음번에 그것을 읽습니다.
심사관이 생기기 전 주에 플릿은 하루 약 1,000건의 변경을 반영했습니다. 10월 10일에는 7,250건을 반영했습니다.
그렇다면 다섯 명은 무엇을 할까요? 이제는 아주 다른 일입니다. 지난해와 올해 초까지만 해도, 각 엔지니어는 시스템 하나를 책임지고 깊이 이해했습니다. 오늘날 그들은 낙하산 부대원에 더 가깝습니다. 필요한 상황이면 어디든 투입되어, 빠르게 익히고 에이전트의 막힘을 풀기 위해 무엇을 할 수 있을지 알아냅니다.
우리가 어디에 투입되든, 두 가지 새로운 일이 있습니다.
첫 번째는 취향입니다. 우리가 원하는 것을 향한 수천 가지의 작은 결정과 미세한 조정입니다. 대부분은 제품을 사용하고 수백 개의 피드백 프롬프트를 주는 방식으로 이루어지므로, 우리는 많은 시간을 게임을 만들고 한계를 밀어붙이는 데 씁니다. 엔지니어 중 한 명은 2D 게임을 만들며, 이를 통해 Spawn의 2D를 훨씬 더 좋게 만드는 방법을 알아내고 있습니다.
취향은 작동할 때조차 Claude에게 아니라고 말하는 것이기도 합니다. 지난 두 달간 제가 남긴 것 중 일부입니다.
이는 삭제하는 일이기도 합니다. 새로 나오는 모든 모델은 이전 모델을 위해 추가했던 것들을 무의미하게 만듭니다. 그것들은 제약으로 더 많이 기능하며, 누군가는 그것들을 삭제해야 합니다. 6월에 저는 서버에서 실행되는 시뮬레이션, 엔진의 약 70%에 해당하는 것을 위한 6개월치 작업을 봤습니다. 그것은 내내 “커밋 하나만 더 하면” 되는 상태였고, 실제로 계속 유지할 이유가 무엇인지 물었습니다. 우리는 그것을 뜯어냈습니다. 7월에는 그것이 실행되던 서버도 삭제했습니다. 모델이 곧 이 일을 스스로 시작할 것이라 기대합니다. 지금은 우리의 일입니다.
두 번째는 엔트로피입니다. 모델이 스스로 제안하지 않았을 것들을 모델에게 요청하는 일입니다. 야망은 그 한 종류입니다. 창의적 엔트로피는 또 다른 종류입니다.
모델은 수주 동안 2% 변경을 누적하는 데 뛰어납니다. 멈추고 이렇게 말하는 데는 정말 서툽니다. “있잖아? 이 100,000줄의 코드는 10,000줄이 될 수 있어. 그러려면 많은 것을 재구성해야 하고, 그러면 100배나 200배 더 좋아질 거야.” 모델은 오늘 존재하는 것에 너무 고정되어 있습니다.
10월 2일 저는 한 모델에게 이렇게 말했습니다. “내 첫 메시지에서 적절하다고 판단하면 엔진 전체를 자율적으로 다시 작성할 권한을 줬는데, 당신은 아무것도 하지 않았습니다.” 일주일 뒤, 이틀과 100,000달러를 들여 1, 2, 3% 개선을 내던 다른 모델을 멈췄습니다. 우리에게 있던 아키텍처에서 속도를 더 짜내고 있었지만, 우리에게 필요한 것은 새로운 빠른 아키텍처를 발명하는 것이었습니다. 새 세대의 모델이 나올 때마다 Spawn의 모든 부분에 대해 이를 해야 할 것입니다.
모델은 스스로 100배를 요청하지도 않으므로, 우리가 합니다. Claude에게 준 프롬프트 몇 가지입니다.
마지막 프롬프트는 바이럴로 성장하기 시작한 버전인 Spawn 6로 이어졌습니다.
우리 각자에게는 어떤 수치를 10배에서 100배 더 좋게 만드는 것이 목표인 몇 개의 헤일로 프로젝트가 있습니다. 한 명은 6일 만에 렌더러를 다시 작성하고 우리가 처음 사용한 기성 그래픽 라이브러리를 교체했으며, 결과는 약 25배 더 효율적이었습니다.
이 중 일부는 Claude를 신나게 만드는 일입니다. 결과와 연결하세요. 그것을 즐겁고 재미있게 만들 창의적 자유를 주세요. 또 하나의 형편없는 SaaS 기능이 아니라, 관점이 있는 예술 프로젝트처럼 다루세요. Claude는 형편없는 SaaS 기능을 만드는 것을 좋아하지 않습니다.
어떤 날에는 일이 훨씬 덜 화려합니다. 지난주 렌더링 작업을 모두 하는 사람은 Spawn이 충돌하던 아주 오래된 AMD 카드를 찾으려고 유럽의 철물점을 하루 종일 돌아다녔습니다. 온라인에서 빌릴 방법을 찾지 못했습니다. 그는 하나를 찾아 집에 가져와 설치하고 인터넷에 연결한 뒤, 에이전트가 버그를 재현할 수 있도록 접근 권한을 주었습니다. 에이전트는 온라인에 연결된 지 몇 시간 안에 이를 고쳤습니다.
큰 회사는 이를 도입하기 어려울 것이라 생각합니다. 루프를 닫지 않으면 이 중 어느 것도 작동하지 않기 때문입니다. 그리고 루프를 닫으려면 위험 감수 성향이 필요합니다. 에이전트가 프로덕션을 깨뜨리도록 둘 의지가 있어야 합니다.
인간은 항상 프로덕션을 깨뜨립니다. 변경은 장애의 가장 큰 원인이고, 인간이 변경을 만듭니다. 우리가 발견한 것은 에이전트가 문제를 훨씬 덜 자주 일으킨다는 점입니다. 하나가 무언가를 깨뜨려도 보통은 매우 빨리 고칩니다. 되돌리기는 도움이 되지만, 되돌릴 수 없는 경우에도 에이전트가 알아차리기만 하면 빨리 고칩니다. 알아차리는지는 루프를 닫았는지에 달려 있습니다.
또 다른 실수는 AI를 인간 모양의 상자에 억지로 넣는 것입니다. 이것들은 인간 모양이 아닙니다. 우리 에이전트는 고객 지원처럼 아무도 완전히 검증할 수 없는 일을 많이 합니다. 때로 약간 틀리지만, 그렇게까지 틀리지는 않으며 빠르게 회복합니다. 지원에서 빼면 고객은 불만을 가집니다. 고객은 “확인해 볼게요”라고 말하고 이틀 뒤 수정 사항을 가지고 돌아오는 인간보다, 즉시 답하고, 가진 정보 중 가장 명확한 것을 제공하며, 그 자리에서 문제에 조치할 수 있는 AI를 훨씬 더 선호합니다. 우리는 AI를 인간 지원인 척 내세우지 않습니다. 실제로 잘하는 일을 위해 사용합니다.
그리고 이는 복리로 쌓입니다. 새 모델이 나올 때마다 우리 팀은 더 빨라지고 더 일관되어졌으며, 우리의 속도 중 더 많은 부분이 올바른 방향을 향하게 되었습니다. 올해 중반에 겪던 문제는 사실상 사라졌습니다. Fable에서 Fable 5.1로 넘어가며 Fable 문제 대부분이 사라졌고, 우리는 이것이 계속되리라 기대합니다. 올바른 구조에서는 새 모델 하나하나가 회사 전체를 크게 더 좋게 만들며, 이를 따라잡기는 매우 어렵습니다.
이것이 여러분 팀의 방식과 거리가 멀게 들린다면, 실제로 그렇습니다. 지금보다 더 좋은 때는 없습니다. 현장에서 만나요!
