TL;DR

  • 에이전트를 대량 투입해 토큰 소비와 코드 생산량을 늘려도 복잡성과 비용이 폭증하고 생산성이 떨어지는 Yegge’s Paradox가 발생하며, 해결책은 명시적 API 경계와 비정규화임.
  • Steve Yegge의 Gastown은 에이전트 기반 코딩의 처리량 중심 작업 방식을 보여주지만, 작업 손실과 코드 품질 저하의 위험도 드러냄.
  • 초기 Amazon도 복잡한 소프트웨어가 단일 시스템에 묶여 독립 확장과 명확한 소유권을 잃었으며, Jeff Bezos의 서비스 인터페이스 의무화가 마이크로서비스 시대의 출발점이 됨.
  • 에이전트가 늘어난 환경에서는 중복을 감수하더라도 팀별 서비스 경계와 외부화 가능한 인터페이스가 필요하며, 명세와 테스트가 에이전트 간 협업의 계약 역할을 함.
  • AI가 경제에 확산되고 모델이 분산된 환경에서 더 잘 작동한다면 기업 규모와 인간의 협업 방식도 달라질 수 있지만, 그 변화의 방향은 아직 열려 있음.

Yegge’s Paradox와 Gastown

  • 2026년 1월 공개된 Steve Yegge의 Gastown은 에이전트로 운영되는 산업화된 코딩 공장으로, 초지능 로봇 침팬지가 필요할 때 시스템을 순식간에 망가뜨릴 수도 있다는 묘사임.
  • Gastown은 매드맥스풍 대형 트럭 그림에 “에이전트를 위한 쿠버네티스를 만들어라”는 지시를 붙이고 Opus 4.8에 10만 달러를 쓰는 상황에 빗댄 구상임. 완성된 해답이라기보다 훗날 형태를 알아볼 초기 시도로 평가함.
  • Gastown이 제시하는 작업 방식은 바이브 코딩(vibe coding)과 처리량 중심의 작업임.

대부분의 작업은 끝나지만 일부는 사라짐. 물고기는 통에서 빠져나오고, 바다로 도망가거나 밟히기도 함. 물고기는 더 들어옴. 초점은 생각의 속도로 창작하고 수정하는 처리량임.

  • 에이전트를 수십 개씩 실행하고, 터미널에서 슬랙으로 옮겨 가며 에이전트가 다른 에이전트를 관리하게 할 수 있음. 코드 읽기를 멈춘 채 9월에 GitHub 기여 2,795건을 기록하는 식의 과잉 생산도 가능함.
  • 그러나 이런 흐름은 복잡성의 진흙탕으로 변할 수 있음. 조직의 Codex 사용 한도를 늘려도 효율은 떨어지고, 풀 리퀘스트 하나의 비용은 치솟으며, 코드베이스 각 모듈에는 복잡성 종양이 자람. 이 간극이 Yegge’s Paradox임.
  • 인간을 계속 개입시키고 더 나은 모델을 기다리는 신중한 선택도 가능하지만, 여기서 제기되는 문제는 모델 역량 부족이 아니라 격리와 오버헤드임. 모델이 다른 영역에서 보여주는 능력과 달리 앱의 결제 로직에 안전한 변경을 적용하기 어려운 이유를 따져야 함.

초기 Amazon의 복잡성과 서비스 경계

  • 2006년 인터뷰에서 Amazon 최고기술책임자(CTO) Werner Vogels는 2001년 무렵의 코드베이스가 복잡한 소프트웨어를 하나의 시스템에 결합해 더는 발전할 수 없는 상태였다고 설명함.

독립적으로 확장해야 하는 부분이 알려지지 않은 다른 코드 경로와 자원을 공유하도록 묶여 있었음. 격리가 없었고, 그 결과 명확한 소유권도 없었음.

  • 이 문제는 인간이 만든 시스템에서도 나타났으며, 20년 전에는 이런 수준의 혼란을 만들려면 대규모 인력과 강압적인 관리가 필요했음. 오늘날에는 에이전트를 관리하는 작은 스타트업도 초기 Amazon과 비슷한 복잡성 문제를 마주할 수 있음.
  • Steve Yegge는 2011년 Google+에 올린 플랫폼 관련 글에서 Jeff Bezos가 Amazon 팀에 내린 지침을 소개함.

