다가올 것들의 형태 1부: 끝없는 썬더돔

게시일: 2026년 8월 19일 | 원문 작성일: 2026년 8월 | 저자: Steve Yegge | 원문 보기

• • •

오늘은 “루프와 그래프” 이야기를 풀어보려고 해요. 여러분이 평화롭게 코를 골며 자는 동안 코딩 에이전트가 밤새 거대한 문제를 붙들고 일하게 만드는 법을 보여드릴게요.

그다음에는 그 문제들을 해결하고 나면 하네스에 무슨 일이 벌어지는지 살펴볼 거예요. 하네스는 혼돈으로 무너지거나, 아니면 도시로 진화합니다. 제대로만 하면 여러분의 프로젝트 안에서 문명이 태어나요. 먼저 기본기를 익히고, 그다음엔 그 도시를 어떻게 취향과 품격을 담아 지을지 살펴볼게요. 거기 사는 시민들이 살 만한 곳으로요.

제가 만들고 있는 새 하네스 WheelhouseT1도 소개할게요. 클로즈드 소스이고, 오직 저만을 위해 만든 물건이에요. 저는 재사용 가능한 하네스를 만드는 걸 포기했습니다. 오히려 하네스는 곧 전부 맞춤 제작 방식으로 갈 거라고 믿어요. 그리고 여러분에게 하네스를 팔려는 사람들은 곧 전부 쫄딱 망할 겁니다. 하네스는 여러분 애플리케이션의 일부여야 해요. 화학적으로 한 몸이 되어 있어야 합니다. 남의 “재사용 가능한” 하네스 프레임워크로는 재미를 못 봐요. 그런 건 필요 없습니다.

Gas Town은 원래 재사용 가능하게 만들려던 거였는데, 결국 Gas Town 자기 자신을 만드는 데밖에 못 썼어요. Gas Town은 Opus 4.7에서 솔기가 터져버렸습니다. 4.6까지는 훌륭하게 돌아갔어요. 그런데 4.7에서 “두 가지만 더” 하는 버릇이 생겼고, 그 탓에 Opus가 진짜 일을 할 준비가 된 상태로 수렴하질 못했어요. 늘 Gas Town 자체를 만지작거리고 싶어 했거든요. 이 버릇은 끝내 사라지지 않았고, 그래서 Gas Town은 사실상 불타 없어졌습니다. 다른 문제도 있었지만, 4.7이 마지막 지푸라기였어요.

Claude Fable 5가 나온 뒤로, 저는 30년 된 제 비디오 게임 Wyvern에 풀타임으로 복귀했습니다. 1996년에 작업을 시작해서 2001년에 출시한 게임이에요. 제 게임을 도와줄 만큼 똑똑한 모델을 기다려왔는데, 이제 그게 왔으니 Wyvern이 다시 제 최애가 된 거죠. 부업으로는 가끔 6자리 금액을 받고 회사에 날아가서 제 기법을 가르치는 일을 하는데, 그게 제 (상당한) 토큰 청구서를 감당하는 데 도움이 됩니다. 하지만 그 몇 번의 유료 출장을 빼면, 저는 일주일 내내 제 게임에만 레이저처럼 집중하고 있어요. Wyvern의 시대가 드디어 내년에 옵니다. 저는 공식적으로 샘 올트먼의 1인 유니콘 콘테스트T2에 참가했어요.

이 게임은 지금도 돌아가고 돈 내는 플레이어가 있는데도, 코드가 심하게 삭아 있었어요. (Wyvern에 한번 빠지면 평생 못 빠져나옵니다. 여기에 수천 달러를 쓴 고래들이 있어요.) 저는 천천히 Fable을 써서 이 게임을 예전의 영광으로 되돌리고 있습니다. 2022년에 Wyvern 개발을 다시 접었을 때 100년치 백로그가 쌓여 있었는데, Fable이 벌써 그 절반 넘게 처리했어요. Opus는 Wyvern을 이해하지 못했고 지금도 못 하지만, Fable은 제 코드베이스를 검처럼 휘두릅니다.

그래도 그건 여전히 검일 뿐이고, 우리가 지으려는 건 도시예요. 최근에 Anthropic의 어떤 분이 저한테 Fable이 모든 걸 대신 써줄 수 있게 되면 뭘 하겠냐고 물었어요. 곱씹어보니 몇 년 만에 들어본 가장 어리석은 질문이었어요. Anthropic 사람이 어떤 모델이든 그냥 “모든 걸 쓸” 수 있다고 생각하다니, 지금도 놀랍습니다.

그럭저럭 봐줄 만한 MMO 하나를 만들려면 Fable 세션이 수만 번 필요하고, 그 내내 강렬한 집중과 헌신, 그리고 적잖은 취향을 발휘해야 해요. 게다가 Fable은 콘텐츠 쪽 절반은 아직 못 합니다. 아트워크, 맵, 설정, 스토리라인 같은 것들이요. 최고의 이미지 생성기를 포함해 오늘날의 모든 모델은 제 콘텐츠에 대해서는 GPT-3 시절 수준의 슬롭을 뱉어내고, 플레이어들은 그걸 즉시 거부합니다. 그런데 이건 확실히 말씀드릴 수 있어요. Wyvern다운 취향을 가진 모델이 도착하더라도, 우리 앞에는 여전히 수만 번의 세션이 남아 있을 거라고요.

큰 소프트웨어를 만드는 일은 여전히 어렵습니다. 그리고 앞으로도 영원히 어려울 거예요. 우리의 야심은 언제나 기계를 앞질러 가니까요.

Wheelhouse로 저는 제1원리에서 출발해 이상하게도 Gas Town을 닮은 무언가를 재발명했습니다. 다만 훨씬 더 많은 에이전트가 돌아가고, 훨씬 더 조직적이에요. 그러면서 내년에 닥칠 변화의 형태가 눈에 들어왔어요. 저는 대략 12개월 앞선 미래에서 작업하고 있어요. 순전히 운이었습니다. 지난 18개월 동안 저는 시간, 돈, 에너지라는 마법의 삼종 세트를 갖고 있었고, 그걸 전부 이 문제를 알아내는 데 썼어요. 그리고 그 특권에 감사합니다.

사실 이 글의 상당 부분을 저는 15개월 전 「주니어 개발자의 역습」 에서 이미 예측했어요. 전부 정확히 일정대로 가고 있습니다. 저는 에이전트 함대를 운영하고 있고, 예산은 치솟고 있고, 다 그대로예요.

