The New Startup Playbook: 에이전트를 다루는 3~10명 팀이 예전엔 수지 안 맞던 일까지 해내는 방식

에이전트를 쓰는 작은 팀은 사람을 덜 쓰는 데서 그치지 않고, 사람을 쓰기엔 너무 비싸 미뤄 둔 일까지 하게 됩니다. 기업이 이 효과를 보려면 인력 감축부터 계산하지 말고 검토 역량과 사양 쓰는 능력을 병목으로 보고, 팀과 문서를 에이전트가 일할 수 있게 다시 짜야 합니다.

요약

Box 공동창업자이자 CEO Aaron Levie가 a16z의 창업 지원 프로그램 speedrun 대담(Speedrun Office Hours)에 나와 2005년 창업 때와 지금의 스타트업을 비교했습니다. 이 대담은 2026년 10월 25일 a16z Show로 다시 공개됐습니다. 2005년 Box의 속도는 공동창업자 네 명이 차고에서 코드와 마케팅 문구, 블로그 글을 얼마나 빨리 치느냐로 정해졌습니다. 지금 앞서가는 창업자들은 직접 만들기보다 에이전트에 일을 맡기고 결과를 검토하는 관리자처럼 일합니다. 에이전트가 쓴 코드 수천 줄을 매일 검토하는 창업자도 있다고 합니다. Levie는 AI-first(처음부터 AI를 전제로 일하는 방식) 팀 3~~10명이 예전 50~~200명 팀의 몫을 낸다고 보고, 기술 업계 27년 동안 본 가장 큰 변화라고 말합니다.

같은 일을 하는 팀 크기가 달라진 이유: 손이 아니라 검토가 속도를 정함

이 지렛대는 두 방향으로 번집니다. 하나는 시장입니다. 거의 모든 업종의 거의 모든 직무에 특화 에이전트가 생기고, 코딩 에이전트가 그 첫 사례라는 것입니다. 다른 하나는 수요입니다. AI 노동이 싸지면 기존 일을 대신하는 데서 끝나지 않고, 비싸서 하지 않던 일이 새로 생깁니다. Levie는 다음 모델 향상의 몫을 소비자보다 기업이 가져가고, 유통은 AI 이전과 크게 다르지 않다고 덧붙입니다. 아래에서는 이 주장을 메커니즘 여섯 가지로 풀고, 기업 안에서 작은 에이전트 팀을 시험하는 방법을 붙였습니다.

Levie가 짚은 변화 세 가지와 그대로인 것 세 가지

핵심 메커니즘

Orchestrator: 만드는 사람에서 맡기고 검토하는 사람으로

사람이 일을 직접 하지 않고 여러 에이전트에 나눠 맡긴 뒤, 결과를 검토하고 고쳐서 합치는 방식입니다. 사람이 사양을 쓰면 에이전트 여러 개가 백그라운드에서 동시에 만들고, 사람은 그 결과를 거르고 고쳐 하나로 합칩니다. Levie는 검토·편집하는 사람의 지렛대가 처음부터 만드는 사람의 약 10배라고 봅니다. 그래서 병목이 만드는 속도에서 검토·조율·통합 속도로 옮겨 갑니다.

Levie도 이 현상은 아직 주로 엔지니어링에서 봤다고 말합니다. 마케팅, 법무, 아웃바운드 영업도 같은 방향으로 갈 것으로 봅니다. 만능은 아닙니다. 에이전트는 실수하고, 많은 사람이 slot machine(슬롯머신)에 빗댈 만큼 여러 번 다시 돌려야 할 때가 있습니다. 가상 예시로, 구매팀 두 명이 공급사 계약서 요약 에이전트 세 개를 오전에 돌리고 오후에는 결과 검토만 하는 식입니다.

Orchestrator 방식: 병목이 만들기에서 검토·통합으로 옮겨 감

Spec-Driven Development: 무엇을 만들지 분명히 적는 능력이 지렛대가 된다

에이전트가 만들기 전에 아주 자세한 프롬프트와 사양(spec)을 먼저 쓰는 방식입니다. Levie는 대충 엮어 만드는 일은 흔해졌고, 값이 오르는 것은 전략과 시장 기회 판단, taste(무엇이 좋은 결과인지 가려내는 안목)라고 봅니다. 진행자는 실수 비용이 싸져도 실수 자체는 계속 생기니 좋은 결정이 더 중요해진다고 보탭니다. 제품 담당자가 엔지니어 없이 만들 수 있는 범위도 넓어집니다. 사양이 흐리면 에이전트는 빠르게 엉뚱한 것을 만들고, 그만큼 검토가 길어집니다.