모든 팀은 데이터와 기능을 서비스 인터페이스로 제공해야 함. 팀은 이 인터페이스를 통해 소통해야 함. 직접 연결, 다른 팀 데이터 저장소의 직접 조회, 공유 메모리, 백도어는 허용되지 않으며 네트워크를 통한 서비스 인터페이스 호출만 허용됨.

  • 인터페이스 구현 기술은 HTTP, CORBA, 발행·구독(pub/sub), 맞춤형 프로토콜 중 무엇이든 상관없으며, 모든 서비스 인터페이스는 외부 개발자에게 공개할 수 있도록 처음부터 설계해야 한다는 내용임. Bezos가 이를 따르지 않는 사람을 해고하겠다고 했다는 대목은 Yegge가 덧붙인 농담임.
  • 이 지침은 마이크로서비스 시대의 출발점으로 제시됨. 마이크로서비스는 매력적인 선택처럼 보이지 않을 수 있지만, 의존하는 외부 API가 계속 작동한다면 내부에서 인간, 에이전트, 침팬지 또는 그 조합이 무엇을 하는지는 알 필요가 없다는 장점이 있음.
  • 테스트 주도 개발(TDD) 등 당시 유행한 관행은 인간 중심 시대에 지나치게 일찍 도입하는 초급 엔지니어 때문에 나쁜 평판을 얻기도 했음. 엔지니어가 20명일 때 모든 기능을 별도 API로 나누는 것은 불필요하고 중복을 늘릴 수 있음. 하지만 이제 그 20명과 함께 일하는 열성적인 인턴이 총 1,000명이라면 명확한 서비스 경계가 필요해짐.

비정규화와 명시적 명세

  • 데이터 모델링의 정규화(normalization)와 비정규화(denormalization)는 중앙 집중화와 효율이 충돌하는 상황을 이해하는 틀임. 분석 쿼리를 바쁜 이벤트 테이블 하나로 보내 데이터를 한곳에 둘지, 통계를 미리 계산해 별도로 저장할지는 구체적인 조건에 따라 달라짐.
  • 같은 틀은 조직에도 적용 가능함. 회사 전체가 하나의 채용 절차를 쓸지 팀마다 채용을 맡을지 선택해야 하며, 후자는 노력을 중복할 수 있지만 효율을 높이고 병목을 줄일 수 있음. 에이전트 시대에는 비정규화와 공식화된 API 경계가 적절한 전술이라는 입장임.
  • 코딩 에이전트와의 협업은 다른 방에 있는 사람에게 탁자를 만들라고 외치는 상황에 비유됨. 탁자가 완성됐다는 답을 듣고 물건을 올리려 하자 상판이 없다는 사실을 알게 되고, 의자를 밀어 넣으려 하자 다리가 없어 탁자 밑으로 들어가지 못하는 식임.
  • 해결책은 정확한 테스트 조건을 포함한 명시적 명세임. 예를 들어 탁자의 높이는 28인치이고 상판은 단단해야 하며 추수감사절 만찬을 지탱해야 한다고 지정하는 것이 탁자 API에 해당함.
  • 다만 탁자를 만드는 동안 다른 사람이 카펫을 깔고, 또 다른 사람이 벽을 칠하고, 방에 불까지 난다면 명세만으로는 충분하지 않음. 이러한 동시 작업의 복잡성이 Yegge’s Paradox임.

중앙집중화가 남기는 질문

  • 비정규화는 James C. Scott의 『Seeing Like a State』를 이해하는 틀이기도 함. 이 책은 중앙집중화가 빚은 실패 사례를 모으며, 끔찍한 기근을 초래한 소련의 농업 집단화와 추상적으로 아름답지만 지역 주민이 살기 어렵고 인간성을 해치는 Le Corbusier의 도시 설계를 다룸.
  • 시스템의 변화는 인간과 기술 사이를 오가며 파급됨. AI가 경제에 의미 있게 확산되고 모델이 정규화·중앙집중화된 환경보다 격리·비정규화된 환경에서 더 잘 작동한다는 전제가 유지된다면, 경제와 인간의 상호작용 및 협업 구조에도 영향이 생길 수 있음.
  • 기업이 더 작아질지, 개인 기업이 작은 API를 서로 공개하고 x402를 통해 대금을 지불하는 흐름이 나타날지, 아니면 에이전트가 인간에게 이해하기 어려운 도시와 기업을 만들며 인간이 협업에서 배제될지는 아직 알 수 없음.
  • 확실한 것은 앞으로 상황이 훨씬 더 낯설어질 수 있다는 전망임.
  • 끝까지 읽었다면 Gastown과 Steve Yegge의 플랫폼 관련 글을 전문으로 읽어 보라는 권유와, Gastown을 처음 읽었을 때 크게 웃었다는 언급이 담겨 있음.