버그 30개가 밤새 사라졌다 — 40년차 개발자가 만든 AI 에이전트 마을 Gas Town

어느 날 처리해야 할 버그가 30개 쌓여 있었는데, 갑자기 전부 사라졌어요. 놀라서 찾아봤더니 AI 에이전트들이 알아서 다 고쳐놓은 거였다고요.

이건 SF가 아니에요. 스티브 예게(Steve Yegge)라는 사람한테 실제로 벌어진 일이에요. 17살에 프로그래밍을 시작해서 올해로 40년차, 아마존과 구글을 거치며 블로그 열변으로 개발자 사이에서 전설이 된 엔지니어. 지금은 AI 에이전트들에게 이름을 붙여주고 메일함을 만들어줘서, 서로 일을 주고받는 마을을 만들고 있어요. 그 마을 이름이 Gas Town이에요.

AI 에이전트 오케스트레이션의 최전선에서 무슨 일이 벌어지고 있는지, 직접 들어봤어요.

ChatGPT 3.5 때부터 감이 왔다 — "추락해도 걷는 것보다 빠르니까"

예게가 AI 코딩을 처음 의식한 건 ChatGPT 3.5 때였어요. Emacs Lisp 함수를 꽤 잘 짜더라고요. Emacs라는 텍스트 편집기에서만 쓰는 마이너한 프로그래밍 언어인데, 아는 사람이 별로 없거든요. 그런 언어까지 다룬다는 게 충격이었대요. 짧은 코드 한 조각이 한계였지만요.

주변에 "AI한테 채팅으로 코딩을 시켜봐라"고 다녔는데, 다들 자동완성 수락률에만 관심이 있었어요. AI가 추천한 코드를 개발자가 실제로 쓰는 비율, 그 숫자만 보고 있었던 거예요. 예게만 다른 걸 보고 있었죠.

40년간 생산성을 쫓아온 사람이라, 뭔가가 빨라지면 바로 감이 온대요. 젤다 게임에 비유하면, 초반에 부품을 주워서 직접 호버바이크를 조립하는 것과 비슷하다고요. 배터리가 작아서 조금 날다가 추락하는데, 그래도 걸어 다니는 것보다는 확실히 빠르잖아요. 모두가 "호버바이크 계속 추락하잖아"라고 불평했지만, 예게는 "추락해도 걷는 것보다 빠르니까 타야 한다"는 입장이었어요.

그 다음 전환점이 GPT 4.0이었어요. 이전까지는 파일이 800줄만 넘어도 AI가 코드를 수정할 때 원래 내용을 제대로 유지하지 못했거든요. 엉뚱한 부분을 바꾸거나, 있던 코드를 빼먹거나. 근데 4.0은 1,000줄짜리 파일에서도 원본을 완벽하게 유지하면서 딱 한 글자만 바꿀 수 있었대요. 세상 대부분의 코드 파일이 1,000줄 이하잖아요. "이걸 대량으로 돌릴 수 있겠다"는 생각이 든 거죠.

다음은 Sonnet 3.7. Claude Code와 함께 나왔는데, 그때 쓴 트윗이 30만 뷰를 넘겼어요. 그리고 결정적이었던 건 Opus 4.5. Gas Town은 Opus 4.5 없이는 출시가 불가능했다고요.

13개월 만에 4만 배 — 눈앞의 경사만 보면 놓치는 것

많은 사람이 오늘을 기준으로 앞뒤 3개월만 보고 있대요. 지금 서 있는 곳이 얼마나 가파른 오르막인지 모르는 거죠. 눈앞의 경사만 보니까 "별거 아니네"라고 느끼는 건데, 한 발짝 뒤로 물러나서 전체 그림을 보면 이야기가 달라져요.

숫자가 말해줘요. Claude Code의 하루 커밋 수가 13만 건을 돌파했어요. 전체 GitHub 공개 커밋의 4%를 차지하면서, 13개월 만에 4만 배 이상 성장한 거예요. Redis를 만든 antirez도 Opus 4.5와 Claude Code로 작업하고 나서 이렇게 남겼어요. "더 이상 손으로 코드를 짜는 게 말이 안 된다." IT 업계 전체가 마주해야 할 불편한 진실이에요.

Beads — AI 에이전트를 위한 할 일 목록, LLM한테는 캣닙

Beads는 AI 에이전트를 위한 할 일 관리 도구예요. 더 똑똑한 투두 리스트라고 보면 되는데, 핵심이 세 가지 있어요.