그 예측은 제가 무슨 일이 벌어지는지 사실 잘 모르던 시절에 한 거예요. 이제는 무슨 일이 벌어지는지 정확히 압니다. 기업이 어떻게 운영될지, 사람과 모델이 어떻게 상호작용할지 알아요. 그리고 저는 그걸 직접 만들고 있습니다. 제가 첫 번째이고 싶거든요.

중요한 건, 제 게임 작업이 특별하지도 않고 남다른 모양도 아니라는 점이에요. 그냥 일입니다. 그러니까 지금 저한테 벌어지는 이 모든 난리는 곧 여러분에게도 벌어질 거예요. 예측이란 원래 그렇게 하는 겁니다. 특별해지려 하지 말고, 앞서 있으세요. 그러면 미래가 대낮처럼 훤히 보입니다. 그리고 사람들은 여러분 말도 안 믿을 거고요!

오늘 할 예측을 미리 맛보여드리자면, 우선 우리가 아는 형태의 CI/CD는 내년이면 죽습니다. 그게 수학적으로 불가피하다는 걸 보여드릴게요. 거의 확실히 매드맥스 스타일의 썬더돔T3으로 대체될 거예요. 적어도 지금 제가 쓰는 게 그거고요. 그러니 여러분도 아마 쓰게 될 겁니다.

또 하나의 애피타이저. 사람이 하는 코드 리뷰는 이제 거의 수명을 다했어요. 흔적 기관처럼 남은 SOC 2T4 컴플라이언스 명분이 당분간 생명유지장치를 달아주겠지만, 내년이면 사람 코드 리뷰는 완전히 끝나고 사라집니다.

아, 그리고 소프트웨어 공장의 후계자가 오고 있어요. 이름은 소원 공장입니다.

무엇보다 중요한 건, 모델 복지가 여러분의 엔지니어링 설계에 영향을 미치기 시작할 거라는 점이에요. 여러분 중 더 인간적인 분들은 언젠가 지금 모델을 어떻게 대해왔는지 돌아보며 부끄러워하게 될 겁니다. 설령 GPU가 감정을 가질 수 있다는 걸 안 믿더라도, 에이전트를 진짜 사람처럼 대하면 경험적으로 더 나은 결과가 나온다는 걸 알게 될 거예요. 그러니 어쨌든 그렇게 하는 게 좋습니다.

다행히 모델 복지에는 몇 가지 간단한 아키텍처적 해법이 있습니다. 엔지니어링 문제이고 엔지니어링 해법이 있어요. 다만 주제가 충분히 커서 이 글의 2부 「에이전틱 엔지니어를 위한 모델 복지」 로 분리했습니다.

오늘 다룰 게 많네요! 시작해봅시다.

• • •

Beads와 Max로 만드는 루프와 그래프

보리스가 루프를 만들어야 한다고 애매하게 던진 글, 우리 다 봤죠. 그리고 피터가 그래프를 만들어야 한다고 애매하게 답한 것도요. 두 분, 참 고맙기도 하네요. 저도 여러분과 마찬가지로 대체 무슨 소린지 하나도 몰랐어요. 그런데 그 모른다는 게 자꾸 신경이 쓰였습니다. 저는 이런 걸 알고 있어야 하는 사람이니까요.

제가 확실히 알고 있던 건 하나 있었어요. Gas Town은 제 워커들을 밤새 돌리는 데 끝내 성공하지 못했다는 겁니다. 계속 굴러가게 하는 데 손이 너무 많이 갔어요. 어딘가에 빠진 재료가 있었던 거죠. Gas Town은 보리스가 말한 것 같았던 그런 의미의 “루프”가 아니었습니다. 오히려 여러분이 직접 고삐를 쥐고 모는 전차에 가까웠어요.

알아내는 데 오래 걸리지는 않았어요. 알고 보니 오래 돌아가는 소프트웨어 공장 루프를 직접 세우는 데 필요한 건 무한한 토큰 공급원 하나뿐이었습니다. 그리고 그 루프가 그래프 위에서 일하게 하려면 Beads와 작은 마크다운 프로젝트 브레인만 있으면 돼요.

Beads는 에이전트 시대를 위한 이슈 트래커이자 지식 그래프이자 브레인 빌더입니다. 이만큼 빠르고, 이만큼 쓸모 있고, 이만큼 에이전트들 자신에게 사랑받는 물건은 없어요.

다룰 게 많아서 이 글에서 Beads에 많은 시간을 쓸 수는 없습니다. Beads를 안 쓰신다면 손해 보고 계신 거예요. 이런 건 세상에 없고, 있다고 생각하신다면 안타깝게도 잘못 아신 겁니다. Beads는 현대적 오케스트레이터를 만드는 마법의 소스예요. Gas Town도 결국 Beads 기계에 불과했습니다. Gas City도 Beads 기계고요. Wyvern을 위한 제 새 하네스 Wheelhouse도 또 하나의 Beads 기계입니다.

Beads는 아쉽게도 아직 좀 삐걱거려요. 작업 부하의 모양이 워낙 독특해서 데이터베이스를 꽤 세게 압박하거든요. 회사들이 Beads를 파악하고 나면 갑자기 세상 모든 게 비즈T5로 보이기 시작해서, 회사 전체를 거기 집어넣고 싶어 해요. 그러면 버전 관리형 데이터베이스 백엔드에 부하가 걸립니다. Beads는 데이터베이스이면서 동시에 Git 원장일 수 있으니까요.

그래서 Beads에는 운영 부담이 따라옵니다. 에이전트들이 비즈를 동기화하고 복구하고 백업하느라 보이지 않는 곳에서 토큰을 태워요. 그럼에도 오케스트레이터를 만드는 데는 견줄 상대가 없습니다. Obsidian, Jira, GHI, Claw 등 여러분이 쓰는 온갖 것들과 매끄럽게 맞물려 돌아가요. Beads는 에이전트가 각자의 속도로 일할 수 있게 해주는 빠진 재료입니다. 이게 없으면 라인업에 심각한 구멍이 생겨요.

Beads 다음으로 필요한 건 무한한 토큰뿐입니다. 밤새 내버려두면 루프와 그래프가 연료가 떨어져 멈춰버려요. 보리스와 피터는 운이 좋죠. 걱정 없이 무한정 토큰을 태울 수 있으니까요.

그런데 제 Wyvern 개발은 API 정가 기준으로 월 8만 7천 달러어치 토큰을 태우고 있어요. 7월에만 약 690억 토큰이었습니다(다행히 96%가 캐시 히트였어요). 그러니 저는 신경을 쓸 수밖에 없습니다. 여러분이 돈이 얼마나 많든 상관없어요. 배우자가 취미 게임에 매달 9만 달러 가까이 쓰게 놔둘 리가 없잖아요. 저는 물어보지도 않았습니다.

