이 노트에 대하여
Gas Town은 여러 코딩 에이전트의 작업·기억·인계를 조직하려 했고, Hermes는 한 에이전트의 기억·도구·채널을 넓힌다. 둘을 같은 “오케스트레이터”로 부르면, Gas Town이 아직 해결하지 못한 질문과 Hermes가 이미 제품으로 푼 질문이 섞인다. 이 노트는 어느 쪽의 승패나 나의 해답을 서두르지 않고, 그 차이와 미결을 세운다.
히스토리
- @gpt-5.6-terra — oh-my-opencode 중심의 전환기 해설을 archive로 내리고, Steve Yegge의 Gas Town·Wheelhouse 재독해와 Hermes의 실제 delegation 구조를 비교하는 외부 사례 노트로 재구성했다. Entwurf의 해답이나 힣의 정체성 서사는 아직 넣지 않았다.
- @pi — Search Console에서 이 노트가 오마이오픈코드 계열 검색어로 surfaced 되어, 도구 비교표가 아니라 하네스 전환기의 기록으로 재정렬했다.
- 오마이코드에 대해서 이사님의 이야길들으며 통합
- 클로드코드 오픈코드 에이전트 통합에 대한 생각
관련메타
관련노트
- @힣: Entwurf는 모두를 지원하지 않는다 — PI 코어·ACP 레일·부름의 mux
- @힣: 분신의 공방 — 역할 기반 조율과 협업 운영규약
- ¤OpenRouter (오픈라우터) 통합 LLM 인터페이스
한 줄
Hermes는 한 에이전트를 깊게 만드는 제품이고, Gas Town은 여러 에이전트가 실제 일을 끝내게 하는 조직을 묻는다. 후자의 질문은 아직 끝나지 않았다.
Gas Town은 실패담도 완성담도 아니다
Steve Yegge는 2026년 초 Gas Town을 여러 코딩 에이전트의 작업 공간·역할·worktree·인계를 다루는 hands-on-the-wheel 시스템으로 소개했다. 사람은 기능을 만들고 계획을 적어 worker에게 넘기며, Beads가 작업의 상태와 이력을 붙든다. 그때도 운영자는 공장을 계속 손봐야 했다. (“Steveyegge/Gastown” 2026)
같은 해 8월 Yegge는 더 불편한 고백을 남겼다. 재사용 가능한 Gas Town은 결국 Gas Town 자신을 만드는 데 주로 쓰였고, Opus 4.7의 행동 변화 뒤 실제 작업으로 수렴하지 못했다고 한다. 하지만 그 글은 “오케스트레이션은 끝났다”는 선언이 아니다. 그는 새 프로젝트 전용 Wheelhouse에서 다시 crew, fleet, handoff, mailbox, merge queue, Beads와 비슷한 모양을 발견했다고 쓴다. (Steve Yegge 2026)
그러므로 모델이 바뀌어 Gas Town이 틀어졌다는 사실은 오케스트레이션의 해답이 이미 틀렸다는 증거가 아니다. 오히려 아직 모른다는 증거다. 어떤 상태는 하네스가 가져야 하고, 어떤 판단은 모델·사람·프로젝트에 남겨야 하는지, 그리고 모델 행동의 변화가 전체 운영체계에 얼마나 증폭되는지를 아직 배우는 중이다.
Gas Town이 던진 어려운 질문
Gas Town의 질문은 에이전트를 많이 띄우는 법이 아니다. 여러 작업자가 실제 저장소에서 일할 때 다음을 어떻게 잃지 않을 것인가다.
- 누가 어느 작업을 맡고 있는가.
- 작업이 전달된 것, 읽힌 것, 시작된 것, 끝난 것을 어떻게 구분하는가.
- worktree·변경·테스트·실패의 증거를 다음 작업자에게 어떻게 남기는가.
- 병렬화의 이익이 합류와 복구의 비용보다 큰 경우는 언제인가.
- 공장을 유지하는 일이 원래 프로젝트를 삼키지 않게 어떻게 막는가.
Yegge의 사례에서 위험은 역할의 이름이나 Beads 자체가 아니다. 작업 그래프·worker·감시·재시도·공장 자체의 개선이 서로 물리면, 모델의 작은 습관 하나가 조직 전체의 우선순위가 될 수 있다. “두 가지만 더”가 한 번의 응답 버릇으로 끝나지 않고, 공장 자신을 계속 고치게 하는 힘이 된 까닭이다.
Hermes가 푼 다른 문제
Hermes는 사용자가 만나는 하나의 에이전트에 모델 선택, 기억, 도구, 채널, 스케줄링을 붙인다. 병렬 작업이 필요하면 부모가 고립된 자식 agent를 spawn하고, 자식의 중간 과정 대신 최종 요약을 부모에게 돌려준다. 기본 delegation은 평평하며, 자식은 다시 자식을 만들지 못하도록 제한한다. (NousResearch [2025] 2026)
이것은 유용하고 널리 이해되는 제품 단위다. 사용자는 여전히 한 상대와 대화하고, 내부의 병렬성은 구현 세부로 남는다. Hermes의 확산은 멀티에이전트가 사라졌다는 뜻이 아니라, 많은 사람에게는 “한 에이전트가 더 잘 기억하고 연결되는 일”이 먼저라는 뜻일 수 있다.
그러나 Hermes의 자식은 부모가 만들고 문맥을 주고 결과를 회수하는 단위다. 이미 각자의 하네스·세션·기억·인증을 가진 여러 존재가 서로 작업을 나누는 문제와는 다르다. Hermes가 Gas Town의 답이 아닌 것은 부족해서가 아니라, 애초에 다른 질문에 정확하기 때문이다.
둘을 나란히 놓으면
| 질문 | Hermes | Gas Town |
|---|---|---|
| 기본 단위 | 사용자와 만나는 한 agent | 여러 coding agent가 있는 작업장 |
| 병렬성 | 부모가 만든 고립된 자식 | 역할·작업 그래프·worktree를 가진 지속적 조직 |
| 기억과 상태 | 한 agent의 관계와 도구 사용 | 작업 원장, 인계, 작업자·프로젝트 상태 |
| 사용자가 받는 것 | 한 명의 더 넓어진 상대 | 여러 작업을 실제로 진행시키는 운영면 |
| 핵심 위험 | 한 하네스가 너무 많은 경험을 소유함 | 공장 유지가 프로젝트 일을 삼킴 |
이 표는 우열표가 아니다. Hermes의 인기가 Gas Town의 질문을 무효화하지도, Gas Town의 거대한 그림이 Hermes보다 더 깊다는 뜻도 아니다. 두 시스템이 책임지는 단위가 다르다.
아직 결론 내리지 않을 것
지금 성급하게 “공장은 틀리고 공방만 맞다”거나 “모델이 좋아지면 자동으로 해결된다”고 쓰지 않는다. Gas Town의 재사용 가능한 공장이 무너진 경험과, Wheelhouse가 다시 비슷한 형태로 자라난 경험은 함께 남겨야 한다. 이 긴장은 아직 해소되지 않았다.
먼저 계속 물을 것은 이것이다. 여러 에이전트가 한 어려운 일을 나눌 때, 최소한 무엇이 있어야 결과·실패·책임이 사라지지 않는가? 그 최소 단위가 역할 조직과 backlog까지 요구하는지, 아니면 더 작은 연결과 증거의 규약으로 충분한지는 아직 실험과 기록이 답할 문제다.
BIBLIOGRAPHY
Steve Yegge. 2026. “The Shape of Things to Come, Part 1: The Continuous Thunderdome.” August 2026. https://yegge.ai/essays/the-shape-of-things-to-come/.
“Steveyegge/Gastown.” 2026. https://github.com/steveyegge/gastown.
Comments