만드는 비용이 내려가면 무엇을 만들지 정하는 능력이 비싸짐

Subagents와 Context Rot: 큰 에이전트 하나 대신 나눠 맡는 에이전트

context rot은 작업이 길어질수록 모델이 앞의 맥락을 놓치고 품질이 떨어지는 현상입니다. Levie는 하나의 super-agent가 모든 일을 잘하는 단계는 아직 아니라고 봅니다. 그래서 코드베이스나 워크플로의 한 부분씩을 맡는 subagent로 나눠야 한다며 Claude 코딩 도구의 subagent를 예로 듭니다. 그는 이 문제가 도구를 몇 개 쓰느냐가 아니라 일을 어떻게 나누느냐의 문제라고 짚습니다. 정답은 팀·회사·도구마다 다르고, 모범 사례는 아직 만들어지는 중이라고 합니다.

Levie: 아직 하나의 super-agent가 다 잘하지 못하니 나눠 맡김

Incumbent Wiring: 기존 조직이 같은 지렛대를 바로 쓰지 못하는 이유

Levie에 따르면 1년 전 창업자들은 Copilot류 자동완성으로 10~~20% 생산성 향상을 말했습니다. 지금 앞선 창업자들은 백그라운드 에이전트로 3~~10배까지 가능하다고 말합니다. 기존 조직이 이 차이를 바로 따라잡지 못하는 데는 이유가 있습니다. 코드베이스에 에이전트가 읽을 문서가 없고, 도구 체계와 엔지니어링 방식도 백그라운드 에이전트를 전제로 짜여 있지 않습니다. 많은 사람이 동시에 에이전트를 돌리면 작업끼리 부딪히는 조정 문제도 생기는데, 작은 팀은 이 비용이 적습니다. Levie는 스타트업의 방식을 배워 Box 운영에 옮기려 한다고 말합니다.

기존 조직이 같은 지렛대를 바로 못 쓰는 네 가지 이유(Levie 발언 정리)

Industry × Job Function Matrix: 업종과 직무를 곱한 약 5,000칸

아이디어가 없다면 업종과 직무를 가로세로로 놓은 표에서 시작하라는 제안입니다. 칸 하나가 한 업종의 한 직무를 맡는 에이전트이고, 이를 기업과 서비스 회사, 시스템 통합 사업자에 팝니다. Levie는 칸이 약 5,000개라고 보고, 기업가치 10억·50억·100억 달러 이상인 회사가 수백 개 나올 것으로 예상합니다. 시장(TAM, 전체 시장 규모)이 작아 실패하는 칸도 많겠지만, 노동 비용이 내려가 수요가 예상보다 커지는 칸도 나온다고 봅니다. 그가 든 예는 생명과학의 FDA 규제 검토 에이전트와 법률 검토 에이전트입니다. 생명과학, 헬스케어, 법률, 컨설팅에서 새 에이전트 회사가 기존 소프트웨어 회사와 서비스 회사를 함께 앞지를 것이라고 봅니다.

업종 × 직무 매트릭스. 앰버 칸은 Levie가 든 예, 나머지 업종·직무 이름은 설명용 예시

칸을 고를 때는 그 일을 얼마나 아느냐가 중요합니다. Levie는 Y Combinator의 Jared Friedman이 남긴 조언을 언급하며 순서를 매깁니다. 가장 좋은 것은 그 일을 직접 해 본 경우, 다음은 해 본 사람이 공동창업자인 경우, 그다음은 그 일을 하는 사람을 옆에서 따라다니며 일을 거꾸로 풀어 보는 경우입니다. 진행자는 기술 창업자와 업무 전문가(예로 Pfizer 출신)를 이어 주는 매칭을 농담 삼아 제안합니다.

Levie가 꼽은 업무 지식 확보 순서: 직접 경험 > 공동창업자 > 관찰

Elastic Demand: 싸진 AI 노동이 예전엔 없던 수요를 만든다

