자율 Fable 모델로 멀티플레이 게임 세계를 만드는 방법 (번역)
원문: https://simonwillison.net/2026/Oct/29/how-i-built-the-most-ai-pilled-company-in-the-world/
How I Built the Most AI-Pilled Company in the World. 헤드라인이 자극적이라 그냥 넘기지 않았으면 한다. Jacob Sansbury가 Spawn을 어떻게 만들고 있는지 설명한 이 글은, 프런티어 모델을 상대로 한 에이전틱 엔지니어링의 최전선이 무엇인지 보여주는 흥미로운 탐구다.
Spawn은 대규모 멀티플레이 게임 환경이다. 플레이어는 게임 내 에이전트 Savi에게 프롬프트를 보내 게임 세계를 수정할 수 있다.
나는 휴대폰에서 몇 분 정도 켜봤다. 성을 프롬프트로 만들고, 이어서 용을 만들고, 그 용을 타고 성 주변을 날아다녔다.
Jacob의 말로는, Spawn은 이제 Fable 기반 에이전트 군집이 자율적으로 개발하고 있고, 토큰 비용만 매달 300만 달러가 넘게 든다(“AI 토큰에 인건비의 30배를 쓴다”).
우리 에이전트는 라이브 코드를 직접 바꾸고 매시간 프로덕션에 배포한다. 그래서 에러, 버그 리포트, 지표를 에이전트가 직접 읽는다. 우리 작업의 약 60%는 프로덕션 에러, Savi 버그 리포트(Savi는 Spawn에서 게임을 만들 때 상대하는 AI다), 로그의 이상 신호, 기능 요청에서 시작한다.
Savi는 자기 버그를 직접 등록한다. 사용자가 버그를 만나거나 Savi가 제품 안에서 버그를 만나면 그녀가 등록한다. 등록 건은 곧바로 에이전트에게 가고, 에이전트가 진짜 고칠 버그인지, 고치지 않을 문제인지, 결정이 필요한 의도된 설계인지 판단한다. 보통 1시간 안에 해당 사용자에게 변경이 전달되고, 같은 채팅에서 메시지로 알려준다.
이건 지속 배포(continuous deployment)를 볼륨 11로 올려놓은 형태다:
이렇게 빠른 루프는 멈추지 않을 때만 작동한다. 그래서 우리는 1시간 동안 배포가 없으면 SEV-0, 즉 가장 심각한 등급의 장애로 분류한다. 배포되지 않은 변경은 쌓이고, 프로덕션에 이미 있는 문제는 더 오래 지속된다. 피드백도 느려진다. 에이전트는 몇 시간치 작업만 머릿속에 담을 수 있어서, 그보다 빠르게 배포하는 것이 오히려 에이전트가 일관성을 유지하는 데 도움이 된다. […]
깨진 변경은 30초 만에, 문제가 있는 지점만 정확히 되돌릴 수 있다. 모니터나 로그 알럿이 울리면 그 장애를 담당하는 에이전트를 시작하거나 깨운다. 우리는 그 복구 경로가 작동하는지 확인하려고 일부러 장애를 일으키기도 한다.
이 글을 읽는 동안 나는 눈썹을 열두 번은 올렸다. 무언가 잘못됐을 때 이해관계가 더 큰 소프트웨어에서 이런 개발 방식이 통할지는 상상하기 어렵지만, 게임에서는 의외로 잘 작동하는 모양이다.
Jacob은 Fable 5, 그리고 5.1이 이런 수준의 자율성을 가능하게 만든 모델이라고 말한다. Opus 5.5는 그들 기준에 조금 못 미쳤고, GPT-6 Astra로 보안 검토 수정을 적용하려던 시도에서는 모든 것이 멈춰버렸다:
모든 기능이 비활성화되어 있었고, 보안 수정이 끝나면 다시 켜라고 표시되어 있었다. Astra는 제품 전체를 훑으면서 안전하지 않은 것들을 꺼버리는 방식으로 안전하게 만들어 놓은 것이다.
이런 종류의 극단적인 실험이 내가 게임 개발에 흥미를 느끼는 이유다. 오늘날 코딩 에이전트가 할 수 있는 것의 경계를 탐색하는 기반이 되어주기 때문이다.