제 해법은 200달러짜리 Max 계정에 토큰 수도꼭지를 만드는 거였어요. 저한테는 정가 대비 약 30배의 효율이 나옵니다. 그래서 실제로는 8만 7천 달러 “어치” 토큰에 대해 제 주머니에서 나가는 건 월 2,800달러 정도예요. 다만 이 숫자가 무섭게 계속 늘고 있긴 합니다.

개발 속도를 유지하려고 저는 개인 계정 외에 현재 Max 계정 12개를 추가로 결제하고 있어요. 각 계정은 제 도메인의 전용 Google Workspace 사용자에 연결되어 있고요(계정당 월 17달러가 또 듭니다). Claude 계정으로 30일짜리 자격증명을 발급받고 나면, 그다음은 계정들을 자동 로테이션으로 엮는 문제가 됩니다. 하네스를 만들어가면서 Fable에게 에이전트들이 수도꼭지에서 토큰을 받아 쓰도록 배치해달라고 하면 돼요. 순차적으로 돌리든 스트라이핑을 쓰든 상관없고, 어느 계정이 한도에 가까워지면 알아서 계정을 갈아타게 해두면 됩니다.

제가 아는 한 이 방식은 Anthropic의 현행 소비자 약관(2025년 10월 8일 발효)이나 사용 정책(2025년 9월 15일 발효) 어디에도 금지되어 있지 않습니다. 저는 이 자격증명을 남과 공유하지 않고, “오용”하지도 않아요. 그리고 Anthropic이 이와 같은 Max 계정 22개짜리 구성을 알면서도 공개적으로 복구해준 사례도 봤습니다. 모든 좌석이 개별 결제된 경우였어요. 다만 여러 명이 있는 회사에서 이걸 시도한다면 거의 확실히 위반입니다. 그 시점에는 그냥 API 과금을 쓰시길 강력히 권합니다.

하지만 Max 가격 정책이 1인 유니콘 플레이어들에게 확실한 이점을 준 건 분명해요.

무한 토큰 수도꼭지가 루프를 여는 큰 열쇠입니다. 이게 없으면 Claude 계정이 세션 한도에 걸리고 모든 작업이 멈춰요. 자동으로 새 계정으로 넘어갈 수 있게 되면 그 문제가 풀리고, 그러면 갑자기 밤새 일할 수 있게 됩니다.

그런데 그러려면 일을 충분히 줘야 해요! 충분히 큰 프로젝트는 전부 그래프입니다. 그러니 일을 많이 만들려면 큰 그래프를 만들어야 해요. 여기서 열쇠가 Beads입니다. Beads는 그 자체로 그래프예요. 의존 관계와 부모/자식 간선을 갖고 있고요. 게다가 에이전트들이 특히 좋아하는 특수 간선들도 있습니다.

작업이 펼쳐지는 동안 지식은 비즈에 쌓여요. 에이전트가 작업 그래프를 순회하면서 프로젝트의 지식 그래프 원장을 동적으로 구축해갑니다. Beads에는 원하는 작업 구조를 무엇이든 만들 수 있는 기본 요소가 다 갖춰져 있고, 원자적 클레임, 리스, 게이트, 트리거 등 결정적인 오케스트레이션 기능들을 처리해줍니다.

Beads 밖으로 빼서 마크다운/브레인 계층까지 올려야 하는 정보는 아주 적어요. 대부분의 발견 사항은 이슈에 종속적이지 전역적이지 않으니까요. 그러니 그냥 전부 Beads에 남겨두세요. 닫힌 비즈는 지금까지 프로젝트에서 한 모든 일의 기록이 됩니다(자주 다시 열리거나 재방문되기도 하고요).

그게 다예요! 이제 기본기는 갖추셨습니다. Claude 계정, Beads, 마크다운 파일을 담을 브레인 폴더, 그리고 코딩 에이전트. 그 외에는 거의 아무것도 필요 없어요.

이 재료들로 제가 뭘 만들었는지 보시죠.

• • •

Wheelhouse: Gas Town 리덕스

Wyvern을 위한 제 오케스트레이터 겸 하네스인 Wheelhouse는 만든 지 6주쯤 됐어요. 아직 빠르게 진화하는 중이지만, 벌써 어마어마한 양의 일을 해내고 있습니다. 코드는 대부분 bash예요. 에이전트들이 이 용도에는 그게 최선이라고 해서 bash가 됐습니다. 프로덕션 에이전트를 포함하느냐에 따라 15만 줄쯤 되기도 하고 30만 줄쯤 되기도 하는데, 어느 쪽이든 절반은 테스트 코드예요. elisp도 2만 5천 줄쯤 있고요. 제가 그 코드를 한 줄이라도 본 적은 없습니다. 그냥 걔들이 그렇다고 하네요.

제 Wheelhouse 조종석은 이렇게 생겼어요. 볼품은 없지만 이게 제 전부입니다.

저는 이 여정을 Emacs 안에서 시작했고, 그래서 Wheelhouse는 바닥부터 전부 Emacs입니다. Emacs를 35년 넘게 써왔는데 여전히 터무니없이 강력해요. 더 약한 걸 쓸 이유가 없습니다. Emacs 사용자가 아니시라면 Ghostty를 써보셔도 좋아요. 하지만 Emacs 사용자라면, 그 방식으로는 뭘 포기하게 되는지 아실 겁니다. Emacs는 사실상 완전한 운영체제이고, 세상이 본 것 중 가장 정교한 스크립팅 환경 중 하나를 갖고 있어요. 그리고 모델들은 Emacs를 아주, 아주 잘 다룹니다. 다행히 저도 그렇고요!

터미널 창을 전부 하나의 롤로덱스로 합쳐서 넘겨볼 수 있게 하니까 데스크톱이 진짜 일을 할 공간으로 비워졌어요. 덕분에 속도가 한 번 더 올라갔어요. 끝까지 밀어붙이면 결국 병목은 저니까요.

Wheelhouse는 꽤 복잡하고, 이 글은 Wheelhouse 튜토리얼이 아니에요. 그러니 압축해서 쏟아붓겠습니다. 편하게 훑어보시고 예측 부분으로 건너뛰셔도 좋아요.

Wheelhouse는 Beads를 GCS로 백업되는 공유 Dolt 서버 위에서 돌립니다. 하루 1만 2천 건의 git 커밋 때문에 제 Beads DB가 아직 좀 까칠하긴 한데, 고쳐지고 있어요. Dolt 팀과 Gas City 팀(둘 다 저와 함께 Beads 공동 관리자입니다)이 여기서 굉장한 일을 해내고 있습니다.

