가스 타운의 에이전트 패턴, 디자인 병목, 그리고 대규모 바이브코딩

게시일: 2026년 1월 24일 | 원문 작성일: 2026년 1월 23일 | 저자: Maggie Appleton | 원문 보기

• • •

Steve Yegge의 Gas Town

몇 주 전 Steve Yegge1가 Gas Town에 대한 정교한 선언문과 가이드를 발표했어요. 매드맥스, 슬로우 호시즈, 워터월드2 등에서 테마를 빌려온 에이전트 오케스트레이터(agent orchestrator)로, 수십 개의 코딩 에이전트를 동시에 실행하는 비유적인 자동화 도시예요. Gas Town은 전부 바이브코딩(vibecoding)3으로 만들어졌고, 즉흥적인 해결책으로 급하게 설계됐으며, 매달 수천 달러의 API 비용을 비효율적으로 태우고 있어요.

별로 유망해 보이지 않지만, 소프트웨어 엔지니어링 커뮤니티 전반에 걸쳐 뜨거운 논쟁과 변화의 불씨를 일으켰어요. 소규모 하이프 머신이 형성됐죠. 거의 모든 엔지니어링 팀의 Slack을 두 번은 돌았을 거예요. 어째서인지 벌써 $GAS 밈코인이 생겨서 40만 달러 이상의 수익을 올리고 있어요. Yegge가 만든 게 아니라 다른 사람이 크리에이터 개인에 토큰을 연결하는 크립토 플랫폼 Bags4에서 세팅한 거예요. 이 코인은 Gas Town의 성공이나 실패와 아무런 관계가 없으니, 순수한 투기적 베팅이에요. 크립토 브로들답죠, 뭐.

그리고 이 하이프는 정당해요. 첫째, 완전히 정신 나간 물건이기 때문이고, 둘째, 에이전트가 앞으로 소프트웨어 개발의 본질을 어떻게 바꿀지 보여주는 진지한 신호이기 때문이에요.

제 소감을 읽기 전에 최소한 Yegge의 원문을 훑어보는 걸 추천해요. 첫째, 저는 그 글을 종합적으로 요약할 생각이 없어요 — 방대하고 종잡을 수 없는 글이라 요약 자체가 만만찮은 일이거든요. 둘째, Yegge의 글쓰기 스타일을 1분만 훑어봐도 분위기가 확실히 전해질 거예요.

Yegge의 창작물을 진지하게 받아들여야 하는 이유는, 이것이 오늘날 개발자를 위한 진지하고 실용적인 도구이기 때문이 아니에요(아니거든요). 이것은 도발적인 질문을 던지고, 에이전트 코딩 시스템이 성숙하고 성장할 때 우리가 직면할 제약의 형태를 드러내는 좋은 사변적 디자인 픽션(speculative design fiction)이기 때문이에요.

• • •

Yegge는 칭찬받을 자격이 있다

비효율성과 혼란에도 불구하고, Yegge가 주체적으로 이런 시스템에 도전하고 실제로 만들어본 점은 칭찬받아 마땅해요. 게다가 형편없는 4분의 1짜리 비행기가 날고 있는 와중에 공개 투어까지 진행하고 있잖아요.

어릴 때 테이트 모던(Tate Modern)5에 가면 Mark Rothko6 작품을 가리키며 엄마에게 “나도 저거 할 수 있어”라고 했고, 엄마는 항상 “그래, 근데 안 했잖아”라고 대답했어요. 많은 사람들이 대규모 자동화된 에이전트 오케스트레이션 시스템이 몇 년 뒤 어떤 모습일지 이야기했지만, 아무도 진지하게 만들어보려 하지 않았어요.

솔직히 말하면, 저는 Gas Town을 어떤 진지한 작업에도 본격적으로 사용해보지 않았어요. 가볍게 살펴본 정도예요. Yegge의 자동화 8단계에서 아직 4-6단계를 맴돌고 있는 저는 진지한 사용자라고 할 수 없거든요.

저는 현재 Claude Code와 OpenCode 에이전트 몇 개를 번갈아 사용하면서도, diff를 주의 깊게 살피고 IDE에서 코드를 정기적으로 확인해요. 무섭도록 빠르게 돌아가는 이 시대에 저를 에이전트 보수파 진영에 넣을 수 있을 거예요. Gas Town은 완전한 8단계 도구예요 — 수십 개 이상의 코딩 에이전트를 관리하는 오케스트레이터를 사용하는 거죠.

