AI 에이전트 시대, 생산성 10배를 만드는 조건

URL: https://www.youtube.com/watch?v=sXCppYzX-0g 날짜: 2026-08-31 채널: Tech Bridge 원문 제목: [한영자막] AI 에이전트로 생산성 10배 높이는 비결: 대다수 기업이 실패하는 진짜 이유 원본 업로드일: 2026-08-30

---

📌 핵심 질문 / 핵심 논점

==AI 에이전트(Agent)가 생산성을 10배·100배, 드물게 1,000배까지 높이려면 인간 중간관리와 승인 사슬을 거치지 않고 에이전트와 직접 상호작용해야 한다. 진짜 병목은 코드 구현이 아니라 아이디어·비전·취향과 이를 전달하는 인간의 대역폭이다.==

• 인간 팀의 병목은 구현 단계가 아니라 PM, 디자이너, VP, CTO가 제품 방향에 개입하며 생기는 소통 비용과 의사결정 지연이다.
• 기업이 원하는 것과 개선 방법을 모르면 에이전트는 나쁜 아이디어를 빠르게 현실로 만들 뿐이며, 대기업의 승인·관료주의는 구현 속도의 효과를 상쇄한다.
• 기존 기업이 과거의 성공에 맞춰 만든 구조를 바꾸기 어려운 동안, Linux와 개인용 에이전트 개발은 각자가 필요한 소프트웨어의 5%를 직접 다시 만드는 기회를 연다.

Adobe Photoshop과 Basecamp처럼 오래 사랑받은 앱의 업데이트 속도가 왜 급격히 빨라지지 않는지에서 질문이 출발한다. 답은 단순히 프로그래머 수나 코드 작성량이 부족해서가 아니다. 수많은 사람이 방향을 조율하는 인간 대역폭, 명확한 비전과 취향의 부족, 승인 절차와 조직 관료주의가 더 큰 병목이다. 따라서 에이전트의 힘은 조직에 더 많은 자동 구현 능력을 추가할 때보다, 의도와 판단을 가진 사람이 에이전트와 직접 반복할 때 크게 나타난다. 이 변화는 기존 대기업의 내부 전환보다 새 회사·오픈소스·개인별 맞춤 소프트웨어에서 먼저 드러날 수 있으며, Linux 데스크톱에는 Windows 종속성을 풀어낼 새로운 플랫폼 기회가 열리고 있다.

1. 오래된 앱의 개발 속도를 막는 진짜 병목

오래된 앱의 기능 증가가 느린 이유는 코드 작성 역량보다 사람 사이의 조정 구조에 있다.

1.1. 구현보다 인간 대역폭이 먼저 막힌다

1. 구현 단계는 보통 핵심 병목이 아니다

   1. 인간 팀의 한계: 여러 사람이 함께 무언가를 만들기 시작하면 병목은 코드를 실제로 작성하는 구현(implementation) 단계에서 드물게 생긴다. 사람의 대역폭(human bandwidth)과 서로의 의도를 전달하는 소통 능력이 먼저 부족해진다.
   2. 조정 비용의 누적: 각자가 직접 판단하고 만들 수 있는 일을 설명하고 전달하고 다시 검토하는 과정으로 바꾸면, 작업 자체보다 의사소통이 더 많은 시간을 차지한다.

2. 조직의 계층이 제품에 모두 참여하려 한다

   1. 늘어나는 참여자: 제품 관리자(Product Manager), 몇 명의 디자이너, 그 위의 부사장(VP), 더 위의 최고기술책임자(CTO)가 제품의 모양을 만드는 과정에 모두 들어온다.
   2. 존재 이유의 정당화: 각 계층이 자신이 조직에 필요한 이유를 입증하려고 방향 결정에 참여하면, 책임과 권한이 명확해지기보다 생산성이 “완전히 죽는” 상황이 생긴다. CTO가 언급되는 순간 인터뷰어가 숨을 들이마신 반응은 이 과도한 계층을 풍자한다.

1.2. 10배 효과는 에이전트와의 직접 접촉에서 나온다