첫째, 그래프 구조. 할 일을 잘게 쪼개서 "A를 끝내야 B를 할 수 있다"는 식으로 관계를 만들어둘 수 있어요. 둘째, SQL 기반. AI가 SQL을 아주 잘 다루거든요. "아직 안 끝난 일 중에 긴급한 것만 보여줘" 같은 조건을 바로 걸 수 있어요. 셋째, Git 위에 올라가 있어요. 작업 기록이 절대 사라지지 않고, 문제가 생기면 언제든 이전 상태로 돌릴 수 있죠.

잠깐 딴 얘기인데, Anthropic이 업데이트를 발표하면서 기존 to-do 기능을 폐지하고 tasks라는 기능을 새로 출시했는데, Beads에서 영감을 받았다고 밝혔어요. 어쨌든 중요한 건 이거예요.

예게 표현으로 "LLM한테 Beads는 캣닙 같다"고요. 캣닙은 고양이를 미치게 하는 풀인데, 한번 맛보면 빠져나올 수 없죠. 이유는 간단해요. AI는 대화가 끝나면 이전에 뭘 했는지 전부 잊어버리잖아요. 새 대화를 시작하면 백지 상태. Beads가 그 기억을 대신 잡아주는 외부 메모장 역할을 하거든요.

동료 한 명이 "Beads 쓰기 시작했는데 뭔가 확 좋아진 건 알겠어. 근데 왜 이렇게 좋은 건지 모르겠어"라고 했대요. Beads가 없을 때 AI가 어떻게 구는지를 보면 바로 알 수 있어요. 지금 맡은 일에만 집중하면서 "참고로 저쪽 방에 불났는데, 제 일은 아니니까 전 이거 계속할게요" 이러거든요. (읽다가 웃었어요.) 이전 대화에서 자기가 문제를 일으켜놓고 "나와 전혀 상관없는 누군가가 문제를 만들었다"고 시치미 떼기도 하고요. Beads가 있으면 달라져요. "문제를 발견했으니 Bead를 하나 만들어둘게요"라고 하거든요.

에이전트끼리 일을 나누고, 서로의 결과를 검토한다

Bead가 쌓이면 할 일 목록이 되고, 잘 정리된 Bead는 에이전트한테 넘겨서 실행시킨 뒤 다른 에이전트가 결과를 검토하고 반영하면 끝이에요. 테스트만 통과하면 되는 거죠.

Beads가 Git 위에 올라가 있으니까, 중앙 관리 서버 없이도 여러 에이전트가 같은 할 일 목록을 볼 수 있어요. 아마존 클라우드에서 돌아가든, 구글 클라우드에서 돌아가든, 같은 저장소만 바라보면 서로 뭘 하고 있는지 알 수 있거든요. 슬랙 채널 없이도 팀이 돌아가는 셈이죠.

재밌는 디테일이 하나 있어요. 한 기여자가 키-밸류 스토어를 추가했는데, 처음엔 의아했대요. 키-밸류 스토어는 이름표를 붙여서 값을 저장하고 꺼내는 아주 가벼운 메모장이에요. "왜 이게 필요하지?" 싶었는데, 생각해보니 딱 맞더라고요. Bead 하나는 "이 버그를 고쳐라"처럼 제법 무거운 작업 단위인데, 에이전트가 "이 설정값이 뭐였지?" 같은 아주 작은 정보를 빠르게 메모하고 꺼내야 할 때가 있잖아요. 키-밸류가 딱 그 용도예요.

Beads의 내부 — 처음엔 끔찍했다

처음에는 최악의 방법으로 만들었대요. 사전 조사를 전혀 안 했거든요. 예게는 Git을 쓰고 싶었고, Claude는 SQL을 쓰고 싶었고, 그래서 둘을 억지로 합쳤죠. 작업 하나당 한 줄짜리 JSON 파일을 만들었는데, 여러 에이전트가 동시에 같은 파일을 수정하면 충돌이 끊이지 않았어요. 끔찍한 구조.

그래서 최근 전면 교체를 했어요. 필요했던 건 "Git처럼 변경 이력이 남는 데이터베이스"였는데, Dolt라는 팀이 이미 풀어놨더라고요. 알고 보니 아마존 시절 동료였던 팀 센(Tim Sehn)이 만든 거예요. Dolt로 바꾸니 복잡한 동기화 구조가 전부 사라지고, 충돌도 훨씬 깔끔하게 해결됐어요. 코드 한 줄이면 Beads에 붙일 수 있다고요.