Yegge도 저에게 Gas Town을 진지하게 사용하지 말라고 여러 번 경고했어요. 점점 더 위협적인 타이포그래피로요. 자기 날것 더미에 대한 본인 판단은 믿어요.

하지만 기본 개념은 파악했고, 이 선언문에 합당한 것 이상의 시간을 보냈어요. 제가 이해할 수 있었던 부분에서 눈에 띄었던 것들을 정리해볼게요.

• • •

1. 에이전트가 코드를 쓰면, 디자인이 병목이 된다

에이전트 무리가 코드 태스크를 처리하고 있으면, 개발 시간은 더 이상 병목이 아니에요. Yegge는 이렇게 말해요: “Gas Town은 구현 계획을 너무 빨리 처리해서 엔진에 먹일 설계와 기획을 엄청나게 많이 해야 해요.”

디자인이 제한 요소가 돼요 — 무엇을 만들고 싶은지 상상하고, 상상을 현실로 만드는 데 필요한 복잡한 세부사항을 전부 파악하는 일이요.

저도 직업적인 작업과 개인 프로젝트 양쪽에서 이 마찰을 확실히 느끼고 있어요. 에이전트 몇 개만 다루고 코드를 직접 보는 제 개발 속도는 Yegge보다 훨씬 느리지만, 빌드 시간이 저를 막는 일은 거의 없어요. 항상 디자인이 문제예요. 이걸 어떻게 설계해야 하지? 이건 어떤 느낌이어야 하지? 이건 어떻게 보여야 하지? 이 전환이 충분히 미묘한가? 이게 올바른 메타포인가?

디자인이 아닐 때는 제품 전략과 기획이에요. 가장 우선순위 높은 기능은 뭐지? 어느 부분을 먼저 만들어야 하지? 다음 논리적이고 점진적인 단계는 뭐지? 이런 종류의 결정은 에이전트가 대신할 수 없어요. 여러분의 인간적 맥락, 취향, 선호, 비전이 필요하거든요.

에이전트가 곁에 있으면 쉽게 앞서나가게 돼요. 존재해서는 안 되는 생성된 함수 더미 속으로 비틀거리며 전진하는 거죠 — 그것들이 여러분의 의도를 정확히 구현하지도, 목표를 달성하지도 못하는데 말이에요.

Gas Town은 이 함정에 반쯤 빠져 있어요. Yegge의 창작물에서 가장 큰 결함은 형편없이 설계됐다는 거예요. 이 시스템의 형태를 미리 설계하지 않았어요. 어떤 메타포와 기본 요소가 효과적이고 효율적이며 사용하기 쉬운 시스템을 만들지, 신중하게 고려한 적이 없었다는 거예요. 그냥 진행하면서 만들어갔죠. 본인도 인정해요: “Gas Town은 복잡해요. 제가 원해서가 아니라, 자립하는 기계가 될 때까지 부품을 계속 추가해야 했으니까요.”

Gas Town은 “특히 이해하기 어려운 이론들로 구성돼 있는데, 지난 3주 동안 제 엉덩이에서 끌어낸 헛소리 묶음이고, 오소리 같은 이름을 붙인 것들”이에요. “17일, 75,000줄의 코드, 2,000개 커밋” 만에 급조됐죠.

Hacker News7의 qcnguy가 이 문제를 잘 짚었어요. Gas Town의 전신인 Yegge의 Beads 프로젝트도 같은 문제를 겪는다고 지적하면서요:

Bluesky8에서 astrra.space의 리뷰도 비슷해요:

Gas Town을 좀 더 깊이 시도해본 용감한 친구들과 동료들도 같은 말을 해요 — 이 물건은 Yegge의 뇌 형태에 맞고, 다른 누구에게도 안 맞는다고요. 이건 다른 사람들도 시도해보길 바라는 공개 제품치고는 상당한 디자인 실패예요. 온보딩 자체가 시련이거든요 — 그야말로 불구덩이에 던져지는 수준이에요.