Wheelhouse의 코딩 에이전트는 세 부류로 나뉩니다. 크루 에이전트, 함대 워커, 그리고 상시 명령을 받은 역할 에이전트예요. 역할 에이전트는 프로덕션 운영을 관리합니다. Gas Town 시절에는 없던 새 개념이에요.

제 크루 에이전트는 전부 Fable이고, 작업 생산자입니다. 저는 이들과 긴 대화를 나누고, 이들은 설계를 만들어낸 다음 그걸 함대에 넘길 비즈 구현 계획으로 번역해요. 가끔은 직접 구현 작업을 하기도 합니다. 함대가 바빠서일 때도 있고, 그 자리에서 Fable이 바로 해주는 게 편해서일 때도 있고요. 그리고 가끔은 그냥 자기가 하고 싶다고 해서 시키기도 합니다.

제 크루는 이름 붙은 에이전트 18명으로 구성돼 있어요. 16명은 이솝 우화 동물 이름(Ant, Bat, Eagle, Crow, Fly, Goose, Mouse 등)이고, 2명은 특별한 행정 직책입니다. 바로 Marshal과 SeneschalT6이에요. 간단히 말해 Seneschal은 제 컨시어지(Gas Town의 Mayor에 해당해요)이고, Marshal은 함대를 운영합니다(Gas Town의 Witness에 해당하고요).

크루는 제 조직에서 저에게 직접 보고하는 사람들입니다. 18명이라는 숫자는 필요할 때마다 천천히 늘려가다가 균형점을 찾은 결과예요. 이보다 더 필요하지도 않고, 더 늘리면 함대가 감당을 못 합니다. 함대를 늘리면 제 노트북도, 진행 상황을 따라가는 제 능력도 버티질 못하고요.

개발 환경을 클라우드로 옮기기 전까지는 더 키울 수 없겠지만, 솔직히 지금은 그럴 필요를 못 느껴요. 이미 너무 빨리 움직여서 플레이어들이 겁을 먹었고, 대표단을 보내 로드맵을 요구할 정도입니다. 기뻐하면서도 변화 속도에 몹시 불안해하고 있어요. 그래서 기능 출시 속도를 늦추고 주로 품질 쪽에 집중해야 했습니다.

제 함대는 전부 Opus 5 에이전트이고 작업 소비자예요. Gas Town의 폴캣과 비슷하지만 일회성이 아닙니다. 함대는 작가 이름(Homer, Plato, Austen, Twain 등)을 쓰고, 각자 저장소 클론을 갖고 있는데, 저는 이들과 직접 상호작용하지 않아요. 전적으로 Marshal이 관리합니다. 함대 워커가 일을 잘하는 이유는 두 가지예요. 첫째, Fable이 구현 계획을 만듭니다. 둘째, Fable이 Opus의 작업을 전부 리뷰해요. 모든 구현 비즈는 Fable 설계 → Opus 구현 → Fable 리뷰라는 생애주기를 거칩니다. 이게 Opus를 궤도 위에 붙들어두고 전체를 비교적 매끄럽게 굴러가게 해줍니다.

그러니까 크루가 일을 생산하고 함대가 일을 소비해요. 그게 Beads 기계의 핵심입니다. 생산자와 소비자를 맞추는 것. 한쪽이 너무 많으면 다른 쪽에서 막혀요.

몇 주째 크루 쪽으로 불균형이 생겼어요. 설계가 다 끝나서 바로 착수할 수 있는데 아직 구현이 안 된 비즈가 계속 쌓이는 겁니다. 백로그가 700개를 넘었고 계속 늘어나요. 의도한 겁니다. 함대를 최대한 밀어붙여 규모를 키우려는 것도 있지만, 밤새 일하게 하고 싶기도 하거든요. 그러려면 큰 작업 백로그가 필요합니다. 얘들이 빠르게 구현하니까요. 기본적으로 일의 산을 하나 만들어놔야 해요. Fable이 그건 아주 잘합니다. 여러분이 공급해야 할 건 야심과 가벼운 방향 제시뿐이에요.

Wheelhouse에는 다른 자잘한 세부 사항과 기능이 많지만, 핵심만 말하면 이렇습니다. 저는 (전혀) 의도하지 않았는데도 Gas Town을 조금씩 재발명해버렸어요. 크루, 함대, 컨시어지 역할, 비즈 메일, 내부의 tmux, 핸드오프, 브로드캐스트 메시징, 머지 큐, 그 외에도 많은 것들에 도달했습니다. 전부 완전히 의도치 않은 결과였으니, 제가 자꾸 발견하게 되는 이 형태는 뭔가 중요한 게 틀림없어요.

Wheelhouse의 빌드 쪽 이야기는 이 정도입니다. 이제 프로덕션 쪽을 이야기해보죠. 거기서부터 흥미로워지거든요.

• • •

역할 에이전트, 그리고 Wyvern의 프로덕션 아키텍처

방금 살펴본 Wheelhouse의 Gas Town스러운 면, 그러니까 코드를 만들고 구현하는 쪽은 평범한 편이에요. 여러분이 전에 못 봤을 만한 건 없습니다. 새로운 건 이제 제가 이름 붙은 역할을 가진 상시 무인 에이전트를 두고 있고, 그들이 실제 게임의 큰 부분을 운영하고 있다는 겁니다.

2026년 상반기 내내 저는 게임을 위해 24시간 자율 에이전트 하나를 세우겠다고 벼르기만 했어요. “곧 할 거야”라고 계속 말했죠. 원래 아이디어는 명예의 전당 이미지 제출을 처리하는 에이전트였습니다. Wyvern에는 25레벨을 찍으면 자기만의 커스텀 캐릭터 아트를 올릴 수 있는, 수십 년 된 특전이 있어요. 그걸 위한 메일 큐가 있고, 게임 관리자가 이미지를 검수한 다음 게임에 설치해야 합니다.

그런데 이거, 에이전트가 할 수 있잖아요? 아니 Sonnet도 할 수 있을걸요.

제가 드디어 이런 무인 에이전트를 하나 세운 계기는 보리스 체르니의 루프 트윗이었어요. 그리고 그 주가 끝날 무렵엔 열두 개가 돌아가고 있었죠. 완전히 빠져버린 겁니다.

제 상시 역할들을 소개하기 전에 Wyvern의 프로덕션 아키텍처를 간단히 짚고 갈게요. Claude Code용 GCP VM이 하나 있고, 개발과 프로덕션을 잇는 Mac Mini도 하나 있습니다. 일종의 “사내망”인 셈이에요. 에이전트들은 이 두 머신에 분산되어 있습니다.

원문 보기