1. Omarchy를 만들며 얻은 계시

   1. 생산성의 폭발적 범위: David Heinemeier Hansson(DHH)은 Omarchy를 지난 3개월 동안 작업하며 10배(10x), 100배(100x), 아주 드문 경우에는 1,000배(1,000x)의 마법 같은 생산성 향상을 얻으려면 에이전트와 직접 상호작용해야 한다는 결론을 얻었다.
   2. 직접 상호작용의 의미: 사람이 에이전트에게 의도와 판단을 바로 전달하고, 결과를 확인해 다시 지시하는 짧은 루프가 에이전트의 구현 능력을 실제 산출물로 연결한다.

2. 다른 인간을 중간에 세우면 속도가 무너진다

   1. 대역폭의 중개 불가: 에이전트와의 대화 대역폭을 다른 사람을 통해 중개할 수 없다. 한 사람이 요구사항을 정리해 다른 사람에게 전달하고 다시 되돌려 받는 순간 그 과정은 너무 느려진다.
   2. 협업의 양면성: DHH는 인간을 좋아하고 함께 일하는 것도 훌륭하다고 말한다. 다만 인간 협업이 좋은 경험이라는 사실과 에이전트의 최대 속도를 내려면 직접 다뤄야 한다는 사실은 동시에 성립한다.

1.3. 대기업에 에이전트를 넣는다고 전체 조직이 10배 빨라지지는 않는다

1. 승인 사슬이 효과를 잘라낸다

   1. 세 단계 승인: 사람이 에이전트를 운전하고 그 결과가 대기업의 세 단계 승인 절차와 온갖 복잡한 조직 시스템을 통과해야 한다면, 에이전트가 빠르게 코드를 만드는 효과는 전체 업무에서 작은 구간에만 적용된다.
   2. 기대치 조정: 에이전트를 인간이 운전하고 여러 승인층이 남아 있는 상황에서 조직 전체가 10배 빨라질 것이라고 기대해서는 안 된다. 구현은 전체 과정의 극히 일부이기 때문이다.

2. 속도 향상 전에 문제 정의가 필요하다

   1. 원하는 것을 모르는 조직: 대부분의 조직은 자신이 무엇을 원하는지, 현재 상황을 어떻게 더 좋게 만들지 모른다. 따라서 구현이 아니라 아이디어, 비전, 취향(taste)에서 병목이 생긴다.
   2. 나쁜 아이디어의 고속화: 아이디어·비전·취향이 구현 능력보다 충분히 많고 선명하지 않으면 에이전트는 좋은 제품을 보장하지 않는다. 오히려 형편없는 아이디어를 빠르게 현실로 만들 수 있다. DHH가 “그럼 그다음은? 그걸 출시할 것인가?”라고 되묻는 이유가 여기에 있다.

2. AI 발전 속도와 소프트웨어 품질을 둘러싼 오해

에이전트가 코드를 빠르게 생성하는 것과 사람들이 매력적인 제품을 고르는 능력은 서로 다른 문제다.

2.1. 코드가 많다고 좋은 소프트웨어가 되지는 않는다

1. Microsoft가 보여준 반례

   1. 무한에 가까운 자원: DHH는 Microsoft를 이 사례에서 일부러 집어 든다. Microsoft는 수만 명의 프로그래머와 수십 년 동안의 끝없는 자원, 끝없는 프로그래밍 역량을 보유해 왔다.
   2. 코드량과 매력의 분리: 그럼에도 많은 코드를 작성할 수 있다는 사실만으로 훌륭하고 매력적인(compelling) 소프트웨어가 만들어지지는 않는다. DHH는 Microsoft를 평소에는 좋아한다고 덧붙인 뒤, 이번에는 비판 대상으로 삼겠다고 농담한다.

2. 복제해야 할 대상은 기존 대기업의 과정이 아니다

   1. 대화 중 반문: 인터뷰어가 조직에 에이전트를 잔뜩 맡기면 모든 문제가 해결될 것처럼 말하자, DHH는 그런 과정이 “Microsoft에서 나올 법한 것”이라고 받아친다.
   2. 새로운 목표: AI를 이용해 기존의 복잡한 조직이 이미 하던 일을 더 많이 반복하는 것이 목표가 아니다. 무엇을 만들 가치가 있는지 판단하는 사람과 직접 일하는 에이전트의 조합이 목표다.