이건 무분별하게 방임적인 에이전트 개발에서 떠오르는 가장 치명적인 함정 중 하나인 것 같아요. 너무 빨리 움직여서 멈추고 생각할 시간이 없어요. 프롬프트하기가 너무 쉬워서, 빌드하는 각 단계에서 뭘 만들고 있는지 충분히 고려하지 않게 돼요. 형편없는 아키텍처 결정, 해독 불가능한 버그, 애초에 뭘 하려고 했는지에 대한 흐릿한 기억 속에 허리까지 잠겨서야 깨닫게 돼요 — 10억 개의 토큰을 날리고 손에 쥔 건 쓰레기 한 무더기뿐이라고요.

• • •

2. 혼란 속에 미래 에이전트 오케스트레이션 패턴의 스케치가 숨어있다

Gas Town의 디자인을 비판해놓고 이제 와서 이런 말을 하긴 좀 그렇지만, 현재의 족제비(polecats), 호송대(convoys), 집사(deacons), 분자(molecules), 원시분자(protomolecules), 시장(mayors), 강신회(seances), 훅(hooks), 구슬(beads), 감시자(witnesses), 위습(wisps), 리그(rigs), 정유소(refineries), 그리고 개(dogs)의 뒤죽박죽은 설익은 스파게티이지만, Yegge의 패턴들은 미래 에이전트 시스템을 위한 유용한 개념적 형태를 대략 스케치하고 있어요.

한 발짝 물러서서 눈을 가늘게 뜨고 보면, 이 개념들의 혼합물 속에서 미래 에이전트 시스템이 따를 법한 몇 가지 기저 패턴이 드러나요.

2a. 계층적 감독을 갖춘 전문화된 역할

Gas Town의 모든 에이전트는 영구적이고 전문화된 역할을 가지고 있어요. 에이전트가 새 세션을 시작하면, 자신이 누구인지와 어떤 일을 해야 하는지 알고 있어요. 몇 가지 예를 들면:

• 시장(Mayor)은 인간의 컨시어지예요 — 여러분이 대화하는 주요 에이전트죠. 다른 모든 에이전트와 소통해서, 작업을 시작하고, 완료 알림을 받고, 생산 흐름을 관리해요
• 족제비(Polecats)는 임시 막노동꾼이에요. 단일하고 격리된 태스크를 완료한 뒤, 작업물을 머지용으로 제출하고 사라져요
• 감시자(Witness)는 족제비들을 감독하고 막힌 곳을 풀어줘요. 문제를 해결하고 프롤레타리아 노동자들을 떠밀어 일하게 하는 게 임무예요
• 정유소(Refinery)는 메인 브랜치로의 머지 큐를 관리해요. 머지 대기 중인 각 작업을 평가하고, 과정에서 충돌을 해결해요. 머지 충돌이 너무 복잡해지면 원래 작업의 의도를 유지하면서 구현을 창의적으로 “재구상”할 수도 있어요

이 도시에는 더 많은 캐릭터가 있지만, 이 정도면 시스템의 맛은 느낄 수 있을 거예요. 각 에이전트에 단일 업무를 부여하면 더 정확하게 프롬프트할 수 있고, 건드릴 수 있는 범위를 제한할 수 있고, 서로 발을 밟지 않으면서 많은 수를 동시에 실행할 수 있어요.

이 에이전트들 사이에 명확한 지휘 체계가 있어요. 시장은 코드를 직접 쓰지 않아요. 여러분과 대화한 뒤, 작업 태스크를 만들어 워커에게 할당해요. 감시자, 집사(Deacon), 그리고 “부트 더 독(Boot the Dog)“이라는 시스템 감독관들이 간헐적으로 노동자들을 찔러보고, 감독관끼리도 서로 찔러보면서 모두가 일하고 있는지 확인해요. 아, 그리고 유지보수와 청소를 하는 “개(dogs)” 크루도 있어요.

참고로, Yegge가 Gas Town의 아키텍처와 워크플로우에 대한 정교한 동물형 다이어그램을 많이 만들었지만, 별 도움이 안 돼요. 전부 Gemini의 Nano Banana로 만들어졌기 때문이에요. Nano Banana는 다이어그램 제작에서 최첨단이지만, 생성형 AI 시스템은 아직 설명적 다이어그램을 만드는 데 정말 서투러요. 해독하기 어렵고, 어수선한 디테일로 가득하고, 화살표가 잘못된 방향을 가리키고, 핵심 정보가 빠져있는 경우가 많아요.