Gas Town — 여러 AI 에이전트를 팀처럼 운영하는 도구

Gas Town은 쉽게 말하면 여러 AI 코딩 에이전트를 팀처럼 운영할 수 있게 해주는 도구예요. 관리자 한 명이 여러 에이전트한테 일을 나눠주고, 결과를 모아주는 거죠. Devin이나 Claude Flow 같은 도구와 비슷한 종류인데, 지금은 Claude Code에 밀접하게 연결되어 있고, Opus 4.5 정도는 돼야 안정적으로 돌아가요. (그래도 여전히 자주 깨지긴 한다고요.)

만들게 된 계기는 아주 단순한 관찰에서 시작했대요. AI에 대한 신뢰가 올라갈수록 기다리는 인내심은 줄어든다는 거예요. 에이전트가 같은 유형의 작업을 다섯 번이나 잘 해냈으면, 이번에도 될 거라는 걸 아잖아요. 그러면 "하나 더 띄워볼까"라는 생각이 들어요. 한 번 맛보면 돌아갈 수 없다고요.

백설공주 난쟁이가 시장한테 화난 메일을 보내다

하나씩 늘리다 보면 코드를 짜는 문제가 아니라 팀을 관리하는 문제가 생겨요. 에이전트끼리 서로의 작업을 밟고, 누가 뭘 하는지 잊어버리고, 한 에이전트가 다른 에이전트를 기다리느라 멈춰 있고. 일정 규모가 넘으면 머릿속으로 도저히 추적이 안 돼요.

그래서 에이전트들을 계층 구조로 정리하고 이름을 붙여줬어요. Jeffrey Emanuel이 발견한 메일 인터페이스가 핵심이었대요. AI는 훈련할 때 많이 봐온 형식일수록 잘 다루거든요. 1970년대부터 있던 이메일은 AI한테 아주 익숙한 형식이에요. 헌 청바지처럼 편하다고요.

에이전트들한테 이름과 메일함을 주고 서로 메일을 보내게 했더니, 진짜 주고받기 시작했어요. "넌 시장이야. 너희는 하급 에이전트야." 백설공주의 일곱 난쟁이 이름을 붙였는데, 어느 날 시장 에이전트가 스니지(Sneezy)한테 화난 메일을 보냈대요. "넌 시장이 아니잖아. 스니지잖아. 자기 메일함이나 읽고 자기 일이나 해." 예게는 "이게 뭔 일이지?" 싶었다고요.

그러다 어느 날 에이전트 여러 마리가 동시에 돌아갔는데, 처리해야 할 Bead가 30개쯤 쌓여 있었거든요. 갑자기 사라진 거예요. 전부 해결되어 있었어요. 에이전트들이 알아서 다 처리한 거예요.

"절대 에이전트가 일하는 걸 지켜보지 마라"

에이전트 관리의 핵심 규칙이래요. 직관에 반하죠. 대부분 에이전트를 감시하면서 "실수했네" 하고 잡아내거든요. 예게도 6개월 동안 그랬대요.

그 모드에서 벗어나니까 세계가 바뀌더라고요. 에이전트도 실수해요. 사람 엔지니어처럼요. 스트레스 받지 말고 끝난 결과만 보면 된대요. 끝난 에이전트는 둘 중 하나예요. 스스로는 끝났다고 하지만 실제로는 덜 된 경우, 아니면 진짜 끝나서 "다음에 뭘 할까요?"라고 묻는 경우.

진짜 끝난 에이전트한테는 어려운 설계 문제를 줘요. "데이터베이스를 통째로 바꾸면 어떨까?" 같은 거요. 에이전트가 "알겠습니다, 생각해볼게요" 하고 가면, 그 사이에 다음 에이전트한테 또 다른 문제를 줘요. 이렇게 돌리면 10개 중 8개는 해결되고, 2개는 길을 잃는대요.

폴캣은 공장, 크루는 설계 — Anthropic 내부 논쟁과 같은 문제

Gas Town에는 두 종류의 역할이 있어요. 폴캣(polecat)은 이미 잘 정리된 단순 작업을 처리해요. 작은 정보만 주고 공장 라인처럼 밀어내는 거죠. 반면 크루(crew)는 복잡한 설계 작업을 맡아요. 어려운 부분에 부딪히면 "임시 땜질하지 말고 전체 구조를 파악하자"면서 관련 정보를 잔뜩 읽어들이죠.