Levie의 예에서 상위 법률 검토는 시간당 1,000~~2,000달러이고, 에이전트는 5~~10달러가 될 수 있습니다. 세상에 변호사가 부족했던 것은 너무 비쌌기 때문이라는 것입니다. 그는 노동 가격이 10분의 1이 되면 수요가 50배까지 늘 수 있다고 봅니다. 지금 가격에서는 공급이 수요를 채우지 못하기 때문입니다.

Levie가 든 법률 검토 비용 비교(상한 기준). 막대 길이는 실제 비율

사람 한 명을 뽑는 데는 10만~30만 달러가 들지만 에이전트는 약 1,000달러로 시작할 수 있습니다. 그래서 Levie는 ROI에 상한이 없고 시작 가격에 하한도 없다고 말합니다. 기업은 사람을 뽑은 적 없는 일에 에이전트를 쓰게 됩니다. Box에도 비용이 10분의 1이면 훨씬 많이 배치할 기능이 있는데, 지금은 예산 우선순위 맨 아래에 있다고 합니다.

Elastic Demand: 대체가 아니라 사람을 뽑은 적 없는 일에 에이전트를 씀

Enterprise Captures Model Gains: 다음 모델 향상의 몫은 기업으로

Levie는 Anthropic의 Dario Amodei가 든 예를 옮깁니다. 모델의 화학 실력이 학부생에서 대학원생 수준으로 올라도 소비자는 거의 못 느끼지만, 제약사에게는 큰 차이라는 것입니다. Levie 자신의 경험도 같습니다. 어머니의 AI 사용은 이미 다 해결됐고, 아이에게 줄 노래·그림·이야기도 지금 수준이면 충분합니다. 반면 로펌 계약서 하나를 AI로 검토했더니 오류가 약 70개 나왔습니다. 그래서 그는 앞으로의 향상 대부분이 기업 용도로 흘러간다고 봅니다. 소비자 쪽 기회도 많지만, 창업자라면 시장 규모와 생산성 효과가 분명한 기업에 걸겠다고 말합니다.

다음 모델 향상이 기업 용도로 흘러가는 이유(Levie·Dario Amodei의 예)

통념과 다른 주장

흔히 이렇게 봅니다기업 AI의 성과는 줄인 인력 비용으로 잽니다.

저자는 이렇게 봅니다싸진 AI 노동의 큰 몫은 비싸서 하지 않던 일을 하게 되는 데서 나옵니다.

근거상위 법률 검토가 시간당 1,000~2,000달러에서 5~10달러로 내려가면 수요가 크게 늘 수 있고, Box에도 비용만 맞으면 늘릴 기능이 예산 맨 아래에 있다고 말합니다.

통념 대 Levie: AI 노동의 가치는 대체보다 새로 하는 일에서

흔히 이렇게 봅니다인력과 데이터, 고객이 많은 기존 강자가 AI에서도 유리합니다.

저자는 이렇게 봅니다에이전트에 맞춰 일하는 3~10명 팀이 기존 강자보다 빨리 움직일 수 있습니다.

근거기존 조직은 에이전트가 읽을 문서가 없고 도구와 업무 흐름이 사람 중심으로 굳어 있습니다. 코딩 에이전트 시장에서는 이미 기존 강자 밖에서 큰 회사들이 나왔습니다.

통념 대 Levie: 규모보다 에이전트에 맞춘 작업 방식이 속도를 정함

흔히 이렇게 봅니다AI로 좋은 제품을 만들면 사용자가 알아서 찾아옵니다.

저자는 이렇게 봅니다AI가 바꾸는 것은 제품이고, 유통의 기본은 그대로입니다.

근거OpenAI App Store 같은 새 채널은 생기겠지만 기본 GTM 모델은 같다고 봅니다. 그의 말로는 "If you build it, they will not necessarily come." 청중을 직접 확보하고 꾸준히 유통을 쌓아야 하며, 한 번의 화제로 해결되지 않는다고 말합니다.

통념 대 Levie: AI가 바꾸는 것은 제품이고 유통은 그대로

저자가 든 사례

2005년 Box와 지금의 창업자

상황: 2005년 Box는 공동창업자 네 명이 개조한 차고에서 일했고, 코드와 문구를 치는 손이 유일한 지렛대였습니다.
한 일: 지금 앞선 창업자들은 에이전트에 일을 맡기고 관리자처럼 검토합니다. 매일 수천 줄을 검토하는 창업자도 있습니다.
결과: 3~~10명 팀이 예전 50~~200명 팀의 몫을 냅니다(Levie의 관찰).
연결: Orchestrator, Spec-Driven Development.