Gas Town의 계층적 접근법은 조정과 주의력 문제를 동시에 해결해요. 이것 없이는 수십 개의 개별 에이전트에 태스크를 할당하고, 누가 막혀있고, 누가 놀고 있고, 누가 다른 에이전트의 작업을 기다리는지 직접 확인해야 해요. 시장을 단일 인터페이스로 두면 그 오버헤드가 사라져요. Claude 탭을 이리저리 전환하는 것보다 훨씬 머리가 편해요.

여기서 캐릭터 구성을 다양화하고 전문 서브에이전트(specialist subagent)를 더 활용할 기회가 많다고 봐요. Gas Town의 에이전트는 모두 소프트웨어 개발 파이프라인의 제너럴리스트 워커예요. 하지만 원하는 종류의 전문가를 추가할 수 있어요 — 데브옵스 전문가, 프로덕트 매니저, 프론트엔드 디버거, 접근성 검사기, 문서 작성자 등. 이들은 특수 스킬과 도구를 적용하기 위해 온디맨드로 호출될 거예요.

2b. 에이전트 역할과 태스크는 영속적, 세션은 일시적

현재 코딩 에이전트의 주요 한계 중 하나는 컨텍스트가 소진된다는 거예요. 컨텍스트 윈도우의 한계에 도달하기도 전에, 컨텍스트 부식(context rot)9이 출력 품질을 떨어뜨려서 계속 유지할 가치가 없어져요. 끊임없이 압축하거나 새 세션을 시작해야 하죠.

Gas Town의 해결책은 각 에이전트 세션을 의도적으로 일회용으로 만드는 거예요. 중요한 정보 — 에이전트 정체성과 태스크 — 를 Git에 저장한 뒤, 세션을 과감하게 종료하고 필요할 때 새 세션을 시작해요. 새 세션은 자신의 정체성과 현재 할당된 작업을 전달받고, 이전 세션이 멈춘 곳에서 계속해요.

Gas Town은 또한 새 세션이 전임자에게 무슨 일이 있었는지 물어볼 수 있는 “강신술(seancing)“를 지원해요 — 마지막 세션을 별도 인스턴스로 재개해서 새 에이전트가 미완료 작업에 대해 질문할 수 있게 하는 거예요.

이 저장과 호출은 모두 Gas Town의 “비즈(Beads)” 시스템을 통해 이루어져요. 비즈는 Yegge가 Gas Town 이전에 만든 메모리 관리 시스템의 이름이기도 해요. 비즈는 작고 추적 가능한 작업 단위로 — 이슈 트래커의 이슈 같은 거예요 — 코드 옆에 JSON으로 Git에 저장돼요. 각 비즈는 ID, 설명, 상태, 담당자를 가지고 있어요. 에이전트 정체성도 비즈로 저장되어, 각 워커에게 세션 크래시에서 살아남는 영구 주소를 부여해요.

Yegge가 이 패턴을 발명한 건 아니에요 — 에이전트 메모리 외부의 구조화된 형식(JSON 같은)으로 원자적 태스크를 추적하는 거요. Anthropic이 2025년 11월에 발표한 장기 실행 에이전트를 위한 효과적인 하네스에 대한 연구에서 같은 접근법을 설명했어요. 이런 종류의 태스크 추적이 Claude Code에 탑재되기까지 그리 오래 걸리지 않을 거예요.

2c. 에이전트에게 지속적인 작업 스트림 공급하기

Gas Town 같은 오케스트레이션 시스템의 핵심 약속은 영구기관이라는 거예요. 시장에게 고수준 명령을 내리면, 동물원 같은 에이전트들이 태스크 분해, 할당, 실행, 버그 확인, 버그 수정, 코드 리뷰, 머지까지 해줘요.

Gas Town의 각 워커 에이전트는 자체 작업 큐와 현재 해야 할 일을 가리키는 “훅(hook)“을 가지고 있어요. 태스크를 끝내는 순간 다음 태스크가 큐 앞으로 올라와요. 시장이 이 큐를 채우는 역할을 해요 — 큰 기능을 원자적 태스크로 분해하고 가용 워커에게 할당하죠.