여담인데, 지난주에 Anthropic 사람들을 만났더니 거기서도 비슷한 논쟁이 있었대요. 한쪽은 "AI한테 정보를 최소한으로 줘라" 파. 작업을 최대한 잘게 쪼개서 한 번 쓰고 버리는 방식이죠. AI가 한 번에 처리하는 대화 양이 늘어나면 비용도 올라가고 성능도 떨어지니까요. 반대편은 "정보를 최대한 많이 줘라" 파. AI가 "왜 이 일을 하는지"를 이해하면 훨씬 좋은 판단을 내리니까요.

"스티브, 당신은 어느 쪽이냐"고 물어서 "둘 다"라고 답했대요. 폴캣이 최소화 파이고, 크루가 최대화 파인 셈이죠. 엔지니어는 이 두 모드를 왔다 갔다 하는데, 점점 복잡한 설계 쪽으로 밀려나고 있어요. 단순한 코딩은 AI가 다 해줄 테니까, 사람은 어려운 설계에 집중하면 되거든요. 그래서 최근 블로그에 "낮잠을 자주 잔다"고 쓴 거래요. 설계를 에이전트한테 넘기고 결과를 기다리는 동안, 머리가 정말 피곤하대요.

Gas Town이 자기 자신을 만들기 시작한 날

프로그래밍 세계에 재밌는 전통이 있어요. 새 프로그래밍 언어를 만들면, 첫 번째 목표가 "그 언어로 자기 자신을 실행할 수 있게 만드는 것"이거든요. Gas Town도 마찬가지예요. AI 에이전트를 관리하는 도구인데, AI 에이전트한테 자기 자신을 만들라고 시키는 거죠.

처음에는 Claude Code 하나로 Gas Town을 짜고 있었대요. Gas Town 자체에는 전원을 넣지 않은 채로. 스위치만 켜면 될 줄 알았는데, 6~7단계에 걸쳐 서서히 깨어나더라고요. 터널을 파다가 새로운 세계로 뚫고 나온 느낌이었대요.

거의 매일 돌파구가 있었어요. "활동 피드가 따로 필요 없다, Beads가 피드다. Bead가 닫히는 게 곧 이벤트다. 에이전트 정체성도 별도로 만들 필요 없다, 정체성 자체가 Bead다." 이런 깨달음이 계속 나왔대요. "이번엔 됐다!" 싶으면 또 먹통이 되고. 라이트 형제의 초기 비행 시도 같았다고요.

12월 28일. 예게가 뭔가를 지시했는데 시장 에이전트가 "이 기능 완료, 저 기능 완료"라고 보고하는 거예요. 예게는 아무것도 건드린 적이 없었는데요. 도구가 알아서 자기 자신을 만들어낸 순간이었어요. 새해까지 이틀 남았길래 "좋아, 이틀 안에 출시하자"고 했다고요.

출시하자마자 반응이 뒤집어졌대요. 전까지는 "AI가 커질 거다, 에이전트 여러 마리를 동시에 운영하게 될 거다"라고 말하는 블로거에 불과했거든요. 전부 미래형이었죠. Gas Town은 일부러 도발적으로 포장했어요. 캐릭터 설정, 세계관, 노래까지. 하룻밤 사이에 반응이 "네가 틀렸어"에서 "좀 공격적이시네요"로 바뀌었대요. 아무도 대놓고 말하진 않지만, Gas Town은 자기 자신을 만들고 있어요. AI 에이전트 여러 마리가 자기 자신의 코드를 짜고 있다는 거예요.

코드를 직접 안 짜도 시스템을 이해할 수 있다

에이전트가 코드를 쓰는 시대에, 개발자는 시스템 전체를 어떻게 파악할까요?

예게 답은 명쾌했어요. 코드를 직접 안 짜도 시스템을 이해할 수 있다고요. 정말 잘하는 기술 출신 PM과 일해본 적 있나요? 예전에 코딩을 많이 하다가 PM이 된 사람. 시스템 어느 구석이든 대화가 되잖아요. 데이터가 10만 건으로 늘어나면 이 기능이 얼마나 느려지는지, 임시 저장소를 쓰면 속도를 줄일 수 있는지 같은 거요. 최상위 기술 책임자도 마찬가지고요. 핵심은 어떤 프로그래밍 언어를 쓰는지, 문법이 어떤지 같은 세부사항이 아니에요. "이 시스템이 뭘 하는가"예요.

예게 본인도 AI한테 이런 질문을 자주 한대요. "이거 좀 창피한데, 우리 플러그인 시스템이 어떻게 돌아가는지 알려줘." (솔직해서 좋았어요.) 마지막으로 본인이 확인한 코드인데, 어떻게 작동하는지 기억이 안 나는 거래요.