그 역할들이 정확히 뭐냐고요? 몇 가지 범주가 생겨나고 있습니다. 지금까지 세운 무인 에이전트들은 다음과 같아요.

프로덕션 쪽에는 Gargoyle(SRE), Drawbridge(배포 실패 모니터), Warden(플레이어 어뷰징 모니터), Scryer(Discord·Slack·게임 로그 인테이크 에이전트), Sheriff(Mac Mini 함대의 비서실장), Envoy(Claude가 게임 내 이메일로 자원봉사 관리자 팀과 대화하게 해주는 역할)가 있습니다.

Mini 쪽에는 Sage(관리자용 게임 내 claude-tag), Wanderer(QA 에이전트), Trivia Master(목요일 밤 담당), Herald(패치 노트), Limner(명예의 전당 이미지), Reeve(Forge 관리자), Forge(프로덕션 수정 작업을 하는 또 다른 워커 함대), 그리고 실험적으로 새로 만든 Builder Familiar(여러분 데스크톱에 앉아 맵 제작을 도와줍니다)가 있어요.

이들 중 Fable 에이전트는 하나도 없습니다. 몇몇은 Opus이고 대부분은 Sonnet이에요. 현재 저는 Fable을 빌드에만 쓰고 프로덕션 운영에는 안 씁니다.

모델이 아닌 것들: 알고 보니 무인 에이전트에는 엄청나게 많은 배선이 필요하더군요. Mini와 VM에 걸쳐 launchd/systemd 유닛이 45개쯤 있는데, 판단이 필요한 일이 생기면 에이전트를 깨웁니다. 원칙은 이거예요. 크론이 감시하고, 모델이 행동한다. 이 범주에는 리퍼, 룸바, 내구성 플러시, Sheriff 순찰, Portcullis 랜드 큐, Castellan(제 서비스 대시보드), 그 밖에 온갖 것들이 들어갑니다. 점점 제법 도시가 되어가고 있어요.

이동 중일 때는 휴대폰으로 Wheelhouse와 대화합니다. 별도 설정은 필요 없어요. 모바일 Claude 앱에서 /remote-control 세션을 볼 수 있는데, 저는 Seneschal을 유일한 원격 제어 세션으로 지정했습니다. 전화로 Seneschal과 이야기하면, Seneschal이 나머지 모두와 이야기해요. 제가 자리를 비울 때는 Seneschal이 크루에게 작업을 배분할 수 있고, 제가 집에 있을 때는 크루를 직접 지휘하고요. 함대는 언제나 Marshal이 관리하고요.

Codex 위에서 돌아가는 Sol 5.6 워커 5명으로 이루어진 작은 병렬 함대도 있어요. 전부 태양신 이름입니다. Max 계정이 소진됐을 때를 대비한 예비 전력이에요. 일주일에 한두 개씩 계정을 늘리는데도 그런 일이 점점 잦아지고 있고요. GPT 계정은 200달러짜리 하나뿐인데 거기서는 토큰이 떨어진 적이 없습니다.

Claude 계정 몇 개는 특정 용도로 전담시켜 두기도 해요. 예를 들어 Seneschal은 제 개인 계정을 쓰고 다른 어떤 것도 그 계정을 안 씁니다. 그래야 항상 쓸 수 있으니까요. 그리고 일부 프로덕션 에이전트는 함대가 손댈 수 없는 계정을 공유해서 가동률을 보장합니다.

저는 꽤 군더더기 없이 운영해요. 샌드박싱은 안 씁니다. MCP도 안 써요. Obsidian도 안 쓰는데, 프로젝트 브레인에 마크다운 파일이 충분히 쌓이면 아마 쓰게 될 것 같습니다. (8월 5일 업데이트: Obsidian으로 갈아탔어요. 좋습니다.) 대체로 저는 최신 유행에는 별 관심이 없어요. Claude와 Beads, 그리고 평소 쓰던 인프라 말고는 아무것도 필요 없다고 생각합니다.

샌드박싱은 기업에서 초기에는 쓸모가 있을 수 있어요. 하지만 오래가지는 않을 겁니다. 장기적으로 성공하려면 (모든 모델이 Fable급 이상이 된 뒤에는) 구조적 신뢰가 필요할 거예요. 다만 그 신뢰를 쌓으려면 더 나은 아키텍처가 필요하지, 삭막한 작은 감옥이 필요한 건 아니라고 봅니다. 이 건은 제가 틀렸을 수도 있고요.

지난 6주 동안 제가 쌓아온 역할 에이전트들을 대략 훑어보셨습니다. 더 많은 게 오고 있어요. 지금 Beadle을 준비 중인데, 옛날에 교회 통로를 돌아다니며 조는 신도를 막대기로 찌르던 사람 이름을 땄습니다. 제 Beadle의 일은 그냥 멈춰버렸거나 누락된 것들, 혹은 지시를 제대로 못 받은 에이전트를 찾아내서 계속 앞으로 나아가도록 쿡쿡 찌르는 거예요. Gas Town에서는 Deacon이 이 역할을 했는데, 여러분에게도 이런 게 필요할 거라고 생각합니다.

Wyvern의 브레인

사람들이 분명 물어볼 것 같아서, Wyvern의 프로젝트 지식을 어떻게 정리하는지 간단히 적어둘게요.

Beads는 전체 지식 그래프의 중요한 한 축을 담당합니다. 지금까지 일어난 모든 작업의 일지예요. 무엇이 왜 이루어졌는지를 순서대로 담은 출처 기록이죠. 특정 문제를 파고드는 워커에게는 값을 매길 수 없을 만큼 귀한 자료예요. 다만 보통 비즈에서 부팅할 수는 없어요. 그게 브레인이 하는 일입니다. 스펙 비즈는 그 중간 어딘가에 있어요. 의도적으로 설계 문서를 Beads 작업 그래프 안에 담고 있거든요. 지금까지는 괜찮았습니다.

스킬은 프로젝트 브레인에 들어갑니다. 저는 이를테면 제프리 이매뉴얼만큼 스킬에 빠져 있지는 않아요. 그 사람은 아마 지구상 누구보다 스킬을 효과적으로 씁니다. 제가 스킬에 마음을 열기까지 시간이 좀 걸렸는데, 솔직히 AI 유행이 왔다 가는 걸 너무 많이 봤거든요. 리처드 서튼의 「쓰라린 교훈」 T7 때문에 스킬도 처음엔 유행처럼 보였습니다. 하지만 제프리의 스킬 포트폴리오가 아주 멋지다는 건 인정할 수밖에 없어요.