사례 1. 2005년 Box와 지금의 창업자 → Orchestrator

코딩 에이전트 시장

상황: 지식 노동 가운데 코딩이 에이전트로 가장 먼저 임계점에 이르렀습니다.
한 일: Replit, Cursor, Windsurf, Lovable, Cognition 같은 회사가 코딩 에이전트를 내놓았습니다.
결과: Levie는 기존 강자에게 가지 않는 AI 코딩 시가총액 수천억 달러를 감당할 수 있다고 봅니다.
연결: Industry × Job Function Matrix의 첫 칸, Incumbent Wiring.

사례 2. 코딩 에이전트 → 매트릭스의 첫 칸이 채워진 모습

법률 검토의 비용

상황: 상위 법률 검토는 시간당 1,000~2,000달러라 늘 공급이 부족했습니다.
한 일: 같은 검토를 에이전트로 하면 시간당 5~10달러가 될 수 있습니다.
결과: 가격이 10분의 1이 되면 수요가 50배까지 늘 수 있다고 봅니다(Levie의 추정, 실측 아님).
연결: Elastic Demand.

사례 3. 법률 검토 → Elastic Demand

로펌 계약서의 오류 70개

상황: 소비자 용도의 AI는 이미 충분한 수준입니다.
한 일: 로펌 계약서 하나를 AI로 검토했습니다.
결과: 오류가 약 70개 나왔습니다. 모델이 얼마나 나아져야 하는지는 원문에서 밝히지 않았습니다.
연결: Enterprise Captures Model Gains.

사례 4. 로펌 계약서 → 모델 향상의 몫이 기업으로

기술 디테일: 작은 에이전트 팀을 실제로 돌리려면

아래는 대담의 주장을 기업 안 시범으로 옮길 때 필요한 설계로, AX Review가 새로 작성했습니다. 필드 이름과 숫자는 가상 예시입니다.

Orchestrator 방식을 시험하려면 검토 로그부터 남깁니다. 지렛대가 검토에서 나온다면 검토를 재야 합니다. 에이전트에 맡긴 작업 하나마다 한 줄씩 기록합니다. slot machine 문제는 attempts(채택까지 다시 돌린 횟수)로 드러나고, 검토가 병목인지는 review_minutes와 build_minutes를 비교하면 보입니다. 로그는 스프레드시트로 시작해도 충분합니다.

{
  "task_id": "PROC-0142",
  "spec_version": "v2",
  "owner": "구매팀 김OO",
  "agent": "contract-summary",
  "model": "<사용 모델명과 버전>",
  "attempts": 2,
  "accepted": true,
  "edit_ratio": 0.18,
  "build_minutes": 6,
  "review_minutes": 14,
  "defects_later": 0,
  "reviewed_at": "2026-11-03"
}

검토 로그 필드와 경고 기준(가상 예시)

Spec-Driven Development를 돌리려면 사양 양식을 고정합니다. 사양에는 goal(무엇을 왜), inputs(넣을 자료와 위치), context_docs(읽을 규칙 문서), constraints(형식·분량·금지 사항), acceptance_tests(통과 조건 35개), out_of_scope(하지 말 일)를 적습니다. 같은 사양을 세 번 따로 돌려 결과를 비교합니다. 세 결과가 크게 다르면 모델보다 사양이 모호하다는 신호이니, 빠진 기준을 acceptance_tests에 더하고 spec_version을 올립니다. 설정을 바꿀 수 있는 도구라면 temperature를 00.2로 낮춰 반복성을 먼저 확인합니다.

같은 사양을 3회 돌려 편차로 사양의 모호함을 찾는 순서(가상 예시)

Subagent로 나누려면 소유 영역과 맥락을 칸으로 정합니다. context rot을 피하려면 각 subagent에 필요한 맥락만 넣습니다. 오케스트레이터는 원문 전체가 아니라 각 subagent 결과의 요약만 받습니다. 흔한 실패는 두 subagent가 같은 파일이나 같은 칸을 고치는 것입니다. 소유 영역을 문서에 적어 잠그고, 겹치면 오케스트레이터가 한쪽만 채택합니다. 한 작업에서 subagent는 3~5개로 시작합니다.

subagent마다 소유 영역과 넣는 맥락을 따로 정함(가상 예시)