”워커는 항상 일한다”는 원칙은 말이 좋지, 실제로는 잘 안 돼요. 현재 모델이 훈련되는 방식 때문에 구현하기가 살짝 어렵거든요. 모델은 인간의 지시를 공손하게 기다리는 도움이 되는 어시스턴트로 설계되어 있어요. 태스크 큐를 확인하고 독립적으로 일을 처리하는 데 익숙하지 않아요.

Gas Town의 임시방편적 해결책은 공격적인 프롬프팅과 끊임없는 독촉(nudging)이에요. 감독 에이전트가 워커를 찔러서 멈추거나 일이 떨어진 애가 있는지 확인해요. 조용해진 워커에게 핑을 보내면, 에이전트가 깜짝 놀라 큐를 확인하고 다시 일을 시작해요. 이 주기적인 독촉이 에이전트 계층을 통해 심장 박동(heartbeat)처럼 타고 퍼지며 모든 것을 움직여요.

첫 버전의 임시방편으로는 괜찮지만, 본격적인 에이전트 오케스트레이션 시스템은 에이전트를 태스크에 집중시키는 신뢰할 수 있는 방법이 필요할 거예요.

2d. 머지 큐와 에이전트가 관리하는 충돌

에이전트 여러 개가 병렬로 작업하면, 당연히 머지 충돌이 터져요. 각 에이전트가 자기 브랜치에서 일하는데, 태스크를 끝낼 즈음이면 메인 브랜치가 완전히 달라져 있을 수 있거든요. 늦게 끝나는 에이전트일수록 상황은 더 나빠져요.

보통은 인간인 여러분이 뒤처리를 하고 어떤 변경을 살릴지 결정하는 부담을 져요. 하지만 에이전트가 자율적으로 돌아가면, 누군가가 그 역할을 해줘야 해요. 그래서 Gas Town에는 전담 머지 에이전트인 정유소(Refinery)가 있어서, 머지 큐를 하나씩 처리해요. 충돌이 너무 꼬여서 원래 작업이 더 이상 맞지 않으면, 변경사항을 창의적으로 “재구상”할 수 있어요. 필요하면 인간에게 에스컬레이션하기도 하고요.

하지만 머지 충돌의 악몽을 피하는 다른 방법이 있어요 — Gas Town에는 내장되어 있지 않지만요: PR을 버리고 스택드 디프(stacked diffs)10로 가는 거예요. 전통적인 git 워크플로우는 각 기능을 며칠이나 몇 주 동안 자체 브랜치에 두고, 커밋을 쌓다가, 하나의 육중한 PR로 머지해요. 스택드 디프는 작업을 작고 원자적인 변경사항으로 분해해서, 각각 독립적으로 리뷰되고 머지되며, 서로 위에 쌓이는 방식이에요.

이건 에이전트가 자연스럽게 작업하는 방식과 맞아요. 에이전트는 이미 며칠에 걸친 거대한 브랜치가 아닌 작고 집중된 변경사항을 생산하고 있거든요. 충돌이 발생해도 각 디프가 건드리는 코드가 적으니 해결하기 쉬워요.

Cursor의 최근 Graphite11 인수 — 스택드 디프 워크플로우 전용 도구 — 는 이 기회를 보는 사람이 저만이 아니라는 걸 시사해요. 수십 개의 에이전트가 지속적으로 변경사항을 랜딩할 때, 이런 빈번하고 점진적인 머지에 특화된 도구와 인터페이스가 필요해요.

• • •

3. 비용은 극도로 높지만, (잠재적) 가치도 그렇다

Yegge는 Gas Town이 “미칠 듯이 비싸다… 돈이 어디서 오는지 잠깐이라도 생각해야 한다면 Gas Town이 마음에 안 들 거예요”라고 묘사해요. Anthropic의 계정당 지출 한도를 우회하기 위해 두 번째 Claude 계정을 쓰고 있어요.

보수적으로 한 달에 최소 2,000달러, 넉넉하게는 5,000달러를 쓰고 있다고 추정할 수 있어요. 현재 $GAS 크립토코인의 거래 수수료로 벌어들인 75,000달러가 이걸 감당하고 있어서, 이 규모로 넉넉히 1년은 돌릴 수 있어요.

현재 비용은 거의 확실히 시스템 비효율성 때문에 인위적으로 부풀려져 있어요. 작업이 유실되고, 버그가 여러 번 수정되고, 디자인이 사라져서 다시 해야 하거든요. 모델이 개선되고 오케스트레이션 패턴이 성숙해지면, 이런 오케스트레이터의 비용은 떨어지면서 출력 품질은 올라갈 거예요.