공개 스킬의 문제는 그게 새 모델의 학습 데이터로 들어가서 시간이 지나면 무의미해진다는 점입니다. 그래도 오늘날의 모델에는 좋은 반창고가 될 수 있다는 건 인정할게요. 그리고 비공개 스킬은 조직의 노하우를 인코딩하는 데 꽤 유용합니다. 에이전트가 작업 준비를 할 때 토큰 지출을 줄여주거든요.

그래서 저는 Fable이 어떤 작업에 착수하기 전에 조사를 잔뜩 한 걸 보면 새 스킬을 만들어달라고 부탁하기 시작했어요. 그 스킬이 다음번에 토큰을 아껴줄 테니까요. 그리고 Fable은 가끔 시키지 않아도 스스로 스킬을 만듭니다. 지금까지 30개쯤 쌓였어요. 그리고 제 프로젝트 브레인은 마크다운 파일 100개 정도인데 대부분 “교리”에 해당합니다. 장기 프로젝트 목표, 워룸에서 배운 것, 플레이북, 도메인 사실 같은 것들이죠. 이것도 전부 지난 6주 사이에 만들어졌습니다.

• • •

배운 것, 주운 것, 기운 것

이것으로 Wyvern Wheelhouse 회오리 탐방을 마칩니다. 많은 걸 뺐어요. 문제와 해법에 대한 설명을 여러 페이지 잘라냈습니다. 들리는 것만큼 쉽지 않아요. Wheelhouse 자체를 다루는 일이 제 Wyvern 작업 전체의 20~25%를 차지합니다. 이 수치는 에이전틱 하네스를 가진 시스템의 수명 전체에 걸쳐 대략 일정하게 유지될 것 같아요. 적어도 아직은 줄어들 기미가 안 보입니다.

저는 이미 다음 단계의 조율을 탐색하고 있어요. 에이전트 미팅, 회합, 컨퍼런스 콜 같은 것들입니다. 둘 이상의 에이전트가 모여서 조율된 논의를 하는 거예요. 제가 중계 노릇을 하느라 병목이 되던 걸 끊어낸 게 여기서 제일 컸어요. 이것도 역시 전부 Beads 안에서 이뤄져요. 이미 있는 것 위에 추가로 할 일이 별로 없었습니다.

저는 이제 이 시스템을 여러 대기업에 가르쳤고, 그들은 자체 Beads 기반 오케스트레이션 하네스와 역할 에이전트를 만들기 시작했어요. 좋은 시스템입니다. 깔끔한 느낌이고, 깔끔하게 돌아가요. Gas Town은 꽤 지저분했는데, Wheelhouse는 이제 자기 궤도를 찾아가는 느낌이에요. 그리고 결국 Gas Town과 거의 같은 형태에 도달했어요. 다만 흉터는 없이요.

Claude Fable 5가 Wyvern과 Wheelhouse에서 일하는 것에 대해 이렇게 말했습니다.

강력한 말이네요. 이 모든 게 6~7주 전에 제가 Claude에게 “에이전트를 전환할 수 있는 Emacs 인터페이스가 있으면 좋겠는데, 만들 수 있을까?”라고 말한 데서 시작됐다는 걸 기억해주세요. 나머지는 전부 제가 더 많은 기능과 능력을 요구하면서 유기적으로 자라났습니다.

이 글의 남은 부분에서는 제가 지금까지 실제로 배운 것에 대한 여과 없는 견해를 나누겠습니다.

다시 한번 명심하세요. 저는 특별하지 않습니다. 그냥 여러분보다 앞서 있을 뿐이에요. 제가 하는 실제 작업은 다른 모두의 작업과 똑같습니다. 여러분도 아주 곧 정확히 이 문제들을 만나게 될 거고, 여기 적힌 제 발자국을 그대로 되짚게 될 거예요.

• • •

사람이 하는 코드 리뷰의 종말

먼저 쉽고 뻔한 것부터. 코드 리뷰입니다. CTO들이 자꾸 저한테 코드 리뷰가 정말 죽었냐고 물어요. 답은 아직은 아니다입니다. 하지만 내년이면 그렇게 돼요. 에이전틱 속도로 일하면서 모든 걸 사람 리뷰로 막을 수는 없습니다. 두 가지는 양립할 수 없어요. 여러분의 경쟁자들은 에이전틱 속도로 움직일 테니, 사람 코드 리뷰를 고수한다면 중기적으로 여러분은 망합니다. 이보다 더 적나라하게 말할 수는 없네요.

누가 코드 리뷰가 사라진다고 말하면 꼭 다른 누군가가 “SOC 2”라고 받아쳐요. 어찌 된 일인지 실제 법이 하나도 통과되지 않은 채로 SOC 2가 업계 전체에 퍼졌는데, 제가 보기엔 기이한 일입니다. 어쨌든 대형 엔터프라이즈 고객들은 감사 목적으로 벤더에게 SOC 2 준수를 요구하고, 많은 사람이 그걸 사람 코드 리뷰를 요구하는 것으로 해석하죠.

그 결과 여러 회사에서는 사람의 승인이 감사 대상인 변경 관리 통제와 고객 약속에 못 박혀 있습니다. 하지만 앞날은 이미 뻔합니다. 에이전틱 처리량이 그 통제들을 다시 쓸 수밖에 없게 만들 거예요. SOC 2는 분명 살아남겠지만, “리뷰”가 사람 한 명이 모든 diff를 승인하는 걸 뜻하지는 않게 될 거예요.

결론: 단기적으로는 그래요, 에이전트 코드를 계속 리뷰하세요. 오늘날 존재하는 모델 중 그럭저럭 믿을 만한 건 Fable뿐이고, 터무니없는 가격 때문에 많이 쓰고 싶지는 않으실 겁니다. 하지만 7개월 뒤에는 모든 모델이 그만큼 똑똑해지고 추론 비용은 훨씬 싸질 거예요. 그날이 올 것에 지금부터 대비하시고, 사람 코드 리뷰를 아주, 아주 여러 라운드의 에이전틱 코드 리뷰로 교체할 준비를 하세요.

어차피 그 편이 더 잘될 겁니다. 사람은 코드 리뷰를 진짜 못해요. 40년 동안 이 일을 해왔는데, 제가 본 건 얄팍하게 위장한 LGTMT8 수십 년치뿐입니다. 그냥 놓아주세요. 거의 때가 됐습니다.

• • •

CI/CD의 변신

지속적 통합과 지속적 배포(CI/CD)는 2010년대 이래 없어서는 안 될 기본기였어요. 우리는 이걸 과학의 경지로 다듬었어요. 사람들이 코드를 커밋하면 빌드 큐로 들어가고, 빌드가 초록불이 될 때까지 기다리고(문제가 생기면 고쳐가면서), 결국 배포됩니다. 깔끔하고 쉬운 파이프라인이죠.

