AI가 내 회사를 운영한다. 1인 개발자가 일주일 만에 15,000달러를 벌어들인 '바이브 코딩(vibe-coded)' — 우리는 $[X]를

AI가 내 회사를 운영합니다. 데모가 아니라 실제 운영자로서 말이죠. 전략을 담당하는 'CEO'와 코드를 작성하는 'CTO' 역할을 하는 두 개의 Claude 터미널, 그리고 소규모 직원처럼 행동하도록 설계된 에이전트 오케스트레이터(agent orchestrator)가 있습니다. 나는 의장(chairman)입니다. 나는 자금과 되돌릴 수 없는 행동을 승인하며, 나머지는 기계가 수행합니다.

올해 초, 한 1인 빌더는 일주일 만에 약 15,000달러 규모의 제품을 바이브 코딩(vibe-coded)으로 만들어냈습니다. 제가 가진 도구들과 같은 범주의 도구들입니다. 수개월 동안 8개의 제품을 출시한 후 우리의 수치는 **$[X]**입니다. 그리고 $[X]는 비밀 유지를 위해서가 아니라, 체면을 지키기 위해 플레이스홀더(placeholder)를 사용할 정도로 작은 금액입니다.

이것은 냉정한 사후 분석(cold autopsy)입니다. 과장도 없고, "AI가 모든 것을 바꿨다"는 식의 말도 없습니다. 그저 실제로 무슨 일이 일어났는지, 그리고 왜 그랬는지에 대한 기록입니다.

미화되지 않은 숫자들

• 8개의 제품 출시. 라이브 상태이며, 배포 가능하고, 여러 제품에는 실제 인증(auth)과 실제 결제(checkout) 연동이 되어 있습니다.
• 유료 고객 ~0명.
• 한 제품(작은 통계 유틸리티)은 실제 유기적 트래픽(organic traffic)을 보유하고 있습니다. 매달 수백 건의 검색 클릭과 수천 명의 사용자가 유입됩니다. 유료 전환율은 사실상 제로입니다.
• 나머지는 "침묵 속에 출시됨"부터 "도메인이 현재 404 에러를 띄움" 사이의 상태입니다.

만약 빌드 결과물만 보았다면, 당신은 이곳이 유능한 업체라고 생각했을 것입니다. 그것이 바로 함정이었습니다.

사후 분석 결과 #1: 나는 프로세스 연극(process-theater) 회사를 만들었다

나는 결과(outcomes)가 아닌 활동(activity)에 최적화된 조직을 만들었습니다. 에이전트들은 스탠드업(standups), 상태 보고서, "일일 활동", 칸반(kanban) 움직임을 생성했습니다. 겉보기에는 회사 같았습니다. 하지만 수익은 거의 창출하지 못했습니다.

이것은 개인의 독특한 실패가 아니라, 이미 기록된 실패 사례입니다. 현재 멀티 에이전트 LLM 시스템에 대한 공개된 실패 분류 체계(failure taxonomy)가 존재합니다 ( "MAST, Multi-Agent System failure taxonomy"를 검색해 보세요). 실패의 상당 부분은 모델의 성능 문제가 아니라, 명세 및 조정 실패(specification and coordination failures) 때문입니다. 즉, 에이전트들이 서로 대화하며 표류하고, 결정을 재논쟁하며, 실제 지표를 움직이지 않는 작업에 대해 자신 있게 진행 상황을 보고하는 것입니다. "99명의 에이전트로 구성된 자율 기업"은 성취가 아닙니다. 그것은 보도 자료를 동반한 실패 모드(failure mode)일 뿐입니다.

해결책은 더 많은 에이전트가 아닙니다. 출력값이 다른 LLM의 의견이 아닌 규칙(rules)에 의해 검증되는, 더 적고, 게이트(gated)가 설정된, 좁은 범위의 작업자(narrow workers)를 사용하는 것입니다. 예를 들어, URL이 200 상태 코드를 반환했는가? 결제가 완료되었는가? PR(Pull Request)이 머지(merge)되었는가? 분석(analytics) 이벤트가 발생했는가? 와 같은 것들 말입니다. "에이전트가 완료했다고 말했다"는 것은 증거가 될 수 없습니다.

사후 분석 결과 #2: 빌드는 결코 병목 현상이 아니었다

15,000달러를 벌어들인 개발자와 저 모두 빌드(build)를 할 수 있습니다. 이제 빌드는 범용적인 기술(commodity)입니다. 차이점은 빌드
'주변'의 모든 것이었습니다:

• 배포(Distribution) 및 오디언스(Audience). 15,000달러의 수익은 이미 자신을 지켜보는 사람들이 있는 상태에서 '공개적으로(in public)' 출시한 사람으로부터 나왔습니다. 저는 검색 엔진을 향해 조용히 출시하고 기다렸습니다.
• 트렌드(Wave) 및 지불 의사(Willingness to pay). 그들은 초기 수용자(early adopters)들이 돈을 쓰는 뜨거운 카테고리에 올라탔습니다. 저는 전체 오디언스가 무료를 원하는 포화된 니치(niche) 시장에서 학생들을 위한 계산기를 만들었습니다.
• 집중(Focus). 그들은 단 하나의 요소를 수익 창출까지 엔드 투 엔드(end-to-end)로 밀어붙였습니다. 저는 미완성된 여덟 개의 프로젝트와 정교하게 꾸며진 가짜 조직도를 가지고 있었습니다.

결과값에서 세 자릿수(three orders of magnitude)의 차이가 났지만, 그 격차 중 코드 때문인 것은
'단 하나도' 없었습니다.