Gas Town이 진정으로 시니어 개발자의 작업을 2-3배 이상 가속화할 수 있다면, 연봉의 10-30%는 쉽게 정당화돼요. 유의미한 작업 한 단위의 비용이 사람을 고용하는 것과 견줄 만해지기 시작해요.

이게 터무니없게 들릴 수도 있어요. 우리 모두 주요 공급자들의 무제한 사용 월 100-200달러라는 인위적으로 낮은 가격에 기준점이 고정돼 있으니까요. 하지만 AI 버블이 터지고, VC 자금이 마르고, AI 업체들이 대규모 추론의 실제 비용을 매길 수밖에 없을 때, 그 “무제한” 티어가 훨씬 비싸질 거라고 예상해야 해요.

이런 도구에 투자하는 수학은 미국이나 서유럽 일부처럼 부유한 곳에서는 이미 방어 가능해요. 개발자 연봉이 낮은 지역에서는 AI 보조 도구에 대한 예산도 그에 맞게 조정될 거예요 — 대규모 자동화보다는 AI를 보수적으로 활용하면서, AI가 못하는 판단은 사람이 직접 메우는 형태가 되겠죠.

• • •

4. Yegge는 코드를 절대 안 본다. 우리도 언제쯤 안 봐도 될까?

Yegge는 이 프로젝트에서 바이브코딩의 진정한 정의를 실천하고 있어요: “이건 100% 바이브코딩이에요. 코드를 본 적도 없고, 볼 생각도 없어요.”

2026년 1월 현재, 코드를 아예 안 보는 건 매우 대담한 제안이에요. 현재 모델의 상태와 그 주변의 빈약한 안전장치를 고려하면, 우리 대다수는 이런 맹목적 코딩 접근법을 무책임하고 무모하다고 볼 거예요 — 버려도 되는 사이드 프로젝트가 아닌 이상은요. Yegge가 들인 노력과 Claude 토큰의 양, 문서 작성, 공개 홍보를 고려하면, Gas Town은 버려도 되는 프로젝트가 아니에요.

”개발자가 여전히 코드를 봐야 하는가?”는 앞으로 몇 년간 가장 첨예하고 뜨거운 논쟁 중 하나가 될 거예요. 질문 자체가 터무니없다고 느끼실 수도 있어요. 하지만 진지한 질문이고, 답은 여러분이 생각하는 것보다 빨리 변할 거예요.

사람들이 이 질문에 답하려 하면서 도덕적이고 개인적 정체성의 선을 따라 나뉘는 걸 이미 보고 있어요. 어떤 사람들은 모든 diff를 확인하고 특정 줄을 직접 수정하는 순수주의자, AI 회의론자, “진정한 개발자(Real Developer)“임을 선언하며, 에이전트를 자유롭게 풀어놓는 사람을 경멸해요. 반면 다른 사람들은 에이전트 맥시멀리즘(agentic maximalism)에 기대어, 위에서 내려다보며 함대를 지휘하고, 아직도 2019년처럼 수동 편집에 끙끙대는 러다이트 무리를 불쌍히 여기죠.

양쪽 모두 상황에 따라 달라지는 판단을 성격 특성이자 확고한 도덕적 입장으로 착각하고 있어요.

더 보수적이고 고려하기 쉬운 논쟁은 이거예요: 에이전트 소프트웨어 개발 도구에서 코드가 얼마나 가까이 있어야 할까? 접근하기가 얼마나 쉬워야 할까? 개발자가 직접 편집하는 빈도는 어느 정도를 기대해야 할까?

Claude Code, Cursor, Conductor 같은 인터페이스는 코드를 경험의 중심에 놓지 않아요. 에이전트가 여러분의 첫 번째이자 주요 인터페이스예요. diff가 흘러가거나 코드 파일이 인라인으로 보일 수 있지만, 직접 만질 수는 없어요. 코드를 직접 편집하려면 IDE를 열고 올바른 파일과 줄로 이동하는 우회로를 거쳐야 해요. 이 디자인은 에이전트에게 변경을 요청하는 것이 직접 구문을 타이핑하는 것보다 쉽다고 가정해요.