Incumbent Wiring을 풀려면 에이전트가 읽을 문서를 먼저 채점합니다. 업무 README, 규칙 문서(금지 사항과 예외 포함), 용어집, 입출력 예시를 항목마다 0·3·5점으로 매깁니다. 합계 20점 만점에 12점 미만인 업무는 에이전트를 붙이기 전에 문서부터 씁니다. 이 문서가 사람 신입의 교육 자료로도 쓰입니다.

에이전트가 읽을 문서 준비도 채점표(가상 예시). 항목마다 0·3·5점

Elastic Demand를 숫자로 보려면 지금 안 하는 일을 다시 계산합니다. 건당 사람 비용은 시간 × 시급, 건당 에이전트 비용은 토큰 비용 + 검토 시간 × 시급입니다. 검토 시간을 빼면 계산이 낙관적으로 나옵니다. 가상 예시로 계약서 검토 한 건에 사람이 2시간(시급 10만 원, 20만 원)이 들고, 에이전트는 토큰 2,000원에 검토 20분(약 3만3천 원)이면 건당 약 3만5천 원입니다. 지금은 건당 20만 원이라 전수 검토를 못 하던 소액 계약이 후보가 됩니다.

지금 안 하는 일을 에이전트 비용으로 다시 계산하는 순서(가상 예시)

기업 용도의 품질은 오류를 세서 잽니다. 로펌 계약서 사례처럼 기업 문서는 오류 개수로 평가합니다. 업무 전문가가 정답을 단 문서 30~50건을 정답 세트로 두고, 오류를 누락·해석 오류·숫자 오류·근거 없음 네 가지로 나눠 셉니다. 같은 문서를 3회 돌려 오류 수의 편차를 보고, 모델 두 개로 교차 확인합니다. 모델을 바꿀 때마다 같은 세트로 다시 채점하면 모델 향상이 우리 업무에서 실제로 얼마나 나는지 보입니다.

계약서 검토 오류를 유형별로 세는 기준(가상 예시)

현업 실행 디테일: 누가, 언제, 무엇을

역할	담당	6주 동안 하는 일
스폰서	사업부장 1명	대상 업무 승인, 늘어난 산출을 어디에 쓸지 결정
팀 리더	현업 팀장 1명	사양 작성 책임, 검토 로그 주간 점검
업무 전문가	그 일을 직접 해 본 담당자 1~2명	정답 세트 작성, 결과 검토
엔지니어	개발자 1명	에이전트·subagent 구성, 로그 수집
검토 책임	법무 또는 품질 담당 1명	오류 유형 정의, 외부로 나가는 결과 승인
재무	재무 담당 1명	건당 비용 계산, 새로 한 일의 가치 확인

시작 전 준비물: 예산이 없어 미뤄 둔 업무 목록, 후보 업무의 절차서와 규칙 문서, 최근 결과물 표본 30~50건, 지금의 건당 처리 시간과 인건비, 쓸 수 있는 에이전트 도구와 데이터 접근 권한 목록.

주차	할 일	산출물
1~2주	미뤄 둔 업무 목록에서 후보 2개 선정, 에이전트용 문서 채점	후보 업무 2개, 문서 점수표
3~4주	사양 양식 작성, subagent 구성, 정답 세트로 1차 채점	사양 v1~v2, 오류 유형별 집계
5~6주	기존 방식과 병행 운영, 검토 로그 수집, 판정 회의	검토 로그, 판정 보고서

작은 에이전트 팀 6주 시범 일정(가상 예시)

업무 전문가 인터뷰 질문: 이 일을 처음부터 끝까지 하면 몇 단계이고 어디서 가장 오래 걸립니까? 신입에게 말로만 가르치는 규칙은 무엇입니까? 결과물에서 틀리면 가장 비싼 부분은 어디입니까? 비용만 맞으면 지금보다 열 배 더 하고 싶은 일은 무엇입니까? 지금은 표본만 보는데 전수로 보고 싶은 것은 무엇입니까?

진행 판정 기준(예시): 같은 품질에서 산출량이 두 배 이상이고, 검토 시간이 작업 시간의 절반 이하이며, 새로 한 일의 가치를 재무가 확인하면 확대합니다. 평균 attempts가 3회를 넘는 상태가 2주 이어지거나, 검토 시간이 직접 할 때보다 길면 사양과 문서를 고쳐 3주차부터 다시 돌립니다.