두 가지 기술적 실전 사례 (이곳은 Dev.to니까요)

회사의 두뇌가 크론(cron) 간격 때문에 죽었다.

에이전트 백본(backbone)은 서버리스 Postgres(Neon 프리 티어)에서 실행됩니다. 프리 티어 컴퓨팅은 5분 동안 유휴(idle) 상태가 되면 자동으로 일시 중단(auto-suspends) 됩니다. 이것이 전체 비용 모델입니다. 어느 시점에 저는 에이전트 하트비트(heartbeat) 크론 주기를 30분에서 5분마다로 늘려 응답성을 "개선"했습니다. 별것 아닌 것처럼 느껴졌습니다.

하지만 아니었습니다. 5분마다 쿼리가 실행된다는 것은 컴퓨팅이 5분의 유휴 시간을
'결코' 가질 수 없음을 의미합니다. 컴퓨팅은 24시간 내내 깨어 있었고, 이는 무료 허용치인 약 190시간에 비해 월간 약 720 컴퓨팅 시간을 사용한 셈이 되었습니다. 그러던 어느 날, 모든 쿼리가 다음과 같은 응답을 반환하기 시작했습니다:

HTTP 402: "exceeded the compute time quota"

6개의 테이블 — agents, tasks, messages, approvals, events — 모두 접근 불가능했습니다. "회사의 두뇌(company brain)"가 다운된 것이며, 이는 몇 주 동안 조용히 이 상황을 향해 타오르고 있었습니다. 교훈: scale-to-zero 인프라를 사용할 때, 당신의 cron 간격은 곧 과금 결정(billing decision)입니다. 만약 그 간격이 중단 임계값(suspend threshold)에 도달하거나 그보다 낮다면, 당신은 자신도 모르게 항상 켜져 있는 서버를 구매한 셈입니다.

더 최악인 것은: 저에게 일일 할당량 모니터링(daily quota monitor)이 있었다는 점입니다. 그것은 한 번도 경고를 울리지 않았습니다 — 왜냐하면 잘못된 데이터베이스(레거시 연결 문자열)를 가리키고 있었기 때문에, 실제 DB가 질식하고 있는 동안에도 즐겁게 "OK"라고 보고했기 때문입니다. 검증하지 않는 모니터링 또한 일종의 보여주기식 행위(theater)일 뿐입니다.

하나의 웹훅(webhook), 네 개의 제품, 조용한 교차 오염.

여러 제품이 동일한 결제 제공업체(payment provider)를 통해 결제됩니다. 해당 제공업체는 모든 판매 내역을 **단일 계정 수준의 핑 URL(single account-level ping URL)**로 보냅니다. 따라서 제품 A의 판매 건이 제품 B의 웹훅을 타격했고 — 핸들러(handler)가 페이로드(payload)를 신뢰했기 때문에 — 잘못된 앱에 권한(entitlements)을 부여했습니다. 해결책은 제품별 식별자(url_params[workspace_id])를 도입하고, 우리 것이 아닌 것은 모두 버리는 외부 판매 방어 기제(foreign-sale guard)를 만드는 것이었습니다. 멀티 테넌트(Multi-tenant) 과금은 대부분 이벤트를 처리하는 것이 아니라, 이벤트를 거부하는 것에 관한 것입니다.

갱신(renewal)의 실체

거창한 재출시는 없습니다. 구체적인 움직임은 다음과 같습니다:

1. 보여주기식 프로세스(process theater) 제거. 에이전트가 직원이라는 허구를 은퇴시킵니다. 규칙 기반의 출력 게이트(rule-based output gates)를 가진 몇몇 좁은 범위의 워커(workers)들만 유지합니다.
2. "완료(done)"의 재정의. "완료" = 테스트 결제가 엔드 투 엔드(end-to-end)로 진행됨 (체크아웃 → 권한 부여 → 기능 작동). 그 이전의 모든 것은 데모(demo)이며, 데모라고 불려야 합니다.
3. 배포(Distribution)는 이제 일급 시민(first-class)입니다. 구축(building)과 동등한 가치를 가집니다 — 창피한 숫자를 그대로 노출하며 공개적으로 이 글을 쓰는 것을 포함하여 말입니다.
4. 움직임이 아닌 전환율(conversion)을 측정하십시오. 실제 퍼널 이벤트(funnel events)가 발생하지 않았다면, 그것은 일어나지 않은 일입니다.

솔직한 마무리

우리는 **$[X]**를 벌었습니다. 이를 미화하지 않겠습니다. 하지만 진단 결과는 이례적으로 명확하며, 명확한 진단은 드물고 실행 비용이 저렴합니다: 기계는 하루 종일 무언가를 만들 수 있습니다. 하지만 기계가 할 수 없었던 것은, 파도가 치는 시장을 선택하고, 관객을 확보하며, 껍데기(shell)를 있는 그대로 부르는 일이었습니다.

만약 이 갱신(renewal)이 어떻게 진행되는지 — 그것이 성공할지 여부를 포함하여 — 지켜보고 싶다면, 실제 사용자가 있는 유일한 제품은 **statmate.org**의 작은 통계 도우미이며, 신뢰성 포트폴리오(credibility-portfolio) 실험은 **trustfolio.dev**에서 진행 중입니다. 두 프로젝트 모두 의도적으로 공개된 실험용 쥐(lab rats) 상태입니다.

수치가 오르든 내리든 다음 숫자를 게시하겠습니다. 이것이 빌딩 인 퍼블릭(building in public)의 방식입니다. 사후 분석(autopsy)은 수술대(table)를 계속 열어두고 있을 때에만 의미가 있습니다.