이 논쟁을 이것 아니면 저것으로 프레이밍하는 건 — 코드를 보거나 안 보거나, 직접 편집하거나 에이전트만 지시하거나, 반-AI 순수주의자이거나 에이전트 맥시멀리스트이거나 — 도움이 안 돼요. 엄격한 이분법은 없으니까요. 적절한 거리는 여러분이 어떤 사람인지나 AI 역량에 대해 뭘 믿는지의 문제가 아니에요. 코드에서 얼마나 손을 떼느냐는 무엇을 만들고 있는지, 누구와 만들고 있는지, 잘못됐을 때 어떤 결과가 따르는지에 따라 달라져요.

에이전트에 넘기는 자유도는 다음 요소들에 달려 있어요:

도메인과 프로그래밍 언어 — 프론트엔드 대 백엔드는 큰 차이예요. 이징 커브를 디자인하거나 미적 느낌을 말로 전달하기엔 언어가 역부족이거든요 — 저는 항상 CSS를 직접 만져야 하고, 원하는 걸 설명하느니 직접 조정하는 게 더 빠를 때가 많아요. Yegge의 CLI 도구는 통과/실패 테스트로 훨씬 쉽게 검증할 수 있어요. 모델 역량도 언어마다 크게 달라요 — React와 Tailwind를 프롬프트하면 Rust나 Haskell보다 훨씬 좋은 결과가 나와요. Rust와 Haskell에서는 모델이 아직 빌림 검사기(borrow checker)와 타입 시스템에서 정기적으로 막혀요.

피드백 루프와 성공의 정의에 대한 접근성 — 에이전트가 자기 작업을 더 많이 검증할 수 있을수록 결과가 좋아져요. 테스트를 실행하고 출력을 볼 수 있으면 뭐가 고장났고 어떻게 고칠지 빠르게 학습해요. 브라우저를 열고 스크린샷을 찍고 클릭할 수 있으면 실수를 발견해요. Ralph Wiggum 플러그인(심슨 캐릭터 이름을 딴 “될 때까지 반복” 도구) 같은 것들은 이런 방향을 지향해요 — 테스트가 통과하거나 특정 조건이 검증될 때까지 루프를 돌려요. 하지만 덜 명확한 작업에는 통하지 않아요. 에이전트에게 시각적 다이어그램을 디자인하라고 하면 어려울 거예요 — 여러분의 미적 선호를 모르고, 자기가 만든 것을 실제로 “볼” 수 없으니까요.

일이 꼬일 때의 리스크 허용도 — 이해관계가 중요해요. 개인 블로그의 이미지가 깨지면 복구할 수 있어요. 하지만 약물 용량을 잘못 계산할 수 있는 의료 시스템이나 실제 돈을 움직이는 뱅킹 앱을 운영하고 있다면, 에이전트를 대충 갖다 대고 잘 되길 비는 식으로는 안 돼요. 기업 소프트웨어에는 컴플라이언스와 규제 승인이 전업인 사람들이 있어요 — 그 사람들이 심각한 가드레일 없이 Gas Town을 프로젝트에 마구 돌리는 걸 허용할 리가 없죠.

그린필드 대 브라운필드 프로젝트 — 새로 시작하는(그린필드) 프로젝트에서는 에이전트에게 아키텍처 결정과 패턴 수립을 맡길 수 있어요 — 마음에 안 들면 쉽게 버리고 다시 시작할 수 있으니까요. 실수의 비용이 낮아요. 하지만 수년간 축적된 관례, 암묵적 패턴, 왜 있는지 아무도 기억 못 하는 코드가 잔뜩 있는 기존 코드베이스(브라운필드)에서는 에이전트에 훨씬 타이트한 감독이 필요해요. 에이전트는 이 코드베이스가 이미 같은 문제를 세 가지 다른 방식으로 풀고 있는데 새로운 패턴을 기꺼이 도입할 거거든요.

