
AI가 상점을 여는 것을 지켜보며 배운 5가지 교훈 — Vibe Coding에서 Vibe Business로의 전환
요약
Vibe Coding 도구가 소프트웨어 생산 속도를 높여주지만, 실제 운영 가능한 비즈니스 시스템 구축에는 한계가 있음을 지적합니다. 단순 코드 생성을 넘어 결제, 재고 관리 등 비즈니스 로직을 통합하는 'Vibe Business'로의 패러다임 전환과 멀티 에이전트 아키텍처의 필요성을 강조합니다.
핵심 포인트
- Vibe Coding은 개발 진입장벽을 낮추지만 비즈니스 완성도는 낮음
- 단순 코드 생성을 넘어 결제, 재고 등 비즈니스 계층 통합 필요
- 멀티 에이전트 스웜 아키텍처를 통한 비즈니스 자동화 지향
- 코딩 도구에서 비즈니스 생성 도구로의 전환 강조
개발자의 92%가 이미 일상적인 워크플로우 (workflow)에서 AI 코딩 도구를 사용하고 있습니다. BuildEZ의 이 통계는 몇 달 전부터 더 이상 놀라운 일이 아니게 되었습니다. 그것은 이제 그저 현실일 뿐입니다. 하지만 제 주의를 끌었던 숫자가 하나 있습니다. 중국에만 1,600만 개 이상의 1인 기업이 존재하며, 이는 전체 기업의 27.4%를 차지한다는 사실입니다. 그리고 AI 에이전트 (AI agents)를 활용하면
이 차이점은 매우 중요하기 때문에 구체적으로 설명하겠습니다.
Vibe Coding 도구들 — Cursor, Bolt.new, Lovable, Replit Agent — 는 한 가지 문제를 아주 훌륭하게 해결합니다: 바로 "나는 코드를 작성할 수 없다"는 문제입니다. 이 도구들은 소프트웨어를 생산하는 속도를 극적으로 높여줍니다. 하지만 Karpathy 본인도 인정한 사실이 있습니다: "Vibe Coding은 바닥(floor)을 높여줄 뿐, 천장(ceiling)을 높여주지는 않는다." 그 결과물은 페이지와 데모일 뿐, 운영 가능한 비즈니스 시스템이 아닙니다.
저는 이 도구들로 수많은 프로젝트를 만들어 보았지만, 매번 똑같은 벽에 부딪혔습니다: AI가 완성된 것처럼 보이는 무언가를 생성하지만, 실제로는 그렇지 않다는 점입니다. 결제 처리(payment processing)가 없습니다. 재고 관리(inventory management)도 없습니다. 고객 커뮤니케이션 계층(customer communication layer)도, 공급망(supply chain)도 없습니다. AI는 고립된 상태에서는 작동하는 코드를 작성하지만, 현실 세계와는 연결되지 않습니다.
Codeflying은 근본적으로 다른 가설 위에서 작동합니다. "어떻게 코드를 생성할 것인가?"를 묻는 대신, "어떻게 비즈니스를 생성할 것인가?"를 묻습니다.
실제 적용 사례는 다음과 같습니다:
| 차원 (Dimension) | Vibe Coding 도구 | Codeflying (Vibe Business) |
|---|---|---|
| 핵심 문제 (Core problem) | "코딩을 할 수 없다" | "비즈니스를 운영할 수 없다" |
| ... | ... | ... |
그 이면에 있는 3계층 아키텍처 (The Three-Layer Architecture Behind It)
저는 그들의 기술적 접근 방식을 깊이 파고들었습니다. 왜냐하면 그 "방법(how)"이 무엇이 실제로 새로운 것인지를 보여주기 때문입니다. Codeflying은 멀티 에이전트 스웜 아키텍처 (multi-agent swarm architecture) — 그들은 이를 "벌 군집 (bee colony)" 프레임워크라고 부릅니다 — 위에서 작동하며, 여기서는 전문화된 AI 에이전트 (AI agents)들이 단순히 코드를 생성하는 대신 서로 다른 비즈니스 역할을 수행합니다.
에이전트 아키텍처는 실제 비즈니스 기능과 직접적으로 매핑됩니다:
agents:
- name: "Requirement Analysis Agent"
role: "자연어 비즈니스 설명을 구조화된 사양(specs)으로 변환"
...
각 에이전트는 단순히 시스템 프롬프트만 다른 범용 챗봇 (generic chatbot)이 아니라, 정의된 책임, 지식 경계, 그리고 인수인계 프로토콜 (handoff protocols)을 가지고 있습니다. 이것은 Karpathy의 에이전틱 엔지니어링 (Agentic Engineering) 비전이 코드 생성이 아닌 커머스 (commerce)에 적용된 사례입니다.
하지만 진정한 해자 (moat)는 에이전트 아키텍처가 아닙니다. 바로 공급망 통합 (supply chain integration)입니다.
아무도 말하지 않는 공급망 계층 (The Supply Chain Layer Nobody Talks About)
Codeflying에 대해 처음 들었을 때, 저는 공급망 (Supply Chain)이 그저 멋진 마케팅용 슬라이드에 불과하다고 생각했습니다. 하지만 설립 팀인 세 명의 전 Tencent 엔지니어들이 상인들을 모집하기 위해 2026년 4월에 이우 국제 무역 시장 (Yiwu International Trade Market)에 직접 발로 뛰며 갔다는 글을 읽었습니다.
그들은 근본적인 불일치를 발견했습니다. 수천 명의 이우 도매업자들은 풍부한 제품 재고를 보유하고 있지만 디지털 판매 채널이 없는 반면, 수백만 명의 일반 사람들은 온라인으로 판매하고 싶어 하지만 실제 도매 공급망에 접근할 방법이 없다는 점입니다. Codeflying은 공급업체 관계를 플랫폼에 직접 내재화함으로써 그 간극을 메웁니다.
이것이 바로 제가 SCaaS — 서비스형 공급망 (Supply Chain as a Service)이라고 부르는 것입니다. 이는 복제하기 가장 어려운 부분입니다. 모델은 매달 개선됩니다. 에이전트 아키텍처 (Agent architectures)는 복제됩니다. 하지만 당신의 플랫폼을 믿고 주문을 이행할 실제 상인들의 네트워크는 어떨까요? 그것은 시간과 관계, 그리고 현장에서의 직접적인 노력이 필요합니다.
Andrej Karpathy의 프레임워크 — Vibe Coding → 에이전트 공학 (Agentic Engineering) → 소프트웨어 3.0 (Software 3.0) — 는 AI가 소프트웨어 제작을 어떻게 변화시키는지 훌륭하게 보여줍니다. 하지만 여기에는 사각지대가 있습니다. 이러한 프레임워크 중 그 어느 것도 소프트웨어가 구축된 후 누가 비즈니스를 운영하는지에 대해서는 답하지 않습니다. 누가 고객을 응대합니까? 누가 주문을 관리합니까? 무언가 잘못되었을 때 누가 책임을 집니까?
Vibe Business는 그 간극을 채웁니다. 이는 Vibe Coding을 대체하는 것이 아니라, 운영 계층 (Operational layer)으로 확장하는 것입니다.
이것이 우리가 구축하는 방식에 의미하는 바
저는 우리가 AI 제품을 평가하는 방식의 변곡점을 목격하고 있다고 생각합니다. 과거의 기준은 생성 품질 (Generation quality)에 관한 것이었습니다. 얼마나 빨리 구축하는지, 코드가 얼마나 깨끗한지, 얼마나 많은 프레임워크를 지원하는지 등이었습니다. 새로운 기준은 비즈니스 완결성 (Business closure)에 관한 것입니다. 고객을 확보할 수 있는가? 주문을 처리할 수 있는가? 풀필먼트 (Fulfillment)를 처리할 수 있는가? 데이터를 보여줄 수 있는가?
제가 추적하고 있는 사고 모델 (Mental model)의 변화는 다음과 같습니다:
Vibe Coding (2025) → 자연어로 코드 작성
Agentic Engineering (2026) → AI 에이전트로 신뢰할 수 있는 소프트웨어 구축
Vibe Business (2026→) → AI 운영으로 실제 비즈니스 운영
사용자 층 또한 극적으로 변화합니다: 개발자(Developers) → 전문 엔지니어(Professional engineers) → 일반인(Regular people).
Karpathy가 Sequoia의 AI Ascent 2026에서 연설했을 때, 그는 흥미로운 프런티어(Frontier)가 더 나은 코드 생성(Code generation)이 아니라 복잡한 환경에서 자율적으로 행동할 수 있는 AI 시스템이라고 언급했습니다. AI 에이전트(AI agents)가 판매, 지원 및 운영을 처리하며 스스로 운영되는 상점 — 그것이 바로 그가 설명하고 있는 복잡한 환경의 전형입니다.
실질적인 리스크
이 내용을 과장하고 싶지는 않습니다. 다음과 같은 실질적인 우려 사항들이 존재합니다:
플랫폼 리스크 (Platform risk): 만약 Pinduoduo, Douyin (TikTok의 중국 형제 서비스), 또는 Meituan이 유사한 AI 기능을 내장하기로 결정한다면, 그들은 거대한 기존 가맹점 네트워크와 사용자 기반을 보유하고 있습니다. 1,500만 달러의 투자를 받은 스타트업이 그들과 쉽게 경쟁하기는 어렵습니다.
공급망 깊이 (Supply chain depth): 이우(Yiwu)는 하나의 시장일 뿐입니다. 선전(Shenzhen)의 전자제품, 광저우(Guangzhou)의 의류, 또는 크로스보더(Cross-border) 카테고리로 확장하는 것은 거대한 운영상의 도전 과제입니다.
콜드 스타트 문제 (Cold start problem): Codeflying은 양측 모두에서 동시다발적인 성장이 필요합니다 — 즉, 상점을 열고 싶어 하는 사용자와 주문을 이행할 의사가 있는 판매자(Merchants)입니다. 양면 시장(Two-sided marketplaces)은 초기 구축(Bootstrap)이 매우 어려운 것으로 악명이 높습니다.
동질화 (Homogenization): 만약 AI가 유사한 제품에 대해 유사해 보이는 상점들을 생성한다면, 개별 판매자의 경쟁 우위는 약화될 것입니다.
하지만 제가 계속해서 되돌아오게 되는 지점은 이것입니다: 실행 세부 사항이 불확실할지라도 방향은 옳다는 것입니다. 1인 기업을 운영하는 비용이 92% 감소할 때, 창업을 고려해 본 적 없던 수백만 명의 사람들이 실행 가능한 비즈니스 운영자가 됩니다. Codeflying이 중요해지기 위해 그 시장의 100%를 점유할 필요는 없습니다 — 그저 모델이 작동한다는 것을 증명하기만 하면 됩니다.
더 큰 질문
만약 AI가 완전한 상점을 생성하고 운영을 도울 수 있다면, "상점을 여는 것"은 "웹사이트를 구축하는 것"과 같아질까요 — 과거에는 전문 기술이 필요했지만 이제는 인프라(Infrastructure)가 되어버린 무언가 말입니다?
제 생각에는 그렇습니다. 그리고 이는 대부분의 사람들이 예상하는 것보다 더 빠르게 일어날 것이라고 생각합니다. 1인에 의해 설립된 중국 신규 기업의 36.3%라는 수치는 우연이 아닙니다. 이는 선행 지표 (Leading indicator)입니다. 도구 (Tooling)가 충분히 좋아지면, 1인 창업 (Solo entrepreneurship)은 기본값이 됩니다.
진정한 기회는 Cursor보다 더 나은 코드 생성기 (Code generator)를 만드는 것이 아닙니다. 프로그래밍 도구의 혜택을 전혀 받지 못했던 사람들의 삶 속으로 AI를 가져오는 것입니다. AI가 사람들이 상점을 열고, 고객에게 서비스를 제공하며, 돈을 버는 것을 돕기 시작할 때 — 그때가 바로 AI가 진정한 인프라 (Infrastructure)가 되는 시점입니다.
참고 문헌: Karpathy의 Vibe Coding (baoyu.io), Agentic Engineering 발표 (36kr), Sequoia AI Ascent 2026에서의 Karpathy (QQ News), 92% 개발자 통계 (BuildEZ), Codeflying 정보 (Baidu Baike, Official), 1인 기업 통계 (Tencent Cloud), Pre-A 펀딩 (Pedaily), Yiwu AI 상점 출시 (Pedaily), Software 3.0 개요 (51CTO).
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기