2.2. “왜 AI가 더 빨리 발전하지 않나?”라는 비판의 역설

1. 현재 역량의 나이

   1. 6개월의 시간: DHH가 말하는 이 수준의 에이전트 역량을 갖춘 지는 약 6개월밖에 되지 않았다. 인간의 생애나 조직 내부의 개발 수명 주기라는 관점에서 보면 6개월은 긴 시간이 아니다.
   2. 과도한 기대: 새로운 능력이 생긴 지 몇 달밖에 되지 않았는데 세상의 모든 소프트웨어가 즉시 바뀌기를 기대하는 것은 기술의 성숙 과정과 맞지 않는다.

2. AI는 이미 전례 없이 빠른 변화를 만들고 있다

   1. 비판의 모순: AI에 대한 비판 중 하나는 “왜 더 빨리 발전하지 않느냐”는 것이다. DHH는 AI보다 우리를 빠르게 발전시킨 다른 형태의 진보는 없었다고 반박한다.
   2. 유토피아 농담: 고작 지난 3개월 동안 세상 전체를 다시 쓰고 소프트웨어로 가득한 유토피아를 만들지 못했다고 조바심을 내는 셈이라고 풍자한다. 기술의 역사적 속도와 개인이 체감하는 제품 출시 속도를 구분해야 한다.

3. Linux와 에이전트가 여는 개인 소프트웨어의 기회

플랫폼이 다시 경쟁 상태로 들어가면서 개인도 자신에게 필요한 소프트웨어를 직접 만들 수 있게 된다.

3.1. Linux의 오래된 결핍이 에이전트 시대의 과제가 된다

1. Linux로의 전환을 가로막은 애플리케이션

   1. Premiere의 의존성: DHH는 Linux를 오랫동안 사랑했지만 Windows와 Mac에 여전히 애착을 가진 이유로 비디오 편집, 특히 Adobe Premiere를 든다.
   2. 다음 질문: Linux용 Premiere와 Photoshop을 누가 만들 것인지가 과제다. 인터뷰어는 “이제 한 사람이 만들 수 있을 것 같다”고 말하고, DHH는 “100% 한 사람이 할 수 있다”고 동의한다.

2. 조급함을 자기 제작으로 전환한다

   1. 조급함의 생산적 역할: DHH는 자신이나 누구든 조급해할 권리가 있다고 말한다. 조급함은 다른 누군가가 해결해 주기를 기다리는 대신 스스로 시작하는 첫 단계이기 때문이다.
   2. 이미 존재하는 수요: Adobe Premiere와 DaVinci 같은 비선형 비디오 편집기(Non-linear Video Editor)를 쓰는 수만 명의 사용자가 같은 불편을 겪는다. Reddit과 포럼에 가면 그 좌절이 반복해서 공유되므로, 에이전트로 해결할 문제와 잠재 사용자를 찾을 수 있다.

3.2. 기능 개발을 늦추는 것은 관료주의다

1. 관리와 회의의 비용

   1. 내부 관료주의: 경영진, 회의, 조직 내부의 관료주의가 기능 개발을 늦추고 있을 가능성이 있다. 문제는 개발자가 코드를 못 써서가 아니라 제품에 도달하기 전 결정 과정이 길다는 데 있다.
   2. 에이전트만 추가할 때의 한계: 개발자에게 에이전트를 많이 맡기면 구현 속도는 빨라질 수 있지만, 기존 관리 구조와 승인 규칙이 그대로면 전체 제품 속도는 같은 비율로 빨라지지 않는다.

2. 처음부터 다시 만드는 선택지

   1. 오픈소스 경로: 기존 조직의 규칙을 우회하려면 오픈소스 프로젝트처럼 개발자가 직접 만들고 사용자가 함께 개선하는 방식이 가능하다.
   2. 새 회사 경로: 대기업 안에서 개발자에게 자유롭게 구축을 맡겨 에이전트 시대로 급격히 전환하기 어렵다면, 처음부터 에이전트 중심으로 운영되는 새 회사를 세우는 방법도 있다.

4. 혁신가의 딜레마와 다시 열리는 컴퓨팅 플랫폼

기존 강자의 안정성이 새로운 시대의 전환 능력을 약화시키는 동안 플랫폼의 중심이 다시 움직이고 있다.

4.1. 거대 기업은 왜 방향을 바꾸기 어려운가

1. 혁신가의 딜레마(Innovator’s Dilemma)

   1. 기존 방식의 최적화: 기존 기업은 과거의 방식으로 너무 훌륭하고 안정적으로 성장했기 때문에 그 방식에 깊이 익숙해졌다.
   2. 조직 전체의 고정: 조직 구조, 관리 계층, 업무 프로세스가 더 이상 존재하지 않는 시대를 전제로 맞춰져 있다. 과거에 최적화된 시스템이 미래의 속도를 제약한다.

2. 초대형 유조선은 급회전하지 않는다

   1. 피벗의 현실: 이런 기업은 방향을 바꾸면 된다고 말한다고 실제로 피벗할 수 없다. DHH는 이들을 초대형 유조선(supertanker)에 비유한다.
   2. 변화가 밖에서 시작되는 이유: 유조선이 빠르게 회전하지 못하듯 거대 기업의 내부 전환도 느리다. 그래서 오픈소스, 개인 프로젝트, 새 회사가 에이전트 중심의 변화를 먼저 일으킬 가능성이 커진다.

4.2. 모바일 독점에서 다중 폼팩터 경쟁으로

1. Apple·Google 모바일 양강 구도에 대한 불만

   1. 통제된 핵심 플랫폼: DHH는 한동안 모바일이 가장 중요한 컴퓨팅 플랫폼이라고 느꼈고, 그 위에 올라앉아 모든 것을 통제하며 통행세(toll booth)처럼 수익을 거두는 Apple과 Google 중 어느 쪽도 끌어내릴 길이 보이지 않아 불만스러웠다고 말한다.
   2. 게임의 변화: 이제 모바일은 여전히 중요하지만 더 이상 유일하게 가장 중요한 플랫폼은 아니다. 휴대전화 외에도 안경, 이어피스(earpiece) 등 다양한 폼팩터가 등장할 수 있어 경쟁의 판이 열려 있다.

2. 컴퓨팅 플랫폼 자체가 다시 경쟁 대상이 된다

   1. 약 40년 만의 기회: 데스크톱을 기준으로 보면 컴퓨팅 플랫폼 자체가 약 40년 만에 처음으로 다시 중요한 변수이자 경쟁 대상이 되었다.
   2. 모든 것이 열려 있음: 어떤 기기가 표준이 될지, 어떤 운영체제와 애플리케이션 조합이 사용자를 묶을지 아직 확정되지 않았다는 점이 새로운 제작자에게 기회다.

4.3. Linux는 데스크톱 밖을 이미 장악했다

1. 1991년부터 이어진 역설

   1. 데스크톱의 미완성: Linux는 1991년부터 존재했지만 데스크톱 컴퓨터에서 Windows를 밀어내거나 데스크톱을 완전히 장악하지는 못했다.
   2. 나머지 세계의 지배: 대신 책상 위의 여러 기기, 냉장고, 토스터 등 컴퓨터를 제외한 거의 모든 종류의 기기에서 Linux가 실행된다. Android도 실제로 Linux이지만 너무 정교하게 포장되어 Linux로 알아보기 어렵다.

2. Windows 종속성을 직접 풀 수 있다

   1. 개인에게 열린 재작성: Windows에 묶여 사용하던 소프트웨어가 있다면 이제 개인이 그것을 다시 작성하는 일이 완전히 손에 닿는 범위가 되었다.
   2. 완벽한 복제는 필수가 아니다: 원본 기능의 100%를 구현하지 못해도 사용자가 실제로 필요로 하는 기능을 제공하면 된다. 이 지점에서 에이전트의 구현 능력이 플랫폼 전환의 실용적 도구가 된다.

5. “Microsoft Office의 5%”와 맞춤형 소프트웨어

범용 애플리케이션 전체를 복제하는 대신 각자가 자주 쓰는 작은 기능 집합을 만들면 문제의 크기가 급격히 줄어든다.

5.1. 사용자는 거대한 앱의 일부만 쓴다

1. 5% 농담의 구조

   1. 개인별 부분집합: Microsoft Office에 대해 “나는 기능의 5%만 쓴다”는 오래된 농담이 있다. DHH는 여기에 “우리 모두 서로 다른 5%를 쓴다”고 응답한다.
   2. 복제 대상의 축소: 모든 사람에게 필요한 단 하나의 완전한 Office를 만들 필요 없이, 각자가 실제로 쓰는 기능 부분집합만 만들면 훨씬 다른 규모의 과제가 된다.

2. 맞춤형 5%의 가치

   1. 필요 기능만 구현: 사용자가 필요한 기능만 선택해 직접 구현하면 불필요한 기능과 복잡한 UI를 끌고 갈 필요가 없다.
   2. 에이전트의 적합성: 이처럼 범위가 좁고 요구사항이 명확한 맞춤형 도구는 현재의 에이전트가 바로 오늘도 매우 잘 만들 수 있는 과제다. DHH는 이런 방식으로 이미 여러 번 만들어 봤다고 말한다.

6. Omarchy에서 확인한 개인 개발의 실제 사례

에이전트는 필요한 기능을 명확히 정의한 개발자가 여러 언어로 실제 배포되는 앱을 만들게 한다.

6.1. 한 언어 개발자에서 폴리글롯 프로그래머로

1. 기술 스택의 확장

   1. 과거의 범위: DHH는 원래 무엇보다 Ruby 프로그래머였고, Bash는 꼭 필요할 때 조금 만지는 정도였다.
   2. 현재의 변화: 최신 에이전트를 사용한 뒤에는 자신이 폴리글롯 프로그래머(polyglot programmer)가 되었다고 느낀다. 지난 두 달 동안 C++를 작성했고, Omarchy 환경에서 실제로 배포된 애플리케이션 세 개를 만들었다.

2. 에이전트가 바꾼 개발자의 역할

   1. 언어 장벽의 하락: 모든 언어의 문법과 생태계를 미리 숙련하지 않아도 만들고 싶은 기능·미적 기준·사용 맥락을 설명하며 구현을 시작할 수 있다.
   2. 결정권의 유지: 에이전트가 코드를 생성해도 무엇을 만들지, 어떤 기능을 버릴지, 결과가 충분히 맞는지 판단하는 것은 사용자에게 남는다. 에이전트는 비전을 대신하는 존재가 아니라 비전을 빠르게 구현하는 도구다.

6.2. Omarchy Write가 Typora를 대체한 과정

1. Linux에서 생긴 글쓰기 문제

   1. iA Writer의 기준: DHH는 Mac에서 iA Writer를 가장 좋아했다. 깔끔하고 단순한 Markdown 작성 환경이었고, 자신의 모든 에세이를 그곳에서 썼다.
   2. Typora로의 임시 이동: Linux로 옮긴 뒤 iA Writer를 설치할 수 없어서 Typora를 선택했다. Typora는 좋은 앱이었지만 셰어웨어(shareware)였고 DHH에게 필요하지 않은 기능이 많이 들어 있었다.

2. 5% 요구사항을 제품으로 바꾸다

   1. 범위의 재정의: 약 6~7주 전, DHH는 Typora가 이미 기본적인 앱인데도 자신에게 필요한 것은 그 기능의 약 5%뿐이라고 판단했다.
   2. 구현 지시: DHH는 에이전트에게 바로 작업을 시작하라고 말하고 C++와 Qt로 작성하도록 했다. 자신이 Omarchy를 위해 만들고 있던 제품의 미적 감각과 잘 어울리는 기술·구현 방향이라고 생각했기 때문이다.

3. 20분 프로토타입에서 2일 만의 전환

   1. 첫 버전: DHH의 기억에 따르면 에이전트는 약 20분 만에 첫 버전을 내놓았다. DHH는 사용해 보면서 아직 뭔가 제대로 맞지 않는다는 점을 발견했다.
   2. 실사용 대체: 그러나 이틀 만에 Typora 사용을 완전히 포기했고, 그 뒤로 모든 에세이를 Omarchy Write로 작성해 왔다. 작은 요구사항, 직접적인 피드백, 빠른 반복이 실제 도구 교체로 이어진 사례다.

주요 발언 모음

“인간 팀이 함께 무언가를 하기 시작하면 병목 현상은 구현에서 발생하는 경우가 드뭅니다. 인간의 대역폭과 소통 능력입니다.”

“마법처럼 10배, 100배, 드물게는 1,000배까지 생산성을 높이려면 에이전트와 직접 소통해야 합니다.”

“그 대역폭을 다른 사람을 통해 중개할 수 없습니다. 너무 느리기 때문입니다.”

“아이디어 부족으로 병목을 겪고, 비전 부족으로 병목을 겪고, 취향 부족으로 병목을 겪습니다.”

“코드를 많이 작성할 수 있다고 해서 훌륭하고 매력적인 소프트웨어가 만들어지는 것은 아닙니다.”

“AI만큼 우리를 빠르게 발전시켜 준 다른 형태의 발전은 없었습니다.”

“조급함은 스스로 해내기 시작하는 첫걸음입니다.”

“이 회사들은 초대형 유조선입니다. 방향을 바꾸는 일은 실제로 일어나지 않습니다.”

“우리 모두 서로 다른 5%를 사용합니다. 그렇다면 우리 각자의 5%를 직접 만들면 어떨까요?”

“약 20분 만에 첫 번째 버전이 나왔고, 이틀 만에 Typora를 포기했습니다.”

핵심 데이터 & 수치

• 10배·100배·1,000배: 에이전트와 직접 상호작용할 때 기대할 수 있다고 DHH가 말한 생산성 향상 범위이며, 1,000배는 매우 드문 경우다.
• 3개월: DHH가 Omarchy를 작업하며 직접적인 에이전트 상호작용의 효과를 깨달은 기간이다.
• 3단계 승인: 대기업의 여러 승인층이 남아 있으면 에이전트의 구현 속도는 전체 업무 중 작은 구간만 단축한다.
• 수만 명: Microsoft가 보유해 온 프로그래머 규모를 설명한 수치이며, Premiere·DaVinci 사용자 커뮤니티 규모를 말할 때도 수만 명이 언급된다.
• 수십 년: Microsoft가 막대한 자원과 프로그래밍 역량을 활용해 온 기간이다.
• 약 6개월: DHH가 현재 수준의 에이전트 역량을 갖추고 있다고 보는 기간이다.
• 3개월: AI가 이 짧은 기간 안에 세상 전체를 소프트웨어 유토피아로 바꾸지 못했다고 조바심 내는 상황을 풍자한 시간 단위다.
• 1991년: Linux가 시작된 시점이다.
• 약 40년: 데스크톱 관점에서 컴퓨팅 플랫폼 자체가 다시 경쟁 변수로 떠오르기까지의 시간이다.
• 5%: Microsoft Office나 Typora 같은 범용 앱에서 개인이 실제로 필요로 하는 기능의 작은 부분집합을 상징한다.
• 지난 2개월: DHH가 C++를 작성하고 Omarchy용 배포 앱 세 개를 만든 기간이다.
• 6~7주 전: Typora의 5%만 필요하다고 판단하고 Omarchy Write 제작을 시작한 시점이다.
• 약 20분: C++와 Qt 기반 Omarchy Write의 첫 버전이 나온 데 걸린 시간이다.
• 2일: 첫 버전이 아직 완벽하지 않았음에도 Typora를 버리고 Omarchy Write로 전환하는 데 걸린 시간이다.

결론 및 시사점

AI 에이전트의 생산성 배수는 조직에 에이전트 수를 추가하는 것만으로 결정되지 않는다. 좋은 결과를 내려면 사람이 무엇을 만들지에 대한 비전과 취향을 가지고 에이전트와 직접 대화해야 하며, 그 대화가 PM·관리자·승인층을 거치며 희석되지 않아야 한다. 기존 대기업은 과거의 성공을 가능하게 한 계층·프로세스·제품 운영 방식 때문에 에이전트 시대로 급회전하기 어렵다.