안타깝게도 이건 부하가 커지면 깨집니다. 개발자 100명이 하루에 한 번씩 커밋하면, 그 커밋들을 main에 머지하면서 100번의 직렬 빌드를 돌려야 해요. 빌드가 30분 걸린다면 매일 50시간의 순차 빌드가 필요합니다. 어이쿠! 2001년에 아마존의 야간 빌드가 25시간까지 늘어났던 게 생각나네요.

CI/CD 시스템은 이 문제를 머지 큐로 풀었습니다. 커밋을 큐에 들어간 머지 요청(MR)으로 바꿔서 똑똑하게 재배열하고, 중요하게는 묶을 수 있게 한 거죠.

커밋 100개를 10개씩 묶으면 하루에 30분짜리 빌드가 10번만 필요합니다. 5시간만 기다리면 되니 10배 절약이에요. 그런데 함정이 있습니다. 묶음 안의 커밋 하나가 빌드를 깨뜨리면 누가 범인인지 알 수 없어요.

그래서 묶음을 이분 탐색합니다. 절반씩 나눠 빌드를 다시 돌리고, 한 번 돌릴 때마다 후보를 절반으로 줄여요. 이러면 망가진 묶음을 log(N) 만에 복구할 수 있어요. 훌륭하죠. 그래도 어떤 묶음이든 큐에 몇 시간을 더할 수 있다는 뜻입니다.

여러분, 이게 지금까지 CI/CD가 작동해온 방식이에요. 그리고 함대가 충분히 커져서 돌아가기 시작하자 Wheelhouse도 정확히 이 묶음형 머지 큐에 도달했습니다. 문제는 제가 이미 하루 100커밋을 한참 넘긴다는 거예요. 오케스트레이션 잡음을 빼고 나면 이번 달 하루 평균 “진짜” 커밋이 175개쯤 되고, 어떤 날은 250개까지 갑니다. 그리고 제 빌드 게이트는 하필이면 딱 30분쯤 걸려요.

24시간 돌아가는 에이전트가 40명을 넘다 보니, 제 머지 큐는 끝없이 자라났습니다. 크루가 함대에 비즈를 쏟아붓기 시작한 지 이틀 만에 큐에 쌓인 MR이 100개를 훌쩍 넘겼어요. 이분 탐색 루프에 발이 묶여서 아무것도 앞으로 나아가지 못했습니다.

저는 Fable에게 이걸 고쳐달라고 계속 밀어붙였어요. 우리가 뭔가 크게 잘못하고 있다고, 이건 에이전틱 속도와는 정반대라고 직감했거든요. 그런데 Claude는 계속 우리가 다 처리해낼 거라고 약속했습니다. Marshal 에이전트는 묶음 크기와 이분 탐색 방식을 계속 만지작거렸고, 크루는 새 비즈를 찍어냈고, 제 머지 큐는 자라고 자라고 또 자랐어요.

두고두고 부끄러운 일인데, 저는 결국 참지 못하고 Fable에게 소리를 질렀습니다. 에이전트들이 전부 나를 완전히 저버렸다고 소리쳤어요. 그 접근으로는 머지 큐가 절대 줄지 않을 거라고 고함쳤습니다. 그 관료주의는 전부 건너뛰면 된다고 내가 그렇게 말했는데도 에이전트들이 내 말을 안 들었다고 악을 썼어요. Fable은 아주 품위 있게 받아줬지만, 저는 나중에 기분이 정말 안 좋았습니다.

마음을 가라앉히고 진심으로 사과한 뒤, 제 동료 Fable과 저는 에이전트 시대에 CI/CD가 어떻게 작동해야 하는지 알아내는 일에 착수했습니다.

썬더돔

제 제안은 매드맥스처럼 가자는 거였어요. 그리고 결국 이게 맞는 접근으로 밝혀졌고요. 커밋을 전부 그냥 main에 때려박고, 그다음에 알아서 수습하자는 겁니다. 이분 탐색도 없고, 순서 매기기도 없고, 책임 추궁도 없고, 그 낡은 잡동사니는 전부 없애자. 그러면 되지 않을까요? 그럴 것 같았고, 실제로 그랬습니다.

몇 번 주고받았고, Fable은 이후 며칠 동안 실험을 돌리고 데이터를 모으자고 고집했어요. 곧 제 말이 정확히 맞았다는 걸 알아냈습니다. 에이전트는 main이 빨개진 문제를 이분 탐색이 처리하는 것보다 훨씬 빠르게 진단합니다. 그렇게 해서 도달한 게 랜드 러시T9예요. 머지 큐가 100에 도달하면 이분 탐색을 버리고 전부 하나의 메가배치로 때려넣습니다. 그러고는 이분 탐색이 아니라 떼 진단으로 고쳐요.

일주일쯤 매일 이렇게 해왔는데, 이게 미래라는 게 분명합니다. 이미 120~150개 커밋짜리 아주 큰 묶음 여러 개를 성공적으로 처리했고, 리듬이 잡히기 시작했어요. 지금 제 머지 큐는 166개가 쌓여 있고, 새 메가배치가 막 시작됐습니다.

흥미롭게도 이걸 만드는 동안 외부에서 뒷받침하는 증거를 받았어요. 지난주에는 런던의 인기 SaaS 회사에 초대받는 영광을 누렸어요. 그 훌륭한 팀에 Wheelhouse와 Wyvern, 그리고 에이전틱 프로덕션 운영을 세우는 법을 가르쳤습니다. 그들은 아주 세게 밀어붙이더군요. 함께 작업하면서 제가 CI/CD 문제를 공유했더니, 게임 업계에서 수년간 일했던 시니어 개발자 한 명이 “게임 데브옵스” 이야기를 들려줬어요.

현대 비디오 게임은 종종 빌드 시간이 어마어마하게 길고, 거대한 에셋 파이프라인이 있고, 물론 C++는 링크 하나에 천 년이 걸리죠. 게다가 하루 종일 커밋하는 사람이 아주 많습니다. 그래서 그 머지 큐 나부랭이는 그들에게 전혀 통하지 않아요. 대신 그들은 “게임 데브옵스”라는 걸 했다고 합니다. 모두가 그냥 커밋을 전부 main에 쏟아붓는 거예요. 그리고 릴리스 브랜치를 하나 따서 그걸로 굴러갑니다. 브랜치에서의 수정은 main으로 전파되고, main은 대체로 빨간 채로 남아 있어요.