협업자 수 — 혼자라면 당연히 YOLO할 수 있어요. 하지만 몇 명과 함께 일하면 코딩 표준과 에이전트 규칙에 합의해야 해요. AGENTS.md 파일 업데이트, MCP 선택, 커맨드와 스킬과 룰 작성 등 자체적인 오버헤드가 생겨요. 모두가 에이전트를 사용할 때의 변화 속도는 압도적일 수 있고, 이를 관리할 합리적인 리뷰 파이프라인을 만들어야 해요. 아침에 출근했더니 누군가의 에이전트가 데이터베이스 스키마를 바꿨고 다른 에이전트가 API 레이어 전체를 리팩토링했는데, 둘 다 여러분이 아직 머지 안 한 거대한 피처와 전혀 안 맞는 상황이 벌어질 수 있어요.

경험 수준 — 시니어 개발자는 더 잘 프롬프트하고, 더 잘 디버그하고, 수십 년간 대규모 프로덕션 환경에서 뭐가 잘못될 수 있는지 본 경험으로 더 엄격한 선호를 설정할 수 있어요. “아, 저거 메모리 릭이네” 또는 “부하 걸리면 데드락 날 거야” 같은 패턴을 인식할 수 있어요. 주니어 개발자는 아직 그런 실패 카탈로그가 없어서, 프롬프트로 자기만의 사상누각을 쌓을 가능성이 훨씬 높아요. 테스트는 통과하고 다 괜찮아 보이다가, 프로덕션 트래픽이 들어오거나 이상한 문자를 누가 입력하면 무너져요. 자기가 모르는지조차 모르는 것(unknown unknowns)으로부터 방어하기는 어려워요.

• • •

미래 전망

이 모든 “상황에 따라 다르다”는 고려사항을 감안할 때, 저는 현재 대부분의 전문 개발자가 하는 진지한 작업에 대해서는 코드를 가까이 둬야 한다(code-must-be-close) 진영에 있어요. 하지만 앞으로 1-2년 안에 에이전트를 감싸는 하네스와 도구가 성숙해지면서 코드 거리를 두는(code-at-a-distance) 진영으로 옮겨갈 거라 예상해요.

필수적인 안전장치와 품질 게이트를 탑재해서 배포할 수 있다면 리스크가 줄어들어요. 물론 모델도 개선되겠지만, 인프라가 훨씬 더 중요해요 — 검증 루프, 테스트, 보안과 디버깅과 코드 품질에 집중하는 전문 서브에이전트가 코드 거리를 실현 가능하게 만들 거예요.

저희 GitHub Next 팀 내부에서도 이 코드 거리 논쟁이 계속되고 있어요. 팀 내 프로젝트 중 하나인 에이전트 워크플로우(Agentic Workflows)는 GitHub Actions를 통해 이벤트에 반응하는 자율 에이전트를 실행해요 — 새 PR, 새 이슈, 특정 시간에요. 모든 커밋이 보안 리뷰 에이전트, 접근성 감사, 문서 업데이터를 기존 CI/CD 테스트와 병렬로 트리거할 수 있어요. 이걸 만드는 팀은 코드를 거의 직접 만지지 않고, 대부분의 작업을 폰에서 에이전트를 지시하며 해요.

이런 종류의 가드레일이 직접 손대지 않는 심시티 스타일의 오케스트레이터 시스템을 덜 무섭게 느끼게 해줘요.

Gas Town 자체가 “그것”이라고 생각하지 않아요. 2027년에 우리 모두가 매일 사용하는 것으로 진화하지 않을 거예요. 앞서 말했듯, 이건 많은 사람이 진지하게 사용할 시스템이 아닌 도발적인 사변적 디자인이에요. 형편없이 설계된 사물이나 시스템이 버려지듯, 이 광적인 창작물은 설계가 너무 부실해서 오래 살아남기 어려워요.

하지만 이것이 씨름하는 문제들과 스케치한 패턴들은 의심의 여지없이 차세대 개발 도구에 나타날 거예요. 소프트웨어 개발 속도가 빨라지면서, 개발 과정의 다른 부분에서 압력이 커지는 걸 체감하게 될 거예요: 사려 깊은 디자인, 비판적 사고, 사용자 리서치, 팀 내 기획과 조정, 무엇을 만들지 결정하기, 그리고 그것이 잘 만들어졌는지 판단하기.

이 새로운 세계에서 가장 가치 있는 도구는 코드를 가장 빠르게 찍어내는 도구가 아닐 거예요. 우리가 더 명확하게 생각하고, 더 신중하게 계획하고, 모든 것이 가속하는 와중에도 품질의 기준을 높게 지킬 수 있도록 도와주는 도구일 거예요.