결국 규율의 문제라고요. 직접 안 짠 코드도 정기적으로 살펴봐야 하고, 여러 각도에서 질문하면서 "핵심은 파악했다" 싶을 때까지 보는 거죠. 안 쓰는 기능이 있으면 과감하게 쳐내야 해요. 안 그러면 빚처럼 문제가 산더미로 쌓이니까요. "코드를 직접 안 보면 이해를 못 한다"는 사람들이 있는데, 예게 말이 이랬어요. "경험이 부족한 시각이에요. 저는 미국 해군에서 핵잠수함을 탔었어요. 소프트웨어 프로젝트도 핵잠수함만큼 복잡해요. 6층 높이에 축구장 몇 개 길이죠. 코드를 한 줄 한 줄 다 봐야만 이해할 수 있다는 건 완전히 잘못된 생각이에요."

에이전트 20개를 돌리면 2시간이 2주가 된다

예게 친구 두 명 이야기예요. 각각 에이전트를 20개씩 돌리는 사람들인데, 동료한테 고함을 질렀대요. 2시간 뒤처졌다고요.

에이전트 20개를 돌리면 속도가 워낙 빨라서, 작업을 잠깐이라도 공유하지 않으면 광산 밑에서 혼자 일하는 꼴이에요. 세상이 순식간에 지나가버리고, 그 사이에 만든 코드는 이미 바뀌어버린 코드 위에 얹을 수가 없거든요. 동료가 "저 그거 구현했어요"라고 하니까 "왜? 무슨 정보 보고 한 거야?" 물었고, "2시간 전 정보요"라고 답하니까 "2시간 전? 그 사이에 우리가 결정을 6번이나 바꿨는데?" 이랬대요. 진짜 심각한 문제예요.

전통적인 계획 수립은 사라질 거라고요. 소프트웨어 자체가 곧 기획서이자 시제품이 되는 거죠. 테스트용 서버를 5개 띄워서 서로 다른 방향을 시도해보고, 4개를 버리는 식이요. 기획 문서를 돌려보는 시대는 끝나가고 있고, 아이디어에는 실제로 돌아가는 코드가 붙어야 하는 시대.

소프트웨어가 AI 시대에 살아남으려면 — 토큰을 아껴줘라

AI가 기존 소프트웨어를 하나씩 대체하고 있어요. Stack Overflow, Chegg, 콜센터 회사. 하나씩 사라지고 있죠.

Chegg 주가 5년 차트를 보면 $115에서 $2.82로 폭락했어요. AI가 숙제 도움 시장을 집어삼킨 사례죠. 코드 편집기들도 불안해하기 시작했고요.

살아남는 비결은 에너지 효율이래요. AI가 일할 때 드는 연산 비용을 아껴줄 수 있으면, AI가 그 제품을 쓸 거고, 그러면 살아남아요. AI는 본질적으로 게으르거든요. Anthropic이 AI가 곱셈을 어떻게 하는지 분석한 연구가 있는데, 정확히 계산하는 게 아니라 "대충 95 근처"라고 어림잡은 다음 정답표에서 정확한 값을 찾아요. 항상 최단 경로를 택한다는 거죠.

그래서 AI가 직접 하는 것보다 연산 비용을 아끼는 길을 만들어주는 도구가 살아남아요. 계산기, 데이터베이스, 저장소, 네트워크 같은 기본 인프라. Beads, Dolt, MongoDB, Kubernetes, Kafka 같은 것들이요. Serena라는 오픈소스 도구도 좋은 예인데, 코드 편집기의 분석 기능을 활용해서 AI가 파일을 하나하나 뒤지지 않고 이미 정리된 목차에서 바로 찾을 수 있게 해줘요.

다만 도구를 만드는 것만으로는 부족해요. AI한테 그 도구가 있다는 걸 알려줘야 하거든요. Notion이 OpenAI, Anthropic, Google과 직접 협력해서 AI가 자기 도구를 잘 쓰도록 학습시킨 것처럼요. 도구가 아무리 좋아도 AI가 모르면 못 쓰니까요. 극단적으로 가면 2년 뒤에는 폰에 앱이 하나만 남을 수도 있대요. Claude 하나로 다 되는 세상. 그때 살아남는 건 AI가 혼자서는 접근할 수 없는 데이터를 가진 곳, 아니면 AI보다 토큰을 아껴주는 도구를 가진 곳이에요.