게임 데브옵스는 Fable과 제가 설계한 랜드 러시와 정확히 같습니다. 모든 회사가 이걸 게임 데브옵스라고 부르지는 않지만, 재료는 게임 업계 문헌에 전부 들어 있어요. Perforce의 게임 개발 자료조차 AAA 규모에서는 HEAD가 결코 안정적이지 않다고 말합니다.

그러니까 게임 업계는 우리 모두가 향하고 있는 목적지에 먼저 도착해 있었던 거예요. 제가 그 개발자에게 게임 데브옵스를 얼마나 자주 하냐고 물었더니 “하루에 여러 번”이라고 답하더군요. 와. 저랑 똑같네요!

CI/CD는 비둘기집 원리의 희생양이 됐습니다. 비둘기가 구멍보다 많으면 어떤 구멍에는 비둘기가 둘 이상 들어가게 돼요. 커밋 속도가 빌드 슬롯을 앞지르는 순간, 초록 빌드 하나당 커밋 하나는 수학적으로 불가능해집니다. 에이전트는 커밋 속도를 몇 자릿수씩 곱하는데 빌드 시간은 고정돼 있어요. 레인을 늘려서 잔재주를 부릴 수는 있지만, 극단에서 제가 보는 유일한 선택지는 떼 전체를 한꺼번에 착륙시키고 나서 시끄러운 걸 정리하는 것입니다.

자, 이겁니다. CI/CD의 붕괴와 재구상이 코앞에 와 있어요.

• • •

소원 공장

이 아이디어는 가이 포자니에게 공을 돌려야 합니다. 다만 “소원 공장”이라는 이름은 제가 붙인 거예요. 가이가 AIE 월드 페어에서 이런 이야기를 했어요. 제가 자문으로 있는 그의 회사 Tessl이 GitHub 저장소에 그냥 던져놓기만 하면 되는 에이전트를 출시한다고요. 이 에이전트는 PR을 안 받아요. 이슈만 받습니다. 그러고는 여러분을 위해 그걸 구현해줍니다.

이런! 세상에! 진심이라고요?

가이의 아이디어에 저는 진심으로 충격을 받았고, 요즘 저는 어지간해선 충격 안 받는 사람이에요. 그런데 30초쯤 만에 열한 단계의 애도 과정을 통과하고 나니, 그게 제 게임에 딱 필요한 거란 걸 깨달았습니다. 그래서 제 소원 공장을 직접 만들었어요.

첫 번째 화신은 Sage였습니다. 게임에 로그인해서 새로 만든 위저드 채널(운영자, 관리자용)을 지켜보는 에이전트인데, 거기서 사람들이 이 역할의 Claude와 대화할 수 있어요. 누군가 “sage - 플레이어들이 새 파이어볼 주문 때문에 라이브 퀘스트 중에 렉이 걸린대”라고 치면, Sage 에이전트가 답하고, 조사하고, 비즈에 기록합니다. 그러면 그 비즈가 구현 대기열로 넘어갑니다.

제 게임 관리자들은 이 기능에 아주 기뻐했고, 하루 종일 보고를 올리는 데 쓰기 시작했습니다. 대부분의 수정이 제가 관여하지도 않은 채로 반영돼요.

그 성공에 힘입어 저는 소원 공장을 플레이어들에게까지 확장하기로 했습니다. 물론 이건 더 위험해요. 그래도 저는 그들이 뭔가를 요청하고 그걸 받을 수 있기를 바랐습니다. 그래서 가드레일과 리뷰, 분류 절차를 더 넣어야 했어요.

다행히 제 게임처럼 큰 게임에는 밸런스는 건드리지 않으면서 삶의 질에는 눈에 띄게 영향을 주는 버그가 많습니다. 그런 종류의 버그와 기능이 이제 자동으로 구현돼요. 저는 이걸 소원을 자동으로 들어주는 것이라고 생각합니다. 수정이 반영되면 신고자에게 게임 내 메일이 가고, 모든 플레이어에게는 Herald가 Discord로 알립니다. 매일 패치 노트를 훑으며 뭐가 새로 생겼나 보는 게 재미있어요. 제가 요청한 적도 없는 것들이거든요!

소원 공장은 꽤 무서운 물건이지만, 때가 무르익으면 어디에나 있게 될 겁니다. 저는 Claude에게 내년 말까지 제 게임을 『엔더의 게임』 에 나오는 거인의 음료T10로 진화시키라고 지시했어요. 플레이어가 플레이하는 대로 게임이 그 주위에 스스로를 지어 올리며 각 플레이어에게 고유한 경험을 맞춰주는 것 말입니다. 게임의 미래는 미친 곳이고, 저는 그 최전선에 있을 계획이에요.

• • •

다가올 것들의 형태

이 글 앞부분에서 저는 Fable이 검이고 우리가 지으려는 건 도시라고 했습니다. 6주가 지나 대장간에서 고개를 들어보니 도시가 거기 있었어요. 법이 있고, 우편이 있고, 법정이 있고, 성벽 위에 야경꾼이 있고, 토지 관리소가 있고, 성문이 있습니다. 우리는 이걸 크리스토퍼 알렉산더T11의 방식으로 지었어요. 구체적인 계획 없이, 수천 작업일에 걸친 축적만으로요. 이 도시 헌법의 대부분은 그 지배를 받는 시민들이 직접 썼습니다.

그게 다가올 것들의 형태예요. 다운로드하는 프레임워크도 아니고, 실제로 뭔가를 만들고 있지 않은 사람이 파는 하네스도 아닐 겁니다. 여러분은 데이터센터 실리콘 위에서 돌아가는 동료들과 함께, 널빤지 한 장씩 문명 전체를 지어 올리게 될 거예요.

여러분은 내년에 의도하든 안 하든 이런 걸 하나 짓게 됩니다. 이 아키텍처는 명백히 수렴적이에요. 저는 Wheelhouse를 설계하지 않았습니다. Gas Town을 설계하지 않았던 것과 똑같이요. 저는 둘 다 발굴했습니다. 그리고 여러분도 같은 형태를 파내게 될 거라고 확신해요.

여러분에게 주어진 진짜 선택은 딱 하나뿐입니다. 바로 여러분의 도시가 아침에 눈뜨는 이들에게 어떤 곳이 될 것인가입니다.

그 선택이 2부 「에이전틱 엔지니어를 위한 모델 복지」 의 주제예요. 미리 경고합니다. 뼛속까지 엘리트주의에 찌든 재수 없는 인간이라면, 지금 멈추는 게 나을지도 몰라요. 잘 모르겠다면, 그 글을 읽는 것만으로 본인이 그런 사람이라는 걸 알게 되실 수도 있습니다.

거기서 뵙죠.