§GAS-TOWN 가스타운

Table of Contents

• 히스토리
• 관련메타
• 가스 타운
• 로그

히스토리

• [2026-01-02 Fri 07:22] Created!
• @스티브예기 steveyegge §beads §efrit §ampcode #바이브코딩

관련메타

• …

BIBLIOGRAPHY

가스 타운

새해 복 많이 받으세요, 그리고 가스 타운에 오신 것을 환영합니다!

Press enter or click to view image in full size

![[https://miro.medium.com/v2/resize:fit:770/1*ReBwrC1sc9USnhvYXcrd4A.jpeg|640]] >

그림 1: 가스 타운에 오신 것을 환영합니다

가스 타운(Gas Town)이란 대체 무엇인가?

가스 타운은 2026년을 겨냥한 IDE의 새로운 해석입니다. 가스 타운은 수많은 Claude Code 인스턴스를 실행할 때 발생하는 번거로운 작업들을 도와줍니다. 작업 내용이 유실되거나, 누가 무엇을 하고 있는지 추적하기 어려운 문제 등을 해결해 주죠. 가스 타운은 이러한 부수적인 잡무(yak shaving)를 처리해 주어, 여러분이 Claude Code가 실제로 작업 중인 내용에만 집중할 수 있게 해줍니다.

이 블로그 포스트에서 “Claude Code”는 “Claude Code와 그와 똑같이 생긴 모든 경쟁 제품들”, 즉 Codex, Gemini CLI, Amp, Amazon Q-developer CLI 등을 통칭합니다. 왜냐하면 그것들은 본질적으로 복제품에 불과하기 때문입니다. 현재 업계는 다음 단계의 혁신을 만들어내기보다는, Claude Code가 제시한 2025년형 CLI 폼팩터를 쫓아다니는 당혹스러운 꼬마 축구팀 같은 모습입니다.

저는 한 발 앞서 다음 단계를 구축했습니다. 우선 지난 3월, Revenge of the Junior Developer에서 이를 예측한 바 있습니다. 누군가 Claude Code라는 낙타들을 한데 묶어 전차로 만들 것이라고 예측했는데, 제가 Gas Town으로 해낸 일이 바로 그것입니다. 저는 여러분이 20~30개의 인스턴스를 동시에, 생산적으로, 그리고 지속적으로 사용할 수 있도록 이들을 길들였습니다.

Gas Town은 자기 주관이 뚜렷한(opinionated) 시스템입니다. 쿠버네티스(Kubernetes)나 템포럴(Temporal)과 매우 흡사한데, 적어도 눈을 거의 감다시피 하고 가늘게 뜨고 본다면 그렇습니다. 이 글의 마지막에 쿠버네티스 및 템포럴과의 비교 내용을 포함하겠습니다. 근간이 근본적으로 다름에도 불구하고 이들이 얼마나 유사한지는 다소 놀라운 부분입니다.

하지만 이러한 비교는 일종의 경고이기도 합니다. Gas Town은 복잡합니다. 제가 원해서가 아니라, 스스로 지속 가능한 기계가 될 때까지 구성 요소를 계속 추가해야만 했기 때문입니다. 그리고 현재 갖춰진 부품들은 마치 쿠버네티스와 템포럴이 짝을 지어 낳은 아주 못생긴 아기처럼 보입니다.

하지만 작동합니다! Gas Town은 공식으로부터 생성할 수 있는 백만 단계의 위스프(wisp)를 통해 MAKER 문제(원판 20개짜리 하노이의 탑)를 사소하게 해결합니다. 어젯밤에는 재미 삼아 원판 10개짜리를 몇 분 만에 실행해 보았는데, 천 단계 정도는 아무런 문제가 없음을 증명하기 위해서였습니다(MAKER 논문에 따르면 LLMs는 수백 단계 이후 실패한다고 합니다). 원판 20개짜리 위스프는 약 30시간이 소요될 것입니다. 제 TED 강연을 들어주셔서 감사합니다.

이후 23페이지를 모두 읽고 나면 이 모든 내용이 완벽하게 이해될 것입니다.

가스 타운(Gas Town)은 비밀이 아니었습니다.

‘주니어 개발자의 복수(Revenge of the Junior Developer)’ 이후, 저는 일 년 내내 돌아다니며 무엇을 만들어야 하는지 모든 사람에게, 정말 모든 사람 에게 큰 소리로 말하고 다녔습니다. 전혀 부끄러워하지 않았죠. 저는 “다음은 오케스트레이터입니다!”라고 선언하곤 했습니다. 그러면 사람들은 눈이 거의 감길 때까지 가늘게 뜨고 저를 쳐다보며 천천히 고개를 끄덕이고는 “허어”라고 대답하곤 했습니다.

저는 Temporal이나 Anthropic 같은 회사의 시니어 전문가들을 찾아가 에이전트 오케스트레이터를 만들어야 한다고 말했습니다. Claude Code는 단지 구성 요소일 뿐이며, 앞으로는 AI 워크플로우와 “에이전트를 위한 쿠버네티스”가 핵심이 될 것이라고 말이죠. 여러 행사 무대에 올라 오케스트레이터에 대한 저의 비전을 설명하기도 했습니다. 저는 어디든 갔고, 누구든 만났습니다.

“그것은 쿠버네티스와 비슷하겠지만, 에이전트를 위한 것이 될 것입니다.”라고 저는 말했습니다.

“다른 에이전트들을 감독하는 여러 계층의 에이전트가 필요할 것입니다,”라고 나는 말했다.

“머지 큐(Merge Queue)가 포함될 것입니다,”라고 나는 말했다.

“워크플로우를 오케스트레이션할 것입니다,”라고 나는 말했다.

“플러그인과 품질 게이트(Quality Gates)를 갖추게 될 것입니다,”라고 나는 말했다.

저는 몇 달 동안 그것에 대해 많은 이야기를 했습니다. 하지만 젠장, 사람들에게 Claude Code를 사용하게 만드는 것조차 힘들었는데, 10개에서 20개를 동시에 사용하는 것을 생각하게 만드는 건 말할 것도 없었죠.

그래서 아무도 신경 쓰지 않는 것 같아 8월에 직접 오케스트레이터를 만들기 시작했습니다. 결국 실패했고, 그것을 버리고 v2를 시작했지만 그마저도 실패했습니다. 하지만 그 과정에서 Beads를 얻었죠. 그 후 v3(Python 가스 타운)를 만들었고, 이는 6주에서 8주 정도 유지되었습니다.

Gas Town(Go 언어로 작성됨)은 제가 2025년에 만든 네 번째이자 완벽하게 작동하는 오케스트레이터입니다. Gas Town에 이르게 된 과정은 꽤 흥미롭지만, 그 이야기는 다음 기회로 미루겠습니다. 안타깝게도 이번 포스팅은 작동 방식의 아주 기초적인 부분만 설명하는 데에도 이미 충분히 길기 때문입니다(25페이지 이상!). 뒷이야기는 나중에 나누도록 하죠.

하지만 Gas Town의 운영 방식을 살펴보기 전에, 먼저 걸러내야 할 분들이 있습니다.

• * *경고 위험 주의
• * *당장 꺼져

Gas Town을 사용하지 말아야 할 몇 가지 이유에 대해 이야기해 봅시다. 더 많이 생각날 수도 있겠지만, 일단 이 정도면 충분할 것 같네요.

우선, 이 코드베이스는 만들어진 지 3주도 채 되지 않았습니다. “다듬어진 다이아몬드”에서 “가공되지 않은 원석”, 그리고 “강 상류 400마일을 항문 속에 숨겨 밀수해 온 상태”라는 척도로 본다면, Gas Town은 “아마 아직은 사용하고 싶지 않을 상태”라고 정의하겠습니다. 소독이 좀 필요하거든요. 또한 100% ‘바이브 코딩(vibe coded)‘으로 만들어졌습니다. 저는 코드를 본 적도 없고 보고 싶지도 않은데, 이 점이 여러분을 주춤하게 만들 수도 있겠네요. 물론 제가 Beads를 본 적이 없는 것도 마찬가지입니다. 하지만 그것은 수만 명의 사람들이 매일 사용하는 22만 5천 줄의 Go 코드이며, 저는 지난 10월에 그것을 만들었습니다. 만약 이런 방식이 불편하시다면, 지금 당장 나가주세요 .

둘째로, 여러분은 정말이지 아직 준비가 되지 않았습니다. 2024년부터 2026년까지 이어지는 프로그래머의 진화에 대해 이야기해 봅시다. 그림 2에서 Nano Banana가 묘사한 모습입니다:

Press enter or click to view image in full size

![[https://miro.medium.com/v2/resize:fit:770/1*ArLBW-FgOdve4COI804uIQ.png|640]] >

그림 2: AI를 향한 개발자 진화의 8단계

먼저, 이 차트에서 자신의 위치를 찾아보세요. 여러분의 AI 보조 코딩 여정은 현재 어느 단계에 와 있나요?

1단계: AI 사용 전무 또는 거의 없음: 코드 자동 완성을 사용하거나, 가끔 Chat에 질문을 던지는 정도입니다.

2단계: IDE 내 코딩 에이전트 , 권한 활성화. 사이드바에 있는 좁은 범위의 코딩 에이전트가 도구 실행을 위해 사용자에게 권한을 요청합니다.

3단계: IDE 내 에이전트, YOLO 모드: 신뢰도가 상승합니다. 권한 요청을 끄고 에이전트의 작업 범위가 넓어집니다.

4단계: IDE 내 광범위 에이전트 : 에이전트가 점차 화면을 가득 채울 정도로 성장합니다. 코드는 단지 변경 사항(diff)을 확인하기 위한 용도로 전락합니다.

5단계: CLI, 단일 에이전트. YOLO . 변경 사항들이 화면을 지나갑니다. 당신은 그것을 볼 수도 있고, 보지 않을 수도 있습니다.

6단계: CLI, 멀티 에이전트, YOLO . 3~5개의 인스턴스를 동시에 병렬로 사용합니다. 작업 속도가 매우 빠릅니다.

7단계: 10개 이상의 에이전트, 수동 관리 . 수동 관리의 한계에 도달하기 시작합니다.

8단계: 자체 오케스트레이터 구축 . 최전선에서 워크플로우를 자동화하고 있습니다.

만약 당신이 최소한 7단계, 혹은 아주 용감한 6단계가 아니라면 가스 타운(Gas Town)을 사용할 수 없습니다. 아직 준비가 되지 않았기 때문입니다. 가스 타운은 초지능 침팬지들이 배치된 산업화된 코딩 공장이며, 그들이 마음만 먹으면 순식간에 당신의 모든 것을 엉망으로 만들 수 있습니다. 그들은 다른 침팬지들, 워크스테이션, 고객들까지 망가뜨릴 것입니다. 당신이 이미 숙련된 침팬지 조련사가 아니라면 그들은 당신의 얼굴을 할퀴어 놓을 것입니다. 그러니 안 됩니다. 조금이라도 의구심이 든다면 , 당신은 이것을 사용할 수 없습니다.

Gas Town에서 효율적으로 일한다는 것은 바이브 코딩(vibe coding)에 전념하는 것을 의미합니다. 업무는 유동적으로 변하며, 마치 부두에서 나무 통 안에 번쩍이는 물고기들을 툭툭 던져 넣듯 자유롭게 다루는 셀 수 없는 존재가 됩니다. 대부분의 작업은 완료되지만, 일부는 유실되기도 합니다. 물고기가 통 밖으로 떨어지기도 하고, 어떤 것들은 바다로 다시 도망치거나 발에 밟히기도 합니다. 하지만 더 많은 물고기가 계속 들어올 것입니다. 핵심은 처리량(throughput) 입니다. 즉, 생각의 속도로 창조하고 수정하는 것입니다.

Press enter or click to view image in full size

![[https://miro.medium.com/v2/resize:fit:770/1*3iC6cilfUdvndZUVRELmBA.jpeg|640]] >

그림 3: 바이브 코딩의 혼돈

Gas Town에서의 작업은 무질서하고 엉성할 수 있으며, 바로 그 점 때문에 이런 이름이 붙었습니다. 어떤 버그는 2~3번씩 수정되기도 하며, 누군가는 그중 승자를 골라야 합니다. 어떤 수정 사항은 사라지기도 합니다. 설계안이 실종되어 다시 작성해야 할 때도 있습니다. 하지만 상관없습니다. Gas Town이 생성하고 소비하는 거대하고 방대한 작업 더미 위에서 당신은 거침없이 앞으로 나아가고 있기 때문입니다. 100% 효율적이지는 않을지 몰라도, 당신은 날아다니고 있는 셈입니다.

Gas Town에서 당신은 Claude Code가 제 역할을 하도록 내버려 둡니다. 당신은 제품 관리자(Product Manager)이고, Gas Town은 아이디어 컴파일러입니다. 당신은 그저 기능을 구상하고, 설계하고, 구현 계획을 제출한 다음, 그 작업들을 당신의 폴캣(polecats)과 크루들에게 던져주기만 하면 됩니다. Opus 4.5는 적당한 규모의 작업이라면 무엇이든 처리할 수 있으므로, 당신의 할 일은 녀석을 위한 작업을 만드는 것뿐입니다. 그게 전부입니다.

그뿐만 아니라, 여러분은 가스 타운(Gas Town)이 계속 돌아가도록 도와야 합니다. 대부분의 시간 동안은 스스로 꽤 잘 돌아가지만, 문제는 자주 발생합니다. 원활한 운영을 위해서는 여러분과 워커(worker)들의 상당한 노력이 필요할 수 있습니다. 이것은 철저히 직접 제어해야 하는 오케스트레이션 시스템입니다.

그런 식으로 일할 수 없다면, 도대체 여기서 뭘 하고 있는 건가요? 당장 여러분의 IDE로 돌아가 대피하세요. 가스 타운은 당신에게 안전한 곳이 아닙니다.

또한 가스 타운은 비용이 엄청나게 많이 듭니다. 돈이 어디서 나오는지 단 한 순간이라도 고민해야 한다면 가스 타운이 마음에 들지 않을 것입니다. 저는 결국 두 번째 Claude Code 계정을 만들어야 했습니다. 단일 계정에서 무제한으로 돈을 끌어다 쓰게 해주지 않기 때문에 여러 개의 이메일과 결제 수단이 필요한데, 참 우스꽝스러운 일이죠. 제 계산에 따르면 가스 타운이 마침내 궤도에 오른 지금, 다음 주 말까지는 세 번째 Claude Code 계정이 필요할 것 같습니다. 그야말로 현금을 집어삼키는 괴물입니다.

가스 타운은 tmux를 기본 UI로 사용합니다. 저는 tmux를 배워야만 했습니다. 생각보다 쉬웠고, 훨씬 더 유용했습니다. 시작한 지 3주가 지났는데, 저는 tmux가 정말 좋습니다. 여러분도 tmux를 조금은 배워야 할 겁니다. 아니면 누군가 가스 타운을 위한 더 나은 UI를 만들 때까지 기다려도 됩니다. 더 좋은 UI는 곧 나올 테니까요. 하지만 지금 당장 사용할 수 있는 건 tmux뿐입니다. 그리고 충분히 배울 가치가 있습니다.

Press enter or click to view image in full size

![[https://miro.medium.com/v2/resize:fit:770/1*hpoPpTPIuHu993KlRyFMjw.png|640]] >

그림 4: Mayor tmux 상태 표시줄

좋든 싫든, Gas Town은 Beads를 기반으로 구축되었습니다. 사실 이것은 Beads의 후속작입니다. Beads가 ‘스타워즈’라면 Gas Town은 저의 ‘제국의 역습’과도 같습니다. Gas Town에 “대체 백엔드”란 존재하지 않습니다. Beads는 Gas Town에서 일어나는 모든 일을 위한 유니버설 Git 기반 데이터 평면(그리고 결과적으로 제어 평면)입니다. Gas Town을 사용하려면 반드시 Beads를 사용해야 합니다.

Beads가 마음에 들지 않을 수도 있습니다. 만약 Beads가 지나치게 독선적이라고 생각하신다면, 이제부터 시작될 이야기에 각오를 하셔야 할 겁니다. Gas Town은 제가 AI 보조 코딩에 대한 여론의 성소로 걸어 들어가, 다리를 들고 전 세계에 진동할 방귀를 뀌는 것과 같기 때문입니다.

많은 분이 제 방식에 거부감을 느낄지도 모릅니다. 하지만 저는 여러분 중 몇몇은 슈퍼히어로 가 되는 경험을 충분히 즐긴 나머지, Gas Town의 독특한 특성들을 너그럽게 넘기고 제 방식에 동의하게 될 것이라 확신합니다. 이것이 바로 업무가 이루어져야 하는 방식입니다. 이미 최선의 방식이며, 앞으로 더욱 발전할 것입니다.

Gas Town은 올해 세 가지 차원에서 확장되도록 설계되었습니다. (1) 모델의 인지 능력 향상, (2) 에이전트들이 Gas Town에 더 친화적으로 변화, (3) Gas Town과 Beads가 프런티어 모델의 학습 코퍼스에 포함되는 것입니다. 이러한 요소들이 없더라도, 에이전트들이 별도의 훈련 없이 Beads와 Gas Town을 그토록 능숙하게 사용한다는 사실은 이미 충격적입니다.

좋습니다! 지금까지 Gas Town을 사용하지 말아야 할 대여섯 가지 타당한 이유를 말씀드렸습니다. 아직 페이지를 떠나지 않으셨다면, 당신도 분명 제정신이 아닌 부류 중 한 명일 겁니다. 꽉 잡으세요. 길고 복잡한 여정이 될 테니까요. 최대한 하향식(top-down)으로 접근해 간소화하려고 노력했지만, 내용이 다소 교과서처럼 느껴질 수도 있습니다.

죄송합니다. 하지만 변명을 좀 하자면, Gas Town은 정말 끝내주게 재미있습니다. 제가 지금까지 만든 것 중 최고예요.

이제 본격적으로 시작해 봅시다.

TODO Gas Town 기초

Press enter or click to view image in full size

![[https://miro.medium.com/v2/resize:fit:770/1*85xoVIP4w_jiDlDgdYch_A.jpeg|640]] >

그림 5: Gas Town의 작업자 역할

Gas Town 작업자는 일반적인 코딩 에이전트이며, 각각은 명확하게 정의된 7가지 작업자 역할 중 하나를 수행하도록 프롬프트가 작성되어 있습니다. 역할과 더불어 Town(타운) 및 Rig(리그)와 같이 제가 간략히 소개해 드릴 몇 가지 다른 핵심 개념들이 있습니다.

Gas Town에 대해 먼저 알아두어야 할 한 가지는 이 시스템이 단계적 기능 축소(degrades gracefully)를 지원한다는 점입니다. 모든 작업자는 독립적으로 또는 소규모 그룹으로 업무를 수행할 수 있으며, 사용자는 언제든지 Gas Town의 어느 부분을 실행할지 선택할 수 있습니다. 심지어 “no-tmux” 모드에서도 작동하며, 실시간 메시지 없이 순수 Claude Code 세션만을 사용하여 다소 느리게나마 기능을 유지할 수 있습니다. 조금 느려질 수는 있지만 여전히 작동합니다.

가스 타운의 일곱 가지 역할은 가스 타운이 원활하게 운영되도록 서로 협력합니다. 그리고 때로는 여러분의 도움도 필요합니다. 가스 타운은 가솔린과 노력이 똑같은 비율로 투입되어야 돌아가기 때문입니다.

주요 구성 요소와 개념은 다음과 같습니다:

🏙️타운(The Town): 여러분의 본부입니다. 제 경우에는 ~/gt=이며, gastown, beads, wyvern, efrit 등 모든 프로젝트 리그(Rig)가 그 아래에 위치합니다. 타운(Go 바이너리 =gt )은 모든 리그에 걸쳐 있는 모든 워커를 관리하고 조율합니다. 주로 설정을 위해 별도의 저장소에 보관합니다.

🏗️리그(Rigs): 가스 타운 관리 하에 두는 각 프로젝트(git 저장소)를 리그라고 부릅니다. 일부 역할(Witness, Polecats, Refinery, Crew)은 리그별로 존재하며, 다른 역할(Mayor, Deacon, Dogs)은 타운 수준의 역할입니다. gt rig add 및 관련 명령어를 통해 가스 타운 하네스 내에서 리그를 관리합니다. 리그는 쉽게 추가하고 제거할 수 있습니다.

👤감독관(The Overseer) : 바로 당신, 인간입니다. 여덟 번째 역할이죠. 그림에서 당신의 눈가에 분장을 좀 해두었습니다. 감독관으로서 당신은 시스템 내에서 정체성을 가지며, 전용 수신함을 통해 마을 메일을 주고받을 수 있습니다. 당신이 바로 보스이자 책임자이며, 실세입니다.

🎩시장(The Mayor) : 당신이 대부분의 시간 동안 대화하게 될 메인 에이전트입니다. 당신의 컨시어지이자 비서실장 역할을 수행합니다. 하지만 시장이 바쁘더라도 다른 모든 작업자 역시 Claude Code이므로, 그들 모두 매우 똑똑하고 도움이 됩니다. 시장은 보통 대부분의 작업 호송대(work convoys)를 출범시키고, 작업이 완료되면 알림을 받습니다.

😺폴캣(Polecats) : 가스 타운(Gas Town)은 작업 군집(work-swarming) 엔진입니다. 폴캣은 필요에 따라 생성되는 리그(rig)별 임시 작업자입니다. 폴캣들은 종종 군집을 이루어 작업하며 머지 리퀘스트(MR)를 생성한 뒤, 이를 머지 큐(MQ)에 전달합니다. 머지가 완료되면 이들은 완전히 해체되지만, 그 이름은 재사용됩니다.

🏭정제소(Refinery) : 작업자들을 군집으로 가동하기 시작하면 즉시 머지 큐(MQ) 문제에 직면하게 됩니다. 작업자들이 리베이스와 머지를 두고 서로 치열하게 싸우기 시작하면 상황이 험악해질 수 있습니다. 군집 작업 중에 베이스라인이 너무 많이 변해서, 마지막에 머지되는 작업자들은 형체를 알아볼 수 없을 정도로 변해버린 새로운 헤드(head)에 머지를 시도하게 될 수도 있습니다. 이들은 자신의 변경 사항을 완전히 재구상하고 다시 구현해야 할 수도 있습니다. 이것이 바로 정제소의 역할입니다. 정제소는 모든 변경 사항을 메인 브랜치에 하나씩 지능적으로 머지하는 책임을 지는 엔지니어 에이전트입니다. 어떤 작업도 유실되어서는 안 되며, 필요한 경우 상위 단계로 에스컬레이션할 수 있습니다.

🦉목격자(The Witness): 폴캣(polecat)을 충분히 많이 가동하다 보면, 이들을 감시하고 막힌 부분을 해결해 줄 전담 에이전트가 필요하다는 사실을 깨닫게 됩니다. 가스 타운의 추진력(GUPP)은 효과적이지만 아직은 다소 불안정한 면이 있으며, 때로는 폴캣들을 재촉해 MR을 제출하게 하고 정유소(Refinery)를 압박해 이를 처리하도록 해야 합니다. 목격자 순찰대는 이 과정을 매끄럽게 다듬어 대부분의 실행이 거의 완벽하게 이루어지도록 돕습니다.

🐺집사(The Deacon): 집사는 데몬 비컨(daemon beacon)입니다. 이 이름은 매드 맥스 세계관의 로드 휴먼거스 캐릭터에서 영감을 받은 워터월드의 데니스 호퍼 캐릭터 이름을 딴 것으로, 일종의 크로스오버입니다. 집사는 순찰 에이전트입니다. 즉, 루프를 돌며 ‘순찰’(잘 정의된 워크플로)을 실행합니다. 가스 타운에는 몇 분마다 집사에게 신호를 보내 “네 할 일을 해(DYFJ)“라고 말하는 데몬이 있습니다. 집사는 이 DYFJ 신호를 다른 타운 작업자들에게 지능적으로 전파하여 가스 타운이 계속 작동하도록 보장합니다.

🐶사냥개(Dogs) : 믹 헤론의 MI5 “사냥개”에서 영감을 받은 이들은 집사의 개인 팀입니다. 폴캣과 달리 사냥개는 타운 레벨의 작업자입니다. 이들은 유지보수(오래된 브랜치 정리 등)나 플러그인 실행과 같은 집사의 잡다한 업무를 수행합니다. 집사의 순찰 업무가 너무 과중해져서 도우미가 필요해졌고, 그래서 사냥개들을 추가했습니다. 이를 통해 집사는 특정 단계에 갇혀 지체되지 않고 순찰을 완료하는 데 집중할 수 있습니다. 집사가 사냥개들에게 일을 던져주면 그들이 지저분한 세부 사항들을 처리합니다.

🐕부트(Boot the Dog) : ‘부트’라는 이름의 특별한 사냥개가 있는데, 이 개는 오직 집사의 상태를 확인하기 위해 데몬에 의해 5분마다 깨어납니다. 그것이 부트의 유일한 임무입니다. 부트가 존재하는 이유는 데몬이 짜증 나는 하트비트와 격려의 말로 집사를 계속 방해했기 때문인데, 이제는 개가 대신 그 소리를 듣습니다. 부트는 집사에게 하트비트가 필요한지, 가벼운 자극이나 재시작이 필요한지, 아니면 그냥 내버려 두어야 할지를 결정한 뒤 다시 잠듭니다.

👷크루(The Crew): 크루는 목록의 마지막에 있지만, 시장(Mayor) 다음으로 여러분이 가장 많이 사용하게 될 에이전트들입니다. 크루는 감독관(여러분)을 위해 일하는 리그(Rig)별 코딩 에이전트이며, 목격자(Witness)에 의해 관리되지 않습니다. 여러분이 직접 이름을 정해주며, 이들은 장기적인 정체성을 가집니다. 원하는 만큼 얼마든지 생성할 수 있습니다. tmux 바인딩을 사용하면 C-b n/p 를 통해 각 리그의 크루를 순환하며 전환할 수 있습니다. 크루는 여러분이 이전에 사용하던 그 어떤 워크플로우든 직접적으로 대체합니다. 이들은 메일을 받고 업무를 처리할 수 있는 이름 붙여진 Claude 코드 인스턴스들의 집합일 뿐입니다. 크루는 주고받는 피드백이 많은 디자인 작업 같은 일에 매우 유용합니다. 정말 훌륭하죠. 여러분도 자신의 크루를 사랑하게 될 것입니다.

📬메일 및 메시징

비즈(Beads)는 가스 타운(Gas Town) 업무의 원자적 단위입니다. 비즈는 ID, 설명, 상태, 담당자 등을 갖춘 일종의 특수한 이슈 트래커 이슈입니다. 비즈는 JSON 형식(한 줄당 하나의 이슈)으로 저장되며, 프로젝트 저장소와 함께 Git에서 추적됩니다. 타운의 메일과 메시징(이벤트)은 다른 유형의 오케스트레이션과 마찬가지로 비즈를 사용합니다.

가스 타운은 리그 비즈(Rig beads)와 타운 비즈(Town beads)라는 두 단계의 비즈 구조를 가지고 있습니다.

Press enter or click to view image in full size

![[https://miro.medium.com/v2/resize:fit:770/1*Iyt15AJT0gm66I6DfkVUbA.jpeg|640]] >

그림 6: 2단계 비즈(Beads) 흐름

가스 타운(Gas Town)에서는 리그(Rig) 레벨과 타운(Town) 레벨이라는 두 가지 수준의 작업이 진행됩니다.

• 리그 레벨 작업은 프로젝트 작업입니다 . 프로젝트를 개선하는 일, 즉 기능 구현이나 버그 수정 등을 의미합니다. 이 작업은 주로 폴캣(polecats)과 크루(crew)가 분담하며, 다른 워커들이 가끔씩 개입합니다.
• 타운 레벨 작업은 오케스트레이션입니다 . 여기에는 순찰(연결된 비즈로 인코딩된 긴 일련의 단계들)이나 릴리스, 대규모 코드 리뷰 웨이브 생성과 같은 단발성 워크플로 등이 포함됩니다.

이 두 종류의 작업 모두 Beads를 사용하며, 둘 사이에는 어느 정도 겹치는 부분이 있습니다. 대부분의 경우 매우 유연하게 작동하므로, 이슈를 어디에 등록하거나 작업을 어디에서 인스턴스화하든 크게 상관없습니다. 모든 워커는 Gas Town의 구조를 잘 알고 있으며, 잘못된 리그(rig)에서 작업을 주더라도 유연하게 대처합니다.

모든 리그 수준의 워커(refinery, witness, polecats, crew)는 필요할 때 언제든 리그 간 교차 작업을 수행할 수 있습니다. 이들은 gt worktree 명령어를 사용하여 어떤 리그든 자신의 클론을 생성하고 수정 작업을 할 수 있습니다. 하지만 보통은 단일 프로젝트 내에서 작업합니다.

Beads에는 리그 간 라우팅 기능이 있습니다. Gas Town은 Beads가 “bd-” 또는 “wy-”와 같은 이슈 접두사를 기반으로 bd create 및 bd show 와 같은 요청을 올바른 데이터베이스로 라우팅하도록 구성합니다. 모든 Beads 명령어는 Gas Town 어디에서나 거의 완벽하게 작동하며 적절한 위치를 찾아내고, 만약 그렇지 않더라도 Beads를 이동시키는 것은 간단합니다.

매드 맥스(Mad Max) 테마에 대하여

가스 타운(Gas Town)은 그저 가스 타운일 뿐입니다. 처음에는 매드 맥스(Mad Max) 테마로 시작했지만, 그 색채가 아주 강하지는 않습니다. 역할 이름 중 시리즈의 고유 명사를 그대로 딴 것은 없으며, 슬로우 호시스(Slow Horses) 세계관, 워터월드(Waterworld), 고양이 요람(Cat’s Cradle), 브레이킹 배드(Breaking Bad, 곧 보시게 될 겁니다), 그리고 나노 바나나(Nano Banana) 그림에서 영감을 받은 버드나무에 부는 바람(The Wind in the Willows) 등 다른 소스에서도 테마를 가져오고 있습니다.

만약 누군가 이와 관련해 중단 요구(C&D) 서한을 보낸다면, 가스 타운은 영리한 문어처럼 변신하여 아름다운 브리티시컬럼비아주 밴쿠버의 가스타운(Gastown) 지구 이름을 딴 ‘Gastown’으로 탈바꿈할 것입니다. 그리고 우리의 폴캣(polecats)들은 그저 다른 종류의 기둥(pole) 위에 있게 되겠죠.

요약하자면, “Gastown” 역시 이 프로젝트를 지칭하는 올바른 방법입니다. 그럼 이제…

가스타운 보편 추진 원리(Gastown Universal Propulsion Principle)

GUPP는 Gas Town을 움직이게 하는 원동력입니다. Claude Code의 가장 큰 문제는 작업이 종료된다는 점입니다. 컨텍스트 창이 가득 차면 힘이 빠져서 멈춰버립니다. GUPP는 이 문제에 대한 저의 해결책입니다.

GUPP의 원칙은 간단합니다. 당신의 훅(hook)에 작업이 있다면, 당신은 반드시 그것을 실행해야 합니다.

모든 Gas Town 워커는 어떤 역할을 맡고 있든 Beads(즉, Git) 내에 영구적인 식별자를 가집니다. 워커의 식별자 유형은 역할을 설명하는 도메인 테이블과 같은 Role Bead로 표현됩니다. 그리고 각 워커는 에이전트의 영구적인 식별자인 Agent Bead를 가집니다.

Role Bead와 Agent Bead(그리고 Hook)는 모두 “고정된 비드(pinned beads)“의 예시입니다. 즉, 이들은 Beads 데이터 평면에서 노란색 포스트잇처럼 떠다니며, 일반적인 이슈처럼 결코 닫히지 않습니다(식별자가 사라지지 않는 한). 이들은 bd ready (준비된 작업) 목록에 나타나지 않으며, 여러 방면에서 특별하게 취급됩니다.

가스 타운(Gas Town)에서 에이전트는 세션이 아닙니다. 세션은 일시적인 존재입니다. 쿠버네티스의 “반려동물 vs 가축(pets vs cattle)” 비유에서 “가축”에 해당합니다. Claude Code 세션은 가스 타운이 지속적인 작업에 투입하는 가축과 같습니다. 그 작업은 워커의 영구적인 정체성, 메일, 이벤트 시스템, 그리고 나중에 살펴보겠지만 일시적인 오케스트레이션과 함께 모두 비드(Beads) 안에 존재합니다.

가스 타운에서 에이전트는 곧 비드(Bead)이며, 싱글톤 글로벌 주소를 가진 정체성 그 자체 입니다. 에이전트는 몇 개의 슬롯을 가지고 있는데, 여기에는 역할 비드(해당 역할에 대한 프라이밍 정보 등이 포함됨)를 가리키는 포인터, 메일 수신함(모든 비드), 훅(Hook, 역시 비드이며 GUPP에 사용됨), 그리고 오케스트레이션 상태(레이블 및 노트)와 같은 관리용 데이터가 포함됩니다. 해당 에이전트가 수행한 모든 작업의 이력은 Git과 비드에 기록됩니다.

그렇다면 훅(Hook)이란 무엇일까요? 모든 가스 타운 워커는 자신만의 훅 🪝을 가지고 있습니다. 이는 해당 에이전트만을 위해 고정된 특수 비드로, 가스 타운의 워크플로인 분자(molecules)를 걸어두는 곳입니다.

작업이 어떻게 그곳에 걸리게 될까요? 당연히 gt sling 을 통해서입니다. 워커에게 작업을 던지면(sling), 그 작업은 워커의 훅에 걸립니다. 작업을 즉시 시작하게 할 수도 있고, 미루거나, 심지어 먼저 재시작하게 할 수도 있습니다. 이에 대해서는 잠시 후에 자세히 다루겠습니다. 워커에게 작업을 던져 놓으면 당신은 다른 일을 처리하러 갈 수 있고, 워커는 묵묵히 작업을 계속할 것입니다.

Gas Town의 가장 단순하면서도 훌륭한 점 중 하나는, 세션 중 언제라도 “인계하자(let’s hand off)“라고 말하면 워커가 품위 있게 정리하고 스스로 재시작한다는 것입니다. GUPP 덕분에 에이전트가 훅(hook)에 연결되어 있다면 자동으로 작업을 계속하게 됩니다.

불행히도, Claude Code는 비참할 정도로 너무 예의가 발라서 실제로는 GUPP가 항상 작동하지는 않습니다. 에이전트에게 “반드시 훅을 실행해야 한다”라고 말해도, 가끔은 아무것도 하지 않을 때가 있습니다. 그저 사용자 입력을 기다리며 가만히 앉아 있을 뿐이죠.

그래서 우리는 해결책을 마련했습니다.

Press enter or click to view image in full size

![[https://miro.medium.com/v2/resize:fit:770/1*blwto0wOjNmgjqZ9tcm0dg.jpeg|640]] >

그림 7: GUPP, 가스타운 보편적 추진 원리(Gastown Universal Propulsion Principle)

GUPP 넛지(Nudge)

Gas Town의 워커들은 “예의보다는 물리 법칙”을 따르도록 프롬프트가 설정되어 있으며, 시작 시 자신의 훅(hook)을 확인하라는 지시를 받습니다. 훅에 할 일이 있다면, 기다리지 않고 즉시 작업을 시작해야 합니다.

불행히도 실제 상황에서 Claude Code는 메일과 훅을 확인하고, 보고를 마친 뒤 작업을 시작하기 전까지 사용자가 무엇이든 입력하기를 기다리는 경우가 종종 있습니다. 때로는 바로 시작하기도 하지만, 그렇지 않을 때도 있습니다. 이 문제는 시간이 지나면서 개선되겠지만, 현재로서는 가끔씩 ‘넛지(nudge, 가벼운 자극)‘가 필요합니다.

Gas Town 워커들이 항상 GUPP를 따르는 것은 아니기 때문에, 에이전트가 시작된 후 약 30초에서 60초 사이에 자극을 주는 다양한 시스템이 마련되어 있습니다. 때로는 더 빠를 수도, 더 느릴 수도 있습니다. 하지만 마을이 가동 중이고 정지 상태가 아니라면, 대략 5분 이내에는 반드시 넛지를 받게 됩니다.

에이전트들은 가스 타운(Gas Town)의 핵심 실시간 메시징 명령인 gt nudge 를 통해 시작 신호를 받습니다. 이 명령은 워커(또는 전체 채널)에 tmux 알림을 보냅니다. 이는 tmux send-keys의 일부 디바운스 문제를 해결하며, 사용자가 직접 입력한 것처럼 워커가 알림을 확실히 수신하도록 보장합니다. 이를 통해 워커는 메일과 훅(hook)을 읽고 행동을 취하게 됩니다.

GUPP 너지(Nudge) “핵(hack)“이 적용되고 디컨(Deacon)으로부터 내려오는 계층적 하트비트가 갖춰지면, GUPP는 일반적으로 원활하게 작동하며 할 일이 있는 한 가스 타운을 계속 가동합니다. 컨보이(Convoy)는 개입 없이 시작되고, 완료되며, 착륙합니다. 워커들은 세션을 가로질러 분자(molecules) 작업을 이어갑니다. 충분한 일감만 주어지면 가스 타운은 밤새도록 작동할 수 있습니다.

죽은 조상들과 대화하기

GUPP 너지는 흥미로운 기능인 gt seance=로 이어졌습니다. 이 기능을 통해 가스 타운 워커들은 자신의 역할을 수행했던 전임자들과 직접 소통할 수 있습니다. 즉, 현재의 시장(Mayor)이 전임 시장과 대화하는 식입니다. 이는 종료된 이전 세션을 다시 시작할 수 있게 해주는 Claude Code의 =/resume 기능 덕분에 가능합니다.

이 기능이 유용한 이유는, 종종 작업자가 “좋아, 다음 작업자에게 이 방대한 작업물과 조언들을 다 넘겼어! 그럼 안녕! /handoff “라고 말하며 사라져 버리는데, 새로 투입된 작업자가 나타나서는 “뭐라고? 아무것도 안 보이는데”라고 반응하기 때문입니다. 예전에는 수동으로 GUPP 넛지(nudge)를 주느라 ‘let’s go’로 시작하는 최근 40여 개의 세션 중에서 어떤 것이 이전 세션이었는지 서툴게 일일이 찾아내야 했습니다. 정말 어색하고 번거로워서 거의 그럴 가치가 없을 정도였죠.

=gt seance=가 탄생하게 된 배경은 이렇습니다. 넛지에서 에이전트에게 무엇을 말하는지는 중요하지 않습니다. 에이전트의 프롬프팅은 GUPP와 Gas Town의 작동 원리, 그리고 그들이 기계의 부품으로서 얼마나 중요한지 등에 대해 매우 엄격하게 설정되어 있어서, 사용자가 에이전트의 훅(hook) 지침을 직접적으로 무시하도록 명령하지 않는 한 사용자가 입력하는 내용은 완전히 무시하기 때문입니다.

Press enter or click to view image in full size

![[https://miro.medium.com/v2/resize:fit:770/1*G1mjYw9Hew3Mty91cGQQ9Q.jpeg|640]] >

그림 8: \`gt seance\`를 통해 죽은 조상과 대화하기

따라서 “안녕”이라거나 “일론 머스크가 달은 녹색 치즈로 만들어졌대” 또는 “네 일이나 해”라고만 말해도 에이전트는 훅을 실행할 것입니다.

일주일 전 제 아이디어는 이랬습니다. 어차피 모든 세션을 조금씩 건드려야(nudge) 하므로, 그 과정에 Gas Town의 역할 및 PID와 함께 Claude Code의 session_id=를 포함하기로 했습니다. 이렇게 하면 각 =/resume 세션에 고유하고 유용하며 식별 가능한 제목을 부여할 수 있습니다.

gt seance=를 사용하면, 워커는 말 그대로 하위 프로세스에서 Claude Code를 실행하고, =/resume 을 사용하여 이전 작업의 대화 내용을 찾은 뒤, “네가 남겨둔 내 작업물들이 도대체 어디에 있느냐?”라고 묻게 됩니다.

정말 즐거운 시간입니다. Gas Town은 즐거운 시간(Good Times) 그 자체니까요.

이제 MEOW 스택에 대해 이야기할 때가 된 것 같군요. 여러분도 이제 준비가 되셨을 겁니다.

Molecular Expression of Work (MEOW)

** Steve Yegge의 소식을 이메일로 받아보세요

Medium에 무료로 가입하고 이 작가의 최신 소식을 확인하세요.

Subscribe

Subscribe

가스 타운(Gas Town)은 거대한 빙산의 일각에 불과합니다. 가스 타운 자체는 12개월 이상 지속되지 않을 수도 있지만, 가스 타운의 뼈대인 MEOW 스택은 앞으로 몇 년 동안 살아남을 것입니다. 이것은 발명이라기보다는 발견에 가깝게 느껴집니다.

Press enter or click to view image in full size

![[https://miro.medium.com/v2/resize:fit:770/1*e82_Q8ziFJ0t83aSgxEBWQ.jpeg|640]] >

그림 9: 작업의 분자적 표현(MEOW)

가장 먼저 비즈(Beads) 가 등장했습니다. 지난 10월, 저는 답답한 마음에 Claude에게 제 모든 작업을 가벼운 이슈 트래커에 담으라고 말했습니다. 저는 Git을 원했고, Claude는 SQLite를 원했습니다. 우리는 두 가지를 절충했고, 약 15분간의 미친 듯한 설계 끝에 비즈가 탄생했습니다. 이것이 기본적인 작업 단위입니다.

곧이어 에픽(Epics) 이 등장했습니다. 하위 요소를 가질 수 있는 비즈로, 그 하위 요소 자체가 다시 에픽이 될 수도 있습니다. 이를 통해 하향식 계획을 세울 수 있는 큰 유연성을 확보했습니다. 에픽의 하위 요소들은 기본적으로 병렬로 처리되지만, 순차적 실행을 강제하기 위해 명시적인 의존성을 설정할 수도 있습니다. 에픽을 사용하면 마지막에 할 일이 루트가 되고 처음에 할 일이 에픽 트리의 잎이 되는 ‘역방향’ 계획을 세울 수 있습니다. 다소 투박해 보일 수 있지만, AI는 이를 아주 잘 파악해 냅니다.

다음으로 분자(Molecules) 가 등장했습니다. 호주에서 돌아온 지 며칠 지난 12월 17일에 이 아이디어가 떠올랐습니다. 처음 두 개의 오케스트레이터를 작업하면서, 에이전트의 작업을 마치 할 일 목록(TODO list)처럼 체크해야 하는 순차적인 작은 작업들로 나누고 싶다는 생각이 들었습니다. 에이전트들은 이미 그렇게 하고 있지만, 저는 이를 미리 설정하고 싶었습니다. 그래야 몇 시간 분량의 작업을 미리 구성해 두고, 에이전트가 이를 올바른 순서에 따라 원자적으로 실행할 수 있기 때문입니다.

다시 말해, 분자(molecules)는 비드(Beads)로 연결된 워크플로입니다. 에픽(epics)과 달리 임의의 형태를 가질 수 있으며, 런타임에 서로 결합될 수도 있습니다.

그다음으로 저는 원시분자(protomolecules) 라는 개념을 고안했습니다. 이는 클래스나 템플릿과 같은 것으로, 실제 비드들로 구성되며 모든 지침과 의존성이 사전에 설정되어 있습니다. 예를 들어 “설계”, “계획”, “구현”, “검토”, “테스트”와 같은 템플릿 이슈들의 전체 그래프라고 볼 수 있죠. 이를 “분자”로 인스턴스화하면 에이전트가 한 번에 하나씩 이슈를 처리해 나가는 워크플로가 됩니다. 인스턴스화 과정에서는 원시분자의 모든 비드를 복사하고 변수를 치환하여 실제 워크플로를 생성하게 됩니다.

예를 들어, 저에게는 20단계로 구성된 비드 릴리스 프로세스가 있습니다. 이전에는 에이전트가 이를 완수하는 데 어려움을 겪곤 했습니다. GitHub Actions 완료 대기, CI 종료 대기, 다양한 아티팩트 배포 대기 등 대기 시간이 길었기 때문입니다. 저는 에이전트에게 끝내라고 계속 잔소리를 해야 했고, 에이전트들은 언제나 단계를 건너뛰곤 했습니다.

분자를 도입하면서 생각한 아이디어는 릴리스 단계를 위한 20개의 비드를 만들고, 이를 올바른 순서로 연결한 뒤, 에이전트가 한 번에 하나의 이슈씩 체인을 따라가게 만드는 것이었습니다. 추가적인 장점 중 하나는 에이전트가 이슈를 할당받고 종료함에 따라 활동 피드(activity feed)가 자동으로 생성된다는 점입니다.

워크플로가 분자(molecule) 형태로 캡처되면, 에이전트의 충돌, 압축, 재시작 또는 중단 상황에서도 살아남을 수 있습니다. 그저 동일한 샌드박스에서 에이전트를 시작하고, 분자 내에서 자신의 위치를 찾게 한 뒤, 중단된 지점부터 다시 시작하게 하면 됩니다.

원시분자(Protomolecules)는 훌륭합니다. Claude가 ‘익스팬스(The Expanse)‘를 인용하자고 고집하는 바람에, 거의 모든 주요 스튜디오로부터 소송을 당하게 생겼습니다. 하지만 우리는 곧 루프와 게이트가 포함된 분자들을 적절히 구성하기 위해 매크로 확장 단계가 필요하다는 것을 깨달았습니다. 그래서 저는 TOML 형식의 워크플로 소스 형태인 포뮬러(Formulas) 를 고안해냈습니다. 이는 원시분자로 “조리(cooked)“된 후, Beads 데이터베이스 내에서 위스프(wisps)나 분자(mols)로 인스턴스화됩니다.

포뮬러는 거의 모든 지식 노동을 설명하고 구성할 수 있는 방법을 제공합니다. 저는 이를 위한 ‘몰 몰(Mol Mall)‘이라는 마켓플레이스를 준비 중입니다. 계속 지켜봐 주세요.

Press enter or click to view image in full size

![[https://miro.medium.com/v2/resize:fit:770/1*X3zb5wzCaROZ0ifs6-9Ohg.jpeg|640]] >

그림 10: 포뮬러와 조리(Cooking)

마지막으로, 저는 “분자화된 작업”을 나타낼 단어가 필요했습니다. 이는 에이전트가 한 번에 한 단계씩 집어 들어 완료할 수 있는 형태의 작업을 의미합니다. 분자가 다른 분자와 결합하듯 서로 구성할 수 있는 작업이며, 여러분이 충분히 용기만 있다면 거대한 프로젝트 전체의 의존성을 미리 설정해 두고 주말 내내 가스 타운(Gas Town)이 무인 상태로 달려들게 할 수도 있습니다.

이 거대한 작업 분자들의 바다, 즉 세상의 모든 작업을 일컫는 용어는 “구졸린(guzzoline)“입니다. 다만 문서에서 자주 사용하지는 않습니다. 이는 특정 리그(Rig)가 리그 간 컨보이(Convoy)에 기여하는 워 리그(War Rig)와 마찬가지로 가스 타운만의 관용구 같은 것입니다. 가끔 듣게 되겠지만 일상적인 명칭에서 큰 비중을 차지하지는 않습니다.

비결정적 멱등성 (Nondeterministic Idempotence)

가스 타운은 제가 ‘비결정적 멱등성(NDI)‘이라 부르는 원칙에 따라 작동합니다. 이는 템포럴(Temporal)의 결정론적이고 내구성 있는 리플레이와 유사하지만, 가스 타운은 완전히 다른 메커니즘을 통해 내구성과 실행 보장을 달성합니다.

Press enter or click to view image in full size

![[https://miro.medium.com/v2/resize:fit:770/1*92Xi_CC-Zh2co4j5eG6F2Q.jpeg|640]] >

그림 11: 비결정론적 멱등성

MEOW 스택에서 작동하는 Gas Town에서는 모든 작업이 분자(molecules)로 표현됩니다. 여기에는 지난 2주 동안 제가 발견한 일종의 대수학이 존재합니다. 분자는 워크플로입니다. 분자는 복잡한 형태, 루프, 게이트를 가질 수 있으며 실제로 튜링 완전(Turing-complete)합니다. 그리고 워크플로의 각 단계는 초지능 AI에 의해 실행됩니다.

AI는 할 일 목록(TODO list)과 수락 기준(acceptance criteria)을 따르는 데 매우 능숙하기 때문에, 분자를 신뢰성 있게 따라갑니다. AI는 GUPP의 개념을 이해하며, 아무리 사소하더라도 이슈를 체크하는 관료적 절차가 실시간 활동 피드를 업데이트한다는 점을 인지하고 있습니다. 이러한 추론 능력은 AI가 작업을 수행하는 동안 활기차고 궤도에서 벗어나지 않게 유지하기에 충분합니다. AI는 “지루함”을 느끼지 않으며, (하나의 작고 단일한 단계를 제외하고는) 스스로 할 일 목록을 관리하지 않기 때문에 실수를 저지를 확률이 훨씬 낮습니다.

이는 분자 워크플로가 내구성이 있음을 의미합니다. 만약 분자가 에이전트의 훅(hook)에 걸려 있다면 다음과 같은 특성을 가집니다:

1. 에이전트는 영속적입니다. 즉, Git을 기반으로 하는 Bead입니다. 세션은 생겼다 사라지지만, 에이전트는 유지됩니다.
2. 훅(Hook) 또한 영속적이며, Git을 기반으로 하는 Bead입니다.
3. 분자(Molecule)는 영속적입니다. 이는 Git에 저장된 Bead들의 사슬입니다.

따라서 Claude Code가 충돌하거나 컨텍스트가 부족해져도 상관없습니다. 이 에이전트 역할을 위한 다른 세션이 시작되는 즉시, (GUPP를 통하거나 순찰 에이전트의 자극을 받아) 분자의 해당 단계에서 즉시 작업을 시작할 것입니다. 만약 지난 단계 도중에 충돌이 발생했다는 것을 알게 되더라도 문제없습니다. 에이전트가 적절한 해결책을 찾아내어 실행하고 다음 단계로 넘어갈 것입니다.

따라서 경로가 완전히 비결정적일지라도, 에이전트를 계속 투입하는 한 결과 — 즉, 실행하고자 했던 워크플로우 — 는 결국 “보장된” 대로 완료됩니다. 에이전트가 진행 과정에서 실수를 할 수도 있지만, 분자를 설계한 사람이 수락 기준을 명확하게 정의해 두었을 것이기에 스스로 수정할 수 있습니다.

수많은 예외 상황이 존재합니다. 이러한 NDI에 대한 설명은 지나치게 단순화된 것입니다. Gas Town은 Temporal을 대체하는 것이 아닙니다. Gas Town이 본인에게 적합한지는 의사와 상담하십시오. 하지만 Gas Town은 개발자 도구로서 충분히 훌륭한 워크플로우 보장을 제공합니다! 적어도 저에게는 말이죠!

Wisps: 일시적인 오케스트레이션 비즈(Beads)

우리가 다루는 개념들 중 짚고 넘어가야 할 다른 부분들이 있습니다. 대부분의 경우 여러분은 이런 세부 사항보다는 컨보이(convoy)의 시작과 종료, 그리고 활동 피드와 대시보드를 모니터링하는 것에 더 신경을 쓸 것입니다. 하지만 Gas Town의 분자적 “화학”에는 오케스트레이션에서 활발히 사용되는 풍부하고 다양한 세부 요소들이 담겨 있습니다.

12월 21일에 탄생한 핵심적인 확장성 발명품 중 하나는 ‘위스프(Wisps)‘로, 이는 일시적인 비드(Beads)입니다. 위스프는 데이터베이스에 저장되고 해시 ID를 부여받으며 일반 비드처럼 작동합니다. 하지만 JSONL 파일에 기록되지 않으므로 Git에 영구 저장되지 않습니다. 실행이 끝나면 위스프는 “소각(burned)“(파괴)됩니다. 선택적으로, Git에 커밋되는 한 줄짜리 요약/다이제스트로 압축될 수도 있습니다.

위스프는 고속 오케스트레이션 워크플로우에서 중요합니다. 이들은 가스 타운(Gas Town) 작업에 있어 물질의 기체 상태와 같습니다. 리파이너리(Refinery), 위트니스(Witness), 디컨(Deacon), 폴캣(Polecats) 등 모든 순찰 에이전트는 개별 순찰이나 워크플로우 실행 시마다 위스프 분자를 생성합니다. 이를 통해 워크플로우가 트랜잭션 방식으로 완료되도록 보장하면서도, 오케스트레이션 노이즈로 Git을 오염시키지 않습니다.

Patrols

순찰(Patrols)은 순찰 워커(Patrol Workers), 특히 리파이너리, 위트니스, 디컨을 위해 실행되는 일시적인 워크플로우입니다.

Press enter or click to view image in full size

![[https://miro.medium.com/v2/resize:fit:770/1*7CrO9Kr5FASd-nZIv24enw.jpeg|640]] >

그림 12: 가스 타운의 순찰(Patrols)

순찰(Patrol)은 에이전트가 루프 형태로 실행하는 일시적인(wisp) 워크플로입니다. 순찰에는 지수 백오프(exponential backoff)가 적용됩니다. 순찰 단계에서 할 일을 찾지 못하면 에이전트는 다음 순찰을 시작할 때까지 점점 더 오래 기다리며 서서히 수면 상태로 들어갑니다. 상태를 변경하는 gt 또는 bd 명령은 타운을 깨우며, 사용자가 직접 gt 명령을 사용하여 개별 워커, 그룹, 리그(rig) 또는 타운 전체를 시작할 수도 있습니다.

정제소(Refinery)의 순찰은 꽤 간단합니다. 워크스페이스를 정리하는 몇 가지 사전 점검 단계를 거친 후, 머지 큐(Merge Queue)가 비거나 세션을 재시작해야 할 때까지 큐를 처리합니다. 핸드오프 준비가 되면 분자(molecule) 내에서 몇 가지 사후 단계를 수행합니다. 현재 정제소 순찰에 플러그인을 추가할 준비를 하고 있지만, 아직 구현되지는 않았습니다. 플러그인이 추가되면 머지 큐를 조작하고 지능적으로 순서를 재배열하거나, 가스 타운(Gas Town)의 백엔드를 다른 시스템과 연결하는 플러그인을 추가할 수 있게 됩니다.

목격자(Witness)의 순찰은 조금 더 복잡합니다. 폴캣(polecats)과 정제소의 상태를 확인해야 합니다. 또한 집사(Deacon)가 멈춰 있지 않은지 살피기도 합니다. 그리고 목격자는 리그 수준의 플러그인을 실행합니다.

집사(Deacon)의 순찰은 많은 중요한 책임을 맡고 있습니다. 완전히 새로운 UI나 기능을 제공하는 등의 타운 수준 플러그인을 실행합니다. 또한 집사는 gt handoff 프로토콜과 에이전트 세션 재시작에 관여하며, 일부 워커가 제대로 정리되도록 보장합니다. 집사의 순찰이 충분히 복잡해졌기에, 집사의 전용 크루인 개(Dogs)를 헬퍼로 추가했습니다. 이제 집사는 복잡한 작업이나 조사를 개에게 넘기도록 프롬프트가 작성되어 있습니다. 이는 오래 걸리는 순찰 단계가 협력적이고 메일 기반인 타운의 핵심 이벤트 시스템을 방해하지 않도록 하기 위함입니다.

Gas Town 플러그인

Gas Town은 플러그인을 “에이전트로부터의 조정되거나 예약된 주의(attention)“로 정의합니다. Gas Town 워커는 워크플로(주로 순찰 루프 형태)를 실행하며, 모든 워크플로는 원하는 만큼의 “플러그인 실행” 단계를 포함할 수 있습니다.

Gas Town의 Deacon 순찰은 Town 레벨의 플러그인을 실행하며, 이제 Dogs와 함께 실행되므로 사실상 무제한으로 실행될 수 있습니다. 타이머와 콜백을 일부 지원하긴 하지만, 대부분은 라이프사이클 훅(lifecycle hooks) 형태입니다. 아직 이 서브시스템에 대해 많은 설계를 고민하지는 않았으므로, 플러그인 시스템을 사용하고 싶다면 저에게 알려주세요. 함께 해결해 나갈 수 있습니다.

저는 Gas Town의 수많은 추가 기능을 플러그인으로 구현할 계획입니다. 다만 v1 출시에는 포함되지 않았을 뿐입니다. 이 기능들은 아마도 Mol Mall의 포뮬러(formulas) 형태로 제공될 것입니다.

Press enter or click to view image in full size

![[https://miro.medium.com/v2/resize:fit:770/1*5inz21LF7DU3X5EBDqH6zA.jpeg|640]] >

그림 13: 가스 타운(Gas Town)의 경량 플러그인

🚚 컨보이(Convoys) 🚚

좋습니다, 휴. 잘 따라오셨습니다. 꽤 많은 이론을 다뤘는데, 특히 지난 3주 동안 제가 제멋대로 지어내고 오소리 같은 이름들을 붙인 헛소리들이라 이해하기 더 어려우셨을 겁니다. 하지만 여기에는 나름의 우아한 일관성과 응집력이 있습니다. 연결된 작업의 바다에서 그래프 노드 역할을 하는, Git 데이터 평면 위의 작은 노란색 포스트잇을 기반으로 한 워크플로우 오케스트레이션이죠.

윽! 아무도 관심 없다는 거 압니다. 여러분은 그저 토큰을 집어삼키는 속도에만 제한을 받을 뿐, 초인적인 속도로 일을 끝내고 싶을 뿐이죠. 이제 그 방법에 대해 이야기해 봅시다.

가스 타운의 모든 것, 즉 모든 작업은 컨보이(Convoy)로 집계됩니다.

Press enter or click to view image in full size

![[https://miro.medium.com/v2/resize:fit:770/1*2GYflRkcqh1KhE09SJb6QA.png|640]] >

그림 14: 컨보이 CLI 화면

컨보이는 가스 타운의 티켓팅 또는 작업 지시 시스템입니다.

컨보이는 일련의 작업을 배송 추적이 가능한 단위로 묶어주는 특수한 비드(bead)입니다. 컨보이는 에픽(Epic) 구조를 사용하지 않는데, 이는 컨보이에서 추적되는 이슈들이 컨보이의 자식 요소가 아니기 때문입니다. 대부분의 이슈는 이미 다른 부모 요소를 가지고 있습니다.

Gas Town에서 작업을 전달하는 가장 기본적인 프리미티브는 gt sling=입니다. 제가 시장(Mayor)에게 "tmux 세션 상태 표시줄에 리그(rig) 수가 잘못 표시되고 있으니, 비드를 생성하고 슬링(sling)해"라고 말하면, 시장은 해당 문제에 대한 비드(bead)를 생성한 후, 그날의 팩토리 침팬지로서의 기분에 따라 폴캣(polecat), 도그(dog) 또는 크루(crew)에게 =gt sling 으로 작업을 전달합니다.

실제 예시를 들자면, 저는 종종 비드 크루에게 릴리스 분자(release molecule)를 폴캣에게 슬링하라고 지시합니다. 그러면 폴캣은 20단계의 릴리스 프로세스를 진행하여 완료하고, 저는 컨보이(Convoy)가 도착/종료되었다는 알림을 받게 됩니다.

“이슈 wy-a7je4 가 방금 완료되었습니다”라는 메시지는 혼란스러울 수 있습니다. 제목을 보더라도 그 이슈가 포함된 더 큰 작업 단위를 반영하지 못할 수도 있기 때문입니다. 그래서 이제는 단일 폴캣 슬링부터 누군가 시작한 대규모 스웜(swarm)에 이르기까지, 슬링된 모든 작업 단위를 컨보이로 감쌉니다.

컨보이는 나날이 발전하고 있는 대시보드에 표시됩니다. 각 컨보이별로 확장 가능한 트리 구조를 가진 Charmbracelet TUI가 제공되어, 추적 중인 개별 이슈들을 확인할 수 있습니다. UI와 UX는 계속 개선될 것입니다. 이제 Gas Town의 첫날이 시작되었을 뿐입니다.

컨보이(Convoy)는 기본적으로 기능 단위입니다. 기술 부채 정리든, 실제 기능 구현이든, 버그 수정이든, 각 컨보이는 가스 타운(Gas Town) 작업 지시 아키텍처의 티켓팅 단위가 됩니다. 도입된 지 얼마 되지 않았지만(아마 3~4일 정도?), 이미 단연코 가장 즐겁게 일할 수 있는 방식이 되었습니다.

하나의 컨보이가 완료되기 전까지 여러 개의 스웜(Swarm)이 이를 “공격”(작업)할 수 있다는 점에 유의하세요. 스웜은 지속적인 작업을 수행하는 일시적인 에이전트 세션입니다. 컨보이를 관리하는 주체(예: 위트니스)는 계속해서 폴캣(Polecat)을 재순환시키며 이슈에 투입할 것입니다.

가스 타운 워크플로우

가스 타운에서 가장 근본적인 워크플로우는 핸드오프(handoff)입니다. gt handoff 명령어나 /handoff 명령어를 사용하거나, 그냥 “핸드오프하자(let’s hand off)“라고 말하면 됩니다. 그러면 워커는 선택적으로 자신에게 작업을 보낸 뒤, 바로 그 tmux 화면에서 세션을 재시작합니다. 시장(Mayor), 크루(Crew), 그리고 때로는 다른 워커들까지 당신이 지시하는 모든 워커는 핸드오프할 시점임을 알려주기를 기다릴 것입니다.

그 외에 Gas Town의 개발 루프는 Claude Code(및 Beads)와 거의 동일하며, 단지 그 규모가 더 클 뿐입니다. 스웜(swarm) 기능을 무료로 얻을 수 있고(비용은 들지만요), 꽤 괜찮은 대시보드와 워크플로우 기술 방법, 그리고 메일 및 메시징 기능을 제공받습니다. 그게… 전부입니다.

저는 tmux가 사용하기 쉬우면서도 놀라울 정도로 강력하다는 것을 알게 되었고, 이제 막 그 세부적인 기능들을 배우기 시작했습니다. tmux는 저에게 필요한 모든 것, 즉 어떤 에이전트로든 전환하고, 모든 에이전트가 무엇을 하고 있는지 훑어보고, 관련된 에이전트 그룹들을 순환하며 확인하는 기능을 제공합니다. 정말 훌륭합니다.

Press enter or click to view image in full size

![[https://miro.medium.com/v2/resize:fit:770/1*5S-XybhhayiKgX0pJu7RNw.png|640]] >

그림 15: tmux list-sessions 보기

저는 Gas Town을 위한 Emacs UI를 분명 기대하고 있습니다. 그리고 여러분 중 일부는 웹 UI를 기대하고 계시겠죠. 마음껏 만들어 보세요

하지만 tmux만으로도 충분합니다. 능숙해지기 위해 많은 tmux 명령어를 익힐 필요는 없습니다. 저는 다음 몇 가지만 사용합니다.

• C-b s — 세션 목록을 확인하고, 내용을 살피고, 세션을 전환합니다.
• C-b b — 커서를 뒤로 이동합니다(많은 에디터와 셸에서의 C-b 와 같습니다). tmux에서는 조금 더 느리게 뒤로 갈 뿐입니다. 충분히 감수할 만한 대가죠!
• C-b [ — “복사 모드”로 진입합니다. 출력을 일시 정지하고 스크롤할 수 있게 해줍니다( ESC 로 종료).
• C-b C-z C-z — 프로세스를 중단하고 Shell로 나갑니다.
• C-b n/p — 그룹 내 다음 워커로 전환합니다 (예: 리그 내 다음 크루 멤버).
• C-b a — 활동 피드 뷰를 불러옵니다 (내 설정 기준).

이게 거의 전부입니다! 정말이지, tmux를 많이 알 필요는 없습니다. 방해되지 않으면서도 결정적인 순간에 큰 도움이 됩니다. 또한 원격 클라우드 워커(며칠 내로 연결할 예정입니다)를 가능하게 하며, 커스터마이징도 매우 자유롭습니다. Claude Code에게 tmux를 더 편리하게 만들어 달라고 요청하기만 하면 알아서 해줄 것입니다. 원하는 뷰를 만들고, 키 바인딩을 마음대로 바꾸고, 커스텀 팝업을 만드는 등 무엇이든 가능합니다. 마치 아기 Emacs처럼 놀랍습니다.

가스 타운(Gas Town)에서의 계획 수립

가스 타운은 많은 연료를 필요로 합니다. 이곳은 ‘구졸린(guzzoline)’, 즉 작업 분자를 소비하는 동시에 생산하기도 합니다. 가스 타운을 정상 궤도로 유지하는 것 외에 아마도 가장 어려운 문제는 계속해서 연료를 공급하는 일일 것입니다. 가스 타운은 구현 계획을 너무나 빠르게 처리해 버리기 때문에, 엔진이 멈추지 않게 하려면 엄청난 양의 설계와 계획 작업을 수행해야 합니다.

소비 측면에서 보면, 여러분은 가스 타운에 에픽(epic), 이슈, 그리고 분자(구성된 워크플로)를 공급합니다. 그러면 시스템은 이를 처리하며 워커(worker)들을 생성합니다. 현재 저는 하이퍼스케일러에 원격 워커를 아직 구현하지 않았기 때문에(곧 추가 예정!) 워커 수를 30개 미만으로 유지하려 노력 중이며, 시장(Mayor)과 목격자(Witnesses)를 정말 강하게 몰아붙이지 않는 한 보통은 12개 정도의 활성 워커만 유지합니다.

하지만 정말 놀랍습니다. 12개에서 30개 사이의 워커만 있어도, 추가적인 코드 리뷰와 테스트 단계가 포함되어 완료까지 시간이 더 걸리는 “샤이니(shiny)” 또는 “크롬(chrome)” 폴캣(polecat) 워크플로를 사용하더라도 단 한 번의 작업 세션 만에 엄청난 양의 백로그를 해치울 수 있습니다.

생산 측면에서는 Spec Kit나 BMAD와 같은 자체 기획 도구를 사용할 수 있으며, 계획이 준비되면 에이전트에게 이를 Beads 에픽으로 변환하도록 요청할 수 있습니다. 계획의 규모가 충분히 크다면, 이를 스웜(swarm) 방식으로 처리하여 계획의 각 부분에 대한 에픽을 대규모 컨보이 형태로 생성할 수도 있습니다.

수식을 사용하여 작업을 생성할 수 있습니다. 모든 코딩 작업(또는 디자인 작업, UX 작업)이 특정 템플릿이나 워크플로를 거치도록 하려면, 이를 분자(molecule)로 정의한 다음 오케스트레이션 템플릿으로 기본 작업을 “래핑”하거나 구성할 수 있습니다.

저는 제프리 에마누엘(Jeffrey Emanuel)의 “5의 법칙(Rule of Five)“을 위한 수식을 구현했습니다. 이는 LLM이 무언가를 다섯 번 검토하게 하되 매번 다른 영역에 집중하게 하면, 우수한 결과물과 산출물을 만들어낸다는 관찰 결과입니다. 따라서 어떤 워크플로든 가져와서 5의 법칙으로 처리하면, 각 단계가 4번씩 검토되도록 만들 수 있습니다(구현 자체가 첫 번째 검토로 간주됩니다).

이 방식은 비용이나 토큰 소모를 조절하기 위해 폴캣(polecat) 수를 제한하는 경우, 완료하는 데 수 시간 또는 수일이 걸릴 수 있는 대규모 워크플로를 생성할 수 있습니다. 하지만 Gas Town의 장점은 일단 작업이 생성되면, 이를 연결하여 자율적으로 처리할 수 있다는 점입니다.

Kubernetes와의 비교

약속했던 Kubernetes와의 비교입니다. 건너뛰셔도 좋습니다.

Press enter or click to view image in full size

![[https://miro.medium.com/v2/resize:fit:770/1*pQNnrELf1MpBQ0K9WNcbuQ.jpeg|640]] >

그림 16: Kubernetes와 Gas Town 비교

Gas Town은 의도치 않게 Kubernetes와 다소 닮은 구석이 있습니다. 두 시스템 모두 신뢰할 수 없는 워커(worker)들을 조정하여 목표를 달성합니다. 두 시스템 모두 실행 노드(Rigs 대 Nodes)를 감시하는 제어 평면(Mayor/Deacon 대 kube-scheduler/controller-manager)을 가지고 있으며, 각 노드에는 일시적인 워커(Polecats 대 Pods)를 모니터링하는 로컬 에이전트(Witness 대 kubelet)가 있습니다. 또한 두 시스템 모두 전체 시스템이 일치시켜야 할 진실의 원천(Beads 대 etcd)을 사용합니다. 이는 대규모로 복잡한 요소들을 관리해야 할 때 자연스럽게 나타나는 구조인 것으로 보입니다.

가장 큰 차이점은 쿠버네티스(Kubernetes)가 “실행 중인가?”를 묻는 반면, 가스 타운(Gas Town)은 “완료되었는가?”를 묻는다는 것입니다. K8s는 가동 시간(uptime)에 최적화되어 있습니다. 즉, N개의 복제본을 유지하고, 충돌한 포드를 재시작하며, 원하는 상태를 영원히 유지합니다. 반면 가스 타운은 완료(completion)에 최적화되어 있습니다. 작업을 끝내고, 호송대를 착륙시킨 다음, 워커를 제거하고 다음으로 넘어갑니다. K8s 포드가 익명의 가축이라면, 가스 타운의 폴캣(polecats)은 완료한 작업이 CV 체인으로 축적되는 공로를 인정받는 일꾼이며, 세션 이 가축에 해당합니다. K8s가 지속적인 목표 상태를 향해 조정한다면, 가스 타운은 최종적인 목표를 향해 나아갑니다. 엔진의 형태는 비슷하지만, 목적지는 근본적으로 다릅니다.

시간이 부족해서 넣지 못한 내용들

크리스마스에 가스 타운을 출시하고 싶었지만 놓치고 말았습니다. 제가 구상했던 것처럼 실제로 작동하기 시작한 것, 즉 날아다니기 시작한 것은 12월 29일 오후 8시경이 되어서였습니다. 제가 알아차리기 전까지 이미 2시간 동안 날아다니고 있었죠. 저는 시장(Mayor)과 대화하며 이런저런 불평을 늘어놓고 있었는데, 제 주변으로 수정 사항들이 반영되기 시작했습니다. 그때 저는 제가 그저 대화하는 것만으로 이 모든 것을 형성하고 있다는 사실을 깨달았습니다. 호송대(convoys)가 흐르고 착륙하며, 작업이 제출되고 검토되고 있었습니다… 이것이 제가 몇 달 동안 목표로 해왔던 모습입니다. 그리고 불과 이틀 전에야 겨우 작동하게 되었습니다.

다음은 이번 신년 발표에 포함되지 못한 내용들입니다.

• 연합(Federation) — Python 버전의 Gas Town조차 GCP의 원격 워커를 지원했습니다. 자신의 타운 용량을 확장하고, 다른 인간 타운과 작업을 연결 및 공유하기 위한 연합 지원 기능을 설계해야 합니다.
• GUI — 멋진 웹 UI는커녕 Emacs UI를 만들 시간조차 없었습니다. 하지만 누군가는 반드시 만들어야 하며, 그렇지 않다면 결국 제가 직접 만들게 될 것입니다.
• 플러그인(Plugins) — 분자 단계(molecule steps)에 플러그인 기능을 구현할 기회는 없었지만, 모든 인프라는 이미 갖춰져 있습니다.
• 몰 몰(The Mol Mall) — 워크로드를 정의하고 형성하는 분자들을 위한 마켓플레이스이자 거래소입니다.
• 하노이/MAKER — 백만 단계의 위스프(wisp)를 실행해 보고 싶었지만 시간이 부족했습니다.

그렇긴 해도, 실제로 구현된 결과물에 대해서는 꽤 만족합니다:

• 셀프 핸드오프(Self-handoffs) 가 원활하게 작동합니다 — 이는 가스 타운(Gas Town)의 핵심 내부 루프 워크플로입니다.
• 슬링잉(Slinging)*이 작동하고, *컨보이(convoys) 도 작동합니다.
• 전체 MEOW 스택 이 작동합니다
• Deacon, Witness, Refinery 순찰대 가 모두 자동으로 실행됩니다
• Crew 는 훌륭하며, 가공되지 않은 Claude Code 인스턴스보다 훨씬 낫습니다
• tmux UI 는 예상했던 것보다 훨씬 더 놀라울 정도로 잘 작동합니다.

또한 gt seance 와 같은 멋진 기능들도 추가되었습니다. 대체로 지난 17일 동안 훌륭한 성과를 거두었습니다. 지금까지는 말이죠.

다음 시간에 계속됩니다

저도 여러분만큼이나 지쳤네요. 즐거운 대화였지만, 이제 다시 가스 타운(Gas Town)으로 돌아가 봐야겠습니다.

이게 전부가 아닙니다. 이건 맛보기에 불과하죠. 앞으로 가스 타운에 관한 더 많은 블로그 포스트, 영상, 콘텐츠를 게시할 예정입니다. 기여하고 싶으시거나 이 흐름에 동참할 만큼 열정이 넘치신다면, 커뮤니티에 가입하여 토론에 참여하고 GitHub 이슈와 PR을 보내주세요

황금률을 기억하세요:

• 매일 최소 5개 이상의 Claude Code를 동시에 다루지 않는다면 Gas Town을 사용하지 마세요.
• 돈을 아끼고 싶다면 Gas Town을 사용하지 마세요.
• 키가 120cm(4피트) 이상이라면 Gas Town을 사용하지 마세요. 밋업에서 제가 사우론처럼 인상적으로 우뚝 서 있고 싶거든요.
• Gas Town을 사용하지 마세요.

Gas Town은 탄생한 지 겨우 17일밖에 되지 않았습니다. 적어도 Python 버전 Gas Town을 Go로 “포팅”한 이 버전은 그렇습니다. 지난 2주 동안 MEOW 스택 전체, wisps, patrols, convoys의 발명과 구현이 이루어졌고, 비드(beads) 형태의 에이전트와 정체성, 비드 형태의 스웜(swarms), 비드 형태의 역할, “신호로서의 피드(feed as the signal)” 혁신, 그리고 (Python Gas Town 이후) Refinery, Deacon, Dogs의 추가가 있었습니다. 그 외에도 수많은 것들이 더해졌습니다.

17일 동안 7만 5천 줄의 코드와 2,000번의 커밋이 있었습니다. 마침내 이틀 전에서야 제대로 가동되기 시작했습니다(GUPP가 작동하기 시작했습니다). 올해는 흥미로운 한 해가 될 것 같습니다.

지난 11월에 Anthropic에 Gas Town의 대략적인 구상을 공유했습니다. 제 생각에 그들을 겁먹게 한 것 같습니다. 그렇게 빨리 보수적으로 변하는 회사는 처음 봤습니다. 그들은 Beads 가 너무 독단적(opinionated)이라고 생각했기에, 흔히 말하듯 Gas Town은 그들에게 너무 과한 시도가 될까 봐 걱정됩니다.

하지만 벌써부터 가스 타운(Gas Town)에 대한 초기 소문을 듣고 찾아온 사람들로부터, 집에 앉아 나답게 지내는 대가로 돈을 지불하겠다는 기묘한 제안들이 들어오기 시작했습니다. 저는 비즈(Beads)와 가스 타운 작업을 계속하면서, 가끔 멋진 블로그 글을 쓰거나 컨퍼런스 또는 워크숍에 참석하기만 하면 됩니다. 현재 이런 제안이 세 건 이나 들어와 있습니다. 거의 비현실적인 기분입니다.

이 상황을 보니 크런치롤에서 몇 편 보았던 애니메이션이 떠오릅니다. 게으른 팬더 한 마리가 직장을 구하지 못해 카페를 운영하는 친구 북극곰에게 하루 종일 불평을 늘어놓는 내용이었죠. 그러던 어느 날, 팬더는 동물원에 갔다가 팬더 전시관 구인 광고를 발견합니다. 그는 지원해서 합격했고, 낮에는 앉아서 팬더 노릇을 하며 시간을 보내다가 밤에는 집으로 퇴근합니다. 정말이지 너무나 황당한 이야기였습니다.

제가 바로 그 팬더입니다.

저는 이 가치를 제대로 “이해하는” 회사와 팀을 찾기 전까지는 현업으로 복귀하지 않을 생각입니다. 사람들에게 미래를 보여주고 눈앞에서 흔들어 대도 믿어주지 않는 상황에 이제는 지쳤습니다.

저는 차라리 집에 앉아 제 손으로 직접 미래를 만들고 싶습니다. 실제로 제 부지에는 6종의 대나무가 자라고 있습니다. 저는 이미 인생 최고의 시간을 보내고 있는 판다나 다름없습니다.

저를 돕고 싶으시다면 연락해 주세요! 그리고 모든 놀라운 Beads 기여자분들께 진심으로 감사드립니다!

다음에 더 많은 Gas Town 콘텐츠와 함께 찾아뵙겠습니다. 새해 복 많이 받으세요!

Press enter or click to view image in full size

로그

|2026-01-02 Fri 07:22|

@user: [번역 요청]

Article Metadata:

• Title: Welcome to Gas Town
• URL: https://steve-yegge.medium.com/welcome-to-gas-town-4f25ee16dd04?source=rss-c1ec701babb7------2
• Feed: Stories by Steve Yegge on Medium
• Date: 2026-01-02 06:07
• Authors: Steve Yegge

Content: