비개발자들이 AI로 10만 달러 이상 비즈니스를 바이브 코딩하는 법

How Non-Coders Are Vibe Coding $100K+ Businesses with AI | Amol Jain URL: https://www.youtube.com/watch?v=JAh8Wv1lQrw 날짜: 2026-08-31 채널: D2_interview

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==코드 작성 비용이 거의 0에 가까워진 시대에 돈을 지불받는 것은 코드 자체가 아니라 고유한 전문성, 판단력, 신뢰, 데이터, 보안, 유통, 네트워크와 실제 서비스다.==

• 코딩을 전혀 몰라도 자신이 잘 아는 틈새 문제와 이미 가진 오디언스를 Replit 앱으로 바꿔 월 수만 달러 또는 수십만 달러 매출의 사업으로 만들 수 있다.
• 원시적인 vibe-coded prototype은 도메인, 보안, 결제, SEO·Answer Engine Optimization(AEO), 유통을 붙여야 production-grade 사업이 된다.
• 기업은 범용 SaaS의 비싼 UI를 사는 대신 자신의 데이터와 워크플로에 맞는 내부 도구를 직접 만들고, Salesforce 같은 system of record·Workday 같은 규제 인프라·DoorDash 같은 물리적 서비스에만 계속 비용을 지불할 가능성이 높다.
• 모델이 빠르게 commoditize될수록 애플리케이션 계층이 hosting, reliability, security, distribution, workflow orchestration을 제공하고 여러 모델을 선택하게 하는 가치가 커진다.

1. 코딩 경험이 없어도 매출을 만드는 세 가지 사업

고유한 문제 이해와 오디언스가 코딩 능력보다 먼저 사업의 출발점이 된다.

1.1. Replit이 포착한 창업의 기회

1. 비개발자의 경제적 이동성

   1. 반복되는 창업: Replit의 head of product engineering인 Amol Jain은 매일 새 사업이 생기며, 거대한 TAM(Total Addressable Market)을 가진 기업만 성공하는 것은 아니라고 설명한다.
   2. 작은 고객 기반의 실질 매출: 100명에서 수백 명의 고객만 섬기는 사업도 실제 수익을 만들고 운영자의 경제적 이동성을 높인다.
   3. 기존 자산의 사업화: Replit은 개인이 가진 distribution network, community, domain expertise, judgment를 코드와 결합해 사업으로 바꾸는 도구가 된다.

2. 코드가 아닌 우위의 전환

   1. 고유한 전문성: 특정 약물, 직무, 지역 상권, 게임 커뮤니티처럼 창업자가 깊이 아는 주제가 제품의 문제 정의와 차별화가 된다.
   2. 고유한 판단과 취향: 같은 AI 도구를 써도 무엇을 만들지, 무엇을 버릴지, 누구에게 팔지 결정하는 taste와 judgment가 결과를 가른다.
   3. 기존 네트워크: 이미 신뢰를 쌓은 커뮤니티와 개인 브랜드는 새 앱을 처음부터 광고하는 것보다 강력한 초기 distribution이 된다.

1.2. Pep AI: 펩타이드 커뮤니티를 모바일 구독 사업으로 바꾸다

1. 문제 발견과 첫 제품

   1. Cedric의 배경: Oregon에 살며 University of Oregon에 다니는 22세 Cedric은 이전에 코드를 작성해 본 적이 없다.
   2. 관심사에서 출발한 문제: 룸메이트와 함께 peptides와 GLP-1에 관심을 갖고 관련 커뮤니티를 깊이 탐색하다가, 더 넓은 커뮤니티에 도움을 줄 기회를 발견했다.
   3. 제품의 역할: 사용자가 펩타이드와 GLP-1 섭취를 추적하고, 새롭게 등장하는 약물과 관련 정보를 더 잘 학습하도록 돕는 앱을 만들었다.

2. Replit을 활용한 구축과 성장

   1. 개발 진입 장벽 제거: 코딩 경험이 전혀 없었지만 Replit에서 모바일 앱과 랜딩 페이지를 모두 만들었다.
   2. 분배 실험: 단순히 앱을 올려두지 않고 distribution을 조금씩 시험하고 실험해 제품을 크게 성장시켰다.
   3. 첫 달 성과: 첫 달에 $60,000를 벌었다.
   4. 사용자 규모: 앱은 수만 명의 active user를 확보했고 매일 성장하고 있다.
   5. 수익 모델: 매출은 in-app purchase가 아니라 subscription에서 발생한다.

3. 전문성의 사업화 원리

   1. 호기심의 축적: Cedric은 사업가라는 정체성만 내세운 것이 아니라 특정 주제를 깊이 공부해 커뮤니티가 필요로 하는 기능을 파악했다.
   2. 관심사와 제품의 결합: 약물에 대한 개인적 관심이 기록·학습·정보 접근이라는 반복 사용 문제로 전환됐다.

1.3. AI Proficiency: $100,000짜리 외주 견적을 3일짜리 빌드로 바꾸다

1. 반복 창업자의 강점

   1. John의 배경: John은 과거에도 회사를 세운 repeat founder다.
   2. 시장 변화 포착: AI가 확산되는 시점에 사람과 기업이 자신의 AI proficiency를 측정하고 인증받을 수 있는 기회가 있다고 판단했다.
   3. 고객 범위: 개인뿐 아니라 enterprises와 기업도 직원의 AI 활용 능력을 측정하고 인증하는 수요를 가질 수 있다.

2. 비개발자에서 제품 출시자로의 전환

   1. 기존 선택지의 가격: 비기술적인 John은 플랫폼을 만들 방법을 몰라 agency에 문의했고, $100,000 이상 견적을 받았다.
   2. 직접 구축: 견적이 맞지 않아 Replit에 접속했고, 코딩을 몰랐지만 3일 안에 전체 시스템을 end-to-end로 만들었다.
   3. 제품 범위: 사용자의 AI 숙련도를 평가하고, 결과에 따라 인증받을 수 있는 AI proficiency 도구를 구축해 출시했다.

3. 출시 후 매출을 만든 능력

   1. 초기 매출: 출시 후 첫 2개월 안에 매출이 이미 $180,000를 넘었다.
   2. 제품 직관: 반복 창업자로서 무엇을 만들고 어떻게 구성해야 하는지에 대한 product intuition이 있었다.
   3. 판매와 유통: John은 제품을 만드는 법만 몰랐을 뿐, 제품을 배포하고 판매하는 법은 알고 있었다.
   4. 핵심 교훈: AI builder는 문제 정의·제품 감각·유통 능력을 가진 사람이 기술 구현만 보완하도록 만들며, 기술력과 창업 역량을 분리한다.

4. 가격에 대한 농담과 실제 가치

   1. agency 견적 농담: Peter Yang은 $100K 견적을 보고 그 agency가 “Fable tokens”를 쓰는 것인지 모르겠다며 농담했다.
   2. 반응: 두 사람은 웃었고, Amol은 그 가격이 정말 비싸다고 인정했다.
   3. 리드 생성 구조: 제품 홈페이지에서 방문자가 AI 능력 테스트를 해보고 잠재 고객(lead)이 되도록 만들 수 있다는 설명이 이어졌다.

1.4. TryNearby: 게임 크리에이터의 오디언스를 지역 상권 마켓플레이스로 확장하다

1. FaZe Apex의 기존 자산

   1. 게임 커뮤니티: FaZe는 게임 역사에서 매우 유명하고 성공적인 gaming group이며, FaZe Apex(Yusuf)는 그 안에서도 잘 알려진 성공적인 gamer다.
   2. 크리에이터 경력: Yusuf는 여러 해 동안 오디언스를 쌓고 비디오 게임을 스트리밍하며 creator로 수익을 만들어왔다.
   3. 비기술적 강점: 기술 구현보다 audience와 creator 생태계를 이해하는 능력이 강점이었다.

2. 지역 사업과 지역 크리에이터 연결

   1. 문제 정의: 지역 사업자가 지역 크리에이터와 연결돼 입소문(word of mouth)을 만들도록 하는 서비스를 구상했다.
   2. 마켓플레이스 모델: 레스토랑 같은 local business와 해당 지역을 잘 아는 local creator를 매칭해 사업자를 홍보한다.
   3. 도메인 지식의 활용: 크리에이터 오디언스가 무엇에 반응하는지 아는 사람이 만든 구조라 광고 플랫폼보다 구체적인 관계를 만들 수 있다.

3. 초기 사업 성과

   1. 창업팀: Yusuf와 co-founder가 함께 TryNearby라는 회사를 만들었다.
   2. YC 참여: 회사는 YC Summer 2026 batch에 들어갔다.
   3. 매출 지표: 마지막으로 대화했을 때 ARR(Annual Recurring Revenue)이 $100,000를 넘었다.
   4. 확장 가능성: Peter는 좋아하는 레스토랑을 직접 홍보할 수 있겠다며 관심을 보였고, 지역 상권과 지역 영향력자의 연결이 실제 이용 장면으로 제시됐다.

2. 원시적인 AI 프로토타입을 생산 가능한 사업으로 바꾸는 과정

앱을 생성하는 일은 시작에 불과하며, 신뢰·보안·결제·발견 가능성을 묶어야 사용자가 돈을 지불하는 제품이 된다.

2.1. 범용 앱의 commoditization과 틈새 우위

1. 쉽게 복제되는 기능

   1. 범용 사용 사례: meal planner, exercise tracker처럼 누구나 만들 수 있는 generic use case는 빠르게 commoditize되고 있다.
   2. 개인 버전의 확산: 사람들이 같은 기능의 자기 버전을 직접 만들 수 있어 단순한 기능만으로는 방어력이 약하다.
   3. Agent에 의한 흡수: 장기적으로는 개인마다 특정 skill을 가진 agent를 갖고, 범용 앱 기능 전체를 agent가 삼켜버릴 가능성이 있다.

2. 그럼에도 커지는 사업의 총량

   1. Stripe 데이터의 방향: Stripe 데이터는 새로 만들어지는 사업의 수가 증가하고 있음을 보여준다.
   2. 새로운 창업자층: 과거에 기술에 노출되지 않았던 average Joe도 자신의 경험을 사업으로 만들 수 있다.
   3. 작아도 번성하는 사업: 모든 사업이 거대한 회사가 될 필요는 없으며, 작은 사업이 안정적으로 thriving하는 것 자체가 성공이다.

3. 발견해야 할 고유한 우위

   1. 직업별 현장 지식: pool cleaner, nurse, jeweler처럼 현장에서 문제를 반복해 겪는 사람은 개발자보다 더 좋은 문제 정의를 할 수 있다.
   2. 구체적인 고객 이해: 특정 직업·지역·취미 커뮤니티의 언어와 불편을 아는 사람이 기능 우선순위를 정한다.
   3. 기능 외의 서비스: 고객은 소프트웨어 파일만 사는 것이 아니라 설치, 운영, 관리, 조언 같은 추가 서비스를 함께 산다.

4. 사용자의 지불 의사

   1. 사람은 본질적으로 게으르다: 모든 사용자가 스스로 도구를 만들거나 모든 단계를 직접 처리하려는 entrepreneurial spirit을 가진 것은 아니다.
   2. 가치가 있으면 지불한다: 사용자의 시간·불확실성·노력을 줄여주는 제품이면 코드가 저렴해져도 비용을 받을 수 있다.
   3. Peter의 정리: 고유한 skill set과 knowledge를 찾고, 앱을 올려두기만 하지 말고 자신의 오디언스에 도달하는 marketing을 해야 한다.
   4. 추가 패키징: 제품에 서비스와 다른 실행 요소를 더해 사용자가 실제 상황에서 바로 쓸 수 있게 해야 한다.

2.2. 제품 관리 인터뷰 코치의 랜딩 페이지

1. 문제의 출발점

   1. 제품 직무의 변화: product management 시장은 변했고, 직무 내용과 인터뷰 방식도 달라졌다.
   2. 오디언스 자산: Peter는 제품 전문가가 출연하는 팟캐스트를 운영하고 제품 전문가 네트워크를 보유하고 있다.
   3. 구체적인 아이디어: 제품 전문가와 지원자를 짝지어 mock interview를 진행하고, 지원자가 실제 인터뷰를 통과하도록 돕는 interview coach를 만들 수 있다.
   4. 차별화된 코칭: CIRCLES framework를 반복 암기하는 수준을 넘어, 실제 제품 전문가에게서 현실적인 피드백을 받게 한다.

2. 아이디어에서 화면으로

   1. 음성 기반 요구사항 입력: Amol은 Whisper Flow를 자주 사용해 만들고 싶은 것을 음성으로 받아 적었다.
   2. Design 탐색: Replit Design을 먼저 사용해 제품에 맞는 여러 방향과 variation을 살펴봤다.
   3. 단순한 랜딩 페이지: 여러 시안을 시험한 뒤 Peter의 랜딩 페이지가 가진 단순함을 출발점으로 삼아 Replit에 페이지 제작을 요청했다.
   4. raw product의 정의: 기본 기능이 들어간 전체 랜딩 페이지를 빠르게 만든 상태는 사업의 완성이 아니라 raw product다.

3. 신뢰를 둘러싼 농담

   1. Peter의 얼굴: Peter는 자신의 얼굴을 랜딩 페이지에 넣으면 신뢰를 높일 수도 있지만 “소름 끼치는(gripping)” 요소가 될 수도 있다고 농담했다.
   2. Amol의 답변: Amol은 “trustworthy face”라서 자신이라면 구매하겠다고 받아쳤다.
   3. 실제 시사점: 얼굴, 개인 브랜드, 기존 관계는 인터뷰 코치처럼 신뢰가 구매 결정에 직접 작용하는 제품에서 distribution과 conversion의 일부가 된다.

2.3. Publish: localhost 밈에서 실제 도메인으로

1. 초보 창업자가 겪는 마지막 1마일

   1. localhost 공유의 문제: vibe coding으로 앱을 만든 뒤 친구에게 localhost 링크를 보내는 일이 반복돼 거의 밈처럼 됐다.
   2. 호스팅 추상화: Replit은 hosting, database와 관련 인프라를 추상화해 비기술 사용자가 배포 과정을 덜 복잡하게 만든다.
   3. 사업용 도메인: 실제 사업에는 기억하기 쉬운 도메인이 필요하다.

2. 도메인 선택 사례

   1. 구매한 도메인: 제품에는 coachpeter.net을 사용했다.
   2. 비용 제약: coachpeter.com은 가격이 너무 비싸서 선택하지 않았다.
   3. 현실적 판단: 사업 초기에는 완벽한 도메인보다 합리적인 비용으로 기억하기 쉬운 주소를 확보하는 판단이 중요하다.

2.4. Security Center: 버튼 하나 뒤에 있는 production 보안

1. Vibe-coded 앱의 공격 표면

   1. 악의적인 공격자: 공개된 앱은 지속적으로 공격받을 수 있고, vibe-coded website는 보안 취약점에 노출되기 쉽다.
   2. API key 노출: 소스 코드에 API key를 넣어 외부에 공개하는 실수가 대표적인 위험이다.
   3. 악성 package: Agent가 악성 패키지를 선택해 설치하면 정보 탈취나 시스템 침해로 이어질 수 있다.
   4. Secret scanning: 코드와 설정에 들어간 비밀값을 탐지해야 한다.
   5. PII 유출: 개인식별정보(PII)를 올바르게 저장하지 않으면 데이터가 새어 나갈 수 있다.

2. 기존 보안 점검과의 차이

   1. 전문팀 의존: 과거에는 security team과 계약해 점검을 맡겼다.
   2. 시간과 비용: 보안팀이 1~2주 동안 검사하고 비용을 많이 청구한 뒤 보고서를 전달했다.
   3. 후속 구현 부담: 보고서를 받은 개발자가 문제를 직접 고쳐야 했기 때문에 검사와 수정 사이에 또 다른 시간이 들었다.

3. Replit Security Center의 동작

   1. 단일 실행: Security Center에서 버튼 하나를 누르면 새 task가 열리고 security scan이 시작된다.
   2. Threat model 생성: 보안 Agent가 특정 앱에서 무엇이 잘못될 수 있는지 threat model을 만든다.
   3. 시나리오별 심층 검사: 가능한 공격 시나리오를 깊게 스캔하고 실제로 문제를 탐지할 수 있는지 시험한다.
   4. 결과 노출: 발견한 문제를 사용자에게 보여줘 배포 전에 수정하도록 한다.
   5. 반복 점검: 첫 배포 직전뿐 아니라 새 기능을 추가할 때마다 recurring scan을 돌릴 수 있다.
   6. Agent의 한계 보완: Replit Agent가 기본적으로 많은 문제를 잘 예방하더라도, 배포 직전 별도 검사로 마지막 매듭을 묶어야 한다.

2.5. Monetization: Stripe 계정부터 결제 라이브 전환까지

1. 자연어로 결제 기능 추가

   1. 요청 방식: Replit Agent에 사용자에게 월 $100 또는 연간 요금으로 구매하게 하는 기능을 추가해 달라고 요청한다.
   2. 복잡성 추상화: Stripe 가입, KYC(Know Your Customer), 상품 플랜, 가격, subscription과 one-time payment 설정을 모두 직접 처리하지 않아도 된다.
   3. 초보자의 수익화: 이전에 무엇도 monetization하지 못했던 사람도 제품에 유료 기능을 붙일 수 있다.

2. Stripe 연동의 단계

   1. 자동 계정 생성: 사용자가 처음부터 별도 Stripe 계정을 만들 필요 없이 Replit이 계정을 만들고 사용자는 claim하면 된다.
   2. Sandbox 구성: 백그라운드에서 Stripe sandbox, API key, plans, prices가 설정된다.
   3. 테스트: 테스트 환경에서 결제 흐름이 제대로 작동하는지 확인한다.
   4. Live 전환: 제품이 준비되면 마지막 구성만 교체해 live Stripe로 전환한다.

2.6. SEO와 Answer Engine을 통한 distribution

1. 검색 가능한 제품 만들기

   1. 핫한 검색어: product management interview coach는 Google에서 관심이 높은 검색어다.
   2. Answer engine 대응: ChatGPT 같은 answer engine이 답변을 생성할 때 제품이 발견되도록 해야 한다.
   3. SEO Agent: SEO Agent가 검색과 answer engine 모두에서 앱의 discoverability를 높이기 위한 작업을 수행한다.

2. 성장 기능의 확장

   1. 현재의 첫 베팅: SEO scan은 Replit이 distribution을 지원하기 시작한 첫 단계다.
   2. 예정된 수단: 광고와 email을 통해 제품을 market하는 방법도 더해질 예정이다.
   3. 만드는 것과 키우는 것의 결합: 좋은 사업을 build하는 것만큼 audience를 얻고 성장시키는 일도 중요하다.

3. 오디언스의 내구성

   1. Peter의 사례: Peter는 큰 Twitter audience를 구축해 둔 덕분에 오디언스를 durable asset으로 본다.
   2. 여러 번의 출시: 오디언스가 있으면 한 제품이 실패해도 여러 제품을 차례로 launch할 수 있다.
   3. 신뢰의 조건: 사람을 속이거나 과장해 이익을 취하는 grifting을 하지 않는 한 오디언스는 반복적인 제품 출시를 지지할 수 있다.

3. 기업이 비싼 SaaS 대신 직접 만드는 내부 도구

코드가 싸지는 순간 기업의 질문은 “어떤 SaaS를 살까”에서 “우리 워크플로에 맞는 것을 직접 만들까”로 이동한다.

3.1. SaaS의 재평가

1. 지난 10년의 기본 구조

   1. 인터페이스 위의 인터페이스: 많은 SaaS startup이 데이터 위에 인터페이스를 얹고, 그 위에 또 다른 인터페이스를 제공했다.
   2. 코드 비용의 하락: AI와 Agent로 code의 cost가 거의 0에 가까워지면서 이 구조가 재평가되고 있다.
   3. 단순 절약 이상의 이유: 기업은 라이선스 비용을 줄이기 위해서만 직접 만드는 것이 아니라, 자신의 workflow에 꼭 맞는 bespoke solution을 원한다.

2. Replit 내부의 변화

   1. 도구 대체: Replit은 내부적으로 많은 도구를 자체 제작물로 교체했다.
   2. 맞춤형 동작: 직접 만든 도구는 팀의 use case에 맞고 기존 범용 제품보다 더 잘 작동한다.
   3. 개발의 접근성: 비개발자도 제품 아이디어를 직접 구축해 부서의 병목을 줄인다.

3.2. Sales Demo 도구: 두 날 만에 만든 내부 제품

1. 기존 Replit 데모의 문제

   1. 기업 영업 확대: Replit이 enterprise에서 성공하면서 sales organization이 크게 성장했다.
   2. 제품 시연의 필요: Replit과 일반 AI 제품은 말로 설명하기보다 prospect에게 직접 demo할 때 가치가 분명해진다.
   3. 시간 지연: security scan 하나만 해도 완료까지 10분이 걸릴 수 있어 live demo 중 dead time이 생긴다.
   4. 비결정성: Agent는 매번 같은 결과를 내지 않고, 때로는 원하지 않는 방향으로 작업하거나 출력이 망가질 수 있다.

2. 비싼 외부 대안

   1. 기존 제품: 데모를 녹화하고 재현하는 startup들이 이미 존재한다.
   2. 기능 수준: 기존 제품은 평균적이고 기본적인 기능에 머무는 경우가 많다.
   3. 가격: 이런 도구는 쉽게 six figures 비용까지 올라간다.

3. RevOps 담당자의 구축

   1. 비개발자 제작: Replit RevOps 팀원이 평생 코드를 써본 적이 없었지만 아이디어를 가져왔다.
   2. 제작 기간: 이 담당자는 이틀 만에 내부 도구를 만들었다.
   3. 사용 결과: 현재 Replit sales 팀이 실제 고객 영업에 사용한다.

4. Chrome extension에서 데모 artifact까지

   1. 녹화 시작: 영업 담당자가 Chrome extension을 설치하고 특정 제품 흐름을 정한다.
   2. 화면 기록과 주석: 확장 기능으로 화면을 걸어가며 녹화하고 각 요소에 annotate한다.
   3. 재현 가능한 산출물: 완료된 기록은 prospect에게 보여줄 수 있는 demoable artifact가 된다.
   4. 스크립트 기반 운영: 영업 담당자는 정해진 script를 따라가며 모든 고객에게 핵심 장면을 안정적으로 보여준다.

5. 맞춤형 소프트웨어의 레버리지

   1. 비용 절감: 외부 SaaS에 지불할 six-figure 비용을 절약한다.
   2. 로드맵 독립성: 외부 공급자의 roadmap이나 다른 고객 요구를 기다리지 않고 필요한 feature를 바로 추가한다.
   3. Persona 기능: 한 담당자가 “고객 persona마다 서로 다른 demo를 만들고 싶다”고 요청하자 제작자가 persona feature를 추가했다.
   4. 조직 내부 문제 해결: 모든 팀원이 사용할 도구를 만들면 한 사람의 작은 개발이 회사 전체의 운영 효율을 높인다.

3.3. Analytics BI: BigQuery 데이터를 한 사람이 내부 플랫폼으로 만들다

1. 외부 provider를 끊은 이유

   1. 데이터 소유권: 필요한 데이터는 이미 Replit의 BigQuery에 있었다.
   2. 가격과 적합성: 기존 BI analytics provider는 매우 비쌌고 여러 면에서 Replit의 use case를 정확히 충족하지 못했다.
   3. 내부 구축: 외부 서비스에 계속 큰 비용을 내는 대신 동일한 목적의 analytics 도구를 내부에서 만들었다.

2. 내부 플랫폼의 기능

   1. 관리자 포털: 어떤 admin portal을 시간이 지나며 몇 명이 여는지 보여준다.
   2. 시각화: 여러 chart 유형, 비교 기능, time frame 설정을 제공한다.
   3. 분석 기능: funnel, data table, retention chart를 만들 수 있다.
   4. 지능화: 회사 데이터와 사용 패턴을 이해하면서 기능에 intelligence를 점점 더 추가하고 있다.

3. 한 사람의 live coding

   1. 제작자: data scientist 한 명이 live code로 플랫폼을 만들었다.
   2. 능력의 범위: 데이터에 대한 이해는 있었지만 전통적인 coder나 builder는 아니었다.
   3. 제품화 가능성: 충분히 개선하면 Replit 고객에게도 analytics platform으로 제공할 수 있다는 가능성이 제기됐다.

4. 직원 자율성과 10x 레버리지

   1. 자발적 제작 문화: Replit은 직원에게 억지로 만들라고 지시하기보다, 주도성과 agency가 강한 사람들이 스스로 도구를 만든다.
   2. Dogfooding: 직원이 만든 도구를 직접 사용하면 제품에 대한 feedback을 얻는 동시에 운영 효율도 높아진다.
   3. Sales stack의 교체: sales 팀은 Salesforce를 system of record로 남기고 나머지 sales stack의 많은 부분을 자체 도구로 바꿨다.
   4. Peter의 1x·2x·10x 구분: 1x 직원은 맡은 핵심 업무만 하고, 2x 직원은 개인 업무를 개선하는 도구를 만들며, 10x 직원은 팀과 회사 전체가 쓰는 도구를 만든다.
   5. Amol의 정의: 10x의 핵심은 조직 전체에 leverage를 만드는 것이다.

4. 코드 비용이 0이 될 때도 살아남는 SaaS

“코드 비용이 0이 되면 무엇에 돈을 내는가?”라는 테스트를 통과하는 자산이 다음 시대의 방어력을 가진다.

4.1. 생존하는 가치의 다섯 가지 축

1. Trust와 risk taking

   1. 신뢰의 가격: 고객은 단순 UI가 아니라 거래와 업무를 안전하게 처리해 줄 신뢰에 돈을 지불한다.
   2. 규제 위험의 인수: 규제 산업에서 올바르게 처리하고 문제가 생겼을 때 책임지는 능력은 단순 코드 생성으로 대체되지 않는다.

2. Data와 system of record

   1. 소유 데이터: 장기간 축적된 기업 데이터와 이를 공식 기록으로 사용하는 지위는 얇은 UI와 다르다.
   2. Salesforce: Salesforce는 sales 영역의 system of record라서 살아남을 가능성이 높다.
   3. Headless 전환: 사용자가 Salesforce UI를 직접 클릭하지 않아도 다른 도구가 Salesforce 데이터와 API 위에서 작동하는 headless 형태로 남을 수 있다.

3. Infrastructure

   1. 운영 부담: 안정적인 hosting, database, 보안, reliability처럼 계속 운영해야 하는 infrastructure는 가치가 있다.
   2. 서비스 수준: 내부 팀이 만들 수 있는 UI와 달리, 규모·장애·복구·접근권한을 책임지는 운영 체계가 진입장벽이 된다.

4. Atoms와 labor

   1. 현실의 물리성: 소프트웨어 코드가 아닌 actual physical things, 즉 atoms를 다루는 사업은 코드 생성으로 대체할 수 없다.
   2. DoorDash: DoorDash는 사람이 실제 음식을 가져다주는 서비스이므로 가치가 남는다.
   3. 노동의 포함: 앱이 아니라 사람의 노동과 현장 실행이 상품의 핵심이면 화면만 복제해서 같은 가치를 만들 수 없다.

5. Network

   1. Social network: 사용자 관계와 상호작용이 쌓이는 social network는 코드를 사서 하루 만에 복제할 수 없다.
   2. 양면 네트워크: 공급자와 수요자, creator와 local business가 연결된 네트워크는 참여자가 많아질수록 방어력이 강해진다.

4.2. UI에서 API·CLI·MCP로 이동하는 SaaS

1. 사용자 경험의 변화

   1. Workday의 UI: Peter는 누구도 Workday UI를 정말 좋아하지 않는다고 농담했지만, Workday가 맡은 기능 자체의 가치는 인정했다.
   2. 새 접근 계층: SaaS 기업은 API, CLI, MCP를 제공해 사용자가 모든 버튼을 직접 클릭하지 않고도 기능을 호출하게 한다.
   3. Headless SaaS: 화면이 아니라 데이터·기록·규제·운영 계층이 남고, 다른 앱과 Agent가 그 위에 새로운 UI를 만든다.

2. Browser Agent의 영향

   1. 브라우저 조작: Agent가 browser와 computer를 조작할 수 있으면 기존 UI가 가진 접근 제한이 줄어든다.
   2. API 역공학: Agent가 필요에 따라 API를 reverse engineer할 수 있다.
   3. 대리 실행: 사용자를 대신해 SaaS에서 작업을 수행하는 능력은 클릭 중심 제품의 차별화를 약화한다.

5. 모델 계층과 애플리케이션 계층의 승부

모델이 교체 가능한 commodity가 될수록 여러 모델을 안정적으로 조율해 사용자가 실제 목적을 달성하게 하는 애플리케이션의 역할이 커진다.

5.1. App layer가 유리해지는 이유

1. 모델의 commoditization

   1. 초기 우려: Peter는 Anthropic과 OpenAI가 model과 harness를 함께 최적화해 full stack을 장악하면 app-layer 회사가 어려워질 수 있다고 생각했다.
   2. 현재의 변화: 좋은 모델이 많아지면서 한 회사가 모든 사용 사례를 독점하기 어려워졌고, app-layer 회사의 위치가 강해졌다.
   3. 기존 thesis의 실현: 모델이 commoditize될 것이라는 애플리케이션 회사들의 오래된 thesis가 현실화되고 있다.

2. 마지막 1마일의 차별화

   1. 코드 생성만으로 부족: frontier model lab이 코드를 제공해도 실제 고객에게 전달하려면 hosting이 필요하다.
   2. Reliable hosting: 안정적으로 배포하고 운영하는 hosting은 사용자가 체감하는 핵심 가치다.
   3. Production packaging: security, distribution, monetization과 사용자에게 맞는 전체 packaging이 마지막 1마일을 완성한다.
   4. 사용자 지불 대상: 사용자는 raw model output이 아니라 자신이 있는 곳까지 결과물을 가져다주는 패키징에 돈을 낸다.

5.2. Model-agnostic 전략

1. 최신 모델 교체에 대응

   1. 변화 속도: 최근 몇 주 사이에도 Qwen과 Kimi가 논의를 바꿀 만큼 latest-and-greatest 모델이 빠르게 달라진다.
   2. 한 바구니 위험: enterprise와 consumer 모두 한 model provider에 모든 것을 걸고 싶어 하지 않는다.
   3. 간접 계층: app layer가 모델을 추상화하면 모델이 바뀌어도 워크플로와 사용 경험을 유지할 수 있다.

2. 비용 최적화

   1. Token maxing의 종말: 무조건 가장 큰 모델을 쓰는 token maxing은 끝나고 있다.
   2. 업무별 선택: 어떤 업무에는 최고급 frontier model을 쓰고, 다른 업무에는 훨씬 저렴한 모델을 쓴다.
   3. Kimi 사례: Kimi가 같은 작업을 10분의 1 비용으로 처리할 수 있다면 그 업무에는 Kimi를 선택할 수 있다.

3. Resilience와 정책 대응

   1. 장애 분산: 단일 provider가 다운되는 일이 이미 있었으므로 한 곳에 의존하면 서비스가 멈출 수 있다.
   2. 가격 변화: 모델 가격은 계속 바뀌어 특정 공급자의 요금 정책에 묶일 위험이 있다.
   3. 정책 변화: provider의 policy가 바뀌어도 고객은 갑자기 전체 제품을 다시 설계하고 싶어 하지 않는다.
   4. Orchestration 계층: model-agnostic app이 여러 AI workflow를 조율하고 그 위에 제품을 만들면 최신 모델·비용·복원력을 함께 관리할 수 있다.

5.3. Frontier model과 저가 sub-agent의 역할 분담

1. 작업 난이도별 모델 배치

   1. 어려운 부분: frontier model은 제품의 planning, architecture와 같이 깊은 추론이 필요한 어려운 부분을 맡는다.
   2. 반복 작업: orchestrator는 더 저렴한 모델에서 실행되는 sub-agent에 기능 구현과 반복 작업을 위임한다.
   3. 비용과 성능의 균형: 모든 작업에 최고가 모델을 쓰지 않고 난이도에 따라 모델을 배치하면 성능을 유지하면서 비용을 줄인다.

2. 기업의 평가 기준 변화

   1. Leaderboard의 퇴장: 기업은 더 이상 token max leaderboard에서 누가 1등인지에만 집중하지 않는다.
   2. ROI 중심: 비용 대비 실제 생산성·매출·운영 개선이라는 ROI의 R(Return)이 중요해졌다.
   3. 측정의 어려움: ROI는 기능과 팀마다 달라 token 비용만으로 계산하기 어렵다.
   4. 농담: Peter는 작은 문제에 거대한 모델을 쓰는 상황을 “화염방사기로 담배에 불을 붙이는 것”에 비유했고, 두 사람은 웃었다.

6. 마무리: AI를 넓은 경제 생태계에 배치하는 낙관론

6.1. 좋은 가격으로 최신 AI를 쓰는 사회

1. 기업 전체의 이익

   1. 접근성 확대: 미국 기업들이 최신 AI를 좋은 가격에 사용할 수 있도록 하는 경쟁은 AI 발전의 혜택을 넓힌다.
   2. 앱 계층의 역할: 여러 모델을 선택하고 운영에 연결하는 앱은 기업이 기술 변화를 따라가도록 돕는다.
   3. 국가적 낙관론: Amol은 모든 기업이 AI를 사용할 수 있는 환경이 미국 경제 생태계와 국가 전체에 좋을 것이라며 미래를 매우 낙관적으로 봤다.

2. 창업자에게 주는 결론

   1. 지금 만들기: 코딩을 배운 뒤 시작할 때를 기다리기보다 자신이 잘 아는 문제를 AI로 build해야 한다.
   2. 완성의 기준: prototype을 만든 뒤 publish, security, payment, SEO, distribution을 붙여 실제 사업으로 전환해야 한다.
   3. 오디언스의 누적: 한 번의 제품 성공보다 신뢰할 수 있는 audience와 domain expertise를 쌓는 것이 여러 번의 사업을 가능하게 한다.

6.2. Replit을 선택하게 된 개인적 계기와 작별 인사

1. Amol의 aha moment

   1. 첫 경험의 충격: Amol은 Replit을 처음 사용했을 때 “aha moment”를 느꼈다.
   2. 부모 휴가 중 결정: 당시 parental leave 중이었지만 그 경험 때문에 휴가에서 나와 Replit에 연락하고 합류했다.
   3. 제품 경험의 힘: 새로운 도구가 단순히 편리한 정도를 넘어 진로 결정을 바꿀 만큼 강한 product moment가 될 수 있다.

2. 마지막 대화

   1. Amol의 초대: Amol은 사람들이 Replit을 replit.com에서 직접 써보고 entrepreneur와 creator에게 좋은 시기인 만큼 무언가를 만들라고 권했다.
   2. Peter의 목표: Peter는 더 많은 것을 만들고 실제 사업으로 바꾸고 싶다며 “잠자는 동안 돈을 벌 수 있기를” 바란다고 말했다.
   3. Amol의 응원: Amol은 Peter가 audience를 이미 확보했으니 잠자는 동안 돈을 벌 수 있을 것이라고 응원했다.
   4. 감사 인사: Peter는 Amol과 팀이 훌륭한 제품을 만드는 데 감사하며, Amol은 대화를 나눠 준 Peter에게 고마움을 전했다.

Riverside 협찬 구간

녹화부터 배포까지의 creator workflow

1. 기록 품질

   1. 4K 로컬 녹화: Riverside는 각 참여자를 로컬에서 4K로 녹화하므로 게스트의 Wi-Fi가 불안정해도 audio와 video가 깨끗하게 남는다.
   2. 다자간 안정성: 인터넷 연결 품질과 무관하게 각 사람의 원본을 따로 확보해 podcast 품질을 지킨다.

2. AI 편집과 재활용

   1. 불필요한 부분 제거: AI tool로 pause와 filler word를 제거하고 recording을 정리할 수 있다.
   2. Transcript 직접 편집: transcript를 직접 고치면 녹화물도 그에 맞춰 편집된다.
   3. 자동 클립: caption이 붙은 clip을 자동으로 만들어 YouTube, Spotify, social media에 바로 게시할 수 있다.
   4. 1인 creator business: 한 사람이 콘텐츠 사업을 운영할 때 녹화·편집·배포를 한곳에서 처리하는 점이 중요하다.
   5. 프로모션: Riverside는 creators.riverside.com/peteryang에서 제공되며 checkout에서 Peteryang 코드를 사용하면 한 달을 무료로 쓸 수 있다고 안내했다.

주요 발언 모음

“If the cost of code goes to zero, what do you pay for?”

“코드 비용이 0이 되면 무엇에 돈을 내는가?”

“It’s the unique judgment or taste. It’s the security. It’s the distribution.”

“고유한 판단과 취향, 보안, 유통에 돈을 낸다.”

“Users are inherently lazy. If you offer them value, they will pay for it.”

“사람은 본질적으로 게으르다. 가치를 제공하면 돈을 지불한다.”

“The 10x definition is creating leverage for the whole company.”

“10x의 정의는 회사 전체에 leverage를 만드는 것이다.”

“Token maxing is coming to an end.”

“Token maxing은 끝나고 있다.”

“It’s a great time to be an entrepreneur or a creator. Go build something.”

“지금은 entrepreneur와 creator에게 좋은 시기다. 무언가를 만들어라.”

핵심 데이터 & 수치

• 36분 06초: 전체 콘텐츠 길이다.
• 22세: Pep AI를 만든 Cedric의 나이다.
• 0년: Cedric과 John, RevOps 제작자는 기존 코딩 경험 없이 제품을 만들었다.
• $60,000: Pep AI가 첫 달에 만든 매출이다.
• 수만 명: Pep AI의 active user 규모다.
• $100,000 이상: John이 agency에서 받은 플랫폼 개발 견적이다.
• 3일: John이 AI proficiency·certification 플랫폼을 end-to-end로 구축한 기간이다.
• 2개월: John의 출시 후 첫 $180,000 이상 매출에 도달한 기간이다.
• $180,000 이상: AI proficiency 플랫폼의 첫 2개월 누적 매출이다.
• YC Summer 2026: TryNearby가 참여한 Y Combinator 배치다.
• $100,000 이상 ARR: TryNearby의 마지막 확인 시점 연간 반복 매출이다.
• 10분: Replit의 live demo에서 security scan이 완료되기까지 걸릴 수 있는 시간이다.
• 1~2주: 과거 외부 보안팀이 앱을 검사하고 보고서를 돌려주는 데 걸리던 기간이다.
• 이틀: RevOps 담당자가 Chrome extension 기반 sales demo 도구를 만든 기간이다.
• 6자리 달러 비용: 외부 demo 도구와 일부 BI·SaaS의 비용이 쉽게 도달하는 규모다.
• BigQuery: Replit이 이미 보유한 데이터 저장소로, 내부 analytics를 만드는 기반이 됐다.
• 월 $100 또는 연간 요금: interview coach에 추가하려 한 예시 subscription 가격이다.
• 1/10 비용: Kimi 같은 저렴한 모델이 특정 작업에서 frontier model 대비 제공할 수 있는 비용 이점의 예시다.
• 4K: Riverside의 참여자별 로컬 녹화 품질이다.

결론 및 시사점

1. 자신의 고유한 우위를 먼저 찾는다: 코드나 앱 아이디어보다 특정 산업·커뮤니티·직업의 문제를 깊이 이해하는 domain expertise, judgment, taste가 먼저다.
2. 작은 TAM을 두려워하지 않는다: 100명에서 수백 명의 고객만 있어도 반복 매출과 경제적 이동성을 만들 수 있으며, 거대한 벤처 규모가 유일한 성공 기준은 아니다.
3. AI를 구현 계층으로 활용한다: 비개발자는 Replit 같은 AI builder로 구현 문제를 해결하고, 자신이 잘하는 제품 감각·판매·유통·서비스에 집중한다.
4. 앱을 네 단계로 완성한다: raw prototype 뒤에 publish와 도메인, Security Center 기반 점검, Stripe monetization, SEO·answer engine·audience distribution을 순서대로 붙인다.
5. 보안은 배포 전후에 반복한다: API key, malicious package, secret, PII 저장 오류는 코드가 작아도 치명적이며, threat model과 recurring scan으로 점검해야 한다.
6. 기존 오디언스는 복리로 쌓인다: 신뢰를 가진 creator는 한 제품이 실패해도 다음 제품을 출시할 수 있어 audience가 durable asset이 된다.
7. 내부 도구는 직원의 업무 레버리지가 된다: 개인용 자동화를 팀용·회사 전체용 시스템으로 확장하면 10x 수준의 생산성 향상을 만들 수 있다.
8. SaaS의 미래 가치를 다시 계산한다: 단순 UI는 직접 복제되지만 trust, proprietary data, infrastructure, regulated risk, atoms, labor, network는 계속 비용을 받을 수 있다.
9. 모델을 고정하지 않는다: frontier model은 어려운 planning과 architecture를 담당하고, 값싼 sub-agent는 반복 구현을 담당하게 해 성능·가격·복원력을 조절한다.
10. 최종 승자는 사용자의 마지막 1마일을 해결하는 제품이다: 모델 출력 자체보다 reliable hosting, security, payment, discovery, distribution, workflow orchestration과 실제 서비스가 사용자의 지불 의사를 만든다.

핵심 요약 (20줄)

1. 코드 비용이 0에 가까워질수록 고객은 코드 자체보다 전문성·판단력·신뢰·보안·유통에 돈을 지불한다.
2. 22세 대학생 Cedric은 코딩 경험 없이 펩타이드와 GLP-1 추적 앱 Pep AI를 만들어 첫 달 $60,000를 벌었다.
3. Pep AI는 수만 명의 active user를 확보했고 subscription으로 매출을 만들며 매일 성장하고 있다.
4. 반복 창업자 John은 AI 숙련도 측정·인증 플랫폼에 대한 $100,000 이상 외주 견적을 거절하고 직접 만들었다.
5. John은 Replit으로 3일 만에 플랫폼을 end-to-end로 구축했고 출시 후 2개월 안에 $180,000 이상 매출을 올렸다.
6. John의 제품 감각과 판매·유통 능력은 부족한 코딩 역량을 AI builder로 보완하면서 사업 성과로 이어졌다.
7. FaZe Apex Yusuf는 게임 스트리밍으로 쌓은 크리에이터 오디언스를 지역 사업자와 지역 크리에이터를 연결하는 TryNearby로 확장했다.
8. TryNearby는 YC Summer 2026에 참여했고 마지막 확인 시점에 $100,000 이상 ARR을 기록했다.
9. meal planner와 exercise tracker 같은 범용 기능은 누구나 복제하거나 Agent로 대체할 수 있어 빠르게 commoditize된다.
10. pool cleaner·nurse·jeweler처럼 현장 문제를 잘 아는 사람은 작더라도 번성하는 틈새 사업을 만들 수 있다.
11. 사용자는 모든 과정을 직접 처리하려 하지 않으므로 시간과 노력을 줄이는 가치 있는 서비스에 기꺼이 돈을 낸다.
12. 제품 관리 인터뷰 코치는 제품 전문가 네트워크와 지원자를 연결해 CIRCLES 암기를 넘어 실제 피드백을 제공하도록 설계됐다.
13. raw prototype은 도메인과 hosting을 붙여 publish하고, API key·악성 패키지·secret·PII를 Security Center로 점검해야 한다.
14. Stripe sandbox와 Agent를 활용하면 초보자도 월별·연간 subscription을 테스트한 뒤 live 결제로 전환할 수 있다.
15. SEO Agent는 Google 검색뿐 아니라 ChatGPT 같은 answer engine에서 제품이 발견되도록 distribution의 첫 단계를 지원한다.
16. Replit RevOps 담당자는 코딩 경험 없이 이틀 만에 Chrome extension 기반 sales demo 도구를 만들어 여섯 자리 SaaS 비용을 줄였다.
17. Replit은 BigQuery 데이터를 활용해 chart·funnel·data table·retention을 제공하는 내부 BI analytics 도구를 한 명의 data scientist와 구축했다.
18. Salesforce의 기록 데이터, Workday의 규제 급여 처리, DoorDash의 사람과 물리적 배송, social network의 관계망은 단순 UI보다 오래 살아남는다.
19. frontier model은 어려운 planning을 맡고 저렴한 sub-agent는 반복 작업을 맡는 model-agnostic orchestration이 비용과 복원력을 높인다.
20. 지금은 고유한 문제를 아는 entrepreneur와 creator가 AI로 만들고 보안·결제·유통을 붙여 실제 사업을 시작하기 좋은 시기다.