Gas City v1.0: “에이전트 공장”을 SDK로 조립하는 시대가 왔어요

에이전트를 한두 개 붙여 자동화해봤는데, 지속 운영(24×7)·감사(audit)·버전 관리까지 가려니 갑자기 난이도가 확 올라가죠.
Steve Yegge가 소개한 Gas City는 그 지점을 정면으로 해결하려는, “다크 팩토리(dark factory)”를 만드는 오케스트레이션 SDK예요.

1) Gas City는 무엇이 달라졌나: Gas Town의 “SDK화”

Gas City는 기존 Gas Town을 뜯어고쳐, 에이전트 팀을 만드는 구성요소를 조립 가능한 SDK 형태로 바꾼 프로젝트예요. 핵심은 기존처럼 “정해진 팀 형태”를 쓰는 게 아니라, 원하는 작업 흐름에 맞춰 임의의 에이전트 토폴로지(구성) 를 선언적으로 만들 수 있다는 점이에요.

또 흥미로운 건, Gas City가 처음부터 “완전히 새로운 것”으로 시작한 게 아니라는 점인데요. 기본으로 Gas Town을 그대로 복제한 ‘Gas Town pack’ 을 포함해서, 시작하자마자 드롭인 대체재(drop-in replacement) 처럼 쓸 수 있어요. 기존 rigs와 beads도 가져올 수 있다고 하니, 이사 비용을 크게 줄이려는 설계가 보입니다.

2) Packs(팩)과 Supervisor Plane: 팀을 “배포 가능한 단위”로 만든다

Gas City의 핵심 단위가 “pack(팩)” 이에요. 팩은 에이전트들의 정체성(identity)·역할(role)·스킬(skills)·페르소나(persona)·상태(state)·메시징(messaging) 같은 것들을 묶어서, 하나의 “미니 공장”처럼 배포하는 방식이죠.

이 팩들을 실제로 굴려주는 상위 계층이 Gas City의 Supervisor Plane(감독/관리 평면) 이에요. 쉽게 말해 “에이전트 팀을 띄우고, 연결하고, 조정하고, 관찰할 수 있게 해주는 운영 레이어”라고 보면 됩니다. 콘솔에서 확인할 수도 있고, 원하면 tmux 같은 터미널 중심 환경도 유지된다고 해요. 이런 구조는 에이전트를 ‘실험용 스크립트’가 아니라 운영 가능한 워커(worker) 로 다루고 싶은 팀에 특히 유용합니다.

3) MEOW + Dolt: 작업을 ‘기억’하고 ‘감사’하는 스택

기사에서 계속 강조되는 기반 스택이 MEOW와 Dolt예요. MEOW는 “Work(작업)”을 시스템의 1급 객체로 두고, 이슈/태스크를 버전되는 지식 그래프(knowledge graph) 로 만든다고 설명합니다. 그리고 그 밑단에서 Dolt(깃 버전 관리가 되는 데이터베이스) 가 받쳐줘요.

이 조합이 왜 중요하냐면, 에이전트는 필연적으로 환각(hallucination)·거짓 기억·망각을 일으킬 수 있고, 그 순간 운영 자동화는 “왜 그렇게 결정했는지”를 추적할 수 있어야 하거든요. Gas City는 에이전트의 모든 행동을 DB에 남길 뿐 아니라 깃 히스토리까지 가져가서, 포렌식(forensics)과 감사 추적에서 강점을 만든다는 주장입니다. 즉, “자동화가 늘수록 통제력이 떨어진다”는 공포를 로그/버전/메모리로 상쇄하려는 거예요.

4) Dark Factory가 아니라 “Light Factory”: 관찰가능성을 기본값으로

요즘 유행하는 “다크 팩토리”는 사람이 지켜보지 않는 자동화를 뜻하지만, Yegge는 이 용어가 오해를 부른다고 짚어요. 중요한 건 “어두움”이 아니라 백그라운드에서 돌아가되, 원하면 언제든 들여다볼 수 있는가(Observability, 관찰가능성) 입니다.

Gas City의 방향은 명확하게 Lights On 쪽이에요. 모든 워커가 동등하게 보이고(addressable) 접근 가능하도록 설계됐고, 원하면 언제든 특정 워커에게 말을 걸 수 있어요. 소비자 제품(예: Claude Code)이 단순함을 위해 일부를 “의도적으로 가린다”는 비교도 나오는데, Gas City는 반대로 운영/엔터프라이즈에서 필요한 “통제 가능한 투명성”을 밀어붙이는 인상입니다.

