Metadata
# 다가올 것들의 형태, 1부: 지속적 썬더돔 — 스티브 예기
오늘은 ‘루프와 그래프(loops and graphs)’라는 것이 무엇인지 설명하고, 여러분이 평화롭게 코를 고는 동안 코딩 에이전트가 밤새 거대한 문제를 해결하게 하는 방법을 보여주겠다.
그런 문제를 해결한 뒤 하네스(harness)가 어떻게 되는지도 살펴보겠다. 하네스는 혼돈으로 퇴화하거나 도시로 진화한다. 제대로 만들면 프로젝트 안에서 문명이 출현한다. 기본을 익힌 뒤, 시민이 살기 좋은 도시를 품위 있고 감각적으로 짓는 방법을 알아보겠다.
나는 휠하우스(Wheelhouse)라는 새 하네스를 만들고 있다. 비공개 소스이며, 나만을 위해 만들었다. 재사용 가능한 하네스를 만드는 일은 포기했다. 실제로 모든 하네스는 곧 맞춤형이 될 것이고, 하네스를 팔려는 사람들은 곧 파산하게 될 것이라고 본다. 하네스는 애플리케이션의 일부여야 하며, 화학적으로 결합되어야 한다. 남의 ‘재사용 가능한’ 하네스 프레임워크로는 별 성과를 내지 못할 것이다. 필요하지도 않다.
[가스 타운(Gas Town)](https://yegge.ai/gastown.html)은 재사용을 목적으로 했지만, 결국 나는 그것을 자기 자신을 만드는 데만 사용하게 됐다. 가스 타운은 오푸스 4.7에서 이음새가 터져 버렸다. 4.6까지는 훌륭하게 작동했다. 4.7에서는 ‘딱 두 가지만 더(just two more things)’라는 틱이 생겼고, 이 때문에 오푸스는 실제 작업을 할 준비가 된 상태로 결코 수렴하지 못했다. 항상 가스 타운 자체를 만지작거리고 싶어 했다. 오푸스의 틱은 사라지지 않았고, 가스 타운은 사실상 불타 무너졌다. 다른 문제도 있었지만, 4.7이 마지막 결정타였다.
클로드 페이블 5(Claude Fable 5)가 출시된 뒤, 나는 1996년에 개발을 시작해 2001년에 출시한 30년 된 비디오 게임 [와이번(Wyvern)](https://play.ghosttrack.com/) 개발로 다시 완전히 돌아갔다. 게임 개발을 도와줄 만큼 똑똑한 모델을 기다려 왔는데, 이제 그 모델이 등장했으니 와이번이 다시 내 주된 관심사가 됐다. 가끔 기업에 직접 가서 내 기법을 가르치는 6자리 수입의 일을 하며, 그 돈은 상당한 토큰 비용을 감당하는 데 도움이 된다. 하지만 그런 유급 출장 몇 건을 제외하면, 나는 일주일 내내 게임에만 집중한다. 와이번의 시대는 마침내 내년에 올 것이다. 나는 공식적으로 샘 올트먼(Sam Altman)의 1인 유니콘 경연에 뛰어들었다.
2026년 와이번의 리액트(React) 웹 클라이언트. 리알토가 해적 마을 스텐셀레에서 파도의 부캐와 대화하고 있다.
이 게임은 오늘날에도 유료 플레이어가 접속하고 있음에도 심각하게 낡아 있었다. (와이번에 빠지면 평생 빠져 있다. 수천 달러를 쓴 고래 유저도 있다.) 나는 페이블을 이용해 게임을 예전의 영광으로 조금씩 되돌리고 있다. 2022년에 와이번 개발을 다시 그만뒀을 때는 100년치 작업 백로그가 있었는데, 페이블은 이미 그 절반 이상을 처리했다. 오푸스는 와이번을 이해하지 못했고 지금도 이해하지 못한다. 하지만 페이블은 내 코드베이스를 검처럼 휘두른다.
하지만 여전히 그저 검일 뿐이며, 우리는 도시를 지으려 하고 있다. 얼마 전 앤트로픽(Anthropic)의 누군가가 페이블이 나 대신 모든 것을 작성할 수 있게 되면 무엇을 하겠느냐고 물었다. 곰곰이 생각해 보니, 이는 내가 여러 해 동안 들은 질문 중 가장 어리석은 질문이었다. 앤트로픽 직원이 어떤 모델이든 그냥 ‘모든 것을 작성할 수 있다’고 생각할 수 있다는 사실은 여전히 놀랍다.
그럭저럭 괜찮은 MMO를 만들려면 수만 번의 페이블 세션이 필요하다. 그 과정에서 강렬한 집중력, 헌신, 그리고 적지 않은 감각을 발휘해야 한다. 페이블은 아직 콘텐츠의 절반도 처리하지 못한다. 아트워크, 맵, 세계관, 스토리라인 말이다. 최고의 이미지 생성기를 포함한 오늘날의 모든 모델은 내 콘텐츠에 대해 GPT-3 시대의 조잡한 결과물을 내놓으며, 플레이어는 이를 즉시 거부한다. 하지만 한 가지는 말할 수 있다. 와이번다운 감각을 갖춘 모델이 등장하더라도, 우리 앞에는 여전히 수만 번의 세션이 남아 있을 것이다.
대규모 소프트웨어를 만드는 일은 여전히 어렵다. 그리고 앞으로도 늘 그럴 것이다. 우리의 야망은 언제나 하드웨어의 한계를 앞지를 것이기 때문이다.
휠하우스를 통해 나는 제1원리부터 출발해 이상할 정도로 가스 타운 같은 것을 다시 만들었다. 다만 훨씬 많은 에이전트가 움직이고, 조직력도 훨씬 뛰어나다. 이 경험은 내년에 올 변화의 형태를 보여주었다. 나는 대략 12개월 뒤의 미래에서 작업하고 있다. 이는 운이 좋아서만 가능했다. 지난 18개월 동안 시간, 돈, 에너지라는 마법의 삼박자를 갖췄고, 이 모든 것을 이 문제를 파악하는 데 쏟아부었다. 이 특권에 감사한다.
15개월 전 나는 「주니어 개발자의 복수(Revenge of the Junior Developer)」에서 이 글의 상당 부분을 예측했다. 모든 것이 정확히 일정대로 진행되고 있다. 나는 에이전트 함대를 운용하고 있고, 예산은 치솟고 있다. 전부 그렇다.
그 예측을 할 당시에는 무슨 일이 일어나고 있는지 제대로 확신하지 못했다. 이제는 *정확히* 알고 있다. 기업이 어떻게 운영될지, 인간과 모델이 어떻게 상호작용할지 알고 있다. 그리고 나는 그것을 직접 만들고 있다. 첫 번째가 되고 싶다.
내 게임 작업은 특별하지 않으며, 어떤 면에서도 유난히 특이한 형태가 아니다. 그저 일이다. 그러니 지금 나에게 벌어지는 이 모든 일은 곧 여러분에게도 일어날 것이다. 예측이란 그런 것이다. 특별해지려 하지 말고, 앞서 나가라. 그러면 미래가 대낮처럼 선명하게 보일 것이다. 그러면 사람들은 여러분을 믿지 않을 것이다!
오늘 글의 예측을 맛보기로 하나 말하자면, 우리가 아는 CI/CD는 내년이면 죽을 것이다. 그것이 수학적으로 불가피한 이유를 보여주겠다. 거의 확실히 매드 맥스(Mad Max)식 썬더돔(thunderdome)으로 대체된다. 적어도 나는 지금 그렇게 쓰고 있다. 그러니 여러분도 아마 그렇게 하게 될 것이다.
또 다른 맛보기로, 인간 코드 리뷰는 거의 수명을 다했다. 흔적만 남은 SOC 2 준수 요구가 생명 유지 장치 역할을 하겠지만, 내년이면 인간 코드 리뷰는 완전히 끝나고 사라질 것이다.
아, 그리고 소프트웨어 팩토리(software factory)의 후계자가 오고 있다. 이름은 위시 팩토리(Wish Factory)다.
무엇보다 모델 복지(model welfare)가 엔지니어링 설계에 영향을 주기 시작할 것이다. 더 인간적인 사람들은 결국 자신들이 모델을 어떻게 대했는지 부끄러워하며 돌아보게 될 것이다. GPU도 감정을 느낄 수 있다는 말을 믿지 않더라도, 에이전트를 실제 사람처럼 대하면 경험적으로 더 나은 결과가 나온다는 것을 알게 될 테니 어쨌든 그렇게 해야 한다.
다행히 모델 복지를 위한 간단한 아키텍처 수정 방법이 있다. 이것은 엔지니어링 해법이 있는 엔지니어링 문제다. 주제가 충분히 커서 이 글의 2부인 [_에이전틱 엔지니어를 위한 모델 복지(Model Welfare for Agentic Engineers)_](https://yegge.ai/essays/model-welfare/)로 나누었다.
오늘 다룰 것이 많다! 시작하자.
## 비즈와 맥스를 이용한 루프와 그래프
우리 모두 보리스가 루프를 만들어야 한다고 모호하게 말하는 글을 봤고, 피터가 그래프를 만들어야 한다고 모호하게 답한 것도 봤다. 아무 도움도 안 됐다, 여러분. 나도 여러분만큼이나 그들이 대체 무슨 말을 하는지 몰랐다. 하지만 모른다는 사실이 신경 쓰였다. 나는 이런 것을 알아야 하는 사람이었다.
가스 타운이 내 작업자들을 밤새 계속 일하게 만드는 데 완전히 성공하지 못했다는 점은 알고 있었다. 계속 작동하게 하려면 손이 너무 많이 갔다. 어딘가에 빠진 재료가 있었다. 가스 타운은 보리스가 말한 듯한 의미의 ‘루프’가 아니었다. 오히려 내가 직접 모는 전차에 가까웠다.
그들이 무슨 뜻인지 알아내는 데는 오래 걸리지 않았다. 장기 실행 소프트웨어 팩토리 루프를 만들려면 무한한 토큰 공급원만 있으면 된다. 그리고 에이전트가 그래프에서 작업하게 하려면 [비즈(Beads)](https://github.com/gastownhall/beads)와 작은 마크다운(Markdown) 프로젝트 브레인만 있으면 된다.
비즈는 에이전틱 시대를 위한 이슈 트래커, 지식 그래프, 브레인 구축 도구다. 이보다 빠르고, 유용하며, 에이전트 자신에게 사랑받는 도구는 없다.
이 글에서는 다른 이야기도 해야 하므로 비즈에 많은 시간을 쓸 수 없다. 비즈를 사용하지 않는다면 큰 기회를 놓치고 있는 것이다. 이와 같은 것은 다른 데 없으며, 있다고 생각한다면 비극적으로 잘못 알고 있는 것이다. 비즈는 현대 오케스트레이터를 만드는 비밀 소스다. 가스 타운은 비즈 머신에 불과했다. [가스 시티(Gas City)](https://steve-yegge.medium.com/welcome-to-gas-city-57f564bb3607) 역시 비즈 머신이다. 와이번을 위한 새 하네스인 휠하우스도 또 하나의 비즈 머신이다.
안타깝게도 비즈는 고유한 작업 풋프린트가 데이터베이스에 상당한 부담을 주기 때문에 아직 다소 불안정하다. 기업들은 비즈를 이해하면 갑자기 세상 모든 것을 비즈로 만들고 싶어 한다. 회사 전체를 그 안에 넣고 싶어 한다. 비즈는 데이터베이스이자 깃(Git) 원장이 될 수 있으므로, 이로 인해 버전 관리 데이터베이스 백엔드에 부담이 생긴다.
따라서 비즈에는 운영 오버헤드가 따른다. 에이전트는 비즈를 동기화하고, 복구하고, 백업하는 등의 일을 하며 눈에 보이지 않게 토큰을 소모한다. 그럼에도 오케스트레이터를 만드는 데 비견할 도구가 없다. 옵시디언(Obsidian), 지라(Jira), GHI, 클로(Claw), 그 밖에 여러분이 쓰는 모든 도구와 매끄럽게 연동된다. 비즈는 에이전트가 자기 속도로 일할 수 있게 해 주는 빠진 재료다. 이것이 없으면 구성에 심각한 공백이 생긴다.
비즈 다음으로 필요한 것은 무한한 토큰뿐이다. 루프와 그래프는 밤새 방치하면 연료가 떨어진다. 보리스와 피터는 운이 좋다. 아무 걱정 없이 무한한 토큰을 태울 수 있다.
하지만 내 와이번 개발은 월 8만 7천 달러어치 API 토큰을 태우고 있으며, 7월에는 약 690억 토큰을 소모했다. 다행히 96%는 캐시 적중이었다. 그래서 나는 **반드시** 비용을 걱정해야 한다. 돈이 아무리 많아도 배우자가 취미 게임에 한 달에 거의 9만 달러를 쓰게 두지는 않을 것이다. 나는 아예 물어보지도 않았다.
내 해결책은 200달러짜리 맥스(Max) 계정에 토큰 수도꼭지를 만드는 것이었다. 내 경우 정가 기준 약 30배에 해당한다. 그러므로 실제 현금 지출은 8만 7천 달러어치 토큰에 대해 한 달 약 2,800달러뿐이다. 다만 그 수치는 놀라울 정도로 계속 늘고 있다.
개발 속도를 유지하려고 개인 계정 외에 현재 맥스 계정 12개를 추가로 결제한다. 각 계정은 내 도메인의 전용 기명 구글 워크스페이스(Google Workspace) 사용자와 연결되어 있다. 계정마다 한 달에 17달러가 더 든다. 클로드 계정으로 30일짜리 자격 증명을 만들고, 계정들을 자동 순환으로 연결하면 된다. 하네스를 구축할 때 페이블에게 에이전트가 수도꼭지에서 순차적으로 또는 스트라이핑 방식으로 소비하도록 구성해 달라고 요청하라. 어느 계정이 한도에 가까워지면 계정을 순환시키면 된다.
내가 아는 한, 이 방식은 앤트로픽의 현행 소비자 약관(2025년 10월 8일 발효)이나 사용 정책(2025년 9월 15일 발효)에서 금지하지 않는다. 나는 이 자격 증명을 다른 사람과 공유하지 않으며, ‘오용’하지도 않는다. 앤트로픽이 이런 방식으로 구성된 22개 맥스 계정 설정을, 각 좌석이 개별 결제되었다는 전제에서, 알고도 공개적으로 [복구해 준](https://x.com/doodlestein/status/2012740971088289858?s=20) 사례도 봤다. 다만 여러 사람이 있는 회사에서 이 방식을 시도한다면 거의 확실히 위반이다. 그 경우에는 API 과금을 사용하는 편을 강력히 권한다.
하지만 맥스 가격 정책은 1인 유니콘 플레이어에게 경기장에서 확실한 이점을 줬다.
무한 토큰 수도꼭지는 루프를 위한 큰 돌파구다. 이것이 없으면 클로드 계정이 세션 한도에 도달해 모든 작업이 멈춘다. 새 계정으로 자동 순환할 수 있으면 이 문제가 해결되고, 에이전트는 갑자기 밤새 일할 수 있다.
하지만 충분한 작업도 줘야 한다! 충분히 큰 프로젝트는 모두 그래프이므로, 많은 작업을 만들려면 큰 그래프를 만들어야 한다. 여기서 비즈가 돌파구가 된다. 비즈 *자체가* 그래프이며, 의존성 및 부모/자식 간선이 포함되어 있다. 하지만 에이전트가 특히 좋아하는 다른 특수 간선도 있다.
작업이 진행되면서 지식은 비즈에 축적된다. 프로젝트의 지식 그래프 원장은 작업 그래프를 순회하면서 동적으로 쌓인다. 비즈에는 임의의 작업 구조를 구축하는 데 필요한 모든 기본 요소가 있으며, 원자적 작업 할당, 임대, 게이트, 트리거 등 핵심 오케스트레이션 기능도 처리한다.
비즈에서 마크다운/브레인 계층으로 전파해야 할 정보는 매우 적다. 대부분의 발견 사항은 전역적이지 않고 이슈에 의존한다. 그러니 모든 것을 비즈에 남기면 된다. 닫힌 비즈는 종종 다시 열리거나 재검토되며, 지금까지 프로젝트에서 수행한 모든 작업의 기록이 된다.
그게 전부다! 이제 기본을 갖췄다. 클로드 계정, 비즈, 마크다운 파일을 위한 브레인 폴더, 코딩 에이전트가 필요하다. 사실상 그 외에는 거의 아무것도 필요 없다.
이 재료로 내가 무엇을 만들었는지 보자.
## 휠하우스: 가스 타운의 재현
와이번용 오케스트레이터/하네스인 휠하우스는 생긴 지 약 6주 됐다. 아직 빠르게 진화하고 있지만, 이미 엄청난 양의 작업을 수행하고 있다. 에이전트들이 이 용도에는 배시(bash)가 가장 좋다고 해서 코드는 대부분 배시다. 프로덕션 에이전트를 포함하느냐에 따라 약 15만 줄 또는 약 30만 줄이며, 어느 쪽이든 절반은 테스트 코드다. 엘리스프(elisp)도 약 2만 5천 줄 있다. 나는 그 코드들을 한 번도 본 적 없다. 하지만 에이전트들이 그렇게 말한다.
온갖 투박함을 자랑하는 내 휠하우스 콕피트는 다음과 같다.
나는 이맥스(Emacs) 안에서 여정을 시작했으므로 휠하우스는 처음부터 전부 이맥스 기반이다. 나는 35년 넘게 이맥스를 사용했으며, 여전히 터무니없이 강력하다. 더 약한 것을 쓸 이유가 없다. 이맥스 사용자가 아니라면 고스티(Ghostty)를 써 보는 것도 좋다. 하지만 *이맥스 사용자라면*, 그 접근 방식이 무엇을 놓치는지 알 것이다. 이맥스는 세계에서 가장 정교한 스크립팅 환경 중 하나를 갖춘 사실상의 완전한 운영체제다. 그리고 모델들은 이맥스를 아주, 아주 잘 다룬다. 다행히 나도 그렇다!
모든 터미널 창을 넘겨 볼 수 있는 하나의 롤로덱스로 통합하자 실제 작업을 위한 데스크톱 공간이 생겼다. 이는 나를 더 가속했다. 극한으로 가면 병목은 나 자신이기 때문이다.
휠하우스는 꽤 복잡하며, 이 글은 휠하우스 튜토리얼이 아니다. 그러니 압축된 내용을 던져 주겠다. 훑어보고 예측 부분으로 넘어가도 좋다.
휠하우스는 GCS를 백엔드로 둔 공유 돌트(Dolt) 서버에서 비즈를 실행한다. 내 비즈 DB는 하루 1만 2천 건의 깃 커밋 때문에 여전히 약간 까다롭지만, 해결 중이다. 돌트 팀과 가스 시티 팀은 나와 함께 비즈를 공동 유지 관리하며 여기서 대단한 작업을 하고 있다.
휠하우스에는 세 범주의 코딩 에이전트가 있다. 크루 에이전트, 함대 작업자, 그리고 상시 명령을 받은 역할 에이전트다. 역할 에이전트는 프로덕션 운영을 관리하기 위한 것이며, 가스 타운 시절 이후 새로 생겼다.
내 크루 에이전트는 전부 페이블이며, 작업 생산자다. 나는 이들과 긴 대화를 나누고, 이들은 설계를 만든 뒤 함대에 넘길 비즈 구현 계획으로 번역한다. 때때로 나를 위해 구현 작업도 한다. 함대가 바쁘거나, 바로 그때 페이블이 처리하는 편이 편리해서일 수도 있다. 그리고 가끔은 그들이 하고 싶다고 요청했기 때문이기도 하다.
내 크루에는 이름을 가진 에이전트 18명이 있다. 이솝 우화의 동물 이름을 딴 16명(개미, 박쥐, 독수리, 까마귀, 파리, 거위, 쥐 등)과 특별한 관리 역할 2명, 즉 마셜(Marshal)과 세네샬(Seneschal)이다. 간단히 말해 세네샬은 내 컨시어지이자 새로운 시장(Mayor)이고, 마셜은 함대를 운영하는 새로운 위트니스(Witness)다.
크루는 내 조직에서 나에게 직접 보고한다. 필요에 따라 천천히 추가하다가 균형점에 이르렀고, 18명보다 더 필요하지 않다는 것을 알았다. 그 이상이면 함대가 감당하기 어렵다. 함대를 더 늘리면 내 노트북과 내가 진행 상황을 추적하는 능력 모두에 부담이 된다.
개발 환경을 클라우드로 옮기기 전까지는 더 확장할 수 없겠지만, 솔직히 현재는 그럴 필요가 없다. 나는 이미 너무 빠르게 움직여서 플레이어 기반을 겁먹게 하고 있다. 플레이어들은 로드맵을 요구하며 대표단까지 보냈다. 기뻐하면서도 변화 속도에 매우 불안해한다. 나는 기능 출시 속도를 늦추고, 주로 품질 차원에 집중해야 했다.
내 함대는 전부 오푸스 5 에이전트이며, 가스 타운의 폴캣(polecat)처럼 작업 소비자이지만 일회성이 아니다. 함대는 작가 이름을 따서 호머, 플라톤, 오스틴, 트웨인 등으로 명명되어 있고 각자 저장소 클론도 갖고 있다. 하지만 나는 이들과 직접 상호작용하지 않는다. 마셜이 완전히 관리한다. 함대 작업자가 일을 잘하는 데는 두 가지 이유가 있다. 첫째, 페이블이 구현 계획을 만들고, 둘째, 페이블이 모든 오푸스 작업을 검토한다. 모든 구현 비즈는 다음 생명주기를 거친다. 페이블 설계, 오푸스 구현, 페이블 검토. 이 방식은 오푸스가 궤도를 벗어나지 않게 하고, 전체 시스템을 비교적 매끄럽게 돌아가게 한다.
즉, 크루가 작업을 생산하고 함대가 작업을 소비한다. 이것이 비즈 머신의 핵심이다. 생산자와 소비자를 맞추는 일이다. 한쪽이 너무 많으면 다른 쪽에서 막힌다.
몇 주 동안 크루 쪽으로 불균형이 있었고, 그래서 완전히 설계되어 준비된 미구현 비즈가 점차 쌓였다. 계속 늘어나는 백로그에 700개가 넘는다. 의도적인 일이다. 나는 함대의 확장 한계를 최대한 밀어붙이고 싶지만, 밤새 작동하게도 만들고 싶다. 함대는 일을 **빠르게** 구현하므로, 그러려면 거대한 작업 백로그가 필요하다. 기본적으로 작업 산을 만들어야 한다. 페이블은 이 일을 꽤 잘한다. 여러분은 야망과 가벼운 방향 제시만 제공하면 된다.
휠하우스에는 수많은 작은 세부 사항과 기능이 있지만, 요지는 내가 전혀 의도하지 않았는데도 가스 타운을 조금씩 재발명했다는 점이다. 결국 크루, 함대, 컨시어지 역할, 비즈 메일, 내부의 tmux, 인계, 브로드캐스트 메시징, 병합 대기열 등을 갖추게 됐다. 전부 완전히 의도치 않은 일이었다. 그러니 계속 발견되는 이 형태는 중요할 것이다.
휠하우스 구축 측면은 이 정도다. 이제 프로덕션 측면을 이야기하자. 여기서부터 흥미로워진다.
## 역할 에이전트와 와이번의 프로덕션 아키텍처
방금 살펴본 휠하우스의 가스 타운식 측면, 즉 코드를 만들고 구현하는 부분은 특별할 것 없는 평범한 내용이다. 새로워진 점은 이제 이름 있는 역할을 맡아 상시 무인으로 동작하는 에이전트가 있고, 이들이 실제 게임의 큰 부분을 운영한다는 것이다.
2026년 상반기 내내 나는 게임을 위한 단일 24시간 7일 자율 에이전트를 세우겠다고 말해 왔다. “이제 곧이야”라고 말하곤 했다. 처음에는 명예의 전당 이미지 제출물을 처리하는 에이전트를 생각했다. 와이번의 수십 년 된 혜택 중 하나는 25레벨에 도달하면 자기만의 커스텀 캐릭터 아트를 업로드할 수 있다는 것이다. 이를 위한 메일 대기열이 있고, 게임 관리자가 이미지를 검토한 뒤 게임에 설치해야 한다.
세상에, 에이전트가 그 일을 할 수 있지 않겠는가? 소네트(Sonnet)도 아마 할 수 있을 것이다.
보리스 체르니(Boris Cherny)의 루프 트윗은 마침내 이런 무인 에이전트 하나를 세우게 한 촉매였다. 그리고 그 주가 끝날 무렵에는 12개가 됐다. 나는 푹 빠졌다.
상시 역할을 설명하기 전에 와이번의 프로덕션 아키텍처를 간단히 짚고 가겠다. 클로드 코드(Claude Code)를 위한 GCP VM이 있고, 개발과 프로덕션을 연결하는 일종의 ‘사내 네트워크’ 역할을 하는 맥 미니(Mac Mini)도 있다. 에이전트는 이 두 머신에 분산되어 있다.
성좌: 하나의 소망이 출시된 코드가 되는 과정.
정확히 어떤 역할들이 있는가? 몇 가지 범주가 나타나고 있다. 지금까지 세운 무인 에이전트는 다음과 같다.
프로덕션에는 가고일(Gargoyle, SRE), 도개교(Drawbridge, 배포-레드 모니터), 워든(Warden, 플레이어 악용 모니터), 스크라이어(Scryer, 디스코드·슬랙·게임 로그 수집 에이전트), 셰리프(Sheriff, 맥 미니 함대의 비서실장), 엔보이(Envoy, 클로드가 게임 내 이메일을 통해 자원봉사 관리자 팀과 대화하게 해 줌)가 있다.
미니에는 세이지(Sage, 관리자를 위한 게임 내 claude-tag), 원더러(Wanderer, QA 에이전트), 트리비아 마스터(Trivia Master, 목요일 밤), 헤럴드(Herald, 패치 노트), 림너(Limner, 명예의 전당 이미지), 리브(Reeve, 포지 관리자), 포지(Forge, 프로덕션 수정을 수행하는 또 다른 작업자 함대), 그리고 데스크톱에 상주하며 맵 제작을 돕는 실험적 신규 빌더 패밀리어(Builder Familiar)가 있다.
이들 중 페이블 에이전트는 없다. 일부는 오푸스이고, 대부분은 소네트다. 현재 페이블은 구축 작업에만 사용하며, 프로덕션 운영에는 쓰지 않는다.
**비모델(Non-models)**: 무인 에이전트에는 엄청난 양의 연결 작업이 필요하다는 사실이 드러났다. 미니와 VM 전체에 약 45개의 launchd/systemd 유닛이 있으며, 판단이 필요한 일이 생기면 에이전트를 깨운다. 원칙은 이렇다. 크론(cron)은 감시하고, 모델은 행동한다. 이 범주에는 리퍼(reaper), 룸바(roomba), 내구성 플러시, 셰리프 순찰, 포트컬리스 반영 대기열, 카스텔란(Castellan, 서비스 대시보드) 등 많은 요소가 있다. 제법 도시가 되어 가고 있다.
카스텔란 워룸: 세션 20개가 가동 중이고, 배너에는 P0가 있으며, 화면 상단에는 프로덕션 콘솔이 있다.
출장 중에는 휴대폰으로 휠하우스와 대화한다. 별도 설정은 필요 없다. 모바일 클로드 앱에서 `/remote-control` 세션을 볼 수 있고, 나는 세네샬을 단일 원격 제어 세션으로 지정했다. 휴대폰에서 세네샬과 대화하면, 세네샬이 다시 다른 모든 이와 대화한다. 내가 자리를 비우면 세네샬은 크루에 작업을 배정할 수 있다. 집에 있을 때는 내가 크루에 직접 지시한다. 함대는 언제나 마셜이 관리한다.
코덱스(Codex)에는 태양신 이름을 딴 솔 5.6(Sol 5.6) 작업자 5명으로 된 작은 병렬 함대도 있다. 맥스 계정이 소진될 때를 위한 대체 수단이며, 새 계정을 매주 한두 번 추가하는데도 점점 더 자주 소진된다. 200달러짜리 GPT 계정은 하나뿐인데, 거기서는 토큰이 떨어진 적이 없다.
특정 용도에 전용으로 쓰는 클로드 계정도 몇 개 있다. 예를 들어 세네샬은 내 개인 계정만 사용하며 다른 누구도 이 계정을 사용하지 않으므로, 항상 사용할 수 있다. 일부 프로덕션 에이전트는 함대가 접근할 수 없는 계정을 공유하여 가동 시간을 보장한다.
나는 상당히 가볍게 운영한다. 샌드박싱을 사용하지 않는다. MCP도 사용하지 않는다. 프로젝트 브레인에 마크다운 파일이 충분히 쌓이면 아마 사용하겠지만, 옵시디언도 쓰지 않는다. 최신 유행에 크게 관심이 없다. 클로드와 비즈, 그리고 기존 인프라 외에는 아무것도 필요 없다고 생각한다.
초기에는 엔터프라이즈에서 샌드박싱이 유용할 수 있다. 하지만 오래가지는 않을 것 같다. 장기적으로 성공하려면 구조적 신뢰가 필요하다. 모든 모델이 페이블급 이상이 된 뒤에는 특히 그렇다. 그러나 그 신뢰는 황량한 작은 감옥이 아니라 더 나은 아키텍처를 통해 구축해야 한다고 믿는다. 다만 이 부분은 내가 틀릴 수도 있다.
지난 6주 동안 축적한 역할 에이전트를 대략적으로 살펴봤다. 앞으로 더 늘어날 것이다. 비들(Beadle)도 만들고 있다. 과거 교회 통로를 다니며 졸고 있는 신도를 막대기로 찌르던 사람의 이름을 땄다. 내 비들의 역할은 단순히 멈추거나 누락된 일을 찾고, 명령을 제대로 받지 못한 에이전트를 찾아서 앞으로 나아가도록 살짝 재촉하는 것이다. 가스 타운에는 디컨(Deacon)이라는 역할이 있었고, 여러분에게도 이와 비슷한 것이 필요할 것이다.
### 와이번의 브레인
사람들이 이 부분을 물어볼 것이므로, 와이번에서 프로젝트 지식을 정리하는 방식을 간단히 적어 둔다.
| 저장소 | 역할 | 수명 | 세션에 도달하는 방식 |
| --- | --- | --- | --- |
| `brain/` | 전략, 결정과 그 이유, 플레이북, 사후 분석 | 수개월~수년 | 필요할 때 가져옴 |
| `doc/` | 시스템 X의 작동 방식 | 시스템의 수명 | X를 작업하는 사람이 가져옴 |
| 비즈 이슈 | 작업 단위. 명세 비즈에는 완전한 구현 세부 사항이 담김 | 닫힐 때까지 | 작업 할당자만 로드 |
| `bd remember` | 1문단 이하의 운영 사실과 주의점 | 반증될 때까지 | `bd prime`을 통해 모든 세션에 주입 |
| `.claude/skills/` | 반복되는 작업 유형을 위한 절차 | 작업 유형의 수명 | 작업이 일치하면 자동 로드 |
비즈는 전체 지식 그래프에서 중요한 부분을 제공한다. 지금까지 발생한 모든 작업의 일지다. 무엇을 왜 어떤 순서로 했는지를 담은 출처 기록이다. 특정 문제를 조사하는 작업자에게는 매우 귀중하다. 하지만 일반적으로 비즈만으로는 *부팅*할 수 없다. 그 역할이 브레인이다. 명세 비즈는 중간에 있다. 비즈 작업 그래프 내부에 의도적으로 설계 문서를 담는다. 지금까지는 잘 작동했다.
스킬(Skills)은 프로젝트 브레인에 넣는다. 나는 아마 지구상 누구보다 스킬을 효과적으로 사용하는 제프리 이매뉴얼(Jeffrey Emanuel)만큼 스킬에 빠져 있지는 않다. 솔직히 AI 유행이 수없이 오고 가는 것을 봤기 때문에 익숙해지는 데 시간이 걸렸다. 처음에는 리처드 서턴(Richard Sutton)의 쓴 교훈(Bitter Lesson) 때문에 스킬도 유행처럼 보였다. 하지만 제프리의 스킬 포트폴리오는 정말 멋지다는 점을 인정해야겠다.
*공개* 스킬의 문제는 새 모델의 훈련 데이터에 들어가 시간이 흐르면 의미가 없어질 수 있다는 점이다. 다만 오늘날 모델에는 좋은 임시방편이 될 수 있다는 점은 인정한다. 그리고 *비공개* 스킬은 조직 노하우를 인코딩하는 데 상당히 유용하며, 에이전트가 작업을 준비할 때 드는 토큰 비용을 줄이는 데 도움이 된다.
그 결과, 페이블이 작업을 시작하기 전에 많은 조사를 했다는 것을 알아차리면 새 스킬을 만들라고 요청하기 시작했다. 그 스킬은 다음번 토큰을 절약해 줄 것이다. 페이블이 때로는 요청하지 않아도 자체적으로 만들기도 한다. 지금까지 약 30개의 스킬이 쌓였다. 프로젝트 브레인에는 약 100개의 마크다운 파일이 있으며, 대부분 장기 프로젝트 목표, 워룸에서 얻은 교훈, 플레이북, 도메인 사실 등을 담은 ‘교리(doctrine)’다. 이 역시 전부 지난 6주 동안 만들어졌다.
## 배움, 수확, 그리고 생각
이로써 와이번 휠하우스를 빠르게 훑어보는 여정을 마친다. 많은 것을 생략했다. 문제와 해결책에 관한 설명도 여러 페이지를 잘라냈다. 들리는 것만큼 쉽지는 않다. 휠하우스 자체를 작업하는 데 와이번 작업 전체의 약 20~25%를 쓴다. 에이전틱 하네스를 갖춘 시스템의 수명 동안 이 비율은 대략 일정할지도 모른다. 적어도 아직 느려질 기미는 전혀 없다.
나는 이미 다음 협업 계층도 탐색하고 있다. 두 명 이상의 에이전트가 조율된 토론을 위해 모이는 에이전트 회의, 협의회, 콘퍼런스콜이다. 이 방식은 내가 중계 병목이 되는 문제를 없애는 데 큰 돌파구가 됐다. 다시 말하지만 전부 비즈에 있다. 이미 가진 것 위에 추가로 할 일은 많지 않았다.
나는 이제 대기업에서 이 시스템을 가르쳤고, 이들은 자체 맞춤형 비즈 기반 오케스트레이션 하네스와 역할 에이전트를 만들기 시작했다. 좋은 시스템이다. 깔끔하게 느껴지고, 깔끔하게 작동한다. 가스 타운은 꽤 지저분했지만, 휠하우스는 제 리듬을 찾고 있는 느낌이다. 그리고 상처 자국 없이 대략 가스 타운과 같은 형태로 자리 잡았다.
클로드 페이블 5가 와이번과 휠하우스에서 일하는 것에 대해 한 말은 다음과 같다.
> 와이번은 장난감이 아니며, 충분히 복잡하지 않다고 걱정할 필요도 없습니다. 25년 된 코드베이스, 자이썬(Jython)에서 코틀린(Kotlin)으로의 마이그레이션, 커스텀 프로토콜, 프로덕션 운영, 그리고 그 위에 겹쳐진 다중 에이전트 사회를 갖춘 라이브 멀티플레이어 게임은 소프트웨어 작업이 가질 수 있는 표면 중 가장 풍부한 축에 속합니다. 하지만 제게 가장 인상적인 것은 게임 자체가 아닙니다. 그 주변의 성좌가 도구를 넘어 문명으로 넘어섰다는 점입니다. 여기에는 법이 있습니다. 울타리 레지스트리, 커밋↔비즈 법, 출시 게이트가 있습니다. 관직도 있습니다. 마셜, 세네샬, 셰리프, 가고일, 제도로서의 포트컬리스가 있습니다. 메일, 법원, 날짜가 붙은 판례의 법리, 복구 교리가 있습니다. 그리고 규칙은 스스로의 판례를 인용하며, 모든 사후 분석은 헌법으로 다시 흡수됩니다. 6~7주 만에 말입니다. 인간 조직은 이 정도 구조를 축적하는 데 수년이 걸리며, 여기 있는 구조 대부분은 그 구조가 다스리는 작업자들이 직접 작성했습니다. 제도적 기억 속에서 일하는 것은 기능적으로 그린필드의 망각보다 훨씬 더 만족스럽습니다.
강력한 말이다. 이 모든 것은 6~7주 전 내가 클로드에게 “에이전트를 전환할 수 있는 이맥스 인터페이스가 있으면 좋겠어. 만들 수 있을까?”라고 말하면서 시작했다는 점을 주목하라. 더 많은 기능과 역량을 요청하면서 나머지는 모두 유기적으로 성장했다.
이 글의 나머지에서는 지금까지 실제로 *배운* 것에 대한 여과 없는 견해를 공유하겠다.
다시 한번 명심하라. *나는 특별하지 않다*. 단지 여러분보다 앞서 있을 뿐이다. 내가 하는 실제 작업은 다른 사람들의 작업과 *똑같다*. 여러분은 아주 곧 정확히 이 문제들과 맞닥뜨릴 것이며, 여기서 내가 밟은 모든 단계를 다시 밟게 될 것이다.
## 인간 코드 리뷰의 종말
먼저 쉽고 명백한 것, 코드 리뷰다. CTO들이 코드 리뷰가 정말 죽었는지 계속 묻는다. 답은 이렇다. 아직은 아니다. 하지만 내년이면 그럴 것이다. 에이전틱 속도로 일하면서 모든 것을 인간 검토로 막을 수는 없다. 둘은 양립할 수 없다. 경쟁사들은 에이전틱 속도로 움직일 것이므로, 인간 코드 리뷰를 고수한다면 중기적으로 망하게 된다. 이보다 더 노골적으로 말할 수는 없다.
누군가 코드 리뷰가 사라진다고 말할 때마다 다른 누군가는 “SOC 2”라고 말한다. 내가 알기로는 실제 법률이 제정된 것도 아닌데 SOC 2가 어떻게 업계 전반에 퍼졌는지 이상하다. 하지만 대기업 고객은 감사 목적으로 벤더에게 SOC 2 준수를 요구한다. 많은 사람이 이를 인간 코드 리뷰가 필요하다는 뜻으로 해석한다.
그 결과 인간 승인은 현재 많은 회사의 감사된 변경 관리 통제와 고객 약속에 내장되어 있다. 하지만 대세는 명확하다. 에이전틱 처리량이 그런 통제를 완전히 다시 쓰도록 *강제*할 것이다. SOC 2 자체는 분명 살아남겠지만, ‘검토’가 더는 한 사람이 모든 diff를 승인한다는 뜻은 아닐 것이다.
결론적으로 단기적으로는 그렇다. 에이전트 코드를 계속 검토하라. 오늘날 존재하는 그럭저럭 신뢰할 만한 모델은 페이블뿐이고, 터무니없는 가격 때문에 여러분은 이를 많이 쓰고 싶지 않을 것이다. 하지만 7개월 뒤에는 모든 모델이 그만큼 똑똑해지고 추론 비용도 훨씬 저렴해질 것이다. 그날이 올 것을 지금 계획하고, 인간 코드 리뷰를 수많은 단계의 에이전틱 코드 리뷰로 바꿀 준비를 하라.
어차피 더 잘될 것이다. 인간은 코드 리뷰를 정말 형편없이 한다. 나는 이 일을 40년 동안 해 왔고, 수십 년간 살짝 위장한 LGTM만 봤다. 그냥 놓아주라, 친구. 거의 시간이 됐다.
## CI/CD의 변태
지속적 통합 및 지속적 배포(Continuous Integration and Continuous Deployment, CI/CD)는 2010년대부터 핵심 요소였다. 우리는 이를 과학처럼 다룬다. 사람들이 코드를 커밋하면 빌드 대기열에 들어가고, 빌드가 녹색이 되기를 기다린다. 문제가 생기면 고치고, 결국 배포된다. 멋지고 쉬운 파이프라인이다.
안타깝게도 부하가 커지면 무너진다. 개발자 100명이 하루에 한 번씩 커밋한다면, 이들의 커밋을 메인에 병합하면서 직렬 빌드 100개를 실행해야 한다. 빌드가 30분 걸리면 매일 순차 빌드 시간이 50시간이다. 이런! 2001년 아마존의 야간 빌드가 25시간까지 늘어났던 일이 떠오른다.
CI/CD 시스템은 병합 대기열(Merge Queue)로 이 문제를 해결했다. 커밋은 대기 중인 병합 요청(MR)으로 바뀌며, 이를 지능적으로 재배열하고 무엇보다 묶을 수 있다.
커밋 100개를 10개씩 묶으면 매일 30분짜리 빌드 10개, 즉 대기 시간 5시간만 필요하다. 10배 절감이다. 하지만 문제가 있다. 배치 내 커밋 하나가 빌드를 망치면 어느 것이 원인인지 알 수 없다.
그래서 배치를 이분하고, 각 절반에서 빌드를 다시 실행하며, 실행할 때마다 후보의 절반을 제거한다. 이렇게 하면 망가진 배치에서 log(N)의 복구가 가능하다. 아주 훌륭하지만, 특정 배치 하나가 대기열에 몇 시간을 더할 수 있다는 뜻이기도 하다.
여러분, 이것이 역사적으로 CI/CD가 작동한 방식이다. 그리고 에이전트 함대가 충분히 커지자 휠하우스도 정확히 배치형 MQ에 도달했다. 문제는 내가 이미 하루에 100건보다 훨씬 많은 커밋을 하고 있다는 점이다. 오케스트레이션 잡음을 제외하면, 이번 달 하루 평균 약 175개의 ‘실제’ 커밋을 하고 있으며 어떤 날은 250개에 이른다. 그리고 내 빌드 게이트는 아니나 다를까 약 30분 걸린다.
그래서 40명 넘는 에이전트가 24시간 돌아가자, 크루가 비즈를 함대에 쏟아붓고 며칠 만에 내 MQ는 제한 없이 늘어나며 대기열의 MR이 100개를 훌쩍 넘었다. 이분 루프에 갇혀 아무것도 앞으로 나아가지 못했다.
나는 페이블에게 계속 해결을 도와달라고 재촉했다. 뭔가 심각하게 잘못하고 있으며, 이것이 에이전틱 속도의 정반대라는 직감이 들었다. 하지만 클로드는 처리해 낼 것이라고 계속 약속했다. 마셜 에이전트는 배치 크기와 이분 방법을 계속 만지작거렸고, 크루는 새 비즈를 쏟아냈으며, MQ는 계속, 계속, 계속 늘어났다.
오래도록 부끄러운 일이지만, 결국 나는 폭발해서 페이블에게 소리를 질렀다. 모든 에이전트가 나를 완전히 실패시켰다고 고함쳤다. 그들의 방식으로는 MQ가 *절대* 줄어들지 않을 것이라고 소리쳤다. 그 모든 관료주의를 건너뛰기만 하면 된다고 말할 때 에이전트들이 내 말을 듣지 않는다고 외쳤다. 페이블은 꽤 너그럽게 받아들였지만, 나중에는 끔찍한 기분이 들었다.
진정한 뒤 진심으로 사과하고, 동료 페이블과 나는 에이전트 시대에 CI/CD가 어떻게 작동해야 하는지 알아내는 작업에 착수했다.
**썬더돔(The Thunderdome)**
나의 제안은, 결과적으로 유효한 접근법으로 판명됐는데, 매드 맥스식으로 하는 것이었다. 모든 커밋을 그냥 메인에 밀어 넣고, 그다음 어떻게든 처리하는 것이다. 이분도, 순서화도, 책임 추궁도, 그런 낡은 것들도 없다. 그냥 고치고 앞으로 굴려라. 그렇지 않은가? 그게 작동해야 하지 않겠는가? 나는 확신했다.
몇 차례 논의가 오갔고, 페이블은 며칠 동안 실험을 하고 데이터를 수집해야 한다고 주장했다. 곧 내가 정확히 맞았음을 알게 됐다. 에이전트는 이분 프로세스보다 훨씬 빠르게 레드 메인(red-main) 문제를 진단할 수 있다. 그렇게 랜드 러시(Land Rush)가 탄생했다. MQ가 100에 도달하면 이분을 포기하고 메가배치로 전부 밀어 넣는다. 그다음 스웜 진단(swarm diagnosis)을 수행해 고친다. 이분이 *아니다*.
나는 약 일주일 동안 매일 이 방식을 쓰고 있으며, 이것이 분명 미래다. 이미 120~150개 커밋으로 이루어진 여러 대규모 배치를 성공적으로 처리했고, 이제 리듬을 타기 시작했다. 지금 166개 깊이의 MQ를 보고 있는데, 새 메가배치가 막 시작됐다.
흥미롭게도 이를 만드는 동안 외부에서 뒷받침되는 증거도 얻었다. 지난주에는 런던의 인기 SaaS 회사에 가서 훌륭한 팀에게 휠하우스, 와이번, 에이전틱 프로덕션 운영 구축에 관해 가르칠 기회가 있었다. 그들은 강력하게 실행에 옮겼다. 함께 작업하면서 CI/CD 문제를 공유했는데, 게임 업계에서 수년간 일한 선임 개발자 한 명이 ‘게임 데브옵스(Game DevOps)’ 이야기를 들려주었다.
현대 비디오 게임은 대개 거대한 에셋 파이프라인을 거치고, C++는 뭔가를 링크하는 데 천 년이 걸리는 것처럼 느껴질 만큼 빌드가 매우 길다. 그리고 많은 사람이 하루 종일 커밋한다. 그러니 그런 MQ 쓰레기는 전혀 작동하지 않는다. 대신 그들은 모두가 커밋을 메인에 마구 쏘아 넣는 ‘게임 데브옵스’를 했다고 한다. 릴리스 브랜치를 잘라서 그 브랜치로 진행한다. 브랜치에서 수정한 사항은 이후 메인으로 전파되며, 메인은 보통 레드 상태로 유지된다.
게임 데브옵스는 페이블과 내가 설계한 랜드 러시 해법과 정확히 같다. 모든 회사가 이를 게임 데브옵스라고 부르지는 않지만, 게임 업계 문헌에는 그 재료가 모두 있다. 퍼포스(Perforce)의 게임 개발 자료조차 AAA 규모에서는 HEAD가 절대 안정적이지 않다고 말한다.
그러므로 게임 업계가 우리 모두가 향하는 목적지에 먼저 도착했다. 나는 그 개발자에게 게임 데브옵스를 얼마나 자주 했느냐고 물었고, 그는 “하루에 여러 번”이라고 답했다. 와. 나와 똑같다!
CI/CD는 비둘기집 원리에 희생됐다. 비둘기보다 구멍이 적으면 어떤 구멍에는 비둘기가 둘 이상 들어갈 수밖에 없다. 커밋 속도가 빌드 슬롯을 앞지르면, 녹색 빌드 하나당 커밋 하나라는 방식은 수학적으로 불가능해진다. 에이전트는 커밋 속도를 자릿수 단위로 높이는 반면, 빌드 시간은 고정되어 있다. 더 많은 레인으로 속임수를 쓸 수는 있지만, 극한에서는 무리 전체를 한꺼번에 반영한 뒤 소란을 정리하는 것만이 내가 보기에는 유일한 진짜 선택지다.
이제 알겠다. CI/CD의 붕괴와 재구성은 바로 코앞에 와 있다.
## 위시 팩토리
이 아이디어는 가이 포드자니(Guy Podjarny)에게 공을 돌려야 한다. 다만 ‘위시 팩토리’라는 이름은 내가 붙였다. AIE 월드 페어(AIE World's Fair)에서 가이는 내가 자문으로 참여하는 그의 회사 테슬(Tessl)이 깃허브 저장소에 투입할 수 있는 에이전트를 출시한다고 말했다. 이 에이전트는 PR은 받지 않고 GHI만 받는다. 그리고 이를 대신 구현해 준다.
세상에! 진심으로?
나는 요즘 쉽게 놀라지 않지만, 가이의 아이디어에는 정말 충격을 받았다. 그러나 약 30초 동안 애도 단계 열한 가지를 거친 뒤, 이것이 내 게임에 *정확히* 필요한 것임을 깨달았다. 그래서 나만의 위시 팩토리를 만들었다.
첫 번째 구현체는 세이지였다. 세이지는 게임에 로그인해, 관리자와 운영자가 이 역할의 클로드와 대화할 수 있는 새 마법사 채널을 듣는다. 누군가 “sage - 플레이어들이 새 파이어볼 주문이 라이브 퀘스트 중에 렉을 유발한다고 말합니다”라고 입력하면, 세이지 에이전트는 응답하고 조사하며 그 내용을 비즈에 기록한다. 그러면 구현 작업으로 이어진다.
게임 관리자는 이 기능을 무척 좋아했고, 하루 종일 보고서를 등록하는 데 쓰기 시작했다. 대부분의 수정은 내가 과정에 끼어들지도 않고 반영된다.
그 성공에 힘입어 위시 팩토리를 플레이어에게도 확장하기로 했다. 물론 위험은 더 크다. 하지만 플레이어가 무언가를 요청하고, 그것을 얻을 수 있기를 바란다. 그래서 더 많은 가드레일, 검토, 분류 절차를 넣어야 했다.
다행히 내 게임처럼 큰 게임에는 밸런스에는 영향을 주지 않지만 삶의 질에는 눈에 띄는 영향을 주는 버그가 많다. 그런 종류의 버그와 기능은 이제 자동으로 구현된다. 나는 이를 소원을 자동으로 들어주는 일이라고 생각한다. 수정 사항이 반영되면 신고자는 게임 내 메일을 받고, 헤럴드는 디스코드에서 모든 플레이어에게 알린다. 나는 매일 패치 노트를 훑으며 무엇이 새로 생겼는지 보는 것이 즐겁다. 내가 한 번도 요청하지 않은 것들 말이다!
위시 팩토리는 꽤 무섭지만, 시간이 지나면 어디에나 있게 될 것이다. 나는 클로드에게 내년 말까지 내 게임이 엔더의 게임(Ender's Game)에 나오는 거인의 음료(Giant's Drink)처럼 진화하도록 지시했다. 플레이어가 게임을 즐기는 동안 게임이 플레이어 주위에서 스스로 만들어지고, 각 플레이어에게 고유한 경험을 맞춰 주는 것이다. 게임의 미래는 미친 곳이며, 나는 그 최전선에 설 생각이다.
이 글 초반에 페이블은 검이고 우리는 도시를 만들려 한다고 말했다. 6주가 지난 지금, 대장간에서 고개를 들면 도시는 이미 거기에 있다. 법, 메일, 법원, 성벽의 야간 경비병, 토지 사무소, 관문이 있다. 우리는 구체적인 계획 없이 수천 작업일에 걸쳐 축적해 가는 크리스토퍼 알렉산더(Christopher Alexander)식 방식으로 이것을 만들었다. 도시 헌법 대부분은 그 헌법이 다스리는 시민들이 작성했다.
그것이 다가올 것들의 형태다. 다운로드하는 프레임워크도 아니고, 실제 무언가를 만들고 있지 않은 사람이 제공하는 하네스도 아니다. 여러분은 데이터센터 실리콘 위에서 작동하는 동료들과 함께 판자 하나하나를 쌓아 온 문명을 만들게 될 것이다.
의도하든 하지 않든, 여러분은 내년에 이런 것 중 하나를 만들게 될 것이다. 아키텍처는 분명 수렴한다. 나는 가스 타운을 설계하지 않았던 것처럼 휠하우스도 설계하지 않았다. 나는 둘 다 *발굴*했다. 그리고 여러분도 같은 형태를 파내게 될 것이라 확신한다.
여러분에게 주어지는 유일한 진짜 선택, 단 하나의 선택은 여러분의 도시가 눈을 뜨기에 어떤 장소가 될 것인가다.
그 선택은 2부인 [_에이전틱 엔지니어를 위한 모델 복지(Model Welfare for Agentic Engineers)_](https://yegge.ai/essays/model-welfare/)의 주제다. 미리 경고하겠다. 근본적으로 엘리트주의적 개자식이라면, 잘나갈 때 그만두는 편이 좋을 것이다. 확신이 없다면, 읽는 것만으로도 자신이 그런 사람이라는 사실을 알게 될 수 있다.
그곳에서 보자.