• 문제 정의부터 확보한다: 에이전트에게 구현을 시키기 전에 사용자 문제, 원하는 경험, 버릴 기능을 한 문장으로 명확히 정한다.
• 직접 루프를 만든다: 요구사항 전달자를 여러 겹 두지 말고, 판단권자가 에이전트의 결과를 직접 보고 짧은 주기로 수정 지시를 내린다.
• 작은 기능 집합으로 시작한다: 거대한 범용 앱의 100% 복제보다 팀이나 개인이 실제로 쓰는 5%의 기능을 우선 구현한다.
• 취향을 품질 기준으로 삼는다: 코드 완성률이 아니라 사용감, 미적 일관성, 실제 작업 흐름을 기준으로 프로토타입을 평가한다.
• 기존 조직의 전환 비용을 인정한다: 에이전트 도입이 승인·회의·관료주의를 자동으로 없애지 않으므로 조직 재설계, 오픈소스, 독립 팀, 새 회사 같은 구조적 선택을 검토한다.
• 플랫폼 이동성을 활용한다: Linux에서 부족한 애플리케이션을 개인별로 재구현할 수 있다는 점을 새로운 제품 기회로 본다.
• 조급함을 실행으로 바꾼다: 완벽한 대체재가 나올 때까지 기다리기보다 가장 불편한 기능 하나를 에이전트와 함께 직접 만든다.

핵심 요약 (20줄)

AI 에이전트의 생산성 배수는 구현 속도보다 인간의 대역폭과 의사소통 구조에 좌우된다. 제품 관리자와 디자이너와 임원과 CTO가 모두 방향 결정에 참여하면 조정 비용이 생산성을 무너뜨린다. 10배와 100배의 향상과 드문 1,000배의 향상은 에이전트와 직접 상호작용할 때 가능해진다. 에이전트와의 대화 대역폭을 다른 인간이 중개하면 전달과 검토가 너무 느려진다. 세 단계 승인과 대기업의 복잡한 시스템은 구현 속도 향상의 효과를 전체 업무로 확장하지 못하게 한다. 대부분의 조직은 구현보다 아이디어와 비전과 취향의 부족에서 더 큰 병목을 겪는다. 에이전트는 좋은 판단이 없으면 형편없는 아이디어를 빠르게 현실로 만들 뿐이다. 수만 명의 프로그래머와 수십 년의 자원을 가진 Microsoft도 코드량만으로 매력적인 소프트웨어를 보장하지 못했다. 현재의 에이전트 역량은 약 6개월밖에 되지 않았지만 AI는 전례 없이 빠른 진보를 만들고 있다. 지난 3개월 만에 세상을 모두 다시 쓰지 못했다고 AI를 느리다고 비판하는 것은 과도한 기대다. Linux 사용자는 Premiere와 Photoshop 같은 핵심 애플리케이션 때문에 Windows와 Mac에 묶여 있었다. 에이전트 시대에는 한 사람이 Linux용 Premiere나 Photoshop의 필요한 부분을 만들 수 있다. Premiere와 DaVinci 사용자 수만 명이 공유하는 불편은 개인 개발의 분명한 수요 신호가 된다. 오픈소스나 새로운 회사는 대기업보다 에이전트 중심 개발로 빠르게 이동하기 쉽다. 기존 기업의 조직과 관리와 프로세스는 과거의 성공에 맞춰져 있어 초대형 유조선처럼 급회전하기 어렵다. 모바일의 Apple과 Google 양강 구도와 달리 안경과 이어피스 같은 새 폼팩터는 플랫폼 경쟁을 다시 열고 있다. Linux는 1991년부터 존재했고 데스크톱을 제외한 냉장고와 토스터와 Android 같은 곳에서 광범위하게 실행된다. 사람마다 Microsoft Office의 서로 다른 5%만 사용하므로 필요한 5%만 직접 만드는 전략이 가능하다. DHH는 최신 에이전트로 Ruby와 Bash를 넘어 C++를 익히고 Omarchy용 앱 세 개를 배포했다. Omarchy Write는 약 20분 만에 첫 버전이 나왔고 이틀 만에 Typora를 대체해 모든 에세이의 작성 도구가 되었다.