5) 왜 멀티 에이전트가 기본값인가: “한 명이 미치면” 끝이니까요

이 글에서 꽤 강한 메시지 중 하나가 이거예요: 실제 비즈니스 프로세스에 단일 에이전트 배포는 거의 금물이라는 것. 이유는 단순합니다. 어떤 모델이든 언제든 비정상 판단을 할 수 있고(환각/망각은 구조적으로 피하기 어렵고), 운영 시스템에서 한 번의 오판은 그대로 사고가 되거든요.

그래서 Gas City는 멀티 에이전트가 서로를 감시하는 적대적/상호검증 구조(adversarial group structure) 를 쉽게 만들 수 있게 합니다. 예를 들어 하나가 추천하면 다른 하나가 검증하고 실행하는 식이죠. “신뢰성(reliability)은 다이얼”이라는 표현처럼, 리뷰 라운드·가드레일(guardrails)·백스톱(backstops)·저지(judges) 를 추가해 원하는 수준까지 끌어올리는 접근입니다. 대신 의료/항법처럼 물리적 피해가 가능한 영역엔 2026년 기준으로는 선을 긋고 있어요.

6) 실제 사용 시나리오: SaaS를 ‘한 입씩’ 대체하는 방법

후반부는 꽤 도발적이에요. SaaS 피라미드의 아래쪽부터 “분해(disintegrating)” 가 시작되고 있고, 어떤 기업에서는 비기술 조직조차 연 $3만짜리 SaaS를 Gas Town 기반으로 인하우스 재구축 중이라는 사례가 나옵니다. 여기서 관점이 재밌는데, SaaS는 결국 모든 고객의 요구를 합친 기능 과잉의 집합이 되고, 대부분의 고객은 20%만 쓰면서 80%를 보조금처럼 부담한다는 주장입니다.

그래서 “Salesforce 전체”를 만들 필요가 아니라, 우리 조직이 쓰는 그 20%만 만들면 된다는 논리로 이어져요. 이때 결정적 병목이 “기능 개발”이 아니라 운영에 필요한 선언적 배포(declarative deploys)·감사 추적·정체성·버전 히스토리·지속 메모리 같은 ‘안 멋있지만 필수인 것들’인데, Gas City가 바로 그 프리미티브(primitives)를 제공한다는 거죠. 현실적인 그림으로는 3~5명의 엔지니어 + Gas City 팩 운영으로 7-figure(수백만 달러) SaaS 비용을 대체할 수 있다고까지 말합니다. 물론 그만큼 보안/컴플라이언스/가용성의 책임을 가져오지만, 규모에 맞는 수준으로 최적화할 수 있다는 주장도 곁들여요.

써볼 만한 접근을 하나 제안하면 이래요.

• 고객지원/승인/정산 같은 “사람이 반복적으로 처리하는 큐(queue)”를 하나 고른다
• pack을 2인 1조(처리자+검증자) 로 구성한다
• 처리 기록을 MEOW/Dolt로 남겨 ‘왜 그렇게 처리했는지’ 를 나중에 재현 가능하게 만든다
• 성과가 보이면, 다음 큐로 확장한다(“코끼리를 한 입씩 먹기”)

마무리: 자동화의 다음 과제는 “속도”가 아니라 운영 가능성이에요

Gas City가 던지는 메시지는 명확해요. 에이전트가 일을 하게 만드는 건 이제 어렵지 않고, 진짜 차이는 지속 운영·관찰가능성·감사·버전 관리·신뢰성 다이얼 같은 “운영의 기본기”에서 난다는 거죠.

만약 요즘 사내에서 “에이전트로 업무 자동화는 되겠는데, 이걸 프로덕션에 올리면 누가 책임지지?” 같은 대화가 나오고 있다면, Gas City를 한 번 관찰해볼 타이밍이에요. 오늘 바로 할 수 있는 한 가지는, 우리 팀이 매달 돈 내는 SaaS 중에서 “우리가 실제로 쓰는 20%”가 뭔지 목록부터 뽑아보는 겁니다. 그 20%가 다음 자동화 팩의 후보가 될 수 있어요.