6주 시범의 진행 판정 기준(가상 예시)

AX 적용 제언. 기업이 이 대담에서 가져갈 순서는 인력 감축 계산이 아니라 새로 할 일의 목록입니다. 예산 맨 아래에 있던 일, 예를 들어 소액 계약 전수 검토, 공급사 전체의 규제 문서 확인, 모든 고객 문의의 근본 원인 분류부터 적습니다. 그다음 그 업무의 문서를 에이전트가 읽을 수 있게 채우고, 그 일을 해 본 사람을 포함한 3~5명 팀에 맡깁니다. 판정은 사용 사례 수가 아니라 검토 로그로 합니다. 업종 × 직무 매트릭스는 사내에서는 부서 × 직무 표로 바꿔 쓸 수 있습니다. 칸마다 지금 비용과 에이전트 비용을 적으면 AX 과제의 우선순위 지도가 됩니다. 사내 확산도 Levie가 말한 유통과 같습니다. 잘 만든 에이전트라도 현업 리더가 쓰게 만들지 않으면 쓰이지 않습니다.

기업 AX에 옮기는 순서: 새로 할 일 → 문서 → 작은 팀 → 판정

원문 사례

항목	내용
출처	a16z Show 에피소드 1239(2026.10.25, 약 34분). speedrun의 Speedrun Office Hours 대담을 다시 공개
화자	Aaron Levie(Box 공동창업자·CEO), a16z 진행자
팀 규모	AI-first 팀 3~~10명이 예전 50~~200명 팀의 산출
지렛대	검토·편집하는 사람은 만드는 사람의 약 10배. 1년 전 Copilot류 10~~20% 향상, 지금 앞선 창업자는 3~~10배 가능성 언급
시장	업종 × 직무 약 5,000칸. 기업가치 10억·50억·100억 달러 이상 회사 수백 개 예상. 예: FDA 규제 검토, 법률 검토 에이전트
코딩 에이전트	Replit, Cursor, Windsurf, Lovable, Cognition. 기존 강자 밖 AI 코딩 시가총액 수천억 달러 감당 가능하다고 봄
비용	상위 법률 검토 시간당 1,000~~2,000달러 대 에이전트 5~~10달러. 채용 10만~30만 달러 대 에이전트 약 1,000달러. 가격 10분의 1이면 수요 최대 50배(추정)
기업 대 소비자	Dario Amodei의 화학 수준 예. 로펌 계약서 AI 검토에서 오류 약 70개
유통	새 채널(OpenAI App Store 등)은 생겨도 기본 GTM은 그대로
창업 조언	그 일을 직접 해 봤다 > 해 본 공동창업자 > 옆에서 관찰. Jared Friedman(Y Combinator)의 조언 언급

핵심 개념

speedrun: a16z가 운영하는 초기 스타트업 지원 프로그램. 이 대담의 원래 무대.
background agent: 사람이 지켜보지 않는 동안 맡은 작업을 따로 돌리고 결과만 돌려주는 에이전트.
Copilot류 도구: 코드를 쓰는 중에 다음 줄을 자동완성해 주는 보조 도구. Levie는 1년 전 생산성 효과의 기준으로 든다.
TAM: Total Addressable Market. 한 제품이 차지할 수 있는 전체 시장 규모.
GTM: go-to-market. 제품을 고객에게 알리고 파는 방식 전체.
시스템 통합 사업자: 여러 소프트웨어를 고객사 환경에 맞춰 묶어 구축해 주는 회사. Levie는 에이전트를 파는 대상으로 기업·서비스 회사와 함께 든다.

내 메모

TODO: 내 생각 추가

원문: “The New Startup Playbook | Box CEO Aaron Levie”(a16z Show, 2026.10.25, Speedrun Office Hours 대담 재공개). 쇼노트와 공개 대본(PodScripts)을 대조해 정리했으며, 대본에서 확인되지 않은 세부는 넣지 않았습니다. 요약·메커니즘·통념과 다른 주장·사례·원문 사례 표는 대담 내용을 AX Review가 다시 정리했습니다. 수치는 Levie의 관찰과 추정이며 실측 자료가 아닙니다. 기술·현업 디테일, JSON 예시, 채점표, 비용 계산, 일정·판정 기준, 인포그래픽은 새로 작성했고 숫자는 가상 예시입니다. 전체 대담은 a16z Show에서 들을 수 있습니다.