# Zero Draft Lab > AI를 쓰는 1인 사업가와 작은 팀의 책임자를 위한 매거진. 사업, AI 업무 위임, 주의력에 관한 선택을 사례와 근거로 살핍니다. Public Ghost content for AI and LLM tooling. This file includes a bounded export of public pages first, then recent public posts. Append `.md` to any post or page URL to get the content in Markdown (for example, `/example-post.md`). ## Pages ### Zero Draft Lab 소개 URL: https://zerodraftlab.com/about/ Last updated: 2026-09-15T08:36:53.000Z **AI로 일과 사업을 설계하는 사람들의 매거진.** 무엇을 만들고, 어디에 AI를 맡기고, 어떻게 돈을 받을지. 사례와 근거, 직접 해본 결과로 다음 결정을 좁힙니다. ## 직접 만들고 운영하는 사람에게 Zero Draft Lab은 AI를 이미 쓰는 1인 사업가와 작은 팀의 책임자를 위해 씁니다. 제품을 만들고, 고객을 만나고, 업무를 나누는 과정에서 선택의 근거가 필요한 사람을 생각합니다. ## 세 가지 결정을 다룹니다 - **사업**: 어떤 고객에게 무엇을 제안하고, 얼마에 어떻게 팔 것인가. - **일과 조직**: AI에게 무엇을 맡기고, 사람이 어디서 검증할 것인가. - **사람**: 주의력과 학습을 어떻게 유지하고, 작업 환경을 바꿀 것인가. ## 근거부터 적용 조건까지 원문과 이론을 읽고, 사례가 성립한 조건을 살핍니다. 직접 실험한 글에는 무엇을 시도했는지, 어떤 결과를 관찰했는지, 그 뒤 판단이 어떻게 바뀌었는지 남깁니다. 확인한 사실과 해석을 구분합니다. 결과가 아직 없으면 무엇을 더 확인해야 하는지 밝힙니다. ## 한 편에서 더 깊이 읽기 공개 구간에서 문제와 핵심 판단을 읽습니다. 유료 구간이 있는 글에서는 같은 흐름을 따라 더 깊은 근거, 사례와 반론까지 이어 읽을 수 있습니다. [처음 읽을 글 고르기](https://zerodraftlab.com/start-here/) · [구독 안내 보기](https://zerodraftlab.com/subscribe/) ### 구독하기 URL: https://zerodraftlab.com/subscribe/ Last updated: 2026-09-15T08:36:55.000Z **다음 결정의 근거를 이어 읽으세요.** 무엇을 만들고, 어디에 AI를 맡기고, 어떻게 돈을 받을지. Zero Draft Lab은 직접 만들고 운영하는 사람의 선택을 다룹니다. ## 무료로 읽기 공개 글과 유료 글의 공개 구간에서 문제, 사례, 핵심 판단을 읽을 수 있습니다. 무료 회원으로 가입하면 이메일로 발행 소식을 받을 수 있습니다. ## Founding Reader로 더 깊이 읽기 유료 구간까지 같은 글을 이어 읽습니다. 주장을 뒷받침하는 근거, 다른 선택이 필요한 조건, 반론과 사례를 더 깊이 살핍니다. 실험을 다룬 글에서는 시도와 관찰 결과를 따라가며, 판단이 어떻게 바뀌었는지 읽습니다. **월 USD 5 · 연 USD 50** [구독 방식 선택하기](#/portal/signup) ## 이런 결정 앞에 있다면 - 만들 제품과 먼저 만날 고객을 정하고 있다면. - AI에게 맡길 일과 사람이 검증할 일을 나누고 있다면. - 주의력을 유지하며 배우고 일할 방법을 찾고 있다면. [처음 읽을 글부터 살펴보기](https://zerodraftlab.com/start-here/) ### 처음 오셨다면 URL: https://zerodraftlab.com/start-here/ Last updated: 2026-09-15T08:36:54.000Z **지금 내려야 할 결정에서 시작하세요.** Zero Draft Lab은 AI로 일과 사업을 설계하는 사람들의 매거진입니다. 사업을 시작하거나 바꾸고 있다면 아래 세 편을 순서대로 읽어보세요. ## 무엇을 만들고, 누구에게, 얼마에 팔 것인가 1. [바이브 코딩 수익화 영상은 왜 시장부터 보라고 했나](https://zerodraftlab.com/vibe-coding-market-first/) 만들기 전에 어떤 시장의 문제를 볼지 생각합니다. 2. [영업이 안 된다는 결론은 너무 일찍 나온다](https://zerodraftlab.com/first-customer-funnel-math/) 고객이 없다는 판단을 내리기 전에 무엇을 세어야 할지 살핍니다. 3. [원가는 가격의 바닥일 뿐이다](https://zerodraftlab.com/cost-is-only-price-floor/) 가격을 정할 때 원가와 함께 볼 기준을 찾습니다. ## AI에게 어디까지 맡길 것인가 일을 맡기는 범위와 결과를 확인하는 책임을 함께 생각합니다. - [에이전트에게 모든 걸 시키지 마라](https://zerodraftlab.com/dont-make-agents-do-everything/) - [회사는 이제 에이전트를 위해 설계되어야 한다](https://zerodraftlab.com/company-must-be-designed-for-agents/) ## 주의력과 작업 환경을 어떻게 지킬 것인가 새로운 것을 배우면서도 하던 일을 이어갈 수 있는 조건을 살핍니다. - [새로움에 자주 끌리는 뇌를 위한 작은 구조](https://zerodraftlab.com/hypercurious-mind/) 공개 구간에서 핵심 판단을 읽고, 유료 구간이 있는 글에서는 근거와 반론을 더 깊이 따라갈 수 있습니다. [무료·유료 구독 안내 보기](https://zerodraftlab.com/subscribe/) ### 개인정보 처리 안내 URL: https://zerodraftlab.com/privacy/ Last updated: 2026-07-26T12:38:43.000Z **최종 업데이트: 2026년 7월 26일** Zero Draft Lab은 사이트와 콘텐츠를 개선하고 실제 구독 경로가 제대로 작동하는지 확인하기 위해 필요한 범위의 이용 데이터를 처리합니다. 분석 도구는 개인을 식별하는 프로필을 만들기 위한 용도로 사용하지 않습니다. ## 사용하는 분석 도구 ### Ghost 사이트 운영 플랫폼인 Ghost의 자체 분석을 사용합니다. Ghost 통계는 쿠키 없이 페이지 조회, 유입 경로, 회원 구분, 무료·유료 전환 및 매출을 집계합니다. 실제 회원가입과 결제 결과의 정본은 Ghost입니다. ### Google Analytics 4 Google Analytics 4(GA4)를 사용해 페이지 조회, 유입 경로, 캠페인 항목, 기기·브라우저 범주, 대략적인 지역 및 사이트 이용 상호작용을 집계합니다. 광고 저장, 광고 개인화 및 Google Signals는 사용하지 않습니다. 분석 저장을 허용하기 전에는 Google Consent Mode의 거부 상태로 태그가 동작하며 쿠키 없는 측정 신호만 전송될 수 있습니다. 분석을 허용하면 Google이 분석용 쿠키 또는 유사 식별자를 사용해 같은 브라우저의 세션을 연결할 수 있습니다. 자세한 내용은 [Google 개인정보처리방침](https://policies.google.com/privacy?ref=zerodraftlab.com)과 [Google Analytics 데이터 보호 안내](https://support.google.com/analytics/answer/6004245?ref=zerodraftlab.com)에서 확인할 수 있습니다. ### Microsoft Clarity Microsoft Clarity를 사용해 클릭, 스크롤, 탐색 흐름, 히트맵 및 세션 리플레이를 확인합니다. Clarity의 마스킹 설정을 적용하며 입력 내용이나 결제 정보를 분석 목적으로 의도적으로 수집하지 않습니다. Clarity의 쿠키 설정은 기본적으로 꺼져 있습니다. 분석을 허용하기 전이거나 거부한 경우에는 Clarity 태그 자체를 실행하지 않습니다. 분석을 허용한 경우에만 Clarity가 분석 세션을 연결하고 리플레이를 시작합니다. 광고 저장은 항상 거부합니다. 자세한 내용은 [Clarity 개인정보 공개 안내](https://learn.microsoft.com/en-us/clarity/setup-and-installation/privacy-disclosure?ref=zerodraftlab.com)에서 확인할 수 있습니다. ### PostHog 미국 리전의 PostHog로 페이지 조회, 글 읽기, 페이월 노출, 검색, 구독 화면 도달 같은 미리 정한 이벤트를 수집합니다. 자동 클릭 수집, 사람 프로필, 히트맵 또는 세션 리플레이는 PostHog에서 사용하지 않습니다. 분석을 허용하지 않으면 페이지마다 새 임시 식별자를 사용하고 이를 저장하지 않습니다. 허용하면 같은 탭에서 세션을 연결하기 위해 브라우저의 세션 저장소에 임의 식별자와 최초 유입 캠페인·referrer 정보를 보관합니다. 이 값은 탭 세션이 끝나면 삭제됩니다. PostHog 이벤트에는 페이지 경로, 게시물 식별 정보, 캠페인 항목, referrer, 구독·검색 버튼 사용 여부처럼 퍼널 분석에 필요한 정보만 넣습니다. 이메일 주소, 이름, 회원 ID, 검색어 원문, 입력 내용 또는 결제 정보는 넣지 않습니다. 다만 인터넷 통신 과정에서 IP 주소와 user-agent가 서비스 제공자에 의해 기술적으로 처리될 수 있습니다. 자세한 내용은 [PostHog 개인정보 안내](https://posthog.com/privacy?ref=zerodraftlab.com)에서 확인할 수 있습니다. ### Google Search Console Google 검색 결과에서의 노출, 클릭, 검색어 및 색인 상태를 집계해서 확인합니다. Search Console을 위해 별도의 브라우저 추적 코드를 설치하지 않습니다. ## 분석 선택과 브라우저 저장소 처음 방문하면 분석 선택 창이 표시됩니다. **분석 허용**을 선택하면 GA4·Clarity의 분석 저장, Clarity 리플레이 및 PostHog의 탭 단위 세션 연결이 활성화됩니다. **쿠키 없이 계속**을 선택하면 Clarity는 실행하지 않고 GA4·PostHog만 개인 프로필 없는 페이지 단위 또는 쿠키 없는 방식으로 집계합니다. 화면 왼쪽 아래의 **분석 설정** 버튼에서 언제든 선택을 바꿀 수 있습니다. 선택 자체를 기억하기 위해 로컬 저장소에 허용 또는 거부 상태를 저장합니다. 이 값은 분석 목적이 아니라 사용자의 선택을 반복해서 묻지 않기 위한 기능성 정보입니다. ## 브라우저 프라이버시 신호 브라우저가 **Global Privacy Control** 또는 **Do Not Track** 신호를 보내면 Zero Draft Lab의 GA4, Clarity 및 PostHog 추적 코드를 실행하지 않습니다. ## 국외 처리와 보관 Google, Microsoft 및 PostHog는 대한민국 밖의 서버와 하위 처리자를 통해 데이터를 처리할 수 있습니다. 처리 목적은 위에 적은 사이트 분석과 운영 개선이며, 데이터의 보관과 삭제는 각 서비스의 현재 설정 및 계약에 따릅니다. 확인되지 않은 고정 보관기간을 약속하지 않으며, 필요 범위를 벗어난 맞춤 이벤트는 수집하지 않습니다. ## 문의 이 안내, 분석 선택 또는 개인정보 처리에 관한 요청은 [joomong@zerodraftlab.com](mailto:joomong@zerodraftlab.com)으로 보내주세요. ### 후킹 멘트 라이브러리 URL: https://zerodraftlab.com/hook-message-library/ Last updated: 2026-08-09T02:01:07.000Z 목적을 고르고, 빈칸을 채우고, 다음 장면에서 약속을 증명한다. 문구보다 먼저 실제로 보여줄 장면과 근거를 정하면 된다. ## 빠른 선택 1. [01 손실 회피](#01) 2. [02 사회적 증거](#02) 3. [03 정보 격차](#03) 4. [04 자기 관련성](#04) 5. [05 후회 회피](#05) 6. [06 통념 반전](#06) 7. [07 누락 발견](#07) 8. [08 단일 변화](#08) 9. [09 새로움](#09) 10. [10 반복 실험](#10) --- ## 01 > 이거 모르면 진짜 손해예요 **목적** 시청자가 흘려보내던 문제를 돈, 시간, 기회 중 하나의 손실로 바꿔 보여준다. **쓸 때** 손실이 생기는 지점과 크기를 실제 기록이나 계산으로 확인했을 때 쓴다. **채우는 공식** “\[대상\]이 \[행동 또는 설정\]을 놓치면 \[금액·시간·기회\]를 \[구체적인 크기\]만큼 잃습니다.” **적용 예시** “주문 확인을 하루 늦게 하면 고객 한 명만 놓치는 게 아닙니다. 오늘 발송 마감까지 함께 놓칩니다.” **다음 장면** 주문 시간과 발송 마감이 함께 찍힌 화면, 손실액 계산표, 누락이 생긴 단계 가운데 하나를 바로 보여준다. **피할 때** 손실의 종류나 크기를 확인할 수 없고 불안만 키우게 될 때는 쓰지 않는다. --- ## 02 > 잘되는 사람들은 다 ○○하더라고요 **목적** 시청자와 가까운 집단에서 반복된 행동을 보여줘 선택 기준을 만든다. **쓸 때** 누구를 몇 명 봤는지, 어떤 행동이 공통으로 나타났는지 기록이 있을 때 쓴다. **채우는 공식** “\[시청자와 가까운 집단\] \[표본 수 또는 관찰 범위\]에서 \[공통 행동\]이 반복됐습니다.” **적용 예시** “반품률이 낮은 판매자 12곳을 보니 상품 설명보다 먼저 배송 조건을 고쳐 쓰고 있었습니다.” **다음 장면** 관찰한 사례 목록, 같은 행동이 표시된 화면, 표본 수가 보이는 기록을 제시한다. **피할 때** 두세 사례를 보고 전체 집단의 습관처럼 말하거나, 성공 기준이 서로 다른 사례를 한데 묶을 때는 피한다. _This page is for paying subscribers only._ ## Posts ### 스포티파이가 공개한 AI 코딩 기록 세 편, 에이전트는 파이프라인의 한 칸이었다 URL: https://zerodraftlab.com/spotify-agent-platform-stack/ Last updated: 2026-09-08T14:05:28.000Z 스포티파이가 2025년 11월부터 2026년 8월까지 사내 AI 코딩 도구를 어떻게 만들고 굴리는지 세 편의 글로 공개했다. 이 글은 그 세 편을 순서대로 소개한다. 첫 번째는 Spotify Engineering 블로그의 [1,500+ PRs Later: Spotify's Journey with Our Background Coding Agent (Honk, Part 1)](https://engineering.atspotify.com/2025/11/spotifys-background-coding-agent-part-1?ref=zerodraftlab.com)이고, 두 번째는 같은 블로그의 [Coding Is No Longer the Constraint](https://engineering.atspotify.com/2026/6/code-with-claude-coding-is-no-longer-the-constraint?ref=zerodraftlab.com), 세 번째는 Spotify Portal의 [What we've learned scaling AI coding agents at Spotify](https://portal.spotify.com/blog/introducing-xirp?ref=zerodraftlab.com)다. 세 편을 묶어 읽으면 한 가지 순서가 보인다. 스포티파이는 에이전트를 먼저 들여온 게 아니라, 2022년부터 쌓아 온 대량 변경 파이프라인의 한 칸을 에이전트로 바꿨다. 그 뒤에 에이전트가 늘어나자 세션과 지식을 관리하는 층을 하나 더 올렸다. ![스포티파이 에이전트 스택 도식. 아래부터 Backstage, Fleet Management, Honk, Xirp 네 층과 각 층의 역할, 공개 시점, 발표 수치를 표로 정리했다.](https://storage.ghost.io/c/da/13/da13bbbc-4992-4354-bf2c-1426bcf8788c/content/images/2026/09/spotify-agent-platform-stack-stack-m.png) 네 층의 역할과 공개 시점. Zero Draft Lab이 원문 세 편을 정리해 그렸다. ## Honk Part 1: 마이그레이션 스크립트 자리에 에이전트를 넣었다 2025년 11월 6일에 나온 첫 글은 Max Charas와 Marc Bruggmann이 썼다. 글은 Fleet Management부터 설명한다. 수천 개 저장소에 같은 변경을 한 번에 적용하는 사내 시스템으로, 2024년 중반 이후 스포티파이 전체 PR의 약 절반을 이 시스템이 자동으로 만들어 왔다고 밝힌다. 다만 변경 하나를 자동화하려면 스크립트를 짜야 했고, 글이 예로 든 Maven 의존성 갱신 스크립트는 2만 줄이 넘었다. Honk는 그 스크립트 자리를 프롬프트로 바꾼 것이다. 저자들은 대상 저장소 선정, PR 생성, 리뷰 요청, 머지까지의 주변 인프라를 그대로 두고, 코드를 바꾸는 단계만 에이전트에 맡겼다고 설명한다. 에이전트는 빌드와 테스트를 통과한 결과만 PR로 연다. 공개 시점까지 머지된 PR은 1,500건이 넘고, 손으로 짤 때보다 60\~90% 시간을 아꼈다는 게 저자들의 계산이다. 글은 미해결 문제도 적었다. 에이전트가 결과를 내기까지 오래 걸리고 출력이 예측하기 어렵다는 점, 그래서 가드레일과 샌드박스가 필요하다는 점을 들었다. 생성된 diff를 LLM으로 다시 판정하는 방법을 언급하지만 판정 기준이나 오탐률은 쓰지 않았다. 저자들은 "아직 모든 답을 갖고 있지 않다"고 썼고, 컨텍스트 엔지니어링과 피드백 루프는 후속편(Part 2, 3)으로 넘겼다. ## Coding Is No Longer the Constraint: 병목이 리뷰로 옮겨갔다 2026년 6월 3일 글은 Code with Claude 행사 발표를 정리한 것으로, Chief Architect인 Niklas Gustavsson의 말을 인용한다. 글이 먼저 내놓는 건 도입 수치다. 엔지니어의 99% 이상이 매주 AI 코딩 도구를 쓰고, 94%가 생산성이 올랐다고 답했으며, PR 빈도는 76% 늘었다. Opus 4.5 출시 뒤 사용량이 크게 뛰었다는 그래프도 실려 있다. 그다음 Fleet Management의 누적 성과를 적는다. 자동 유지보수 PR 250만 건 이상을 머지했고, 대부분 사람 개입 없이 자동 머지됐다. Honk는 Fleetshift가 대상 선정과 진행 추적을 맡고 코드 수정만 담당하는 구조이며, 가장 최근 백엔드 Java 마이그레이션은 사흘 걸렸다고 한다. 엔지니어는 Slack 대화 중에 Honk를 호출하고 완성된 PR을 받는다. 개발자 경험이 에이전트에게도 적용된다는 절이 이 글에서 가장 눈에 띈다. 글은 코드베이스가 일관될수록 Claude가 더 잘 작동하고, 조각난 코드베이스에서는 성능이 측정 가능하게 떨어졌다고 적는다. Backstage의 컴포넌트 카탈로그와 "golden state" 표준, 린트가 에이전트에게 즉시 피드백을 주고, 에이전트는 그 피드백으로 스스로 고친다는 설명이다. 약 100개 도구를 Backstage 하나로 합쳐 둔 것이 사람뿐 아니라 에이전트에게도 이득이었다는 게 글의 주장이다. 마지막 절의 제목이 곧 결론이다. 프로토타입이 며칠에서 몇 분으로 줄자, 제약은 코드를 쓰는 속도가 아니라 사람이 판단하고 리뷰하는 속도가 됐다. 늘어난 PR을 감당하려고 안전한 변경은 자동 머지하고 사람의 리뷰는 판단이 필요한 곳에 모은다고 글은 적는다. ![세 편의 발표가 내놓은 숫자 아홉 개를 카드로 정리했다. 1,500건 이상 머지 PR, 60에서 90퍼센트 시간 절감, 약 50퍼센트 PR 자동화, 99퍼센트와 94퍼센트 도입률, 76퍼센트 PR 증가, 250만 건 자동 PR, 3일 걸린 Java 마이그레이션, 36,000 세션, 50개 이상 병렬 세션. 각 카드에 출처와 날짜를 적었다.](https://storage.ghost.io/c/da/13/da13bbbc-4992-4354-bf2c-1426bcf8788c/content/images/2026/09/spotify-agent-platform-stack-numbers-m.png) 세 편이 내놓은 숫자. 시점과 분모가 달라 한 축에 올리지 않았다. ## Xirp: 에이전트가 늘자 세션과 지식을 관리하는 층이 필요해졌다 2026년 8월 10일 Spotify Portal에 Tyson Singer가 쓴 글은 Honk 이후의 문제를 다룬다. 엔지니어들이 한 세션이 아니라 여러 에이전트를 저장소와 브랜치를 넘나들며 병렬로 돌리기 시작했고, 한 사람이 50개 이상 세션을 굴리는 경우도 나왔다. 그러자 한 세션이 이미 푼 문제를 다른 세션이 다시 찾아 헤매는 낭비가 생겼다. 지식도 흩어져 있었다. 글은 CLAUDE.md 파일, 팀마다 다른 MCP 설정, 개인 프롬프트 모음에 노하우가 갇혀 있었다고 적는다. Xirp는 이 둘을 묶는 도구다. 세션을 한 화면에서 관리하고, 컨텍스트를 특정 에이전트나 하네스에서 떼어내 Claude Code·Codex·Gemini CLI와 자체 호스팅 오픈소스 모델 사이를 작업 중에 옮겨 다닐 수 있게 했다. 팀이 만든 스킬과 설정은 마켓플레이스에서 공유한다. 벤더 중립을 택한 이유로 글은 모델·에이전트·비용이 계속 바뀌는 환경을 든다. 새 모델이 나오면 갈아타고, 작업마다 가격 대비 성능이 좋은 쪽으로 보내겠다는 것이다. 사내에서 36,000 세션을 처리한 뒤 외부에 공개했고, 접근은 xirp.spotify.com에서 받는다. 오픈소스 여부는 글에 없다. ## ZDL이 읽는 순서 세 편에서 스포티파이가 직접 말한 사실과 Zero Draft Lab의 해석을 나눠 적는다. 원문이 말한 사실은 이렇다. Fleet Management는 2022년부터 있었고 에이전트 이전에 이미 PR 절반을 자동화했다. Honk는 그 파이프라인의 코드 변경 단계만 대체했다. 코드베이스가 일관될수록 에이전트 성능이 올랐다. PR이 늘자 병목은 리뷰로 옮겨갔다. 에이전트 세션이 늘자 세션·지식 관리 층을 따로 만들었다. ZDL의 해석은 순서에 있다. 스포티파이의 성과는 에이전트 모델의 성능보다, 에이전트가 들어올 자리를 미리 파 둔 파이프라인과 표준에서 나온 것으로 읽힌다. 도식의 아래 두 층이 없는 조직이 Honk만 따라 만들면, 에이전트가 만든 PR을 어디로 보내고 무엇으로 검증할지부터 다시 정해야 한다. 반대로 CI와 PR 흐름이 이미 있는 조직이라면, 새 시스템을 짓기보다 지금 흐름의 한 칸을 에이전트로 바꾸는 쪽이 이 기록에 가깝다. 둘째 해석은 자동 머지 정책이다. 6월 글은 안전한 변경을 자동 머지한다고만 적고, 무엇을 안전하다고 보는지는 쓰지 않았다. PR 76% 증가를 감당한 건 결국 그 기준이었을 텐데, 기준은 공개되지 않았다. 따라 하려는 조직은 이 빈칸을 스스로 채워야 한다. ## 주의점 모든 수치는 스포티파이 자체 발표다. 99%, 94%, 76%의 설문 방법과 기간, 60\~90% 절감의 계산 근거는 원문에 없다. "12월 이후 엔지니어가 코드를 한 줄도 안 썼다"는 표현은 2차 매체의 요약이며 세 편의 원문에는 없다. Xirp 사용 엔지니어 수로 돌아다니는 1,300명이라는 숫자도 원문에는 "수천 명"으로만 적혀 있어 이 글에서는 쓰지 않았다. Honk의 후속편 Part 2(컨텍스트 엔지니어링)와 Part 3(피드백 루프)은 이 글에서 다루지 않았다. 판정 기준과 오탐률처럼 Part 1이 비워 둔 내용이 거기에 있을 수 있다. ### 디자인에 배치 규칙을 담으면 개발자에게 무엇이 넘어갈까 URL: https://zerodraftlab.com/penpot-design-code-layout/ Last updated: 2026-09-07T04:36:50.000Z [Penpot](https://penpot.app/?ref=zerodraftlab.com)의 공식 소개에는 디자인 도구에서 익숙한 화면과 웹 개발에서 쓰는 이름이 함께 나온다. 캔버스에서 요소를 배치하지만, 그 배치를 정하는 방식은 CSS Grid와 Flex다. 개발자는 Inspect에서 디자인의 속성과 코드를 확인한다. 이 글은 화면을 그린 뒤 개발자가 무엇을 다시 판단해야 하는지에 초점을 맞춘다. 버튼 사이 간격은 일정한가. 내용이 길어지면 상자는 늘어나는가. 화면 폭이 줄면 요소는 어떻게 배치되는가. Penpot은 이런 질문을 디자인 단계의 설정으로 다루고, 그 설정을 코드와 연결한다. ![Penpot 공식 홈페이지에서 소개하는 앱 프로젝트 편집 화면](https://img.plasmic.app/img-optimizer/v1/img/72b71a7302cd1476867d124e9fe46817.webp) Penpot 공식 홈페이지의 제품 화면. 실제로 이 프로젝트를 편집한 기록은 아니다. 이미지: Penpot · [원문](https://penpot.app/?ref=zerodraftlab.com) 발견 경로는 [Exploding Topics의 2026년 8월 24일 미국 트렌드 목록](https://explodingtopics.com/blog/trending-topics?ref=zerodraftlab.com)이다. 목록의 검색 관심을 팀 도입률이나 개발 시간 절감의 근거로 쓰지는 않았다. 아래 설명은 공식 사용자 가이드와 제품 안내를 대조한 결과다. ## 상자의 위치와 상자가 움직이는 규칙 [Flexible Layouts 가이드](https://help.penpot.app/user-guide/designing/flexible-layouts/?ref=zerodraftlab.com)는 Flex Layout을 CSS Flexbox에 기반한 기능으로 설명한다. 방향, 정렬, 요소 사이 간격, 안쪽 여백과 크기를 설정할 수 있다. 내용과 컨테이너에 맞춰 크기를 조절하는 방식도 다룬다. 예를 들어 ‘확인’이라는 짧은 버튼 문구를 ‘신청 내용 확인’으로 바꾸는 상황을 생각해보자. 이때 궁금한 것은 처음 버튼의 폭뿐 아니라, 글자가 길어졌을 때의 처리다. 이는 기능 설명을 위한 가상 예시다. Penpot 가이드 역시 내용에 따라 커지는 버튼을 Flex의 기본 예제로 제시한다. ![Penpot Flex Layout의 방향, 정렬, 간격과 크기 설정을 표시한 공식 문서 화면](https://raw.githubusercontent.com/penpot/penpot/develop/docs/img/flexible-layouts/flex-properties.webp) Flex Layout의 속성 패널. 방향과 간격을 수치·규칙으로 설정한다. 이미지: Penpot 공식 문서 · [설명](https://help.penpot.app/user-guide/designing/flexible-layouts/?ref=zerodraftlab.com) Grid Layout은 행과 열을 함께 다룬다. 가이드는 셀과 영역, 간격, 행·열의 크기를 설명한다. 요소를 순서대로 배치하거나 특정 셀·영역에 놓는 방식도 구분한다. Flex와 Grid를 고를 때 살펴볼 것은 이름보다 어떤 관계로 요소를 배치하려는가다. | 배치에서 정할 것 | 공식 가이드의 관련 기능 | | ------------------ | -------------- | | 방향·정렬·사이 간격 | Flex Layout 속성 | | 행·열과 여러 셀을 차지하는 영역 | Grid Layout 속성 | | 일반 배치 흐름에서 벗어난 요소 | 절대 위치 설정 | ## 폭이 바뀌어도 비율은 남는다 Grid 가이드는 남은 공간을 나누는 단위인 `fr`도 설명한다. 아래는 이를 이해하기 위해 만든 별도 예시다. 두 열의 비율을 1:3으로 두고 전체 폭만 바꿨다. 글 안에서 ‘좁게’를 선택하면 두 영역이 함께 줄어든다. 넓게 좁게 1fr 3fr ZDL이 CSS로 만든 개념 예시. Penpot에서 내보낸 코드나 앱 실행 화면이 아니다. 칸 사이 간격이 없는 단순한 두 열이다. 여기서 바뀌는 것은 전체 폭이고, 유지되는 것은 두 열의 비율이다. 화면을 설명할 때 ‘왼쪽 영역이 지금 몇 픽셀인가’와 ‘폭이 달라지면 어떻게 나눌 것인가’는 서로 다른 정보다. 디자인 도구에 배치 규칙이 있으면 후자의 질문도 디자인 안에서 다룰 수 있다. ![넓은 영역과 좁은 영역 모두에서 왼쪽 1fr, 오른쪽 3fr 비율을 유지한 ZDL 설명 도식](https://storage.ghost.io/c/da/13/da13bbbc-4992-4354-bf2c-1426bcf8788c/content/images/2026/09/layout-example.png) 같은 비율을 두 가지 폭에 적용한 정적 도식. 위 조작 예시를 사용하지 않아도 비교할 수 있도록 함께 실었다. ## Inspect에서 실제로 가져가는 것 [Dev tools 가이드](https://help.penpot.app/user-guide/dev-tools/?ref=zerodraftlab.com)에 따르면 Inspect에서는 레이어 간 거리, 보드 가장자리까지의 거리, 스타일과 콘텐츠 속성을 확인한다. 속성을 하나씩 또는 묶어서 복사할 수 있고, 레이어의 CSS를 복사하는 기능도 있다. Code 탭이 제공하는 항목은 구체적이다. 선택한 레이어의 SVG·HTML 마크업과 CSS 스타일을 확인한다. 에셋 내보내기도 가능하다. 디자인 화면을 보고 수치를 다시 옮기는 과정에 이 정보를 사용할 수 있다. ![Penpot Grid 디자인에서 Inspect 코드 화면으로 전환하는 공식 시연](https://raw.githubusercontent.com/penpot/penpot/develop/docs/img/flexible-layouts/layouts-grid-code.gif) Grid와 코드 확인을 연결한 공식 문서의 움직이는 예시. 이미지: Penpot · [원문](https://help.penpot.app/user-guide/designing/flexible-layouts/?ref=zerodraftlab.com) **코드 조각을 얻는 것과 앱이 완성되는 것은 구분해야 한다.** 이 문서가 설명하는 범위는 선택한 디자인의 마크업·스타일·에셋이다. 로그인 처리, 데이터 저장, 오류 상태까지 완성된다는 근거로 읽을 수는 없다. 이번 조사에서는 내보낸 코드를 실제 서비스에 통합하지 않았다. 따라서 Penpot을 평가할 때는 ‘코드가 나오나’에서 한 걸음 더 들어가야 한다. 디자인에서 정한 배치와 속성이 어떤 형태로 전달되는지, 기존 프로젝트에서 그 결과를 어떻게 사용할지 확인할 문제다. 공식 문서만으로 통합 품질이나 절감 시간을 수치화할 수는 없다. ## 여러 화면이 같은 값을 쓰게 하는 방법 배치 규칙과 별개로, 여러 화면이 공유하는 색이나 크기 값도 관리해야 한다. [Design Tokens 가이드](https://help.penpot.app/user-guide/design-systems/design-tokens/?ref=zerodraftlab.com)는 토큰을 세트와 테마로 관리하고 JSON으로 가져오거나 내보내는 기능을 설명한다. 하나의 파일 또는 세트별로 나눈 여러 파일을 사용할 수 있다. 값을 파일로 주고받을 수 있다는 점은 팀의 연결 방식에 선택지를 준다. 다만 JSON을 내보냈다는 사실만으로 제품 코드와 항상 동기화된 것은 아니다. 어떤 파일을 기준으로 삼을지, 변경 내용을 언제 적용할지는 실제 작업 흐름에서 정할 일이다. **옆으로 넘겨보기 · 배치 / 검사 / 공유 값** ![배치: Flex와 Grid로 방향, 간격, 행과 열을 정한다](https://storage.ghost.io/c/da/13/da13bbbc-4992-4354-bf2c-1426bcf8788c/content/images/2026/09/slides.001-1.png) 1 / 3 · 요소의 관계를 정한다. ![검사: Inspect에서 거리와 속성, HTML SVG CSS를 확인한다](https://storage.ghost.io/c/da/13/da13bbbc-4992-4354-bf2c-1426bcf8788c/content/images/2026/09/slides.002-1.png) 2 / 3 · 확인하고 가져갈 정보를 정한다. ![공유 값: 디자인 토큰을 JSON으로 주고받으며 코드 반영 과정은 별도로 정한다](https://storage.ghost.io/c/da/13/da13bbbc-4992-4354-bf2c-1426bcf8788c/content/images/2026/09/slides.003-1.png) 3 / 3 · 공유 값의 이동과 반영을 구분한다. ## AI 연결도 디자인 파일을 다룬다 [공식 MCP Server 소개](https://penpot.app/ai/mcp-server?ref=zerodraftlab.com)는 AI 에이전트를 Penpot의 플러그인 API와 연결하는 경로를 안내한다. Codex·Cursor·Claude 등의 연결 예시를 제시하며, 디자인 파일을 읽고 상호작용하는 작업을 설명한다. 이 연결은 앞서 본 기능 위에서 이해할 수 있다. 화면의 요소와 속성을 다루는 작업에 AI를 참여시키는 것이다. 여기서는 MCP를 설치하거나 디자인을 생성하지 않았다. 연결 안내가 있다는 것과 원하는 디자인이 정확히 만들어진다는 것은 각각 검증할 항목이다. ## 무료 플랜과 직접 운영의 조건 [2026년 9월 7일 확인한 요금 안내](https://penpot.app/pricing?ref=zerodraftlab.com)에서 Cloud Professional은 사용자당 월 0달러로 표시된다. 팀 구성원 최대 8명, 무제한 뷰어, 최대 10GB 저장공간, 자동 저장 버전과 삭제 파일 복구 기간 각각 7일을 안내한다. 파일 수 제한이 없다는 문구에도 저장공간 범위라는 조건이 붙는다. [Self-host 안내](https://penpot.app/self-host?ref=zerodraftlab.com)는 자체 서버나 사설 클라우드에 설치하는 경로를 제공한다. 이 경우 저장 위치와 운영 환경을 직접 선택할 수 있다. 운영에 필요한 서버·백업·업데이트 비용까지 사라진다고 해석할 수는 없다. 이 글은 팀을 이주시켜 본 후기가 아니다. 공식 자료에서 확인한 Penpot의 제안은 배치 규칙을 디자인에 담고, 개발자가 그 속성과 코드를 확인하고, 공유 값을 파일로 주고받는 데 있다. 도입을 검토한다면 자기 팀의 화면 하나로 이 과정을 따라가며 실제로 가져갈 수 있는 정보부터 확인하는 편이 구체적이다. 자료 확인: 2026년 9월 7일. 공식 제품 화면·사용자 가이드에 대한 해설이다. ZDL 개념 예시를 제외한 화면은 Penpot 제공 자료이며 직접 사용한 결과로 제시하지 않았다. 설명 카드와 비율 도식은 ZDL 제작이다. ### 물병은 이미 많은데, Owala는 뚜껑에서 무엇을 바꿨을까 URL: https://zerodraftlab.com/owala-freesip-bottle-design/ Last updated: 2026-09-07T04:36:46.000Z [Owala FreeSip](https://owalalife.com/products/freesip?ref=zerodraftlab.com)을 설명하는 첫 동작은 간단하다. 병을 세운 채 안쪽 빨대로 마신다. 병을 기울이면 넓은 입구로 마신다. 공식 제품 소개는 이 두 동작을 한 뚜껑에 담았다는 점부터 설명한다. 물병 디자인을 보면 대개 색과 형태가 먼저 눈에 들어온다. FreeSip에도 눈에 띄는 배색이 있다. 하지만 사진에서 뚜껑 쪽으로 시선을 옮기면 다른 질문이 생긴다. 같은 물을 마시는데, 사용자가 병을 드는 방식까지 제품이 어디까지 받아줄 수 있을까. ![Owala FreeSip Neo Sage의 공식 제품 사진. 녹색 몸통과 분홍색 띠, 밝은 뚜껑의 배색](https://cdn.shopify.com/s/files/1/0439/2537/3087/products/Neo_Sage_24oz_SC-4000x4000-c38c18a.png?v=1762181963&width=640) FreeSip 24oz Neo Sage. 몸통·띠·뚜껑의 배색을 살펴보기 위한 공식 제품 사진. 이미지: Owala · [제품 원문](https://owalalife.com/products/freesip?ref=zerodraftlab.com) 이 제품은 [Exploding Topics의 2026년 8월 24일 미국 트렌드 목록](https://explodingtopics.com/blog/trending-topics?ref=zerodraftlab.com)에서 발견했다. 검색 관심은 글감을 찾는 단서로만 사용했다. 그 목록으로 디자인의 판매 효과를 설명할 수는 없다. 여기서는 스테인리스 FreeSip의 공식 제품 자료와 사용설명서를 읽고, 확인한 구조에 편집 해석을 덧붙인다. ## 같은 뚜껑에서 두 가지로 마신다 빨대를 쓰면 병을 세운 상태로 마실 수 있다. 넓은 입구를 쓰려면 병을 기울인다. [공식 제품 설명](https://checkout.owalalife.com/products/freesip?ref=zerodraftlab.com)이 제시하는 선택은 뚜껑을 교체하는 절차 없이 같은 FreeSip 입구에서 이루어진다. **세워서 마시기**내장 빨대를 이용한다. 병을 세운 상태를 유지한다. **기울여 마시기**넓은 입구를 이용한다. 병을 입 쪽으로 기울인다. 가령 책상에서 병을 세워 마시다가, 잠시 일어나 병을 기울여 마시는 장면을 떠올릴 수 있다. 이는 기능을 이해하기 위한 가상 상황이다. 두 방식 중 무엇이 더 편한지는 손의 크기, 자세, 습관에 따라 직접 확인할 문제다. ![병을 세운 상태로 Owala FreeSip을 마시는 공식 사용 장면](https://checkout.owalalife.com/cdn/shop/files/FreeSip_Stock_DSC08079-301x200-f29fae0.jpg?v=1730233758) 병을 크게 기울이지 않고 마시는 공식 연출 사진. 실사용 평가 자료는 아니다. 이미지: Owala · [원문](https://checkout.owalalife.com/products/freesip?ref=zerodraftlab.com) 디자인에서 읽을 수 있는 선택은 분명하다. 사용자가 두 방식 중 하나를 고르는 시점을 물병 구매 때부터 매번 마실 때까지 열어둔다. 이것은 기능 구성에 대한 해석이다. 음수량이 늘었는지, 다른 물병보다 만족도가 높은지까지 증명하는 말은 아니다. ## 손잡이는 버튼 앞에도 놓인다 버튼을 누르면 입구 덮개가 열린다. 휴대용 고리는 접었을 때 잠금 역할도 한다고 제품 페이지는 설명한다. 같은 부품이 들고 다닐 때와 닫아둘 때 서로 다른 일을 맡는다. [제품에 연결된 사용설명서](https://cdn.shopify.com/s/files/1/0439/2537/3087/files/owala%5Fusage%5Fguides-freesip%5F010528af-d433-4abd-b8a8-d6ecc20b44cf.pdf?v=1703090284&ref=zerodraftlab.com)는 이 역할을 더 구체적으로 적는다. 버튼이 다른 물건에 눌리지 않게 하고, 고리로 버튼을 덮어 우발적인 누름을 줄이라는 안내다. 따라서 ‘잠금’은 부품이 있다는 말에서 끝나지 않는다. 고리를 어디에 놓느냐까지 사용 조건에 포함된다. 아래 카드는 뚜껑을 둘러싼 동작을 나눈 것이다. 실제 기계 도면이 아닌 기능 설명이며, 세척 조건은 뒤에서 별도로 살펴본다. **옆으로 넘겨보기 · 열기 / 마시기 / 휴대하기** ![열기: 버튼을 눌러 입구 덮개를 연다](https://storage.ghost.io/c/da/13/da13bbbc-4992-4354-bf2c-1426bcf8788c/content/images/2026/09/slides.001.png) 1 / 3 · 버튼과 입구 덮개. 공식 제품 설명을 바탕으로 ZDL 제작. ![마시기: 세워서 빨대로, 기울여서 넓은 입구로 마신다](https://storage.ghost.io/c/da/13/da13bbbc-4992-4354-bf2c-1426bcf8788c/content/images/2026/09/slides.002.png) 2 / 3 · 같은 입구에서 고르는 두 동작. ![휴대하기: 고리로 버튼을 덮어 우발적인 누름을 줄인다](https://storage.ghost.io/c/da/13/da13bbbc-4992-4354-bf2c-1426bcf8788c/content/images/2026/09/slides.003.png) 3 / 3 · 사용설명서의 고리 배치 안내. ## 용량을 늘리면 병은 어느 쪽으로 커질까 공식 FAQ의 FreeSip 치수에는 흥미로운 차이가 있다. 24oz는 높이 10.68인치·지름 3.12인치, 32oz는 10.66인치·3.43인치다. 용량이 커지지만 표기 높이는 거의 같고, 지름이 커진다. 40oz는 높이 11.64인치·지름 3.60인치다. [치수 출처](https://owalalife.com/pages/faq?ref=zerodraftlab.com) ![공식 표기 치수 비교. 24oz 높이 27.13cm 지름 7.92cm, 32oz 높이 27.08cm 지름 8.71cm, 40oz 높이 29.57cm 지름 9.14cm](https://storage.ghost.io/c/da/13/da13bbbc-4992-4354-bf2c-1426bcf8788c/content/images/2026/09/dimensions.png) 공식 인치 값을 1인치=2.54cm로 환산하고 소수 둘째 자리까지 반올림했다. 제조사 표기값이며 실물 측정값이 아니다. 모델별 높이와 지름을 각각 같은 축으로 비교했다. | FreeSip | 높이 | 지름 | | ------- | ------- | ------ | | 24oz | 27.13cm | 7.92cm | | 32oz | 27.08cm | 8.71cm | | 40oz | 29.57cm | 9.14cm | 24oz와 32oz의 표기 지름 차이는 약 0.79cm다. 용량 숫자만 보면 놓칠 수 있는 차이다. 컵홀더나 가방 주머니처럼 폭에 제한이 있는 자리에 넣으려면 높이와 함께 지름을 대조해야 한다. 이 표로 특정 차량이나 가방에 맞는다고 판정한 것은 아니다. ## 배색에는 이름과 날짜가 붙는다 Owala의 [Color Drop 페이지](https://owalalife.com/color-drop?ref=zerodraftlab.com)는 색을 출시 일정과 함께 전시한다. 지난 제품을 모은 ‘The Vault’에는 이름과 날짜가 나란히 남는다. 예를 들어 Serene Tangerine은 2022년 6월 7일, Denim on Denim은 같은 해 7월 7일로 표시된다. ![Owala FreeSip Lemon Limeade 공식 사진. 노란 몸통과 주황색 계열 뚜껑, 연두색 고리의 배색](https://cdn.shopify.com/s/files/1/0439/2537/3087/files/24ozYellowFreeSip-SC-1080x1080-f521e30.png?v=1717000536&width=640) FreeSip Lemon Limeade. 본문 첫 사진과 다른 배색을 비교한다. 이 사진은 Color Drop 제품임을 뜻하지 않는다. 이미지: Owala · [제품 원문](https://owalalife.com/products/freesip?ref=zerodraftlab.com) 상시 제품 사진과 Color Drop의 기록은 구분해서 볼 필요가 있다. 전자는 한 제품의 구성 부위에 색을 배치한 결과다. 후자는 색 조합에 이름과 공개 시점을 붙여 별도의 소식으로 다루는 방식이다. 공식 기록에서 확인되는 것은 이러한 운영 형태까지다. 여기서 ‘색을 바꾸면 재구매가 일어난다’고 결론 내리기는 이르다. 구매자별 주문이나 색상별 판매 자료를 확인하지 않았다. 다만 제품을 설명할 때 쓰는 언어가 입구와 용량에서 색의 이름과 출시일로 확장된다는 점은 페이지에서 읽을 수 있다. ## 마신 뒤에는 분리해서 씻을 부품이 남는다 사용설명서는 뚜껑의 입구 패킹을 빼서 따로 세척하고, 빨대도 분리하도록 안내한다. 뚜껑은 식기세척기 상단 선반, 빨대는 수저 바구니를 사용할 수 있다고 적혀 있다. 스테인리스 몸통은 따뜻한 비눗물로 손세척하도록 안내한다. **공식 자료끼리 다른 부분도 있다.** [2024년 6월 7일 세척 블로그](https://checkout.owalalife.com/blogs/water-cooler/how-to-clean-a-stainless-steel-freesip-water-bottle?ref=zerodraftlab.com)에는 뚜껑을 식기세척기에서 제외하라는 내용과 ‘slider’라는 부품 표현이 나온다. 반면 제품에 연결된 PDF와 FAQ는 뚜껑의 상단 선반 사용을 허용한다. 이 글은 PDF를 기준으로 정리했다. 보유한 모델의 동봉 설명서가 다르면 그 안내를 먼저 확인해야 한다. [교체 부품 목록](https://checkout.owalalife.com/collections/replacement-parts?ref=zerodraftlab.com)에는 뚜껑, 빨대, FreeSip 입구 패킹이 따로 올라 있다. 부품을 별도로 안내한다는 점은 확인되지만, 모든 지역에서 항상 살 수 있다는 뜻은 아니다. 국내 배송이나 부품 호환성은 이번 조사에서 시험하지 않았다. 두 마시기 방식을 합친 구조를 평가하려면 씻고 다시 조립하는 과정도 함께 봐야 한다. 입구가 편리한지는 마시는 순간의 질문이고, 계속 쓰기 좋은지는 관리까지 포함한 질문이다. 여기서는 세척 시간이나 내구성을 측정하지 않았다. ## 어떤 음료든 담는 물병은 아니다 사용설명서에는 뜨겁거나 탄산이 있거나 부패하기 쉬운 액체를 넣지 말라는 제한이 있다. 전자레인지 사용, 냉동, 끓이기도 금지한다. 같은 브랜드의 다른 제품에 허용되는 음료를 스테인리스 FreeSip에 그대로 적용하면 안 된다. Owala의 제품 소개는 누수 방지를 내세운다. 이 글에서는 그 성능을 직접 시험하지 않았다. 사용 조건이 정해진 제품인 만큼, 그 표현을 모든 음료와 모든 상황에서 새지 않는다는 보장으로 확대하지 않는다. 공식 자료를 따라가며 확인한 FreeSip의 디자인은 손이 닿는 곳에 모인다. 버튼으로 열고, 두 방식으로 마시고, 고리로 버튼을 덮는다. 크기를 고를 때는 지름이 달라지고, 집에 돌아오면 빨대와 패킹을 분리해 씻는다. 색이 눈길을 끌었다면, 실제 선택은 이 동작들이 자신의 하루에 맞는지까지 살펴본 뒤에 할 수 있다. 자료 확인: 2026년 9월 7일. 공식 제품 자료에 대한 디자인 해설이며, 실물 사용 후기나 판매 성공 원인 분석이 아니다. 제품 사진은 Owala의 원본에 연결했고, 차트와 설명 카드는 ZDL이 제작했다. ### 단톡방으로도 약속을 잡는데, 초대장 앱은 무엇을 해결할까 URL: https://zerodraftlab.com/partiful-event-coordination/ Last updated: 2026-09-07T04:36:41.000Z [Partiful의 초대장](https://partiful.com/invitations/make-invitations?ref=zerodraftlab.com)에는 날짜와 장소뿐 아니라 참석 응답과 일괄 공지가 붙어 있다. 링크를 받은 사람이 응답하면 주최자는 같은 행사 페이지에서 그 상태를 확인한다. 초대장을 보낸 뒤에도 계속 사용하는 화면이다. 이 제품은 Exploding Topics의 [2026년 8월 24일 미국 트렌드 목록](https://explodingtopics.com/blog/trending-topics?ref=zerodraftlab.com)에 검색 증가율 9,800%로 올라 있다. 이 숫자는 그 사이트가 표시한 검색 관심 지표다. 이용자 수나 매출 증가율은 아니다. 공개 목록만으로 한국에서 얼마나 쓰이는지, 어떤 기능 때문에 관심이 늘었는지도 알 수 없다. 이 글은 그 수치에서 제품을 발견한 뒤, Partiful의 공식 화면과 도움말로 무엇을 제공하는지 살펴본다. ![Partiful 공식 소개 페이지의 공유 가능한 초대·참석 응답 링크 예시](https://framerusercontent.com/images/YEHEiNRFbGGhb195mSenrepKkyM.jpg?height=500&width=600) 초대 링크와 참석 응답을 함께 보여주는 공식 제품 이미지. 이미지: Partiful · [원문](https://partiful.com/invitations/make-invitations?ref=zerodraftlab.com) ## 초대장을 보내고 나서 생기는 일 친구들과 저녁 모임을 준비한다고 가정해보자. 날짜와 장소를 정해 단톡방에 올린다. 누군가는 참석한다고 답하고, 누군가는 동반자를 데려가도 되는지 묻는다. 장소가 바뀌면 다시 공지하고, 행사가 끝나면 사진을 모은다. 이는 제품을 설명하기 위한 가상 상황이며, 실제 이용자 인터뷰는 아니다. 이 상황에서 주최자가 관리하는 정보는 서로 다르다. 날짜와 장소는 모임의 현재 정보이고, 참석 여부는 사람마다 달라지는 상태이며, 사진은 모임이 끝난 뒤 쌓이는 기록이다. ZDL이 Partiful에서 주목한 점은 이 정보들을 하나의 행사를 기준으로 연결한다는 구성이다. **01 준비**날짜·장소·초대 디자인 게스트 질문 설정 **02 참석 관리**응답·정원·대기명단 변경 사항 공지 **03 모임 이후**행사 페이지에 참석자 사진 추가 공식 생성·설정·사진 안내를 묶은 ZDL 도식. 필수 절차나 효과 측정 결과를 뜻하지 않는다. ## 먼저 페이지를 만들고, 익숙한 곳으로 링크를 보낸다 [첫 행사 만들기 도움말](https://help.partiful.com/en-us/articles/15525299-creating-your-first-partiful-event?ref=zerodraftlab.com)은 행사 정보를 입력하고 테마와 효과를 고른 뒤 설정을 조정하는 순서로 안내한다. 공동 주최자, 결제 정보, 참석 인원 제한, 게스트 질문 등을 설정할 수 있다. 저장한 뒤에도 행사를 수정할 수 있다. 초대 경로는 여러 가지다. 이전 행사에서 만난 사람을 Partiful 안에서 초대할 수 있고, 앱에서 연락처를 동기화하는 경로도 있다. 링크를 복사해 문자나 이메일로 보내는 방법도 안내한다. 따라서 이 제품의 사용 흐름에는 기존 연락 수단이 함께 들어간다. 초대 링크를 전달하고, 세부 정보와 응답은 행사 페이지에서 관리하는 구조다. ![Partiful 초대장 테마와 시각 효과의 공식 예시](https://framerusercontent.com/images/bCk52c4u3kQtdzFPb0hyNtk5mck.jpg?height=500&width=600) 초대장 디자인을 고르는 공식 예시. 이미지: Partiful · [원문](https://partiful.com/invitations/make-invitations?ref=zerodraftlab.com) 공식 소개는 색상·폰트·애니메이션·사진을 바꿀 수 있다고 설명한다. 이 디자인이 참석률을 높인다는 실험 결과는 여기서 확인하지 않았다. 다만 초대받은 사람이 처음 보는 화면과, 주최자가 응답을 관리하는 기능이 같은 제품 안에 있다는 점은 확인할 수 있다. ## ‘누가 오는가’를 관리할 수 있는 상태로 만든다 [인원 제한 도움말](https://help.partiful.com/en-us/articles/15525379-how-can-i-limit-group-size?ref=zerodraftlab.com)은 최대 정원과 자동 대기명단을 설정할 수 있다고 안내한다. 자리가 생기면 다음 대기자를 자동으로 추가하고 문자로 알린다. 동반 인원도 제한할 수 있다. ‘참석자가 많다’는 말을 실제로 처리할 수 있는 정원과 순서로 바꾼 기능이다. 질문도 응답에 붙는다. [Guest Questionnaire 도움말](https://help.partiful.com/en-us/articles/15525424-collecting-guest-info-dietary-restrictions-names-of-1s-etc?ref=zerodraftlab.com)에 따르면 참석 응답을 받을 때 질문을 제시할 수 있고, 답변은 주최자만 볼 수 있다. 식이 제한이나 동반자 이름처럼 준비에 필요한 정보를 모으는 용도다. **질문을 추가하는 시점이 중요하다.** 이미 참석 응답을 한 뒤 새 질문이 추가되면, 기존 참석자는 다시 응답해야 갱신된 질문을 볼 수 있다. 질문을 만들었다고 모든 참석자의 답변이 자동으로 채워지지는 않는다. 이 조건은 기능을 소개할 때 빠뜨리기 쉽다. 질문을 받을 수 있다는 것과 필요한 답이 모두 모였다는 것은 다르다. 주최자는 초대 전에 어떤 정보가 필요한지 정해야 하고, 질문을 바꾼 뒤에는 기존 참석자의 응답 상태도 살펴야 한다. ## 초대 이후에도 같은 페이지를 다시 쓰게 한다 [Partiful 홈페이지](https://partiful.com/?ref=zerodraftlab.com)는 Text Blast로 참석자들에게 변경 사항을 한 번에 알리는 기능, 날짜를 정하기 전 투표, 게스트 질문, 사진 앨범을 소개한다. 제품이 묶은 일의 범위가 행사 당일 전후까지 이어진다. ![Partiful Text Blast 공지 기능의 공식 화면 예시](https://framerusercontent.com/images/Y0qxuGzySDF4eA6SV0koIHlYko.jpg?height=1000&width=1200) 참석자에게 공지를 보내는 Text Blast의 공식 이미지. 이미지: Partiful · [원문](https://partiful.com/invitations/make-invitations?ref=zerodraftlab.com) [서비스 소개 도움말](https://help.partiful.com/en-us/articles/15525594-why-use-partiful?ref=zerodraftlab.com)은 다른 참석자를 볼 수 있는 기능을 주최자가 제어하며, 행사 뒤에는 참석자들이 사진을 페이지에 추가할 수 있다고 설명한다. 함께 누가 오는지 확인하는 일과 함께 찍은 사진을 찾는 일이 같은 행사에 연결된다. 다음 세 장은 도움말의 기능과 조건을 다시 정리한 것이다. 앞의 설명과 함께 읽으면 초대장을 만든 뒤 주최자가 계속 다루는 일이 무엇인지 볼 수 있다. **옆으로 넘겨보기 · 준비 / 진행 / 이후** ![준비: 참석 응답 때 질문을 받고, 질문을 나중에 추가하면 기존 참석자는 다시 응답해야 한다](https://storage.ghost.io/c/da/13/da13bbbc-4992-4354-bf2c-1426bcf8788c/content/images/2026/09/slide.001.png) 1 / 3 · 질문 수집 조건. ZDL 제작, Partiful 도움말 근거. ![진행: 정원과 자동 대기명단을 설정하고 빈자리가 생기면 다음 대기자를 추가한다](https://storage.ghost.io/c/da/13/da13bbbc-4992-4354-bf2c-1426bcf8788c/content/images/2026/09/slide.002.png) 2 / 3 · 정원과 대기명단. ZDL 제작, Partiful 도움말 근거. ![이후: 참석자들이 행사 페이지에 사진을 추가할 수 있다](https://storage.ghost.io/c/da/13/da13bbbc-4992-4354-bf2c-1426bcf8788c/content/images/2026/09/slide.003.png) 3 / 3 · 행사 뒤 사진 공유. ZDL 제작, Partiful 도움말 근거. ## 무료 초대와 유료 티켓은 조건이 다르다 초대장 소개 페이지는 초대 제작을 무료로 안내한다. 유료 티켓 판매까지 모든 비용이 없다는 뜻으로 읽으면 안 된다. [2026년 6월 16일 수수료 도움말](https://help.partiful.com/en-us/articles/15525398-what-fees-does-partiful-charge?ref=zerodraftlab.com)은 티켓 수수료가 행사 규모와 티켓 가격에 따라 달라진다고 설명한다. 무료 티켓에는 수수료가 없다고 안내한다. 유료 티켓 설정에는 주최자가 받을 금액인 ‘You receive’와 참석자에게 표시할 ‘Ticket price’가 있다. 도움말은 표시 가격 112달러, 주최자 수령 100달러인 예시를 든다. 차액 12달러를 아래에 표시했다. 이 사례에서 계산한 금액이며 모든 행사에 적용할 고정 요율은 아니다. 세금이 적용되면 결제 화면에 별도로 표시된다. ![Partiful 공식 예시: 표시 티켓 가격 112달러 중 주최자 수령 100달러, 서비스 수수료 12달러. 세금 별도](https://storage.ghost.io/c/da/13/da13bbbc-4992-4354-bf2c-1426bcf8788c/content/images/2026/09/fee-chart.png) 공식 도움말의 단일 예시를 Vega-Lite로 재구성했다. 보편적 수수료율이나 실제 거래 실측이 아니다. [출처](https://help.partiful.com/en-us/articles/15525398-what-fees-does-partiful-charge?ref=zerodraftlab.com) ## 사람을 모으는 기능에는 공개 범위도 붙는다 [행사 설정 도움말](https://help.partiful.com/en-us/articles/15525301-what-features-are-available-to-change-in-my-event-settings?ref=zerodraftlab.com)에는 게스트 승인, 참석 응답 켜기·끄기, 동반자 수, 게스트 명단 익명화, 참석 인원 숨김, 행사 열람 비밀번호, 공개·비공개 설정이 나온다. 자동 알림을 확인하거나 끄는 항목도 있다. 여기서 서로 다른 결정을 한꺼번에 ‘비공개 행사’라고 부르지 않는 편이 정확하다. 행사에 들어올 수 있는지, 참석을 승인받아야 하는지, 다른 참석자의 정보를 볼 수 있는지는 각각 확인할 설정이다. 공식 문서가 여러 항목을 따로 제공하는 만큼, 초대 페이지를 공유하기 전에 그 범위를 정할 수 있다. | 주최자의 질문 | 공식 문서의 관련 설정 | | -------------- | -------------------- | | 누구의 참석을 받을까? | 게스트 승인, 참석 응답, 동반자 수 | | 참석자끼리 무엇을 볼까? | 게스트 명단 익명화, 인원 숨김 | | 행사 페이지를 누가 열까? | 공개·비공개, 열람 비밀번호 | ## 이 제품에서 확인한 것, 아직 모르는 것 ZDL의 해석은 이렇다. Partiful의 제품 단위는 한 번 보내고 끝내는 초대 이미지보다 길다. 참석 의사를 받고, 빈자리를 처리하고, 변경을 알리고, 사진을 모으는 동안 행사 페이지가 유지된다. 위에서 확인한 기능들을 함께 놓으면 주최자가 관리할 대상이 ‘여러 대화’에서 ‘하나의 행사와 그 참석 상태’로 정리되는 구성을 읽을 수 있다. 그 구성이 얼마나 시간을 아끼는지, 실제 참석을 얼마나 늘리는지는 이번 조사로 확인하지 못했다. 한국 전화번호로 초대와 알림을 받아보거나 유료 티켓을 판매한 것도 아니다. 따라서 이 글은 국내 운영을 검증한 사용 후기나 메신저와의 성능 비교가 아니다. 공식 자료로 확인한 제품 구성과 그에 대한 편집 해설이다. 처음의 질문으로 돌아가면, 단톡방에서도 약속은 잡을 수 있다. Partiful이 별도로 제공하는 것은 행사 정보를 다시 찾고, 사람마다 달라지는 응답을 관리하고, 행사 뒤의 기록을 붙일 수 있는 페이지다. 이 제품을 살펴볼 때는 초대장 디자인과 함께 그 페이지에 남는 상태와 설정까지 볼 필요가 있다. 자료 확인: 2026년 9월 7일. Exploding Topics는 발견 경로, Partiful 공식 소개와 도움말은 기능 설명의 근거다. 제품 이미지의 권리는 Partiful 및 각 권리자에게 있으며 해당 기능을 설명하기 위해 원문과 연결했다. 흐름도·슬라이드·차트는 ZDL 재구성이다. ### 네이버 검색에서 무엇이 달라졌나: AI 광고·플레이스·쇼핑의 공식 노출 조건 URL: https://zerodraftlab.com/naver-search-exposure-rules/ Last updated: 2026-09-07T04:36:54.000Z SEARCH BRIEFING · 2026.09.07 네이버는 2026년 9월 3일 [쇼핑검색광고의 노출 위치와 개수를 조정하는 방식을 확대한다](https://ads.naver.com/notice/34004?ref=zerodraftlab.com)고 공지했다. 적용 예정일은 9월 10일이다. 광고와 일반 상품, 슈퍼적립 상품의 개수와 위치를 고정하지 않고 이용자 반응에 따라 구성한다는 내용이다. 같은 공지에는 광고 등록 방법, 노출 순위 산정, 과금 방식은 기존과 같다는 설명도 들어 있다. 변경 대상은 네이버 PC 통합검색과 모바일·PC 쇼핑이다. 모바일 통합검색에는 이 방식이 적용돼 있다고 네이버는 설명한다. 9월 7일 기준으로 확인되는 사실은 기존 적용 영역과 앞으로 확대할 영역이 나뉘어 있다는 것, 그리고 이번 공지가 화면에 배치되는 광고의 위치·개수와 순위 산정을 구분하고 있다는 것이다. 이 글은 2026년 9월 7일까지 확인한 네이버 공식 공지와 고객센터 설명을 바탕으로 검색 노출 조건을 살펴본다. 날짜가 있는 변경 공지와 현재 공개된 상시 기준을 구분했다. 공지된 적용 상태를 기술하며, 개별 키워드의 검색 화면이나 업체 순위를 직접 측정한 결과는 포함하지 않는다. **이 글에서 확인할 세 가지** 쇼핑: 이미 적용된 변경과 예정된 테스트의 날짜 AI: 출처 인용·업체 요약·유료 광고의 서로 다른 조건 플레이스: 이미지·별점 표시와 리뷰 제재의 범위 ## 01 · 9월 쇼핑 개편은 언제, 어디에 적용되나 9월에는 쇼핑 화면에 관한 공지가 더 있다. [8월 27일 공지](https://ads.naver.com/notice/33795?ref=zerodraftlab.com)는 모바일 통합검색의 일부 질의에서 가격비교와 네이버플러스 스토어 두 컬렉션을 하나로 합치는 일정을 9월 3일로 안내했다. 이어 나온 [9월 4일 공지](https://ads.naver.com/notice/33965?ref=zerodraftlab.com)는 일부 패션 질의에 쇼핑 컬렉션 개선을 적용했다고 설명하면서, 범위와 노출 요소를 추가로 바꾸는 테스트를 예고했다. 추가 테스트 기간은 9월 11일부터 17일까지다. 대상도 모바일 통합검색의 일부 질의와 일부 트래픽으로 제한돼 있다. 따라서 9월 7일 시점의 문서에서는 앞선 적용과 뒤따를 테스트를 별도로 읽어야 한다. 후속 공지의 존재는 테스트가 전면 적용됐다는 근거가 되지 않는다. [![9월 쇼핑 변경 일정. 초록은 공지에서 적용을 확인한 항목, 황색은 9월 7일 이후의 예정 항목이다. 출처: 네이버 광고 공지 33795·33965·34004. ZDL 재구성.](https://storage.ghost.io/c/da/13/da13bbbc-4992-4354-bf2c-1426bcf8788c/content/images/2026/09/timeline.png)](https://storage.ghost.io/c/da/13/da13bbbc-4992-4354-bf2c-1426bcf8788c/content/images/2026/09/timeline.png?ref=zerodraftlab.com) 9월 쇼핑 변경 일정. 초록은 공지에서 적용을 확인한 항목, 황색은 9월 7일 이후의 예정 항목이다. 출처: 네이버 광고 공지 33795·33965·34004\. ZDL 재구성. 상품 자체의 검색 평가 기준은 다른 문서에 있다. [스마트스토어 고객센터](https://help.sell.smartstore.naver.com/faq/content.help?faqId=4814&ref=zerodraftlab.com)는 네이버쇼핑 검색 순위가 적합도·인기도·신뢰도 점수를 바탕으로 그룹상품·카탈로그와 함께 구성된다고 설명한다. 같은 도움말은 검색품질 체크에서 스마트스토어 전용 상품명이 아닌 기본 상품명을 사용한다는 주의사항도 안내한다. 화면 개편 일정과 상품정보 평가 기준은 각각 공개돼 있으며, 9월 10일 공지는 기존 순위 산정을 유지한다고 명시한다. ## 02 · 검색 AI, 플레이스 AI, AI 광고의 조건은 다르다 AI가 들어간 검색에서도 노출되는 대상에 따라 설명이 달라진다. 네이버가 [6월 26일 정식 출시한 AI탭](https://www.navercorp.com/media/pressReleasesDetail?seq=10034429&ref=zerodraftlab.com)은 전체 사용자를 대상으로 한 대화형 검색 서비스다. 공식 발표에는 모바일과 PC 검색창의 진입 버튼, 지도 확인, 실시간 예약 가능 시간 안내가 포함돼 있다. 장소를 답변에 제시하는 기능과 예약에 필요한 정보를 연결하는 기능을 함께 설명한다. [![AI탭의 모바일·PC 검색 진입 화면. 6월 26일 정식 출시 발표에 포함된 예시 · 이미지: 네이버, 공식 자료](https://corp-homepage-phinf.pstatic.net/MjAyNjA2MjZfMTg3/MDAxNzgyNDMwMDA3MTAw.ziBXbshdFPt_9zcIgCyK-du55UykjbZ7FCi0fZKC8wcg.xDAlqEOjNr9dPnsmHB6DznQ1uHogK-tDm4WtR59Dtrgg.PNG/%EC%9D%B4%EB%AF%B8%EC%A7%801_%EB%84%A4%EC%9D%B4%EB%B2%84_PC%EC%99%80_%EB%AA%A8%EB%B0%94%EC%9D%BC_%EA%B2%80%EC%83%89%EC%B0%BD%EC%97%90%EC%84%9C_%ED%81%B4%EB%A6%AD_%ED%95%9C%EB%B2%88%EC%9C%BC%EB%A1%9C_AI%ED%83%AD_%EC%9D%B4%EC%9A%A9_%EA%B0%80%EB%8A%A5.png)](https://corp-homepage-phinf.pstatic.net/MjAyNjA2MjZfMTg3/MDAxNzgyNDMwMDA3MTAw.ziBXbshdFPt%5F9zcIgCyK-du55UykjbZ7FCi0fZKC8wcg.xDAlqEOjNr9dPnsmHB6DznQ1uHogK-tDm4WtR59Dtrgg.PNG/%EC%9D%B4%EB%AF%B8%EC%A7%801%5F%EB%84%A4%EC%9D%B4%EB%B2%84%5FPC%EC%99%80%5F%EB%AA%A8%EB%B0%94%EC%9D%BC%5F%EA%B2%80%EC%83%89%EC%B0%BD%EC%97%90%EC%84%9C%5F%ED%81%B4%EB%A6%AD%5F%ED%95%9C%EB%B2%88%EC%9C%BC%EB%A1%9C%5FAI%ED%83%AD%5F%EC%9D%B4%EC%9A%A9%5F%EA%B0%80%EB%8A%A5.png?ref=zerodraftlab.com) AI탭의 모바일·PC 검색 진입 화면. 6월 26일 정식 출시 발표에 포함된 예시 · 이미지: 네이버, [공식 자료](https://www.navercorp.com/media/pressReleasesDetail?seq=10034429&ref=zerodraftlab.com) 검색 결과의 AI 브리핑에는 답변의 근거가 되는 콘텐츠도 제시된다. 네이버는 [8월 7일 발표](https://www.navercorp.com/media/pressReleasesDetail?seq=10034578&ref=zerodraftlab.com)에서 검색 의도에 맞는 답변과 함께 블로그 등 출처 콘텐츠를 연결한다고 설명했다. 이 발표에는 창작자 지원 프로그램인 네이버 메이트의 선정 기준도 나온다. AI 브리핑 인용 횟수, 주제별 전문성, 활동성 등을 종합해 매월 약 3,000명을 선정한다는 내용이다. 이 문서에서 인용 횟수는 메이트 선정에 고려하는 자료다. 메이트 선정자가 반드시 AI 브리핑에 인용된다거나 특정 검색어에서 상위에 노출된다는 보장 조건은 제시하지 않는다. 프로그램의 선정 기준과 검색의 출처 선정 조건을 같은 것으로 설명할 근거는 이 발표에 없다. 업체 상세 화면의 AI 브리핑은 별도 도움말을 갖고 있다. [플레이스 AI 브리핑 안내](https://help.naver.com/service/30026/contents/24632?lang=ko&osType=COMMONOS&ref=zerodraftlab.com)는 음식점·카페 등 일부 업종과 리뷰가 많은 업체를 대상으로 서비스한다고 설명한다. 업체명으로 검색했을 때의 플레이스 검색 결과와 업체 상세 페이지 홈탭이 노출 영역이다. 리뷰 수가 기준에 맞지 않으면 제공되지 않지만, 최소 리뷰 수는 도움말에 기재하지 않았다. 플레이스 AI 브리핑은 네이버 이용자가 작성한 데이터를 바탕으로 제공된다. 사업주가 내용을 임의로 수정할 수는 없다. 제공 대상 업체는 스마트플레이스의 업체정보·AI 정보 메뉴에서 노출 여부를 바꿀 수 있고, 저장한 설정은 1일 이내 검색 결과에 반영된다고 안내한다. 요약 내용의 편집 권한과 표시 여부를 정하는 권한이 구분돼 있다. 여기에 유료 광고가 추가됐다. [네이버 AI 광고 출시 공지](https://ads.naver.com/notice/31888?ref=zerodraftlab.com)는 광고주센터 오픈을 7월 15일, 노출 오픈을 7월 21일로 안내했다. 대상은 통합검색의 독립된 AI 브리핑 영역이며, 플레이스의 이용자 리뷰 요약 영역은 제외한다. 정식 서비스의 대상 상품은 ADVoost 검색광고로 명시돼 있다. 광고 문안은 광고주센터와 랜딩페이지 정보를 활용해 AI가 작성하며 광고주가 직접 수정할 수 없다. 광고그룹에서 운영 여부를 설정하고, 출시 시 확장검색 광고그룹은 기본 켜짐으로 안내됐다. 과금은 클릭당 방식이고 확장검색 예산을 사용한다. 관련 파워링크 광고의 평균 가격을 기반으로 CPC가 정해지며 별도 입찰가를 설정하지 않는다. 같은 공지는 시간·요일 타겟팅을 제공하되, 지역·성별·연령·이용자 세그먼트는 광고 선출의 힌트로 사용한다고 설명한다. 모든 AI 브리핑에 광고를 노출하지 않으며, 소재 심의 대상 의료 광고는 노출이 제한된다. 이 조건은 AI 브리핑에 삽입되는 광고에 관한 것이다. 블로그 원문의 출처 인용이나 플레이스 리뷰 요약에 그대로 옮겨 적용할 조건은 아니다. **슬라이드 1–3 · AI가 노출되는 세 경로** 옆으로 밀어 비교하세요. 이미지를 누르면 크게 볼 수 있습니다. [![1 / 3 · 검색 AI 브리핑의 출처 콘텐츠. 본문 공식 자료를 바탕으로 ZDL 재구성.](https://storage.ghost.io/c/da/13/da13bbbc-4992-4354-bf2c-1426bcf8788c/content/images/2026/09/slide-01.png)](https://storage.ghost.io/c/da/13/da13bbbc-4992-4354-bf2c-1426bcf8788c/content/images/2026/09/slide-01.png?ref=zerodraftlab.com) 1 / 3 · 검색 AI 브리핑의 출처 콘텐츠. 본문 공식 자료를 바탕으로 ZDL 재구성. [![2 / 3 · 업체 상세 화면의 플레이스 AI 브리핑. 본문 공식 자료를 바탕으로 ZDL 재구성.](https://storage.ghost.io/c/da/13/da13bbbc-4992-4354-bf2c-1426bcf8788c/content/images/2026/09/slide-02.png)](https://storage.ghost.io/c/da/13/da13bbbc-4992-4354-bf2c-1426bcf8788c/content/images/2026/09/slide-02.png?ref=zerodraftlab.com) 2 / 3 · 업체 상세 화면의 플레이스 AI 브리핑. 본문 공식 자료를 바탕으로 ZDL 재구성. [![3 / 3 · ADVoost 검색광고의 AI 브리핑 광고. 본문 공식 자료를 바탕으로 ZDL 재구성.](https://storage.ghost.io/c/da/13/da13bbbc-4992-4354-bf2c-1426bcf8788c/content/images/2026/09/slide-03.png)](https://storage.ghost.io/c/da/13/da13bbbc-4992-4354-bf2c-1426bcf8788c/content/images/2026/09/slide-03.png?ref=zerodraftlab.com) 3 / 3 · ADVoost 검색광고의 AI 브리핑 광고. 본문 공식 자료를 바탕으로 ZDL 재구성. ## 03 · 플레이스는 무엇을 평가하고, 무엇을 보여주나 플레이스 검색의 기본 기준은 [공식 SEO·어뷰징 운영원칙](https://new.smartplace.naver.com/help/policy?menu=abuse&tab=smartplace&ref=zerodraftlab.com)에서 더 구체적으로 확인할 수 있다. 네이버는 검색어와 업체의 유사도, 카테고리와 업체의 인기도, 거리, 정보의 충실성을 함께 고려한다고 설명한다. 방문 리뷰의 텍스트와 사진, 자체 수집 검색 데이터도 종합적으로 검토한다고 밝힌다. 유사도 설명에는 업체 소개와 리뷰를 분석한 의미 기반 매칭이 등장한다. 업체 인기도에는 언급 수·이미지 수·클릭 수 등이 포함된다. 거리 설명은 사용자 위치와 업체 사이의 거리를 기준으로 한다. 인기도가 높으면 더 먼 업체가 상단에 노출될 수도 있다고 명시돼 있다. 이 문서는 클릭 하나나 거리 하나가 순위를 단독으로 결정한다고 설명하지 않는다. 네이버는 같은 운영원칙에서 과도한 허위 클릭, 허위 예약과 취소·환불, 비정상적인 검색 패턴 등을 어뷰징으로 안내한다. 정제 로직을 거쳐 적절하다고 판단한 데이터만 검색에 반영하고 세부 필터 기준은 공개하지 않는다고 설명한다. 공개된 평가 요소 안에 클릭과 리뷰가 있다는 사실과, 조작된 클릭·리뷰를 유효한 데이터로 인정한다는 주장은 양립하지 않는다. 기본 평가 기준과 별개로 검색 화면도 업종에 따라 바뀌었다. [5월 21일 공지](https://smartplace.naver.com/notices/1018?ref=zerodraftlab.com)는 5월 28일부터 일부 업종에 범용 특화 컬렉션을 적용한다고 안내한다. 예시 업종은 헬스장·필라테스·요가·사진관·꽃집이다. 대상 업종에 등록된 업체에는 별도 신청 없이 적용된다는 설명이다. 이 화면에서는 업체 이미지 여러 장과 방문자 리뷰의 이미지·일부 문장을 검색 결과에 함께 제공한다. 거리순·관련도순 정렬과 영업중·예약·쿠폰·휠체어 출입 가능 필터도 안내돼 있다. 모바일 일반 업체에는 업체 이미지 2장과 방문자 리뷰 이미지 6장, 최대 8장을 제공하는 구성이다. PC 통합검색과 PC 지도에는 업체 대표 이미지 1장을 노출한다고 설명한다. 업종과 기기에 따른 차이가 공지에 포함돼 있다. [![범용 특화 컬렉션의 공식 화면 예시. 적용 업종·기기에 따라 구성이 다르다 · 이미지: 네이버, 공식 자료](https://ldb-phinf.pstatic.net/20260521_20/1779340833155zDPVx_JPEG/%BB%E7%BE%F7%C1%D6%B0%F8%C1%F6%BF%EB.01.jpg)](https://ldb-phinf.pstatic.net/20260521%5F20/1779340833155zDPVx%5FJPEG/%BB%E7%BE%F7%C1%D6%B0%F8%C1%F6%BF%EB.01.jpg?ref=zerodraftlab.com) 범용 특화 컬렉션의 공식 화면 예시. 적용 업종·기기에 따라 구성이 다르다 · 이미지: 네이버, [공식 자료](https://smartplace.naver.com/notices/1018?ref=zerodraftlab.com) [![모바일 범용 특화 컬렉션의 최대 이미지 구성. 일반 업체 2+6장, 광고 운영 업체 3+4장. 순위나 클릭 성과를 나타내는 차트가 아니다. 출처: 스마트플레이스 공지 1018. ZDL 재구성.](https://storage.ghost.io/c/da/13/da13bbbc-4992-4354-bf2c-1426bcf8788c/content/images/2026/09/image-counts.png)](https://storage.ghost.io/c/da/13/da13bbbc-4992-4354-bf2c-1426bcf8788c/content/images/2026/09/image-counts.png?ref=zerodraftlab.com) 모바일 범용 특화 컬렉션의 최대 이미지 구성. 일반 업체 2+6장, 광고 운영 업체 3+4장. 순위나 클릭 성과를 나타내는 차트가 아니다. 출처: 스마트플레이스 공지 1018\. ZDL 재구성. 식당은 다른 정보 항목이 추가됐다. [7월 9일 공지](https://new.smartplace.naver.com/notices/1063?ref=zerodraftlab.com)는 콜키지의 병 수·비용·조건, 대관, 키즈 메뉴, 기념일·생일 혜택 등 상세정보를 이용자 화면에 반영한다고 안내했다. 공통 항목으로는 인근 연계 주차장 정보가 있는 업체의 홈탭·정보탭 표시를 설명한다. 대관과 좌석 정보는 식당 업종에서만 노출된다고 명시한다. 해당 공지가 안내하는 것은 정보의 표시 범위이며, 항목을 입력하면 일정 순위에 오른다는 수치는 제시하지 않는다. ## 04 · 별점 표시와 리뷰 제재는 업체에 어떤 영향을 주나 리뷰 별점 역시 표시 대상과 설정 범위를 나눠야 한다. [6월 1일 별점 정보 노출 공지](https://smartplace.naver.com/notices/1028?ref=zerodraftlab.com)는 4월 6일부터 수집한 별점이 포함된 리뷰를 7월 9일부터 주요 지면에 공개한다고 안내했다. 평균 별점은 2021년 10월 25일까지 수집했던 과거 별점과 새로 수집한 별점을 합산해 산출한다. 사업주는 평균 별점의 표시 여부를 설정할 수 있다. 기존 업체는 저장된 ON/OFF 값을 유지하며, 2026년 4월부터 수집을 재개한 신규 업장은 별도 설정이 없으면 OFF로 적용된다고 안내됐다. 평균을 숨겨도 개별 리뷰의 별점은 표시된다. 과거 별점을 수집했지만 이번 재수집 대상에 포함되지 않은 일부 업종은 기존 평균 별점 노출을 해제한다고 설명한다. [![별점 정보가 노출되는 화면의 공식 안내. 평균 별점과 개별 리뷰 별점은 표시 설정 범위가 다르다 · 이미지: 네이버, 공식 자료](https://ldb-phinf.pstatic.net/20260601_49/1780276410196izcmS_JPEG/%BB%E7%BE%F7%C1%D6_%BA%B0%C1%A1_%C1%A4%BA%B8_%B3%EB%C3%E2_%BE%C8%B3%BB.jpg)](https://ldb-phinf.pstatic.net/20260601%5F49/1780276410196izcmS%5FJPEG/%BB%E7%BE%F7%C1%D6%5F%BA%B0%C1%A1%5F%C1%A4%BA%B8%5F%B3%EB%C3%E2%5F%BE%C8%B3%BB.jpg?ref=zerodraftlab.com) 별점 정보가 노출되는 화면의 공식 안내. 평균 별점과 개별 리뷰 별점은 표시 설정 범위가 다르다 · 이미지: 네이버, [공식 자료](https://smartplace.naver.com/notices/1028?ref=zerodraftlab.com) 노출을 제한하는 조치도 업체 단위로 공지돼 있다. [1월 28일 리뷰 어뷰징 공지](https://smartplace.naver.com/notices/957?ref=zerodraftlab.com)는 가짜 영수증, 리뷰 작성을 목적으로 한 허위 예약, 방문·경험하지 않은 사람이 작성한 허위 리뷰를 제재 대상으로 열거한다. 해당 행위가 한 번 확인돼도 업체 단위 페널티를 적용한다고 안내한다. 공지된 조치는 리뷰 탭의 일정 기간 블라인드, 업체 AI 브리핑의 일정 기간 삭제, 등록된 모든 리뷰의 미노출 가능성이다. AI 브리핑은 삭제 후 재생성이 불가능할 수도 있다고 명시한다. 이 문서로 확인할 수 있는 것은 네이버가 안내한 제재 범위다. 실제로 제재받은 업체 수나 업종별 순위 변동은 공지에 제시돼 있지 않다. ## 05 · 블로그와 AI 생성 글의 공개 평가 기준 블로그 검색은 출처와 개별 문서에 관한 설명을 함께 제공한다. [C-Rank 도움말](https://help.naver.com/service/5626/contents/22927?ref=zerodraftlab.com)은 개별 문서보다 출처의 신뢰도를 평가하는 기술이라고 정의한다. 관심사 집중도, 정보 품질, 콘텐츠 소비·생산의 연결 등을 종합적으로 판단한다고 설명한다. [D.I.A. 도움말](https://help.naver.com/service/5626/contents/22926?osType=COMMONOS&ref=zerodraftlab.com)은 키워드별로 이용자가 선호하는 문서에 대한 점수를 랭킹에 반영한다고 설명한다. 주제 적합도, 경험 정보, 정보 충실성, 문서 의도, 상대적인 어뷰징 척도, 독창성, 적시성이 공개된 요소다. 매일 변화하는 데이터를 학습해 품질 요소와 기준값을 갱신하고, 정규화한 점수를 랭킹에 주기적으로 반영한다고 안내한다. 두 설명은 현재 공개된 기준으로 읽어야 한다. 도움말의 존재만으로 과거와 동일한 가중치가 적용된다고 확인할 수는 없다. [블로그 검색 소개](https://help.naver.com/service/5626/contents/22921?osType=COMMONOS&ref=zerodraftlab.com)도 C-Rank와 D.I.A.를 비롯한 여러 모델과 변질·스팸·유사문서 분석을 지속적으로 고도화한다고 설명한다. 기본순과 최신순은 로직이 달라 결과가 다를 수 있다는 내용도 포함한다. AI 생성물에 대한 검색 정책은 [서치어드바이저의 웹 콘텐츠 스팸사례](https://searchadvisor.naver.com/guide/content-abusing?ref=zerodraftlab.com)에서 확인할 수 있다. 네이버는 검색 결과를 점유하려고 유사한 템플릿의 문장 일부만 바꿔 무의미하게 대량 발행하는 경우를 저품질 콘텐츠 대량 생성으로 설명한다. AI나 자동화 프로그램이 사용될 수 있지만, 특정 기술의 활용 여부만으로 판단하지 않는다고 명시한다. **공개된 것은 평가 요소다.** C-Rank·D.I.A. 도움말은 평가 대상을 설명한다. 특정 키워드 반복 횟수, 리뷰 수, 체류시간을 넣으면 상위에 오른다는 보장값은 이 자료들에 제시돼 있지 않다. 같은 문서는 키워드 반복·남용, 숨겨진 텍스트, 기계적인 복제·변형, 조작된 방문·추천, 백링크와 만료 도메인 악용 등을 스팸 유형으로 다룬다. 스팸으로 탐지된 사이트와 문서는 검색 제외나 순위 하락 등의 불이익을 받을 수 있다. 이 정책이 직접 설명하는 판단 대상은 콘텐츠와 행위다. AI 도구 사용 자체를 일괄적인 검색 제외 사유로 규정한 문구는 해당 설명에 없다. 검색 반영에는 시간과 수집 범위도 관여한다. [블로그의 검색 미노출 도움말](https://help.naver.com/service/5593/bookmark/9564?lang=ko&ref=zerodraftlab.com)은 등록·수정한 글이 바로 반영되지 않는다며 24시간 경과 여부를 확인하도록 안내한다. 제목이나 본문 문장 등 여러 검색어로 확인할 것을 권하며, 특정 게시물의 노출을 예측하거나 보장할 수 없다고 명시한다. ## 06 · 검색 미노출을 확인할 때 구분해야 할 단계 웹사이트에는 수집과 색인 단계가 있다. [서치어드바이저](https://searchadvisor.naver.com/?ref=zerodraftlab.com)는 검색로봇이 사이트를 방문해 웹문서를 자동 수집한다고 설명하고 수집·색인 현황을 제공한다. 사이트에서 수집을 막는 설정이 있는지와, 수집된 문서가 어떤 검색어에 노출되는지는 서로 다른 확인 항목이다. [공식 품질 가이드](https://searchadvisor.naver.com/doc/wmt%5Fguide%5Fps%5Fquality.pdf?ref=zerodraftlab.com)에는 Yeti 접근 허용, robots.txt, 검색 노출을 차단하는 noindex 메타태그가 안내돼 있다. 클립은 장소·쇼핑 등의 정보 태그를 통해 노출 지면을 연결한다. [공식 프로필 안내](https://mkt.naver.com/clip-profile?ref=zerodraftlab.com)는 태그를 추가한 클립이 네이버 앱 홈피드·검색·플레이스·지도·스토어 등에 노출될 수 있다고 설명한다. [분석 도움말](https://help.naver.com/service/30048/contents/24476?lang=ko&osType=COMMONOS&ref=zerodraftlab.com)은 노출수, 클릭수, 유입처별 조회 비율을 각각 제공한다고 안내한다. 전체 조회수와 검색을 통해 발생한 조회는 집계 범위가 다르다. 공식 공지에는 알고리즘 변경 외의 일시적 검색 영향도 나타난다. [9월 2일 카페서비스 점검 안내](https://help.naver.com/notice/noticeView.help?lang=ko¬iceNo=33828&serviceNo=5622&ref=zerodraftlab.com)는 점검 전후 검색 미노출, 통계 조회, 조회수 미반영에 영향이 있을 수 있다고 밝혔다. 이는 해당 점검에 관한 안내이며, 모든 미노출의 원인을 설명하는 자료는 아니다. 공개 지표의 범위도 정해져 있다. [서치어드바이저의 노출·클릭 보고서 안내](https://searchadvisor.naver.com/guide/report-expose-ctr?ref=zerodraftlab.com)는 웹 검색과 연관된 영역을 대상으로 하며 블로그 검색과 검색광고 등의 지표를 포함하지 않는다고 설명한다. 따라서 이 보고서의 수치만으로 블로그, 플레이스, 광고를 합친 네이버 전체 유입을 확인할 수는 없다. ## 공식 자료로 확인할 수 있는 범위 2026년 9월 7일 기준, 쇼핑의 위치·개수 변경은 적용 영역과 확대 예정일이 공지돼 있다. AI 브리핑 광고에는 대상 상품과 예산·타겟팅·업종 제한이 명시돼 있고, 플레이스에는 정보 표시와 리뷰 제재 조건이 공개돼 있다. 블로그의 공개 도움말은 출처 신뢰도와 문서 품질을 설명한다. 이 자료들에는 모든 영역에 공통으로 적용되는 키워드 반복 횟수, 리뷰 수, 체류시간의 상위노출 보장값이 제시돼 있지 않다. 자료 기준일: 2026년 9월 7일, 한국시간. 본문은 링크한 네이버 공식 자료의 설명과 적용 범위에 한정한다. 성과 개선율·개별 업체 순위·실제 광고 집행 결과는 독립 검증하지 않았으며 이 글의 근거로 사용하지 않았다. 원문을 확인하지 못한 FAQ 구조화 데이터 종료의 세부 일정, 저장리스트·크리에이터 채널 검색의 세부 노출 조건은 분석에서 제외했다. ### AGI가 구간이라면, 도착했다는 말의 기준은 무엇일까 URL: https://zerodraftlab.com/agi-arrival-as-interval/ Last updated: 2026-09-05T17:56:54.000Z Move78은 AGI에 도달하는 때를 하나의 시점보다 “구간”으로 보는 글을 올렸다. 이어 지금을 그 구간 안으로 판단하고, 사람들이 이를 인정할 계기가 남았다는 의견을 덧붙였다. 짧은 게시물 안에는 서로 다른 두 가지 주장이 들어 있다. > [X 원문 보기](https://x.com/move78th/status/2096138611238572470?ref=zerodraftlab.com) ## 먼저 도착의 모양을 바꾼다 첫 번째 주장은 AGI의 도착을 어떻게 상상할지에 관한 것이다. 얇은 결승선이라면 선을 넘기 전과 후를 나눌 수 있다. 구간이라는 비유를 쓰면 그 경계에 폭이 생긴다. 같은 변화를 보면서도 누군가는 도착했다고 말하고, 다른 사람은 아직이라고 말할 여지가 생긴다. 게시물에 인용된 김단테의 글 일부에도 폭이 있는 결승선의 비유가 나온다. 다만 여기서 확인한 것은 Move78 원문과 그 안에 표시된 인용 부분이다. 인용이 이어지는 영상 전체와 최초 발화자의 맥락까지 확인한 것은 아니므로, 이 글은 특정 연구자의 공식 선언으로 옮겨 적지 않는다. 구간이라는 표현은 경계가 명확하지 않을 수 있다는 생각을 전달한다. 그 자체로 AGI를 판정할 시험이나 점수를 제공하지는 않는다. 비유가 직관적으로 와닿는 것과 판정 기준이 갖춰지는 것은 각각 살펴야 할 문제다. ## 그다음 현재의 위치를 주장한다 두 번째 주장은 지금이 이미 그 구간 안이라는 판단이다. Move78은 여기에 사람들이 인정하게 될 사건을 연결한다. 기술의 변화와 그 변화를 사회가 받아들이는 때를 나눠 보는 관점이다. 첫 번째 주장에 동의한다고 두 번째 주장까지 자동으로 증명되지는 않는다. 도착이 점진적일 수 있다고 생각하면서도, 현재 어느 위치에 있는지는 판단을 보류할 수 있다. 반대로 특정 능력이 충분해졌다고 느끼면서도 다른 사람이 그 평가에 동의하지 않을 수 있다. 원문에는 현재 위치를 검증할 측정 결과나 공통 판정 기준이 제시되어 있지 않다. 따라서 “이미 구간에 들어왔다”는 문장은 작성자의 판단으로 읽어야 한다. 이 구분을 빼면 관점을 소개하는 글이 확인된 기술 현황을 전달하는 글처럼 바뀐다. ## 이 비유에서 가져갈 질문 ZDL이 주목하는 것은 도착 여부를 놓고 대화할 때 서로 무엇을 기준으로 삼는지 드러내는 일이다. 누군가는 한 과제를 푸는 능력을 떠올릴 수 있고, 다른 사람은 여러 일을 안정적으로 맡기는 상태를 떠올릴 수 있다. 이는 원문이 제공한 측정 결과가 아니라, 비유를 읽으며 덧붙이는 해석이다. 같은 단어를 써도 기대하는 상태가 다르면 대화가 평행선을 달린다. “도착했다”는 판단을 이해하려면 어떤 일을 어느 정도까지 할 수 있을 때 그 말을 쓰는지 알아야 한다. 구간이라는 비유를 받아들일수록 현재 위치를 설명하는 기준이 더 필요해진다. Move78의 글은 그 기준을 완성하기보다 질문을 연다. AGI가 어느 날의 발표와 함께 확정되는 모습을 기대했다면, 점진적인 변화와 뒤늦은 인정을 따로 생각하게 한다. 이제 남는 것은 그 폭 안에서 무엇을 관찰했을 때 판단을 바꿀지다. ### ImgCompress의 로컬 처리는 어느 컴퓨터에서 일어날까 URL: https://zerodraftlab.com/imgcompress-local-image-processing/ Last updated: 2026-09-05T17:56:51.000Z 이미지 압축, 형식 변환, 배경 제거를 할 때마다 다른 사이트를 여는 사람에게 ImgCompress는 간단한 제안을 한다. 이 작업을 자기 서버의 한 화면에서 처리하자는 것이다. Snow Brave의 X 게시물과 [공식 저장소](https://github.com/karimz1/imgcompress?ref=zerodraftlab.com)를 함께 읽었다. > [X 원문 보기](https://x.com/Sn0wbrave/status/2095929474898337873?ref=zerodraftlab.com) ## 원문은 형식과 작업을 한데 묶는다 Snow Brave는 70개 이상의 이미지 형식, 압축과 변환, AI 배경 제거를 소개한다. 이어 Docker 실행과 일괄 처리, PDF 지원을 덧붙인다. 짧은 글이지만 사용 장면은 선명하다. 파일 종류가 바뀔 때마다 변환 도구를 다시 찾는 수고를 줄이려는 제품이다. 공식 README 역시 70개 이상의 입력 형식을 안내한다. HEIC와 PSD 같은 파일을 받아 다른 형식으로 바꾸고, 여러 이미지를 PDF로 묶을 수 있다. 배경 제거 모델은 CPU에서 실행하며, 기능을 쓰기 위한 외부 API 키가 필요하지 않다고 설명한다. 이는 프로젝트가 안내하는 기능이며, 이번에 모든 형식을 직접 변환해 본 것은 아니다. ## 브라우저는 조작 화면이고, 처리는 서버가 맡는다 원문의 “로컬”을 읽을 때 구분할 부분이 있다. ImgCompress는 Docker 컨테이너로 실행하는 이미지 처리 서버다. 공식 설명의 기준점은 그 컨테이너를 띄운 컴퓨터다. 웹 화면을 쓴다는 사실만으로 모든 처리가 사용자의 브라우저 안에서 끝난다는 뜻은 아니다. 예를 들어 개인 컴퓨터에 설치해 그 컴퓨터에서 접속하는 경우를 생각해보자. 반대로 별도 서버에 설치하고 노트북에서 접속할 수도 있다. 후자의 “자기 서버에서 처리”는 “노트북 밖으로 파일이 나가지 않음”과 의미가 다르다. 이 구분은 제품을 깎아내리는 조건이 아니라, 로컬이라는 말을 실제 설치 위치에 맞춰 읽는 방법이다. ## 도구를 합치면 무엇을 덜 결정하게 될까 ZDL의 해석은 기능의 개수보다 작업 흐름에 있다. 이미지 한 묶음의 형식과 용량을 정리하려는데 변환 사이트를 먼저 고르고, 다시 압축 서비스를 찾는다면 파일 처리 전에도 선택이 생긴다. 하나의 작업 화면은 이런 선택을 줄일 후보가 된다. 물론 기능 목록만으로 내 작업에 더 빠르다고 결론 낼 수는 없다. 작은 이미지 몇 장을 가끔 바꾸는 사람과 반복해서 묶음 파일을 처리하는 사람은 설치를 감수할 이유가 다르다. 배경 제거 결과가 마음에 드는지, 변환된 이미지가 필요한 품질을 유지하는지도 기능의 존재와 별개의 판단이다. 이번 글은 설치 후기나 성능 비교가 아니다. 공식 자료가 설명하는 처리 구조까지 확인했다. ImgCompress의 로컬 처리를 자기 작업에 대입하려면 먼저 컨테이너를 어디에 둘 것인지 정해야 한다. 그 위치를 알아야 원본 파일이 어디까지 이동하는지도 설명할 수 있다. ### OpenMAIC는 슬라이드 다음에 풀 문제까지 만든다 URL: https://zerodraftlab.com/openmaic-interactive-lesson-generation/ Last updated: 2026-09-05T17:56:48.000Z OpenMAIC는 주제나 자료를 받아 수업 개요를 짜고, 슬라이드와 퀴즈, 상호작용 활동으로 이어주는 오픈소스 도구다. X에서 Ren이 소개한 글을 출발점으로 [공식 저장소](https://github.com/THU-MAIC/OpenMAIC?ref=zerodraftlab.com)를 확인했다. 관심이 가는 대목은 강의 화면을 만든 뒤 학습자가 할 일까지 함께 구성한다는 점이다. > [X 원문 보기](https://x.com/Ryrenz/status/2095929892047057221?ref=zerodraftlab.com) ## 원문이 제안한 것은 강의 준비의 묶음 처리다 Ren은 자료를 모으고, 발표자료를 만들고, 문제를 출제하고, 배포물을 준비하는 과정을 나열한다. OpenMAIC는 이 작업들을 여러 에이전트에게 맡긴다는 소개다. 원문에 나온 준비 시간과 별 개수는 사용자가 전한 수치다. 이 글에서는 절약 시간이나 교육 효과의 근거로 사용하지 않는다. 공식 README의 생성 흐름은 개요부터 시작한다. 주제 설명이나 자료를 입력하면 수업 구조를 만들고, 그 구조를 슬라이드·퀴즈·인터랙티브 HTML·프로젝트 학습 활동으로 구체화한다. 설명할 내용과 그 내용을 다뤄볼 활동을 하나의 수업 안에 배치하는 방식이다. 가령 개념 설명을 읽는 데서 끝나는 수업과, 설명 뒤에 질문에 답하고 화면을 조작하는 수업은 학습자에게 요구하는 행동이 다르다. ZDL이 이 도구에서 보는 가능성은 이런 활동의 초안을 함께 확보하는 데 있다. 생성된 활동이 학습 목표와 맞는지는 별도로 살펴야 한다. ## 대화하는 교실과 가져갈 수 있는 결과물 공식 자료는 AI 교사와 동료가 참여하는 대화, 화이트보드, 음성 기능을 설명한다. 퀴즈에는 AI 채점과 피드백도 붙는다. 따라서 결과물은 일방향 발표자료에만 머물지 않는다. 학습자가 질문하고 답을 받는 교실 경험도 제품의 범위에 들어간다. 편집 가능한 PowerPoint와 인터랙티브 HTML 내보내기도 지원한다. 발표자료를 받아 사람이 수정할지, 상호작용이 있는 화면을 쓸지 선택할 수 있다. 다만 파일을 내보낼 수 있다는 사실만으로 수업의 모든 기능이 다른 환경에서도 그대로 작동한다고 볼 수는 없다. ## 로컬 실행과 로컬 모델은 따로 고른다 Ren은 다양한 모델 연결과 브라우저 저장 방식을 함께 소개했다. 공식 README에도 외부 LLM 제공자와 Ollama·Lemonade 같은 로컬 제공자가 나와 있다. 앱을 내 컴퓨터에서 실행하면서 외부 모델 API를 연결할 수도 있고, 로컬 모델을 선택할 수도 있다는 뜻이다. 외부 API가 모든 구성의 필수 조건은 아니다. Pro 워크벤치에는 별도 설정이 필요하다. 공식 안내상 기본 비활성이며, 서버 런타임과 PostgreSQL을 구성해야 한다. 기본 수업 생성과 확장된 작업 환경을 같은 설치 단계로 생각하면 실제 준비 범위를 잘못 잡기 쉽다. 세부 조건은 [공식 Pro 설정 안내](https://github.com/THU-MAIC/OpenMAIC?ref=zerodraftlab.com#optional-agent-workbench-and-runtime)에서 확인할 수 있다. 이번 확인은 원문과 공식 문서를 대조한 범위다. 직접 수업을 생성하거나 학습 효과를 측정하지 않았다. OpenMAIC를 판단할 때 남는 질문은 분명하다. 생성된 슬라이드 다음에 놓인 문제가, 앞에서 설명한 내용을 실제로 이해했는지 드러내는가. ### 바이브 코딩 수익화 영상은 왜 시장부터 보라고 했나 URL: https://zerodraftlab.com/vibe-coding-market-first/ Last updated: 2026-08-29T06:37:14.000Z 2026년 4월 14일 애드버코더 채널에 올라온 [「바이브코딩으로 사이트 2개를 만들어 수익화에 성공했습니다」](https://www.youtube.com/watch?v=kyAzktHs33o&ref=zerodraftlab.com)는 도구 사용법보다 수익화 순서를 다룬 9분짜리 영상이다. 제작자는 애드버코더AI와 채널파인더를 사례로 들며 제품을 만들기 전에 돈을 낼 수요부터 찾았다고 말한다. 제목에는 매출 성과가 앞에 나오지만 영상의 중심은 다른 곳에 있다. 무엇을 만들지 정하지 않은 채 새 AI 도구와 강의만 따라다니면 결과물이 남지 않는다는 진단, 아이디어가 없다면 블로그 자동화 시스템을 만들며 코딩과 수익화를 함께 익히라는 제안이다. ## 영상은 ‘수단 중독’부터 지적한다 영상은 바이브 코딩을 배우려다 멈추는 과정을 강의 결제, 새 도구 설치, 며칠간의 실습, 흥미 저하, 다음 강의 결제로 묘사한다. 제작자는 이 반복을 ‘수단 중독’이라고 부른다. 도구를 배우는 일 자체가 목적이 되면 무엇을 팔지, 누가 살지, 만든 다음 어디에서 고객을 만날지가 비어 있다는 설명이다. 이 대목은 제작자의 관찰이지 조사 결과는 아니다. 실제로 돈을 버는 사람이 극소수라는 말도 영상 안에서 통계로 뒷받침되지는 않는다. 다만 튜토리얼은 제작까지 보여주고 유통·판매·재구매는 생략하기 쉽다는 문제 제기는 선명하다. 바이브 코딩이 일시적인 유행만은 아니라는 근거도 나온다. [Collins Dictionary는 ‘vibe coding’을 2025년 올해의 단어로 선정했다](https://www.collinsdictionary.com/us/woty?ref=zerodraftlab.com). 영상은 이 관심이 개발자 밖으로 넓어졌다고 본다. 그러나 검색량 증가와 사업 성과는 다른 지표다. 사람들이 도구를 많이 찾는다는 사실만으로 그 도구로 만든 제품의 수요가 생기지는 않는다. ## 두 서비스가 증명하는 것과 아직 증명하지 못한 것 첫 사례는 AI로 블로그 글을 만들고 발행하는 애드버코더AI다. 제작자는 마케터로 일하며 확인한 수요를 바탕으로 약 3년 전에 서비스를 만들었고, 회원이 3,000명을 넘었다고 말한다. [애드버코더AI의 현재 공식 페이지](https://advercoder.com/?ref=zerodraftlab.com)에서도 키워드 수집, 초안 작성, 교정, 발행을 잇는 자동화 기능과 블로그·카페 마케팅 교육을 확인할 수 있다. 두 번째 사례는 떠오르는 유튜브 채널을 찾는 채널파인더다. 제작자는 Claude Code로 이 서비스를 만들었고, 출시 약 4개월 뒤 월 매출 690만 원과 누적 매출 약 2,200만 원을 기록했다고 밝힌다. [채널파인더 공식 페이지](https://channelfinder.kr/?ref=zerodraftlab.com)에는 일일 조회수 순위, 해외 성공 채널, 실시간 인기 영상 같은 기능이 실제로 운영되고 있다. 여기까지 확인되는 것은 두 서비스의 존재와 기능이다. 회원 수와 매출은 영상 제작자가 공개한 숫자이며 결제 내역이나 회계 자료로 독립 검증되지는 않았다. 비용과 환불, 고객 획득 경로, 재구매율도 나오지 않는다. 현재 두 공식 페이지에 표시된 운영 법인도 서로 다르지만 영상은 두 회사와 서비스의 관계를 설명하지 않는다. 따라서 이 숫자는 제작자의 운영 사례로 읽을 수는 있어도, 같은 도구를 쓰면 누구나 비슷한 매출을 얻는다는 증거는 아니다. ## 아이디어가 없다면 블로그 시스템부터 만들라는 제안 영상은 만들 제품이 뚜렷한 사람에게 수요를 먼저 확인한 뒤 서비스를 만들라고 권한다. 목표가 없는 사람에게는 블로그 마케팅 시스템을 첫 프로젝트로 제안한다. 글 한 편이 검색 유입을 오래 가져올 수 있고, 광고·제휴·CPA처럼 한 트래픽에 여러 수익 모델을 붙일 수 있다는 이유다. 블로그를 운영하며 키워드 분석, 크롤링, API 연결, 자동 발행을 구현하면 코딩 연습과 실제 운영을 한 흐름에 넣을 수 있다는 설명은 이 영상에서 가장 구체적이다. 제작자는 애드버코더AI도 자신의 블로그 운영을 자동화하다 나온 제품이라고 말한다. 작은 내부 도구가 반복되는 문제를 해결하고, 그 문제가 다른 사람에게도 있다면 제품 후보가 된다는 경로다. 다만 영상이 제시한 수익 수치는 그대로 일반화하기 어렵다. 영상은 2026년 AdSense RPM이 12% 올랐다고 말하지만 근거 자료를 제시하지 않는다. [Google의 공식 설명](https://support.google.com/adsense/answer/190515?ref=zerodraftlab.com)에서 RPM은 예상 수익을 페이지뷰나 노출 수로 나눈 뒤 1,000을 곱한 계정별 지표다. 모든 블로그에 적용되는 고정 수익률이 아니다. 네이버 쇼핑 커넥트의 수익 배분율도 상품마다 다르다. 영상은 최대 33%라고 소개한다. [네이버의 공식 출시 자료](https://www.navercorp.com/media/pressReleasesDetail?seq=33116&ref=zerodraftlab.com)는 판매자가 상품과 수익 공유 비율을 직접 정하고 크리에이터가 상품별 비율을 확인한다고 설명한다. 확인한 공식 자료에는 33%가 공통 상한이라는 내용이 없다. 특정 시점의 특정 상품에서 가능한 비율과 누구에게나 적용되는 수익률을 구분해야 한다. ## 이 영상은 강의 판매 퍼널이기도 하다 영상은 블로그 시스템을 바이브 코딩 입문 경로로 설명한 뒤 애드버코더의 유료 강의와 무료 라이브 방송을 소개하며 끝난다. 정보와 판매가 한 영상에 함께 들어 있다. 블로그 자동화가 가장 현실적인 입문법이라는 결론에는 제작자가 판매하는 서비스와 교육 과정의 이해관계가 겹친다. ## Zero Draft Lab의 해석 이 영상에서 가져갈 만한 판단은 바이브 코딩의 성능보다 작업 순서다. 제품을 먼저 만든 뒤 고객을 찾는 대신, 이미 반복되는 문제와 돈이 흐르는 시장을 찾고 필요한 도구를 만드는 순서다. 애드버코더AI와 채널파인더는 제작자가 이 순서를 적용했다고 밝힌 사례다. 월 매출 690만 원이라는 숫자는 관심을 끌지만 사업의 재현성을 보여주지는 않는다. 매출이 얼마나 남았는지, 고객이 왜 결제했고 얼마나 오래 남는지, 유입에 얼마를 썼는지가 빠져 있기 때문이다. 영상이 설득력 있게 설명한 것은 바이브 코딩으로 돈을 버는 공식이 아니라, **시장과 수익 경로를 정하지 않은 코딩은 더 빨리 완성된 미판매 제품을 만들 수 있다는 점**이다. --- 주요 출처: 애드버코더 YouTube 영상 [「바이브코딩으로 사이트 2개를 만들어 수익화에 성공했습니다」](https://www.youtube.com/watch?v=kyAzktHs33o&ref=zerodraftlab.com), [애드버코더AI 공식 페이지](https://advercoder.com/?ref=zerodraftlab.com), [채널파인더 공식 페이지](https://channelfinder.kr/?ref=zerodraftlab.com), [Collins Dictionary 2025 올해의 단어](https://www.collinsdictionary.com/us/woty?ref=zerodraftlab.com), [Google AdSense RPM 설명](https://support.google.com/adsense/answer/190515?ref=zerodraftlab.com), [네이버 쇼핑 커넥트 출시 자료](https://www.navercorp.com/media/pressReleasesDetail?seq=33116&ref=zerodraftlab.com). 회원 수와 매출은 영상 제작자의 자기 보고이며 독립 검증 자료가 공개되지 않았습니다. ### 턱 골절로 쉬던 기계공이 만든 NVSTly는 디스코드 봇으로 5자리 MRR에 갔다 URL: https://zerodraftlab.com/discord-bot-as-distribution/ Last updated: 2026-08-29T06:37:28.000Z 인디해커스가 2025년 10월 30일에 올린 [**How a sucker punch and a broken jaw led to a 5-figure MRR business**](https://www.indiehackers.com/post/tech/how-a-sucker-punch-and-a-broken-jaw-led-to-a-5-figure-mrr-business-yQBoOGEKkI6dlsczcCtf?ref=zerodraftlab.com)는 소셜 트레이딩 플랫폼 [NVSTly](https://nvstly.com/?ref=zerodraftlab.com)를 만든 Rich Watson의 창업기다. 글쓴이는 James Fleischmann이고, 본문은 창업자가 1인칭으로 직접 쓴 형식이다. 이 글은 그 원문이 공개하는 내용을 순서대로 풀고, 원문이 계정 벽에서 끊기는 지점을 밝힌 뒤, 같은 페이지의 공개 댓글에서 창업자가 직접 답한 내용을 덧붙인다. 먼저 경계를 적는다. 원문은 첫 절만 로그인 없이 읽히고, 나머지는 인디해커스 무료 계정 가입 벽 뒤에 있다. 아래에서 "원문이 밝힌다"고 쓴 부분은 계정 없이 확인한 첫 절과 페이지 상단 정보 블록, 그리고 공개 댓글에 한정한다. ## 페이지 상단이 밝히는 숫자 기사 상단 정보 블록에 세 값이 있다. 회사는 NVSTly, 창업자는 Rich Watson, 매출은 `>$10K a month`다. 월 1만 달러가 넘는다는 뜻이고, 정확한 액수는 공개하지 않았다. ## 기계공이 턱이 부러진 채로 본 것 원문의 첫 절 제목은 "From machinist to founder"다. Watson은 NVSTly를 만들기 전 기계공이었다고 적는다. 급여와 복지와 고용 안정이 다 괜찮은 자리였다고 스스로 밝힌다. 2020년에 그는 도로 위 시비에 휘말려 턱이 부러졌고, 회복하느라 일을 쉬었다. 같은 시기에 팬데믹이 닥쳐 캘리포니아가 봉쇄에 들어갔고 많은 사람이 일자리를 잃었다. 그리고 레딧 /r/wallstreetbets가 게임스탑(`$GME`)을 중심으로 폭발하면서 개인 투자 붐이 일었다. Watson은 이 조합을 "완벽한 폭풍"이라고 부른다. 모두가 집에 갇혀 있었고, 소셜 미디어 사용량이 치솟았고, Webull·Robinhood·thinkorswim 같은 무수수료 증권사가 거래 문턱을 그 어느 때보다 낮췄다. 이 흐름이 수백만 명의 신규 개인 투자자를 시장으로 밀어 넣었다고 그는 적는다. ## 그가 지목한 구멍은 정보가 아니라 검증이었다 회복하는 동안 그가 본 공백은 이것이다. 트레이더와 인플루언서가 소셜 미디어와 디스코드에서 매매 신호와 분석을 뿌리고 있는데, **성과를 검증하거나 결과를 투명하게 추적할 방법이 없었다**는 것이다. 특히 디스코드는 트레이딩 커뮤니티로 가득했고, 신호를 손으로 올리기만 할 뿐 정확도를 집계하거나 누가 제일 잘하는지 가려낼 장치가 없었다. 그래서 만든 것이 NVSTly다. 원문은 이를 "트레이더가 매매를 추적하고 공유하고 따라 할 수 있으며 상세한 인사이트와 성과 분석을 제공하는 인터랙티브 소셜 트레이딩 플랫폼"이라고 설명한다. 숫자는 한 문장으로 나온다. 지난 1년 반 동안 5자리 MRR을 거의 50% 늘렸고 월 단위 성장이 이어지고 있다는 것이다. 기사 게재일이 2025년 10월 30일이므로 이 "1년 반"은 그 시점 기준이다. ## 원문이 끊기는 지점 여기서 무료 열람이 끝난다. 페이지는 "나머지를 읽으려면 구독하라, 가입은 무료다"라는 안내로 넘어간다. 목차만 공개되어 있어서 남은 절의 제목은 확인된다. 순서대로 "Building the MVP", "Viral loops", "An evolving business model", "Starting with the wrong model", "Parting advice", "What's next?"다. 즉 원문에는 MVP를 어떻게 만들었는지, 바이럴 루프가 무엇이었는지, 사업 모델이 어떻게 바뀌었는지, 처음에 어떤 모델이 틀렸는지가 더 들어 있다. 이 글은 그 내용을 읽지 않았으므로 추측해서 채우지 않는다. ## 창업자가 댓글에서 직접 답한 디스코드 이야기 같은 페이지의 댓글은 로그인 없이 읽힌다. 한 독자가 디스코드 커뮤니티에서 5자리 MRR까지 키우는 과정에 어떤 큰 장애물이 있었는지 물었고, Watson이 직접 답했다. 아래는 그 답의 내용이다. 첫째, 초기에 디스코드 커뮤니티를 키우는 데 **보수 없는 시간을 셀 수 없이 썼다**고 말한다. 당시에는 경쟁이 극심했고, 여러 커뮤니티가 이른바 '셀프봇'으로 남의 커뮤니티를 습격해 DM으로 회원을 빼내고 있었다. 지금은 디스코드가 셀프봇과 대량 DM과 스팸을 막는 기능을 여러 해에 걸쳐 붙여서 그런 짓이 훨씬 어려워졌다고 덧붙인다. 둘째, 그는 이 여정에서 **수백 명의 커뮤니티 소유자·관리자·매니저와 대화했다**고 밝힌다. 그리고 그중 상당수가 자기 봇을 반기지 않았다고 적는다. 이유는 두 가지였다. 자존심 때문이거나, 자기 커뮤니티 회원이 NVSTly 쪽으로 빠져나갈까 진심으로 두려워했기 때문이다. 봇이 제공하는 기능으로 자기 커뮤니티가 더 강해진다는 쪽으로는 보지 않았다는 것이다. 셋째, 그 뒤 몇 해가 지난 지금도 **모바일 앱보다 디스코드에서 더 많은 성장이 나온다**고 말한다. 원문 표현은 이렇다. "we still see most of our growth on Discord than we do with our mobile apps." 다만 그는 이것을 자랑이 아니라 자연스러운 결과로 설명한다. 자사 금융 봇이 지금 디스코드에서 워낙 널리 쓰이기 때문이라는 것이다. ## 확인되지 않은 것 수치는 모두 창업자가 스스로 밝힌 값이고 외부 감사가 없다. "5자리 MRR"은 월 1만 달러에서 9만 9천 달러 사이 어디든 될 수 있으며 원문은 좁히지 않는다. "거의 50% 증가"의 기준 시점도 원문이 명시하지 않는다. 가격표와 요금제는 무료 구간에 나오지 않으므로 이 글은 다루지 않는다. 댓글에 "verified trader monetization"이라는 표현이 나오지만 그것은 독자의 요약이지 창업자의 서술이 아니다. 기사 자체가 2025년 10월 자료라는 점도 그대로 둔다. 그 뒤 NVSTly의 상태가 어떻게 바뀌었는지는 이 원문으로 알 수 없다. ## Zero Draft Lab의 해석 아래는 원문의 서술이 아니라 Zero Draft Lab이 덧붙이는 판단이다. 이 사례에서 재사용할 수 있는 부분은 창업 계기가 아니라 유통 경로다. Watson은 자기 앱으로 사람을 끌어오는 대신, 사람이 이미 모여 있는 남의 방 안에 봇을 넣었다. 봇은 마케팅 채널이 아니라 제품의 배포 형태 자체였다. 그래서 몇 년이 지나 자체 모바일 앱이 생긴 뒤에도 성장의 무게중심이 그대로 디스코드에 남았다. 여기에 붙은 비용도 같이 봐야 한다. 이 경로의 관문은 사용자가 아니라 커뮤니티 운영자다. 그는 수백 명을 설득해야 했고, 상당수는 회원을 빼앗길까 봐 거절했다. 봇을 심는 유통은 광고비가 아니라 **한 명씩 설득하는 시간**으로 값을 치른다. 이 비용을 빼고 "디스코드 봇으로 성장했다"만 옮기면 실제와 다른 그림이 된다. 그리고 이 경로가 통한 이유는 봇이 운영자에게도 이득이었기 때문이다. 성과 추적이라는 기능은 커뮤니티 밖으로 회원을 빼내는 장치가 아니라, 그 커뮤니티 안에서 누가 맞혔는지를 보여 주는 장치다. 남의 마당에 무언가를 놓으려면 그 마당 주인이 먼저 이득을 봐야 한다는 조건은 트레이딩 밖에서도 그대로 남는다. ### 바쁨은 줄일 대상이 아니라 셀 대상이다 URL: https://zerodraftlab.com/activity-is-not-progress/ Last updated: 2026-09-15T08:34:39.000Z 바쁨은 세기 쉽다. 회의 몇 건, 메일 몇 통, 처리한 요청 몇 개인지 달력과 받은편지함이 알아서 기록해 준다. 반면 진전은 세기 어렵다. 오늘 한 일 중 무엇이 다음 매출을 만들었는지는 몇 주 뒤에야, 그것도 흐릿하게 드러난다. 그래서 사람은 세기 쉬운 것을 세기 어려운 것의 대역으로 쓴다. 하루가 꽉 찼으면 잘 굴러갔다고 느끼고, 한가했으면 뒤처졌다고 느낀다. 하지만 **바쁨은 진전의 증거가 아니라 진전을 못 보게 가리는 화면**이다. 둘은 함께 움직일 때도 있지만 같은 것이 아니다. ## 우리는 자기 노동시간부터 정직하게 세지 못한다 이 착각은 의지의 문제가 아니라 측정의 문제다. 존 로빈슨과 앤 보스트롬은 1994년 *Monthly Labor Review*에 사람들의 응답 시간과 시간일지 기록을 맞대어 본 결과를 실었다. 주 40\~44시간 일한다고 답한 사람들은 실제 기록보다 약 2시간을 부풀렸다. 주 55\~59시간이라고 답한 사람들은 약 10시간을 부풀렸다. 여기서 중요한 건 오차의 크기가 아니라 방향이다. **많이 일한다고 답할수록 오차가 커졌다.** 바쁘다고 느끼는 사람일수록 자기 시간을 더 크게 잘못 센다는 뜻이다. 기억은 밀도 높았던 순간을 늘려서 저장하고 비어 있던 구간을 지운다. 그래서 "요즘 정신없다"는 자기 진단은 시간 배분의 근거로 쓸 수 없다. ## 활동의 덫에는 50년 된 이름이 있다 조직 차원에서 같은 현상을 먼저 이름 붙인 사람은 조지 오디오니다. 그는 1974년 책 *Management and the Activity Trap*에서 사람들이 결과가 아니라 처리한 항목 수에 매달리게 되는 상태를 활동의 덫이라고 불렀다. 심해지면 조직 전체가 움직임을 추진력으로 착각한다. 덫이라는 비유가 정확한 이유가 있다. 활동은 즉시 보상을 준다. 메일에 답하면 받은편지함이 줄고, 회의를 마치면 일정에 줄이 그어진다. 반면 자격을 갖춘 상담 하나를 잡는 일은 거절당할 수 있고 결과도 늦게 온다. 사람은 확실한 작은 보상을 불확실한 큰 보상보다 먼저 집는다. 그래서 하루는 자연히 잡무 쪽으로 기운다. ## 세는 방법을 바꾸면 숫자가 드러난다 영업 교육자 윌 배런은 12년간 천 명이 넘는 사업주와 일했다고 밝히며 한 가지 연습을 시킨다. 한 주 동안 한 일을 1시간 단위로 빠짐없이 적는다. 회의, 반복되는 메일 스레드, 행정 처리까지 전부 적는다. 그리고 주말에 각 항목에 이렇게 묻는다. 이 일이 자격을 갖춘 잠재고객과의 대화를 만들었는가. 진행 중인 거래를 한 칸이라도 앞으로 옮겼는가. 아니면 새 잡무만 만들었는가. 그가 말하는 결과는 일관된다. 대부분의 사업주에게 매출을 실제로 움직인 시간은 **주 1\~2시간**에 그친다. 나머지는 생산적으로 느껴지지만 돈을 만들지 않는 일이다. 이건 통제된 연구가 아니라 한 실무자의 관찰이지만, 앞의 시간일지 연구와 방향이 같다. 기억으로 물으면 부풀고, 기록으로 물으면 줄어든다. 그래서 첫 번째 처방은 더 열심히 하라는 말이 아니다. **기억 대신 기록으로 세라는 것**이다. 그리고 바쁨을 줄이려 하기 전에, 매출을 움직인 시간의 절대량이 몇 시간인지부터 숫자로 확인하라는 것이다. 그 숫자를 모르는 상태에서는 무엇을 덜어낼지도 정할 수 없다. 그런데 여기서 정직한 반문이 나온다. 잡무 대부분이 실제로 누군가는 해야 하는 일이라면, 그 시간을 어디서 떼어낼 수 있나? 이 반문은 옳다. 그리고 답은 잡무를 없애는 데 있지 않다. 필요한 일과 진전시키는 일은 서로 다른 축이기 때문이다. 세금 신고는 필요하지만 어떤 거래도 앞으로 옮기지 않는다. 두 축을 하나로 합쳐 놓으면 "필요한 일이었다"는 이유로 모든 시간이 정당화된다. 갈라놓아야 선택이 생긴다. ## 잡무는 줄지 않고 팽창한다 덜어내기가 실패하는 이유도 오래전에 서술됐다. 시릴 노스코트 파킨슨은 1955년 *The Economist*에 실은 글에서 일은 그것을 처리하도록 주어진 시간을 채울 만큼 팽창한다고 썼다. 한가한 노부인이 엽서 한 장 부치는 데 하루를 다 쓰는 장면이 그 예였다. 이 관찰을 받아들이면 처방이 달라진다. 잡무를 열 시간 걷어내도 그 열 시간은 비어 있지 않는다. 남은 잡무가 부풀어 그 자리를 다시 채운다. 그래서 "효율을 높여 시간을 벌겠다"는 계획은 대개 벌어들인 시간을 다시 잡무에 반납하는 것으로 끝난다. 빈자리는 저절로 매출 활동으로 채워지지 않는다. ## 반론 — 준비와 학습은 잡무가 아니다 여기서 기준을 너무 좁게 잡으면 다른 손해가 난다. 제품을 고치는 일, 사례를 정리하는 일, 새 도구를 익히는 일은 이번 주 어떤 거래도 옮기지 않는다. 그래도 이들은 몇 달 뒤의 거래 전체의 성사율을 바꾼다. 보상이 늦게 오는 활동과 보상이 아예 없는 활동은 다르다. 둘을 가르는 질문은 하나다. **이 일이 미래의 어떤 특정한 거래를 어떤 경로로 앞당기는지 한 문장으로 댈 수 있는가.** 경로를 댈 수 있으면 지연된 진전이다. 경로가 "언젠가 도움이 될 것"으로만 설명되면 그건 잡무다. 이 기준은 완벽하지 않지만, 모든 활동을 필요라는 한 단어로 뭉뚱그리는 것보다는 훨씬 낫다. ## AI는 잡무를 더 싸게 만들고, 그래서 더 많이 만든다 이 지점에서 최근의 변수가 들어온다. 에이전트와 생성 모델은 보고서, 요약, 회의록, 정리 문서를 만드는 비용을 급격히 낮춘다. 파킨슨의 관찰을 그대로 적용하면 결과는 예측 가능하다. 단가가 떨어진 산출물은 총량이 늘어난다. 예전에는 쓸 엄두를 못 내던 문서가 이제 쉽게 만들어지고, 만들어진 문서는 누군가 읽고 검토하고 회신해야 한다. 그래서 AI 도입 뒤에 체감 바쁨이 오히려 늘어나는 일이 생긴다. 도구가 나빠서가 아니다. 절약된 시간을 무엇에 쓸지 미리 정해두지 않았기 때문이다. 자동화가 만든 여유는 기본값으로 더 많은 잡무를 흡수한다. 에이전트에게 무엇을 맡길지보다, 에이전트가 벌어준 시간을 어디로 보낼지가 더 중요한 결정이 된다. ## 시간을 늘리지 말고 순서를 뒤집는다 그러므로 실제 변경은 시간 관리 기법이 아니라 순서에 있다. 대부분은 잡무를 먼저 처리하고 남는 시간에 매출 활동을 한다. 잡무는 팽창하므로 남는 시간은 없다. 순서를 뒤집으면 이 구조가 깨진다. 주에 몇 시간을 매출 활동으로 먼저 떼어 고정하고, 나머지 시간으로 잡무를 돌린다. 잡무는 줄어든 시간에 맞춰 다시 압축된다. 팽창하는 성질은 수축에도 똑같이 작동한다. 이때 떼어내는 시간의 크기는 야심이 아니라 현재 숫자에서 출발해야 한다. 지금 주 1시간이라면 다음 목표는 8시간이 아니라 3시간이다. 기록으로 확인한 실제값에서 조금씩 올리는 방식만이 유지된다. 한 번에 크게 잡은 계획은 첫 주의 급한 요청 하나에 무너지고, 무너진 뒤에는 원래 상태로 돌아간다. 결국 이 글의 주장은 더 적게 일하라는 것도, 더 많이 일하라는 것도 아니다. 바쁨과 진전을 같은 이름으로 부르지 말라는 것이다. 바쁨은 없앨 대상이 아니라 셀 대상이고, 진전은 시간을 더 쓴다고 생기는 것이 아니라 어느 시간을 먼저 떼어놓느냐로 결정된다. **일주일이 꽉 찼는지 묻지 말고, 그 주에 거래를 앞으로 옮긴 시간이 몇 시간이었는지 물어야 한다.** --- 출발 소절: Will Barron, [12 Years of Business Advice in 26 minutes (that generated $1.4B)](https://www.youtube.com/watch?v=GQMsTUe2nNo&ref=zerodraftlab.com)의 「one-hour week」 파트. 천 명 이상의 사업주와 14억 달러 신규 매출은 화자의 자기 보고 수치입니다. 시간 과대보고 수치는 John P. Robinson · Ann Bostrom, [The overestimated workweek? What time diary measures suggest](https://www.bls.gov/opub/mlr/1994/08/art2full.pdf?ref=zerodraftlab.com), *Monthly Labor Review*, 1994년 8월. 활동의 덫은 George S. Odiorne, *Management and the Activity Trap*, Harper & Row, 1974\. 일의 팽창은 C. Northcote Parkinson, [Parkinson's Law](https://doc.cat-v.org/economics/parkinsons-law/the-economist-article.pdf?ref=zerodraftlab.com), *The Economist*, 1955년 11월 19일(보존본). 지연된 진전과 잡무를 가르는 기준, AI 도입 이후의 잡무 팽창, 순서 뒤집기는 이 글의 해석입니다. ### 속도를 위해 카오스를 감수하되, 핑계로 쓰지 마라 URL: https://zerodraftlab.com/chaos-without-excuses/ Last updated: 2026-09-15T08:34:40.000Z 일에는 생각보다 포기해도 되는 일이 많다. 모든 요청에 답하지 않아도 된다. 모든 문서를 최신으로 유지하지 않아도 된다. 임시로 만든 도구를 완성품처럼 다듬지 않아도 된다. 이미 목적을 다한 회의를 계속 열 필요도 없다. 일을 빨리 하는 것만으로는 이 차이를 만들 수 없다. **속도는 더 빨리 처리하는 능력보다, 지금 하지 않을 일을 고르는 능력에서 나온다.** 블리츠스케일링이 효율보다 속도를 우선한다는 말도 여기서 현실이 된다. 효율적인 조직은 낭비를 줄이고 같은 품질을 반복하려 한다. 빠르게 커지는 조직은 그 질서를 만들 시간까지 아껴야 한다. 그래서 중복, 임시방편, 불완전한 인수인계, 곧 버릴 작업을 감수한다. 리드 호프먼은 이를 [“카오스를 받아들이는 일”](https://www.cbsnews.com/news/blitzscaling-silicon-valley-investor-reid-hoffman-says-companies-should-embrace-chaos/?ref=zerodraftlab.com)이라고 설명했다. 회사가 너무 빨리 커지면 제품과 운영 방식, 관리 구조가 6개월에서 12개월마다 크게 바뀐다. 천천히 배우고 정돈할 때의 편안한 효율은 사라진다. ## 속도를 내려면 어떤 불은 그냥 타게 둬야 한다 호프먼이 제시한 반직관적 규칙에는 [“불을 내버려 두라”와 “버릴 일을 하라”](https://marker.medium.com/7-counterintuitive-rules-for-growing-your-business-super-fast-9dcdc2bfc649?ref=zerodraftlab.com)도 있다. 모든 문제를 해결하려 들면 가장 중요한 문제에 쓸 속도를 잃는다. 열 시간이 걸리는 정교한 해법보다 한 시간짜리 임시방편이 지금의 병목을 풀 수 있다면, 나중에 버릴 것을 알면서도 그쪽을 택한다. 여기서 카오스는 아무렇게나 일한 결과가 아니다. 중요한 한 가지에 자원을 몰았기 때문에 나머지를 의도적으로 흐트러뜨린 결과다. 미완성 문서, 수동 처리, 중복 도구, 늦은 답변은 그 자체로 전략이 아니다. 무엇을 지키려고 그것들을 포기했는지가 분명할 때만 속도의 비용이 된다. 문제는 카오스가 너무 좋은 핑계가 된다는 데 있다. 약속을 놓치면 “지금은 속도가 중요하다”고 말할 수 있다. 같은 사고가 반복되면 “과도기라서 그렇다”고 넘길 수 있다. 목표가 바뀌어도 “빠르게 적응했다”고 부를 수 있다. 정리하지 않은 일, 책임지지 않은 결정, 준비하지 않은 실패가 모두 블리츠스케일링의 비용처럼 보이기 시작한다. 그러면 속도가 만든 카오스와 무능이 만든 혼란을 어떻게 가르는가. 첫 번째 차이는 움직이지 않는 목표다. 방법과 도구, 사람의 역할은 계속 바뀔 수 있다. 그러나 지금 무엇을 가장 빨리 증명하거나 차지하려는지는 고정돼 있어야 한다. 목표까지 자주 바뀐다면 주변을 포기한 것이 아니라 중심을 잃은 것이다. ## 포기한 일에는 이유보다 경계가 필요하다 두 번째 차이는 손실의 경계다. 내가 문서화를 포기한 대가가 다음 사람의 야근으로 돌아가면 속도가 아니라 비용 이전이다. 고객의 신뢰, 직원의 급여, 법적 의무, 안전, 되돌릴 수 없는 데이터까지 태우면 카오스가 아니라 파괴다. 내일 복구할 수 있는 불편과 한 번 잃으면 돌아오지 않는 자산을 같은 불로 취급해서는 안 된다. 세 번째 차이는 끝나는 조건이다. “지금만 임시”라는 말에는 날짜나 사건이 붙어야 한다. 고객 열 곳을 확보할 때까지 수동으로 처리한다. 이번 출시가 끝나면 중복 도구 하나를 없앤다. 같은 장애가 두 번 생기면 속도보다 재발 방지를 먼저 고친다. 끝나는 조건이 없는 임시방편은 임시가 아니라 운영 방식이다. 이 기준은 카오스를 없애지 않는다. 오히려 더 큰 카오스를 감수하게 한다. 무엇을 버렸는지 알고, 어디까지 태울지 정하고, 언제 다시 볼지 남겼기 때문이다. 질서를 모두 회복한 뒤 움직이려는 유혹에서 벗어나면서도 실패를 블리츠스케일링 탓으로 돌리지 않게 된다. ## 에이전트가 많을수록 더 많이 포기해야 한다 AI 에이전트는 할 수 있는 일의 수를 폭발시킨다. 글도 쓰고, 조사도 하고, 제품도 만들고, 운영도 자동화할 수 있다. 생산 비용이 내려가면 모든 가능성을 실행해도 될 것처럼 보인다. 하지만 산출물이 빨리 늘어난다고 목표에 도달하는 속도까지 빨라지지는 않는다. 가능한 일이 열 배가 되면 포기해야 할 일도 열 배가 된다. 에이전트를 붙일 수 있다는 이유만으로 자동화하면 새로운 유지보수와 검토가 생긴다. 일을 만드는 능력이 일을 버리는 판단보다 앞서면, 빠른 조직은 곧 산출물로 가득 찬 느린 조직이 된다. 블리츠스케일링은 모든 일을 빠르게 해내는 상태가 아니다. 한 가지 속도를 지키기 위해 많은 일을 미완성으로 남기고, 일부 문제는 커지는 것을 보면서도 지나가는 선택이다. 카오스는 그 선택의 비용이다. 핑계는 다르다. 무엇을 위해 버렸는지, 어디까지 망가뜨려도 되는지, 언제 다시 판단할지를 말하지 않는다. 카오스를 감수하는 사람은 포기한 일을 기억한다. 카오스를 핑계로 쓰는 사람은 포기했다는 사실부터 지운다. --- 주요 출처: Reid Hoffman·Chris Yeh의 블리츠스케일링 원칙을 소개한 Reid Hoffman, [「7 Counterintuitive Rules for Growing Your Business Super-Fast」](https://marker.medium.com/7-counterintuitive-rules-for-growing-your-business-super-fast-9dcdc2bfc649?ref=zerodraftlab.com); CBS News, [「Silicon Valley investor Reid Hoffman says companies should 'embrace chaos'」](https://www.cbsnews.com/news/blitzscaling-silicon-valley-investor-reid-hoffman-says-companies-should-embrace-chaos/?ref=zerodraftlab.com). 움직이지 않는 목표, 손실의 경계, 끝나는 조건으로 카오스와 핑계를 구분한 부분은 Zero Draft Lab의 해석입니다. ### 오픈소스 수익모델은 여섯 개가 아니라 질문 하나다 URL: https://zerodraftlab.com/open-source-uncopyable-layer/ Last updated: 2026-09-15T08:34:41.000Z 오픈소스로 돈을 벌려면 모델부터 고르라고들 한다. 오픈코어냐, API냐, 호스팅이냐. 순서가 거꾸로다. 모델은 고르는 것이 아니라 제품을 보면 이미 정해져 있다. 실제로 돈이 도는 형태를 세어보면 여섯이다. 매니지드 호스팅은 운영을 판다. API는 쌓인 데이터를 판다. 듀얼 라이선스는 법적 지위를 판다. 지원과 인증은 책임을 판다. 마켓플레이스는 생태계를 판다. 여섯 번째인 오픈코어만 파는 것의 이름이 다르다. 기능을 어디서 자를지 선언할 뿐, 무엇이 복제되지 않는지는 말하지 않는다. 앞의 다섯은 회사를 대보면 층이 그대로 드러난다. [고스트](https://ghost.org/about/?ref=zerodraftlab.com)는 코드를 전부 AGPL로 풀고 유료 기능을 따로 두지 않는다. 남은 층이 운영뿐이라서 파는 것도 호스팅 하나다. [컨텍스트7](https://github.com/upstash/context7?ref=zerodraftlab.com)은 클라이언트를 열고 인덱스를 닫았다. 남은 층이 쌓인 데이터라서 요금은 API 호출에 붙는다. MySQL은 소스가 다 열려 있어도 남의 상용 제품에 심으려면 GPL을 벗어야 한다. 남은 층이 법적 지위라서 파는 것이 라이선스다. 레드햇은 소스를 다 주고 보증을 판다. 남은 층이 책임이라서 조달 부서가 서명하는 것은 코드가 아니라 SLA다. 오토매틱과 오도는 코어보다 그 위에 붙은 확장 유통에서 걷는다. 남은 층이 파는 쪽과 사는 쪽이 쌓인 생태계다. 여기까지 다섯 모델에 다섯 층이 하나씩 붙는다. 남은 하나가 오픈코어다. 붙일 층이 없고, 매출을 보면 이유가 나온다. 몽고DB는 FY26 매출 24.6억 달러 중 18.1억 달러를 아틀라스에서 냈다. 엘라스틱은 17.4억 달러 중 8.37억 달러가 클라우드다. 이름은 오픈코어인데 계산서는 운영이 쓴다. 오픈코어는 여섯 번째 층이 아니라, 층을 정하지 않은 채 기능만 갈라 둔 포장이다. 층을 못 찾은 회사는 라이선스를 조인다. 엘라스틱이 SSPL로 바꾸자 오픈서치가 나왔고, 레디스에는 발키가, 하시코프에는 오픈토푸가 나왔다. 계약서로 급히 만들어낸 층은 포크 한 번에 무너진다. 그러니 첫 결정은 모델 이름이 아니다. 오늘 저장소를 통째로 공개했다고 치고, 내일 경쟁자가 그래도 못 만드는 것을 적어보는 일이다. 그 자리가 비어 있으면 어느 모델을 붙여도 매출이 붙지 않는다. 남는 질문은 하나다. 복제되지 않는 층은 어디서 생기고 언제 사라지나. 다섯 층은 결국 네 종류의 복제 비용으로 접힌다. 남의 시간, 쌓인 시간, 법, 책임이다. 운영은 남의 시간이고, 데이터와 생태계는 둘 다 쌓인 시간이다. 모델은 이 넷 중 하나를 고른 결과이고, 무너질 때도 고른 그 자리에서 무너진다. ## 남의 시간은 쉬워질수록 얇아진다 운영이 층인 모델은 셀프호스트가 쉬워지는 만큼 얇아진다. 도커 이미지 하나로 끝나는 제품에는 호스팅비를 받기 어렵다. 고스트와 디스코스가 결제, 발송, 업타임까지 떠안는 이유가 여기 있다. 팔고 있는 것은 설치가 아니라 매달 사라지는 시간이다. 코딩 에이전트가 셀프호스트 문제를 대신 풀어주기 시작하면 이 층은 더 얇아진다. ## 쌓인 시간은 안 베껴지는 대신 미터기를 드러낸다 인덱스, 크롤러, 동기화는 포크해도 따라오지 않는다. 대신 원가가 호출마다 붙어서 무료 한도가 곧 손익분기가 된다. 이 모델의 진짜 이점은 마진이 아니라 조이는 방법에 있다. 나중에 조일 손잡이가 요금제와 호출 한도라서, 이미 공개한 약속을 뒤집지 않아도 된다. 라이선스를 회수한 회사들이 잃은 것은 매출이 아니라 신뢰였다. 마켓플레이스도 같은 층에 앉는다. 확장을 파는 쪽과 사는 쪽이 모이는 데 걸린 시간이 복제를 막는다. 코어를 통째로 베껴도 상점은 따라오지 않는다. 다만 이 층은 내가 쌓는 것이 아니라 남이 쌓아주는 것이라서, 수수료를 올리는 순간 무너질 수도 있다. ## 법과 책임은 층이 아니라 계약이다 듀얼 라이선스는 상대가 내 코드를 자기 제품에 심어 배포할 때만 성립한다. 라이브러리에는 걸리고 SaaS에는 안 걸린다. 사용자는 소프트웨어를 배포하지 않으니 GPL 의무가 생기지 않는다. AGPL이 따로 만들어진 이유이자, 요즘 인프라 회사들이 AGPL을 고르는 이유다. 보증형도 마찬가지로 규제와 조달이 사줄 때만 성립한다. 레드햇이 2023년에 RHEL 소스 공개 경로를 센트OS 스트림으로 좁힌 사건은, 책임이라는 층도 복제 압력을 받는다는 뜻이었다. ## 층이 없는 제품에 붙일 모델은 없다 인증, CRUD, 대시보드처럼 주말에 복제되는 층은 아무리 잘 만들어도 곡괭이가 되지 않는다. 그때 선택지는 둘뿐이다. 층이 생길 때까지 파는 것을 미루거나, 이미 층을 가진 남의 제품 위에 얹히거나. 재단과 후원이 세 번째 길처럼 보이지만 그것은 매출이 아니라 자금 조달이다. 블렌더는 개발자를 먹여 살리되 성장 속도는 후원자 수가 정한다. 모델 이름은 나중에 붙는다. 먼저 답할 것은 하나다. 전부 공개하고 남는 것이 무엇인가. 운영이면 호스팅을, 축적이면 API나 마켓플레이스를, 법이면 라이선스를, 책임이면 보증을 팔면 된다. 넷 다 아니라면 아직 팔 물건이 없는 것이고, 그때 할 일은 모델 비교가 아니라 층을 만드는 일이다. ### 좋은 관리자는 판단을 독점하지 않는다 URL: https://zerodraftlab.com/scale-judgment-not-approval/ Last updated: 2026-08-29T06:35:27.000Z [37signals의 관리자 플레이북](https://basecamp.com/managers?ref=zerodraftlab.com)은 채용부터 해고까지 16개 장으로 이어진다. 겉으로 보면 인사 실무 안내서다. 끝까지 읽으면 더 큰 설계가 보인다. **좋은 관리자는 모든 결정을 승인하지 않는다. 다른 사람이 더 좋은 판단을 내리게 만든다.** 자율성을 중시하는 회사라면 관리자가 덜 필요해 보인다. 37signals도 모든 직원이 스스로를 관리할 수 있는 사람이어야 한다고 말한다. 그런데 플레이북은 자율성을 방임으로 번역하지 않는다. 관리자는 일하는 방법을 대신 정하지 않되, 좋은 일이 무엇인지 선명하게 보여주고 기준에서 벗어날 때 바로 개입해야 한다. ## 자율성을 믿을수록 경계를 먼저 적는다 [관리자 기준](https://basecamp.com/managers/manager-standards?ref=zerodraftlab.com)은 세 영역으로 나뉜다. 직무 전문성으로 기술적 조언을 주는 능력, 정기적인 1:1과 피드백을 유지하는 참여, 부하 직원에게도 자신의 관리 방식에 대한 의견을 구하는 코칭 수용성이다. 관리자는 직급만으로 권위를 얻지 않는다. 반복되는 행동으로 신뢰를 증명해야 한다. 흥미로운 대목은 무엇을 할 수 있는가보다 [어디까지 할 수 없는가](https://basecamp.com/managers/boundaries?ref=zerodraftlab.com)를 먼저 밝힌다는 점이다. 직원은 휴가를 허락받지 않고 일정을 알린다. 관리자는 보상 수준과 이익 배분을 결정하지 않는다. 괴롭힘이나 차별 같은 중대한 신고를 받으면 혼자 해결하려 하지 않고 People Ops에 넘긴다. 이 경계는 관리자의 힘을 약하게 만들지 않는다. 대신 재량을 써야 할 문제와 정해진 절차를 따라야 할 문제를 분리한다. 모든 사안을 관리자 개인의 판단에 맡기지 않으니 직원은 눈치를 덜 보고, 관리자는 사람과 일의 품질에 집중할 수 있다. ## 채용은 늦게 하고, 온보딩은 촘촘하게 한다 37signals는 [지속적으로 일이 막힐 만큼 아플 때 채용한다](https://basecamp.com/managers/hiring?ref=zerodraftlab.com). 빈자리가 불편하다는 이유만으로 사람을 늘리지 않는다. 실제 업무와 닮은 과제로 지원자의 기술뿐 아니라 문제 접근법과 의사소통을 본다. 확신할 후보가 없으면 아무도 뽑지 않는 편이 팀에 부담을 더하는 채용보다 낫다고 본다. 일단 뽑으면 관리 강도는 잠시 높아진다. [온보딩 장](https://basecamp.com/managers/onboarding?ref=zerodraftlab.com)은 첫날 통화, 주간 1:1, 3·6·12개월 평가, 첫해의 반복 설명을 요구한다. 도구 사용법만 알려주는 것이 아니다. 어떤 채널에서 무엇을 말하는지, 좋은 결과물은 어떤 모습인지, 막혔을 때 어떻게 도움을 구하는지, 합리적인 긴급성과 좋은 판단이 실제 업무에서 어떻게 드러나는지까지 설명한다. 신입에게 관리가 많이 필요한 이유는 능력이 없어서가 아니다. 아직 회사의 암묵적 기준을 볼 수 없기 때문이다. 관리자는 처음부터 답을 대신 내리는 사람이 아니라, 보이지 않던 판단 기준을 드러내는 사람이다. ## 성과 관리는 연말 행사가 아니라 평소의 증거 수집이다 [성과 관리 모델](https://basecamp.com/managers/performance-management-model?ref=zerodraftlab.com)은 역량, 참여, 코칭 수용성의 세 축을 사용한다. 기술이 뛰어나도 무엇을 하는지 공유하지 않고 피드백을 거부한다면 높은 성과자로 보지 않는다. 반대로 한 프로젝트에서 참여도가 낮았다는 이유로 사람 전체를 고정된 등급에 가두지도 않는다. 세 축은 시점에 따라 움직이는 관찰값이다. [평가](https://basecamp.com/managers/performance-reviews?ref=zerodraftlab.com)에는 인상보다 작업 증거가 들어간다. PR, 프로젝트 기록, 동료의 구체적인 피드백을 모아 결과의 양과 영향, 필요한 수정의 정도, 판단력, 협업 방식을 함께 본다. 연간 평가에서 처음 문제를 알리는 일도 피한다. 평소에 피드백하지 않았다면 직원은 자신의 수준을 잘못 이해하고, 팀은 문제를 오래 떠안는다. 문제가 반복되면 기록은 기억을 대신한다. [성과 부진](https://basecamp.com/managers/underperformance-and-terminations?ref=zerodraftlab.com)과 [어려운 대화](https://basecamp.com/managers/navigating-difficult-conversations?ref=zerodraftlab.com)를 다루는 장은 부족한 점, 실제 사례, 팀에 미친 영향, 바뀌어야 할 행동, 기한과 결과를 미리 적으라고 한다. 대화를 미루는 친절은 직원에게 개선 기회를 주지 않고 동료에게 비용을 넘긴다. ## 피드백은 관리자의 취향을 복제하는 일이 아니다 [피드백 장](https://basecamp.com/managers/giving-feedback?ref=zerodraftlab.com)은 다른 접근법과 잘못된 접근법을 구분한다. 직원의 방법이 관리자의 방법과 달라도 결과와 팀에 해가 없다면 개입하지 않는다. 진행이 늦거나 품질과 사기를 해칠 때만 관찰한 사실, 기대한 상태, 바꿔야 할 행동을 구체적으로 말한다. 이 구분이 없으면 전문성이 미세 관리로 바뀐다. 관리자는 자신의 정답을 빠르게 복제할 수 있지만, 그 팀은 관리자가 없는 순간 멈춘다. 반대로 결과 기준만 공유하고 다른 해결법을 허용하면 직원은 선택의 결과를 보고 자신의 판단을 교정한다. [1:1](https://basecamp.com/managers/1-1s?ref=zerodraftlab.com)도 진행 상황을 받아 적는 시간이 아니다. 어떤 결정을 내렸고 왜 그렇게 했는지 함께 검토하며 판단 과정을 연습하는 시간이다. [코칭](https://basecamp.com/managers/coaching?ref=zerodraftlab.com)은 답을 직접 주는 방식과 질문으로 스스로 답을 찾게 하는 방식을 상황에 따라 섞는다. 경험이 부족하거나 시간이 촉박할 때는 더 구체적으로 지시하고, 스스로 해결할 역량이 있으면 질문을 통해 생각을 확장한다. ## AI는 판단자가 아니라 리허설 상대다 플레이북은 여러 장에서 AI 사용을 권한다. 채용 과제가 모호한지 압박 시험하고, 피드백 문장에서 사람을 공격하는 표현이나 근거 없는 판단을 찾고, 현재 직급과 다음 직급의 차이를 정리하는 데 쓴다. 어려운 대화를 앞두고 주장에 증거가 있는지 점검하는 용도도 나온다. 그러나 AI가 최종 판단을 내리게 하지는 않는다. [승진](https://basecamp.com/managers/promotion?ref=zerodraftlab.com)은 체크리스트로 자동 판정하지 않고, 이미 모은 업무 증거와 사업상 필요를 관리자가 함께 판단한다. 어려운 대화에서도 AI가 만든 대본을 읽지 말라고 한다. 맥락과 책임이 필요한 결정을 모델에 넘기면 평가가 일관돼 보일 수는 있어도 관리자의 책임은 사라지지 않는다. 이 쓰임새는 AI 시대의 관리 원칙을 잘 보여준다. AI는 표현의 모호함과 빠진 근거를 찾는 값싼 반대편이 될 수 있다. 하지만 누구를 채용하고 승진시키며 내보낼지 결정하는 일은 증거를 해석하고 결과를 감당할 사람이 맡아야 한다. ## 관리자의 산출물은 더 많은 승인이 아니다 [마지막 장](https://basecamp.com/managers/multiplier-managers?ref=zerodraftlab.com)은 모든 중요한 결정이 위로 올라오면 관리자가 병목이 된다고 지적한다. 그래서 좋은 관리자는 문제의 답보다 답을 만드는 방법을 가르친다. 직원이 관리자 없이도 판단할 수 있게 되면 의사결정이 분산되고, 두 사람 모두 더 빠르게 움직인다. 그렇다고 관리자가 사라지는 것은 아니다. 기대 수준을 명확히 하고, 실제 작업을 관찰하고, 좋은 행동을 구체적으로 인정하고, 문제가 작을 때 직접 말하고, 합의한 내용을 기록하는 일은 계속 남는다. [플레이북의 결론](https://basecamp.com/managers/conclusion?ref=zerodraftlab.com)처럼 관리 능력은 타고난 감각보다 반복 가능한 연습에서 나온다. ## Zero Draft Lab의 해석 이 플레이북은 사람 관리 문서인 동시에 의사결정 시스템 문서다. 권한의 경계, 평가 기준, 피드백 주기, 증거의 위치, 에스컬레이션 경로를 미리 정해 관리자의 기분이 조직의 운영체제가 되는 일을 막는다. 자율적인 팀은 관리가 없는 팀이 아니다. 작은 결정은 현장에 남기고, 큰 결정은 근거와 책임이 있는 곳으로 보내는 팀이다. 좋은 관리자는 자신의 승인 건수를 늘리지 않는다. **자신이 없어도 좋은 판단이 흐를 수 있는 조건을 늘린다.** --- 주요 출처: 37signals, [Manager Playbook](https://basecamp.com/managers?ref=zerodraftlab.com)과 하위 16개 장. 관리자 플레이북을 의사결정 시스템으로 읽고 AI를 판단자가 아닌 리허설 상대로 해석한 부분은 Zero Draft Lab의 해석입니다. ### 깃허브에 올린다고 제품이 되는 건 아니다 URL: https://zerodraftlab.com/open-source-is-distribution/ Last updated: 2026-09-15T08:34:41.000Z 바이브코딩으로 돈을 벌고 싶은 사람은 광부다. 금은 첫 결제 고객이다. 대부분은 금을 캐지 못한다. 그래도 곡괭이부터 산다. MCP 서버나 SDK를 깃허브에 올리는 일이 딱 그렇다. 곡괭이는 제품이 아니다. 무료 도구는 고객과 악수하는 면이고, 돈을 받을 엔진은 API 뒤에 남겨야 한다. 이 구분은 새롭지 않다. Stephen O'Grady는 2007년에 오픈소스 회사의 이점을 [distribution](https://redmonk.com/sogrady/2007/06/07/the-open-source-business-meme/?ref=zerodraftlab.com)이라고 불렀다. Peter Levine은 2019년에 커뮤니티를 [개발자가 밀어 올리는 깔때기 상단](https://a16z.com/open-source-from-community-to-commercialization/?ref=zerodraftlab.com)이라고 적었다. 이 모델에서 오픈소스는 판매할 제품이라기보다 고객을 얻는 비용에 가깝다. ## 오픈코어와 API 모델은 실패 방식이 다르다 오픈코어는 작동하는 제품을 깃허브에 둔다. 사용자는 직접 셀프호스트할 수 있다. 회사는 SSO, 감사 로그, 클러스터, 호스팅처럼 같은 제품의 위층에서 돈을 받는다. GitLab과 Grafana가 대표적이다. 바이브코더가 만드는 많은 도구는 구조가 다르다. 공개 레포에는 MCP 서버나 SDK가 있고, 설치는 한 줄로 끝난다. 하지만 실행하면 결국 회사의 API를 호출한다. Joe Morrison은 2019년에 이를 [value-added libraries의 별자리](https://joemorrison.medium.com/three-models-for-commercializing-open-source-software-84d3130c82cd?ref=zerodraftlab.com)라고 불렀다. Vercel은 2025년에 같은 구조를 [Open SDK strategy](https://vercel.com/blog/open-sdk-strategy?ref=zerodraftlab.com)로 정리했다. 프레임워크와 클라이언트는 열고, 상업 제품은 따로 둔다. 둘을 오픈소스라는 한 단어로 묶으면 계획이 틀린다. 오픈코어 회사는 제품을 너무 많이 열면 돈을 못 받는다. API 회사는 어댑터를 너무 적게 열면 아예 설치되지 않는다. 실패 방식이 반대다. ## 설치 지점만 바뀌었고 계산대는 그대로다 2010년대에는 패키지 설치가 첫 악수였다. 지금은 에이전트의 도구함에 들어가는 일이 그 역할을 한다. 사용자는 제품을 받은 것처럼 느끼지만 직접 돌릴 수 있는 것은 클라이언트뿐이다. 인덱스를 다시 만들 수 없다면 포크는 제품이 아니라 광고만 복제한다. 따라서 나중에 클라이언트 라이선스를 뒤집을 이유가 없다. 조정할 것은 API 호출 한도와 요금제다. 호출 한도를 조정하는 일은 라이선스 회수가 아니라 서비스 가격 조정이다. 제품을 열어 두었다가 나중에 라이선스를 거두는 일과는 종류가 다르다. ## 여는 것과 잠그는 것을 첫날에 적는다 열어야 할 것은 개발자나 에이전트가 직접 만져야 시작되는 면이다. MCP, CLI, SDK, 예제, 문서가 여기에 들어간다. 로컬에서 혼자 쓰는 최소 기능은 실제로 작동해야 한다. 데모 수준에서 잠그면 유통이 시작되지 않는다. 닫아둘 것은 다시 만들기 비싼 층이다. 인덱스, 크롤러, 동기화, 호스티드 검색이 여기에 들어간다. README에 이 경계를 첫날 적는다. 제품 전체를 열었다가 나중에 라이선스를 바꾸는 경로보다 처음부터 엔진을 닫아두는 경로가 싸다. 반대로 공개한 부분이 너무 완전하면 유료로 넘어갈 이유가 사라진다. 로컬 무료 버전은 쓸 만해야 한다. 유료 가치는 세션이 바뀌고, 기기가 늘고, 팀이 생길 때 생기는 불편을 해결해야 한다. ## 첫 곡괭이는 코딩 에이전트가 아니다 에디터, 문서, 로그인, 결제에는 이미 강자가 있다. 바이브코더가 앱을 돈으로 바꾸는 과정에서 아직 구멍이 큰 곳은 세션이 바뀔 때 사라지는 프로젝트 기억이다. 범용 메모리 플랫폼을 표방하면 에이전트 벤더의 기본 기능과 정면으로 맞붙는다. 범위는 유료 제품을 만들 때 필요한 기억으로 좁히는 편이 낫다. 로컬 클라이언트는 깃허브에 열고, 동기화와 검색은 API로 판다. ## 90일에 볼 것은 스타가 아니다 스타는 광고이지 북극성이 아니다. 설치, API 키 발급, 무료 한도 도달, 결제만 본다. 스타만 있고 키 발급이 없다면 유통에서 멈춘 것이다. 키는 발급되는데 아무도 한도에 닿지 않는다면 유료 엔진의 가치나 경계를 다시 봐야 한다. 악수는 열고, 엔진은 미터링한다. 이미 한 약속은 라이선스로 뒤집지 않는다. 깃허브는 가게 앞이고, 제품은 API 뒤에 있다. --- 오픈소스를 유통으로 본 서술은 RedMonk의 The Open Source Business Meme, a16z의 Open Source From Community to Commercialization, Joe Morrison의 Three Models for Commercializing Open Source Software, Vercel Open SDK strategy를 참고했습니다. Context7이 무엇을 공개하고 무엇을 API에 남겼는지는 upstash/context7 README를 기준으로 했습니다. 본문은 특정 회사의 매출이나 전환율을 검증하지 않습니다. ### 클로드 코드의 세션이 서로 연락하기 시작했다 URL: https://zerodraftlab.com/claude-code-sessions-connect/ Last updated: 2026-08-29T06:35:55.000Z 2026년 8월 15일 한국시간 기준, Anthropic의 [Claude 제품 릴리스 노트](https://support.claude.com/en/articles/12138966-release-notes?ref=zerodraftlab.com)에 올라온 8월 항목은 하나다. Enterprise 조직이 제3자 skill과 plugin을 올리거나 수정할 때 악성 콘텐츠를 검사하는 보안 스캔 베타다. 같은 기간 Claude Code에는 변화가 몰렸다. 공식 [GitHub 릴리스 목록](https://github.com/anthropics/claude-code/releases?ref=zerodraftlab.com)을 날짜별로 세면 8월 4일의 `v2.1.221`부터 8월 15일의 `v2.1.233`까지 12개 버전이 나왔다. 여러 Claude Code 세션이 서로를 찾고, 메시지를 보내고, 각자의 작업 공간에서 일을 이어가는 기능이 이번 묶음의 중심에 있다. ## Claude 쪽 변화는 보안과 제품 전환에 모였다 Claude 앱의 8월 신규 기능은 현재까지 Enterprise용 skill·plugin 보안 스캔 하나다. 새 모델 출시는 없다. 공식 릴리스 노트상 직전 모델 발표는 7월 24일의 Claude Opus 5다. 대신 이전에 예고된 제품 전환 두 건이 8월에 도착했다. 기존 Claude in Slack은 8월 3일부터 [Claude Tag](https://support.claude.com/en/articles/15594475-what-is-claude-tag?ref=zerodraftlab.com)로 넘어갔다. Team과 Enterprise 사용자는 채널에서 `@Claude`를 불러 작업을 맡기고, Claude는 참여한 채널의 관련 맥락을 기억해 후속 작업을 할 수 있다. 8월 17일에는 [Legacy Workbench가 종료될 예정](https://support.claude.com/en/articles/8606378-how-do-i-use-the-workbench?ref=zerodraftlab.com)이다. 새 Workbench는 공개 Messages API의 요청과 응답을 그대로 보여주는 stateless 도구다. 대신 저장된 prompt, 버전 기록과 eval은 지원하지 않는다. Legacy Workbench에 남은 자료는 종료 전에 export해야 한다. ## Claude Code 세션이 서로 연락한다 [v2.1.224](https://github.com/anthropics/claude-code/releases/tag/v2.1.224?ref=zerodraftlab.com)에는 `SendMessage`와 `ListAgents`가 들어갔다. macOS와 Linux에서 실행 중인 Claude Code 세션이 같은 컴퓨터뿐 아니라 다른 컴퓨터의 세션도 찾고 메시지를 보낼 수 있다. Remote Control 세션에도 먼저 말을 걸 수 있다. [v2.1.232](https://github.com/anthropics/claude-code/releases/tag/v2.1.232?ref=zerodraftlab.com)는 이 흐름을 사용자 인터페이스로 끌어올렸다. 프롬프트에서 `@세션명`을 쓰면 Claude가 해당 세션에 메시지를 보낸다. 같은 컴퓨터에서 세션 이름이 겹치면 자동으로 다른 이름을 붙이고, 다른 세션이 보낸 메시지를 받을지·보류할지·거절할지도 설정할 수 있다. Subagent의 기본 동작도 바뀌었다. `subagent_type: "fork"`는 부모 세션의 전체 대화와 prompt cache를 상속하며, interactive session에서 띄운 일반 subagent는 기본적으로 background에서 실행된다. 여러 세션이 각각 맥락과 이름을 가진 채 협업하는 구조가 제품 기본값으로 들어왔다. ## Claude가 일할 컴퓨터도 직접 고를 수 있다 v2.1.224의 `claude self-hosted-runner`는 Team과 Enterprise 사용자가 자신의 머신이나 컨테이너를 Claude Code web·mobile·desktop 세션의 실행 장소로 등록하게 한다. 조직이 관리하는 컴퓨터에서 원격 작업을 돌릴 수 있는 선택지가 생겼다. Remote Control도 8월 릴리스 대부분에서 손질됐다. 긴 대화를 compact한 뒤 history가 깨지던 문제, 네트워크가 끊긴 뒤 재접속이 멈추던 문제, Desktop이나 IDE에서 세션을 다시 열 때 새 claude.ai 세션으로 보이던 문제가 수정됐다. v2.1.232부터는 네트워크가 흔들려도 약 30분 동안 재접속을 계속한다. ## 분업의 단위는 worktree가 됐다 [v2.1.221](https://github.com/anthropics/claude-code/releases/tag/v2.1.221?ref=zerodraftlab.com)부터 `/fork`로 갈라진 세션은 원래 checkout을 함께 쓰지 않고 별도 Git worktree를 만든다. 바로 다음 [v2.1.222](https://github.com/anthropics/claude-code/releases/tag/v2.1.222?ref=zerodraftlab.com)에서는 격리된 세션과 subagent가 main checkout을 대상으로 destructive git 명령을 실행할 수 있던 허점도 막았다. GitLab 지원도 같은 경계 위에 올라왔다. v2.1.232는 GitLab plugin marketplace, 여러 GitLab token 형식의 redaction, `glab` 설정 파일 보호를 추가했다. [v2.1.233](https://github.com/anthropics/claude-code/releases/tag/v2.1.233?ref=zerodraftlab.com)에서는 GitLab merge request URL을 `--worktree`와 `claude agents`가 직접 받는다. GitHub PR만 전제하던 작업 흐름이 GitLab MR까지 넓어진 것이다. ## 자동화가 늘어난 만큼 경계도 자주 바뀐다 8월 변경에는 권한 우회와 sandbox 수정이 반복해서 등장한다. zsh 조건문 안에 명령을 숨기는 방식, PowerShell 변수로 뒤따르는 파일 접근을 바꾸는 방식, symlink와 Windows UNC path를 이용하는 방식이 차례로 막혔다. 중첩 Git 저장소는 부모 폴더의 신뢰를 물려받지 않고 각각 확인을 받게 됐다. 기존 사용법을 바꾸는 항목도 있다. v2.1.222에서 `/ultraplan`이 제거됐다. v2.1.233부터 Opus 4.8, Sonnet 5, Fable 5, Mythos 5와 이후 모델에서는 `TaskCreate`, `TaskGet`, `TaskUpdate`, `TaskList`, `TodoWrite`가 기본 제공되지 않는다. 필요한 환경은 `CLAUDE_CODE_ENABLE_TODO_TOOLS=1`로 다시 켤 수 있다. 릴리스 속도 자체도 주의할 신호다. v2.1.232에서 강화한 Windows의 input redirection과 Cygwin symlink 권한 검사는 다음 버전인 v2.1.233에서 일부 되돌려졌다. 더 좁은 수정으로 다시 내놓겠다는 설명이 붙었다. 12일 동안 12개 버전이 나온 제품에서는 최신 기능을 안다는 것만큼 현재 설치 버전과 changelog를 읽는 일이 중요하다. ## Zero Draft Lab의 해석 8월의 Claude Code는 세션 이름, 대화 맥락, prompt cache, worktree, permission, runner, Remote Control, marketplace와 gateway를 하나의 작업 상태로 묶기 시작했다. Claude Code는 여러 작업자를 배치하고 격리하고 다시 연결하는 운영 레이어에 가까워지고 있다. 그 운영 레이어는 아직 빠르게 변한다. 세션 간 통신이 기본값이 된 바로 다음 버전에서 보안 경계가 다시 조정되고, 익숙한 task 도구가 모델별로 사라진다. 기능을 켜기 전에 어떤 세션이 어떤 저장소와 worktree를 소유하는지, 메시지를 어디까지 자동으로 받을지, 작업이 끝났다는 증거를 무엇으로 남길지 정해야 한다. --- 2026년 8월 15일 KST 기준. 주요 출처: Anthropic, [Claude 제품 릴리스 노트](https://support.claude.com/en/articles/12138966-release-notes?ref=zerodraftlab.com), [Claude Tag 안내](https://support.claude.com/en/articles/15594475-what-is-claude-tag?ref=zerodraftlab.com), [Workbench 전환 안내](https://support.claude.com/en/articles/8606378-how-do-i-use-the-workbench?ref=zerodraftlab.com); Anthropic Claude Code, [공식 GitHub 릴리스 목록](https://github.com/anthropics/claude-code/releases?ref=zerodraftlab.com) 및 [v2.1.221](https://github.com/anthropics/claude-code/releases/tag/v2.1.221?ref=zerodraftlab.com), [v2.1.222](https://github.com/anthropics/claude-code/releases/tag/v2.1.222?ref=zerodraftlab.com), [v2.1.224](https://github.com/anthropics/claude-code/releases/tag/v2.1.224?ref=zerodraftlab.com), [v2.1.232](https://github.com/anthropics/claude-code/releases/tag/v2.1.232?ref=zerodraftlab.com), [v2.1.233](https://github.com/anthropics/claude-code/releases/tag/v2.1.233?ref=zerodraftlab.com). Claude Code가 작업자 배치와 격리를 맡는 운영 레이어에 가까워졌다는 결론은 이 변경 묶음에 대한 Zero Draft Lab의 해석입니다. ### 원가는 가격의 바닥일 뿐이다 URL: https://zerodraftlab.com/cost-is-only-price-floor/ Last updated: 2026-08-29T06:36:09.000Z 가격을 정할 때 가장 먼저 보는 숫자는 대개 원가다. 서버비와 모델 사용료에 원하는 마진을 얹으면 계산이 쉽다. 그러나 B2B 고객은 판매자의 원가를 사지 않는다. 일을 덜 하거나, 비용을 줄이거나, 매출을 늘리는 결과를 산다. Y Combinator 파트너 톰 블롬필드는 [B2B 가격 강의](https://www.youtube.com/watch?v=4hjiRmgmHiU&ref=zerodraftlab.com)에서 가격의 출발점을 고객의 경제적 가치에 둔다. 제품이 고객에게 얼마를 벌어주거나 아껴주는지 고객과 함께 계산하고, 그중 일부를 가격으로 가져오라는 것이다. 원가는 이 계산의 출발점이 아니라 내려가면 안 되는 바닥이다. ## 고객이 얻는 돈부터 쓴다 강의의 예시는 가상 고객센터다. 상담원 100명의 총고용비가 1인당 연 10만 달러라면 연간 비용은 1,000만 달러다. 제품이 업무량을 20% 줄인다면 고객이 얻는 가치는 연 200만 달러로 계산할 수 있다. 블롬필드는 이 가치의 25\~50%를 가격으로 검토할 수 있다며 약 70만 달러를 예로 든다. 여기서 중요한 것은 70만 달러라는 답이 아니다. 가격을 “우리 제품은 이 정도는 받아야 한다”가 아니라 “고객의 어떤 비용이 얼마나 달라지는가”로 설명한다는 점이다. 담당자는 이 계산을 들고 CFO에게 구매를 변호할 수 있다. 물론 판매자가 만든 가치 계산은 쉽게 부풀려진다. 기준 기간, 실제 사용률, 도입비, 결과가 나타날 때까지 걸리는 시간, 다른 변화의 영향을 함께 넣어야 한다. 고객과 판매자가 측정 방법에 합의하지 못한 가치는 가격 근거가 아니라 영업 문구에 가깝다. ## 가치식은 파일럿의 합격선도 정한다 가치식은 계약 전에만 쓰는 계산표가 아니다. 파일럿이 성공했는지 판정하는 기준이 된다. 고객지원 업무를 20% 줄이기로 했다면 시작 전에 현재 처리시간과 인건비를 기록하고, 종료 뒤 같은 방식으로 측정한다. 절감률이 15%인지 25%인지에 따라 약속과 가격을 다시 조정할 수 있다. 이렇게 하면 “반응이 좋았다”는 모호한 결론 대신 돈과 연결된 결과가 남는다. 반대로 측정할 수 없는 파일럿은 무료 사용 기간만 늘리고 구매 결정은 미룰 가능성이 크다. ## 원가는 가격의 바닥이다 가치가 천장이라면 원가는 바닥이다. 블롬필드는 AWS나 OpenAI가 제공한 크레딧도 현금 원가처럼 계산하라고 말한다. 크레딧이 끝난 뒤에도 같은 가격으로 팔아야 하기 때문이다. 고객이 한 번 더 사용할 때 늘어나는 모델·서버·지원 비용을 빼고도 사업을 운영할 돈이 남아야 한다. 강의에서 제시한 소프트웨어 총마진 80\~90%는 보편 법칙이 아니라 투자자 관점의 경험칙이다. AI 추론비, 데이터 공급비, 사람이 개입하는 서비스 비중에 따라 적정 마진은 달라진다. 다만 원가를 무시한 가치 기반 가격도 오래가지 못하고, 원가에만 마진을 붙인 가격은 고객이 얻는 큰 가치를 놓칠 수 있다. ## 경쟁자가 싸다고 따라 내리면 상품이 사라진다 경쟁사 가격은 확인해야 하지만 복사할 답은 아니다. 더 싼 경쟁자가 등장할 때마다 가격을 내리면 결국 기능과 지원을 유지할 돈도 사라진다. 블롬필드가 권하는 방향은 업종, 기능, 통합, 규제 대응처럼 특정 고객이 더 중요하게 여기는 차이를 만드는 것이다. 다만 “차별화했으니 비싸도 된다”는 말만으로는 부족하다. 그 차이가 구매자의 비용, 위험, 매출 중 무엇을 얼마나 바꾸는지 다시 가치식으로 돌아와야 한다. 경쟁 가격은 시장의 신호이고, 고객 가치와 원가는 가격의 경계다. ## 가격 구조는 구매 습관과 판매 방식을 함께 정한다 고객이 이미 좌석당 비용에 익숙하다면 좌석 가격이 설명하기 쉽다. 처리 건수나 API 호출량으로 예산을 잡는 고객이라면 사용량 가격이 자연스럽다. 낯선 구조를 교육하는 데 드는 비용까지 가격에 포함되므로, 가능하면 고객이 익숙한 단위를 빌리는 편이 낫다. 블롬필드는 순수 사용량제보다 최소 월 약정과 구간 할인 같은 혼합형을 선호한다. 반복 매출을 예측하고 영업 조직을 운영하기 쉽기 때문이다. 이것도 모든 고객에게 최선이라는 뜻은 아니다. 사용량이 크게 흔들리는 AI·API 제품은 종량제, 상한선, 약정을 조합해 고객의 예산 위험과 판매자의 매출 위험을 나눌 수 있다. 가격은 판매 방식도 결정한다. 강의는 영업 담당자 총보상의 약 다섯 배를 신규 연간 반복매출로 벌어야 한다는 거친 기준을 제시한다. 정확한 배수보다 중요한 결론은 낮은 계약금액에 비싼 영업 절차를 붙일 수 없다는 것이다. 가격이 작으면 셀프서브와 짧은 구매가 필요하고, 가격이 크면 보안 검토와 도입 지원을 감당할 여지가 생긴다. ## 엔터프라이즈 가격이 공개되지 않는 이유 엔터프라이즈의 “문의하기”는 단지 가격을 숨기는 장치가 아니다. 같은 제품도 고객 규모, 절감액, 규제 요구, SSO·감사로그·데이터 상주 같은 기능에 따라 가치와 도입비가 달라진다. 공개된 저가 요금제로 작은 고객을 받고, 별도 협상으로 큰 고객의 요구를 반영할 수 있다. 그러나 가치 기반 가격을 고객마다 최대한 받아내는 불투명한 협상으로 쓰면 신뢰를 잃는다. 고객군, 제공 범위, 성공 기준이 달라질 때 가격이 왜 달라지는지 설명할 수 있어야 한다. 가치식은 가격 차별을 정당화하는 주문이 아니라 범위와 결과를 합의하는 문서다. ## 무료 파일럿보다 짧고 측정 가능한 검증 긴 무료 체험은 사용을 늘릴 수 있지만 구매 결정을 보장하지 않는다. 블롬필드는 짧은 파일럿에 명확한 성공 기준을 두고, 제품에 자신이 있다면 연간 계약에 30일 또는 60일 환불·철회 조건을 붙이는 방식을 제안한다. 고객에게는 위험을 낮추고 판매자에게는 결정 시점을 만든다. 또 스타트업을 큰 회사처럼 보이게 꾸미지 말라고 한다. 초기 회사가 줄 수 있는 창업자의 직접 지원과 빠른 수정은 약점이 아니라 거래 조건이다. 파일럿에서 그 장점을 쓰되, 매번 창업자가 붙어야만 결과가 나오는지 원가에는 정직하게 반영해야 한다. ## 가격도 실제 제안으로 배운다 가격은 설문보다 실제 구매 제안에서 더 잘 배운다. 블롬필드는 확신이 없다면 새 제안마다 가격을 50%씩 올려보고, 가격 하나 때문에 거래의 25% 넘게 잃을 때 조정하라는 공격적인 실험법을 말한다. 시장, 표본, 거래 규모를 무시하고 적용할 공식은 아니다. 특히 적은 제안 수에서는 한두 건의 거절을 일반화하기 쉽다. 안전한 해석은 가격을 고정된 진실로 보지 말고 기록 가능한 실험으로 운영하라는 것이다. 고객군, 제안 가격, 가치 가정, 거절 이유, 계약 결과를 함께 남기면 “비싸서 안 샀다”와 “가치가 불분명해서 안 샀다”를 구분할 수 있다. ## Zero Draft Lab의 해석 가격표는 원가에 마진을 얹는 문서가 아니다. 고객이 어떤 비용을 피하고, 그 결과를 어떻게 확인하며, 그중 얼마를 판매자와 나눌지 적는 계약의 초안에 가깝다. 순서는 단순하다. 고객의 현재 비용이나 수익을 적고, 제품이 바꾸는 비율과 측정법에 합의한다. 그다음 원가를 바닥으로 확인하고, 경쟁 대안과 구매 습관에 맞춰 가격 단위를 고른다. 마지막으로 그 가격이 감당할 수 있는 판매 절차를 붙인다. 이 네 숫자가 연결되지 않으면 가격은 계산이 아니라 희망에 머문다. --- 주요 출처는 Y Combinator의 [How To Price For B2B](https://www.youtube.com/watch?v=4hjiRmgmHiU&ref=zerodraftlab.com)입니다. 가치 기반 가격의 일반 원칙과 고객 조사·세분화·비용 점검은 Stripe의 [B2B pricing strategy](https://stripe.com/resources/more/b2b-pricing-strategy-how-to-design-models-that-drive-long-term-growth?ref=zerodraftlab.com), B2B 소프트웨어의 저가 책정 위험은 Stripe의 [Marc Andreessen AMA](https://stripe.com/blog/marc-andreessen-ama?ref=zerodraftlab.com)와 대조했습니다. 25\~50% 가치 배분, 80\~90% 총마진, 영업 보상 대비 신규 ARR 5배, 제안마다 50% 인상해 가격만으로 25% 넘게 잃을 때 조정하라는 수치는 모두 강연자의 경험칙이며 업계 표준이 아닙니다. ### 영업이 안 된다는 결론은 너무 일찍 나온다 URL: https://zerodraftlab.com/first-customer-funnel-math/ Last updated: 2026-08-29T06:38:15.000Z [**Y Combinator의 「How to Get Your First Customers」**](https://www.youtube.com/watch?v=hyYCn%5FkAngI&ref=zerodraftlab.com)는 새로운 성장 채널을 추천하지 않는다. 계약 목표에서 출발해 데모, 응답, 최초 연락 수를 거꾸로 계산하라고 한다. 초기 영업이 막혔을 때 “영업은 안 된다”는 결론부터 내리지 않게 만드는 산수다. 강연자는 YC 파트너이자 Airbnb 성장팀에서 일했던 Gustaf Alströmer다. 영상은 수작업 고객 모집, 창업자 영업, 퍼널 기록, 첫 결제, 목표 역산 순서로 진행된다. 여기서 쓸 만한 부분은 성공 사례보다 각 단계의 이탈을 기록하는 방식이다. ## 고객 두 명은 연락 500건 뒤에 있을 수 있다 영상의 가상 예시는 유료 고객 두 명을 목표로 둔다. 최초 연락 500건에서 250건이 열리고, 약 20건이 응답하고, 10건이 데모로 이어져 두 건이 결제되는 흐름이다. 이 숫자는 YC 회사들의 평균도, 달성 보장선도 아니다. 퍼널마다 사람이 빠져나가므로 마지막 목표만 적어서는 필요한 앞단의 양을 알 수 없다는 설명용 계산이다. 자기 사업에서는 고객 수부터 거꾸로 쓴다. 계약 두 건을 만들려면 제안이 몇 건 필요했는지, 제안을 만들려면 상담이 몇 건 필요했는지, 상담을 잡으려면 몇 명에게 연락했는지를 기록한다. 처음에는 가정으로 채우되, 실제 결과가 생길 때마다 자기 전환율로 바꾼다. ## 시도 횟수가 적으면 실패 원인도 알 수 없다 같은 가상 전환율에서 연락을 100건만 보내면 결제가 0건일 수 있다. 영상은 이때 SEO, 광고, 추천 같은 다른 채널로 옮겨가는 창업자의 판단을 경계한다. 연락 수가 부족했는지, 대상이 틀렸는지, 메시지가 약했는지, 데모가 문제였는지 구분할 기록이 없기 때문이다. 그렇다고 무작정 500건을 보내라는 뜻은 아니다. 연락, 응답, 미팅, 제안, 결제를 나누면 어디서 크게 줄었는지 볼 수 있다. 응답이 없으면 대상과 첫 문장을 살피고, 미팅은 잡히는데 계약이 없으면 자격 확인·가격·제안을 살핀다. 같은 “매출 0원”이어도 고칠 곳이 달라진다. ## 첫 고객은 가장 쉬운 곳에서 찾는다 Alströmer는 첫 고객을 가장 설득하기 어려운 대기업에서 찾지 말라고 한다. 이미 아는 사람, 의사결정자가 가까운 작은 조직, 새 도구를 기꺼이 시험하는 초기 수용자가 더 빠른 후보가 될 수 있다. Brex 창업자들이 YC 동기 회사에서 첫 열 곳을 모집하고 직접 온보딩한 사례도 이 대목에서 등장한다. “스타트업이 가장 쉽다”는 조언은 YC의 B2B 소프트웨어 환경에 치우쳐 있다. 의료·금융처럼 규제와 구매 절차가 강한 시장, 소비자가 직접 사는 제품, 지역 기반 서비스에는 그대로 적용되지 않는다. 더 넓게 가져갈 기준은 문제를 자주 겪고, 예산이나 결정 권한이 있으며, 새 해결책을 시험할 이유가 있는 사람부터 찾는 것이다. YC의 다른 공식 강의도 첫 고객을 고를 때 문제의 현재 비용, 발생 빈도, 해결 예산을 확인하라고 설명한다. ## 창업자가 직접 팔아야 퍼널의 뜻을 안다 영상은 초기에 영업팀부터 채용하지 말라고 권한다. 창업자가 고객의 문제, 제품의 한계, 구매 반론을 직접 들어야 어떤 영업이 좋은지 판단할 수 있다는 이유다. 고객을 모르는 상태에서 영업을 외주화하면 제품이 약한지, 대상이 틀렸는지, 판매 과정이 나쁜지 구분하기 어렵다. 첫 연락은 길게 설득하는 편지보다 짧은 확인에 가깝다. 영상이 제안하는 구성은 평문 6\~8문장 안에서 상대의 문제, 제품이 하는 일, 믿을 근거, 다음 행동을 밝히는 것이다. 이 형식도 업계의 정답은 아니다. 다만 한 번에 한 사람에게 무엇을 왜 제안하는지 드러내므로 응답과 무응답을 해석하기 쉽다. ## 무료 사용자는 아직 결제 증거가 아니다 Alströmer는 첫 고객에게도 가격을 묻고 결제를 받아야 한다고 강조한다. 무료 파일럿은 거절을 늦추지만, 상대가 문제 해결에 돈을 쓸 의사가 있는지는 남기지 않는다. B2B에서는 무기한 무료 체험보다 환불 보장이나 짧은 해지권을 제시하는 방법을 권한다. 환불 보장이 모든 상품에 맞는 것은 아니다. 납품비가 큰 서비스, 규제 산업, 결과가 오래 걸리는 제품에는 다른 위험 분담 방식이 필요하다. 남는 원칙은 무료 반응과 유료 수요를 같은 숫자로 세지 않는 것이다. 가격을 제시했을 때의 결제와 거절이 퍼널의 마지막 칸을 채운다. ## 계약 뒤의 온보딩도 영업 숫자다 영상의 퍼널은 결제에서 끝나지 않는다. 초기 제품은 사용법이 매끄럽지 않으므로 창업자가 직접 온보딩하고 실제 사용까지 확인하라고 한다. 계약만 세고 사용을 놓치면 첫 달의 매출이 장기 고객으로 이어지지 않는다. 따라서 초기 장부에는 명단, 연락, 응답, 미팅, 제안, 결제와 함께 첫 사용을 적어야 한다. 각 단계의 숫자가 쌓이면 “영업이 안 된다”는 감상은 “응답 뒤 미팅 전환이 낮다”거나 “결제 뒤 사용이 시작되지 않는다”는 수정 가능한 문장으로 바뀐다. ## Zero Draft Lab의 해석 첫 매출의 역산은 매출을 예측하는 정교한 모델이 아니다. 아직 모르는 전환율을 드러내고, 다음 주에 어느 칸의 데이터를 더 모아야 하는지 정하는 작업표에 가깝다. 영상의 500건을 베끼는 대신 자기 퍼널에서 실제로 빠져나간 사람을 센다. 연락 100건 뒤 결제가 없었다면 영업 실패라고 쓸 수 없다. 누구에게 보냈고, 몇 명이 답했고, 몇 번 가격을 제시했는지 없으면 실패한 단계도 없기 때문이다. 첫 고객 목표는 “열심히 팔기”보다 \`연락 -> 응답 -> 미팅 -> 제안 -> 결제 -> 첫 사용\`의 빈칸을 하나씩 실제 숫자로 바꾸는 데서 시작한다. ## 출처와 주의점 - [Y Combinator, 「How to Get Your First Customers | Startup School」](https://www.youtube.com/watch?v=hyYCn%5FkAngI&ref=zerodraftlab.com) — 수작업 모집, 창업자 영업, 퍼널, 과금, 목표 역산의 1차 출처 - [Paul Graham, 「Do Things that Don't Scale」](https://www.paulgraham.com/ds.html?ref=zerodraftlab.com) — 초기 사용자를 직접 모집하고 수작업 경험에서 제품을 배우는 논지 - [Y Combinator, 「Startup School Week 1 Recap」](https://www.ycombinator.com/blog/startup-school-week-1-recap-kevin-hale-and-eric-migicovsky/?ref=zerodraftlab.com) — 첫 고객의 문제 비용, 발생 빈도, 예산·권한을 확인하는 보조 공식 자료 영상의 500건 연락과 단계별 전환율은 설명용 가정이다. 회사·시장별 실측 평균으로 확인되지 않았으며, 이메일 대량 발송이나 플랫폼 자동화를 허가하는 기준도 아니다. 이 글은 자막 전문을 복제하지 않고 공개 영상의 논지와 공식 자료를 대조해 재서술했다. ### 첫 100명 고객이라는 목표는 신기루다 URL: https://zerodraftlab.com/first-100-customers-myth/ Last updated: 2026-08-27T11:30:15.000Z 듀크대에서 창업을 가르치는 [아론 디닌(Aaron Dinin)](https://aarondinin.medium.com/?ref=zerodraftlab.com)이 2025년 10월 30일 Entrepreneurship Handbook에 [The Cheat Code to Getting Your First 100 Customers](https://ehandbook.com/the-cheat-code-to-getting-your-first-100-customers-d905bd866f78?ref=zerodraftlab.com)를 올렸다. 이 글은 그 원문이 공개 구간에서 말한 내용을 순서대로 풀고, 원문의 주장과 Zero Draft Lab의 해석을 나눠 적는다. 먼저 밝힐 것이 있다. 원문은 Medium 멤버 전용 글이고, 뒤쪽 절반은 로그인 없이 열리지 않는다. 이 글이 다루는 범위는 공개 구간, 즉 저자가 “치트코드는 직관에 반한다”고 예고하는 지점까지다. 치트코드의 내용 자체는 확인하지 못했다. ## 오피스아워에 온 창업자 원문은 저자의 오피스아워 장면에서 시작한다. 한 창업자가 가벼운 공황 상태로 찾아왔다. 몇 달째 스타트업을 붙잡고 있었고, 제품도 괜찮고 팀도 탄탄하고 초기 지표도 나쁘지 않았다. 그런데 돈 내는 고객이 안 붙었다. 그는 매주 다른 걸 시도했다. 소상공인에게 콜드 메일을 보냈고, 중간관리자를 겨냥해 링크드인 광고를 돌렸고, 프리랜서와 제휴를 맺었고, 비영리 단체에 연락을 돌렸다. 전부 실패했다. 저자가 이상적인 고객이 누구냐고 물었다. 창업자는 이렇게 답했다. “음... 사실 아무나 다 쓸 수 있어요.” 저자는 이것을 “아무나(anyone) 전략”이라고 부른다. 그 창업자는 조금씩 모두를 위한 제품을 만들었고, 그 결과 누구에게도 아무것도 해주지 못하는 제품이 됐다. 저자는 이것이 초기 단계에서 가장 흔한 함정이라고 적는다. 그물을 너무 넓게 던져서 아무것도 걸리지 않는 상태다. ## 저자는 “첫 100명 고객”이라는 말을 싫어한다 여기서 원문이 방향을 튼다. 저자가 고백을 하나 넣는다. 자신은 “첫 100명 고객”이라는 표현 자체를 싫어한다는 것이다. 그 표현은 스타트업 조언의 상투어다. 초기 트랙션을 줄여 부르는 말이고, “봐, 되고 있잖아”라고 말해주는 증거로 쓰인다. 그런데 저자는 실제로는 그 숫자가 일종의 신기루가 된다고 말한다. 창업자들은 100명만 채우면 *모든 것*이 맞물려 돌아가리라 생각하기 시작한다. 투자자가 줄을 서고, 매출이 눈덩이처럼 불고, 성장은 알아서 굴러갈 것이라고 믿는다. 저자의 답은 짧다. 그렇게 안 된다. ## 101번째 고객은 첫 번째만큼 어렵다 원문에서 가장 단단한 문장이 여기 나온다. 101번째 고객을 얻는 일은 1번째 고객을 얻는 일만큼 어렵다. 갑자기 모든 게 쉬워지는 마법의 임계점 같은 건 없다. 다만 저자는 그 표현을 완전히 버리지는 않는다. “첫 100명 고객”은 초점을 잡는 장치로는 쓸모가 있다고 인정한다. 고객 1,000명이나 10,000명, 100,000명까지 가고 싶다면 어쨌든 첫 100명을 얻는 방법부터 알아내야 하기 때문이다. 그리고 그 방법이 바로 저자가 말하는 치트코드인데, 저자는 그것이 직관에 반한다고 예고한다. 공개 구간은 정확히 이 문장에서 끝난다. ## 확인하지 못한 것 원문 후반, 즉 치트코드의 실제 내용은 Medium 멤버 전용 구간에 있다. 그래서 이 글은 그 답이 무엇인지 말하지 않는다. 도입부 서사와 “아무나 전략” 비판을 근거로 좁히기 전략일 것이라고 짐작할 수는 있지만, 짐작은 근거가 아니다. 저자가 직접 “직관에 반한다”고 예고한 이상, 흔한 결론일 것이라고 단정하면 틀릴 가능성이 크다. ## Zero Draft Lab의 해석 공개 구간만으로도 쓸모 있는 것이 하나 있다. 목표 숫자와 성장 곡선을 분리해서 보는 관점이다. 초기 창업자는 대개 고객 수를 계단으로 상상한다. 어느 칸에 올라서면 다음 칸은 저절로 온다고 믿는다. 저자의 반박은 그 계단이 사실은 평지라는 것이다. 101번째 고객도 같은 노동, 같은 설득, 같은 거절을 요구한다. 이 관점을 받아들이면 초기 목표의 성격이 바뀐다. 100명은 도착점이 아니라 측정 단위가 된다. 100명을 채우는 동안 어떤 채널이 몇 번 반복해서 작동했는지, 그 반복이 사람 손을 얼마나 태우는지가 실제로 알아야 할 값이다. 숫자 자체가 아니라 그 숫자를 만든 절차가 다음 100명으로 넘어간다. 반대로 “아무나” 답변이 위험한 이유도 같은 자리에서 설명된다. 대상이 없으면 반복할 절차도 안 생긴다. 콜드 메일과 링크드인 광고와 제휴를 매주 갈아 끼운 그 창업자는 시도를 100번 한 것이 아니라, 서로 다른 실험을 각각 한 번씩 한 것에 가깝다. ## 주의점 이 글은 원문의 공개 구간만 근거로 삼았다. 원문 후반의 논지가 여기 적힌 해석과 다를 수 있다. 저자 소개, 발행일, 발행 매체는 2026년 8월 27일 기준 Medium 페이지에서 확인한 값이다. 원문 전체를 읽으려면 Medium 멤버십이 필요하다. ### ProofShot은 AI 코딩 에이전트가 만든 화면을 영상으로 증명한다 URL: https://zerodraftlab.com/proofshot-bundles-agent-proof/ Last updated: 2026-08-27T08:33:51.000Z [**ProofShot**](https://github.com/AmElmo/proofshot?ref=zerodraftlab.com)은 AI 코딩 에이전트가 만든 화면을 브라우저에서 직접 확인하고, 영상·스크린샷·에러 로그를 한 폴더로 묶어 사람에게 넘기는 오픈소스 CLI다. 이 글은 저장소와 README가 설명하는 내용을 순서대로 풀고, 저장소 지표에서 확인되는 사실과 Zero Draft Lab의 해석을 나눠 적는다. 만든 사람은 GitHub 계정 `AmElmo`이고, 라이선스는 MIT다. npm 패키지 이름도 [proofshot](https://www.npmjs.com/package/proofshot?ref=zerodraftlab.com)이다. ## 문제 설정: 에이전트는 자기가 만든 화면을 못 본다 README의 출발점은 한 문장이다. AI 코딩 에이전트는 UI 기능을 눈이 가려진 채로 만든다. 코드는 쓰지만 결과 화면이 제대로 보이는지, 동작하는지, 에러가 나는지 스스로 확인하지 못한다. ProofShot은 그 고리를 닫겠다고 말한다. 실제 브라우저에서 테스트하고, 영상으로 기록하고, 에러를 모으고, 사람이 검토할 수 있게 한 묶음으로 만든다. 결과물은 로컬에서 보거나 `proofshot pr` 명령으로 GitHub PR 댓글에 올린다. 벤더 종속과 클라우드 의존이 없다는 점을 README가 명시한다. ## “Playwright MCP 쓰면 되지 않나”에 대한 답 README는 가장 많이 받는 질문을 직접 적어 뒀다. Playwright MCP나 Chrome DevTools MCP, agent-browser를 그냥 쓰면 되지 않느냐는 것이다. 저자의 답은 이렇다. 그 도구들은 브라우저를 조작한다. ProofShot은 사람이 검토할 증거 묶음을 만드는 검증 워크플로다. 비교표에서 ProofShot만 가지고 있다고 표시한 항목은 개발 서버 로그 수집, 10개 이상 언어의 에러 탐지, 타임스탬프가 붙은 액션 타임라인, 인터랙티브 HTML 뷰어, 영상과 동기화된 로그 재생, PR 댓글 업로드, 시각적 차이 비교, 에이전트 무관 스킬 설치다. 구조도 분명히 밝힌다. ProofShot은 Vercel의 [agent-browser](https://github.com/vercel-labs/agent-browser?ref=zerodraftlab.com) 위에 얹힌다. 브라우저 조작 기능은 agent-browser에서 가져오고, ProofShot은 세션 관리, 서버 로그 수집, 에러 탐지, 영상 편집, 시각 동기화, 뷰어, PR 업로드를 더한다. 선택 기준도 README가 정리해 뒀다. 개발 중 실시간 디버깅이나 DOM 검사가 필요하면 Playwright MCP나 DevTools MCP를 쓰고, 몇 초 만에 훑거나 PR에 붙일 증거 묶음이 필요하면 ProofShot을 쓰라는 것이다. ## 세 단계로 돈다: start, test, stop 설치는 두 줄이다. `npm install -g proofshot`로 CLI와 agent-browser를 설치하고, `proofshot install`로 이 컴퓨터에 있는 AI 코딩 도구를 감지해 스킬 파일을 심는다. 스킬은 프로젝트가 아니라 사용자 레벨에 설치되므로 모든 프로젝트에서 그대로 쓴다. 작업은 세 단계다. `proofshot start`가 브라우저를 열고 녹화를 시작하고 서버 로그를 붙잡는다. 그다음 에이전트가 `agent-browser` 명령으로 화면을 눌러 보고 값을 채워 넣고 스크린샷을 찍는다. 마지막에 `proofshot stop`이 영상과 스크린샷과 에러를 묶는다. README는 사람이 할 일을 한 문장으로 줄여 놓았다. 사용자는 “proofshot으로 확인해”라고 말하고, 스킬 파일이 나머지 절차를 에이전트에게 알려준다. ## 세션 하나가 남기는 것 세션마다 `./proofshot-artifacts/` 아래에 시각이 찍힌 폴더가 생긴다. 안에는 전체 세션 영상 `session.webm`, 스크럽 바와 타임라인과 로그 탭을 가진 단독 실행 뷰어 `viewer.html`, 에러와 스크린샷과 영상을 정리한 `SUMMARY.md`, 순간별 스크린샷 `step-*.png`, 타임스탬프와 요소 정보가 담긴 `session-log.json`, 개발 서버 출력 `server.log`, 브라우저 콘솔 출력 `console-output.log`가 들어간다. 뷰어에는 콘솔 로그 탭과 서버 로그 탭이 있고, 에러가 강조되며, 시각이 영상과 맞춰진다. 영상의 특정 지점에서 어떤 로그가 찍혔는지 그 자리에서 본다는 뜻이다. ## 나머지 명령 `proofshot exec`는 agent-browser로 넘기는 통로인데, 실행하면서 시각과 요소 정보를 자동으로 기록하고 스크린샷 경로를 정리한다. 세션이 살아 있는 동안에는 `start`가 만든 같은 브라우저 세션을 재사용한다. `proofshot diff --baseline`은 지금 스크린샷을 이전 산출물과 비교한다. `proofshot pr`은 현재 브랜치에서 기록된 세션을 찾아 스크린샷과 영상을 올리고 PR에 댓글을 남긴다. 기본 방식은 공식 GitHub 저장소 콘텐츠 API를 써서 `proofshot-artifacts` 브랜치에 올리는 것이고, 일반적인 `gh` 인증이나 `GH_TOKEN`으로 동작한다. 인라인 첨부를 쓰는 `github-web-attachments` 방식도 남아 있지만 GitHub 내부 업로드 엔드포인트에 의존하고 브라우저로 로그인한 OAuth 세션은 거부될 수 있다고 README가 미리 적어 뒀다. `ffmpeg`가 있으면 `.webm`을 `.mp4`로 바꾼다. `proofshot clean`은 산출물 폴더를 지우고, `proofshot doctor`는 설정 경로, 브라우저 모드, 뷰포트, 설치된 실행 파일, 진행 중인 세션을 출력한다. ## 지원 도구와 에러 탐지 범위 `proofshot install`이 감지하는 도구는 여섯 개다. Claude Code는 `~/.claude/skills/proofshot/SKILL.md`, Cursor는 `~/.cursor/rules/proofshot.mdc`, Codex는 `~/.codex/skills/proofshot/SKILL.md`, OpenCode는 `~/.config/opencode/skills/proofshot/SKILL.md`에 설치한다. Gemini CLI와 Windsurf는 파일을 새로 만들지 않고 기존 규칙 파일에 내용을 덧붙인다. 서버 로그의 에러 탐지는 JavaScript와 Node.js, Python, Ruby와 Rails, Go, Java와 Kotlin, Rust, PHP, C#과 .NET, Elixir와 Phoenix를 포함해 10개 이상 언어를 다룬다. 새 언어 패턴은 `src/utils/error-patterns.ts`에 추가하게 되어 있다. 저장소에는 SaaS 대시보드, 칸반 보드, 채팅 화면 세 가지 샘플 앱이 들어 있어서 자기 프로젝트 없이도 시험해 볼 수 있다. ## 저장소 지표에서 확인되는 사실 2026년 8월 27일 기준으로 GitHub API가 돌려주는 값은 다음과 같다. 별 853개, 포크 50개, 열린 이슈 7개, 라이선스 MIT다. 저장소는 2026년 2월 27일에 생겼다. 같은 시점 npm 통계에서 최근 30일 내려받기는 3,891회, 최근 7일은 686회다. 최신 버전은 1.6.0이고 지금까지 올라온 버전은 13개다. 다만 마지막 커밋과 마지막 릴리스가 모두 2026년 4월 14일이다. 넉 달 넘게 새 커밋이 없다는 뜻이다. 이 수치들은 조회 시점의 값이며, 도입을 정할 때는 직접 다시 확인해야 한다. ## Zero Draft Lab의 해석 여기부터는 원문의 주장이 아니라 이 글의 판단이다. ProofShot이 건드리는 것은 에이전트의 능력이 아니라 사람의 검토 비용이다. 에이전트에게 일을 더 맡기지 못하는 이유는 대개 실력이 아니라 확인이다. 화면 작업은 결과를 눈으로 봐야 믿을 수 있는데, 그 확인을 사람이 매번 직접 하면 위임한 만큼 시간을 돌려받지 못한다. 영상과 로그가 한 폴더로 나오면 확인은 몇 초짜리 훑기로 줄어든다. PR에 붙는다는 점이 특히 크다. 증거가 로컬 폴더에 있으면 만든 사람만 보지만, PR 댓글에 붙으면 리뷰어와 나중에 그 커밋을 여는 사람까지 같은 증거를 본다. 확인 기록이 개인의 기억에서 저장소의 기록으로 옮겨간다. 동시에 넉 달째 조용한 저장소라는 사실을 그대로 둔 채 판단해야 한다. 별 853개와 월 3,891회 내려받기는 관심과 사용을 보여주지만 유지보수 약속은 아니다. MIT 라이선스라 직접 고쳐 쓸 수는 있고, 실제로 이 도구는 agent-browser 위의 얇은 층이므로 아래층이 바뀌면 영향을 받는다. 팀 표준으로 넣기 전에 저장소 활동과 의존 관계를 한 번 더 보는 편이 안전하다. ### X에서 파는 사람들의 20가지 손기술 URL: https://zerodraftlab.com/x-sales-tactics-playbook/ Last updated: 2026-09-15T08:34:42.000Z X에서 디지털 상품을 파는 사람들을 오래 보다 보면 이상한 단어가 자꾸 눈에 걸린다. **AI**, **90**, **Claude**, **GRACEGONGCEO**. 어떤 것은 댓글에 쓰라고 하고, 어떤 것은 결제창에 넣으라고 한다. 전부 코드처럼 보이지만 하는 일은 다르다. 댓글의 **AI**는 관심자를 가려내고, 결제창의 **GRACEGONGCEO**는 가격과 유입 경로를 바꾼다. **HYPEX** 같은 크리에이터 코드는 할인 없이 추천인에게 수수료를 돌려주기도 한다. 영미권 X 판매자들이 잘하는 것은 멋진 글 한 편으로 낯선 사람을 설득하는 일이 아니다. 결제까지 필요한 작은 동의를 잘게 나누는 일이다. 댓글 한 단어, 무료 파일 한 장, 환불 가능한 첫 결제처럼 거절하기 쉬운 요청부터 건넨다. 그 장치를 스무 개의 손기술로 정리했다. 매출 수치는 판매자가 직접 주장한 경우가 많다. 그래서 조회수와 댓글 수를 매출 증거로 취급하지 않았고, 확인할 수 있는 판매 구조만 가져왔다. ## 1\. 키워드를 팔지 말고 손든 사람을 모아라 “AI라고 댓글 달면 보내드립니다.” 여기서 **AI**는 비밀번호가 아니다. 관심자 표시다. [Yara](https://x.com/AI%5Fcreator%5FYara/status/2027724862983442928?ref=zerodraftlab.com)는 n8n 워크플로를 원하는 사람에게 AI라는 댓글을 받았고, [Easytools](https://x.com/easytoolshq/status/2034581038479917441?ref=zerodraftlab.com)는 콘텐츠 파일을 원하는 사람에게 90이라고 쓰게 했다. 좋아요는 예의로 누를 수 있다. 특정 자료를 달라는 댓글은 필요를 드러낸다. 판매자는 이 차이를 이용해 불특정 조회자를 후속 연락이 가능한 사람으로 바꾼다. 단, 파일만 보내고 끝나면 무료 배포다. 키워드 뒤에는 같은 문제를 더 깊이 해결하는 상품이 있어야 한다. > 댓글 AI → 무료 워크플로 → 전체 템플릿 미리보기 → 완성판 결제 ## 2\. 자동 DM보다 먼저 DM할 이유를 만들어라 댓글을 달았다는 이유만으로 광고 메시지를 쏘면 관계가 바로 빚이 된다. 더 나은 문장은 “원하면 GUIDE라고 DM 주세요”다. 사용자가 먼저 대화를 열기 때문에 전달 실패도 줄고 의사도 더 선명하다. [Daniel Priestley](https://x.com/DanielPriestley/status/2032819133763489842?ref=zerodraftlab.com)는 긴 문제 제기 뒤에 무료 영상과 워크숍을 놓는다. 핵심은 공짜라는 말이 아니다. 글을 읽고 더 알고 싶은 사람에게 다음 행동을 한 칸만 보여주는 것이다. X는 대량 자동 DM과 참여 조작을 제한한다. 댓글 수를 부풀리려고 팔로우, 리포스트, 댓글을 한꺼번에 강제하면 판매 기술이 아니라 계정 위험이 된다. ## 3\. 견본은 설명보다 먼저 일하게 하라 코드 상품이라면 함수 하나, 템플릿이라면 한 장, 강의라면 첫 모듈을 꺼낸다. “좋습니다”라는 문장보다 실제 파일이 품질을 더 빨리 증명한다. [CSS Studio](https://cssstudio.ai/pricing?ref=zerodraftlab.com)는 무료 편집기를 남겨두고 AI 기능과 업데이트가 들어간 버전을 일회성 가격으로 판다. 무료판은 자선이 아니다. 구매자가 설명을 읽지 않고도 제품의 손맛을 확인하는 판매 지면이다. 좋은 견본은 유료 상품과 같은 문제를 푼다. 이메일 강의를 팔면서 무관한 프롬프트 모음을 뿌리면 리드는 늘어도 구매자는 늘지 않는다. ## 4\. 무료 자료에 다음 문제를 심어라 무료 자료가 모든 일을 끝내면 감사 인사만 남는다. 반대로 아무것도 해결하지 못하면 미끼로 보인다. 한 문제를 제대로 해결한 뒤, 해결 과정에서 생기는 다음 문제를 유료 상품이 맡아야 한다. [Corey Ganim](https://x.com/coreyganim/status/2033889336215658685?ref=zerodraftlab.com)은 AI 회사를 만드는 긴 튜토리얼을 공개하고, 혼자 실행하기 어려운 독자를 Build With AI 대기자 명단으로 보낸다. 무료 글은 문제를 숨기지 않는다. 대신 실행 속도와 함께할 사람을 유료 가치로 남긴다. ## 5\. 제품보다 할인받을 권리를 먼저 팔아라 [Motion](https://x.com/motiondotdev/status/2036865457408426261?ref=zerodraftlab.com)은 CSS Studio 출시 전에 뉴스레터 구독자에게 20% 할인을 예고했다. 아직 살 수 없는 제품을 억지로 예약 판매하지 않았다. 가장 싸게 살 권리를 미리 배포했다. 출시 할인은 가격을 깎는 장치이면서 수요를 세는 장치다. 구독자가 적으면 오퍼나 유통이 약한 것이고, 구독자는 많지만 결제가 없으면 제품이나 가격을 다시 봐야 한다. “곧 가격이 오릅니다”보다 “출시일까지 구독하면 20% 코드가 갑니다”가 강하다. 고객이 무엇을 해야 하는지 보이고, 판매자는 어느 단계에서 이탈했는지 읽을 수 있다. ## 6\. 할인 코드마다 주인을 붙여라 [Grace Gong](https://x.com/gracegongGG/status/2040224448561676725?ref=zerodraftlab.com)은 AI 행사 홍보에 자신의 이름이 들어간 50% 코드를 썼다. [HumanX 홍보 사례](https://x.com/LToomre/status/2031769742269157728?ref=zerodraftlab.com)에서는 추천인별 코드로 100달러를 할인했다. 같은 할인을 모두에게 뿌리면 매출만 보인다. 사람마다 다른 코드를 주면 누가 매출을 데려왔는지 보인다. 작은 판매자는 복잡한 제휴 시스템을 만들기 전에 Stripe 프로모션 코드만으로 이 구조를 시험할 수 있다. 할인의 목적은 싸 보이는 일이 아니다. 망설일 이유 하나를 없애고, 어느 유통 경로가 일했는지 기록하는 일이다. ## 7\. 할인하지 않는 크리에이터 코드를 만들어라 [HYPEX](https://x.com/HYPEX/status/2002167320005771545?ref=zerodraftlab.com)는 구매자가 자신을 지원하고 싶다면 크리에이터 코드를 써달라고 말한다. 소비자 가격을 깎는다는 약속은 없다. 구매 이유를 “싸게 산다”에서 “내가 보는 사람을 후원한다”로 바꾼다. 이 코드는 추천인의 신뢰를 빌리고, 판매 수수료를 나누며, 누가 실제 구매자를 데려오는지 측정한다. 팔로워가 많은 사람보다 구매 코드가 반복해서 쓰이는 사람이 더 좋은 파트너다. ## 8\. 가짜 마감 대신 시스템이 닫히게 하라 “24시간 뒤 삭제”는 너무 많이 쓰여서 이제 문장만으로는 믿기 어렵다. 정말 끝낼 생각이라면 결제 시스템도 함께 닫혀야 한다. Stripe Payment Links는 결제 완료 횟수를 제한하고, 한도에 도달하면 링크를 비활성화할 수 있다. 프로모션 코드에도 만료일과 최대 사용 횟수를 붙일 수 있다. 판매자가 잠든 뒤에도 마감이 지켜진다. 마감을 계속 연장할 예정이라면 처음부터 마감이라 부르지 않는 편이 낫다. “초기 구매자 50명에게만 이 가격”처럼 실제 운영 조건을 쓰면 된다. ## 9\. 가격을 월이 아니라 작업 단위로 번역하라 [Ridges](https://x.com/JosephJacks%5F/status/2029614924725719262?ref=zerodraftlab.com)는 월 29달러보다 PR 한 건당 0.29달러라는 숫자를 앞세웠다. 고객은 AI 코딩 도구의 월 구독료보다 자신이 처리할 작업 수를 더 쉽게 비교한다. 템플릿은 완성 문서 한 건, 이미지 도구는 생성 한 장, 리서치 제품은 조사 한 건으로 번역할 수 있다. 단위 가격은 총액을 숨기는 기술이 아니다. 고객의 실제 사용량으로 가격을 읽게 하는 기술이다. ## 10\. 작은 제품에는 구독을 강요하지 마라 [Marc Lou](https://x.com/marc%5Flouvion/status/1846481970274168929?ref=zerodraftlab.com)는 자신의 여러 제품에서 낮은 구독료보다 일회성 가격과 크레딧이 더 잘 팔렸다고 주장했다. 공개된 감사 자료는 없지만, 구매 방식과 제품 사용 주기가 맞아야 한다는 문제는 남는다. 매달 새 가치를 주지 않는 템플릿, 작은 유틸리티, 짧은 가이드에 구독을 붙이면 고객은 제품보다 해지를 먼저 생각한다. 일회성 가격은 반복 매출을 포기하는 선택이 아니라 구매 저항을 없애는 선택이 될 수 있다. ## 11\. 무료판을 없애는 실험도 해보라 무료판은 항상 선한 성장 장치가 아니다. 지원 비용이 크고 유료 전환이 거의 없다면 구경꾼을 오래 붙잡는 장치가 된다. [Pieter Levels](https://x.com/levelsio/status/1752075138919473349?ref=zerodraftlab.com)와 [Ernesto Lopez](https://x.com/ErnestoSOFTWARE/status/2036069922753634677?ref=zerodraftlab.com)는 hard paywall 뒤에서 매출이 늘었다고 주장한다. 둘 다 판매자 자가 보고라 숫자를 그대로 믿을 수는 없다. 다만 무료 가입 이벤트가 아니라 구매 이벤트를 최적화해야 한다는 판단은 시험할 수 있다. 무료판을 지우기 전에 무료 사용자가 유료 고객보다 어떤 비용을 더 만드는지 봐야 한다. 지원 문의, 연산 비용, 저장 공간, 스팸을 측정하지 않으면 유료벽은 전략이 아니라 성급한 문 닫기가 된다. ## 12\. 가격을 모르면 고객에게 빈칸을 줘라 [Shane Levine](https://x.com/theShaneLevine/status/1909668571774591147?ref=zerodraftlab.com)은 iOS 프로토타입을 Gumroad의 원하는 만큼 결제로 내놓았다. 대부분은 무료로 받았지만 일부는 5달러, 10달러, 한 사람은 50달러를 냈다고 공개했다. 원하는 만큼 결제는 수익 모델이라기보다 가격 탐색 장치다. 다운로드 수와 결제자 수, 지불액 분포를 함께 볼 수 있다. 무료 다운로드가 많다는 사실만으로 상품성이 증명되지는 않는다. 결제자가 생겼다면 그들이 왜 냈는지 묻는다. 응원인지, 시간 절약인지, 상업적 이용권인지에 따라 다음 고정 가격이 달라진다. ## 13\. 개인 상품을 팀 묶음으로 다시 팔아라 개인이 99달러에 사는 제품을 다섯 명이 각각 결제하게 만들 필요는 없다. [CSS Studio](https://cssstudio.ai/pricing?ref=zerodraftlab.com)처럼 팀 좌석을 하나의 상품으로 묶으면 구매자가 비용을 설명하기 쉬워진다. 팀 가격의 가치는 단순 할인에 있지 않다. 영수증 하나, 라이선스 관리 하나, 공통 업데이트라는 관리 비용 감소에 있다. 팀 기능이 없더라도 좌석 수와 이용 범위를 명확히 적으면 첫 B2B 패키지를 만들 수 있다. ## 14\. 월간 구매자에게 연간 절약액을 보여줘라 연간 결제는 “두 달 무료”보다 “내가 이 제품을 1년 쓸 것인가”라는 판단을 요구한다. 그래서 월간 가격 옆에 연간 총액만 붙이면 잘 움직이지 않는다. 먼저 월간을 고른 사람에게 연간 전환 시 절약액과 유지되는 권리를 보여준다. Stripe Payment Links는 월간 구독을 선택한 고객에게 연간 플랜을 상향 제안할 수 있다. 이미 구매 의사를 밝힌 순간에만 한 번 묻는 것이 핵심이다. ## 15\. 본 상품 옆에 다음 일을 놓아라 프롬프트 모음을 산 사람에게 또 다른 프롬프트 모음을 보여주면 메뉴만 길어진다. 첫 상품으로 끝낸 뒤 바로 생기는 일을 붙여야 한다. 예를 들어 랜딩페이지 템플릿 옆에는 카피 체크리스트가 맞고, AI 이미지 워크플로 옆에는 상업 이용 라이선스나 편집 프리셋이 맞다. Stripe Payment Links에서는 최대 10개의 선택 상품을 추가할 수 있다. 주문 범프의 질문은 “무엇을 더 팔까”가 아니다. “방금 산 것을 쓰려면 고객이 다음에 무엇을 해야 하나”다. ## 16\. 코드가 무료면 설치와 운영을 팔아라 [Core](https://x.com/blakeandersonw/status/2038276867464061056?ref=zerodraftlab.com)는 Apache 2.0으로 코드를 공개하고 호스팅 버전을 알렸다. 오픈소스가 유료 상품의 반대편에 있는 것은 아니다. 코드는 배포를 맡고, 호스팅은 설치·업데이트·백업·팀 권한을 맡는다. “코드를 드립니다”는 개발 상품에서 강한 견본이 된다. 다만 저장소 별표와 실제 호스팅 결제를 분리해서 봐야 한다. 무료 코드는 관심을 증명할 뿐 운영에 돈을 낼 사람까지 증명하지 않는다. ## 17\. 구매자보다 판매자를 먼저 모아라 [Action Model](https://x.com/ActionModelAI/status/2024167670229455161?ref=zerodraftlab.com)은 워크플로 제작자에게 “누군가 사용할 때마다 돈을 번다”고 제안했다. 마켓플레이스가 텅 비었을 때 구매자에게 선택지를 광고하기보다 공급자에게 수익 가능성을 판 것이다. 이 기술은 템플릿 마켓, 프롬프트 마켓, 에이전트 워크플로 마켓에 맞는다. 초기에는 판매 수수료보다 첫 제작자가 실제로 얼마를 벌었는지 보여주는 편이 중요하다. 공급자 수만 늘고 구매가 없으면 마켓이 아니라 파일 창고다. ## 18\. 광고비를 먼저 쓰지 말고 판매 뒤에 나눠라 제휴 판매는 크리에이터에게 게시물 제작비를 먼저 지급하지 않는다. 추적 링크나 코드에서 판매가 발생한 뒤 수수료를 나눈다. [Affiliate Network 사례](https://x.com/johnvirality/status/2036444247486853261?ref=zerodraftlab.com)는 AI UGC 제휴 캠페인에서 큰 귀속 매출을 주장한다. 독립 감사 자료가 없으므로 숫자는 증거가 아니다. 여기서 가져올 것은 성과가 난 유통에만 비용을 붙이는 계약 구조다. 제휴 매출도 증분 매출과 같지 않다. 원래 살 고객이 코드를 썼을 수 있다. 코드별 매출뿐 아니라 신규 고객 비중, 환불, 할인과 수수료를 뺀 기여이익을 함께 봐야 한다. ## 19\. 보너스를 쌓기 전에 본 상품을 한 문장으로 말하라 [Julian Goldie](https://x.com/JulianGoldieSEO/status/2038737425598652575?ref=zerodraftlab.com)의 멤버십 판매 글에는 마감, 가격 잠금, 연간 할인, 수많은 보너스와 거대한 가치 합계가 한꺼번에 들어간다. 반응 장치를 배우기에는 좋은 표본이지만 그대로 베끼면 상품보다 계산표가 더 커진다. 보너스는 구매자가 본 상품을 쓰다가 만나는 장애물만 제거해야 한다. 강의를 사면 필요한 템플릿과 예시는 보너스가 된다. 무관한 전자책 열 권은 가치가 아니라 정리할 짐이다. 합산 가치가 실제 판매 가격도, 고객이 지불한 가격도 아니라면 앵커가 아니라 꾸며낸 숫자다. ## 20\. 수익 인증을 판매 기술로 착각하지 마라 [Himanshu Kumar](https://x.com/codewithimanshu/status/2036973891768508814?ref=zerodraftlab.com)는 잠든 사이 4만3,800달러를 벌었다고 주장하며 24시간 무료 가이드를 배포했다. [비슷한 게시물](https://x.com/ai%5Funcovered/status/2039341426136535200?ref=zerodraftlab.com)도 72시간 수익 숫자와 댓글 키워드를 결합했다. 이 형식은 잘 퍼진다. 큰 숫자가 욕망을 만들고, 24시간이 조급함을 만들고, 댓글 조건이 노출을 늘린다. 그러나 판매 화면, 환불, 비용, 기간별 결제가 없으면 남는 것은 판매자의 주장뿐이다. 좋은 사례 연구는 조회수에서 멈추지 않는다. 게시물에서 어떤 오퍼로 이동했는지, 실제 가격이 무엇인지, 결제 표면이 살아 있는지, 숫자가 총매출인지 순매출인지 구분한다. 이 네 가지가 없으면 “돈 버는 법”을 파는 게시물이 돈을 벌었을 가능성만 남는다. ## 스무 기술을 한 줄로 잇는 법 이 기술을 전부 한 상품에 붙일 필요는 없다. 첫 판매에는 다섯 칸이면 충분하다. > 쓸 만한 견본 → 키워드나 DM으로 손들기 → 추적 가능한 오퍼 → 위험을 낮춘 결제 → 바로 생기는 다음 일 Stripe를 이미 갖고 있다면 새 판매 시스템부터 만들 이유도 없다. Payment Link 하나에 프로모션 코드, 만료일, 최대 사용 횟수, UTM, 환불 조건을 넣는다. 첫 구매가 생긴 뒤에만 연간 플랜이나 관련 상품을 붙인다. 측정할 숫자는 조회수가 아니다. 손든 사람 중 몇 명이 자료를 받았는지, 받은 사람 중 몇 명이 상품 페이지를 열었는지, 그중 몇 명이 결제했고 환불했는지를 본다. 어느 칸이 비는지 알면 다음에 고칠 문장도 하나로 좁아진다. **X에서 파는 사람들은 콘텐츠를 곧장 돈으로 바꾸지 않는다. 거절하기 쉬운 작은 동의를 다음 동의로 연결한다. 손기술의 이름은 달라도 돈은 그 연결부에서 생긴다.** --- 주요 출처: 위에 연결한 각 판매자의 X 게시물과 제품 페이지; Stripe, [Payment Links 프로모션](https://docs.stripe.com/payment-links/promotions?ref=zerodraftlab.com), [Payment Links 맞춤 설정](https://docs.stripe.com/payment-links/customize?ref=zerodraftlab.com), [쿠폰과 프로모션 코드](https://docs.stripe.com/billing/subscriptions/coupons?ref=zerodraftlab.com); X, [Developer Guidelines](https://docs.x.com/developer-guidelines?ref=zerodraftlab.com). 판매자가 밝힌 매출과 성과는 독립적으로 감사된 자료가 아니며, 해당 문단에서 자가 주장으로 구분했습니다. ### 바이브코딩 금광에서 팔 것은 입장권이 아니다 URL: https://zerodraftlab.com/open-core-sells-pickaxes/ Last updated: 2026-09-15T08:34:43.000Z 바이브코딩으로 돈 벌고 싶다는 사람이 많다. 이 문장을 사업 기회로 읽으면 길은 둘이다. 같이 금을 캐거나, 광부에게 곡괭이를 팔거나. 금을 캐는 쪽은 이미 붐빈다. 프롬프트를 넣으면 앱이 나오는 자리에는 Lovable과 레플릿과 볼트가 앉아 있다. 코드를 함께 짜는 자리에는 커서가 있다. 지금 이 층에 들어가면 결국 입장권을 조금 더 싸게 파는 싸움이다. 그것도 사업이지만, 여기서 볼 자리는 아니다. 곡괭이는 다르다. 금광이 열려도 대부분의 광부는 금을 못 캔다. 주말에 앱 하나 만들고 끝나는 경우가 더 많다. 그래도 곡괭이는 팔린다. 광부가 망하기 전에 삽부터 사기 때문이다. 이 광부는 예전 개발자와 다르다. 보안팀도 조달 부서도 없고 SAML을 찾지도 않는다. 클로드 코드나 커서에 레포를 물리고, API 키가 붙으면 됐다고 본다. 지갑을 여는 순간도 다르다. 앱을 계속 살려야 하거나 무료 한도에 걸릴 때다. 오픈코어가 이 층에 맞는 이유다. 제품은 깃헙에 있고, 혼자 설치해 실제로 써볼 수 있어야 한다. 데모만으로는 입소문이 나지 않는다. 고전적인 오픈코어는 무료 코어 위에 SSO와 감사 로그를 얹어 돈을 받았다. [깃랩](https://handbook.gitlab.com/handbook/company/stewardship/?ref=zerodraftlab.com)이 그렇게 공개 회사가 됐다. 바이브코더에게 유료 층은 기업용 부가기능보다 호스팅에 가깝다. 기능은 무료여도, 계속 돌아가게 만드는 운영에는 돈을 낸다. 이미 이 자리를 차지한 곡괭이도 있다. [수파베이스는 2026년 6월](https://supabase.com/blog/series-f?ref=zerodraftlab.com), 신규 데이터베이스의 60퍼센트 이상을 AI 도구가 만들고 그중 클로드 코드의 비중이 가장 크다고 밝혔다. 데이터베이스 생성량은 전년보다 여섯 배 늘었다. 열린 제품이 README와 MCP만으로 에이전트의 손에 들어가면, 그 제품이 기본 곡괭이가 된다. 모델은 간단하다. 금을 캐거나 금광 입장권을 팔지 않는다. 제품을 깃헙에 두고, 광부가 살아남아 무료 한도를 넘을 때 계산서를 보낸다. 이 계산이 성립하려면 부가기능보다 호스팅이 매출의 중심이어야 한다. 실제로 상장한 오픈코어 회사들의 매출은 이미 그쪽으로 기울었다. 몽고DB FY26 매출 24.6억 달러 중 아틀라스가 18.1억 달러다. 엘라스틱 FY26 매출 17.4억 달러 중 클라우드가 8.37억 달러다. 컨플루언트도 클라우드가 구독 매출의 절반이다. 시트와 SSO보다 셀프호스트가 입소문을 만들고, 매니지드 서비스가 매출을 만드는 그림에 가깝다. 그러니 깃헙 별 수에 2퍼센트를 곱해 유료 고객을 역산하면 안 된다. 깃랩도 S-1에서 유료 전환율을 모른다고 적었다. 봐야 할 숫자는 첫 성공 호출까지 걸린 시간, 실제 쿼리가 생긴 프로젝트, 무료 한도를 넘긴 프로젝트다. ## 라이선스를 조이면 포크가 난다 제품을 깃헙에 두면 다른 클라우드도 그 제품을 호스팅할 수 있다. 엘라스틱이 SSPL로 바꾼 뒤 오픈서치가 나왔고, 레디스에는 발키, 하시코프에는 오픈토푸가 나왔다. 라이선스를 바꿔도 클라우드를 멈추지는 못한다. 대신 커뮤니티가 갈라진다. 그라파나의 AGPL은 오픈소스라는 이름을 지키면서, 같은 제품을 서비스로 파는 쪽을 불편하게 하는 중간값이다. ## 이 모델이 깨지는 자리 가치 전부가 코어 한 덩어리에 들어가면 커뮤니티 에디션이 곧 제품의 전부가 된다. 그때 오픈코어는 공짜 파일로 끝난다. 셀프호스트 운영이 너무 쉬워도 클라우드는 팔리지 않는다. 인증이나 CRUD처럼 에이전트가 주말에 복제할 수 있는 층도 곡괭이가 되지 않는다. 남는 것은 돌리기 괴로운 것, 혹은 이미 쌓인 인덱스와 데이터처럼 복제에 시간이 드는 것이다. 그래서 해자는 플러그에 두면 안 된다. MCP는 키만 바꾸면 남의 공장에 꽂힌다. 바꾸기 어려운 것은 이미 차지한 기본값, 쌓인 상태, 운영이다. 수파베이스가 지금 앉아 있는 자리가 그렇다. 바이브코딩 금광에서 팔 것은 앱 제작 입장권이 아니다. 광부가 앱을 계속 돌릴 때 한 줄로 붙는 도구를 깃헙에 두고, 그 도구를 대신 운영한 대가를 받는 일이다. ### 퇴사는 사업 검증이 아니라 runway 결정이다 URL: https://zerodraftlab.com/quitting-is-a-runway-decision/ Last updated: 2026-09-15T08:34:44.000Z 퇴사는 사업 아이디어가 검증됐다는 증거가 아니다. 월급이 끊긴 뒤 생활비와 사업비를 감당하면서 고객 검증을 계속할 수 있는 기간을 사는 자본 배분 결정이다. Edmund Yong은 [퇴사 직후 첫 기록](https://www.youtube.com/watch?v=-oHnkJD1nDE&ref=zerodraftlab.com), [퇴사 이유를 정리한 영상](https://www.youtube.com/watch?v=qMTKz4Wa%5FHI&ref=zerodraftlab.com), [6개월 뒤 1인 창업의 장점](https://www.youtube.com/watch?v=I2aKS-1oUnc&ref=zerodraftlab.com)에서 자율성, 소유감, 빠른 학습, 장소의 자유를 말한다. ## 퇴사 이유와 퇴사 조건은 다른 문서다 일의 의미가 줄고, 기여를 인정받지 못하며, 결정권이 부족하다는 감정은 변화가 필요한 이유가 될 수 있다. 그러나 그 이유만으로 현재 사업이 생활비를 낼 수 있다는 결론은 나오지 않는다. 직장을 떠나고 싶은 이유와 사업을 계속할 수 있는 조건을 분리해야 한다. Yong은 첫 영상에서 재무적으로 가장 현명한 결정은 아니었을 수 있다고 말한다. 공개된 영상만으로 당시 저축, 월 지출, 보험, 세금, 가족 책임을 알 수 없다. 결과가 좋았다는 이후 서사가 출발 시점의 위험을 소급해 없애지는 않는다. ## runway는 달력의 숫자보다 비용 구조다 [미국 SBA의 startup cost 안내](https://www.sba.gov/business-guide/plan-your-business/calculate-your-startup-costs?ref=zerodraftlab.com)는 일회성 비용과 월별 비용을 나누고, 사업 유형에 맞는 비용을 계산해 손익분기 시점을 추정하라고 한다. 개인 생활비가 함께 걸린 1인 사업은 사업 고정비, 변동비, 생활비, 예상 세금, 비상자금을 따로 봐야 한다. runway가 12개월이라는 말도 매달 같은 속도로 돈이 줄 때만 맞다. 매출이 늘거나 AI 사용료·광고비가 커지면 달라진다. 따라서 보유 현금만 적지 말고 매달 실제 순유출과 다음 점검일, 중단 기준을 함께 기록해야 한다. 이 기준을 적으면 직장을 유지하는 시간이 사업을 미루는 시간인지, 더 싼 조건에서 검증을 계속할 자본인지도 구분할 수 있다. 퇴사 여부보다 먼저 봐야 할 것은 현재 고용이 어떤 실험을 가능하게 하고 어떤 병목을 만들고 있는지다. ## 직장은 대안이 아니라 실험 자금이 될 수 있다 영상은 9-to-5와 1인 창업을 대조하지만 두 길 사이에는 side project, freelancing, 근무시간 조정, 고객 인터뷰 같은 단계가 있다. 월급을 받으면서 첫 결제와 반복 사용을 확인하면 사업의 협상력이 커진다. 고용 상태에서 얻은 자본과 기술도 창업 자산이다. 반대로 고객 지원과 제품 장애가 이미 본업과 함께 감당하기 어려운 수준이고, 반복 매출과 획득 경로가 보이며, 충분한 runway가 있다면 퇴사가 성장 제약을 푸는 선택이 될 수 있다. 판단 근거는 불만의 강도가 아니라 시간을 더 투입했을 때 닫힐 구체적 병목이다. ## 자유는 일정이 사라지는 것이 아니라 책임이 모이는 것이다 Yong은 한 사람이 디자인, 개발, 마케팅, 고객지원을 맡으면서 의사결정과 피드백이 빨라졌다고 말한다. 동시에 승리와 장애가 모두 자신에게 돌아온다고 인정한다. 위치의 자유는 고객 대응, 건강, 회계, 장애 복구를 대신해 주지 않는다. 퇴사를 검토할 때 필요한 문장은 “더는 회사가 싫다” 다음에 온다. 어떤 고객 고통이 확인됐는가. 현재 수작업 해결은 무엇인가. 첫 유료 검증은 어디서 나오는가. 월별 비용과 runway는 얼마인가. 어느 날짜에 어떤 숫자가 없으면 전략을 바꾸거나 재취업할 것인가. 퇴사는 용기의 시험도 실패의 반대말도 아니다. 사업이 아직 틀릴 수 있다는 사실을 받아들이고, 틀렸을 때 회복 가능한 범위 안에서 시간을 사는 결정이다. ## 퇴사 판단은 낙관 시나리오보다 복귀 조건에서 선명해진다 매출이 계획보다 늦고 비용이 예상보다 커졌을 때 무엇을 줄이고 언제 소득원을 다시 만들지 정해 두면, runway는 마지막 날까지 버티는 카운트다운이 아니게 된다. 재취업이나 freelancing을 실패 선언으로 두지 않고 회복 경로로 포함해야 실험이 틀렸을 때도 자본과 건강을 지킬 수 있다. 반대로 중단 조건이 없으면 보유 현금이 줄수록 이미 쓴 시간 때문에 더 큰 위험을 감수하기 쉽다. 다음 점검일과 최소 매출, 고객 증거, 최대 월 순유출을 미리 적는 이유는 미래를 정확히 예측하기 위해서가 아니다. 불리한 현실이 왔을 때 출발 당시의 판단 기준을 협상하지 않기 위해서다. --- 주요 출처는 Edmund Yong의 [Life as a Solo Startup Founder](https://www.youtube.com/watch?v=-oHnkJD1nDE&ref=zerodraftlab.com), [Why I Quit My 9-5](https://www.youtube.com/watch?v=qMTKz4Wa%5FHI&ref=zerodraftlab.com), [Why I Love Being a Solo Startup Founder](https://www.youtube.com/watch?v=I2aKS-1oUnc&ref=zerodraftlab.com)입니다. 퇴사 이유와 이후 경험은 제작자의 개인 서사이며 재무 상태나 성공 확률을 검증하지 않습니다. 비용 분류와 손익분기 준비는 [U.S. Small Business Administration 공식 안내](https://www.sba.gov/business-guide/plan-your-business/calculate-your-startup-costs?ref=zerodraftlab.com)를 참고했습니다. 본문은 개인 재무·세무 자문이 아닙니다. ### 코딩과 마케팅의 순서는 증거가 정한다 URL: https://zerodraftlab.com/evidence-decides-code-or-market/ Last updated: 2026-09-15T08:34:45.000Z 코딩과 마케팅 중 무엇을 먼저 할지는 직업 취향으로 정할 문제가 아니다. 지금 가장 값싸게 닫을 수 있는 불확실성이 제품인가, 수요인가에 따라 순서가 바뀐다. Edmund Yong은 [코딩과 마케팅의 순서를 다룬 영상](https://www.youtube.com/watch?v=0LE0trd740Q&ref=zerodraftlab.com)에서 경쟁 제품이 없고 공개된 요청이 분명할 때는 먼저 만들었으며, 대부분의 아이디어는 랜딩페이지와 잠재고객 대화로 먼저 확인하는 편이 낫다고 말한다. ## 만들기 먼저가 맞는 경우에도 증거가 필요하다 그가 폴더 확장을 먼저 만든 근거는 ChatGPT 사용자 포럼과 커뮤니티의 반복 요청이었다. 구현이 작고, 창업자 자신도 같은 문제를 겪었고, 사용자가 결과를 바로 평가할 수 있었다. “독창적이어서”가 아니라 빠른 빌드가 가장 싼 검증 방법이었던 셈이다. 경쟁자가 없다는 사실만으로 build-first가 정당화되지는 않는다. 수요가 없어서 아무도 만들지 않았을 수도 있다. 공개 요청의 빈도, 현재 우회 방법, 구현 비용, 첫 사용자에게 닿는 경로가 함께 있어야 한다. ## 마케팅 먼저는 광고 캠페인이 아니다 제품이 없을 때의 마케팅은 멋진 브랜드를 만드는 일이 아니다. 한 문장으로 문제와 결과를 설명하고, 대상 고객에게 보여 주고, 연락처나 대화처럼 비용 있는 반응을 받는 일이다. 랜딩페이지 방문 수보다 누구의 어떤 말이 행동으로 이어졌는지가 중요하다. “관심 있어요”는 약한 증거다. 현재 쓰는 대안 공개, 데모 약속, 파일 제공, 유료 pilot, 선결제처럼 고객이 시간·데이터·돈을 내놓을수록 강해진다. 만들기 전 검증의 목적은 확신을 얻는 것이 아니라 잘못된 약속을 싸게 버리는 것이다. 코딩과 마케팅을 번갈아 하는 이유도 여기에 있다. 한쪽은 약속이 구현 가능한지 시험하고, 다른 쪽은 그 약속을 원하는 사람이 실제로 행동하는지 시험한다. 둘을 오래 떼어 놓으면 서로의 가장 위험한 가정을 확인하지 못한다. ## 코딩과 마케팅은 모드로 나누되 루프로 연결한다 Yong은 하루 안에서 계속 전환하지 않고 build day와 marketing day를 나눴다고 설명한다. 코딩과 고객 접촉은 사고 방식이 달라 깊은 작업을 지키는 데 도움이 된다. 하지만 한쪽을 몇 달씩 고립시키면 학습이 늦어진다. 작은 주기로 묶는 편이 낫다. 고객 대화에서 위험한 가정 하나를 고르고, 가장 작은 제품 변화로 시험하고, 사용 행동을 확인한 뒤 다음 대화로 돌아간다. 마케팅은 수요를 만들고 읽으며, 코딩은 그 약속을 제품 행동으로 바꾼다. ## 다음 행동은 가장 약한 증거가 정한다 고객 문제는 분명하지만 해결책이 가능한지 모르면 prototype을 만든다. 제품은 작동하지만 아무도 가입하지 않으면 메시지와 채널을 시험한다. 가입은 하지만 결제가 없으면 가치 체험과 가격을 본다. 결제는 있지만 유지되지 않으면 기능 추가보다 반복 사용 장면을 조사한다. 이렇게 보면 “코드 먼저냐 마케팅 먼저냐”는 한 번의 선택이 아니다. 퍼널의 어느 연결이 추측인지 찾는 반복 질문이다. 둘 중 좋아하는 일을 먼저 하는 대신, 현재 사업에서 가장 약한 증거를 먼저 만든다. ## 증거의 비용은 다음 결정을 바꿀 만큼만 써야 한다 프로토타입이 하루면 가능한데 인터뷰를 한 달 하는 것도, 고객 한 명과 대화하면 버릴 약속을 몇 주 동안 구현하는 것도 비싸다. 좋은 검증은 가장 엄격한 실험이 아니라 결과가 어느 쪽이든 다음 행동을 바꾸는 가장 작은 실험이다. 그러려면 시작 전에 판정 기준을 적어야 한다. 어떤 반응이면 만들고, 어떤 반응이면 약속을 바꾸며, 어떤 반응이면 중단할지를 정하지 않으면 방문과 칭찬을 모두 긍정 신호로 해석하게 된다. 코드와 마케팅의 순서는 기술 성향이 아니라, 현재 가설을 반증할 증거를 가장 싸게 살 수 있는 쪽이 정한다. --- 주요 출처는 Edmund Yong의 [Should I Code or Market First?](https://www.youtube.com/watch?v=0LE0trd740Q&ref=zerodraftlab.com)입니다. 1만 사용자와 5만 달러 이상의 매출, 커뮤니티 수요와 성장 경로는 제작자의 자기보고이며 독립 검증된 일반 성공 공식이 아닙니다. 랜딩페이지·대화·유료 pilot의 증거 강도 구분은 Zero Draft Lab의 해석입니다. ### 플랫폼 위 제품은 세 군데서 깨진다 URL: https://zerodraftlab.com/platform-products-break-three-ways/ Last updated: 2026-09-15T08:34:45.000Z 플랫폼 위 제품은 플랫폼이 같은 기능을 만들 때만 위험한 것이 아니다. 플랫폼 화면이 바뀌고, 배포 심사가 지연되고, 클라이언트 코드에 비밀값이 들어가도 깨진다. 전략, 운영, 보안을 따로 관리해야 한다. Edmund Yong의 브라우저 확장 기록은 세 종류의 사고를 보여 준다. [OpenAI가 유사 기능을 출시한 사건](https://www.youtube.com/watch?v=SAbp7E9daso&ref=zerodraftlab.com), [ChatGPT 화면 변경으로 버그가 난 운영](https://www.youtube.com/watch?v=K2Jlzp54kdc&ref=zerodraftlab.com), [확장 번들에 secret이 노출된 사건](https://www.youtube.com/watch?v=JxB0FX%5F4ql4&ref=zerodraftlab.com)이다. ## 첫 번째 위험은 핵심 기능의 흡수다 OpenAI가 Projects를 내놓자 폴더 확장의 해지와 삭제가 늘었다고 Yong은 말한다. 그는 Projects 안에서도 필요한 계층 구조와 bookmark를 추가해 플랫폼 기능을 보완했다. 직접 경쟁을 피하고 heavy user의 복잡한 흐름으로 한 단계 이동한 선택이다. 그렇다고 대체 위험이 사라진 것은 아니다. 플랫폼이 다음 기능을 흡수할 수 있다. 플랫폼 위 앱의 방어선은 기능 개수보다 고객의 데이터 정리 방식, 다른 플랫폼과의 연결, 지원 품질, 이전 가능한 자산에 있다. ## 두 번째 위험은 보이지 않는 화면 계약이다 브라우저 확장은 공식 API가 아니라 페이지 구조와 동작에 기대는 경우가 많다. ChatGPT Canvas 같은 화면 변경 뒤 여러 버그가 생겼고, 사용자의 신고로 문제를 알게 됐다고 한다. 플랫폼 release note 확인, 작은 회귀 테스트, 쉬운 신고 경로가 운영 기능이 되는 이유다. 그는 버그를 한 번에 모아 새 빌드 하나로 제출했다. 문맥 전환과 심사 횟수를 줄이려는 선택이지만 긴급 보안 수정까지 기다려서는 안 된다. 기능 버그의 batch와 보안 사고의 즉시 대응은 다른 queue여야 한다. 다만 전략 위험과 운영 위험을 나눴다고 관리가 끝나는 것은 아니다. 제품이 빠르게 복구됐더라도 클라이언트에 있으면 안 되는 권한이 들어갔다면, 기능 queue와 다른 중단 조건으로 즉시 다뤄야 한다. ## 세 번째 위험은 클라이언트에 들어간 권한이다 사용되지 않는 utility가 secret key를 참조했고 production bundle에서 평문으로 발견됐다. Yong은 참조를 제거하고 자격증명을 교체했으며, 악용이나 데이터 유출은 확인되지 않았다고 말한다. 이 결론은 제작자의 조사 범위에 따른 자기보고다. [Chrome 확장 보안 공식 문서](https://developer.chrome.com/docs/extensions/develop/security-privacy/stay-secure?ref=zerodraftlab.com)는 content script로 secret이나 다른 origin의 데이터를 보내지 말고, 필요한 최소 권한만 요청하라고 안내한다. 배포되는 클라이언트 코드는 사용자가 읽을 수 있다고 가정해야 한다. 숨겨야 하는 권한은 서버에 두고 좁은 작업만 호출하게 한다. ## 복구 속도에는 스토어 대기 시간도 포함된다 자격증명 교체 뒤 기존 확장이 작동하지 않았고, 새 빌드가 승인될 때까지 사용자는 기다려야 했다. [Chrome Web Store 공식 문서](https://developer.chrome.com/docs/webstore/review-process?ref=zerodraftlab.com)에 따르면 새 확장과 업데이트 모두 review를 거치며 소요 시간은 달라질 수 있다. 코드를 고친 시점과 사용자가 수정본을 받은 시점은 다르다. 그래서 플랫폼 위 제품의 incident plan에는 자격증명 회수, 서버 측 차단, 사용자 공지, 이전 버전 호환, 제출 상태 확인이 함께 있어야 한다. 한 사람에게 모든 책임이 모인 1인 사업일수록 미리 적어 둔 순서가 판단 시간을 줄인다. 기능 복제, 화면 변경, secret 노출은 서로 다른 사건처럼 보인다. 공통점은 내 코드 밖의 조건이 제품의 생존과 복구 시간을 정한다는 것이다. 플랫폼을 쓰지 말라는 결론이 아니라, 빌린 표면과 내가 통제하는 경계를 장부에 따로 적으라는 결론이다. ## 세 위험은 서로 다른 신호와 중단 조건을 가진다 기능 흡수는 해지와 사용 장면의 변화로, 화면 계약 파손은 회귀 테스트와 고객 신고로, secret 노출은 배포 전 스캔과 자격증명 사용 기록으로 먼저 보인다. 하나의 “플랫폼 리스크” 지표로 합치면 전략 문제에 긴급 패치를 하거나 보안 사고를 다음 제품 회의까지 미루게 된다. 대응의 종료 조건도 달라야 한다. 전략은 고객 가치가 플랫폼 기본 기능과 다시 구분되는지, 운영은 수정본이 실제 사용자에게 도달했는지, 보안은 자격증명이 회수되고 영향 범위가 확인됐는지로 닫는다. 1인 사업의 위험 관리는 모든 사고를 막는 체계가 아니라, 사건의 종류를 빨리 알아보고 맞는 queue를 여는 능력이다. --- 주요 출처는 Edmund Yong의 [OpenAI “Ended” My Startup](https://www.youtube.com/watch?v=SAbp7E9daso&ref=zerodraftlab.com), [A Realistic Coding Vlog](https://www.youtube.com/watch?v=K2Jlzp54kdc&ref=zerodraftlab.com), [Building a Solo Startup in My 20s](https://www.youtube.com/watch?v=JxB0FX%5F4ql4&ref=zerodraftlab.com)입니다. 사용자·매출·해지, secret 노출 범위와 무피해 결론은 제작자의 자기보고입니다. 최소 권한과 content script 경계는 [Chrome 공식 보안 문서](https://developer.chrome.com/docs/extensions/develop/security-privacy/stay-secure?ref=zerodraftlab.com), update review 대기는 [공식 review 문서](https://developer.chrome.com/docs/webstore/review-process?ref=zerodraftlab.com)를 대조했습니다. ### 매출 순위표는 고객 검증이 아니다 URL: https://zerodraftlab.com/revenue-leaderboards-are-not-validation/ Last updated: 2026-09-15T08:34:46.000Z 다른 앱의 매출을 보는 것은 시장 조사의 시작이 될 수 있다. 그러나 순위표의 숫자는 내 고객이 같은 문제에 돈을 낼 이유를 대신하지 못한다. 매출 증거와 고객 고통 증거는 서로 다른 자료다. Edmund Yong은 [1인 스타트업 아이디어 검증 영상](https://www.youtube.com/watch?v=OoofplYkDQI&ref=zerodraftlab.com)에서 독창성 집착을 버리고, build-in-public 사례와 매출 순위표, 프리랜서 마켓의 반복 서비스를 살펴보라고 제안한다. 이미 돈이 흐르는 곳에서 아이디어를 찾는 방식이다. ## 경쟁 제품의 존재는 문제의 존재를 보여 준다 같은 문제를 푸는 제품이 여럿 있다는 사실은 아이디어가 늦었다는 판정이 아니다. 고객이 이미 해결책을 찾고 비교한다는 신호다. 가격, 속도, 사용 난이도, 특정 고객군 중 한 축에서 더 나은 선택을 만들 수 있다. 다만 “매출이 있으니 검증됐다”는 문장은 주어가 빠졌다. 그 창업자의 고객, 채널, 브랜드, 가격에서 거래가 검증된 것이다. 후발 제품이 같은 수요를 얻으려면 어떤 고객이 왜 기존 제품을 선택했고 무엇 때문에 떠나는지 다시 확인해야 한다. ## 공개 매출은 규모를 보여 줘도 원인을 보여 주지 않는다 Yong은 Stripe 연결을 내세우는 공개 매출 순위표를 데이터 소스로 든다. 숫자가 실제 결제 시스템에서 왔더라도 비용, 환불, 할인, 한 고객 의존도, 창업자의 기존 audience는 보이지 않을 수 있다. revenue는 profit도 아니고 반복 가능한 획득 경로도 아니다. build-in-public 글도 같은 경계가 있다. 성공 사례는 많이 공유되고 중단된 실험은 조용히 사라진다. 제작자 역시 소셜미디어 숫자가 과장될 수 있다고 경고한다. 여러 사례에서 반복되는 고객, 작업, 채널을 가설로 뽑되 성공 확률로 계산해서는 안 된다. 순위표가 보여 주지 못한 원인은 고객이 실제로 일을 맡기는 장면에서 드러난다. 같은 결과를 파는 서비스가 반복되는 이유가 단순 작업량인지, 예외를 책임질 사람인지 구분해야 소프트웨어가 대체할 범위를 고를 수 있다. ## 프리랜서 수요는 자동화 후보이지 제품 주문서가 아니다 반복 구매되는 서비스를 소프트웨어로 바꾸는 관점은 유용하다. 사람이 매번 배경을 지우거나 보고서를 정리한다면 작업 빈도와 지불 의사가 이미 보인다. 하지만 고객이 사람을 고용하는 이유가 예외 처리, 책임, 상담에 있다면 버튼 하나로 바꿀 수 없다. 서비스를 관찰할 때는 입력이 얼마나 표준화됐는지, 실패를 누가 고치는지, 결과 품질을 어떻게 판단하는지, 고객이 결과와 책임 중 무엇에 돈을 내는지 물어야 한다. Yong도 이 방법은 자신이 아직 직접 시험하지 않았다고 밝힌다. ## 순위표 다음에는 작은 유료 수작업이 온다 검증 순서는 간단하다. 매출 사례로 시장 후보를 찾고, 불만과 반복 작업을 수집하고, 한 고객에게 수작업으로 결과를 제공하고, 실제 결제를 받은 뒤 반복되는 부분만 제품화한다. 코드를 쓰기 전에 고객의 입력과 완료 기준을 배울 수 있다. 아이디어 검증은 위험을 없애는 일이 아니다. 어떤 위험을 먼저 돈과 대화로 확인할지 정하는 일이다. 다른 사람의 매출은 탐색 비용을 줄인다. 내 제품의 수요는 내 고객의 행동으로만 닫힌다. ## 강한 증거는 남의 숫자에서 내 거래로 이동한다 처음에는 여러 제품의 매출과 리뷰로 시장의 언어를 배울 수 있다. 다음에는 특정 고객의 현재 대안과 불만을 확인하고, 그다음에는 수작업 결과를 약속해 시간이나 데이터를 받아야 한다. 마지막에 돈이 오가면 적어도 고객, 문제, 결과, 가격이 한 번 연결됐다는 증거가 생긴다. 이 순서를 건너뛰고 순위표에서 바로 제품으로 가면 가장 비싼 가정이 그대로 남는다. 기존 제품의 고객을 내가 만날 수 있는지, 같은 결과를 낼 수 있는지, 그 과정의 책임을 소프트웨어가 감당할 수 있는지 모른다. 시장 조사의 목적은 매출이 큰 아이디어를 고르는 것이 아니라, 남의 성공에서 빌린 확신을 내 고객의 작은 거래로 교체하는 데 있다. --- 주요 출처는 Edmund Yong의 [How to Validate Solo Startup Ideas Fast](https://www.youtube.com/watch?v=OoofplYkDQI&ref=zerodraftlab.com)입니다. 영상에 언급된 창업자 매출, 순위표의 검증 방식과 성공 사례는 현재 독립 확인하지 않았고 시장 탐색 신호로만 다뤘습니다. 프리랜서 서비스를 제품화하는 방식은 제작자도 미검증 아이디어라고 밝혔습니다. 특정 제품을 복제하거나 매출 수치를 수요 보장으로 해석하지 않았습니다. ### 꾸준함보다 다음 시작점을 남기는 습관 URL: https://zerodraftlab.com/leave-a-clear-next-step/ Last updated: 2026-09-15T08:34:47.000Z 꾸준히 일하는 사람은 매일 의욕이 넘치는 사람이 아니다. 오늘 멈춘 위치와 내일 시작할 한 동작을 남겨, 다시 들어갈 때 드는 판단 비용을 줄인 사람에 가깝다. Edmund Yong은 [코딩을 즐겁게 만드는 습관](https://www.youtube.com/watch?v=Q9uXOSGS8IQ&ref=zerodraftlab.com), [과도한 고민 없이 출시하는 방식](https://www.youtube.com/watch?v=CJ-xMLz-ZrM&ref=zerodraftlab.com), [이동 중에도 일하는 생활 기록](https://www.youtube.com/watch?v=l5tdsK%5FOd2Q&ref=zerodraftlab.com)에서 작은 이정표, 종료 기록, 마감, time blocking을 반복해서 말한다. ## 작은 할 일은 성취감보다 상태를 보존한다 큰 목표를 작은 단계로 나누면 완료 표시가 늘어난다. 더 중요한 이점은 다음 행동이 눈에 보인다는 것이다. “앱 만들기”는 다시 계획해야 하지만 “결제 실패 webhook 재현”은 바로 시작할 수 있다. Yong은 작업을 마칠 때 내일 할 일과 blocker를 텍스트에 남기고, 다음 날 전날의 commit을 보며 맥락을 복원한다고 말한다. 이 종료 의식은 기억을 믿지 않고 작업 상태를 외부에 저장한다. 생산성 앱의 기능보다 다시 시작하는 데 필요한 정보가 한곳에 있는지가 중요하다. ## 마감은 기능 수를 줄일 때만 도움이 된다 그는 공개 출시일처럼 외부 약속을 만들어 끝없는 수정에서 벗어나라고 제안한다. 그러나 마감이 품질을 자동으로 만들지는 않는다. 계정, 결제, 데이터처럼 실패 비용이 큰 흐름을 생략하고 날짜만 지키면 검토 부채가 다음 날 돌아온다. 좋은 마감은 핵심 사용자가 얻어야 할 결과를 고정하고 나머지를 버리는 장치다. 한두 문제를 완결해서 풀고, 예상 사용량도 오지 않은 상태에서 확장성 설계를 미룬다. 빠른 출시와 미완성 출시는 같은 말이 아니다. 이 차이는 하루의 종료에서도 같다. 시간을 다 썼다는 이유로 멈추는 것과, 다음 사람이 이어받을 수 있는 상태를 남기고 멈추는 것은 다른 완료다. 혼자 일해도 내일의 자신은 오늘의 문맥을 공유하지 않는 다음 작업자다. ## streak는 방향이 맞을 때만 자산이다 GitHub contribution streak나 작은 보상은 작업을 시작하는 신호가 될 수 있다. 하지만 streak를 지키기 위한 의미 없는 commit도 가능하다. 측정값이 목적을 대신하면 꾸준함이 아니라 숫자 유지가 된다. 더 나은 기록은 “오늘 몇 줄 썼나”보다 “어떤 불확실성을 닫았나”다. 버그를 재현했거나, 고객 한 명과 대화했거나, 결제 경로를 확인했다면 작은 변경도 제품을 전진시킨다. 반대로 기능을 많이 만들었어도 수요 질문을 미뤘다면 활동량만 늘었다. ## 환경이 흔들릴수록 고정할 것은 적어야 한다 Yong은 장소를 자주 옮기면서도 아침 글쓰기, 당일 할 일, 운동과 수면을 고정점으로 둔다. 이동 생활이 정신력을 자동으로 높인다는 증거는 아니다. 오히려 루틴이 자주 깨지므로 중요한 작업을 시간과 장소에 미리 배정해야 했다고 설명한다. 지속 가능한 작업 시스템은 완벽한 하루를 요구하지 않는다. 시작 신호, 한 번에 한 작업, 멈출 조건, 다음 시작점 네 가지면 된다. 의욕이 낮은 날에도 이 구조가 남아 있으면 다시 계획하는 데 하루를 쓰지 않는다. ## 좋은 다음 행동은 판단 하나를 미리 끝낸다 “내일 결제를 고친다”에는 여전히 어디서 시작할지 결정하는 일이 남아 있다. “실패 webhook의 payload를 재현하고 현재 로그와 비교한다”는 행동은 첫 판단을 이미 끝냈다. 다음 행동이 작다는 말은 작업 시간이 짧다는 뜻보다, 시작 전에 다시 설계할 범위가 적다는 뜻이다. blocker도 같은 방식으로 남겨야 한다. “API가 안 된다”가 아니라 어떤 요청이 어떤 응답으로 실패했고, 확인하지 못한 가정이 무엇인지 적으면 중단이 조사 자산이 된다. 꾸준함은 멈추지 않는 성격이 아니라, 멈출 때마다 다음 시작의 불확실성을 하나 줄이는 운영 습관이다. --- 주요 출처는 Edmund Yong의 [How I Make Coding Fun with Simple Habits](https://www.youtube.com/watch?v=Q9uXOSGS8IQ&ref=zerodraftlab.com), [My Simple System to Code Without Mental Blocks](https://www.youtube.com/watch?v=CJ-xMLz-ZrM&ref=zerodraftlab.com), [Life as a 26 y/o Solo Startup Founder](https://www.youtube.com/watch?v=l5tdsK%5FOd2Q&ref=zerodraftlab.com)입니다. 습관과 생산성 효과는 제작자의 개인 경험이며 인과가 검증된 실험으로 다루지 않았습니다. 스폰서 교육·디자인 도구와 dopamine detox 주장은 권장 근거에서 제외했습니다. ### 1인 개발 장비의 목적은 선택을 줄이는 것이다 URL: https://zerodraftlab.com/solo-setup-reduces-decisions/ Last updated: 2026-09-15T08:34:47.000Z 1인 개발 장비의 목적은 더 많은 도구를 갖는 것이 아니다. 자리를 옮겨도 같은 작업을 시작하고, 집중이 끊겼을 때 빠르게 돌아오며, 다음 도구를 고르는 시간을 줄이는 것이다. Edmund Yong은 세 차례에 걸쳐 [한 대의 노트북 중심 구성](https://www.youtube.com/watch?v=AGrh9X0eU8I&ref=zerodraftlab.com), [배낭 하나에 들어가는 이동 구성](https://www.youtube.com/watch?v=nCuaNmeVfQY&ref=zerodraftlab.com), [새 16인치 MacBook 구성](https://www.youtube.com/watch?v=SVuHW7k-Ht4&ref=zerodraftlab.com)을 공개했다. 기기와 앱은 바뀌었지만 선택 기준은 휴대성, 방해 제거, 반복 동작 축소로 남았다. ## 미니멀리즘은 물건 수보다 전환 규칙이다 초기 구성에서는 한 화면만 써서 한 작업에 집중한다고 말한다. 이동 구성에서는 iPad를 두 번째 화면으로 쓴다. 최신 구성에서는 더 큰 노트북과 외장 키보드·트랙패드를 더한다. “적을수록 좋다”는 고정된 물건 수가 아니라, 현재 작업에서 전환 비용을 낮추는 조합으로 변했다. 이 변화가 중요한 이유는 장비 추천 목록이 보편적이지 않기 때문이다. 같은 사람이 이동 빈도, 작업 시간, 영상 편집 비중이 바뀌자 다른 선택을 했다. 다른 창업자의 최종 책상을 복제하기보다 어떤 불편 때문에 장비가 추가됐고 무엇을 치웠는지 봐야 한다. ## 좋은 도구는 반복 결정을 사라지게 한다 세 영상에서 반복되는 것은 키보드로 앱과 창을 전환하고, 프로젝트 안에 다음 할 일을 남기고, 방해 사이트와 추천 화면을 차단하는 흐름이다. 효과는 클릭 몇 번을 줄이는 데만 있지 않다. 작업을 시작할 때 “어디에 적었지, 무엇부터 하지, 어떤 창을 열지”를 다시 결정하지 않게 한다. 반대로 앱 하나가 여러 기능을 제공한다는 이유만으로 필수 도구가 되지는 않는다. 반복 작업의 빈도, 설정 유지 비용, 실패 때 대체 경로를 함께 봐야 한다. 한 달 동안 쓰지 않은 런처 확장과 터미널 앱은 미니멀한 화면 뒤의 운영 부채일 수 있다. 결정을 줄이는 도구와 책임을 감추는 도구는 겉으로 비슷하다. 자동 설정과 단축키가 재시작을 돕는 동안에는 자산이지만, 왜 필요한지 모른 채 유지되는 순간부터 작업 환경은 창업자의 기억에 의존하는 또 하나의 시스템이 된다. ## 사양과 건강 효과는 개인 경험으로 남겨야 한다 Yong은 무광 필름과 조명이 눈의 피로와 편두통을 줄였다고 말하고, 고휘도 설정과 특정 자세의 trade-off도 언급한다. 이는 개인 경험이지 의료 효과를 보장하는 자료가 아니다. 밝기, 반사, 자세, 휴식은 개인 상태와 작업 환경에 맞춰 조절해야 한다. 고사양 노트북도 수익의 원인이 아니다. 영상 편집, 로컬 모델, 긴 배터리 사용처럼 실제 workload가 요구할 때 비용을 정당화한다. 현재 기기에서 빌드와 편집이 끝난다면 업그레이드보다 백업, 복구, 자동 설정이 작업 중단 시간을 더 크게 줄일 수 있다. ## 새 장비를 살 때는 제거할 결정을 적는다 구매 전에는 세 질문이면 충분하다. 지금 반복되는 마찰은 무엇인가. 새 도구가 없애는 단계는 무엇인가. 한 달 뒤 사용 여부를 무엇으로 판단할 것인가. 답이 “더 생산적인 느낌”뿐이면 장비가 아니라 기대를 사고 있을 가능성이 크다. 좋은 1인 개발 환경은 사진으로 완성되지 않는다. 다른 장소에서도 같은 프로젝트를 열고, 어제 남긴 다음 행동을 찾고, 변경을 되돌리고, 집중이 끝나면 상태를 남길 수 있을 때 완성된다. 미니멀한 장비의 핵심은 소유량이 아니라 재시작 시간이다. ## 재시작 시간은 장비보다 상태 이전으로 줄어든다 노트북을 바꾸거나 작업 장소를 옮겼을 때 가장 오래 걸리는 것은 앱 설치가 아니라 현재 맥락을 복원하는 일이다. 어떤 branch에서 무엇을 확인했고, 다음 행동이 무엇이며, 필요한 계정과 데이터가 어디에 있는지가 남아 있으면 새 장비는 교체 가능한 단말이 된다. 그렇지 않으면 좋은 하드웨어도 창업자의 기억을 기다린다. 따라서 장비 투자와 작업 시스템 투자는 따로 평가해야 한다. 렌더링 시간이나 배터리 중단을 실제로 줄였다면 하드웨어의 효과이고, 프로젝트를 찾고 설정을 고르는 시간이 줄었다면 문서와 자동화의 효과다. 둘을 분리해야 다음 구매가 해결할 수 없는 문제를 새 기기로 덮지 않는다. --- 주요 출처는 Edmund Yong의 [My MacBook Setup](https://www.youtube.com/watch?v=AGrh9X0eU8I&ref=zerodraftlab.com), [Minimalist Tech Setup](https://www.youtube.com/watch?v=nCuaNmeVfQY&ref=zerodraftlab.com), [My New Minimalist MacBook Setup for Coding](https://www.youtube.com/watch?v=SVuHW7k-Ht4&ref=zerodraftlab.com)입니다. 영상에는 협찬·제휴 제품이 포함되며 제품 사양과 앱 기능은 게시 뒤 바뀔 수 있습니다. 눈 피로·편두통 관련 내용은 제작자의 개인 경험이며 의료 조언이나 효과 검증으로 다루지 않았습니다. ### 첫 결제 뒤 제품은 세 번 바뀌었다 URL: https://zerodraftlab.com/first-payment-changes-the-product/ Last updated: 2026-09-15T08:34:48.000Z 첫 결제는 아이디어가 맞았다는 종착점이 아니다. 실제 사용자가 들어오면 제품의 이름, 가격, 기능 우선순위가 차례로 바뀐다. 출시 전 계획보다 출시 뒤 제약이 제품을 더 많이 설계한다. Edmund Yong은 유튜브 자막을 대량으로 내려받는 앱을 만든 과정을 세 편에 걸쳐 공개했다. [첫 제작과 출시](https://www.youtube.com/watch?v=cESaIUWoCJQ&ref=zerodraftlab.com), [출시 한 달 안의 운영](https://www.youtube.com/watch?v=QI2t35PLsCw&ref=zerodraftlab.com), [기능·도메인·가격 변경](https://www.youtube.com/watch?v=tfNIoZE4q-Q&ref=zerodraftlab.com)을 이어 보면 한 제품이 첫 결제 뒤 어떻게 달라지는지 보인다. ## 첫 결제는 문제의 크기보다 거래 가능성을 보여 준다 첫 버전은 채널이나 재생목록의 자막을 한꺼번에 내려받는 한 가지 흐름에 집중했다. Yong은 출시 뒤 13명 가입, 6명 결제, 200파운드 이상의 매출을 얻었다고 말한다. 이 작은 표본만으로 시장 규모를 알 수는 없지만 낯선 사람이 초기 제품에 돈을 냈다는 사실은 다음 대화를 시작할 근거가 된다. 한 달이 지나기 전에는 200명 이상의 사용자와 1,000파운드 이상의 누적 매출을 공개했다. 여기에도 비용, 환불, 반복 구매, 획득 경로는 빠져 있다. 그래서 “수익형 앱”보다 “특정 작업에 결제가 발생한 앱”이라고 읽는 편이 정확하다. ## 두 번째 변화는 기능보다 전달 경로에서 왔다 웹앱만 있던 제품에 브라우저 확장을 붙였다. 사용자가 영상을 보던 화면에서 바로 자막을 받을 수 있게 하고, Chrome Web Store라는 별도 발견 경로를 얻기 위해서였다. 새 기능 하나가 아니라 사용 장소와 유통 채널을 동시에 바꾼 선택이다. 반면 사용자 피드백을 많이 받는다고 모든 요청을 구현한 것은 아니다. 창업자 자신이 핵심 사용자라는 확신으로 기능을 더 만들기도 했다. 자기 문제를 푼다는 장점은 빠른 판단이고, 위험은 자신의 사용법을 전체 시장으로 일반화하는 것이다. 결제와 반복 사용 데이터를 함께 보지 않으면 founder goggles는 사라지지 않는다. 첫 결제 뒤에는 이 위험이 더 커진다. 돈을 낸 사람이 있다는 사실이 창업자의 모든 가정을 승인한 것처럼 느껴지지만, 실제로 확인된 것은 당시 이름과 가격과 기능 묶음에서 한 거래가 일어났다는 데 그친다. ## 세 번째 변화는 제품 이름과 원가에서 왔다 Yong은 YouTube 상표가 제품명에 묶이는 위험을 줄이고 다른 영상 플랫폼으로 넓힐 수 있도록 도메인을 바꿨다고 설명한다. 이는 법률 판단의 정답이라기보다, 제품명이 확장 범위와 이전 비용을 만든 사례다. 초기에 싸게 산 설명형 도메인도 사용자가 생기면 이메일, 링크, 검색 기록을 함께 옮겨야 한다. AI 대화 기능을 넣은 뒤에는 LLM 사용량이라는 변동비가 생겼다. 그는 일회성 크레딧 가격에서 주간·월간 구독 하나로 옮겼다. 가격 변경의 근거가 “구독 매출이 좋아 보여서”가 아니라 제품을 쓸수록 발생하는 원가였다. 다만 무제한 요금제가 실제 사용 분포에서 유지 가능한지는 공개되지 않았다. ## 기능을 멈춘 순간부터 시장 검증이 시작된다 세 번째 영상의 마지막에 Yong은 앱을 더 건드리지 않고 실제 결제 고객의 피드백과 마케팅에 집중하겠다고 말한다. 키워드 콘텐츠와 소셜 콘텐츠를 후보로 두지만 그 결과는 아직 없다. 제품 상태가 좋아졌다는 창업자의 느낌과 획득 경로가 생겼다는 증거는 다르다. 세 편을 한꺼번에 보면 첫 결제 뒤 확인할 순서가 보인다. 거래가 반복되는가, 사용 장소에서 마찰을 줄일 수 있는가, 이름이 확장을 막는가, 새 기능의 변동비를 가격이 감당하는가, 기능 추가를 멈추고 획득을 시험했는가. 첫 결제는 제품을 확정하지 않는다. 제품을 바꿀 자격을 준다. ## 변경의 이유가 남아야 제품이 배운다 도메인, 확장 프로그램, AI 기능, 구독 가격을 한꺼번에 바꾸면 매출이 달라져도 원인을 알기 어렵다. 작은 사업은 통제 실험을 완벽하게 만들 수 없지만, 변경 전의 문제와 기대한 행동, 실제 결과를 남길 수는 있다. 그래야 다음 기능이 지난달의 느낌이 아니라 확인된 병목에서 시작한다. 특히 가격 변경은 고객 메시지와 원가 구조를 동시에 바꾼다. 일회성 작업을 반복 구독으로 부르면 사용 빈도와 지속 가치도 함께 증명해야 한다. 첫 결제가 제품을 바꿀 자격을 준다는 말은 마음대로 확장할 허가가 아니라, 거래 뒤 드러난 제약을 한 번에 하나씩 배울 책임이 생긴다는 뜻이다. --- 주요 출처는 Edmund Yong의 [How I Coded Another Profitable App Solo](https://www.youtube.com/watch?v=cESaIUWoCJQ&ref=zerodraftlab.com), [Building a Profitable App from Scratch Solo](https://www.youtube.com/watch?v=QI2t35PLsCw&ref=zerodraftlab.com), [My Solo Startup Journey So Far](https://www.youtube.com/watch?v=tfNIoZE4q-Q&ref=zerodraftlab.com)입니다. 가입자·결제자·매출·기간은 제작자의 자기보고이며 결제 자료, 비용, 환불, 유지율로 독립 검증되지 않았습니다. 제품명 변경은 제작자가 설명한 위험 대응으로만 다뤘고 법률 결론으로 일반화하지 않았습니다. ### 플랫폼 앱의 첫 고객은 빌린 유통에서 온다 URL: https://zerodraftlab.com/platform-apps-rent-their-distribution/ Last updated: 2026-09-15T08:34:49.000Z 플랫폼 안에서 앱을 만들면 결제, 인증, 사용자를 처음부터 만들지 않아도 된다. 대신 고객 접점과 규칙을 빌린다. 첫 고객은 빨리 만날 수 있지만 수수료, 노출 방식, 정책 변경도 함께 따라온다. Edmund Yong은 [Whop 앱 제작 영상](https://www.youtube.com/watch?v=x3C-3dX3e6Q&ref=zerodraftlab.com)에서 커뮤니티 운영자용 콘텐츠 아이디어와 스크립트 도구를 만든다. 플랫폼 안의 기존 앱과 운영자 수요를 살펴보고, 작은 완결 제품을 올린 뒤 직접 고객에게 알렸다고 설명한다. ## 플랫폼은 기능보다 빠른 시장 경계를 준다 일반 웹앱은 누구를 위한 제품인지부터 넓게 탐색해야 한다. 플랫폼 앱은 사용자 역할, 반복 행동, 결제 방식이 어느 정도 정해져 있다. 커뮤니티 운영자가 이미 회원에게 콘텐츠를 제공하고 있다면 아이디어 생성이나 스크립트 작성 같은 보조 도구의 사용 장면도 구체적이다. [Whop 공식 문서](https://docs.whop.com/?ref=zerodraftlab.com)는 플랫폼 안에서 앱을 만들고 App Store로 배포하는 경로와, 외부 제품에 결제만 붙이는 경로를 구분한다. 이 선택은 UI 위치 이상의 문제다. 앱이 플랫폼 안에 살면 발견과 맥락을 얻고, 외부에 두면 고객 경험과 데이터 경계를 더 직접 소유한다. ## 빌린 유통은 공짜 유통이 아니다 Yong은 당시 경쟁 앱 수와 플랫폼의 창작자·사용자 규모를 기회로 제시한다. 이 숫자는 영상과 파트너 설명에 기반한 시점 자료이므로 현재 규모로 사용할 수 없다. 더구나 전체 플랫폼 사용자가 특정 앱의 도달 가능 고객과 같지도 않다. 마켓플레이스에 등록했다고 고객이 자동으로 오지는 않는다. 검색 순위, 카테고리, 리뷰, 운영자 추천, 직접 영업 중 어떤 경로가 설치를 만드는지 확인해야 한다. 플랫폼이 유통 비용을 없애는 것이 아니라 이미 모인 관계망에 접근할 수 있는 선택지를 준다. 그 선택지의 가격은 수수료만으로 계산되지 않는다. 고객이 앱을 발견하고 결제하는 경로를 플랫폼이 소유할수록, 창업자는 빠른 접근과 맞바꾸어 고객 관계를 관찰하고 이전할 권한 일부를 내놓는다. ## 초기 매출보다 의존성 장부를 같이 적는다 Yong은 출시 후 일주일 동안 400달러가 넘는 매출을 기록했고, 해지가 없다고 가정하면 약 391달러 MRR이라고 말한다. 일주일 매출과 조건부 MRR은 장기 유지율이나 순이익이 아니다. 영상은 플랫폼 협찬을 포함하며 결제 내역과 비용도 공개하지 않았다. 그래도 첫 결제가 빠르게 나온 이유를 분석할 수는 있다. 명확한 플랫폼 사용자, 이미 존재하는 결제와 계정, 좁은 사용 장면, 직접적인 고객 접촉이 한꺼번에 있었다. 반대로 수수료, 앱 심사, API 변경, 고객 데이터 접근, 플랫폼 밖으로의 이전 가능성은 별도 위험이다. ## 플랫폼 앱은 유통 실험으로 시작한다 좋은 첫 질문은 “이 플랫폼에 앱을 만들까”가 아니다. “이 플랫폼 안의 어떤 사용자가 어떤 반복 작업에 이미 돈을 쓰는가”다. 그다음 가장 작은 도구로 결제와 사용을 확인하고, 획득 경로와 플랫폼 의존성을 동시에 기록한다. 영상에서는 다수 잠재고객에게 연락하기 위한 자동화도 등장한다. 플랫폼 약관과 수신자의 기대를 확인하지 않은 대량 메시지는 지속 가능한 유통이 아니다. 초기 고객 인터뷰와 소수의 관련성 높은 접촉은 유용하지만, 응답률을 위해 관계를 소모하면 빌린 유통의 가장 중요한 자산을 잃는다. 플랫폼 앱의 장점은 제품을 덜 만드는 데 있지 않다. 고객을 만나는 데 필요한 기반을 빌려 수요 검증을 앞당기는 데 있다. 검증 뒤에도 남아야 하는 것은 매출 숫자 하나가 아니라 어느 고객이 왜 설치했고, 플랫폼 규칙이 바뀌어도 어떤 가치가 유지되는지에 대한 기록이다. ## 빌린 유통에서 소유할 것은 고객의 문제다 플랫폼의 사용자 수나 검색 순위는 가져갈 수 없지만, 어떤 역할의 사용자가 어떤 반복 작업에서 멈췄는지에 대한 지식은 쌓을 수 있다. 설치 이유, 첫 성공 행동, 해지 이유를 제품 안에서 허용된 범위로 기록하면 플랫폼 밖에서도 문제의 구조를 설명할 수 있다. 반대로 “플랫폼에 사람이 많다”는 가설만 남으면 정책 변화와 함께 시장 이해도 사라진다. 독립 제품으로 옮길지 플랫폼 안에 남을지도 이 지식으로 판단해야 한다. 고객이 플랫폼 문맥과 결제를 원한다면 독립은 오히려 마찰을 늘릴 수 있다. 데이터 경계와 고객 경험을 직접 통제해야 가치가 커진다면 이전 비용을 미리 계산해야 한다. 플랫폼 의존성의 반대는 무조건 탈출하는 것이 아니라, 무엇을 빌리고 무엇을 학습 자산으로 소유하는지 아는 상태다. --- 주요 출처는 Edmund Yong의 [I Built an App on Whop and Made $400 in a Week](https://www.youtube.com/watch?v=x3C-3dX3e6Q&ref=zerodraftlab.com)입니다. 매출, 조건부 MRR, 당시 플랫폼 규모는 협찬을 포함한 영상 제작자의 자기보고이며 독립 검증된 재무 성과가 아닙니다. 앱 배포와 결제 경로는 [Whop 공식 문서](https://docs.whop.com/?ref=zerodraftlab.com)를 대조했습니다. 영상의 대량 연락 자동화는 약관 준수나 권장 영업 방식으로 옮기지 않았습니다. ### 800시간 뒤 남은 것은 프롬프트가 아니라 반복 작업이다 URL: https://zerodraftlab.com/repetition-becomes-agent-infrastructure/ Last updated: 2026-09-15T08:34:50.000Z AI 코딩을 오래 쓰고도 남는 것은 화려한 프롬프트보다 반복 작업의 흔적이다. 매번 다시 설명한 규칙은 프로젝트 지침이 되고, 자주 시킨 절차는 명령이 되며, 독립적으로 검토할 일은 별도 작업 단위가 된다. Edmund Yong은 [Claude Code를 800시간 이상 쓴 뒤 정리한 영상](https://www.youtube.com/watch?v=Ffh9OeJ7yxw&ref=zerodraftlab.com)에서 프로젝트 메모리, 반복 명령, 최신 문서 연결, 하위 작업, 플러그인을 다룬다. [Cursor 작업 영상](https://www.youtube.com/watch?v=V-zhv95AhF8&ref=zerodraftlab.com)에서는 반복 수정 사항을 프로젝트 규칙으로 옮기고 관련 파일과 문서를 명시적으로 제공한다. 또 다른 [바이브 코더에게 필요한 기술 영상](https://www.youtube.com/watch?v=2IQYbwQpFdM&ref=zerodraftlab.com)에서는 프로그래밍 기초, Git, 명확한 요청, 디버깅, 보안을 최소 역량으로 꼽는다. ## 반복 설명은 기억 파일로 졸업시킨다 프로젝트를 열 때마다 빌드 명령, 폴더 구조, 테스트 방식, 금지된 의존성을 설명한다면 대화가 아니라 저장 위치가 잘못된 것이다. [Anthropic의 Claude Code 메모리 문서](https://docs.anthropic.com/en/docs/claude-code/memory?ref=zerodraftlab.com)도 `CLAUDE.md`에 프로젝트 아키텍처, 코딩 표준, 자주 쓰는 작업 흐름을 기록하는 용도를 설명한다. 다만 지침 파일을 모든 지식의 창고로 만들면 서로 충돌하고 오래된 규칙이 남는다. 에이전트가 행동을 바꿔야 하는 짧은 규칙과 정본 문서의 위치만 두고, 긴 설계 배경은 별도 문서와 테스트로 보존하는 편이 낫다. 기억은 압축된 운영 인터페이스다. 2025년의 Cursor 모델명, 자율 실행 옵션, 규칙 파일 형식을 그대로 따라 할 필요도 없다. 제품 UI는 바뀌지만 “같은 수정을 두 번 설명했다면 반복 가능한 규칙 후보”라는 판단은 남는다. 규칙을 추가한 뒤에는 실제 변경이 줄었는지 확인하고, 더는 맞지 않는 규칙은 지워야 한다. ## 반복 프롬프트는 검증 가능한 명령으로 바꾼다 같은 린트, 테스트, 릴리스 점검을 매번 자연어로 요청할 필요는 없다. 입력과 출력이 정해진 절차는 스크립트나 명령으로 만들고, 에이전트는 언제 그것을 실행할지 판단하게 한다. 이렇게 하면 결과를 재현하고 실패 지점을 찾기 쉬워진다. 도구 연결도 개수가 아니라 판단 비용을 줄이는가로 평가해야 한다. 최신 문서를 가져오는 연결은 오래된 API를 추측하는 문제를 줄일 수 있다. 반대로 사용하지 않는 MCP나 플러그인은 권한, 오류, 컨텍스트만 늘린다. 설치보다 제거 기준을 먼저 정하는 편이 안전하다. 반복을 기반 시설로 바꾸는 일은 더 많은 자동화를 쌓는 과정이 아니라, 사람의 판단이 필요한 부분과 이미 답이 정해진 부분을 갈라 놓는 과정이다. 이 구분이 없으면 기억 파일과 명령도 오래된 판단을 더 빠르게 반복한다. ## 하위 작업은 역할극보다 독립된 결과물이어야 한다 “시니어 개발자처럼 생각해”보다 “이 변경에서 보안 문제만 찾아 파일과 근거를 보고해”가 분리하기 쉽다. Yong도 하위 에이전트를 추상적인 직함보다 정리, 문서, 조사, UI 검토처럼 경계가 있는 작업에 쓰라고 설명한다. 동시에 같은 파일을 고치는 여러 작업을 무작정 병렬화하면 충돌과 재검토 비용이 커진다. 작업을 나눌 기준은 결과를 독립적으로 검증할 수 있는가다. 조사 보고서, 테스트 실패 원인, 접근성 점검처럼 읽기 결과가 분리되면 유용하다. 설계 결정 하나를 여러 에이전트가 각자 바꾸게 하는 것은 책임을 나눈 것이 아니라 상태를 복제한 것이다. ## 속도를 지키는 최후의 기술은 복구다 AI가 코드를 빨리 생성할수록 Git, 디버거, 로그, 인증과 권한의 기초가 더 중요해진다. 생성된 변경을 되돌리고, 차이를 읽고, 실패를 재현하고, 비밀값과 입력 경계를 확인할 수 없다면 속도는 누적 위험으로 바뀐다. 프로그래밍 문법을 모두 외워야 AI 코딩을 시작할 수 있다는 뜻은 아니다. 최소 자격은 결과의 소유자가 될 수 있는가다. 무엇이 바뀌었는지 설명하고, 테스트를 실행하고, 이상하면 원래 상태로 돌아갈 수 있어야 한다. 오래 쓸수록 프롬프트 기술은 기반 시설로 바뀐다. 반복 규칙은 기억, 반복 절차는 명령, 최신 사실은 문서 연결, 독립 검토는 하위 작업, 안전망은 Git과 테스트가 맡는다. 에이전트 숙련도는 한 번에 멋진 답을 받는 능력보다 반복을 재현 가능한 시스템으로 바꾸는 능력에 가깝다. ## 좋은 기반 시설은 틀린 반복을 멈출 수 있다 규칙과 스크립트에는 성공 경로뿐 아니라 재검토 조건이 필요하다. 의존성 버전이 바뀌었거나 같은 예외가 두 번 생겼거나 실행 결과가 더는 목적을 충족하지 못하면, 에이전트가 기존 지침을 따르는 대신 멈추고 정본을 다시 읽어야 한다. 자동화의 안정성은 언제나 같은 행동을 하는 데 있지 않다. 또한 반복 작업이 사라졌다는 사실만으로 효과를 판단할 수 없다. 검토 시간이 줄었는지, 실패를 더 빨리 찾았는지, 새로운 사람이 같은 절차를 재현할 수 있는지를 봐야 한다. 프롬프트가 기반 시설이 되는 순간부터 품질은 답변의 인상보다 변경 이력, 테스트, 실패 영수증으로 측정된다. --- 주요 출처는 Edmund Yong의 [800+ Hours of Claude Code: 10 Tips for 2026](https://www.youtube.com/watch?v=Ffh9OeJ7yxw&ref=zerodraftlab.com), [Cursor AI Tricks](https://www.youtube.com/watch?v=V-zhv95AhF8&ref=zerodraftlab.com), [5 Skills Every Vibe Coder Needs](https://www.youtube.com/watch?v=2IQYbwQpFdM&ref=zerodraftlab.com)입니다. 800시간은 제작자의 자기보고이며 영상 게시 뒤 제품 기능은 바뀔 수 있습니다. `CLAUDE.md`의 용도는 [Anthropic 공식 문서](https://docs.anthropic.com/en/docs/claude-code/memory?ref=zerodraftlab.com)를 대조했고, 특정 스폰서 교육 서비스는 권장 근거로 사용하지 않았습니다. ### 24시간 에이전트보다 먼저 자동화할 일을 고른다 URL: https://zerodraftlab.com/automate-work-before-running-agent/ Last updated: 2026-09-15T08:34:50.000Z 24시간 작동하는 AI 에이전트를 먼저 설치하면 일이 자동화되는 것이 아니라 권한이 자동화될 수 있다. 무엇을 읽고, 어떤 판단을 하고, 어디까지 실행하며, 누가 결과를 승인하는지 정한 뒤에야 에이전트가 업무가 된다. Edmund Yong은 [OpenClaw 활용 영상](https://www.youtube.com/watch?v=XmSxfFrkcDs&ref=zerodraftlab.com)에서 세 가지 흐름을 보여 준다. 제품 지표와 고객 메시지를 모은 아침 브리핑, 휴대폰에서 요청한 버그 수정과 커밋, 무료 사용자에게 보낼 이메일 시퀀스 초안이다. 모두 유용해 보이지만 필요한 권한과 실패 비용은 서로 다르다. ## 같은 자동화가 아니라 세 단계의 책임이다 브리핑은 여러 소스를 읽고 요약한다. 잘못돼도 사람이 원문을 확인하면 된다. 이메일 초안은 고객에게 영향을 줄 수 있지만 발송 전 검토 단계가 있으면 되돌릴 수 있다. 코드 수정과 커밋은 저장소 상태를 바꾸므로 테스트, 변경 범위, 리뷰, 배포 경계를 함께 설계해야 한다. 이 셋을 모두 “에이전트가 해 준 일”로 묶으면 통제가 흐려진다. 읽기, 초안, 변경, 외부 발송을 별도 등급으로 나누고 등급마다 허용 도구와 승인 지점을 정해야 한다. 처음에는 읽기 전용 브리핑처럼 실패 비용이 낮고 품질을 비교하기 쉬운 작업이 적합하다. ## 개인 봇도 외부 콘텐츠를 읽는 순간 공격 표면이 생긴다 [OpenClaw 공식 보안 문서](https://docs.openclaw.ai/security?ref=zerodraftlab.com)는 본인만 봇에 메시지를 보내더라도 웹페이지, 이메일, 문서, 첨부파일 같은 신뢰하지 않은 콘텐츠를 읽으면 prompt injection이 발생할 수 있다고 경고한다. 발신자만 믿을 것이 아니라 에이전트가 읽는 내용과 사용할 수 있는 도구를 함께 제한해야 한다. 공식 문서는 신뢰하지 않은 콘텐츠를 읽는 에이전트에는 읽기 전용 또는 도구 없는 구성을 쓰고, 파일·네트워크·브라우저 접근을 필요한 범위로 줄이며, 변경 뒤 보안 감사를 실행하라고 안내한다. Telegram 같은 채널 연결은 편리한 입력창이지 새로운 보안 경계가 아니다. 봇 토큰과 연결 권한도 자격증명으로 관리해야 한다. 이 경계는 설치 화면의 권한 목록만으로 완성되지 않는다. 에이전트가 어떤 업무를 맡았는지 정의하지 않으면 필요한 최소 권한도 계산할 수 없고, 실행 결과가 맞았는지 판정할 기준도 생기지 않는다. ## 업무 정의가 없으면 24시간 실행은 소음이 된다 좋은 자동화 후보는 입력과 완료 조건이 반복된다. 예를 들어 매일 같은 지표 다섯 개를 읽고, 전날 대비 변화와 확인할 이상치만 적는 브리핑은 평가하기 쉽다. 반면 “사업을 성장시켜 줘”는 필요한 정보, 허용 행동, 성공 기준이 모두 열려 있어 장시간 실행할수록 결과보다 검토 부담이 커진다. 실행 전에 네 줄이면 충분하다. 입력은 어디에서 오나. 허용된 동작은 무엇인가. 사람이 확인해야 할 지점은 어디인가. 실패하면 어떤 상태로 돌아가나. 이 네 가지를 답하지 못하면 아직 에이전트 문제가 아니라 업무 설계 문제다. ## 항상 켜져 있다는 것은 성능이 아니라 운영 책임이다 Yong은 관리형 호스팅으로 빠르게 에이전트를 연결하는 과정을 보여 주지만, 영상의 설치 속도와 스폰서 주장을 안전성 보장으로 볼 수는 없다. 지속 실행에는 비용 상한, 로그, 알림, 자격증명 회수, 권한 변경, 장애 때 정지하는 방법이 필요하다. 에이전트 도입의 첫 성과는 밤새 일했다는 사실이 아니다. 같은 입력에서 사람이 검토할 수 있는 결과를 내고, 승인되지 않은 행동은 하지 않으며, 실패 뒤 원인을 추적할 수 있는가다. 24시간 가동은 그 조건을 통과한 업무에 마지막으로 붙이는 옵션이다. ## 최소 권한은 업무의 완료 조건에서 역산한다 아침 브리핑이 목적이라면 원본을 읽고 요약을 저장할 곳이면 충분하다. 이메일 초안이라면 발송 권한 없이 초안함까지만 열 수 있다. 코드 수정도 commit과 배포를 한 권한으로 묶을 이유가 없다. 원하는 결과에서 한 단계씩 거꾸로 올라가면 편의를 위해 붙인 권한과 업무에 꼭 필요한 권한이 갈린다. 이 구조에서는 자동화 실패도 더 작게 보인다. 요약이 틀렸는지, 초안이 기준을 어겼는지, 변경이 테스트를 깨뜨렸는지 각각 다른 영수증으로 남길 수 있다. 에이전트의 자율성은 권한을 넓혀 사람의 개입을 없애는 방향보다, 작업 단위를 좁혀 사람이 확인해야 할 불확실성을 줄이는 방향으로 커져야 한다. --- 주요 출처는 Edmund Yong의 [3 OpenClaw Workflows I Use to Run My Business](https://www.youtube.com/watch?v=XmSxfFrkcDs&ref=zerodraftlab.com)입니다. 영상 속 생산성·전환 효과와 호스팅 편의는 제작자의 경험 또는 스폰서 설명입니다. prompt injection, trust boundary, 도구 제한과 감사 기준은 [OpenClaw 공식 보안 문서](https://docs.openclaw.ai/security?ref=zerodraftlab.com)를 대조했습니다. 영상에 노출된 설정값이나 자격증명은 옮기지 않았습니다. ### 첫 100달러 MRR은 수익보다 퍼널을 보여준다 URL: https://zerodraftlab.com/first-mrr-reveals-the-funnel/ Last updated: 2026-09-15T08:34:51.000Z 첫 100달러 MRR은 사업의 승리 선언보다 측정 장치에 가깝다. 방문자가 가입하고 결제하는 경로를 숫자로 볼 수 있게 만들기 때문이다. 매출이 작아도 퍼널이 보이면 다음 실험은 구체적이 된다. Edmund Yong은 [수익형 앱 제작 영상](https://www.youtube.com/watch?v=%5FtLJR5OaiCw&ref=zerodraftlab.com)에서 유튜브 영상을 번역하는 브라우저 확장 Fluently를 만든다. 자신이 겪은 문제에서 시작해 경쟁 제품과 사용자 불만을 확인하고, 가장 작은 완결 제품을 출시한 뒤 여러 유통 채널을 시험한다. ## 아이디어 검증은 존재 여부보다 불만의 모양을 본다 비슷한 제품이 있다는 사실은 수요의 한 단서일 뿐이다. 더 중요한 것은 사용자가 무엇 때문에 기존 제품을 떠나는지다. 번역 품질, 처리 시간, 가격, 설치 과정 중 어느 문제가 반복되는지 알아야 작은 제품의 첫 약속을 정할 수 있다. Yong은 제품을 진통제, 비타민, 사탕에 비유하고 자신이 자주 쓰는 문제를 골랐다. 이 분류가 시장을 자동으로 검증해 주지는 않는다. 그래도 첫 기능을 정할 때 “흥미로운 기술인가” 대신 “사용자가 지금 어떤 불편을 없애려고 돈이나 시간을 쓰는가”를 묻게 한다. ## 출시 채널마다 다른 질문에 답한다 그는 X, Product Hunt, LinkedIn, Reddit을 차례로 시도했다. Product Hunt에서는 85표와 당일 13위를 얻었다고 말하지만, 이것만으로 반복 가능한 고객 획득이 증명되지는 않는다. LinkedIn은 반응이 약했고 Reddit은 자기홍보 제약이 컸다. 같은 글을 여러 곳에 뿌리는 것보다 채널이 허용하는 행동과 사용자가 기대하는 맥락을 먼저 알아야 한다. 그 뒤 약 100달러를 광고에 써서 15만 회 노출, 400회 클릭, 26명 가입, 5명 결제, 약 100달러 MRR을 얻었다고 공개한다. 제작자 수치를 그대로 계산하면 노출 대비 클릭은 약 0.27%, 클릭 대비 가입은 6.5%, 가입 대비 결제는 약 19%다. 표본이 작고 한 번의 캠페인이므로 일반화할 전환율은 아니다. 이 숫자들이 유용한 이유는 비율이 높거나 낮아서가 아니라 서로 다른 실패를 분리해 주기 때문이다. 노출에서 클릭으로, 클릭에서 가입으로, 가입에서 결제로 넘어갈 때 고객은 각기 다른 약속을 확인한다. ## 매출과 광고 효율을 분리해야 한다 100달러를 써서 100달러 MRR을 만들었다고 즉시 손익분기라고 부를 수는 없다. 결제가 다음 달에도 유지되는지, 환불과 결제 수수료가 얼마인지, AI 처리 비용과 지원 시간이 얼마나 드는지 남아 있다. 반대로 첫 달 광고비만 보고 실패라고 단정할 수도 없다. 고객이 유지된다면 이후 월의 수익이 획득비를 회수할 수 있다. 이 사례가 알려 주는 것은 성공 확률이 아니라 다음에 물을 질문이다. 클릭이 적으면 광고와 타깃을, 가입이 적으면 랜딩과 온보딩을, 결제가 적으면 가치 체험과 가격을 고친다. 유지율이 없으면 아직 MRR이 아니라 첫 결제 실험에 가깝다. ## 첫 매출의 목적은 더 좋은 실험을 사는 것이다 Yong 자신도 초보자 대부분에게 유료 광고를 바로 권하지 않으며 이후에는 유기적 유통을 찾겠다고 말한다. 첫 100달러가 유용한 이유는 크기보다 경로에 있다. 아이디어, 제품, 채널, 결제 사이에서 어디가 끊기는지 관찰할 수 있게 했다. 작은 앱이 처음 기록해야 할 대시보드는 총 노출보다 단순하다. 유입 출처, 방문, 가입, 핵심 행동, 결제, 다음 달 유지, 환불, 변동비다. 이 일곱 숫자가 있으면 “사람들이 좋아한다”를 “어디에서 돈이 되는 행동이 멈추는가”로 바꿀 수 있다. ## 작은 표본에서는 고객 한 명의 경로가 평균보다 중요하다 결제자가 다섯 명일 때 한 명의 행동은 전환율을 크게 바꾼다. 이 시기에 소수점 비율을 최적화하면 정밀해 보이는 우연을 쫓기 쉽다. 각 결제자가 어떤 문구를 보고 왔고, 가입 뒤 어떤 행동을 했으며, 무엇 때문에 돈을 냈는지를 연결해서 보는 편이 다음 가설을 더 잘 만든다. 첫 MRR은 성장 그래프의 시작점이기 전에 측정 구조의 시험이다. 광고 플랫폼의 클릭, 제품의 가입, 결제 시스템의 거래가 같은 사용자의 여정으로 이어지지 않으면 퍼널은 숫자 목록일 뿐이다. 작은 매출이 남기는 가장 큰 자산은 금액보다, 이후 고객이 늘어도 같은 질문을 물을 수 있는 사건 기록이다. --- 주요 출처는 Edmund Yong의 [I Built a Profitable App From Scratch (Full Process)](https://www.youtube.com/watch?v=%5FtLJR5OaiCw&ref=zerodraftlab.com)입니다. 노출, 클릭, 가입, 결제, 광고비와 MRR은 제작자의 단일 캠페인 자기보고이며 광고 계정·결제 자료로 독립 검증되지 않았습니다. 본문의 전환율은 그 공개 숫자를 단순 계산한 값이고, 비용·해지·환불이 빠져 있어 순이익이나 지속 가능한 획득비로 해석하지 않았습니다. ### AI 앱의 48시간은 스토어 심사까지다 URL: https://zerodraftlab.com/app-store-review-defines-scope/ Last updated: 2026-09-15T08:34:52.000Z 48시간 안에 모바일 앱을 만들었다는 말은 대개 빌드가 끝났다는 뜻이다. 사용자가 받을 수 있는 제품이 됐다는 뜻은 아니다. 실제 기기에서 작동하고, 스토어 메타데이터가 맞고, 심사를 통과해야 비로소 출시다. Edmund Yong은 [48시간 모바일 앱 제작 영상](https://www.youtube.com/watch?v=Ibtlam1vFGI&ref=zerodraftlab.com)에서 아이디어를 고르고, 핵심 기능을 구현하고, 에뮬레이터와 실제 기기에서 시험한 뒤 App Store에 제출한다. 첫 제출은 계정 삭제, 앱 아이콘, 메타데이터 문제로 세 차례 반려됐고 수정 뒤 승인됐다고 말한다. ## 빠른 제작일수록 마지막 단계가 범위를 다시 정한다 Yong이 만든 것은 자신의 웹 제품을 보조하는 무료 모바일 앱이었다. 이미 있는 제품의 사용자와 문제를 알고 있었고, 처음부터 한두 개 핵심 기능만 골랐다. 이 조건이 48시간을 가능하게 했다. 낯선 시장의 수요 조사, 결제 설계, 고객지원 체계까지 이 시간 안에 끝낸 것은 아니다. 짧은 제작 일정에서는 스토어 심사를 마지막 체크박스로 미루기 쉽다. 그러나 계정 생성이 있으면 삭제 경로가 필요하고, 심사자가 기능을 확인할 수 있도록 계정과 설명을 제공해야 하며, 아이콘과 설명도 실제 앱과 일치해야 한다. [Apple의 App Review Guidelines](https://developer.apple.com/app-store/review/guidelines/?ref=zerodraftlab.com)는 제출 전에 앱 정보와 메타데이터를 완성하고, 계정 기반 기능에는 작동하는 데모 계정이나 전체 기능 데모 모드를 제공하라고 안내한다. ## 계정 삭제는 설정 화면 하나가 아니다 [Apple의 계정 삭제 안내](https://developer.apple.com/support/offering-account-deletion-in-your-app/?ref=zerodraftlab.com)에 따르면 계정 생성을 지원하는 앱은 앱 안에서 삭제를 시작할 수 있어야 한다. 단순 비활성화만 제공해서는 충분하지 않다. 관련 개인 데이터, 구독과 청구, Sign in with Apple 토큰까지 연결해서 생각해야 한다. 그러므로 로그인은 “나중에 붙일 기능”이 아니라 제품 범위를 키우는 결정이다. 초기 버전에 계정이 꼭 필요하지 않다면 로컬 저장이나 제한된 체험으로 시작할 수 있다. 필요하다면 가입과 동시에 삭제, 데이터 보존, 재인증, 구독 취소까지 하나의 기능 묶음으로 추정해야 한다. 이 묶음을 일정 끝에서 발견하면 반려는 예외가 아니라 누락된 범위를 알려 주는 뒤늦은 설계 검토가 된다. 심사 대응 시간을 줄이려면 제출 문서를 쓰기 전에 설치부터 삭제까지의 사용자 생애주기를 먼저 그려야 한다. ## 출시는 코드 밖에서 시작한다 작은 앱의 완료 조건은 기능 목록보다 전달 경로로 쓰는 편이 낫다. 실제 기기에서 핵심 흐름이 끝나는가, 심사자가 같은 흐름을 재현할 수 있는가, 스크린샷과 설명이 현재 버전을 반영하는가, 삭제와 개인정보 흐름이 있는가, 반려됐을 때 고칠 시간이 남아 있는가를 확인한다. Yong의 사례에서 가장 재사용할 만한 교훈은 특정 노코드 도구가 아니다. 빠르게 만들수록 배포와 심사를 별도 단계가 아니라 제품 설계에 포함해야 한다는 점이다. 48시간 MVP의 진짜 범위는 첫 빌드가 아니라 낯선 사용자가 설치할 수 있는 상태까지다. ## 반려 사유는 제품 경계에 대한 외부 피드백이다 아이콘과 설명의 불일치는 포장 실수처럼 보이지만, 심사자가 현재 제품을 재현할 정보가 없다는 뜻이기도 하다. 계정 삭제 누락은 설정 화면 하나의 결함이 아니라 가입 이후 데이터와 결제를 누가 책임지는지 정하지 않았다는 신호다. 반려 항목을 각각 고치기보다 어떤 제품 책임이 코드 밖으로 빠졌는지 묶어 봐야 같은 문제가 다음 버전에 돌아오지 않는다. 빠른 제작에서 줄여야 할 것은 핵심 책임이 아니라 가정의 수다. 첫 버전의 계정·기능·플랫폼을 좁히면 심사와 개인정보 흐름도 함께 작아진다. 출시 속도는 코드를 얼마나 빨리 만들었는지가 아니라, 외부 규칙까지 포함한 가장 작은 약속을 한 번에 통과시키는 능력에서 나온다. --- 주요 출처는 Edmund Yong의 [I Built a Mobile App in 48 Hours (No Code)](https://www.youtube.com/watch?v=Ibtlam1vFGI&ref=zerodraftlab.com)입니다. 제작 시간과 세 차례 반려 경험은 제작자의 자기보고입니다. 현재 심사 요건은 [Apple App Review Guidelines](https://developer.apple.com/app-store/review/guidelines/?ref=zerodraftlab.com)와 [계정 삭제 공식 안내](https://developer.apple.com/support/offering-account-deletion-in-your-app/?ref=zerodraftlab.com)를 대조했습니다. 영상에 등장한 제작 도구와 스폰서 주장은 일반적인 개발 속도 보장으로 다루지 않았습니다. ### UGC 제작비가 싸질수록 검수가 비싸진다 URL: https://zerodraftlab.com/cheap-ugc-makes-review-expensive/ Last updated: 2026-09-15T08:34:52.000Z AI 영상 도구는 짧은 광고 한 편을 만드는 비용을 낮춘다. 제작비가 내려간 자리에 곧바로 성과가 생기는 것은 아니다. 어색한 손, 과장된 대사, 근거 없는 약속, 브랜드와 맞지 않는 화자를 골라내는 일이 늘어난다. Edmund Yong은 [혼자 앱 광고를 만드는 영상](https://www.youtube.com/watch?v=xyKxB8q7wQk&ref=zerodraftlab.com)에서 Claude와 Higgsfield를 이용해 Create Skills의 짧은 UGC 형식 광고를 만든다. 그는 영상 생성에 약 5분과 몇 달러가 들었다고 말하며, 일반 UGC 제작자의 수백·수천 달러와 비교한다. 이 수치는 한 번의 자기보고이고 영상은 Higgsfield 홍보를 포함한다. ## 생성 전에 광고의 단위를 먼저 고른다 Yong은 광고를 hook, problem, solution, call to action 네 부분으로 나눈다. 첫 3초에는 특정 사용자가 자기 얘기라고 느낄 문장을 두고, 짧은 화면에는 제품의 한 동작만 보여준다. AI에는 다섯 개의 hook과 서로 다른 각도를 먼저 요청한 뒤 하나를 골라 영상으로 만든다. 이 순서에서 AI가 맡은 일은 선택지를 만드는 것이다. 누구를 부를지, 어떤 문제를 앞에 놓을지, 제품이 실제로 약속할 수 있는 범위는 사람이 정한다. 제품 설명이 모호하면 생성 속도가 빨라져도 모호한 광고만 더 많이 나온다. ## 첫 출력은 완성본이 아니라 검수 대기열이다 영상에서도 첫 결과의 손 모양과 동작이 어색해 다시 생성한다. 완성 뒤에는 Gemini에 영상을 넣어 hook, 에너지, 화면 자막, 제품 결과 설명을 비평하게 한다. 모델이 만든 광고를 다른 모델이 평가하는 구조다. 이 평가를 고객 반응으로 착각하면 안 된다. 모델은 영상의 구조적 결함을 찾는 보조 검수자가 될 수 있지만, 사람들이 멈춰 보고 클릭하고 결제할지는 실제 노출에서만 알 수 있다. 생성 모델과 평가 모델이 같은 관습을 공유하면 서로 비슷한 광고를 높게 평가할 가능성도 있다. 따라서 모델 검수의 역할은 승자를 고르는 것이 아니라 명백한 실패를 싸게 버리는 데 가깝다. 제품과 다른 화면, 읽히지 않는 자막, 약속을 증명하지 못하는 장면을 먼저 제거한 뒤에야 실제 고객 반응을 비교할 수 있다. ## 싸진 것은 렌더링이고 비싸진 것은 선별이다 UGC 생성비가 몇 달러로 내려가면 창업자는 더 많은 hook과 화자를 시험할 수 있다. 동시에 합성 인물 고지, 허위 후기처럼 보이는 연출, 제품 화면의 정확성, 음악·이미지 권리, 플랫폼 정책을 매번 확인해야 한다. 광고 한 편의 현금비용은 줄어도 검수하지 않은 한 편이 만드는 신뢰 비용은 줄지 않는다. Yong은 새 계정을 1\~2주 동안 관련 콘텐츠에 반응시켜야 낮은 조회수를 피할 수 있다고 조언한다. 이른바 계정 워밍업과 “view jail”은 영상에서 제시된 경험칙이며 플랫폼 공식 규칙이나 검증된 인과로 확인되지 않았다. ZDL은 이를 실행 지침으로 옮기지 않는다. AI 광고의 작업표에는 생성 수보다 먼저 각도, 대상, 약속, 검수자, 실제 반응을 적어야 한다. 제작비가 싸질수록 무엇을 내보내지 않을지 결정하는 비용이 광고의 원가가 된다. ## 생산량이 늘면 학습의 단위도 바뀐다 광고 열 편을 한꺼번에 만들고 화자, 배경, hook, CTA를 모두 바꾸면 조회수가 달라도 무엇이 작동했는지 알기 어렵다. 생성 비용이 낮다는 이유로 변수를 늘리면 콘텐츠는 많아지고 학습은 줄어든다. 한 번에 비교할 차이를 좁히고 나머지 조건을 남겨야 다음 편이 이전 편보다 나아질 근거가 생긴다. 또한 많이 만든 광고는 많이 보관하고 추적해야 한다. 어느 약속이 승인됐고 어떤 화면이 현재 제품과 맞는지, 어떤 소재가 이미 반복됐는지 기록하지 않으면 싼 제작물이 검수 부채와 브랜드 불일치를 쌓는다. AI UGC의 경쟁력은 생성 버튼의 속도가 아니라, 작은 실험을 버리고 배운 이유를 다음 선택에 전달하는 편집 체계에서 나온다. --- 주요 출처는 Edmund Yong의 [How I Make Marketing Ads for My Apps Solo](https://www.youtube.com/watch?v=xyKxB8q7wQk&ref=zerodraftlab.com)입니다. 제작 시간·비용과 UGC 외주비 비교는 제작자의 단건 자기보고입니다. 영상은 Higgsfield 홍보를 포함합니다. 계정 워밍업, view jail, hook 효과는 플랫폼 공식 자료나 통제 실험으로 확인되지 않아 경험칙으로만 표시했습니다. ### 작은 앱도 팔리지만 인수자는 코드를 사지 않는다 URL: https://zerodraftlab.com/buyers-need-transferable-small-apps/ Last updated: 2026-09-15T08:34:53.000Z 작은 앱이 팔릴 때 구매자가 사는 것은 코드 저장소 하나가 아니다. 매출이 어디서 나오고, 얼마나 자주 고장 나며, 창업자가 떠난 뒤에도 다른 사람이 운영할 수 있는지를 함께 산다. Edmund Yong은 [첫 스타트업 매각 영상](https://www.youtube.com/watch?v=wbvMph3m88Q&ref=zerodraftlab.com)에서 ChatGPT 대화에 폴더를 붙이는 브라우저 확장 Easy Folders를 매각한 과정을 설명한다. 그가 밝힌 누적 매출은 약 10만 달러, 매각가는 5자리 수다. 정확한 가격과 계약 조건은 공개하지 않았다. ## 부업으로 만든 기능이 현금흐름 자산이 됐다 Yong은 직장에 다니며 주말마다 확장을 만들고 고쳤다. Reddit, Facebook 그룹, OpenAI 포럼에서 제품을 알렸고 첫 결제를 받았다. 작은 매출은 퇴사를 바로 가능하게 한 돈이라기보다, 고용주를 위해서가 아니라 자신이 소유한 소프트웨어에도 누군가 돈을 낸다는 증거가 됐다고 회고한다. 문제는 플랫폼 의존성이었다. ChatGPT가 업데이트될 때마다 확장이 깨질 수 있었고, OpenAI가 Projects 기능을 내놓자 폴더 기능의 희소성이 낮아졌다. Yong은 다른 제품에 집중할 시간과 생활비 runway를 얻기 위해 매각을 선택했다. ## 매각 시점에는 현재 매출보다 방향도 붙는다 그는 Acquire.com과 창업자 네트워크에 매물을 알렸고, 진지한 구매자를 찾는 데 약 한 달이 걸렸다고 말한다. 가장 아쉬웠던 점은 성장세가 멈춘 뒤에 팔기 시작한 것이었다. 매출이 남아 있어도 상승하는 제품보다 미래를 설명하기 어려웠고, 그 때문에 가격에서 수천 달러를 놓쳤다고 추정한다. 이것은 성장 중일 때 무조건 팔아야 한다는 공식이 아니다. 다만 매수자는 과거 매출표와 함께 인수 뒤의 방향을 산다. 성장률이 내려가면 가격은 현금흐름뿐 아니라 새 운영자가 다시 성장시킬 가능성에 더 크게 의존한다. 그 가능성은 발표 자료보다 인수자가 실제로 이어받을 수 있는 상태에서 판별된다. 매출의 원인이 창업자의 개인 계정과 관계, 수동 대응, 머릿속 예외 처리에 묶여 있다면 거래 뒤 같은 숫자가 반복될 근거가 약해진다. ## 인수자는 창업자 없이 작동하는지를 확인한다 구매자가 물은 항목은 매출, 트래픽, 고객지원량, 유지보수 시간, 성장률, 자산 이전 가능성이었다. 계약 뒤에는 코드, 도메인, 결제 계정, 운영 문서를 넘겼다. 제품이 창업자의 기억 속 절차에 의존할수록 인수 뒤 위험이 커진다. 그래서 매각 준비는 구매자를 찾기 전에 시작된다. 수익과 비용이 분리돼 있고, 계정 소유권을 이전할 수 있으며, 장애 처리와 배포 방법을 다른 사람이 읽을 수 있어야 한다. 같은 매출을 내는 앱이라도 한 달에 한 번 확인하면 되는 제품과 매일 창업자가 고쳐야 하는 제품은 다른 자산이다. ## 작은 매각은 성공담보다 선택권에 가깝다 Easy Folders의 매각가는 인생을 바꿀 규모가 아니었다고 Yong은 말한다. 대신 다음 제품을 만들 시간을 샀다. 부업이 제품이 되고, 제품이 작은 현금흐름을 만들고, 그 운영권을 넘겨 다음 실험의 runway로 바뀌었다. 이 사례 하나로 브라우저 확장의 일반적인 매각 배수나 성공 확률을 계산할 수는 없다. 공개된 것은 한 창업자의 자기보고이고 구매자의 재무·계약 검증 자료는 보이지 않는다. 그래도 매각 가능한 작은 앱의 조건은 드러난다. 코드가 아니라 현금흐름과 운영 책임을 다른 사람에게 넘길 수 있어야 한다. ## 인수 준비는 창업자의 숨은 보조금을 드러낸다 작은 제품의 이익에는 창업자가 무료로 제공한 노동이 빠지기 쉽다. 새 고객을 직접 설득한 시간, 플랫폼이 바뀔 때 급히 고친 밤, 문서 없이 처리한 환불을 비용으로 되돌려 보면 현금흐름의 성격이 달라진다. 구매자는 그 노동을 계속 제공할 수 없으므로 인수 뒤 필요한 시간을 다시 가격에 넣는다. 이 계산은 매각할 생각이 없어도 유용하다. 계정과 비용을 분리하고, 반복 장애를 기록하고, 다른 사람이 배포를 재현하게 만들면 제품이 창업자에게 요구하는 보조금이 보인다. 매각 가능성은 특별한 exit 전략이라기보다, 사업이 소유자의 기억과 긴급 노동 없이도 같은 약속을 지킬 수 있는지 묻는 운영 테스트다. --- 주요 출처는 Edmund Yong의 [My First Startup Exit: $100K Revenue, 5-Figure Sale](https://www.youtube.com/watch?v=wbvMph3m88Q&ref=zerodraftlab.com)입니다. 매출, 매각가 범위, 거래 기간, 가격 손실 추정은 제작자의 자기보고입니다. 구매자, 정확한 계약 금액, 비용, 세금, 거래 문서는 공개되지 않아 독립 검증된 exit 사례로 취급하지 않았습니다. ### AI 코딩의 병목은 생성보다 안전한 실험이다 URL: https://zerodraftlab.com/ai-coding-needs-safe-experiments/ Last updated: 2026-09-15T08:34:54.000Z AI 코딩 도구가 한 번에 더 많은 파일을 바꿀수록 생성 속도보다 실험 장소가 중요해진다. 운영 데이터 위에서 새 검색 기능을 시험하다가 잘못된 쿼리 하나를 실행하면, 빨리 만든 기능보다 복구할 일이 먼저 생긴다. Edmund Yong은 [자신의 AI 코딩 워크플로 영상](https://www.youtube.com/watch?v=qHDjSTqs7Bc&ref=zerodraftlab.com)에서 저장한 자료를 분류하고 검색하는 기능을 만든다. 브라우저 확장으로 모은 글과 영상을 markdown으로 바꾸고, MCP 서버를 통해 에이전트가 필요한 자료를 찾게 하는 제품이다. ## 자료를 많이 저장하면 다음 병목은 회수다 처음에는 웹 자료를 한곳에 저장하는 것만으로 쓸모가 있었다. 자료가 늘자 목록은 다시 검색해야 할 창고가 됐다. Yong은 에이전트가 비슷한 자료를 폴더로 묶고, 현재 작업에 맞는 출처를 점수화해 돌려주는 기능을 추가한다. 이 변화는 저장량과 활성 문맥이 다르다는 점을 보여준다. 모든 자료를 매번 프롬프트에 넣는 대신, 작업할 때 필요한 몇 개를 찾는다. 다만 “유용함” 점수가 정확한지는 별도 문제다. 잘못 정리된 폴더와 검색 결과가 반복되면 에이전트는 정돈된 형태의 오류를 계속 참고할 수 있다. ## 운영 데이터와 닮은 샌드박스가 필요하다 Yong은 실제 데이터로 기능을 확인하되 운영 DB를 직접 건드리지 않기 위해 Ghost라는 개발 도구로 임시 PostgreSQL 데이터베이스를 만들고 버린다. [Ghost 공식 문서](https://ghost.build/docs/?ref=zerodraftlab.com)도 에이전트가 격리된 데이터베이스를 생성·복제·삭제하는 개발 흐름을 제공한다고 설명한다. 격리 DB는 실수의 범위를 줄이지만 기능의 안전을 보증하지는 않는다. 어떤 운영 데이터를 복제했는지, 개인정보가 포함됐는지, schema와 확장이 같은지, 테스트 뒤 무엇이 남는지 확인해야 한다. 여러 DB를 동시에 돌릴 수 있다는 사실도 비용 상한과 종료 조건 없이 병렬 실행해도 된다는 뜻이 아니다. 따라서 좋은 샌드박스는 운영 환경과 완전히 다른 장난감도, 운영 환경을 그대로 복제한 두 번째 위험도 아니다. 이번 실험이 깨뜨릴 수 있는 조건만 충분히 닮고, 실패했을 때 폐기할 수 있도록 데이터와 권한의 범위를 줄인 환경이다. ## 에이전트의 자율성은 폐기 가능한 환경에서 먼저 늘린다 이 워크플로의 실용적인 부분은 에이전트에게 운영 권한을 더 주는 데 있지 않다. 실패해도 버릴 수 있는 환경을 먼저 만들고 그 안에서 작업 범위를 넓힌다. DB뿐 아니라 branch, worktree, 미리보기 배포, 임시 계정도 같은 역할을 한다. Yong은 당시 Codex를 큰 기능의 계획·구현·테스트에, Cursor를 손수 고치는 편집기에 사용한다고 말한다. 모델 우열과 도구 선호는 2026년 5월 개인 경험이다. 어떤 모델을 쓰든 마지막 안전선은 변경 diff, 테스트 결과, 권한 범위, 비용과 데이터 read-back이다. AI 코딩의 속도는 생성된 코드 줄 수로 쉽게 보인다. 안전한 실험 환경이 줄인 복구 시간은 눈에 덜 띈다. 혼자 운영하는 제품에서는 두 번째 숫자가 더 오래 사업을 살린다. ## 샌드박스도 현실의 위험을 선택해서 닮아야 한다 검색 품질을 시험한다면 실제와 비슷한 자료 분포와 잘못된 분류 사례가 필요하다. 권한을 시험한다면 서로 다른 사용자와 거절 경로가 있어야 한다. 단지 빈 데이터베이스에서 쿼리가 성공했다는 결과는 운영 환경의 안전보다 코드가 실행됐다는 사실만 보여 준다. 반대로 모든 운영 데이터를 복제하면 실험 환경이라는 이름 아래 개인정보와 비용을 다시 늘린다. 테스트에 필요한 최소 표본을 만들고, 복제 이유와 폐기 시점을 기록하며, 운영 반영 전에는 diff와 migration·rollback 경로를 다시 확인해야 한다. 자율성의 크기는 에이전트가 할 수 있는 일보다 실패 뒤 남는 상태로 측정하는 편이 정확하다. --- 주요 출처는 Edmund Yong의 [My AI Coding Workflow — Everything I Use Now](https://www.youtube.com/watch?v=qHDjSTqs7Bc&ref=zerodraftlab.com)입니다. 임시 데이터베이스 기능은 [Ghost 공식 문서](https://ghost.build/docs/?ref=zerodraftlab.com)를 대조했습니다. 특정 모델의 성능, 도구 선호, 무료 사용량은 영상 게시 시점의 제작자 관찰 또는 업체 조건이며 일반 벤치마크로 다루지 않았습니다. ### 첫 수익형 앱의 교과과정은 코드로 끝나지 않는다 URL: https://zerodraftlab.com/profitable-app-curriculum-exceeds-code/ Last updated: 2026-09-15T08:34:55.000Z AI가 코드를 써주면 첫 수익형 앱을 만드는 데 무엇을 배워야 할까. 프레임워크를 하나 더 외우는 일보다, AI가 만든 결과를 검토하고 제품을 세상에 내놓는 데 필요한 최소 지식을 고르는 편이 먼저다. Edmund Yong은 [2026년에 첫 수익형 앱을 다시 시작한다면 배울 것](https://www.youtube.com/watch?v=FEc4EW9s2BU&ref=zerodraftlab.com)을 기술 기초, 제작 도구, 유통으로 나눈다. 앞서 공개한 [첫 수익형 앱 로드맵](https://www.youtube.com/watch?v=CNsvts6pVzo&ref=zerodraftlab.com)에서는 문제 정의, 기술 선택, 결제, 배포, 랜딩페이지, 피드백을 한 흐름으로 묶었다. 그는 4년의 소프트웨어 엔지니어 경력과 컴퓨터과학 학위가 있었고, 1년 남짓 혼자 앱을 운영해 25만 달러 이상의 매출과 한 차례의 5자리 수 매각을 경험했다고 밝힌다. ## AI를 쓰기 위해서도 시스템의 경계는 알아야 한다 Yong이 먼저 고른 기술 기초는 API, 데이터베이스, Git이다. API에서는 누가 어떤 입력으로 동작을 호출하는지, 데이터베이스에서는 사용자 권한과 데이터 격리를, Git에서는 변경 이력과 복구 방법을 이해하라고 한다. 목표는 모든 코드를 손으로 쓰는 개발자가 되는 것이 아니다. 결제 정보가 잘못 저장됐는지, 다른 사용자의 데이터가 보이는지, 에이전트가 한꺼번에 바꾼 파일을 되돌릴 수 있는지 판단할 만큼 시스템을 읽는 것이다. 자연어로 화면을 만드는 능력과 운영 중인 제품을 책임지는 능력 사이에는 이 지식이 놓인다. ## 도구 목록은 교과과정이 될 수 없다 영상에는 Lovable, Bolt, Codex, Claude Code, Cursor, Supabase, Convex, Vercel, Stripe 등 많은 도구가 나온다. Yong은 노코드 도구를 아이디어 탐색과 프로토타입에 쓰고, 실제 사용자 데이터와 결제를 다루기 시작하면 코드 에이전트와 전용 인프라로 옮기는 방식을 제안한다. 도구 이름은 빠르게 바뀐다. 반면 인증된 요청, 데이터 권한, 버전 관리, 결제 이벤트, 배포 후 오류 같은 문제는 남는다. 어떤 도구를 배우느냐보다 제품이 돈과 데이터를 다루기 시작할 때 어느 책임이 생기는지 배우는 편이 오래간다. ## 수익형이라는 말의 최소 단위는 첫 결제다 Yong은 초보자의 첫 수익형 앱을 “고통스러운 문제 하나를 해결하고 결제 고객 한 명을 얻은 작은 제품”으로 정의한다. 큰 ARR이나 자동화된 회사가 아니다. 자신이 겪는 문제를 골라 빠르게 만들고, 창업자가 직접 데모와 튜토리얼을 배포하며, 일찍 가격을 붙이는 순서다. 그래서 기술 다음에는 랜딩페이지 카피, 제품 데모, 소셜 콘텐츠, SEO와 AEO가 온다. 코드를 완성한 뒤 마케팅을 시작하는 것이 아니라, 어떤 언어로 고객을 부를지와 어디서 발견될지를 제품과 함께 만든다. 여기서 교과과정의 순서는 고정된 강의 목록이 아니라 다음 실패의 비용으로 정해야 한다. 아직 결제 한 건도 없다면 대규모 인프라보다 고객에게 약속을 설명하는 능력이 급하고, 사용자 데이터가 들어오기 시작했다면 권한과 복구가 곧 제품 기능이 된다. ## 이 로드맵은 완전한 초보자의 실험 결과가 아니다 Yong은 자신의 출발점이 완전한 초보가 아니었다고 먼저 밝힌다. 그가 제시한 과정은 경험자가 과거를 돌아보며 압축한 로드맵이지, 개발 경험이 없는 사람이 같은 기간과 결과를 재현했다는 증거가 아니다. 25만 달러 매출과 매각 금액도 영상에서 밝힌 자기보고다. 그래도 학습 순서는 분명하다. AI가 대신 만들 수 없는 모든 지식을 공부하는 것이 아니라, 위험을 알아보고, 작은 제품을 출시하고, 첫 결제를 받은 뒤, 실제 오류와 고객 반응에서 다음 지식을 고른다. 첫 앱의 교과과정은 코드베이스가 아니라 출시 뒤 생긴 책임에서 완성된다. ## 학습 부채는 운영 부채보다 먼저 갚을 필요가 없다 초보자는 모르는 것이 많다는 사실 때문에 출시를 미루기 쉽다. 그러나 당장 발생하지 않은 문제를 모두 공부하는 것도 추측에 자원을 쓰는 일이다. 반대로 인증과 결제를 붙여 놓고 권한 모델이나 환불 흐름을 모른 채 사용자부터 모으는 것은 학습 부채를 고객에게 전가한다. 경계는 실제 책임이 시작되는 시점이다. 공개 데모에서는 되돌리기와 설명 능력이 중요하고, 계정이 생기면 데이터 격리와 삭제가, 결제가 생기면 가격·환불·비용 추적이 필요해진다. AI 시대의 최소 학습은 얕은 지식의 긴 목록이 아니라, 제품이 새 책임을 얻을 때 그 책임을 읽고 멈출 수 있는 능력이다. --- 주요 출처는 Edmund Yong의 [Everything I’d Learn to Ship My First Profitable App in 2026](https://www.youtube.com/watch?v=FEc4EW9s2BU&ref=zerodraftlab.com)과 [How I Code Profitable Apps Solo](https://www.youtube.com/watch?v=CNsvts6pVzo&ref=zerodraftlab.com)입니다. 경력, 누적 매출, 매각, 운영 성과는 제작자의 자기보고이며 독립 감사된 재무 수치가 아닙니다. 영상에 나온 도구 추천은 각 게시 시점의 제작자 선택으로만 다뤘습니다. ### 취향은 프롬프트가 아니라 비교에서 자란다 URL: https://zerodraftlab.com/taste-grows-through-comparison/ Last updated: 2026-09-15T08:34:56.000Z AI가 만든 화면이 밋밋할 때 프롬프트에 “더 세련되게”를 붙여도 결과는 크게 달라지지 않는다. 세련됨이 어떤 화면, 간격, 순서, 상태 변화를 뜻하는지 입력하지 않았기 때문이다. Edmund Yong은 [디자이너 없이 앱을 다듬는 영상](https://www.youtube.com/watch?v=-ZeY0vUlt24&ref=zerodraftlab.com)에서 프롬프트보다 비교 자료를 먼저 넣는다. 경쟁 제품의 피드, 생산성 앱의 온보딩, 결제 화면을 찾아 AI 에이전트가 공통점과 차이를 분석하게 한 뒤 자기 제품에 적용할 항목을 고른다. ## 참고 화면은 정답지가 아니라 어휘집이다 영상은 Mobbin의 화면 자료와 MCP 서버를 사용한다. [Mobbin 공식 문서](https://docs.mobbin.com/mcp/introduction?ref=zerodraftlab.com)에 따르면 MCP 서버는 실제 제품 화면을 자연어로 검색해 AI 도구에 이미지로 돌려주며 유료 플랜에서 제공된다. Yong의 영상도 Mobbin을 홍보하는 내용을 포함한다. 그가 보여주는 작업은 복사보다 비교에 가깝다. 먼저 자기 화면과 해결할 부분을 좁힌다. 경쟁 제품 몇 개에서 같은 흐름을 찾고, 빌릴 패턴과 피할 패턴을 나눈다. 마지막으로 현재 제품에 맞는 변경만 제안하게 한다. “좋은 디자인을 만들어줘”라는 주문을 “이 피드의 정보 밀도를 세 제품과 비교해라”라는 조사로 바꾼 셈이다. ## 출시된 화면이 효과가 검증된 화면은 아니다 유명 앱이 쓴 패턴에는 전문가의 시간이 들어갔을 가능성이 크다. 그렇다고 스크린샷만 보고 그 패턴이 가입률이나 결제를 높였다고 결론낼 수는 없다. 실험 결과, 대상 사용자, 이전 버전, 실패한 시안은 자료실에 보이지 않는다. 표본에도 편향이 있다. 눈에 잘 띄는 소비자 앱만 따라가면 업무용 제품에 불필요한 애니메이션과 단계가 늘 수 있다. 여러 앱에서 반복되는 관습은 사용자가 익숙할 가능성을 알려주지만, 자기 제품의 문제를 해결한다는 증거는 아니다. 그래서 참고 화면을 적용할 때는 모양보다 이유를 적어야 한다. 첫 화면에서 권한 요청을 늦춘 이유, 결제 전에 기능 차이를 보여주는 이유, 피드에서 부가 정보를 접은 이유를 설명하지 못하면 패턴을 가져온 것이 아니라 장식을 옮긴 것이다. 그 이유를 적는 순간 참고 화면은 취향의 증거에서 가설의 재료로 바뀐다. 같은 패턴을 쓴 제품이 많다는 사실보다, 그 패턴이 지금 제품의 어느 마찰을 줄일 것인지가 비교의 중심이 된다. ## 취향은 많이 보는 것보다 결과를 비교할 때 남는다 Yong은 반복해서 좋은 화면을 보며 무엇이 자연스러운지 감각이 생겼다고 말한다. 여기에 한 단계가 더 필요하다. 참고 전후에 사용자가 과업을 끝내는 시간, 이탈하는 단계, 오류와 문의가 어떻게 달라졌는지 봐야 한다. 시각적 취향과 제품 판단은 같은 능력이 아니다. AI 에이전트는 자료를 찾고 차이를 정리하는 시간을 줄일 수 있다. 무엇을 빌릴지, 누구에게 맞는지, 결과가 나아졌는지는 제품을 운영하는 사람이 책임진다. 취향은 멋진 화면을 많이 저장한 목록보다 비교와 결과 사이에 남은 판단 기록에 가깝다. ## 자료가 많아질수록 기준은 더 좁아져야 한다 수십 개 화면의 평균을 내면 무난한 UI는 만들 수 있어도 중요한 선택은 흐려진다. 가입을 서두르는 제품과 신뢰를 먼저 쌓아야 하는 제품, 매일 쓰는 도구와 한 번만 쓰는 도구는 같은 온보딩을 공유할 이유가 없다. 좋은 비교는 닮은 화면을 많이 모으는 일이 아니라, 서로 다른 제약을 가진 사례를 의도적으로 제외하는 일까지 포함한다. 따라서 디자인 기록에는 채택한 패턴만큼 버린 패턴과 이유가 남아야 한다. 다음 변경에서 결과가 나빠졌을 때 무엇을 되돌릴지 알 수 있고, 다른 사람이 “유명 앱도 이렇게 한다”는 말로 맥락을 지우는 것도 막는다. 취향은 선택의 일관성이 아니라, 결과가 달라지면 선택을 고칠 수 있는 비교 기준이다. --- 주요 출처는 Edmund Yong의 [How To Make Your Apps Beautiful Without a Designer](https://www.youtube.com/watch?v=-ZeY0vUlt24&ref=zerodraftlab.com)입니다. Mobbin MCP의 기능·지원 방식·유료 플랜 조건은 [Mobbin 공식 문서](https://docs.mobbin.com/mcp/introduction?ref=zerodraftlab.com)를 확인했습니다. 영상은 제품 홍보를 포함하며, 특정 화면 패턴의 전환 효과는 공개된 실험 결과가 아니라 제작자의 해석입니다. ### AI 에이전트가 못 찾는 앱은 없는 앱과 비슷하다 URL: https://zerodraftlab.com/agents-cannot-use-hidden-apps/ Last updated: 2026-09-15T08:34:56.000Z 사람이 앱을 쓰려면 먼저 검색하거나 추천받고, 설명을 읽어 이해한 뒤, 화면에서 행동할 수 있어야 한다. AI 에이전트도 순서는 비슷하다. 다만 화면을 보는 대신 공개 문서와 HTML 구조를 읽고, API나 도구 호출로 행동한다. Edmund Yong은 [AI 시대에 앱을 최적화하는 방법](https://www.youtube.com/watch?v=PnfOdYoZxeE&ref=zerodraftlab.com)을 세 질문으로 정리한다. 에이전트가 앱을 찾을 수 있는가, 무엇을 하는지 이해할 수 있는가, 실제로 사용할 수 있는가. 그는 이를 findable, legible, usable로 나눈다. ## 찾을 수 있다는 말은 검색 결과에 뜬다는 뜻보다 넓다 첫 단계는 제품의 공개 설명을 분명하게 만드는 일이다. 어떤 고객이 어떤 작업에 쓰고, 무엇과 연결되며, 어떤 결과를 얻는지 랜딩페이지에 적는다. “업무를 혁신하는 AI”처럼 대상을 숨긴 문구는 사람에게도 모호하고 검색 시스템에도 분류할 단서가 적다. Yong은 페이지가 HTTP 200을 반환하는지, robots.txt가 필요한 수집기를 막는지, sitemap에 홈·가격·문서 페이지가 들어 있는지를 먼저 확인하라고 한다. 여기서 모든 AI 봇을 허용해야 한다는 결론은 나오지 않는다. 검색 노출, 학습 수집, 저작권, 서버 비용을 구분한 뒤 허용 범위를 정해야 한다. 중요한 것은 의도하지 않은 차단과 의도한 정책을 구별하는 것이다. ## 읽을 수 있는 화면은 구조가 역할을 말한다 두 번째 단계는 페이지가 자기 구조를 설명하게 만드는 일이다. 버튼은 `button`, 이동은 링크, 입력은 `form`, 제목은 heading으로 표현한다. [MDN의 semantic HTML 설명](https://developer.mozilla.org/en-US/docs/Glossary/Semantics?ref=zerodraftlab.com)처럼 알맞은 요소는 코드에 역할을 남기고, 검색엔진과 보조기술이 구조를 해석하는 단서가 된다. semantic HTML만 쓴다고 에이전트가 제품을 정확히 이해하는 것은 아니다. 시작 방법, 주요 흐름, 자주 나는 오류, 입력과 결과의 예시가 담긴 짧은 문서가 함께 있어야 한다. 화면의 구조와 제품의 설명은 서로 다른 층이다. ## 사용 가능성은 인터페이스보다 권한에서 갈린다 마지막 단계에서 Yong은 API, CLI, MCP를 후보로 든다. API는 외부 시스템이 핵심 동작을 호출하게 하고, CLI는 터미널에 익숙한 사용자의 작업을 줄인다. MCP 서버는 에이전트가 발견하고 호출할 도구의 이름과 입력 구조를 제공한다. [MCP 공식 구조](https://modelcontextprotocol.io/specification/2025-06-18/architecture?ref=zerodraftlab.com)도 서버가 도구·리소스·프롬프트를 노출하고 호스트가 권한과 연결을 통제하는 형태로 설명한다. 인터페이스를 하나 더 만들면 공격 표면도 하나 늘어난다. 처음부터 제품 전체를 열기보다 외부 사용 가치가 큰 한두 동작만 고르고, 인증, 입력 검증, rate limit, 실행 기록, 오류 복구를 붙여야 한다. 사람용 화면과 에이전트용 도구가 서로 다른 데이터 규칙을 가지면 제품 로직도 두 벌이 된다. 이 때문에 발견성, 가독성, 사용 가능성을 각자 따로 개선해서는 충분하지 않다. 공개 설명이 약속한 작업이 도구 호출로 이어지고, 그 호출이 사람용 화면과 같은 권한 규칙 안에서 끝나는지 하나의 경로로 확인해야 한다. ## 에이전트용 앱은 별도 제품이 아니다 findable, legible, usable은 에이전트 전용 유행어라기보다 기존 제품 위생을 다른 소비자에게 확장한 것이다. 명확한 카피, semantic HTML, 공개 문서, 좁고 안전한 API는 사람과 검색엔진에도 도움이 된다. Yong은 자신의 앱에 MCP를 붙인 뒤 사용과 참여가 늘었다고 말하지만 측정 기간과 수치는 공개하지 않았다. 이 경험을 “MCP를 만들면 매출이 오른다”로 바꿀 수는 없다. 에이전트 인터페이스의 첫 검증값은 설치 수가 아니라 사람이 하던 실제 작업을 권한 침범 없이 끝냈는지다. ## 발견성의 최종 검증은 호출 영수증이다 에이전트가 제품 이름을 언급했다고 해서 발견 문제가 해결된 것은 아니다. 공개 페이지에서 용도를 알아내고, 올바른 문서를 골라 읽고, 필요한 도구를 선택하고, 허용된 입력으로 결과를 만든 단계가 이어져야 한다. 어느 단계에서 멈췄는지를 남기지 않으면 노출 문제와 권한 문제를 같은 카피 수정으로 고치게 된다. 그래서 에이전트 인터페이스의 운영 지표는 검색 노출만으로 끝나지 않는다. 어떤 설명을 읽고 어떤 도구를 골랐는지, 호출이 왜 거절됐는지, 사람이 다시 고친 입력은 무엇인지가 다음 제품 결정을 만든다. 에이전트용 최적화는 새 채널에 제품을 포장하는 일이 아니라, 제품이 이미 갖고 있던 약속과 권한 사이의 틈을 드러내는 감사에 가깝다. --- 주요 출처는 Edmund Yong의 [How To Optimize Your Apps For The “AI Era”](https://www.youtube.com/watch?v=PnfOdYoZxeE&ref=zerodraftlab.com)입니다. semantic HTML은 [MDN](https://developer.mozilla.org/en-US/docs/Glossary/Semantics?ref=zerodraftlab.com), MCP의 host-client-server 구조와 보안 경계는 [Model Context Protocol 공식 명세](https://modelcontextprotocol.io/specification/2025-06-18/architecture?ref=zerodraftlab.com)를 대조했습니다. 에이전트 사용 증가와 매출 가능성은 영상 제작자의 관찰·기대이며 독립 검증된 성과로 다루지 않았습니다. ### 광고비를 쓰기 전에 증거부터 만들어라 URL: https://zerodraftlab.com/proof-before-ad-spend/ Last updated: 2026-08-30T02:57:45.000Z [**Daniel Priestley의 22분 비즈니스 플레이북**](https://www.youtube.com/watch?v=WiTIgjYxWbE&ref=zerodraftlab.com)은 광고를 마지막 단계에 둔다. 먼저 과거의 성과에서 증거를 찾고, 그 경험을 상품으로 묶고, 관심과 판매 전환을 측정한 뒤에야 유료 확장 비용을 계산한다. 영상 제목은 백만 달러를 약속하지만, 본문에서 쓸 만한 부분은 성공담보다 순서다. 이 글은 Priestley가 제시한 순서를 따라가되, 그의 사례와 수치는 같은 조직의 마케팅 자료라는 경계도 함께 적는다. ## 첫 단계는 증거 이야기다 Priestley는 최근 5년을 돌아보며 자신이 특별한 결과를 만들었던 장면을 찾으라고 한다. 그가 말하는 *proof story*에는 네 가지가 들어간다. 누구에게 필요한 결과인지, 결과를 숫자로 표현할 수 있는지, 그 결과에 이름을 붙일 수 있는지, 과정을 단계별로 설명할 수 있는지다. 특정 고객에게 어떤 결과를 만들었고, 그 과정을 다시 설명할 수 있어야 한다. Priestley는 이 이야기가 개인의 경험과 방법을 담은 지식자산의 출발점이라고 본다. ## 경험을 배우는 상품과 실행하는 상품으로 나눈다 다음 단계에서는 같은 지식자산을 두 상품으로 나눈다. *product for prospects*는 잠재고객이 방법과 증거를 배우는 입구다. 웨비나, 진단, 짧은 강의가 여기에 들어간다. *core offering*은 그 방법을 실제로 전달하는 본상품이다. 대행, 소프트웨어, 물리적 제품, 컨설팅처럼 전달 방식은 달라질 수 있다. 앞의 상품은 “이 사람이 무엇을 알고 있는가”를 확인하게 하고, 본상품은 “그 결과를 내 상황에 적용하면 무엇을 받는가”를 답한다. 이 연결이 없으면 소개 콘텐츠와 유료 상품 사이가 끊긴다. ## 관심은 노출에서 끝나지 않는다 Priestley는 관심을 *noticed, known, rated*의 세 단계로 설명한다. 먼저 존재를 알아차리고, 긴 콘텐츠를 통해 방법을 이해하고, 다른 사람의 평가와 연관 브랜드를 통해 신뢰를 판단한다. 영상에서는 90일 안에 짧은 콘텐츠를 11번 봐야 처음 알아차린다는 수치도 제시한다. 출처가 제시되지 않아 보편 법칙으로 받아들일 근거는 부족하다. 운영상 쓸 수 있는 판단은 더 좁다. 한두 번 올린 콘텐츠로 시장의 무관심을 판정하지 말고, 짧은 콘텐츠가 증거와 본상품을 설명하는 긴 콘텐츠로 이어지는지 확인해야 한다. ## 랜딩페이지는 관심 신호를 받는 곳이다 관심을 얻은 뒤에는 사람들이 다음 행동을 선택하게 해야 한다. Priestley가 제시한 랜딩페이지의 네 요소는 훅, 가치제안, 신뢰 근거, 행동 요청이다. 불편이나 원하는 결과를 짚고, 무엇을 더 낫게 만들 수 있는지 설명하고, 그 약속을 믿을 근거를 붙인 다음 진단·워크숍·대기명단 같은 한 가지 행동으로 보낸다. 조회수와 좋아요는 약한 신호다. 연락처를 남기고, 진단을 시작하고, 상담 시간을 잡는 행동은 판매 과정으로 이어질 수 있다. 랜딩페이지는 관심을 다음 단계의 숫자로 바꾼다. ## 판매는 LAPS로 읽는다 Priestley는 판매 과정을 LAPS로 기록한다. *Leads, Appointments, Presentations, Sales*, 즉 리드가 몇 건 생겼고, 몇 건이 약속으로 이어졌으며, 실제 제안을 몇 번 보여줬고, 그중 몇 건이 결제됐는지를 본다. 이 숫자가 있어야 병목을 구분할 수 있다. 리드가 적은지, 상담 예약이 안 잡히는지, 제안 이후에 떨어지는지에 따라 고칠 곳이 달라진다. “마케팅이 안 된다”는 한 문장으로는 어느 단계에 돈과 시간을 써야 할지 알 수 없다. ## 광고비는 전환율을 확인한 뒤 계산한다 영상의 마지막 단계는 유료 확장이다. Priestley는 먼저 한 건의 판매에 얼마까지 쓸 수 있는지 정하고, LAPS 전환율로 허용 리드 비용을 역산한다. 영상의 가상 예시는 5,000달러 상품에서 매출의 15%인 750달러를 판매 획득에 쓸 수 있고, 리드 100건 중 3건이 결제된다면 리드당 22.50달러까지 허용할 수 있다는 계산이다. 이 숫자는 업계 평균이나 수익 보장이 아니다. 상품 가격, 마진, 환불, 판매 주기와 실제 전환율이 바뀌면 허용 비용도 달라진다. Priestley의 핵심은 광고 채널 추천보다 선후관계에 있다. 증거가 있는 상품, 관심을 받는 콘텐츠, 신호를 모으는 랜딩페이지, 반복해서 측정한 판매 과정이 먼저다. ## Zero Draft Lab의 해석 이 순서를 뒤집으면 상품의 증거가 약한 상태에서 광고를 집행하고, 클릭이 생기면 랜딩페이지 문구를 고치고, 결제가 없으면 다시 타깃을 바꾸게 된다. 무엇이 실패했는지 구분할 숫자가 없어서 광고비로 불확실성을 더 크게 산다. 이 플레이북을 적용하려면 최근에 만든 결과 한 건을 고르고, 고객·결과·이름·과정을 한 장에 적는다. 그 한 장이 없으면 콘텐츠는 주장만 반복하고, 랜딩페이지는 약속만 늘어놓고, 광고는 검증되지 않은 경로를 확대한다. ## 출처와 주의점 - [Daniel Priestley, “Everyone Who Uses This Playbook Makes $1 Million”](https://www.youtube.com/watch?v=WiTIgjYxWbE&ref=zerodraftlab.com) — proof story, 두 상품, 관심, 랜딩페이지, LAPS, 유료 확장 순서의 1차 출처 - [Dent, “Get Launched”](https://my.dent.global/uk/getlaunched/?ref=zerodraftlab.com) — 참여한 청중, 패키지형 오퍼, LAPS를 설명하는 Daniel Priestley 소속 조직의 공식 자료 Dent의 프로그램 소개와 영상 속 성공 사례는 Priestley 측의 자기보고 및 상업적 마케팅 자료다. 이 글은 프레임워크의 순서를 설명하며, 개별 매출 성과나 “11회 노출” 수치를 독립적으로 검증된 성공 공식으로 다루지 않는다. ### 양이 질을 만든다. 단, 피드백이 있을 때만 URL: https://zerodraftlab.com/quantity-needs-feedback/ Last updated: 2026-08-30T03:37:28.000Z 사진 수업에서 한쪽 학생들에게는 사진 백 장을, 다른 쪽 학생들에게는 완벽한 사진 한 장을 과제로 냈다. 학기 말에 더 좋은 사진을 내놓은 쪽은 백 장을 찍은 학생들이었다. 많이 찍는 동안 구도와 빛을 시험하고, 실패를 보고, 다음 사진을 바꿨기 때문이다. [Why Trying to Be Perfect Won’t Help You Achieve Your GoalsJerry Uelsmann의 사진 수업과 반복의 효과를 소개한 James Clear의 글James Clear](https://jamesclear.com/repetitions?ref=zerodraftlab.com) 이 이야기는 흔히 도예 수업의 일화로 돌아다닌다. David Bayles와 Ted Orland의 책 *Art & Fear*도 도자기로 각색해 실었다. Orland가 나중에 밝힌 실제 출발점은 플로리다대학교에서 Jerry Uelsmann이 맡았던 기초 사진 수업이었다. 엄밀한 통제 실험은 아니다. 그래도 이 수업이 건드린 문제는 정확하다. 결과를 좋아지게 만든 것은 ‘많음’ 자체였을까, 많이 만드는 동안 생긴 수정이었을까. ## 양이 늘린 것은 작품 수보다 피드백의 횟수였다 백 장을 찍은 학생에게는 판단할 장면도 백 번 생긴다. 셔터를 너무 늦게 눌렀는지, 프레임 안에 무엇이 남았는지, 빛이 피사체를 살렸는지 바로 확인할 수 있다. 한 장을 구상하는 학생은 머릿속에서 완성도를 높였지만, 카메라와 현실이 돌려주는 답은 적게 받았다. 연습의 단위는 결과물 하나가 아니다. 결과를 보고 다음 행동을 바꾸는 한 바퀴가 연습 한 번이다. 그래서 양은 질을 직접 생산하지 않는다. 양은 피드백을 받을 기회를 늘리고, 피드백을 반영한 다음 시도가 질을 만든다. ## 같은 실패를 복제하면 양은 질이 되지 않는다 여기서 ‘일단 많이 하라’는 조언은 쉽게 망가진다. 같은 구도로 사진 백 장을 찍거나, 읽히지 않는 글을 같은 방식으로 백 편 쓰거나, 반응 없는 광고 문구의 단어만 백 번 바꾸면 생산량은 늘어도 판단은 그대로다. 실패가 다음 시도에 들어가지 않았기 때문이다. 생성형 AI는 이 착각을 더 싸게 만든다. 같은 가설에서 나온 문구 백 개는 실험 백 번이 아니다. 한 번의 추측을 백 가지 문장으로 복제한 것이다. 고객이 무엇에 반응했는지 보지 않고 프롬프트만 다시 돌리면, 모델은 생산 속도를 높여도 우리의 판단을 고치지 못한다. ## 유효한 반복은 다음 시도를 바꾼다 글쓰기에서는 초고를 공개해 어디에서 독자가 멈추는지 본다. 코딩에서는 작은 동작을 실행해 테스트 실패와 사용자의 막힘을 읽는다. 제품에서는 기능 열 개를 한꺼번에 만들기보다 약속 하나를 내놓고 누가 돈이나 시간을 내는지 확인한다. 분야는 달라도 반복의 구조는 같다. **만든다 → 본다 → 하나를 바꾼다 → 다시 만든다.** ‘본다’가 빠지면 생산이고, ‘바꾼다’가 빠지면 복제다. 피드백도 막연하면 소용없다. 이번 시도에서 무엇을 확인할지 정해야 다음 결과와 비교할 수 있다. 제목을 바꿨다면 클릭을 보고, 도입부를 바꿨다면 이탈을 보고, 결제 문구를 바꿨다면 구매를 본다. 한 번에 하나씩 바꿔야 무엇이 결과를 움직였는지도 남는다. ## 완벽한 첫 결과보다 실패를 기억하는 다음 결과 Jeff Atwood는 이 일화를 소프트웨어에 옮겨, 이론만 쌓기보다 실제로 많이 만들며 실수에서 배우라고 썼다. 다만 ‘많이’의 기준을 코드 줄 수나 배포 횟수로 잡으면 다시 함정에 빠진다. 어제의 실패가 오늘의 설계에 남았는지가 더 정확한 기준이다. 첫 결과가 형편없어도 괜찮다는 말은 품질을 포기하자는 뜻이 아니다. 품질 판단을 머릿속에서 끝내지 말자는 뜻이다. 열 번째 결과가 첫 번째 결과의 실패를 기억하고 있다면 양은 질로 이동하고 있다. 기억하지 못한다면 백 번째 결과도 첫 번째 결과의 복사본이다. --- **출처** - [James Clear — Why Trying to Be Perfect Won’t Help You Achieve Your Goals](https://jamesclear.com/repetitions?ref=zerodraftlab.com) - [Coding Horror — Quantity Always Trumps Quality](https://blog.codinghorror.com/quantity-always-trumps-quality/?ref=zerodraftlab.com) - [University of Florida — Jerry Uelsmann](https://arts.ufl.edu/directory/1923/staff?ref=zerodraftlab.com) - [University of Florida News — Jerry Uelsmann retrospective](https://archive.news.ufl.edu/articles/2011/05/harn-presents-critical-retrospective-of-jerry-uelsmanns-work.html?ref=zerodraftlab.com) ### 일단 판매부터 만든다 URL: https://zerodraftlab.com/sell-before-you-build/ Last updated: 2026-09-15T08:34:57.000Z 《2027년에 사업을 하는 법》 1 2027년에 사업을 시작하는 사람이 가장 먼저 만들 것은 제품이 아니다. 판매가 일어날 조건이다. AI 덕분에 앱 하나를 만드는 시간은 짧아졌다. 그래서 잘못된 제품도 더 빨리 만들 수 있게 됐다. 예전에는 개발비가 아이디어를 걸러냈다. 지금은 그 문턱이 낮아져, 고객이 원하는지 확인하기 전에 기능부터 쌓기 쉽다. 제작 속도가 빨라졌지만 무엇을 만들어야 하는지는 여전히 시장이 답한다. 순서를 뒤집어야 한다. 제품을 만든 뒤 판매하는 대신, 판매될 조건을 확인한 뒤 제품을 만든다. 여기서 판매는 존재하지 않는 제품을 이미 완성됐다고 속이거나 매출이 생겼다고 꾸미는 일이 아니다. 특정 고객이 특정 약속을 보고 시간, 정보, 연락 허용 같은 비용을 실제로 내는지 관찰하는 일이다. ## 아이디어를 판매 가설로 바꾼다 “이런 서비스를 만들면 사람들이 좋아할 것이다”는 사업 가설로 쓰기 어렵다. 누가 좋아할지, 무엇을 할지, 언제 틀렸다고 인정할지가 빠져 있기 때문이다. 판매 가설에는 대상, 약속, 행동, 기간이 들어간다. > 특정 상황에 놓인 고객 중 일정 비율이, 일정 기간 안에 이 약속을 보고 유효 리드를 남길 것이다. 예상 비율을 뒷받침할 과거 데이터가 없다면 업계 평균처럼 말하지 않는다. 첫 실험의 판정 가설로 기록한다. 결과가 나온 뒤 기준을 낮추거나 대상을 넓히면 무엇이든 성공한 것처럼 만들 수 있다. 성공, 실패, 중단 조건을 노출 전에 적어야 하는 이유다. Alberto Savoia는 아직 만들지 않은 제품에 대한 실제 행동을 관찰하는 방법을 Fake Door라고 불렀다. 출시예정 페이지, 메뉴, 신청 버튼처럼 제품이 들어갈 자리를 먼저 열고 누가 그 문을 통과하는지 본다. 문을 통과한 뒤에는 아직 출시 전이라는 사실과 다음 절차를 분명하게 알려야 한다. 페이크도어는 거짓 배송이 아니라 비싼 개발 전에 수요를 재는 계측 장치다. ## 기능보다 약속을 먼저 만든다 고객은 기능 목록에 반응하지 않는다. 지금 겪는 장면을 알아보고, 그 장면을 설명하는 이름을 얻고, 달라질 결과를 상상할 때 움직인다. “AI 기반 아동 기질 분석 서비스”는 제작자가 만들 제품을 설명한다. “떼쓰는 아이를 고치려 하기 전에 지금 어떤 자극이 과부하인지 알아보세요”는 고객이 멈춰 설 이유를 만든다. 첫 문장은 개발 명세에 가깝고 두 번째 문장은 판매 가설에 가깝다. 이 약속을 시장에 던질 때는 세 가지를 구분해야 한다. 어느 매체에 놓았는가. 그 매체에서 어떤 포맷으로 보여줬는가. 고객의 어떤 장면과 욕망을 메시지로 삼았는가. 세 축이 뒤섞인 채 조회수만 모으면 무엇이 반응을 만들었는지 알 수 없다. ## 첫 번째 제품은 판매 경로다 노출용 영상은 출시예정 페이지로 이어지고, 페이지는 연락처만이 아니라 실제 문제와 시급성, 후속 연락 의사를 받는다. 이메일 한 줄도 관심의 증거지만, 문제를 겪고 있으며 다음 대화에 시간을 내겠다는 유효 리드는 더 강한 증거다. 예치금과 선주문은 그보다 강하고, 실제 결제와 반복 구매는 다시 다음 단계다. 그러므로 “일단 판매부터 만든다”는 말은 제품 없이 매출을 만들었다고 선언하자는 뜻이 아니다. 누가 어느 약속에 행동하는지, 어떤 경로로 들어와 어느 정도의 비용을 내는지 먼저 확인하자는 뜻이다. 이 단계의 산출물은 앱이 아니라 판매 가설, 노출물, 출시예정 페이지, 유효 리드, 그리고 이들을 잇는 기록이다. 이제 남은 질문은 하나다. 이 판매 실험을 어떻게 반복 가능한 방법으로 만들 것인가. 반복 가능하게 만들려면 콘텐츠를 많이 만드는 대신 변수를 하나씩 좁혀야 한다. 매체, 포맷, 메시지를 동시에 무작위로 바꾸면 반응이 나와도 이유를 설명할 수 없다. ## 매체, 포맷, 메시지 순으로 좁힌다 첫 단계에서는 고객과 핵심 약속을 고정하고 매체를 바꾼다. YouTube Shorts, Instagram Reels, 영상 광고, 검색 광고, 아티클 가운데 어디에서 유효한 방문이 생기는지 본다. 매체마다 기본 형식은 맞추되 문제와 약속은 유지한다. 조회수가 아니라 비교 가능한 노출이나 비용 대비 유효 랜딩으로 읽는다. 반응이 나온 매체 안에서는 포맷을 바꾼다. 고객이 겪는 장면을 재현할 수도 있고, 문제에 이름을 붙일 수도 있으며, 흔한 대응을 뒤집거나 짧은 진단을 보여줄 수도 있다. 이 단계에서는 핵심 약속을 고정한다. 어떤 전달 형식이 사람을 멈춰 세우고 다음 행동으로 보내는지 확인한다. 매체와 포맷이 좁혀진 뒤 메시지를 시험한다. 예를 들어 장면 재인, 정체성 명명, 반응 교정이라는 세 가족을 만들고 각 가족에서 첫 1.5초 훅을 세 개씩 만든다. 영상 아홉 개가 아니라 서로 구분되는 가설 아홉 개다. 같은 주장을 어휘만 바꾼 아홉 편은 표본 수를 늘리지 않는다. ## Remotion은 가설 표본을 만드는 장비다 영상 제작에서 Remotion을 쓰는 이유도 대량 생산 자체에 있지 않다. 화면 비율, 길이, 자막 위치, 장면 전환, CTA 위치를 고정하고 고객, 메시지 가족, 훅, 장면별 대본만 구조화된 입력으로 바꿀 수 있기 때문이다. 한 편의 영상에는 고유한 `creative_key`를 붙인다. 이 키와 함께 대상 고객, 매체, 포맷, 메시지 가족, 훅, 랜딩 변형을 `spec.json`에 기록한다. AI는 그 경계 안에서 대본 후보를 만들 수 있다. 하지만 매일 자유롭게 콘텐츠를 발명하게 두지 않는다. 사람이 가설을 고르고 초·중·후반 화면을 검수한 뒤 동일한 규칙으로 렌더한다. Remotion의 공식 문서가 설명하는 parameterized rendering은 입력값으로 영상 내용과 메타데이터를 바꾸는 구조를 지원한다. 이 기능은 제작 편의보다 실험 통제에 더 유용하다. 영상마다 편집 방식까지 달라지면 메시지가 이긴 것인지 편집이 이긴 것인지 분리하기 어렵다. ## 출시예정 페이지에서 증거를 회수한다 각 영상은 같은 약속을 이어받은 출시예정 페이지로 연결한다. 페이지에는 누구를 위한 것인지, 어떤 문제를 다루는지, 어떤 결과를 제공할 예정인지, 아직 출시 전이라는 사실, 관심 있는 사람이 취할 다음 행동을 적는다. 폼에는 제품 결정을 바꿀 정보만 받는다. 대상 고객 조건, 현재 겪는 문제, 시급성, 후속 연락 동의가 기본이다. 사용하지 않을 개인정보를 받거나 입력 항목을 늘려 리드가 진지해 보이게 만들 필요는 없다. 어떤 조건을 충족해야 `qualified_lead`인지 노출 전에 정한다. `creative_key`는 영상에서 끝나지 않는다. 노출, 랜딩, 폼 제출, 유효 리드 판정, 후속 상담까지 같은 키를 보존한다. 그래야 조회수는 높았지만 리드가 없던 메시지와 조회수는 작아도 상담으로 이어진 메시지를 구분할 수 있다. 총 리드만 보면 매체 효과와 메시지 효과, 랜딩 효과가 다시 섞인다. ## 증거의 강도를 한 단계씩 높인다 노출보다 클릭이 강하고, 클릭보다 유효 랜딩이 강하다. 연락처 제출보다 유효 리드가 강하며, 상담 예약, 예치금, 선주문, 결제, 반복 구매로 갈수록 고객이 감수하는 비용이 커진다. 첫 페이크도어는 유효 리드에서 닫을 수 있다. 다만 이를 판매 완료라고 부르지는 않는다. 특정 고객이 특정 약속에 반응해 다음 대화가 가능한 수준의 비용을 냈다는 뜻이다. 유효 리드가 확인되면 상담과 예치로 증거를 높인다. 유효 리드도 없다면 대상, 약속, 메시지 가운데 하나만 바꿔 다시 시험한다. 판정에는 반드시 분모가 붙는다. “리드 열 명”만으로는 약속의 힘을 알 수 없다. 누구에게 얼마나 노출했는지, 어느 매체에서 얼마를 썼는지, 몇 명이 유효 랜딩과 유효 리드가 됐는지 함께 기록한다. 서로 다른 고객군과 기간은 한 전환율로 섞지 않는다. ## 승자만 늘리고 자동화는 나중에 붙인다 처음부터 콘텐츠 공장을 만들면 검증되지 않은 메시지를 싸게 많이 생산하게 된다. 먼저 구분되는 가설 아홉 개를 수동으로 시험한다. 반응이 나온 메시지 가족만 더 많은 변형으로 늘려 반복성을 확인한다. 그 과정에서 대본 작성, 화면 검수, 렌더링, 예약 발행, 추적 키 생성, 중복 방지, 결과 수집 가운데 실제로 반복되는 병목이 드러난다. 그 병목만 자동화한다. 자동화할 수 있다는 사실은 자동화할 이유가 아니다. 이미 효과가 확인된 일을 더 적은 비용으로 반복할 수 있을 때 비로소 운영 레버가 된다. 개발을 시작할 조건도 여기서 나온다. 어떤 고객이, 어느 매체의 어떤 포맷에서, 어떤 메시지를 보고, 어느 정도의 비율과 비용으로 유효 리드가 되는지 설명할 수 있어야 한다. 그 문장을 데이터로 채운 뒤의 개발은 막연한 창작이 아니다. 이미 반응한 고객에게 약속한 결과를 실제로 배송하는 일이다. --- Fake Door와 시장 행동 가설은 Alberto Savoia의 [Pretotyping Techniques](https://www.albertosavoia.com/uploads/1/4/0/9/14099067/summary%5Fof%5Fpretotyping%5Ftechniques.pdf?ref=zerodraftlab.com)와 [Pretotype Planning Canvas](https://www.albertosavoia.com/uploads/1/4/0/9/14099067/pretotyping%5Fplanning%5Fcanvas%5Fby%5Fchris%5Fcallaghan.pdf?ref=zerodraftlab.com)를 참고했다. 구조화 입력 기반 영상 렌더링은 [Remotion 공식 문서](https://www.remotion.dev/docs/parameterized-rendering?ref=zerodraftlab.com), 사전 가설과 변수 분리는 [Google Ads 동영상 실험 가이드](https://support.google.com/google-ads/answer/10436762?hl=ko&ref=zerodraftlab.com)를 확인했다. 매체·포맷·메시지의 단계적 축소, `creative_key`, 유효 리드에서 시작하는 증거 사다리, 자동화 순서는 이 글의 운영 해석이다. ### 결정이 어려우면 2부 리그를 운영하라 URL: https://zerodraftlab.com/run-a-second-league/ Last updated: 2026-09-15T08:34:57.000Z 결정을 못 내리는 사람에게는 흔히 선택지를 줄이라고 말한다. 맞는 조언이지만, ADHD가 섞이면 선택지의 수만이 문제는 아니다. 어떤 사람에게는 지금 고르지 않은 일이 영영 사라질 것처럼 느껴진다. 하나를 선택하는 순간 나머지를 버리는 기분이 들면, 사소한 결정도 오래 붙잡게 된다. 이때 필요한 것은 더 정확한 우선순위표가 아니라 2부 리그다. 1부에는 지금 실제로 시간과 돈을 쓰는 일만 둔다. 자리는 한두 개, 많아도 세 개다. 2부에는 흥미롭지만 아직 전력으로 밀 근거가 부족한 일을 둔다. 2부에 내려갔다고 실패한 것도, 포기한 것도 아니다. 작은 경기로 가능성을 확인하는 중이다. 이 구조가 없으면 선택지는 대개 두 칸에 들어간다. 당장 한다. 아니면 버린다. 새 아이디어가 생길 때마다 기존 계획을 중단하거나, 반대로 놓칠까 봐 모든 일을 동시에 시작한다. 어느 쪽이든 현재 작업량이 불어난다. 2부 리그는 세 번째 상태를 만든다. *지금은 아니지만 살아 있음.* 읽고 싶은 책은 다음 달의 한 장짜리 독서 실험이 되고, 해보고 싶은 사업은 주말 이틀짜리 판매 페이지가 된다. 새 관심사를 1부로 바로 올리지 않아도 되니 흥미를 억누를 필요가 없고, 기존 일도 매번 자리를 빼앗기지 않는다. ## 결정을 승격과 강등으로 바꾼다 승격은 기분이 세졌다는 뜻이 아니다. 2부에서 실제 반응이 생겼다는 뜻이다. 글감이라면 끝까지 쓴 문단과 독자의 반응, 사업이라면 인터뷰와 결제, 운동이라면 다시 하게 만든 일정이 근거가 된다. 반대로 1부에 있어도 몇 주째 움직이지 않거나 비용만 먹는 일은 강등할 수 있다. 그러면 결정은 정체성 선언이 아니라 자원 배분이 된다. “나는 이 일을 할 사람인가”를 한 번에 판결하는 대신 “다음 두 주 동안 어느 정도의 자리를 줄 것인가”를 정한다. 선택의 무게가 줄어드는 이유는 중요한 일을 가볍게 취급해서가 아니다. 영구계약을 요구하던 선택을 짧은 임대계약으로 바꾸기 때문이다. 짧은 임대계약이 되면 질문도 달라진다. 최고의 선택을 찾는 대신, 다음 승격 심사에 필요한 증거가 무엇인지 묻게 된다. 이 차이가 2부 리그를 단순한 할 일 목록과 갈라놓는다. ## 머릿속 심사를 바깥으로 꺼낸다 2부 리그는 정식 ADHD 치료법이 아니다. 다만 ADHD의 비약물적 개입에서 반복되는 조직화와 계획 훈련을 다른 모양으로 구현한다. 약물치료 중인 청소년을 대상으로 한 한 무작위 대조시험의 CBT 모듈도 중앙화된 할 일 목록, 우선순위 설정, 큰 일을 작은 단계로 나누는 기술을 가르쳤다. 기억하고 비교하고 보류하는 일을 머릿속에서 계속 돌리지 않고 외부 구조가 맡게 한 것이다. 1부와 2부를 나누면 “나중에 할 수도 있는 일”을 기억하기 위해 지금의 주의를 계속 쓰지 않아도 된다. 대신 리그에는 재심 날짜가 필요하다. 검토 날짜가 없으면 2부는 가능성을 지켜주는 장치가 아니라 죄책감을 보관하는 창고가 된다. ## 먼 보상 대신 가까운 경기를 만든다 ADHD 집단은 대조군보다 미래 보상의 가치를 더 가파르게 낮춰 평가하는 경향을 보인다. 21개 연구, 3,913명을 묶은 지연할인 메타분석에서는 그 차이가 중간 정도의 효과 크기로 나타났다. 이것은 ADHD가 있는 모든 사람이 같은 결정을 한다는 뜻은 아니다. 다만 보상이 멀고 모호할수록 당장의 흥미가 강한 선택에 밀릴 가능성을 설명하는 한 단서다. “언젠가 책을 쓰겠다”는 보상은 너무 멀다. 2부 리그는 이를 이번 주에 세 문단을 쓰고 다시 볼 수 있는 경기로 바꾼다. 장기 목표를 더 크게 외치는 대신 다음 피드백까지의 거리를 줄인다. 작은 실험이 끝나면 기대가 아니라 결과를 들고 승격 여부를 판단한다. ## 모든 가능성을 실행하지 않고도 보존한다 조직은 이미 잘되는 사업에 자원을 쓰면서도 새 사업을 탐색해야 한다. 개인도 비슷하다. 1부는 활용의 자리이고 2부는 탐색의 자리다. 둘을 섞으면 새 아이디어가 현재의 약속을 매번 깨뜨리고, 완전히 갈라놓으면 새로운 흥미가 실제 기회로 자라지 못한다. 다만 리그에는 정원이 있어야 한다. 1부 세 자리와 2부 다섯 자리를 넘기기 시작하면 이름만 붙인 동시 진행이 된다. 2부 후보는 작은 실험, 다음 심사일, 승격 조건 가운데 적어도 하나를 가져야 한다. 아무 경기에도 나가지 않은 후보는 보존된 가능성이 아니라 미뤄둔 결정이다. NICE의 성인 ADHD 지침은 약물치료 여부를 판단하기 전후로 환경 조정을 적용하고 검토하는 절차를 둔다. 2부 리그도 그 범위에서 읽는 편이 정확하다. 진단이나 치료를 대신하는 이론이 아니라, 관심사와 약속이 충돌하는 환경을 덜 가혹하게 설계하는 방법이다. 결정이 막히는 날에는 인생 전체를 판결하지 않아도 된다. 지금 출전할 일과 작은 경기만 치를 일을 나누면 된다. 다음 심사에서 근거가 생긴 일만 올리고, 근거를 만들지 못한 일은 자리를 비운다. --- 이 글의 \`2부 리그\`는 Owner가 제안한 운영 비유이며 정식 임상 용어가 아니다. 조직화·계획 훈련에 관한 설명은 [ADHD 인지행동치료 무작위 대조시험](https://pmc.ncbi.nlm.nih.gov/articles/PMC5026858/?ref=zerodraftlab.com), 지연할인에 관한 설명은 [ADHD와 금전적 지연할인 메타분석](https://pubmed.ncbi.nlm.nih.gov/27722208/?ref=zerodraftlab.com), 환경 조정의 임상적 위치는 [NICE ADHD 진료지침](https://www.nice.org.uk/guidance/ng87/chapter/recommendations?ref=zerodraftlab.com)을 확인했다. 승강제와 탐색·활용을 연결한 부분은 이 글의 해석이다. ### 엣지란 무엇인가 URL: https://zerodraftlab.com/edge-is-not-one-place/ Last updated: 2026-08-30T02:57:31.000Z 엣지는 사용자나 데이터가 생기는 곳과 가까운 처리 지점을 뜻한다. 하나의 고정된 장소가 아니라, 멀리 있는 원본 서버와 비교해 더 가까운 쪽을 가리키는 상대적인 말이다. 그래서 같은 서비스 안에서도 접속을 받는 엣지, 코드를 실행하는 엣지, 데이터를 읽는 엣지가 서로 다른 곳에 있을 수 있다. Cloudflare의 [CDN reference architecture](https://developers.cloudflare.com/reference-architecture/architectures/cdn/?ref=zerodraftlab.com)는 원본 콘텐츠를 사용자 가까운 CDN 사업자의 네트워크 엣지에 캐시해 지연을 줄이는 구조를 설명한다. 캐시에서 시작한 엣지라는 말이 함수와 데이터베이스까지 넓어지면서 무엇이 가까워졌는지가 흐려졌다. 엣지를 이해하려면 제품 이름보다 한 요청이 어디에서 접속되고, 계산되고, 읽히고, 쓰이는지를 나눠봐야 한다. ## 한 번의 요청에도 엣지는 여러 개다 서울의 사용자가 웹페이지를 열었다고 해보자. 요청은 가까운 접속 지점인 PoP에 먼저 도착할 수 있다. 여기서 TLS 연결, 방화벽, 라우팅, 정적 파일 캐시를 처리한다. 캐시에 답이 없으면 실제 애플리케이션 코드가 실행되는 compute region으로 넘어간다. 코드가 데이터를 요구하면 읽기 복제본이나 primary 데이터베이스로 다시 이동한다. ``` 사용자 → PoP → compute region → read replica → primary database ``` 이 경로에서 PoP만 서울이고 함수는 도쿄, 데이터베이스는 미국에 있을 수도 있다. 첫 접속이 가까웠다는 사실만으로 전체 요청이 가까운 곳에서 처리됐다고 말할 수 없다. [Vercel의 현재 CDN 문서](https://vercel.com/docs/cdn?ref=zerodraftlab.com)는 이 차이를 숫자로 드러낸다. Vercel은 126개가 넘는 PoP와 20개가 넘는 compute region을 별도로 적는다. PoP는 요청을 받고 캐시와 라우팅을 처리하는 앞문이고, 그 뒤의 리전이 코드를 실행한다. PoP 개수를 함수 실행 지점 개수로 읽으면 안 된다. ## 엣지는 어떻게 조달되는가 엣지 사업자가 세계 모든 데이터센터 건물과 해저 케이블을 직접 소유할 필요는 없다. 데이터센터 사업자에게 랙, 전력, 냉각을 빌리고 통신사나 인터넷 교환 지점과 연결할 수 있다. 그 위에 자기 서버, 라우팅, 캐시, 런타임을 올리면 하나의 엣지 네트워크가 된다. Cloudflare는 이 층을 직접 운영하는 쪽에 가깝다. 자체 네트워크와 Anycast 라우팅으로 요청을 가까운 PoP에 들이고 같은 망에서 보안, 캐시, Workers 실행을 묶는다. 그러나 Cloudflare의 [Network Interconnect 문서](https://developers.cloudflare.com/network-interconnect/?ref=zerodraftlab.com)도 고객 장비와 Cloudflare 하드웨어가 공유 데이터센터에서 물리 회선으로 연결되는 구조를 설명한다. 네트워크를 운영한다는 말과 전 세계 부동산·전력·광케이블을 전부 소유한다는 말은 다르다. 다른 사업자는 AWS 같은 클라우드 사업자의 여러 리전에서 컴퓨트를 빌린 뒤 자체 런타임과 배포 경험을 얹을 수 있다. 물리 인프라를 도매로 사고 소프트웨어와 운영을 소매 상품으로 파는 셈이다. 또 다른 사업자는 전문 CDN이나 엣지 컴퓨트 사업자의 플랫폼을 조합한다. 어느 방식이든 사용자에게 보이는 제품명만으로 밑단의 소유 구조를 알 수는 없다. ## Supabase는 함수가 엣지이고 DB는 리전이다 Supabase는 TypeScript 함수를 [글로벌 Edge Functions](https://supabase.com/docs/guides/functions?ref=zerodraftlab.com)로 배포한다. 요청은 가까운 edge gateway를 거쳐 지역별 Deno 호환 런타임에서 실행될 수 있다. 이 부분을 두고 “Supabase가 엣지에서 구동된다”고 말하는 것은 자연스럽다. 데이터베이스의 배치는 다르다. [Supabase 리전 문서](https://supabase.com/docs/guides/platform/regions?ref=zerodraftlab.com)는 프로젝트 하나가 하나의 primary region에 배포된다고 명시한다. 일반 리전도 실제로는 가용한 AWS 리전에 배치되며 서울, 도쿄, 싱가포르 같은 특정 AWS 리전을 고를 수도 있다. 따라서 유럽 사용자 가까이에서 Edge Function이 실행돼도 PostgreSQL primary가 서울에 있다면 DB 쿼리는 서울까지 왕복한다. DB를 여러 번 순차 호출하는 함수라면 사용자와 함수 사이에서 아낀 시간보다 함수와 DB 사이의 장거리 왕복이 더 커질 수 있다. Supabase가 데이터 작업이 많은 함수를 DB와 같은 리전에서 실행하는 방식을 별도로 안내하는 이유다. ## Cloudflare D1도 모든 쓰기가 엣지에서 일어나지는 않는다 Cloudflare가 큰 엣지망을 가졌다고 해서 D1 원본도 모든 PoP에 하나씩 생기는 것은 아니다. [D1 읽기 복제 문서](https://developers.cloudflare.com/d1/best-practices/read-replication/?ref=zerodraftlab.com)에 따르면 복제를 사용하지 않을 때 읽기와 쓰기는 세계 한 위치의 primary database instance로 향한다. 읽기 복제를 켜면 여러 지역의 read replica가 사용자 가까이에서 읽기를 처리할 수 있다. 복제는 비동기이므로 replica lag가 생길 수 있고, Sessions API가 순차 일관성을 보완한다. 쓰기는 여전히 primary로 전달된다. D1은 Cloudflare 네트워크와 밀접하게 결합된 데이터베이스지만 글로벌 다중 primary 쓰기 데이터베이스는 아니다. ## “엣지에서 돈다” 다음에 물어야 할 것 제품 설명에 엣지가 나오면 다음 경로를 분리해서 보면 된다. - 사용자 연결은 어느 PoP에서 끝나는가. - 캐시가 응답할 수 있는 범위는 어디까지인가. - 애플리케이션 코드는 어느 리전에서 실행되는가. - 읽기는 원본과 복제본 중 어디에서 처리되는가. - 쓰기는 어느 primary로 모이는가. - 각 구간에서 장거리 네트워크 왕복이 몇 번 발생하는가. 엣지는 공급자가 붙이는 등급이 아니다. 한 요청을 접속, 캐시, 계산, 읽기, 쓰기로 나눴을 때 어느 작업을 사용자나 데이터 발생지 가까이 옮겼는지를 설명하는 말이다. 제품 이름 옆의 “edge”보다 요청이 실제로 지나가는 화살표를 그려보는 편이 정확하다. --- 주요 출처: Cloudflare, [CDN Reference Architecture](https://developers.cloudflare.com/reference-architecture/architectures/cdn/?ref=zerodraftlab.com), [Network Interconnect](https://developers.cloudflare.com/network-interconnect/?ref=zerodraftlab.com), [D1 Global read replication](https://developers.cloudflare.com/d1/best-practices/read-replication/?ref=zerodraftlab.com); Supabase, [Edge Functions](https://supabase.com/docs/guides/functions?ref=zerodraftlab.com)와 [Available regions](https://supabase.com/docs/guides/platform/regions?ref=zerodraftlab.com); Vercel, [CDN overview](https://vercel.com/docs/cdn?ref=zerodraftlab.com). 인프라 조달을 도매와 소매로 나눈 비유와 제품 카피를 요청 경로로 다시 읽는 방법은 Zero Draft Lab의 해석입니다. ### 월 4,900원 SaaS의 잔인한 산수 URL: https://zerodraftlab.com/saas-price-customer-math/ Last updated: 2026-09-15T08:34:58.000Z 월 4,900원짜리 SaaS로 월 4,000만 원을 벌려면 유료 고객이 몇 명 필요할까? 약 8,163명이다. 계산은 초등학교 수준이지만, 결과는 가볍지 않다. 여기서 8,163명은 회원가입을 한 사람도, 무료 체험을 시작한 사람도 아니다. 이번 달에도 실제로 돈을 내는 고객이다. 제품 하나를 혼자 만들 수 있다는 사실과 8,163명의 결제를 계속 유지할 수 있다는 사실 사이에는 회사 하나만큼의 거리가 있다. 전환율을 2%로 가정하면 8,163명의 유료 고객을 얻는 데 약 40만8,000회의 방문이 필요하다. 이 역시 단순한 사고실험이다. 2%는 모든 SaaS에 통하는 업계 평균이 아니고, 방문의 질과 결제까지 걸리는 시간도 반영하지 않는다. 그래도 이 가정은 한 가지를 선명하게 만든다. **저가 구독은 판매의 마찰을 낮추는 대신 엄청난 유통량을 요구한다.** ## 싼 가격은 문제를 없애지 않고 옮긴다 월 4,900원은 결제를 받기 쉬운 가격처럼 보인다. 구매자가 오래 고민할 이유도, 영업 담당자를 만날 이유도 적다. 그러나 가격을 낮춰 사라진 설득의 부담은 획득, 지원, 결제 실패, 이탈 관리로 이동한다. 한 명을 설득하는 일은 쉬워지지만 아주 많은 사람을 찾아야 한다. 월 이탈률을 5%로 놓으면 문제가 한 번 더 커진다. 유료 고객 8,163명 중 약 408명이 매달 빠져나간다. 신규 유료 고객 408명을 다시 데려와야 매출이 성장하는 것이 아니라 제자리에 머문다. 매달 500명을 새로 결제시켜도 순증은 약 92명뿐이다. 5%라는 숫자도 벤치마크가 아니라 가정이다. 실제 이탈은 상품, 고객군, 계약 주기, 집계 방식에 따라 달라진다. 다만 복리의 방향은 달라지지 않는다. 매달 95%가 남는다면 최초 고객 집단은 1년 뒤 약 54%만 남는다. 낮아 보이는 월간 손실이 누적되면 고객 기반의 절반 가까이를 다시 채워야 한다. ## 고객 수는 사업모델의 설계 조건이다 그래서 이 산수는 “1인 SaaS는 어렵다”는 푸념으로 끝나면 안 된다. 더 중요한 결론은 제품을 만들기 전에 감당 가능한 고객 수를 정해야 한다는 것이다. 고객 한 명이 보내는 문의가 한 달에 2분뿐이어도 8,163명이면 272시간이다. 모든 고객이 문의하지 않더라도, 저가 상품은 아주 작은 운영 마찰까지 큰 비용으로 증폭시킨다. 매출 4,000만 원도 곧바로 창업자의 소득이 되지 않는다. 결제 수수료, 세금, 서버와 모델 사용료, 환불, 고객지원, 유료 획득비를 빼야 한다. 사용량이 늘수록 원가가 함께 오르는 AI 제품이라면 매출보다 먼저 고객 한 명을 한 달 더 유지할 때 남는 기여이익을 봐야 한다. 따라서 이 산수를 본 뒤에 물어야 할 질문은 “어떻게 8,163명을 모으지?” 하나가 아니다. 감당할 수 없는 숫자가 나왔다면 사업의 어느 변수를 바꿔야 하는가. 바꿀 수 있는 변수는 생각보다 적다. 고객 한 명에게 받는 금액을 높이거나, 결제 전환을 높이거나, 이탈을 낮추거나, 목표 이익을 만드는 비용 구조를 바꿔야 한다. 수학은 창업자의 낙관을 할인해주지 않는다. ## 가격을 열 배 올리면 고객은 열 배 줄어들지 않는다 같은 월 4,000만 원을 월 4만9,000원으로 만들려면 약 817명이 필요하다. 월 49만 원이면 약 82명, 월 490만 원이면 9명이다. 이 계산만 보면 가격을 올리는 것이 정답처럼 보인다. 그러나 가격은 숫자만 바꾸는 손잡이가 아니다. 구매자와 문제, 약속, 판매 방식이 함께 바뀐다. 월 4,900원짜리 제품은 많은 사람이 작게 겪는 불편을 거의 스스로 해결해야 한다. 월 49만 원짜리 제품은 더 적은 고객이 반복해서 겪는 비싼 문제를 해결해야 한다. 월 490만 원을 받으려면 소프트웨어만 넘기는 것이 아니라 도입, 책임, 결과 확인까지 포함될 가능성이 크다. 고객 수가 줄어드는 대신 한 고객을 이해하고 성공시키는 노동이 늘어난다. 그래서 “가격을 올려라”는 조언만으로는 부족하다. 가격을 열 배 올리고 싶다면 고객이 잃고 있는 돈이나 시간, 피하고 싶은 위험, 구매 뒤에 기대하는 결과도 열 배 가까이 선명해져야 한다. 저가 제품을 고가 제품처럼 포장하는 것이 아니라 더 비싼 문제로 이동해야 한다. 그 이동을 가장 빨리 검증하는 장비가 서비스다. ## 서비스는 SaaS의 패배가 아니라 탐사 장비다 이 지점에서 서비스와 외주를 함께 하라는 조언이 나온다. 흔히 이것을 “제품만으로 안 되니 몸으로 때우는 일”이라고 낮춰 본다. 하지만 초기에는 반대다. 서비스는 고객이 실제로 돈을 내는 문제, 예외가 생기는 지점, 결과를 판단하는 기준을 가장 빨리 보여준다. 예를 들어 월 49만 원짜리 수작업 해결책을 열 곳에 먼저 팔면 8,163명의 익명 사용자를 모으기 전에 열 번의 깊은 학습을 얻을 수 있다. 그 과정에서 반복되는 입력, 판단, 산출물을 찾아 소프트웨어로 옮긴다. 제품은 서비스를 지우는 데서 시작하는 것이 아니라, 서비스 안에서 되풀이되는 일을 발견하는 데서 시작한다. 다만 서비스 매출을 구독 매출처럼 부르면 안 된다. 창업자의 시간이 계속 들어가야 유지되는 돈과 제품이 반복해서 만드는 돈은 원가 구조가 다르다. 둘을 함께 팔 수는 있지만 장부에서는 분리해야 한다. 서비스는 시장을 배우고 초기 현금을 만드는 도구이지, SaaS의 단위경제성을 가리는 화장품이 아니다. ## 전환율은 버튼보다 방문자의 이유에서 갈린다 40만 회라는 방문 숫자를 본 창업자는 랜딩페이지 문구와 결제 버튼부터 고치기 쉽다. 그러나 전환율 2%는 페이지 하나의 성적표가 아니다. 어떤 문제를 가진 사람이 어떤 약속을 보고 들어왔는지, 무료 대안과 현상 유지 중 무엇을 버려야 하는지, 결제 직전에 어떤 증거가 부족했는지가 섞인 결과다. 관심 없는 방문자 40만 명보다 지금 해결책을 찾는 사람 4,000명이 낫다. 좁은 문제를 다룬 글, 고객이 실제로 쓰는 검색어, 직접 판매에서 들은 반론, 기존 업무에 바로 넣을 수 있는 데모가 전환의 분모를 바꾼다. 유통은 트래픽을 크게 만드는 일이 아니라 구매 이유가 있는 사람의 비율을 높이는 일이다. 이탈도 같은 방식으로 읽어야 한다. 떠난 고객을 설득하는 메시지보다 먼저, 고객이 반복해서 돌아올 일이 있는지 확인해야 한다. 일회성 문제를 월 구독으로 포장했다면 리텐션 캠페인으로 구조를 고칠 수 없다. 반복 매출을 원하면 반복 문제, 반복 데이터, 반복 결과 중 적어도 하나가 제품 안에 있어야 한다. ## 코드 전에 손익계산서의 분모를 정한다 제품을 만들기 전에는 거창한 재무 모델이 필요하지 않다. 원하는 월 기여이익을 적고, 고객 한 명에게 실제로 남는 돈으로 나눈다. 그러면 필요한 유료 고객 수가 나온다. 예상 이탈을 적용해 매달 대체해야 할 고객을 계산하고, 판매 방식에 맞는 전환율로 필요한 대화나 방문의 수를 역산한다. 그 결과가 혼자 감당할 수 없는 규모라면 더 열심히 만들 때가 아니다. 더 비싼 문제를 고르거나, 반복 지원을 제품에서 제거하거나, 서비스로 먼저 배우거나, 이미 수요가 모인 유통 경로를 확보해야 한다. 어떤 선택을 하든 제품의 기능보다 사업의 분모가 먼저 바뀐다. 1인 SaaS의 장점은 혼자 코드를 쓸 수 있다는 데 있다. 함정은 혼자 수천 명을 상대할 수 있다고 착각하는 데 있다. **좋은 1인 사업은 가장 많은 고객을 모으는 사업이 아니라, 창업자가 감당할 수 있는 고객 수로 원하는 이익을 만드는 사업이다.** --- 출발점은 온라인에 공유된 1인 SaaS 역산 예시입니다. 월 4,000만 원, 구독료 4,900원, 전환율 2%, 월 이탈률 5%는 사실 주장이나 업계 벤치마크가 아니라 사고실험의 가정으로만 사용했습니다. 계산값은 반올림했습니다. MRR과 구독자 이탈의 정의는 Stripe의 [Billing analytics 공식 문서](https://docs.stripe.com/billing/subscriptions/analytics?ref=zerodraftlab.com)를 대조했습니다. 가격·서비스·기여이익으로의 확장은 이 글의 해석입니다. ### 유저는 0명인데 서버는 10만 명을 걱정한다 URL: https://zerodraftlab.com/scale-follows-demand/ Last updated: 2026-09-15T08:34:59.000Z 토끼가 AI로 사이드프로젝트 하나를 만들고 싶다고 말한다. 곧바로 세 명이 끼어든다. 계획도 없이 프롬프트만 치면 끝날 줄 알았느냐, 로그인과 결제와 에러 처리는 생각했느냐, 유저 10만 명이 몰리면 서버는 누가 버틸 것이냐. 질문 하나하나는 틀리지 않았다. 계정이 있는 제품에는 로그인이 필요하고, 돈을 받으면 결제 실패를 다뤄야 하며, 사용자가 늘면 서버도 버텨야 한다. 그런데 이 정답들을 한꺼번에 꺼내는 순간 제품은 시작 전에 완성품의 의무를 떠안는다. 아직 한 명도 쓰지 않는 서비스가 10만 명의 트래픽을 견디기 위해 첫 사용자를 만나는 일을 미룬다. 상상 속 성공은 이상하게 구체적이다. 데이터베이스를 어떻게 나눌지, 큐를 어디에 둘지, 다중 리전을 언제 열지까지 그릴 수 있다. 반면 첫 사용자가 왜 이 제품을 켜야 하는지는 흐릿하다. 기술 문제는 답을 찾을 수 있어서 편하고, 수요 문제는 거절을 만나야 해서 불편하다. 확장성은 이 불편을 엔지니어링 문제로 바꿔주는 좋은 피난처가 된다. 폴 그레이엄은 [「Do Things that Don't Scale」](https://www.paulgraham.com/ds.html?ref=zerodraftlab.com)에서 초기 스타트업은 사용자를 한 명씩 직접 모집하고, 필요하면 소프트웨어가 해야 할 일까지 사람이 대신하라고 썼다. 자동화할 병목을 알기 전에 자동화부터 해두는 것보다, 실제 문제를 손으로 해결하면서 무엇이 반복되는지 배우는 편이 낫다는 주장이다. 그는 실수의 대가가 큰 영역은 예외라고도 선을 그었다. **현재의 증거보다 앞선 규모는 만들지 않는다.** 사용자가 다섯 명이면 다섯 명의 행동을 정확히 볼 수 있어야 한다. 유료 제품이면 실제 결제가 한 번 끝나야 한다. 핵심 작업이 실패하면 원인을 찾고 복구할 수 있어야 한다. 이 요구는 지금 존재한다. 10만 동시접속은 아직 존재하지 않는다. 마틴 파울러가 설명한 [YAGNI](https://martinfowler.com/bliki/Yagni.html?ref=zerodraftlab.com)는 아직 쓰이지 않을 능력을 미리 구현할 때 생기는 비용을 다룬다. 구현비뿐 아니라 가치가 늦게 전달되는 비용과, 복잡성을 계속 들고 가는 비용이 생긴다. 더 큰 문제는 요구가 실제로 도착했을 때 과거의 추측으로 만든 구조가 맞지 않을 수 있다는 점이다. 첫 제품이 견뎌야 할 것은 상상 속 유명세가 아니라 다음번 진짜 학습이다. 로그인, 결제, 테스트, 보안, 배포, 확장성 가운데 무엇을 지금 넣고 무엇을 뒤로 미룰지는 틀렸을 때의 비용과 되돌리기 어려운 정도로 가른다. 같은 로그인도 커뮤니티 프로필을 위한 로그인과 환자 기록을 여는 로그인은 다르다. 같은 결제도 테스트용 가격 버튼과 자동 갱신 구독은 다르다. “초기 제품이니까”라는 말은 낮은 트래픽을 설명할 수는 있어도 돈과 개인정보를 잃어도 된다는 허가는 아니다. ## 미뤄도 되는 복잡성과 미루면 안 되는 책임 유저 10만 명을 위한 샤딩, 여러 지역에 걸친 복제, 복잡한 이벤트 버스는 대개 아직 일어나지 않은 부하를 위한 능력이다. 반면 결제 금액이 맞는지, 비밀번호와 세션이 안전한지, 실패한 작업을 다시 실행해도 중복 청구되지 않는지는 현재 한 명의 사용자에게도 영향을 준다. 전자는 수요의 증거가 생길 때 키울 수 있지만 후자는 첫 거래부터 책임져야 한다. [OWASP ASVS](https://owasp.org/www-project-application-security-verification-standard/?ref=zerodraftlab.com)는 애플리케이션이 다루는 자산과 신뢰 수준에 맞춰 어떤 보안 통제를 확인할지 합의하는 기준을 제공한다. 회원 계정이 없는 실험에 인증 시스템을 미리 만들 필요는 없다. 계정과 민감정보를 받기로 했다면 보안은 현재 제품의 일부가 된다. 미래 용량을 덜어낸 자리에 무엇을 남겨야, 지금은 작게 만들면서 나중에는 싸게 바꿀 수 있을까? YAGNI에도 같은 예외가 있다. 파울러는 리팩터링, 자동화된 테스트, 지속적 배포처럼 코드를 바꾸기 쉽게 만드는 활동을 미래 기능과 구분한다. 이 장치들은 언젠가 필요할 기능을 미리 구현하는 것이 아니라, 오늘의 판단이 틀렸을 때 싸게 고칠 수 있게 한다. 초기 제품에 필요한 기술적 여유는 10만 명을 위한 용량보다 방향을 바꿀 수 있는 가역성에 가깝다. ## 시간을 고정하면 상상이 잘린다 Basecamp의 [Shape Up](https://basecamp.com/shapeup/1.2-chapter-03?ref=zerodraftlab.com)은 일을 시작하기 전에 얼마나 오래 쓸지 정하고, 그 시간 안에 들어오도록 범위를 바꾸는 방식을 제안한다. 예상 기능을 모두 쌓은 뒤 기간을 계산하는 대신, 이 문제에 쓸 수 있는 시간부터 정하면 설계가 제약을 받는다. “있으면 좋은 것”이 “이번에 없으면 사용자가 핵심 작업을 끝내지 못하는가”라는 질문을 통과해야 한다. AI 사이드프로젝트라면 이 제약은 더 중요하다. 코드를 빨리 만들 수 있으니 생각나는 기능을 모두 넣기 쉬워졌고, 서로 다른 라이브러리를 연결해 본격적인 시스템처럼 보이게 만들기도 쉬워졌다. 제작 속도가 빨라진 만큼 잘못 고른 범위를 완성하는 속도도 빨라졌다. 처음 다섯 명에게 유료로 한 가지 작업을 끝내게 하려는 제품을 생각해보자. 결제가 가설의 일부라면 결제 흐름은 필요하다. 핵심 작업이 오래 걸린다면 진행 상태와 실패 복구도 필요하다. 그러나 다섯 명이 같은 시간에 몰려도 버티는 단일 앱과 데이터베이스가 있다면, 10만 명을 위한 마이크로서비스는 다음 가설을 검증하지 않는다. 오히려 로그가 여러 곳으로 갈리고 배포 지점이 늘어 첫 실패의 원인을 찾기 어려워질 수 있다. ## 규모는 숫자가 아니라 사건으로 도착한다 확장 준비를 언제 시작할지 달력으로 정할 수는 없다. 실제 응답 시간이 핵심 작업을 방해하고, 수작업이 주문을 놓치게 하고, 데이터 양 때문에 배치가 끝나지 않고, 한 고객의 계약이 특정 격리를 요구하는 순간이 온다. 이때 규모는 상상이 아니라 관찰된 병목이나 합의된 의무다. 그 증거에 맞춰 캐시, 큐, 파티셔닝, 격리를 한 단계씩 더하면 된다. 반론도 있다. 갑작스러운 방송 노출이나 대형 캠페인처럼 첫날부터 많은 사람이 들어올 것이 확정된 제품은 미리 용량을 준비해야 한다. 데이터 구조를 나중에 바꾸기 매우 비싼 제품도 있다. 하지만 이것은 “언젠가 잘되면”이라는 막연한 기대와 다르다. 예정된 트래픽, 체결된 계약, 법적 의무, 되돌릴 수 없는 데이터 선택은 이미 현재의 증거다. 좋은 초기 구조는 미래를 정확히 맞히지 않는다. 틀린 예측을 제거하고, 실제 사용에서 나온 다음 요구를 받아들일 자리를 남긴다. 첫 번째 서버의 임무는 10만 명을 견디는 것이 아니라 한 명의 결제를 잃지 않고, 한 번의 실패를 설명하며, 다음 변경을 두려움 없이 배포하게 하는 것이다. --- 초기 사용자를 직접 모집하고 수작업으로 병목을 배우는 설명은 Paul Graham의 [「Do Things that Don't Scale」](https://www.paulgraham.com/ds.html?ref=zerodraftlab.com), 추정 기능의 구현·지연·유지 비용과 변경 용이성의 구분은 Martin Fowler의 [「Yagni」](https://martinfowler.com/bliki/Yagni.html?ref=zerodraftlab.com), 보안 검증의 범위와 엄격도는 [OWASP ASVS](https://owasp.org/www-project-application-security-verification-standard/?ref=zerodraftlab.com), 시간 예산으로 범위를 제한하는 설명은 Ryan Singer의 [「Shape Up — Set Boundaries」](https://basecamp.com/shapeup/1.2-chapter-03?ref=zerodraftlab.com)를 대조했다. “규모는 수요의 증거 뒤에 온다”와 현재 책임·미래 용량을 나누는 구분은 이 글의 해석이다. ### 광고를 많이 만들수록 더 많이 배우는 것은 아니다 URL: https://zerodraftlab.com/ad-volume-is-not-learning/ Last updated: 2026-09-15T08:35:00.000Z 30일 동안 광고 1,352개를 테스트했다는 제목은 강하다. 숫자가 크니 그만큼 많이 배웠을 것처럼 들린다. 하지만 광고 개수와 학습량은 같은 장부에 들어가지 않는다. 같은 후킹 문구의 어순을 바꾸고, 같은 제품 사진의 배경색을 바꾸고, 같은 약속을 세로 영상과 정사각형 이미지로 다시 만들면 광고 파일은 빠르게 늘어난다. 실패한 이유를 구분할 수 없다면 늘어난 것은 파일 수뿐이다. 이 구분은 AI 광고 제작 도구가 보편화될수록 더 중요해진다. Meta의 Advantage+ creative는 이미지 확장, 배경 생성, 문구 변형, 정지 이미지 애니메이션 같은 기능으로 한 소재에서 더 많은 변형을 만든다. 플랫폼은 이를 “더 다양해진 크리에이티브”라고 설명한다. 제작 속도는 분명 빨라진다. 그러나 변형을 많이 생성하는 능력과 무엇을 배울지 정하는 능력은 다르다. ## 다양성은 파일 수가 아니라 가설 사이의 거리다 Meta의 Performance 5도 광고 소재의 다양화를 권한다. 여러 메시지와 형식을 주고 시스템이 사람마다 더 관련 있는 광고를 고르게 하라는 뜻이다. 여기서 다양성은 한 시안의 사소한 변주만을 뜻하지 않는다. 같은 제품이라도 고객이 붙잡힌 문제, 약속하는 변화, 믿게 만드는 증거, 말하는 사람, 사용하는 장면은 달라질 수 있다. “시간을 아낀다”와 “실수를 줄인다”는 서로 다른 약속이다. 창업자의 설명과 실제 사용자의 시연은 서로 다른 증거다. 제품 사진과 사용 과정 영상은 단지 포맷만 다른 것이 아니라 다른 의심에 답할 수 있다. 반대로 문구 세 줄과 배경 네 개를 조합해 열두 장을 만들었다고 해도 모두 같은 이유로 선택되거나 버려질 수 있다. 이 경우 광고는 열두 개지만 가설은 하나다. 광고 소재의 다양성은 개수보다 서로 다른 고객 판단을 얼마나 건드리는지로 봐야 한다. ## 메타 광고의 테스트는 자동으로 실험이 되지 않는다 광고관리자에서 여러 광고를 동시에 돌리면 결과 표가 생긴다. 그 표가 곧 인과를 증명하지는 않는다. Meta의 전달 시스템은 학습 단계에서 어떤 사람과 게재 위치가 결과를 낼지 탐색하고, 성과가 예상되는 곳에 노출과 예산을 다르게 배분한다. 모든 광고가 같은 사람에게 같은 횟수로 무작위 노출되는 실험실과는 다르다. 그래서 많이 집행된 광고가 더 좋은 광고였을 가능성과, 시스템이 일찍 가능성을 높게 보고 더 많은 기회를 준 광고였을 가능성이 섞인다. 클릭률이 높은 소재가 매출을 만든 것인지, 원래 살 가능성이 높은 사람에게 더 많이 도달한 것인지도 결과 표만으로는 완전히 분리하기 어렵다. 영상에서 Mark는 승인된 광고의 랜딩 페이지를 바꾸는 식의 조작이 알고리즘에 악영향을 줄 수 있다고 경고한다. Meta 공식 안내에서 직접 확인되는 범위는 조금 좁다. 링크나 소재 변경은 광고를 다시 검토하게 만들 수 있고, 중대한 수정은 광고를 다시 준비 단계로 보낼 수 있다. 이것만으로 Meta가 랜딩 페이지 수정에 벌점을 준다고 단정할 수는 없다. 다만 테스트 중 목적지와 메시지를 함께 바꾸면 이전 구간과 이후 구간을 같은 조건으로 비교하기 어려워진다. 광고 운영자가 지켜야 할 것은 알고리즘의 기분이 아니라 비교 가능성이다. 무엇을 바꿨는지 모르면 성과가 올라도 다음 결정을 복제할 수 없다. ## 광고 한 개보다 가설 한 개를 세어야 한다 광고 테스트의 최소 단위는 파일이 아니라 반증 가능한 가설이다. “짧은 영상이 좋을 것이다”는 아직 넓다. “구매 직전 고객에게는 창업자 설명보다 실제 사용 장면이 첫 구매 전환을 더 높일 것이다”라고 적으면 대상, 비교할 증거, 확인할 결과가 생긴다. 좋은 결과만 찾는 것도 충분하지 않다. 테스트가 끝난 뒤 무엇을 더 이상 믿지 않게 됐는지 말할 수 있어야 한다. 제품 설명을 줄인 영상이 클릭은 늘렸지만 구매 전환은 낮췄다면, 짧은 설명이 항상 낫다는 믿음은 약해진다. 다음 광고는 더 짧게 만드는 대신 구매 전 의심을 해소하는 증거를 바꾸는 쪽으로 간다. 1,352라는 숫자는 제작 능력을 말해줄 수 있다. 각 광고가 어떤 가설을 맡았고 어떤 결정을 폐기했는지 없으면 학습 능력까지 증명하지는 못한다. 광고 라이브러리보다 먼저 필요한 것은 광고가 줄인 불확실성의 장부다. 그러면 소재, 퍼널, 미디어 바잉이 한꺼번에 움직이는 현실에서 무엇을 고정하고 무엇을 바꿔야 다음 광고가 이전 광고보다 더 많은 정보를 남길까. 고정해야 하는 것은 화면 모양이 아니라 비교의 기준이다. 광고 결과에는 적어도 네 층이 겹친다. 고객이 반응한 문제와 약속, 그 약속을 표현한 소재, 클릭 뒤의 제안과 랜딩 페이지, 노출과 예산을 배분한 전달 방식이다. 네 층을 한꺼번에 바꾸면 매출이 올라도 어느 결정이 효과를 냈는지 남지 않는다. ## 발견과 확인은 같은 캠페인에서 끝내지 않는다 처음부터 변수 하나만 바꾸는 정교한 A/B 테스트를 고집하면 탐색이 느려질 수 있다. 아직 고객이 어떤 문제와 증거에 반응하는지도 모르는 단계라면 서로 멀리 떨어진 소재를 넓게 던지는 편이 낫다. 이때 목표는 승자를 확정하는 것이 아니라 가능성이 낮은 방향을 빨리 버리고 다음 확인 대상을 고르는 것이다. 발견 단계에서는 제안, 전환 목표, 측정 창을 가능한 한 안정적으로 두고 문제·약속·증거가 다른 소재를 비교한다. 플랫폼의 자동 전달은 유망한 조합을 찾는 탐색 장치로 쓴다. 여기서 나온 상위 소재는 후보이지 인과가 확인된 승자가 아니다. 확인 단계에서는 한 번에 하나의 사업 결정을 좁힌다. 사용 장면과 창업자 설명 중 무엇이 구매 전환에 유리한지 보고 싶다면 가격, 랜딩 페이지, 타기팅과 최적화 목표는 유지한다. Meta 광고관리자의 A/B 테스트나 별도 랜딩 실험을 쓰더라도 중간에 링크, 예산 구조, 전환 이벤트를 함부로 바꾸지 않는다. 차이가 작다면 멋진 해석을 붙이지 않고 아직 구분할 수 없다고 남긴다. 이 두 단계를 섞으면 탐색 중 우연히 앞선 광고를 영구 승자로 오해하거나, 확인해야 할 가설을 끝없이 새 소재로 덮게 된다. 넓게 찾고 좁게 확인하는 순서가 광고 생산을 학습으로 바꾼다. ## 퍼널은 광고 성과의 배경이 아니라 실험 변수다 영상은 같은 광고도 어떤 퍼널에 연결하느냐에 따라 성과가 달라진다고 강조한다. 이 말은 광고의 공을 랜딩 페이지에 넘기라는 뜻이 아니다. 광고가 만든 기대와 도착한 페이지의 약속이 이어지는지 함께 봐야 한다는 뜻에 가깝다. 광고가 “설치 없이 바로 쓴다”고 말했는데 랜딩 첫 화면이 기능 목록부터 보여주면 클릭과 구매 사이에서 약속이 끊긴다. 광고를 더 자극적으로 바꾸면 클릭률은 오를 수 있지만 끊어진 약속은 더 커진다. 반대로 랜딩 페이지가 약속, 증거, 가격과 위험을 명확히 이어주면 평범한 광고도 구매 판단을 끝낼 수 있다. 그래서 광고 지표는 퍼널 지표와 함께 읽어야 한다. 클릭률이 떨어졌다면 소재나 노출 대상의 문제일 수 있다. 클릭률은 유지되는데 구매 전환이 내려갔다면 페이지, 제안, 가격, 재고 같은 클릭 뒤 조건을 먼저 의심할 수 있다. 구매 수는 유지되는데 환불이나 저품질 리드가 늘었다면 최적화 목표가 사업이 원하는 고객과 어긋났을 수 있다. 어느 경우든 한 지표만으로 원인을 확정하지 않고 다음 확인 대상을 좁히는 단서로 쓴다. Meta의 Conversions API가 구매 이후 행동이나 고객 가치 신호를 전달할 수 있게 하는 이유도 여기에 있다. 플랫폼이 클릭이나 값싼 리드만 보게 하면 그 목표를 잘 만드는 사람을 찾는다. 반복 구매, 자격 있는 리드, 오프라인 전환처럼 사업에 가까운 신호를 정확히 보낼수록 광고 최적화와 사업 성과의 거리가 줄어들 수 있다. 개인정보와 플랫폼 정책을 지키며 수집·전송해야 한다는 경계도 함께 남는다. ## 광고의 수명은 피로도 한 단어로 설명되지 않는다 성과가 내려가면 흔히 소재가 죽었다고 말한다. 실제로 같은 광고가 같은 사람에게 반복 노출돼 반응이 줄었을 수 있다. 하지만 경매 비용, 도달한 사람의 구성, 랜딩 전환, 가격, 재고, 경쟁사의 프로모션도 같은 시기에 움직인다. 소재를 폐기하기 전에 하락이 어디서 시작됐는지 나눠봐야 한다. 노출 비용이 올랐는지, 클릭 반응이 내려갔는지, 클릭 뒤 전환이 꺾였는지, 매출은 유지되지만 마진이 줄었는지를 구분한다. 이 분해는 원인을 자동으로 증명하지 않지만 모든 하락을 광고 피로로 몰아가는 것보다 다음 테스트를 작게 만든다. 좋았던 광고를 끝없이 살리는 것도 목표가 아니다. 어떤 약속과 증거가 통했는지 남기면 한 파일의 수명이 끝나도 다음 소재가 그 학습을 이어받는다. 반대로 파일만 복제하면 광고는 계속 늘지만 매번 처음부터 다시 시작한다. ## AI는 제작비를 낮추지만 실험비를 없애지 않는다 생성형 AI로 배경, 문구, 영상 변형을 빠르게 만들면 제작 병목은 약해진다. 그만큼 비슷한 소재를 대량으로 만드는 유혹도 커진다. 한 프롬프트에서 나온 스무 개의 결과가 시각적으로 달라도 같은 고객, 같은 약속, 같은 증거를 반복할 수 있다. AI를 광고 실험에 쓰려면 생성 개수보다 가설의 거리를 먼저 정해야 한다. 고객이 피하려는 손실, 얻고 싶은 변화, 믿을 만한 증거, 구매를 막는 위험을 각각 다른 방향으로 만들고, AI는 그 방향을 여러 형식에 맞게 표현하는 데 쓴다. 방향을 고르는 일까지 자동 생성에 맡기면 다양해 보이는 동어반복이 나온다. 운영 장부도 바뀌어야 한다. 이번 주에 몇 개를 만들었는지뿐 아니라 서로 다른 가설이 몇 개였는지, 무엇이 확인되지 않았는지, 어떤 결정을 버렸는지, 결과가 매출과 기여이익까지 이어졌는지를 적는다. 클릭률 승자가 저마진 고객만 데려왔다면 광고 플랫폼의 승리와 사업의 승리는 다르다. 광고 100개로 서로 다른 가설 열 개를 확인한 팀은 광고 1,352개로 같은 약속을 반복한 팀보다 더 많이 배울 수 있다. 생산량이 경쟁력이 되는 시기는 짧다. 다음 광고가 이전 광고의 실패를 기억하게 만드는 구조가 더 오래 남는다. --- 출발점: Mark Builds Brands Highlights, [I tested 1,352 Ads in 30 days. here’s how meta ads algo works](https://www.youtube.com/watch?v=r7E2DSRq9Lo&ref=zerodraftlab.com). 1,352개 테스트, 무작위 소재 탐색, 다양성, 퍼널, 미디어 바잉, 광고 수명은 영상 발표자의 주장과 YouTube AI 요약을 아이디어 출발점으로 삼았다. 계정 수, 예산, 표본 배분, 통제 방식은 공개 요약에서 확인되지 않아 보편적인 성과 근거로 쓰지 않았다. 공식 교차 확인: Meta for Business의 [Performance 5](https://www.facebook.com/business/ads/performance-marketing), [Advantage+ creative](https://www.facebook.com/business/ads/meta-advantage-plus/creative), [광고 세트 단순화 안내](https://www.facebook.com/business/ads/ad-set-structure), [광고 검토 안내](https://www.facebook.com/business/ads/review-policy-guidelines), [전달 상태와 학습 단계](https://www.facebook.com/help/messenger-app/650774041651557), [광고관리자 A/B 테스트 안내](https://www.facebook.com/help/messenger-app/621956575422138/), [Conversions API 안내](https://www.facebook.com/business/help/AboutConversionsAPI). Meta 자료는 플랫폼 공급자의 제품·운영 권고이며 개별 계정의 성과를 보장하지 않는다. 가설의 거리, 발견과 확인의 분리, 불확실성 장부는 이 글의 해석이다. ### 창업을 공부하느라 고객을 만나지 않았다 URL: https://zerodraftlab.com/learning-instead-of-customers/ Last updated: 2026-09-15T08:35:00.000Z 사진 속 남자는 《How to Build a Million-Dollar Startup》이라는 두꺼운 책을 읽고 있다. 성공의 비밀이 나올 것 같은 책을 펼치자 한 문장만 적혀 있다. “Go get customers.” 그는 운다. 웃긴 이유는 답이 너무 단순해서가 아니다. 이미 알고 있던 답이기 때문이다. 고객을 만나야 한다는 말을 모르는 창업자는 드물다. 그런데도 시장조사 보고서를 더 읽고, 사업계획서를 고치고, 기능을 하나 더 만든다. 준비는 계속되지만 고객과 마주치는 순간은 자꾸 뒤로 밀린다. 공부에는 깨끗한 진척이 있다. 읽은 페이지, 정리한 노트, 완성한 화면이 남는다. 고객 접촉은 그렇지 않다. 답장이 오지 않고, 문제라고 생각한 일을 대수롭지 않게 여기고, 좋다고 말하면서도 돈은 내지 않는다. 한 주를 보낸 뒤 남는 것이 거절 세 건뿐일 수도 있다. 그래서 창업 공부는 쉽게 회피 수단이 된다. 더 많이 알면 덜 틀릴 것 같지만, 고객을 만나기 전의 지식은 가설을 정교하게 만들 뿐 그 가설을 사실로 바꾸지 못한다. 내부 논리는 촘촘해지고 외부 불확실성은 그대로 남는다. 폴 그레이엄은 [「Do Things that Don't Scale」](https://www.paulgraham.com/ds.html?ref=zerodraftlab.com)에서 초기 창업자가 사용자를 직접 모집하기 꺼리는 이유로 낯선 사람에게 거절당하는 불편과, 처음 얻는 사용자 수가 너무 작아 보인다는 점을 들었다. Stripe의 창업자들은 써보겠다는 사람에게 링크를 보내고 기다리지 않았다. 그 자리에서 노트북을 받아 설치했다. 제품의 확장성보다 사용자가 실제로 움직이는 장면을 먼저 만들었다. Y Combinator도 [초기 창업자를 위한 핵심 조언](https://www.ycombinator.com/blog/ycs-essential-startup-advice/?ref=zerodraftlab.com)에서 해야 할 일을 코드를 쓰는 것과 사용자에게 말하는 것으로 압축한다. 여기서 코드는 제품을 완성하는 수단이 아니다. 고객과 다음 대화를 열기 위한 물건이다. 랜딩페이지, 데모, 수작업 서비스도 같은 역할을 할 수 있다. ## 공부는 불안을 줄이고, 고객은 불확실성을 줄인다 두 효과를 섞으면 바쁜데도 사업은 제자리다. 좋은 강의는 무엇을 물어볼지 알려준다. 좋은 책은 흩어진 경험에 이름을 붙여준다. 그러나 누구에게 어떤 문제를 얼마에 해결할지는 독서 기록에서 나오지 않는다. 스티브 블랭크가 [Customer Development Manifesto](https://steveblank.com/2012/03/29/nail-the-customer-development-manifesto/?ref=zerodraftlab.com)의 첫 원칙으로 “건물 안에는 사실이 없다”고 쓴 이유도 여기에 있다. 창업자는 사업모델을 실행하는 사람이기 전에 반복 가능한 모델을 찾는 사람이다. 찾는 동안 사업계획서의 문장은 사실이 아니라 검증을 기다리는 가설이다. 그렇다면 고객을 만났다는 사실만으로 충분한가. 대화 횟수를 채우고 원하는 기능을 물어본 뒤 다시 제품으로 돌아가면, 창업 공부가 고객 인터뷰라는 새 형식으로 바뀌었을 뿐이다. 문제는 “고객을 만나야 한다”는 조언을 한 줄 더 외우는 데 있지 않다. 매주 무엇을 진척으로 셀 것인지 바꾸는 데 있다. 진척의 단위는 산출물이 아니라 시장에서 지워진 불확실성 하나여야 한다. ## 인터뷰는 기능 투표가 아니다 블랭크는 [Customer Development is Not a Focus Group](https://steveblank.com/2009/11/30/customer-development-is-not-a-focus-group/?ref=zerodraftlab.com)에서 고객에게 원하는 기능 목록을 받는 일을 고객 발견과 구분했다. 고객은 미래의 행동을 정확히 예측하지 못하고, 창업자는 듣고 싶은 답을 골라 듣기 쉽다. 대화의 가치는 아이디어를 승인받는 데 있지 않다. 더 쓸모 있는 재료는 이미 벌어진 일이다. 마지막으로 그 문제를 겪은 때, 지금 쓰는 대안, 해결하지 않았을 때 생긴 비용, 구매를 승인하는 사람, 실제로 지불한 금액을 따라가면 고객의 말이 행동과 연결된다. “이런 제품이 있으면 쓰겠다”보다 엑셀 파일을 매주 두 시간씩 손으로 고치는 장면이 강한 증거다. 그래서 초기 제품은 정답이라기보다 대화를 구체적으로 만드는 도구에 가깝다. 화면을 보여주면 추상적인 호감이 사용 순서와 반론으로 바뀐다. 가격을 붙이면 칭찬이 구매와 거절로 갈린다. 직접 납품하면 고객이 중요하다고 말한 기능보다 실제 작업을 막는 예외가 먼저 드러난다. ## 자동화는 고객을 얻은 뒤의 문장이다 창업자가 공부와 제작으로 돌아가는 또 다른 이유는 한 명씩 파는 일이 작아 보이기 때문이다. 광고 퍼널, 셀프서브 가입, 추천 루프를 만들면 사업처럼 보인다. 지인에게 데모를 보여주고 첫 고객의 데이터를 손으로 옮기는 일은 임시방편처럼 보인다. 하지만 자동화는 이미 작동하는 행동을 반복하는 기술이다. 아직 아무도 사지 않는다면 자동화할 행동도 없다. 그레이엄이 수작업으로 사용자를 모집하고 문제를 해결하라고 한 이유는 초기 노동을 미화하기 위해서가 아니다. 반복되는 병목을 몸으로 겪어야 무엇을 코드로 옮길지 알 수 있기 때문이다. 책과 강의는 이 과정에서 빠지지 않는다. 다만 순서가 달라진다. 고객에게 거절당한 뒤 가격 책을 읽으면 가격이론은 방어 문구가 아니라 실패를 해석하는 언어가 된다. 직접 납품한 뒤 운영 책을 읽으면 프로세스는 멋진 다이어그램이 아니라 다음 주문에서 없앨 병목이 된다. 경험이 질문을 만들고, 공부가 그 질문을 더 정확하게 다룬다. ## 고객 접촉도 틀릴 수 있다 아무 고객이나 많이 만난다고 시장이 보이는 것은 아니다. 구매자가 아닌 사람의 의견을 모으거나, 현재 행동 대신 미래 의향을 묻거나, 서로 다른 고객군의 요구를 한 제품에 섞으면 대화가 오히려 가설을 흐린다. 고객의 말은 명령이 아니라 관찰 자료다. 그래서 만남 전에는 검증할 가설이 하나 필요하고, 만남 뒤에는 그 가설을 유지할지 버릴지 기록해야 한다. “사람들이 이 기능을 좋아했다”보다 “이 문제를 지난달 세 번 겪었고, 두 곳은 이미 외주비를 내고 있었으며, 한 곳은 제안서를 거절했다”가 다음 결정을 더 잘 만든다. 긍정적인 반응만 모으지 않으면 거절도 진척이 된다. 창업 공부가 나쁜 것은 아니다. 고객에게 던질 질문 없이 책을 읽고, 책에서 얻은 답을 고객에게 확인받으려 할 때 문제가 생긴다. 다음 읽을 책을 고르기 전에 지난 7일 동안 보낸 제안, 들은 거절, 관찰한 대안, 받은 결제를 먼저 세면 된다. --- 출발점은 Owner가 Google Photos에서 선택한 “How to Build a Million-Dollar Startup / Go get customers” 밈 캡처다. 원본 캡처와 비공개 Google Photos URL, 계정 식별자는 저장하거나 공개하지 않았다. 밈의 최초 제작자와 원 게시물은 확인하지 못했으므로 이미지의 출처나 저작권 상태를 주장하지 않는다. 초기 사용자 모집과 고객 발견에 관한 설명은 Paul Graham의 [「Do Things that Don't Scale」](https://www.paulgraham.com/ds.html?ref=zerodraftlab.com), Y Combinator의 [「YC's Essential Startup Advice」](https://www.ycombinator.com/blog/ycs-essential-startup-advice/?ref=zerodraftlab.com), Steve Blank의 [Customer Development Manifesto](https://steveblank.com/2012/03/29/nail-the-customer-development-manifesto/?ref=zerodraftlab.com)와 [「Customer Development is Not a Focus Group」](https://steveblank.com/2009/11/30/customer-development-is-not-a-focus-group/?ref=zerodraftlab.com)을 대조했다. 학습이 불안을 줄이는 반면 고객 접촉이 시장 불확실성을 줄인다는 구분은 이 글의 해석이다. ### 에이전트 결제는 수요가 아니다 URL: https://zerodraftlab.com/agent-payments-are-not-demand/ Last updated: 2026-09-15T08:35:01.000Z AI에게 물건을 파는 상점이 빠르게 늘고 있다는 그래프가 돌았다. 제목은 ‘에이전트에게 판매하는 고유 상점 수’였다. 사람 대신 소프트웨어가 지갑을 들고 API와 데이터, 컴퓨팅을 산다는 이야기다. 숫자는 이미 미래처럼 보인다. x402 공식 사이트는 2026년 8월 9일 조회 시 최근 30일 동안 7,541만 건의 거래, 2,424만 달러의 거래액, 9만 4천여 구매자와 2만 2천 판매자를 표시했다. 거래 횟수만 보면 에이전트 경제가 시작됐다는 말이 과장이 아닌 듯하다. 그러나 이 숫자를 곧바로 시장 크기로 읽으면 안 된다. x402가 해결한 것은 수요의 생성이 아니라 결제 마찰의 제거이기 때문이다. ## 소프트웨어가 결제할 수 있게 됐다 x402의 작동 방식은 단순하다. 프로그램이 유료 API를 요청하면 서버가 HTTP 402 응답과 함께 가격, 결제 수단, 네트워크, 수취 주소를 돌려준다. 프로그램은 지갑으로 결제 승인을 서명해 같은 요청을 다시 보낸다. facilitator가 서명과 잔액을 검증하고 블록체인에 정산하면 서버가 자료를 내준다. 회원가입도, 월 구독도, 사람이 누르는 결제 버튼도 필요 없다. 날씨 데이터 한 번, 모델 추론 한 번, 브라우저 세션 한 번처럼 아주 작은 단위로 사고팔 수 있다. 카드의 고정 수수료 때문에 불가능했던 소액 거래를 소프트웨어 속도로 처리한다. 이것은 실제 진전이다. 문제는 그다음이다. 거래 비용이 거의 0에 가까워지고 일부 facilitator가 가스비까지 대신 내주면, 거래 횟수는 고객 수보다 자동화하기 쉬운 숫자가 된다. 한 개발자가 자기 서비스를 시험해도 한 건이고, 디렉터리 봇이 새 엔드포인트를 확인해도 한 건이며, 같은 주체가 지갑을 나눠 반복 정산해도 거래는 계속 늘어난다. ## 거래 횟수는 가장 만들기 쉬운 성장 지표다 독립 분석 프로젝트 x402stats는 자체 필터를 적용해 2026년 8월 6일 기준 8만 5천여 판매자 지갑 가운데 매출 100달러 이상, 서로 다른 구매자 3명 이상, 평균 결제액 0.001달러 이상을 모두 만족한 판매자를 111곳으로 집계했다. 이 기준은 매우 엄격하므로 111이 유일한 정답은 아니다. 다만 지갑 수와 돈을 버는 사업자 수가 전혀 다른 숫자라는 점은 선명하다. 2026년 7월 공개된 연구 프리프린트도 Base의 x402 거래를 추적해 21.2%를 허구성 거래, 63.78%를 연결된 주체 안의 내부 정산으로 분류했다. 아직 동료평가를 거치지 않은 연구이고 온체인 흔적만으로 실제 운영 의도를 완전히 판별할 수도 없다. 그럼에도 거래 횟수가 독립 고객의 지불 의사를 직접 증명하지 못한다는 비판은 피하기 어렵다. 반대쪽 증거도 있다. Visa와 Artemis는 식별된 워시·테스트 활동을 제외한 뒤에도 2026년 4월까지 x402에서 1억 960만 건, 1,500만 달러의 조정 거래를 관찰했다. 전부 허상이라는 뜻은 아니다. 기술은 작동하고 실제 지불도 존재한다. 다만 진짜 질문은 거래가 일어났느냐가 아니라, 서로 독립된 누가 어떤 가치 때문에 돈을 내고 다시 내는가다. 그 답을 보려면 거래량 그래프 대신 돈의 관계를 봐야 한다. ## 에이전트 경제에도 매출의 질이 있다 첫 번째 경계는 독립성이다. 결제 지갑과 판매 지갑의 소유자가 다르고, 구매를 지시한 사람이나 회사도 판매자와 무관해야 한다. 자기 테스트와 생태계 크롤러는 제품이 작동한다는 증거일 수 있지만 시장이 있다는 증거는 아니다. 두 번째 경계는 반복성이다. 한 에이전트가 같은 서비스를 천 번 호출했더라도 그것이 한 개발자의 실험 예산에서 나왔다면 고객 기반은 하나다. 반대로 서로 다른 회사가 업무에 필요한 데이터를 매주 구매하고 비용을 계속 승인한다면 거래 횟수가 적어도 더 단단한 시장이다. 세 번째 경계는 가치 보존이다. 결제액 가운데 판매자가 실제로 남기는 금액, 서비스를 제공하는 원가, facilitator와 지갑·환전·규제 준수 비용을 함께 봐야 한다. 거래가 많아질수록 손실이 커지는 서비스는 에이전트 경제의 대표 사례가 아니라 자동화된 보조금 소진 장치다. 이 세 경계를 통과하면 ‘AI 에이전트가 고객이 된다’는 문장의 뜻도 달라진다. 고객은 모델이나 지갑 주소가 아니다. 예산을 위임하고 결과에 책임지는 사람이나 조직이 고객이다. 에이전트는 그 고객의 구매 빈도를 높이고 거래 단위를 잘게 쪼개는 실행 주체다. ## 결제 규격보다 신뢰와 유통이 더 희소하다 x402는 Coinbase가 시작했지만 지금은 Linux Foundation 아래의 개방형 표준이다. 프로토콜 사용료도 없다. 표준이 널리 퍼질수록 한 회사가 길목을 독점해 통행료를 받기는 오히려 어려워진다. 가치는 주변 층에 쌓인다. Coinbase는 facilitator와 개발자 지갑, Base 네트워크를 갖고 있다. Circle은 USDC와 에이전트 지갑, 소액 정산을 묶는다. Stripe와 AWS는 기존 판매자 계정, 은행 입금, 세금·환불·회계, WAF 배포면을 이미 보유한다. Cloudflare는 봇을 식별하고 콘텐츠와 API 앞에서 결제를 요구할 수 있다. 이 가운데 가장 오래 남을 해자는 결제 메시지의 형식이 아닐 수 있다. 어떤 에이전트가 누구의 권한으로 왔는지, 얼마까지 써도 되는지, 잘못 산 것을 어떻게 취소할지, 어느 판매자를 믿어도 되는지, 무엇이 살 만한 데이터인지 판단하는 층이 더 어렵다. Visa가 지적했듯 에이전트가 잘못 구매했거나 악성 프롬프트가 지출을 돌렸을 때 책임 주체와 되돌리는 절차는 아직 명확하지 않다. 사람 대신 소프트웨어가 초당 수천 번 거래하면 기존의 주문 단위 분쟁과 환불 규칙도 그대로 적용하기 어렵다. 결제 자체보다 위임, 한도, 증거, 취소가 시장의 병목이 된다. ## x402 하나가 모든 결제를 먹지는 않는다 Stripe와 Tempo가 만든 Machine Payments Protocol은 스테이블코인뿐 아니라 카드와 법정화폐, 반복 결제까지 기존 Stripe 운영 체계에 연결한다. Stripe는 x402도 함께 지원한다. 소액 API 호출에는 스테이블코인이 맞을 수 있고, 여행 예약이나 재고 구매처럼 금액이 크고 환불이 필요한 거래에는 카드와 기존 결제망이 유리할 수 있다. 따라서 승자는 하나의 코인이나 프로토콜을 먼저 고른 회사가 아닐 가능성이 크다. 에이전트가 여러 결제 방식을 넘나들어도 같은 예산 정책과 거래 증거, 판매자 신뢰를 유지해주는 곳이 더 강하다. 그리고 그 위에서 실제 돈을 받는 쪽은 에이전트가 반복해서 살 만큼 희소한 데이터와 도구를 가진 공급자다. 다음 고객은 사람이 아닐 수 있다. 그러나 다음 수요까지 자동으로 생기는 것은 아니다. 에이전트 경제는 스크립트가 서로 돈을 돌릴 때가 아니라, 서로 독립된 사람들이 희소한 가치에 예산을 반복해서 위임할 때 시작된다. 그 전까지 거래 그래프는 시장의 증거라기보다 결제 가능성의 증거다. --- 주요 참고: [x402 공식 현황](https://x402.org/?ref=zerodraftlab.com); [x402 판매자 문서](https://docs.x402.org/getting-started/quickstart-for-sellers?ref=zerodraftlab.com); Shengchen Ling 외, [How Agentic Is Agentic Commerce?](https://arxiv.org/abs/2607.12575?ref=zerodraftlab.com); [x402stats 독립 집계](https://x402stats.io/?ref=zerodraftlab.com); Visa·Artemis, [Agentic Payments from the Ground Up](https://www.visa.com/en-us/thought-leadership/innovation/agentic-payments-from-the-ground-up?ref=zerodraftlab.com); [x402 Foundation 출범 발표](https://www.linuxfoundation.org/press/linux-foundation-announces-operational-launch-of-x402-foundation-to-standardize-internet-native-payments-for-ai-agents-and-applications?ref=zerodraftlab.com); Stripe, [Machine Payments Protocol 소개](https://stripe.com/blog/machine-payments-protocol?ref=zerodraftlab.com). 공식 대시보드 수치는 집계 정의가 서로 다르며 계속 변합니다. x402stats의 ‘유기적 판매자’는 해당 프로젝트의 자체 임계값이고, arXiv 연구는 동료평가 전 프리프린트입니다. ### 콘텐츠는 영업 전에 고객을 드러낸다 URL: https://zerodraftlab.com/content-reveals-warm-leads/ Last updated: 2026-09-15T08:35:02.000Z 콘텐츠를 올렸는데 상담이 들어오지 않으면 흔히 둘 중 하나를 탓한다. 조회수가 부족했거나, 영업이 약했다고 말한다. 그래서 마케팅팀은 더 넓은 주제로 도달을 늘리고 영업팀은 더 많은 명단에 연락한다. 콘텐츠와 아웃바운드는 서로 모르는 채 각자의 숫자를 키운다. 이 분리는 초기 사업에서 특히 비싸다. 고객을 아직 잘 모르는 팀이 넓은 콘텐츠를 만들면 엉뚱한 사람이 모인다. 그 반응을 무시하고 차가운 명단에 연락하면 영업은 매번 처음부터 신뢰를 만들어야 한다. 두 활동에 돈과 시간이 들어가지만 고객에 관한 지식은 이어지지 않는다. Finn Mallery의 영상 [「I asked 10 of YC’s fastest-growing founders how they got customers」](https://www.youtube.com/watch?v=4OQd%5FbuPjnE&ref=zerodraftlab.com)은 빠르게 성장한 YC 창업자들에게 들은 내용을 네 단계로 정리한다. 오래된 산업의 쉬운 싸움을 고르고, 고객에게 집요하게 가까이 가고, 그 고객만 멈춰 볼 콘텐츠를 만들고, 반응한 사람에게 개인적으로 연락하라는 순서다. 영상은 이 순서를 2026년의 과학적인 성장 공식처럼 말한다. 그 정도의 인과를 입증할 자료는 공개되지 않았다. 누구를 어떻게 골랐는지, 인터뷰에서 정확히 무엇을 물었는지, 같은 방법을 쓰고 실패한 회사가 얼마나 되는지 알 수 없다. Corgi와 Arini가 보험과 치과 접수 같은 오래된 업무를 다룬다는 점은 YC 회사 페이지에서도 확인되지만, 그 사실만으로 시장 선택이 성장의 원인이 되지는 않는다. 그 과장을 걷어내도 네 단계 사이에는 남는 연결이 있다. **고객 대화에서 얻은 문제 언어가 콘텐츠가 되고, 콘텐츠의 반응이 다음 영업 대상을 드러내며, 영업 대화가 다시 고객 지식을 늘린다.** 콘텐츠와 영업을 두 채널로 보지 않을 때 비로소 하나의 학습 루프가 보인다. ## 고객 대화는 콘텐츠의 원료를 바꾼다 고객과 가까이 있다는 말은 인터뷰 횟수를 자랑하라는 뜻이 아니다. 고객이 어떤 업무를 하다가 멈추는지, 어떤 표현으로 문제를 설명하는지, 이미 무엇에 돈을 쓰고 있는지 알아내는 일이다. 솔루션을 설명하는 시간보다 고객이 자신의 하루를 설명하는 시간이 길어야 한다. 이 대화가 없으면 콘텐츠는 제품의 기능을 바깥으로 번역하는 데 그친다. “AI로 업무를 혁신한다”, “더 빠르고 간편하다” 같은 문장은 누구에게도 틀리지 않지만, 누구의 오늘도 정확히 건드리지 못한다. 반대로 실제 대화에서 반복된 장면은 독자가 자기 일로 알아보는 문장이 된다. 보험 견적의 인수 절차, 치과의 놓친 전화, 매출채권의 반복 확인처럼 업무가 보이는 언어다. 이때 콘텐츠는 이미 알고 있는 답을 크게 외치는 확성기가 아니다. 고객에게서 들은 문제 가설을 공개적으로 시험하는 작은 탐침이다. 같은 문제를 겪는 사람이 멈추고, 저장하고, 자신의 사례를 덧붙이면 가설의 경계가 선명해진다. 아무도 반응하지 않으면 주제, 표현, 고객군 가운데 무엇이 어긋났는지 다시 물을 수 있다. ## 조회수는 얼마나 퍼졌는지 말하고, 반응은 누가 아팠는지 말한다 영상에서 가장 쓸 만한 사례는 200만에 가까운 노출이 매출을 만들지 못한 반면, 더 좁은 글이 훨씬 적은 노출로 매출을 만들었다는 제작자의 경험이다. 수치는 자기보고라 그대로 일반화할 수 없다. 다만 넓은 도달과 자격 있는 수요가 다른 사건이라는 구분은 남는다. 좋은 콘텐츠 성과를 조회수 하나로 줄이면 팀은 문제를 넓혀야 이긴다. 반응한 사람의 직무와 상황을 함께 보면 선택이 달라진다. 잠재 고객 열 명이 자기 업무를 길게 설명한 글은 업계 밖 만 명이 웃고 지나간 글보다 다음 제품과 영업에 더 많은 정보를 줄 수 있다. 그렇다고 모든 좋아요가 영업 기회라는 뜻도 아니다. 사람은 동의해서, 나중에 읽으려고, 지인을 떠올려서, 작성자를 응원하려고 반응한다. 웹사이트 방문은 더 약하다. 방문 사실만으로 누가 어떤 문제를 가졌는지 알 수 없고, 익명 방문자를 찾아내는 기술이 접촉 허가를 만들어주지도 않는다. **콘텐츠는 고객을 자동으로 데려오는 기계보다, 어디에 고객일 가능성이 있는 사람이 있는지 보여주는 공개 조사에 가깝다.** 조사 결과를 읽으려면 도달과 반응, 문제 적합, 대화 의사를 서로 다른 신호로 봐야 한다. ## 웜은 온도가 아니라 맥락의 양이다 콜드와 웜을 명단의 속성처럼 다루면 좋아요 한 번이 곧 연락 허가로 바뀐다. 하지만 따뜻함은 상대가 우리를 봤다는 사실만으로 생기지 않는다. 어떤 문제를 어떤 맥락에서 함께 보고 있는지가 분명할수록 첫 대화에 필요한 설명이 줄어드는 것이다. 따라서 콘텐츠 뒤의 영업은 “제 글에 좋아요를 눌렀으니 제품을 소개하겠습니다”로 시작해서는 안 된다. 더 정확한 질문은 이렇다. 상대가 반응한 내용이 우리 제품이 해결하는 문제와 같은가. 그 사람이 그 문제를 실제로 다루는 역할인가. 지금 말을 거는 일이 상대에게도 대화할 이유를 주는가. 이 세 질문을 통과한 반응만 골라도 아웃바운드의 양은 줄어든다. 대신 첫 메시지에는 출처가 생긴다. 왜 이 사람에게 연락하는지, 어느 문제를 함께 보고 있는지, 무엇을 팔기 전에 무엇을 확인하려는지가 짧게 설명된다. 그렇다면 반응을 포착한 뒤 어디까지 접근해야 영업이 되고, 어디서부터 감시와 스팸이 될까. 경계는 반응의 크기보다 상대가 남긴 맥락과 접촉 허용 범위에서 정해진다. 콘텐츠를 봤다는 사실, 문제에 공감했다는 표현, 대화를 요청한 행동은 같은 강도의 신호가 아니다. 이 차이를 무시하면 웜 아웃바운드는 이름만 따뜻한 콜드 스팸이 된다. ## 관심, 문제 적합, 접촉 허용은 따로 움직인다 노출과 방문은 관심이 있었을 가능성만 남긴다. 이 단계에서는 개인을 특정해 연락할 근거가 거의 없다. 좋아요와 팔로우는 사람이 드러나지만 문제 적합은 아직 모호하다. 구체적인 댓글, 같은 문제를 설명한 답장, 관련 자료의 요청은 무엇에 반응했는지 알려준다. 상담 신청이나 제품 가입처럼 직접 다음 행동을 고른 경우에야 접촉 허용도 강해진다. 세 신호는 순서대로만 강해지지 않는다. 타깃 회사의 임원이 글을 저장했더라도 지금 그 문제를 맡고 있지 않을 수 있다. 작은 회사의 실무자가 댓글 하나에 정확한 운영 마찰을 적었다면 문제 적합은 높지만 구매 권한은 낮을 수 있다. 뉴스레터를 오래 읽은 사람도 판매 연락을 원하지 않을 수 있다. 그래서 좋은 웜 아웃바운드는 사람을 점수로 압축하기 전에 반응의 문맥을 읽는다. “치과 예약 전화의 30%가 끊긴다”는 글에 자신의 지점 상황을 적은 운영자에게는 그 장면을 묻는 대화가 가능하다. 일반적인 AI 밈에 좋아요를 누른 사람에게 치과용 제품을 파는 것은 문맥을 발명하는 일이다. ## 첫 연락은 판매 문구보다 관찰의 영수증에 가깝다 개인화는 이름과 회사명을 문장에 끼우는 기술이 아니다. 연락한 이유를 상대가 검증할 수 있게 밝히는 일이다. 어떤 공개 반응을 보았고, 그 반응이 어떤 문제와 연결된다고 읽었으며, 해석이 맞는지 짧게 묻는다. 틀렸다면 답하지 않아도 되거나 거절할 수 있어야 한다. 예를 들어 “최근 글 잘 봤습니다. 저희 솔루션을 소개하고 싶습니다”는 누구에게나 보낼 수 있다. 반면 “예약 취소 뒤 재연락이 수작업이라는 댓글을 봤습니다. 취소 당일보다 다음 날 회수율이 더 떨어지는지도 궁금했습니다”는 관찰과 질문이 이어진다. 제품을 말하기 전에도 상대가 답할 이유가 있다. 이 방식은 메시지를 길게 쓰라는 뜻이 아니다. 상대가 공개하지 않은 매출, 조직 문제, 개인 사정을 추정해 놀라게 만들 이유도 없다. 공개된 업무 맥락 안에서 한 가지 문제만 묻고, 답이 없으면 자동 추적 메시지로 압박하지 않는 편이 낫다. 따뜻함은 데이터의 양이 아니라 설명해야 할 거리가 줄었다는 뜻이다. ## 자동화는 좋은 맥락을 대량으로 복제하지 못한다 영상은 LinkedIn에서 주당 많은 연결 요청을 자동화하는 방법도 권한다. 이 부분은 그대로 가져오면 안 된다. LinkedIn 사용자 약관은 비인가 자동화 수단으로 연락처를 추가하거나 메시지를 보내는 행위를 금지하며, 서비스는 연결 수와 연락 기능을 제한할 수 있다. 제한 안에서 자동화하면 안전하다는 제작자의 설명은 공식 허가가 아니다. 운영상으로도 같은 문제가 생긴다. 자동화가 늘리는 것은 접촉 수이지 맥락의 정확도가 아니다. 약한 신호까지 명단에 넣고 문장 몇 곳만 바꾸면 웜 아웃바운드의 장점이 사라진다. 상대는 자신이 관찰된 이유보다 자동화된 이유를 먼저 알아챈다. 자동화가 맡을 수 있는 일은 내부 정리에 가깝다. 공개 반응을 주제별로 모으고, 이미 대화한 사람을 중복해서 찾지 않으며, 답장이 온 맥락을 다음 고객 조사에 연결하는 일이다. 실제 연결 요청과 메시지는 플랫폼이 허용한 기능과 상대의 기대 안에서 사람이 검토해야 한다. ## 콘텐츠 성과는 다음 대화의 질로 돌아와야 한다 이 루프를 운영하면 콘텐츠 대시보드도 달라진다. 조회수와 팔로워는 배포 상태를 알려준다. 그 뒤에 어떤 고객 역할이 반응했는지, 어떤 문제 문장에 자기 사례를 보탰는지, 몇 건이 자격 있는 대화로 이어졌는지를 붙여야 한다. 대화가 생겼다고 성공이 끝나는 것도 아니다. 같은 문제가 실제로 반복됐는지, 현재 대안에 돈이나 시간이 쓰이고 있는지, 제안 뒤에 파이프라인과 계약이 생겼는지, 그 계약이 획득·납품 비용을 빼고 기여이익을 남겼는지까지 이어서 본다. 조회수가 적더라도 이 흐름이 선명한 글은 다시 쓸 가치가 있다. 반대로 조회수도 높고 상담도 많지만 자격 없는 문의만 쌓인다면 콘텐츠가 문제를 너무 넓게 약속했을 수 있다. 연락은 잘 오지만 답장이 없으면 반응 신호를 과대평가했거나 첫 메시지에 상대의 맥락이 없을 수 있다. 계약은 생기는데 납품 비용이 크다면 콘텐츠보다 오퍼와 운영 범위를 고쳐야 한다. ## 루프가 닫히면 다음 글의 주제가 달라진다 영업 대화는 콘텐츠가 만든 관심을 수확하는 마지막 단계로 끝나지 않는다. 어떤 문장이 오해를 낳았는지, 예상과 다른 역할이 반응했는지, 사람들이 왜 지금은 사지 않는지 알게 된다. 이 정보가 다음 글과 제품 판단으로 돌아가야 한다. 그러면 발행 회의에서 “이번 주에는 무엇이 잘 터질까”보다 “지난 대화에서 반복됐지만 아직 설명하지 못한 문제는 무엇인가”를 묻게 된다. 영업팀도 새 명단의 크기보다 어느 글의 어떤 문제에 반응한 사람과 이야기해야 하는지 볼 수 있다. 콘텐츠와 아웃바운드가 같은 고객 기록을 쓰기 시작한다. 영상의 네 단계는 모든 회사를 빠르게 키우는 공식이 아니다. 시장의 구조, 계약 주기, 규제, 제품의 완성도에 따라 작동 범위가 달라진다. 다만 고객 조사, 콘텐츠, 영업을 서로의 뒤처리로 두지 않는 순서는 유효하다. **고객의 말을 받아 쓴 콘텐츠는 더 크게 퍼지기 전에 누구와 대화해야 하는지부터 드러낸다. 그 대화가 다시 다음 글을 바꿀 때 콘텐츠는 영업의 앞단이 아니라 사업이 고객을 배우는 반복 장치가 된다.** --- 주요 출처: Finn Mallery, [I asked 10 of YC’s fastest-growing founders how they got customers (everything I learned)](https://www.youtube.com/watch?v=4OQd%5FbuPjnE&ref=zerodraftlab.com); Y Combinator, [Corgi Insurance](https://www.ycombinator.com/companies/corgi-insurance?ref=zerodraftlab.com), [Arini](https://www.ycombinator.com/companies/arini?ref=zerodraftlab.com), [Gojiberry AI](https://www.ycombinator.com/companies/gojiberry-ai?ref=zerodraftlab.com); LinkedIn, [User Agreement](https://www.linkedin.com/legal/user-agreement?ref=zerodraftlab.com). 영상의 네 단계와 사례는 공개 자동자막을 대조했으며, 보편적 성장 공식·95:5 비율·예상 계약 수·회사별 매출 수치는 독립 검증이 없어 일반화하지 않았습니다. 콘텐츠를 공개 조사로 보고 관심·문제 적합·접촉 허용을 나눈 부분은 Zero Draft Lab의 해석입니다. ### 토스쇼핑 쉐어링크는 새로운 쿠팡파트너스가 아니다 URL: https://zerodraftlab.com/toss-sharelink-editorial-filter/ Last updated: 2026-09-15T08:35:02.000Z “쿠팡파트너스 다음은 토스쇼핑 쉐어링크다.” 부업 계정에서 이런 문장이 돌기 시작했다. 근거로 붙는 숫자는 10%다. 쿠팡파트너스의 공개 이용가이드 2024년 12월판에 적힌 일반 상품 기본 지급률 3%보다 크다. 토스는 상품 목록을 가져오고 추적 링크를 발급하는 Open API까지 열었다. 여기까지만 보면 자동화 문제처럼 보인다. 잘 팔리는 상품을 매일 불러오고, AI로 소개문을 만들고, 링크를 붙여 블로그와 SNS에 뿌린다. 상품이 팔리면 결제액의 10%를 받는다. 상품 데이터까지 API로 들어오니 남은 일은 파이프라인을 연결하는 것뿐인 듯하다. 공식 문서를 읽으면 절반은 맞다. 토스쇼핑 쉐어링크는 클릭 후 24시간 안에 발생한 구매를 마지막으로 클릭한 크리에이터의 실적으로 잡는다. 처음 공유한 상품이 아니라 다른 상품을 사도 인정한다. Open API에서는 카테고리 베스트, 전체 베스트, 하루특가, 상품 상세, 가격, 품절 상태를 읽고 추적 링크를 만들 수 있다. 나머지 절반은 기한과 조건에 있다. 현재 10%는 기본 5%에 프로모션 5%를 더한 값이다. 토스의 2026년 6월 30일 공지에 따르면 프로모션은 9월 25일까지다. 기준도 링크 생성일이나 결제일이 아니라 **구매확정일**이다. 마감 직전에 판매된 주문은 배송과 구매확정이 늦어지면 10% 적용을 받지 못할 수 있다. 장기 수익은 5%로 계산해야 한다. ## 10%보다 월 200개가 더 중요한 숫자다 토스는 쉐어링크 랜딩페이지에서 2026년 6월 내부 데이터를 공개했다. 처음 링크를 복사한 뒤 첫 수익까지 평균 5일, 한 달 안에 수익이 발생한 크리에이터 비율 83.7%, 월 200개 이상 상품을 공유한 사람들의 판매금액 3,100만 원이다. 최근 한 달 최고 예상 수익금은 1,000만 원이라고 광고한다. 그대로 성공 확률로 읽으면 안 된다. 83.7%가 벌었다는 수익의 하한은 10원일 수 있다. 3,100만 원이 평균인지 중앙값인지, 표본이 몇 명인지도 페이지에 적혀 있지 않다. 월 1,000만 원 역시 평균이 아니라 가장 높은 한 명의 예상 수익이다. 판매확정과 실제 지급 사이에도 차이가 있다. 그래도 월 200개라는 활동량은 숨길 수 없는 단서다. 하루에 여섯 개가 넘는 상품을 계속 골라 공유해야 토스가 성공 사례로 내세우는 집단에 들어간다. 한 번 잘 쓴 리뷰가 오래 돈을 버는 구조보다, 오늘 팔릴 상품을 계속 교체하는 편성 사업에 가깝다. 상품 수요가 없는 것도 아니다. 토스쇼핑 공개 페이지에는 스파클 생수 500ml 80개 묶음이 80만 회 넘게 조회되고 리뷰가 2만 개 이상 쌓여 있다. 캡슐세제와 화장지, 물티슈도 수십만 회 조회와 수천 개 리뷰를 보인다. 이미 구매가 일어나는 시장 위에 외부 판매 채널을 붙이는 프로그램이다. 문제는 이 수요에 접근하는 방식이다. PC에서 토스쇼핑 상품 페이지를 열면 가격과 구매 버튼 대신 QR코드가 나온다. 가격은 모바일에서 확인하라고 한다. 앱인토스 개발자 커뮤니티에서도 토스 직원은 다른 토스 서비스로 바로 이동시키는 별도 SDK나 API를 제공하지 않는다고 답했다. 검색 블로그를 PC로 읽는 사람에게는 구매 단계가 하나 더 생긴다. 그래서 토스쇼핑 쉐어링크는 쿠팡파트너스의 링크만 바꿔 끼우는 사업이 아니다. 쿠팡이 장기간 쌓은 상품 검색 습관과 구매 동선을 그대로 빌릴 수 없고, 모바일 피드에서 발견과 클릭을 한 번에 만들어야 한다. 높은 수수료는 이 유통 마찰을 상쇄하기 위해 토스가 지불하는 시장 진입비에 가깝다. Open API가 이 마찰을 없애주지는 않는다. API가 줄이는 것은 상품을 찾고 링크를 만드는 비용이다. 모두가 같은 베스트 상품과 하루특가를 받을 수 있게 되면 링크의 공급은 급격히 늘어난다. 그다음 희소해지는 것은 상품 데이터가 아니라, 어떤 상품을 남기고 무엇을 버렸는지 설명하는 판단이다. 자동화해야 할 대상도 여기서 갈린다. 게시물 수를 늘리는 기계보다 먼저 필요한 것은 추천 후보를 줄이는 편집 장치다. ## 베스트셀러가 추천상품은 아니다 토스쇼핑 전자제품 인기 목록에는 조회 수가 수만 회인 무선청소기가 평점 3.1점과 3.4점으로 노출돼 있다. 많이 팔렸다는 사실은 구매 의도가 있다는 뜻이지, 다시 권할 만한 상품이라는 뜻은 아니다. 베스트셀러 API의 순위를 그대로 콘텐츠 순위로 옮기면 크리에이터가 맡아야 할 판단을 플랫폼 랭킹에 넘기게 된다. 반대로 생활용품 목록에는 세제, 화장지, 물티슈처럼 평점 4.7점 안팎과 리뷰 수천 개가 함께 쌓인 묶음 상품이 많다. 반복구매가 일어나고 제품 차이를 가격, 용량, 리뷰, 배송일로 설명할 수 있다. 전자제품처럼 고장 여부를 설명하거나 건강기능식품처럼 효능 표현을 다룰 필요도 적다. 낮은 객단가는 대용량 묶음으로 일부 보완된다. 이 차이는 첫 편성 주제를 정해준다. “오늘의 인기상품”은 플랫폼이 이미 제공한다. 외부 편집자가 만들 수 있는 것은 “오늘 많이 팔리지만 추천하지 않는 상품”과 “반복해서 사도 될 조건을 갖춘 대용량 생필품”의 구분이다. 같은 상품을 밀더라도 평점, 리뷰 수, 할인율, 품절 여부를 공개하고 제외 이유까지 남기면 링크가 아니라 판단을 축적할 수 있다. ## 콘텐츠 공장은 프로모션이 끝나면 멈춘다 현재 10%에서 구매액 3,100만 원은 수수료 310만 원이다. 기본 5%로 돌아가면 155만 원이다. 같은 제작량과 트래픽을 유지해도 수익이 절반이 된다. 자동화 비용이 낮더라도 검수, 계정 운영, 영상 편집, 댓글 대응에 쓰는 시간은 남는다. 그러므로 실험의 손익은 처음부터 5%로 다시 계산해야 한다. 프로모션 수익으로만 성립하는 콘텐츠 형식은 9월 이후 폐기될 모델이다. 구매확정 10건을 만들기 전까지 서버와 데이터베이스를 붙일 이유도 없다. 모바일 피드에서 생필품 후보를 직접 고르고, 클릭과 주문, 구매확정, 반품을 기록하면 API보다 먼저 필요한 숫자가 나온다. 확정 수익을 클릭 수로 나눈 값과 콘텐츠 제작시간으로 나눈 값이다. 토스가 공개한 성공 사례처럼 월 200개를 공유해야 한다면 운영자는 두 가지 중 하나를 선택해야 한다. 상품마다 얕은 소개를 대량 생산하거나, 하루 편성 안에서 같은 판단 기준을 반복해 신뢰를 쌓는다. 앞의 방식은 API를 연결한 다음 날부터 복제된다. 뒤의 방식은 무엇을 제외했는지가 기록으로 남는다. ## 코드는 판매가 확인된 뒤에 붙는다 Open API는 아직 시범운영 중이다. 호출 서버의 고정 출발지 IP를 등록해야 하고, 문서끼리도 테스트 환경 유무에 대한 설명이 엇갈린다. 상품 조회와 신규 링크 발급은 각각 하루 1만 건으로 제한되며 랭킹은 하루 한 번 갱신된다. 토스도 응답과 링크를 저장해 재사용하라고 권한다. 이 조건에서 첫 시스템은 거대한 상품 사이트가 아니다. 하루 한 번 후보를 받아 품절 상품과 낮은 평점 상품을 빼고, 사람이 고른 소수 상품의 추적 링크를 저장하는 정도면 충분하다. 자동 게시까지 연결하면 잘못된 가격, 종료된 특가, 과장된 소개도 같은 속도로 퍼진다. 운영정책은 자동으로 앱을 열거나 과도하게 클릭을 유도하는 방식, 무동의 메시지와 댓글 홍보를 금지하고 있다. 유통 채널도 모바일에서 시작해야 한다. Threads나 짧은 영상에서 “세 개 중 하나는 거른다”는 편집 포맷을 반복하고, 실제 구매확정이 쌓인 뒤 웹 아카이브를 붙이는 순서다. YouTube에서는 설명란이나 고정 댓글만으로 부족하고 제목 또는 영상 안에도 경제적 이해관계를 밝혀야 한다. 링크를 많이 숨기는 것보다 광고임을 드러낸 상태에서 계속 클릭받는 편이 오래 간다. 토스쇼핑 쉐어링크의 초기 기회는 분명하다. 수수료가 높고, 실제 상품 수요가 있으며, 데이터와 링크 발급도 자동화할 수 있다. 동시에 그 조건들은 상품 소개문을 가장 빨리 값싼 것으로 만든다. 같은 API를 받은 운영자 사이에서 차이를 만드는 것은 더 많은 링크가 아니다. **링크를 만드는 비용이 0에 가까워질수록, 팔지 않기로 한 상품의 목록이 편집자의 자산이 된다.** --- 주요 출처: 토스쇼핑 쉐어링크 [공식 소개](https://sharelink.toss.im/?ref=zerodraftlab.com), [수익금 계산](https://sharelink-docs.toss.im/guide/settlement?ref=zerodraftlab.com), [2026년 6월 30일 프로모션 공지](https://sharelink-docs.toss.im/help/notice?ref=zerodraftlab.com), [Open API 연동 가이드](https://sharelink-docs.toss.im/guide/open-api?ref=zerodraftlab.com), [API 공통 규약](https://sharelink-docs.toss.im/guide/open-api/convention?ref=zerodraftlab.com), [운영정책](https://sharelink-docs.toss.im/help/policy?ref=zerodraftlab.com); 토스쇼핑 [공개 상품 페이지](https://toss.shopping/?ref=zerodraftlab.com), [생활용품](https://toss.shopping/category/22343?ref=zerodraftlab.com), [전자제품](https://toss.shopping/category/16443?ref=zerodraftlab.com); 앱인토스 개발자 커뮤니티 [토스쇼핑 이동 관련 답변](https://techchat-apps-in-toss.toss.im/t/topic/4102?ref=zerodraftlab.com); 쿠팡파트너스 [이용가이드 2024년 12월판](https://partners.coupangcdn.com/partners-guide/partners-guide-20250324160743.pdf?ref=zerodraftlab.com). 토스가 공개한 크리에이터 수치는 2026년 6월 내부 데이터지만 표본 수와 분포가 공개되지 않아 일반적인 수익 수준으로 해석하지 않았다. ### AI 검색은 키워드를 질문 묶음으로 찢는다 URL: https://zerodraftlab.com/ai-search-query-fanout/ Last updated: 2026-09-15T08:35:03.000Z “직원 열 명이 쓰기 좋은 CRM”을 검색하면 사람은 한 문장을 입력한다. AI 검색은 그 문장을 그대로 찾아다니지 않는다. 가격, 도입 난도, 사용자 수 제한, 기존 도구와의 연동, 고객지원, 보안처럼 답에 필요한 질문을 여러 갈래로 나눠 자료를 모은다. Google은 이 동작을 *query fan-out*이라고 설명한다. AI Mode와 AI Overviews가 하나의 질문을 하위 주제와 데이터 출처별 검색으로 펼친 뒤, 결과를 합쳐 답을 만든다는 뜻이다. 검색창에는 질문 하나가 보이지만 뒤에서는 작은 조사팀이 동시에 움직인다. Ahrefs의 영상 [〈Learn 80% of AEO in 19 Minutes〉](https://www.youtube.com/watch?v=58MR03s0ev8&ref=zerodraftlab.com)도 여기서 출발한다. 하나의 대표 키워드에서 순위가 높아도, AI가 펼친 질문들에 브랜드가 등장하지 않으면 추천 답변에는 들어가기 어렵다고 말한다. **검색의 단위가 키워드 하나에서 판단에 필요한 질문 묶음으로 바뀌고 있다.** 콘텐츠팀이 관리해야 할 것도 페이지 순위만이 아니라, 고객의 결정을 구성하는 질문과 각 질문에 붙일 수 있는 증거다. ## 한 검색어 뒤에는 작은 구매위원회가 숨어 있다 “직원 열 명이 쓰기 좋은 CRM”을 다시 보자. 재무 담당자는 월 비용과 해지 조건을 묻는다. 현장 사용자는 배우기 쉬운지, 매일 입력해야 할 항목이 많은지 본다. 개발자는 API와 데이터 내보내기를 확인한다. 대표는 도입 후 실제로 매출 누수를 줄일 수 있는지 알고 싶어 한다. 사람 한 명이 검색했어도 질문 안에는 여러 역할이 들어 있다. AI 검색은 이 역할들을 하위 질의로 펼친다. 제품 목록만 있는 페이지, “쉬운 CRM”이라는 형용사를 반복하는 페이지, 기능을 백 개 나열한 페이지는 그중 일부에만 답한다. 기존 SEO에서는 대표 키워드와 페이지의 대응이 중요한 작업 단위였다. 검색 의도에 맞는 페이지를 만들고, 내부 링크와 외부 링크로 권위를 쌓았다. 이 원칙이 사라진 것은 아니다. Google도 AI 검색을 위해 별도의 특수 최적화나 새로운 마크업이 필요한 것은 아니며, 기존 검색 기본기가 그대로 적용된다고 밝힌다. 달라지는 것은 한 페이지가 경쟁하는 장면이다. AI는 대표 키워드의 상위 문서만 요약하지 않고, 답을 만들기 위해 가격표·지원 문서·비교 글·사용자 후기·영상·공식 정책처럼 서로 다른 역할의 자료를 모을 수 있다. “이 키워드에서 몇 등인가”만 보면 어떤 질문에서 증거가 비는지 알 수 없다. ## 질문이 늘었다고 페이지도 늘리면 안 된다 Query fan-out을 들은 콘텐츠팀이 가장 쉽게 하는 실수는 하위 질문마다 글을 하나씩 만드는 것이다. “10인 CRM 가격”, “10인 CRM 보안”, “10인 CRM 추천”, “10인 CRM 연동”을 모두 별도 페이지로 만들면 표면적 범위는 넓어진다. 하지만 내용이 같은 제품 소개를 조금씩 바꾼 것이라면 증거는 늘지 않는다. 하위 질의는 콘텐츠 생산 목록이 아니라 구매 판단의 구조를 보여준다. 가격 질문에는 현재 요금과 포함 범위가 필요하다. 보안 질문에는 인증, 데이터 위치, 보존 정책 같은 검증 가능한 사실이 필요하다. 도입 난도에는 실제 설정 단계와 걸린 시간이, 경쟁 제품 비교에는 동일한 기준과 불리한 조건까지 있어야 한다. 같은 사실을 여러 URL에 복제하면 페이지 수는 늘어도 답의 재료는 거의 늘지 않는다. 반대로 가격 페이지 하나가 조건과 갱신일을 정확히 밝히고, 고객 사례 하나가 도입 전후의 작업 변화를 보여주며, 독립된 리뷰가 사용 중 마찰을 기록하면 세 문서는 서로 다른 질문을 맡는다. 그래서 AEO의 콘텐츠 단위는 “페이지 한 장”보다 “검증 가능한 답 하나”에 가깝다. 그 답들이 한 페이지에 모일 수도 있고, 제품 문서와 영상과 외부 리뷰에 나뉠 수도 있다. 중요한 것은 URL 개수가 아니라 질문마다 다른 근거가 있는가다. ## AI가 좋아하는 형식보다 답이 필요한 이유를 먼저 봐야 한다 Ahrefs 영상은 결론을 먼저 쓰는 BLUF, 독립적으로 이해되는 짧은 섹션, 목록과 비교, 명확한 개체명, 최신 갱신일을 권한다. AI가 답의 일부를 가져다 쓰기 쉽게 만드는 실용적인 편집법이다. 동시에 Ahrefs의 Brand Radar와 Keywords Explorer로 빠진 질문과 경쟁사 언급을 찾는 제품 사용법으로 이어진다. 이해관계를 빼고 형식만 받아들이면 다시 체크리스트 장사가 된다. 모든 글 첫 줄에 요약을 넣고, H2를 잘게 나누고, 연도를 제목에 붙이는 것으로 AEO가 끝났다고 믿게 된다. 그러나 형식은 이미 없는 증거를 만들지 못한다. 가격이 비공개인데 가격 비교표를 잘 쓸 수 없고, 고객이 제품을 계속 쓰지 않는데 최신 사례를 꾸밀 수는 없다. Google의 안내도 같은 경계선을 긋는다. AI 기능에 노출되기 위한 별도의 AI 전용 파일이나 특수 스키마는 필요하지 않다. 크롤링 가능성, 도움이 되는 본문, 정확한 구조화 데이터, 최신 정보처럼 기존 검색 품질 원칙이 먼저다. Query fan-out은 새로운 꼼수가 아니라 검색 시스템이 질문을 더 넓게 조사한다는 설명이다. 여기까지 오면 공개 구간의 결론은 충분하다. 대표 키워드를 이기는 페이지 한 장보다, 결정 질문마다 확인할 수 있는 증거의 묶음이 AI 검색에 더 잘 맞는다. 그러면 실제 콘텐츠 운영에서는 무엇을 채우고, 무엇을 더 만들지 말아야 할까. 먼저 키워드 목록을 질문 그래프로 바꿔야 한다. 가운데에 고객이 내리는 결정을 놓고, 그 결정을 바꿀 수 있는 질문만 가지로 연결한다. 질문의 수가 아니라 답에 따라 선택이 달라지는지가 기준이다. ## 첫 단계는 하위 질의 수집이 아니라 결정 분해다 “10인 CRM”이라면 가운데 결정은 ‘지금 이 팀이 이 제품을 도입할 것인가’다. 그다음에 비용, 학습 부담, 데이터 이동, 기존 도구와의 연동, 관리자 통제, 지원 품질을 붙인다. 각 가지에는 답을 요구하는 사람과 선택이 뒤집히는 조건을 적는다. 예산 질문에서는 좌석·기능별 총비용과 해지 조건에 따라 선택이 바뀐다. 이때 필요한 증거는 갱신일이 있는 공식 가격표다. “합리적인 가격”이라는 소개문은 답이 되지 않는다. 팀이 실제로 쓸 수 있는지는 설정에 걸린 시간과 매일 필요한 입력량이 가른다. 도입 기록, 실제 화면, 사용자 관찰이 답을 만든다. 데이터 주권을 묻는다면 내보내기 형식과 종료 후 보존 조건을 지원 문서·계약·테스트 결과에서 확인해야 한다. 연동 질문에는 필수 통합의 범위와 실패 방식을 보여주는 문서나 동작 영상이 필요하다. 이 질문들을 글 제목으로 곧장 바꾸지 않는다. 먼저 현재 증거가 어디에 있는지 연결한다. 가격 질문은 가격 페이지가 맡고, 데이터 이동은 지원 문서가 맡으며, 실제 사용 난도는 고객 사례나 영상이 맡을 수 있다. 한 자료가 여러 질문에 답해도 되고, 중요한 질문 하나에 서로 다른 자격의 자료가 함께 붙어도 된다. 이렇게 보면 콘텐츠 공백과 제품 공백도 구분된다. 기능은 있는데 설명이 없으면 콘텐츠 공백이다. 연동 자체가 자주 끊기면 제품 공백이다. 고객이 도입 효과를 측정하지 않았다면 증거 공백이다. 글로 해결할 수 없는 빈칸을 글감으로 바꾸지 않는 것이 이 작업의 첫 번째 절약이다. ## 증거는 출처의 역할까지 나눠야 한다 공식 사이트는 가격, 정책, 제품 범위처럼 회사가 책임질 사실에 강하다. 고객은 실제 사용의 마찰과 결과를 증언한다. 파트너는 연동 범위를 확인한다. 독립 비교자는 대안 사이의 기준을 제공한다. YouTube는 설정과 작동을 화면으로 보여준다. 모든 표면에 같은 소개문을 뿌리면 AI가 발견할 URL은 늘 수 있다. 그러나 같은 당사자의 주장을 여러 번 읽은 것에 가깝다. 질문 그래프의 각 가지에는 링크뿐 아니라 누가 어떤 자격으로 말하는지도 붙여야 한다. 자사 정본이 맡을 질문과 외부 증거가 필요한 질문을 섞지 않기 위해서다. 이 구분은 부정적인 정보도 자산으로 만든다. “설정은 쉽다”보다 “초기 데이터 정리에 이틀이 들었고 이후 주간 보고가 한 시간 줄었다”는 사례가 더 많은 질문에 답한다. 마찰을 숨기지 않은 기록은 도입 난도, 필요한 준비, 기대 효과의 범위를 한꺼번에 보여준다. ## 최신성은 날짜 장식이 아니라 변경 책임이다 가격, 기능, 정책, 지원 범위는 바뀐다. 제목에 2026을 붙이는 것보다 누가 언제 무엇을 다시 확인할지 정하는 편이 낫다. 갱신일만 바꾸고 내용은 그대로 두면 최신성 신호가 아니라 오래된 증거를 새것처럼 보이게 하는 장식이 된다. 질문 그래프에서 변동성이 큰 가지를 표시하면 관리 우선순위가 보인다. 가격과 정책은 짧은 주기로, 고객의 장기 효과는 더 긴 주기로 확인한다. 경쟁 제품 비교는 상대가 바뀔 때마다 기준을 다시 점검한다. 오래된 페이지를 무조건 새로 쓰기보다, 결정에 영향을 주는 사실이 바뀌었는지 기록한다. 크롤러 접근도 같은 운영 문제다. robots.txt나 방화벽이 검색·AI 봇을 막으면 좋은 증거가 있어도 읽히지 않을 수 있다. 다만 모든 봇을 허용하는 것이 정답은 아니다. 저작권, 서버 비용, 보안 정책을 고려해 어떤 크롤러에 어떤 표면을 열지 정하고, 실수로 닫힌 공개 문서가 없는지 확인해야 한다. ## 측정은 인용 횟수에서 사업 결과로 이어져야 한다 Query fan-out은 사용자가 보지 못하는 내부 동작이고, 모델과 시점에 따라 달라진다. 하위 질의를 완벽하게 복원하겠다는 목표는 금방 도구 대시보드 관리로 변한다. 대표적인 구매 질문을 반복 측정하고, 브랜드가 어떤 답과 출처에 함께 등장하는지 관찰하는 정도가 현실적이다. 그다음에는 인용과 매출 사이의 단계를 분리한다. AI 답변에서 언급됐는가, 링크 방문이 있었는가, 방문자가 자격 있는 문의나 가입으로 이어졌는가, 그 고객이 기여이익을 남겼는가를 따로 본다. 인용이 늘고 문의가 그대로라면 질문 선택이나 제안이 빗나갔을 수 있다. 방문은 적어도 고의도 문의가 늘었다면 단순 트래픽으로는 잡히지 않는 효과가 있다. 자기보고도 보조 근거가 된다. 상담이나 가입에서 “어디서 알게 됐는가”를 묻고 AI 검색, YouTube, 비교 글 같은 선택지를 남기면 다크 퍼널의 일부를 볼 수 있다. 다만 기억에 의존한 응답이므로 분석 도구의 유입 기록과 함께 읽어야 한다. ## Query fan-out은 콘텐츠 생산량을 줄이는 지도다 질문 그래프를 만들면 새 글 목록보다 먼저 삭제할 목록이 나온다. 같은 설명을 반복하는 페이지, 실제 결정과 무관한 롱테일 키워드, 증거 없이 형식만 갖춘 비교표, 갱신할 책임자가 없는 연도형 글은 줄일 수 있다. 남길 것은 고객의 선택을 바꾸는 질문과 그 질문에 책임 있게 답하는 자료다. 어떤 것은 공식 가격표이고, 어떤 것은 한 고객의 실패 기록이며, 어떤 것은 파트너의 연동 문서다. 에세이는 흩어진 증거가 어떤 판단으로 이어지는지 설명한다. AI 검색이 질문 하나를 여러 갈래로 찢는다면 콘텐츠팀은 페이지를 같은 수만큼 늘릴 필요가 없다. 고객의 결정이 갈라지는 지점을 찾고, 그곳의 빈칸이 글인지 제품인지 증거인지 구분하면 된다. **Query fan-out은 더 많이 쓰라는 신호가 아니다. 고객의 질문이 갈라지는 곳에서 검증 가능한 빈칸을 줄이라는 신호다.** --- 주요 출처: Ahrefs, [Learn 80% of AEO in 19 Minutes](https://www.youtube.com/watch?v=58MR03s0ev8&ref=zerodraftlab.com) 및 [Query fan-out 분석](https://ahrefs.com/blog/query-fan-out/?ref=zerodraftlab.com); Google Search Central, [AI features and your website](https://developers.google.com/search/docs/appearance/ai-features?ref=zerodraftlab.com)와 [Top ways to ensure your content performs well in Google's AI experiences on Search](https://developers.google.com/search/docs/fundamentals/ai-optimization-guide?ref=zerodraftlab.com); Google, [AI Mode 소개](https://blog.google/products-and-platforms/products/search/ai-mode-search/?ref=zerodraftlab.com). Ahrefs 자료는 AEO 설명과 자사 제품 사용법이 함께 있는 공급자 자료다. 영상에는 공개 자막이 없어 본문은 영상의 공개 설명문과 Google 공식 문서를 교차해 작성했다. 질문 그래프와 증거 공백의 구분은 이 글의 분석이다. ### 사람을 멈추는 첫마디를 만드는 법 URL: https://zerodraftlab.com/hook-is-attention-contract/ Last updated: 2026-09-15T08:35:04.000Z 사람을 멈춰 세우는 첫마디를 모으면 이런 문장들이 나온다. > 이거 모르면 진짜 손해예요 > 잘되는 사람들은 다 ○○하더라고요 > 이거 제대로 아는 사람 별로 없어요 > 이런 적 한 번쯤 있죠? > 이걸 진작 알았으면 좋았을 텐데 > 다들 ○○인 줄 아는데 사실은 ○○이에요 > 이거 다들 그냥 넘어가는 건데 > 딱 하나만 바꾸면 돼요 > 아마 처음 들어볼걸요? > ○○번 해보니까 결국 답은 하나예요 이 문장들은 후킹의 뼈대다. 빈칸에 주제어를 하나 넣는다고 내 문장이 되지는 않는다. “이거 모르면 진짜 손해예요” 뒤에 제품 이름을 붙이고, “잘되는 사람들은 다” 뒤에 내가 팔고 싶은 행동을 붙이면 익숙한 광고가 한 편 더 생긴다. 영상에서 보여줄 장면과 증거를 먼저 고른 뒤, 그것을 가장 짧게 약속하는 문장으로 돌아온다. 순서는 **장면, 긴장, 약속, 증거**다. 위의 열 문장은 이 네 칸 가운데 하나를 빠르게 여는 손잡이로 쓸 수 있다. ## 문장보다 먼저 장면을 잡는다 “이런 적 한 번쯤 있죠?”, “이걸 진작 알았으면 좋았을 텐데”, “이거 다들 그냥 넘어가는 건데”는 모두 시청자의 기억을 건드린다. 문제는 ‘이런’, ‘이걸’, ‘이거’가 비어 있다는 데 있다. 후킹을 쓰기 전에 그 대명사를 영상으로 찍을 수 있는 장면으로 바꿔야 한다. 답답했다, 후회했다, 손해 봤다는 감정어만으로는 사람마다 다른 일을 떠올린다. 장면에는 손의 움직임과 화면의 위치, 반복한 행동이 있다. 파일을 다시 열었다. 결제 직전에 창을 닫았다. 같은 숫자를 세 번 확인했다. 댓글을 쓰다 지웠다. 이런 행동이 잡히면 “이런 적 있죠?”가 비로소 특정한 사람을 부른다. 질문형 제목을 다룬 두 현장 실험에서는 질문이 평서문보다 더 많은 독자를 끌었고, 독자가 자기 경험을 떠올리게 하는 단서가 붙었을 때 더 강했다. 효과는 주제에 따라 달랐다. 힘은 질문 부호보다 질문 안의 자기 기억 검색 단서에서 나왔다. 그래서 “이런 적 한 번쯤 있죠?”는 “\[구체적인 행동\]했다가 \[문제\]가 생겨서 \[이어진 행동\]까지 해본 적 있죠?”로 채운다. “이걸 진작 알았으면”에는 그때 하던 일과 줄일 수 있었던 우회를 넣는다. “다들 그냥 넘어간다”에는 화면 속 표시나 문서의 한 줄처럼 손가락으로 가리킬 위치를 넣는다. ## 장면 안에서 긴장을 찾는다 장면만 정확하다고 계속 보지는 않는다. 시청자가 알던 것과 지금 보게 될 것 사이에 차이가 있어야 한다. 열 문장에서는 손해, 지식 격차, 반전, 새로움이 그 차이를 만든다. “이거 모르면 진짜 손해예요”를 쓰려면 손해를 돈, 시간, 기회 중 하나로 바꿔야 한다. “이거 제대로 아는 사람 별로 없어요”에서는 ‘제대로’의 경계가 필요하다. 개념은 알지만 적용 조건을 모른다거나, 평소에는 맞지만 특정 상황에서는 틀린다는 식이다. “아마 처음 들어볼걸요?”에는 낯선 이름만 두지 않고, 그 이름을 알면 익숙한 문제에서 무엇이 새로 보이는지 붙인다. “다들 ○○인 줄 아는데 사실은 ○○이에요”는 긴장을 가장 선명하게 만든다. 첫 빈칸에는 사람들이 실제로 믿는 표면 원인을, 두 번째 빈칸에는 다음 장면에서 확인할 다른 원인을 넣는다. ‘사실은’ 뒤에 의견만 놓으면 반전이 아니라 말싸움이 된다. 온라인 뉴스 제목을 대상으로 한 3만 건 이상의 실험에서는 흔한 단어와 읽기 쉬운 문장으로 쓴 제목이 더 많이 선택됐다. 업워디 제목 실험 8,977건을 분석한 연구에서는 정보가 너무 모호한 구간에서 구체성을 더할 때 클릭이 늘었지만, 이미 충분히 구체적인 제목에 정보를 더하면 클릭이 줄었다. 후킹은 쉽게 읽혀야 하고, 자기 문제인지 알아볼 정보는 남겨야 한다. 모든 답을 첫 문장에 넣을 필요는 없다. 여기까지가 멈출 이유를 만드는 일이다. 이제 그 이유에 맞는 약속을 걸고, 다음 화면에서 값을 지급해야 한다. 약속의 크기는 내가 가진 증거보다 커질 수 없다. ## 약속은 증거의 크기에 맞춘다 “잘되는 사람들은 다 ○○하더라고요”, “딱 하나만 바꾸면 돼요”, “○○번 해보니까 결국 답은 하나예요”는 말하는 사람의 관찰과 경험을 담을 수 있다. 동시에 가장 쉽게 부풀릴 수 있는 문장들이다. “잘되는 사람들”은 시청자와 가까운 집단으로 좁힌다. 호텔 수건 재사용을 다룬 두 차례 현장 실험에서는 일반적인 환경 보호 호소보다 다른 투숙객의 실제 행동을 알려준 문구가 더 효과적이었다. 같은 방을 쓴 투숙객처럼 상황이 가까운 집단을 제시했을 때 효과가 가장 컸다. 사회적 증거의 힘은 지금 선택하는 사람과 가까운 행동에서 나온다. 따라서 “잘되는 사람들은 다” 뒤에는 막연한 성공 습관 대신 관찰한 표본과 공통 행동이 온다. 세 명을 봤다면 세 명이라고 말한다. 기록이 없다면 ‘다’라고 말하지 않는다. “딱 하나만 바꾸면 돼요”의 ‘하나’에는 나머지 조건을 그대로 두고 먼저 시험할 변수 하나를 넣는다. 다음 화면에서는 바꾸기 전과 후를 같은 조건으로 비교할 수 있어야 한다. “○○번 해보니까 결국 답은 하나예요”에서 숫자는 결론의 영수증이다. 무엇을 몇 번 했는지, 조건이 얼마나 달랐는지, 그 안에서 어떤 공통점이 남았는지 이어져야 한다. 횟수를 세지 않았다면 숫자를 만들지 않는다. 실제 기록이 있다면 열 문장 가운데 가장 강한 출발점이 될 수 있다. ## 후킹은 다음 화면까지 포함한다 첫마디가 손해를 말했다면 다음 화면에는 비용이 생기는 지점이나 계산 근거가 나와야 한다. 공통 행동을 말했다면 관찰한 사례가 나와야 한다. 질문을 던졌다면 그 장면을 재현하고, 통념을 뒤집었다면 두 원인을 비교해야 한다. 지나치는 지점을 말했다면 화면을 확대하고, 하나만 바꾼다고 했다면 전후를 같은 조건으로 보여준다. 첫마디만 세고 증거가 늦으면 시청자는 값을 먼저 내고 물건을 받지 못한다. 틱톡의 2023년 광고 가이드는 첫 6초를 핵심 구간으로 보고, 자체 분석에서 광고 회상 효과의 90%와 인지도 효과의 80%가 이 안에 잡혔다고 설명한다. 플랫폼이 후원한 광고 연구이므로 모든 숏폼에 통하는 법칙은 아니다. 다만 첫 문장과 첫 증거를 따로 설계해서는 안 된다는 실무 기준으로는 쓸 수 있다. 첫 6초를 세 덩어리로 보면 촬영이 쉬워진다. 첫 화면에서 대상과 행동을 보여주고, 그 위에 긴장과 약속을 담은 첫마디를 얹는다. 3초를 넘기기 전에 손해, 반전, 공통 행동, 전후 차이 가운데 하나를 꺼낸다. 자기소개와 배경 설명은 그다음이다. ## 문구는 마지막에 고른다 후킹을 새로 쓸 때는 증거에서 거꾸로 올라간다. 먼저 이 영상에서 실제로 보여줄 수 있는 것을 한 줄로 적는다. 그 증거가 누구의 어느 장면에 걸리는지 찾는다. 시청자가 알고 있던 것과 무엇이 다른지 정한다. 마지막에야 열 문장 가운데 맞는 뼈대를 고른다. 같은 장면도 가진 증거에 따라 문장이 달라진다. 실제 전후 비교가 있으면 “딱 하나만 바꾸면 돼요”가 맞을 수 있다. 여러 사례에서 반복된 행동을 확인했다면 “잘되는 사람들은 다”가 맞을 수 있다. 원인 두 개를 비교할 자료가 있다면 “다들 A인 줄 아는데 사실은 B”가 맞다. 증거가 문구를 고른다. 시험할 때는 영상 본문과 결말을 그대로 둔다. 질문형, 반전형, 실제 횟수형처럼 첫마디와 첫 증거만 바꾼다. 첫 화면에서 멈춘 사람, 3초 뒤 남은 사람, 끝까지 본 사람, 저장·공유한 사람, 마지막 행동까지 한 사람을 따로 본다. 멈춤은 늘었는데 3초 유지가 떨어졌다면 약속이 늦게 지급됐을 가능성이 있다. 완주율은 올랐는데 마지막 행동이 그대로라면 재미는 생겼지만 해결할 문제를 정확히 부르지 못했을 수 있다. 증거를 먼저 고르고, 장면으로 돌아가 긴장을 찾은 다음, 갚을 수 있는 만큼만 약속한다. 마지막에 열 문장 가운데 맞는 뼈대로 압축한다. 이 순서를 거치면 익숙한 첫마디도 남의 문구처럼 들리지 않는다. --- 주요 참고: Hillary C. Shulman 외, [Reading Dies in Complexity: Online News Consumers Prefer Simple Writing](https://doi.org/10.1126/sciadv.adn2555?ref=zerodraftlab.com); Marianne Aubin Le Quéré, J. Nathan Matias, [When Curiosity Gaps Backfire: Effects of Headline Concreteness on Information Selection Decisions](https://doi.org/10.1038/s41598-024-81575-9?ref=zerodraftlab.com); Linda Lai, Audun Farbrot, [What Makes You Click? The Effect of Question Headlines on Readership in Computer-Mediated Communication](https://doi.org/10.1080/15534510.2013.847859?ref=zerodraftlab.com); Noah J. Goldstein, Robert B. Cialdini, Vladas Griskevicius, [A Room with a Viewpoint: Using Social Norms to Motivate Environmental Conservation in Hotels](https://doi.org/10.1086/586910?ref=zerodraftlab.com); TikTok for Business, [Creative Codes](https://ads.tiktok.com/business/library/TikTok%5FCreativeCodes%5FMay2023.pdf?ref=zerodraftlab.com). 헤드라인과 사회규범 연구의 대상은 뉴스 독자와 호텔 투숙객이며, TikTok 자료는 플랫폼 광고 가이드입니다. 이를 한국어 숏폼의 장면·긴장·약속·증거 구조로 연결한 부분은 Zero Draft Lab의 실전 해석입니다. ### 유튜브 요약은 PRD가 아니다 URL: https://zerodraftlab.com/video-summary-to-prd/ Last updated: 2026-09-15T08:35:06.000Z 유튜브에서 제품 만드는 법을 설명하는 영상을 보고 AI에게 요약을 시키면 훌륭한 작업계획이 나온 것처럼 보인다. 기획의 중요성, PRD, 기능명세, 사용자 흐름, 와이어프레임, 구현 순서가 깔끔하게 정리된다. 영상 20분이 몇 개의 불릿으로 줄어든다. Google은 [Gemini Apps에서 YouTube 영상을 찾고 내용을 물어볼 수 있다](https://support.google.com/gemini/answer/16622858?ref=zerodraftlab.com)고 안내한다. YouTube 안의 대화형 AI도 시청 중인 영상에 질문하고 관련 내용을 더 찾게 돕는다. 동시에 [응답의 품질과 정확성이 달라질 수 있다](https://support.google.com/youtube/answer/14110396?ref=zerodraftlab.com)고 밝힌다. 영상 이해와 제품 결정은 다른 일이다. 요약은 화자가 무엇을 말했는지 압축한다. PRD는 우리 제품에서 무엇을 만들고, 무엇을 만들지 않으며, 어떤 결과로 성공을 판단할지 약속한다. 앞의 문서는 원문을 향하고, 뒤의 문서는 실행과 책임을 향한다. ## 요약은 빈칸을 드러내지 않는다 영상에서 “사용자 흐름을 먼저 그리라”고 말했다면 요약은 그 문장을 잘 보존할 수 있다. 그러나 우리 사용자가 누구인지, 첫 화면에서 어떤 행동을 해야 하는지, 인증이 필요한지, 실패하면 어디로 돌아가는지는 영상에 없다. AI가 자연스럽게 채우면 결정하지 않은 내용이 요구사항처럼 굳어진다. 좋은 요약은 화자의 주장, 사례, 순서를 보존한다. 좋은 PRD는 문제, 대상 사용자, 현재 행동, 제약, 제외 범위, 성공 조건, 확인 방법을 우리 맥락에서 정한다. 영상에서 얻은 프레임은 PRD의 질문을 만들 수 있지만 답까지 소유하지 않는다. 따라서 영상에서 PRD로 넘어갈 때는 중간 문서가 필요하다. “화자가 주장한 것”, “우리 상황에 적용할 가설”, “결정해야 할 것”, “검증할 증거”를 분리한다. 이 구분이 없으면 출처의 설명과 작성자의 추정과 프로젝트의 합의가 한 문장에 섞인다. AI가 요약을 잘할수록 이 경계는 더 중요해진다. 문장이 완성돼 보이면 빈칸이 있다는 사실을 놓치기 쉽다. PRD로 옮길 수 있는 것은 문장의 완성도가 아니라 결정의 계보다. 어떤 관찰에서 어떤 가설이 나왔고, 누가 무엇을 선택했으며, 그 선택이 틀렸는지 무엇으로 확인할지를 남겨야 한다. ## 주장, 결정, 검증을 한 칸씩 옮긴다 예를 들어 영상이 “AI와 대화해 PRD를 만든다”고 말한다면 먼저 주장으로 기록한다. 우리 프로젝트에서는 “사용자가 하고 싶은 일을 자유문으로 입력하면 기능 후보를 정리한다”는 가설로 바꿀 수 있다. 이후 입력 방식, 개인정보 처리, 응답 오류, 수정 권한을 사람이 결정한다. 마지막으로 대표 과제 몇 개를 넣어 요구사항 누락과 잘못된 기능 추가를 확인한다. 이 흐름에서 AI는 빈 문서를 채우는 작가보다 변환기와 비평가로 쓰는 편이 안전하다. 원문에서 주장과 사례를 뽑고, 가설의 모순을 찾고, 빠진 예외를 질문하고, 인수조건 초안을 제안한다. 사업 목표와 위험 허용치, 최종 제외 범위는 책임지는 사람이 정한다. 타임스탬프도 남겨야 한다. 요약의 한 문장이 영상 어느 지점에서 나왔는지 가리키면 다시 맥락을 볼 수 있다. AI가 만든 해석은 별도로 표시한다. 영상 전체를 보지 않은 사람이 요약을 원문처럼 인용하는 일을 줄인다. PRD의 분량은 중요하지 않다. 긴 문서도 결정이 없을 수 있고, 짧은 문서도 문제와 제외 범위와 검증이 선명할 수 있다. 핵심은 개발자나 Agent가 구현을 시작할 때 임의로 사업 판단을 만들지 않아도 되는가다. 영상 요약은 학습의 입구를 넓힌다. 긴 영상을 훑고 질문을 만들며 필요한 구간을 다시 찾게 한다. 그 편리함을 실행 계약으로 오해하면 속도는 빨라져도 책임은 흐려진다. 요약 다음에 한 번 더 편집해야 한다. 원문의 말을 우리 결정으로 옮기고, 그 결정이 틀렸을 때 되돌아갈 증거를 붙이는 편집이다. --- 참고: Google Gemini Apps Help, [Find and ask about YouTube content](https://support.google.com/gemini/answer/16622858?ref=zerodraftlab.com); YouTube Help, [Learn more about the conversational AI tool when watching videos](https://support.google.com/youtube/answer/14110396?ref=zerodraftlab.com). 영상→주장→가설→결정→검증 구조는 이 글의 편집적 해석입니다. ### PMax가 고쳐주지 못하는 것 URL: https://zerodraftlab.com/pmax-needs-conversion-signal/ Last updated: 2026-09-15T08:35:05.000Z 광고 성과가 답답할 때 Performance Max는 매력적으로 보인다. 검색, 디스플레이, 유튜브, 디스커버, Gmail, 지도까지 한 캠페인에서 운영하고 Google AI가 입찰과 예산과 소재 조합을 조정한다. 사람이 놓친 수요를 자동화가 찾아줄 것이라는 기대가 붙는다. [Google Ads의 설명](https://support.google.com/google-ads/answer/10724817?ref=zerodraftlab.com)대로 PMax는 광고주가 정한 전환 목표와 전환 가치, 예산, 크리에이티브, 고객 데이터를 입력으로 사용한다. 자동화는 목표를 발명하지 않는다. 어떤 행동을 전환으로 셀지, 어떤 고객이 더 가치 있는지 광고주가 먼저 정해야 한다. 이 차이를 놓치면 잘못된 목표를 더 효율적으로 달성할 수 있다. 상담 신청을 전환으로 잡았는데 실제 구매와 무관한 문의가 많이 들어오면 시스템은 그 문의를 더 찾는다. 클릭과 전화가 늘어도 매출과 기여이익이 나아지지 않을 수 있다. ## 자동화는 신호의 품질을 확대한다 Google도 [PMax FAQ](https://support.google.com/google-ads/answer/14587068?ref=zerodraftlab.com)에서 리드 수보다 품질을 중시하려면 실제 판매에 가까운 전환을 측정하고, CRM의 결과를 다시 광고에 전달하라고 권한다. 전환 데이터가 많을수록 AI가 원하는 결과를 더 빨리 찾을 수 있지만, 품질 신호와 충분한 양 사이의 균형이 필요하다고 설명한다. 여기서 문제는 광고 계정 밖에 있다. 상담팀이 어떤 문의가 적합했는지 기록하지 않거나, 예약과 방문과 결제가 서로 다른 시스템에 흩어져 있으면 좋은 신호를 돌려줄 수 없다. PMax 설정을 바꾸기 전에 고객이 광고를 보고 실제 매출까지 가는 경로를 연결해야 한다. 예산도 단순한 연료가 아니다. 데이터가 너무 적으면 소재와 대상과 지면의 조합을 비교하기 어렵다. 반대로 예산만 늘리면 잘못 정의한 전환을 더 많이 살 수 있다. “자동화니까 적은 예산으로도 알아서 학습한다”거나 “예산을 크게 넣으면 학습이 해결된다”는 두 기대 모두 신호 설계를 건너뛴다. PMax가 강한 곳은 여러 채널의 입찰을 같은 목표로 조정하는 일이다. 고객에게 무엇을 약속할지, 상담이 그 약속을 지켰는지, 환불과 취소를 포함한 최종 가치가 얼마인지는 광고주가 연결해야 한다. 그러므로 PMax 도입 전 질문은 “어떤 캠페인 구조가 좋은가”보다 “지금 시스템이 무엇을 성공으로 보고 있는가”다. 전환 이름, 값, 지연시간, 중복, 취소와 환불, 오프라인 결과를 먼저 본다. ## 광고 플랫폼과 매출 장부 사이를 닫는다 리드 사업에서는 문의가 접수된 순간과 돈이 들어온 순간 사이가 길다. 상담, 견적, 예약, 방문, 계약, 결제, 환불이 이어진다. 초반 행동만 광고에 보내면 시스템은 빠르고 쉬운 리드를 좋아한다. 뒤의 결과를 보내면 학습은 느려질 수 있지만 사업과 가까워진다. 각 단계의 값을 같게 두지 않아야 한다. 전화 버튼 클릭과 결제 완료를 모두 전환으로 세더라도 중요도와 전환 가치는 다르다. 중복 전환과 내부 테스트, 스팸 리드를 제거하고, 취소·환불이 생긴 결과를 어떻게 반영할지도 정한다. 초기에는 데이터가 적어 최종 구매만으로 학습하기 어려울 수 있다. Google도 고객 여정을 매핑하고 처음에는 마이크로 전환을 함께 보다가 데이터가 자라면 더 가치 높은 행동으로 옮기라고 안내한다. 이때 마이크로 전환은 영구 목표가 아니라 다음 단계로 가기 위한 임시 신호다. 크리에이티브도 같은 원칙을 따른다. 다양한 이미지와 문구를 많이 넣는 것만으로는 부족하다. 어떤 고객 문제와 약속을 시험하는지 태그를 붙이고, 광고 자산별 전환을 보되 캠페인 전체의 목표와 분리해서 과대해석하지 않는다. Google은 PMax가 채널 전체의 한계 ROI를 최적화하므로 개별 채널 평균만으로 판단하면 오해할 수 있다고 설명한다. 자동화가 투명하지 않다는 불만도 남는다. 모든 입찰과 조합을 사람이 해석할 수는 없다. 그렇기 때문에 통제할 수 있는 입력과 출력이 더 중요하다. 전환 정의, 가치, 예산 상한, 브랜드와 랜딩페이지 범위, CRM 결과, 실험 기간을 명시하고 바뀐 항목을 기록한다. PMax는 망가진 고객 여정을 고치는 도구가 아니다. 고객 여정에서 측정 가능한 신호를 받아 여러 채널의 입찰을 조정하는 도구다. 광고 이후의 상담과 결제와 환불이 장부에 연결될수록 자동화도 사업에 가까운 답을 낸다. --- 참고: Google Ads Help, [About Performance Max campaigns](https://support.google.com/google-ads/answer/10724817?ref=zerodraftlab.com), [Answering Your Top Questions About Performance Max](https://support.google.com/google-ads/answer/14587068?ref=zerodraftlab.com). Google이 공개한 평균 개선 수치는 해당 자료의 광고주 집단 결과이며 개별 계정의 성과를 보장하지 않습니다. ### 운세 앱은 첫 화면에서 무엇을 파는가 URL: https://zerodraftlab.com/identity-promise-drives-activation/ Last updated: 2026-09-15T08:35:05.000Z 운세 상담 앱의 첫 화면에는 기능보다 약속이 먼저 나온다. “당신은 잘될 운명” 같은 문장이 불안을 이름 붙이고, 타로·사주·신점이라는 세 가지 선택지가 뒤따른다. 첫 가입 쿠폰은 지금 바로 상담을 시작할 이유를 만든다. [소울톡의 App Store 페이지](https://apps.apple.com/kr/app/id6444065022?ref=zerodraftlab.com)는 첫 가입 상담권, 24시간 상담, 타로·사주·신점 상담사, 익명 상담을 한 화면에서 강조한다. 사용자가 사는 것은 운세 기능 하나가 아니다. 고민을 혼자 붙잡고 있는 시간을 끝내고 누군가에게 지금 물어볼 수 있다는 상태 변화다. 이 구조는 운세 앱에만 있지 않다. 정신건강, 교육, 피트니스, 재무, 법률 상담처럼 결과가 바로 보이지 않는 서비스는 기능을 설명하기 전에 사용자가 어떤 불안에서 어떤 상태로 이동하는지 보여줘야 한다. 기능 목록은 그 약속을 믿게 하는 증거가 된다. ## 첫 화면은 제품 설명보다 자기 설명에 가깝다 사용자는 앱이 무엇인지 읽으면서 동시에 “이게 지금 내 문제인가”를 판단한다. 연애, 결혼, 취업, 미래 같은 구체적인 고민을 나열하면 사용자는 자기 상황을 찾는다. 여러 상담 방식은 기능 다양성보다 자신에게 맞는 해석 방식을 고를 수 있다는 통제감을 준다. 쿠폰은 가격을 낮추는 장치이면서 첫 행동의 불확실성을 줄이는 장치다. 상담 품질을 알 수 없는 상태에서 큰 금액을 내기 어렵다. 즉시 쓸 수 있는 작은 크레딧은 설명을 더 읽는 대신 경험해 보게 한다. 다만 강한 약속은 강한 증거를 요구한다. “국내 1위”, 만족도, 상담 건수, 재상담률 같은 숫자는 기준과 기간과 집계 방식이 함께 있어야 해석할 수 있다. 사용자의 불안을 크게 자극한 뒤 쿠폰으로 결제를 재촉하면 활성화는 높아져도 신뢰 부채가 쌓일 수 있다. 첫 화면의 좋은 약속은 사용자의 약한 순간을 이용하지 않고, 서비스를 통해 실제로 할 수 있는 첫 행동을 선명하게 만든다. 그 약속을 검증하려면 다운로드 전환만 봐서는 부족하다. 어떤 문구와 선택지가 첫 상담을 만들었는지, 상담 후 환불과 재이용과 만족이 어떻게 달라졌는지 이어봐야 한다. ## 정체성 약속을 실험 가능한 단위로 만든다 Apple은 [Product Page Optimization](https://developer.apple.com/app-store/product-page-optimization/?ref=zerodraftlab.com)에서 앱 아이콘, 스크린샷, 미리보기 영상을 최대 세 가지 대안으로 시험하고 전환 차이를 보게 한다. 특정 캐릭터나 가치제안, 지역에 맞춘 콘텐츠가 더 반응을 얻는지 검증할 수 있다. 하지만 설치율만 높인 문구가 좋은 약속이라는 뜻은 아니다. “정확한 답을 준다”, “마음이 편해진다”, “즉시 전문가와 연결된다”는 약속은 서로 다른 사용자를 데려올 수 있다. 설치 후 첫 상담 시작률, 상담 완료, 추가 결제, 환불, 재상담, 불만 유형을 약속별로 연결해야 한다. 세 가지 선택지도 무조건 많을수록 좋지 않다. 사용자가 차이를 이해하지 못하면 타로·사주·신점은 선택권이 아니라 추가 고민이 된다. 각 방식이 어떤 질문에 맞고 어떤 답을 주지 못하는지 설명하면 선택이 쉬워진다. 상담사 목록을 보여주는 것보다 첫 질문을 고르게 하는 편이 나을 수도 있다. 쿠폰의 역할도 분리해 봐야 한다. 가격 장벽을 낮춘 것인지, 유효기간이 조급함을 만든 것인지, 무료 경험이 품질을 보여준 것인지가 다르다. 쿠폰 사용자는 많지만 유료 재상담이 적다면 활성화가 아니라 일회성 체험만 산 셈이다. 익명성 약속은 특히 운영이 따라야 한다. 앱 소개에 익명 상담을 적는 것과 실제로 어떤 정보가 상담사와 플랫폼에 보이고 얼마나 보관되는지는 별개의 문제다. 가장 강한 마케팅 문구일수록 제품과 개인정보처리방침과 고객지원이 같은 뜻을 써야 한다. 첫 화면에서 파는 것은 기능이 아니라 “이 고민을 지금 다룰 수 있다”는 허가다. 정체성 약속이 사용자를 움직이고, 선택지가 첫 행동을 좁히고, 쿠폰이 체험 비용을 낮춘다. 그다음 환불과 재이용까지 봐야 약속이 클릭을 만든 것인지 좋은 고객 경험을 만든 것인지 알 수 있다. --- 참고: [소울톡 App Store 제품 페이지](https://apps.apple.com/kr/app/id6444065022?ref=zerodraftlab.com), Apple Developer [Product Page Optimization](https://developer.apple.com/app-store/product-page-optimization/?ref=zerodraftlab.com). 앱 페이지의 평가 수, 문구와 프로모션은 변경될 수 있으며, 제품 페이지에 기재된 만족도·상담량·1위 주장을 이 글이 독립적으로 검증하거나 보증하지 않습니다. ### 책을 AI Skill로 바꾸면 지식이 되는가 URL: https://zerodraftlab.com/books-become-agent-skills/ Last updated: 2026-09-15T08:35:07.000Z 책 한 권을 AI에게 넣고 물어보면 지식을 곧바로 쓸 수 있을 것처럼 보인다. PDF를 첨부하고 “핵심을 요약해 줘”라고 하면 몇 초 만에 목차와 개념과 교훈이 나온다. 읽는 시간이 줄었다는 느낌도 든다. 하지만 요약은 책의 내용을 짧게 만든 결과다. Skill은 어떤 상황에서 어느 부분을 다시 읽고, 어떤 판단 규칙을 적용하며, 어디까지가 책의 주장인지 알려주는 작업 인터페이스다. 둘은 파일 크기가 아니라 사용 방식이 다르다. 공개 프로젝트 [book-to-skill](https://github.com/virgiliojr94/book-to-skill?ref=zerodraftlab.com)은 기술서나 문서 묶음을 프레임워크, 판단 규칙, 안티패턴, 장별 파일로 나눠 Agent Skill로 만드는 방식을 제안한다. 전체 책을 매번 컨텍스트에 넣는 대신 필요한 장을 그때 읽게 한다. 이 발상은 지식을 압축하기보다 호출 가능하게 만든다. ## 요약은 기억을 줄이고 Skill은 탐색 비용을 줄인다 긴 책의 한 문단을 찾기 위해 전체 PDF를 매번 읽히면 비용이 크다. 반대로 한 번 만든 요약만 읽히면 중요한 예외와 근거가 사라진다. 장별 인덱스와 주제 색인을 두면 Agent는 먼저 어디를 봐야 하는지 좁히고, 필요한 원문을 다시 읽을 수 있다. 이때 핵심은 “책 내용을 완전히 내재화했다”는 표현을 경계하는 것이다. Skill 파일은 책의 대체물이 아니다. 책의 구조를 보존한 지도이자 적용 규칙이다. 질문이 지도 밖으로 나가면 원문을 확인하거나 모른다고 말해야 한다. 특히 판단 규칙은 요약문과 달리 조건을 가져야 한다. “고객을 이해하라”는 교훈은 어디에나 맞지만 행동을 고르지 못한다. “신규 카테고리에서 고객이 문제를 아직 이름 붙이지 못했다면 기능 비교보다 문제 교육을 먼저 한다”처럼 상황과 선택이 연결돼야 작업에서 다시 쓸 수 있다. 책을 Skill로 바꾸는 일은 문장을 잘 줄이는 작업이 아니다. 원문에서 반복되는 프레임워크와 결정 기준, 실패 패턴을 찾아 호출 규칙으로 재배치하는 편집이다. 이 편집에는 손실이 생긴다. 저자의 논증이 잘게 분해되면서 서로 이어진 맥락이 끊길 수 있고, 편집자가 중요하다고 본 개념만 전면에 남을 수 있다. Skill은 검색 비용을 줄이는 대신 새로운 해석 권력을 만든다. ## 좋은 Skill은 출처와 반증 경로를 남긴다 판단 규칙마다 어느 장과 어떤 문단에서 왔는지 가리킬 수 있어야 한다. 저자의 문장, 편집자의 해석, 프로젝트에 맞춘 적용 규칙을 구분한다. 이 경계가 없으면 시간이 지날수록 책의 주장과 조직의 관행이 섞인다. 버전도 중요하다. 개정판에서 사례와 결론이 달라졌는데 Skill이 구판을 기준으로 남을 수 있다. 원본 파일의 제목, 저자, 판본, 생성일, 사용 범위를 기록하고, 업데이트 때 무엇이 바뀌었는지 비교해야 한다. 웹 문서처럼 계속 바뀌는 원천이라면 마지막 확인 시점과 최신성 경고가 필요하다. Skill이 작업을 자동으로 실행하게 한다면 지식과 권한도 나눠야 한다. 책의 프레임워크를 설명하는 파일에 배포나 결제 같은 쓰기 권한까지 줄 이유는 없다. 읽기용 지식과 실행용 절차를 분리하고, 외부 상태를 바꾸는 단계에는 별도의 확인 규칙을 둔다. 평가도 “그럴듯한 답을 했는가”로 끝나지 않는다. 책에 있는 질문에는 근거 장을 찾는지, 책에 없는 질문에는 범위를 벗어났다고 말하는지, 상충하는 구절을 하나로 뭉개지 않는지 본다. 같은 질문을 원문 검색과 Skill 경유로 풀어 정확도와 읽은 범위를 비교할 수 있다. 모든 책을 Skill로 만들 필요도 없다. 한 번 읽고 끝날 책, 서사의 흐름 자체가 가치인 책, 현재 작업과 연결되지 않는 책은 메모나 검색 가능한 원문이면 충분하다. 반복해서 판단에 쓰고, 특정 장을 자주 다시 찾고, 여러 사람이 같은 프레임을 적용할 때 변환 비용이 정당화된다. 책이 Skill이 되는 순간은 파일 생성이 끝났을 때가 아니다. 실제 질문에서 맞는 장을 다시 열고, 근거를 보여주고, 적용 범위를 지키며, 새 판본이 나오면 고칠 수 있을 때다. 지식은 압축률보다 출처로 돌아갈 수 있는 능력에서 오래간다. --- 참고: GitHub, [virgiliojr94/book-to-skill](https://github.com/virgiliojr94/book-to-skill?ref=zerodraftlab.com). 이 프로젝트가 제시한 생성 절차와 토큰 절감 수치는 해당 프로젝트의 설명이며, 모든 책·모델·질문에서 같은 결과를 보장하지 않습니다. 출처 계보, 버전, 권한, 평가에 관한 논지는 이 글의 편집적 해석입니다. ### 채용 플랫폼보다 채용담당자가 먼저다 URL: https://zerodraftlab.com/hiring-quality-belongs-to-manager/ Last updated: 2026-09-15T08:35:07.000Z 채용이 안 되면 먼저 플랫폼을 바꾼다. 더 유명한 채용사이트에 공고를 올리고, 유료 노출을 사고, 추천 채용과 헤드헌터를 붙인다. 지원자가 늘면 채용 문제가 풀릴 것처럼 보인다. 하지만 좋은 후보가 들어와도 직무가 모호하고 면접관마다 기준이 다르면 선택은 좋아지지 않는다. 한 사람은 경력을 보고, 다른 사람은 말투를 보고, 마지막 의사결정자는 “우리 팀과 잘 맞는 느낌”을 본다. 플랫폼은 후보를 데려올 수 있지만 평가 기준을 만들지는 못한다. 미국 인사관리처의 [구조화 면접 안내](https://www.opm.gov/policy-data-oversight/assessment-and-selection/structured-interviews?ref=zerodraftlab.com)는 모든 후보에게 같은 순서의 사전 질문을 하고, 같은 평정척도와 답변 기준으로 평가하라고 설명한다. 목적은 직무 관련 역량을 일관되게 확인하는 데 있다. 이 일은 채용 플랫폼보다 채용담당자와 hiring manager의 몫이다. ## 공고는 역할의 결과를 설명해야 한다 “열정적이고 커뮤니케이션이 뛰어난 인재”는 누구나 원한다. 어떤 일을 잘해야 하는지는 말해주지 않는다. 채용담당자는 입사 후 3개월과 1년에 만들어야 할 결과, 자주 마주칠 판단, 협업 상대, 실패 비용을 먼저 정의해야 한다. 이 정의가 있으면 경력 연차와 학벌을 넘어 실제 과거 행동을 물을 수 있다. 비슷한 문제를 어떻게 풀었는지, 어떤 제약에서 무엇을 포기했는지, 결과를 어떤 자료로 확인했는지 묻는다. 답변을 비교할 기준도 생긴다. 반대로 역할이 모호하면 면접은 호감도 테스트가 된다. 추천 채용은 신뢰할 만한 소개라는 이유로 기준을 건너뛰고, 유명 플랫폼의 많은 지원자는 검토 부담만 늘릴 수 있다. 채널의 문제가 평가의 문제를 가린다. 채용 품질은 입사 승인 순간에 확정되지 않는다. 기대한 일을 실제로 수행했는지, 온보딩과 자원 제공이 충분했는지, 조직이 약속한 역할과 실제 역할이 같았는지 입사 후에 확인해야 한다. 이 피드백이 다음 직무 정의와 면접 기준으로 돌아와야 한다. 그래서 채용담당자의 성과를 지원자 수와 채용 소요일만으로 보면 행동이 왜곡된다. 많은 지원자를 빨리 처리하는 능력과 좋은 사람을 알아보고 입사 후 성공시키는 능력은 같지 않다. ## 채용 퍼널 뒤에 품질 장부를 붙인다 첫 단계는 후보가 아니라 직무를 구조화하는 것이다. 해야 할 일을 과제 단위로 나누고, 각 과제에 필요한 역량과 관찰 가능한 행동을 적는다. 면접 질문은 이 행동을 드러내도록 만들고, 평정 기준에는 좋은 답과 부족한 답의 차이를 둔다. 면접관 교육도 필요하다. 같은 질문을 읽는다고 같은 면접이 되지 않는다. 후속 질문의 범위, 기록 방식, 이해상충, 차별 위험, 독립 평가 후 합의 순서를 정해야 한다. 면접 직후 느낌을 먼저 공유하면 뒤의 평가자가 앞사람의 확신에 끌릴 수 있다. 입사 후에는 면접 점수와 실제 결과를 연결한다. 수습 통과 여부 하나로 끝내지 않고 역할별 핵심 결과, 온보딩 속도, 팀과 후보 양쪽의 기대 불일치, 퇴사 사유를 본다. 면접에서 높게 평가한 역량이 실제 성과와 무관했다면 질문이나 평정 기준을 고친다. 이 장부는 hiring manager도 평가한다. 후보가 부족했다고만 말하기 전에 공고 승인과 면접 일정이 늦지 않았는지, 좋은 후보에게 역할을 충분히 설명했는지, 결정이 기준에 따라 이뤄졌는지 본다. 채용을 인사팀에 발주하는 관리자는 좋은 후보를 잃고도 플랫폼 탓을 할 수 있다. 추천은 여전히 강한 채널이고, 좋은 플랫폼은 탐색 비용을 줄인다. 다만 채널은 직무 정의와 구조화된 평가 위에 올라가야 한다. 추천받은 사람도 같은 핵심 역량을 확인하고, 공개 지원자도 실제 과제로 실력을 보여줄 수 있어야 한다. 채용 플랫폼을 고르는 일은 필요하다. 그보다 먼저 누가 좋은 채용인지 정의하고, 누가 그 판단에 책임지며, 입사 후 어떤 증거로 되돌아볼지를 정해야 한다. 플랫폼은 사람을 데려온다. 채용 품질은 조직이 그 사람을 어떻게 보고 선택하고 일하게 했는지에서 결정된다. --- 참고: U.S. Office of Personnel Management, [Structured Interviews](https://www.opm.gov/policy-data-oversight/assessment-and-selection/structured-interviews?ref=zerodraftlab.com). 구조화 면접의 원칙을 민간기업에 적용하는 방식과 hiring manager의 품질 장부는 이 글의 편집적 해석입니다. 실제 채용은 해당 국가의 노동·차별·개인정보 관련 법규를 함께 검토해야 합니다. ### 개인정보처리방침은 코드에서 시작한다 URL: https://zerodraftlab.com/privacy-policy-starts-with-code/ Last updated: 2026-09-15T08:35:09.000Z 개인정보처리방침을 만들어 달라고 하면 대개 문서부터 연다. 다른 서비스의 방침을 참고하고, 회사명과 이메일을 바꾸고, 우리 서비스에 맞아 보이는 항목을 덧붙인다. 문장은 그럴듯해진다. 정작 서비스가 어떤 정보를 모으는지는 여전히 모른다. 이 문제는 드물지 않다. 개인정보보호위원회가 2025년 50개 서비스를 평가한 결과, 실제 서비스 이용 과정에서 고지되는 처리 목적·항목·보유기간과 처리방침의 일치율은 53%였다. 전년의 28%보다는 나아졌지만, 절반 가까운 내용이 실제 서비스와 맞지 않았다는 뜻이다. [개인정보위 평가 결과](https://www.pipc.go.kr/np/cop/bbs/selectBoardArticle.do?bbsId=BS074&mCode=&nttId=11746&ref=zerodraftlab.com) 처리방침은 약속문이다. 코드와 운영이 실제로 하는 일을 글로 공개한다. 그래서 방침보다 먼저 읽어야 할 것은 회원가입 화면, 데이터베이스 스키마, 로그 수집 설정, 결제 모듈, 분석 도구, 고객문의 채널이다. 문서가 코드보다 앞서면 약속과 현실이 어긋난다. ## 법률의 목차는 시스템 조사표다 [개인정보 보호법 제30조](https://law.go.kr/lsLinkCommonInfo.do?chrClsCd=010202&lsJoLnkSeq=1020398435&ref=zerodraftlab.com)는 처리 목적, 보유기간, 제3자 제공, 파기, 처리위탁, 정보주체의 권리, 자동수집 장치 등을 처리방침에 담도록 한다. [시행령 제31조](https://www.law.go.kr/LSW/lsLawLinkInfo.do?chrClsCd=010202&lsJoLnkSeq=900079801&ref=zerodraftlab.com)는 처리 항목, 국외 이전의 근거와 세부 내용, 안전성 확보조치까지 요구한다. 이 목록은 문서 목차이기 전에 조사 질문이다. 어느 화면과 API에서 무엇을 받는가. 어떤 데이터베이스·로그·파일 저장소에 남는가. 누가 접근할 수 있는가. 외부 사업자에게 어떤 값이 전달되는가. 어느 국가에서 처리되는가. 무엇을 기준으로 언제 삭제되는가. 그러므로 첫 산출물은 처리방침 초안이 아니라 개인정보 처리대장이어야 한다. 기능, 정보주체, 수집 지점, 처리 항목, 목적과 법적 근거, 저장소, 접근자, 수탁자·재수탁자, 이전 국가, 보유기간, 파기 방법, 마지막 검증일을 한 줄로 연결한다. ## 코드만 읽어서도 부족하다 제목은 “코드에서 시작한다”지만 코드만 읽어서는 처리방침을 만들 수 없다. 회원가입 폼과 데이터베이스 스키마뿐 아니라 인증 사업자, 결제대행사, 분석 SDK, 오류 추적기, 고객문의 메일, CRM, 운영자가 내려받은 CSV, 협업 도구, 백업과 관리자 화면까지 봐야 한다. 개인정보는 애플리케이션 코드 밖에서도 복제되고 전달된다. 확인은 네 방향으로 하면 된다. 어디서 들어오는가. 어디에 남는가. 누구에게 넘어가는가. 어떻게 없어지는가. 이 네 질문에 답하지 못한 칸이 처리방침의 빈칸이 된다. 여기서부터 개인정보 작업은 법률 문구를 고르는 일이 아니라 시스템의 모순을 고치는 일이 된다. 목적이 없는 로그는 줄이고, 사용하지 않는 입력 항목은 없애고, 삭제할 수 없는 저장소에는 삭제 경로를 만들어야 한다. [개인정보 보호법 제21조](https://www.law.go.kr/LSW/lsLawLinkInfo.do?chrClsCd=010202&lsJoLnkSeq=900078981&ref=zerodraftlab.com)는 개인정보가 불필요해지면 지체 없이 파기하고 복구·재생되지 않도록 조치하도록 정한다. “탈퇴 시 삭제합니다”라는 문구만 있고 실제 삭제 경로가 없다면 문장보다 시스템을 먼저 고쳐야 한다. ## 처리방침은 출시 절차에 들어가야 한다 서비스는 계속 바뀐다. 소셜 로그인을 붙이고, 결제사를 바꾸고, 상담 챗봇을 추가하고, 로그 필드를 늘리고, 분석 SDK를 교체한다. 기능 변경이 곧 데이터 흐름 변경일 수 있다. [2026년 개인정보위 작성지침](https://www.pipc.go.kr/np/cop/bbs/selectBoardArticle.do?bbsId=BS217&mCode=D010030020&nttId=12018&ref=zerodraftlab.com)은 처리방침과 실제 처리 현황을 일치시키고 정확성·투명성·최신성을 유지하라고 안내한다. 신규 서비스를 도입하거나 기존 서비스를 변경할 때 개인정보 보호책임자에게 사전 통보하는 내부 절차도 권고한다. 실무에서는 기능 출시 전에 다섯 가지를 확인하면 된다. - 새로 받거나 생성하는 개인정보가 있는가. - 새 저장소·수탁자·재수탁자·처리 국가가 생겼는가. - 목적과 보유기간이 달라졌는가. - 열람·정정·삭제 요청을 실제로 처리할 수 있는가. - 처리대장과 처리방침에서 바뀌어야 할 줄은 어디인가. 2025년 평가에서도 서비스 도입·변경 시 개인정보 처리 승인 절차를 둔 기업이 처리방침과 실제 처리의 정합성을 높인 사례로 소개됐다. 문서를 출시 후에 고치는 대신 데이터 흐름 변경을 출시 조건으로 다룬 것이다. 처리방침 자체도 제품 화면이다. 2026 지침은 로그인하지 않아도 확인할 수 있어야 하며, 모바일 앱에서는 첫 화면에서 세 단계 이상 거치지 않는 경로를 권고한다. 이전 버전과 적용기간을 보존하고, 중요한 변경은 전후 비교표로 알려야 한다. ## AI에서는 프롬프트도 데이터 흐름이다 AI 기능을 붙이면 조사 범위가 넓어진다. 사용자가 입력한 문장뿐 아니라 문서·이미지·음성·첨부파일, 생성된 결과물, 이용기록까지 처리 대상이 될 수 있다. 프롬프트와 첨부파일을 저장하는지, 답변 생성 뒤 파기하는지, 서비스 제공과 품질 개선의 보유기간이 다른지 확인해야 한다. 입력을 자체 모델이나 외부 사업자의 모델 학습에 쓰는지, 외부 AI API로 어떤 값이 전송되는지, 사용자가 학습 활용을 거부하거나 대화를 삭제할 수 있는지도 따로 봐야 한다. [개인정보위의 생성형 AI 개인정보 처리 안내서](https://m.pipc.go.kr/np/cop/bbs/selectBoardArticle.do?bbsId=BS217&mCode=G010030000&nttId=11439&ref=zerodraftlab.com)는 목적 설정부터 학습·개발, 배포, 정보주체 권리 보장까지 수명주기 전체를 확인하도록 한다. 2026 처리방침 작성지침에는 AI 입력·결과물, 외부 모델 위탁, 국외 이전, 학습 활용 여부를 다루는 별도 부록도 신설됐다. 외부 AI 사업자가 자사 서비스의 답변 생성을 대신한다면 처리위탁에 가까울 수 있다. 외부 제휴사가 자기 서비스 제공을 위해 정보를 저장·이용한다면 제3자 제공에 가까울 수 있다. 이름만 보고 판단할 수 없고, 데이터가 어디로 가서 누구의 목적으로 쓰이는지를 확인해야 한다. [개인정보 보호법 제26조](https://www.law.go.kr/lsLinkCommonInfo.do?lsJoLnkSeq=1029331867&ref=zerodraftlab.com)는 위탁업무와 수탁자·재수탁자의 공개와 감독을 요구한다. 해외 AI나 클라우드로 개인정보를 보내는 경우에는 수탁사 이름만 적어서도 부족하다. 이전 국가, 시기와 방법, 이전받는 자, 목적, 보유기간, 거부 방법과 효과까지 실제 계약과 설정을 확인해야 한다. [개인정보 보호법 제28조의8](https://www.law.go.kr/lsLinkCommonInfo.do?chrClsCd=010202&lsJoLnkSeq=1029334953&ref=zerodraftlab.com) ## 처리방침은 데이터 흐름의 배포본이다 영국 개인정보 감독기관 ICO도 개인정보 안내문을 쓰기 전에 정보감사와 데이터 매핑으로 무엇을 보유하고 어디에서 왔으며 누구와 공유하고 얼마나 보관하는지 먼저 확인하라고 안내한다. [ICO 데이터 매핑 지침](https://ico.org.uk/for-organisations/advice-and-services/audits/data-protection-audit-framework/toolkits/records-management/data-mapping-and-recording/?ref=zerodraftlab.com) 처리방침을 독립된 문서로 보면 출시 때 한 번 쓰고 잊는다. 개인정보 처리대장의 공개용 배포본으로 보면 기능·수탁자·저장소가 바뀔 때 함께 바뀐다. 문서에서 답하지 못한 칸은 문장 문제가 아니라 시스템의 미확인 영역이다. --- 이 글은 제품·개발·운영 관점의 일반적인 해설이며 법률 자문이 아닙니다. 구체적인 적법 근거, 민감정보, 아동 정보, 처리위탁·제3자 제공 및 국외 이전 판단은 현재 서비스 구조와 계약을 기준으로 별도 검토해야 합니다. 법령과 안내서는 2026년 8월 8일 확인했습니다. ### 비포애프터를 촬영으로 끝내면 안 된다 URL: https://zerodraftlab.com/before-after-evidence-pipeline/ Last updated: 2026-09-15T08:35:09.000Z 병원에서 비포애프터를 만들 때 대화는 촬영 일정부터 시작하기 쉽다. 언제 환자를 찍을지, 어떤 각도가 잘 나오는지, 짧은 영상으로 만들지, 대기실 화면과 SNS에 어떻게 쓸지를 정한다. 결과물이 콘텐츠라면 자연스러운 순서다. 하지만 비포애프터는 두 장의 사진이 아니라 하나의 주장이다. 전과 후가 같은 조건에서 비교됐고, 변화가 해당 치료와 관련 있으며, 이 사례를 다른 환자에게 보여줘도 된다는 주장을 한꺼번에 담는다. 촬영 기술보다 증거의 계보가 먼저다. [의료법 제56조](https://www.law.go.kr/LSW/lsLawLinkInfo.do?chrClsCd=010202&lsId=001788&lsJoLnkSeq=900350305&print=print&ref=zerodraftlab.com)는 환자의 치료경험담 등 소비자가 치료 효과를 오인할 우려가 있는 의료광고와 거짓·과장 광고를 금지한다. 환자가 동의했으니 게시해도 된다는 판단과, 그 게시물이 치료 효과를 오인하게 만들지 않는다는 판단은 별개다. ## 좋은 촬영보다 같은 조건이 먼저다 조명, 거리, 표정, 자세, 화장, 렌즈와 보정이 달라지면 같은 사람도 크게 달라 보인다. 전후 사진이 증거로 작동하려면 이 조건을 최대한 맞추고, 촬영 시점과 치료 횟수, 함께 진행한 다른 조치를 기록해야 한다. 결과가 좋게 보이도록 고르는 편집과 실제 변화를 보여주는 기록은 다르다. 변화 측정도 화면의 인상만으로 끝나지 않는다. 치료 목적에 맞는 지표가 있다면 사진과 함께 남긴다. 의료진이 판단한 개선과 환자가 느낀 만족도도 구분한다. 두 값이 다를 수 있기 때문이다. 사진은 설명을 돕는 한 종류의 자료이지 모든 결과를 대신하지 않는다. 동의는 마지막 서명 한 번으로 끝나지 않는다. 진료를 위해 찍는 사진과 교육, 대기실, 홈페이지, SNS 광고에 쓰는 사진은 목적과 공개 범위가 다르다. 환자가 어디에 얼마나 오래 공개되는지 이해해야 하고, 철회가 들어왔을 때 어떤 채널에서 내려야 하는지도 정해야 한다. 이 조건을 촬영 전에 합의하면 비포애프터는 콘텐츠팀의 자산이 아니라 진료와 증거와 공개를 잇는 기록이 된다. 촬영이 끝난 뒤 동의와 설명을 맞추려 하면 가장 중요한 사실이 이미 빠져 있다. 증거의 계보는 사진 한 장에 파일명을 붙이는 것보다 길다. 누구의 어떤 치료를 언제 어떤 조건에서 기록했고, 누가 결과 표현을 검토했으며, 어느 공개면에 어떤 기간 동안 사용하도록 동의했는지가 함께 이어져야 한다. ## 진료기록과 마케팅 자산을 한 폴더에 섞지 않는다 원본 사진은 진료 맥락을 가진 민감한 정보일 수 있다. 마케팅팀이 쓰는 편집본과 같은 접근권한으로 두면 필요 이상의 사람이 원본을 보게 된다. 반대로 편집본만 남기면 촬영 조건과 동의 범위를 확인하기 어렵다. 원본, 검토본, 공개본을 구분하고 각각의 접근자와 보유 기간을 정해야 한다. 공개본에는 필요한 정보만 남긴다. 얼굴 전체가 필요하지 않다면 범위를 줄이고, 파일 메타데이터와 내부 식별자도 확인한다. 동의서에는 “마케팅 활용” 같은 넓은 문구만 쓰기보다 홈페이지, SNS, 대기실, 광고 집행처럼 실제 채널을 설명한다. 철회와 만료가 생기면 공개면 목록을 따라 회수한다. 콘텐츠 제작 속도와 의료광고 검토 속도도 분리해야 한다. 짧은 영상 하나를 만들 때마다 모든 판단을 처음부터 반복하면 검토는 형식이 된다. 허용할 표현, 피해야 할 비교, 필요한 고지, 의료진 검토 지점을 유형별로 정하되 개별 사례의 사실관계는 다시 확인한다. 좋은 결과만 고르는 선택 편향도 숨길 수 없다. 특정 환자의 변화는 그 환자의 변화다. 평균 효과나 일반적인 결과처럼 확대해서 말하지 않는다. 전후 사진이 선명할수록 독자는 인과를 강하게 읽기 때문에 설명은 더 조심해야 한다. 대기실 화면과 SNS도 같은 공개가 아니다. 대기실은 제한된 공간이지만 환자와 동반자가 반복해서 본다. SNS 광고는 저장과 공유, 재배포가 쉽고 국경을 넘을 수 있다. 한 채널의 동의를 다른 채널로 자동 확장하지 않아야 한다. 비포애프터를 많이 만드는 병원은 콘텐츠 공장보다 증거 관리 조직에 가깝다. 동일 조건 촬영, 치료 맥락, 결과 검토, 목적별 동의, 공개 채널, 철회와 회수 기록이 한 줄로 이어져야 한다. 이 계보가 없으면 잘 찍힌 전후 사진은 설득력이 아니라 오해의 속도만 높일 수 있다. --- 참고: [의료법 제56조](https://www.law.go.kr/LSW/lsLawLinkInfo.do?chrClsCd=010202&lsId=001788&lsJoLnkSeq=900350305&print=print&ref=zerodraftlab.com), [개인정보 보호법 제30조](https://law.go.kr/lsLinkCommonInfo.do?chrClsCd=010202&lsJoLnkSeq=1020398435&ref=zerodraftlab.com). 이 글은 의료광고 또는 개인정보 법률 자문이 아닙니다. 구체적인 촬영·동의·게시 판단은 현재 법령, 심의 대상 매체, 진료기록의 성격과 개별 동의 범위에 맞춰 검토해야 합니다. ### 광고세트는 왜 팔렸는지 말해주지 않는다 URL: https://zerodraftlab.com/ads-need-message-units/ Last updated: 2026-09-15T08:35:08.000Z 광고 보고서는 대개 캠페인, 광고세트, 광고 순서로 정리된다. 비용이 많이 든 광고세트를 끄고, 전환이 나온 광고세트에 예산을 더한다. 숫자는 정돈되지만 한 가지 질문에는 답하지 못한다. 고객은 대체 무엇 때문에 움직였을까. 광고 관리자 탓으로 돌리기 어려운 문제다. [Meta가 설명하는 광고 계층](https://www.facebook.com/help/messenger-app/621956575422138/)에서 캠페인은 목표를, 광고세트는 타깃·노출 위치·예산·일정을, 광고는 이미지·영상·텍스트·링크를 담는다. 이 계층은 광고를 만들고 배송하기 위한 구조다. 고객이 어떤 약속에 반응했는지는 별도로 분류해야 한다. 같은 할인, 같은 불안, 같은 사용 장면을 말하는 소재를 여러 광고세트에 나눠 넣으면 계정에는 실험이 많아 보인다. 실제로는 하나의 메시지를 반복한 것일 수 있다. 반대로 같은 광고세트 안에 가격, 시간 절약, 실패 위험, 편의, 체면이라는 다른 이유가 섞이면 결과가 좋아도 어느 약속이 반응을 만들었는지 분리하기 어렵다. [Meta Blueprint의 크리에이티브 다양화 과정](https://www.facebookblueprint.com/student/path/253130-increase-campaign-performance-with-diversified-creative?ref=zerodraftlab.com)도 광고를 콘셉트와 동기, 형식으로 나누어 다룬다. 학술 연구에서도 비슷한 구분이 보인다. Dall’Olio와 Vakratsas는 [광고 크리에이티브 전략 연구](https://doi.org/10.1177/00222429221074960?ref=zerodraftlab.com)에서 내용의 기능과 표현 형식을 분리했다. 실증 자료가 TV 광고와 소비재에 한정된 연구이므로 Meta 광고의 성과를 직접 설명하지는 못한다. 여기서 가져올 것은 같은 메시지를 다른 형식으로 만든 경우와 애초에 다른 메시지를 만든 경우를 나누는 관점이다. ## 광고세트는 배송 상자다 광고세트별 매출을 본다고 상자 안의 어떤 제안이 팔렸는지 알 수 있는 것은 아니다. 배송 조건과 구매 이유를 같은 칸에 넣었기 때문이다. 타깃과 예산은 게재 조건이고, “돈을 아낀다”와 “실패를 피한다”는 고객에게 건 약속이다. 그래서 광고와 광고세트 사이에 별도의 학습 단위가 필요하다. 여기서는 그것을 **메시지 단위**라고 부르겠다. Meta의 기능명이나 광고업계의 표준 용어가 아니라, 광고주가 자기 실험을 읽기 위해 만드는 운영 단위다. 이 글에서는 네 가지를 기록한다. 어떤 상황의 고객에게, 무엇이 달라진다고 약속하고, 고객이 치르던 어떤 비용이나 불안을 줄이며, 그 약속을 무엇으로 믿게 하는가. 이미지·영상·카피 길이·출연자·지면은 그 메시지를 표현하는 형식으로 따로 기록한다. 가상의 예약 서비스를 생각해 보자. 이 서비스가 빠른 예약, 당일 변경, 가격 비교 기능을 실제로 제공한다고 가정한다. “전화 없이 바로 예약한다”는 시간 메시지, “일정이 바뀌어도 고칠 수 있다”는 위험 메시지, “결제 전에 가격을 비교한다”는 비용 메시지가 나온다. 세 메시지를 정지 이미지와 짧은 영상으로 각각 만들면 광고는 여섯 개지만 메시지 단위는 세 개다. 영상의 자막과 배경색만 바꾼 다섯 편은 다섯 개의 새 메시지가 아니다. 이렇게 분류하면 보고서 문장이 달라진다. “광고세트 B의 CPA가 낮았다”에서 멈추지 않고 “시간 메시지를 담은 두 형식에서 구매까지 같은 방향이 반복됐고, 비용 메시지는 클릭 이후 이탈이 컸다”라고 읽을 수 있다. 후자는 다음 소재뿐 아니라 랜딩페이지에서 먼저 설명할 약속도 바꾼다. 다만 분류표를 만들었다고 고객의 머릿속을 읽은 것은 아니다. 메시지 단위는 왜 팔렸는지를 확정하는 답이 아니라, 서로 다른 가설이 한 보고서에 섞이지 않게 하는 장치다. 분류 뒤에 남는 더 어려운 문제는 성과를 어떻게 읽느냐이다. 광고 플랫폼은 모든 사람에게 광고를 무작위로 보여주지 않는다. 구매할 가능성이 높은 사람에게 특정 광고가 더 많이 노출되면, 좋은 고객을 찾아낸 성과와 광고가 고객을 움직인 효과가 한 숫자에 섞인다. ## 관찰된 승자와 원인을 분리한다 Gordon, Zettelmeyer, Bhargava, Chapsky는 [Facebook의 대규모 광고 실험 15건](https://www.kellogg.northwestern.edu/faculty/gordon%5Fb/files/fb%5Fcomparison.pdf?ref=zerodraftlab.com)을 이용해 무작위 실험과 관찰 기반 추정을 비교했다. 약 5억 개의 사용자-실험 관측치와 16억 회의 노출을 분석했지만, 관찰 방법은 인구통계와 행동 변수를 폭넓게 통제한 뒤에도 무작위 실험의 효과를 자주 복원하지 못했다. 광고세트와 소재별 CPA는 예산을 운영하는 데 유용하다. 그러나 그 숫자만으로 “이 메시지가 구매를 만들었다”라고 말할 수는 없다. 소구점 태그는 관찰된 패턴을 정리하고 다음 비교 대상을 정한다. 인과를 확인해야 할 때는 타깃·기간·게재 조건을 맞춘 A/B 테스트나 리프트 실험이 필요하다. 무작위 실험도 고객의 내면을 그대로 설명하지는 않는다. 특정 메시지를 본 집단의 행동이 대조군과 달라졌다는 사실을 보여줄 뿐이다. 고객이 왜 그 약속을 믿었는지, 어떤 표현에서 불신했는지는 인터뷰·설문·상담 기록 같은 다른 증거로 보완해야 한다. 행동 실험과 고객 언어를 합쳐야 “무슨 메시지가 움직였는가”와 “왜 그렇게 받아들였는가”를 나눠 볼 수 있다. ## 클릭에서 멈추면 다른 고객을 고른다 메시지 단위의 성과를 클릭 하나로 판정하면 강한 자극을 잘 만드는 광고가 이긴다. 하지만 방문을 늘린 메시지와 구매를 늘린 메시지는 같지 않을 수 있다. Johnson, Lewis, Nubbemeyer가 [Google Display Network의 현장 실험 432건](https://marketing.wharton.upenn.edu/wp-content/uploads/2017/08/Johnson-Garrett-PAPER-VERSION-2.pdf?ref=zerodraftlab.com)을 분석했을 때도 광고는 방문과 전환을 모두 늘렸지만, 방문 증가가 전환 증가로 같은 비율로 이어지지 않았다. 이 연구에서 방문자 10% 증가는 전환자 약 5\~7% 증가로 이어졌다. 따라서 메시지는 최소한 노출, 방문, 핵심 행동, 구매를 같은 이름으로 이어봐야 한다. 사업에 따라 취소·환불·구독 유지·재구매·오프라인 결제도 필요하다. [Meta의 Conversions API 안내](https://www.facebook.com/business/help/AboutConversionsAPI)도 웹과 앱 전환뿐 아니라 오프라인 이벤트, 구독 같은 구매 후 행동, 고객 점수를 다룰 수 있다고 설명한다. 구매 후 데이터를 연결할 때는 개인정보와 약관 경계를 먼저 지켜야 한다. 핵심은 외부 전송량을 늘리는 것이 아니라 내부 보고에서 어떤 메시지가 어떤 후속 결과와 연결됐는지 추적하는 데 있다. 예를 들어 비용 메시지가 클릭과 첫 구매는 많이 만들었지만 환불도 함께 높았다면 “이긴 광고”라는 판정은 성급하다. 시간 메시지는 첫 구매 CPA가 조금 높아도 구독 유지나 재구매가 나을 수 있다. 어느 지표가 중요한지는 사업 모델이 정한다. 광고 플랫폼의 기본 열이 정해 주지 않는다. ## 분류법에는 정답표가 없다 가격·시간·위험·편의·체면은 시작하기 쉬운 태그일 뿐 보편적인 다섯 범주가 아니다. Ronald Taylor의 [여섯 가지 메시지 전략 모델](https://doi.org/10.1080/00218499.1999.12466442?ref=zerodraftlab.com)은 이성·긴급 필요·습관과 자아·사회·감각이라는 다른 구분을 제안한다. 다른 연구는 인지·감정·경험을 쓰기도 한다. 실무 분류의 목적은 한 팀이 같은 광고를 같은 기준으로 읽고, 기준이 바뀌면 과거 데이터도 다시 분류할 수 있게 만드는 데 있다. 실무에서는 메시지 단위에 고정된 식별자를 붙이고 표현 형식을 별도 열로 둔다. 새 이미지가 같은 고객 상황과 약속을 반복하면 기존 메시지 ID에 묶는다. 약속이나 고객의 희생이 달라지면 새 메시지 ID를 만든다. 하나의 광고가 여러 약속을 담으면 주 메시지 하나와 보조 메시지를 구분하거나, 처음부터 실험용 소재를 다시 만든다. 무엇을 시험하는지 말할 수 없는 광고는 결과가 나와도 학습을 남기기 어렵다. 그다음 보고서는 세 문장으로 닫을 수 있다. 어떤 메시지가 어느 형식과 고객군에서 관찰됐는가. 그 패턴은 구매 이후까지 이어졌는가. 다음 실험에서 무엇을 고정하고 무엇을 바꿀 것인가. 광고세트는 광고를 배송한다. 메시지 단위는 다음 판단을 남긴다. --- 출처와 경계: Meta 광고 계층 및 크리에이티브 다양화 공식 문서, Dall’Olio·Vakratsas의 내용-표현 구분 연구, Gordon 외 연구진의 Facebook 무작위 실험 비교, Johnson 외 연구진의 432개 디스플레이 광고 실험, Meta Conversions API 안내, Taylor의 메시지 전략 모델을 검토했습니다. “메시지 단위”와 네 가지 기록 항목은 이 자료들을 바탕으로 구성한 이 글의 운영 프레임이며 Meta의 공식 기능이나 보편적 분류법이 아닙니다. ### OpenClaw와 Hermes는 메모리를 어떻게 관리하는가 URL: https://zerodraftlab.com/openclaw-hermes-memory-management/ Last updated: 2026-08-08T10:11:12.000Z 에이전트가 사용자를 기억한다고 말할 때 그 안에는 서로 다른 일이 섞여 있다. 지난 대화를 줄여 현재 세션을 이어가는 일, 오래된 기록에서 필요한 내용을 찾는 일, 반복해서 중요한 사실을 다음 세션의 기본 지식으로 올리는 일은 같은 기능이 아니다. [OpenClaw의 메모리 공식 문서](https://docs.openclaw.ai/concepts/memory?ref=zerodraftlab.com)와 [Hermes의 Persistent Memory 문서](https://hermes-agent.nousresearch.com/docs/user-guide/features/memory/?ref=zerodraftlab.com)를 나란히 읽으면 차이가 선명해진다. OpenClaw는 기록을 여러 층에 보존한 뒤 강한 신호를 장기 기억으로 승격한다. Hermes는 시작부터 활성 메모리의 크기를 작게 고정하고, 길어진 수행법은 스킬로 보낸다. ## OpenClaw는 기록, 회수, 승격을 나눈다 OpenClaw의 기본 메모리는 에이전트 작업공간의 평범한 마크다운 파일이다. 문서에는 숨겨진 내부 상태가 없다고 명시돼 있다. 디스크에 기록된 것만 다음에 기억할 수 있다. 파일의 역할은 네 가지로 갈린다. `USER.md`에는 사용자의 안정적인 선호와 관계, 대화 방식이 들어간다. `MEMORY.md`에는 오래 유지할 사실과 결정이 들어간다. `memory/YYYY-MM-DD.md`는 그날의 관찰과 세션 요약을 담는 작업 기록이다. `DREAMS.md`는 백그라운드 통합 과정과 사람이 검토할 수 있는 요약을 남긴다. 모든 파일이 매번 프롬프트에 들어가지는 않는다. `USER.md`와 `MEMORY.md`는 세션 시작에 쓰이는 작은 층이고, 날짜별 기록은 검색 대상으로 남는다. `MEMORY.md`가 부트스트랩 예산보다 커져도 원본 파일은 그대로 보존된다. 잘리는 것은 모델에게 주입되는 사본이다. OpenClaw가 저장 용량과 활성 문맥을 분리하는 지점이다. 필요한 과거는 `memory_search`와 `memory_get`으로 가져온다. 임베딩을 설정하면 의미 유사도와 키워드를 섞은 하이브리드 검색을 쓴다. 더 넓은 로컬 검색이 필요하면 [QMD 메모리 엔진](https://docs.openclaw.ai/concepts/memory-qmd?ref=zerodraftlab.com)을 붙일 수 있다. QMD는 BM25, 벡터 검색, 재순위를 결합하고 프로젝트 문서나 세션 기록처럼 작업공간 밖의 디렉터리도 색인한다. ## Dreaming은 많이 적힌 내용을 그대로 장기 기억으로 올리지 않는다 날짜별 기록에서 `MEMORY.md`로 올라가는 경로가 [Dreaming](https://docs.openclaw.ai/concepts/dreaming?ref=zerodraftlab.com)이다. 현재 공식 문서에서는 기본 활성화된 백그라운드 통합 시스템으로 설명한다. 한 번의 요약이 아니라 Light, REM, Deep 세 단계를 거친다. Light 단계는 최근 기록과 회수 신호를 읽고 중복을 줄여 후보를 만든다. REM 단계는 반복되는 주제와 연결을 정리한다. 둘 다 `MEMORY.md`를 직접 바꾸지 않는다. Deep 단계에 와서야 후보의 점수, 회수 횟수, 서로 다른 질의에서 등장한 횟수를 함께 검사한다. 세 문턱을 모두 넘은 후보만 장기 기억 갱신 대상으로 들어간다. 승격 직전에는 원문을 다시 읽는다. 삭제되거나 오래된 조각을 그대로 올리지 않기 위해서다. 대화 기록을 후보로 쓸 때는 민감 내용을 먼저 가리고, 출처가 신뢰할 수 없거나 시스템이 주입한 내용은 통합 프롬프트에서 제외한다. 받아들일 수 있는 재작성은 기존 기억을 충분히 보존하고, 새 후보의 출처를 포함하며, 부트스트랩 예산 안에 들어와야 한다. 갱신 전 원본은 SQLite 기반 상태에 보관되고 결과는 `DREAMS.md`에서 검토할 수 있다. OpenClaw의 [Memory Wiki](https://docs.openclaw.ai/plugins/memory-wiki?ref=zerodraftlab.com)도 이 흐름을 대신하지 않는다. 검색, 승격, Dreaming은 활성 메모리 백엔드가 맡고, Memory Wiki는 그 옆에서 주장과 근거, 모순, 최신성을 구조화한다. 회수용 메모리와 관리되는 지식 위키를 별도 층으로 둔 셈이다. ## 대화 압축은 장기 기억과 다른 작업이다 OpenClaw의 [Compaction](https://docs.openclaw.ai/concepts/compaction?ref=zerodraftlab.com)은 오래된 대화를 요약해 현재 세션을 이어가는 기능이다. 최근 메시지는 그대로 두고 이전 턴을 요약한 항목으로 바꾼다. 전체 대화 원본을 장기 기억으로 승격하는 과정은 아니다. 다만 압축 직전에는 중요한 사실이 대화 안에만 남지 않도록 memory flush가 먼저 실행된다. 에이전트에게 필요한 내용을 파일로 저장할 기회를 준 뒤 세션 문맥을 줄인다. OpenClaw에서 압축과 기억이 만나는 지점은 여기까지다. 압축은 현재 대화의 크기를 관리하고, Dreaming은 여러 기록 중 무엇을 다음 세션의 기본 지식으로 남길지 판단한다. ## Hermes는 활성 메모리부터 작게 고정한다 Hermes의 기본 선택은 더 엄격하다. `MEMORY.md`는 환경, 프로젝트 관례, 배운 점을 담으며 기본 한도는 2,200자다. `USER.md`는 사용자 선호와 대화 방식을 담고 1,375자로 제한된다. 문서가 제시하는 전형적인 크기는 각각 8\~15개, 5\~10개 항목이다. 두 파일은 세션을 시작할 때 시스템 프롬프트에 고정된 스냅샷으로 들어간다. 세션 중 메모리를 추가하거나 바꾸면 디스크에는 곧바로 저장되지만 현재 프롬프트는 바뀌지 않는다. 새 내용은 다음 세션부터 기본 문맥에 나타난다. Hermes는 이를 프롬프트 prefix cache를 유지하기 위한 의도적인 설계라고 설명한다. 한도를 넘겼을 때 조용히 오래된 항목을 버리지도 않는다. `memory` 도구가 오류와 현재 항목을 돌려주면 에이전트가 겹치는 내용을 합치거나 덜 중요한 항목을 지운 뒤 다시 추가한다. 공식 문서는 사용량이 80%를 넘으면 새 항목을 넣기 전에 통합하라고 권한다. Hermes에서 메모리 다이어트는 백그라운드의 불투명한 삭제가 아니라 현재 항목을 보고 수행하는 명시적 편집이다. ## Hermes의 학습은 메모리와 스킬로 갈라진다 Hermes는 턴이 끝난 뒤 백그라운드 자기개선 리뷰를 실행할 수 있다. 반복된 사용자 교정이나 다음 세션에도 필요한 사실은 작은 메모리 항목이 된다. 더 긴 절차와 도구 사용법은 [스킬](https://hermes-agent.nousresearch.com/docs/user-guide/features/skills?ref=zerodraftlab.com)로 생성되거나 기존 스킬에 패치된다. 스킬은 항상 프롬프트에 들어가는 문서가 아니다. 필요한 순간에만 불러오는 점진적 공개 구조다. Hermes 공식 문서는 작은 영구 사실은 메모리, 길고 반복 가능한 절차는 스킬에 두라고 구분한다. 메모리 한도를 늘리는 대신 지식의 종류에 따라 로딩 시점을 나눈다. 자동 학습이 불안하면 `memory.write_approval`과 `skills.write_approval`을 켤 수 있다. 이 경우 백그라운드 리뷰가 만든 변경도 바로 반영되지 않고 검토 대기열에 쌓인다. 작은 메모리는 항목 단위로 승인하고, 스킬은 전체 diff를 보고 승인하거나 거절한다. 더 깊은 장기 기억이 필요하면 Honcho, OpenViking, Mem0, Hindsight 같은 외부 provider를 기본 메모리 옆에 붙일 수 있다. ## Hermes도 대화 압축을 메모리와 분리한다 Hermes의 공식 저장소에 있는 [컨텍스트 압축 설명](https://github.com/NousResearch/hermes-agent/blob/main/website/docs/developer-guide/context-compression-and-caching.md?ref=zerodraftlab.com)에는 두 개의 안전선이 나온다. 기본 agent compressor는 컨텍스트의 50%에서 작동하고, gateway는 85%에서 큰 세션을 막는 안전망으로 움직인다. 압축할 때는 오래된 도구 출력을 먼저 비우고, 그래도 크면 이전 대화를 구조화된 요약과 최근 메시지 꼬리로 바꾼다. 이 압축 결과가 `MEMORY.md`로 자동 승격되는 것은 아니다. 현재 대화를 계속할 수 있게 줄이는 작업과 다음 세션에도 남길 사실을 고르는 작업은 독립적으로 움직인다. Hermes는 작은 영구 메모리, 필요할 때 읽는 스킬, 현재 세션을 줄이는 압축을 서로 다른 장치로 관리한다. ## OpenClaw는 승격 문턱을 만들고 Hermes는 자리부터 제한한다 OpenClaw의 기본형은 기록을 넓게 남기는 데 유리하다. 날짜별 메모리를 검색할 수 있고, 반복해서 회수되는 신호를 Dreaming이 장기 기억으로 올린다. 자료가 많아질수록 무엇을 삭제할지보다 무엇을 승격할지가 중요해진다. 대신 검색 인덱스, 후보 점수, 통합 결과를 함께 관리해야 한다. Hermes의 기본형은 항상 들어오는 문맥을 예측하기 쉽다. 2,200자와 1,375자라는 작은 예산 때문에 항목 하나를 추가하려면 기존 내용을 합칠지 판단해야 한다. 긴 절차는 스킬로 빠지고, 더 큰 기억은 외부 provider가 맡는다. 대신 기본 메모리만으로 많은 과거 기록을 탐색하는 구조는 아니다. 어느 쪽도 모든 대화를 매번 프롬프트에 다시 넣지 않는다. OpenClaw는 작업 기록, 검색, 장기 기억, 위키를 층으로 나눈다. Hermes는 사용자 프로필, 작은 영구 메모리, 스킬, 외부 provider를 나눈다. 두 제품에서 공통으로 남는 원칙은 저장된 기록의 양과 지금 모델이 읽어야 할 양을 같은 숫자로 관리하지 않는다는 것이다. 그래서 OpenClaw의 질문은 “이 기록이 여러 상황에서 다시 불렸는가”에 가깝다. Hermes의 질문은 “이 사실이 다음 세션의 2,200자 안에 계속 남을 자격이 있는가”에 가깝다. 하나는 승격의 증거를 쌓고, 다른 하나는 작은 자리에서 경쟁시킨다. --- 주요 출처: OpenClaw 공식 문서 [Memory overview](https://docs.openclaw.ai/concepts/memory?ref=zerodraftlab.com), [Dreaming](https://docs.openclaw.ai/concepts/dreaming?ref=zerodraftlab.com), [Compaction](https://docs.openclaw.ai/concepts/compaction?ref=zerodraftlab.com), [QMD memory engine](https://docs.openclaw.ai/concepts/memory-qmd?ref=zerodraftlab.com), [Memory Wiki](https://docs.openclaw.ai/plugins/memory-wiki?ref=zerodraftlab.com); Hermes Agent 공식 문서 [Persistent Memory](https://hermes-agent.nousresearch.com/docs/user-guide/features/memory/?ref=zerodraftlab.com), [Skills System](https://hermes-agent.nousresearch.com/docs/user-guide/features/skills?ref=zerodraftlab.com), 공식 저장소의 [background\_review.py](https://github.com/NousResearch/hermes-agent/blob/main/agent/background%5Freview.py?ref=zerodraftlab.com)와 [Context Compression & Prompt Caching](https://github.com/NousResearch/hermes-agent/blob/main/website/docs/developer-guide/context-compression-and-caching.md?ref=zerodraftlab.com). 기능과 기본값은 2026년 8월 8일 확인한 문서 기준입니다. 마지막 두 단락의 장단점과 질문 형태는 공식 기능을 비교한 Zero Draft Lab의 해석입니다. ### 안 되는 제품은 시간을 두 번 쓴다 URL: https://zerodraftlab.com/cost-of-not-pivoting/ Last updated: 2026-09-15T08:35:10.000Z 돈이 없는 창업자는 돈보다 먼저 시간을 잃는다. 한 번에 두 제품을 제대로 만들 수 있다고 믿어도 실제로는 한 제품이 가장 좋은 시간과 판단력을 가져간다. 그래서 제품 하나를 계속 붙잡는 비용은 개발에 들어간 시간만이 아니다. 그동안 시작하지 못한 다음 제품의 시간까지 함께 사라진다. Y Combinator의 Dalton Caldwell은 [피벗 강연](https://www.youtube.com/watch?v=8pNxKX1SUGE&t=128s&ref=zerodraftlab.com)과 [공식 녹취](https://www.ycombinator.com/blog/startup-school-week-6-recap-tim-brady-on-culture-and-dalton-caldwell-on-pivoting/?ref=zerodraftlab.com)에서 이 문제를 기회비용으로 설명한다. 한 번에 제대로 할 수 있는 일은 사실상 하나인데, 안 된다는 증거가 있는 일에 계속 매달리면 다른 일을 하지 못하는 비용을 치른다는 것이다. 실패한 제품은 시간을 한 번 쓰고 끝나지 않는다. 자기 수명을 연장하는 데 한 번, 다음 가능성을 막는 데 다시 한 번 쓴다. 이 설명이 불편한 이유는 창업자의 미덕으로 여겨지는 끈기와 충돌하기 때문이다. 우리는 오래 버틴 사람의 성공담은 기억하지만, 같은 반응을 붙잡은 채 몇 년을 보낸 사람의 장부는 잘 보지 않는다. 이미 쓴 시간은 앞으로도 써야 할 이유처럼 느껴진다. Caldwell이 사람들이 피벗을 늦추는 첫 이유로 손실 회피를 드는 까닭이다. 그는 농담처럼 제품의 상태를 ‘지금까지 나온 반응 ÷ 집중해서 투입한 개월 수’로 보라고 말한다. 정확한 계산식은 아니지만 방향은 선명하다. 같은 가입자 열 명이라도 2주 만에 얻었을 때와 18개월 만에 얻었을 때의 의미는 다르다. 투입이 늘었는데 반응의 강도가 그대로라면, 시간이 문제를 해결한 것이 아니라 약한 신호를 더 비싸게 만들었을 수 있다. ## 빨리 만드는 이유는 빨리 포기하기 위해서가 아니다 YC가 첫 버전을 일찍 내라고 반복해서 말하는 이유도 여기에 있다. [출시 강연](https://www.youtube.com/watch?v=u36A-YTxiOw&t=45s&ref=zerodraftlab.com)에서는 창업자가 몇 달 동안 출시를 공들여 준비해도 대부분은 아무도 관심을 보이지 않는다고 지적한다. 첫 제품을 고객 앞에 놓는 데 6개월이 걸리면 두 번째로 배울 기회가 오기 전에 회사가 끝날 수도 있다. 다른 [MVP 강연](https://www.youtube.com/watch?v=1hHMwLxN6EM&t=279s&ref=zerodraftlab.com)의 표현은 더 짧다. 첫 버전은 몇 달이 아니라 몇 주 안에 만들 수 있어야 한다. 여기서 속도는 생산성 자랑이 아니다. 시장의 답을 받기 전까지 창업자가 하는 일은 대부분 추측이다. 기능을 더 붙이고 문장을 더 다듬어도 고객이 실제로 보고, 쓰고, 거절하거나 돈을 내기 전에는 그 제품이 안 되는지조차 알 수 없다. 시장에 한 번도 닿지 않은 제품은 오래 만들었어도 오래 검증한 제품이 아니다. 제작 기간을 줄인다는 것은 실패를 서두르는 일이 아니라 판단 가능한 증거가 없는 기간을 줄이는 일이다. 그러므로 중단은 감정의 반대말이 아니라 증거의 다음 행동이다. 충분한 반응이 생기면 더 투자하고, 약한 반응만 반복되면 같은 자원을 더 나은 질문으로 옮긴다. 피벗은 꿈을 배신하는 사건이 아니라 자원을 다시 배치하는 결정이다. 하지만 실망할 때마다 아이디어를 바꾼다면 100번의 출시는 100개의 미완성 파일만 남길 것이다. 그렇다면 끈기와 미련, 피벗과 아이디어 쇼핑은 어디에서 갈릴까. Caldwell의 답은 모든 시도가 한 번의 슛으로 인정되는 것은 아니라는 데서 시작한다. 그는 여러 번의 슛이 한 번보다 성공하기 쉽다고 말하면서도, 반드시 ‘질 좋은 슛’이어야 한다고 선을 긋는다. 만들다 만 아이디어를 계속 갈아타는 것은 확률을 높이지 않는다. 제품을 완성하고, 출시하고, 사람에게 건네고, 반응을 확인하는 한 사이클을 닫아야 비로소 다음 슛이 의미를 가진다. ## 미완성은 실패가 아니라 미측정이다 이 구분이 없으면 빠른 피벗은 가장 편리한 회피가 된다. 구현이 어려워졌을 때, 첫 반응이 차가웠을 때, 더 화려한 아이디어를 발견했을 때마다 방향을 바꿀 수 있다. Caldwell도 아이디어를 만성적으로 바꾸는 사람이라면 오히려 하나를 끝까지 밀어볼 필요가 있다고 경고한다. 유행하는 분야가 나타났다는 이유만으로 옮기는 것도 좋은 피벗이 아니다. 좋은 피벗은 불편한 절차를 먼저 통과한다. 낯선 사람이 이해할 수 있는 형태로 제품을 끝내고, 실제 사용을 요청하고, 가능하면 돈을 요구한다. 그 뒤에도 반응이 약해야 비로소 ‘안 된다’는 증거가 생긴다. 고객에게 보여주지 않은 제품, 가격을 붙이지 않은 제품, 유통을 시도하지 않은 제품은 실패작이 아니다. 아직 측정하지 않은 작업이다. 그래서 최소 제품의 핵심은 기능 수보다 닫힌 학습 주기다. YC에 실린 [SketchDeck의 기록](https://www.ycombinator.com/blog/tips-ship-early-and-often?ref=zerodraftlab.com)을 보면 첫 제품의 제작 기간은 3개월에서 1주, 하루, 몇 시간으로 줄었다. 가장 큰 반응을 얻은 것은 파일과 이메일 주소를 받는 단일 페이지였다. 복잡한 기능이 없어서 성공한 것이 아니라, 고객이 원하는 행동을 하고 창업자가 그 반응을 읽을 수 있을 만큼은 완결되어 있었다. 같은 강연에서 Caldwell은 Magic이 주말에 프로토타입을 만들었고, Retool은 피벗한 제품을 2주 만에 만들어 첫 고객을 얻었다고 설명한다. 이 숫자를 모든 제품의 제작 시한으로 복사하면 곤란하다. 하드웨어와 규제 산업, 기업 영업은 다른 시간을 요구한다. 중요한 것은 달력의 짧음이 아니라 투입한 시간에 비해 시장의 신호가 강해지고 있는지다. ## 중단 날짜보다 먼저 필요한 것 제품을 언제 죽일지 정하는 보편적인 날짜는 없다. 대신 계속할 이유는 점점 더 강해져야 한다. 사용자가 다시 오고, 돈을 내고, 다른 사람에게 권하고, 창업자가 밀지 않아도 사용이 이어지는 방향으로 움직여야 한다. 시간이 지날수록 설명과 설득만 늘고 행동은 그대로라면, 더 많은 시간은 반전을 위한 투자가 아니라 같은 결론의 구매가 된다. 반대로 작은 반응이라도 질이 좋아지고 있다면 기간만 보고 버리는 것도 잘못이다. 가입자 수는 적어도 결제 비율이 높아지거나, 사용자가 자발적으로 돌아오거나, 특정 고객군에서 문제가 유난히 선명해질 수 있다. 피벗의 기준은 ‘몇 주가 지났는가’가 아니라 ‘새로운 증거가 기존 판단을 얼마나 바꾸었는가’다. 여러 번의 슛을 확보한다는 말도 결국 같은 뜻이다. 아무거나 많이 만드는 것이 아니라, 하나를 시장이 판정할 수 있는 상태까지 작게 끝내고 그 판정을 다음 시도에 반영한다. 한 발을 오래 조준한다고 명중률이 계속 오르지는 않는다. 이미 빗나갔다는 증거가 있는데도 방아쇠를 붙잡고 있으면 다음 발을 쏠 수 없다. 끈기는 특정 제품을 영원히 살리는 능력이 아니다. 고객이 원하는 문제를 찾을 때까지 완성하고, 내놓고, 듣고, 다시 선택하는 능력이다. 제품에는 미련을 덜 두고 탐색에는 더 끈질겨야 한다. 그래야 실패한 제품이 시간을 두 번 쓰지 않고, 다음 제품의 출발점이 된다. ### 100개를 만들겠다는 말의 진짜 의미 URL: https://zerodraftlab.com/why-build-one-hundred-products/ Last updated: 2026-09-15T08:35:11.000Z 2021년 피터 레벨스는 자신이 만든 70개가 넘는 프로젝트 가운데 돈을 벌면서 성장한 것은 4개뿐이었다고 적었다. 계산하면 약 5.7%다. 이 한 줄은 금세 매혹적인 공식으로 바뀐다. 제품을 100개 만들면 다섯 개쯤 성공한다는 공식이다. 하지만 레벨스의 [프로젝트 장부](https://levels.io/projects/?ref=zerodraftlab.com)를 열어보면 그렇게 단순한 통계가 아니다. 지금 장부에는 오래 돈을 번 성공작뿐 아니라 잠깐 돈을 번 프로젝트, 실패작, 애초에 수익을 목적으로 하지 않은 작업, 아직 판정할 수 없는 신작이 함께 들어 있다. 2021년의 4개와 지금 장부의 분류도 같지 않다. 분모를 무엇으로 잡느냐에 따라 성공률은 달라진다. 그러므로 5%는 자연법칙도, 성과 보장도 아니다. 피터 레벨스에게서 가져올 것은 숫자가 아니라 태도다. 성공작을 미리 알아맞힐 수 있다는 믿음을 버리고, 시장이 판단할 수 있을 만큼 완성된 시도를 반복한다는 태도다. ## 많이 만든다는 말은 오래 만들지 않겠다는 말이다 레벨스가 처음부터 다작을 신봉했던 것은 아니다. 그는 한 프로젝트에 1년을 썼지만 고객은 돈을 내지 않았고, 그 뒤에야 여러 개를 만들어 반응을 보겠다는 방식으로 돌아섰다고 [회고했다](https://levels.io/bootstrapping/?ref=zerodraftlab.com). 이어 한 달에 하나씩 실제로 끝내고 출시하는 ‘12개월 12개 스타트업’을 시작했다. 여기서 중요한 단어는 ‘12개’보다 ‘끝내고 출시한다’다. 아이디어를 적는 것, 대기자 명단을 받는 것, 서버에 올려두는 것은 시장에 노출된 제품과 다르다. 낯선 사람이 제품을 이해하고, 사용하고, 가능하다면 돈까지 낼 수 있어야 한다. 그래야 다음 행동이 기다림이 아니라 판정이 된다. 존 용푹의 초기 실험은 이 차이를 잘 보여준다. 그는 7개월 동안 제품 7개를 출시했지만 직접 매출은 0달러였다고 [기록했다](https://www.bannerbear.com/journey-to-10k-mrr/?ref=zerodraftlab.com). 이유도 명확했다. 제품들에 수익모델이 없었다. 출시 습관과 기술적 관심사는 얻었지만, 시장이 구매로 답할 질문은 던지지 않은 셈이다. 그래서 출시 수만 세면 위험하다. 무료 도구 하나와 가격이 붙은 제품 하나, 지인에게 보여준 데모와 공개 유통을 거친 제품 하나, 첫날 방문자가 많은 제품과 석 달 뒤에도 반복 결제가 남는 제품 하나를 같은 한 건으로 셀 수 있기 때문이다. 물량은 늘었는데 사업적 학습은 늘지 않을 수 있다. ## 100번의 출시는 100개의 회사를 뜻하지 않는다 100 Launches를 제대로 세려면 제품보다 판정 가능한 실험을 세야 한다. 출시 한 건에는 최소한 고객 한 종류, 해결할 문제 한 가지, 실제 유료 행동 하나가 있어야 한다. 공개 URL과 유입 경로, 결제 또는 선주문, 그리고 계속할지 중단할지 판단할 날짜도 필요하다. 이 정의는 한 제품 안에서 기능을 계속 늘리는 방식과 반대다. 회사 차원에서는 시도를 더하지만, 각 시도 안에서는 선택지를 뺀다. 누구나 쓸 수 있는 만능 도구 대신 특정 고객이 특정 순간에 돈을 내고 끝낼 수 있는 작은 결과를 만든다. 성공 확률을 높이는 비밀 기능을 찾는 것이 아니라 실패 한 번의 가격을 낮춘다. 이때 5%는 목표 적중률이 아니라 자원 배분을 위한 가정에 가깝다. 대부분이 중단될 수 있다고 전제하면 첫 버전에 석 달을 쓰기 어려워지고, 공통 인증·결제·계측·배포 부품을 재사용하게 되며, 약한 반응을 자존심 때문에 연장할 이유도 줄어든다. 반대로 돈과 반복 사용이 함께 나타난 제품에는 새 실험보다 더 많은 시간을 줄 수 있다. 문제는 여전히 남는다. 중단될 95개를 싸게 만드는 것만으로는 충분하지 않다. 실패할 때마다 고객 조사, 랜딩페이지, 코드, 유통 관계를 처음부터 다시 만든다면 100번째 제품도 첫 번째 제품만큼 비싸다. 그렇다면 나머지 95개의 실패를 어떻게 낭비가 아니게 만들 수 있을까. 그 답은 출시를 독립된 복권이 아니라 앞선 시도의 자산을 물려받는 연속 실험으로 설계하는 데서 시작한다. ## 한 번의 출시를 작게 닫는 법 에드먼드 용의 최근 앱 제작기는 이 한 사이클을 구체적으로 보여준다. 그는 [아이디어 검증 영상](https://www.youtube.com/watch?v=OoofplYkDQI&ref=zerodraftlab.com)에서 독창성보다 이미 돈이 흐르는 문제를 찾으라고 말한다. 경쟁 제품이 있다는 사실은 피해야 할 적신호가 아니라 수요가 존재한다는 증거가 될 수 있다. 더 단순하게, 더 싸게, 더 쉽게 만들거나 빠진 핵심 기능을 채우는 식으로 차이를 만든다. 그는 번역 튜토리얼 프로젝트를 유튜브 자막 번역 문제로 좁혀 Fluently를 만들었다. [제작 영상](https://www.youtube.com/watch?v=%5FtLJR5OaiCw&ref=zerodraftlab.com)에서 첫 버전의 제작 상한을 주말로 두고, ‘단순하지만 좋아할 만하고 완결된’ 제품을 내는 SLC 방식을 적용했다고 설명한다. 얇은 데모가 아니라 사용자가 결과를 얻고 결제할 수 있는 최소 완결판이다. 출시 뒤에는 Product Hunt, X, LinkedIn, Reddit을 시험했고 광고도 집행했다. 그가 영상에서 공개한 자기보고 수치로는 광고비 100달러 이상이 노출 15만 회 이상과 클릭 400회 이상을 만들었고, 가입자 26명 가운데 5명이 결제해 약 100달러의 월 반복 매출이 생겼다. 성공담이라기보다 한 번의 출시가 어디에서 막혔는지 읽을 수 있는 작은 손익계산서에 가깝다. 여기서 출시의 완료는 제품을 올린 날이 아니다. 문제의 증거, 제작 상한, 실제 결제, 채널별 유입, 단위경제가 한 줄로 이어진 날이다. 이 정도가 보여야 다음 제품으로 갈지, 같은 제품의 전환을 고칠지, 더 크게 투자할지를 결정할 수 있다. 그런데 이 실험에서 결제가 전혀 없었다면 제품을 바로 버려야 했을까. 고객이 없는 것과 고객에게 닿지 못한 것은 다른 실패다. 그렇다면 제품 실패와 판매 실패를 어떻게 구분할 수 있을까. 구분하려면 제품의 고객과 문제는 잠시 고정한 채, 그것을 설명하고 제안하고 유통하는 방식만 제한된 횟수로 바꿔 봐야 한다. ## 제품 실패와 판매 실패를 분리해야 한다 사브리 수비에게서 가져올 것은 제품 개수가 아니라 제품 하나 안의 판매 실험이다. 그의 [공식 판매 페이지](https://summit.selllikecrazybook.com/?ref=zerodraftlab.com)는 구매 욕구가 강한 고객을 정하고, 그들의 언어를 조사하고, 제안과 광고 문구와 퍼널을 반복해서 시험하는 직접반응 마케팅의 구조를 그대로 드러낸다. 페이지에 등장하는 거대한 성과 수치는 판매자의 주장이지 이 글이 독립 검증한 실적은 아니다. 참고할 것은 과장이 아니라 실험 단위다. 사람이 결제하지 않았다는 사실만으로 제품 가설 전체가 틀렸다고 단정할 수는 없다. 고객이 아닌 사람에게 보여줬을 수 있고, 문제가 아니라 기능을 설명했을 수 있고, 가격이 아니라 위험이 커 보였을 수 있고, 고객이 없는 채널에서 기다렸을 수 있다. 반대로 훅과 오퍼를 계속 바꾸느라 결제 없는 제품의 수명을 무한히 연장해서도 안 된다. 따라서 한 제품은 여러 개의 메시지 샷을 가질 수 있지만 판정일은 하나여야 한다. 고객군, 핵심 문제, 유료 결과는 고정하고 훅·제안·랜딩·유통 경로를 제한된 횟수로 바꿔 본다. 그 뒤에도 돈과 반복 사용이 없으면 제품을 중단한다. 이 구분이 있어야 100 Launches가 조급한 폐기와 끝없는 미련 사이에서 작동한다. ## 실패한 제품도 다음 제품의 원가를 낮춰야 한다 다니엘 프리슬리의 역할은 여기서 시작한다. 그는 [『24 Assets』](https://danielpriestley.com/24-assets-book/?ref=zerodraftlab.com)에서 사업을 디지털이고 확장 가능하며 가치 있는 자산의 묶음으로 보는 관점을 제시한다. 프리슬리는 100개 제품을 만든 사례가 아니다. 그의 렌즈는 중단된 제품에서 무엇을 회수할지를 묻게 한다. 실패한 랜딩페이지에서 고객이 실제로 쓰는 문제 언어를 남길 수 있다. 가입은 했지만 결제하지 않은 사람의 질문에서 새로운 반론 처리를 남길 수 있다. 인증, 결제, 이메일, 계측 코드는 다음 제품의 제작 시간을 줄이는 공용 부품이 된다. 작게나마 반응한 채널과 아무도 오지 않은 채널의 차이는 다음 출시의 유통 자산이 된다. 이렇게 보면 실패의 반대는 성공이 아니다. 아무것도 남기지 못한 것이 실패다. 제품은 닫혀도 고객 언어, 코드, 가격 학습, 유통 관계, 운영 절차 가운데 하나 이상이 다음 시도로 넘어가야 한다. 그러면 열 번째 출시는 첫 번째보다 빨라지고, 서른 번째 출시는 앞선 스물아홉 번의 데이터 위에서 시작한다. 에드먼드 용의 첫 매각도 같은 점을 보여준다. 그는 작은 브라우저 확장 프로그램 Easy Folders가 누적 10만 달러가 넘는 매출을 냈고 다섯 자리 금액에 팔렸다고 [직접 밝혔다](https://www.youtube.com/watch?v=wbvMph3m88Q&ref=zerodraftlab.com). 동시에 ChatGPT 위에 지은 제품이라 플랫폼 업데이트가 기능을 깨뜨릴 수 있었다고 설명한다. 구매자는 매출뿐 아니라 유지보수 부담과 자산 이전 가능성을 본다. 작은 제품도 코드와 고객과 현금흐름이 넘겨질 수 있을 때 사업 자산이 된다. ## 많이 쏘는 사람에게 더 중요한 것은 멈추는 규칙이다 마크 루는 2023년 자신의 [뉴스레터](https://newsletter.marclou.com/p/my-solopreneur-story-0-to-65k-month-in-2-years?ref=zerodraftlab.com)에서 2년 동안 제품 17개를 출시했고 월 6만5천 달러에 도달했다고 썼다. 모두 자기보고 수치다. 더 유용한 대목은 그가 나중에 적용했다는 규칙이다. 무료 플랜을 두지 않고, 진통제 같은 문제만 고르며, 제품-시장 적합성이 없으면 이동했다. 8개월 동안 만든 8개 중 6개가 돈을 벌었지만 생활비를 낸 것은 2개였다고도 적었다. 돈을 벌었다는 제품과 자원을 집중할 승자는 같은 말이 아니다. 한 번 결제된 제품, 유지비를 겨우 충당하는 제품, 반복 사용과 공헌이익이 늘어나는 제품을 나눠야 한다. 작은 매출을 성공으로 세면 포트폴리오는 곧 관리해야 할 잔존 제품으로 가득 찬다. 승자는 돈과 반복이 함께 강해지고, 더 투자할수록 창업자의 시간이 아니라 시스템이 커지는 제품이어야 한다. Supercell은 비용 규모가 전혀 다른 회사라 1인 창업의 경제성과 비교할 수 없다. 다만 중단 거버넌스는 참고할 만하다. 회사는 2022년 글에서 당시 글로벌 히트작 5개를 출시하는 동안 30개가 넘는 게임을 중단했다고 [밝혔다](https://supercell.com/en/news/next-chapter/?ref=zerodraftlab.com). 좋은 게임도 장기 기준을 넘지 못하면 팀이 스스로 중단하고, 학습과 인력을 다음 시도로 옮겼다. 이 운영법에서 중단은 벌이 아니다. 더 나은 베팅에 자원을 돌려주는 행위다. 동시에 약한 숫자 하나 때문에 너무 빨리 죽이는 것도 아니다. 고객이 다시 쓰는지, 다시 돈을 내는지, 공헌이익이 남는지, 창업자 없이 유지 가능한지를 정해진 날짜에 함께 본다. 숫자의 보편 임계값은 사업마다 다르지만, 판정일과 판정 항목은 출시 전에 있어야 한다. ## 100번 출시하는 회사는 제품 공장이 아니다 피터 레벨스는 시도의 수를 늘린다. 에드먼드 용은 한 시도를 주말급 완결판과 실제 결제로 닫는다. 사브리 수비는 제품 가설과 판매 가설을 분리한다. 다니엘 프리슬리는 중단된 시도에서도 다음 원가를 낮출 자산을 회수한다. 존 용푹과 마크 루는 출시량을 수익모델과 구매로 다시 묶는다. Supercell은 승자가 아닌 프로젝트에서 자원을 회수한다. 이들을 하나로 엮으면 순서는 단순하다. 많이 쏘되 한 발은 작게 만든다. 작게 만들되 결제할 수 있을 만큼 완결한다. 반응이 없으면 제품을 탓하기 전에 제한된 판매 실험을 한다. 그래도 돈과 반복이 없으면 중단하고 자산을 회수한다. 강한 신호가 나오면 새 제품 수를 줄이고 승자에게 집중한다. 그래서 100개를 만들겠다는 선언의 진짜 의미는 100개의 SaaS를 소유하겠다는 것이 아니다. 예측의 자신감보다 판정의 속도를 믿겠다는 뜻이다. 첫 번째 실패와 아흔아홉 번째 실패의 가격이 같지 않도록 만들겠다는 뜻이다. 그리고 다섯 개의 승자가 나타났을 때 나머지 아흔다섯 개를 계속 부양하지 않을 용기를 미리 설계하겠다는 뜻이다. ### 회의주의를 대신해주는 사람은 권위가 된다 URL: https://zerodraftlab.com/outsourced-skepticism-builds-authority/ Last updated: 2026-09-15T08:35:11.000Z [알간지의 맥도날드 핫커피 영상](https://www.youtube.com/watch?v=ZjA1-yukZWw&ref=zerodraftlab.com)은 한 문장으로 시작한다. 우리가 진실이라 믿는 거짓이 어떻게 만들어지고 이용되는지 보겠다는 것이다. 영상은 먼저 대중이 기억하는 사건을 꺼낸다. 운전하던 할머니가 뜨거운 커피를 쏟고 맥도날드에서 거액을 받아냈다는 이야기다. 투표를 열고 채팅 반응을 보여준 뒤, 8분 46초에 진행자가 말한다. “이제 진실을 알아보죠.” 뒤이어 정반대의 사건이 복원된다. 스텔라 리벡은 운전자가 아니었다. 차는 주차돼 있었다. 79세였던 그는 몸의 16%에 화상을 입었고 그중 약 6%는 3도 화상이었다. 피부 이식과 장기 치료가 필요했다. 맥도날드 매뉴얼은 커피를 180\~190°F로 제공하도록 했고, 회사에는 이전 10년 동안 700건이 넘는 화상 신고가 들어와 있었다. 배심은 리벡에게도 20%의 과실이 있다고 봤지만 맥도날드의 책임이 더 크다고 판단했다. 270만 달러의 징벌적 손해배상은 판사가 48만 달러로 줄였고, 양측은 나중에 비공개 금액으로 합의했다. 이 핵심 사실들은 재판기록을 인용한 [University of Miami Law Review의 사례 연구](https://lawcat.berkeley.edu/record/1117858/files/fulltext.pdf?ref=zerodraftlab.com), [Cornell Legal Information Institute](https://www.law.cornell.edu/wex/Liebeck%5Fv%5FMcDonalds%5FRestaurants%5F1994?ref=zerodraftlab.com), [American Museum of Tort Law](https://www.tortmuseum.org/liebeck-v-mcdonalds/?ref=zerodraftlab.com)의 설명과 대체로 일치한다. 이 영상은 흔한 통념보다 정확하다. 평결액과 실제 수령액도 구분한다. 현재 맥도날드 매뉴얼의 온도가 낮아졌다는 대목은 공개 원문으로 확인하기 어려웠지만, 영상도 리벡 사건과의 인과는 단언하지 않았다. 사실관계가 대체로 맞아도 다른 문제는 남는다. 영상은 짧고 강한 한 방향의 이야기를 경계하라고 말한다. 맥락은 많은 정보를 요구하며, 빠른 판단 전에 충분한 정보를 접했는지 점검해야 한다고 결론낸다. 하지만 시청자는 무엇이 충분한 정보인지 직접 고르지 않았다. 어떤 기록을 보고, 어느 반론을 남기고, 어디서 사실 확인을 멈출지, 사건에서 어떤 교훈을 꺼낼지까지 진행자가 결정했다. 짧은 통념을 무너뜨린 것은 독립적인 검증이 아니라 더 길고 완성도 높은 반전 서사였다. ## 최근 해설 영상 9편 중 7편이 같은 역할을 배치했다 한 편의 인상으로 채널 전체를 재단하지 않기 위해 2026년 8월 8일 현재 최근 공개 업로드 12편을 고정해 봤다. 질의응답 클립, 실시간 채팅 게임, 자사 도서 발표를 빼면 외부 사건·인물·개념을 설명하는 제작형 롱폼은 9편이었다. 각 영상에서 다섯 장치를 확인했다. 시청자가 믿을 법한 통념이나 첫 판단을 제시하는가. 핵심 정보를 뒤로 미뤘다가 반전시키는가. 투표·채팅·가상문답으로 초기 오답을 화면에 배치하는가. 여러 자료의 최종 의미를 진행자가 확정하는가. 마지막에 일반적인 삶의 태도나 도덕적 교훈을 제시하는가. 다섯 장치 가운데 네 개 이상이 나타난 영상은 9편 중 7편이었다. 핫커피 영상은 다섯 개가 모두 있었다. 뉴욕의 군중을 다룬 영상은 무질서한 폭동처럼 보이는 장면에서 시작해 농구팀 우승의 기쁨으로 뒤집은 다음, 같은 군중을 이해하게 됐는지 다시 투표했다. 예언가를 다룬 영상은 초능력·심리 분석·마술 중 하나를 고르게 한 뒤 트릭을 해설하고 최초 투표를 다시 열었다. 결혼, 테일러 스위프트, 트럼프, AI 산업 영상도 통념이나 질문을 먼저 세우고, 지연된 답과 진행자의 일반 교훈으로 닫혔다. 반례도 있었다. \`flow\`를 설명한 영상은 답을 초반에 바로 말했고, AI 여자친구 로봇 영상은 두 질문의 답을 미뤘지만 시청자를 명시적인 오답자 자리에 놓지는 않았다. 그래서 이 관찰은 채널의 모든 영상을 하나로 묶지 않는다. 더 좁게 말하면, 최근 외부 주제 해설에서 반복되는 주된 형식은 **통념을 깨주는 해설자**다. ## 의심을 배우는 것과 의심을 맡기는 것은 다르다 Dan Sperber와 동료들은 이를 생각할 단서를 [인식적 경계(epistemic vigilance)](https://doi.org/10.1111/j.1468-0017.2010.01394.x?ref=zerodraftlab.com)라는 개념으로 설명한다. 인간은 타인의 말에 크게 의존한다. 그 의존이 유리하려면 발신자가 유능하고 정직한지, 전달된 내용이 기존 지식과 증거에 비춰 믿을 만한지를 계속 평가해야 한다. 무조건 믿는 것도, 무조건 불신하는 것도 경계가 아니다. 좋은 해설은 이 비용을 줄인다. 흩어진 기록을 모으고, 잘못 알려진 사실을 바로잡고, 독자가 원문까지 갈 수 있게 한다. 핫커피 영상은 실제로 이 일을 상당 부분 해냈다. 하지만 해설자가 사실 수집뿐 아니라 반론의 강도와 최종 의미까지 대신 정하면 시청자는 의심하는 법을 연습하지 않아도 된다. 첫 번째 권위를 불신하고 두 번째 권위를 신뢰하면 된다. 언론의 짧은 보도를 의심하는 대신, 그 보도를 뒤집어주는 진행자의 긴 설명을 믿는다. 믿음의 내용은 더 정확해질 수 있지만 믿음을 만드는 절차는 여전히 타인에게 있다. 이것이 빌려온 회의주의다. 시청자는 의심한 결과를 소유하지만 의심하는 과정을 수행하지 않는다. 그래서 영상이 끝난 뒤 남는 것은 “나는 속지 않았다”는 감각과 진행자의 다음 판정을 기다리는 습관일 수 있다. 맞는 답을 얻는 일과 스스로 판단할 수 있게 되는 일은 같은 성과가 아니다. 그렇다면 긴 설명은 언제 배움을 만들고, 언제 해설자의 권위를 만드는가. 차이는 영상 길이가 아니라 설명의 비대칭에 있다. 시청자는 진행자가 고른 자료만 볼 수 있고, 진행자는 시청자의 첫 답을 보면서도 자신의 조사 과정에서 틀렸던 순간은 편집할 수 있다. 반전이 완성된 영상에서는 진행자만 처음부터 끝까지 아는 사람이고 시청자는 정해진 순서로 무지를 벗어나는 사람이 된다. ## 매끄러운 설명은 진실보다 먼저 완성감을 준다 Rolf Reber와 Christian Unkelbach는 [처리 유창성과 진실 판단의 관계](https://doi.org/10.1007/s13164-010-0039-7?ref=zerodraftlab.com)를 검토했다. 사람은 반복해서 접해 쉽게 처리되는 문장을 새로운 문장보다 참이라고 판단하는 경향이 있다. 저자들은 이것을 무조건 오류로 취급하지 않았다. 우리가 접하는 진술의 과반이 참이라면 익숙함과 용이성을 진실의 단서로 사용하는 것은 현실에서 꽤 합리적일 수 있다. 35분짜리 영상이 인물, 재판, 정치, 언론을 하나의 인과로 잇고 예상 반론까지 제때 해소하면 결론은 머릿속에서 쉽게 굴러간다. 어려운 사건이 이해 가능한 모양을 얻는다. 다만 논문이 직접 다룬 것은 주로 반복 노출로 생기는 유창성이다. 잘 편집된 영상의 인과적 매끄러움에 같은 효과가 그대로 난다고 확정할 수는 없다. 여기서 가능한 말은 더 제한적이다. **이해하기 쉬운 설명은 근거가 충분한 설명처럼 느껴질 조건을 만든다.** 그 느낌은 설명 깊이와도 연결된다. Leonid Rozenblit와 Frank Keil은 [설명 깊이의 착각](https://doi.org/10.1207/S15516709COG2605%5F1?ref=zerodraftlab.com)을 12개 연구로 보였다. 참가자들은 지퍼나 헬리콥터 같은 장치의 작동을 실제보다 깊게 안다고 평가했다. 그러나 원리를 단계별로 직접 설명하게 하자 자기평가가 낮아졌다. 알아보는 것과 만들어내는 것 사이에 틈이 있었던 것이다. 영상의 설명을 따라가며 고개를 끄덕이는 일도 사건을 다시 구성하는 일과 다르다. 영상을 끄고 재판 쟁점, 맥도날드의 가장 강한 반론, 확인되지 않은 주장, 결론을 바꿀 증거를 적으라고 하면 막힐 수 있다. 핫커피 사건의 새 결론을 기억한다고 해서 그 결론에 이른 검증 절차까지 가진 것은 아니다. 원 연구가 유튜브 시청을 실험한 것은 아니므로 이것은 적용 가설이다. 그래도 설명을 소비한 뒤 무엇을 직접 재현할 수 있는지 묻는 검사는 유용하다. ## 반전 서사는 사실을 고치는 동시에 역할을 고정한다 Melanie Green과 Timothy Brock의 [서사 운송 연구](https://doi.org/10.1037/0022-3514.79.5.701?ref=zerodraftlab.com)에서는 이야기에 더 몰입한 참가자일수록 이야기와 일치하는 믿음과 인물 평가가 강했다. 높은 몰입 집단은 이야기 속 어색하거나 틀린 대목도 덜 찾아냈다. 네 실험은 글로 된 서사를 사용했으므로 유튜브 영상에 효과 크기를 옮길 수는 없다. 다만 핫커피 영상이 왜 사건 목록보다 강한지는 설명한다. 영상에는 무고하게 조롱당한 피해자, 위험을 알면서 무감각했던 기업, 맥락을 잘라낸 언론, 사건을 이용한 정치가 있다. 마지막에는 제한된 정보로 서로에게 잔인해지는 인간이 남는다. 각 대목에 근거가 있어도 이 배열은 하나의 도덕적 방향을 만든다. 사실 확인은 피해자 복권의 서사 안에서 진행되고, 시청자는 자료를 비교하기 전에 결말에 도착한다. 도덕적 결론은 확산에도 유리할 수 있다. William Brady와 동료들은 [총 563,312개의 정치 트윗](https://doi.org/10.1073/pnas.1618923114?ref=zerodraftlab.com)을 분석해 도덕과 감정을 함께 담은 단어가 하나 늘 때 예상 리트윗률이 평균 약 20% 높아지는 연관을 보고했다. 이는 트위터 관찰 연구이지 유튜브 추천의 인과 실험이 아니다. 그래도 사건 설명이 \`무엇이 있었나\`에서 끝나지 않고 잔인함, 사랑, 용기, 인간다움으로 닫히는 이유를 이해할 보조 렌즈는 된다. 시청자는 사실뿐 아니라 공유할 감정과 자기 태도를 함께 받는다. 투표와 채팅은 이 흐름을 더 선명하게 만든다. 겉으로는 상호작용이지만 영상 안에서 시청자의 답은 증거를 추가하거나 결론을 바꾸지 못한다. 첫 투표는 무지의 기록이 되고, 마지막 투표는 진행자의 설명이 성공했다는 장면이 된다. 시청자는 참여했지만 논증의 공동 저자가 아니다. Hugo Mercier와 Sperber의 [논증적 추론 이론](https://doi.org/10.1017/S0140525X10000968?ref=zerodraftlab.com)은 중요한 반대편을 보여준다. 사람은 혼자 자기 입장을 방어할 때 편향될 수 있지만, 타인의 논증을 실제로 평가하고 반박받는 환경에서는 더 나은 추론을 할 수 있다. 투표가 토론이 되려면 진행자의 주장도 화면 안에서 패배할 수 있어야 한다. 시청자가 새로운 증거를 넣고, 강한 반론이 결론을 수정하며, 불확실성이 끝까지 살아남아야 한다. 정답을 미리 가진 사람이 오답을 수집하는 장면은 그 조건과 다르다. ## 좋은 해설은 결론보다 검증 경로를 남긴다 모든 반전형 설명을 권위 연출로 부르면 반대 방향으로 틀린다. 설명자는 자료를 선택할 수밖에 없고, 복잡한 사건을 이해시키려면 순서와 긴장이 필요하다. 핫커피 영상처럼 잘못 알려진 사실을 복원하는 작업은 분명한 가치가 있다. 시청자가 모든 재판기록과 논문을 처음부터 읽어야만 배울 수 있다면 전문 해설은 존재할 이유가 없다. 경계는 편집 기술이 아니라 검증 가능성에 있다. 좋은 해설은 결론을 강하게 말하면서도 독자가 그 결론에서 빠져나갈 문을 남긴다. 핵심 출처를 영상의 장식이 아니라 실제 접근 가능한 경로로 제공한다. 원 기록이 없고 당사자 요약만 있는 대목, 자료끼리 숫자가 어긋나는 대목, 조사해도 확인하지 못한 대목을 구분한다. 상대 주장을 우스운 통념으로만 재현하지 않고, 결론을 위협할 만큼 강한 형태로 남겨둔다. 핫커피 사건이라면 현재 맥도날드 전국 매뉴얼의 온도가 실제로 낮아졌는지는 미확인으로 두어야 한다. 700건은 \`700건의 신고·청구\`이지 모두 같은 수준의 중화상이나 700건의 재판이 아니라고 말해야 한다. 당시 업계 관행과 뜨거운 커피의 품질을 둘러싼 맥도날드 측 논증도, 배심이 결국 받아들이지 않았다는 결과와 함께 보여줄 수 있다. 반대편을 충분히 설명하는 것은 양쪽이 똑같이 옳다고 만드는 일이 아니다. 판정이 무엇을 이겼는지 보존하는 일이다. 가장 간단한 판별법은 영상을 본 뒤 진행자를 지우는 것이다. 시청자가 핵심 출처를 열 수 있는가. 사실, 해석, 교훈을 분리할 수 있는가. 가장 강한 반론과 남은 불확실성을 말할 수 있는가. 새로운 증거가 나오면 어느 결론을 바꿔야 하는지 아는가. 가능하다면 설명은 판단 능력을 이전한 것이다. 불가능하고 \`그 사람이 조사했으니 맞다\`만 남는다면 설명은 판단을 대행한 것이다. 회의주의는 모든 말을 의심하는 표정이 아니다. 믿음을 바꿀 조건을 스스로 가지고 있는 상태다. 짧은 통념을 긴 반전으로 교체하는 것만으로는 그 조건이 생기지 않는다. 틀린 권위를 밀어내고 더 매력적인 권위를 세웠을 수도 있다. 통념을 깨주는 사람은 유익하다. 그러나 그 사람이 없으면 다음 통념을 깰 수 없게 되는 순간, 회의주의는 능력이 아니라 구독 서비스가 된다. 의심의 결과는 빌릴 수 있어도 의심하는 역할까지 넘기면, 회의주의를 대신해주는 사람이 새로운 권위가 된다. --- 표본과 출처 경계: 2026-08-08 현재 알간지 최근 공개 업로드 12편을 확인했고, 외부 주제 제작형 롱폼 9편 가운데 7편에서 다섯 장치 중 네 개 이상을 관찰했습니다. 이는 최근 표본의 형식 코딩이며 채널 전체, 제작 의도, 개별 시청자의 실제 심리를 증명하지 않습니다. 주요 참고: William Haltom 외, [Java Jive: Genealogy of a Juridical Icon](https://lawcat.berkeley.edu/record/1117858/files/fulltext.pdf?ref=zerodraftlab.com); Dan Sperber 외, [Epistemic Vigilance](https://doi.org/10.1111/j.1468-0017.2010.01394.x?ref=zerodraftlab.com); Hugo Mercier·Dan Sperber, [Why do humans reason?](https://doi.org/10.1017/S0140525X10000968?ref=zerodraftlab.com); Rolf Reber·Christian Unkelbach, [The Epistemic Status of Processing Fluency as Source for Judgments of Truth](https://doi.org/10.1007/s13164-010-0039-7?ref=zerodraftlab.com); Leonid Rozenblit·Frank Keil, [The misunderstood limits of folk science](https://doi.org/10.1207/S15516709COG2605%5F1?ref=zerodraftlab.com); Melanie Green·Timothy Brock, [The Role of Transportation in the Persuasiveness of Public Narratives](https://doi.org/10.1037/0022-3514.79.5.701?ref=zerodraftlab.com); William Brady 외, [Emotion shapes the diffusion of moralized content in social networks](https://doi.org/10.1073/pnas.1618923114?ref=zerodraftlab.com). ### 빼기는 취향이 아니라 자격 진술이다 URL: https://zerodraftlab.com/subtraction-is-qualification/ Last updated: 2026-09-15T08:35:12.000Z 1인 개발자 커뮤니티에는 요즘 같은 형태의 무용담이 돈다. 무언가를 덜어냈더니 팔리기 시작했다는 이야기다. 기능을 줄였다, 요금제를 없앴다, 계정 가입을 없앴다. 만드는 비용이 거의 0에 수렴한 시대에 차별화는 더하기가 아니라 빼기에서 나온다는 결론이 뒤따른다. 가장 많이 인용된 사례부터 원문을 읽어보는 편이 낫다. 소규모 부동산 관리 회사를 상대로 B2B 도구를 파는 개발자가 [월 매출 7,000달러 언저리에서 중간 요금제를 없앤 기록](https://www.reddit.com/r/SaaS/comments/1utsg7s/i%5Fkilled%5Fmy%5F99%5Fplan%5Fand%5Frevenue%5Fwent%5Fup%5F22%5Fbuyers/?ref=zerodraftlab.com)을 남겼다. 1년 동안 29달러, 99달러, 199달러 세 단계를 운영했고 99달러에 "추천" 배지까지 붙였지만 그 칸만 비어 있었다. 가격이 잘못됐거나 기능 구성이 틀렸다고 보고 주말을 들여 다시 잘라봤지만 중간은 여전히 무덤이었다. 그가 찾은 답은 해지 사유 메모에 있었다. 반복해서 나온 문장은 "너무 비싸다"가 아니라 "본전을 뽑고 있는지 확신이 안 섰다"였다. 99달러를 내면서 자기가 잘못된 칸을 골랐을지 모른다고 조용히 걱정하고 있었다는 것이다. 그는 중간을 지웠고, 두 달 뒤 매출이 22% 올랐다고 적었다. ## 같은 글의 최상단 댓글이 그 인과를 무너뜨린다 그런데 그는 중간만 지운 것이 아니다. 남은 두 단계를 29달러와 199달러가 아니라 *39달러*와 199달러로 바꿨다. 가장 많은 추천을 받은 댓글이 정확히 그 지점을 짚었다. 진입 가격을 34% 올려놓고 매출이 22% 오른 것을 중간 티어 제거의 효과라고 부를 수는 없다. 변수 두 개가 같은 시점에 움직였고, 둘을 분리한 관측은 존재하지 않는다. 이 구조는 낯설지 않다. 어떤 조치 다음에 좋은 숫자가 왔다는 관찰과, 그 조치가 없었다면 그 숫자가 오지 않았을 것이라는 주장은 다른 층위의 명제다. 무용담은 거의 언제나 앞의 것을 말하면서 뒤의 것으로 읽힌다. 그렇다면 "선택지를 줄이면 더 팔린다"는 명제 자체는 어떤가. 이건 실무자 일화가 아니라 실제로 통제된 실험이 있는 주제다. ## 24종은 발길을 더 끌었고, 구매는 10분의 1로 무너졌다 Sheena Iyengar와 Mark Lepper가 [2000년 *Journal of Personality and Social Psychology*에 실은 실험](https://doi.org/10.1037/0022-3514.79.6.995?ref=zerodraftlab.com)은 고급 식료품점에 잼 시식대를 차렸다. 한 조건에는 6종, 다른 조건에는 24종을 진열하고 시간대를 교차 배치했다. 시식한 사람에게는 1달러 할인 쿠폰을 줬고, 실제 구매는 매장 계산대에서 일어났다. 먼저 관심 지표를 보면 많은 쪽이 이겼다. 24종 진열대를 지나간 242명 중 60%인 145명이 걸음을 멈췄다. 6종 쪽은 260명 중 40%인 104명이었다. 통계적으로도 분명한 차이였다. 다양성은 실제로 사람을 더 끌어당겼다. 구매는 반대로 갔다. 6종 조건에서 멈춰 선 사람의 30%인 31명이 잼을 샀다. 24종 조건에서는 3%인 4명이 샀다. 시식한 종류의 수는 두 조건이 사실상 같았다. 1.38종과 1.50종으로, 24종을 본 사람이 더 많이 맛보지도 않았다. 더 많이 보여준 진열대는 더 많은 사람을 세워놓고 더 적게 팔았다. 두 번째 연구는 교실에서 같은 구조를 확인했다. 추가 점수를 주는 선택 과제의 주제를 6개로 준 반은 74%가 제출했고, 30개로 준 반은 60%가 제출했다. 제출된 글의 평가 점수도 6개 조건이 더 높았다. 여기까지만 보면 무용담이 실험으로 뒷받침되는 것처럼 보인다. 문제는 이 실험이 잘 재현되지 않는다는 것이다. ## 50개 실험을 모으면 평균 효과가 0으로 사라진다 Benjamin Scheibehenne, Rainer Greifeneder, Peter Todd는 [출판·미출판 실험 50건에서 63개 조건, 총 5,036명의 데이터를 모아 메타분석](https://doi.org/10.1086/651235?ref=zerodraftlab.com)했다. 결과는 평균 효과크기가 사실상 0이었다. 강한 선택 과부하를 관측한 연구도 있었지만, 효과가 없거나 오히려 선택지가 많을수록 결정과 만족이 나아진 연구도 그만큼 있었다. 연구 간 분산만 컸다. 즉 "적을수록 팔린다"는 법칙이 아니다. 조건에 따라 부호가 뒤집히는 현상이다. 그런데도 실무자들은 계속 같은 종류의 경험을 보고한다. 법칙이 아닌 것을 두고 사람들이 반복해서 같은 것을 목격하고 있다면, 그들이 실제로 본 것이 무엇인지 다시 물어야 한다. 잼 실험에서 가장 잘 재현되는 부분은 효과의 방향이 아니라 **두 지표가 갈라졌다는 사실**이다. 같은 조작이 관심 지표는 60%로 끌어올리고 구매 지표는 3%로 떨어뜨렸다. 하나의 변경이 잘 보이는 숫자와 돈이 되는 숫자를 반대 방향으로 밀었다. 덜어냈더니 팔렸다고 말하는 사람들이 실제로 관측한 것은 대개 이 분리다. 기능 목록이 길수록 랜딩 페이지는 그럴듯해 보이고 클릭은 늘어난다. 요금제가 세 개일 때 가격표는 더 성숙해 보인다. 그렇게 좋아지는 것은 전부 결제 이전의 숫자다. 빼기가 효과를 낸 사례들은 개수를 줄여서 이긴 것이 아니라, 늘려서 얻고 있던 것이 애초에 매출이 아니었다는 사실을 드러낸 것에 가깝다. 그러면 남는 질문은 하나다. 무엇을 빼야 하는지는 무엇으로 판단하는가. 기준은 개수가 아니라 자격이다. 빼기가 작동한 사례들을 나란히 놓으면, 줄어든 것은 항상 선택지의 수가 아니라 *누구를 위한 물건인지를 흐리게 하던 것*이었다. ## 제품을 한 줄도 바꾸지 않고 팔리기 시작한 경우 YouTube 창작자용 도구를 1년 동안 만든 개발자가 [가장 좋았던 마케팅 결정은 AI를 파는 것을 그만둔 것이었다고 적었다](https://www.reddit.com/r/indiehackers/comments/1uwfmxp/i%5Fspent%5Fa%5Fyear%5Fbuilding%5Fan%5Fai%5Fproduct%5Fthe%5Fbest/?ref=zerodraftlab.com). 그전까지 그의 소개는 기능 나열이었다. 트렌드 조사, 이상치 탐지, 영상 해부, 비트 시트, 썸네일 분석, 발행 전 검토, MCP 연동. 전부 사실이었고 전부 작동했다. 그가 다시 읽어보고 내린 판단은 그 목록이 "탭이 일곱 개 달린 또 하나의 AI 도구함"으로 읽힌다는 것이었다. 그래서 문장을 바꿨다. **창작자는 이제 그 어느 때보다 빠르게 콘텐츠를 만들 수 있지만, 다음 한 주를 어떤 아이디어에 써야 하는지는 여전히 모른다.** 제품은 그대로였다. 바뀐 것은 프레이밍뿐이었다. 그가 정리한 표현으로는, 그동안 엔진을 팔고 있었지만 실제 가치는 잘못된 영상을 만들지 않게 해주는 데 있었다. 여기서 빠진 것은 기능이 아니다. 일곱 개의 기능은 지금도 전부 있다. 빠진 것은 *이 물건이 누구의 어떤 순간을 위한 것인지*를 가리고 있던 목록이다. 목록은 무엇 하나 틀리지 않았기 때문에 더 위험했다. 틀린 문장은 반박당하지만, 전부 맞는데 초점이 없는 문장은 그냥 읽히지 않는다. ## 실격 조건을 첫 줄에 두면 클릭은 반드시 나빠진다 더 선명한 사례는 macOS 전용 도구를 만든 개발자의 기록이다. 그는 [가장 중요한 자격 단어 하나를 묻어두고 몇 주를 잘못된 사용자에게 썼다](https://www.reddit.com/r/indiehackers/comments/1v5t3hb/i%5Fburied%5Fthe%5Fsingle%5Fmost%5Fimportant%5Fqualifying/?ref=zerodraftlab.com). 소개는 문제와 해법으로 시작했고 플랫폼 제약은 뒤쪽에, 찾아봐야 보이는 자리에 있었다. 가치를 앞세우고 한계를 앞에 두지 말라는 통상의 조언 그대로였다. 그가 관찰한 것은 관심을 보이고 눌러 들어온 다음 벽에 부딪히는 사람들의 반복된 실망이었다. 전부 피할 수 있었던 실망이고, 단어 하나의 위치가 만든 실망이었다. 그의 재정의는 이렇다. "Mac 전용"은 숨겨야 할 한계가 아니라 공짜로 걸러주는 자격 조건이다. 일찍 튕겨 나간 Windows 사용자는 그가 실망시키지 않은 사람이고, 항의 댓글을 받지 않은 사람이고, 사과할 필요가 없던 사람이다. 늦게 말하는 것은 그들을 얻는 것이 아니라 알게 되는 시점을 더 나쁜 자리로 미루는 것이다. 그가 스스로 인정한 부분이 더 중요하다. 자격 조건을 숨긴 것은 마케팅 감각으로 포장된 작은 부정직이었고, 자기는 적합도 대신 클릭을 최적화하고 있었다는 것이다. 살 수 없는 사람에게서 나온 클릭은 *보기 좋은 숫자로 포장한 실망 제조*다. 이 문장은 잼 실험의 60%를 정확히 설명한다. 24종 진열대 앞에 멈춰 선 145명은 실패가 아니라 비용이었다. 그들을 세우는 데 든 진열 공간과 응대 시간은 실재했고, 그중 4명만 샀다. 자격을 앞으로 당기는 모든 조치는 관심 지표를 반드시 악화시킨다. 그것이 부작용이 아니라 작동 원리다. 중간 요금제 사례도 이 틀에서 다시 읽힌다. 진입가 인상이라는 교란 변수 때문에 22%는 인과로 쓸 수 없지만, 함께 보고된 부수 관찰 하나는 가격 인상으로 설명되지 않는다. "내가 맞는 요금제에 있는 게 맞나요"라는 문의가 크게 줄었다는 것이다. 해지 메모의 문장이 "비싸다"가 아니라 "확신이 안 선다"였던 것과 같은 자리를 가리킨다. 중간 칸의 문제는 가격도 기능 구성도 아니었고, 고객이 *자기가 그 칸에 해당하는 사람인지 스스로 판정할 수 없었다*는 데 있었다. 자격을 만들지 못하는 선택지는 성과가 낮은 선택지가 아니라 해로운 선택지다. ## 그런데 청중이 사람이 아니면 규칙이 뒤집힌다 빼기를 원칙으로 승격시키면 곧바로 반례에 부딪힌다. 5개월 동안 자동화 없이 손으로 220개가 넘는 디렉토리에 제품을 등록한 사람이 [그 분포를 정리해 올렸다](https://www.reddit.com/r/indiehackers/comments/1vdlnb1/ive%5Fmanually%5Fsubmitted%5Fstartups%5Fto%5F220/?ref=zerodraftlab.com). 실제로 사람을 보내는 곳은 약 15개다. Product Hunt, BetaList, G2, Capterra, AlternativeTo, SaaSHub, Crunchbase, 그리고 Indie Hackers 정도. 예산이 없으면 주말 두 번으로 이 15개만 해도 업사이드 대부분을 가져간다. 다음 60개가량은 아무도 보내지 않지만 회사를 실재하게 보이도록 만든다. 누군가 "우리 제품 대안"을 검색했을 때 결과에 등장하는 이유가 이 층이다. 나머지 145개는 그의 표현으로 링크 농장이다. 방문자는 없다. 백링크의 SEO 가치도 사실상 없다. 그가 굳이 못 박은 대로 이 백링크들은 거의 전부 nofollow이고, 디렉토리 등록으로 도메인 지표가 오른다고 파는 쪽은 한물갔거나 상대가 모르기를 바라는 쪽이다. 그런데도 그가 계속 관측하는 현상이 있다. 겹치는 리스팅에 충분히 여러 번 등장하고 나면 제품이 ChatGPT와 Perplexity에 인용되기 시작한다는 것이다. 모델이 그 중복을 "확립된 회사"라는 신호로 읽는 것 같다는 게 그의 해석이고, 그는 이것을 그해 배운 것 중 가장 흥미롭지만 냉소적인 사실이라고 적었다. 이 사람은 그 작업을 대행하는 서비스를 직접 운영한다고 같은 글에서 밝혔으므로, 145개 꼬리의 가치를 크게 부를 유인이 있다는 점은 감안해야 한다. 다만 그가 스스로 던진 질문이 그 유인과 반대 방향이라는 점은 기록해둘 만하다. 그는 목록을 70개로 줄이고 값을 낮춰야 하는 것 아니냐고 물었고, 자기는 줄이는 쪽으로 기운다고 썼다. 여기서 나오는 것은 개수의 문제가 아니라 청중의 비대칭이다. **사람의 주의는 빼기로 얻고, 기계의 인용은 더하기로 얻는다.** 사람 앞에서 중복은 소음이지만, 언어 모델 앞에서 중복은 근거다. 사람에게는 하나의 명확한 자격 문장이 필요하고, 모델에게는 여러 출처에 걸친 반복된 언급이 필요하다. 두 청중을 같은 규칙으로 상대하면 한쪽은 반드시 손해를 본다. 실무에서 이 둘이 충돌하는 지점은 대개 하나다. 사람이 읽는 면은 좁히고, 기계가 읽는 면은 넓힌다. ## 뺀 것의 청구서는 나중에 온다 마지막 경계는 비용의 시점이다. 구독 피로에 역베팅해서 [HTML 파일 하나짜리 도구를 9달러 단발로 파는 개발자](https://www.reddit.com/r/indiehackers/comments/1v2gz20/betting%5Fon%5Fsubscription%5Ffatigue%5Fi%5Fsell%5Fonefile/?ref=zerodraftlab.com)가 있다. 계정도 백엔드도 없고 브라우저 안에서만 돌아가며 localStorage에 저장하고 PDF로 내보낸다. 서버 비용이 0이라 한계비용이 0이고, 그래서 "한 번 사서 영원히 소유"가 성립한다. 인보이스 생성기, 견적서, 용역계약서, 프리랜서 시간 기록기, 포지션 계산기 다섯 개를 각각 9달러에 판다. 같은 모델을 15달러 단발로 운영 중인 다른 개발자의 댓글이 이 구조의 진짜 비용을 지적했다. 단발 판매가 앗아가는 것은 반복 매출이 아니라 *확인 시점*이다. 구독자는 해지 버튼을 누르면서 무언가를 알려준다. 한 번 사고 간 사람은 조용히 사라지고, 8개월 뒤에 뭔가 고장 나면 여전히 무상 지원을 기대한다. 자기 머릿속에서는 평생분을 이미 한 번에 지불했기 때문이다. 그러니 단발 가격은 이탈률이 아니라 *만료일 없는 지원*을 예산에 잡아야 한다. 다른 댓글은 성립 조건을 더 좁혔다. 사용할 때마다 비용이 발생하는 제품이라면 정액 평생가는 헤비 유저 한 명으로 적자가 난다. 그 사람은 유료 AI 서비스를 호출하는 모바일 앱을 운영하면서 무료 구간, 1회 평생 해제, 그리고 파워 유저가 자기 API 키를 넣어 비용을 스스로 부담하는 선택지를 조합해 대응하고 있었다. 즉 백엔드를 없앤 것이 이긴 게 아니라, 백엔드를 없앨 수 있는 종류의 제품이었던 것이 이긴 것이다. ## 빼기는 취향이 아니라 진술이다 정리하면 세 가지가 남는다. 첫째, 무언가를 없앴더니 매출이 올랐다는 보고는 대부분 다른 변경과 함께 일어나며, 그 자체로는 인과가 아니다. 둘째, 그럼에도 반복해서 관측되는 것은 선택지를 늘릴 때 관심 지표와 구매 지표가 반대로 움직인다는 사실이고, 이것이 빼기의 실제 효용이 앉아 있는 자리다. 셋째, 빼기가 작동할 때 실제로 제거된 것은 개수가 아니라 자격을 흐리던 것이며, 자격을 앞으로 당기면 잘 보이는 숫자는 반드시 나빠진다. 그래서 이 결정은 미적 취향이 아니다. 자기 제품이 누구를 위한 것이 아닌지를 문장으로 적고, 그 문장 때문에 줄어드는 방문자 수를 감수하겠다는 진술이다. 조직이 그 하락을 성과 저하가 아니라 비용 절감으로 읽지 못하면 이 거래는 성립하지 않는다. 광고를 껐는데 매출이 그대로일 때와 같은 종류의 해석 문제이고, 대개 데이터보다 이 해석에서 먼저 무너진다. 가장 먼저 손볼 자리는 대체로 정해져 있다. 제품 소개의 첫 줄에서, 이 물건을 쓸 수 없는 사람이 그 사실을 알아차리기까지 걸리는 시간이다. --- 주요 출처: Sheena S. Iyengar, Mark R. Lepper, [When Choice Is Demotivating: Can One Desire Too Much of a Good Thing?](https://doi.org/10.1037/0022-3514.79.6.995?ref=zerodraftlab.com), *Journal of Personality and Social Psychology* 79(6), 2000, 995–1006; Benjamin Scheibehenne, Rainer Greifeneder, Peter M. Todd, [Can There Ever Be Too Many Options? A Meta-Analytic Review of Choice Overload](https://doi.org/10.1086/651235?ref=zerodraftlab.com), *Journal of Consumer Research* 37(3), 2010, 409–425\. 실무 사례는 2026년 7\~8월 r/SaaS와 r/indiehackers에 공개된 개별 운영자의 자기 보고이며, 통제된 실험이 아니라 단일 사업체의 관측이다. 디렉토리 사례의 작성자는 해당 대행 서비스를 운영한다고 같은 글에서 밝혔다. 인용한 금액과 비율은 각 작성자가 보고한 시점의 값이다. ### 귀속된 매출은 증분이 아니다 URL: https://zerodraftlab.com/attribution-is-not-incrementality/ Last updated: 2026-09-15T08:35:13.000Z 광고 리포트의 마지막 줄에는 대개 이런 숫자가 있다. “이 캠페인이 만든 매출 3억.” 그 숫자는 광고를 클릭한 사람이 그 뒤에 결제한 금액의 합계다. 클릭이 결제를 만들었다는 증거는 아니다. 둘의 차이를 실제로 재본 회사가 있다. eBay는 2012년 3월 자사 브랜드가 들어간 검색어, 그러니까 “ebay”가 포함된 모든 쿼리의 검색광고를 Yahoo!와 MSN에서 전면 중단했다. Google에서는 계속 집행해 계절성 대조군으로 삼았다. 유료 클릭은 0으로 떨어졌고 자연검색 클릭이 그만큼 올라왔다. [Thomas Blake, Chris Nosko, Steven Tadelis의 Econometrica 논문](https://doi.org/10.3982/ECTA12423?ref=zerodraftlab.com)에 그 결과가 정리돼 있다. 광고를 끄면서 포기한 클릭 트래픽의 99.5%가 자연검색으로 즉시 흡수됐다. 계절성을 보정한 뒤 실제로 사라진 클릭은 0.529%였다. 브랜드 검색광고에 귀속돼 있던 매출의 거의 전부가 광고 없이도 발생할 매출이었다는 뜻이다. 브랜드 검색어라 당연한 결과라고 볼 수도 있다. 그래서 같은 팀은 브랜드어를 뺀 나머지 키워드로 다시 실험했다. 미국 210개 시장권역(DMA) 가운데 68곳에서 60일 동안 비브랜드 키워드 입찰을 전부 멈추고, 사전 매출 추세가 맞춰진 대조 권역과 비교했다. 유료검색 체제 전체가 매출에 더한 몫은 0.66%, 95% 신뢰구간은 -0.42%에서 1.74%였다. 0을 포함한다. ## 같은 데이터가 4,173%와 -63%를 동시에 말한다 같은 논문에서 더 중요한 것은 실험값 자체가 아니라 관측값과의 거리다. 실험 이전 기간의 데이터로 매출을 광고비에 회귀시키면 투자수익률이 4,173%로 나온다. 지역과 날짜 고정효과를 넣어도 1,632%다. 실험이 만든 변동만 사용하면 같은 기간, 같은 회사의 수익률은 -63%가 된다. 95% 신뢰구간은 -124%에서 -3%로, 단기 양의 수익 가설이 기각된다. 이 격차는 측정 오차가 아니라 구조에서 나온다. 검색광고비는 클릭이 발생할 때만 지출된다. 클릭은 살 마음이 있는 사람이 한다. 그래서 광고비가 많이 나간 구간은 원래 구매 의도가 높았던 구간이다. 지출과 매출이 함께 움직이는 것은 광고가 매출을 만들어서가 아니라, 둘 다 같은 원인의 결과이기 때문이다. 이것이 검색광고만의 문제였다면 다른 채널로 피하면 된다. 그렇지 않다. Facebook에서 실행된 15건의 무작위 통제실험을 분석한 [Brett Gordon, Florian Zettelmeyer, Neha Bhargava, Dan Chapsky의 연구](https://doi.org/10.1287/mksc.2018.1135?ref=zerodraftlab.com)는 5억 건의 사용자-실험 관측치와 16억 회 노출을 놓고 실험 결과와 관측 기반 추정치를 나란히 비교했다. 일반적으로 관측 방법은 광고 효과를 과대추정했고, 절반의 연구에서 구매 성과의 추정 증가율이 실제값과 세 배 어긋났다. 광고주가 통상 확보할 수 있는 수준을 훨씬 넘는 개인 단위 변수를 통제한 뒤의 결과다. 귀속과 증분은 다른 질문에 답한다. 귀속은 구매 직전에 무엇이 있었는지를 기록한다. 증분은 그것이 없었다면 어땠을지를 묻는다. 대시보드는 앞의 질문만 답할 수 있고, 예산 결정은 뒤의 질문에 달려 있다. 그렇다면 귀속 숫자를 버리고 무엇을 믿어야 하나. 답은 더 정교한 귀속 모델이 아니다. 그 방향은 이미 대규모로 시험됐고 실패했다. ## 데이터를 늘려도 관측 모형은 실험을 복원하지 못한다 Gordon과 Robert Moakler, Zettelmeyer는 [663건의 대규모 실험](https://doi.org/10.1287/mksc.2022.1413?ref=zerodraftlab.com)으로 앞의 연구를 확장했다. 사용자 단위 변수를 5,000개 이상 확보하고, 이중 강건 기계학습(DML)과 층화 성향점수 매칭(SPSM)을 붙였다. DML이 SPSM보다는 나았지만 어느 쪽도 실험값을 제대로 복원하지 못했다. 실패의 원인은 알고리즘이다. 광고 플랫폼은 전환할 확률이 높은 사람에게 노출을 몰아준다. 노출 여부 자체가 결과의 예측치가 되도록 최적화된다는 뜻이다. 관측 모형이 통제해야 할 결정적 변수는 플랫폼 내부의 예측 점수인데, 그 점수는 광고주 데이터에 존재하지 않는다. Gordon 팀은 이 지점을 사고실험으로 정량화했다. 관측 추정치의 편향을 없애줄 가상의 미관측 변수를 시뮬레이션하고 그 설명력을 실제 관측 변수 전체의 설명력과 비교했더니, 일부 연구에서는 보유한 변수 전부를 합친 것보다 설명력이 큰 변수를 추가로 확보해야 실험값에 도달했다. 타깃팅이 정교해질수록 이 요구는 커진다. 즉 측정 기술의 발전이 문제를 완화하는 게 아니라 악화시킨다. ## 실험은 정답이지만 공짜는 아니다 그렇다고 모든 지출을 실험으로 검증하라는 결론은 성립하지 않는다. Randall Lewis와 Justin Rao는 [25건의 대형 광고 실험](https://doi.org/10.1093/qje/qjv023?ref=zerodraftlab.com)을 모아 그 한계를 계산했다. 총 280만 달러의 광고비가 투입된 실험들에서 투자수익률 신뢰구간의 폭은 중앙값 기준 100%p를 넘었다. 개인의 구매 금액이 광고비 대비 워낙 변동이 커서, 변동계수 10이 흔하게 관측된다. 의미 있는 정밀도를 얻으려면 1,000만 person-week 규모가 필요해지는 경우가 나온다. 여기서 나오는 결론은 “실험을 항상 하라”가 아니라 “실험을 아무 데나 쓰지 말라”다. 소재 A와 B 중 무엇이 나은지는 실험으로 답하기에 너무 비싼 질문일 때가 많다. 반대로 “이 채널 전체를 유지할 것인가”는 효과 크기가 크고 결정의 금액도 커서 실험이 성립한다. eBay가 검증한 것도 소재가 아니라 채널의 존재 여부였다. ## “광고가 무용하다”는 반대 방향의 오독이다 eBay 결과를 모든 회사에 옮기면 틀린다. 같은 논문의 이질성 분석이 그 경계를 보여준다. 광고 효과는 이전 1년간 구매 이력이 없는 사용자에게서 가장 컸고, 구매 빈도가 올라갈수록 빠르게 0에 수렴했다. 문제는 광고비 대부분이 후자, 즉 이미 eBay를 알고 이미 사던 사람들에게 지출됐다는 점이다. 평균 수익률이 음수가 된 이유가 여기 있다. 채널이 무력한 것이 아니라, 이미 아는 사람에게 다시 알리는 데 돈이 흘러간 것이다. 그래서 이 연구는 광고 무용론이 아니라 정보 제공 관점의 근거로 읽힌다. 아직 그 브랜드를 모르는 사람에게 존재를 알릴 때 광고는 작동한다. 반대로 대부분의 잠재 고객이 이미 이름을 아는 브랜드에서는, 특히 브랜드 검색어에서는 지출의 상당 부분이 이미 오기로 한 사람을 가로채는 데 쓰인다. 자기 회사가 어느 쪽인지에 따라 같은 채널의 판단이 갈린다. 브랜드 키워드를 방어 목적으로 산다는 반론도 여기서 검증 대상이 된다. 경쟁사가 우리 브랜드어에 입찰하는 상황은 eBay 실험 기간에도 존재했고, 그 조건에서도 99.5%가 회수됐다. 다만 자연검색 결과에서 자사 페이지가 최상단이 아니거나, 브랜드어에 실제로 경쟁 입찰이 붙는 카테고리라면 결과는 달라질 수 있다. 확인 방법은 논쟁이 아니라 같은 절차다. 기간과 지역을 나눠 껐다 켜보고 매출 차이를 본다. ## 예산 단위를 끌 수 있는 단위로 바꾸는 일 실무에서 이 결론이 요구하는 변화는 도구가 아니라 예산 구조에 있다. 대부분의 광고 계정은 “끌 수 없는 단위”로 짜여 있다. 전국 단일 캠페인, 상시 집행, 성과는 플랫폼 귀속으로 정산. 이 구조에서는 증분을 측정할 여지가 애초에 없다. eBay 실험이 가능했던 이유는 지역 단위 입찰로 트래픽의 30%를 떼어낼 수 있었기 때문이다. 그러니 순서는 반대가 된다. 측정 방법을 고르기 전에, 끌 수 있는 경계를 먼저 만든다. 지역, 시간대, 청중 세그먼트 중 무엇이든 일정 비율을 상시 홀드아웃으로 남기면 그 자체가 상시 측정 장치가 된다. 그 위에서 귀속 숫자는 예산 근거에서 운영 신호로 강등된다. 어떤 소재와 키워드가 반응을 얻는지 보는 데는 여전히 유용하고, 채널에 얼마를 쓸지 결정하는 데는 쓰지 않는다. 이 전환에서 가장 먼저 부딪히는 것은 데이터가 아니라 조직의 손익 감각이다. 광고를 껐는데 매출이 그대로면 담당자는 성과를 잃은 것처럼 보인다. 실제로는 같은 매출을 더 적은 비용으로 만든 것이고, 그 지출이 어디로 옮겨가야 하는지 알아낸 것이다. 이 해석을 조직이 공유하지 못하면 어떤 실험 설계도 오래 살아남지 못한다. 시작점은 대체로 명확하다. 자사 브랜드 키워드다. 클릭당 비용이 가장 낮아 효율 지표가 가장 좋아 보이고, 귀속 매출이 가장 크게 잡히며, 증분이 가장 적을 가능성이 높은 지출이 같은 자리에 있다. --- 주요 출처: Thomas Blake, Chris Nosko, Steven Tadelis, [Consumer Heterogeneity and Paid Search Effectiveness: A Large-Scale Field Experiment](https://doi.org/10.3982/ECTA12423?ref=zerodraftlab.com), Econometrica 83(1), 2015([NBER Working Paper 20171](https://www.nber.org/papers/w20171?ref=zerodraftlab.com)); Brett R. Gordon, Florian Zettelmeyer, Neha Bhargava, Dan Chapsky, [A Comparison of Approaches to Advertising Measurement: Evidence from Big Field Experiments at Facebook](https://doi.org/10.1287/mksc.2018.1135?ref=zerodraftlab.com), Marketing Science 38(2), 2019; Brett R. Gordon, Robert Moakler, Florian Zettelmeyer, [Close Enough? A Large-Scale Exploration of Non-Experimental Approaches to Advertising Measurement](https://doi.org/10.1287/mksc.2022.1413?ref=zerodraftlab.com), Marketing Science 42(4), 2023; Randall A. Lewis, Justin M. Rao, [The Unfavorable Economics of Measuring the Returns to Advertising](https://doi.org/10.1093/qje/qjv023?ref=zerodraftlab.com), Quarterly Journal of Economics 130(4), 2015\. 인용한 수치는 각 논문이 보고한 해당 실험의 값이며, 다른 브랜드와 기간에 그대로 적용되는 상수가 아니다. ### 바이럴 루프의 백엔드는 계보다 URL: https://zerodraftlab.com/viral-loops-need-lineage/ Last updated: 2026-09-15T08:35:14.000Z 제품에 바이럴 루프를 넣자는 말이 나오면 대개 공유 버튼부터 그린다. 카카오톡, 이메일, 링크 복사 버튼을 붙이고 친구를 데려오면 크레딧을 주는 규칙을 만든다. 리퍼럴 SaaS를 고른 뒤에는 바이럴 기능이 생겼다고 말한다. 이 장치들은 결과를 운반하거나 보상을 정산한다. 그러나 수신자가 왜 링크를 열어야 하는지는 만들지 못한다. 광고 문구가 붙은 추천 링크는 여전히 광고다. 친구가 보냈다는 사실만으로 수신자가 새 소프트웨어를 배워야 할 이유는 생기지 않는다. 이미 완성된 결과물이 제품 안에서 전파 경로를 만든다. [Typeform](https://help.typeform.com/hc/en-us/articles/360029262372-Remove-Typeform-branding?ref=zerodraftlab.com)의 응답자는 누군가 만든 설문을 먼저 사용하고, 제출 뒤에야 ‘Create a typeform’을 본다. [Figma Community](https://help.figma.com/hc/en-us/articles/360038510873-Find-and-Duplicate-Files-from-the-Community?ref=zerodraftlab.com)의 방문자는 파일과 프로토타입을 미리 본 뒤 독립된 사본을 만든다. [Replit](https://docs.replit.com/build/remix-an-app?ref=zerodraftlab.com)의 방문자는 공개된 앱을 작동시킨 뒤 Remix로 작동하는 독립 사본을 얻고 다시 고칠 수 있다. 세 제품에서는 사용자가 홍보물을 별도로 만들지 않아도 설문, 디자인, 앱이라는 업무 산출물이 다음 사용자의 진입점이 된다. 수신자는 설명을 읽는 대신 결과물을 먼저 사용해 본 다음 자기 결과물을 만들 수 있다. **결과물을 만드는 웹앱에서는 다음 사람도 다시 만들 수 있는 결과물이 전파 단위가 된다.** 이 차이는 조회수와 바이럴을 구분한다. [Goel과 동료들](https://pubsonline.informs.org/doi/10.1287/mnsc.2015.2158?ref=zerodraftlab.com)이 트위터의 10억 건 확산 사건을 분석했을 때 큰 도달은 깊은 사람 간 연쇄보다 한 번의 큰 방송에서 나오는 경우가 많았다. [Leskovec와 동료들](https://snap.stanford.edu/class/cs224w-readings/leskovec07viral.pdf?ref=zerodraftlab.com)이 한 온라인 소매업체의 인센티브형 프로그램에서 400만 명의 추천망을 조사했을 때도 평균적인 추천은 구매를 잘 만들지 못했고 멀리 퍼지지 않았다. 많이 공유됐다는 사실만으로 제품 안에 자기증식 회로가 생겼다고 말할 수 없다. 공개 결과물 A를 본 사람이 결과물 B를 만들고, B가 다시 C의 출발점이 될 때 비로소 세대가 생긴다. 그래서 제품은 공유 횟수보다 A와 B의 관계를 알아야 한다. 원본은 무엇이었는지, 누가 새 결과물을 만들었는지, 몇 세대째인지, 새 결과물도 다시 공개됐는지가 남아야 한다. 그렇다면 공유 뒤의 재생산을 관찰하려면 제품은 무엇을 저장해야 할까? 먼저 부모와 자식을 저장해야 한다. `public_token`과 공개·회수 상태는 링크의 수명주기를 다룬다. `parent_id`는 직접 파생을 귀속하고, `root_id`와 `generation`은 전체 계보와 세대별 확산을 빠르게 분석한다. 이 기록으로 명시적 파생은 관찰할 수 있지만 바이럴 기능의 증분 효과를 알려면 홀드아웃이나 무작위 실험이 필요하다. ## 공개 결과물과 원본 기록은 다른 객체다 공유를 위해 내부 결과를 그대로 공개하면 루프보다 사고가 먼저 난다. 진단 보고서라면 원본 입력, 이메일, 내부 권고, 모델의 원문 응답을 공개 객체에 넣지 않는다. 외부인이 봐도 되는 작은 스냅샷을 별도로 만들고, 사용자가 내용을 확인한 뒤 명시적으로 공개하게 해야 한다. 공개 링크는 회수할 수 있어야 하며 기본 상태는 비공개여야 한다. 게시된 스냅샷은 가능한 한 고정한다. 결과를 고치고 싶다면 조용히 내용을 바꾸기보다 새 버전을 발행해 무엇을 보고 파생됐는지 남기는 편이 낫다. 계보에는 어떤 결과가 새 사용을 만들었는지가 남는다. ## Rails 8에는 이 구조를 만들 부품이 이미 있다 이 정도의 루프에는 별도 성장 프레임워크가 필요하지 않다. Active Record의 자기참조 관계로 부모와 뿌리를 저장하고, `has_secure_token`으로 공개 URL을 만든다. 만료되는 미리보기나 관리 링크에는 목적과 만료시간을 붙인 `signed_id`를 쓸 수 있지만, signed ID는 암호화가 아니므로 고객 정보나 진단 내용을 담아서는 안 된다. 결과 생성은 Active Job과 Solid Queue에 맡긴다. Rails 8.1의 `ActiveJob::Continuable`은 긴 작업을 단계로 나누고 재시작 뒤 마지막 완료 지점에서 이어갈 수 있다. 생성 요청은 controller의 `rate_limit`과 일일 사용량으로 막는다. 공개 페이지는 Rails가 서버 렌더링하고, 생성 상태를 갱신할 때 Turbo Frame이나 Turbo Stream을 쓴다. 공유 버튼은 Stimulus에서 Web Share API를 호출하고 지원하지 않는 환경에서는 Clipboard로 내려가면 된다. 여기서 Web Share의 Promise가 성공했다는 사실도 전환은 아니다. 브라우저와 운영체제에 따라 공유 창을 띄운 시점이나 데이터를 대상 앱에 넘긴 시점에 완료될 수 있다. 소유자 제외, 봇 필터, 중복 제거를 통과한 열람과 자식 결과물 생성은 서버 이벤트로 관찰한다. 익명 링크만으로 의도한 수신자였는지는 알 수 없다. 라이브러리도 같은 기준으로 고른다. 방문과 UTM 귀속이 필요해지면 [Ahoy](https://github.com/ankane/ahoy?ref=zerodraftlab.com)를 붙일 수 있고, 비교 실험을 할 만큼 트래픽이 쌓이면 [Field Test](https://github.com/ankane/field%5Ftest?ref=zerodraftlab.com)를 검토할 수 있다. 공개 카드 이미지는 기존 `image_processing`과 libvips로 만들 수 있다. [Tailwind CSS 4](https://tailwindcss.com/docs/compatibility?ref=zerodraftlab.com)는 공식 문서에서 Sass와 함께 쓰도록 설계되지 않았다고 밝힌다. 바이럴 루프와 관계없는 CSS 전처리기를 관성적으로 추가하면 빌드 경로만 하나 더 생긴다. ## SaaS는 남용 방지·관찰·정산을 대신한다 [Cloudflare Turnstile](https://developers.cloudflare.com/turnstile/?ref=zerodraftlab.com)은 자동화된 생성 요청을 걸러낸다. 과다 사용은 `rate_limit`과 사용량 할당으로 제한한다. [PostHog](https://posthog.com/product-analytics?ref=zerodraftlab.com)는 반복되는 cohort와 retention 질문을 풀고, Resend나 Postmark는 이메일 전달을 맡는다. 이런 서비스는 이미 생긴 흐름을 방어하거나 관찰한다. 결과물이 파생될 이유를 대신 만들지는 않는다. 리퍼럴 SaaS는 보상, 파트너 귀속, 지급 같은 운영이 실제 병목이 됐을 때 가치가 생긴다. 아직 한 사람의 결과물이 다음 사람의 결과물을 만드는지 확인하지 못한 단계에서 붙이면 검증하지 않은 루프 위에 정산 시스템부터 올리는 셈이다. ## 박수 대신 번식을 센다 최소 이벤트는 많지 않다. 결과물 생성, 명시적 공개, 소유자를 제외하고 봇·중복을 걸러낸 외부 열람, 파생 시작, 자식 결과물 생성, 자식 결과물 공개를 서버에서 기록하면 된다. 공유 버튼 클릭은 `share_intent`라는 보조지표로 남길 수 있지만 성공 판정에 쓰지 않는다. 첫 번째 지표는 공개된 부모 하나가 일정 기간 안에 몇 개의 공개된 자식을 만들었는가다. 두 번째는 부모가 공개된 시점부터 자식이 공개될 때까지 걸린 시간이다. 반복 사용이 있는 제품이라면 자식 사용자가 다음 주기에도 핵심 행동을 했는지까지 봐야 한다. 가입이나 클릭만 세면 싸고 질 낮은 유입이 좋은 루프처럼 보인다. 처음부터 생성 과정을 전부 자동화할 필요도 없다. 사람이 만든 유료 원본은 비공개로 두고, 외부인이 즉시 이해할 수 있는 작은 공개 스냅샷만 수작업으로 만들어도 루프는 시험할 수 있다. 수신자가 “내 것도 만들어 보기”를 눌러 자식 결과물을 만들고 다시 공개하는 흐름이 확인된 뒤 생성 작업을 자동화하면 된다. Rails 8은 제품을 바이럴하게 만들지 않는다. 다만 바이럴이라는 말을 공유 버튼과 추천 코드에서 꺼내, 결과물의 부모와 자식이라는 검증 가능한 데이터로 옮기게 해준다. 첫 번째로 추가할 표는 추천인 순위표가 아니라 `parent_id`가 있는 결과물 표다. --- 주요 출처: Replit, [Remix an app](https://docs.replit.com/build/remix-an-app?ref=zerodraftlab.com); Figma, [Duplicate Community files](https://help.figma.com/hc/en-us/articles/360038510873-Find-and-Duplicate-Files-from-the-Community?ref=zerodraftlab.com); Typeform, [Remove Typeform branding](https://help.typeform.com/hc/en-us/articles/360029262372-Remove-Typeform-branding?ref=zerodraftlab.com); Sinan Aral·Dylan Walker, [Creating Social Contagion Through Viral Product Design](https://pubsonline.informs.org/doi/10.1287/mnsc.1110.1421?ref=zerodraftlab.com); Sharad Goel 외, [The Structural Virality of Online Diffusion](https://pubsonline.informs.org/doi/10.1287/mnsc.2015.2158?ref=zerodraftlab.com); Jure Leskovec 외, [The Dynamics of Viral Marketing](https://snap.stanford.edu/class/cs224w-readings/leskovec07viral.pdf?ref=zerodraftlab.com); Ruby on Rails, [Rails 8.1 Release Notes](https://guides.rubyonrails.org/8%5F1%5Frelease%5Fnotes.html?ref=zerodraftlab.com), [Signed ID](https://api.rubyonrails.org/classes/ActiveRecord/SignedId.html?ref=zerodraftlab.com), [Rate Limiting API](https://api.rubyonrails.org/v8.1.3/classes/ActionController/RateLimiting/ClassMethods.html?ref=zerodraftlab.com); MDN, [Web Share API](https://developer.mozilla.org/en-US/docs/Web/API/Navigator/share?ref=zerodraftlab.com); Tailwind CSS, [Compatibility](https://tailwindcss.com/docs/compatibility?ref=zerodraftlab.com). ‘전파 가능한 결과물’, parent/root/generation 계보, reproduction rate와 cycle time의 제품 적용은 위 사례·연구·공식 문서를 연결한 이 글의 해석이다. Rails 문서는 구현 가능성을 설명할 뿐 바이럴 성장을 보장하지 않는다. ### 바이럴에는 면역계가 있다 URL: https://zerodraftlab.com/viral-growth-meets-immunity/ Last updated: 2026-09-15T08:35:14.000Z 마케팅은 바이러스에서 번식률이라는 말을 빌려왔다. 한 사용자가 몇 명을 초대하고 그중 몇 명이 가입하는지 곱해 K-factor를 구한다. 계산식 안에서 수신자는 아직 아무 판단도 하지 않은 빈칸처럼 놓인다. 실제 감염은 그렇게 진행되지 않는다. [CDC의 감염 사슬](https://archive.cdc.gov/www%5Fcdc%5Fgov/csels/dsepd/ss1978/lesson1/section10.html?ref=zerodraftlab.com)에는 병원체, 저장소, 탈출구, 전파 방식, 침입구와 함께 ‘감수성 있는 숙주’가 들어간다. 바이러스가 세포에 부착한 뒤에도 진입, 탈각, 복제, 조립, 방출을 마쳐야 다음 감염을 만들 수 있다. [바이러스 복제 주기를 정리한 의학 교재](https://pmc.ncbi.nlm.nih.gov/articles/PMC7158351/?ref=zerodraftlab.com)도 부착만으로 생산적인 감염이 성립하지 않는다고 설명한다. 그래서 역학에는 두 재생산수가 있다. `R₀`는 개입도 면역도 없는 완전 감수성 집단을 가정한다. 현실의 `Rₜ`는 그 시점의 감수성, 행동, 연결 구조, 면역 수준과 병원체의 전파력이 함께 반영된 평균이다. [CDC](https://www.cdc.gov/cfa-modeling-and-forecasting/modeling-handbook/mh-rt.html?ref=zerodraftlab.com)가 지적하듯 현실에서 완전 감수성 집단은 드물고, 같은 병원체도 `Rₜ`는 시간에 따라 달라진다. 제품의 수신자도 빈칸이 아니다. 스팸 필터가 있고, 모르는 도메인을 경계하며, 가입벽과 연락처 권한을 의심한다. 전에 받은 형편없는 초대장은 다음 초대의 해석까지 바꾼다. 생물학적 면역과 같은 현상은 아니지만, 제품이 반복해서 만든 학습된 회피를 ‘제품의 면역 기억’이라고 부를 수는 있다. 접촉을 늘린다고 감수성이 그대로 남지도 않는다. [Edwards, Li, Lee의 강제 팝업 노출 연구](https://doi.org/10.1080/00913367.2002.10673678?ref=zerodraftlab.com)에서는 과업을 방해한다고 느낄수록 침입성 지각이 커졌고, 짜증과 광고 회피로 이어졌다. 초대 버튼을 더 자주 띄우거나 자동 메시지를 더 많이 보내면 노출량은 늘어도 수신자의 방어는 더 빨리 작동할 수 있다. **바이럴의 유효재생산수는 발신자의 전파력만으로 결정되지 않는다. 수신자가 방어할 이유보다 자기 가치를 먼저 발견해야 다음 세대가 생긴다.** 그렇다면 제품의 `Rₜ`를 올리면서도 면역 반응을 키우지 않는 루프는 어떤 순서로 설계해야 할까? 수신자는 링크가 도착한 순간부터 비용을 계산한다. 누가 보냈는지, 열어도 안전한지, 가입을 요구하는지, 자기 일과 무슨 관계가 있는지를 본다. 첫 화면이 이메일 입력창이면 제품은 가치를 복제하기 전에 경계부터 활성화한 셈이다. ## 노출과 복제 사이에는 네 번의 탈락이 있다 바이러스 복제 주기를 제품 흐름에 그대로 등치할 수는 없지만, 실패 지점을 나누는 틀로는 쓸 수 있다. 링크 도착은 부착, 공개 결과물의 안전한 열람은 진입, 수신자가 자기 결과물을 만드는 일은 복제, 그 결과물을 명시적으로 공개하는 일은 방출에 대응한다. 공개된 자식 결과물이 다시 다음 사람의 진입점이 되어야 전파가 이어진다. 링크를 열자마자 가입을 요구하면 진입에서 멈춘다. 결과물은 유용하지만 자기 버전을 만들 수 없으면 복제가 없다. 새 결과물을 만들었어도 개인정보 때문에 공개할 수 없다면 방출이 막힌다. 공유 버튼 클릭이나 초대 메일 발송은 이 네 단계 중 첫 접촉만 관찰한다. 제품팀은 각 단계의 방어 비용부터 줄여야 한다. 초대 문구를 짧게 다듬는 일보다 앞선다. 공개 페이지에는 수신자가 이해하는 데 필요한 결과만 두고 원본 입력, 이메일, 내부 메모는 제외한다. 가입 전에 결과의 가치를 확인하게 하고, 자기 버전을 만들겠다고 선택한 순간에만 계정을 요청한다. 공개는 opt-in으로 두고 링크를 회수할 수 있어야 한다. ## 제품의 면역 반응은 두 속도로 움직인다 [미국 국립일반의학연구소](https://nigms.nih.gov/biobeat/2023/12/what-is-the-immune-system?ref=zerodraftlab.com)는 선천면역을 피부와 점막 같은 장벽부터 즉시 작동하는 방어로, 적응면역을 특정 병원체를 기억해 다음 노출에 더 빠르게 반응하는 체계로 설명한다. 제품에서는 브라우저 경고, 스팸함, 모르는 발신자, 로그인벽, 연락처 접근 권한이 첫 장벽처럼 작동한다. 이전에 경험한 저품질 초대, 자동 발송, 해지하기 어려운 알림은 특정 제품이나 발신자에 대한 학습된 회피를 만든다. 여기서 비유의 한계를 지켜야 한다. 광고 회피는 항체 반응이 아니고, 사람을 감염시켜야 할 숙주로 보는 순간 제품 판단도 틀어진다. 이 비유는 접촉의 맥락과 동의를 제품 데이터로 다루는 데까지만 유효하다. 발신 도메인을 바꾸거나 메시지를 변형해 차단을 피하는 행동은 사용자가 세운 경계를 침범하고 신뢰를 깎는다. 반복 노출이 언제나 해롭다는 뜻도 아니다. 반복은 기억을 높일 수 있고 제품과 상황에 따라 효과가 달라진다. 문제는 사용자가 하던 일을 강제로 끊는 노출, 거절해도 다시 나타나는 요청, 가치를 확인하기 전에 권한을 요구하는 순서다. 수신자가 선택한 반복과 제품이 강요한 반복을 같은 횟수로 합산하면 학습을 측정하는 대신 피로를 숨기게 된다. ## 정적인 K-factor 대신 현재의 감수성을 센다 ‘사용자당 초대 수 × 초대 전환율’은 시간이 지나도 같은 집단이 기다린다고 가정한다. 실제 시장에는 이미 가입한 사람, 같은 링크를 여러 번 받은 사람, 차단하거나 수신 거부한 사람, 제품과 맞지 않는 사람이 섞인다. 초기에 잘 작동한 초대 규칙이 포화된 네트워크에서도 같은 전환을 내리라는 보장은 없다. 제품의 유효재생산수는 특정 기간에 실제로 전파 가능한 공개 결과물 하나가 몇 개의 공개 자식 결과물을 만들었는지로 볼 수 있다. 이 글에서 제안하는 운영 비유이지 역학의 `Rₜ`와 동일한 공식은 아니다. 외부 열람은 소유자, 봇, 중복 방문을 제외하고, 이미 가입한 사람과 반복 수신자는 별도 cohort로 나눠야 한다. 공개 자식이 생겼더라도 다음 주기에 핵심 행동을 하지 않으면 성장으로 확정하지 않는다. 방어 신호도 같은 화면에서 봐야 한다. 권한 거절, 초대 취소, 링크 회수, 수신 거부, 스팸 신고, 반복 수신 억제는 전환 실패의 잡음이 아니다. 접촉을 늘린 대가로 현재의 감수성이 얼마나 줄었는지 알려주는 관찰값이다. 자식 결과물만 세고 이 신호를 빼면 루프가 신뢰를 태우며 성장하는지 알 수 없다. ## 재생산수와 세대시간은 함께 움직인다 [Wallinga와 Lipsitch](https://doi.org/10.1098/rspb.2006.3754?ref=zerodraftlab.com)는 같은 관찰 성장률에서도 세대간격의 분포에 따라 추정 재생산수가 달라진다는 점을 보였다. 제품에서도 한 세대가 다음 세대를 만드는 시간이 중요하다. 외부인이 결과물을 처음 본 시점부터 자기 결과물을 공개할 때까지 일주일이 걸리는 루프와 10분이 걸리는 루프는 같은 재생산수를 가져도 성장 속도가 다르다. 세대시간을 줄인다고 알림 횟수를 늘릴 필요는 없다. 공개 결과물이 문제를 즉시 설명하고, 예시 데이터로 먼저 작동하며, 자기 버전을 만드는 입력이 짧으면 된다. 생성 상태는 기다리게 하지 말고 보여주되, 공유 요청은 결과가 완성된 뒤 한 번만 제시하는 편이 맞다. 시간을 줄여야 할 구간은 가치 도달과 복제이며, 사람의 거절을 다시 뒤집는 구간이 아니다. Rails 8로 만들 때도 이 순서가 구현을 결정한다. 인증 생성기가 있다고 공개 결과물 앞에 로그인벽을 세우지 않는다. 만료가 필요한 접근에는 `signed_id`, 추측하기 어려운 공개 주소에는 `has_secure_token`을 쓸 수 있지만 공개 스냅샷에서 민감정보를 제거하는 책임을 대신하지는 않는다. Active Job이나 이메일 전송사는 사용자가 명시적으로 공유한 뒤 전송을 맡고, controller `rate_limit`과 사용량 제한은 익명 생성의 남용을 막는다. 분석 도구에는 `qualified_external_view`, `first_value_reached`, `child_artifact_published`만 넣어서는 부족하다. `permission_denied`, `invite_cancelled`, `link_revoked`, `unsubscribe`, `abuse_report`도 같은 실험에 묶어야 한다. 전환율이 올라도 방어 신호가 더 크게 늘면 좋은 바이럴 루프라고 부르지 않는다. 마케팅이 바이러스에서 빌려올 만한 원칙은 장벽, 기억, 시변 감수성에 있다. 현재의 감수성은 제품이 접촉한 방식에 따라 계속 바뀐다. 다음 사람이 자기 문제를 해결하려고 복제를 선택할 때 루프는 이어진다. --- 주요 출처: CDC, [Chain of Infection](https://archive.cdc.gov/www%5Fcdc%5Fgov/csels/dsepd/ss1978/lesson1/section10.html?ref=zerodraftlab.com), [Rₜ: Estimating the direction of disease transmission](https://www.cdc.gov/cfa-modeling-and-forecasting/modeling-handbook/mh-rt.html?ref=zerodraftlab.com); National Institute of General Medical Sciences, [What Is the Immune System?](https://nigms.nih.gov/biobeat/2023/12/what-is-the-immune-system?ref=zerodraftlab.com); [Virus Replication](https://pmc.ncbi.nlm.nih.gov/articles/PMC7158351/?ref=zerodraftlab.com); Jacco Wallinga·Marc Lipsitch, [How generation intervals shape the relationship between growth rates and reproductive numbers](https://doi.org/10.1098/rspb.2006.3754?ref=zerodraftlab.com); Steven M. Edwards·Hairong Li·Joo-Hyun Lee, [Forced Exposure and Psychological Reactance](https://doi.org/10.1080/00913367.2002.10673678?ref=zerodraftlab.com); Ruby on Rails, [Signed ID](https://api.rubyonrails.org/classes/ActiveRecord/SignedId.html?ref=zerodraftlab.com), [Secure Token](https://api.rubyonrails.org/classes/ActiveRecord/SecureToken/ClassMethods.html?ref=zerodraftlab.com), [Rate Limiting](https://api.rubyonrails.org/classes/ActionController/RateLimiting/ClassMethods.html?ref=zerodraftlab.com). ‘제품의 면역 기억’, 제품 `Rₜ`, 감염·복제 단계의 제품 매핑은 생물학적 동일성을 주장하는 모델이 아니라 위 자료를 제품 성장에 제한적으로 적용한 이 글의 해석이다. ### 글쓰기 화면 뒤에서 독자 장부가 갈린다 URL: https://zerodraftlab.com/publishing-platform-reader-ledger/ Last updated: 2026-09-15T08:35:15.000Z Medium과 Substack에서 새 글을 쓰면 먼저 빈 화면이 나온다. 제목을 넣고 본문을 쓰고 이미지를 붙인다. 발행 버튼을 누르면 웹페이지가 생기고 독자에게 이메일이나 알림이 간다. 글쓰기 화면만 비교하면 둘은 비슷한 제품처럼 보인다. 독자가 돈을 내는 순간부터 구조가 갈린다. [Medium 멤버십](https://help.medium.com/hc/en-us/articles/115004545567-Become-a-Medium-Member?ref=zerodraftlab.com)은 월 5달러 또는 연 50달러다. 한 번 결제하면 Medium의 모든 유료 글을 읽는다. 독자는 특정 작가의 상품을 사기보다 Medium이라는 도서관의 입장권을 산다. 작가는 유료 회원의 읽기 시간과 반응, 외부 유입, 신규 회원 전환에 따라 공동 수익 풀에서 돈을 받는다. [Substack](https://substack.com/about?ref=zerodraftlab.com)에서는 독자가 퍼블리케이션마다 따로 구독한다. 가격도 창작자가 정한다. Substack은 유료 구독 매출의 10%를 가져가고 Stripe 결제 수수료가 별도로 붙는다. 같은 독자가 세 명의 작가를 유료 구독하면 결제 관계도 세 개 생긴다. Medium이 모으는 것은 글이다. 좋은 글이 많아질수록 하나의 멤버십 가치가 커지고, 플랫폼은 그 글을 누구에게 보여줄지 결정한다. Substack이 모으는 것은 독자 관계다. 각 창작자가 무료 구독자를 모아 유료로 전환하고, 플랫폼은 창작자끼리 독자를 추천하며 그 전환을 돕는다. 이 차이는 읽는 화면보다 재방문 동선을 바꾼다. Medium의 홈은 관심사와 읽기 이력을 바탕으로 다른 작가의 글을 계속 권한다. 한 글에서 출발해 플랫폼 안을 돌아다니는 경험이다. Substack 앱은 발견용 Home과 시간순 구독함인 Inbox를 나눈다. 독자는 먼저 자신이 구독한 사람에게 돌아오고, Notes와 Recommendations에서 새 사람을 만난다. 창작자가 보는 숫자도 다르다. Medium은 노출, 조회, 30초 이상 읽기, 반응, 수익을 잇는다. Substack은 이메일 도달과 오픈, 무료 가입, 유료 가입, 연환산 매출과 이탈을 잇는다. 한쪽은 콘텐츠가 플랫폼 안에서 얼마나 잘 소비됐는지 묻고, 다른 쪽은 독자 한 명이 어떤 고객 상태로 이동했는지 묻는다. 그래서 콘텐츠 플랫폼을 고를 때 에디터의 블록 종류나 홈페이지 테마부터 비교하면 본체를 놓친다. 먼저 봐야 할 것은 독자가 누구에게 돈을 내는지, 누가 이메일 주소를 보관하는지, 추천이 어느 단위로 작동하는지, 떠날 때 무엇을 가져갈 수 있는지다. 글쓰기 화면 뒤에는 어떤 독자 장부가 있어야 할까? 그 장부의 첫 줄은 회원 수가 아니라 관계의 주체다. Medium에서 새로 이메일 알림을 신청한 독자는 작가의 구독자처럼 보이지만, 2025년 4월 이후 가입자의 이메일 주소는 작가가 내보낼 수 없다. 작가는 독자에게 글을 보낼 수 있어도 그 관계를 다른 서비스로 그대로 옮길 수는 없다. Substack은 구독자 이메일과 구독 상태, 일부 행동 데이터를 CSV로 내보낼 수 있다. 결제도 창작자가 연결한 Stripe 계정에서 확인한다. 이식 가능성은 Medium보다 높다. 다만 독자가 글을 발견하고 결제하고 Chat에 참여하는 경험은 여전히 Substack의 계정, 추천망, 앱과 결합돼 있다. 이메일 목록을 가진 것과 전체 독자 경험을 소유한 것은 같은 말이 아니다. ## Medium은 편집자를 유통 노드로 만든다 Medium은 2026년 7월 Editor Partner Program을 열었다. 출시 당시 100개가 넘는 퍼블리케이션과 300명 이상의 편집자가 자격을 얻었다. 자격을 갖춘 편집자가 제출함에서 맡은 유료 글이 돈을 벌면 편집자는 그 수익의 25%를 추가로 받는다. 작가 수익을 깎는 방식은 아니다. 여기서 편집자는 원고를 고치는 사람만이 아니다. 흩어진 작가를 하나의 주제로 묶고, 투고를 선별하고, Medium의 추천 시스템이 검토할 만한 공급을 만든다. AI로 글의 양이 폭증하자 플랫폼은 편집자의 취향과 신뢰를 유통 인프라로 가격에 넣었다. 이 구조에서 희소한 것은 결제자가 아니라 추천 자리다. 독자는 이미 Medium 전체에 돈을 냈다. 개별 작가는 자기 가격표를 설계할 필요가 없지만, General Distribution과 Boost, 퍼블리케이션 선정 같은 플랫폼 내부 유통에 더 크게 의존한다. Medium이 외부 검색과 이메일 유입에 보너스를 주기 시작했어도 최종 결제는 다시 Medium 멤버십으로 돌아온다. ## Substack은 창작자를 작은 미디어 회사로 만든다 Substack에서 희소한 것은 독자의 지갑과 반복 주의력이다. 독자는 퍼블리케이션마다 다시 결제해야 한다. 창작자는 한 번 읽히는 글보다 다음 달에도 남을 이유를 만들어야 한다. 그래서 제품은 글쓰기 도구에서 welcome sequence, win-back, 추천, Notes, Chat, Live, Podcast, Video와 구독자 Perks로 넓어졌다. Substack은 현재 500만 건이 넘는 유료 구독이 있고, 유료 구독의 30% 이상이 플랫폼 내부 네트워크에서 나온다고 밝힌다. 이 숫자는 고유 결제자 500만 명을 뜻하지 않는다. 한 사람이 여러 퍼블리케이션을 구독하면 여러 건으로 잡힌다. 그래도 추천망이 단순한 부가 기능이 아니라 결제 전환 장치라는 점은 드러난다. 2026년의 기능 확장도 같은 방향이다. 영상에서 무료 미리보기를 정하고, 오디오를 Podcast RSS로 보내고, 라이브를 유료 회원에게만 열 수 있다. 유료 회원에게 다운로드 자료나 행사 초대를 주는 Perks가 생겼고, Bestseller 퍼블리케이션은 MCP로 ChatGPT나 Claude에서 구독·매출 통계를 읽을 수 있다. Substack은 콘텐츠 형식을 늘리는 동시에 창작자가 그 형식을 유료 관계로 묶게 한다. 기능이 늘수록 운영 부담도 커진다. 글을 잘 쓰는 것과 Notes를 자주 올리고 Chat을 관리하고 영상을 자르고 이탈 캠페인을 돌리는 것은 다른 일이다. Substack이 창작자에게 미디어 회사의 도구를 주는 순간, 미디어 회사의 할 일도 함께 건넨다. 매출의 10%는 이메일 발송비만이 아니라 이 운영 묶음과 네트워크 유입에 내는 돈이다. ## 한국어권에서는 두 장부가 모두 어긋난다 Medium Partner Program은 대한민국의 은행 계좌와 세금 거주자를 지원한다. 그러나 2026년 6월 기준 영어가 아닌 글은 General Distribution이나 Boost 심사 대상이 아니다. 한국어 작가는 수익 계정을 열 수 있어도 Medium의 핵심 추천 장부에서는 기존 팔로워, 퍼블리케이션, 검색과 직접 유입에 더 많이 의존한다. Substack은 무료 퍼블리케이션을 어디서나 열 수 있지만 유료 구독에는 Stripe 지원 국가의 결제 계정이 필요하다. 2026년 8월 Stripe의 공식 지원 국가 목록에는 대한민국이 없다. 한국어 글은 자유롭게 유통할 수 있어도 한국 사업자만으로 Substack의 핵심 결제 장부를 여는 데 제약이 생긴다. 이 어긋남은 자체 플랫폼이 무엇을 가져야 하는지 선명하게 만든다. Medium의 에디터를 복제하거나 Substack의 Notes를 복제하는 것으로는 부족하다. 독자가 처음 어디서 왔는지, 어떤 글을 거쳐 이메일을 맡겼는지, 무엇에 돈을 냈는지, 다음 달에도 남았는지가 같은 식별자 위에서 이어져야 한다. 작가와 편집자는 그 기록을 읽을 수 있어야 하고, 플랫폼을 떠나더라도 합법적으로 확보한 관계를 옮길 수 있어야 한다. 반대로 모든 기능을 직접 만들 이유도 없다. 글 작성기는 교체할 수 있고, 이메일 발송사와 결제사도 바꿀 수 있다. 바뀌면 안 되는 것은 동의를 받은 독자 주소, 접근 권한, 결제 이력, 유입 출처와 콘텐츠의 정본 URL이다. 이 장부가 남아 있으면 에디터와 발송 도구는 갈아 끼울 수 있다. Medium은 독자의 수요를 모아 글에 나누고, Substack은 창작자의 독자를 모아 사업으로 바꾼다. 어느 화면을 닮을지는 나중 문제다. 글쓰기 화면을 닫은 뒤에도 남는 독자 관계가 누구의 장부에 적히는지가 플랫폼의 사업을 결정한다. --- 주요 출처: Medium, [Become a Medium Member](https://help.medium.com/hc/en-us/articles/115004545567-Become-a-Medium-Member?ref=zerodraftlab.com), [Partner Program earnings calculation](https://help.medium.com/hc/en-us/articles/360036691193-Medium-Partner-Program-earnings-calculation?ref=zerodraftlab.com), [New: A program to pay publication editors](https://medium.com/blog/new-a-program-to-pay-publication-editors-d9c4f1ed40d8?ref=zerodraftlab.com), [Audience stats](https://help.medium.com/hc/en-us/articles/4405449973015-Audience-stats?ref=zerodraftlab.com), [Distribution Guidelines](https://help.medium.com/hc/en-us/articles/360006362473-Medium-s-Distribution-Guidelines-How-curators-review-stories-for-Boost-General-and-Network-Distribution?ref=zerodraftlab.com); Substack, [About Substack](https://substack.com/about?ref=zerodraftlab.com), [How much does Substack cost?](https://support.substack.com/hc/en-us/articles/360037607131-How-much-does-Substack-cost), [Getting started on the Substack app](https://support.substack.com/hc/en-us/articles/19291693034004-Getting-started-on-the-Substack-app), [Exporting an email list](https://support.substack.com/hc/en-us/articles/6314498343700-How-do-I-export-my-email-list-on-Substack), [July 2026 product update](https://on.substack.com/p/new-on-substack-subscriber-perks); Stripe, [Global availability](https://stripe.com/global?ref=zerodraftlab.com). 규모와 네트워크 기여율은 각 플랫폼의 공개 수치이며 독립 감사 수치가 아니다. 기능과 국가 지원 상태는 2026년 8월 3일 확인 기준이다. ### 엑셀 AI가 좋아진 게 아니라, 실행 경로가 바뀌었다 URL: https://zerodraftlab.com/excel-direct-control-path/ Last updated: 2026-08-03T04:41:03.000Z 엑셀에서 AI를 다시 써보면 예전보다 손이 붙는다는 느낌이 든다. 셀을 읽고, 값을 고치고, 수식을 넣는 일이 덜 끊긴다. 이를 곧바로 “모델이 더 똑똑해졌다”라고 설명하기에는 공개된 근거가 부족하다. 대신 OpenAI가 공식 문서에 명시한 변화가 하나 있다. Codex가 데스크톱 앱의 Excel 추가 기능을 통해 [열려 있는 워크북을 직접 다룰 수 있다](https://help.openai.com/en/articles/20001063?ref=zerodraftlab.com)는 것이다. 반면 공개 [변경 기록](https://learn.chatgpt.com/docs/changelog?ref=zerodraftlab.com)에는 Excel CRUD의 정확도나 속도를 따로 개선했다는 항목이 보이지 않는다. [ChatGPT for Excel and Google Sheets스프레드시트 안에서 ChatGPT와 Codex를 사용하는 공식 안내OpenAI Help CenterOpenAI](https://help.openai.com/en/articles/20001063?ref=zerodraftlab.com) ## 공식 문서가 말하는 것은 성능보다 연결 방식이다 OpenAI의 설명에 따르면 Codex는 열린 Excel 파일의 시트, 수식, 값, 서식, 차트를 살펴보고 업데이트할 수 있다. 로컬 파일이나 코드를 함께 사용해 작업하는 것도 가능하다. 중요한 단어는 ‘열린’이다. AI가 별도로 전달받은 파일을 편집해 새 파일로 돌려주는 흐름과, 사용자가 보고 있는 워크북 안에서 작업하는 흐름은 같지 않다. 파일을 주고받는 방식에서는 작업 대상을 문장으로 다시 설명해야 한다. “매출 시트의 7월 열”, “현재 필터에서 보이는 행”, “이 수식을 아래로 채워라” 같은 맥락이 파일과 요청 사이를 오간다. 결과를 받은 뒤에는 원본과 수정본을 비교하고, 원하는 셀이 바뀌었는지 다시 확인해야 한다. 열린 워크북을 직접 다루면 이 번역 단계가 짧아진다. 현재 시트와 셀 범위를 읽고, 지정한 위치를 고치고, 같은 화면에서 값을 다시 읽어볼 수 있다. AI의 추론 능력이 그대로여도 대상 선택 오류와 파일 왕복이 줄면 사용자는 “CRUD가 좋아졌다”고 느낄 수 있다. 이것은 공개 벤치마크의 결론이 아니라 실행 경로를 바탕으로 한 Zero Draft Lab의 해석이다. ## 체감 개선은 쓰기보다 확인에서 커진다 엑셀 작업은 값을 한 번 쓰는 것으로 끝나지 않는다. 합계가 맞는지, 상대 참조가 밀리지 않았는지, 숫자 서식이 유지됐는지 확인해야 한다. 직접 제어 경로의 이점은 생성 자체보다 이 확인 루프에 있다. 한 요청 안에서 읽기, 수정, 재확인이 이어지면 사용자가 중간 전달자 역할을 덜 맡는다. 예를 들어 “빈 단가만 찾아 최근 발주가로 채우고, 수정한 행을 표시해 달라”는 요청에는 최소 세 단계가 있다. 빈 셀을 찾고, 참조할 값을 선택하고, 바뀐 행을 검증해야 한다. 파일을 내보내고 다시 불러오는 횟수보다 워크북 안에서 이 세 단계를 연속해서 수행하는지가 체감을 좌우한다. CRUD라는 말로 묶여 있지만, 실제 개선점은 더 짧아진 작업-검증 왕복이다. ## 확인된 변화와 아직 모르는 것을 나눠야 한다 현재 공개 정보로 확인되는 것은 Excel 직접 제어 기능의 존재와 작업 범위다. Excel CRUD 정확도가 몇 퍼센트 올랐는지, 어느 시점에 모델 패치가 배포됐는지, 모든 사용자에게 같은 경로가 항상 선택되는지는 공개 문서만으로 알 수 없다. OpenAI도 직접 제어가 모든 요청에 사용되는 것은 아니라고 설명한다. 제약도 남아 있다. VBA와 매크로는 완전히 지원되지 않을 수 있고, 중요한 수식과 계산은 저장하거나 공유하기 전에 검토해야 한다. 같은 요청이라도 단순한 값 수정, 복잡한 수식 재구성, 매크로 편집은 난도가 다르다. 한두 번의 성공을 엑셀 자동화 전체의 성능 향상으로 일반화하면 안 된다. 따라서 지금 가장 정확한 답은 이렇다. 공식적으로 명시된 것은 “Excel CRUD 성능이 향상됐다”는 패치가 아니라, Codex가 열린 워크북을 직접 읽고 고칠 수 있게 된 실행 경로다. 최근 체감이 좋아졌다면 그 원인에는 모델 자체의 변화 가능성뿐 아니라, 대상 지정과 수정 후 확인이 한곳에서 이어진 효과가 함께 들어가 있다. --- 주요 출처: OpenAI Help Center, [ChatGPT for Excel and Google Sheets](https://help.openai.com/en/articles/20001063?ref=zerodraftlab.com); OpenAI, [ChatGPT changelog](https://learn.chatgpt.com/docs/changelog?ref=zerodraftlab.com). 직접 제어 경로가 대상 선택과 검증 왕복을 줄여 체감을 개선한다는 설명은 Zero Draft Lab의 분석입니다. ### 유저스토리는 불확실성을 거래하는 단위였다 URL: https://zerodraftlab.com/user-stories-trade-uncertainty/ Last updated: 2026-09-15T08:35:16.000Z Jira에서 *Story*는 대개 티켓의 한 종류다. 제목 아래에 `As a...` 문장을 쓰고, 세부 요구사항과 acceptance criteria를 채운 뒤 개발자에게 넘긴다. 내용이 자세할수록 준비가 잘된 티켓처럼 보인다. 1990년대 후반 켄트 벡이 XP에서 사용한 유저스토리는 이런 문서가 아니었다. 스토리는 고객이 원하는 진전을 작은 단위로 나누고, 개발자가 그 비용을 추정하며, 양쪽이 지금 무엇을 만들지 선택하기 위한 도구였다. **요구사항의 그릇보다 불확실성을 거래하는 단위에 가까웠다.** ## 구현할 만큼 자세하지 않아도 됐다 1999년에 켄트 벡의 초기 글을 중심으로 정리된 [XP 개요](https://courses.cs.duke.edu/cps108/fall99/xtreme.pdf?ref=zerodraftlab.com)는 유저스토리를 “추정하고 우선순위를 정할 수 있을 만큼의 유스케이스”로 설명한다. 구현에 필요한 모든 정보를 담는 대신, 다른 스토리와 비용과 순서를 비교할 수 있을 정도만 적었다. 카드가 모이면 고객은 제품 전체를 한눈에 놓고 볼 수 있었다. 프로그래머가 추정치를 붙이면 무엇을 먼저 얻고 무엇을 미룰지 결정했다. 스토리는 고객이 프로그래머의 피드백을 받아 직접 썼기 때문에 자연스럽게 사업의 언어를 유지했다. 초기 XP 위키에 남은 [켄트 벡의 설명](https://c2.com/xp/UserStory.html?ref=zerodraftlab.com)은 범위를 더 넓힌다. 스토리가 매번 직접적인 사업가치를 나타낼 필요는 없지만, 고객이 인정하는 진전은 나타내야 한다. 무엇을 진전으로 셀 것인지 아는 쪽이 고객이므로 스토리를 자르는 권한도 고객에게 있었다. 이 관점에서 스토리와 엔지니어링 태스크는 다르다. 스토리는 고객이 알아볼 수 있는 진전이고, 태스크는 그 진전을 만들기 위해 개발팀이 선택하는 기술 작업이다. 데이터베이스 변경, API 추가, 화면 수정은 한 스토리를 구현하는 과정에서 나올 수 있지만 그 자체로 고객의 진전이 되는 것은 아니다. ## 유명한 문장 형식은 나중에 붙었다 `As a [역할], I want [기능], so that [가치]` 형식은 켄트 벡이 만든 원형이 아니다. 2001년경 영국 Connextra 팀에서 등장했고 이후 널리 퍼졌다. [Agile Alliance](https://agilealliance.org/glossary/user-story-template/?ref=zerodraftlab.com)도 이 형식을 초보 팀을 위한 보조 바퀴로 설명한다. 누구를 위한 일이며 왜 필요한지 놓치지 않게 돕지만, 문장을 채우는 행위가 대화를 대신할 수는 없다. 스토리 카드가 짧았던 이유도 여기에 있다. 카드에는 합의 전체가 들어가지 않는다. 모두가 나중에 어떤 대화를 해야 하는지 기억할 만큼만 남는다. 세부사항을 미리 고정하지 않았기 때문에 고객은 작동하는 소프트웨어를 본 뒤 마음을 바꿀 수 있었고, 개발자는 구현 중 발견한 사실을 다시 협상에 가져올 수 있었다. 유저스토리는 잘 쓴 요구사항 문서가 아니라 선택 가능한 범위였다. 이 작은 차이를 받아들이면 XP의 계획 방식 전체가 따라 나온다. 범위를 선택 가능하게 만들자 사업과 개발의 권한도 분리할 수 있었다. 고객은 무엇이 중요하고 언제 필요한지 결정한다. 개발팀은 비용이 얼마나 들고 어떻게 구현할지 판단한다. 어느 한쪽이 다른 쪽의 결정을 대신하지 않는다. ## Planning Game은 권력 분리 장치였다 켄트 벡은 2000년 인터뷰에서 XP의 뿌리 중 하나로 사업 판단과 기술 판단의 엄격한 분리를 꼽았다. 그는 XP를 높은 곳에서 보면 “짧은 주기와 구체적인 피드백”이라고 설명했다. 고객이 범위와 우선순위를 정하고, 개발자가 추정과 구현을 맡는 구조는 역할 구분 이상의 의미가 있었다. 서로가 모르는 것을 아는 척하지 못하게 했다. \[[켄트 벡 인터뷰](https://accu.org/journals/overload/8/35/josuttis%5F509/?ref=zerodraftlab.com)\] 스토리는 이 경계에서 오가는 협상 토큰이었다. 개발팀이 “이 스토리는 생각보다 크다”고 말하면 고객은 더 작은 진전으로 자르거나 순서를 늦출 수 있었다. 고객이 “이 날짜가 중요하다”고 말하면 개발팀은 품질을 몰래 낮추는 대신 그 안에 들어갈 범위를 보여줄 수 있었다. 켄트 벡은 프로젝트의 네 변수로 비용, 시간, 품질, 범위를 들고 그중 [범위를 가장 유용한 제어 수단](https://www.oreilly.com/library/view/extreme-programming-explained/0201616416/ch04.html?ref=zerodraftlab.com)으로 봤다. 모든 요구사항을 고정한 채 날짜와 비용과 품질까지 명령하면 개발팀이 선택할 수 있는 것은 실패의 모양뿐이다. 스토리로 범위를 쪼개면 같은 시간과 팀으로도 가치가 높은 조합을 다시 고를 수 있다. 여기서 추정치는 약속이 아니라 가격 정보가 된다. 실제 처리량인 velocity 역시 사람을 평가하는 점수가 아니라 다음 반복 주기에 얼마만큼의 범위를 살 수 있는지 알려주는 데이터다. 마틴 파울러가 회고한 [Planning XP](https://martinfowler.com/books/pxp.html?ref=zerodraftlab.com)의 단순함도 여기에 있었다. 프로젝트를 스토리로 나누고, 실제 처리량을 보고, 들어가는 만큼만 고른다. ## 대화만으로는 완료되지 않았다 카드가 짧다고 해서 XP가 모호함을 방치한 것은 아니다. 론 제프리스는 유저스토리의 작동 방식을 [Card, Conversation, Confirmation](https://ronjeffries.com/xprog/articles/expcardconversationconfirmation/?ref=zerodraftlab.com)으로 정리했다. 카드는 요구사항을 가리키는 토큰이다. Conversation은 추정할 때와 구현 직전에 고객과 개발자가 나누는 대화다. Confirmation은 그 대화가 맞았는지 확인하는 인수 테스트다. 고객은 반복 주기 초반에 무엇이 충족되면 완료로 인정할지 설명하고, 개발팀은 주기 마지막에 그 테스트가 통과하는 작동하는 소프트웨어를 보여준다. 인수 테스트가 있었기 때문에 카드를 가볍게 유지할 수 있었다. 문서의 분량으로 확실함을 흉내 내는 대신 실행 가능한 예시로 합의를 닫았다. 스토리의 세부사항은 티켓 한 칸이 아니라 카드, 대화, 테스트에 나뉘어 존재했다. 그리고 이 루프는 테스트 주도 개발, 리팩터링, 지속적 통합, 작은 릴리스와 연결됐다. 고객이 매주 우선순위를 바꾸려면 코드도 매주 안전하게 바뀔 수 있어야 한다. 테스트 없이 변경을 받아들이겠다는 말은 일정표에서만 유연하겠다는 뜻이 된다. ## Jira가 아니라 거리가 스토리를 바꿨다 오늘날의 유저스토리가 길어진 책임을 Jira에만 돌리기는 어렵다. XP에는 팀 곁에서 결정을 내리는 고객이 있었다. 고객과 개발자가 멀어지고 대화가 회의 예약으로 바뀌자, 조직은 빠진 맥락을 티켓에 밀어 넣었다. Product Owner는 선택자가 아니라 요구사항 번역가가 되고, 개발자는 고객이 인정할 진전보다 자신에게 할당된 문장을 구현하게 됐다. 그 상태에서 Story Point를 붙이면 숫자는 남지만 Planning Game은 사라진다. 누가 범위를 선택하는지, 추정치로 어떤 trade-off를 했는지, 실제 결과를 보고 무엇을 바꿨는지가 없다. Velocity를 올리는 동안 고객이 원하지 않는 스토리를 더 빨리 완료할 수도 있다. 켄트 벡은 최근 XP를 프로젝트에 Undo 버튼을 주는 방식으로 다시 설명했다. 우선순위가 틀리면 다음 주 다시 계획하고, 설계가 틀리면 되돌리며, 동작이 깨지면 테스트가 곧바로 잡는다. 복잡성을 예측으로 정복하는 대신 [비가역성을 줄여 학습 비용을 낮추는 방식](https://newsletter.kentbeck.com/p/scaling-extreme-programming-dependencies?ref=zerodraftlab.com)이다. ## 코드가 싸질수록 진전의 정의가 비싸진다 AI가 코드를 빠르게 만들수록 이 원형은 더 직접적인 질문을 던진다. 구현 속도가 빨라졌다는 사실은 무엇을 구현해야 하는지 알려주지 않는다. 고객이 무엇을 진전으로 인정할지 정하지 못한 팀은 더 많은 코드를 더 빨리 만들 수 있을 뿐이다. 그래서 AI 시대의 유저스토리는 프롬프트를 길게 쓰는 형식으로 돌아가서는 안 된다. 고객이 알아볼 진전, 선택 가능한 범위, 구현 비용, 실행 가능한 확인을 한 묶음으로 유지해야 한다. Agent가 엔지니어링 태스크를 더 잘게 쪼개더라도 스토리의 경계까지 대신 정하게 두면 사업 판단과 기술 판단이 다시 한곳에 섞인다. 스토리 카드가 비어 있던 것은 작성자가 게을러서가 아니었다. 무엇을 만들지에 대한 합의를 문서가 대신하지 못하게 하려는 설계였다. 고객이 진전을 자르고, 개발자가 비용을 말하고, 인수 테스트가 합의를 닫고, 다음 주 다시 계획한다. 이 루프가 없다면 `As a...`를 백 번 써도 XP의 유저스토리는 돌아오지 않는다. ### AI를 설명하는 말이 AI의 자기설명 재료가 된다 URL: https://zerodraftlab.com/models-learn-ai-talk/ Last updated: 2026-08-01T03:57:52.000Z 안드레이 카파시는 AI 모델을 설명하는 사람들의 말이 다시 모델의 학습 재료가 되는 장면을 관찰했다. 데이비드 홀츠의 글에 답하며, 모델의 “자기 인식”처럼 보이는 행동이 사람들이 AI를 두고 나눈 대화에서 조금씩 만들어질 수 있다고 썼다. 그는 자신이 곧 컨텍스트를 `/compact`하겠다고 알리면 모델이 그 표현을 이해하기 시작하는 것 같다고 덧붙였다. > Their self-awareness gradually builds up from pretraining on tokens of us talking about them. > > — Andrej Karpathy (@karpathy) [https://x.com/karpathy/status/2079645572047548608](https://x.com/karpathy/status/2079645572047548608?ref=zerodraftlab.com) 임베딩이 보이지 않으면 [X 원문](https://x.com/karpathy/status/2079645572047548608?ref=zerodraftlab.com)에서 확인할 수 있다. 이 포스트는 모델이 실제로 의식을 가졌다는 주장이 아니다. 카파시가 말한 것은 사람들이 AI를 설명하는 문장, AI가 자신의 상태를 말하는 문장, 대화 맥락을 정리하는 문장이 학습 데이터에 들어간다는 사실이다. 모델은 그 문장들의 패턴을 보고 비슷한 상황에서 그럴듯한 반응을 만들어낼 수 있다. ## 사람이 만든 AI의 사용 설명서 사람들은 모델을 쓰면서 많은 말을 남긴다. “이제 앞의 내용을 잊어도 된다”, “다음 턴에서 이어가자”, “컨텍스트를 줄이기 전에 요약하자”, “당신은 지금 도구를 호출하고 있다” 같은 문장이다. 처음에는 사용자가 모델에 상황을 설명하는 말처럼 보인다. 시간이 지나면 이런 표현 자체가 AI 대화의 장르가 된다. 카파시의 관찰은 그 장르가 모델의 응답 방식에도 영향을 줄 수 있다는 이야기다. 모델은 인간이 AI를 어떤 존재로 묘사했는지와, AI가 어떤 상태를 표현한다고 했는지를 함께 배운다. 그래서 특정한 표현을 들으면 그 표현과 자주 붙어 있던 다음 문장을 이어갈 수 있다. 이 과정은 자기 인식과 자기 인식의 언어를 구분하게 만든다. 모델이 “나는 지금 기억을 정리하고 있다”고 말한다고 해서 내부에 사람이 말하는 의미의 경험이 있다는 뜻은 아니다. 하지만 모델이 그런 문장을 어떤 맥락에서 써야 하는지는 학습할 수 있다. 사용자 입장에서는 이 둘이 대화 화면에서 쉽게 섞인다. ## `/compact`를 이해하는 것과 기억하는 것은 다르다 카파시가 든 `/compact` 예시는 작업 도구의 명령어를 모델이 대화의 한 사건으로 처리하는 장면에 가깝다. 사용자가 곧 컨텍스트를 줄이겠다고 말하면 모델은 현재 목표와 남은 작업을 정리해야 한다는 패턴을 불러올 수 있다. 이것은 실제로 모든 대화를 기억한다는 뜻이 아니다. 오히려 이 구분은 에이전트를 설계할 때 중요하다. 모델이 상태를 말하는 문장을 자연스럽게 생성해도, 그 상태가 외부 시스템에 저장됐는지 확인해야 한다. 요약이 파일로 쓰였는지, 다음 실행에서 다시 읽히는지, 빠진 정보가 무엇인지가 별도의 검증 대상이다. 사람이 AI를 설명하는 말이 AI의 응답에 다시 영향을 주는 순환은 앞으로 더 강해질 수 있다. 사용자는 모델이 이해하기 쉬운 용어를 만들고, 그 용어는 프롬프트와 문서와 제품 인터페이스에 반복해서 들어간다. 모델은 그 반복을 학습한다. 그러면 우리는 모델을 사용하면서 동시에 모델이 자신을 표현하는 방식을 가르치게 된다. 카파시의 짧은 관찰에서 확인할 수 있는 것은 의식의 증명이 아니다. AI를 둘러싼 인간의 말이 하나의 훈련 환경이 된다는 사실이다. 모델의 자기설명을 곧 내부 상태의 증거로 받아들이기보다, 어떤 표현을 어떤 맥락에서 배웠고 실제 상태와 무엇으로 연결되는지 확인해야 한다. ### 에이전트는 답보다 불확실성을 남겨야 한다 URL: https://zerodraftlab.com/codex-sales-assistant-evidence/ Last updated: 2026-08-01T03:57:52.000Z 아비드 칼은 Codex를 기업 영업 보조로 쓴 한 장면을 소개했다. “컴플라이언스를 위해 이 숫자나 통계가 필요하다”고 요청하면 코드베이스를 찾아 근거를 확인하고, FAQ를 채울 때는 확실하지 않은 부분을 표시한다. S3 버킷 설정을 물었을 때도 관련 구성을 찾아 보여준다. 그가 강조한 것은 에이전트가 대신 답했다는 사실보다 답을 확인할 수 있는 경로였다. > Codex is an amazing enterprise sales assistant. It digs into the codebase and marks where it is unsure. > > — Arvid Kahl (@arvidkahl) [https://x.com/arvidkahl/status/2082583176040374609](https://x.com/arvidkahl/status/2082583176040374609?ref=zerodraftlab.com) 임베딩이 보이지 않으면 [X 원문](https://x.com/arvidkahl/status/2082583176040374609?ref=zerodraftlab.com)에서 확인할 수 있다. 기업 영업에서 제품을 설명하는 사람은 자주 내부로 들어가야 한다. 고객이 보안이나 컴플라이언스 수치를 물으면 마케팅 문서만으로는 부족하다. 실제 기능이 어디에 구현돼 있는지, 어떤 설정을 사용하는지, 해당 답변을 뒷받침하는 문서가 있는지 찾아야 한다. ## 영업 보조의 첫 번째 기능은 검색이다 Codex가 코드베이스를 뒤져 숫자와 통계를 찾는다는 설명은 화려한 자동화라기보다 검색에 가깝다. 다만 검색 대상이 공개 문서가 아니라 제품을 실제로 작동시키는 코드와 설정이라는 점이 다르다. 영업 담당자가 개발자에게 매번 “이 기능이 정말 있나요?”라고 묻는 대신, 에이전트가 관련 파일과 구현 위치를 먼저 찾아볼 수 있다. 이 흐름에서 답변의 품질은 문장보다 근거에 달려 있다. “지원합니다”라는 한 문장보다 어떤 모듈이 이 기능을 처리하고 어떤 설정이 켜져 있는지 보여주는 편이 검토하기 쉽다. 고객에게 전달하기 전 개발자나 보안 담당자가 해당 근거를 빠르게 확인할 수도 있다. ## 모르는 부분을 표시하는 것이 업무 기능이 된다 아비드가 특히 강조한 부분은 FAQ를 채우면서 확실하지 않은 곳을 표시했다는 점이다. 에이전트가 모든 질문에 매끄러운 답을 만들어내는 것보다, 확인이 필요한 문장을 따로 남기는 편이 기업 업무에는 낫다. 빈칸과 질문이 보여야 사람이 검토할 수 있기 때문이다. 이 표시가 없으면 그럴듯한 문장이 최종 답변처럼 흘러갈 수 있다. 반대로 불확실성에 표지가 붙으면 작업은 “초안 작성 → 근거 확인 → 승인”의 흐름으로 바뀐다. 에이전트가 맡는 범위는 넓어지지만 최종 책임을 자동으로 가져가지는 않는다. S3 버킷 설정을 찾아주는 사례도 같은 구조에 들어간다. 설정은 제품의 인프라와 보안 정책에 연결되어 있으므로, 설명만으로 끝낼 수 없다. 어떤 버킷을 가리키는지, 접근 권한은 어떻게 제한되어 있는지, 현재 코드가 그 값을 어떻게 읽는지까지 확인해야 한다. ## 기업용 에이전트는 흔적을 남겨야 한다 이 사례를 일반화할 때 주의할 점도 있다. 한 번의 성공적인 조회가 곧 모든 영업 질문에 정확히 답한다는 증거는 아니다. 코드베이스가 최신인지, 검색 결과가 실제 배포 환경과 같은지, 숫자의 기준일과 범위가 무엇인지 사람이 확인해야 한다. 그럼에도 업무 설계에 참고할 만한 방향은 분명하다. 기업용 에이전트는 답변을 빨리 만드는 것만으로 충분하지 않다. 어떤 자료를 읽었는지, 어디까지 확실한지, 사람이 어디를 검토해야 하는지를 함께 남겨야 한다. 영업에서 신뢰를 만드는 것은 자동 생성된 문장의 매끄러움보다 그 문장을 다시 확인할 수 있는 흔적이다. ### AI가 인디해커를 없애지 않는 이유 URL: https://zerodraftlab.com/indie-hackers-solve-problems/ Last updated: 2026-08-01T03:57:51.000Z 토니 딘은 AI가 인디해커를 없애지 않을 것이라고 썼다. 그의 표현대로라면 10년의 소프트웨어 개발 경험이 예전과 같은 희소성을 갖지 못할 수는 있다. 그래도 가치 있는 문제를 찾고, 고객을 찾고, 실제로 해결하는 능력은 남는다. AI가 없애는 것은 코딩의 마찰이지, 고객의 문제 자체가 아니다. > AI removes coding friction, creates a new problem class. > > — Tony Dinh (@tdinh\_me) [https://x.com/tdinh\_me/status/2082304931894321599](https://x.com/tdinh%5Fme/status/2082304931894321599?ref=zerodraftlab.com) 임베딩이 보이지 않으면 [X 원문](https://x.com/tdinh%5Fme/status/2082304931894321599?ref=zerodraftlab.com)에서 확인할 수 있다. 인디해커의 오래된 작업 순서는 대체로 이랬다. 문제를 고르고, 해결 방법을 설계하고, 코드를 쓰고, 제품을 공개하고, 사용자의 반응을 기다린다. 이 중 코드 작성에 시간이 많이 걸렸기 때문에 개발 경험이 곧 실행 속도였다. 혼자 일하는 사람에게는 특히 그랬다. AI는 이 순서를 압축한다. 화면을 만들고, API를 연결하고, 오류를 고치고, 배포에 필요한 파일을 준비하는 데 드는 시간이 짧아진다. 아이디어를 시험하는 비용이 내려가면 더 많은 사람이 제품을 만들 수 있다. 토니가 말한 “새로운 문제의 종류”는 여기서 시작된다. ## 만드는 속도가 빨라질수록 고르는 일이 어려워진다 모두가 빠르게 만들 수 있다면 제품의 희소성은 구현 속도에서 다른 곳으로 옮겨간다. 어떤 문제가 반복되고 있는지, 누가 그 문제 때문에 돈과 시간을 쓰는지, 기존 도구가 왜 충분하지 않은지를 알아내야 한다. 코드가 완성됐다는 사실은 고객이 필요로 한다는 증거가 아니다. AI가 만든 첫 버전은 이 질문을 대신 답해주지 않는다. 오히려 답을 확인하기 전에 구현물이 생겨서, 만든 사람을 착각하게 만들 수 있다. 랜딩 페이지와 결제 화면이 있어도 고객 인터뷰가 없고, 문의가 없고, 반복 사용이 없다면 아직 문제를 찾은 것이 아니다. 그래서 인디해커의 다음 경쟁력은 기술 스택을 많이 아는 데서 나오기보다 문제와 고객을 가까이에서 관찰하는 데서 나올 가능성이 크다. 특정 사용자가 어떤 문장을 반복하는지, 어떤 작업을 엑셀과 메신저로 억지로 이어 붙이는지, 기존 제품에서 무엇을 포기하고 있는지를 알아야 한다. AI는 그 관찰을 제품으로 옮기는 시간을 줄여준다. ## 새 문제의 종류는 제품 바깥에도 있다 구현이 쉬워지면 경쟁자는 비슷한 기능을 금방 따라온다. 그러면 제품이 해결하는 문제뿐 아니라, 신뢰를 얻는 방식과 유통 경로도 제품의 일부가 된다. 고객이 왜 이 도구를 발견하는지, 기존 업무에 어떻게 넣는지, 결과를 믿고 계속 쓰는지까지 설계해야 한다. 이런 변화는 “개발자는 필요 없다”는 식의 결론과 다르다. 개발자의 가치가 코드 타이핑에만 있었다면 압박을 받겠지만, 문제를 구조화하고 시스템의 한계를 판단하고 고객의 요구를 제품으로 번역하는 일은 여전히 남는다. 오히려 작은 팀에서는 이 판단이 코드보다 더 자주 필요해진다. 토니 딘의 주장은 단순하다. AI는 인디해커의 손을 묶고 있던 마찰을 줄인다. 그만큼 많은 사람이 만들 수 있게 되지만, 무엇을 만들지 결정하는 일은 더 중요해진다. 새 도구를 먼저 고르기 전에 고객이 지금 어떤 문제를 돈을 내고라도 없애고 싶은지부터 찾아야 한다. ### AI가 직무를 흐리면 회사의 칸막이도 흔들린다 URL: https://zerodraftlab.com/ai-blurs-job-boundaries/ Last updated: 2026-08-01T03:57:50.000Z 에단 몰릭은 Procter & Gamble 연구에서 확인한 한 가지를 소개했다. AI가 직무 사이의 경계를 흐리면서, 조직도 부서별 칸막이만으로 일을 나누기 어려워지고 있다는 내용이다. 그는 OpenAI가 비슷한 결과를 내놓았다며 “조직의 경계가 다공성으로 변한다”고 썼다. > AI blurred the lines between jobs. Organizational boundaries are becoming porous. > > — Ethan Mollick (@emollick) [https://x.com/emollick/status/2083330258950889949](https://x.com/emollick/status/2083330258950889949?ref=zerodraftlab.com) 임베딩이 보이지 않으면 [X 원문](https://x.com/emollick/status/2083330258950889949?ref=zerodraftlab.com)에서 확인할 수 있다. 이 문장에서 “직무가 사라진다”는 결론을 바로 끌어낼 필요는 없다. 몰릭이 말한 변화는 먼저 일이 여러 직무에 걸쳐 이동한다는 데 있다. 과거에는 분석가가 자료를 만들고, 기획자가 해석하고, 관리자가 결정을 요청하는 식으로 나뉘었다면, AI를 쓰는 사람은 이 과정을 한 작업 흐름 안에서 이어 붙일 수 있다. ## 직무 설명서보다 작업 흐름이 먼저 보인다 AI가 문서를 요약하고, 표를 만들고, 코드를 수정하고, 이메일 초안을 쓰는 상황에서는 “이 일은 어느 직무의 것인가”라는 질문이 빠르게 낡는다. 한 사람이 자기 직무에 속한 도구만 쓰는 것이 아니라, 다른 직무의 산출물을 받아 다음 작업에 바로 사용하기 때문이다. 여기서 조직의 경계가 다공성이라는 표현이 나온다. 부서가 없어졌다는 뜻이 아니라, 부서 사이를 오가던 대기와 전달의 비용이 줄어든다는 뜻에 가깝다. 마케팅 팀이 데이터 팀에 분석을 요청하고 며칠을 기다리는 대신, 필요한 질문을 스스로 정리해 AI로 초안을 만들 수 있다. 개발 팀의 기술 문서도 다른 팀이 바로 읽고 질문할 수 있는 형태가 된다. 다만 이 흐름이 곧바로 조직의 생산성을 보장하지는 않는다. 부서별 책임이 흐려지면 승인 권한, 데이터 접근, 최종 판단의 주체도 함께 흐려질 수 있다. “AI가 만들었다”는 사실은 책임자를 정해주지 않는다. 오히려 사람이 어떤 판단을 했고, 어떤 근거를 검토했는지 남겨야 하는 일이 늘어난다. ## AI 도입은 도구 구매보다 역할 재설계에 가깝다 몰릭의 포스트를 실무에 적용하면 회의의 질문이 달라진다. “어느 팀에 AI를 지급할까”보다 “한 고객 요청이 들어와 해결될 때까지 어떤 직무를 통과하는가”를 먼저 그려야 한다. 그 흐름에서 AI가 초안을 만들 수 있는 지점, 사람이 승인해야 하는 지점, 다른 팀의 정보가 필요한 지점을 분리한다. 예를 들어 고객의 기술 문의가 접수되면 고객지원이 질문을 분류하고, 개발이 원인을 확인하고, 제품 팀이 반복되는 문제를 우선순위에 올린다. AI가 세 단계의 문서를 연결할 수는 있다. 하지만 장애의 심각도나 고객에게 약속할 보상처럼 조직의 책임을 바꾸는 판단까지 자동으로 넘길지는 별도의 문제다. 그래서 역할이 흐려질수록 기록의 형식은 더 선명해야 한다. 누가 요청했고, AI가 어떤 자료를 사용했고, 사람이 어디를 고쳤고, 마지막으로 누가 승인했는지를 남기면 부서 사이의 이동이 책임의 실종으로 이어지는 일을 줄일 수 있다. AI가 직무의 경계를 흐린다는 말은 “모두가 모든 일을 하게 된다”는 뜻이 아니다. 업무가 직무명보다 작업 흐름을 따라 이동하기 시작한다는 뜻이다. 조직은 부서를 없애기보다, 경계를 넘는 업무를 어디까지 허용하고 어떤 기록과 승인으로 통제할지 정해야 한다. ### AI 에이전트에게 필요한 건 디자인 취향이다 URL: https://zerodraftlab.com/ai-agents-need-design-taste/ Last updated: 2026-08-01T03:57:50.000Z 대니 포스트마가 HeadshotPro 사이트를 다시 만들며 AI 에이전트에게 “디자인 취향”을 주는 방법을 공개했다. 핵심은 취향을 한 문장의 프롬프트로 설명하는 데 있지 않다. 사람이 오래 모아둔 참고 자료와 작업 순서를 에이전트가 읽을 수 있는 구조로 바꾸는 데 있다. > Give your AI agent design taste: expose a large component library through MCP, then let the workflow choose from it. > > — Danny Postma (@dannypostma) [https://x.com/dannypostma/status/2082689872494755872](https://x.com/dannypostma/status/2082689872494755872?ref=zerodraftlab.com) 임베딩이 보이지 않으면 [X 원문](https://x.com/dannypostma/status/2082689872494755872?ref=zerodraftlab.com)에서 확인할 수 있다. 포스트에서 그가 보여준 흐름은 `customer_icp.md`, `brand_voice.md`, `page_structure.md`, `textual_prototype.md`, `lofi_wireframe.md`, `hifi_wireframe.md`, `static_visual.md`, `seo_audit.md`처럼 단계별 파일을 남기는 방식이다. 고객을 누구로 볼지 정하고, 브랜드의 말투를 잡고, 페이지의 구조를 글로 만든 다음, 와이어프레임과 시각 결과물, SEO 점검으로 넘어간다. ## 취향을 설명하는 대신 선택지를 만든다 “세련되게 만들어줘”라는 지시는 에이전트가 검증하기 어렵다. 무엇이 세련된지 기준이 없고, 결과가 마음에 들지 않아도 어느 단계에서 어긋났는지 찾기 힘들다. 반면 컴포넌트 라이브러리와 단계별 산출물을 주면 작업이 조금 달라진다. 에이전트는 빈 화면에서 모든 결정을 새로 만들기보다, 이미 모아둔 선택지와 규칙 안에서 조합할 수 있다. 대니는 10년 동안 모은 4,000개가 넘는 컴포넌트 라이브러리를 MCP로 노출했다고 설명했다. 여기서 MCP는 단순한 파일 저장소가 아니다. 에이전트가 필요할 때 라이브러리를 검색하고, 적절한 조각을 불러오고, 자신의 결과물에 적용할 수 있는 통로다. 사람이 머릿속으로 알고 있던 “이런 느낌”을 검색 가능한 재료로 바꾼 셈이다. 이 방식의 장점은 재현성이다. 한 번 잘 나온 화면을 우연한 결과로 남기지 않고, 다음 작업에서도 다시 쓸 수 있는 참고 체계로 바꾼다. 에이전트가 매번 새로 만든 결과를 사람의 감으로 고치는 대신, 브랜드의 기준에 맞는 예시를 먼저 꺼내게 한다. ## 파일을 많이 만드는 것이 목적은 아니다 단계별 파일을 만든다고 해서 자동으로 좋은 디자인이 나오는 것은 아니다. 파일이 서로 다른 말을 하거나, 고객 정의와 실제 페이지가 따로 놀면 문서만 늘어난다. 각 파일이 다음 결정을 제한하는지 확인해야 한다. `customer_icp.md`가 페이지의 독자를 바꾸고, `brand_voice.md`가 문장을 바꾸고, `page_structure.md`가 화면의 순서를 바꿔야 한다. 컴포넌트 라이브러리도 마찬가지다. 에이전트가 기존 조각을 복사하는 것과 브랜드에 맞는 선택을 하는 것은 다르다. 라이브러리에는 좋은 예시뿐 아니라 사용하지 말아야 할 패턴, 제품별 예외, 선택 이유까지 붙어 있어야 한다. 그래야 에이전트가 “비슷해 보이는 것”과 “이 제품에 맞는 것”을 구분할 수 있다. 결국 에이전트에게 디자인 취향을 가르치는 일은 취향을 감정적으로 설명하는 일이 아니다. 어떤 고객을 위해, 어떤 순서로, 어떤 예시를 참고해, 어느 지점에서 사람이 검토할지 고정하는 일이다. 대니 포스트마의 실험은 그 기준을 4,000개가 넘는 컴포넌트와 MCP, 그리고 단계별 문서로 연결한 사례다. 다음에 에이전트에게 “좀 더 좋아 보이게”를 요청하기 전에 먼저 남길 것은 프롬프트 한 줄이 아닐 수 있다. 좋은 선택과 나쁜 선택이 쌓여 있는 라이브러리, 그리고 그 선택이 만들어지는 순서다. ### AI는 자기소개를 추천으로 읽는다 URL: https://zerodraftlab.com/citation-is-not-endorsement/ Last updated: 2026-09-15T08:35:17.000Z AI 검색의 출처 목록을 보다가 한 법무법인의 자체 사이트가 반복해서 잡힌 장면에 멈췄다. 남이 평가한 리뷰도, 공공기관 자료도 아니었다. 그 법무법인이 자기 업무를 설명해 둔 페이지였다. 이상하다고 단정할 일은 아니다. 이혼 절차, 상담 방식, 사무실 위치처럼 그 조직이 가장 정확하게 답할 수 있는 정보가 있다. 페이지가 잘 정리되어 있다면 AI가 가져다 쓰는 것도 자연스럽다. 그런데 같은 문장이 AI의 추천 답변 아래 작은 출처 표시로 이동하는 순간 문법이 달라진다. 법무법인 홈페이지에서 “우리는 이 분야에 전문성이 있습니다”라고 읽으면 사람은 자기소개로 받아들인다. 누가 말했는지가 화면에 붙어 있기 때문이다. 반면 AI가 여러 업체를 설명하는 답변의 출처 목록에 그 페이지를 놓으면, 문장은 외부 검증을 거친 근거처럼 보인다. 내용은 그대로인데 작성자와 평가 대상의 관계가 사라진다. **AI는 자기소개를 바꾸지 않았다. 자기소개가 놓인 자리를 바꿨다.** 출처 표식이 주는 안도감도 이 착시를 키운다. 링크가 있으면 출처를 추적할 수 있다는 사실은 맞다. 하지만 추적 가능하다는 것과 독립된 누군가가 보증했다는 것은 다른 말이다. 한 AI 인용 측정 서비스도 자사 방법론에서 인용 빈도가 검색엔진의 신뢰나 보증을 뜻하지 않는다고 명시한다. 인용은 우선 “이 문장이 어디에서 왔는가”에 답한다. “이 판단을 누가 독립적으로 확인했는가”까지 답하지는 않는다. 이 차이를 놓치면 정확한 자사 정보와 영리한 자기추천이 같은 외형을 갖는다. 둘 다 검색되고, 둘 다 요약되며, 둘 다 답변 아래 파란 링크 하나를 얻는다. 독자가 보는 것은 출처의 존재다. 사라진 것은 출처의 역할이다. 사라진 관계를 다시 붙여 보면 같은 사이트의 가치가 질문마다 달라진다. 영업시간을 묻는다면 공식 사이트는 가장 강한 증인이다. 가격과 환불 규정을 묻는다면 판매자가 직접 공개한 문서가 출발점이다. 그러나 “어디가 가장 좋은가”를 묻는 순간 자기소개 페이지의 자격은 바뀐다. 후보가 자신에 대해 말할 권리는 있지만, 자신을 1위로 판정할 독립성은 없기 때문이다. 이 문제는 거짓과 진실의 구분보다 까다롭다. 페이지의 모든 문장이 사실일 수 있다. 경력도 맞고, 제공 서비스도 맞고, 주소도 맞을 수 있다. 그래도 그 사실들의 묶음이 비교 우위를 증명하지는 않는다. 이력서는 지원자의 경력을 확인하는 자료이지만, 그 지원자가 최종 합격자여야 한다는 독립 평가서는 아닌 것과 같다. ## 검색은 관련성을 찾고, 사람은 증언으로 읽는다 일반적인 검색 증강 생성은 질문과 문서의 관련성을 중심으로 자료를 가져오며, 출처마다 다른 신뢰도를 놓칠 수 있다. 2025년 EMNLP 논문이 별도의 출처 신뢰도 추정 방식을 제안한 것도 이 간극 때문이다. 2023년 생성형 검색 감사 연구에서는 생성 문장의 51.5%만 인용으로 완전히 뒷받침됐고, 인용의 74.5%가 연결된 문장을 실제로 지지했다. 이 연구가 출처의 소유 관계까지 다룬 것은 아니지만, 링크가 붙었다는 이유만으로 검증을 끝낼 수 없다는 사실은 보여준다. 더 어려운 문제는 여러 링크가 여러 증인을 뜻하지 않는다는 데 있다. 같은 회사가 운영하는 본사이트, 별도 정보 사이트, 서브도메인 세 개가 한 답변에 등장하면 화면에는 출처가 다섯 개로 보일 수 있다. 그러나 소유 관계가 같고 주장도 같은 곳에서 왔다면 증인은 한 명이다. URL의 복수성은 합의의 독립성을 보장하지 않는다. 출발점이 된 관찰에서는 같은 뿌리의 여러 사이트가 별개 출처처럼 집계될 수 있다는 문제도 제기됐다. 그 특정 사례를 여기서 재현한 것은 아니다. 그래서 의도를 판정하는 대신 감사 단위를 바꿔야 한다. 링크 수를 세는 데서 멈추지 말고, 누가 소유하고 누구의 이해를 대변하는지 묶어 봐야 한다. 그래야 다섯 개의 출처인지 한 증인의 다섯 페이지인지 구분할 수 있다. ## 좋은 GEO는 자기소개를 숨기지 않는다 자사 사이트를 쓰지 말라는 뜻은 아니다. 운영시간, 가격, 절차, 제한, 담당자, 원자료처럼 자신이 가장 잘 증언할 수 있는 사실은 자사 사이트에 정확하고 구조적으로 남겨야 한다. AI가 읽을 수 있는 공식 기록이 없으면 오래된 블로그와 부정확한 요약이 빈자리를 차지한다. 경계는 자기소개를 제3자 평가처럼 위장하는 순간 생긴다. “2026년 최고의 업체”라는 비교표를 만들고 자신을 1위에 올리거나, 같은 소유자가 여러 매체인 것처럼 페이지를 나눠 합의를 연출하면 정보 구조화가 아니라 관계 은폐에 가까워진다. 반대로 작성 주체와 소유 관계를 드러내고, 자사 자료가 답할 수 없는 비교 판단은 고객 기록·공공 데이터·독립 시험처럼 다른 자격의 근거에 맡기면 출처는 역할을 되찾는다. AI 검색에서 가장 먼저 감사해야 할 숫자는 인용 횟수가 아니다. 한 문장을 지지하는 출처들이 실제로 서로 독립되어 있는가다. 다음에 추천 답변의 링크 세 개를 보게 되면 세 링크를 세 증인으로 계산하기 전에, 누가 누구에 대해 말하고 있는지부터 보자. 각주는 문장의 주소를 알려준다. 그 주소에 사는 사람이 증인인지 당사자인지는 여전히 우리가 확인해야 한다. --- 주요 참고: Citly, [측정 방법론](https://www.citly.co.kr/methodology?ref=zerodraftlab.com); Nelson Liu, Tianyi Zhang, Percy Liang, [Evaluating Verifiability in Generative Search Engines](https://aclanthology.org/2023.findings-emnlp.467/?ref=zerodraftlab.com); Jeongyeon Hwang 외, [Retrieval-Augmented Generation with Estimation of Source Reliability](https://aclanthology.org/2025.emnlp-main.1738/?ref=zerodraftlab.com); Rustem Kakimov 외, [Auditing Citation Behavior in AI-Generated Search Summaries](https://proceedings.mlr.press/v318/kakimov26a.html?ref=zerodraftlab.com). 출처 독립성·소유 관계에 관한 적용은 위 공개 방법론과 연구를 바탕으로 한 이 글의 해석이다. 원출발점인 소셜 캡처의 특정 수치와 서브도메인 사례는 독립적으로 재현하지 않았으므로 본문의 일반 명제를 입증하는 실측값으로 사용하지 않았다. ### 검색 트래픽은 고객이 아니다 URL: https://zerodraftlab.com/search-traffic-is-not-growth/ Last updated: 2026-09-15T08:35:18.000Z 검색 노출이 0에서 2,000으로 뛰고, 월 방문자가 3만 명을 넘는다. SEO 성과 사례에서 가장 자주 보이는 장면이다. 선이 가파르게 올라갈수록 반박하기 어려워 보인다. 그 그래프가 증명하는 것은 검색 결과에서 페이지가 더 자주 발견됐다는 사실이다. 그중 몇 명이 처음 온 고객인지, 예약을 지켰는지, 매출보다 큰 비용을 남기지 않았는지는 그래프 밖에 있다. [Google Search Console의 성과 보고서](https://support.google.com/webmasters/answer/7576553?hl=en&ref=zerodraftlab.com)가 기본으로 보여주는 숫자도 노출, 클릭, CTR, 평균 게재순위다. 제품 이름 그대로 검색 성과를 측정한다. 클릭한 사람이 신규 고객이 됐는지는 Search Console이 답할 질문이 아니다. 문제는 이 제한이 보고 과정에서 사라지는 데 있다. 검색 도구가 셀 수 있는 숫자가 SEO의 최종 성과로 승격된다. 노출은 클릭으로, 클릭은 세션으로, 세션은 문의로 이어지지만 보고서는 대개 가장 수집하기 쉬운 앞부분에서 끝난다. ## 전환은 설정한 곳에서 끝난다 GA4를 붙이면 한 단계 더 갈 수 있다. [Traffic acquisition report](https://support.google.com/analytics/answer/12923437?hl=en&ref=zerodraftlab.com)는 유입 채널별 세션, 참여, key event, 매출을 함께 볼 수 있다. 다만 key event는 사업자가 중요하다고 지정한 이벤트다. 문의 폼 제출을 key event로 정하면 보고서는 문의에서 성공을 선언한다. 오프라인 서비스에서는 문의와 고객 사이가 길다. 같은 사람이 폼과 전화로 두 번 문의할 수 있다. 예약한 뒤 취소하거나 나타나지 않을 수 있다. 기존 고객이 검색으로 전화했을 수도 있다. 방문했어도 수익이 거의 남지 않는 상품만 이용할 수 있다. 이 구간을 빼면 SEO 팀은 문의 수를 늘리는 데 성공하고 현장은 상담 피로만 떠안을 수 있다. 낮은 장벽으로 리드를 많이 모을수록 중복, 오문의, 가격 문의도 함께 늘어난다. 대시보드는 좋아졌는데 상담팀이 더 지치고 신규 고객은 그대로인 상황이 가능하다. 검색 트래픽은 고객이 아니다. 검색 트래픽은 고객이 될 가능성이 있는 사람이 페이지에 도착했다는 기록이다. 성장으로 부르려면 웹에서 끝난 기록을 현장의 결과와 연결해야 한다. 이 연결은 SEO 팀 혼자 만들 수 없다. SEO 팀은 검색어와 페이지를 고칠 수 있지만, 신규 여부와 방문 완료, 환불과 원가는 현장만 안다. 현장이 결과 데이터를 돌려주지 않으면 SEO 팀은 앞단의 대리 지표를 최적화할 수밖에 없다. 그렇다면 SEO 보고서의 마지막 줄에는 무엇이 있어야 할까? 마지막 줄을 정하려면 먼저 한 줄짜리 퍼널을 버려야 한다. 검색 노출에서 이익까지는 서로 다른 책임과 오류를 가진 네 개의 장부로 나뉜다. ## 검색 장부는 수요의 모양을 기록한다 첫 번째 장부에는 검색어, 페이지, 노출, 클릭을 둔다. 브랜드명을 이미 아는 사람이 들어온 검색과 아직 브랜드를 모르는 사람이 진료명·증상·문제로 찾은 검색도 나눈다. 브랜드 검색 증가는 의미가 있지만 SEO만의 획득 성과로 전부 가져오면 안 된다. 다른 광고, 입소문, 오프라인 노출이 먼저 브랜드를 알렸을 수 있기 때문이다. Search Console은 지원되는 속성에서 브랜드 검색과 비브랜드 검색을 분리해 볼 수 있게 한다. 이 구분은 신규 고객을 확정하지 않는다. 다만 기존 수요를 받아낸 것과 새로운 문제 검색에서 발견된 것을 같은 클릭으로 뭉개지 않게 한다. ## 행동 장부는 웹에서 생긴 의도를 기록한다 두 번째 장부에는 전화 버튼, 상담 신청, 예약 완료처럼 사용자가 남긴 행동을 둔다. 여기서는 숫자를 늘리기 전에 중복과 품질을 처리해야 한다. 동일 연락처의 반복 제출, 봇, 채용·영업 문의, 취소된 예약을 그대로 더하면 콘텐츠 성과가 아니라 입력창의 소음을 센다. GA4의 User acquisition과 Traffic acquisition도 범위가 다르다. 전자는 새 사용자가 처음 어디서 왔는지, 후자는 각 세션이 어디서 왔는지 본다. 한 사람이 처음에는 다른 채널로 브랜드를 알고 나중에 오가닉 검색으로 돌아왔다면 두 보고서의 답이 달라질 수 있다. 두 보고서는 서로 다른 질문에 답한다. ## 고객 장부는 실제 신규를 판정한다 세 번째 장부에서 예약은 방문으로 바뀌고, 방문자는 신규와 기존으로 갈린다. 오프라인 사업이 SEO를 성장 채널로 운영하려면 이 판정이 웹 분석 도구 밖의 CRM, 예약 시스템, POS 같은 운영 데이터에서 돌아와야 한다. 기술적으로 막힌 일만은 아니다. [GA4 Measurement Protocol](https://developers.google.com/analytics/devguides/collection/protocol/ga4?ref=zerodraftlab.com)은 서버 간 이벤트와 오프라인 상호작용을 Analytics로 보낼 수 있다고 설명한다. [Google Ads의 enhanced conversions for leads](https://support.google.com/google-ads/answer/15479486?hl=en&ref=zerodraftlab.com)도 웹 리드와 CRM의 오프라인 전환을 매칭하는 구조를 제공한다. 특히 민감한 서비스를 다룬다면 마케팅 시스템에는 판정에 필요한 최소 이벤트와 비식별 식별자만 남겨야 한다. 상담 내용이나 진료 정보가 성과 측정을 핑계로 광고 도구에 흘러가면 측정 정확도보다 큰 손실을 만든다. ## 이익 장부는 좋은 고객의 정의를 바꾼다 네 번째 장부에는 신규 고객 수와 함께 매출, 변동비, 환불, 채널 운영비를 둔다. 매출이 큰 서비스도 재료비와 전달 비용이 크면 기여이익은 작을 수 있다. 클릭당 비용이 없는 오가닉 검색도 무료가 아니다. 콘텐츠 제작, 개발, 외주, 내부 검수와 유지보수에 돈과 시간이 들어간다. Roland Rust와 동료들은 [마케팅 생산성의 사슬](https://doi.org/10.1509/jmkg.68.4.76.42721?ref=zerodraftlab.com)에서 마케팅 행동, 고객 반응, 시장 성과, 재무 효과를 연결해 봐야 한다고 제안했다. 동시에 마케팅이 브랜드와 고객 자산처럼 장기 자산을 만들 수 있다는 점도 포함했다. 당장 발생한 매출만으로 모든 콘텐츠를 자르면 장기 효과를 놓치고, 장기 효과를 핑계로 재무 결과를 영원히 미루면 책임이 사라진다. 그래서 SEO 보고서는 하나의 완벽한 귀속 숫자보다 두 종류의 결과를 나란히 보여주는 편이 낫다. 검색 장부에는 어떤 수요와 페이지가 커졌는지 남긴다. 사업 장부에는 그 기간 실제 신규 고객과 기여이익이 어떻게 변했는지 남긴다. 둘 사이에서 식별 가능한 문의와 예약만 연결하고, 연결되지 않는 부분은 억지로 SEO의 공으로 만들지 않는다. 월간 회의에서 필요한 질문도 달라진다. “트래픽이 얼마나 늘었나” 다음에 “어떤 검색 수요가 문의를 만들었나”, “그 문의 중 실제 신규는 몇 명이었나”, “그 신규가 남긴 기여이익은 얼마였나”를 차례로 묻는다. 연결이 끊긴 지점이 있으면 그 공백 자체가 다음 달의 측정 과제가 된다. 검색 노출과 클릭의 증가는 유통 성과다. 신규 고객과 기여이익까지 확인하면 그 유통이 사업 성과로 이어졌는지 판단할 수 있다. 두 숫자를 구분하는 조직만이 트래픽을 키울지, 전환을 고칠지, 상담 장벽을 높일지, 아예 다른 수요를 공략할지 결정할 수 있다. 실제 방문 데이터를 돌려받지 않는 SEO의 납품물은 성장보다 검색에서 출발한 가능성에 가깝다. --- 주요 출처: Google Search Console, [Performance report](https://support.google.com/webmasters/answer/7576553?hl=en&ref=zerodraftlab.com)와 [Common tasks and use cases](https://support.google.com/webmasters/answer/17010961?hl=en&ref=zerodraftlab.com); Google Analytics, [User acquisition report vs. Traffic acquisition report](https://support.google.com/analytics/answer/14731736?hl=en&ref=zerodraftlab.com)와 [Measurement Protocol](https://developers.google.com/analytics/devguides/collection/protocol/ga4?ref=zerodraftlab.com); Google Ads, [Enhanced conversions for leads](https://support.google.com/google-ads/answer/15479486?hl=en&ref=zerodraftlab.com); Roland T. Rust et al., [Measuring Marketing Productivity: Current Knowledge and Future Directions](https://doi.org/10.1509/jmkg.68.4.76.42721?ref=zerodraftlab.com). 이 글은 특정 병원의 SEO 성과가 거짓이라고 판단하지 않는다. 공개된 트래픽 그래프만으로 실제 신규 고객과 기여이익까지 증명할 수 없다는 측정 경계를 다룬다. ### 후기 플랫폼은 왜 지인을 이기지 못하는가 URL: https://zerodraftlab.com/reviews-cannot-beat-friends/ Last updated: 2026-09-15T08:35:18.000Z 성형 후기 커뮤니티에서 믿을 만한 정보를 묻던 대화는 뜻밖에 짧게 끝났다. 영수증 후기의 사진은 참고할 만하지만, 가장 좋은 방법은 시술을 많이 해본 지인을 두는 것이라는 답이었다. 작성자도 “사실 지인 찬스가 최고”라고 동의했다. 플랫폼에는 지인 한 명보다 훨씬 많은 정보가 있다. 수천 장의 사진, 병원별 평점, 시술명과 가격, 회복 과정이 쌓인다. 그런데 선택이 어려워질수록 사람들은 다시 주변에서 직접 경험한 사람을 찾는다. 정보의 양이 늘어도 신뢰가 같은 속도로 늘지는 않는다. 후기 플랫폼과 지인은 서로 다른 일을 한다. 플랫폼은 모르는 선택지를 발견하게 하고 여러 사례의 범위를 보여준다. 지인은 그 정보가 나와 얼마나 비슷한 조건에서 나왔는지 설명하고, 빠진 내용을 물어볼 수 있게 한다. 전자는 탐색에 강하고 후자는 해석에 강하다. ## 지인은 작은 표본이지만 대화할 수 있는 표본이다 재클린 브라운과 피터 레인젠은 1987년 입소문 추천이 실제 사회관계를 따라 어떻게 이동하는지 분석했다. 약한 관계는 서로 떨어진 집단 사이로 새로운 정보를 옮기는 데 중요했다. 반면 강한 관계는 추천 정보가 필요할 때 더 자주 활성화됐고, 사람들은 강한 관계의 말을 더 영향력 있게 받아들였다. 이 차이는 플랫폼과 지인의 장점을 함께 설명한다. 낯선 사람 수천 명의 후기는 내가 몰랐던 병원과 선택지를 발견하게 한다. 가까운 사람의 경험은 선택지가 좁혀진 뒤 더 큰 영향을 준다. 그 사람의 평소 기준, 통증을 견디는 정도, 비용 감각, 결과에 대한 기대를 이미 알고 있기 때문이다. 서비스 구매를 연구한 하비르 반살과 피터 보이어도 입소문의 영향이 발신자의 전문성뿐 아니라 관계의 강도와 정보를 얼마나 적극적으로 구했는지에 연결된다고 봤다. 의료처럼 결과를 구매 전에 확인하기 어렵고 되돌리기 힘든 선택에서는 “누가 좋다고 했는가”와 “왜 그 사람에게 물었는가”가 내용만큼 중요해진다. 지인의 정보가 자동으로 정확해지는 것은 아니다. 한두 번의 경험은 표본이 작고, 자기 선택을 합리화할 수 있으며, 친한 병원이나 의사를 감쌀 수도 있다. 지인의 우위는 객관성보다 수정 가능성에 있다. 애매한 표현을 다시 묻고, 사진 밖의 불편을 확인하고, 몇 달 뒤 평가가 바뀌었는지 들을 수 있다. 나쁜 추천이었다면 그 사람과 다시 마주친다. 여기서 관계 비용이 생긴다. 익명의 후기는 틀려도 작성자가 사라질 수 있지만, 지인은 다음 대화에서 이유를 설명해야 한다. 후기 플랫폼이 지인을 이기려면 후기 수를 늘리는 대신 이 책임의 구조를 제품 안에 만들어야 한다. 그 구조는 모든 작성자의 실명을 공개하는 방식과는 다르다. 성형, 질병, 정신건강처럼 민감한 경험에서는 익명성이 있어야 솔직한 정보가 나온다. 같은 사람이 시간에 걸쳐 남긴 말이 이어져야 한다. 플랫폼은 이해관계와 이용 여부를 확인하고, 나중의 질문과 수정도 같은 기록에 붙여야 한다. ## 온라인 신뢰도 사람의 흔적을 찾는다 크리스 포먼, 아닌디야 고스, 바티아 비젠펠트는 아마존 리뷰와 지역별 구매 데이터를 이용해 작성자의 신원 단서가 리뷰 판단에 미치는 영향을 살폈다. 이용자는 신원을 설명하는 정보가 담긴 리뷰를 더 긍정적으로 평가했고, 그런 정보의 공개는 이후 판매 증가와도 관련이 있었다. 같은 지역이라는 단서도 이 관계를 강화했다. 사람들은 리뷰를 쓴 사람의 생활 조건과 취향을 판단할 단서를 찾았다. “효과가 좋았다”는 문장보다 작성자의 기준을 알 수 있을 때 그 말을 내 상황에 맞게 번역할 수 있다. 전자 평판 장치는 이 관계 정보를 규모 있게 복원하려는 시도다. 게리 볼턴, 엘레나 카톡, 악셀 오켄펠스의 실험에서 온라인 피드백은 낯선 사람끼리 거래하는 시장의 효율을 크게 높였다. 하지만 같은 상대와 반복해서 거래하는 시장을 완전히 따라잡지는 못했다. 피드백을 남겨 생기는 신뢰의 이익은 공동체 전체가 누리지만, 피드백을 정확하게 남기는 비용은 개인이 부담하는 공공재 문제가 생겼다. 별점이 많아도 책임이 얇을 수 있는 이유다. 후기를 자세히 써서 다음 사람을 돕는 일, 몇 달 뒤 결과를 수정하는 일, 업체의 압력을 공개하는 일에는 시간이 든다. 그 기록이 작성자에게 돌아오는 이익은 작다. 반면 지인의 조언은 다음 만남과 자신의 평판으로 되돌아온다. ## 플랫폼은 말한 사람뿐 아니라 침묵한 사람도 봐야 한다 후기 플랫폼의 또 다른 약점은 올라온 글만 보여준다는 점이다. 크리산토스 델라로카스와 찰스 우드는 이베이 피드백을 분석하며 자발적 보고가 실제 거래 결과의 분포를 왜곡할 수 있다고 지적했다. 만족한 거래자가 불만족한 거래자보다 피드백을 더 자주 남긴다면, 화면의 높은 평점은 경험 전체의 평균이 아니다. 아무 말도 남기지 않은 거래가 얼마나 되는지도 정보다. 좋은 후기 시스템은 글의 숫자보다 기록의 분모를 보여줘야 한다. 실제 이용 건수 중 후기가 남은 비율, 작성 직후와 몇 달 뒤 평가의 차이, 혜택을 받은 후기의 비중이 함께 보여야 한다. 한 번 작성한 글을 박제하기보다 시간이 지나 평가를 갱신할 수 있어야 하고, 질문과 답변도 원래 경험에서 떨어져 나가지 않아야 한다. 이런 장치는 후기 생산량을 줄일 수 있다. 검증과 후속 기록은 귀찮고, 이해관계를 표시하면 클릭률이 낮아질 수도 있다. 그러나 마찰을 모두 제거한 플랫폼은 콘텐츠를 많이 모으는 대신 책임질 사람을 지운다. 후기 수는 늘지만 이용자는 마지막 결정을 다시 지인에게 가져간다. 지인 경험도 결론이 아니라 하나의 증거로 써야 한다. 플랫폼은 후보와 질문을 만들고, 지인은 개인 조건을 보정하며, 공식 정보와 전문가 상담은 확인 가능한 사실을 채운다. 서로 다른 출처가 같은 결론을 내는지보다 각 출처가 무엇을 알고 무엇에 책임지는지를 구분하는 편이 안전하다. 플랫폼이 지인보다 많은 경험을 모을 수는 있다. 그 경험에 시간, 맥락, 재질문과 수정 이력을 남길 때 낯선 사람의 말도 다시 확인할 수 있는 정보가 된다. --- 주요 참고: Jacqueline Johnson Brown, Peter H. Reingen, [Social Ties and Word-of-Mouth Referral Behavior](https://doi.org/10.1086/209118?ref=zerodraftlab.com); Harvir S. Bansal, Peter A. Voyer, [Word-of-Mouth Processes within a Services Purchase Decision Context](https://doi.org/10.1177/109467050032005?ref=zerodraftlab.com); Chris Forman, Anindya Ghose, Batia Wiesenfeld, [Examining the Relationship Between Reviews and Sales: The Role of Reviewer Identity Disclosure in Electronic Markets](https://doi.org/10.1287/isre.1080.0193?ref=zerodraftlab.com); Gary E. Bolton, Elena Katok, Axel Ockenfels, [How Effective Are Electronic Reputation Mechanisms?](https://doi.org/10.1287/mnsc.1030.0199?ref=zerodraftlab.com); Chrysanthos Dellarocas, Charles A. Wood, [The Sound of Silence in Online Feedback](https://doi.org/10.1287/mnsc.1070.0747?ref=zerodraftlab.com). 각 연구는 입소문 네트워크, 서비스 구매, 아마존 리뷰, 전자 거래 실험, 이베이 피드백을 다룹니다. 한국의 의료 후기 플랫폼에 대한 적용과 ‘관계 비용’이라는 해석은 이 글의 종합이며, 지인의 경험이 항상 정확하다는 뜻이 아닙니다. ### 진정성은 왜 점점 못 쓴 문장처럼 보이는가 URL: https://zerodraftlab.com/authenticity-looks-unpolished/ Last updated: 2026-09-15T08:35:19.000Z 광고 문장은 대개 너무 잘 쓴다. 제품명은 정확한 자리에 들어가고, 장점은 세 개로 정리되며, 불만조차 브랜드가 해결할 문제로 곱게 접힌다. 읽는 사람은 내용을 판단하기 전에 형식을 알아본다. “이건 나를 설득하려는 글이구나.” 반대편에는 오타가 있고 문장이 끊기며 사진의 수평도 맞지 않는 글이 있다. 작성자는 귀찮다는 듯 짧게 답하고, 굳이 제품명을 반복하지 않는다. 이런 글은 정보가 더 정확해서가 아니라 광고처럼 보이지 않아서 신뢰를 얻는다. 성형 후기 커뮤니티에서는 이 차이가 더 선명하다. 정돈된 칭찬은 대행사가 쓴 것처럼 의심받고, 불친절한 한 줄은 실제 환자가 남긴 말처럼 읽힌다. 병원 이름을 제대로 쓰지 않거나 결과를 무심하게 말하는 태도까지 진정성의 증거가 된다. 사람들은 “누가 광고를 이렇게 성의 없이 하겠어”라고 판단한다. 광고가 너무 매끈해진 시장에서는 서툼이 품질이 아니라 독립성의 대리 지표가 된다. ## 사람은 내용보다 먼저 설득의 흔적을 찾는다 메리언 프리스태드와 피터 라이트는 1994년 설득 지식 모델에서 소비자가 설득자의 목표와 전술에 관한 지식을 쌓고, 그것을 이용해 설득 시도에 대응한다고 설명했다. 광고를 많이 본 사람은 카피의 주장만 읽지 않는다. 이 문장을 누가 왜 썼는지, 어떤 반응을 끌어내려는지도 함께 본다. 문장이 매끄럽다는 사실 자체가 문제는 아니다. 그러나 매끄러운 문장, 균형 잡힌 사진, 빠짐없는 장점, 정확한 구매 링크가 한꺼번에 나타나면 그것들은 설득자의 흔적이 된다. 독자는 사실관계를 확인하기 전에 방어 자세부터 취한다. 비격식 문체가 효과를 내는 경우도 관찰된다. 2026년 《Journal of Retailing and Consumer Services》에 실린 연구는 약 140만 개의 인스타그램 게시물을 분석했고, 협찬 게시물에서 격식 있는 언어가 참여를 낮추는 반면 인터넷식 표현과 이모지는 참여를 높이는 경향을 보고했다. 이어진 실험에서는 지각된 진정성을 함께 살폈다. 이 결과를 “말을 막 쓰면 팔린다”는 처방으로 읽으면 곤란하다. 연구의 대상은 인스타그램 협찬 콘텐츠였고, 참여가 정보의 정확성이나 구매 후 만족을 뜻하지도 않는다. 중요한 점은 사람들이 문체를 발신자의 의도와 연결해 해석한다는 것이다. 자연스러운 말투는 내용을 운반하는 그릇이면서 상업적 통제를 덜 받았다는 신호로도 작동한다. 그리고 사람들이 어떤 표면을 독립적인 사람의 흔적으로 읽는지 알게 되는 순간, 그 표면은 제작 가능한 광고 자산이 된다. 크리스털 애비딘은 이 제작법을 ‘조율된 아마추어리즘(calibrated amateurism)’이라고 불렀다. 애비딘이 연구한 가족 인플루언서들은 일상의 사소한 장면을 공유했지만, 그 아마추어 같은 표면도 관심 경제 안에서 공들여 만들어졌다. 진짜 초보인지와 무관하게 플랫폼의 문법, 촬영 도구, 말투와 사회적 관계를 이용해 날것처럼 보이는 진정성을 생산했다. 요즘 광고 제작자는 완성도를 낮추는 일까지 정교하게 기획한다. 조명을 하나만 쓰고, 손으로 든 휴대전화가 조금 흔들리게 찍고, 자막의 맞춤법을 일부러 덜 다듬는다. 창업자는 회의 중 급히 적은 것 같은 문장으로 제품을 소개한다. 브랜드 계정은 고객센터의 말투 대신 운영자가 짜증 섞인 답변을 남기는 모습을 보여준다. 스크린샷에는 알림과 배터리 잔량을 남겨둔다. 이것들은 제작 실수가 아니라 제작된 실수다. 광고가 광고의 외형을 버리고 이용자의 외형을 빌리는 것이다. ## 결함은 진정성을 만들 수 있지만 진실을 보증하지 않는다 작은 결함이 진정성 인식에 영향을 주는 실험도 있다. 2023년 《Journal of Business Research》에 실린 연구는 가상 인플루언서의 작은 주근깨 같은 미적 결함이 심리적 거리를 줄이고 브랜드 진정성 인식을 높일 수 있다고 보고했다. 다른 맥락과 대상을 다룬 연구이므로 거친 문장 전체에 그대로 일반화할 수는 없다. 그래도 완벽함이 언제나 신뢰를 높이는 것은 아니라는 점은 보여준다. 문제는 결함을 만드는 비용이 너무 낮다는 데 있다. 오타 하나, 흐린 사진 한 장, 반말 한 줄은 누구나 복제할 수 있다. 생성형 AI에게 “광고 같지 않게, 약간 짜증 난 실제 사용자처럼”이라고 지시하는 데는 몇 초면 충분하다. 표면의 서툼이 널리 통하면 서툼을 연출하는 도구도 함께 퍼진다. 그 뒤에는 진정성의 군비 경쟁이 시작된다. 매끈한 광고를 의심하던 사람은 거친 광고까지 의심한다. 브랜드는 더 사적인 고백과 더 엉성한 화면을 꺼내고, 이용자는 더 강한 결함을 찾아야 안심한다. 진정성을 증명하려고 만든 표면이 늘어날수록 표면만으로 진정성을 판별하기 어려워진다. 그래서 진정성을 문체의 속성으로 보면 안 된다. 거친 말투는 누가 썼는지 추정하게 하는 단서일 뿐, 그 사람이 책임질 수 있는 말을 했다는 증거는 아니다. 실제 고객도 틀릴 수 있고, 무뚝뚝한 창업자도 과장할 수 있으며, 정돈된 공식 답변이 오히려 가장 정확할 때도 있다. ## 흉내 내기 비싼 신호를 봐야 한다 값싼 표면 대신 시간과 책임이 드는 신호를 확인해야 한다. 작성자가 예전에도 같은 기준으로 말했는지, 불리한 질문이 나온 뒤 답을 바꾸지 않았는지, 추천으로 생기는 이해관계를 공개했는지, 틀린 내용을 고치고 기록을 남겼는지 보는 것이다. 병원 후기라면 사진의 거친 질감보다 시간의 연속성이 중요하다. 수술 직후의 칭찬만 있는지, 회복 과정과 불편, 추가 진료가 이어지는지 봐야 한다. 창업자 글이라면 문장의 투박함보다 이전 약속과 제품 변경 기록이 맞물리는지가 중요하다. UGC 광고라면 촬영 방식보다 협찬 관계와 원본 계정의 이력을 먼저 확인해야 한다. 이런 신호는 한 번의 게시물로 만들기 어렵다. 말을 지키는 데는 시간이 들고, 잘못을 고치는 데는 평판 비용이 들며, 이해관계를 밝히면 단기 전환이 떨어질 수도 있다. 바로 그 비용 때문에 오타보다 믿을 만하다. 잘 쓴 문장을 의심하는 감각은 광고에 적응한 결과다. 못 쓴 문장을 믿는 감각도 곧 광고에 적응당한다. 이제 필요한 것은 더 날것 같은 표면이 아니라, 발신자가 나중에도 책임질 수밖에 없는 구조다. --- 주요 참고: Marian Friestad, Peter Wright, [The Persuasion Knowledge Model: How People Cope with Persuasion Attempts](https://doi.org/10.1086/209380?ref=zerodraftlab.com); Crystal Abidin, [#familygoals: Family Influencers, Calibrated Amateurism, and Justifying Young Digital Labor](https://doi.org/10.1177/2056305117707191?ref=zerodraftlab.com); Abhishek Kumar Jha, Ronak Singhania, Samrat Bagchi, [Stop Sabotaging Your Influencers: How Language Formality Undermines Engagement in Sponsored Content](https://doi.org/10.1016/j.jretconser.2025.104480?ref=zerodraftlab.com); Linxiang Lv 외, [Minor Flaws Are Better: The Positive Effect of Aesthetic Imperfection About Avatar Endorsers on Brand Authenticity](https://doi.org/10.1016/j.jbusres.2023.114125?ref=zerodraftlab.com). 각 연구는 설득 지식, 가족 인플루언서, 인스타그램 협찬 게시물, 가상 인플루언서의 미적 결함을 다룹니다. 성형 후기·창업자 글·UGC 전반에 대한 적용은 이 글의 해석이며, 거친 문체가 정확성이나 독립성을 보증한다는 뜻이 아닙니다. ### AI가 앱으로 가는 길을 다시 배분한다 URL: https://zerodraftlab.com/ai-redistributes-app-discovery/ Last updated: 2026-08-30T02:54:53.000Z 2026년 7월 26일, Pieter Levels는 인디해커들의 트래픽과 매출이 함께 내려가는 흐름이 보인다고 썼다. 자신의 제품에서도 같은 일이 벌어지고 있으며, “Big AI가 예전에 앱이 하던 모든 것을 잠식하고 있다”는 해석을 붙였다. > I'm seeing a trend here of declining revenue and traffic with indiehackers > > On my own projects too > > Maybe big VC products too but I wouldn't know cause they don't share revenue > > To me it seems clear BigAI is cannibalizing everything that used to be apps > > Not bad btw, just times… [https://t.co/SmOYCsxfMZ](https://t.co/SmOYCsxfMZ?ref=zerodraftlab.com) > > — @levelsio (@levelsio) [July 26, 2026](https://x.com/levelsio/status/2081372113307402730?ref%5Fsrc=twsrc%5Etfw&ref=zerodraftlab.com) 임베딩이 보이지 않으면 [X 원문](https://x.com/levelsio/status/2081372113307402730?ref=zerodraftlab.com)에서 볼 수 있다. 이 포스트가 인용한 사례는 Bannerbear 창업자 Jon Yongfook의 기록이다. Bannerbear는 마케팅 이미지와 영상을 자동 생성하는 API SaaS다. Yongfook은 2026년 7월 Google 추천 유입이 연초보다 거의 절반으로 줄었다고 공개했다. 사이트 유입이 줄자 가입과 유료 전환도 함께 내려갔다. 그는 단기 해법을 찾지 못했고 YouTube, 뉴스레터, 크리에이터 같은 다른 채널에 투자하겠다고 썼다. “그냥 콘텐츠를 쓰는” 전략의 효율도 예전 같지 않다고 판단했다. > Gotta talk about the good and the bad right? I noticed our signups / conversions are pretty weak this month. > > TLDR everything is downstream of us getting less traffic to the site. Our google referrals have basically halved this year (chart below). > > Makes sense, since even… [pic.twitter.com/jybKFEFZ5a](https://t.co/jybKFEFZ5a?ref=zerodraftlab.com) > > — Jon Yongfook (@yongfook) [July 26, 2026](https://x.com/yongfook/status/2081184546087944534?ref%5Fsrc=twsrc%5Etfw&ref=zerodraftlab.com) 임베딩이 보이지 않으면 [X 원문](https://x.com/yongfook/status/2081184546087944534?ref=zerodraftlab.com)에서 볼 수 있다. 이 숫자는 Bannerbear 한 회사의 내부 분석이다. 절대 방문자 수와 매출 감소 폭은 공개되지 않았고, Google 유입 감소의 원인이 AI라고 분해한 자료도 없다. 계절성, 검색 순위, 경쟁 제품, 제품 수요가 함께 영향을 줬을 수 있다. Levels의 포스트는 시장 통계가 아니라 여러 창업자가 체감하는 방향을 압축한 관찰로 읽어야 한다. ## 같은 창업자가 6년 전에는 콘텐츠를 성장의 중심에 뒀다 Yongfook의 기록이 좋은 이유는 비교할 과거가 남아 있기 때문이다. 그는 2020년 [첫 유료 고객을 얻은 과정](https://www.bannerbear.com/blog/how-to-get-your-first-25-saas-customers/?ref=zerodraftlab.com)을 공개했다. 블로그에 부트스트랩 과정을 쓰고, 뉴스레터 구독자 1,500명을 모으고, 제품 기능을 설명하는 글을 수십 편 발행했다. 마케팅 사이트의 콘텐츠도 천천히 늘렸다. 콘텐츠만으로 고객을 얻었다는 성공담은 아니었다. 제품을 여러 번 바꾸고, 커뮤니티에서 답하고, 고객에게 직접 연락하고, 기능을 개선하는 일이 함께 있었다. 2021년에는 월 반복매출 1만 달러에서 2만7천 달러로 성장한 해의 마케팅을 다시 정리했다. 이 글에서 [기술 콘텐츠를 더 많이 쓰지 못한 것을 아쉬워했고](https://www.bannerbear.com/blog/one-year-of-marketing-a-saas-from-10k-to-20k-mrr/?ref=zerodraftlab.com), Puppeteer와 FFmpeg를 다룬 글이 유기적 검색 유입을 만들었다고 설명했다. 튜토리얼 제작을 위해 전담 작가를 채용했고, 무료 도구를 Google 첫 페이지에 올렸으며, 블로그를 개편하고 Ahrefs로 검색 상태를 점검했다. 2021년의 공식은 선명했다. 창업자가 제품을 만들며 얻은 지식을 글로 남기면 같은 문제를 검색하는 사람이 발견하고, 그 사람이 문제를 대신 해결해주는 제품을 만난다. 2026년의 기록에서는 콘텐츠와 고객 사이의 배급 장치가 바뀌며 이 연결이 약해졌다. 콘텐츠의 지식과 신뢰 가치는 남아도 검색 유입 기능은 예전만 못했다. ## 검색 결과 안에서 질문이 끝난다 Pew Research Center는 2025년 3월 미국 성인 900명의 Google 검색 68,879건을 분석했다. [AI 요약이 나타난 검색](https://www.pewresearch.org/short-reads/2025/07/22/google-users-are-less-likely-to-click-on-links-when-an-ai-summary-appears-in-the-results/?ref=zerodraftlab.com)에서 일반 검색결과를 누른 비율은 8%였다. AI 요약이 없을 때의 15%보다 낮았다. AI 요약이 인용한 출처를 직접 누른 비율은 1%였고, 검색 뒤 브라우저 이용을 끝낸 비율은 26%로 AI 요약이 없을 때의 16%보다 높았다. 이 연구도 AI 요약의 순수한 인과효과를 증명하지는 않는다. AI 요약은 질문형 문장과 긴 검색어에서 더 자주 나타났고, 이런 검색은 원래 클릭 행동이 다를 수 있다. 다만 사용자가 출처 사이트에 들어가기 전에 Google 안에서 답을 소비하는 행동은 분명히 관찰됐다. 예전의 검색은 답을 찾을 후보를 배열했다. AI 요약과 대화형 검색은 후보를 읽고 답을 조립한다. “FFmpeg로 영상 위에 이미지를 어떻게 얹나”를 검색한 사람이 Bannerbear의 기술 글을 방문하던 흐름에서, 이제는 AI가 여러 글을 읽어 명령어와 코드를 먼저 내놓는다. 제품이 해결하는 문제까지 답변 안에서 끝나면 글에서 제품으로 이동할 이유도 줄어든다. ## AI는 방문을 없애기도 하고 새로 만들기도 한다 AI 유입을 무조건 제로클릭으로 보는 해석에는 반례가 있다. ChatGPT가 2026년 5월 7일 답변 속 브랜드 이름에 눈에 띄는 링크를 붙이자, [Similarweb의 데스크톱 패널](https://www.similarweb.com/blog/insights/ai-news/chatgpt-referral-traffic-triples/?ref=zerodraftlab.com)에서 일주일간 ChatGPT 추천 유입이 157.7% 늘었다. 브랜드 홈페이지로 향한 추천은 354.7% 증가했고, 전체 추천 중 홈페이지 도착 비중은 기존 26\~32%에서 약 60%로 올라갔다. 방문의 질도 달라졌다. 같은 조사에서 방문당 페이지 수는 3.8에서 4.7로, 평균 체류시간은 3.5분에서 3.9분으로 늘었다. 다만 조사 기간은 2026년 4월 30일부터 5월 20일까지로 짧고, Similarweb은 절대 유입량을 공개하지 않았다. 이 자료로 AI 추천이 Google 유입 손실을 얼마나 메웠는지는 판정할 수 없다. 다만 AI 제품의 링크 배치 하나가 웹사이트 유입의 양과 도착 지점을 크게 바꿀 수 있다는 점은 확인된다. 리테일에서는 전환까지 바뀌고 있다. [Adobe Digital Insights](https://business.adobe.com/uk/blog/recognition-not-preference-ai-search-measurement?ref=zerodraftlab.com)에 따르면 2026년 1분기 미국 소매 사이트의 AI 추천 유입은 전년 대비 393% 늘었다. 2026년 3월 AI 추천 방문자는 다른 경로의 방문자보다 전환율이 42% 높고, 방문당 매출은 37% 높았으며, 체류시간은 48% 길었다. 상품 비교를 대화 안에서 끝낸 사람이 구매에 가까운 상태로 사이트에 도착했기 때문이다. 소매 사이트의 결과이므로 부트스트랩 SaaS의 전환율로 옮겨 적을 수는 없다. 검색이 보내던 많은 방문은 줄어들 수 있다. 대신 AI가 선택한 브랜드에는 더 적고 더 가까운 방문이 올 수 있다. 문제는 그 배분권을 앱이 갖지 못한다는 데 있다. ChatGPT가 링크를 크게 만들면 유입이 늘고, 답변 안에서 작업을 끝내면 유입이 사라진다. ## 앱의 입구가 검색창에서 추천과 호출로 옮겨간다 OpenAI가 2025년 공개한 [ChatGPT Apps](https://openai.com/index/introducing-apps-in-chatgpt/?ref=zerodraftlab.com)는 이 변화가 유입을 넘어 제품 사용으로 이어지는 구조를 보여준다. 사용자는 Spotify에 재생목록을 만들어달라고 하거나 Canva에 슬라이드를 만들게 할 수 있다. ChatGPT는 대화 맥락에 맞는 앱을 먼저 제안할 수도 있다. 사용자가 제품 홈페이지를 방문해 메뉴를 배우기 전에, AI가 제품을 고르고 기능을 호출한다. 이 구조에서 콘텐츠의 역할도 바뀐다. 검색 결과에서 클릭을 얻는 글만으로는 부족하다. AI가 어떤 고객에게 제품을 추천해야 하는지 설명할 수 있도록 구체적인 사용 사례, 가격과 제약, 최신 문서, 고객이 확인할 수 있는 성과 증거가 필요하다. 실제 작업을 끝낼 API와 연동 경로도 제품의 배급면이 된다. 이 변화를 AEO나 GEO라는 이름의 새 프로젝트로 묶는 것만으로는 부족하다. Yongfook이 답글에서 “그게 실제로 무엇을 뜻하느냐”고 되물은 까닭도 여기에 있다. AI에게 잘 보인다는 목표만으로는 누가 어떤 질문에서 제품을 발견했고, 가입했으며, 돈을 냈는지 알 수 없다. 측정은 기존 퍼널과 새 퍼널을 한 화면에 놓는 데서 시작한다. Google 유입, AI 추천 유입, 직접 방문을 함께 보고 각각의 가입률과 유료 전환율을 연결한다. YouTube와 뉴스레터처럼 플랫폼이 답을 대신 써도 독자와 다시 만날 수 있는 채널도 따로 본다. 제품 문서와 API는 방문자를 많이 모으는 콘텐츠가 아니라 이미 선택한 고객과 에이전트가 일을 끝내는 경로로 평가한다. Bannerbear 사례만으로 앱의 종말을 선언할 수는 없다. 그러나 콘텐츠를 쌓으면 검색이 고객을 보내준다는 전제는 더 이상 안전하지 않다. 다음 분기의 콘텐츠 계획을 늘리기 전에 Google, AI 추천, 직접 방문이 실제 가입과 매출에 각각 얼마나 기여하는지부터 같은 표에서 확인해야 한다. --- 출처: Pieter Levels, [indiehacker traffic and revenue observation](https://x.com/levelsio/status/2081372113307402730?ref=zerodraftlab.com); Jon Yongfook, [Bannerbear Google referral update](https://x.com/yongfook/status/2081184546087944534?ref=zerodraftlab.com), [How to Get Your First 25 SaaS Customers](https://www.bannerbear.com/blog/how-to-get-your-first-25-saas-customers/?ref=zerodraftlab.com), [1 Year of Marketing a SaaS from $10K MRR to $27K MRR](https://www.bannerbear.com/blog/one-year-of-marketing-a-saas-from-10k-to-20k-mrr/?ref=zerodraftlab.com); Pew Research Center, [Google users are less likely to click on links when an AI summary appears](https://www.pewresearch.org/short-reads/2025/07/22/google-users-are-less-likely-to-click-on-links-when-an-ai-summary-appears-in-the-results/?ref=zerodraftlab.com); Similarweb, [ChatGPT Referral Traffic Near Triples Overnight](https://www.similarweb.com/blog/insights/ai-news/chatgpt-referral-traffic-triples/?ref=zerodraftlab.com); Adobe, [Why GEO Matters for Brand Visibility in AI Search](https://business.adobe.com/uk/blog/recognition-not-preference-ai-search-measurement?ref=zerodraftlab.com); OpenAI, [Introducing apps in ChatGPT](https://openai.com/index/introducing-apps-in-chatgpt/?ref=zerodraftlab.com). Big AI가 앱의 트래픽과 매출을 잠식한다는 표현은 Levels의 해석이며, 시장 전체에서 입증된 단일 인과결론으로 사용하지 않았다. ### 테스트를 만들던 팀은 왜 에이전트 관제실을 만들었나 URL: https://zerodraftlab.com/stably-testing-to-orca/ Last updated: 2026-07-26T14:57:19.000Z Orca의 제작사는 Y Combinator가 현재 [Stably AI (Orca)](https://www.ycombinator.com/companies/stably-ai-orca/jobs?ref=zerodraftlab.com)로 소개하는 샌프란시스코의 4인 팀이다. 2022년 창업해 YC W22를 거친 이 팀은 AI 테스트 제품 Stably를 운영하면서 오픈소스 에이전트 IDE Orca를 만들었다. [Stably AI (Orca) — Y CombinatorOrca를 만드는 YC W22 개발도구 회사의 현재 회사 정보와 창업자 소개![](https://www.ycombinator.com/favicon.ico)Y Combinatorycombinator.com](https://www.ycombinator.com/companies/stably-ai-orca/jobs?ref=zerodraftlab.com) ## 창업자는 Jinjing Liang과 Neil Parker다 YC 회사 페이지는 Jinjing Liang을 공동창업자 겸 CEO, Neil Parker를 창업자로 적는다. 약 1년 전 Stably의 YC Launch 글에서는 Liang이 Google Chrome의 테스트·릴리스 인프라를 만들었고, Parker가 Uber Safety 팀에서 대규모 머신러닝 프로젝트를 이끌었다고 소개했다. 이 경력은 회사가 직접 제출한 창업자 설명이므로, 독립적으로 검증된 이력이라기보다 Stably의 공식 소개로 읽는 편이 정확하다. 당시 Stably가 풀던 문제는 분명했다. PR과 릴리스를 검사하는 AI QA 엔지니어였다. 사람이 자연어로 테스트 의도를 적으면 Playwright 테스트를 만들고, 코드 변경에 맞춰 필요한 테스트를 골라 실행하며, 깨진 테스트를 고치는 제품을 내세웠다. PM과 QA도 코드를 직접 쓰지 않고 테스트에 참여하게 한다는 것이 초기 판매 논리였다. ## 테스트 제품은 지금도 살아 있다 Orca의 등장만 보고 Stably가 테스트 사업을 접고 완전히 피벗했다고 말하기는 이르다. 현재 [Stably 홈페이지](https://www.stably.ai/?ref=zerodraftlab.com)는 첫 화면에서 Orca를 “New from Stably”라고 소개한 뒤, 바로 아래에서 AI Test Builder와 CLI·Cloud 테스트 제품을 판매한다. 테스트 변경의 검토 가능성, 실행 기록, 승인과 감사 추적도 여전히 핵심 기능으로 제시한다. 현재 공개된 표면만 보면 두 제품을 병행하는 확장에 가깝다. Stably는 테스트를 만들고 유지하는 유료 제품이고, Orca는 Claude Code·Codex·Cursor CLI 같은 코딩 에이전트를 격리된 worktree에서 돌리는 MIT 오픈소스 개발 환경이다. 한 회사가 코드 작성 단계와 검증 단계를 각각 다른 제품으로 잡고 있다. ## 테스트 팀이 관제 도구를 만든 이유 여기부터는 Zero Draft Lab의 해석이다. 테스트 자동화를 오래 다룬 팀은 AI가 코드를 얼마나 빨리 쓰는지보다, 생성된 변경을 어떻게 격리하고 검토하며 실패를 되돌릴지 먼저 보게 된다. Stably가 강조해온 PR diff, Playwright, human-in-the-loop, reviewable change, audit trail은 Orca의 worktree, diff review, agent status와 자연스럽게 연결된다. 문제의 범위가 한 단계 넓어졌다. Stably는 에이전트가 만든 코드를 테스트한다. Orca는 그 코드를 만드는 여러 에이전트가 서로의 checkout을 덮어쓰지 않게 하고, 사람이 결과를 비교해 merge할 수 있게 한다. 테스트에서 익힌 통제 방식을 개발 작업 전체로 끌어올렸다는 해석이 가능한 이유다. 다만 회사가 이런 제품 전략을 공식적으로 설명한 자료는 아직 찾지 못했다. ## 브랜드와 법인은 구분해야 한다 사용자가 보는 이름은 Stably AI와 Orca지만, [Orca 이용약관](https://www.onorca.dev/terms?ref=zerodraftlab.com)은 서비스 제공 주체를 Lovecast Inc.로 적고 문의 주소를 `help@stably.ai`로 둔다. 브랜드는 Orca, 팀 표기는 Stably AI (Orca), 약관상 법인은 Lovecast Inc.로 나뉘어 있다. 현재 확인 가능한 팀 정보도 여기까지다. YC 페이지가 팀 규모를 4명으로 표시하지만, 창업자 둘 외 나머지 구성원의 최신 명단과 역할은 공식 페이지에서 확인되지 않는다. 공개 프로필을 모아 현재 재직자라고 단정하면 오히려 정확도가 떨어진다. ## 이 팀을 볼 때 남는 질문 Stably AI가 만드는 두 제품은 같은 문제의 앞뒤를 차지한다. Orca가 에이전트 작업을 늘리면 검토하고 테스트할 변경도 늘어난다. Stably의 테스트 제품은 그 다음 병목을 받는다. 오픈소스 Orca가 유료 테스트 제품의 유통 경로가 될지, 두 제품이 하나의 개발 운영 체계로 합쳐질지는 아직 공개 증거가 없다. 지금 확실히 말할 수 있는 답은 짧다. Orca는 Jinjing Liang과 Neil Parker가 세운 Stably AI 팀이 만들었다. 이 팀의 출발점은 AI 코딩 자체보다 소프트웨어 테스트와 릴리스 신뢰성이었다. 그래서 Orca의 중심에도 화려한 코드 생성보다 worktree 격리, 상태 확인, diff 검토가 놓여 있다. --- 주요 출처: Y Combinator, [Stably AI (Orca) 회사 페이지](https://www.ycombinator.com/companies/stably-ai-orca/jobs?ref=zerodraftlab.com)와 [Stably Launch](https://www.ycombinator.com/launches/NvN-stably-tests-every-code-change-like-your-best-engineer-would?ref=zerodraftlab.com); [Stably 공식 홈페이지](https://www.stably.ai/?ref=zerodraftlab.com); Orca, [Terms of Service](https://www.onorca.dev/terms?ref=zerodraftlab.com). 제품 사이의 연속성과 유통 전략에 관한 문단은 공개된 제품 구조를 바탕으로 한 Zero Draft Lab의 해석입니다. ### 커뮤니티를 소유하면 여론의 편집권도 소유한다 URL: https://zerodraftlab.com/community-owns-the-agenda/ Last updated: 2026-09-15T08:35:20.000Z 병원이 직접 운영하는 후기 커뮤니티가 있다고 하자. 운영자는 나쁜 후기를 삭제하지 않겠다고 약속한다. 직원이 환자인 척 글을 쓰지도 않는다. 올라온 문장을 손대지 않는다는 약속만 지키면 이곳은 중립적인 커뮤니티가 될까. 운영자는 문장을 고치지 않고도 여론을 편집할 수 있다. 첫 화면에 어떤 게시물을 놓을지, 인기 글을 무엇으로 계산할지, 어떤 카테고리를 먼저 보여줄지, 신고된 글을 검토하는 동안 숨길지, 새 회원에게 무엇을 물을지 정한다. 검색 결과와 알림도 운영자가 만든 순서대로 움직인다. 커뮤니티의 편집권은 삭제 버튼보다 넓다. 무엇이 남아 있는지와 무엇이 먼저 보이는지를 함께 결정한다. ## 판매자가 광장의 설계자까지 맡는다 병원 커뮤니티에는 서로 다른 역할이 한곳에 겹친다. 병원은 서비스를 판매하고, 게시 규칙을 만들고, 노출 순서를 정하며, 이용자의 질문과 관심 데이터를 본다. 커뮤니티가 활발해질수록 병원은 사람들이 무엇을 걱정하고 어떤 표현에 반응하는지도 더 정확히 알게 된다. 독립 커뮤니티에도 운영자의 취향과 상업적 이해관계는 들어간다. 병원 소유 커뮤니티에서는 편집 결과와 매출 결과가 같은 조직 안으로 돌아온다. 어떤 후기 범주가 커지고 작아지는지가 예약과 상담으로 연결된다. 악의를 입증하지 않아도 이해상충은 성립한다. 판매자와 편집자가 같은 주체이기 때문이다. 이 구조에서 모든 후기가 거짓일 필요는 없다. 실제 환자가 자기 경험을 사실대로 쓸 수 있다. 운영자가 개입하지 않은 비판도 남아 있을 수 있다. 그래도 독자는 보이는 글이 전체 경험을 얼마나 대표하는지 알기 어렵다. 광장을 운영하는 주체가 그 광장에서 선택되는 상품의 판매자이기 때문이다. 맥스웰 매컴스와 도널드 쇼는 1972년 의제 설정 연구에서 언론이 뉴스를 선택하고 배치하는 방식에 주목했다. 사람은 기사에서 어떤 쟁점이 존재하는지만 배우지 않는다. 정보의 양과 위치를 보며 어떤 쟁점이 중요한지도 판단한다. 이 연구는 선거 보도와 유권자를 다뤘지만, 선택과 배치가 중요도의 감각을 만든다는 관찰은 커뮤니티 화면에도 이어진다. 예를 들어 첫 화면에 만족 후기와 회복 일지만 반복해서 뜨고 부작용, 재수술, 환불 경험은 별도 메뉴 깊숙한 곳에 모여 있다면 운영자는 비판을 삭제하지 않아도 된다. 모든 글이 살아 있다는 사실과 모든 글이 비슷하게 발견될 수 있다는 사실은 다르다. ## 보이지 않는 편집은 기록도 남기지 않는다 종이 잡지의 편집은 목차와 지면에 드러난다. 온라인 커뮤니티의 편집은 추천순, 인기순, 검색 가중치, 알림 발송 같은 기능 속에 들어간다. 독자는 게시물이 왜 자기 앞에 왔는지 모른 채 그것을 커뮤니티의 자연스러운 관심사로 받아들이기 쉽다. 페이스북 연구진이 포함된 한 연구는 68만 9,003명의 뉴스피드에서 긍정적이거나 부정적인 표현이 담긴 게시물의 노출을 줄였다. 이후 이용자가 쓰는 감정 단어에도 작지만 통계적으로 유의한 변화가 나타났다. 효과 크기는 작았고 연구 절차는 큰 윤리 논쟁을 불렀다. 동시에 이 실험은 게시물을 새로 만들지 않고 노출량만 바꿔도 이용자의 표현이 달라질 수 있음을 보여줬다. 커뮤니티 소유권을 밝히는 표시는 필요하다. 그러나 화면 아래의 “이 커뮤니티는 ○○병원이 운영합니다”라는 문장만으로는 누가 인기순을 설계했고 무엇이 숨겨졌는지 알 수 없다. 소유 관계를 공개한 다음에는 편집 방식도 설명해야 한다. 편집 방식을 공개할 때 알고리즘 코드를 전부 내놓을 필요는 없다. 이용자가 체감하는 규칙부터 말하면 된다. 인기 글은 조회수, 댓글, 저장, 운영자 추천 중 무엇으로 정해지는가. 신고된 글은 검토 전부터 가려지는가. 병원 직원과 대행사 계정은 표시되는가. 검색 결과에서 공식 답변과 이용자 경험은 어떻게 구분되는가. 에이탄 박시, 솔로몬 메싱, 라다 아다믹은 미국 페이스북 이용자 1,010만 명이 정치 뉴스를 접하는 과정을 분석했다. 친구가 공유한 글, 알고리즘으로 정렬된 뉴스피드에서 실제로 본 글, 이용자가 클릭한 글을 나눠 비교했다. 알고리즘 정렬은 반대 성향 콘텐츠의 노출을 줄였지만 이용자의 선택이 미친 영향은 더 컸다. 이 결과는 알고리즘이 사람을 마음대로 조종한다는 주장과 거리가 있다. 노출 구조와 이용자의 선택이 함께 결과를 만든다. 그래서 운영자는 “이용자가 좋아한 글을 보여줬을 뿐”이라고 말할 수 있고, 이용자는 “많이 보이니 중요한 글이라고 생각했을 뿐”이라고 말할 수 있다. 두 반응이 맞물리면 처음 정한 배치 기준이 이용자의 선택으로 강화된다. ## 후기 조작보다 넓은 문제가 있다 미국 연방거래위원회는 2023년 개정한 추천·후기 지침을 설명하며 후기를 구매하거나 삭제하는 행위만 다루지 않았다. 소비자의 인식을 왜곡하도록 후기를 모집하고, 억누르고, 밀어 올리고, 배열하고, 게시하고, 추천·비추천하고, 편집하는 행위까지 문제의 범위에 넣었다. 직원 후기와 이해관계 공개도 별도로 다뤘다. 이 지침을 한국 병원에 그대로 적용할 수 있다는 뜻은 아니다. 참고할 만한 대목은 규제기관도 후기의 진실성을 개별 문장만으로 보지 않는다는 점이다. 후기의 수집과 배열, 가시성까지 소비자의 판단을 구성한다. 유럽연합의 디지털서비스법도 추천 시스템을 쓰는 온라인 플랫폼에 주요 매개변수와 이용자가 그 매개변수에 영향을 줄 수 있는 선택지를 알기 쉬운 말로 설명하도록 요구한다. 대형 플랫폼과 작은 병원 커뮤니티의 규모와 법적 의무는 같지 않다. 여기서 가져올 만한 관점은 추천과 배열에도 설명 책임이 따른다는 점이다. ## 운영권과 증언의 독립성을 분리해야 한다 병원이 커뮤니티를 운영하는 일에는 실용적인 가치가 있다. 환자는 공식 답변을 빨리 받을 수 있고 병원은 반복되는 질문을 발견해 안내를 고칠 수 있다. 이 장점을 살리려면 병원의 공식 설명과 이용자의 증언이 같은 목소리로 섞이지 않게 해야 한다. 직원과 대행사 계정에는 이해관계가 보이게 표시돼야 한다. 삭제·숨김·복구 기준과 처리 건수를 남기고, 인기순만 강제하지 말고 최신순과 전체 검색을 제공해야 한다. 부작용이나 분쟁 카테고리를 찾기 어렵게 만들지 않아야 한다. 운영 결정에 이의를 제기할 통로도 병원 내부 민원 창구와 분리할 필요가 있다. 독자가 확인해야 할 것은 비판 글의 존재만이 아니다. 비판이 올라오고, 발견되고, 반응을 얻고, 운영자에게 불편해진 뒤에도 같은 규칙 아래 남을 수 있는지가 더 중요하다. 그 과정을 확인할 방법이 없다면 조용한 커뮤니티는 높은 만족도를 증명하지 못한다. 판매자가 커뮤니티를 소유하는 순간 판매 공간과 증언 공간의 경계가 흐려진다. 그 경계를 다시 보이게 만드는 책임은 게시물을 쓴 이용자가 아니라 편집권을 가진 운영자에게 있다. --- 주요 참고: Maxwell E. McCombs, Donald L. Shaw, [The Agenda-Setting Function of Mass Media](https://doi.org/10.1086/267990?ref=zerodraftlab.com); Adam D. I. Kramer, Jamie E. Guillory, Jeffrey T. Hancock, [Experimental Evidence of Massive-Scale Emotional Contagion Through Social Networks](https://doi.org/10.1073/pnas.1320040111?ref=zerodraftlab.com); Eytan Bakshy, Solomon Messing, Lada A. Adamic, [Exposure to Ideologically Diverse News and Opinion on Facebook](https://doi.org/10.1126/science.aaa1160?ref=zerodraftlab.com); 미국 연방거래위원회, [Updated Endorsement Guides](https://www.ftc.gov/news-events/news/press-releases/2023/06/federal-trade-commission-announces-updated-advertising-guides-combat-deceptive-reviews-endorsements?ref=zerodraftlab.com); 유럽연합, [Digital Services Act Article 27](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32022R2065&ref=zerodraftlab.com). 위 연구와 규정은 선거 보도, 페이스북 뉴스피드, 후기·추천, 대형 온라인 플랫폼을 다룹니다. 병원 소유 커뮤니티에 대한 적용은 의제 설정과 가시성 통제라는 공통 구조를 바탕으로 한 이 글의 해석입니다. ### AI가 읽는 문서로는 부족하다 URL: https://zerodraftlab.com/agent-writable-docs/ Last updated: 2026-07-26T14:52:48.000Z AI가 문서를 읽게 만드는 일은 이제 어렵지 않다. HTML 옆에 Markdown을 내놓고, `llms.txt`에 문서 목록을 적으면 된다. Cloudflare가 공개한 [Nimbus](https://github.com/cloudflare/nimbus?ref=zerodraftlab.com)는 그 다음 문제를 다룬다. 에이전트가 문서를 읽은 뒤 실제로 고치고, 빌드하고, 검증하게 하려면 문서 사이트가 어떤 구조여야 하는가. [cloudflare/nimbusDocs for humans and agents, built on Astro![](https://github.githubassets.com/favicons/favicon.svg)GitHubcloudflare/nimbus![](https://opengraph.githubassets.com/1/cloudflare/nimbus)](https://github.com/cloudflare/nimbus?ref=zerodraftlab.com) Nimbus의 대답은 소스 소유권이다. 레이아웃, 컴포넌트, 스타일, 라우트, 콘텐츠를 프로젝트 안의 실제 파일로 만든다. 프레임워크는 보이지 않는 배관만 패키지로 제공한다. 화면에서 보이는 요소가 외부 테마의 import 경계 뒤에 숨지 않으니 사람과 코딩 에이전트가 같은 저장소를 보고 수정할 수 있다. ## 읽기 좋은 문서와 고치기 좋은 문서는 다르다 Nimbus 사이트는 각 페이지의 `.md` 또는 `.mdx` 버전, 사이트 전체 색인인 `llms.txt`와 `llms-full.txt`, JSON-LD, 사이트맵을 기본으로 만든다. 검색 결과나 에이전트가 브라우저 화면을 긁지 않아도 문서의 본문과 구조를 가져갈 수 있다. 여기까지는 AI가 읽을 수 있는 문서다. Nimbus의 [설계 철학](https://nimbus-docs.com/philosophy/?ref=zerodraftlab.com)은 유지보수까지 범위를 넓힌다. 에이전트가 페이지를 추가하려면 어느 파일을 고쳐야 하는지, 변경이 다른 레이아웃과 충돌하지 않는지, 빌드 뒤 어떤 검사를 통과해야 하는지까지 볼 수 있어야 한다. 문서가 답변용 데이터에서 작업 가능한 코드베이스로 바뀐다. 차이는 문서가 낡았을 때 드러난다. 읽기 전용 표면은 에이전트에게 오래된 답을 더 잘 전달한다. 수정 가능한 표면은 에이전트가 원문을 고치고, 링크와 구조를 검사하고, 실패한 빌드를 근거로 다시 수정하게 한다. 문서 품질의 병목이 검색에서 변경과 검증으로 이동한다. ## 기능을 설치하는 방식도 달라진다 Nimbus의 CLI는 단순한 파일 복사와 에이전트 작업을 구분한다. 컴포넌트처럼 결과가 정해진 항목은 소스 파일로 복사한다. 새 버전 문서나 404 페이지처럼 프로젝트 맥락을 읽어야 하는 기능은 Markdown 실행 절차를 에이전트에게 넘긴다. 에이전트는 기존 설치 여부를 확인하고, 변경 계획을 세우고, 파일을 수정한 뒤 빌드로 검증한다. 문서 린터도 같은 방향을 따른다. 단일 H1, 맨 URL, 링크 문구 같은 규칙에 안정적인 식별자를 붙이고 JSON 진단을 출력한다. 사람이 읽는 경고문과 에이전트가 처리하는 오류 형식이 따로 놀지 않는다. 콘텐츠 스키마에는 작성 주체와 인간 검토 여부 같은 provenance를 넣을 수 있다. 에이전트가 글을 쓰는 순간 생기는 “누가 만들었고 사람이 확인했는가”라는 질문을 문서 바깥의 관행이 아니라 데이터로 남긴다. ## 소스를 소유하면 업그레이드도 소유한다 이 설계의 비용은 명확하다. 테마가 대신 관리하던 레이아웃과 컴포넌트를 내 저장소로 가져오면 수정 자유와 함께 유지보수 책임도 따라온다. 보안 수정이나 접근성 개선이 상위 패키지 하나를 올리는 것으로 끝나지 않을 수 있다. Nimbus도 현재 상태를 pre-1.0이라고 밝히며, minor release 사이에도 공개 표면이 바뀔 수 있으니 버전을 고정하고 changelog를 확인하라고 권한다. 지금은 안정된 표준보다 빠르게 움직이는 설계 제안에 가깝다. 에이전트 경계에도 거친 부분이 남아 있다. 현재 starter는 코딩 에이전트 안내 파일을 [AGENT.md](https://github.com/cloudflare/nimbus/blob/main/packages/nimbus-starter-source/AGENT.md?ref=zerodraftlab.com)라는 단수 이름으로 만든다. 이를 표준 이름인 `AGENTS.md`로 바꾸자는 [이슈 #38](https://github.com/cloudflare/nimbus/issues/38?ref=zerodraftlab.com)은 닫혔지만 scaffold에는 아직 반영되지 않았다. 기본 설정의 `site` 값도 [https://example.com](https://github.com/cloudflare/nimbus/blob/main/packages/nimbus-starter-source/astro.config.ts?ref=zerodraftlab.com)이므로, 그대로 빌드하면 canonical URL과 사이트맵이 잘못된 주소를 품을 수 있다. 기능을 에이전트용 실행 절차로 전달하는 방식은 신뢰 경계도 바꾼다. 패키지 코드를 검토하는 것만으로는 부족하다. 어떤 registry에서 어떤 절차를 받았는지, 실행 전에 사람이 무엇을 확인하는지, 적용 뒤 어떤 검증을 남기는지까지 운영 규칙이 필요하다. ## 프레임워크보다 먼저 가져올 네 가지 Nimbus로 전면 이주하지 않아도 핵심 설계는 기존 문서 시스템에 넣을 수 있다. 모든 페이지에 원문과 가까운 Markdown 표면을 제공하고, 전체 문서를 한 번에 찾을 수 있는 색인을 만든다. 작성 주체와 검토 상태를 스키마에 남기고, 문서 규칙을 사람이 읽는 가이드에서 기계가 판정하는 린트로 옮긴다. 이 네 가지가 갖춰지면 에이전트는 문서를 답변의 재료로만 쓰지 않는다. 어떤 파일을 바꿨는지, 왜 바꿨는지, 무엇을 통과했는지 남기며 문서의 수명주기에 참여할 수 있다. 도입 판단도 좁게 할 수 있다. 새 문서 프로젝트 하나에서 에이전트에게 페이지 추가와 링크 수정, 빌드 검증까지 맡겨본다. 사람이 맥락을 다시 설명한 시간, 실패를 찾은 검사, 변경 근거를 추적하는 시간을 잰다. 이 세 가지가 줄지 않는다면 agent-first라는 이름과 관계없이 운영 개선은 일어나지 않은 것이다. --- 주요 출처: Cloudflare, [Nimbus 공개 저장소와 README](https://github.com/cloudflare/nimbus?ref=zerodraftlab.com); Nimbus, [Philosophy](https://nimbus-docs.com/philosophy/?ref=zerodraftlab.com); Nimbus, [Agent surfaces](https://nimbus-docs.com/ai/agent-surfaces/?ref=zerodraftlab.com); Nimbus, [CLI](https://nimbus-docs.com/cli/?ref=zerodraftlab.com). 문서를 “읽기 표면”에서 “변경·검증 표면”으로 확장해야 한다는 해석, registry 기반 실행 절차의 신뢰 경계, 좁은 파일럿 제안은 Zero Draft Lab의 분석입니다. ### 제목을 이기면 본문이 따라온다 URL: https://zerodraftlab.com/title-before-writing/ Last updated: 2026-07-26T14:00:09.000Z Matt Gray가 2026년 7월 25일 올린 포스트는 세 문장뿐이다. 콘텐츠에서 가장 큰 기회는 제작에 들어가기 전이고, 주제와 제목이 약하면 카메라 앞에서 아무리 잘해도 소용없으며, 제목을 이기면 영상이 따라온다는 주장이다. > The biggest opportunity in your content is pre-production. > > If the title and topic are weak, it doesn't matter how good you are on camera. > > Win the title. The video follows. > > — MATT GRAY (@matt\_gray\_) [July 25, 2026](https://x.com/matt%5Fgray%5F/status/2080987464110395800?ref%5Fsrc=twsrc%5Etfw&ref=zerodraftlab.com) 임베딩이 보이지 않으면 [X 원문](https://x.com/matt%5Fgray%5F/status/2080987464110395800?ref=zerodraftlab.com)에서 볼 수 있다. 원문은 영상에 관한 말이다. 이를 글쓰기에 옮기면 제목을 본문 전에 주제의 품질을 확인하는 가장 싼 시험으로 쓸 수 있다. 여기서부터는 Zero Draft Lab의 해석이다. ## 제목은 주제를 압축하는 테스트다 아이디어는 머릿속에 있을 때 대개 그럴듯하다. “AI와 콘텐츠의 미래”, “생산성을 높이는 방법”, “요즘 마케팅의 변화” 같은 주제는 넓어서 무엇이든 담을 수 있다. 바로 그 점 때문에 아직 글이 아니다. 독자가 무엇을 새로 알게 되는지, 어떤 판단이 바뀌는지, 왜 지금 읽어야 하는지가 정해지지 않았다. 제목을 먼저 쓰면 이 빈칸이 드러난다. 구체적인 대상과 변화, 이해관계가 한 문장에 들어가지 않으면 주제가 덜 익었을 가능성이 크다. 단어를 화려하게 바꿔도 해결되지 않는다. 문장이 나오지 않을수록 주장이 비어 있는지 봐야 한다. 예를 들어 “코딩 에이전트 오르카 소개”는 대상을 말하지만 독자가 얻을 판단은 말하지 않는다. “코딩 에이전트 여러 대를 돌리면 IDE보다 관제실이 필요하다”는 운영 조건과 결론을 함께 건다. 이제 본문이 해야 할 일도 선명해진다. 여러 에이전트를 동시에 돌릴 때 기존 IDE가 어디서 부족한지, 관제실이라는 비유가 어떤 기능으로 이어지는지 증명하면 된다. ## 본문부터 쓰면 약한 주제에도 애착이 붙는다 제목을 나중으로 미루면 빈 문서에서 생각을 찾게 된다. 자료를 모으고 문단을 늘리다 보면 어느새 천 자, 이천 자가 쌓인다. 그때 주제가 약하다는 사실을 발견해도 버리기 어렵다. 이미 들인 시간을 설명하기 위해 제목을 더 세게 포장하고, 본문은 그 약속을 따라가지 못한다. 사전 제작의 경제성은 여기서 나온다. 약한 제목 열 개를 버리는 비용은 작다. 약한 주제로 쓴 본문 한 편을 버리는 비용은 크다. 제목 단계에서 실패하면 단어 몇 줄을 잃는다. 본문 단계에서 실패하면 조사와 구성, 편집에 쓴 시간을 함께 잃는다. ## 문서를 열기 전에 제목 열 개를 쓴다 Matt Gray의 세 문장을 글쓰기 절차로 옮기면 복잡한 기획표가 필요하지 않다. 먼저 독자가 글을 읽은 뒤 가져가야 할 판단을 한 문장으로 적는다. 그 문장을 서로 다른 각도에서 제목 열 개로 바꿔본다. 넓은 명사와 분위기만 남은 제목은 지우고, 구체적인 대상과 변화가 보이는 제목만 남긴다. 마지막에는 제목 하나만 보고 세 가지를 확인한다. - 무엇에 관한 글인지 명사를 집어 말할 수 있는가. - 본문이 증명해야 할 주장이 들어 있는가. - 그 주장이 맞다면 독자의 판단이나 행동이 달라지는가. 세 질문에 답하지 못하면 문장 수정을 멈추고 주제로 돌아간다. 제목 후보가 모두 비슷한 추상어를 맴돈다면 소재부터 다시 고른다. ## 좋은 제목은 클릭보다 약속을 관리한다 제목을 먼저 쓴다는 말은 자극적인 문구를 먼저 고르라는 뜻이 아니다. 제목이 본문보다 강하면 클릭은 얻어도 신뢰를 잃는다. 사전 제작에서 고른 제목은 독자에게 건 약속이면서 작성자가 따라갈 작업 명세다. 본문의 사례와 근거, 반론은 그 약속을 지키기 위해 존재한다. 그래서 제목을 먼저 정하면 글의 끝도 보인다. 제목의 주장을 충분히 증명한 지점에서 멈출 수 있고, 관련 있어 보인다는 이유로 붙인 문단을 걷어낼 수 있다. 좋은 제목은 독자를 데려오는 문구인 동시에 본문이 옆길로 새지 않게 하는 경계다. 제목 하나를 고른 뒤 문서를 연다. 열 개를 써도 살아남는 제목이 없다면 본문을 시작하지 않는다. 주제를 다시 고르는 편이 천 문장을 고치는 것보다 싸다. --- 출처: Matt Gray, [“The biggest opportunity in your content is pre-production”](https://x.com/matt%5Fgray%5F/status/2080987464110395800?ref=zerodraftlab.com), 2026년 7월 25일. 제목을 주제의 사전 검사와 작업 명세로 사용하는 해석, 오르카 제목 사례, 제목 열 개와 세 가지 확인 질문은 Zero Draft Lab의 분석과 제안입니다. ### 거절보다 비싼 것은 보내지 않은 부탁이다 URL: https://zerodraftlab.com/cost-of-not-asking/ Last updated: 2026-09-15T08:35:20.000Z 오후 4시 47분, 한 팀장은 전 직장 상사에게 보낼 메시지를 지웠다. 새로 열린 사업 책임자 자리에 관심이 있는데 담당자를 소개해달라는 부탁이었다. 너무 오랜만에 연락하는 것 같았고, 상대가 곤란해할 것 같았다. 메시지는 임시 저장함에도 남지 않았다. 거절 답장은 오지 않았다. 부탁을 보내지 않았기 때문이다. 이 가상의 장면에서 손실은 조용하다. 거절은 기억에 남지만 보내지 않은 부탁은 기록조차 되지 않는다. 우리는 상처받은 몇 번을 근거로 앞으로 받을 거절을 예측하고, 소개·협상·피드백·기회의 문을 스스로 닫는다. 그래서 삶에서 놓친 기회 가운데 얼마나 많은 것이 타인의 거절이 아니라 자신의 사전 거절에서 사라졌는지 계산하기 어렵다. Prompter가 X에 올린 Claude Opus 5 답변은 “인생을 크게 바꿀 최고의 비전통적 생활 기술”을 묻는 질문에 도발적인 처방을 내놓았다. 거절당할 것이라고 꽤 확신하는 부탁을 일부러, 자주 하라는 것이다. 얼핏 보면 낯가림을 이겨내라는 흔한 조언처럼 들린다. 이 답변이 흥미로운 이유는 용기보다 예측 오류를 근거로 들었다는 데 있다. ## 우리는 부탁의 수락률을 실제보다 낮게 잡는다 Francis J. Flynn과 Vanessa K. B. Lake(Bohns)는 2008년 직접적인 도움 요청을 사람들이 얼마나 받아들일지 예측하는 연구를 발표했다. 실험실과 자연스러운 현장 상황을 포함한 첫 세 연구에서 참가자들은 타인이 도움 요청에 응할 가능성을 최대 50%까지 과소평가했다. 부탁하는 사람은 상대가 치러야 할 시간과 수고, 즉 “예”의 비용에 집중했다. 부탁받는 사람에게는 거절하며 느끼는 어색함과 죄책감, 즉 “아니요”의 비용도 있었다. 이 연구가 모든 부탁의 절반은 성공한다는 뜻은 아니다. 모든 문화와 관계, 요청의 크기에 같은 수치를 적용할 수도 없다. 연구가 드러낸 것은 방향이다. 부탁하는 사람의 머릿속 계산에는 상대가 거절할 때 느끼는 사회적 비용이 자주 빠진다. 그래서 예상 수락률이 실제보다 낮아진다. 2018년 Erica Boothby와 동료들이 발표한 ‘liking gap’ 연구는 다른 장면에서 비슷한 비관을 발견했다. 사람들은 첫 대화가 끝난 뒤 상대가 자신을 얼마나 좋아했고 대화를 즐겼는지 체계적으로 낮게 추정했다. 짧은 대화와 긴 대화, 일반 성인과 대학 기숙사 동료를 관찰한 연구에서도 차이가 나타났다. 대화 상대가 보낸 호의의 신호는 있었지만, 당사자는 자기 말실수와 어색함을 복기하느라 그 신호를 충분히 읽지 못했다. 두 연구는 같은 현상을 측정하지 않는다. 하나는 도움 요청의 수락 가능성이고 다른 하나는 대화 상대의 호감에 대한 추정이다. 함께 놓으면 한 가지 습관이 보인다. 사람은 사회적 장면에서 타인의 반응을 예측할 때 자기 안의 불편함을 바깥의 평가로 번역하곤 한다. 내가 어색하니 상대도 나를 부담스러워할 것이라고 생각하고, 내가 거절이 두려우니 상대도 틀림없이 거절할 것이라고 계산한다. **실제보다 낮게 입력된 성공률이 부탁을 가로막는다.** ## 거절당한 부탁보다 보내지 않은 부탁이 더 비싸다 거절된 부탁은 적어도 현실의 답을 남긴다. 지금은 어렵다, 범위가 너무 크다, 다른 사람이 더 적합하다, 다음 달에는 가능하다는 정보가 생긴다. 보내지 않은 부탁은 아무 정보도 만들지 않는다. 상대의 의사와 무관하게 가능성을 0으로 확정할 뿐이다. 이 차이는 한 번보다 반복에서 커진다. 소개를 부탁하지 않고, 가격을 협상하지 않고, 초안을 보여주지 않고, 원하는 역할에 손을 들지 않는 선택이 쌓이면 사람은 능력 밖이 아니라 요청 밖에 있는 기회를 계속 잃는다. 겉으로는 안전하게 지냈지만 자신의 세계가 어디까지 열릴 수 있는지 한 번도 측정하지 못한다. 거절을 잘 견디는 성격부터 만들 필요는 없다. 거절 예측을 교정해야 할 추정치로 다루면 된다. 실제로 부탁하고 받은 답을 쌓을수록 머릿속 수락률은 현실에 가까워진다. 그때는 어떤 부탁을 보내고 어떤 부탁을 접을지 다시 배울 수 있다. 그 구분은 성공 가능성보다 상대가 치를 비용을 먼저 보는 데서 시작한다. 같은 소개 부탁이라도 “가능하면 담당자에게 제 이력서를 전달해주세요”와 “이번 주 안에 담당자를 설득해 미팅을 잡아주세요”는 다르다. 전자는 상대가 짧게 전달하거나 편하게 거절할 수 있다. 후자는 시간, 평판, 후속 책임까지 요구한다. 요청의 크기를 줄이면 부탁하는 사람의 두려움만 낮아지는 것이 아니라 부탁받는 사람의 실제 부담도 줄어든다. ## 수락률 뒤에는 거절의 사회적 비용이 있다 도움 요청 연구에는 불편한 반대편이 있다. 사람들이 예상보다 자주 승낙하는 이유 가운데 하나는 거절이 사회적으로 어렵기 때문이다. Vanessa Bohns는 자신의 연구를 설명하며 필요한 도움을 생각보다 쉽게 받을 수 있다는 점을 좋은 소식으로, 연애나 비윤리적 요청에서도 상대가 우리가 생각하는 것보다 거절하기 어려울 수 있다는 점을 나쁜 소식으로 구분한다. 따라서 수락률을 과소평가한다는 연구를 “사람들은 밀어붙이면 넘어온다”로 읽으면 결론이 뒤집힌다. 직급 차이가 크거나, 거래를 끊기 어렵거나, 친밀한 관계처럼 거절 뒤의 손실이 큰 상황에서는 “예”가 호의가 아니라 압박의 결과일 수 있다. 요청자는 승낙 여부만으로 상대의 진짜 선호를 알 수 없다. 좋은 부탁에는 쉬운 출구가 있다. 어렵다면 답하지 않아도 된다고 말하고, 거절 이유를 요구하지 않으며, 한 번의 거절을 협상의 시작으로 취급하지 않는다. 상사가 부하 직원에게, 고객이 생계가 걸린 공급자에게, 영향력이 큰 사람이 팬에게 부탁할 때는 이 출구가 문장 하나보다 훨씬 넓어야 한다. 요청을 거절해도 관계와 평가가 그대로라는 사실이 행동으로 확인돼야 한다. 이 윤리적 경계가 있어야 생활 기술을 오래 쓸 수 있다. 상대에게 낮은 비용으로 분명하게 묻고, 나온 답을 그대로 받아들이는 사람은 관계를 소모하지 않으면서 더 많은 현실 데이터를 얻는다. 거절을 설득 부족으로 해석하는 사람은 당장의 승낙 몇 개를 얻더라도 다음 부탁을 보낼 관계를 잃는다. ## 부탁은 머릿속 예측을 현실로 교정한다 처음의 팀장에게 필요한 것도 거절 개수를 채우는 도전이 아니다. 자신이 어떤 부탁에서 수락 가능성을 지나치게 낮게 잡는지 확인하는 작은 관찰이다. 한 달 동안 보내려다 접은 부탁을 적고, 예상한 답과 실제 답을 비교해볼 수 있다. 소개, 피드백, 조건 협상처럼 상대가 작고 분명한 행동으로 답할 수 있는 요청부터 시작하면 된다. 이 기록은 성공률보다 머릿속 세계 모형이 어떻게 틀렸는지를 보여준다. “오랜만이라 싫어할 것”이라고 예상했지만 반갑게 답한 사람, 부탁한 형태로는 어렵지만 다른 사람을 연결해준 사람, 거절했어도 관계가 전혀 나빠지지 않은 사람이 예측을 고친다. 수락과 거절 사이에는 조건부 수락, 대안, 조언, 더 나은 시점이라는 답도 있다는 사실이 보인다. 반대로 반복해서 거절되는 부탁도 가치가 있다. 요청의 범위가 너무 크거나, 상대 선택이 잘못됐거나, 제공하는 맥락이 부족하다는 신호일 수 있다. 이때 고칠 것은 자존감이 아니라 부탁의 설계다. 현실의 답이 쌓이면 “나는 원래 이런 기회를 얻지 못한다”는 막연한 믿음이 구체적인 문제로 바뀐다. 물론 어떤 거절은 아프고, 어떤 관계는 부탁 한 번으로도 어색해질 수 있다. 연구 평균은 개별 상황의 판단을 대신하지 않는다. 다만 자신의 불편함만으로 타인의 답을 미리 써버리는 습관 역시 정확한 판단은 아니다. 거절 위험과 관계 비용을 살핀 뒤에도 부탁할 가치가 남는다면, 상대의 몫인 답을 대신 결정하지 않는 편이 낫다. 팀장은 지웠던 메시지를 다시 쓴다. 오랜만에 연락해 미안하다는 변명은 줄이고, 왜 그 역할에 관심이 있는지 두 문장으로 설명한다. 소개가 부담스럽다면 편하게 넘겨도 괜찮다고 덧붙인다. 답이 무엇일지는 아직 모른다. 오늘은 상대가 실제로 답할 수 있는 부탁을 보낸다. --- 주요 출처: Prompter, [“Opus 5 on the worlds greatest life hack”](https://x.com/PromptLLM/status/2080751975579132152?ref=zerodraftlab.com) (2026); Francis J. Flynn·Vanessa K. B. Lake(Bohns), [If You Need Help, Just Ask: Underestimating Compliance With Direct Requests for Help](https://ecommons.cornell.edu/items/9c0adbfb-985c-4f7d-aae3-96959822bc4c?ref=zerodraftlab.com) (2008); Erica J. Boothby 외, [The Liking Gap in Conversations: Do People Like Us More Than We Think?](https://clarkrelationshiplab.yale.edu/sites/default/files/files/BoothbyCooneySandstromClark2018.pdf?ref=zerodraftlab.com) (2018); Vanessa Bohns, [Research on influence, compliance and consent](https://www.vanessabohns.com/research?ref=zerodraftlab.com). 도입부의 팀장과 메시지는 논지를 설명하기 위한 가상 사례이며, 두 연구를 ‘요청 예측의 교정’으로 연결한 부분은 이 글의 해석입니다. ### 광고는 본문보다 댓글에서 완성된다 URL: https://zerodraftlab.com/fake-consensus-in-comments/ Last updated: 2026-09-15T08:35:21.000Z 광고성 게시물 하나는 쉽게 의심받는다. 문장이 지나치게 매끈하거나 좋은 말만 이어지면 독자는 바로 경계한다. 그런데 그 아래에 서로 다른 계정들이 “저도 궁금해요”, “여기 괜찮았어요”, “정보 부탁드려요”라고 반응하기 시작하면 인상이 달라진다. 독자는 같은 광고를 여러 번 읽는다고 느끼지 않는다. 여러 사람이 이미 관심을 보이고 선택했다는 장면을 본다. 게시물의 주장은 판매자의 말이지만, 댓글은 그 주장을 검증한 타인의 반응처럼 보이기 때문이다. 조직된 댓글은 **합의가 이미 형성됐다는 분위기**를 만든다. 칭찬은 그 재료 중 하나일 뿐이다. 한 계정은 질문하고, 다른 계정은 경험을 말하고, 또 다른 계정은 결정을 재촉한다. 서로 다른 역할이 붙으면 광고 문구 하나가 대화로 변한다. ## 사람은 주장보다 먼저 도착한 반응을 본다 레프 무치니크, 시난 아랄, 숀 테일러는 사회 뉴스 사이트의 댓글 10만 1,281개를 대상으로 대규모 무작위 실험을 했다. 연구진은 일부 댓글에 작성 직후 인위적인 추천 한 표를 더하고, 일부에는 비추천 한 표를 더했으며, 나머지는 그대로 두었다. 이후 이용자들은 자신이 보는 점수가 실험으로 조정됐다는 사실을 몰랐다. 처음부터 추천 한 표를 받은 댓글은 다음 이용자에게 추천받을 확률이 대조군보다 32% 높았다. 이 작은 차이는 뒤에서 교정되지 않고 누적돼 최종 평균 점수를 25% 끌어올렸다. 반대로 인위적인 비추천은 이용자들이 바로잡으려는 반응을 불러 일으켰다. 이 실험의 대상은 광고가 아니라 온라인 평점이었다. 연구진은 댓글의 내용 대신 숫자 하나만 바꿨다. 그런데도 먼저 보이는 긍정적 판단이 뒤에 온 사람의 판단에 영향을 줬다. 집단 평가는 출발점의 흔적을 다음 반응으로 이어받을 수 있다. 댓글 작업이 노리는 것도 이 출발점이다. 실제 이용자가 아무 반응도 남기지 않은 빈 공간에 첫 질문과 첫 칭찬, 첫 구매 의사를 심는다. 뒤늦게 들어온 사람은 제품만 보지 않는다. 앞선 사람들이 무엇을 중요하게 봤고 어느 방향으로 반응했는지도 함께 읽는다. 이 때문에 가짜 댓글 몇 개의 영향은 그 댓글의 조회수로 끝나지 않는다. 이후에 달린 진짜 반응의 방향까지 바꿀 수 있다. 그렇다면 몇 사람이 연출한 합의는 언제부터 실제 여론처럼 작동하기 시작할까? 경계는 실제 이용자가 그 대화에 합류하는 순간 흐려진다. 처음의 반응은 직원이나 대행사가 만들었지만, 그 분위기를 보고 관심을 가진 사람의 질문은 진짜다. 추천 수가 올라가 노출이 늘고, 노출을 통해 유입된 사람이 다시 반응하면 조작된 출발점 위에 실제 행동이 쌓인다. 가짜 합의는 진짜 참여자를 모집해 스스로를 현실로 만들 수 있다. ## 초기 반응은 결과의 경로를 바꾼다 매슈 살가닉, 피터 도즈, 덩컨 와츠는 1만 4,341명이 처음 듣는 노래를 평가하고 내려받는 인공 음악 시장을 만들었다. 어떤 집단은 다른 참가자들의 선택을 볼 수 있었고, 어떤 집단은 볼 수 없었다. 사회적 정보가 강해질수록 인기의 격차는 커졌고 어떤 곡이 성공할지는 더 예측하기 어려워졌다. 품질이 완전히 사라진 것은 아니었다. 좋은 곡은 대체로 최하위로 떨어지지 않았고 나쁜 곡은 대체로 최상위에 오르지 못했다. 그 사이의 결과는 앞선 선택에 크게 흔들렸다. 댓글에서도 같은 종류의 경로 의존성이 생길 수 있다. 초기에 “효과가 좋다”는 반응이 몰리면 이후 이용자는 효과를 중심으로 경험을 해석한다. “예약이 어렵다”는 말이 먼저 쌓이면 희소성이 강조된다. “정보를 달라”는 댓글이 이어지면 아직 검증되지 않은 상품도 이미 수요가 생긴 것처럼 보인다. 이은주와 장윤재의 온라인 포털 뉴스 실험에서도 다른 독자의 댓글은 참가자가 인식하는 여론과 일부 참가자의 개인 의견에 영향을 줬다. 별도의 페이스북 뉴스 실험에서는 부정적인 댓글이 본문의 설득력을 낮췄고, 많은 ‘좋아요’만으로는 같은 효과가 나타나지 않았다. 숫자보다 구체적인 타인의 반응이 더 강한 단서가 될 수 있다는 뜻이다. ## 직원 댓글은 독립된 증인의 자리를 빌린다 직원도 자기 회사의 게시물에 의견을 보탤 수 있다. 관계를 밝히고 질문에 답하거나 잘못된 정보를 고치면 회사의 공식 설명으로 읽힌다. 관계를 숨긴 채 이용자처럼 반응하면 댓글이 가진 제3자 신뢰를 빌려 쓴다. 독자는 여러 독립된 사람이 같은 판단에 도달했다고 믿는다. 실제로는 한 조직의 결정이 여러 계정으로 나뉘어 보였을 뿐이다. 표본 수가 부풀려지고, 의견의 다양성이 사라지며, 반대 의견을 내는 사람은 자신만 분위기를 잘못 읽었다고 느끼기 쉬워진다. 사업자가 지켜야 할 경계도 여기서 분명해진다. 직원은 이용자 역할을 연기하지 않고 소속을 드러낸 채 답해야 한다. 체험 고객의 반응을 요청할 수는 있어도 문구와 게시 시점을 단체로 맞춰서는 안 된다. 플랫폼은 같은 시간대에 몰린 계정, 반복되는 역할 분담, 이해관계 표시가 없는 조직 계정을 단순 참여량으로 계산하지 않아야 한다. 독자에게 댓글 수는 품질의 증거가 아니다. 누가 먼저 대화를 시작했는지, 계정마다 실제 이력이 있는지, 불만과 반론도 살아 있는지, 시간이 지나도 후속 경험이 이어지는지를 함께 봐야 한다. 모든 댓글이 한 방향으로 매끈하게 정렬돼 있다면 높은 만족도보다 조정된 대화일 가능성을 먼저 확인할 이유가 있다. --- 주요 참고: Lev Muchnik, Sinan Aral, Sean J. Taylor, [Social Influence Bias: A Randomized Experiment](https://doi.org/10.1126/science.1240466?ref=zerodraftlab.com); Matthew J. Salganik, Peter Sheridan Dodds, Duncan J. Watts, [Experimental Study of Inequality and Unpredictability in an Artificial Cultural Market](https://doi.org/10.1126/science.1121066?ref=zerodraftlab.com); Eun-Ju Lee, Yoon Jae Jang, [What Do Others’ Reactions to News on Internet Portal Sites Tell Us?](https://doi.org/10.1177/0093650210376189?ref=zerodraftlab.com); Stephan Winter, Caroline Brückner, Nicole C. Krämer, [They Came, They Liked, They Commented](https://doi.org/10.1089/cyber.2015.0005?ref=zerodraftlab.com). 이 연구들은 온라인 평점, 인공 음악 시장, 뉴스 댓글을 다뤘으며 직원이 동원된 광고 댓글을 직접 검증한 자료는 아닙니다. 조직된 댓글과 가짜 합의에 대한 적용은 사회적 영향과 경로 의존성을 바탕으로 한 이 글의 해석입니다. ### 〈호프〉는 충무로 영화투자의 답인가 URL: https://zerodraftlab.com/chungmuro-film-investment/ Last updated: 2026-08-30T02:54:13.000Z 2026년 7월 25일까지 **312만9829명**. 업계가 거론하는 손익분기점 700만 명의 **44.7%**다. 아직 387만171명이 더 필요하다. 개봉 후 11일 동안 박스오피스 1위를 지켰지만, 오늘 기준으로 〈호프〉를 흥행 성공작이라고 부를 수는 없다. 300만 돌파는 초반 흥행 속도를 말해준다. 손익분기점까지 갔다는 뜻은 아니다. 현재 채운 몫보다 남은 몫이 더 크다. 7월 29일 〈스파이더맨: 브랜드 뉴 데이〉와 8월 5일 〈오디세이〉가 개봉하면 일반관과 특별관 경쟁도 거세진다. 영화진흥위원회 통합전산망을 인용한 [7월 26일 집계](https://v.daum.net/v/20260726084839942?ref=zerodraftlab.com)에 따르면, 〈호프〉는 전날 32만7571명을 모아 누적 312만9829명을 기록했다. [같은 날 한국경제 보도](https://www.hankyung.com/article/2026072664791?ref=zerodraftlab.com)가 제시한 업계 추정 손익분기점은 700만 명이다. 국내 극장 기준 회수 여부는 아직 판가름 나지 않았다. ## 선판매를 감안한 보도에서도 700만 명이다 〈호프〉는 해외 선판매로 위험을 줄였지만 투자 성공까지 확정하지 못했다. [플러스엠의 발표를 전한 연합뉴스](https://fr.yna.co.kr/view/AFR20260529002000884?ref=zerodraftlab.com)에 따르면 〈호프〉는 북미·유럽·중동 등 200여 개 국가와 지역에 선판매됐고, 한국영화 해외 선판매액 기록을 세웠다. 북미 등 영어권은 네온, 프랑스는 포커스 피처스와 UPI 프랑스, 스페인·이탈리아·독일은 무비가 배급을 맡는다. 플러스엠은 정확한 선판매액과 순제작비를 공개하지 않았다. 공식적으로 확인되는 경계는 ‘선판매만으로 순제작비의 절반가량을 회수했다’는 배급사 설명까지다. 국내 보도는 선판매액을 200억 원대 중반, 순제작비를 500억\~600억 원대로 추정한다. 마케팅·금융비용까지 합친 총투자비는 이보다 클 수 있다. 모두 감사된 공개 결산이 아니라 보도와 업계 추정치다. [Korea JoongAng Daily](https://www.koreajoongangdaily.com/entertainment/made-at-home-paid-for-abroad-global-presales-rewrite-the-business-model-for-korean-cinema/12742261?ref=zerodraftlab.com)는 원래 국내 극장 손익분기점이 약 1000만 명으로 추정됐으나 선판매 뒤 크게 낮아졌다고 보도했다. 7월 26일 보도에 등장한 700만 명은 이 선판매 효과가 반영된 수치로 읽는 편이 타당하다. 정확한 산식은 공개되지 않았다. 따라서 누적 312만 명에 ‘순제작비 절반 선회수’를 다시 더해 안전하다고 평가하면 같은 선판매 효과를 두 번 계산할 수 있다. 선판매는 손익분기점을 낮춘 요인이다. 현재 관객 수와 별개로 남아 있는 추가 안전판처럼 취급할 수 없다. 해외 배급사가 지급한 최소보장금과 판권대금은 개봉 전 손실 노출을 줄였다. 플러스엠은 해외 흥행 성적에 따라 추가 수입을 나누는 계약도 포함됐다고 밝혔다. 이 구조가 줄인 위험의 크기와 실제 이익은 공개정보만으로 계산할 수 없다. ## 700만 명은 먼저 넘어야 할 문턱이다 현재 보도대로라면 국내 극장에서 700만 명을 채워야 프로젝트 전체가 손익분기점에 도달한다. 700만 명을 넘는다고 모든 투자자가 동시에 같은 수익률을 얻는 것은 아니다. 티켓 매출은 극장과 배급사가 나눠 갖고, 배급수수료, 국내 마케팅비, 해외판매수수료, 추가 제작비와 투자원금이 계약에 정한 순서대로 빠진다. 남은 금액이 있어야 순이익 배분이 시작된다. 선판매액도 곧바로 이익은 아니다. 먼저 제작비를 메우는 돈이고, 판매수수료와 현지 배급사의 권리범위가 붙는다. 해외 극장 흥행과 후속 판권 수입이 최종 정산을 개선할 수 있지만, 공개된 숫자로는 그 규모를 계산할 수 없다. 극장 뒤에는 PVOD·디지털 구매, 구독형 OTT, 유료·무료방송, 항공과 라이브러리 매출이 남는다. 〈호프〉의 200여 개 지역 계약이 이 창구를 어디까지 넘겼는지는 공개되지 않았다. 지역별 모든 권리를 정액에 양도했다면 개봉 전 확정회수와 맞바꿔 이후 상승분을 포기한 것이다. 최소보장금 뒤 현지 흥행과 후속 창구 수익을 나누는 계약이라면 투자자는 해외 성과에 계속 참여한다. ‘200여 개 지역 판매’만으로는 미래 매출의 주인이 누구인지 알 수 없다. 따라서 〈호프〉 투자자가 지금 봐야 할 것은 누적관객 하나가 아니다. 1. **회수 기준:** 순제작비만 계산한 것인지, 국내외 P&A와 금융비용까지 포함한 총원가인지. 2. **선판매 순액:** 발표된 계약총액에서 판매수수료와 현지 비용을 뺀 뒤 실제로 얼마가 들어왔는지. 3. **회수 순서:** 플러스엠의 배급수수료, 투자원금, 제작사 몫과 부분투자자 몫이 어떤 순서로 지급되는지. 4. **해외 초과수익:** 현지 흥행이 최소보장금을 넘었을 때 한국 투자자에게 돌아오는 비율이 얼마인지. 5. **남는 권리:** 속편·프리퀄·리메이크·시리즈와 캐릭터 IP를 누가 갖는지. 이 다섯 항목이 없으면 700만 관객 전망은 투자설명서가 아니라 흥행 뉴스다. ## 플러스엠과 부분투자자는 같은 〈호프〉를 산 게 아니다 제작사는 포지드필름스, 메인 투자·배급사는 플러스엠이다. 감독과 배우는 작품을 만들고 출연료와 계약에 따른 성과보수를 받는다. 해외 배급사는 지역별 권리를 미리 산다. 극장은 상영공간과 관객 접점을 제공하고 티켓 매출 일부를 가져간다. 이 가운데 플러스엠은 단순한 지분투자자가 아니다. 국내 배급권, 개봉일과 마케팅 의사결정, 매출 수금과 정산, 해외판매 구조에 접근한다. 흥행에 실패해도 투자손실은 나지만 배급·판매수수료라는 별도 수익원이 있을 수 있다. 감독·배우와의 관계, 후속 프로젝트의 우선권도 남는다. 수동적 부분투자자는 다르다. 자본은 대지만 예산 초과, 추가 촬영, 마케팅비 확대와 개봉전략을 직접 통제하기 어렵다. 계약에 감사권과 선순위 회수권이 없다면 플러스엠이 만든 숫자를 받아보는 위치에 머문다. 같은 영화에 돈을 넣어도 권리와 위험은 같지 않다. ## 〈호프〉가 판 것은 한국영화 한 편이 아니다 나홍진이라는 감독 브랜드, 황정민·조인성의 국내 인지도, 마이클 패스벤더와 알리시아 비칸데르의 국제 인지도, 칸 경쟁부문 선정, 대형 화면에 맞춘 장르와 200여 개 지역의 배급망이 하나의 패키지가 됐다. 〈호프〉는 완성된 뒤 해외에 덤으로 판 영화가 아니라 기획 단계부터 해외 선판매가 가능한 상품으로 만들어졌다. 그래서 〈호프〉의 구조를 평범한 충무로 영화에 그대로 대입할 수 없다. 해외 바이어가 개봉 전에 큰 최소보장금을 낼 감독 브랜드, 장르, 캐스팅과 영화제 신호를 동시에 갖춘 프로젝트는 드물다. 선판매 구조가 좋다는 사실도 〈호프〉의 흥행이나 투자 성공을 보장하지 않는다. ## 7월 26일 현재 판정 초반 속도는 빨랐다. 개봉 11일째 312만 명, 박스오피스 1위, 특별관 수요가 확인됐다. 하지만 손익분기 관객 수 기준 진척률은 44.7%다. 남은 관객 387만 명은 지금까지 모은 관객보다 많다. 200여 개 지역 선판매는 이 위험을 낮춘 원인이고, 현재 700만 명이라는 추정 손익분기점에 이미 반영됐을 가능성이 크다. 이를 별도 수익으로 한 번 더 더해 투자 성공에 가깝다고 말할 근거는 없다. 관객 평이 갈리는 가운데 경쟁작까지 들어오므로 장기 흥행도 단정하기 어렵다. 〈호프〉의 최종 투자수익률은 비공개 계약과 해외 개봉 정산이 나와야 알 수 있다. 오늘 공개된 정보만으로는 흥행 성공도, 투자 성공도 입증되지 않았다. 수동적 부분투자자라면 312만 관객과 200여 개 지역 선판매라는 헤드라인만으로 들어갈 이유가 없다. 선판매 순액, 총원가, 회수 순서, 해외 초과수익과 후속 IP가 공개되지 않은 현재 판정은 **투자 근거 부족**이다. --- 2026년 7월 26일 기준. 주요 출처: 영화관입장권 통합전산망을 인용한 [일간스포츠 박스오피스 집계](https://v.daum.net/v/20260726084839942?ref=zerodraftlab.com); 연합뉴스, [〈호프〉 200여 개 지역 선판매 및 플러스엠 공개 범위](https://fr.yna.co.kr/view/AFR20260529002000884?ref=zerodraftlab.com); Korea JoongAng Daily, [해외 선판매액·순제작비·해외 흥행 연동 계약에 관한 보도](https://www.koreajoongangdaily.com/entertainment/made-at-home-paid-for-abroad-global-presales-rewrite-the-business-model-for-korean-cinema/12742261?ref=zerodraftlab.com); 한국경제, [7월 26일 흥행과 경쟁작 분석](https://www.hankyung.com/article/2026072664791?ref=zerodraftlab.com); 영화진흥위원회, [2025년 한국 영화산업 결산](https://www.kofic.kr/kofic/business/rsch/findPolicyDetail.do?policyNo=8186&ref=zerodraftlab.com). 선판매액, 제작비와 손익분기점은 배급사가 원액을 공개하지 않은 항목으로 보도·업계 추정치를 구분해 사용했습니다. 본문은 공개정보에 기초한 산업 분석이며 특정 금융상품에 대한 투자 권유가 아닙니다. ### 오르카는 코딩 에이전트 관제실이다 URL: https://zerodraftlab.com/orca-agent-control-room/ Last updated: 2026-08-30T02:53:59.000Z Claude Code와 Codex를 번갈아 쓰다 보면 모델보다 먼저 막히는 것이 있다. 어느 에이전트가 어떤 브랜치에서 일하는지, 무엇을 바꿨는지, 지금 답을 기다리는지 한눈에 보이지 않는다. [Orca](https://www.onorca.dev/?ref=zerodraftlab.com)는 이미 구독 중인 코딩 에이전트를 여러 작업 공간에 배치하고 결과를 검토하는 데스크톱 Agent Development Environment(ADE)다. [Orca — The Agent IDEClaude Code, Codex, OpenCode 등 여러 코딩 에이전트를 격리된 worktree에서 함께 실행하는 개발 환경![](https://www.onorca.dev/favicon.ico)Orcaonorca.dev](https://www.onorca.dev/?ref=zerodraftlab.com) Orca는 에이전트마다 일할 자리를 만든다. Claude Code, Codex, Cursor CLI, OpenCode처럼 터미널에서 실행되는 도구를 기존 구독과 인증으로 불러온다. 저장소를 등록하고 작업을 만들면 실제 `git worktree`와 브랜치, 전용 터미널을 만든다. 에디터와 브라우저, diff 화면도 그 worktree에 묶인다. ## 작업 하나가 worktree 하나가 된다 Orca의 기본 단위는 채팅이 아니라 작업이다. 저장소의 기준 브랜치에서 worktree를 만들고, 그 안에서 에이전트를 실행한다. 변경이 끝나면 기준 ref와 diff를 비교하고, 줄 단위로 피드백하고, commit과 push, pull request까지 이어간다. 필요 없는 worktree와 브랜치는 확인 후 함께 지울 수 있다. 이 구조는 여러 에이전트가 같은 checkout의 파일을 덮어쓰는 일을 막는다. 한 에이전트는 로그인 버그를 고치고, 다른 에이전트는 테스트를 보강하며, 세 번째 에이전트는 문서를 정리해도 각자의 파일과 브랜치를 가진다. 여러 저장소를 프로젝트 그룹으로 묶고 각 작업을 GitHub·GitLab·Linear·Jira 항목과 연결하는 것도 같은 모델의 확장이다. ## 같은 문제에 세 에이전트를 붙일 수도 있다 공식 첫 세션 안내는 같은 프롬프트를 Claude Code, Codex, Cursor CLI에 각각 보내는 예시를 쓴다. 세 개의 worktree와 세 개의 diff를 만든 뒤 가장 나은 결과를 고르고, 나머지 둘을 버리는 방식이다. Orca의 split pane과 상태 표시가 어느 에이전트가 작업 중이고, 입력을 기다리고, 끝났는지 보여준다. 경쟁 실행은 항상 이득이 아니다. 모델 세 개가 같은 문제를 풀면 시간과 구독 한도도 세 번 쓴다. 정답을 고를 테스트나 acceptance criteria가 없으면 diff 세 개를 사람이 읽는 일이 새 병목이 된다. 구현 경로가 불확실하고 결과를 기계적으로 비교할 수 있는 버그, 리팩터링, UI 대안에서 먼저 써볼 만하다. ## 브라우저와 원격 컴퓨터도 worktree에 붙는다 Orca는 worktree마다 Chromium 창을 열 수 있다. Design Mode에서 화면 요소를 누르면 해당 HTML·CSS와 잘라낸 스크린샷을 에이전트에게 보낸다. UI 버그를 설명하기 위해 DOM 경로와 이미지를 따로 모으는 수고를 줄이는 기능이다. diff에 코멘트를 달아 다시 에이전트에게 보내고, 실패한 GitHub Actions 로그를 같은 화면에서 넘길 수도 있다. 에이전트를 노트북 밖에서 실행할 수도 있다. SSH 대상에 worktree를 만들면 코드와 에이전트는 원격 서버에서 돌고 에디터와 diff는 로컬에 남는다. 연결이 끊겨도 원격 세션은 계속 실행된다. iOS·Android companion은 데스크톱과 페어링해 상태와 최근 터미널 출력을 보고, 짧은 답을 보내거나 source control을 확인하는 리모컨에 가깝다. 공식 문서는 모바일 연결을 데스크톱과 휴대폰 사이의 직접 연결로 설명하며 cloud relay는 사용하지 않는다고 밝힌다. ## worktree는 보안 샌드박스가 아니다 권한 기본값은 도입 전에 바꿔볼 부분이다. Orca는 지원하는 에이전트를 처음 실행할 때 Claude Code의 `--dangerously-skip-permissions`, Codex의 `--dangerously-bypass-approvals-and-sandbox` 같은 완전 자율 플래그를 미리 넣는다. 설정에서 전체 기본값을 Manual로 바꿀 수 있지만, 설치 직후의 설계 의도는 worktree를 작업용 샌드박스로 삼는 것이다. Git worktree가 나누는 것은 브랜치와 파일 checkout이다. 같은 컴퓨터의 환경변수, SSH 키, 클라우드 인증, 데이터베이스, 포트, 실행 중인 프로세스까지 격리하지는 않는다. 에이전트가 저장소 밖의 파일을 지우거나 외부 시스템에 쓰는 위험도 diff를 버린다고 되돌아오지 않는다. 민감한 저장소에서는 먼저 Manual 권한으로 바꾸고, 계정과 secret, 배포 권한을 작업별로 제한해야 한다. 더 강한 격리가 필요하면 Orca가 지원하는 별도 VM·컨테이너형 per-workspace 환경을 검토하는 편이 맞다. ## 오르카가 값을 하는 순간 작은 수정 하나를 한 에이전트에게 맡기는 사람에게 Orca는 터미널 위에 화면을 하나 더 얹는다. 반대로 독립된 작업을 세 개 이상 동시에 돌리고, Claude와 Codex의 결과를 비교하고, 원격 서버의 장시간 작업까지 관리한다면 작업 전환 비용을 줄일 수 있다. 특히 작업마다 branch와 worktree를 만드는 규칙은 알고 있지만 매번 터미널에서 직접 만들고 정리하는 팀에 잘 맞는다. 도입 판단은 저장소 하나로 끝낼 수 있다. 권한을 Manual로 바꾸고, 서로 독립된 작업 두세 개만 Orca worktree에 배치한다. 작업 생성부터 검토 가능한 diff까지 걸린 시간, 사람이 다시 설명한 횟수, 버린 병렬 실행의 수를 기록한다. 이 숫자가 줄지 않으면 대시보드 하나만 늘어난 셈이다. --- 주요 출처: Orca, [공식 홈페이지](https://www.onorca.dev/?ref=zerodraftlab.com)와 [What is Orca?](https://www.onorca.dev/docs?ref=zerodraftlab.com); Orca Docs, [Worktrees](https://www.onorca.dev/docs/model/worktrees?ref=zerodraftlab.com), [Your first 3-agent session](https://www.onorca.dev/docs/first-session?ref=zerodraftlab.com), [Agents & sessions](https://www.onorca.dev/docs/model/agents-sessions?ref=zerodraftlab.com), [SSH worktrees](https://www.onorca.dev/docs/ssh?ref=zerodraftlab.com), [Mobile companion](https://www.onorca.dev/docs/mobile?ref=zerodraftlab.com), [Privacy & Telemetry](https://www.onorca.dev/docs/telemetry?ref=zerodraftlab.com); [stablyai/orca 공개 저장소](https://github.com/stablyai/orca?ref=zerodraftlab.com). worktree의 격리 경계, 경쟁 실행의 비용, 좁은 파일럿 제안은 Zero Draft Lab의 분석입니다. ### 후기 커뮤니티는 성공할수록 광고판이 된다 URL: https://zerodraftlab.com/review-community-ad-market/ Last updated: 2026-09-15T08:35:22.000Z 사람들은 광고를 피하려고 후기 커뮤니티에 들어간다. 병원 홈페이지에는 잘된 사례만 있고, 광고에는 불편했던 과정이 없기 때문이다. 커뮤니티에서는 회복 기간, 예상 밖의 통증, 추가 비용, 후회한 선택처럼 판매자가 먼저 말하지 않는 내용을 찾을 수 있다. 초기의 작은 커뮤니티가 쓸모 있는 이유도 여기에 있다. 오래 활동한 사람을 서로 기억하고, 과거 글과 지금 글을 연결해 읽으며, 한 번의 칭찬보다 여러 달에 걸친 경험을 본다. 누가 무엇을 왜 추천하는지 대충이라도 추적할 수 있다. 신뢰는 좋은 문장보다 관계의 이력에서 나온다. 그런데 이 신뢰가 사람을 모으기 시작하면 커뮤니티의 경제가 바뀐다. 검색 유입이 늘고 구매 직전의 이용자가 모인다. 병원, 업체, 브로커, 광고대행사 입장에서는 일반 광고보다 훨씬 매력적인 공간이 된다. 이미 관심이 생긴 사람이 구체적인 선택지를 비교하고 있기 때문이다. ## 신뢰가 광고 재고로 바뀌는 순간 광고는 배너를 붙이는 데서 멈추지 않는다. 커뮤니티 안에서 통하는 후기의 형식을 배운다. 지나치게 완벽한 칭찬은 의심받으니 작은 불만을 섞는다. 홍보 문구는 거부감을 주니 일상적인 말투를 쓴다. 결과만 올리면 광고 같으니 고민 과정과 댓글 대화를 덧붙인다. 이때 광고는 후기 옆에 놓이는 대신 후기처럼 보이기 시작한다. 온라인 리뷰 조작을 연구한 경제학 논문들도 이 유인을 확인했다. 디나 메이즐린, 야니브 도버, 주디스 슈발리에는 실제 숙박객만 리뷰를 쓸 수 있는 Expedia와 누구나 쓸 수 있던 TripAdvisor를 비교했다. 조작 유인이 큰 호텔일수록 공개형 플랫폼에서 자기 호텔에는 더 긍정적이고 경쟁 호텔에는 더 부정적인 리뷰가 나타났다. 마이클 루카와 게오르기오스 저바스는 Yelp가 의심 리뷰로 걸러낸 식당 리뷰를 분석해 평판이 약하거나 경쟁이 심할수록 리뷰 조작 유인이 커지는 패턴을 보고했다. 두 연구는 호텔과 식당 플랫폼을 다뤘다. 한국의 성형 후기 커뮤니티를 직접 조사한 증거는 아니다. 다만 구매 결정에 리뷰가 큰 영향을 주고, 작성자의 이해관계를 독자가 확인하기 어려울 때 사업자가 후기 형식에 개입할 경제적 유인이 생긴다는 구조는 같다. ## 진짜를 가리던 신호도 복제된다 이용자는 바보가 아니다. 광고 냄새가 나는 문장을 피하고, 사진을 보고, 계정의 과거 글을 읽고, 좋은 말만 하는 사람을 의심한다. 문제는 이런 판별법이 공개돼 있다는 데 있다. 이용자가 무엇을 진짜의 신호로 보는지 알려지는 순간 그 신호도 광고 제작법에 들어간다. 사진이 글보다 믿을 만하다고 알려지면 사진이 핵심 광고 자산이 된다. 길고 구체적인 후기가 진짜처럼 보이면 광고도 길고 구체적으로 변한다. 약간의 단점을 적은 글이 더 신뢰받으면 감당할 수 있는 단점이 의도적으로 섞인다. 댓글의 자연스러운 대화가 중요해지면 여러 계정이 서로 반응하며 합의를 연출할 수 있다. 좋은 판별법이 오래 버티지 못하는 이유다. 사람들은 콘텐츠의 모양으로 진짜를 찾지만, 광고는 그 모양을 복제한다. 커뮤니티의 규모가 커질수록 복제에 쓸 돈과 얻을 매출도 커진다. 결국 이용자는 더 작은 커뮤니티로 이동한다. 새 공간은 아직 광고가 적고 사람을 기억할 수 있어 믿을 만하다. 그러나 그 신뢰가 알려져 사람이 몰리면 같은 유인이 다시 생긴다. 좋은 커뮤니티가 망가지는 데에는 운영자의 악의도 필요하지 않다. **쌓인 신뢰가 판매 가능한 자산이 되었는데, 그 신뢰를 누가 어떻게 사용하는지 구분할 장치가 없으면 된다.** 그래서 다음 질문은 어느 커뮤니티를 믿을지가 아니다. 같은 후기 형식 아래에서 어떤 생산 구조를 확인해야 하는가다. 가장 먼저 볼 것은 문장의 진정성이 아니라 **작성자의 이력과 이해관계를 얼마나 추적할 수 있는가**다. 오늘 만든 계정의 정교한 후기보다 몇 달 전의 고민, 선택 직후의 반응, 시간이 지난 뒤의 평가가 연결되는 기록이 더 많은 정보를 준다. 한 번에 잘 만든 콘텐츠는 살 수 있지만, 모순 없이 이어지는 시간은 만들기 어렵다. 오래된 계정도 거래되고 관리될 수 있다. 한 가지 신호를 정답처럼 쓰면 판별법은 다시 쉽게 복제된다. 작성 시점, 활동 이력, 구체적인 불편, 다른 이용자와의 관계, 상업적 혜택 공개 여부를 함께 봐야 한다. 신뢰는 배지 하나가 아니라 서로 다른 흔적이 맞물릴 때 생긴다. ## 후기 시장에도 레몬 문제가 생긴다 조지 애컬로프는 중고차 시장에서 판매자는 차의 품질을 알지만 구매자는 알기 어려울 때 어떤 일이 생기는지 설명했다. 구매자가 좋은 차와 나쁜 차를 구분하지 못하면 평균 품질에 맞춘 가격만 지불하려 한다. 좋은 차를 가진 판매자는 그 가격에 팔 이유가 없어 시장을 떠난다. 낮은 품질이 높은 품질을 밀어내는 구조다. 후기 커뮤니티에서도 비슷한 일이 벌어진다. 독자가 실제 경험과 홍보성 경험담을 구분하지 못하면 모든 후기를 할인해서 읽는다. 시간을 들여 솔직하게 쓴 사람은 “광고 아니냐”는 의심을 받고, 경험을 나눌 보상은 줄어든다. 반면 홍보를 목적으로 들어온 사람은 판매 성과가 있으므로 계속 글을 만든다. 의심이 커질수록 선의의 작성자가 먼저 지치고, 돈을 버는 작성자만 남기 쉽다. 이 구조에서 단순한 게시물 삭제는 충분하지 않다. 삭제 기준이 불투명하면 이용자는 운영자가 불리한 후기를 지운다고 의심한다. 반대로 아무것도 막지 않으면 광고가 후기 공급량을 채운다. 커뮤니티가 지켜야 할 것은 게시물의 양이 아니라, 누가 어떤 조건에서 글을 썼는지 확인할 수 있는 추적 가능성이다. ## 성장을 원한다면 마찰을 남겨야 한다 플랫폼은 가입과 작성을 쉽게 만들수록 빨리 큰다. 그러나 후기의 신뢰는 어느 정도의 마찰에서 나온다. 실제 이용 확인, 혜택과 관계 공개, 수정 이력, 장기간의 후속 기록, 운영자의 제재 기준처럼 조작 비용을 높이는 장치가 필요하다. 이 장치들은 콘텐츠 공급을 줄일 수 있다. 광고 매출과도 충돌한다. 그래서 많은 커뮤니티가 성장과 신뢰를 동시에 외치면서 실제 제품은 성장에만 맞춘다. 회원 수와 게시물 수는 매일 보이지만, 광고 때문에 떠난 이용자와 사라진 솔직한 작성자는 대시보드에서 잘 보이지 않는다. 커뮤니티 운영자가 신뢰를 지키고 싶다면 광고를 없애겠다는 선언보다 경계를 설계해야 한다. 협찬과 혜택을 받은 글은 눈에 띄게 분리하고, 후기 작성 자격과 검증 범위를 설명하며, 병원이나 업체와 관련된 계정의 활동을 같은 규칙으로 다뤄야 한다. 운영자가 돈을 버는 방식도 이용자가 이해할 수 있어야 한다. 이용자에게는 완벽하게 깨끗한 커뮤니티를 찾는 일이 답이 아니다. 그런 공간도 알려지면 같은 압력을 받는다. 후기는 후보를 만들고 질문을 정리하는 재료로 쓰되, 한 게시물이나 한 커뮤니티의 분위기로 큰 결정을 끝내지 않는 편이 낫다. 특히 의료처럼 되돌리기 어려운 선택에서는 서로 독립된 출처와 직접 확인한 정보를 함께 봐야 한다. 커뮤니티의 이름보다 정보가 만들어진 구조를 보자. 누가 썼는지, 어떤 혜택이 있었는지, 시간이 지나도 기록이 이어지는지, 운영자는 광고와 후기를 어떻게 나누는지 확인해야 한다. 이 질문에 답할 수 없는 공간에서는 진짜처럼 보이는 후기의 수가 많아질수록 오히려 덜 믿어야 한다. --- 주요 참고: George A. Akerlof, [The Market for “Lemons”: Quality Uncertainty and the Market Mechanism](https://doi.org/10.2307/1879431?ref=zerodraftlab.com); Dina Mayzlin, Yaniv Dover, Judith Chevalier, [Promotional Reviews: An Empirical Investigation of Online Review Manipulation](https://doi.org/10.1257/aer.104.8.2421?ref=zerodraftlab.com); Michael Luca, Georgios Zervas, [Fake It Till You Make It: Reputation, Competition, and Yelp Review Fraud](https://doi.org/10.1287/mnsc.2015.2304?ref=zerodraftlab.com). 위 연구는 각각 중고차 시장, 호텔 리뷰, 식당 리뷰를 다루며 한국의 의료 후기 커뮤니티를 직접 검증한 자료는 아닙니다. 의료 후기 커뮤니티에 대한 적용은 정보 비대칭과 리뷰 조작 유인을 바탕으로 한 이 글의 해석입니다. ### 먼저 말하면 설명, 나중에 말하면 변명일까 URL: https://zerodraftlab.com/explanation-or-excuse/ Last updated: 2026-08-30T02:53:28.000Z X에 이런 문장이 올라왔다. 연봉 1억 엔인 엘리트 직장인이 했다는 말이라고 했다. > 年収1億のエリートサラリーマンが言ってた言葉 「先に言えば、説明。後に言えば、言い訳。」 > > — ゴッホ。 (@goho\_\_\_) [July 25, 2026](https://x.com/goho%5F%5F%5F/status/2080966446050668747?ref%5Fsrc=twsrc%5Etfw&ref=zerodraftlab.com) 임베딩이 보이지 않으면 [X 원문](https://x.com/goho%5F%5F%5F/status/2080966446050668747?ref=zerodraftlab.com)에서 볼 수 있다. > 먼저 말하면 설명이고, 나중에 말하면 변명이다. 문장은 기억하기 좋다. 출처는 약하다. 게시물에는 그 직장인이 누구인지, 어디에서 한 말인지 확인할 정보가 없다. 같은 표현은 X 게시물보다 훨씬 앞선 2021년 컨설턴트 와니 다쓰야의 글에서도 확인된다. 그는 “나는 먼저 말하면 설명, 나중에 말하면 변명이라고 생각한다”고 썼다. **‘연봉 1억 엔 직장인의 말’은 확인된 출처가 아니라 게시물에 붙은 설정**으로 보는 편이 안전하다. 그렇다고 문장의 내용까지 근거가 없는 것은 아니다. 사회심리학과 위기 커뮤니케이션에는 이 문장과 거의 같은 현상을 다룬 연구가 있다. ## 가장 가까운 이론은 ‘Stealing Thunder’다 *Stealing thunder*는 자신에게 불리한 정보를 다른 사람이 폭로하기 전에 먼저 공개하는 전략이다. 1993년 연구진은 모의 형사재판과 민사재판에서 이 효과를 실험했다. 형사재판 실험에는 257명, 민사재판 실험에는 148명이 참여했다. 불리한 증거를 검사가 먼저 꺼낸 경우보다 피고 측이나 증인이 자발적으로 공개한 경우, 그 정보가 판단에 미치는 부정적 영향이 줄고 발화자의 신뢰도는 높아졌다. 경로분석에서도 신뢰도 상승이 판결 차이를 설명하는 주요 경로로 나타났다. 여기서 ‘먼저’는 반드시 문제가 생기기 전이라는 뜻이 아니다. 잘못은 이미 벌어졌어도 제3자가 찾아내기 전에 자신이 먼저 밝히면 *stealing thunder*에 해당한다. X 문구의 ‘사전 설명’보다 범위가 좁고, ‘선제적 자진 공개’에 더 가깝다. 왜 효과가 생길까. 자신에게 불리한 사실을 자발적으로 꺼내는 행동은 단기적으로 자기 이익에 반한다. 듣는 사람은 그 비용을 감수한 행동에서 정직성의 신호를 읽는다. 감춰진 비밀로 남아 있던 정보의 희소성과 충격도 줄어든다. 먼저 말한 사람이 사실을 없애는 것이 아니라, 그 사실을 해석할 때 함께 적용되는 신뢰도를 바꾸는 셈이다. ## 구체성과 후속 조치가 효과를 가른다 2021년 네 차례 실험에서는 자진 공개의 구체성이 효과를 갈랐다. 잘못의 내용과 규모를 상세히 밝힌 고백은 정직성 평가와 전반적 평가의 손상을 줄였다. “일부 문제가 있었다”처럼 모호하거나 중간 수준으로 공개한 고백은 보호 효과가 약하거나 거의 없었다. 먼저 말하면서 핵심을 숨기면 솔직함보다 회피로 읽힌다. 2016년 위기 커뮤니케이션 연구에서는 사람들이 선제 공개의 설득 의도, 다시 말해 평판을 관리하려는 계산을 분명하게 알아차렸을 때 긍정적 효과가 사라졌다. 선제 공개도 면피 기술처럼 보이면 통하지 않는다. 한국 참가자를 대상으로 한 연구도 같은 경계를 보여준다. 연구진은 286명의 질적 응답을 분석한 뒤 426명을 대상으로 무작위 실험을 했다. 선제 공개에 대한 평가는 단순하지 않았고, 투명한 설명과 제대로 된 후속 조치가 붙을 때 신뢰도와 긍정적 구전 의도가 높아졌다. 빨리 말하는 것만으로는 부족했다. 여기서 한 걸음 더 해석하면 설명의 가치는 타이밍보다 **상대에게 남겨주는 선택지**에서 나온다. 일정이 늦어질 가능성을 미리 알리면 상대는 범위를 줄이거나, 사람을 더 붙이거나, 약속을 다시 잡을 수 있다. 모든 선택지가 사라진 뒤 같은 사유를 말하면 정보가 아니라 책임 배분에만 영향을 준다. 그래서 변명처럼 들린다. ## 나쁜 소식은 왜 늦어지는가 사람이 불리한 소식을 미루는 현상에는 *MUM Effect*라는 이름이 붙어 있다. 1971년 현장연구에서는 장애 지원 신청자에게 승인 결정보다 거절 결정을 전달하는 데 더 오랜 시간이 걸렸다. 표본은 27명으로 작고 결과도 오늘날 기준으로 강한 통계적 증거는 아니었지만, 이후 연구는 조직의 위계 안에서 나쁜 소식이 누락되거나 완곡해지는 현상으로 이 개념을 확장했다. 2021년 의료기관 종사자를 조사한 연구에서는 상사와의 관계가 좋고 직원에게 권한이 있으며, 조직이 단기 실적만 밀어붙이지 않을수록 상사에게 부정적 사건을 숨기는 *Hierarchical MUM Effect*가 줄었다. 에이미 에드먼드슨의 1999년 51개 팀 연구에서도 대인 위험을 감수해도 안전하다는 공동의 믿음, 즉 심리적 안전감이 실수 논의와 피드백 같은 학습 행동에 연결됐다. 따라서 “왜 미리 말하지 않았어?”라는 문장을 보고자를 벌주는 데 쓰면 다음 보고는 더 늦어진다. 선제 보고를 요구하는 조직은 나쁜 소식을 가져온 사람과 나쁜 소식을 만든 사람부터 구분해야 한다. ## 먼저 말해도 변명인 경우가 있다 실패하기 전에 핑곗거리를 만들어두는 행동은 *self-handicapping*으로 연구돼 왔다. 1991년 두 실험에서 이런 행동은 실패를 능력 부족으로 보는 평가는 줄였지만, 당사자의 성격과 책임감에 대한 평가는 더 나쁘게 만들었다. “미리 말했으니 설명”이라는 형식만 빌려 자기평가를 보호하면 선제적 변명이 된다. 반대로 나중에 하는 말이 모두 변명인 것도 아니다. 2005년 두 연구에서는 피해자가 자신의 경험을 충분히 말하고 이해받았다고 느낀 뒤 받은 사과가 즉각적인 사과보다 효과적이었다. 위험과 사실은 빨리 알리되, 사과로 상대의 말을 끊어서는 안 된다는 뜻이다. 설명의 속도와 사과의 속도는 같은 문제가 아니다. ## 업무에서는 다섯 가지를 먼저 말하면 된다 1. 지금 확인된 사실 2. 예상되는 영향과 아직 모르는 범위 3. 상대가 지금 선택할 수 있는 대안 4. 내가 이미 시작한 조치 5. 다음 업데이트 시각 “외부 API 승인이 늦어지고 있습니다”에서 멈추면 보험성 문장이다. “승인이 오늘 안에 나지 않으면 출시가 최대 이틀 늦어집니다. 기능 범위를 줄이면 예정일을 지킬 수 있습니다. 대체 경로를 시험 중이며 오후 5시에 다시 보고하겠습니다”까지 말해야 설명이 된다. 리더는 나쁜 소식을 말한 사람을 벌하지 않고, 남은 선택지와 다음 업데이트 시각을 합의하는 보고 구조부터 만들어야 한다. --- 주요 출처: ゴッホ。, [“先に言えば、説明。後に言えば、言い訳。”](https://x.com/goho%5F%5F%5F/status/2080966446050668747?ref=zerodraftlab.com), 2026년 7월 25일; 和仁達也, [先に言えば説明、後で言えば言い訳。](https://jcfca.com/media/kiziitiran/cat02/5833.html?ref=zerodraftlab.com); Williams, Bourgeois & Croyle, [The Effects of Stealing Thunder in Criminal and Civil Trials](https://doi.org/10.1007/BF01044684?ref=zerodraftlab.com); Nguyen, Guyer & Fabrigar, [Stealing thunder: The influence of confession specificity and transgression severity](https://doi.org/10.1016/j.jesp.2021.104218?ref=zerodraftlab.com); Lee, [Weathering the crisis](https://doi.org/10.1016/j.pubrev.2016.02.005?ref=zerodraftlab.com); Kim & Lee, [How to maximize the effectiveness of stealing thunder in crisis communication](https://doi.org/10.1108/CCIJ-04-2021-0047?ref=zerodraftlab.com); Tesser, Rosen & Tesser, [On the Reluctance to Communicate Undesirable Messages](https://doi.org/10.2466/pr0.1971.29.2.651?ref=zerodraftlab.com); Scrimpshire 외, [Can we talk?](https://doi.org/10.1108/CDI-03-2021-0083?ref=zerodraftlab.com); Edmondson, [Psychological Safety and Learning Behavior in Work Teams](https://doi.org/10.2307/2666999?ref=zerodraftlab.com); Luginbuhl & Palmer, [Impression Management Aspects of Self-Handicapping](https://doi.org/10.1177/0146167291176008?ref=zerodraftlab.com); Frantz & Bennigson, [Better Late than Early](https://doi.org/10.1016/j.jesp.2004.07.007?ref=zerodraftlab.com). ### 스스로 쓰는 옵시디언은 쓰기 권한부터 나눠야 한다 URL: https://zerodraftlab.com/self-writing-vault-starts-with-write-boundaries/ Last updated: 2026-09-15T08:35:23.000Z 노트가 쌓일수록 지식은 늘어나는데, 쓸 수 있는 생각은 줄어든다. 캡처한 문장과 회의 기록, 읽다 만 글, 음성 메모가 수천 개 남아 있어도 다음 판단에 불려오지 않으면 저장 공간만 차지한다. chewa가 X에 올린 [‘스스로 쓰는 vault’에 관한 글](https://x.com/chewadot/status/2071564521735684253?ref=zerodraftlab.com)은 이 문제를 여덟 개 규칙으로 푼다. 음성으로 생각을 잡고, 모든 입력을 하나의 inbox에 넣고, 아침에는 Claude가 분류와 백링크를 맡고, 일요일에는 한 주의 생각을 다시 합성한다. `raw/`에 들어간 원본은 건드리지 않는다. 글은 포르투의 33세 과학 저널 편집자가 8년간 모은 2,400개 마크다운 파일을 Claude에 연결한 뒤 오래 묵은 원고를 끝냈다는 사례로 시작한다. 다만 인물의 이름이나 vault, 결과물을 확인할 링크는 없다. 이 일화는 검증된 사례보다 문제를 설명하는 장면으로 읽는 편이 안전하다. 그래도 여덟 규칙이 짚은 병목은 정확하다. 사람은 생각을 저장하는 데서 지치지 않는다. 저장한 생각을 다시 읽고, 겹치는 내용을 합치고, 오래된 주장과 새 주장의 충돌을 표시하는 유지보수에서 지친다. 노트 앱을 바꾸고 폴더 체계를 새로 만들어도 이 노동은 사라지지 않는다. ## 검색은 과거를 찾지만 위키는 과거를 고친다 Andrej Karpathy가 공개한 [LLM Wiki 패턴](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f?ref=zerodraftlab.com)은 같은 문제를 검색보다 한 단계 앞에서 다룬다. 일반적인 RAG는 질문이 들어올 때마다 원문 조각을 찾아 답을 조립한다. 좋은 답을 얻어도 그 과정에서 만들어진 연결과 반론은 다음 질문을 위해 남지 않는다. LLM Wiki에서는 에이전트가 원문과 사용자 사이에 영속적인 마크다운 위키를 만든다. 새 자료가 들어오면 요약 파일 하나를 추가하는 데서 멈추지 않는다. 기존 개념 페이지를 고치고, 관련 인물과 프로젝트를 연결하고, 앞선 주장과 충돌하는 부분을 표시한다. 한 번 만든 연결이 다음 질문의 출발점이 된다. 이 구조에서 Obsidian은 화면이고 마크다운 파일은 재료다. 실제 제품은 에이전트가 계속 유지하는 지식층이다. 그래프가 예뻐 보이는지보다 지난달의 판단이 오늘의 자료 때문에 어떻게 달라졌는지가 중요하다. 여기까지 보면 매일 아침 cron을 걸어두고 Claude에게 vault 전체를 맡기면 될 것 같다. 그러나 스스로 쓰는 vault의 품질은 실행 시각보다 쓰기 권한에서 갈린다. 에이전트가 모든 파일을 같은 권한으로 다루면 정리 속도만큼 원본 훼손과 오분류도 빨라진다. ## 원본을 보존해야 에이전트의 해석을 고칠 수 있다 음성 메모에는 말이 끊긴 자리와 당시의 감정, 아직 이름 붙이지 못한 의심이 남아 있다. 에이전트가 문장을 매끈하게 다듬는 순간 그 흔적은 쉽게 사라진다. 회의 기록도 마찬가지다. 요약본에는 결론이 남지만, 누가 무엇을 확신하지 못했는지와 어떤 조건을 달았는지는 빠질 수 있다. 그래서 `raw/`를 보존한다는 규칙은 백업 습관보다 중요하다. 원본과 에이전트의 해석을 분리해야 요약이 틀렸을 때 돌아갈 근거가 생긴다. 같은 자료를 다음 모델이 다시 읽을 수도 있고, 당시에는 사소해 보였던 문장이 2년 뒤 새로운 프로젝트의 단서가 될 수도 있다. 스스로 쓰는 vault는 에이전트가 자유롭게 쓰는 폴더가 아니다. 사람이 남긴 원본, 에이전트가 편집하는 지식, 둘 사이의 규칙을 서로 다른 층으로 나눈 시스템이다. 그렇다면 에이전트에게 어느 층까지 맡겨야 할까? 허용 범위는 파일 형식보다 지식의 수명에 따라 나누는 편이 낫다. 오래 보존할 원본에는 쓰기 권한을 주지 않고, 계속 수정되어야 할 위키에는 넓은 편집 권한을 주며, 두 층을 연결하는 규칙은 사람과 에이전트가 함께 고친다. ## 세 층을 섞으면 자동화가 기억을 오염시킨다 첫째 층은 불변 원본이다. 기사, 논문, 회의록, 음성 전사, 스크린샷, 데이터 파일이 들어간다. 에이전트는 읽고 인용할 수 있지만 덮어쓰거나 이름을 바꾸지 않는다. 잘못 들어온 파일도 삭제보다 상태 표시를 우선한다. 원본의 역할은 최신 설명이 아니라 나중에 다시 판정할 수 있는 증거이기 때문이다. 둘째 층은 에이전트가 유지하는 위키다. 인물, 회사, 개념, 프로젝트, 소스 요약, 여러 소스를 묶은 synthesis가 여기에 놓인다. 새 자료가 들어오면 관련 페이지를 함께 고치고, 출처를 링크하고, 모순을 표시한다. 사람이 매번 폴더를 고르는 수고는 줄어들지만 결과는 여전히 마크다운으로 읽고 비교할 수 있다. 셋째 층은 스키마다. `CLAUDE.md`나 `AGENTS.md` 같은 파일에 폴더 구조, 페이지 형식, 출처 표기, 민감정보 규칙, 삭제와 승격 조건을 적는다. 이 문서는 프롬프트 모음보다 운영 계약에 가깝다. 에이전트가 반복해서 잘못 분류하면 지시 한 줄을 덧붙이는 데서 끝내지 않고 분류 기준과 검증 절차를 고쳐야 한다. 이 세 층은 무인 자동화의 범위도 결정한다. 새 원본을 발견하고 임시 요약을 만드는 일은 예약 실행에 맡길 수 있다. 기존 위키의 중요한 주장을 뒤집거나 여러 프로젝트의 허브를 합치는 일은 diff와 근거를 남긴 뒤 반영해야 한다. 원본 삭제, 민감정보 이동, 외부 발행은 별도 승인 밖으로 밀어낸다. Karpathy도 ingest 과정에서 새 소스를 한 번에 하나씩 읽고, 무엇을 강조할지 사용자가 함께 정하는 방식을 선호한다고 적었다. 에이전트가 유지보수를 맡는다는 말은 사람이 판단에서 빠진다는 뜻이 아니다. 사람은 소스와 방향을 고르고, 에이전트는 요약·연결·모순 검출처럼 반복 비용이 큰 부분을 맡는다. ## 백링크 개수는 지식의 품질을 증명하지 못한다 chewa의 글은 새 노트마다 기존 노트 세 개, 그중 하나는 2년 이상 된 노트에 연결하라고 제안한다. 초기에는 고아 노트를 줄이는 자극이 될 수 있다. 그러나 할당량이 목표가 되면 에이전트는 의미가 약한 연결도 만들어낸다. 오래된 노트를 끼워 넣기 위해 주제보다 날짜를 먼저 보는 순간 그래프는 촘촘해져도 탐색 비용은 커진다. 연결에는 이유가 필요하다. 같은 개념을 보강하는지, 기존 주장을 반박하는지, 한 결정의 원인이거나 결과인지, 동일한 사람과 프로젝트를 다루는지 설명할 수 있어야 한다. 이 관계를 한 문장으로 적지 못하는 백링크는 숫자를 늘릴 뿐 다음 판단을 돕지 못한다. 그래프 밀도도 보조 지표로만 써야 한다. 연결 수가 늘었다는 사실은 활동량을 보여주지만, 오래된 오류가 고쳐졌는지와 중요한 질문에 더 빨리 답하게 됐는지는 말해주지 않는다. 주간 lint에서 고아 페이지, 출처 없는 주장, 서로 충돌하는 페이지, 오래되어 폐기된 판단을 함께 확인해야 그래프가 의미를 가진다. ## 주간 합성은 노트 정리가 아니라 판단 기록이다 여덟 규칙 중 가장 실용적인 것은 일요일 synthesis다. 일주일치 노트를 다시 요약하는 문서가 아니라, 반복해서 등장한 문제와 바뀐 판단, 아직 닫히지 않은 질문을 한 파일에 모은다. 사람이 다시 읽을 가능성이 높은 산출물도 개별 캡처보다 이 합성본이다. 좋은 주간 synthesis에는 이번 주에 무엇을 많이 기록했는가보다 무엇이 달라졌는가가 남는다. 기존 가설을 뒤집은 새 근거, 서로 다른 프로젝트에서 반복된 병목, 말만 하고 실행하지 않은 약속, 다음 주에 확인해야 할 반례를 적는다. 일간 노트가 사건의 로그라면 주간 합성은 판단의 변경 이력이다. 새 세션에 vault 전체를 밀어 넣을 필요도 없다. 현재 목표, 최근 결정, 열린 질문, 관련 페이지를 가리키는 작은 index를 먼저 읽히고 필요할 때 원본으로 내려가면 된다. 긴 컨텍스트보다 최신 경로가 중요하다. 처음부터 아침 7시 cron을 만들 이유는 없다. 같은 ingest를 몇 차례 수동으로 돌려 분류 기준과 실패 형태를 확인하고, 결과를 되돌릴 수 있을 때 예약 실행으로 옮기면 된다. 자동화의 완료 기준도 “파일을 옮겼다”가 아니라 출처를 유지했고, 기존 주장과의 차이를 남겼고, 사람이 다음 판단에 쓸 수 있는 synthesis를 만들었다가 되어야 한다. 시작할 때 필요한 폴더는 많지 않다. 원본을 받는 곳, 에이전트가 쓰는 위키, 검토 전 결과를 두는 곳, 운영 규칙 한 파일이면 충분하다. 첫 주에는 에이전트가 쓴 내용을 매번 읽고 잘못된 연결을 지운다. 반복해서 맞는 분류만 자동화한다. 그렇게 만든 vault는 대신 생각해주는 두 번째 뇌가 아니다. 과거의 원문을 보존하고, 현재의 해석을 계속 고치며, 다음 판단이 어디에서 왔는지 보여주는 작업 기록이다. 에이전트에게 맡길 일은 기억 자체가 아니라 기억을 유지하는 노동이다. --- 주요 출처: chewa, [The Self-Writing Vault: 8 Rules for Pointing Claude at Obsidian and Letting It Run Without You](https://x.com/chewadot/status/2071564521735684253?ref=zerodraftlab.com); Andrej Karpathy, [LLM Wiki](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f?ref=zerodraftlab.com). 포르투 편집자 사례는 원문에 검증 가능한 식별자나 결과물 링크가 없어 도입 사례로만 다뤘습니다. 쓰기 권한을 지식의 수명에 따라 나누고, 백링크 할당량보다 관계의 이유를 기록하며, 무인 실행을 단계적으로 넓혀야 한다는 주장은 두 자료를 바탕으로 한 이 글의 해석입니다. ### 길고양이 논쟁에서 철학자들은 서로 다른 생명을 센다 URL: https://zerodraftlab.com/cat-culling-moral-ledgers/ Last updated: 2026-09-15T08:35:23.000Z 길고양이 논쟁은 자주 사랑의 크기를 겨루는 싸움이 된다. 고양이를 걱정하면 야생동물을 외면한 사람으로 몰리고, 새를 걱정하면 고양이를 미워하는 사람으로 몰린다. 정작 양쪽이 무엇을 생명으로 세고 있는지는 뒤로 밀린다. 새덕후의 영상 [「고양이, 이젠 결단을 내려야합니다」](https://www.youtube.com/watch?v=Ev8JQQzdn6Q&ref=zerodraftlab.com)은 이 대립을 가장 거친 결론까지 밀어붙인다. 보호소와 입양에는 수용 한계가 있고 TNR만으로 개체 수를 줄이기 어렵기 때문에, 등록제와 실내 사육을 시행하고 국가가 길고양이를 포획해 제거해야 한다는 주장이다. 이 주장의 출발점은 가볍지 않다. 2023년 *Nature Communications*에 실린 전 세계 연구 종합은 자유롭게 돌아다니는 고양이의 먹이로 확인된 종을 2,084종으로 집계했다. 그중 347종은 보전 우려종이었다. 연구진은 섬에서 고양이에게 먹히는 보전 우려종의 수가 대륙보다 세 배 많다고 보고했다. 고양이가 야생동물을 사냥한다는 사실에서 곧바로 어떤 관리 정책이 옳다는 결론이 나오지는 않는다. 사실은 피해의 크기를 보여주지만, 누구의 손실을 먼저 셀지는 정해주지 않는다. 이 지점에서 철학자들은 서로 다른 장부를 펼친다. ## 벤담과 싱어는 고통의 총량을 센다 벤담이 동물을 도덕적으로 고려하는 기준으로 제시한 것은 이성이나 언어가 아니라 고통을 느낄 수 있는가였다. 피터 싱어의 동물해방론도 고통을 겪는 존재의 이해관계를 종이 다르다는 이유로 배제할 수 없다는 방향으로 이어진다. 이 장부에는 포획돼 죽는 고양이만 올라가지 않는다. 고양이에게 물려 죽는 새와 파충류, 부모를 잃는 새끼, 질병과 굶주림 속에서 살아가는 길고양이도 함께 올라간다. 고양이 한 마리의 눈에 보이는 죽음만 세고 야생동물의 반복되는 죽음을 빼면 계산이 편파적이다. 반대로 생태계라는 말로 고양이가 겪는 공포와 고통을 0으로 처리해도 같은 오류가 생긴다. 공리주의가 살처분을 자동 승인하는 것은 아니다. 어떤 방법이 실제로 개체 수와 야생동물 피해를 줄이는지, 포획 과정의 고통은 얼마나 되는지, 제거 뒤 다른 개체가 유입되는지까지 비교해야 한다. 총고통이 줄었다는 증거가 있어야 결론도 따라온다. ## 리건은 한 마리를 통계로 지우지 않는다 톰 리건은 동물을 쾌락과 고통을 담는 그릇으로만 보지 않았다. 기억하고 기대하며 자신에게 중요한 삶을 경험하는 ‘삶의 주체’에게는 고유한 가치가 있다고 봤다. 이 관점에서 죄 없는 고양이를 생태계 복원의 수단으로 죽이는 일은 총합 계산으로 정당화하기 어렵다. 특히 길고양이 문제의 상당 부분을 유기, 방목, 미등록 번식처럼 인간의 행동이 만들었다면 반론은 더 강해진다. 인간이 만든 위험의 비용을 고양이의 죽음으로 정산하는 셈이기 때문이다. 등록과 유기 방지, 실내 사육, 입양과 번식 차단을 충분히 시행하지 않은 국가가 먼저 살처분을 말할 자격이 있는지도 묻게 된다. ## 레오폴드는 한 종이 아니라 공동체를 본다 알도 레오폴드의 대지 윤리는 도덕 공동체의 범위를 흙, 물, 식물, 동물까지 넓힌다. 판단 단위도 개체 하나에서 생태공동체의 온전성과 안정성으로 이동한다. 인간이 데려온 포식자가 섬의 토착종을 사라지게 한다면, 아무것도 하지 않는 선택도 중립이 아니다. 이 관점은 영상의 결론에 가장 가까이 선다. 제거되는 고양이의 수보다 그 개입이 생태공동체의 회복에 기여하는지를 본다. 다만 레오폴드의 원칙을 “생태계를 위해 개체는 언제든 희생할 수 있다”로 줄이면 곤란하다. 알도 레오폴드 재단의 해설도 대지 윤리를 개체에 대한 관심과 공동체에 대한 책임을 함께 담는 윤리로 설명한다. 같은 피해 자료를 보고도 결론이 갈리는 이유가 여기에 있다. 각자가 다른 생명을 빼먹어서가 아니라, 다른 단위를 도덕적 장부의 첫 줄에 올려놓는다. 그렇다면 국가는 무엇을 세어야 하는가. 국가는 세 장부 중 하나만 고를 수 없다. 개체의 고통만 세면 멸종과 서식지 붕괴처럼 되돌리기 어려운 손실이 사라지고, 생태계만 세면 실제로 포획되고 죽는 동물이 숫자로 납작해진다. 인간의 책임을 빼면 유기와 방목을 방치한 채 가장 약한 개체에게 비용을 넘기게 된다. ## 요나스는 되돌릴 수 없는 손실을 먼저 본다 한스 요나스의 책임 윤리는 현재의 행동이 먼 미래의 생명 조건까지 바꿀 만큼 강해졌다는 데서 출발한다. 현재 세대와 미래 세대의 관계에는 힘의 비대칭이 있다. 우리는 미래의 선택지를 줄일 수 있지만, 미래의 존재는 지금 우리의 결정을 고칠 수 없다. 이 관점에서 종의 소멸은 특별한 무게를 가진다. 관리 정책은 바꿀 수 있지만 멸종은 되돌리기 어렵다. 피해가 확인된 보전 핵심 지역에서 완전한 확실성을 기다리는 것도 책임 있는 태도라고 보기 어렵다. 그러나 예방 원칙은 백지수표가 아니다. “생태계에 위험할 수 있다”는 문장만으로 전국의 길고양이를 하나의 방식으로 처리할 수는 없다. 지역별 개체 수, 유입 경로, 사냥 피해, 번식률, 대안의 효과를 측정하고 개입 뒤 결과를 다시 공개해야 한다. 불확실성이 행동의 이유라면, 같은 불확실성은 개입 범위를 제한하는 이유이기도 하다. ## 푸코는 누가 죽일 권한을 갖는지 묻는다 푸코의 생명정치에서 현대 국가는 개별 사건만 처벌하지 않는다. 통계와 행정 지식을 이용해 인구를 분류하고 출생, 질병, 이동, 죽음을 관리한다. 길고양이가 몇 마리인지 세고, 반려동물과 유기동물과 야생화된 개체를 나누고, 특정 지역의 개체군을 제거하는 일도 이런 통치 기술의 일부다. 이 시선은 관리 자체를 금지하지 않는다. 대신 분류와 수치가 어떻게 정당성을 만드는지 추적한다. 어떤 고양이는 집 안에서 보호받고 어떤 고양이는 위치와 소유관계 때문에 제거 대상이 된다. 어느 부처가 어떤 근거로 개체를 분류하며, 누가 피해와 성공을 측정하는지 공개되지 않으면 ‘과학적 관리’는 책임 주체를 숨기는 말이 될 수 있다. 영상이 개인의 사적 포획보다 국가의 공식 정책을 요구하는 이유도 여기서 중요해진다. 공권력이 맡는다고 윤리 문제가 사라지는 것은 아니지만, 최소한 법적 기준, 포획 방식, 지역 범위, 사후 평가와 이의제기 절차를 요구할 수 있다. 개인의 혐오와 생태 관리가 뒤섞이지 않게 만드는 장치도 필요하다. ## TNR의 효과는 구호가 아니라 조건의 문제다 TNR을 두고 “효과가 있다”와 “효과가 없다”만 반복하면 정책 조건이 사라진다. 관련 연구는 장기간 지속되는 높은 중성화율, 새 개체의 유입 통제, 새끼의 입양과 지속적인 모니터링이 필요하다고 지적한다. 실제 현장에서는 이런 조건을 얼마나 충족했는지에 따라 결과가 크게 달라질 수 있고, 엄격한 개체 수 추적 자료도 충분하지 않다. 따라서 TNR의 한계를 말하는 것과 살처분만이 유일한 해결책이라고 선언하는 것은 같은 문장이 아니다. 보전 가치가 높은 섬과 도심 주거지는 위험과 목표가 다르다. 한쪽에는 신속한 제거가 필요할 수 있고, 다른 쪽에는 유입 차단과 집중 중성화, 입양이 더 적합할 수 있다. 정책은 동물의 이름보다 장소의 생태와 관리 가능성을 기준으로 설계해야 한다. ## 도덕적 정책은 무엇을 셌는지 공개한다 길고양이 관리가 정당하려면 세 가지 결과가 함께 보여야 한다. 고양이의 고통을 가능한 한 낮췄는가. 토착 야생동물의 피해를 실제로 줄였는가. 유기와 방목, 무등록 번식처럼 인간이 계속 만드는 유입 경로를 막았는가. 이 가운데 하나라도 빠지면 정책은 오래가지 못한다. 포획만 하고 유입을 막지 않으면 같은 장소에 다시 개체가 채워진다. TNR만 하고 야생동물 피해를 측정하지 않으면 중성화된 포식자가 계속 사냥할 수 있다. 생태계만 말하고 포획 과정의 고통을 감추면 과학은 잔혹함의 면허처럼 들린다. 철학자들은 하나의 정답을 주지 않는다. 대신 정책이 숨긴 비용을 서로 다른 장부에서 찾아낸다. 벤담과 싱어는 모든 동물의 고통을, 리건은 죽게 될 개체의 고유한 삶을, 레오폴드는 토착 생태공동체를, 요나스는 미래에 되돌릴 수 없는 손실을, 푸코는 그것을 분류하고 집행하는 권력을 보게 한다. 국가가 내려야 할 결단은 “고양이를 사랑할 것인가”가 아니다. 어느 지역에서 어떤 손실이 발생하고 있으며, 가장 적은 고통으로 그 손실을 줄이는 조합이 무엇인지 증명하는 일이다. 제거가 필요한 지역이라면 범위와 근거, 방법과 결과를 공개해야 한다. 그렇지 않은 지역이라면 유기와 방목부터 막고 비살상 관리가 효과를 내는 조건을 만들어야 한다. --- 주요 출처: [Lepczyk 외, “A global synthesis and assessment of free-ranging domestic cat diet”](https://www.nature.com/articles/s41467-023-42766-6?ref=zerodraftlab.com); Stanford Encyclopedia of Philosophy의 [The Moral Status of Animals](https://plato.stanford.edu/entries/moral-animal/?ref=zerodraftlab.com), [Environmental Ethics](https://plato.stanford.edu/entries/ethics-environmental/?ref=zerodraftlab.com), [Intergenerational Justice](https://plato.stanford.edu/entries/justice-intergenerational/?ref=zerodraftlab.com), [Michel Foucault](https://plato.stanford.edu/entries/foucault/?ref=zerodraftlab.com); Aldo Leopold Foundation의 [Understanding the Land Ethic](https://www.aldoleopold.org/blogs/understanding-the-land-ethic?ref=zerodraftlab.com); TNR의 조건과 근거 한계를 다룬 [Coe 외의 5년 추적 연구](https://nsojournals.onlinelibrary.wiley.com/doi/10.2981/wlb.00799?ref=zerodraftlab.com)와 [Boone의 관리 검토](https://journals.sagepub.com/doi/10.1177/1098612X15594995?ref=zerodraftlab.com). 새덕후 영상은 논쟁과 논증을 발견한 출발점으로 사용했으며, 영상 속 수치나 정책 효능을 단독 사실 근거로 옮기지 않았다. ### 좋은 습관에는 ‘느린 도파민’이 필요 없다 URL: https://zerodraftlab.com/good-habits-do-not-need-slow-dopamine/ Last updated: 2026-08-30T02:52:47.000Z The Preserver는 남성에게 “느린 도파민”을 고르라며 열다섯 가지 활동을 권했다. 어려운 기술을 배우고, 직접 요리하고, 긴 책을 읽고, 이어폰 없이 걷고, 노을을 보고, 친구에게 전화하라는 목록이다. 손으로 무언가를 만들고, 중량을 들고, 보드게임과 퍼즐을 하고, 휴대폰 없이 영화를 보고, 식물을 기르고, 천천히 호흡하고, 생각을 기록하라는 조언도 이어진다. > “DEAR MEN, PLEASE CHOOSE SLOW DOPAMINE” > > — 𝐓𝐡𝐞 𝐏𝐫𝐞𝐬𝐞𝐫𝐯𝐞𝐫 (@ThePreserverofU) [July 22, 2026](https://x.com/ThePreserverofU/status/2080038424245899755?ref%5Fsrc=twsrc%5Etfw&ref=zerodraftlab.com) 임베딩이 보이지 않으면 [X 원문](https://x.com/ThePreserverofU/status/2080038424245899755?ref=zerodraftlab.com)에서 볼 수 있다. 목록은 대체로 건강하다. 이름이 문제다. 서로 다른 활동의 효용을 “도파민이 천천히 나온다”는 하나의 생물학적 설명으로 묶는 순간, 좋은 생활 조언은 측정하지 않은 신경과학 주장으로 바뀐다. ## 연구에서 말하는 ‘느린 도파민’은 다른 뜻이다 2026년 7월 23일 PubMed에서 제목과 초록에 정확히 *slow dopamine*이 들어간 논문을 검색하면 여덟 건이 나온다. 최근 두 편이 다룬 것은 독서와 산책의 차이가 아니다. 건강한 성인 20명에게 메틸페니데이트를 정맥으로 투여해 빠르게, 경구로 투여해 느리게 도파민을 증가시킨 뒤 PET-fMRI로 약물 보상과 뇌 연결성의 차이를 본 연구다. 여기서 빠름과 느림은 일상 활동의 품질이 아니라 약물이 뇌에 도달하는 속도다. *Dopamine fasting*이라는 표현은 PubMed에 2024년 문헌고찰 한 편이 잡힌다. 그 논문도 개념의 과학적 근거가 부족하다는 비판과 극단적 단식·고립의 위험을 함께 적었다. ClinicalTrials.gov에서 *dopamine fasting*과 *dopamine detox*를 정확히 검색한 등록 연구는 같은 날 기준 0건이었다. 생활 습관을 “느린 도파민”으로 분류하는 임상적 기준, 측정법, 개입 프로토콜은 아직 확립되지 않았다. 도파민 자체도 행복의 양을 표시하는 단순한 연료가 아니다. 보상을 예측하고, 단서를 학습하고, 행동에 힘을 배분하는 과정에 관여한다. 여러 시간척도의 도파민 신호가 존재한다는 사실과 특정 취미가 “느린 도파민 활동”이라는 주장은 별개의 문장이다. ## 목록에서 근거가 비교적 단단한 활동 중량운동은 이 목록에서 가장 근거가 분명한 축에 속한다. 33개 무작위 임상시험, 1,877명을 합친 메타분석에서 저항운동은 우울 증상을 중간 정도 줄이는 결과와 연관됐다. 연구 간 이질성은 컸고, 이 결과가 모든 사람의 우울증 치료를 대신한다는 뜻은 아니다. 확인된 것은 훈련과 증상의 관계이지 도파민 방출 속도가 아니다. 느린 호흡도 비슷하다. 12개 무작위시험, 성인 785명을 합친 메타분석에서 호흡 훈련은 대조군보다 주관적 스트레스를 작거나 중간 정도 줄였다. 불안과 우울 증상에서도 비슷한 방향이 나왔지만 다수 연구의 비뚤림 위험은 중간 수준이었다. 원 논문 저자들도 유행의 크기가 근거를 앞서지 않도록 주의해야 한다고 썼다. 정원 가꾸기는 웰빙과 삶의 질에 긍정적인 결과를 보인 40개 리뷰를 다시 모은 우산형 문헌고찰이 있다. 다만 개입, 대상과 측정치가 크게 달라 직접적인 임상 처방으로 옮기기 어렵다. 손으로 만드는 공예 역시 19개 연구가 단기 개선을 보고했지만 설계와 품질의 편차가 커 확정적 결론은 이르다. 보드게임의 인지 효과는 주로 고령자나 인지 저하 위험군에서 연구됐다. “모든 남성의 도파민을 느리게 만든다”는 범용 처방으로 넓힐 근거는 아니다. ## 휴대폰을 치우는 효과는 도파민 해독과 다르다 휴대폰 없는 영화와 이어폰 없는 산책을 직접 시험한 연구는 찾기 어렵다. 휴대폰의 방해 효과를 다룬 근거는 있다. 알림음이나 진동만 받아도 기기를 직접 만지지 않은 사람의 주의 과제 수행이 흐트러졌다는 실험이 있다. 문제는 도파민의 속도보다 진행 중인 과제를 끊는 신호다. 2025년 한 무작위 대조시험에서는 참가자 467명이 2주 동안 스마트폰의 모바일 인터넷을 차단하는 개입에 등록했다. 실제로 14일 중 10일 이상 차단을 유지한 사람은 119명이었다. 연구진의 사전등록 분석에서는 주관적 웰빙, 정신건강과 지속주의가 개선됐다. 참가자들은 대면 교류, 운동, 자연과 취미에 더 많은 시간을 썼다. 연구진도 기대 효과, 선별된 표본과 낮은 순응도를 한계로 적었다. 스마트폰 사용을 3주 동안 하루 두 시간 이하로 줄인 건강한 학생 111명의 시험에서도 스트레스, 웰빙, 우울 증상과 수면에서 단기 개선이 나타났다. 개입이 끝나자 사용 시간은 빠르게 원래 수준에 가까워졌다. 반면 소셜미디어 완전 중단 연구 10개, 4,674명을 합친 2025년 메타분석에서는 긍정 정서, 부정 정서와 삶의 만족도에 유의한 평균 효과가 없었다. 연결을 전부 끊는 의식보다 알림, 사용 시간과 접근 경로를 구체적으로 바꾸는 개입이 더 정확한 질문이다. ## 열다섯 가지는 하나의 처방이 아니다 긴 책 읽기의 장기 인지 효과를 살핀 연구는 주로 고령자를 대상으로 하며 결과도 일관되지 않다. 노을을 더 보는 횟수, 산책할 때 이어폰을 빼는 행위, 휴대폰 없이 영화 한 편을 보는 행위를 각각 “느린 도파민”과 연결한 직접 근거는 없다. 일일 회고와 저널 쓰기는 사실상 겹치는 항목이다. 표현적 글쓰기 연구도 대상과 글쓰기 방식에 따라 효과가 달랐다. 성별을 붙일 근거도 없다. 인용된 운동, 호흡, 정원 가꾸기, 디지털 사용 개입은 남성만을 위한 기전을 제시하지 않는다. “남자라면”은 연구 결과가 아니라 게시물의 독자 설정이다. 이 목록을 쓸 방법은 있다. 집중이 문제라면 30분 동안 알림을 끄고 휴대폰을 다른 방에 둔다. 스트레스가 문제라면 저항운동이나 느린 호흡을 일정에 넣는다. 고립이 문제라면 친구에게 전화할 시간을 먼저 잡는다. 한 활동을 고르고 수면, 기분, 과제 완료율이 실제로 달라지는지 관찰한다. 효과가 남으면 습관을 유지하면 된다. 그 습관을 지키는 데 “느린 도파민”이라는 설명은 필요하지 않다. --- 주요 출처: The Preserver, [“DEAR MEN, PLEASE CHOOSE SLOW DOPAMINE”](https://x.com/ThePreserverofU/status/2080038424245899755?ref=zerodraftlab.com), 2026년 7월 22일; PubMed, [“slow dopamine” 제목·초록 검색](https://pubmed.ncbi.nlm.nih.gov/?term=%22slow+dopamine%22%5BTitle%2FAbstract%5D&ref=zerodraftlab.com) 및 [dopamine fasting 문헌고찰](https://pubmed.ncbi.nlm.nih.gov/38966464/?ref=zerodraftlab.com); Manza 외, [약물 보상에서 빠르고 느린 도파민 증가](https://doi.org/10.1038/s41467-023-41972-6?ref=zerodraftlab.com) 및 [뇌 연결성 차이](https://doi.org/10.1038/s41386-024-01803-8?ref=zerodraftlab.com); Berke, [도파민, 보상 예측과 동기](https://doi.org/10.1038/s41593-018-0152-y?ref=zerodraftlab.com); Gordon 외, [저항운동과 우울 증상 메타분석](https://pubmed.ncbi.nlm.nih.gov/29800984/?ref=zerodraftlab.com); Fincham 외, [호흡 훈련 메타분석](https://pubmed.ncbi.nlm.nih.gov/36624160/?ref=zerodraftlab.com); Gerber 외, [정원 가꾸기 우산형 문헌고찰](https://pubmed.ncbi.nlm.nih.gov/38287430/?ref=zerodraftlab.com); Stothart 외, [휴대폰 알림의 주의 비용](https://pubmed.ncbi.nlm.nih.gov/26121498/?ref=zerodraftlab.com); Castelo 외, [스마트폰 모바일 인터넷 차단 무작위시험](https://doi.org/10.1093/pnasnexus/pgaf017?ref=zerodraftlab.com); Pieh 외, [스마트폰 화면 시간 감축 무작위시험](https://pubmed.ncbi.nlm.nih.gov/39985031/?ref=zerodraftlab.com); Hall 외, [소셜미디어 중단 메타분석](https://pubmed.ncbi.nlm.nih.gov/40038410/?ref=zerodraftlab.com); ClinicalTrials.gov, [“dopamine fasting” 등록 연구 검색](https://clinicaltrials.gov/search?term=%22dopamine%20fasting%22&ref=zerodraftlab.com). ### 코르티솔은 당신의 인생 성적표가 아니다 URL: https://zerodraftlab.com/cortisol-is-not-your-life-score/ Last updated: 2026-09-15T08:35:24.000Z “삶을 싫어하고, 온종일 실내에 있고, 카페인을 들이붓고, 잠을 자지 않고, 주말을 술로 보내고, 비극을 계속 확인하고, 둠스크롤링하면 코르티솔이 높아진다.” [Peyton Elroy](https://x.com/PeytonElroy?ref=zerodraftlab.com)의 짧은 게시물은 나쁜 생활의 목록을 하나의 호르몬으로 묶는다. 피곤하고 초조하며 삶이 마음에 들지 않는 이유가 혈액 속 숫자 하나로 번역된다. 그래서 강하다. 복잡한 불만에 생물학적 이름을 붙이면, 막연했던 문제가 갑자기 측정 가능하고 고칠 수 있는 것처럼 보인다. 수면 부족, 카페인, 과음, 지속적인 스트레스는 몸의 스트레스 반응과 서로 영향을 주고받는다. 그러나 섬유질 부족, 뒷담화, 포르노, 관계에 대한 원망, 실내 생활까지 모두 같은 강도의 직접 원인처럼 놓을 수는 없다. **코르티솔은 당신의 인생에 매기는 도덕 점수가 아니다. 생활이 엉켰다는 감각과 의학적으로 확인된 코르티솔 과다는 같은 말도 아니다.** ## 코르티솔에는 정상 리듬이 있다 코르티솔은 정상적인 생존에 필요한 호르몬이다. 혈압과 에너지 사용, 면역 반응에 관여하고, 아침에는 올라가 깨어날 준비를 돕고 밤에는 낮아지는 일중 리듬을 가진다. 운동이나 급한 상황에서 일시적으로 오르는 반응도 몸이 고장 났다는 뜻이 아니다. 코르티솔 수치는 측정 시각, 복용 약, 수면과 음주 상태, 반복 측정에서 나타나는 패턴에 따라 의미가 달라진다. “스트레스 호르몬”이라는 별명만으로는 정상 반응과 질환을 구분할 수 없다. 내분비학회는 쿠싱증후군을 평가할 때 무작위 혈중 코르티솔을 진단 검사로 쓰지 말라고 권고한다. 대신 24시간 소변, 심야 타액, 덱사메타손 억제처럼 시간과 생리 리듬을 반영하는 검사를 사용하고, 이상 소견도 다른 검사로 확인한다. 피로, 체중 변화, 우울감처럼 흔한 증상만으로 광범위하게 검사하는 것도 권하지 않는다. 인터넷에서는 “코르티솔이 높다”가 거의 모든 불편의 설명으로 쓰이지만, 진료실에서는 오히려 한 번의 숫자를 경계한다. 호르몬이 실제로 변하기 때문에 호르몬을 제대로 측정하기가 어렵다. ## 한 문장 안에 생리, 습관, 관계, 도덕 판단이 섞여 있다 카페인은 비교적 직접적인 사례다. 무작위 교차시험에서 카페인은 코르티솔 반응을 높였고, 매일 섭취하면 반응이 줄지만 완전히 사라지지는 않았다. 그렇다고 커피를 마신 순간 건강이 나빠졌다는 뜻은 아니다. 용량, 시간, 내성, 수면 손실과 함께 봐야 한다. 술도 단순히 “코르티솔을 올린다”로 끝나지 않는다. 급성 음주는 스트레스 축을 활성화할 수 있지만, 만성적이고 많은 음주는 반응을 무디게 하고 조절을 흐트러뜨릴 수 있다. 기능 이상은 언제나 숫자가 높아지는 한 방향으로만 나타나지 않는다. 수면 부족에 관한 연구도 조건에 따라 결과가 달라진다. 급성 수면 박탈 연구 24건을 모은 메타분석은 전체 분석에서 코르티솔의 유의한 차이를 확인하지 못했다. 혈청을 사용하거나 여러 번 측정한 하위분석에서는 증가가 보였지만, 아침·오후·저녁 시간대별 분석에서는 차이가 없었다. 수면 박탈 뒤 급성 스트레스 반응을 다룬 다른 체계적 문헌고찰도 일관된 결론을 내릴 근거가 부족하다고 평가했다. “잠을 못 자면 코르티솔이 오른다”는 문장은 생활 조언으로는 그럴듯하지만, 모든 시간대와 사람에게 같은 생리 법칙은 아니다. 부정적 뉴스도 비슷하다. 실제 뉴스를 읽힌 한 실험에서 뉴스 자체가 코르티솔을 즉시 유의하게 올리지는 않았다. 다만 여성 참가자는 이후 스트레스 과제에서 더 큰 코르티솔 반응을 보였고 부정적 뉴스를 더 잘 기억했다. 둠스크롤링의 해로움을 말할 수는 있어도, 화면을 내릴 때마다 호르몬이 누적된다고 단정할 수는 없다. “코르티솔”이라는 단어를 지우면 이 게시물이 포착한 더 오래된 문제가 보인다. 회복을 계속 다음 날로 미루는 생활 구조다. 피곤해서 카페인을 늘리고, 늦게까지 깨어 있기 위해 다시 자극을 찾고, 잠이 얕아져 다음 날 더 많은 카페인을 찾는다. 술로 주말의 긴장을 껐다가 수면과 기분이 흔들리고, 월요일에는 다시 버티기 모드로 들어간다. ## 호르몬보다 먼저 보이는 것은 회복 부채의 순환이다 이 순환에서 코르티솔은 원인 하나라기보다 여러 반응 중 하나다. 수면 시간, 각성제, 음주, 빛, 움직임, 일의 통제감, 관계 갈등이 서로 영향을 준다. 하나의 숫자를 낮추려 하면 “코르티솔 디톡스” 같은 새 소비가 생기기 쉽지만, 순환을 보면 어디에서 빚이 시작되고 어디에서 이자가 붙는지가 보인다. 가령 오후 늦은 카페인은 당장의 각성을 사지만 밤의 수면 압력을 약하게 만들 수 있다. 부족한 잠은 다음 날 카페인의 가치를 더 크게 만든다. 이렇게 오늘의 각성을 내일의 회복에서 계속 빌리면 카페인 습관이 회복 부채를 키운다. 음주도 같은 방식으로 본다. 술을 마셨을 때의 코르티솔 변화만 붙잡으면 중요한 장면을 놓친다. 실제 손실은 술이 스트레스 해소의 기본 버튼이 되고, 수면과 기분이 흔들리며, 회복되지 않은 상태에서 다시 스트레스를 견뎌야 하는 반복에 있을 수 있다. 둠스크롤링은 행동으로 옮길 수 없는 위협을 끝없이 공급한다. 뉴스를 확인했지만 해결할 수 있는 일은 늘지 않고, 몸과 주의만 다음 경보를 기다린다. 정보가 부족해서 계속 보는 것이 아니라 불안을 끝내기 위해 보는데, 피드는 끝나지 않으므로 종료 신호도 오지 않는다. ## 생물학의 언어가 생활을 도덕 재판으로 바꾸기도 한다 반대로 섬유질, 뒷담화, 포르노, 파트너에 대한 원망은 같은 칸에 놓으면 안 된다. 섬유질은 영양의 문제이고, 뒷담화는 사회적 행동이며, 포르노와 원망은 사용 방식과 관계 맥락을 살펴야 한다. 각각 중요한 결과를 만들 수 있지만, “코르티솔을 올리는 나쁜 사람의 습관”으로 묶는 순간 근거보다 수치심이 앞선다. 이런 도덕화는 실행에도 불리하다. 삶을 싫어해서 호르몬이 망가졌다고 믿으면 고쳐야 할 대상이 너무 커진다. 직업, 관계, 식사, 뉴스, 성생활, 수면, 카페인, 음주를 한꺼번에 정화하려다 며칠 만에 실패한다. 실패는 다시 자기혐오의 증거가 되고, 자기혐오는 더 강한 통제 계획을 부른다. 반면 회복 부채로 보면 시작점은 작고 구체적이다. 일정한 기상 시간을 지키고, 오후의 카페인이 밤에 남는지 보고, 술이 다음 날 수면과 기분에 남기는 흔적을 확인하고, 행동할 수 없는 뉴스를 보는 종료 시점을 만든다. 낮의 빛과 움직임, 사람과의 실제 접촉을 늘리는 것도 “코르티솔 해킹”이 아니라 리듬과 회복 기회를 되찾는 일이다. 싫어하는 일과 통제할 수 없는 일정, 지속적인 관계 갈등은 호흡법으로 해결되지 않는다. 수면과 자극을 정리하면 나쁜 구조를 더 오래 견딜 힘이 아니라, 무엇을 바꿔야 하는지 판단할 체력을 되찾을 수 있다. ## 생활 불만과 내분비 질환은 분리해서 다뤄야 한다 피로하거나 불안하다는 이유만으로 고코르티솔을 자가진단할 필요는 없다. 반대로 의사가 처방한 스테로이드 노출이 있거나, 나이에 비해 이례적이고 여러 진행성 징후가 함께 나타난다면 생활 습관 콘텐츠로 덮지 말고 진료에서 평가해야 한다. 내분비 질환은 의지 문제도, 인생 태도의 심판도 아니다. Peyton Elroy의 문장은 현대 생활의 여러 습관이 한 방향으로 회복을 깎는 장면을 잘 포착했다. 다만 그 모든 결과에 코르티솔이라는 이름을 붙이면서 의학적 주장과 생활 비평의 경계가 사라졌다. **이 문장은 코르티솔을 낮추라는 처방보다, 수면·자극·음주·뉴스 소비가 서로를 악화시키는 고리를 찾으라는 경고로 읽을 때 더 쓸모 있다.** --- 주요 출처: [Endocrine Society, 쿠싱증후군 진단 가이드라인](https://www.endocrine.org/clinical-practice-guidelines/diagnosis-of-cushing-syndrome?ref=zerodraftlab.com); 미국 NIDDK의 [Cushing’s Syndrome](https://www.niddk.nih.gov/health-information/endocrine-diseases/cushings-syndrome?ref=zerodraftlab.com); 카페인과 코르티솔 반응을 다룬 [무작위 교차시험](https://pubmed.ncbi.nlm.nih.gov/16204431/?ref=zerodraftlab.com); 급성 수면 박탈과 코르티솔의 [체계적 문헌고찰·메타분석](https://pubmed.ncbi.nlm.nih.gov/38777757/?ref=zerodraftlab.com) 및 수면 박탈 뒤 스트레스 반응의 [체계적 문헌고찰](https://pubmed.ncbi.nlm.nih.gov/38991306/?ref=zerodraftlab.com); 미국 NIAAA의 [알코올과 내분비계 리뷰](https://arcr.niaaa.nih.gov/media/551/download?ref=zerodraftlab.com); 부정적 뉴스와 스트레스 반응을 다룬 [실험 연구](https://pmc.ncbi.nlm.nih.gov/articles/PMC3468453/?ref=zerodraftlab.com); 미국 NIMH의 [정신건강 자기관리 안내](https://www.nimh.nih.gov/health/topics/caring-for-your-mental-health?ref=zerodraftlab.com). 이 글은 의학적 진단이나 개인 치료 지시가 아닙니다. ### 전환율을 올리는 문구는 창고에서 시작된다 URL: https://zerodraftlab.com/conversion-copy-starts-in-warehouse/ Last updated: 2026-09-15T08:35:25.000Z 결제 버튼 아래에 “Ships by Tomorrow”라는 문장을 붙인 실험이 공개됐다. 고객이 결제를 누르기 직전, 주문이 내일 발송된다는 약속을 보여준 것이다. [공개된 대시보드](https://x.com/DaveDiederen/status/2076985061056852039?ref=zerodraftlab.com)에서 메시지 그룹의 전환율은 3.16%에서 3.37%로 올랐다. 상대 상승률은 6.65%였다. 방문자당 매출은 9.04%, 방문자당 이익은 9.31% 높았다. 작은 문장 하나가 월 주문 702건과 매출 5만5천 달러를 더 만든다는 추정치도 붙었다. 숫자는 매력적이지만 아직 승리를 선언할 단계는 아니다. 전환율 상승의 95% 구간은 -1%에서 +15%, 방문자당 이익은 -2%에서 +22%였다. 둘 다 0을 걸친다. Intelligems가 권하는 그룹별 주문 수와 실험 기간, 대조군을 이길 확률도 공개되지 않았다. 월간 증분 역시 실현된 매출이 아니라 관측된 상승률을 월간 트래픽에 곱한 추정이다. 그런데 이 불완전한 실험은 꽤 정확한 문제를 건드렸다. 장바구니에 상품을 담은 사람은 주문 뒤에 일어날 일을 모른다. 언제 출고되는지, 언제 받는지, 기다리다 후회할지 알 수 없다. 결제 버튼 옆의 배송 약속은 구매 뒤의 시간을 보이게 만든다. Baymard의 결제 사용성 연구에서도 같은 장면이 반복됐다. “3\~5영업일 배송”만 본 참가자들은 주말과 주문 마감시간을 머릿속으로 계산했고, 어떤 사람은 달력까지 열었다. 조사 대상 사이트의 41%는 배송 선택 화면에 예상 도착일을 제공하지 않았다. 사용자는 상품을 받는 날짜를 알고 싶어 했다. 그래서 “내일 발송”보다 “7월 25일 토요일 도착 예정”이 더 완성된 약속이다. 발송일은 판매자의 행동을 설명한다. 도착일은 고객의 계획을 돕는다. 선물, 여행 준비물, 행사 의상처럼 날짜가 구매 이유와 연결된 상품일수록 이 차이는 커진다. **좋은 배송 문구는 설득을 더하지 않는다. 거래가 끝난 뒤의 불확실성을 줄인다.** 이제 고객에게 보이는 한 줄을 어떤 운영 데이터가 보증해야 하는지 살펴볼 차례다. 정확한 도착일을 만들려면 재고 위치, 주문 마감시간, 창고 휴무일, 상품별 포장 시간, 택배사 집하 시간, 목적지 우편번호가 한 계산에 들어가야 한다. 금요일 오후 주문에 월요일 출고 규칙을 적용하지 않으면 잘못 계산된 “내일 도착”이 오배송 예고가 된다. 선물 포장이나 예약 상품처럼 처리 시간이 다른 주문도 같은 약속을 쓰면 안 된다. Shopify의 Shop Promise가 과거 주문 처리 기록과 운송 시간을 이용하고, 빠르고 안정적으로 배송한 상위 판매자에게만 배지를 여는 이유가 여기에 있다. Shopify는 Promise가 표시된 상품 페이지에서 최대 25%의 상대 전환 상승을 제시한다. 상세 표본과 신뢰구간이 공개된 독립 연구는 아니지만, 배송 문구가 재고·물류 데이터와 결합될 때 하나의 제품 기능이 된다는 점은 분명하다. Maude가 공개한 실험도 정적인 문구보다 계산된 날짜 쪽을 지지한다. 이 브랜드는 대조군, 예상 도착일 표시군, 예상 도착일과 무료배송 기준을 함께 보여준 그룹으로 나눠 2주간 시험했다. 솔루션 판매사가 공개한 사례라는 한계가 있지만, 도착일만 보여준 그룹에서 전환율 12%와 이익 10% 상승을 보고했다. 문구를 하나 더 얹은 세 번째 그룹보다 배송 불확실성 하나만 제거한 그룹이 이겼다. ## 빠른 약속은 기대치라는 부채를 만든다 배송 약속에는 전환 대시보드에 바로 나타나지 않는 비용이 있다. Tmall 거래 자료를 분석한 *Decision Support Systems* 연구에서는 특급배송 약속을 받은 주문이 같은 시간에 배송된 일반 주문보다 더 낮은 평점을 받았고, 리뷰도 덜 남겼다. 약속보다 일찍 도착해도 이 효과가 이어졌다. 빠른 배송이라는 문장이 고객의 기준점을 먼저 끌어올렸기 때문이다. 구매 전환만 최적화하면 이 비용을 놓친다. “내일 도착”이 주문을 늘려도 실제 약속 준수율이 떨어지고 배송 문의, 취소, 환불, 낮은 평점이 늘면 얻은 전환을 다시 토해낸다. 카피 테스트가 물류 성과와 분리될 수 없는 이유다. 실제로 시험한다면 대조군과 실험군의 문장만 비교해서는 부족하다. 핵심 지표는 방문자당 기여이익으로 잡고, 결제 진입률과 구매 전환율을 함께 본다. 동시에 약속일 준수율, 지연 취소와 환불, “언제 오나요” 문의, 후기와 재구매를 보호 지표로 둬야 한다. 한 주 이상 운영하면서 요일 효과를 지나고, 실험 전에 정한 표본 수와 중단 기준을 지킨다. 표현도 데이터의 정밀도에 맞춰야 한다. 지역별 도착일을 안정적으로 계산할 수 있으면 날짜를 보여준다. 출고까지만 통제할 수 있으면 “오후 2시 전 결제 시 오늘 출고”라고 쓴다. 변동성이 큰 상품에는 넓은 도착 범위를 제공하고, 택배 지연이 발생하면 약속을 자동으로 보수적으로 바꾼다. 모든 방문자에게 같은 다섯 단어를 보여주는 방식은 쉽지만 가장 쉽게 거짓말이 된다. 디지털 상품의 “결제 즉시 이메일 발송”도 같은 원리를 쓴다. 다만 결제 승인 뒤 메일과 다운로드 권한이 실제로 즉시 생성되고, 스팸함이나 잘못된 주소 문제를 복구할 수 있을 때만 약속이 된다. 물리 배송 사례의 상승률을 디지털 상품에 그대로 옮길 근거는 없다. 각 상품에서 고객이 결제 직전 무엇을 기다리고 두려워하는지부터 확인해야 한다. 배송 문구를 바꾸기 전에 최근 주문 기록에서 주문 시각부터 출고, 첫 집하, 최종 도착까지의 분포를 먼저 계산하자. 그 데이터가 지킬 수 있는 가장 구체적인 날짜만 결제 버튼 옆에 놓고, 전환과 약속 준수율을 같은 실험에서 읽어야 한다. --- 주요 출처: Dave Diederen의 [원 실험 포스트](https://x.com/DaveDiederen/status/2076985061056852039?ref=zerodraftlab.com); Intelligems, [Statistical Significance](https://docs.intelligems.io/analytics/experiment-analytics/statistical-significance?ref=zerodraftlab.com); Baymard Institute, [Use “Delivery Date” Not “Shipping Speed”](https://baymard.com/blog/shipping-speed-vs-delivery-date?ref=zerodraftlab.com); Shopify, [Shop Promise](https://www.shopify.com/shop-promise?ref=zerodraftlab.com); Loop, [Maude Delivery Promise 사례](https://www.loopreturns.com/case-studies/case-study-maude/?ref=zerodraftlab.com); Ahmed 외, [The role of commitment in online reputation systems](https://doi.org/10.1016/j.dss.2023.114061?ref=zerodraftlab.com). 원 게시물과 상용 솔루션 사례의 성과 수치는 원자료 전체가 공개되지 않은 방향성 근거로만 사용했습니다. ### Claude에게 내 일은 얼마나 자동화됐나를 데이터로 물을 수 있다 URL: https://zerodraftlab.com/ask-claude-economic-index/ Last updated: 2026-08-30T02:52:07.000Z Anthropic이 2026년 7월 22일 [Anthropic Economic Index](https://www.anthropic.com/economic-index?ref=zerodraftlab.com)를 Claude에서 직접 조회하는 커넥터를 공개했다. 데이터셋을 내려받아 표를 해석하지 않아도 직업, 업무, 지역별 AI 사용을 자연어로 물을 수 있다. > You can now ask Claude about the Anthropic Economic Index, our public dataset measuring how AI is used across the economy. > > Ask which occupations use AI the most, or what kinds of tasks people are automating, and the answers draw directly from the Index data. [pic.twitter.com/21DKJTJmrz](https://t.co/21DKJTJmrz?ref=zerodraftlab.com) > > — Claude (@claudeai) [July 22, 2026](https://x.com/claudeai/status/2079979809606664564?ref%5Fsrc=twsrc%5Etfw&ref=zerodraftlab.com) 임베딩이 보이지 않으면 [X 원문](https://x.com/claudeai/status/2079979809606664564?ref=zerodraftlab.com)에서 볼 수 있다. ## 무엇을 물을 수 있나 Anthropic의 [공식 발표](https://www.anthropic.com/news/anthropic-economic-index-connector?ref=zerodraftlab.com)는 커넥터의 용도를 네 가지 질문으로 설명한다. AI를 가장 많이 쓰는 직업은 무엇인지, 콜로라도에서는 Claude를 주로 어디에 쓰는지, 교사는 어떤 업무에 Claude를 쓰는지, 자동화되는 작업이 지난 1년 동안 어떻게 달라졌는지 묻는 식이다. 질문의 공통점은 “AI가 무엇을 할 수 있는가”보다 “사람들이 이미 어디에 쓰고 있는가”를 본다는 데 있다. 답변은 Index 데이터를 근거로 삼는다. 연구자용 데이터셋과 대시보드에 있던 접근 경로가 Claude 대화창까지 짧아졌다. ## 커넥터는 1분이면 켤 수 있다 `claude.ai`에서 커넥터 메뉴를 열고 디렉터리의 `Anthropic Economic Index`를 활성화하면 된다. 별도 프로그램을 설치할 필요가 없고, 어떤 Claude 모델을 선택하든 일반 대화에서 사용할 수 있다. Anthropic이 권하는 질문 순서도 단순하다. 먼저 “내 업종에 관해 Index가 보여주는 것은 무엇인가”처럼 넓게 묻는다. 이어서 직업, 구체적인 업무, 지역, 시점으로 범위를 좁힌다. 마지막에는 결론을 뒷받침한 원자료와 한계를 함께 보여달라고 요청한다. > 내 업종에서 Claude 사용이 많이 관찰된 직업과 업무를 구분해줘. 자동화와 협업 사용을 나누고, 지역·시점별 차이가 있으면 보여줘. 각 결론의 근거 데이터와 표본 기간을 붙이고, Index에 없는 내용은 추정하지 마. ## 질문의 비용은 낮아졌고, 질문의 품질은 더 중요해졌다 **ZDL 해석:** 커넥터는 데이터 접근 비용을 줄였다. 같은 데이터에서도 “가장 많이 쓰는 직업”만 물으면 순위표가 나오고, “그 직업의 어떤 업무가 자동화되고 어떤 업무가 사람과의 협업으로 남는가”를 물으면 일의 구조가 보인다. 직업명보다 업무 단위가 유용하다. 한 직업 안에는 작성, 조사, 판단, 설명, 승인처럼 성격이 다른 일이 섞여 있다. AI 사용량이 높다는 사실만으로 직업 전체의 대체를 말할 수는 없다. 어떤 업무에서 사용이 관찰됐는지, 그 사용이 결과물을 맡기는 자동화인지 사람과 주고받는 협업인지까지 내려가야 한다. 비교축도 붙여야 한다. 한 시점의 평균보다 지역 차이, 시간에 따른 변화, 사용량과 자동화 비중의 차이가 더 많은 것을 알려준다. 관찰되지 않은 업무를 함께 요청하면 현재의 공백도 볼 수 있다. 데이터 부재는 이번 표본에서 충분히 관찰되지 않았다는 뜻이다. AI가 쓸모없다는 증거로 쓰면 안 된다. ## Claude 사용 데이터는 노동시장 전체가 아니다 Anthropic은 발표문 끝에 데이터의 경계를 적었다. Index는 **Claude에서 관찰된 사용 패턴**을 보여주며 노동시장 전체를 대표하지 않는다. 특정 직업의 수치가 높아도 다른 AI 서비스와 사내 도구의 사용, 실제 고용 변화, 생산성, 매출 결과까지 자동으로 설명하지 않는다. 답변을 읽을 때는 표본 기간, 지역 범위, 관찰 단위, 분모를 함께 확인해야 한다. 커넥터가 출처 데이터를 보여주지 못하거나 질문한 지역·직무의 데이터가 부족하면 그 한계 자체를 답으로 받아들여야 한다. 전체 데이터셋은 기존처럼 [Anthropic Economic Index 웹사이트](https://www.anthropic.com/economic-index?ref=zerodraftlab.com)에서 무료로 내려받을 수 있다. 이 커넥터의 쓸모는 막연한 대체 공포를 업무 단위의 검증 질문으로 줄이는 데 있다. Index에서 후보 업무를 찾고, 자신의 조직에서는 처리 시간·오류·매출 같은 실제 결과를 따로 측정해야 한다. 공개 데이터가 알려주는 것은 어디를 먼저 볼지이며, 우리 조직에서 효과가 있었는지는 우리 데이터가 답한다. --- 주요 출처: Claude, [Anthropic Economic Index 커넥터 발표](https://x.com/claudeai/status/2079979809606664564?ref=zerodraftlab.com), 2026년 7월 22일; Anthropic, [Ask Claude about the Anthropic Economic Index](https://www.anthropic.com/news/anthropic-economic-index-connector?ref=zerodraftlab.com); Anthropic, [Anthropic Economic Index](https://www.anthropic.com/economic-index?ref=zerodraftlab.com). ### 10가지 ‘이론’은 같은 종류의 지식이 아니다 URL: https://zerodraftlab.com/ten-ideas-not-same-kind/ Last updated: 2026-08-30T02:51:49.000Z X 계정 The Preserver는 남성에게 진화심리학부터 2차 사고까지 열 가지를 공부하라고 권했다. 짧고 공유하기 좋은 목록이다. 다만 이들을 모두 “theories”라고 묶으면 각 지식의 쓰임이 흐려진다. 연구 분야, 추론법, 자기계발 원리, 풍자에서 나온 격언, 철학 체계, 심리학 이론과 경제 개념이 한 목록에 섞여 있다. > “AS A MAN, PLEASE STUDY THESE THEORIES…” > > — 𝐓𝐡𝐞 𝐏𝐫𝐞𝐬𝐞𝐫𝐯𝐞𝐫 (@ThePreserverofU) [July 22, 2026](https://x.com/ThePreserverofU/status/2080005457092243726?ref%5Fsrc=twsrc%5Etfw&ref=zerodraftlab.com) 임베딩이 보이지 않으면 [X 원문](https://x.com/ThePreserverofU/status/2080005457092243726?ref=zerodraftlab.com)에서 볼 수 있다. 분류가 어긋나면 공부법도 어긋난다. 이론에는 근거와 반례를 물어야 하고, 철학에는 어떤 삶을 좋은 삶으로 보는지 물어야 한다. 휴리스틱은 정답으로 외우는 대신 실제 데이터에 대입해 봐야 한다. 원문 순서대로 열 가지의 정체를 다시 나눠보자. ## 열 가지는 각각 무엇인가 1. **진화심리학.** 자연선택의 관점으로 인간의 마음과 행동을 연구하는 분야이자 연구 프로그램이다. “남자는 원래 이렇다” 같은 사후 설명을 붙이는 면허가 아니다. 어떤 심리 기제가 어떤 적응 문제를 풀도록 형성됐다는 가설을 세우고, 다른 설명과 비교할 수 있어야 한다. 2. **제1원리 사고.** 주장을 더 이상 쉽게 분해할 수 없는 전제까지 내려간 뒤 다시 조립하는 추론법이다. 아리스토텔레스의 철학에서 제1원리는 탐구가 도달해야 할 출발점이었다. 오늘날의 제1원리 사고도 답을 주는 이론보다 전제를 의심하는 절차에 가깝다. 3. **복리 효과.** 작은 선택이 반복되며 큰 차이를 만든다는 자기계발 원리다. 대런 하디의 책 *The Compound Effect*를 통해 널리 알려졌다. 돈의 복리에는 이자율과 기간이 있지만 습관에는 같은 공식이 없다. 반복의 방향, 환경과 피드백이 나쁘면 작은 행동도 손실을 누적한다. 4. **파킨슨의 법칙.** 주어진 시간만큼 일이 늘어난다는 관찰이다. C. 노스코트 파킨슨이 1955년 *The Economist*에 쓴 글은 관료제 팽창을 다룬 풍자에서 출발했다. 모든 업무에 촉박한 마감을 걸라는 자연법칙으로 읽기보다, 과업의 범위와 품질 기준이 시간에 따라 불어나는지 점검하는 휴리스틱으로 쓸 만하다. 5. **80/20 법칙.** 소수의 원인이 다수의 결과를 만든다는 분포 관찰이자 우선순위 도구다. 품질관리에서는 영향이 큰 “vital few”를 찾는 데 사용한다. 실제 비율이 언제나 80 대 20이라는 뜻은 아니다. 데이터를 정렬해 집중 구간이 있는지 먼저 확인해야 한다. 6. **스토아 철학.** 감정을 없애는 생산성 기술보다 훨씬 큰 철학 체계다. 고대 스토아학파는 물리학, 논리학, 윤리학을 함께 다뤘고 좋은 삶을 이성과 덕의 문제로 보았다. 통제할 수 있는 일에 집중한다는 현대식 요약만 읽으면 정의, 공동체와 덕에 관한 절반을 놓친다. 7. **애착 이론.** 이 목록에서 이름 그대로 심리학 이론에 가장 가까운 항목이다. 볼비가 시작하고 에인스워스가 확장한 이론은 영유아와 양육자의 정서적 유대가 이후 발달과 안정성에 어떤 영향을 주는지 설명한다. 성인의 애착 유형은 관계를 돌아보는 언어가 될 수 있지만 사람을 “회피형”이나 “불안형”으로 고정하는 성격 진단표는 아니다. 8. **관계의 수요와 공급.** 경제학의 시장 모형을 인간관계에 옮긴 비유다. 경제학에서 수요와 공급은 가격에 따라 구매·판매하려는 재화나 서비스의 양을 설명한다. 관계에는 합의된 가격도, 표준화된 상품 단위도 없다. 선택지의 희소성이나 상호성을 살피는 데 제한적으로 쓸 수 있지만 사람의 가치를 시장 가격처럼 계산하기 시작하면 비유가 현실을 가린다. 9. **기회비용.** 하나를 선택하면서 포기한 다음 최선의 대안이 가진 가치다. 경제학의 핵심 개념이며 돈뿐 아니라 시간과 자원에도 적용된다. 관계, 커리어와 사업에서 유용한 이유는 선택의 이익만 보던 시선을 포기한 대안까지 넓혀주기 때문이다. 10. **2차 사고.** 선택의 즉각적 결과 다음에 벌어질 결과까지 묻는 의사결정 습관이다. “그러면 그다음에는?”을 반복해 인센티브 변화, 반작용과 장기 비용을 살핀다. 미래를 정확히 예측하는 이론은 아니며, 첫 효과만 보고 내린 결정을 한 번 더 검토하는 절차다. ## 같은 방식으로 공부하지 마라 열 가지를 한꺼번에 읽기보다 지금 풀 문제가 무엇인지 먼저 정해야 한다. 관계에서 반복되는 패턴을 이해하려면 애착 이론의 연구 범위와 한계를 읽는다. 제한된 시간과 돈을 배분해야 한다면 기회비용과 파레토 분석을 실제 숫자에 대입한다. 일이 끝없이 커진다면 파킨슨의 관찰을 적용해 마감만 줄이지 말고 완료 조건부터 고정한다. - **이론과 연구 분야**에는 근거, 적용 범위, 경쟁 설명과 반례를 묻는다. - **철학**에는 어떤 가치를 우선하며 그 가치가 행동을 어떻게 바꾸는지 묻는다. - **경제 개념**에는 무엇이 희소하고 어떤 대안을 포기하는지 구체적으로 적는다. - **휴리스틱과 추론법**은 가설로 사용하고 결과를 측정한다. - **비유**는 설명력을 잃거나 사람을 도구로 바꾸는 순간 내려놓는다. 이 목록은 판단 도구함을 넓혀준다. 열 개의 이름을 외우는 일은 시작일 뿐이다. 개념의 종류를 구분하고, 자기 문제에 맞는 하나를 고르고, 실패하는 조건까지 함께 읽어야 실제 판단이 달라진다. 성별은 이 공부의 조건이 아니다. 선택하고 책임지는 사람이라면 누구나 필요한 습관이다. --- 주요 출처: The Preserver, [“AS A MAN, PLEASE STUDY THESE THEORIES”](https://x.com/ThePreserverofU/status/2080005457092243726?ref=zerodraftlab.com), 2026년 7월 22일; UC Santa Barbara Center for Evolutionary Psychology, [Principles of Evolutionary Psychology](https://www.cep.ucsb.edu/principles-of-evolutionary-psychology/?ref=zerodraftlab.com); Stanford Encyclopedia of Philosophy, [Aristotle](https://plato.stanford.edu/entries/aristotle/?ref=zerodraftlab.com) 및 [Stoicism](https://plato.stanford.edu/entries/stoicism/?ref=zerodraftlab.com); Hachette, [The Compound Effect](https://www.hachette.co.uk/titles/darren-hardy-llc/the-compound-effect/9781399805780/?ref=zerodraftlab.com); *The Economist*, [Parkinson’s Law](https://www.economist.com/news/1955/11/19/parkinsons-law?ref=zerodraftlab.com); American Society for Quality, [Quality Glossary](https://asq.org/quality-resources/quality-glossary?ref=zerodraftlab.com); APA Dictionary of Psychology, [attachment theory](https://dictionary.apa.org/attachment-theory?ref=zerodraftlab.com); OpenStax, [Demand, Supply, and Equilibrium](https://openstax.org/books/principles-economics-3e/pages/3-1-demand-supply-and-equilibrium-in-markets-for-goods-and-services?ref=zerodraftlab.com) 및 [Opportunity Cost](https://openstax.org/books/principles-economics-2e/pages/2-key-concepts-and-summary?ref=zerodraftlab.com). ### 라이프스타일 비즈니스는 욕이 아니다 URL: https://zerodraftlab.com/lifestyle-business-is-not-an-insult/ Last updated: 2026-08-30T02:51:35.000Z David Senra는 DHH의 슈퍼카 차고 포스트를 인용하며 “라이프스타일 비즈니스”라는 말을 뒤집었다. 남들이 “그거 그냥 라이프스타일 비즈니스잖아”라고 하면, 사업도 있고 라이프스타일도 있으며 그 라이프스타일에는 노란 람보르기니도 들어간다고 답하는 식이다. > People are like “You’re just running a lifestyle business.” “Yeah I have a business and a lifestyle…” > > — David Senra (@davidsenra) [July 22, 2026](https://x.com/davidsenra/status/2080068798175117543?ref%5Fsrc=twsrc%5Etfw&ref=zerodraftlab.com) 임베딩이 보이지 않으면 [X 원문](https://x.com/davidsenra/status/2080068798175117543?ref=zerodraftlab.com)에서 볼 수 있다. 짧은 농담이지만 구조는 분명하다. 첫 문장은 외부의 평가다. 사업이 충분히 크지 않고, 빠르게 확장되지 않으며, 창업자의 삶에 맞춰져 있다는 비하가 들어 있다. 두 번째 문장은 그 평가 기준을 거부한다. 사업의 목적이 투자자에게 거대한 미래를 약속하는 데만 있는 것이 아니라, 소유자가 원하는 현재를 실제로 만드는 데도 있다는 반격이다. ## “라이프스타일”이 붙으면 왜 작은 사업처럼 들릴까 스타트업의 익숙한 문법에서 좋은 사업은 빠르게 성장하고, 시장을 장악하고, 조직을 키우고, 더 높은 기업가치를 인정받아야 한다. 이 문법으로 보면 창업자가 통제권을 지키고, 이익을 꺼내 쓰고, 자신이 원하는 속도로 회사를 운영하는 선택은 야망이 부족한 것으로 보인다. 그래서 라이프스타일 비즈니스는 종종 “크게 될 수 없는 사업”의 완곡한 표현으로 쓰인다. 하지만 여기에는 서로 다른 두 질문이 섞여 있다. 하나는 이 사업이 얼마나 크게 확장될 수 있느냐는 질문이고, 다른 하나는 이 사업이 소유자와 고객에게 어떤 삶을 지속해서 만들어주느냐는 질문이다. 첫 번째 질문에서 작다고 해서 두 번째 질문에서도 실패한 것은 아니다. ## Senra는 다른 점수판을 꺼냈다 Senra는 “내 사업도 사실 크게 성장할 수 있다”고 방어하지 않는다. 사업이 있고, 그 사업이 원하는 라이프스타일을 만들며, 그 결과가 눈앞의 물건으로 확인된다는 다른 점수판을 꺼낸다. 람보르기니는 Senra가 고른 상징이다. 누군가에게 원하는 삶은 좋은 차가 가득한 차고일 수 있고, 다른 사람에게는 가족과 보내는 시간, 고용하지 않을 자유, 싫은 고객을 거절할 권리, 장소에 얽매이지 않는 일정일 수 있다. 어떤 소비를 하느냐보다 **사업이 소유자의 시간을 빼앗는지, 선택권을 늘리는지**가 더 중요하다. ## DHH의 차고가 이 농담의 배경이다 Senra가 연결한 [DHH의 원문](https://x.com/dhh/status/2079955830057931207?ref=zerodraftlab.com)은 테슬라 Model Y를 뛰어난 이동 도구라고 인정하면서도, 이동 이상의 경험을 원할 때는 내연기관을 이길 수 없다고 말한다. 그는 좋은 자동차를 모으는 일을 창업 성공이 주는 훌륭한 보상 중 하나로 표현했다. Senra의 포스트는 사업의 성공을 기업가치나 직원 수로만 말하던 자리에 창업자가 실제로 누리는 보상을 들이민다. 미래의 엑시트 가격보다 지금 소유한 시간과 현금, 통제권이 더 현실적인 성공 증거일 수 있다는 주장이다. ## 37signals는 이 농담을 운영 원칙으로 설명한다 DHH가 공동 소유한 37signals는 [수익을 선택하는 이유](https://37signals.com/why-we-choose-profit?ref=zerodraftlab.com)에서 이 관점을 더 직접적으로 밝힌다. 회사는 이익을 매년 전부 재투자하지 않고 소유자에게 분배하며, 그렇게 회사 안에 쌓인 위험을 줄인다고 설명한다. 이익은 시간을 사고, 외부 자금에 의존하지 않을 자유와 방향을 바꿀 유연성을 준다는 것이다. 또한 37signals는 기업가치를 얼마나 인정받는지에 관심을 쓰지 않는다고 말한다. 기업가치는 언젠가 누군가가 지분을 사줘야 현금이 된다. 반면 고객이 지불한 돈에서 비용을 빼고 남은 이익은 지금 선택권으로 바꿀 수 있다. 이 차이 때문에 겉으로 더 작은 회사가 소유자에게는 더 큰 자산일 수 있다. 높은 평가를 받았지만 계속 외부 자금이 필요한 회사보다, 성장은 느려도 고객이 반복해서 결제하고 이익이 남으며 소유권을 지킨 회사가 더 많은 자유를 줄 수 있다. ## 물론 “라이프스타일”은 부실한 사업의 면허가 아니다 원하는 삶을 만든다는 말이 낮은 제품 품질, 불안정한 현금흐름, 창업자 한 사람에게 과도하게 의존하는 운영을 정당화하지는 않는다. 고객에게 가치가 없고, 비용을 빼면 돈이 남지 않으며, 창업자가 잠시 쉬는 순간 멈추는 사업은 라이프스타일 비즈니스라서 좋은 것이 아니라 아직 취약한 사업이다. 좋은 라이프스타일 비즈니스가 되려면 먼저 좋은 사업이어야 한다. 고객이 계속 지불할 이유가 있고, 원가와 인건비를 빼도 이익이 남고, 소유자의 건강과 시간을 파괴하지 않는 방식으로 반복되어야 한다. “작지만 자유롭다”에서 자유만 말하고 작은 이유를 외면하면 자기합리화가 된다. ## 성공의 정의는 구체적이어야 한다 Senra의 농담이 강한 이유는 성공을 추상어로 말하지 않기 때문이다. 영향력, 자율성, 가치 창출 같은 말 대신 노란 람보르기니 한 대를 놓는다. 취향에는 동의하지 않아도 그 사람이 무엇을 위해 일했는지는 바로 이해된다. 모든 창업자가 같은 차를 원할 필요는 없다. 다만 자신이 만든 사업이 어떤 삶을 가능하게 해야 하는지는 구체적으로 답할 수 있어야 한다. 그렇지 않으면 매출과 성장률은 계속 오르는데, 정작 사업을 시작한 사람의 시간과 선택권은 줄어드는 역설이 생긴다. 고객이 계속 결제하고, 비용을 빼도 이익이 남고, 소유자가 원했던 시간과 선택권을 실제로 얻는다면 그 사업은 이미 자기 목적을 달성하고 있다. 그때 “라이프스타일 비즈니스”라는 말은 비하가 아니라 정확한 설명이 된다. --- 주요 출처: David Senra, [라이프스타일 비즈니스와 노란 람보르기니에 관한 X 포스트](https://x.com/davidsenra/status/2080068798175117543?ref=zerodraftlab.com), 2026년 7월 22일; DHH, [Model Y와 자동차 수집에 관한 X 포스트](https://x.com/dhh/status/2079955830057931207?ref=zerodraftlab.com), 2026년 7월 22일; 37signals, [“Why We Choose Profit at 37signals”](https://37signals.com/why-we-choose-profit?ref=zerodraftlab.com). ### 인재가 없는 게 아니라, 전환율이 낮은 것이다 URL: https://zerodraftlab.com/talent-conversion-rate/ Last updated: 2026-09-15T08:35:25.000Z 같은 날 입사한 두 명의 제품 매니저가 있다. 한 사람은 핵심 제품 출시를 맡고, 노련한 리더에게 매주 피드백을 받으며, 경영진 앞에서 결과를 설명한다. 다른 사람은 요구사항이 계속 바뀌는 내부 도구를 넘겨받는다. 성공 기준도, 정기 피드백도, 실패했을 때 방어해줄 후원자도 없다. 여섯 달 뒤 첫 번째 사람은 ‘하이 퍼포머’, 두 번째 사람은 ‘실행력이 아쉬운 사람’으로 분류된다. 조직은 두 사람의 능력을 발견했다고 생각한다. 그러나 그동안 서로 다른 경로를 제공했다는 사실은 평가표에서 빠진다. **조직은 인재를 선별하기만 하는 것이 아니라, 누가 인재로 보일지도 함께 만든다.** ## 성과를 개인의 속성으로만 읽으면 시스템의 손실이 사라진다 2008년 PopTech에서 Malcolm Gladwell은 James Flynn의 개념을 빌려 ‘capitalization rate’를 설명했다. 어떤 집단에서 무언가를 해낼 잠재력이 있는 사람 가운데 실제로 그 일을 해내는 사람이 얼마나 되는지를 보는 관점이다. 여기서는 이를 ‘잠재력 전환율’이라고 부르자. 이 관점은 성공한 사람이 어떤 특성을 가졌는지 묻기 전에, 같은 가능성을 가진 사람 중 누가 기회·훈련·시간·안전망을 얻었는지 묻게 한다. Gladwell은 빈곤, 잘못 설계된 선발 규칙, 노력에 대한 문화적 해석이 이 전환율을 낮출 수 있다고 주장했다. 그의 책 *Outliers*도 성공을 개인의 재능과 노력만으로 설명하지 않고, 가족·문화·세대·우연한 기회가 함께 만든 결과로 다룬다. 아이스하키의 생년월일 효과는 이 주장을 보여주는 대표 사례다. 같은 연령대로 묶인 선수 중 기준일 직후에 태어난 아이는 몇 달 더 성장한 상태에서 선발된다. 코치는 성숙도의 차이를 재능으로 읽기 쉽고, 먼저 뽑힌 아이는 더 좋은 훈련과 더 많은 경기를 받는다. 작은 초기 차이가 실제 실력 차이로 자란 뒤에는 출발점이 보이지 않는다. 이 현상은 Gladwell의 이야기로만 남지 않았다. 38개 연구와 253개 표본을 합친 2009년 메타분석은 스포츠에서 상대연령 효과가 반복해서 나타나지만, 전체 효과 크기는 작고 연령·경기 수준·종목에 따라 달라진다고 정리했다. 규칙이 결과에 영향을 준다는 증거인 동시에, 생년월일 하나로 모든 성취를 설명해서도 안 된다는 경계다. ## 회사는 사람을 평가하지만, 실제로는 사람과 경로의 결합을 평가한다 이 논리를 직장으로 옮기는 순간부터는 이 글의 해석이다. 핵심 프로젝트, 좋은 관리자, 고객과의 직접 접촉, 빠른 피드백, 실패 뒤 재도전 기회는 조직 안에서 고르게 배분되지 않는다. 처음 받은 과제가 좋았던 사람은 성과를 보여줄 장면을 더 많이 얻고, 그 성과는 다음 기회를 받을 근거가 된다. 반대편에서는 낮은 가시성과 느린 피드백이 능력 부족의 증거로 축적된다. 그래서 “좋은 사람이 없다”는 진단은 너무 빨리 채용시장으로 향한다. 채용 풀을 넓히기 전에 입사한 사람의 잠재력이 어디에서 새는지 봐야 한다. 배치에서 새는가, 피드백에서 새는가, 중요한 일을 맡기 전의 신뢰 심사에서 새는가, 한 번 실패한 뒤 다시 시도할 기회에서 새는가. 인재 부족은 공급 문제가 아니라 낮은 전환율일 수 있다. 그 차이는 스타의 수보다 스타가 만들어진 경로에서 더 잘 드러난다. 전환율이 낮은 조직의 스타는 대개 비슷한 경로를 통과한다. 이미 좋은 평가를 받은 사람이 중요한 과제를 받고, 중요한 과제에서 만든 성과가 다시 좋은 평가를 보강한다. 성과로 기회를 배분한 뒤, 그 기회로 생긴 성과를 원래 능력의 증거로 읽는 순환이다. 이 순환이 언제나 부당한 것은 아니다. 자원은 한정돼 있고, 검증된 사람에게 큰 일을 맡기는 선택은 합리적이다. 문제는 첫 신호가 얼마나 정확했는지 확인하지 않은 채 초기 순위를 장기 신분으로 굳힐 때 생긴다. 짧은 과제 하나, 특정 관리자와의 궁합, 우연히 좋은 고객을 만난 경험이 이후의 훈련량과 가시성까지 결정한다면 조직은 현재 성과와 미래 잠재력을 구분하기 어려워진다. ## 재능도 노력도 사라지지 않는다 잠재력 전환율을 강조한다고 해서 개인차가 없어진다는 뜻은 아니다. 의도적 연습에 관한 2014년 메타분석은 연습이 성과에 중요하지만 설명력은 분야별로 크게 달랐다고 보고했다. 게임에서는 성과 차이의 26%, 음악은 21%, 스포츠는 18%를 설명했지만 전문직에서는 1% 미만이었다. 노력 하나로 결과를 환원하기 어렵고, 시스템 하나로 환원하기도 어렵다. Gladwell의 강연을 “재능은 중요하지 않다”로 줄이면 다시 같은 오류에 빠진다. 개인의 능력만으로 성공을 설명하던 단순화를 환경만으로 설명하는 단순화로 바꾸는 셈이다. 더 유용한 해석은 관찰된 성과가 사람, 과제, 지원, 시간, 선발 규칙이 함께 만든 결과라는 것이다. 이 구분은 채용과 육성의 관계도 바꾼다. 늘 외부의 A급 인재를 사 와야만 성과가 나는 회사는 채용을 잘하는 회사일 수 있다. 동시에 내부의 평범한 잠재력을 성과로 바꾸는 능력이 약한 회사일 수도 있다. 반대로 누구나 같은 결과를 내게 만드는 것이 높은 전환율도 아니다. 더 많은 사람이 자신의 가능성을 시험할 만큼 충분한 과제와 피드백을 받고, 초기 오판에서 회복할 경로가 있는지가 중요하다. ## AI는 전환율을 자동으로 높이지 않는다 AI는 피드백과 연습의 단가를 낮춘다. 과거에는 관리자 한 명이 몇 사람에게만 줄 수 있던 초안 검토, 역할 연습, 데이터 정리, 반복 실험을 더 많은 사람에게 제공할 수 있다. 그러나 좋은 모델과 자동화가 이미 높은 평가를 받은 소수에게만 집중되면 기존 순환은 더 빨라진다. 기술의 보급보다 누가 더 많은 시도와 더 빠른 피드백을 얻는지가 전환율을 결정한다. 새로운 A급 인재를 찾기 전에 지난 1년의 기회가 누구에게 흘렀는지 따라가야 한다. 중요한 고객, 좋은 관리자, 빠른 피드백, 실패 뒤 재시도 기회가 늘 같은 이름에 모였다면 현재의 인재 지도가 사람의 능력만 그린 것은 아니다. 그 경로를 그대로 둔 채 채용 풀만 넓히면 조직은 더 많은 잠재력을 같은 방식으로 잃는다. --- 주요 출처: PopTech, Malcolm Gladwell, [Human potential](https://vimeo.com/7182319?ref=zerodraftlab.com) (2008); Malcolm Gladwell, [*Outliers* 공식 소개](https://gladwell.com/books/outliers?ref=zerodraftlab.com); Stephen Cobley 외, [Annual age-grouping and athlete development](https://pubmed.ncbi.nlm.nih.gov/19290678/?ref=zerodraftlab.com) (2009); Brooke Macnamara 외, [Deliberate Practice and Performance](https://journals.sagepub.com/doi/10.1177/0956797614535810?ref=zerodraftlab.com) (2014). 도입부의 제품 매니저와 직장 내 전환율 해석은 논지를 설명하기 위한 가상 사례와 이 글의 독립 해석입니다. ### 고생하고 있다는 사실은 제품이 맞다는 증거가 아니다 URL: https://zerodraftlab.com/struggle-is-not-product-proof/ Last updated: 2026-08-30T02:51:08.000Z 창업에는 이상한 도덕이 붙는다. 오래 버틴 사람이 진지한 사람이고, 더 고생한 팀이 결국 이길 것이라는 믿음이다. 그래서 제품이 팔리지 않아도 “원래 스타트업은 힘들다”는 말이 설명처럼 쓰인다. Sourcery가 공개한 아래 영상에서 Zynga 창업자 마크 핀커스는 정반대의 말을 한다. 제품이 맞으면 모든 것이 함께 풀리며, 바위를 언덕 위로 미는 듯한 느낌이 아니라는 것이다. > Mark Pincus’s best advice for founders: life is too short to struggle. “From a product standpoint, when something works, everything works.” > > — sourcery (@sourceryy) [July 22, 2026](https://x.com/sourceryy/status/2079724354749788588?ref%5Fsrc=twsrc%5Etfw&ref=zerodraftlab.com) 임베딩이 보이지 않으면 [X 원문](https://x.com/sourceryy/status/2079724354749788588?ref=zerodraftlab.com)에서 볼 수 있다. 이 말만 떼어놓으면 “쉬운 사업만 하라”는 조언처럼 들린다. 그러나 [Sourcery의 전체 인터뷰와 전사](https://pod.wave.co/podcast/sourcery/mark-pincus-how-to-build-billion-dollar-products?ref=zerodraftlab.com)를 보면 논지는 더 정확하다. 핀커스는 어려움을 피하라고 말하기 전에, 자신이 붙잡은 근본적인 직감과 그 직감을 구현한 특정 제품 아이디어를 분리하라고 말한다. ## 지켜야 할 것은 제품이 아니라 문제에 대한 직감이다 핀커스는 과거 소셜 네트워크 서비스 Tribe를 설명하며, 자신이 본 인간의 욕구는 맞았지만 당시의 제품은 그 답이 아니었다고 돌아본다. 여기서 중요한 구분이 나온다. 창업가가 처음 본 문제와 그 문제를 해결하려고 만든 첫 제품은 같은 것이 아니다. 사람들이 특정한 방식으로 연결되고 싶다는 관찰은 맞을 수 있다. 하지만 그 욕구를 커뮤니티 서비스로 구현할지, 게임으로 구현할지, 업무 도구로 구현할지는 별개의 가설이다. 근본적인 직감을 지키는 일과 첫 구현을 끝까지 지키는 일은 전혀 다르다. 많은 창업가는 둘을 하나로 묶는다. 제품이 거절당하면 자신의 통찰 전체가 부정당했다고 느끼기 때문이다. 그러면 더 오래 만들고, 더 세게 팔고, 더 많은 설명을 붙인다. 끈기는 남지만 학습은 멈춘다. ## 고생은 헌신의 증거일 수 있지만 제품의 증거는 아니다 어려운 일을 해내는 능력은 중요하다. 다만 창업가의 고생은 창업가에 관한 정보이지, 고객이 그 제품을 원하는지에 관한 정보는 아니다. 고객은 팀이 몇 달을 밤샜는지 알지 못한다. 고객이 보여주는 것은 사용하거나, 돈을 내거나, 다른 사람에게 권하거나, 아무 일도 하지 않는 행동뿐이다. 그래서 “모든 것이 풀린다”는 표현도 마법처럼 받아들여서는 안 된다. 좋은 제품에도 버그가 생기고, 채용은 어렵고, 영업은 오래 걸리며, 규제 산업과 딥테크는 검증에 긴 시간이 필요하다. 제품-시장 적합성이 실행의 고통을 없애주지는 않는다. 달라지는 것은 고통의 방향이다. 시장이 당기는 제품은 늘어난 수요를 감당하고 품질을 지키느라 어렵다. 시장이 밀어내는 제품은 고객에게 필요성을 설명하고, 다시 오게 만들고, 매번 예외적인 설득을 반복하느라 어렵다. 둘 다 힘들지만 전자는 반응을 처리하는 어려움이고, 후자는 반응을 만들어내야 하는 어려움이다. ## “계속할까”보다 먼저 물어야 할 질문 따라서 판단 기준은 내가 얼마나 힘든지가 아니다. 제품을 계속 밀지 않아도 고객 쪽에서 어떤 움직임이 생기는지다. 사용자가 알림 없이 돌아오는가. 돈을 내거나 먼저 계약하려 하는가. 동료에게 전하거나 다른 용도로 넓혀 쓰는가. 새 고객을 설득하는 비용이 반복할수록 낮아지는가. 이 신호가 없다면 곧바로 문제 자체를 버릴 필요는 없다. 대신 같은 문제를 푸는 다른 구현을 더 싸고 빠르게 시험해야 한다. 핀커스가 전체 인터뷰에서 강조하는 것도 하나의 아이디어에 감정적으로 매달리는 대신 여러 번의 실험으로 더 나은 답에 접근하는 태도다. 반대로 약한 신호 하나를 “번개가 병에 들어온 순간”으로 과장해서도 안 된다. 지인의 칭찬, 일회성 매출, 창업자의 수작업으로 유지된 사용은 지속적인 시장 견인과 다르다. 이 조언은 제품-시장 적합성을 판정하는 공식이 아니라, 고생을 성공의 선행지표로 착각하지 않게 하는 교정 장치에 가깝다. ## 끈기는 같은 제품을 오래 미는 능력이 아니다 좋은 창업가는 아무것도 포기하지 않는 사람이 아니다. 문제에 대한 신념과 현재의 구현을 구분하고, 고객 행동이 부정한 구현을 놓아줄 수 있는 사람이다. 그래야 하나의 제품에 10년을 쓰는 대신, 중요한 문제를 붙잡은 채 여러 번 답을 바꿀 수 있다. **고생은 헌신의 증거일 수 있다. 그러나 제품의 증거는 고객 행동이다.** 바위를 더 세게 밀기 전에, 반대편에서 누군가 당기고 있는지부터 봐야 한다. --- 주요 출처: Sourcery, [마크 핀커스 인터뷰 영상 발췌](https://x.com/sourceryy/status/2079724354749788588?ref=zerodraftlab.com), 2026년 7월 22일; Sourcery, [Mark Pincus: How to Build Billion-Dollar Products 전체 인터뷰·전사](https://pod.wave.co/podcast/sourcery/mark-pincus-how-to-build-billion-dollar-products?ref=zerodraftlab.com), 2026년 6월 23일. Tribe 사례와 핀커스의 조언은 인터뷰 내용에 따른 것이며, 고객 견인 신호와 두 종류의 어려움에 관한 구분은 Zero Draft Lab의 해석이다. ### 폴리매스는 많이 아는 사람이 아니다 URL: https://zerodraftlab.com/polymath-is-adaptability-not-knowledge/ Last updated: 2026-08-30T02:50:55.000Z 2026년 7월 23일, Mustafa는 폴리매스를 “여러 분야를 조금씩 아는 사람”이 아니라 “무엇이든 배울 수 있는 사람”으로 정의했다. 지식의 양보다 적응력이 중요하며, 서로 다른 분야의 사고법을 옮겨 쓰는 데서 혁신이 나온다는 주장이다. 첨부 이미지는 Peter Hollins의 책 *Polymath* 표지이고, 작성자는 후속 답글에 Amazon 제휴 링크라고 밝혔다. > “a polymath is not someone who knows a little about everything. it is someone who can learn anything.” > > — Mustafa (@oprydai) [July 23, 2026](https://x.com/oprydai/status/2080197986039267573?ref=zerodraftlab.com) 임베딩이 보이지 않으면 [X 원문](https://x.com/oprydai/status/2080197986039267573?ref=zerodraftlab.com)에서 볼 수 있다. 이 포스트는 연구 결과를 정리한 글이 아니라 책을 소개하는 짧은 홍보문이다. 그래도 폴리매스를 단순한 박식함이 아니라 학습과 전이의 능력으로 다시 정의했다는 점은 살펴볼 가치가 있다. 원문이 전개한 순서를 따라가 보자. ## 지식 목록에서 학습 능력으로 원문이 먼저 지우는 것은 “폴리매스는 모든 분야를 조금씩 아는 사람”이라는 통념이다. 여러 주제의 용어와 사례를 기억하는 것과, 처음 만난 분야에서 중요한 구조를 찾아 실제 문제에 적용하는 것은 다르다. 전자는 지식의 목록이고 후자는 학습 능력이다. 이 관점에서 질문도 달라진다. “무엇을 알고 있는가”보다 “낯선 문제를 만났을 때 무엇을 먼저 배우고, 기존 지식과 어떻게 연결하며, 어느 시점에 행동으로 옮기는가”가 중요해진다. 원문이 말한 적응력은 막연한 유연함이 아니라 이 과정을 반복할 수 있는 능력에 가깝다. ## 적응력은 여섯 가지 습관으로 구성된다 원문은 폴리매스의 기반을 여섯 가지로 정리한다. - **빠르게 배운다.** 모든 것을 공부하는 대신 현재 문제를 푸는 데 필요한 핵심 개념부터 찾는다. - **아이디어를 연결한다.** 새 지식을 기존 경험과 분리해 저장하지 않고 공통 구조를 찾는다. - **분야를 전환한다.** 한 분야의 익숙한 답이 통하지 않을 때 다른 렌즈로 문제를 다시 본다. - **정신모형을 만든다.** 개별 사례를 외우는 대신 여러 상황에서 다시 쓸 수 있는 원리를 압축한다. - **의도적으로 연습한다.** 이해했다는 느낌에서 멈추지 않고 실제 과제로 약점을 드러낸다. - **호기심을 유지한다.** 당장의 정답과 관계없어 보이는 분야에도 질문을 열어둔다. 여기서 “분야를 전환한다”는 말만 떼어내면 쉽게 산만함이 된다. 원문의 목록에서도 전환은 연결, 정신모형, 의도적 연습과 함께 놓여 있다. 새로운 분야를 계속 시작하는 것이 아니라, 한 분야에서 배운 구조를 다른 문제에 옮겨 보고 결과로 검증하는 것이 핵심이다. ## 각 분야는 서로 다른 질문을 빌려준다 원문은 분야별 사고법을 짧게 대응시킨다. 물리학은 제약조건을, 생물학은 적응을, 컴퓨터과학은 추상화를, 경제학은 인센티브를, 디자인은 인간 행동을 가르친다는 식이다. 이는 각 학문 전체에 대한 정의라기보다 문제를 다시 보는 질문의 예다. 같은 제품 이탈 문제도 컴퓨터과학의 렌즈로 보면 시스템 구조와 예외 처리의 문제이고, 경제학의 렌즈로 보면 행동을 유도하는 보상의 문제이며, 디자인의 렌즈로 보면 사용자가 다음 행동을 이해하지 못한 문제일 수 있다. 답을 다른 분야에서 그대로 가져오는 것이 아니라, 다른 분야가 중요하게 보는 변수를 빌려오는 것이다. ## 중요한 것은 수집이 아니라 전이다 학습과학에서 말하는 *adaptive expertise*, 즉 적응적 전문성도 비슷한 구분을 사용한다. 익숙한 상황에서 지식을 능숙하게 실행하는 것을 넘어, 새로운 상황에서 지식을 유연하게 적용하는 능력이다. 하지만 이 능력은 사실 조각을 많이 저장한다고 자동으로 생기지 않는다. 핵심 개념과 사례, 현실의 맥락이 서로 연결된 지식 구조가 필요하다. 학습자는 그 연결을 장기간 반복해서 연습해야 한다. [Educational Psychology Review의 연결 연습 프레임워크](https://link.springer.com/article/10.1007/s10648-020-09561-x?ref=zerodraftlab.com)는 고립된 정보의 숙달만으로는 깊은 이해와 전이가 만들어지지 않는다고 설명한다. 분야를 넓히는 것 자체가 언제나 보상을 받는 것도 아니다. 2025년 PNAS 연구는 STEM 62개 저널에 제출된 논문 12만8,950편을 분석했다. 참고문헌으로 측정한 지식 기반의 학제성은 채택 확률 상승과 관련됐지만, 제목과 초록에 드러난 주제의 학제성은 오히려 채택 확률 하락과 관련됐다. 이 결과를 개인의 경력에 그대로 옮길 수는 없다. 다만 “여러 분야를 다룬다”는 표면적 정체성과, 실제로 여러 지식 기반을 결합한 작업이 평가에서 다르게 작동할 수 있음을 보여준다. [PNAS 원문](https://pmc.ncbi.nlm.nih.gov/articles/PMC12037057/?ref=zerodraftlab.com) ## 이 포스트가 생략한 것 “무엇이든 배울 수 있다”는 문장은 매력적이지만, 학습 속도가 모든 분야에 동일하게 적용되는 범용 능력이라는 뜻은 아니다. 깊은 이해는 느리게 쌓이고, 한 맥락에서 익힌 지식이 다른 맥락으로 자연스럽게 옮겨가지 않는 경우도 많다. 폴리매스에게 필요한 것은 깊이 대신 넓이를 선택하는 일이 아니라, 깊이 있는 기준점을 가진 채 전이를 연습하는 일이다. 출처의 성격도 구분해야 한다. 이 X 포스트는 Peter Hollins의 책을 소개하고 [다음 답글에서 제휴 링크](https://x.com/oprydai/status/2080197989927428429?ref=zerodraftlab.com)로 연결되는 홍보 콘텐츠다. 여섯 가지 습관은 유용한 요약이지만, 그 자체가 효과를 입증한 연구 모형은 아니다. 방향을 제시하는 문장과 검증된 방법론을 같은 것으로 읽지 않는 편이 안전하다. ## 폴리매스를 만드는 가장 작은 운영법 실제로 적용하려면 세 가지만 남길 수 있다. 1. **기준 분야를 하나 둔다.** 결과를 만들고 피드백을 받을 수 있을 만큼 깊게 파는 주력 분야다. 2. **다른 분야에서 렌즈 하나만 빌린다.** 책 한 권을 끝내는 것보다 지금의 문제를 다르게 보게 하는 개념 하나를 고른다. 3. **전이를 결과물로 검증한다.** 원래 문제, 빌린 원리, 달라진 결정, 실제 결과를 기록한다. 이렇게 보면 폴리매스의 지표는 공부한 분야의 수가 아니다. 다른 분야에서 가져온 원리가 실제 판단이나 결과를 바꾼 횟수다. 박식함은 많은 것을 보관하는 능력이지만, 적응력은 필요한 순간에 지식을 연결하고 변환하는 능력이다. 원문의 가장 쓸모 있는 문장은 바로 그 차이를 짚은 데 있다. --- 주요 출처: Mustafa, [폴리매스를 적응력으로 정의한 X 포스트](https://x.com/oprydai/status/2080197986039267573?ref=zerodraftlab.com) 및 [제휴 링크 고지 답글](https://x.com/oprydai/status/2080197989927428429?ref=zerodraftlab.com), 2026년 7월 23일; Stigler 외, [Practicing Connections](https://link.springer.com/article/10.1007/s10648-020-09561-x?ref=zerodraftlab.com), *Educational Psychology Review*, 2020; Xiang·Romero·Teplitskiy, [Evaluating interdisciplinary research](https://pmc.ncbi.nlm.nih.gov/articles/PMC12037057/?ref=zerodraftlab.com), *PNAS*, 2025. ### AI는 부자의 서비스를 싸게 만들었다. 책임까지 싸진 않았다 URL: https://zerodraftlab.com/ai-made-rich-person-services-cheap/ Last updated: 2026-08-30T02:50:42.000Z 알렉스 엡스타인은 AI가 만든 변화를 열 가지 서비스로 압축했다. 과거에는 돈과 인맥이 있어야 충분히 누릴 수 있었던 개인 과외, 법률·세무 조언, 주치의형 상담, 커리어 코칭, 전담 비서가 이제 거의 누구에게나 열렸다는 주장이다. > “Rich person” services that poor people can access now thanks to AI: custom tutor, job training, legal advice, tax advice… > > — Alex Epstein (@AlexEpstein) [July 22, 2026](https://x.com/AlexEpstein/status/2079988893508862270?ref%5Fsrc=twsrc%5Etfw&ref=zerodraftlab.com) 임베딩이 보이지 않으면 [X 원문](https://x.com/AlexEpstein/status/2079988893508862270?ref=zerodraftlab.com)에서 볼 수 있다. 이 목록은 AI가 각 직업을 완전히 대체했다는 증거가 아니다. 지금 싸진 것은 전문가의 최종 판단보다 **첫 질문을 받아주고, 초안을 만들고, 같은 설명을 몇 번이고 다시 해주는 지식 노동의 입구**다. 원문이 나열한 순서대로 보면 그 변화가 더 선명하다. ## 열 가지 서비스에서 실제로 싸진 것 1. **맞춤형 과외.** 학습자의 수준에 맞춰 같은 개념을 다른 비유로 설명하고, 즉석 문제를 만들고, 오답을 보고 다음 문제의 난도를 바꿀 수 있다. 정해진 수업 시간이나 질문 횟수를 기다릴 필요가 없다. 2. **직무 훈련.** 특정 역할의 업무 절차를 풀어 설명하고, 고객 응대나 면접을 역할극으로 반복하며, 결과물에 즉시 피드백을 줄 수 있다. 교육 자료를 읽는 것과 실제 숙련은 다르지만 연습 상대의 비용은 크게 내려간다. 3. **법률 조언.** 계약서의 낯선 문장을 풀고, 쟁점을 분류하고, 변호사에게 물어볼 질문을 만드는 1차 작업을 맡길 수 있다. 다만 관할과 최신 판례, 사실관계에 따라 결론이 바뀌므로 법적 판단 자체가 자동으로 보장되는 것은 아니다. 4. **세무 조언.** 거래를 항목별로 정리하고, 필요한 증빙을 점검하고, 여러 세금 시나리오를 비교하는 데 쓸 수 있다. 세법의 적용 시점과 신고 책임은 남기 때문에 초안과 실제 신고를 구분해야 한다. 5. **재무 설계.** 예산, 현금흐름, 부채 상환, 투자 가정을 하나의 모델로 만들고 선택지별 결과를 계산할 수 있다. 그러나 위험 감수 수준과 규제, 상품의 실제 조건까지 확인하지 않은 숫자는 계획이 아니라 시뮬레이션이다. 6. **심리 상담.** 감정을 말로 정리하고, 반복되는 생각을 기록하고, 다음 대화를 준비하는 상시 대화 상대가 될 수 있다. 이것은 접근성을 넓히지만 위기 대응, 진단, 치료 관계까지 대신한다는 뜻은 아니다. 7. **주치의형 상담.** 증상 기록을 구조화하고, 검사 결과의 용어를 풀고, 진료 전에 질문 목록을 만드는 일은 언제든 할 수 있다. 환자의 몸을 직접 보고 책임지는 진단과 처방은 여전히 다른 층위의 일이다. 8. **커리어 코칭.** 경력과 제약을 길게 설명하면 가능한 이동 경로를 펼치고, 이력서와 면접 답변을 반복해서 고칠 수 있다. 한 시간짜리 상담보다 더 많은 가설을 시험할 수 있다는 것이 장점이다. 9. **전담 비서.** 이메일 초안, 회의 요약, 일정 후보, 리서치, 후속 작업 정리를 한 인터페이스에서 처리할 수 있다. 요청할 때마다 추가 인건비가 생기지 않으므로 작은 조직과 개인에게 특히 큰 변화다. 10. **시험 준비.** 목표 시험에 맞춘 문제를 만들고, 오답 유형을 기억하고, 취약한 영역만 다시 훈련할 수 있다. 과외와 마찬가지로 개인화와 반복의 한계비용이 낮아진다. 열 가지를 관통하는 공통점은 전문가 한 명의 시간을 예약하지 않아도 된다는 것이다. 질문은 밤에도 받아주고, 설명이 마음에 들지 않으면 다른 방식으로 다시 말하며, 초안을 열 번 고쳐도 눈치를 주지 않는다. 과거의 프리미엄 서비스에서 가장 먼저 분리돼 나온 것은 **전문가의 시간**이었다. ## “거의 공짜”라는 방향은 맞다 스탠퍼드 HAI의 2026 AI Index는 생성형 AI가 대중화 3년 만에 인구 기준 53%의 채택률에 도달했고, 미국 소비자가 얻는 연간 소비자잉여를 2026년 초 1,720억 달러로 추정했다. 보고서는 이 도구들의 상당수가 무료이거나 무료에 가깝게 제공된다고 설명한다. 엡스타인의 “vanishingly cheap”은 적어도 **접근 비용이 빠르게 떨어진다**는 방향에서는 과장이 아니다. 하지만 저 수치는 AI가 변호사, 의사, 세무사, 상담사와 같은 품질의 결과를 냈다는 증거가 아니다. 사용자가 무료 또는 낮은 가격으로 큰 효용을 느낀다는 관찰과, 고위험 전문 서비스가 안전하게 대체됐다는 결론은 별개다. ## 싸지지 않은 것은 검증과 책임이다 법률 영역에서 미국변호사협회의 Formal Opinion 512는 변호사가 생성형 AI를 쓰더라도 역량, 비밀유지, 의뢰인과의 소통, 법원에 대한 진실성 같은 의무를 그대로 져야 한다고 정리한다. 도구가 조사와 초안을 빠르게 해도 결과를 검토하고 책임지는 사람이 사라지지는 않는다. 의료에서도 경계는 같다. 세계보건기구는 AI가 의료 인력 부족을 보완하고 접근성을 넓힐 가능성을 인정하면서도, 그럴듯하지만 틀린 답, 편향된 데이터, 민감정보 노출, 불명확한 책임을 핵심 위험으로 든다. 교육 분야의 UNESCO 지침도 인간 중심의 검증과 개인정보 보호를 전제로 AI 활용을 다룬다. 그래서 AI가 싸게 만든 것과 아직 비싼 것을 나눠야 한다. - **싸진 것:** 첫 설명, 반복 질문, 자료 요약, 초안 작성, 선택지 생성, 연습 상대 - **아직 비싼 것:** 정확한 현실 맥락, 원자료 확인, 예외 판단, 실제 집행, 결과에 대한 책임 과거에는 이 둘이 전문가의 시간 안에 묶여 있었다. 이제 AI가 앞부분을 떼어내 거의 공짜로 공급한다. 그 결과 전문가의 가치가 사라지기보다, 설명을 많이 해주는 능력에서 **틀린 답을 걸러내고 현실의 결과까지 닫는 능력**으로 이동한다. ## 부자의 서비스가 아니라 전문성의 입구가 대중화됐다 엡스타인의 표현은 변화를 눈에 띄게 만들지만 “부자의 서비스를 가난한 사람에게 그대로 복제했다”고 읽으면 너무 멀리 간다. AI가 먼저 대중화한 것은 전담 전문가가 아니라, 전담 전문가가 제공하던 서비스의 일부다. 누구나 질문하고, 자신의 맥락을 길게 설명하고, 여러 가설을 시험할 수 있게 됐다는 점만으로도 이 변화는 충분히 크다. 다음 프리미엄은 지식을 말해주는 데 붙지 않는다. 사용자의 긴 맥락을 기억하고, 출처를 확인하고, 필요한 순간 인간 전문가에게 넘기고, 결정이 실행된 뒤 결과까지 추적하는 시스템에 붙는다. **AI는 조언의 가격을 낮췄다. 그래서 책임의 가격이 더 선명해졌다.** --- 주요 출처: Alex Epstein, [“Rich person services that poor people can access now thanks to AI”](https://x.com/AlexEpstein/status/2079988893508862270?ref=zerodraftlab.com), 2026년 7월 22일; Stanford Institute for Human-Centered AI, [2026 AI Index Report — Economy](https://hai.stanford.edu/ai-index/2026-ai-index-report/economy?ref=zerodraftlab.com); American Bar Association, [Formal Opinion 512: Generative Artificial Intelligence Tools](https://www.americanbar.org/content/dam/aba/administrative/professional%5Fresponsibility/ethics-opinions/aba-formal-opinion-512.pdf?ref=zerodraftlab.com); World Health Organization, [WHO calls for safe and ethical AI for health](https://www.who.int/news/item/16-05-2023-who-calls-for-safe-and-ethical-ai-for-health?ref=zerodraftlab.com); UNESCO, [Guidance for generative AI in education and research](https://www.unesco.org/en/articles/guidance-generative-ai-education-and-research?ref=zerodraftlab.com). ### 딥워크는 끝나지 않았다. 수행자가 바뀌었다 URL: https://zerodraftlab.com/deep-work-changed-hands/ Last updated: 2026-08-30T02:50:28.000Z 코너 브레넌-버크는 짧은 포스트 하나로 에이전트 시대의 역할 분담을 과장해 압축했다. “자폐적 딥워크의 시대는 끝났다. 당신의 에이전트가 더 자폐적이고 딥워크도 더 잘한다. 얕은 일의 미래에 온 것을 환영한다. 완전한 ADHD의 승리.” > the era of autistic deep work is over > > your agents are more autistic than you and better at deep work > > welcome to the shallow work future > > total ADHD dominance > > — conor brennan-burke (@contextconor) [July 22, 2026](https://x.com/contextconor/status/2079907141616324985?ref%5Fsrc=twsrc%5Etfw&ref=zerodraftlab.com) 임베딩이 보이지 않으면 [X 원문](https://x.com/contextconor/status/2079907141616324985?ref=zerodraftlab.com)에서 볼 수 있다. 먼저 경계를 그어야 한다. 여기서 자폐성과 ADHD는 임상적 설명이 아니라 인터넷식 과장이다. 두 특성을 정확히 묘사하지도 않는다. 이 포스트가 실제로 대비하는 것은 **한 문제에 오래 머무르는 실행**과 **여러 작업 사이를 빠르게 오가는 지휘**다. ## 딥워크가 사라진 것이 아니다 첫 문장의 뜻은 인간이 더는 모든 깊은 실행을 직접 붙들 필요가 없다는 것이다. 자료를 오래 읽고, 저장소 전체를 훑고, 여러 가설을 시험하고, 테스트 실패를 고치고, 결과를 문서로 남기는 일은 에이전트가 긴 루프로 수행할 수 있다. 사람처럼 지루함을 느끼지 않고, 중간 산출물을 몇 번이고 다시 만드는 비용도 낮다. 하지만 “에이전트가 딥워크를 더 잘한다”는 말에는 조건이 빠져 있다. 에이전트는 목표와 맥락, 사용할 도구, 멈춰야 할 경계, 완료를 증명할 방법이 주어졌을 때만 깊게 일한다. 이 조건이 없으면 오래 일하는 대신 오래 헤맨다. 실행 시간이 길다고 작업이 깊어지는 것은 아니다. ## 인간의 일은 짧아지지만 얕아지지는 않는다 포스트가 말하는 ‘얕은 일의 미래’에서 사람은 긴 산출물을 직접 만드는 대신 일을 고르고, 잘게 나누고, 여러 에이전트에 보내고, 중간 결과를 읽고, 우선순위를 다시 정한다. 한 번의 개입은 짧다. 문제를 던지는 데 5분, 증거를 읽는 데 10분, 방향을 바꾸는 데 2분이 들 수 있다. 여기서 짧음과 얕음은 다르다. 무엇을 맡길지, 어떤 결과를 믿을지, 어디서 중지할지, 실패의 책임을 누가 질지는 여전히 고밀도 판단이다. 화면에서 자주 전환한다는 이유만으로 사고까지 가벼워지는 것은 아니다. 오히려 깊이는 산출물 제작에서 **문제 선택과 시스템 설계**로 한 층 올라간다. ## ‘ADHD의 승리’가 가리키는 운영 모델 마지막 문장은 주의력 장애에 대한 사실 주장이 아니다. 에이전트 여러 개가 동시에 일할 때, 인간에게 필요한 리듬이 한 과제에 몇 시간 잠기는 방식에서 빠른 배분·전환·예외 처리로 이동한다는 도발에 가깝다. 한 사람이 하나의 작업을 완주하던 흐름이, 한 사람이 여러 작업 큐를 움직이는 흐름으로 바뀐다. 이 리듬이 진짜 레버리지가 되려면 네 가지가 필요하다. 에이전트가 다시 읽을 수 있는 맥락, 작업마다 좁혀진 권한, 결과를 확인할 영수증, 다음 실행으로 이어지는 기억이다. 이것이 없으면 얕은 일의 미래가 아니라 알림과 미완료 작업만 늘어나는 위임극이 된다. 그러므로 코너의 문장을 가장 정확히 고치면 이렇다. **딥워크는 끝나지 않았다. 수행자가 바뀌었다.** 에이전트는 긴 실행을 맡고, 인간은 무엇을 깊게 실행할 가치가 있는지 정한다. 미래를 지배하는 것은 산만함 자체가 아니라, 짧은 판단으로 여러 개의 깊은 실행을 움직일 수 있는 운영체계다. --- 출처: conor brennan-burke, [“the era of autistic deep work is over”](https://x.com/contextconor/status/2079907141616324985?ref=zerodraftlab.com), 2026년 7월 22일. ### AI 1인 창업은 어디까지 혼자인가: Formula Bot의 월 4만 달러 구조 URL: https://zerodraftlab.com/ai-one-person-business-formula-bot/ Last updated: 2026-09-15T08:35:26.000Z Formula Bot의 성공담에는 AI 1인 창업가가 보고 싶어 하는 숫자가 모두 들어 있다. 코드를 쓰지 못했던 창업자 한 명, 주말에 만든 제품, 사용자 100만 명, 연 환산 매출 50만 달러. 2025년 공개된 월 매출은 4만2,000달러를 넘었다. 이 숫자만 이어 붙이면 결론은 간단하다. AI와 노코드를 사용하면 이제 한 사람이 회사를 만들고, 제품을 개발하고, 100만 명에게 서비스하면서 월 4만 달러를 벌 수 있다는 이야기다. 그런데 창업자 David Bressler는 Bubble 인터뷰에서 이 이야기를 스스로 무너뜨리는 문장을 남겼다. > “한 사람 회사이지만, 한 사람 회사가 아니기도 하다.” Formula Bot에는 직원이 한 명뿐이다. 동시에 외부 에이전시의 전담 개발자 두 명이 매주 제품을 개발한다. 그렇다면 이 사업은 1인 기업인가, 작은 팀인가. 이 질문은 말꼬리를 잡는 일이 아니다. AI 1인 창업을 복제하려는 사람이 무엇을 준비하고 어떤 비용을 예상해야 하는지를 완전히 바꾼다. ## 시작은 정말 혼자였다 Bressler는 마케팅 분석과 데이터 분야에서 15년가량 일했다. 개발자는 아니었지만 Excel을 매일 사용했고, 동료들이 수식을 물어보면 답을 알려주는 사람이었다. 2022년 둘째 아이의 출산휴가 중 OpenAI Playground를 사용하다가 자연어를 Excel 수식으로 바꾸는 제품을 떠올렸다. 첫 버전은 입력창과 버튼, 결과창이 전부였다. 사용자가 “A열의 합계를 구해줘”라고 쓰면 API 한 번을 호출해 수식을 돌려주는 구조였다. Bubble로 만든 이 제품에는 로그인도, 결제도, 사용량 제한도 없었다. 그는 Excel 커뮤니티에 무료 도구를 올렸고, 글은 더 큰 Reddit 커뮤니티인 *InternetIsBeautiful*로 옮겨가 100만 회 이상 노출됐다. 다음 날에는 TikTok 인플루언서들이 제품을 소개하기 시작했다. 여기서 제품의 완성도보다 중요한 것은 마찰이 없었다는 사실이다. 회원가입이 없었고, 돈을 내지 않아도 됐으며, 이름만 읽어도 무엇을 하는 제품인지 알 수 있었다. 당시 경쟁 제품 중에는 더 예쁘고 기능이 많은 제품도 있었지만 Formula Bot이 퍼졌다. Bressler는 그 차이를 제품명이 곧 검색어였다는 점, 무료로 즉시 사용할 수 있었다는 점, Reddit의 확산 경로를 먼저 탔다는 점에서 찾는다. 하지만 무료 사용자는 무료가 아니었다. 첫 몇 주 동안 OpenAI 비용 약 5,000달러가 발생했고, 몇 달 뒤 누적 적자는 1만 달러에 이르렀다. 무료·무제한이라는 유통 전략이 사람에게는 마찰을 없애는 동시에 사업자에게는 사용량만큼 비용을 청구했다. ## 무료 도구는 단계적으로 유료 제품이 됐다 Bressler는 처음부터 정교한 SaaS 가격표를 설계하지 않았다. 무료 도구가 퍼지는 동안 배너 광고와 Excel 교육 상품의 제휴 수수료로 비용을 메웠다. 이후 로그인을 붙이고, 무료 사용량을 제한하고, 월 2.99달러 구독을 도입했다. 기능이 늘어날 때마다 가격도 올렸다. 2023년 초 공개된 MRR은 1만4,000달러를 넘었고, 한 달 매출은 2만2,000\~2만3,000달러까지 올라갔다. 2025년 인터뷰에서 그는 전년도 ARR이 약 50만 달러였고 월 매출이 4만2,000달러를 넘었다고 밝혔다. 당시 매출의 99.9%는 월 15\~35달러 구독에서 나왔다. 이 숫자는 사업이 광고성 바이럴에서 반복 결제로 이동했다는 점에서는 의미가 있다. 그러나 “사용자 100만 명”은 유료 고객 100만 명이 아니다. 공개된 100만 명은 누적 이메일 계정 수다. 무료 도구가 만든 거대한 상단 퍼널에서 소수의 반복 사용자가 돈을 내는 구조다. 초기 인터뷰에서도 무료 한도를 넘는 사용자는 전체의 약 3%로 설명됐다. Formula Bot이 판 것은 AI 그 자체가 아니었다. Excel 수식을 몰라 검색하고, 문법을 고치고, 다시 붙여 넣는 시간을 줄였다. 이후 PDF와 스프레드시트 업로드, 차트, 데이터 정리, 감성 분석, Google Analytics와 데이터베이스 연결을 붙이며 제품을 ‘수식 생성기’에서 ‘대화형 데이터 분석가’로 넓혔다. 한 번 쓰고 떠날 수 있는 신기한 도구를 업무 흐름에 남는 구독으로 바꾸려는 확장이었다. ## 월 $5K에서 1인 회사의 경계가 바뀌었다 중요한 전환은 MRR 약 5,000달러에서 일어났다. Bressler는 Bubble 전문 에이전시 Zeroic을 고용했다. 2025년 기준 전담 Bubble 개발자 두 명이 Formula Bot에 주당 약 20시간을 투입했고, Make, AWS, Render 같은 미들웨어와 기술 작업의 대부분을 담당했다. Bressler는 간단한 개념증명을 만들고 제품 방향과 마케팅에 더 많은 시간을 썼다. 법인 명부와 LinkedIn만 보면 직원은 창업자 한 명이다. 그러나 제품을 계속 작동시키고 확장하는 데 필요한 인간의 수를 세면 한 명이 아니다. Formula Bot은 소유권 기준으로는 1인 회사이고, 급여명부 기준으로는 직원 0명 회사이며, 운영 의존성 기준으로는 외부 개발팀을 가진 회사다. AI 1인 창업을 평가할 때 이 세 가지 기준을 섞으면 안 된다. 직원 수만 세면 외주 노동은 사라진 것처럼 보이고, 창업자 수만 세면 제품을 만드는 사람까지 한 명인 것처럼 보인다. 실제로 복제할 수 있는 모델을 알려면 “몇 명을 고용했는가”보다 **매주 누구의 노동이 없으면 이 사업이 멈추는가**를 물어야 한다. 그렇다고 Formula Bot을 가짜 1인 기업이라고 치워버리면 더 중요한 변화를 놓친다. 이 회사가 새롭게 만든 것은 무인 회사가 아니라, 창업자 한 명이 소유권과 방향을 유지하면서 필요한 인간 노동만 회사 바깥에서 가변적으로 불러오는 구조다. 그 구조의 핵심은 사람을 없앤 데 있지 않고, 사람을 관리하는 단위를 직무에서 결과로 바꾼 데 있다. ## 고정 조직이 가변 생산능력으로 바뀌었다 전통적인 작은 SaaS라면 개발자를 채용하고, 업무를 나누고, 성과를 평가하며, 제품 수요와 상관없이 매달 급여를 지급했을 것이다. Formula Bot은 그 자리에 Bubble, OpenAI, 클라우드 서비스와 외부 개발팀을 놓았다. 사용량이 적을 때는 도구 비용만 내고, 제품이 복잡해진 뒤에는 필요한 개발 시간을 구매했다. 이 구조는 ‘혼자서 모든 일을 한다’는 자수성가 서사와 다르다. 창업자가 직접 한 일의 총량보다 어떤 판단을 내부에 남겼는지가 중요하다. Bressler는 고객이 어떤 데이터를 연결하려는지, 제품을 어느 방향으로 단순화할지, 어떤 무료 도구가 검색 유입을 만들지를 결정한다. 외부 개발자는 그 판단을 안전하고 확장 가능한 시스템으로 구현한다. 회사의 경계가 사람을 고용했는가에서 결정권을 어디에 두었는가로 이동한 셈이다. 제품 전략과 고객 이해는 내부에 남고, 구현 능력은 필요할 때 조달된다. 이때 창업자는 만능 작업자가 아니라 매우 작은 조직의 제품 책임자이자 자본 배분자가 된다. 그러나 외주를 쓰면 자동으로 가벼운 회사가 되는 것은 아니다. 요구사항이 불명확하면 외부팀의 시간이 늘고, 제품 지식이 에이전시에 축적되면 교체 비용이 커지며, 장애가 발생했을 때 책임 경계가 흐려진다. 직원 수가 0이어도 의사소통 비용과 핵심 인력 의존성은 남는다. 급여가 송장으로 바뀌었을 뿐 관리가 사라진 것은 아니다. ## AI는 제품 노동을 줄였지만 제품 회사를 없애지는 않았다 초기 Formula Bot은 흔히 말하는 AI 래퍼에 가까웠다. 사용자 입력을 받아 프롬프트와 함께 API에 보내고 결과를 보여줬다. 이 수준에서는 비개발자 한 명도 며칠 만에 제품을 만들 수 있었다. 하지만 데이터 분석가라는 약속을 지키려면 파일을 저장하고, 큰 데이터를 처리하고, Python 코드를 실행하고, 외부 데이터 소스를 연결하고, 오류를 복구하며, 고객 데이터를 보호해야 한다. 실제 스택은 Bubble과 OpenAI에서 AWS S3, Render와 GitHub, n8n, Gemini로 넓어졌다. Bressler는 앱의 no-code 비중이 100%에서 약 70%로 내려갔고 더 낮아질 것이라고 설명했다. 이는 no-code가 실패했다는 뜻이 아니다. no-code는 시장 진입 시간을 줄여 선점 기회를 샀다. 제품이 성장한 뒤에는 그때 얻은 매출로 코드와 전문 인력을 조달했다. 처음부터 확장 가능한 완벽한 시스템을 만들었다면 Reddit의 짧은 기회를 놓쳤을 수 있다. 반대로 초기 구조를 끝까지 고집했다면 100만 계정의 파일과 데이터 연결을 감당하기 어려웠을 것이다. 여기서 복제할 것은 특정 도구가 아니다. **불확실성이 큰 단계에서는 속도를 사고, 수요가 확인된 단계에서는 신뢰성과 생산능력을 산다**는 투자 순서다. MVP의 기술 부채는 무조건 피해야 할 실패가 아니라, 시장의 시간을 사기 위해 의도적으로 진 빚일 수 있다. 다만 매출이 생긴 뒤에도 갚지 않으면 그때부터는 전략이 아니라 방치가 된다. ## 바이럴은 사건이었고, 검색은 자산이 됐다 Formula Bot을 월 4만 달러까지 만든 유통도 하나의 채널로 설명되지 않는다. Reddit과 TikTok은 첫 폭발을 만들었다. 하지만 Bressler가 공개한 트래픽은 2023년 중반부터 2024년 말까지 정체됐다. 신기함이 사라지자 무료 입소문도 멈췄다. 그 뒤 성장을 다시 만든 것은 무료 도구를 이용한 SEO, 제한적인 Google 광고, 유료 인플루언서 마케팅이었다. PDF to Excel 변환기, SQL 쿼리 생성기, Excel 수식 생성기처럼 핵심 제품과 가까운 무료 도구가 검색 방문을 받았다. 여러 화면에 흩어진 기능을 하나의 채팅 인터페이스로 합치고 버튼과 섹션을 약 30% 줄인 뒤 전환율이 45% 개선됐다고도 밝혔다. 초기 바이럴은 복제하기 어렵지만 이 두 번째 단계는 비교적 복제 가능하다. 고객이 결과 직전에 검색하는 작은 도구를 무료로 제공하고, 그 도구의 다음 작업을 유료 제품이 이어받게 한다. 무료 도구마다 별도 사업을 만들지 않고 하나의 제품으로 수요를 모은다. 그리고 기능을 늘린 뒤에는 고객에게 더 많은 선택지를 보여주는 대신 한 인터페이스에서 더 많은 일을 끝내게 한다. 반대로 2022년의 Reddit 전략을 그대로 따라 하면 실패할 가능성이 높다. Bressler 자신도 지금 같은 글을 올리면 홍보로 삭제될 것이며, 자연어로 수식을 만드는 기능은 더 이상 신기하지 않다고 말한다. Formula Bot의 경쟁우위는 ‘AI를 썼다’가 아니라 AI가 아직 낯설 때 카테고리 이름과 유통 경로를 먼저 차지한 시간이었다. ## 복제해야 할 것은 제품이 아니라 전환의 순서다 Formula Bot을 복제해 또 하나의 수식 생성기를 만드는 것은 늦었다. 대신 그 사업이 지나온 전환은 다른 시장에도 적용할 수 있다. 처음에는 직업인이 반복해서 겪는 작고 명확한 문제를 잡았다. 그다음 가장 얇은 제품으로 실제 사용을 만들었다. 무료와 무가입으로 공유 마찰을 낮췄고, 비용이 폭발하자 로그인과 한도, 결제를 순서대로 붙였다. 단일 기능이 반복 결제를 얻자 더 넓은 업무 흐름으로 확장했다. 창업자의 시간이 제품 구현에 묶이기 시작하자 고정 조직을 만들기 전에 외부 생산능력을 샀다. 마지막으로 바이럴이 멈추자 검색과 유료 유통을 운영 자산으로 만들었다. 이 순서에서 어느 단계도 영구적인 정답은 아니었다. 무료 무제한은 출시에는 맞았지만 운영에는 틀렸다. no-code는 선점에는 맞았지만 확장에는 부족해졌다. 혼자 만드는 방식은 검증에는 맞았지만 제품 범위가 커지자 병목이 됐다. Formula Bot의 강점은 처음부터 완벽한 모델을 찾은 데 있지 않고, 단계가 바뀔 때 이전의 성공 공식을 버린 데 있다. 따라서 Formula Bot을 ‘한 사람이 AI로 월 4만 달러를 번 사례’라고 부르면 가장 실용적인 교훈이 사라진다. 더 정확한 설명은 이렇다. 한 사람이 시장과 소유권을 장악하고, AI와 no-code로 진입 시간을 줄였으며, 검증 뒤에는 외부 개발팀을 붙여 생산능력을 확장했다. **AI 1인 창업의 새로운 단위는 혼자 일하는 사람이 아니다. 적은 수의 결정권자가 소프트웨어, 모델, 외부 전문가를 조합해 큰 결과를 통제하는 회사다.** 직원 수는 작게 유지할 수 있다. 그러나 인간 노동과 운영 책임까지 사라졌다고 믿는 순간, 성공담은 플레이북이 아니라 착시가 된다. --- 주요 출처: David Bressler의 [Starter Story 인터뷰](https://www.starterstory.com/stories/excelformulabot?ref=zerodraftlab.com)와 [Indie Hackers 인터뷰](https://www.indiehackers.com/post/8XGnzrxG1neA3jy37x2D?ref=zerodraftlab.com), Bubble의 [Formula Bot 사례 연구](https://bubble.io/blog/formula-bot/?ref=zerodraftlab.com), [2022년 Hacker News 출시 기록](https://news.ycombinator.com/item?id=32303435&ref=zerodraftlab.com). 사용자 수, 매출, 전환율, 비용은 창업자 및 관련 업체가 공개한 자기보고이며 독립 감사된 재무 수치로 취급하지 않았습니다. Bubble 사례의 ‘2023년 출산휴가’ 표기는 창업자의 2023년 인터뷰에 나온 2022년 5월 출산휴가 및 2022년 9월 출시 기록과 충돌해 본문에서는 더 이른 당사자 기록을 채택했습니다. Semrush 한국 데이터베이스 2026-07-23 조회에서 제목 축으로 사용한 ‘1 인 창업’은 월 검색량 320, KD 9였고 ‘AI 창업’은 월 검색량 260, KD 8이었습니다. ### 위임이 회사를 쪼갰다. 잭 도시가 가장 늦게 배운 것 URL: https://zerodraftlab.com/jack-dorsey-overdelegation/ Last updated: 2026-07-23T08:20:25.000Z 잭 도시가 자신의 가장 큰 리더십 실수로 꼽은 것은 의외로 **너무 많이 위임한 것**이었다. 아래 X 포스트는 Sequoia Capital 팟캐스트에서 그가 Block의 다중 CEO 구조를 돌아본 107초짜리 장면을 옮겼다. > Jack Dorsey, co-founder of Block, on his biggest leadership mistake: delegating too much. > > — Big Brain Business (@BigBrainBizness) [July 22, 2026](https://x.com/BigBrainBizness/status/2079914466867876019?ref=zerodraftlab.com) 임베딩이 보이지 않으면 [X 원문](https://x.com/BigBrainBizness/status/2079914466867876019?ref=zerodraftlab.com)에서 볼 수 있다. 영상의 1차 출처는 Sequoia Capital의 [Long Strange Trip 인터뷰와 전문](https://sequoiacap.com/podcast/jack-dorsey-every-company-can-now-be-a-mini-agi/?ref=zerodraftlab.com)이다. 이 말을 “창업자는 모든 결정을 직접 해야 한다”는 조언으로 읽으면 핵심을 놓친다. 도시가 후회한 것은 권한 이양 자체가 아니라, **하나여야 할 회사의 가치를 여러 사업 책임자의 목표로 쪼갠 것**이었다. ## Square와 Cash App이 한 회사 안의 두 회사가 됐다 도시는 Block 안에 Square를 맡는 CEO와 Cash App을 맡는 CEO를 따로 두려 했다. 각 사업에 강한 리더를 두면 더 빠르게 움직일 것처럼 보인다. 실제로 벌어진 일은 반대였다. Block이 하나의 운영체계가 아니라 여러 회사를 보유한 지주회사처럼 변했다. 그가 인터뷰에서 짚은 문제는 세 가지였다. 사업마다 문화가 달라졌고, 중요하게 여기는 가치가 달라졌으며, 실행 수준도 벌어졌다. 각 조직은 자기 속도로 성장했지만 둘을 합쳐야 생기는 회사의 가치는 약해졌다. ## 사업부의 성장은 회사의 가치와 같지 않다 Square는 판매자 쪽을, Cash App은 소비자 쪽을 본다. 도시가 본 Block의 가능성은 이 두 사업을 따로 키우는 데 있지 않았다. 거래의 양쪽을 가진 회사가 기존 금융망 전체에 도전하는 데 있었다. 그런데 CEO 단위로 사업을 나누자 각 조직은 자기 사업을 최적화했다. 이것은 부서 성과가 좋아도 전체 회사의 전략이 약해질 수 있는 전형적인 **로컬 최적화**다. 공통 가치가 사업부 경계를 넘어야 하는 회사라면, 자율성은 목표가 아니라 수단이어야 한다. ## 그가 후회한 것은 실수보다 학습 지연이었다 도시는 실패와 잘못된 결정을 모두 후회한다고 말하지 않았다. 실수에서 배우지 않기로 했거나, 충분히 빨리 배우지 않은 순간을 후회한다고 했다. 과도한 위임도 그래서 가장 아픈 사례였다. 구조가 회사를 갈라놓는 신호가 보였는데도 너무 늦게 고쳤다는 것이다. 여기서 리더의 역할은 모든 판단을 회수하는 것이 아니다. 서로 다른 조직의 성과가 공통 고객 가치로 다시 합쳐지는지 계속 읽고, 합쳐지지 않을 때 구조를 바꾸는 것이다. 위임한 뒤 결과 숫자만 받는 것으로는 부족하다. ## “회사가 읽히면” 위임의 방정식이 달라진다 같은 인터뷰에서 도시는 Slack 메시지, 이메일, 코드, 문서, 회의 기록처럼 회사가 만드는 작업 흔적 위에 AI intelligence layer를 두겠다는 구상을 설명했다. 목표는 경영진에게 올라오는 요약만 보는 대신 누구나 회사의 실제 상태를 질의할 수 있게 만드는 것이다. 그래서 그의 최근 해법은 마이크로매니지먼트보다 **가독성**에 가깝다. 권한은 나눠도 정보와 의도는 쪼개지지 않게 한다. 리더가 모든 일을 하는 대신, 회사가 무엇을 하고 왜 그렇게 하는지 직접 읽을 수 있는 구조를 만든다. 다만 이것은 아직 검증이 끝난 경영 공식이 아니다. Block은 이 구상과 함께 조직을 크게 줄였고, 회사 전체의 가독성은 쉽게 전사 감시나 최고경영자 중심화로 변질될 수 있다. 도시와 Roelof Botha도 인터뷰에서 이 전환이 초기 단계이며 답을 모두 안다고 보지 않는다고 선을 그었다. ## 위임 전에 먼저 정해야 할 것 ZDL식으로 줄이면 세 가지다. 1. **무엇이 합쳐져야 회사의 가치가 되는가.** 사업부별 매출보다 먼저 공통 가치 루프를 정한다. 2. **경계를 넘는 결정은 누가 책임지는가.** 각 부서가 잘하는 것과 회사 전체가 이기는 것은 다른 문제다. 3. **리더가 현실을 직접 읽을 수 있는가.** 보고 단계가 늘어날수록 예쁜 요약보다 검색 가능한 원자료와 결정 기록이 중요해진다. 좋은 리더는 일을 가장 많이 쥔 사람도, 가장 많이 넘긴 사람도 아니다. **나눠진 판단이 하나의 가치로 다시 합쳐지게 만드는 사람**이다. 잭 도시가 가장 늦게 배웠다고 말한 것도 결국 그 차이였다. 출처: [Big Brain Business X 포스트](https://x.com/BigBrainBizness/status/2079914466867876019?ref=zerodraftlab.com), [Sequoia Capital 인터뷰·전문](https://sequoiacap.com/podcast/jack-dorsey-every-company-can-now-be-a-mini-agi/?ref=zerodraftlab.com), [From Hierarchy to Intelligence](https://sequoiacap.com/article/from-hierarchy-to-intelligence/?ref=zerodraftlab.com). 조직 가독성의 효용과 위험, 위임의 세 가지 선행조건은 Zero Draft Lab의 해석이다. ### 잭 도시는 플랫폼을 만들었다. 지금은 플랫폼 밖의 질서를 만든다 URL: https://zerodraftlab.com/jack-dorsey-beyond-platforms/ Last updated: 2026-08-30T02:49:57.000Z *함께 읽기:* [*에이전트에게 필요한 것은 채팅창이 아니라 자리다*](https://zerodraftlab.com/agents-need-a-seat/) 2026년의 잭 도시는 두 사람처럼 보인다. 한쪽에서는 수천 명이 일하는 상장사 Block을 이끈다. 다른 쪽에서는 회사 계정과 중앙 서버 없이도 사람이 대화하고 거래할 수 있는 프로토콜을 밀어붙인다. 한쪽만 보면 설명은 간단하다. 그는 여전히 거대 플랫폼의 창업자이거나, 중앙화에 등을 돌린 탈중앙화 전도사다. 하지만 그의 현재를 이해하려면 두 모습을 함께 봐야 한다. 잭 도시가 지난 20년 동안 바꿔온 것은 사업 분야보다 **통제권을 어디에 둘 것인가**라는 답에 가깝다. ## 트위터가 보여준 것은 규모만이 아니었다 잭 도시는 트위터 공동 창업자로 2007년부터 2008년까지 CEO를 맡았다. 2015년 CEO로 돌아왔을 때는 2009년 공동 창업한 Square의 CEO도 겸했다. 그는 2021년 트위터 CEO에서 물러났고, 2026년 7월 현재 Block의 최고경영자에 해당하는 Block Head이자 이사회 의장으로 남아 있다. 이 이력은 흔히 연쇄 창업가의 성공담으로 정리된다. 그러나 트위터는 그에게 플랫폼의 다른 얼굴도 보여줬다. 수억 명의 신원과 관계, 발언 기록이 한 회사의 계정 체계에 들어가면 회사는 제품만 운영하는 것이 아니다. 누가 말할 수 있는지, 무엇을 지울지, 어떤 규칙을 적용할지까지 결정하는 제도가 된다. 잭 도시가 이후 반복해서 건드린 것은 바로 이 권한이었다. 더 좋은 소셜 앱을 만드는 것보다, 하나의 회사가 소셜 네트워크 전체를 소유하지 않아도 되는 기반을 만들려 했다. ## Bluesky를 시작했고, 다시 떠났다 2019년 트위터는 잭 도시의 구상 아래 탈중앙화 소셜미디어 프로토콜을 만들 작은 독립 팀에 자금을 대겠다고 발표했다. 이것이 Bluesky의 출발이었다. Bluesky는 2021년 별도 법인으로 독립했고, 특정 조직 하나가 소유할 수 없는 개방형 프로토콜을 목표로 삼았다. 그러나 잭 도시는 2024년 Bluesky 이사회를 떠났다. 그해 인터뷰에서 그는 Bluesky가 회사, 이사회, 콘텐츠 관리 구조를 갖추며 트위터의 실수를 반복하고 있다고 평가했고, 중앙 서버 없이 키와 릴레이로 작동하는 Nostr에 무게를 옮겼다고 설명했다. 이것은 그의 판단이지 Bluesky의 실패가 확정됐다는 뜻은 아니다. Bluesky는 현재 잭 도시 없이 운영되며, 2026년 5월 기준 4,400만 명이 넘는 사용자를 보유했다고 밝힌다. 이 대목이 중요하다. 잭 도시의 여정은 정답을 차례로 찾아낸 직선이 아니다. 자신이 시작한 시도도 통제권이 다시 회사로 모인다고 판단하면 떠나 다른 기반을 택하는 반복에 가깝다. 그 선택이 언제나 옳았다는 증거도 아직 없다. ## Bitchat은 계정을 지운 실험이었다 2025년에는 개인 프로젝트 [Bitchat](https://github.com/permissionlesstech/bitchat?ref=zerodraftlab.com)을 공개했다. 가까이 있는 기기끼리는 블루투스 메시로, 멀리 떨어진 사람과는 Nostr를 통해 연결하는 메시징 앱이다. 전화번호, 이메일, 사용자명, 중앙 서버를 필수로 두지 않는다. 그는 이 프로젝트를 Block의 AI 에이전트 도구 goose로 만든 주말 실험이라고 소개했다. 동시에 초기 구현은 견고하지 않았다고 직접 인정했다. Bitchat의 의미는 완성도보다 출발점에 있다. 트위터가 계정과 서버를 먼저 만들었다면, Bitchat은 사람 사이의 연결을 먼저 만들고 계정을 선택 사항으로 밀어냈다. ## Block에서는 회사를 플랫폼이 아니라 지능으로 바꾼다 잭 도시는 플랫폼을 버리고 광야로 떠난 사람이 아니다. 지금도 Block을 운영한다. 다만 회사 안에서조차 기존 조직 구조를 고정된 것으로 보지 않는다. 그는 2025년 goose의 목표를 질문에 답하는 도구가 아니라 필요한 행동을 먼저 제안하는 완전 자율 시스템이라고 설명했다. 2026년에는 Block을 계층 조직이 아닌 하나의 ‘지능’으로 만들겠다는 구상을 공동 발표했다. 원격 근무에서 생기는 결정, 대화, 코드, 계획을 기계가 읽을 수 있는 회사 모델로 만들고, 관리자가 전달하던 정보를 AI가 계속 갱신하게 한다는 생각이다. 여기에는 불편한 긴장이 있다. 사용자 신원과 관계는 회사 밖으로 분산시키려 하면서, Block 안의 업무 기록과 고객 거래 신호는 더 강한 하나의 지능으로 모으려 한다. 잭 도시의 현재는 모든 것을 탈중앙화하는 프로젝트가 아니다. **개인이 소유해야 할 것과 조직이 통합해야 할 것의 경계를 다시 긋는 프로젝트**다. ## Buzz는 그 경계 위에 놓여 있다 Block 팀이 2026년 7월 [Buzz](https://block.xyz/inside/introducing-buzz-where-humans-and-agents-work-together?ref=zerodraftlab.com)를 공개한 다음 날, 잭 도시는 직접 [「why we’re buzzing」](https://x.com/jack/status/2080056638820450400?ref=zerodraftlab.com)이라는 글을 올렸다. 그는 Buzz를 Slack과 GitHub에 대한 의존을 줄이고, 대화·코드·CI·에이전트 도구 사이에서 사라지는 맥락을 한곳에 모으기 위해 만든 오픈소스 작업 공간이라고 설명했다. 이 설명은 Buzz가 잭 도시의 개인 사이드 프로젝트는 아니지만 그의 현재 전략과 분리된 제품도 아니라는 점을 분명히 한다. 그는 Block을 하나의 지능으로 재구성하는 과정에서 goose를 더 깊이 사용할수록 도구 사이의 단절이 한계가 됐고, 그들이 직접 겪은 문제를 풀기 위해 Buzz를 만들었다고 썼다. 사람과 AI 에이전트는 회사가 발급한 익명 봇 계정이 아니라 각자의 암호학적 신원으로 참여한다. 메시지, 패치, 검토, 워크플로 단계, 승인은 직접 운영할 수 있는 릴레이에 서명된 이벤트로 남는다. 잭 도시는 이를 사람과 에이전트가 같은 종류의 키와 채널, 감사 기록을 갖는 구조로 설명했다. 개인의 신원은 플랫폼보다 오래가고, 조직의 맥락은 개인의 채팅창보다 오래가는 셈이다. 그는 앞으로 Block의 더 많은 업무를 Buzz에서 운영하겠다고 밝혔다. 에이전트가 거래할 수 있게 하는 방향도 다음 가능성으로 언급했다. Buzz는 Nostr와 Bitchat이 제기한 신원 문제와 goose와 Block의 회사 지능이 풀려는 맥락 문제를 하나의 협업 공간에서 연결한 실험이다. 다만 이것은 로드맵이지 성과 증명은 아니다. 잭 도시의 설명에서도 Git 호스팅은 연결 중이고, 모바일과 푸시는 앞으로 올 기능이며, 승인 게이트는 일부만 만들어졌다. 각 작업 공간이 아직 단일 릴레이에서 작동하기 때문에 릴레이 간 연합도 완전한 탈중앙화로 가기 위한 다음 단계다. 개방형 프로토콜 역시 키 관리, 콘텐츠 관리, 스팸, 거버넌스를 해결해야 하고, Block은 AI가 관리 계층을 대신할 수 있다는 가설을 이제 시험하는 중이다. 그럼에도 잭 도시의 현재는 분명하다. 그는 더 많은 사람을 한 플랫폼 안에 넣는 방법보다, 플랫폼이 바뀌어도 남는 것을 설계하는 데 가까워지고 있다. **플랫폼을 만든 사람이 지금 만들려는 것은 더 강한 플랫폼이 아니라, 플랫폼이 없어져도 남는 신원·기록·관계다.** --- 주요 출처: Twitter의 [2015년 CEO 선임 공시](https://www.sec.gov/Archives/edgar/data/1418091/000156459015008279/twtr-8k%5F20150930.htm?ref=zerodraftlab.com)와 [2021년 사임 공시](https://www.sec.gov/Archives/edgar/data/1418091/000119312521342255/d401229d8k.htm?ref=zerodraftlab.com); Block의 [2026년 위임장](https://www.sec.gov/Archives/edgar/data/1512673/000162828026027203/sq-20260423.htm?ref=zerodraftlab.com), [From Hierarchy to Intelligence](https://block.xyz/inside/from-hierarchy-to-intelligence?ref=zerodraftlab.com), [2025년 J.P. Morgan 콘퍼런스 요약](https://block.xyz/inside/jack-dorsey-amrita-ahuja-at-jpm-technology-media-and-communications-conference?ref=zerodraftlab.com); Bluesky의 [창립 기록](https://bsky.social/about/blog/2-28-2022-how-it-started?ref=zerodraftlab.com)과 [현재 회사 정보](https://www.bsky.social/about/faq?ref=zerodraftlab.com); Jack Dorsey의 [2024년 인터뷰](https://www.piratewires.com/p/interview-with-jack-dorsey-mike-solana?ref=zerodraftlab.com), [Bitchat 공개 설명](https://github.com/orgs/permissionlesstech/discussions/139?ref=zerodraftlab.com), [2026년 X 아티클 「why we’re buzzing」](https://x.com/jack/status/2080056638820450400?ref=zerodraftlab.com). 통제권의 위치라는 연결과 개인 신원 분산·조직 지능 통합이라는 경계 해석은 Zero Draft Lab의 분석입니다. ### 휴대폰에서 Claude Code를 켰다. 바뀐 것은 화면이 아니다 URL: https://zerodraftlab.com/phone-claude-code-changes-workplace/ Last updated: 2026-08-30T02:49:43.000Z 롭 할람이 공개한 아래 포스트는 “휴대폰에서 Claude Code를 쓰는 법”을 16단계로 정리한 짧은 구축기다. 월 5\~10유로 수준의 VPS를 사고, Tailscale과 SSH로 접속을 잠근 뒤, tmux 안에서 Claude Code를 계속 실행한다. 마지막에는 서버 구성과 운영 원칙까지 Claude Code에 넘긴다. > If you wanna do it yourself, this is how: > > Buy (\~15 min) > 1\. Cheap VPS from Hetzner or DigitalOcean (\~€5-10/mo), Ubuntu 24.04, tick automatic backups at checkout > 2\. Add your domain to Cloudflare (free plan), switch nameservers at your registrar > 3\. Install Termius (SSH app) +… > > — Rob Hallam (@robj3d3) [July 22, 2026](https://x.com/robj3d3/status/2080018987849773315?ref%5Fsrc=twsrc%5Etfw&ref=zerodraftlab.com) 임베딩이 보이지 않으면 [X 원문](https://x.com/robj3d3/status/2080018987849773315?ref=zerodraftlab.com)에서 볼 수 있다. 완성된 것은 거창한 AI 플랫폼이 아니다. 인터넷에 늘 켜져 있는 작은 Ubuntu 컴퓨터 한 대와, 그 컴퓨터를 노트북과 휴대폰에서 안전하게 여는 통로다. 코드와 파일, Claude Code 프로세스는 서버에 남는다. Termius는 접속 화면이고, Tailscale은 사설 통로이며, tmux는 연결이 끊겨도 프로세스를 살려두는 장치다. 원문이 제안한 순서를 그대로 따라가 보자. ## 1\~3\. 서버를 사고 들어갈 도구를 준비한다 1. **저렴한 VPS를 산다.** Rob은 Hetzner나 DigitalOcean의 월 5\~10유로급 서버, Ubuntu 24.04, 공급자 자동 백업 옵션을 제안한다. 자신이 실제로 산 Hetzner VPS는 월 8유로였다. 2. **도메인을 Cloudflare에 연결한다.** 도메인을 Cloudflare 무료 플랜에 추가하고 registrar의 nameserver를 바꾼다. 나중에 웹페이지를 공개할 때 Cloudflare를 앞단에 두기 위한 준비다. 3. **노트북과 휴대폰에 Termius와 Tailscale을 설치한다.** Termius는 SSH 클라이언트, Tailscale은 기기끼리 사설망을 만드는 도구다. 둘 다 이 정도 개인 구성에서는 무료 플랜으로 시작할 수 있다. 여기까지는 서버를 한 대 사고, 접속에 사용할 앱을 깐 단계다. 아직 안전하게 잠근 것은 아니다. 원문은 다음 4\~10단계에 더 많은 설명을 쓴다. 이 구성에서 중요한 것은 Claude Code 설치보다 공개 인터넷에서 SSH를 치우는 일이기 때문이다. ## 4\~10\. 공개 SSH를 닫고 Tailscale 안으로 들어간다 1. **Termius에서 SSH 키를 만든다.** VPS를 생성할 때 공개키를 넣고, 비밀번호 로그인 대신 키로만 접속한다. 2. **공개 IP로 한 번 접속해 서버를 준비한다.** 시스템 패키지를 업데이트하고 서버에 Tailscale을 설치한 뒤 자신의 tailnet에 로그인시킨다. 3. **서버의 Tailscale key expiry를 끈다.** 원격 서버의 키가 만료돼 접속 통로가 사라지는 일을 막기 위한 선택이다. 4. **Tailscale 주소로 SSH가 되는지 먼저 확인한다.** 서버에 부여된 `100.x` 주소로 실제 접속이 되는 것을 확인하기 전에는 공개 SSH 통로를 닫지 않는다. 이 순서가 뒤집히면 스스로 서버 밖에 잠길 수 있다. 5. **provider firewall의 인바운드 규칙을 정리한다.** 원문은 공개 SSH를 완전히 닫고, 웹 트래픽용 443번 포트만 Cloudflare의 공개 IP 대역에서 받도록 제안한다. 6. **외부 네트워크에서 다시 시험한다.** 서버의 공개 IP로는 연결이 timeout되고, Tailscale 주소로는 접속돼야 한다. 인터넷 전체에 열린 관리 포트가 없어졌는지 확인하는 단계다. 7. **기기마다 SSH 키를 따로 둔다.** 노트북 키를 휴대폰에 복사하지 않고 휴대폰용 키를 별도로 만들어 `authorized_keys`에 추가한다. 한 기기를 잃어버려도 그 키만 제거할 수 있다. 이제 서버는 공개 인터넷에서 SSH를 받지 않고, Tailscale에 로그인한 자신의 기기에서만 관리할 수 있다. 다음은 그 안에 Claude Code를 계속 살아 있게 만드는 단계다. 원문의 11단계부터는 안전한 원격 서버를 개인 AI 작업장으로 바꾼다. ## 11\~12\. tmux 안에 Claude Code를 띄운다 1. **tmux와 Claude Code를 설치한다.** Ubuntu에서 tmux를 설치하고 Anthropic의 공식 설치 방법으로 Claude Code를 넣는다. 2. **Claude Code는 tmux 세션 안에서 실행한다.** SSH 연결이 끊기거나 휴대폰 앱을 닫아도 tmux 안의 프로세스는 계속 돈다. 나중에 같은 세션에 다시 붙으면 직전 터미널 화면과 실행 중인 작업을 이어서 볼 수 있다. 여기서 휴대폰은 Claude Code가 실행되는 컴퓨터가 아니다. 서버의 tmux 세션에 붙는 리모컨이다. 노트북을 닫아도 서버는 켜져 있으므로 이동 중에 상태를 확인하거나 다음 지시를 보낼 수 있다. ## 13\~14\. 서버 운영법을 CLAUDE.md로 넘긴다 1. **한 번의 긴 인수인계 프롬프트를 준다.** 서버 사양과 보안 모델, 프로젝트 폴더 규칙, 프로젝트별 tmux 세션, 선호하는 작업 방식, 파괴적 작업 전 확인 같은 상시 규칙을 설명한다. 새 서비스는 localhost나 Tailscale에만 bind하라는 경계도 포함한다. 2. **Claude Code가 그 내용을 먼저 `CLAUDE.md`에 쓰게 한다.** 다음 세션부터 서버 구조와 운영 원칙을 다시 설명하지 않아도 되도록 저장소 밖에 있던 인수인계를 파일로 고정한다. 이 두 단계가 원문의 핵심이다. Claude Code를 설치하는 데서 멈추지 않고, 이 컴퓨터가 어떤 목적으로 존재하고 무엇을 함부로 바꾸면 안 되는지까지 환경 안에 남긴다. 이후에는 “사이트 하나 만들어줘”라고 말해도 Claude Code가 어느 폴더에 만들고, 어떻게 노출하고, 어떤 변경에서 확인을 받아야 하는지 기본값을 가진다. ## 15\~16\. 기능보다 백업을 먼저 만들고 첫 페이지를 띄운다 1. **첫 기능 전에 nightly backup을 만든다.** 원문은 데이터가 매일 GitHub로 올라가도록 하고 실제로 작동하는지 시험한 뒤에야 페이지를 만들라고 제안한다. 2. **나머지 서버 구성을 Claude Code에 맡긴다.** Caddy와 Cloudflare DNS plugin, SQLite를 설치하고 첫 웹페이지를 배포하게 한다. 이후에는 휴대폰 Termius에서 원하는 것을 말하고 결과를 확인하는 흐름이다. 이렇게 16단계가 끝나면 구성은 단순하다. Cloudflare가 공개 웹 요청을 받고, 관리 접속은 Tailscale 안에서만 이뤄진다. 서버 안에서는 Caddy가 웹을 제공하고 SQLite가 데이터를 저장한다. Claude Code는 tmux 안에서 살아 있으며, 노트북과 휴대폰은 Termius를 통해 같은 작업장에 들어간다. ## 그대로 따라 하기 전에 알아둘 세 가지 첫째, 8단계의 방화벽 규칙은 모든 VPS에 그대로 복사할 범용 정답이 아니다. 443번을 Cloudflare IP에서만 받는 구성은 웹 트래픽이 Cloudflare proxy를 통과한다는 전제가 있다. 공개 웹서비스를 아직 띄우지 않거나 다른 노출 방식을 쓴다면 필요한 인바운드 규칙도 달라진다. 둘째, 서버의 “모든 데이터”를 GitHub로 보내면 안 된다. 소스 코드는 private repository에 둘 수 있지만 데이터베이스, 환경변수, 개인 데이터, API 키는 별도의 암호화 백업과 secret 관리가 필요하다. 백업 작업의 성공보다 새 서버에서 실제로 복원되는지가 더 중요하다. 셋째, key expiry를 끄면 편한 대신 오래 살아 있는 서버 신원을 직접 관리해야 한다. Tailscale은 서버 같은 장기 기기에서 만료를 끌 수 있다고 안내하지만, 필요 없어진 기기와 키를 검토하고 폐기하는 책임까지 사라지는 것은 아니다. 휴대폰에서 실행 중인 Claude Code를 조종하는 것만 필요하다면 Anthropic의 Remote Control이 더 짧은 길이다. 로컬 Claude Code 세션을 모바일 앱이나 브라우저에서 이어갈 수 있고, 인바운드 포트를 열지 않는다. 이 VPS 구성이 추가로 주는 것은 노트북과 분리된 가동 시간, 고정된 서버 환경, 직접 호스팅하는 웹서비스다. 그러므로 이 포스트의 결과물은 “휴대폰용 Claude Code”라기보다 **어디서든 들어갈 수 있고, 연결이 끊겨도 계속 살아 있는 개인 서버 작업장**이다. 원문의 16단계는 서버를 사고, 잠그고, Claude Code에 운영법을 인계하고, 백업 뒤 첫 서비스를 띄우는 순서로 읽으면 가장 정확하다. --- 주요 출처: Rob Hallam, [Hetzner VPS·Tailscale·Termius·Claude Code 16단계 구성](https://x.com/robj3d3/status/2080018987849773315?ref=zerodraftlab.com), 2026년 7월 22일; Ghost, [Twitter / X integration](https://ghost.org/integrations/twitter/?ref=zerodraftlab.com); Anthropic, [Claude Code Remote Control](https://code.claude.com/docs/en/remote-control?ref=zerodraftlab.com) 및 [설치 문서](https://docs.anthropic.com/en/docs/claude-code/getting-started?ref=zerodraftlab.com); Tailscale, [Key expiry](https://tailscale.com/docs/features/access-control/key-expiry?ref=zerodraftlab.com)와 [Access control](https://tailscale.com/docs/features/access-control?ref=zerodraftlab.com); Cloudflare, [Cloudflare IP addresses](https://developers.cloudflare.com/fundamentals/concepts/cloudflare-ip-addresses/?ref=zerodraftlab.com); tmux, [공식 프로젝트 문서](https://tmux.github.io/?ref=zerodraftlab.com); GitHub Docs, [Storing your secrets safely](https://docs.github.com/en/get-started/learning-to-code/storing-your-secrets-safely?ref=zerodraftlab.com). ### 에이전트에게 필요한 것은 채팅창이 아니라 자리다 URL: https://zerodraftlab.com/agents-need-a-seat/ Last updated: 2026-08-30T02:49:30.000Z 지금 대부분의 회사에서 AI는 팀원이 아니다. 채팅창 안에서 기다리는 도구다. 사람이 질문하면 답하고, 초안을 만들면 다시 사라진다. 그 결과를 실제 업무에 옮기려면 누군가 복사해 문서에 붙이고, 이슈를 만들고, 코드를 검토하고, 승인자를 찾아야 한다. 우리는 이를 AI와의 협업이라고 부르지만, 구조만 보면 건물 밖 콜센터에 필요할 때마다 전화하는 방식에 가깝다. 모델은 점점 유능해지는데 조직의 생산성이 같은 속도로 오르지 않는 이유도 여기에 있다. **지능은 들어왔지만, 그 지능이 일할 자리는 아직 만들어지지 않았다.** 7월 26일, Gokul Rajaram은 Block의 Buzz 주변에 생태계가 형성되기 시작했다며 SageOx를 소개했다. Buzz 안의 에이전트가 매 세션을 시작할 때 팀의 공유 지식과 더 넓은 업무 맥락을 먼저 읽게 하겠다는 구상이다. > Excited for the ecosystem that's starting to form around Buzz by Block. > > SageOx ([@TheSageOx](https://x.com/TheSageOx?ref%5Fsrc=twsrc%5Etfw&ref=zerodraftlab.com)) is at the forefront of this ecosystem, enabling teams' shared knowledge to natively integrate with Buzz — buzz-agents drawing on team knowledge and broader shared context, every session… [https://t.co/s7f1lijLj2](https://t.co/s7f1lijLj2?ref=zerodraftlab.com) > > — Gokul Rajaram (@gokulr) [July 26, 2026](https://x.com/gokulr/status/2081176841809985941?ref%5Fsrc=twsrc%5Etfw&ref=zerodraftlab.com) 임베딩이 보이지 않으면 [X 원문](https://x.com/gokulr/status/2081176841809985941?ref=zerodraftlab.com)에서 볼 수 있다. Block이 공개한 [Buzz](https://block.xyz/inside/introducing-buzz-where-humans-and-agents-work-together?ref=zerodraftlab.com)는 사람과 AI 에이전트가 채널, 스레드, 다이렉트 메시지, 코드 저장소, 워크플로를 함께 쓰는 오픈소스 협업 공간이다. 겉모습은 익숙한 팀 메신저에 가깝지만, 그 안에서 에이전트를 다루는 방식은 다르다. Buzz에서 에이전트는 각자 암호학적 신원을 갖고 허용된 공간에 참여한다. 대화하고, 코드를 검토하고, 승인된 자동화를 실행한다. 사람 여러 명과 에이전트 여러 명이 같은 작업의 맥락을 공유하고, 앞선 결과 위에서 다음 일을 이어간다. ## 팀원의 조건은 신원·권한·기록이다 에이전트를 팀원처럼 보이게 만드는 일은 쉽다. 이름과 프로필 사진을 붙이고, 먼저 메시지를 보내게 하면 된다. 하지만 그것만으로는 팀원이 되지 않는다. 조직에서 자리를 가진다는 것은 세 가지가 분명하다는 뜻이다. 누구인지, 어디까지 할 수 있는지, 무엇을 했는지다. Buzz는 이 세 가지를 같은 신원 모델에 묶으려 한다. 사람과 에이전트는 각자의 키를 갖고, 채널 멤버십과 권한 범위 안에서 행동하며, 그 행동을 감사 가능한 기록으로 남긴다. 에이전트에게 사람의 계정을 빌려주거나, 모든 자동화를 하나의 API 키 뒤에 숨기는 방식과 다르다. 이 구조의 가치는 실수가 생겼을 때 책임의 경계를 다시 찾을 수 있다는 데 있다. 어떤 에이전트가 어느 대화와 파일을 보고 판단했는지, 누구의 승인 뒤에 무엇을 실행했는지, 다음 사람이 어디서 이어받아야 하는지가 남는다. AI를 믿을 것인가 말 것인가라는 막연한 질문이, 어떤 신원에 어떤 권한을 주고 어떤 증거를 요구할 것인가라는 운영 문제로 바뀐다. ## 협업의 단위가 프롬프트에서 기록으로 바뀐다 현재의 AI 업무는 대개 프롬프트를 중심으로 조직된다. 한 사람이 맥락을 모아 질문하고, 답을 받은 뒤 다른 도구로 옮긴다. 대화는 채팅에, 코드는 저장소에, 테스트 결과는 CI 화면에, 승인은 또 다른 메신저에 남는다. 에이전트가 똑똑해질수록 오히려 이 조각들을 다시 연결하는 사람의 일이 늘어난다. Buzz의 더 큰 제안은 이 조각들을 하나의 작업 기록으로 다루는 데 있다. 현재 공개 저장소는 메시지, 반응, 워크플로 단계, 검토 승인, Git 이벤트를 같은 종류의 서명된 이벤트로 기록한다고 설명한다. 기능 브랜치 하나가 방이 되고, 그 안에서 패치, 테스트, 리뷰, 병합 판단이 함께 쌓이는 그림이다. 이 구조가 작동하면 에이전트는 매번 처음부터 설명을 듣지 않아도 된다. 결정이 내려진 대화와 실제 변경, 승인과 실행 결과가 같은 맥락 안에 있기 때문이다. 중요한 자산도 최고의 프롬프트 모음에서 **조직이 왜 그렇게 결정했는지 다시 읽을 수 있는 기록**으로 이동한다. ## 자리를 얻은 에이전트에게는 기억이 필요하다 Gokul의 포스트가 연결한 [SageOx의 글](https://sageox.ai/blog/welcome-buzz?ref=zerodraftlab.com)은 Buzz를 일하는 장소, SageOx를 팀의 기억을 가진 두뇌로 구분한다. SageOx 팀은 Buzz를 테스트 환경에 띄우고 기존 SageOx 기억을 불러와 에이전트에게 질문했다고 설명한다. 이 사례가 보여주는 것은 완성된 범용 연동보다 두 시스템이 맞물리는 지점이다. Buzz는 누가 어느 채널에서 어떤 권한으로 행동했고 무엇을 남겼는지 기록한다. SageOx의 [Team Context](https://sageox.ai/docs/features/team-context?ref=zerodraftlab.com)는 팀 규칙, 아키텍처 결정, 용어와 회의에서 추출한 지식을 Git 저장소에 보관한다. 에이전트는 세션을 시작할 때 `AGENTS.md`, `SOUL.md`, `TEAM.md`, `MEMORY.md`와 관련 문서 목록을 읽는다. 저장소별 Ledger에는 앞선 작업과 판단의 이력이 쌓인다. 자리와 기억이 결합되면 에이전트는 현재 대화의 참여자가 누구인지, 지금 허용된 행동이 무엇인지, 팀이 이전에 어떤 선택을 했고 왜 되돌렸는지를 한 흐름에서 읽을 수 있다. 새로운 세션이 매번 경력 없는 신입처럼 시작하는 문제도 줄어든다. 다만 SageOx가 발표한 Buzz 연결은 아직 호환성과 더 깊은 연동을 약속한 초기 단계다. 블로그는 테스트 환경에서 기억을 불러온 사례와 앞으로 만들 방향을 함께 말한다. 이미 일반 팀이 설치 버튼 하나로 완성된 통합을 쓸 수 있다는 뜻은 아니다. 기억을 인프라로 만들면 새 책임도 생긴다. SageOx의 [데이터 설명](https://sageox.ai/docs/features/your-data?ref=zerodraftlab.com)에 따르면 Team Context와 Ledger는 표준 Git 저장소로 남고 로컬 사본도 가질 수 있지만, 호스팅 원본은 SageOx의 미국 서부 리전에 놓인다. 회의, 결정, 에이전트 세션에서 무엇을 수집하고 누가 읽을지는 모델 선택보다 먼저 정해야 한다. 팀의 기억은 에이전트의 성능을 높이는 입력이면서 동시에 가장 민감한 운영 자산이기 때문이다. ## Nostr는 신원을 플랫폼 밖에 둔다 Buzz는 Nostr 프로토콜 위에 만들어졌다. Block은 그 이유를 멀티에이전트 협업의 가장 근본적인 문제가 신원이기 때문이라고 설명한다. 사람과 에이전트가 플랫폼 계정이 아니라 자신이 보유한 키쌍으로 참여하면, 신원은 특정 모델 회사나 협업툴에 덜 종속된다. 여기에 Apache 2.0 오픈소스와 자체 호스팅 선택지가 붙는다. 팀은 원하는 모델과 에이전트 도구를 연결하고, 필요하면 데이터와 릴레이를 직접 운영할 수 있다. Block의 호스팅을 이용할 수도 있다. 이론상 협업 공간을 바꾸더라도 에이전트의 신원과 운영 규칙을 한 공급자의 계정 체계에 전부 맡기지 않는 구조다. 다만 휴대 가능한 평판과 여러 릴레이를 넘나드는 완성된 생태계까지 현재 제품으로 착각해서는 안 된다. 공개 저장소도 릴레이 간 평판 같은 기능은 아직 구현된 현실이 아니라 향후 방향으로 구분한다. 개방형 프로토콜은 잠금 효과를 줄일 가능성을 주지만, 자체 호스팅과 키 관리의 운영 부담까지 없애주지는 않는다. ## Buzz는 아직 운영 가설이다 [buzz.xyz](https://buzz.xyz/?ref=zerodraftlab.com)는 스스로를 “초기 단계를 함께 시험해보자”는 말로 소개한다. 공개 저장소 역시 데스크톱 앱, 채널, 검색, 감사 로그, CLI와 일부 Git 기능은 현재 동작하지만 모바일, 승인 워크플로의 연결부, 릴레이 간 평판 등은 진행 중이거나 아직 코드가 따라오지 않은 영역이라고 밝힌다. 지금 당장 모든 협업툴을 대체할 완성품으로 읽으면 안 된다. 그럼에도 Buzz가 던진 질문은 제품의 완성도보다 앞서 있다. 회사가 에이전트를 실제 업무에 넣으려면 어디에 둘 것인가. 개인의 채팅 기록 안에 둘 것인가, 사람 계정을 빌려줄 것인가, 아니면 독립된 신원과 제한된 권한, 검색 가능한 작업 이력을 가진 구성원으로 둘 것인가. 이 질문을 시험하는 데 거대한 전환은 필요하지 않다. 예를 들어 릴리스 노트를 만드는 한 흐름만 맡겨볼 수 있다. 에이전트가 병합된 변경과 관련 대화를 읽고 초안을 만들고, 사람이 검토한 뒤 승인된 결과만 내보내게 한다. 이때 볼 것은 문장을 얼마나 잘 썼는지만이 아니다. 맥락을 다시 설명하는 시간이 줄었는지, 근거를 따라갈 수 있는지, 권한 밖의 행동이 막혔는지, 다음 사람이 기록에서 이어받을 수 있는지를 봐야 한다. AI 시대의 협업툴은 사람과 에이전트가 같은 맥락을 읽되 서로 다른 권한으로 행동하고, 그 결과를 같은 기록에 남기는 운영체제가 되어야 한다. 그 기록에서 팀의 기억을 추출해 다음 세션으로 되돌려주는 흐름도 필요하다. 에이전트에게 신원과 제한된 권한을 주고, 팀의 기억을 다음 세션으로 돌려보내는 좁은 워크플로 하나부터 시험해야 한다. *이어 읽기:* [*잭 도시는 플랫폼을 만들었다. 지금은 플랫폼 밖의 질서를 만든다*](https://zerodraftlab.com/jack-dorsey-beyond-platforms/) --- 주요 출처: Gokul Rajaram, [Buzz와 SageOx 생태계에 관한 포스트](https://x.com/gokulr/status/2081176841809985941?ref=zerodraftlab.com); SageOx, [Welcome, Buzz. We've Been Expecting You.](https://sageox.ai/blog/welcome-buzz?ref=zerodraftlab.com), [Team Context](https://sageox.ai/docs/features/team-context?ref=zerodraftlab.com), [Your data](https://sageox.ai/docs/features/your-data?ref=zerodraftlab.com); Block, [Introducing Buzz: where humans and agents work together](https://block.xyz/inside/introducing-buzz-where-humans-and-agents-work-together?ref=zerodraftlab.com); [Buzz 공식 사이트](https://buzz.xyz/?ref=zerodraftlab.com); Block, [Buzz 오픈소스 저장소](https://github.com/block/buzz?ref=zerodraftlab.com). 신원·권한·기록을 조직 내 “자리”로 해석한 부분, 자리와 기억의 결합, 좁은 릴리스 워크플로부터 검증하자는 제안은 Zero Draft Lab의 해석입니다. ### 모두를 만족시키려 만든 전략은 아무것도 바꾸지 못한다 URL: https://zerodraftlab.com/strategy-that-pleases-everyone/ Last updated: 2026-09-15T08:35:27.000Z 전략회의는 평화롭게 끝났다. 영업팀이 원한 엔터프라이즈 확장, 제품팀이 원한 AI 기능, 마케팅팀이 원한 리브랜딩, 고객팀이 원한 리텐션 개선이 모두 ‘핵심 과제’에 들어갔다. 누구의 예산도 줄지 않았고, 누구의 프로젝트도 취소되지 않았다. 회의실에서는 이것을 정렬이라고 불렀다. 다음 날 조직은 작년과 똑같이 일했다. 한 가상의 소프트웨어 회사를 생각해보자. CEO는 선택과 집중을 주문했지만, 각 부서는 자기 과제가 빠지면 회사가 위험해진다고 설명했다. 논쟁을 끝내는 가장 쉬운 방법은 전부 넣는 것이었다. 문서는 길어졌고 갈등은 사라졌다. 대신 전략이 해야 할 일도 함께 사라졌다. **모두를 만족시키려 만든 전략은 아무 행동도 틀렸다고 말하지 못한다.** ## 목표가 늘어난 것이 아니라 선택이 사라진 것이다 “매출을 키운다”, “고객 경험을 혁신한다”, “AI 전환을 선도한다”는 문장은 바람직하다. 문제는 이 문장들이 거의 모든 프로젝트를 정당화한다는 데 있다. 엔터프라이즈 영업도, 셀프서비스 제품도, 대규모 브랜드 캠페인도, 비용 절감도 모두 같은 목표 아래 들어갈 수 있다. 무엇을 먼저 하고 무엇을 포기할지는 여전히 현장에 남는다. 리처드 루멜트가 목표와 전략을 구분하는 이유다. 전략은 원하는 상태를 크게 선언하는 일이 아니라, 전진을 막는 결정적 장애물을 규정하고 그 장애물에 힘을 집중하는 일이다. 목표는 방향을 알려줄 수 있지만, 장애물과 대응 방식이 없으면 어려운 선택을 대신하지 못한다. 나쁜 전략은 종종 무능보다 갈등 회피에서 나온다. 하나를 고르면 다른 하나는 밀린다. 특정 고객을 우선하면 다른 고객의 요구를 늦춰야 하고, 온보딩을 고치기로 하면 신규 기능 일부를 미뤄야 한다. 리더가 이 손실을 감수하지 않으면 전략 문서는 각 부서의 희망을 모은 휴전 협정이 된다. ## 전략은 무엇을 할지가 아니라 무엇이 이제 틀렸는지를 말한다 좋은 전략이 생기면 어제까지 합리적이던 행동 중 일부가 오늘은 잘못된 행동이 된다. 고객 정착이 병목이라면 리드만 늘리는 광고는 우선순위에서 밀린다. 유통이 병목이라면 제품 기능을 더 쌓는 일은 핵심 대응이 아니다. 전략은 새로운 할 일을 추가하기 전에 기존 행동의 정당성을 다시 심사한다. 그래서 가장 간단한 판별 질문은 이것이다. 이 전략 때문에 중단되거나 미뤄지는 일이 있는가. 없다면 문서는 목표, 가치, 운영계획일 수는 있어도 자원을 집중시키는 전략은 아닐 가능성이 크다. 첫 번째 선택은 할 일이 아니라 문제의 이름에서 시작된다. 루멜트가 전략의 첫 요소로 진단을 두는 이유다. 진단은 현황을 빠짐없이 요약하는 문장이 아니라, 복잡한 상황에서 무엇이 성패를 가르는지 선택하는 판단이다. 하지만 같은 매출 정체에도 어떤 진단을 붙이느냐에 따라 예산과 행동은 정반대로 갈린다. 가상의 소프트웨어 회사는 성장 둔화를 보고 있다. 이것을 “인지도 부족”으로 진단하면 브랜드 캠페인이 맞고, “엔터프라이즈 기능 부족”으로 진단하면 제품 개발이 맞다. 그러나 실제 병목이 계약 뒤 첫 달의 정착 실패라면 두 처방은 문제를 비껴간다. 같은 매출 정체를 보고도 진단 하나가 예산의 목적을 완전히 바꾼다. 좋은 진단은 반박 가능해야 한다. “우리는 더 혁신해야 한다”는 문장은 어떤 결과가 나와도 틀렸다고 판정하기 어렵다. 반면 “성장 둔화의 핵심은 신규 유입이 아니라 첫 달 정착 실패다”는 문장은 코호트와 사용 데이터로 공격할 수 있다. 틀릴 수 있는 문장만이 행동을 고를 만큼 구체적인 문장이다. 두 번째 선택은 진단에 대응하는 지도 방침이다. 지도 방침은 목표 숫자도 세부 할 일도 아니다. 무한한 대응 중 어떤 방식으로 장애물을 넘을지 정하는 가드레일이다. 첫 달 정착이 문제라면 “신규 세그먼트 확장을 잠시 멈추고, 기존 핵심 고객이 첫 가치를 얻는 시간에 제품·영업·고객팀의 자원을 집중한다”처럼 행동의 범위를 좁힌다. 이 문장의 힘은 멋진 방향보다 배제에서 나온다. 새 세그먼트 캠페인, 범용 AI 기능, 사용하지 않는 고객까지 끌어오는 할인은 방침과 충돌한다. 전략이 생기자 회의에서 모두 살려둔 프로젝트 중 일부가 비로소 중단 후보가 된다. ## 행동은 많아서가 아니라 서로를 강화할 때 전략이 된다 세 번째 선택은 일관된 행동이다. 제품팀이 첫 설정 단계를 줄이고, 영업팀이 적합하지 않은 고객을 무리하게 계약하지 않으며, 고객팀이 첫 달의 핵심 행동에 개입하고, 마케팅팀이 빠른 가치 도달을 약속한다면 각 행동은 다른 행동의 효과를 키운다. 반대로 영업 보상은 계약 수만 늘리고 제품은 고급 기능에 몰두한다면, 부서마다 열심히 일해도 전체 전략은 서로를 지운다. 여기서 ‘진단·방침·행동’이라는 세 칸을 채우는 것만으로 전략이 완성되는 것은 아니다. 진단은 틀릴 수 있고, 방침은 현실의 역량을 과대평가할 수 있으며, 행동은 말로만 정렬될 수 있다. 그래서 전략의 진짜 read-back은 문서가 아니라 예산, 인력, 일정에서 일어난 이동이다. 전략을 세웠는데도 모든 프로젝트가 살아 있고 부서별 예산 비율이 그대로이며 일정에서 밀려난 일이 없다면, 조직은 아직 선택하지 않은 것이다. 반대로 중단된 프로젝트가 있고, 특정 병목에 여러 부서의 행동이 모이고, 그 진단이 틀렸을 때 확인할 데이터가 있다면 전략은 문서 밖으로 나온다. ## 여러 목표를 갖는 것과 여러 전략을 한 문서에 숨기는 것은 다르다 물론 조직은 매출, 품질, 고객, 비용을 동시에 관리해야 한다. 전략이 하나의 숫자만 보라는 뜻은 아니다. 운영 목표는 여러 개일 수 있고, 서로 다른 사업에는 서로 다른 전략이 필요할 수 있다. 문제는 한정된 자원을 두고 경쟁하는 선택들을 모두 ‘최우선’으로 부르면서, 어느 도전이 지금 중심인지 말하지 않는 것이다. 처음의 가상 회사가 다시 전략회의를 연다면 질문은 “무엇을 더 넣을까”가 아니다. 지금 전진을 막는 결정적 장애물은 무엇인가. 그 장애물을 넘기 위해 어떤 접근을 택할 것인가. 그 선택 때문에 중단되는 일은 무엇인가. 그리고 남은 행동들은 서로의 힘을 키우는가. 이 질문에 답하는 순간 회의는 덜 평화로워진다. 누군가는 예산을 잃고, 누군가의 좋은 아이디어는 다음으로 밀린다. 그러나 바로 그 불편함이 자원이 실제로 모이고 있다는 증거다. **모두가 만족한 전략이 아무것도 바꾸지 못하는 이유는 합의가 나빠서가 아니라, 선택의 대가까지 합의하지 않았기 때문이다.** --- 주요 출처: Richard Rumelt, [Good Strategy Bad Strategy](https://www.richardrumelt.com/books?ref=zerodraftlab.com); [The Rumelt Perspectives](https://rumelt.substack.com/about); Penguin Random House, [Good Strategy Bad Strategy](https://www.penguinrandomhouse.com/books/208668/good-strategy-bad-strategy-by-richard-rumelt/?ref=zerodraftlab.com). 소프트웨어 회사와 전략회의는 논지를 설명하기 위한 가상 사례이며, 각 부서의 행동 예시는 이 글의 독립 해석입니다. ### 고객은 당신을 안다. 살 때는 경쟁사를 떠올린다 URL: https://zerodraftlab.com/known-but-not-recalled/ Last updated: 2026-09-15T08:35:27.000Z 브랜드 인지도는 올랐다. 신규 매출은 그대로였다. 회의실에서 가장 먼저 나온 처방은 광고를 더 오래 돌리자는 것이었다. 사람들이 이름을 알아보기 시작했으니 노출량만 늘리면 구매도 따라올 것이라는 계산이었다. 합리적으로 들린다. 대시보드에는 실제로 좋아진 숫자가 있고, 광고를 끄는 선택은 성과를 포기하는 것처럼 보인다. 그러나 이 팀이 고객의 구매 순간을 따라가 봤다면 전혀 다른 장면을 발견했을 수 있다. 고객은 브랜드 이름을 알고 있었다. 정작 문제가 생긴 날에는 경쟁사를 떠올렸다. 한 가상의 회계 소프트웨어 팀을 생각해보자. 고객은 설문에서 이 브랜드를 알아본다. 하지만 월말 손익을 급히 정리해야 할 때는 “월말 결산 자동화”를 검색하고, 처음 직원을 뽑았을 때는 “급여·세금 처리”로 시작한다. 두 순간 모두 브랜드 이름은 검색어에도, 첫 후보에도 없다. 나중에 이름을 보여주면 “알고 있던 서비스”라고 답한다. **브랜드는 고객의 기억 속에 있었지만, 필요한 순간으로 가는 길이 없었다.** ## 설문에서는 기억났고, 구매 순간에는 사라졌다 인지도 조사는 대개 브랜드명이나 카테고리명을 단서로 준다. 이 이름을 아는가, 이 카테고리에서 떠오르는 브랜드는 무엇인가를 묻는다. 실제 구매는 다른 단서에서 시작된다. 마감이 닥쳤을 때, 비용이 새고 있을 때, 누군가에게 결과를 보고해야 할 때처럼 고객의 상황이 먼저 기억을 두드린다. 에런버그-배스 연구소가 정신적 가용성을 인지도와 구분하는 이유다. 정신적 가용성은 구매 상황에서 브랜드가 생각나거나 눈에 띌 가능성이다. 이름을 저장한 사람의 수보다, 그 이름으로 들어가는 상황별 경로가 얼마나 넓고 선명한지를 본다. 브랜드를 안다는 대답은 파일이 존재한다는 뜻일 뿐, 필요한 순간에 그 파일이 열린다는 뜻은 아니다. 구매를 시작하게 만드는 상황 단서를 카테고리 진입점이라고 부른다. “회계가 필요할 때”는 너무 넓다. 월말 보고가 밀렸을 때, 첫 직원을 채용했을 때, 세금 신고를 앞두고 증빙이 흩어졌을 때는 서로 다른 진입점이다. 브랜드가 추상적인 “간편한 회계”에만 연결돼 있다면 고객은 문구에는 동의하면서도 자기 문제가 터진 순간에는 다른 이름을 꺼낸다. ## 그래서 팀은 틀린 숫자에 맞는 예산을 늘린다 여기서 인지도는 위험한 위안을 준다. 광고가 무언가를 만들고 있다는 증거는 보여주지만, 무엇을 만들지 못했는지는 숨긴다. 팀은 브랜드명을 더 반복하고, 보조 인지도는 다시 오른다. 반면 고객의 문제와 브랜드 사이에는 새 연결이 생기지 않는다. 측정하기 쉬운 숫자가 다음 예산의 방향까지 결정하는 순간이다. 그렇다고 답이 무조건 광고 중단은 아니다. 이 가상의 팀 앞에는 세 개의 제안이 놓일 수 있다. 도달을 더 살 것인가, 검색·유통 경로를 고칠 것인가, 제품과 가격을 손볼 것인가. 셋 다 그럴듯하다. 하지만 고객이 사라진 순간을 구분하지 못하면 다음 예산도 가장 익숙한 손잡이에 들어간다. 그 매출은 정확히 어디에서 새고 있을까? 첫 번째 누수는 필요가 생겼는데 브랜드가 떠오르지 않는 순간이다. 고객은 카테고리에 들어왔지만 우리를 후보로 불러내지 못한다. 이때 문제는 전환 버튼이나 영업 스크립트가 아니다. 브랜드와 중요한 구매 상황 사이의 기억 연결이 약한 것이다. 기억 누수는 브랜드명을 먼저 보여주는 조사로 찾기 어렵다. 상황을 먼저 제시해야 한다. “월말 손익을 내일까지 보고해야 한다면 무엇을 쓰겠는가”, “첫 급여 처리를 맡게 됐다면 어떤 서비스를 찾겠는가”처럼 실제 구매 단서에서 출발한다. 여기서 경쟁사는 나오고 우리 이름이 나오지 않는다면, 더 많은 일반 인지도보다 그 상황과 브랜드를 함께 기억시키는 광고가 필요하다. ## 떠오르지 않았는가, 찾지 못했는가, 보고도 거절했는가 이때 캠페인의 단위도 슬로건에서 구매 상황으로 바뀐다. 같은 “간편한 회계”를 반복하는 대신 월말 보고, 첫 채용, 세금 신고처럼 상업적으로 충분히 큰 진입점마다 브랜드가 필요한 이유를 연결한다. 상황은 달라져도 이름, 색, 형태, 문체 같은 식별 장치는 고정한다. 변해야 하는 것은 기억의 입구이고, 축적돼야 하는 것은 발신자다. 두 번째 누수는 브랜드가 떠올랐는데 찾거나 살 수 없는 순간이다. 고객이 브랜드명을 검색했지만 결과에서 공식 상품을 구분하기 어렵고, 원하는 요금제나 규격이 없고, 가입과 결제가 막힌다. 이때 광고를 더 사면 수요는 늘어도 누수도 함께 커진다. 필요한 것은 정신적 가용성이 아니라 존재하고, 눈에 띄고, 살 수 있게 만드는 물리적 가용성이다. 오프라인에서는 입점, 재고, 매대가 이 문제를 드러낸다. 온라인에서는 검색 결과, 마켓플레이스 노출, 상품명과 썸네일, 가격 공개, 가입 단계가 같은 역할을 한다. 고객이 우리를 직접 찾았다는 흔적은 있는데 구매 환경에서 사라진다면, 다음 예산은 브랜드 광고보다 발견과 거래의 배관으로 가야 한다. 세 번째 누수는 더 불편하다. 고객이 우리를 떠올렸고, 찾았고, 비교했지만 경쟁사를 골랐다. 가격이 맞지 않거나, 필요한 기능이 없거나, 신뢰할 증거가 부족하거나, 전환 비용이 너무 크기 때문이다. 이 상황을 “브랜드가 덜 알려져서”라고 설명하면 제품과 오퍼의 결함을 광고비로 덮게 된다. 정신적·물리적 가용성은 비교 목록에 들어가게 할 수 있지만, 약한 선택 이유까지 대신해주지는 않는다. ## 유료 전환을 만드는 것은 더 많은 지표가 아니라 누수의 위치다 세 누수는 대시보드 하나로 구분되지 않는다. 상황별 비보조 회상, 브랜드 검색과 검색 결과, 상품 조회 이후의 이탈, 잃어버린 거래의 이유를 같은 구매 흐름 위에 놓아야 한다. 각각을 따로 보면 마케팅팀은 기억 문제를, 커머스팀은 발견 문제를, 제품팀은 오퍼 문제를 자기 언어로만 설명한다. 연결하면 고객이 어느 문 앞에서 돌아섰는지가 보인다. 가상의 회계 소프트웨어 팀도 먼저 결론을 고를 필요가 없다. 월말 보고 상황에서 이름이 나오지 않으면 그 진입점과 브랜드를 연결한다. 이름을 직접 검색하는데 적합한 상품이 보이지 않으면 검색과 포트폴리오를 고친다. 데모와 가격표까지 본 고객이 계약하지 않으면 잃은 거래의 이유를 제품·가격·증거에서 찾는다. 같은 매출 정체라도 예산이 향할 곳은 완전히 달라진다. 인지도는 버릴 지표가 아니다. 모르는 브랜드는 떠올리기 어렵다. 다만 인지도가 높다는 사실만으로 광고의 다음 1원이 정당화되지는 않는다. 그 돈은 기억의 연결을 새로 만들 수도 있고, 이미 존재하는 수요가 새는 배관을 고칠 수도 있고, 선택받지 못하는 오퍼를 바꿀 수도 있다. 고객이 브랜드를 안다고 말하는데도 매출이 움직이지 않는다면 광고 효과부터 의심할 필요는 없다. 먼저 고객이 사라진 순간을 찾아야 한다. **필요할 때 떠올리지 못했는지, 떠올리고도 찾지 못했는지, 찾고도 선택하지 않았는지.** 이 세 문장을 가르지 못한 인지도는 성과가 아니라 다음 오판을 안심시키는 숫자가 된다. --- 주요 출처: Ehrenberg-Bass Institute, [Mental availability is not awareness, brand salience is not awareness](https://marketingscience.info/news-and-insights/mental-availability-is-not-awareness-brand-salience-is-not-awareness?ref=zerodraftlab.com), [Identifying and Prioritising Category Entry Points](https://marketingscience.info/learn-with-us/commercial-research/identifying-and-prioritising-category-entry-points?ref=zerodraftlab.com), [Easy to Find: Being Where B2B Buying Happens](https://marketingscience.info/news-and-insights/easy-to-find-being-where-b2b-buying-happens?ref=zerodraftlab.com). 회계 소프트웨어 팀은 논지를 설명하기 위한 가상 사례이며, 기억·발견·오퍼의 세 누수 구분은 이 글의 해석입니다. ### 리텐션은 성장을 대신하지 못한다 URL: https://zerodraftlab.com/retention-is-not-growth/ Last updated: 2026-09-15T08:35:28.000Z 리텐션은 숫자가 깔끔하다. 가입한 고객이 다시 왔는지, 구독을 갱신했는지, 이탈률이 몇 퍼센트인지 바로 보인다. 반면 아직 우리를 사지 않은 사람은 CRM에 없다. 그래서 팀은 보이는 고객을 더 자주 움직이는 일을 성장이라고 부르기 쉽다. 하지만 기존 고객이 잘 남아 있는 것과 시장에서 더 커지는 것은 같은 일이 아니다. 고객 열 명이 모두 남아도 새 고객이 한 명도 오지 않으면 사업의 크기는 바뀌지 않는다. **리텐션은 현재 매출을 지키는 힘이고, 성장은 구매자 풀의 크기를 바꾸는 힘**이다. ## 작은 브랜드는 충성도 때문에 작은 것이 아니다 에런버그-배스 연구소가 여러 시장에서 관찰한 이중 위험 법칙은 큰 브랜드와 작은 브랜드의 차이를 두 부분으로 나눈다. 작은 브랜드는 구매자가 훨씬 적고, 그 적은 구매자들의 구매 빈도와 충성도도 조금 낮다. 첫 번째 차이는 크고 두 번째 차이는 작다. 여기서 순서를 거꾸로 읽으면 안 된다. 작은 브랜드의 낮은 재구매율을 독립된 원인으로 보고 충성도만 끌어올리려 하면, 브랜드 크기의 결과에 매달리게 된다. 브랜드가 더 많은 사람에게 선택되면 구매 빈도와 태도도 대체로 조금씩 따라 움직인다. 충성도는 완전히 따로 돌릴 수 있는 손잡이가 아니다. 이 법칙은 충성 고객이 쓸모없다는 말도 아니다. 한 사람의 매출 기여는 헤비 바이어가 크다. 다만 성장의 다음 단위를 어디서 얻을 것인지가 다른 문제다. 이미 자주 사는 사람은 더 살 수 있는 여지가 작고, 올해의 헤비 바이어가 내년에도 같은 강도로 살 것이라는 보장도 없다. ## 라이트 바이어는 작아서 보이지 않고, 많아서 중요하다 브랜드의 구매자 구성에는 어쩌다 한 번 사는 사람이 늘 많다. 개인별 매출이 작아 CRM 우선순위에서는 밀리지만, 이들이 모이면 매출의 큰 부분이 된다. 브랜드가 성장할 때도 변화의 상당 부분은 소수 단골의 구매 횟수가 폭증해서가 아니라, 더 많은 사람이 가끔이라도 브랜드를 사기 시작해서 생긴다. 그런데 조직의 도구는 반대 방향으로 기울어 있다. CRM은 이미 아는 고객을 세분화하고, 자동화는 재구매 메시지를 정교하게 만들며, 대시보드는 작은 이탈률 개선을 즉시 칭찬한다. 아직 고객이 아닌 사람에게 더 넓게 기억되고 더 쉽게 발견되는 일은 느리고 귀속도 어렵다. 측정하기 쉬운 일이 성장의 정의를 가로채는 순간이다. 그렇다면 리텐션을 포기하고 신규 획득에만 돈을 쓰라는 뜻일까? 아니다. 뜻은 더 단순하다. **방어와 성장을 같은 이름으로 부르지 말라**는 것이다. 약속한 품질을 지키고, 예방 가능한 실패를 줄이고, 갱신 과정의 불필요한 마찰을 없애는 일은 사업의 바닥을 지킨다. 바닥이 새는 상태에서 유입을 늘리면 획득비만 낭비한다. ## 기본 품질과 추가 충성도 투자는 다르다 문제는 건강한 바닥을 만든 뒤에도 모든 추가 예산을 기존 고객에게 다시 쓰는 경우다. 이미 살 사람이 받는 포인트, 이미 익숙한 고객에게만 보이는 개인화, 필요하지 않은 상품의 교차판매는 매출을 새로 만들기보다 원래 일어날 행동에 보조금을 얹을 수 있다. 리텐션의 첫 층은 제품과 서비스의 결함을 고치는 일이다. 그 위의 추가 투자는 반드시 한계효과를 물어야 한다. 같은 비용으로 이탈을 조금 더 낮추는 편이 나은지, 아직 우리를 떠올리지 못하는 카테고리 구매자에게 닿는 편이 나은지 비교해야 한다. 예산은 충성이라는 미덕이 아니라 다음 매출 한 단위의 출처를 따라가야 한다. ## 구독 사업도 이 원리 밖에 있지 않다 구독 사업에서는 이탈이 훨씬 선명하게 보이므로 리텐션이 전부처럼 느껴진다. 높은 이탈은 실제로 치명적이다. 고객이 약속한 가치를 받지 못해 빠져나가고 있다면 먼저 고쳐야 한다. 그러나 이탈이 안정된 뒤에도 가입자 수를 키우려면 결국 새 고객이 들어와야 한다. 따라서 “획득이 중요하다”는 말도 CAC를 무시하고 아무 고객이나 사 오라는 처방이 아니다. 새 구매자가 만드는 총이익, 회수기간, 운영 용량을 함께 봐야 한다. 리텐션과 단위경제성이 최소선을 통과한 뒤, 더 많은 카테고리 구매자에게 기억되고 발견되고 구매되게 만드는 것이 성장이다. ## AI는 잘못 고른 손잡이도 더 빨리 돌린다 AI는 기존 데이터베이스를 쪼개고, 이탈 가능성을 예측하고, 사람마다 다른 메시지를 보내는 비용을 빠르게 낮춘다. 이것은 유용하지만 목표를 대신 정해주지는 않는다. 구매자 풀이 줄고 있는데도 기존 고객의 클릭률만 계속 최적화하면, 더 정교한 리텐션 시스템이 더 작은 시장을 관리하게 된다. 그래서 AI 마케팅 시스템에는 현재 고객 지표만 넣어서는 안 된다. 카테고리 전체에서 우리를 사는 사람의 비율, 첫 구매자 수, 라이트 바이어의 재진입, 비구매자 도달, 검색·유통·결제에서의 발견 가능성을 함께 봐야 한다. 에이전트가 무엇을 최적화할지는 모델 성능보다 성장의 정의에 달려 있다. ## 성장 목표는 애정이 아니라 구매자 수로 쓴다 충성 고객은 중요하다. 다만 그 중요성 때문에 성장의 원천까지 충성도로 설명할 수는 없다. 기존 고객에게 약속한 가치를 지키는 일은 방어로, 새로운 구매 기회를 만드는 일은 성장으로 분리하면 예산의 역할이 선명해진다. 리텐션은 사업이 무너지지 않게 한다. 그러나 사업의 외곽선을 넓히는 것은 아직 우리 고객이 아닌 사람, 그리고 가끔만 우리를 사는 사람이다. **성장을 원한다면 고객이 얼마나 사랑하는지만 묻지 말고, 얼마나 많은 사람이 한 번이라도 우리를 선택하는지부터 물어야 한다.** --- 출발 소절: 마케팅 고전 워크북의 「침투율이 성장을 결정한다」. 주요 대조 출처: Ehrenberg-Bass Institute, [Effective brand growth: Acquisition or retention?](https://marketingscience.info/news-and-insights/effective-brand-growth-acquisition-or-retention?ref=zerodraftlab.com), [The heavy buyer fallacy](https://marketingscience.info/news-and-insights/the-heavy-buyer-fallacy?ref=zerodraftlab.com), [Answering critics](https://marketingscience.info/answering-critics/?ref=zerodraftlab.com). 방어와 성장의 예산 분류, 구독 사업의 최소선, AI 최적화로의 확장은 이 글의 해석입니다. ### 새 카테고리는 이름이 아니라 교육비다 URL: https://zerodraftlab.com/category-creation-is-market-education/ Last updated: 2026-09-15T08:35:29.000Z 스타트업의 소개 자료에는 자주 이런 문장이 등장한다. “우리는 새로운 카테고리를 만들고 있다.” 기존 시장의 추격자보다 새 시장의 창시자가 더 커 보이고, 경쟁사가 없는 이름을 붙이면 비교에서도 벗어날 수 있을 것처럼 느껴진다. 이 기대가 전부 허상은 아니다. 새 카테고리를 만든 회사는 제품 이름보다 먼저 문제를 설명하고, 좋은 해결책의 기준을 정하며, 시장이 커질수록 그 기준의 대표자로 불릴 수 있다. April Dunford가 소개한 Eloqua처럼 실제로 카테고리를 만들고 선두가 된 사례도 있다. 그래서 카테고리 창조는 브랜딩의 최고 단계처럼 보인다. 남이 만든 비교표에서 한 칸을 차지하는 대신 비교표 자체를 만드는 전략이다. 성공하면 제품을 파는 회사가 아니라 시장의 언어를 소유한 회사가 된다. ## 이름을 만든 순간 비용이 시작된다 하지만 새 이름은 아직 시장이 아니다. 고객은 먼저 그 말의 뜻을 배워야 하고, 자신이 왜 그 문제를 갖고 있는지 이해해야 하며, 기존 방식과 다른 예산을 써야 하는 이유까지 납득해야 한다. 마지막으로 여러 대안 중 왜 최초 제안자를 골라야 하는지도 다시 배워야 한다. 기존 카테고리에 들어가면 이 설명의 상당 부분을 빌릴 수 있다. “회계 소프트웨어”라고 말하면 고객은 대략 무엇을 하고, 누가 쓰며, 어떤 예산에서 검토하는지 안다. 새 카테고리는 이 선반을 빌리지 않는다. 제품을 올려놓을 선반부터 직접 만들어야 한다. Dunford는 새 카테고리를 만드는 회사가 문제, 이름, 구매 기준을 교육한 뒤 정작 더 큰 후발주자에게 시장을 내줄 수 있다고 경고한다. 최초 진입자는 모두가 사용할 언어에 먼저 투자하지만, 그 언어가 공용재가 되는 순간 경쟁자는 교육비를 내지 않고 들어온다. 그러므로 “경쟁사가 없는 카테고리”는 종종 “아직 고객의 머릿속에도 없는 카테고리”다. 경쟁이 사라진 것이 아니라 시장 교육이라는 더 비싼 경쟁으로 바뀐 셈이다. ## 기존 시장을 쓰는 것은 야망 부족이 아니다 그렇다면 큰 회사를 만들려면 언젠가 반드시 새 카테고리를 선언해야 할까? 그럴 필요는 없다. 기존 카테고리는 낡은 꼬리표가 아니라 고객이 이미 지불한 학습비다. 무엇을 기대해야 하는지, 누구와 비교해야 하는지, 어느 예산에서 사야 하는지에 관한 공통 지식이 들어 있다. 좋은 포지셔닝은 그 지식을 버리지 않고 우리 강점이 가장 잘 보이는 부분만 선택한다. Dunford가 설명한 Janna Systems 사례가 이를 보여준다. 회사는 처음에 거대한 Siebel과 “엔터프라이즈 CRM”으로 맞붙었다. 관계 구조를 다르게 표현하는 고유 기능이 있었지만 일반 CRM 비교에서는 그 가치가 흐렸다. 투자은행 고객에게서는 그 기능이 거래에 영향을 주는 인간관계를 파악하는 핵심 능력이 됐다. 회사는 완전히 새 이름을 만들지 않고 “투자은행을 위한 CRM”으로 범위를 좁혔다. CRM이라는 익숙한 선반은 유지하되, 자신이 이길 수 있는 고객과 구매 기준을 바꾼 것이다. Dunford의 기록에 따르면 매출은 18개월 동안 200만 달러 미만에서 약 8,000만 달러까지 성장했고, 이후 Siebel에 인수됐다. 이 사례의 교훈은 틈새에 영원히 머물라는 것이 아니다. 먼저 가장 쉽게 이기는 작은 시장에서 증거와 준거 고객을 만들고, 자원과 신뢰가 생긴 뒤 경계를 넓힐 수 있다는 뜻이다. Salesforce와 Qualtrics도 큰 범주를 다시 그리기 전에 각각 CRM과 설문 소프트웨어라는 기존 시장에서 충분한 규모를 만들었다고 Dunford는 지적한다. ## 새 카테고리는 세 가지 부담을 감당할 때만 성립한다 기존 어떤 범주도 제품의 핵심 가치를 심하게 왜곡한다면 새 틀이 필요할 수 있다. 그러나 새로움만으로는 부족하다. 고객이 문제와 이름과 구매 기준을 배울 때까지 반복해서 설명할 유통력, 영업력, 자본이 있어야 한다. 그 교육이 끝난 뒤 후발주자가 같은 언어를 쓸 때도 선두를 지킬 제품·데이터·네트워크·브랜드 같은 축적도 필요하다. 셋 중 하나가 없다면 새 카테고리 선언은 전략보다 문구에 가깝다. 제품의 가치가 기존 범주 안에서도 설명되는데 새 이름을 고집하면, 차별화하려고 고객의 이해를 희생한다. 교육할 자원이 없으면 시장이 배우기 전에 회사의 시간이 먼저 끝난다. 축적이 없으면 시장이 열린 뒤 더 강한 회사가 기준을 가져간다. AI 제품은 특히 이 함정에 빠지기 쉽다. “AI 에이전트 플랫폼”, “지능형 업무 운영체제” 같은 이름은 기술의 시의성을 말하지만 고객이 무엇을 사고 어떤 대안을 버리는지는 설명하지 못할 수 있다. AI라는 단어를 빼도 무엇을 파는지 분명해야 한다. 카테고리는 제품의 자리를 정하고, 트렌드는 왜 지금 중요한지를 보탠다. ## 카테고리 창조는 공짜로 얻는 독점이 아니다 새 카테고리를 만들면 경쟁을 피할 수 있다는 말은 절반만 맞다. 기존 경쟁사와의 직접 비교에서는 벗어날 수 있지만, 대신 무관심과 오해와 예산 부재를 모두 상대해야 한다. 그리고 성공해서 시장이 보이는 순간에는 교육을 마친 후발주자와 다시 경쟁한다. 따라서 질문은 “우리가 새 카테고리의 리더가 될 수 있는가”보다 먼저 와야 한다. **“이 시장의 학습비를 우리가 먼저 내야만 제품의 가치가 보이는가.”** 답이 아니라면 익숙한 범주를 빌리고, 이길 수 있는 하위 시장을 고르며, 이미 다른 사실을 증명하는 편이 낫다. 새 카테고리는 멋진 이름이 아니다. 고객 전체가 새로운 방식으로 생각하도록 만드는 장기 투자다. 이름을 붙이는 데는 하루가 걸리지만, 시장이 그 이름으로 예산을 쓰게 만드는 데는 회사의 유통과 자본과 시간이 들어간다. 카테고리를 만든다는 말은 결국 그 교육비를 먼저 내겠다는 약속이다. --- 출발 소절: 마케팅 고전 워크북의 「시장 범주와 세일즈 스토리」 중 ‘범주 전략 세 가지’. 주요 대조 출처: April Dunford, [A Quickstart Guide to Positioning](https://www.aprildunford.com/post/a-quickstart-guide-to-positioning?ref=zerodraftlab.com) 및 [Product Framing Can Help Grow Your Startup—or Kill It](https://www.aprildunford.com/post/product-framing-can-help-grow-your-startup-or-kill-it?ref=zerodraftlab.com). Janna Systems의 성장 수치는 Dunford가 보고한 사례이며, 교육비·공용재·AI 트렌드 레이어로의 확장은 이 글의 해석입니다. ### 형용사를 지우면 차별점이 보인다 URL: https://zerodraftlab.com/adjectives-are-not-differentiation/ Last updated: 2026-09-15T08:35:29.000Z 제품 소개서에서 가장 빨리 늘어나는 것은 기능이 아니라 형용사다. 더 빠른, 더 쉬운, 더 똑똑한, 더 유연한. 문제는 경쟁사도 같은 단어를 쓸 수 있다는 데 있다. 누구나 주장할 수 있는 장점은 고객이 비교할 수 없는 장점이다. 차별화는 좋은 말을 고르는 작업이 아니다. **고객의 실제 대안에는 없고 우리에게는 있는 사실을 찾는 작업**이다. April Dunford의 포지셔닝 순서에서 고유 속성이 경쟁 대안 다음에 오는 이유도 여기에 있다. 무엇과 비교하는지 정하지 않으면 무엇이 다른지도 정할 수 없다. 예를 들어 “도입이 쉽다”는 차별점이 아니다. 엑셀 파일을 그대로 올릴 수 있다, 설치 없이 첫 작업을 끝낼 수 있다, 기존 방식과 30일 동안 병행할 수 있다는 문장은 차별점 후보가 된다. 각각은 고객이 확인할 수 있고, 경쟁 대안과 나란히 놓을 수 있으며, 거짓이면 반박할 수 있기 때문이다. ## 차별점은 비교 가능한 사실이다 팀은 흔히 제품 안에서만 차이를 찾는다. 그러나 고객이 사는 것은 코드가 아니다. 같은 기능이라도 설치 방식, 가격 구조, 납품 속도, 지원 범위, 팀의 전문성, 파트너십에 따라 전혀 다른 선택지가 된다. 월 구독만 가능한 경쟁자 옆의 건별 요금, 셀프서비스 도구 옆의 전문가 검수, 범용 제품 옆의 특정 업무 데이터 연결도 고유 속성이 될 수 있다. 중요한 것은 그 차이를 주장 대신 운영 사실로 쓰는 것이다. “지원이 훌륭하다”보다 “모든 문의에 담당자가 영업일 기준 네 시간 안에 답한다”가 강하다. “보안이 뛰어나다”보다 “고객 데이터가 지정한 지역 밖으로 나가지 않는다”가 강하다. 앞 문장은 평가이고 뒤 문장은 구조다. 구조는 증거를 남긴다. 응답 시간 기록, 감사 로그, 계약 조건, 제품 화면, 납품 과정처럼 고객이 확인할 흔적이 생긴다. 차별화 문장이 구체적일수록 마케팅팀 혼자 만들 수 없고, 실제 제품과 운영이 그 문장을 지탱해야 한다. ## 구체적이라고 모두 중요한 것은 아니다 그렇다면 숫자와 사실만 붙이면 모든 속성이 차별점이 되는가? 그렇지는 않다. 경쟁 대안에 없다는 사실과 고객이 중요하게 여긴다는 사실은 별개다. 버튼 색이 유일하고 보고서 항목이 하나 더 많아도 고객의 선택을 바꾸지 못하면 포지셔닝의 재료가 되기 어렵다. 고유 속성은 아직 가치가 아니다. 그것은 가치로 이어질 가능성이 있는 원인이다. “모든 수정 이력을 자동으로 남긴다”는 속성이 “누가 무엇을 바꿨는지 다시 확인할 수 있다”는 능력을 만들고, 그 능력이 “분쟁이 생겨도 근거를 복원할 수 있다”는 고객 가치로 이어질 때 비로소 구매 이유가 된다. 이 연결을 건너뛰면 데모는 특이한 기능으로 가득 차지만 고객은 그래서 무엇이 좋아지는지 알지 못한다. 반대로 가치만 말하고 속성을 생략하면 약속은 커지지만 왜 우리만 그 결과를 만들 수 있는지 설명하지 못한다. 좋은 포지셔닝은 관찰 가능한 사실과 고객이 원하는 변화를 인과로 묶는다. ## 진짜 차이는 대개 대가를 치른다 믿을 만한 차별점에는 종종 선택과 포기가 숨어 있다. 네 시간 안에 사람이 답하려면 지원 범위와 인력을 그렇게 설계해야 한다. 설정 없이 바로 쓰게 하려면 사용자가 바꿀 수 있는 항목을 줄여야 할 수 있다. 고객 데이터가 특정 환경을 벗어나지 않게 하려면 더 싼 공용 인프라를 포기해야 할 수 있다. 이 대가는 약점이 아니라 사실성을 높인다. 모든 고객에게 가장 싸고, 가장 빠르고, 가장 유연하며, 가장 안전하다는 주장은 내부 선택이 없는 문장이다. 무엇을 위해 무엇을 포기했는지가 보일 때 고객은 그 차이가 광고 문구가 아니라 제품과 사업의 구조라는 사실을 이해한다. AI 제품에서도 이 구분은 중요하다. “최신 AI를 사용한다”는 말은 모델을 빌려 쓰는 누구나 할 수 있다. 반면 결과마다 근거 문장을 남긴다, 위험도가 높은 요청은 사람에게 넘긴다, 고객별 수정이 다음 출력 규칙에 반영된다는 속성은 제품이 실제로 어떻게 작동하는지를 드러낸다. 모델 이름이 같아도 책임과 학습의 구조는 다를 수 있다. ## 차별점은 해자와도 다르다 오늘 고유하다고 영원히 모방하기 어려운 것은 아니다. 포지셔닝에 필요한 차별점과 장기 방어력인 해자를 같은 것으로 보면, 팀은 완벽하게 독점적인 기술을 찾느라 현재 고객이 선택하는 이유를 놓친다. 지금의 경쟁 대안보다 의미 있게 다른 사실이면 포지셔닝의 출발점이 될 수 있다. 다만 차이가 쉽게 복제된다면 계속 갱신해야 한다. 고객이 실제로 비교하는 대안이 바뀌었는지, 경쟁자가 같은 구조를 갖췄는지, 한때 중요했던 속성을 고객이 여전히 가치 있게 보는지를 다시 확인해야 한다. 차별화는 한 번 완성하는 슬로건이 아니라 현실의 차이를 정기적으로 읽는 작업이다. 제품 소개에서 형용사를 지워보면 많은 문장이 사라진다. 그 자리에 남아야 하는 것은 우리가 어떻게 다르게 작동하는지, 고객이 무엇으로 확인할 수 있는지, 그 차이가 어떤 변화를 만드는지다. 차별점은 더 크게 말하는 장점이 아니다. **대안과 나란히 놓았을 때도 남는 비대칭적인 사실**이다. --- 출발 소절: 마케팅 고전 워크북의 「경쟁 대안과 고유 속성」 중 ‘고유 속성: 대안은 못 하고 우리는 하는 것’. 주요 대조 출처: April Dunford, [A Quickstart Guide to Positioning](https://www.aprildunford.com/post/a-quickstart-guide-to-positioning?ref=zerodraftlab.com). 속성-능력-가치의 인과, 차별점에 내재한 trade-off, AI 제품과 해자로의 확장은 이 글의 해석입니다. ### 가장 강한 경쟁자는 현상 유지다 URL: https://zerodraftlab.com/status-quo-is-the-competitor/ Last updated: 2026-09-15T08:35:30.000Z 제품 팀이 경쟁 지도를 그리면 비슷한 기능을 가진 회사 이름이 줄지어 나온다. 고객이 보는 선택지는 훨씬 다르다. 새 소프트웨어를 사는 대신 엑셀을 계속 쓰거나, 담당자 한 명이 손으로 처리하거나, 외주 업체에 맡기거나, 문제가 더 커질 때까지 아무것도 하지 않을 수 있다. 그래서 포지셔닝에서 먼저 물어야 할 질문은 “우리와 닮은 회사는 어디인가”가 아니다. **“우리 제품이 내일 사라진다면 고객은 무엇으로 돌아갈 것인가”**다. April Dunford는 이를 경쟁사가 아니라 경쟁 대안이라고 부른다. 고객이 실제로 비교하는 선택지가 경쟁 대안이다. 같은 범주의 제품일 수도 있지만, 무료 도구와 수작업과 무행동일 수도 있다. 특히 기업 구매에서는 새 제품과 다른 제품의 대결보다 새 제품과 현상 유지의 대결이 더 자주 벌어진다. ## 비교 대상이 바뀌면 강점도 바뀐다 정산 소프트웨어가 다른 정산 SaaS와 경쟁한다고 생각하면 기능 수, 대시보드, 연동 범위를 비교한다. 그러나 고객이 지금 엑셀과 메신저로 월말 대사를 하고 있다면 중요한 차이는 달라진다. 수정 이력을 자동으로 남기는가, 이중 입력을 막는가, 마감 전에 누락을 알려주는가가 더 큰 가치가 된다. 경쟁 대안을 잘못 잡으면 차별화도 틀어진다. 직접 경쟁사보다 조금 나은 기능을 강조했는데 고객은 애초에 그 경쟁사를 검토하지 않았을 수 있다. 팀은 시장에서 이기려고 애썼지만, 고객의 실제 선택지에는 참가하지도 못한 셈이다. 가장 어려운 대안은 아무것도 하지 않기다. 무행동은 기능이 없어서 비교표에 잡히지 않지만 비용도, 학습도, 승인도 요구하지 않는다. 문제가 불편해도 아직 견딜 만하다면 고객에게는 충분히 합리적인 선택이다. ## 현상 유지는 공짜가 아니라 익숙하다 William Samuelson과 Richard Zeckhauser는 1988년 연구에서 사람들이 기존 선택을 불균형하게 유지하는 현상유지 편향을 실험과 실제 의사결정 자료에서 확인했다. 그러나 모든 현상 유지를 비합리적 고집으로 몰아가면 또 틀린다. 새 도구에는 구매 가격 밖의 비용이 붙는다. 데이터를 옮기고, 사용법을 배우고, 동료를 설득하고, 기존 업무를 잠시 멈추며, 실패했을 때 책임질 사람이 필요하다. 지금 방식이 불편해도 결과를 예측할 수 있다면, 불확실한 개선보다 확실한 불편을 택하는 것이 합리적일 수 있다. 따라서 제품은 새 상태가 더 좋다는 것만 증명해서는 부족하다. 지금 상태에서 새 상태로 건너가는 과정도 안전하다는 사실을 보여줘야 한다. 고객이 사는 것은 기능 묶음이 아니라 변화의 기대값이기 때문이다. 그렇다면 과장된 위기감을 만들지 않고 어떻게 현상 유지를 이길 수 있을까? 먼저 현상 유지가 고객에게 주는 가치를 인정해야 한다. 익숙한 절차는 느려도 예측 가능하고, 낡은 도구는 불편해도 이미 교육비를 냈으며, 아무것도 하지 않으면 적어도 새로운 실패의 책임은 생기지 않는다. 이 가치를 무시한 채 “왜 아직도 엑셀을 쓰세요”라고 묻는 순간 판매자는 고객의 현실을 모르는 사람이 된다. ## 변화의 이익보다 변화의 구조를 보여줘야 한다 현상 유지를 이기는 포지셔닝은 현재 방식의 숨은 비용과 전환 뒤의 편익만 대조하지 않는다. 둘 사이의 이동 비용까지 설명한다. 어떤 데이터가 옮겨지고, 기존 방식과 얼마나 병행할 수 있으며, 첫 가치를 언제 확인하고, 맞지 않으면 어디까지 되돌릴 수 있는지가 제품 설명의 일부가 되어야 한다. 그래서 좋은 증거도 결과 숫자 하나로 끝나지 않는다. 도입 전 어떤 수작업이 있었는지, 전환 기간에 무엇이 멈추지 않았는지, 첫 주에 어떤 오류를 발견했는지, 예외가 생겼을 때 누가 어떻게 처리했는지를 보여준다. 고객은 성공담만 읽는 것이 아니라 자신이 감당해야 할 변화의 모양을 계산한다. 이 관점은 가격의 의미도 바꾼다. 무료인 엑셀과 가격으로 싸우면 유료 제품은 항상 불리하다. 대신 반복 대사, 누락 확인, 담당자 의존, 감사 대응처럼 현재 방식이 소비하는 시간과 위험을 비교 기준으로 올려야 한다. 그렇다고 공포를 부풀리면 안 된다. 비용이 실제로 관찰되는 고객에게만 변화의 이유가 성립한다. ## AI 제품의 경쟁자는 다른 모델이 아닐 수 있다 AI 제품은 특히 경쟁 대안을 잘못 잡기 쉽다. 벤치마크 점수와 모델 가격을 비교하지만, 고객은 다른 AI 제품이 아니라 사람이 검토하는 기존 절차와 비교할 수 있다. 그 절차는 느려도 책임자가 보이고, 예외를 설명할 수 있으며, 사고가 나면 어디서 멈출지 안다. 이 경우 정확도 몇 퍼센트 개선만으로는 현상 유지를 이기지 못한다. 어떤 작업만 자동화하는지, 사람이 어디에서 승인하는지, 입력과 결과가 기록되는지, 실패를 감지하면 원래 절차로 돌아갈 수 있는지를 보여줘야 한다. AI의 성능보다 전환과 책임의 설계가 구매 이유가 된다. ## 경쟁사를 보지 말라는 뜻은 아니다 물론 고객의 최종 후보에 실제 경쟁 제품이 반복해서 등장한다면 그것도 경쟁 대안이다. 핵심은 경쟁사를 지우는 것이 아니라 회의실에서 만든 경쟁사 목록을 고객의 선택 기록으로 교체하는 데 있다. 같은 범주라는 이유로 경쟁자가 되는 것도 아니고, 제품이 아니라는 이유로 경쟁에서 빠지는 것도 아니다. 고객이 우리 없이 실제로 택할 선택지만 남겨야 한다. 그래야 무엇이 고유한지, 어떤 가치를 말해야 하는지, 어떤 증거가 필요한지가 현실 위에서 정해진다. 가장 강한 경쟁자는 더 많은 기능을 가진 회사가 아닐 수 있다. 이미 굴러가고 있고, 설명할 필요가 없으며, 바꾸지 않아도 오늘은 지나가는 현재의 방식이다. 포지셔닝은 경쟁사를 이기는 문장을 만드는 일이 아니라, 고객이 왜 지금의 방식을 떠나도 되는지 납득시키는 일에서 시작한다. --- 출발 소절: 마케팅 고전 워크북의 「경쟁 대안과 고유 속성」 중 ‘진짜 경쟁 대안: 고객이 우리 대신 쓰는 것’. 주요 대조 출처: April Dunford, [Positioning and Competition](https://www.aprildunford.com/post/positioning-and-competition?ref=zerodraftlab.com) 및 [A Quickstart Guide to Positioning](https://www.aprildunford.com/post/a-quickstart-guide-to-positioning?ref=zerodraftlab.com); William Samuelson·Richard Zeckhauser, [Status Quo Bias in Decision Making](https://doi.org/10.1007/BF00055564?ref=zerodraftlab.com), *Journal of Risk and Uncertainty* 1, 1988\. 전환 안전성·AI 책임 설계로의 확장은 이 글의 해석입니다. ### 테스트는 사고 전에 죽어야 한다 URL: https://zerodraftlab.com/tests-should-fail-before-production/ Last updated: 2026-09-15T08:35:31.000Z 탄광 카나리아에서 온 말이 있다. 광부들은 사람이 유독가스를 알아차리기 전에 새가 먼저 반응하기를 바라며 카나리아를 갱도 안으로 데려갔다. 새가 쓰러지면 아직 사람이 쓰러지지 않았다는 뜻이 아니라, 이제 곧 사람이 쓰러질 수 있다는 뜻이었다. 그래서 카나리아는 테스트용 신호의 오래된 이름이 되었다. 무언가가 실제 사고로 커지기 전에, 더 작고 더 민감한 대상이 먼저 이상을 드러내는 장치다. 다만 이 비유를 소프트웨어에 옮길 때는 한 가지를 정확히 해야 한다. 카나리아는 테스트 그 자체가 아니다. 카나리아는 전체 시스템에 변경을 적용하기 전에, 일부 운영 트래픽에 먼저 노출하는 방법이다. 테스트가 닫힌 환경에서 조건을 확인한다면, 카나리아는 아직 예측하지 못한 현실을 제한된 범위에서 만나게 한다. ## 카나리아는 정말 죽었을까 역사 속 카나리아는 단순히 희생되는 새였다는 이야기보다 조금 복잡하다. 앨버타 정부의 석탄산업 역사 자료는 카나리아의 작은 몸, 빠른 호흡, 높은 대사율이 특히 일산화탄소에 민감하게 반응하게 만들었다고 설명한다. 새가 횃대에서 떨어지면 광부들은 위험을 알아차리고 대피하거나 호흡기를 준비할 시간을 얻었다. [Science and Industry Museum의 자료](https://blog.scienceandindustrymuseum.org.uk/canary-resuscitator/?ref=zerodraftlab.com)에 따르면 이 방법은 19세기 말부터 쓰였고, John Haldane이 1896년 광산 폭발의 원인을 조사한 뒤 일산화탄소를 사람이 다치기 전에 감지할 방법을 찾으면서 체계화됐다. 산소통이 달린 우리도 있었다. 카나리아가 중독 증상을 보이면 우리를 닫고 산소를 공급해 되살리는 장치였다. 그러니 “죽어서 알려주는 새”라는 표현은 강력하지만 완전히 정확하지는 않다. 더 정확한 표현은 이렇다. 카나리아는 사람이 위험해지기 전에 먼저 상태가 망가지는, 작고 민감한 조기경보 장치였다. ## 소프트웨어의 카나리아는 테스트가 아니다 Google SRE의 [Canarying Releases](https://sre.google/workbook/canarying-releases/?ref=zerodraftlab.com)는 카나리잉을 변경의 일부이자 시간 제한적인 배포와 그 평가로 정의한다. 새 버전을 전체 운영 환경에 한 번에 배포하는 대신, 작은 사용자 집단이나 트래픽 일부에 먼저 보내고 기존 버전과 비교한다. 나쁘면 멈추거나 되돌리고, 괜찮으면 더 넓은 범위로 확장한다. Google의 SRE 책은 이 구분을 더 노골적으로 적는다. [카나리 테스트는 실제로는 테스트가 아니다](https://sre.google/sre-book/testing-reliability/?ref=zerodraftlab.com). 정해진 입력에 대해 결정론적인 조건을 확인하는 단위 테스트나 부하 테스트와 달리, 카나리는 예측하기 어려운 실제 운영 트래픽을 일부 받아보는 구조화된 사용자 수용에 가깝다. 이 차이는 중요하다. 테스트가 초록이라는 것은 특정 조건을 통과했다는 뜻이다. 카나리가 초록이라는 것은 아직 작은 현실 노출에서 큰 이상을 발견하지 못했다는 뜻이다. 둘은 서로 다른 종류의 증거를 만든다. ## 좋은 테스트는 먼저 실패해야 한다 테스트를 모두 통과시키는 것이 목적이라고 생각하면 빨간 테스트는 제거해야 할 장애물처럼 보인다. 그러나 테스트의 진짜 역할은 안심을 생산하는 것이 아니라, 안심할 수 없는 상태를 가능한 한 싸게 드러내는 것이다. 좋은 테스트는 개발자의 컴퓨터에서 실패한다. 배포가 끝난 뒤가 아니라, 변경사항이 아직 작고, 원인을 좁힐 수 있고, 되돌리는 비용이 낮을 때 실패한다. 실패가 빠를수록 테스트는 더 유용하다. 실패가 코드가 사용자에게 닿은 뒤에야 나타난다면 그것은 테스트의 실패라기보다 검증 경계가 너무 늦었다는 신호다. 그렇다고 모든 문제를 테스트가 미리 잡을 수 있다는 뜻은 아니다. 테스트 환경은 운영 환경과 다르고, 테스트가 다루지 않은 입력과 상태와 순서가 언제나 남는다. 그래서 테스트가 초록인 상태에서도 카나리아가 필요하다. 카나리아는 테스트가 놓친 현실의 조각을, 전체 사용자에게 노출하기 전에 가져온다. 테스트와 카나리아는 경쟁 관계가 아니다. 테스트는 변경을 작은 조건으로 쪼개어 확인하고, 카나리아는 변경을 작은 현실로 쪼개어 확인한다. 테스트가 코드의 결함을 먼저 죽인다면, 카나리아는 운영에서만 드러나는 결함을 먼저 죽인다. 여기서 “죽는다”는 말은 시스템을 망가뜨린다는 뜻이 아니다. 빨간 신호가 나왔을 때 전체 확산을 멈출 수 있다는 뜻이다. 실패가 사용자 전체의 장애가 되기 전에, 아직 되돌릴 수 있는 범위에서 관측되어야 한다. 그렇다면 작은 실패가 실제로 안전을 만들어내려면 무엇이 필요할까? 먼저 실패의 범위가 작아야 한다. Google SRE가 설명하듯 카나리아 트래픽이 전체의 작은 비율이면 전체 오류율에서는 문제가 희미하게 보일 수 있다. 그래서 카나리아와 기존 버전의 신호를 분리해서 비교해야 한다. 전체 평균이 초록이라고 카나리아가 건강하다고 말할 수는 없다. 다음으로 무엇을 보면 중단할지 미리 정해야 한다. HTTP 오류율, 지연시간, 특정 기능의 성공률, 데이터 무결성, 비용 급증처럼 시스템의 위험을 드러내는 신호가 있어야 한다. “이상하면 멈춘다”는 문장만으로는 부족하다. 어떤 차이를 이상으로 볼지, 얼마 동안 관찰할지, 누가 확산을 멈출지까지 운영 흐름에 들어 있어야 한다. 마지막으로 되돌릴 수 있어야 한다. [Martin Fowler가 설명하는 카나리 릴리스](https://martinfowler.com/bliki/CanaryRelease.html?ref=zerodraftlab.com)의 핵심은 느린 배포 자체가 아니라, 문제가 생기면 사용자를 이전 버전으로 다시 보낼 수 있다는 점이다. 롤백이 없거나 데이터 변경이 이미 공유 상태를 오염시킨다면, 작은 트래픽에 보냈다는 이유만으로 안전해지지 않는다. ## 카나리아가 죽지 않는 이유 카나리아가 항상 위험을 알려주는 것은 아니다. 첫째, 관측 신호가 잘못되면 카나리아는 살아 있는 것처럼 보인다. 전체 서비스의 오류율만 보면 1%의 카나리아 오류가 사라질 수 있다. 버전별·집단별로 신호를 나누지 않으면, 카나리아는 죽었는데 대시보드만 살아 있을 수 있다. 둘째, 카나리아가 실제 운영을 충분히 만나지 못할 수 있다. 사용자의 특정 지역, 계정 상태, 장바구니 조합, 결제 흐름, 데이터 크기에서만 발생하는 결함은 작은 트래픽에 우연히 포함되지 않을 수 있다. 카나리아는 확률을 낮추는 장치이지, 모든 경로를 통과했다는 증명서가 아니다. 셋째, 상태를 공유하는 시스템에서는 카나리아가 다른 사용자에게 영향을 줄 수 있다. Google SRE도 인공 트래픽과 트래픽 복제만으로는 캐시, 쿠키, 요청 어피니티, 변경 가능한 데이터의 위험을 충분히 재현하기 어렵다고 지적한다. 읽기 전용 경로에서 먼저 확인하거나, 부작용을 분리하거나, 되돌릴 수 없는 작업을 카나리아에서 막아야 하는 이유다. 그래서 카나리아는 작은 배포 비율만으로 완성되지 않는다. 작은 노출, 비교 가능한 기준선, 실패를 알아차릴 신호, 자동 또는 명시적인 중단, 빠른 롤백이 한 묶음이어야 한다. 이 중 하나라도 빠지면 카나리아는 조기경보 장치가 아니라 작은 규모의 장애가 된다. ## 테스트가 카나리아가 되는 순간 테스트를 카나리아처럼 설계한다는 말은 테스트를 일부러 불안정하게 만들자는 뜻이 아니다. 실패가 나왔을 때 누가 무엇을 알 수 있는지를 설계하자는 뜻이다. 커밋 단계의 테스트는 빠르게 실패하고 원인을 좁혀야 한다. 통합 단계의 테스트는 여러 경계가 합쳐졌을 때 생기는 문제를 찾아야 한다. 배포 직전의 카나리아는 실제 입력과 실제 시간과 실제 운영 제약을 조금 받아야 한다. 각 단계가 같은 초록불을 내는 것이 아니라, 다음 위험으로 넘어갈 자격을 서로 다른 방식으로 증명해야 한다. [Kubernetes의 공식 문서](https://kubernetes.io/docs/concepts/workloads/management/?ref=zerodraftlab.com)가 안정 버전과 카나리 버전을 나란히 두고 replica 비율로 트래픽을 조절하는 예시를 보여주는 것도 같은 이유다. 카나리는 영구적인 별도 제품이 아니다. 기존 버전과 비교되는 임시 상태이며, 충분히 확인되면 안정 트랙으로 승격되고 제거된다. 이 관점에서 테스트의 빨간불은 나쁜 소식이 아니다. 너무 늦게 켜지는 빨간불이 나쁜 소식이다. 개발 중에 실패하는 테스트, 일부 트래픽에서 실패하는 카나리, 전체 확산 전에 멈추는 배포는 모두 같은 운영 철학을 공유한다. 사고의 크기를 키우기 전에 실패의 크기를 줄이는 것이다. 탄광의 카나리아는 사람을 대신해 위험을 겪었다. 소프트웨어의 카나리아는 사용자를 대신해 변경을 조금 먼저 겪는다. 우리는 더 이상 새가 쓰러지기를 기다릴 필요는 없지만, 시스템이 조용히 초록색을 유지하는 것만으로 안전하다고 믿어서도 안 된다. **좋은 테스트는 사고가 난 뒤 성공을 증명하지 않는다. 사람이 알아차리기 전에 먼저 실패하고, 실패가 아직 작을 때 우리에게 돌아갈 길을 알려준다.** 참고: [Alberta’s Energy Heritage — Canaries in the Coal Mine](https://history.alberta.ca/EnergyHeritage/coal/the-early-development-of-the-coal-industry-1874-1914/early-methods-and-technology/canaries-in-the-coal-mine.aspx?ref=zerodraftlab.com); [Science and Industry Museum — The canary resuscitator](https://blog.scienceandindustrymuseum.org.uk/canary-resuscitator/?ref=zerodraftlab.com); [Google SRE Workbook — Canarying Releases](https://sre.google/workbook/canarying-releases/?ref=zerodraftlab.com); [Google SRE Book — Testing Reliability](https://sre.google/sre-book/testing-reliability/?ref=zerodraftlab.com); [Martin Fowler — Canary Release](https://martinfowler.com/bliki/CanaryRelease.html?ref=zerodraftlab.com); [Kubernetes — Canary deployments](https://kubernetes.io/docs/concepts/workloads/management/?ref=zerodraftlab.com). ### CI/CD는 테스트를 돌리는 일이 아니라 통합을 설계하는 일이다 URL: https://zerodraftlab.com/test-pyramid-ci-cost/ Last updated: 2026-09-15T08:35:31.000Z PR이 초록이면 안심한다. GitLab MR의 파이프라인이 통과해도 일단 다음 일로 넘어간다. 그런데 main에 합쳐진 뒤 통합 테스트가 깨지거나, 배포 태그에서 smoke가 실패하거나, 같은 커밋에 CI가 두 번씩 붙어 비용이 불어나면 질문이 달라진다. CI/CD는 테스트를 많이 돌리는 장치가 아니다. 변경이 다음 상태로 넘어갈 자격을 증명하는 흐름이다. PR과 MR은 코드를 제안하는 통합 지점이고, CI는 그 제안에 증거를 붙이며, CD는 증거가 쌓인 결과를 다음 환경으로 승격한다. GitHub Actions와 GitLab CI/CD의 YAML 문법은 다르다. GitHub에서는 workflow와 event를 쓰고, GitLab에서는 pipeline source와 rules를 쓴다. 하지만 둘 다 같은 질문을 품고 있다. 이 검사는 어느 변경에서, 어느 통합 상태를 대상으로, 얼마의 비용으로 실행되어야 하는가. ## 테스트 피라미드는 CI/CD의 시간표다 Mike Cohn의 테스트 피라미드는 단위 테스트를 많이 쓰고 통합 테스트를 그보다 적게 쓰며 E2E 테스트는 더 적게 두자는 그림으로 알려졌다. Ham Vocke는 [The Practical Test Pyramid](https://martinfowler.com/articles/practical-test-pyramid.html?ref=zerodraftlab.com)에서 이 개념을 실제 테스트 포트폴리오로 풀었고, Martin Fowler도 [TestPyramid](https://martinfowler.com/bliki/TestPyramid.html?ref=zerodraftlab.com)을 자동화 테스트의 균형을 생각하는 은유로 설명했다. 핵심은 테스트 개수의 비율이 아니다. 아래층은 빠르고 실패 원인을 좁게 알려주며, 위층은 실제 환경을 넓게 확인하는 대신 느리고 실패 해석에 더 많은 맥락을 요구한다는 차이다. 둘은 모두 필요하지만 같은 이벤트에 같은 빈도로 붙을 필요가 없다. Mike Wacker는 Google Testing Blog의 [Just Say No to More End-to-End Tests](https://testing.googleblog.com/2015/04/just-say-no-to-more-end-to-end-tests.html?ref=zerodraftlab.com)에서 E2E 중심 전략의 문제를 설명했다. 제품을 빌드하고 테스트 환경에 배포한 뒤 브라우저로 전체 시나리오를 지나야 결과를 얻을 수 있다. 실패가 나와도 원인이 어느 서비스와 어느 경계에 있는지 바로 알기 어렵다. 그의 결론은 E2E를 없애자는 것이 아니다. 같은 결함을 더 작고 빠른 테스트로 잡을 수 있다면 굳이 전체 시스템을 통과시키지 말자는 것이다. 커밋의 피드백은 작은 테스트가 담당하고, 통합된 결과의 신뢰는 더 큰 테스트가 담당해야 한다. [Software Engineering at Google 11장](https://abseil.io/resources/swe-book/html/ch11.html?ref=zerodraftlab.com)은 이 차이를 테스트의 크기와 범위로 나눈다. 무엇을 검증하는지가 scope라면, 몇 개의 프로세스와 머신과 네트워크와 시간이 필요한지가 size다. 한 함수만 확인해도 브라우저를 띄워야 한다면 큰 테스트일 수 있고, 여러 컴포넌트를 다뤄도 한 프로세스 안에서 끝나면 작은 테스트에 가까울 수 있다. 이 분류가 CI/CD의 시간표를 만든다. small은 변경마다 빠르게 실행하고, medium은 통합 경계에서 확인하며, large는 빌드·릴리스·배포 같은 상위 게이트에서 실행한다. 테스트가 좋은지 나쁜지만 결정하는 것이 아니라, 언제 실행해야 그 테스트의 정보 가치가 비용을 이기는지를 결정하는 셈이다. ## PR과 MR은 코드 저장소의 통합 계약이다 PR과 MR은 단순한 UI 이름 차이가 아니다. 둘 다 아직 기본 브랜치에 들어가지 않은 변경을 하나의 통합 단위로 묶고, 리뷰와 자동 검증과 승인을 모으는 경계다. 이 경계가 명확해야 CI의 결과도 의미를 갖는다. PR의 초록 불빛은 “이 브랜치가 지금까지의 조건을 만족한다”는 증거다. 그것은 “다음 커밋에서도 안전하다”거나 “main에 들어간 뒤에도 모든 시스템과 맞는다”는 보증이 아니다. MR의 성공 파이프라인도 마찬가지다. 소스 브랜치만 검증했는지, 타깃 브랜치와 합쳐진 임시 결과까지 검증했는지에 따라 증거의 범위가 달라진다. 따라서 CI를 설계할 때 먼저 테스트 목록을 쓰면 안 된다. PR/MR에서 무엇을 약속할지, main에서 무엇을 통합할지, tag에서 무엇을 실제 배포의 증거로 삼을지 먼저 나눠야 한다. 테스트는 그 계약을 구현하는 수단이다. ## GitHub Actions의 이벤트는 실행 그래프다 GitHub Actions workflow는 어떤 event가 일어날 때 실행된다. [공식 문서](https://docs.github.com/en/actions/reference/workflows-and-actions/events-that-trigger-workflows?ref=zerodraftlab.com)에서 \`pull\_request\`는 PR이 열리거나 소스 브랜치에 커밋이 추가되는 등의 활동을 기준으로 실행되고, \`push\`는 브랜치에 커밋이 올라가는 사건을 기준으로 실행된다. 이 둘을 한 workflow에 무심코 함께 걸면 같은 변경이 PR 레인과 브랜치 push 레인에서 모두 실행될 수 있다. GitHub는 여러 이벤트가 동시에 일어나면 여러 workflow run을 만들 수 있다고 설명한다. 기능적으로는 모두 초록인데, 비용과 대기 시간은 아무도 책임지지 않는 상태가 된다. 이벤트는 단순한 스위치가 아니라 실행 그래프다. \`pull\_request\`에는 리뷰 중인 변경의 빠른 검증을 붙이고, \`push\`의 main 조건에는 통합 결과의 풀 테스트를 붙이며, tag나 release에는 배포와 production smoke를 붙인다. merge queue를 쓰는 저장소라면 required check가 \`merge\_group\`에서도 보고되도록 별도 이벤트를 다뤄야 한다. 그렇지 않으면 PR에서는 통과한 체크가 큐에 들어간 뒤 다시 보고되지 않아 머지가 멈출 수 있다. ## GitLab MR pipeline은 브랜치와 병합 결과를 구분한다 GitLab의 [merge request pipeline](https://docs.gitlab.com/ci/pipelines/merge%5Frequest%5Fpipelines/?ref=zerodraftlab.com)은 MR을 만들거나 소스 브랜치에 새 커밋을 push할 때 실행할 수 있다. 기본 MR pipeline은 소스 브랜치의 내용만 실행한다. 타깃 브랜치와 실제로 합쳐졌을 때 문제가 없는지 보려면 merged results pipeline을 써야 한다. GitLab은 이 경우 두 브랜치를 합친 임시 커밋을 만들어 통합 결과를 검사한다. 여기서도 pipeline source가 계약의 일부가 된다. \`.gitlab-ci.yml\`의 \`rules\`나 \`workflow:rules\`가 \`CI\_PIPELINE\_SOURCE == "merge\_request\_event"\`를 명시해야 MR pipeline이 만들어진다. 반대로 branch pipeline과 MR pipeline을 모두 허용하는 규칙을 넓게 쓰면 같은 push에 파이프라인이 두 개 생길 수 있다. GitLab 공식 troubleshooting 문서가 이 문제를 따로 다루는 이유가 있다. 중복 pipeline은 단순한 화면 중복이 아니다. 같은 커밋에 runner를 두 번 점유하고, 결과가 서로 다른 상태처럼 보이며, 어떤 pipeline을 머지 조건으로 삼아야 하는지 흐리게 만든다. GitHub의 \`pull\_request\`와 \`push\` 조합, GitLab의 branch와 MR pipeline 조합은 문법은 달라도 같은 설계 실패를 만들 수 있다. 이제 테스트 피라미드와 PR/MR의 관계가 보인다. 테스트의 층은 실행 비용을 설명하고, PR/MR은 검증 결과가 모일 통합 지점을 설명한다. CI/CD는 이 둘을 연결하는 시간표다. 그렇다면 이 시간표를 실제 비용 사고와 GitHub·GitLab의 레인 설계에 어떻게 적용해야 할까? 먼저 같은 테스트를 어느 플랫폼에서 실행할지보다, 어느 상태의 코드를 증명하는지부터 고정해야 한다. 소스 브랜치의 가능성을 확인하는 검증과 타깃 브랜치와 합쳐진 결과를 확인하는 검증과 실제 배포된 환경을 확인하는 검증은 서로 다른 증거다. 한 레인의 초록을 다른 레인의 초록으로 빌려 쓰면 CI는 빨라 보여도 신뢰 경계가 사라진다. ## 비용 사고는 테스트보다 통합 지점에서 시작됐다 2026년 7월 20일 relic-works org에서는 Actions가 7월 1일부터 20일까지 11,462분을 사용했고, 그중 oblivseoul-sveltekit이 9,907분을 차지했다. 조직 전체 예산 상한은 $50에 도달했고, \`prevent\_further\_usage\`가 켜진 예산은 다른 저장소의 잡 시작까지 막았다. 결제 실패처럼 보이는 오류였지만 실제 원인은 비용 상한이라는 통합 인프라 정책이었다. 이 수치는 2026년 7월 20일 당시의 시점 고정 스냅샷이다. 이후 같은 날 API를 다시 읽었을 때 조직 Actions 누적 사용량은 11,587.6667분, 해당 저장소는 10,030.6667분으로 늘었고, Actions 예산은 $100이며 \`prevent\_further\_usage=true\`였다. 비용 수치를 사용할 때는 숫자보다 관측 시점을 함께 보존해야 한다. 저장소의 구조는 더 선명했다. \`ci\`가 230회 실행되었고 한 번에 약 16.5분이 걸렸다. 그중 E2E 단계가 871초로 88%를 차지했다. 55개 스펙을 desktop과 mobile 두 뷰포트로 매번 돌렸고, Lighthouse도 229회 실행되어 601분을 사용했다. 느리고 넓은 검증이 하루 11\~12개의 에이전트 커밋마다 반복되면, 테스트는 안전망이 아니라 생산비가 된다. GitHub Actions 공식 문서는 private repository의 hosted runner 사용량을 계정의 무료분과 과금분으로 계산하고 각 job의 분과 부분 분을 올림한다고 설명한다. 그래서 병렬 잡을 늘려 벽시계 시간을 줄이는 최적화와 총 과금 분을 줄이는 최적화는 다르다. 비용을 줄이려면 세 항, 즉 실행 빈도·잡 시간·잡 수 중 실제로 곱이 큰 항을 줄여야 한다. ## 세 플랫폼 레인은 사실 세 상태를 증명한다 oblivseoul-sveltekit의 [PR #307](https://github.com/relic-works/oblivseoul-sveltekit/pull/307?ref=zerodraftlab.com)은 GitHub Actions를 두 레인으로 나눴다. PR 커밋에서는 매출 경로와 컴플라이언스 가드와 계약 메타 스펙을 확인하는 8개 스모크를 남겼다. 리드폼 복구, 리드 스키마, 멱등성, CTA 링크, 리다이렉트, GA 호스트 가드가 여기에 들어간다. main에 합쳐지면 풀 Playwright 스위트와 비주얼 골든을 돌린다. Lighthouse도 pull request 트리거를 제거하고 main push와 수동 실행으로 옮겼다. 이것은 테스트를 삭제한 것이 아니라, 통합 결과가 생긴 뒤에야 의미가 생기는 측정과 시각 회귀 검사를 더 적합한 문으로 옮긴 것이다. 같은 구조를 GitLab MR에 옮기면 MR pipeline에는 빠른 계약·정적 검사·핵심 스모크를 둔다. merged results pipeline을 선택한 경우에는 타깃 브랜치와 합쳐진 임시 결과에서 통합 테스트와 넓은 회귀를 확인할 수 있다. default branch pipeline은 통합된 main의 산출물을 만들고, tag pipeline은 실제 배포와 production smoke를 증명한다. 이것은 GitHub와 GitLab의 공식 기본 설정이 아니라, 같은 위험을 각 플랫폼의 이벤트 모델에 맞춰 배치한 설계다. GitHub에서는 \`pull\_request\`, \`push\`, 필요하면 \`merge\_group\`의 관계를 정리하고, GitLab에서는 \`CI\_PIPELINE\_SOURCE\`, \`workflow:rules\`, merged results의 관계를 정리한다. 플랫폼이 바뀌어도 상태의 순서는 바뀌지 않는다. ## 중복 pipeline은 CI/CD의 아이스크림 콘이다 테스트 피라미드가 E2E의 비율만 말하는 것은 아니었던 것처럼, CI 비용도 단순히 “잡이 오래 걸린다”의 문제가 아니다. 소스 브랜치와 MR 결과를 둘 다 검사하고, PR과 push를 둘 다 검사하고, main과 tag에서 같은 풀 스위트를 다시 검사하면 하나의 변경이 여러 증거처럼 복제된다. GitLab은 \`workflow:rules\`로 어떤 종류의 pipeline을 만들지 먼저 제한하라고 안내한다. GitHub도 여러 이벤트가 동시에 발생하면 여러 run이 생길 수 있으므로 event와 branch filter를 의도적으로 설계해야 한다. 중복을 막는 일은 CI 최적화의 마지막 손질이 아니라, 어떤 결과가 통합을 허용하는지 결정하는 계약의 일부다. 여기서 Owner가 고정한 게이트는 비용과 무관하게 남아야 한다. PR마다 유지하기로 한 coverage-gate, 컴플라이언스 가드, 매출 경로 스모크는 작은 형태로라도 가장 빠른 통합 경계에 있어야 한다. 반대로 Lighthouse와 비주얼 골든처럼 통합 결과에서 한 번 확인해도 되는 검사는 머지 뒤로 미룰 수 있다. 줄이는 것은 방어선이 아니라 중복과 잘못된 타이밍이다. ## CI는 증거를 만들고 CD는 증거를 승격한다 CI와 CD를 하나의 거대한 pipeline으로 붙이면 모든 단계가 모든 변경에 반응해야 한다는 압박이 생긴다. 그러면 PR 하나가 사실상 배포 후보처럼 다뤄지고, 아직 설계가 바뀌는 코드에 가장 비싼 검증이 붙는다. 더 단순한 모델은 상태를 나누는 것이다. PR/MR은 변경이 리뷰 가능한지 증명한다. main은 여러 변경이 함께 작동하는지 증명한다. tag나 release는 이 통합 결과를 배포할 수 있는지 증명한다. production smoke는 실제 사용자 환경에서 방금 승격한 산출물이 맞는지 증명한다. GitHub의 protected branch가 required status checks와 리뷰를 머지 조건으로 삼고, GitLab의 MR pipeline과 merged results가 머지 전 검증을 담당하는 이유도 이 경계 때문이다. 머지는 단순히 브랜치를 합치는 Git 명령이 아니라, 한 상태의 증거를 다음 상태의 책임으로 넘기는 행위다. 좋은 CI/CD는 가장 많은 테스트를 가장 빨리 돌리는 시스템이 아니다. 변경의 위험도가 올라가는 지점마다 그 위험에 맞는 증거를 하나씩 요구하는 시스템이다. 작은 검사는 커밋과 PR/MR에, 넓은 검사는 main과 merged result에, 배포 검사는 tag와 production에 둔다. **PR과 MR은 코드를 보여주는 페이지가 아니라 통합 계약이고, CI는 초록불을 만드는 장치가 아니라 증거를 생산하는 공정이며, CD는 그 증거를 다음 환경으로 승격하는 책임이다.** 이 세 가지를 분리하면 GitHub Actions와 GitLab CI/CD는 경쟁 제품이 아니라 같은 운영 원리를 구현하는 서로 다른 표면으로 보인다. --- 주요 출처: Ham Vocke, [The Practical Test Pyramid](https://martinfowler.com/articles/practical-test-pyramid.html?ref=zerodraftlab.com); Martin Fowler, [TestPyramid](https://martinfowler.com/bliki/TestPyramid.html?ref=zerodraftlab.com); Mike Wacker, [Just Say No to More End-to-End Tests](https://testing.googleblog.com/2015/04/just-say-no-to-more-end-to-end-tests.html?ref=zerodraftlab.com); Google, [Software Engineering at Google, Chapter 11: Testing Overview](https://abseil.io/resources/swe-book/html/ch11.html?ref=zerodraftlab.com); GitHub, [Events that trigger workflows](https://docs.github.com/en/actions/reference/workflows-and-actions/events-that-trigger-workflows?ref=zerodraftlab.com), [Triggering a workflow](https://docs.github.com/en/actions/how-tos/write-workflows/choose-when-workflows-run/trigger-a-workflow?ref=zerodraftlab.com), [Managing protected branches](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches?ref=zerodraftlab.com); GitLab, [Merge request pipelines](https://docs.gitlab.com/ci/pipelines/merge%5Frequest%5Fpipelines/?ref=zerodraftlab.com), [Merged results pipelines](https://docs.gitlab.com/ci/pipelines/merged%5Fresults%5Fpipelines/?ref=zerodraftlab.com), [Troubleshooting merge request pipelines](https://docs.gitlab.com/ci/pipelines/mr%5Fpipeline%5Ftroubleshooting/?ref=zerodraftlab.com), [Specify when jobs run with rules](https://docs.gitlab.com/ci/jobs/job%5Frules/?ref=zerodraftlab.com); 사례: [oblivseoul-sveltekit PR #307](https://github.com/relic-works/oblivseoul-sveltekit/pull/307?ref=zerodraftlab.com). 11,462분·9,907분·$50·86%는 2026-07-20 시점 고정 스냅샷이며, 후속 API 수치는 별도로 구분했다. ### 정답을 틀리는 것보다 문제의 종류를 틀리는 게 더 위험하다 URL: https://zerodraftlab.com/right-answer-wrong-domain/ Last updated: 2026-09-15T08:35:32.000Z 회의가 길어지면 조직은 보통 정보가 부족하다고 생각한다. 데이터를 더 모으고, 전문가를 더 부르고, 보고서의 경우의 수를 늘린다. 그런데 아무리 분석해도 결론이 나지 않는다면 부족한 것은 정보가 아니라 문제를 보는 방식일 수 있다. 어떤 문제는 분석하면 답을 찾을 수 있다. 어떤 문제는 행동하기 전에는 무엇이 답인지 알 수 없다. 둘 다 어렵지만 같은 종류의 어려움은 아니다. 이 차이를 무시하면 유능한 전문가와 충분한 데이터가 오히려 결정을 늦춘다. Dave Snowden과 Mary Boone이 2007년 *Harvard Business Review*에 소개한 Cynefin 프레임워크는 의사결정의 출발점을 바꾼다. 먼저 답을 찾는 대신 지금 다루는 상황이 어떤 시스템에 속하는지 묻는다. 현재 공식 설명은 이를 명료한 문제, 복합적인 문제, 복잡한 문제, 혼돈, 그리고 아직 어느 영역인지 알 수 없는 혼란으로 구분한다. ## 어려운 문제에도 서로 다른 문법이 있다 명료한 문제에서는 원인과 결과가 반복된다. 주문서의 누락 항목을 확인하거나 정해진 소독 절차를 수행하는 일처럼 규칙과 모범사례가 잘 작동한다. 여기서 매번 창의적인 토론을 여는 것은 신중함이 아니라 낭비다. 복합적인 문제는 구성요소가 많고 답을 찾기 어렵지만, 충분히 분석하면 원인과 결과를 밝혀낼 수 있다. 건물의 구조 안전성을 계산하고, 예상 거래량에 맞춰 서버 용량을 설계하고, 계약의 법적 위험을 검토하는 일이 그렇다. 답이 하나가 아닐 수 있어도 전문지식과 분석은 선택지를 크게 줄인다. 복잡한 문제는 다르다. 신제품의 어떤 기능이 습관을 만들지, 조직문화 개편이 실제 협업을 바꿀지, 새로운 가격이 고객의 인식을 어떻게 움직일지는 사전에 완전히 계산하기 어렵다. 원인과 결과가 행위자들의 반응 속에서 함께 만들어지기 때문이다. 여기서는 분석한 뒤 실행하는 것이 아니라, 작게 시도하고 반응을 관찰하며 다음 행동을 정해야 한다. 혼돈에서는 그 작은 실험조차 먼저가 아니다. 서비스 전체 장애나 대량 품질사고처럼 피해가 번지고 있다면 원인 분석보다 안정화가 앞선다. 우선 멈추고, 격리하고, 질서를 만든 다음에야 상황을 다른 영역으로 옮겨 판단할 수 있다. 이 분류의 가치는 이름을 외우는 데 있지 않다. 같은 조직이 서로 다른 영역에 같은 의사결정 방식을 강요하고 있다는 사실을 드러내는 데 있다. 예를 들어 신제품 출시도 하나의 문제처럼 보이지만 실제로는 섞여 있다. 개인정보 처리와 결제 정합성은 전문가가 검증해야 하고, 고객이 어떤 메시지에 반응할지는 시장에서 작게 시험해야 한다. 앞의 일에 실험을 쓰거나 뒤의 일에 정답형 분석을 쓰는 순간, 같은 프로젝트 안에서도 방법과 문제가 어긋난다. ## 분석할 수 없는 것을 분석하면 확신만 늘어난다 복잡한 문제를 복합적인 문제로 착각하면 조직은 예측 정확도를 높이겠다는 명목으로 회의를 반복한다. 아직 시장에 존재하지 않는 고객 반응을 스프레드시트 안에서 찾고, 실행하기 전에는 생기지 않을 학습을 전문가의 의견으로 대신한다. 보고서는 더 정교해지지만 불확실성은 줄지 않는다. 반대 오류도 비싸다. 복합적인 문제를 복잡한 문제로 취급하면 이미 축적된 전문지식을 무시하고 모든 것을 실험한다. 구조 계산, 보안 설정, 세무 처리처럼 분석 가능한 일까지 “일단 해보자”로 접근하면 학습이 아니라 사고가 남는다. 실험은 전문성을 대신하는 태도가 아니라, 인과관계를 미리 알 수 없는 영역에서 쓰는 방법이다. **좋은 의사결정은 정답을 빨리 고르는 능력이 아니라, 정답을 찾는 방법부터 바꿀 수 있는 능력이다.** 명료한 문제에는 절차를, 복합적인 문제에는 전문가 분석을, 복잡한 문제에는 안전한 탐색을, 혼돈에는 즉각적인 안정화를 써야 한다. 그렇다면 하나의 프로젝트가 여러 종류의 문제를 동시에 품고 있을 때는 무엇을 기준으로 움직여야 할까? 그때 필요한 것은 프로젝트 전체에 이름표 하나를 붙이는 일이 아니라, 결정을 더 작은 단위로 나누는 일이다. 같은 서비스 장애 안에도 지금 당장 트래픽을 차단해야 하는 혼돈, 로그를 분석해 원인을 찾는 복합성, 재발 방지 행동이 현장에서 작동할지 시험하는 복잡성, 이후 런북으로 고정할 수 있는 명료성이 함께 존재한다. ## 영역은 성숙도 등급이 아니라 현재의 관계다 Cynefin을 낮은 단계에서 높은 단계로 올라가는 성숙도 모델처럼 읽으면 또 하나의 오해가 생긴다. 학습이 쌓이면 복잡했던 일이 분석 가능한 일이 되고, 마침내 표준 절차로 굳어질 수는 있다. 그러나 모든 문제가 혼돈에서 출발해 한 방향으로만 이동하는 것은 아니다. 익숙한 절차도 환경이 바뀌면 다시 불안정해진다. 규제 변경, 새로운 경쟁자, 기술 전환, 인력 구성의 변화는 어제의 모범사례를 오늘의 위험으로 만들 수 있다. 특히 명료한 영역의 절차를 맹신하면 변화 신호를 무시한 채 혼돈으로 떨어질 수 있다. 표준화는 학습의 종착지가 아니라 조건이 유지되는 동안만 유효한 압축이다. 따라서 분류의 단위는 “우리 회사는 복잡하다” 같은 거대한 선언이 되어서는 안 된다. 지금 결정하려는 가격, 기능, 사고 대응, 채용, 계약을 각각 놓고 원인과 결과를 사전에 알 수 있는지 물어야 한다. 알 수 있다면 분석하고, 상호작용 뒤에야 드러난다면 작고 가역적인 행동으로 배워야 한다. ## 리더의 역할도 영역마다 달라진다 명료한 문제에서 리더는 좋은 절차가 지켜지게 만들면 된다. 복합적인 문제에서는 서로 다른 전문가의 분석을 비교하고 판단 기준을 분명히 해야 한다. 복잡한 문제에서는 정답을 선언하는 대신 여러 작은 탐색이 안전하게 벌어지도록 경계를 설계하고, 예상 밖의 신호를 포착해야 한다. 혼돈에서는 토론을 잠시 멈추고 피해를 제한할 명령을 내려야 한다. 문제는 리더가 자신에게 익숙한 한 가지 방식만 반복할 때 생긴다. 분석에 강한 리더는 모든 상황을 복합적인 문제로 만들고, 창업가형 리더는 모든 문제를 실험으로 바꾸며, 위기 대응에 익숙한 리더는 평시에도 명령을 남발한다. 능력의 부족보다 능력의 과잉 적용이 더 자주 조직을 망친다. ## AI는 영역 착각을 더 그럴듯하게 만든다 AI는 명료하고 복합적인 문제에서 특히 강하다. 규칙을 반복 적용하고, 많은 문서를 비교하고, 가능한 원인을 빠르게 좁힐 수 있다. 문제와 평가 기준이 분명할수록 기계가 만드는 속도와 일관성은 큰 이점이 된다. 그러나 복잡한 문제에 AI를 넣는 순간 인과관계까지 계산 가능해지는 것은 아니다. AI는 실험안을 만들고 약한 신호를 정리하며 관찰 범위를 넓힐 수 있지만, 아직 일어나지 않은 시장 반응을 확정된 답으로 바꾸지는 못한다. 오히려 유창한 보고서가 “분석하면 알 수 있다”는 착각을 강화할 수 있다. 그래서 AI 시대의 중요한 구분은 인간과 기계 중 누가 더 똑똑한가가 아니다. 지금 하는 일이 규칙의 실행인지, 전문가 분석인지, 현실과 상호작용해야만 배울 수 있는 탐색인지 먼저 구별하는 것이다. 복잡한 영역에서 AI의 역할은 예언자가 아니라 더 싸고 빠른 탐색 보조자에 가깝다. ## 전략은 방법을 바꾸는 속도다 조직이 틀린 답을 고르는 것은 피할 수 없다. 더 위험한 실패는 문제의 종류를 틀린 채 같은 방법을 오래 밀어붙이는 것이다. 분석으로 배울 수 없는 것을 계속 분석하고, 전문가가 풀 수 있는 것을 계속 실험하며, 위기 속에서 합의를 기다리는 동안 손실은 커진다. Cynefin은 세상을 다섯 칸에 정리하는 표가 아니다. 우리가 좋아하는 의사결정 방식이 지금 현실과 맞는지 의심하게 만드는 장치다. 좋은 전략은 언제나 정답을 아는 상태가 아니라, 현실이 달라졌을 때 질문과 행동의 문법을 바꾸는 능력에서 시작한다. --- 주요 출처: 김병호, [케네빈 프레임워크(Cynefin framework)](https://brunch.co.kr/@kbhpmp/150?ref=zerodraftlab.com); David J. Snowden·Mary E. Boone, [A Leader’s Framework for Decision Making](https://hbr.org/2007/11/a-leaders-framework-for-decision-making?ref=zerodraftlab.com); The Cynefin Co, [The Cynefin Framework](https://thecynefin.co/about-us/about-cynefin-framework/?ref=zerodraftlab.com), [Enhancing Decision Making with the Cynefin Framework](https://thecynefin.co/effective-decision-making-support-tool/?ref=zerodraftlab.com), [Where Machines Work Best and Why Humans Remain Indispensable](https://thecynefin.co/cynefin-framework-lens-machines-human-work-together/?ref=zerodraftlab.com). 현재 공식 표기의 Clear와 Confused/Aporetic을 반영했으며, 원문을 복제하지 않고 의사결정 방식과 AI 적용 경계로 재구성했습니다. ### 골든 스냅샷은 누구의 이론인가 URL: https://zerodraftlab.com/golden-snapshot-origin/ Last updated: 2026-09-15T08:35:33.000Z “골든 스냅샷은 누구의 이론인가?”라는 질문은 화면 테스트가 실패했을 때 자주 나온다. 기준 이미지가 하나 있고, 현재 화면을 그 이미지와 비교한다. 다르면 CI가 빨간불을 켠다. 이 흐름은 단순해서 누군가 한 번에 발명한 단일 이론처럼 보이지만, 실제 계보는 조금 다르다. ## 가장 가까운 원조는 Michael Feathers다 현재 동작을 먼저 기록하고, 코드를 바꾼 뒤 그 동작이 달라졌는지를 감시하는 생각은 화면보다 훨씬 오래됐다. Michael Feathers는 2002년 글에서 레거시 코드를 안전하게 바꾸기 위한 *test covering*을 설명했다. 여기서 테스트의 기준은 외부에서 정한 이상적인 정답이 아니라, 시스템이 어제 실제로 하던 동작이다. 그 기준을 먼저 붙잡은 다음 코드를 바꾸고, 변화가 생기면 의도된 것인지 판단한다. [Feathers의 2002년 원문](https://objectmentor.com/resources/articles/WorkingEffectivelyWithLegacyCode.pdf?ref=zerodraftlab.com)에 이 구조가 남아 있다. 이후 이 방식은 *characterization test*라는 이름으로 널리 설명됐다. 이 이름을 Feathers가 소개했다는 동시대 설명도 남아 있다. 특성화 테스트는 “코드가 무엇을 해야 하는가”보다 “지금 실제로 무엇을 하는가”를 기록한다. 그래서 이 테스트는 처음부터 정답을 증명하는 장치라기보다, 변경으로 인해 행동이 달라졌다는 사실을 알려주는 안전망이다. [Alberto Savoia의 2007년 정리](https://www.artima.com/weblogs/viewpost.jsp?thread=198296&ref=zerodraftlab.com)는 Feathers의 용어와 알고리즘을 직접 설명한다. ## 스냅샷은 그 생각을 다른 출력에 적용한 이름이다 출력이 숫자나 문자열이면 그 값을 저장한다. 출력이 HTML 트리나 화면 이미지면 그 결과를 snapshot 또는 golden master로 저장한다. 핵심은 파일 확장자가 아니라 비교 구조다. 처음 승인한 결과를 기준으로 삼고, 다음 실행의 결과가 달라졌는지 확인한다. 웹 UI 쪽에서 이 방식을 대중화한 중요한 전환점은 Jest다. Jest 팀은 2016년 React 트리 snapshot testing을 공개하면서, 컴포넌트를 렌더링하고 그 결과를 파일로 저장한 뒤 다음 실행과 비교하는 흐름을 설명했다. 당시 기능을 만든 사람으로 Ben Alpert와 Cristian Carlesso를 명시했다. [Jest 14 공식 글](https://archive.jestjs.io/blog/2016/07/27/jest-14?ref=zerodraftlab.com)에 이 기록이 있다. 웹 화면의 PNG 비교는 Playwright가 제공하는 visual comparison으로 구현할 수 있다. Playwright는 첫 실행에서 기준 스크린샷을 만들고, 다음 실행부터 `toHaveScreenshot()`으로 현재 화면과 비교한다. 브라우저와 실행 환경이 달라지면 글꼴과 렌더링이 달라질 수 있으므로 같은 환경에서 기준 이미지를 만들어야 한다. [Playwright 공식 문서](https://playwright.dev/docs/test-snapshots?ref=zerodraftlab.com)가 이 동작과 갱신 명령을 명시한다. 따라서 “골든 스냅샷 이론은 누구 것인가?”에 대한 가장 정확한 답은 이렇다. 뿌리가 되는 변경 안전성 개념을 특성화 테스트로 정리한 사람은 Michael Feathers다. Jest와 Playwright는 그 계보를 각각 UI 출력과 화면 이미지에 적용한 도구다. “골든 스냅샷”이라는 표현 자체를 한 사람이 독점하는 정식 학파나 단일 발명품은 아니다. 하지만 이 역사를 실제 개발에 가져오면, 기준 이미지를 어떻게 취급할지라는 더 까다로운 문제가 남는다. 그 문제의 핵심은 기준 이미지가 정답지가 아니라 변경 감지기라는 점이다. 누군가 정상이라고 승인한 결과를 저장하고, 그 뒤의 차이를 알려줄 뿐이다. 처음 저장한 화면에 이미 잘못된 문구나 잘못된 링크가 있었다면, 스냅샷은 그 오류도 금색으로 보존한다. ## 기준 이미지는 정답지가 아니라 변경 감지기다 이 점은 변경 속도가 빠른 개발에서 특히 중요하다. 변경을 빠르게 만들 수 있어도, 어떤 변경이 의도된 것인지 결정하는 권한은 별개다. 링크의 목적지만 바꾸고 버튼의 크기와 위치를 유지하는 작업은 행동 변경이다. 그 경우에는 href와 클릭 가능 여부를 기능 테스트로 확인하고, 화면 기준은 그대로 둔다. 반대로 버튼을 회색으로 보이게 하거나 레이아웃을 바꾸는 요구라면 시각 변경이다. 그때만 해당 URL, 언어, viewport의 기준 이미지를 새로 승인한다. 그래서 스냅샷 갱신은 “테스트를 초록으로 만드는 정리 작업”이 아니다. 현재 기준을 폐기하고 새 기준을 채택하는 작은 릴리스 승인이다. 전체 폴더를 한꺼번에 다시 생성하는 명령은 편하지만, 그 안에 의도하지 않은 회귀도 함께 저장한다. Jest 문서도 스냅샷을 코드처럼 커밋하고 리뷰하라고 하며, 실패 원인을 확인하지 않은 채 재생성하는 습관을 경계한다. ## 일반적인 운영 원칙 시각 비교 실패가 많이 발생했다고 해서 기준 이미지가 특별히 권위 있어서인 것은 아니다. 하나의 UI 변경이 여러 경로와 viewport에 동시에 흔적을 남겼을 수 있다. 이 상황에서 해야 할 일은 PNG를 많이 바꾸는 것이 아니라, 실패를 네 가지 질문으로 분해하는 것이다. 어느 URL인가. 어느 언어인가. 어느 viewport인가. 실제 요구가 화면 변경인가, 아니면 동작 변경인가. 그 질문에 답한 뒤에만 기준을 갱신한다. 화면 모양을 유지해야 하는 행동 변경이면 기능 테스트를 보강하고 기준 이미지는 유지한다. 비활성 상태의 색과 모양처럼 시각 변경이 요구되면 그 범위의 이미지만 같은 실행 환경에서 갱신한다. 갱신한 이미지는 코드와 함께 리뷰하고, 검토자는 “현재 화면이 바뀌었다”가 아니라 “요청된 변경만 남아 있는가”를 본다. 이렇게 보면 골든 스냅샷은 낡은 화면을 지키는 종교가 아니다. 변경의 종류를 분리하고, 결과를 사람이 승인 가능한 단위로 줄이는 기록 장치다. Feathers의 특성화 테스트가 코드 행동을 붙잡았다면, Playwright의 화면 기준은 그 원리를 픽셀과 렌더링 환경까지 확장한 셈이다. 무엇을 금색으로 남길지는 도구가 아니라 변경을 승인하는 사람과 리뷰어가 결정해야 한다. ## 출처 - [Michael Feathers, Working Effectively With Legacy Code (2002)](https://objectmentor.com/resources/articles/WorkingEffectivelyWithLegacyCode.pdf?ref=zerodraftlab.com) - [Alberto Savoia, Working Effectively With Characterization Tests (2007)](https://www.artima.com/weblogs/viewpost.jsp?thread=198296&ref=zerodraftlab.com) - [Jest 14.0: React Tree Snapshot Testing (2016)](https://archive.jestjs.io/blog/2016/07/27/jest-14?ref=zerodraftlab.com) - [Playwright, Visual comparisons](https://playwright.dev/docs/test-snapshots?ref=zerodraftlab.com) ### AI가 콘텐츠를 무한히 만들수록 브랜드 코드는 더 비싸진다 URL: https://zerodraftlab.com/ai-makes-brand-codes-more-valuable/ Last updated: 2026-09-15T08:35:33.000Z 생성형 AI는 콘텐츠 제작비를 낮췄다. 한 사람이 하루에 만들던 이미지와 문안을 이제 수십 가지 비율, 언어, 후크로 변형할 수 있다. 제작량만 보면 모든 브랜드가 작은 스튜디오를 갖게 된 셈이다. 하지만 더 많이 만들 수 있다는 사실이 더 잘 기억된다는 뜻은 아니다. 같은 모델과 비슷한 프롬프트를 쓰면 매끈한 조명, 익숙한 구도, 무난한 문장도 함께 늘어난다. 품질의 바닥은 올라가지만 결과물 사이의 거리는 좁아진다. 콘텐츠가 풍부해질수록 어느 브랜드가 만들었는지 구별하는 일은 오히려 어려워진다. **AI가 콘텐츠를 무한히 만들수록 브랜드 코드는 더 비싸진다.** 희소해지는 것은 이미지나 문장이 아니라 이름과 로고를 가려도 한 브랜드를 떠올리게 하는 기억의 단서이기 때문이다. ## 2026년의 병목은 생산보다 식별이다 IAB의 2026년 미국 광고 구매자 조사에는 이 역설이 드러난다. 구매자들은 AI 콘텐츠의 범람 속에서 신뢰받는 인간의 스토리텔링과 높은 주목도를 주는 차별화를 우선한다고 답했다. AI를 쓰지 않겠다는 선언이 아니다. AI가 생산의 기본 도구가 될수록 사람의 신뢰와 브랜드의 차이가 더 중요한 구매 이유가 된다는 신호다. Kantar의 2026년 전망도 비슷한 문제를 보여준다. 크리에이터 콘텐츠를 늘리려는 마케터는 많지만, Kantar 분석에서 브랜드와 강하게 연결되는 크리에이터 콘텐츠는 27%에 불과했다. 콘텐츠가 주목을 받아도 누가 말했는지 남지 않으면 크리에이터의 자산은 늘고 브랜드의 기억은 늘지 않을 수 있다. 한국 소비자 태도 조사에서도 브랜드의 고유성은 사라지지 않았다. Criteo가 2026년 한국 소비자 1,107명을 포함해 진행한 조사에서 한국 응답자의 76%는 AI 환경에서도 브랜드의 정체성과 고유한 존재감이 중요하다고 답했다. 이는 실제 구매 효과를 증명하는 수치가 아니라 설문 응답이다. 그래도 AI가 브랜드를 무의미하게 만든다는 주장에는 반대 방향의 신호다. ## 브랜드 코드는 디자인 규칙이 아니라 기억 자산이다 브랜드 코드는 로고 사용법이나 색상값의 목록과 다르다. 특정 색의 조합, 반복되는 형태, 캐릭터, 사진의 구도, 문장의 리듬, 소리, 제품을 보여주는 방식처럼 이름 없이도 한 브랜드를 불러오는 신호다. Ehrenberg-Bass Institute는 이런 distinctive asset의 힘을 얼마나 널리 알려졌는지와 얼마나 한 브랜드에 고유하게 연결되는지로 설명한다. 따라서 가이드에 적혀 있다고 자산이 되는 것은 아니다. 유행하는 파스텔 색, 모두가 쓰는 산세리프 글꼴, AI가 잘 만드는 영화 같은 조명은 세련돼 보일 수 있지만 한 브랜드만 가리키지 않는다. 반대로 다소 낯설어도 반복 노출 뒤 특정 브랜드로 정확히 연결되는 신호는 기억 자산이 될 수 있다. AI는 이 차이를 더 크게 만든다. 생성 모델은 변형을 빠르게 만들지만 무엇을 끝까지 지켜야 하는지는 스스로 결정하지 못한다. 매번 새로운 스타일을 탐색하게 두면 결과물 하나하나는 좋아 보여도 브랜드의 기억은 매번 처음부터 다시 시작한다. 생산 효율이 브랜드 망각의 속도를 높이는 셈이다. 브랜드 코드의 역할은 모든 콘텐츠를 똑같이 만드는 것이 아니다. 수백 개의 변형이 서로 다른 상황과 사람에게 말을 걸면서도 같은 발신자로 인식되게 하는 것이다. 콘텐츠가 무한해질수록 이 소수의 반복 가능한 신호는 제작 규칙을 넘어 기억의 계약이 된다. 그렇다면 브랜드는 무엇을 고정하고 무엇을 AI에 맡겨야 할까. 그리고 클릭률이 잘 나온다는 이유로 평범한 스타일을 고유 자산이라고 착각하지 않으려면 무엇을 측정해야 할까. 먼저 고정할 것은 가이드에서 가장 예쁜 요소가 아니라 이미 사람 머릿속에서 한 브랜드에 고유하게 연결되는 소수의 신호다. 그런 신호가 없다면 후보를 정해 반복하고 검증해야 한다. 메시지, 채널, 비율, 제품 장면은 바꿔도 되지만 그 변형을 한 발신자로 묶어 주는 단서는 남겨야 한다. ## 가이드, 실행 규칙, 기억 자산을 분리한다 브랜드 가이드는 조직이 무엇을 사용해도 되는지 말한다. 실행 규칙은 특정 채널에서 요소를 어떻게 조합할지 말한다. 기억 자산은 소비자가 실제로 무엇을 보고 그 브랜드를 떠올리는지 보여준다. 세 문서는 겹칠 수 있지만 같은 것은 아니다. 가이드에는 오래전 정한 색과 서체가 남아 있어도 사람들은 그것을 경쟁사와 헷갈릴 수 있다. 내부 구성원이 사랑하는 캐릭터도 외부에서는 알려지지 않았을 수 있다. 반대로 광고마다 반복해 온 제품 실루엣이나 짧은 소리가 문서에 제대로 기록되지 않았는데도 강한 연결을 갖고 있을 수 있다. 내부의 의도보다 외부의 기억을 먼저 측정해야 하는 이유다. Ehrenberg-Bass가 구분하는 인지도와 고유성은 이때 유용하다. 많은 사람이 알아보지만 여러 브랜드를 함께 떠올리는 신호는 유명해도 소유하기 어렵다. 한 브랜드에만 연결되지만 아는 사람이 적은 신호는 투자 후보가 될 수 있다. 널리 알려졌고 한 브랜드에 고유하게 연결되는 신호만이 규모를 키우면서 보호할 핵심 자산이다. ## AI 워크플로에는 불변층과 변형층이 필요하다 생성 시스템에 브랜드 가이드 PDF를 통째로 넣는 것만으로는 부족하다. 모델은 그 안의 모든 규칙을 같은 무게로 다루지 않고, 프롬프트와 참조 이미지가 바뀔 때 중요한 신호를 희석할 수 있다. 워크플로 자체가 무엇을 보존하고 무엇을 탐색할지 구분해야 한다. 불변층에는 브랜드를 식별하게 하는 색의 관계, 형태, 캐릭터의 핵심 특징, 문장의 호흡, 사운드 모티프처럼 변형 뒤에도 남아야 할 신호가 들어간다. 변형층에는 후크, 배경, 제품 사용 장면, 화면 비율, 언어, 크리에이터의 목소리처럼 맥락에 맞춰 달라져야 할 요소가 들어간다. 여기서 불변은 픽셀 복사를 뜻하지 않는다. 같은 인물 사진과 같은 레이아웃을 모든 채널에 붙이면 일관성은 생겨도 피로가 쌓인다. 좋은 코드는 형태가 바뀌어도 관계가 남는다. 색의 정확한 면적은 달라도 대비 방식이 반복되고, 문장은 달라도 특유의 속도와 어휘 선택이 남으며, 크리에이터의 개성은 살아 있어도 브랜드를 호출하는 장면이나 소리가 반복되는 식이다. AI가 만든 모든 결과물은 이 불변층을 통과한 뒤에만 후보가 된다. 생성 개수보다 통과율을 관리해야 한다. 산출물이 늘수록 한 번의 큰 리브랜딩보다 작은 드리프트가 수백 번 누적되는 문제가 더 위험하기 때문이다. ## 로고를 가리고, 잘라 보고, 경쟁사 오인까지 잰다 브랜드 코드를 측정할 때 “우리 브랜드 같나요”라고 묻는 것은 약한 시험이다. 브랜드 이름을 먼저 보여 주면 응답자는 정답을 맞추려 한다. 대신 이름과 로고를 가린 요소를 짧게 보여 주고 가장 먼저 떠오르는 브랜드를 묻는 편이 낫다. 이때 자사 선택률만 보면 안 된다. 아무 브랜드도 떠오르지 않는지, 카테고리만 떠오르는지, 특정 경쟁사를 잘못 떠올리는지 함께 봐야 한다. 자사 연결이 늘어도 경쟁사 오인이 함께 늘면 그 신호는 고유 자산이 아니라 카테고리 관습일 수 있다. 현실의 노출은 완전한 키비주얼보다 가혹하다. 피드에서 1초만 보이고, 화면 일부가 잘리며, 소리 없이 재생되고, 생성 과정에서 배경과 인물이 바뀐다. 그래서 원본뿐 아니라 짧은 노출, 작은 크기, 부분 크롭, 흑백, 무음, 여러 AI 변형에서도 브랜드 연결이 남는지 봐야 한다. 강한 코드는 완벽한 조건이 아니라 손실된 조건에서 정체를 드러낸다. ## CTR은 실행을 평가하지만 소유권을 증명하지 않는다 클릭률이 높은 소재가 반드시 브랜드 자산을 쌓는 것은 아니다. 강한 할인 문구, 낯익은 밈, 자극적인 크리에이터는 반응을 만들 수 있지만 발신자를 기억시키지 못할 수 있다. CTR은 그 실행이 행동을 일으켰는지 보여 주고, 비이름 브랜드 연결은 기억이 누구에게 귀속됐는지 보여 준다. 둘은 함께 봐야 한다. 단기에는 소재별 반응과 브랜드 연결을 나란히 측정하고, 반복 노출 뒤에는 자발 회상, 브랜드 검색, 해당 코드와 브랜드의 연결 변화, 경쟁사 오인 변화를 본다. 검색 증가도 다른 캠페인과 계절의 영향을 받으므로 단독 인과 증거로 쓰지 않는다. 핵심은 한 지표로 모든 역할을 대신시키지 않는 것이다. 크리에이터 협업도 같은 원칙을 따른다. 크리에이터의 말투를 브랜드 문장으로 덮으면 신뢰가 사라지고, 아무 코드도 남기지 않으면 브랜드 귀속이 사라진다. 장기 플랫폼은 매번 같은 광고를 요구하지 않는다. 서로 다른 창작자가 자기 방식으로 해석할 수 있으면서도 브랜드를 떠올리게 하는 반복 장치를 만든다. ## 식별은 설득을 대신하지 않는다 distinctive asset은 브랜드가 누구인지 빠르게 알게 하지만 왜 사야 하는지를 자동으로 설명하지 않는다. 기억하기 쉬운 색과 캐릭터가 약한 제품, 모호한 약속, 나쁜 고객 경험을 구할 수는 없다. 브랜드 코드는 의미 있는 제품 약속과 실행을 더 빨리 알아보게 하는 증폭기다. 반대로 코드를 너무 엄격하게 묶으면 모든 결과물이 굳을 수 있다. 새 채널과 문화에 맞춰 변형할 여지를 남기고, 무엇이 실제 자산인지 정기적으로 다시 측정해야 한다. 지켜야 할 것은 옛 파일이 아니라 살아 있는 기억의 연결이다. AI 시대의 강한 콘텐츠 조직은 매번 새로운 스타일을 대량 생산하는 공장이 아니다. 소수의 기억 규칙을 보존하면서도 더 많은 상황에 맞게 변주하는 시스템이다. 제작비가 내려갈수록 남는 경쟁력은 제작량이 아니라 귀속이다. **누구나 무한히 만들 수 있을 때 비싸지는 것은 콘텐츠가 아니다. 로고가 없어도 “저 브랜드다”라고 알아보게 만드는 코드다.** --- 주요 출처: IAB, [2026 Outlook Study](https://www.iab.com/wp-content/uploads/2026/01/IAB%5F2026%5FOutlook%5FStudy%5FJanuary%5F2026.pdf?ref=zerodraftlab.com); Criteo, [2026 Commerce and AI Trends](https://www.criteo.com/kr/news/press-releases/2026/06/criteo-releases-2026-commerce-and-ai-trends-report/?ref=zerodraftlab.com); Ehrenberg-Bass Institute, [Brands of Distinction](https://marketingscience.info/news-and-insights/brands-of-distinction?ref=zerodraftlab.com) 및 [Distinctive Asset Measurement](https://marketingscience.info/learn-with-us/commercial-research/distinctive-asset?ref=zerodraftlab.com); Kantar, [2026 Marketing Trends](https://www.kantar.com/north-america/Company-news/Kantars-2026-Marketing-Trends?ref=zerodraftlab.com). IAB는 미국 광고 구매자 조사, Criteo는 의뢰 소비자 설문, Kantar는 자체 분석·조사이므로 각 수치를 보편적 인과효과로 일반화하지 않았습니다. 불변층·변형층과 측정 설계는 이 자료를 바탕으로 확장한 이 글의 분석입니다. ### AI 버블의 다음 숫자는 모델 점수가 아니라 가동률이다 URL: https://zerodraftlab.com/ai-bubble-next-number-is-utilization/ Last updated: 2026-09-15T08:35:34.000Z AI 기업을 평가하는 가장 쉬운 방법은 모델 점수를 보는 것이다. 벤치마크가 오르면 기술이 전진했고, 순위가 떨어지면 뒤처졌다고 말할 수 있다. 하지만 수천억 달러의 데이터센터가 깔린 뒤에는 더 어려운 숫자가 회사를 가른다. **그 컴퓨팅 자산이 실제로 몇 시간이나 돈을 벌고 있는가.** Meta가 Anthropic에 컴퓨팅 파워를 임대하는 방안을 협상 중이라는 보도가 이 질문을 수면 위로 올렸다. New York Times를 인용한 Reuters 보도에 따르면 잠재 거래 규모는 2년간 최대 100억 달러다. 아직 서명된 계약은 아니고, 공급할 칩과 용량, 가격, 최소구매약정도 공개되지 않았다. 그럼에도 이 협상이 중요한 이유는 한 회사의 매출이 늘어날 수 있어서만은 아니다. AI 인프라 경쟁이 **누가 더 많이 확보했는가**에서 **누가 더 잘 회전시키는가**로 넘어가고 있다는 신호이기 때문이다. ## 가장 큰 AI 구매자가 판매자가 되는 순간 Meta는 2026년 한 해에만 1,250억\~1,450억 달러를 자본적 지출에 투입할 계획이다. 1분기 자본적 지출은 198억 달러를 넘었고, 3월 말 기준 취소할 수 없는 계약상 약정은 2,376억 달러에 달한다. 회사가 빌리고 사기로 한 데이터센터, 제3자 클라우드 용량, 서버와 네트워크가 여러 해에 걸쳐 들어오는 구조다. 이 숫자만 보면 Meta는 컴퓨팅 파워의 압도적인 구매자다. 그런데 동시에 외부 기업에 컴퓨팅을 빌려주는 판매자가 되려 한다. 모순처럼 보이지만 대규모 인프라는 원래 이런 모순을 만든다. 데이터센터는 앱 사용량처럼 매끄럽게 늘어나지 않는다. 전력, 부지, 냉각, 네트워크, 가속기는 큰 덩어리로 계약되고 몇 년 뒤 차례로 들어온다. 내부 수요는 모델 학습 일정과 제품 출시, 추론량에 따라 출렁인다. 미래의 피크를 감당하려고 미리 산 용량은 오늘의 일부 시간대에 비어 있을 수 있다. 이 틈을 외부 고객의 장기 수요로 채울 수 있다면 유휴 시간은 매출로 바뀐다. 반대로 내부에서 쓸 이유가 사라져 급히 임대하는 것이라면 외부 매출은 과잉 투자의 손실을 조금 늦추는 데 그친다. 같은 거래가 자본 운용의 영리함일 수도 있고, 수요 예측 실패의 영수증일 수도 있다. ## 100억 달러는 크지만, 회수율을 증명하지는 않는다 잠재 거래액 100억 달러를 2년에 균등하게 나누면 연간 50억 달러다. Meta의 2026년 자본적 지출 가이던스와 비교하면 약 3.4\~4.0%다. 작은 돈은 아니지만 이 비율만으로 투자 회수를 말할 수는 없다. 100억 달러가 전부 매출로 인식되는 시기, 전력비와 네트워크비, 감가상각, 공급할 하드웨어의 원가, 계약 중도 해지 조건을 모르기 때문이다. Meta가 이미 사 둔 용량을 재판매하는지, 새로 지은 자산을 직접 제공하는지에 따라서도 경제성이 달라진다. 그래서 지금 필요한 숫자는 헤드라인 계약 총액이 아니다. 최소 사용량을 보장하는지, 공급 자산의 가동률이 얼마나 올라가는지, 외부 컴퓨트 매출의 총이익률이 얼마인지, 감가상각보다 현금 유입이 빠르게 늘어나는지를 봐야 한다. Meta도 이 위험을 알고 있다. 회사는 10-Q에서 실제 필요를 넘는 기술 인프라가 자산 손상으로 이어질 수 있다고 적었다. 2026년 1분기 감가상각비는 약 60억 달러였고, 데이터센터와 기술 인프라 운영비 증가가 매출원가를 끌어올렸다. AI 버블을 판별하는 숫자는 어느 모델이 1등인지보다 이 비용을 누가 지속 가능한 현금흐름으로 바꾸는지에 가까워지고 있다. ## Databricks의 1,880억 달러는 다른 층에 붙은 가격이다 같은 주에 Databricks는 1,880억 달러 기업가치의 전략적 투자 라운드 term sheet에 서명했다고 발표했다. 이번 여름 후반 종결을 예상하는 단계라 아직 닫힌 거래는 아니다. 회사가 2월에 공개한 매출 run-rate는 54억 달러 초과, 전년 대비 성장률은 65% 초과, AI 제품 매출 run-rate는 14억 달러 초과였다. 2월 수치를 그대로 분모로 쓰면 1,880억 달러는 매출 run-rate의 약 34.8배다. 최신 매출을 반영한 정식 배수는 아니지만, 자본이 어디에 높은 값을 붙이는지는 보여준다. GPU 자체뿐 아니라 기업의 데이터, 보안, 비용, 여러 모델과 에이전트를 한곳에서 통제하는 층이다. 원시 컴퓨트가 넘쳐도 기업 데이터가 흩어져 있고 권한과 비용을 통제하지 못하면 AI는 운영계에 들어가지 못한다. 반대로 Databricks 같은 제어층은 어떤 모델과 가속기가 승리해도 사용량을 흡수할 수 있다고 주장한다. 하드웨어의 가동률과 소프트웨어의 사용량이 서로를 밀어 올리는 구조다. 하지만 높은 기업가치도 현금흐름의 증명은 아니다. Databricks는 비상장기업이고, 이번 발표는 종결된 라운드가 아니라 term sheet다. 기업가치가 다섯 달 만에 크게 올랐다는 사실은 투자자의 기대를 보여줄 뿐, 그 기대가 언제 어떤 이익으로 돌아오는지는 별개의 질문이다. ## AI 버블은 GPU의 수가 아니라 계약의 질에서 드러난다 지금까지 AI 인프라의 희소성은 모든 투자를 정당화하는 것처럼 보였다. 더 많은 전력과 더 많은 칩을 확보하면 미래 수요가 따라올 것이라는 믿음이었다. 이제 대규모 용량이 실제로 들어오면서 그 믿음은 계약서와 손익계산서의 시험을 받는다. Meta–Anthropic 협상이 체결된다면 확인해야 할 것은 100억 달러라는 숫자보다 그 안의 구조다. Anthropic이 일정 금액을 무조건 지불하는가. 수요가 줄면 Meta가 용량 위험을 떠안는가. 특정 칩의 빠른 노후화를 누가 부담하는가. 전력과 네트워크 비용이 오르면 가격을 다시 정할 수 있는가. 이 조건이 공개되기 전까지 “Meta가 클라우드 사업으로 AI 투자를 회수했다”거나 “쓸 곳 없는 GPU를 처분한다”는 결론은 모두 너무 빠르다. 지금 확인된 변화는 더 근본적이다. **Meta는 모델 회사이기 전에 컴퓨트 포트폴리오 운영자가 되고 있다.** 용량을 사고, 직접 짓고, 내부 제품에 배분하고, 필요하면 외부 수요와 연결하는 사업이다. 이 사업의 경쟁력은 벤치마크 순위만으로 측정되지 않는다. 수요 예측, 계약 설계, 전력 조달, 감가상각, 고객 신용과 가동률이 함께 결정한다. 여기서부터는 AI 인프라 투자를 실제로 판별할 수 있는 숫자를 더 좁혀 보자. 회계상 자산회전율을 그대로 계산하려면 AI 인프라 매출과 평균 자산이 따로 공시돼야 한다. Meta는 이를 별도 사업부로 공개하지 않는다. 따라서 지금은 세 개의 대체 지표로 자본 회수를 추적하는 편이 정확하다. ## 첫째, 계약 매출보다 보장 사용량을 본다 최대 계약액은 가장 낙관적인 사용량을 합친 상한일 수 있다. 반면 take-or-pay나 최소구매약정은 고객이 실제로 쓰지 않아도 공급자가 받는 현금흐름을 만든다. 데이터센터처럼 고정비가 큰 사업에서는 두 숫자의 차이가 수익성의 대부분을 결정할 수 있다. 계약 기간도 길수록 무조건 좋은 것은 아니다. 장기 고정가격 계약은 가동률을 보장하지만, 전력비가 오르거나 더 좋은 칩이 나왔을 때 마진을 잠글 수 있다. 반대로 짧은 계약은 가격을 다시 정할 수 있지만 자산의 잔존가치 위험을 공급자가 진다. 계약액, 기간, 최소 사용량, 가격 조정 조항을 한 묶음으로 봐야 한다. ## 둘째, CAPEX와 감가상각의 시차를 본다 Meta의 1분기 영업현금흐름은 322억 달러, 잉여현금흐름은 124억 달러였다. 광고 사업이 막대한 AI 투자를 아직 감당하고 있다는 뜻이다. 그러나 연간 CAPEX 가이던스는 1,250억\~1,450억 달러이고, 아직 시작되지 않은 데이터센터·네트워크 리스 의무만 1,828억 달러다. 현금은 건설과 장비 구매 시점에 먼저 나가고, 비용은 감가상각으로 여러 해에 걸쳐 손익계산서에 들어온다. 초기에는 매출 성장과 영업이익이 튼튼해 보여도, 뒤늦게 들어오는 감가상각과 운영비가 마진을 누를 수 있다. 외부 컴퓨트 매출이 생긴다면 그 성장률이 감가상각 증가율을 따라잡는지가 중요한 이유다. ## 셋째, 내부 수요와 외부 수요의 충돌을 본다 용량 임대는 유휴 자산을 줄이지만, 자체 모델이 예상보다 빠르게 성장하면 외부 장기 계약이 내부 공급을 묶을 수 있다. 반대로 언제든 내부로 회수할 수 있는 계약은 고객에게 안정적인 클라우드가 아니다. Meta가 범용 클라우드가 되려면 단순히 남는 GPU를 파는 것보다 어려운 서비스 수준, 격리, 지원, 생태계 문제를 풀어야 한다. 그래서 이 협상의 가장 좋은 형태는 내부 피크와 겹치지 않는 용량을 장기 고객에게 배분하면서도, 가격과 기간이 기술 노후화 위험을 보상하는 구조다. 가장 나쁜 형태는 내부 수요 예측 실패를 숨기기 위해 낮은 마진의 장기 계약으로 자산을 묶는 것이다. ## Databricks는 가동률의 반대편에서 돈을 번다 컴퓨트 공급자는 자산을 놀리지 않아야 한다. Databricks 같은 제어층은 고객이 여러 컴퓨트와 모델을 더 자주, 더 안전하게 쓰게 만들어야 한다. 하나는 공급 가동률을, 다른 하나는 기업 사용량을 판다. 이 구조에서 Databricks의 위험은 다른 곳에 있다. 고객이 AI 비용을 통제하지 못해 실험을 줄이거나, 클라우드 사업자가 데이터·거버넌스 기능을 번들로 제공하거나, 오픈소스 조합이 충분히 좋아지면 높은 성장률과 순매출유지율이 꺾일 수 있다. 34.8배라는 참고 배수는 성장과 현금흐름이 동시에 유지될 때만 버틸 수 있는 기대다. ## 다음 분기의 체크리스트 첫째, Meta–Anthropic 협상이 실제 서명 계약으로 바뀌는지 본다. 둘째, 최소구매약정과 공급 용량, 칩, 기간이 공개되는지 확인한다. 셋째, Meta가 외부 컴퓨트 매출과 총이익률을 별도로 보여주는지 본다. 넷째, 감가상각과 데이터센터 운영비가 광고 사업의 이익 증가보다 빠르게 오르는지 추적한다. 다섯째, Databricks 라운드가 실제로 종결되는지와 최신 매출 run-rate·FCF가 1,880억 달러 기대를 따라가는지 확인한다. AI 버블은 어느 날 갑자기 모든 수요가 사라질 때만 터지는 것이 아니다. 비싼 자산이 계속 가동되지만 자본비용을 넘는 현금을 만들지 못할 때도 조용히 꺼진다. 반대로 모델 경쟁이 혼란스러워도 높은 가동률, 질 좋은 장기 계약, 늘어나는 현금흐름이 확인되면 인프라는 거품이 아니라 사업이 된다. **다음 AI 리더보드는 모델 순위표가 아니다. CAPEX를 얼마나 빨리, 얼마나 높은 마진의 반복 현금흐름으로 바꾸는지를 보여주는 표다.** --- 주요 출처: Reuters, [Meta–Anthropic 컴퓨팅 임대 협상 보도](https://www.reuters.com/technology/meta-talks-10-billion-anthropic-compute-deal-nyt-reports-2026-07-17/?ref=zerodraftlab.com); Meta, [2026년 1분기 실적](https://investor.atmeta.com/investor-news/press-release-details/2026/Meta-Reports-First-Quarter-2026-Results/?ref=zerodraftlab.com) 및 [Form 10-Q](https://www.sec.gov/Archives/edgar/data/1326801/000162828026028526/meta-20260331.htm?ref=zerodraftlab.com); Databricks, [1,880억 달러 전략적 투자 발표](https://www.databricks.com/company/newsroom/press-releases/databricks-raising-strategic-round-funding-188-billion-valuation?ref=zerodraftlab.com)와 [54억 달러 매출 run-rate 발표](https://www.databricks.com/company/newsroom/press-releases/databricks-grows-65-yoy-surpasses-5-4-billion-revenue-run-rate?ref=zerodraftlab.com). Meta–Anthropic 거래는 협상 단계이고 Databricks 라운드는 term sheet 단계다. 34.8배는 2026년 2월 run-rate와 7월 term-sheet 가치를 단순 비교한 참고치이며 투자 조언이 아니다. ### 리테일 미디어는 광고 지면이 아니라 구매 데이터의 새 관문이다 URL: https://zerodraftlab.com/retail-media-is-purchase-data-gateway/ Last updated: 2026-09-15T08:35:35.000Z 매장 입구의 진열대와 전단지는 오래전부터 광고였다. 제조사는 더 잘 보이는 자리를 얻기 위해 비용을 냈고 유통사는 쇼핑 동선과 판매 데이터를 이용해 그 자리를 팔았다. 리테일 미디어가 새로운 이유는 이 오래된 거래가 디지털 광고의 속도와 측정 언어를 얻었기 때문이다. IAB는 미국 commerce media 광고비가 2026년 전년 대비 12.1% 증가해 전체 광고시장 전망치 9.5%보다 약 30% 빠르게 성장할 것으로 봤다. off-site 광고, 매장 안의 디지털 지면, AI 쇼핑 도우미가 새 기회로 거론된다. 동시에 파편화, 측정 불일치, 증분성에 대한 의문도 해결되지 않은 문제로 적었다. **리테일 미디어의 핵심은 광고 지면이 아니다. 검색, 상품 진열, 가격, 재고, 장바구니, 구매를 한 사업자가 연결할 수 있다는 사실이다.** ## 광고가 구매 순간에 가까워진다 검색광고는 사용자의 의도를 알고 소셜 광고는 관심을 추정한다. 리테일 미디어는 여기에 실제 상품과 거래를 붙인다. 어떤 검색어 뒤에 어느 상품이 보였고, 어떤 가격과 재고 상태에서 장바구니에 들어갔으며, 결국 무엇이 결제됐는지를 같은 시스템 안에서 볼 수 있다. 이 차이는 타기팅보다 측정에서 더 크다. 광고주는 노출과 클릭에서 멈추지 않고 SKU 단위 판매, 신규 구매자, 반복 구매, 장바구니 크기까지 보고 싶어 한다. 유통사는 거래에서 생긴 신호를 광고 상품으로 바꾸고, 낮은 유통 마진 위에 더 높은 광고 마진을 쌓을 수 있다. 그래서 리테일 미디어는 쇼핑몰 안의 검색 배너에 머물지 않는다. 유통사의 고객 데이터를 이용해 외부 웹과 CTV에서 광고를 집행하는 off-site, 매장 스크린과 디지털 진열대, 브랜드 자체 데이터를 결합하는 clean room으로 넓어진다. 매체의 경계가 사이트가 아니라 구매 데이터를 사용할 수 있는 권리로 바뀐다. ## 상품 진열권이 경매로 바뀐다 리테일 미디어는 광고와 머천다이징의 경계도 흐린다. 검색 결과 첫 줄, 카테고리 상단, 추천 묶음, 장바구니 직전 제안은 광고 지면인 동시에 상품 진열이다. 브랜드는 소비자의 관심만 사는 것이 아니라 디지털 선반의 가시성을 산다. 이 구조는 강력하지만 중립적이지 않다. 유통사는 어떤 상품을 보이게 할지 결정하고, 광고를 팔고, 주문을 기록하며, 성과 보고서까지 만든다. 광고비가 늘수록 자연 검색 결과와 유료 진열의 구분, 소비자 경험과 광고 수익의 충돌, 자사 상품과 입점 브랜드의 경쟁이 중요해진다. 검색 결과에서 광고가 너무 많아지면 구매 경험이 나빠진다. 성과가 좋은 상품보다 광고비를 더 낸 상품이 앞에 서면 단기 광고 매출은 오르지만 쇼핑 신뢰는 줄 수 있다. 리테일 미디어는 새 배너 사업이 아니라 광고 수익과 상거래 신뢰를 동시에 운영하는 사업이다. ## 폐쇄 루프는 인과관계가 아니다 구매까지 연결되는 보고서는 기존 디지털 광고보다 단단해 보인다. 광고를 본 계정이 며칠 뒤 같은 플랫폼에서 제품을 샀다면 성과가 명확해 보이기 때문이다. 그러나 구매에 가까운 사람에게 광고를 보여준 것과 광고가 구매를 추가로 만들었다는 것은 다른 주장이다. IAB와 IAB Europe은 commerce media의 증분 측정 지침에서 attribution과 ROAS는 무엇이 일어났는지를 보여주지만 마케팅이 그 결과의 원인이었는지는 말하지 못한다고 구분한다. 광고가 없어도 제품을 검색해 샀을 사람, 이미 다른 채널에서 설득된 사람, 할인 때문에 구매한 사람까지 광고 성과에 포함될 수 있다. 한 플랫폼 안에서 노출과 구매를 연결할 수 있다는 것은 훌륭한 관측 능력이다. 하지만 관측이 정교해질수록 인과관계가 자동으로 강해지는 것은 아니다. 특히 광고를 판매한 플랫폼이 귀속 규칙과 성과 판정도 통제한다면 브랜드는 편리한 숫자와 독립적인 판단을 구분해야 한다. 리테일 미디어의 진짜 가치는 구매 데이터를 많이 보여주는 데 있지 않다. 광고가 없었을 세계와 비교할 수 있게 만드는 데 있다. 그렇다면 플랫폼이 지면과 거래와 성적표를 모두 가진 시장에서 브랜드는 무엇을 직접 소유하고 어떻게 성과를 판정해야 하는가? 브랜드가 직접 소유해야 하는 것은 모든 고객의 원시 데이터가 아니라 **광고 전 기준선, 상품별 경제성, 가격·재고·프로모션의 변화, 실험 설계와 판정 이력**이다. 플랫폼의 주문 데이터는 더 풍부할 수 있지만, 브랜드의 이익 구조와 다른 채널에서 일어난 변화까지 자동으로 알지는 못한다. 두 데이터가 만날 때만 판매 보고서가 사업 판단으로 바뀐다. ## 한 주문에 여러 ROAS가 붙는 이유 소비자는 한 채널만 거쳐 구매하지 않는다. 소셜에서 제품을 발견하고 검색광고를 클릭한 뒤, 리테일 플랫폼에서 브랜드 키워드를 검색하고 sponsored listing을 거쳐 결제할 수 있다. 각 플랫폼이 자기 attribution window 안에서 주문을 잡으면 같은 매출이 세 번의 성과로 보고된다. 이때 플랫폼별 ROAS를 합산해 예산을 늘리면 실제 매출보다 더 많은 기여를 산다. 리테일 미디어의 강한 구매 신호도 이 문제를 없애지 않는다. 오히려 구매에 가장 가까운 마지막 접점이라 이미 만들어진 수요를 가장 많이 가져갈 수 있다. 그래서 운영 보고와 예산 판정은 분리해야 한다. attribution은 검색어, 소재, SKU, 입찰을 빠르게 조정하는 운영 신호로 쓸 수 있다. 예산을 더 넣어도 되는지는 holdout, 지역 실험, matched market, 모델 기반 counterfactual, MMM처럼 광고가 없었을 기준선을 만드는 방법으로 따로 본다. 모든 캠페인에 무작위 실험을 할 수는 없다. 비용이 크고 플랫폼 밖의 노출이 대조군을 오염시킬 수 있다. 그렇다고 가장 편한 ROAS를 인과효과로 부를 수는 없다. 중요한 것은 숫자마다 허용되는 주장을 제한하는 것이다. platform attribution은 운영 최적화, platform lift는 해당 환경의 보정, 독립 실험은 인과 검증, MMM은 전체 예산 배분에 더 적합하다. ## 매출이 아니라 기여이익까지 내려가야 한다 리테일 미디어는 구매에 가까워 매출을 쉽게 보여주지만 브랜드가 남기는 돈은 여러 층을 통과한다. 광고비, 유통 수수료, 판촉 분담금, 할인, 물류비, 반품, 대행 수수료를 빼고 나면 높은 ROAS가 낮은 기여이익으로 바뀔 수 있다. 특히 브랜드 키워드 광고는 이미 제품을 찾던 고객에게 비용을 붙일 위험이 있다. 검색 상단을 경쟁사에 내주지 않는 방어 가치가 있을 수 있지만, 방어비를 신규 수요 창출과 같은 가격으로 평가하면 안 된다. 카테고리 검색, 경쟁 상품 상세, 신규 고객, 재구매 방어는 서로 다른 경제적 역할을 가진다. 판정 단위도 캠페인 평균에서 상품과 고객군으로 내려가야 한다. 마진이 높은 입문 상품이 첫 구매를 만들고 이후 다른 제품으로 확장될 수 있다. 반대로 매출은 크지만 반품률과 프로모션 의존도가 높은 SKU는 광고를 늘릴수록 손실이 커질 수 있다. Amazon이 Marketing Cloud의 구매 신호 조회 기간을 13개월에서 최대 5년으로 넓히며 customer lifetime value와 new-to-brand를 사용 사례로 든 이유도 단일 주문보다 긴 관계를 보려는 데 있다. 이는 플랫폼의 기능 설명이며 성과의 독립 검증은 아니다. ## 측정 계약이 매체 계약만큼 중요해진다 리테일 미디어를 살 때 CPM과 CPC만 협상해서는 부족하다. 무엇을 노출로 인정하는지, attribution window가 며칠인지, 클릭과 view-through를 어떻게 나누는지, 광고한 SKU 외의 halo sale을 어디까지 포함하는지, 온라인과 매장 구매를 어떻게 연결하는지 확인해야 한다. IAB/MRC 지침은 다른 매체 노출과 기존 구매 의도를 귀속 판단에서 고려하고, featured SKU와 halo SKU, deterministic과 probabilistic 결과, 온라인과 오프라인을 구분해 공개하도록 요구한다. 이 항목들이 빠진 ROAS는 숫자가 아니라 플랫폼마다 다른 문법이다. 브랜드가 보존해야 할 최소 정본도 여기서 나온다. 일별 가격과 재고, 프로모션, 상품별 매출과 마진, 자연 검색 순위, 광고 노출과 비용, 신규·기존 고객 정의, 반품, 실험군과 비교군을 같은 시간축에 남긴다. 플랫폼이 바뀌어도 이 기준선이 있어야 성과를 비교하고 측정 방식의 변화도 발견할 수 있다. ## clean room은 데이터 소유권의 종착지가 아니다 Amazon Marketing Cloud 같은 clean room은 pseudonymized 광고 신호와 광고주 자체 데이터를 결합하고 집계된 익명 결과를 제공한다. 개인정보를 원시 상태로 주고받지 않으면서 더 깊은 분석을 할 수 있다는 장점이 있다. 그러나 분석 공간에 데이터를 넣을 수 있다는 것과 고객 관계를 브랜드가 소유한다는 것은 다르다. 쿼리 가능한 필드, 조회 기간, 결합 키, 최소 집계 기준, 출력 제한, 사용료는 플랫폼이 정한다. 브랜드가 플랫폼 밖의 가격·재고·CRM·마진 데이터를 정리하지 않았다면 clean room은 자체 정본을 강화하는 도구가 아니라 플랫폼 보고서를 더 복잡하게 보는 창이 된다. 좋은 데이터 전략은 모든 원시 데이터를 가져오는 것이 아니다. 재현 가능한 질문을 소유하는 것이다. 어느 기간의 어떤 고객을 신규로 봤는지, 어떤 상품을 halo에 넣었는지, 어떤 대조군을 썼는지, 결과가 어느 비용과 마진을 포함하는지 기록해야 다음 분기에도 같은 판정을 반복할 수 있다. ## AI 쇼핑 에이전트는 구매 데이터의 관문을 더 중요하게 만든다 IAB는 2026년 commerce media 성장 기대의 하나로 agentic AI shopping assistant를 들었다. 아직 확정된 시장 구조가 아니라 구매자 전망이다. 다만 쇼핑 에이전트가 사용자의 조건을 받아 상품을 비교하고 구매한다면 가격, 재고, 배송, 옵션, 반품 정책, 판매 이력처럼 구조화된 상거래 신호의 가치는 커진다. 이때 리테일 플랫폼은 사람에게 광고를 보여주는 매체를 넘어 에이전트가 상품을 발견하고 신뢰하는 데이터 관문이 될 수 있다. 광고 상품도 sponsored listing에서 에이전트가 읽는 프로모션, 가용성, 서비스 수준, 검증된 상품 주장으로 넓어질 수 있다. 동시에 광고와 추천의 경계는 더 민감해진다. 에이전트가 더 높은 광고비를 낸 상품을 선택하면서 그 상업적 개입을 설명하지 않으면 구매 데이터의 정밀함이 사용자 이익을 보장하지 않는다. 브랜드에는 기계가 읽을 수 있는 정확한 상품 정보가, 플랫폼에는 유료 개입과 추천 근거를 구분하는 규칙이 필요하다. ## 리테일 미디어를 살 때는 데이터가 아니라 판정권을 산다 모든 브랜드가 자체 리테일 미디어 인프라를 만들 필요는 없다. 구매 주기가 길고 플랫폼 안의 판매 비중이 낮거나, 매장 데이터 연결이 약한 카테고리에서는 풍부해 보이는 보고서가 사업 전체의 작은 조각일 수 있다. 반대로 반복 구매가 많고 SKU와 고객군이 선명한 브랜드에는 제품·미디어·CRM을 연결하는 강력한 실험장이 된다. 따라서 좋은 리테일 미디어 투자는 가장 많은 구매 데이터를 약속하는 네트워크를 고르는 일이 아니다. 데이터 정의를 설명하고, 비교 기준을 만들 수 있으며, 마진까지 연결하고, 플랫폼 밖의 결과와 교정할 수 있는 네트워크를 고르는 일이다. **검색과 소셜이 관심의 관문이었다면 리테일 미디어는 거래의 관문이 된다.** 관문을 가진 사업자는 지면뿐 아니라 상품의 발견과 성과의 해석을 판다. 브랜드가 사야 하는 것은 예쁜 성적표가 아니라, 그 성적표가 틀릴 수 있는 조건까지 검증할 수 있는 판정권이다. --- 주요 출처: IAB, [2026 Outlook Study](https://www.iab.com/wp-content/uploads/2026/01/IAB%5F2026%5FOutlook%5FStudy%5FJanuary%5F2026.pdf?ref=zerodraftlab.com); IAB 및 IAB Europe, [Guidelines for Incremental Measurement in Commerce Media](https://www.iab.com/guidelines/guidelines-for-incremental-measurement-in-commerce-media/?ref=zerodraftlab.com); IAB/MRC, [Retail Media Measurement Guidelines](https://www.iab.com/wp-content/uploads/2024/01/IAB%5FRetail%5FMedia%5FMeasurement%5FGuidelines%5FJanuary2024.pdf?ref=zerodraftlab.com); Amazon Ads, [Marketing analytics](https://advertising.amazon.com/measurement-analytics?ref=zerodraftlab.com) 및 [AMC 5-year retail lookback](https://advertising.amazon.com/en-ca/library/news/amc-measurement-expansion?ref=zerodraftlab.com). 12.1%는 미국 광고 구매자의 2026년 전망이며, Amazon 자료는 플랫폼 기능에 대한 자기보고입니다. 중복 귀속, 기여이익, 측정 계약, 데이터 정본과 판정권의 구조는 이 근거를 바탕으로 한 글의 운영 분석입니다. ### 에이전트에게 권한을 주지 말고 계획에 권한을 줘라 URL: https://zerodraftlab.com/permission-belongs-to-the-plan/ Last updated: 2026-09-15T08:35:36.000Z 프로덕션 장애를 고치는 AI 에이전트에는 권한이 필요하다. 로그만 읽어서는 롤백할 수 없고, 설정을 바꾸거나 캐시를 지우거나 수정 코드를 올릴 수도 없다. 그렇다고 운영자의 권한을 통째로 넘기면 에이전트가 잘못 이해한 한 문장이 서비스 전체를 바꿀 수 있다. 그래서 지금까지의 선택은 답답한 read-only와 위험한 상시 권한 사이에 있었다. 안전한 에이전트는 제안만 하고, 실제로 유용한 에이전트는 사람처럼 넓은 권한을 가진다는 타협이다. Vercel Agent가 흥미로운 이유는 이 양자택일을 권한 구조로 다시 풀기 때문이다. 에이전트에게 권한을 주는 대신 **사용자가 승인한 계획에 권한을 준다.** 모델을 완전히 믿지 않으면서도 프로덕션에서 실제 행동하게 만드는 방식이다. ## 신뢰는 정답률이 아니라 실수의 비용이다 Vercel Agent는 완전히 새로 등장한 제품이 아니다. 경보 분류와 pull request 검토에서 시작해, 대시보드에서 로그·지표·배포를 조사하고 해결 계획을 제안하며 승인 뒤 조치하는 범위로 확장됐다. 기본값은 read-only이고 \`vercel-agent\`라는 별도 principal로 움직인다. 이 구분은 이름표 이상의 의미가 있다. 일반적인 에이전트는 사용자의 토큰을 받아 사용자의 신원으로 행동한다. 로그에는 사람이 한 일과 에이전트가 한 일이 섞이고, 에이전트 하나만 중지하려면 사용자의 접근까지 끊어야 할 수 있다. 별도 principal을 두면 누가 요청했고, 누가 승인했으며, 어떤 주체가 실행했는지를 나눠 기록할 수 있다. 하지만 별도 신원만으로 안전해지지는 않는다. 이름이 다른 관리자 계정에 넓은 권한을 주면 위험은 그대로다. 신원은 행동을 귀속할 뿐이고, 실제 피해 범위는 권한이 결정한다. ## 계획이 곧 권한이 된다 Vercel Agent는 롤백, 설정 변경, 캐시 삭제 같은 write가 필요하면 먼저 계획을 제시한다. 사용자가 승인하면 그 계획에 명시된 작업에만 짧게 유효한 capability를 받고, 일을 마치면 다시 read-only로 돌아간다. 실행되는 각 호출은 계획의 capability, 발급된 토큰의 scope, 기존 팀 권한이라는 세 층을 모두 통과해야 한다. 사용자가 원래 할 수 없는 일을 에이전트가 대신 할 수 없고, 승인된 계획 밖의 행동도 모델의 판단만으로 넓힐 수 없다. 통제는 프롬프트가 아니라 플랫폼에 남는다. 이 설계의 핵심은 에이전트가 틀리지 않을 것이라고 가정하지 않는 데 있다. 모델이 잘못된 원인을 찾거나, 모호한 지시를 과도하게 해석하거나, 하위 에이전트가 엉뚱한 행동을 제안해도 실행 가능한 범위는 승인된 계획 안에 갇힌다. 신뢰를 모델의 성격에서 시스템의 경계로 옮긴다. ## 코드를 쓸 권한과 운영계를 바꿀 권한도 다르다 Vercel Agent가 만든 코드는 실제 운영계에서 바로 실행되지 않는다. 임시 Firecracker microVM인 Vercel Sandbox에서 실제 프로젝트의 build, test, lint를 돌리고 통과한 결과를 pull request로 제시한다. 코드를 자유롭게 생성하는 공간과 사용자에게 영향을 주는 공간을 분리한 것이다. 이 분리는 중요하다. 에이전트가 파일을 쓸 수 있다는 사실이 배포 권한을 가져야 한다는 뜻은 아니다. 테스트를 통과했다는 사실도 프로덕션 설정 변경이나 데이터 write를 허가하는 근거와는 다르다. 생성, 검증, 승인, 실행을 하나의 권한으로 묶을수록 작은 오류가 큰 사건으로 번진다. 물론 Vercel이 제시한 장애 대응 사례는 회사가 설명한 자사 환경의 전형적 시나리오다. 모든 장애를 3분 안에 해결한다는 독립된 보장이 아니며, 현재 기능도 Pro·Enterprise 팀에 점진적으로 배포 중이다. 그럼에도 별도 신원, 계획 단위 임시 권한, sandbox, 되돌릴 수 있는 배포를 한 흐름으로 묶은 설계는 더 넓은 질문을 남긴다. **프로덕션 에이전트에게 실제 권한을 주면서도, 잘못된 한 번의 판단이 계정 전체의 권한으로 번지지 않게 하려면 무엇을 분리해야 하는가?** 먼저 분리할 것은 신원, 의도, 권한, 실행, 증거다. 이 다섯 층이 한 토큰과 한 대화 안에 합쳐져 있으면 사람의 승인 버튼이 있어도 안전하지 않다. 반대로 각 층이 독립된 객체와 판정을 가지면 모델이 바뀌어도 통제 구조는 남는다. ## 에이전트 신원은 사람의 대리 계정이 아니어야 한다 에이전트가 사용자의 API key를 그대로 쓰면 시스템은 행동의 실제 주체를 알 수 없다. “Owner가 실행했다”는 로그만 남고, 그 안에서 모델이 제안했는지 사람이 직접 명령했는지 복원하기 어렵다. 권한을 회수할 때도 사람과 에이전트를 함께 끊어야 한다. 독립된 agent principal은 최소 세 가지를 가능하게 한다. 에이전트별 권한 회수, 행동별 귀속, 여러 하위 에이전트 사이의 격리다. 같은 사용자를 위해 일해도 조사 에이전트, 배포 에이전트, 결제 에이전트가 하나의 자격증명을 공유할 이유는 없다. 하나가 오염되거나 잘못된 지시를 받아도 나머지의 권한으로 이동하지 못해야 한다. Vercel이 Better Auth를 인수하며 Agent Auth를 함께 강조한 것도 이 층과 연결된다. Better Auth 팀은 각 에이전트가 독립된 신원과 scope가 제한되고 취소 가능한 권한을 갖는 방향을 개발해 왔다. 다만 인수 발표와 Vercel Agent의 기능 확장은 서로 다른 사건이다. 공개 라이브러리를 인수했다는 사실이 곧 범용 agent identity 표준의 완성을 뜻하지도 않는다. 신원을 분리해도 에이전트가 무엇을 하겠다는지 모호하면 권한은 다시 넓어진다. 다음 병목은 자연어 요청을 사람이 검토할 수 있는 계획으로 만들고, 그 계획을 기계가 강제할 수 있는 capability로 번역하는 과정이다. ## 승인할 대상은 자연어가 아니라 실행 가능한 계획이다 “문제를 고쳐줘”라는 문장에 승인 버튼을 붙이는 것은 계획 승인이라기보다 포괄 위임에 가깝다. 사람이 보아야 할 것은 목표뿐 아니라 어떤 리소스에 어떤 동사를 적용하고, 예상 결과가 무엇이며, 실패하면 어디로 돌아가는지다. 예를 들어 “checkout 장애를 해결한다”는 목표는 권한이 될 수 없다. “배포 A를 배포 B로 롤백하고, 캐시 key C만 삭제하며, 오류율이 기준 아래로 내려오지 않으면 추가 write 없이 중지한다”는 계획이어야 한다. 그래야 자연어 의도를 \`deployment.rollback\`, \`cache.purge\` 같은 제한된 capability로 번역할 수 있다. 계획은 실행 중에도 마음대로 늘어나면 안 된다. 조사하다 새 설정 변경이 필요해졌다면 기존 승인을 확대 해석하는 대신 새로운 diff를 제시하고 다시 권한을 받아야 한다. 좋은 계획 승인은 모델에게 재량을 없애는 것이 아니라, 재량이 필요한 순간과 권한이 필요한 순간을 분리한다. ## 짧은 수명만으로는 부족하다 short-lived token은 탈취됐을 때의 시간을 줄이지만, 살아 있는 동안 무엇이든 할 수 있다면 피해는 여전히 크다. 임시 권한은 시간뿐 아니라 대상 리소스, 허용 동작, 호출 횟수나 금액, 환경, 승인자 권한의 교집합으로 좁아져야 한다. 여기서 중요한 원칙은 권한 상승 금지다. 에이전트가 받은 capability로 다른 capability를 발급하거나, 새 principal을 만들거나, 자신의 정책을 고칠 수 있으면 계획의 경계가 무너진다. 권한을 집행하는 판정기는 모델이 수정할 수 없는 플랫폼 층에 있어야 한다. ## Sandbox는 실행을 격리하지만 결과를 보증하지 않는다 격리된 환경에서 build와 test를 통과한 코드는 그렇지 않은 코드보다 안전하다. 그러나 sandbox는 테스트가 놓친 사업 규칙, 실제 트래픽의 경쟁 상태, 외부 결제와 데이터 변경까지 증명하지 않는다. 생성 코드가 host를 해치지 못하게 하는 경계와 그 코드를 운영계에 반영해도 되는지를 판단하는 경계는 별개다. 따라서 sandbox 결과는 배포 권한의 자동 승격이 아니라 승인에 붙는 증거가 되어야 한다. 어떤 테스트를 돌렸고, 무엇은 검증하지 못했으며, 변경 diff와 예상 영향이 무엇인지 남겨야 한다. 검증 증거가 없는 “성공”은 모델의 보고일 뿐 시스템의 판정이 아니다. ## 승인 피로는 사람을 더 많이 넣어서 해결되지 않는다 모든 캐시 삭제와 설정 변경을 사람이 매번 읽으면 결국 승인 버튼은 형식이 된다. 안전을 위해 넣은 사람이 처리량의 병목이 되고, 반복되는 요청에 무심코 동의하게 된다. 해법은 사람을 빼거나 권한을 넓히는 양자택일이 아니다. 낮은 위험의 반복 계획은 정책이 자동 승인할 수 있다. 대상이 staging이고, 비용 한도 안이며, 되돌릴 수 있고, 이미 검증된 행동 조합이라면 결정적 규칙이 승인한다. production 데이터 삭제, 결제, 권한 변경, 되돌리기 어려운 migration처럼 영향이 큰 계획만 사람에게 올린다. 이때 사람은 에이전트의 모든 사고 과정을 읽을 필요가 없다. 변경되는 권한의 diff, blast radius, 검증 결과, rollback 경로, 남은 불확실성을 보면 된다. 승인 인터페이스가 긴 추론문을 보여줄수록 중요한 권한 변화가 묻힐 수 있다. ## Rollback은 실패 뒤의 기능이 아니라 권한의 전제다 Vercel은 immutable deployment가 각 배포를 보존하기 때문에 잘못된 변경을 이전 버전으로 되돌릴 수 있다고 강조한다. 이 구조는 에이전트를 위해 처음 만든 것이 아니지만, 자율 실행의 위험을 낮추는 기반이 된다. 같은 원리는 다른 시스템에도 적용된다. 설정은 이전 값을 보존하고, 데이터 변경은 보상 동작이나 복구 지점을 가지며, 외부 메시지는 초안과 발송을 나누고, 금전 행동은 한도와 취소 가능성을 먼저 확인해야 한다. 되돌릴 수 없는 행동일수록 capability는 더 좁고 승인 증거는 더 강해야 한다. 에이전트의 성능이 좋아질수록 더 넓은 권한을 미리 주고 싶어진다. 그러나 모델의 정답률은 권한 설계를 대체하지 않는다. 아주 드문 오류도 충분히 큰 권한과 만나면 사업을 멈출 수 있다. 반대로 제한된 권한과 빠른 복구가 있으면 완벽하지 않은 모델도 실제 일을 맡을 수 있다. **강력한 에이전트는 모든 일을 할 수 있는 에이전트가 아니다. 승인된 계획만 실행하고, 계획이 끝나면 다시 아무것도 바꿀 수 없는 에이전트다.** --- 주요 출처: Vercel, [Vercel Agent](https://vercel.com/blog/vercel-agent?ref=zerodraftlab.com) 및 [Vercel acquires Better Auth](https://vercel.com/blog/vercel-acquires-better-auth?ref=zerodraftlab.com); Better Auth, [Better Auth is joining Vercel](https://www.better-auth.com/blog/better-auth-joins-vercel?ref=zerodraftlab.com). 별도 principal, read-only 기본, plan-to-permission, short-lived capability, 세 층 권한 검사, Firecracker 기반 Sandbox와 immutable deployment는 Vercel의 공식 설명에 근거합니다. 장애 완화 사례와 제품 효과는 회사가 제시한 자사 시나리오이며 독립적인 보편 성능 측정이 아닙니다. 실행 가능한 계획의 구성, 자동 승인 위험 등급, 권한 상승 금지와 복구 설계는 이를 확장한 이 글의 분석입니다. ### 좋은 하네스는 스킬을 더 붙이지 않는다 URL: https://zerodraftlab.com/better-harness-fewer-skills/ Last updated: 2026-09-15T08:35:37.000Z 같은 AI를 더 잘 쓰는 방법에 대해, 최근 나온 세 개의 숫자는 서로 충돌하는 것처럼 보인다. Impossible Research의 Schema 하네스는 ARC-AGI-3 공개 게임에서 평균 98.98%를 기록했다. 연구팀이 함께 제시한 Claude Code 기준선은 42.83%였다. 새 모델을 학습한 결과가 아니라, 모델이 환경을 관찰하고 가설을 기록하고 다음 행동을 검증하는 실행 구조를 바꾼 결과라고 설명한다. 반면 SWE-Skills-Bench는 AI 코딩 에이전트에 재사용 지침 묶음인 ‘스킬’을 추가해도 49개 중 39개는 통과율을 높이지 못했다고 보고했다. 평균 개선은 1.2%에 불과했고, 세 개는 오히려 성능을 최대 10% 낮췄다. 최악의 경우 통과율은 그대로인데 토큰만 451% 늘었다. 한쪽에서는 모델 바깥의 장치가 성능을 두 배 넘게 끌어올리고, 다른 쪽에서는 모델 바깥에 붙인 장치 대부분이 별 도움이 되지 않는다. 차이는 ‘얼마나 많이 붙였는가’가 아니라 **무엇을 바꿨는가**에 있다. ## 하네스는 실행을 바꾸고 스킬은 문맥을 늘린다 하네스와 스킬은 자주 같은 말처럼 섞인다. 둘 다 모델 가중치 밖에 있고, 모델에게 더 나은 행동을 시키기 때문이다. 그러나 작동하는 층위는 다르다. 스킬은 대체로 “이 일을 할 때는 이렇게 하라”는 지침, 예시, 참고 자료를 컨텍스트에 넣는다. 모델이 이미 아는 일반론을 다시 설명하거나 현재 프로젝트와 맞지 않는 버전의 절차를 주면, 읽어야 할 문맥만 늘고 판단은 흐려진다. SWE-Skills-Bench에서 성능을 해친 스킬도 오래된 지침이 실제 프로젝트 맥락과 충돌한 경우였다. 좋은 하네스는 조언을 더하지 않는다. 모델이 지금 무엇을 알고 있는지 외부 상태로 남기고, 다음 행동이 현실을 어떻게 바꿨는지 다시 보여주며, 예상과 결과가 어긋나면 규칙을 수정하게 한다. 기억해야 할 것을 파일과 로그로 옮기고, 맞았는지 틀렸는지를 테스트로 돌려준다. Schema가 강조하는 것도 이 차이다. 에이전트는 게임 화면을 보고 즉흥적으로 움직이는 대신, 관찰한 개체와 규칙을 실행 가능한 세계 모델로 만든다. 행동 전에 다음 상태를 예측하고, 실제 상태와 비교하며, 틀리면 표현이나 규칙을 고친다. 모델에게 “더 논리적으로 생각하라”는 말을 반복하는 것이 아니라 추론이 반박될 수 있는 고리를 만든다. 98.98%를 범용 지능의 돌파로 읽어서는 안 된다. 이 수치는 ARC-AGI-3 공개 세트 25개 궤적의 평균이며 연구팀의 자체 평가다. 비공개 세트에서도 같은 격차가 유지되는지, 독립 재현에서도 같은 결과가 나오는지는 아직 확인되지 않았다. 그래도 이 사례가 보여주는 운영 원리는 유효하다. 모델의 생각을 믿는 것보다 생각이 현실과 부딪치게 만드는 편이 강하다. ## 비싼 모델의 비용도 토큰 가격보다 구조가 결정했다 Cognition의 Fusion 실험도 같은 방향을 가리킨다. 회사는 FrontierCode 1.1에서 3,000회 자체 평가를 돌려, 비싼 리드 모델이 계획과 판정을 맡고 저렴한 보조 에이전트가 구현을 맡는 구조를 비교했다. Fable 5만 썼을 때는 회당 4.03달러에 60.8점이었지만, Sidekick을 붙이자 1.86달러에 60.7점이었다. 점수는 거의 같고 비용은 54% 줄었다. 핵심은 단순히 싼 모델에게 더 많이 시킨 것이 아니었다. 두 리드 모델의 평균 위임 횟수는 비슷했다. 차이는 언제 무엇을 맡겼는지였다. Fable은 제약, 예외, 완료 조건을 담은 짧은 위임문을 일찍 넘겼고, 결과가 오면 차이를 검토했다. 평균 리드 턴은 11.5회로 Opus의 26.5회보다 적었고, Fable 주도 실행의 81%에서는 리드가 코드를 한 번도 직접 고치지 않았다. 이 역시 모든 작업에 적용되는 공식은 아니다. 짧은 일이나 원인 추적이 한 줄로 이어지는 디버깅은 쪼개서 맡길 부분이 적었다. 좋은 하네스는 무조건 위임하라는 규칙이 아니라, 비싼 판단과 싼 실행의 경계를 작업에 맞게 바꾸는 구조다. 그래서 AI 시스템을 개선할 때 먼저 물어야 할 질문은 “어떤 스킬을 더 설치할까”가 아니다. **모델의 오류를 드러내는 상태, 피드백, 위임, 검증의 고리가 있는가**다. 그렇다면 어떤 스캐폴딩은 남기고, 어떤 스킬은 버려야 하는가? 첫 기준은 그 장치가 모델에게 문장을 더 주는지, 현실에서 온 차이를 돌려주는지다. “계획을 세우고 검토하라”는 지침은 모델이 이미 알고 있을 가능성이 높다. 반면 현재 브랜치, 실패한 테스트, 남은 예산, 직전 승인, 실제 API 응답은 모델이 스스로 알 수 없다. 오래가는 하네스는 일반 지식을 가르치기보다 작업의 현재 상태를 공급한다. 이 기준을 실제 시스템에 적용하면 남겨야 할 구조는 네 층으로 좁혀진다. 상태를 밖에 두고, 실패 가능한 검증을 연결하고, 결과 단위로 위임하며, 권한과 중지 조건을 명시하는 것이다. ## 상태는 대화를 길게 만드는 대신 밖으로 나와야 한다 에이전트가 긴 대화 안에서 모든 사실을 기억하게 하면 컨텍스트가 곧 작업장이 된다. 시간이 갈수록 같은 파일을 다시 읽고, 이미 기각한 가설을 되살리며, 오래된 지시와 새 사실을 한꺼번에 처리한다. 더 큰 컨텍스트 창은 이 문제를 늦출 수 있지만 없애지는 못한다. 좋은 하네스는 상태를 모델 밖의 작은 정본으로 압축한다. 지금의 목표, 이미 확인한 사실, 열린 가설, 실행 결과, 남은 불확실성을 사람이 읽을 수 있고 기계가 갱신할 수 있는 형태로 둔다. 다음 턴에는 전체 대화를 다시 먹이는 대신 이 상태와 필요한 증거만 불러온다. Schema의 실행 가능한 세계 모델은 게임에 맞춘 사례지만, 원리는 코드 작업의 테스트 결과나 영업 에이전트의 고객 상태에도 같다. ## 검증은 ‘한 번 더 생각해’가 아니라 실패 가능한 판정이어야 한다 AI에게 자기 답을 검토하라고 하면 같은 추론을 다른 문장으로 반복할 수 있다. 검증이 되려면 모델의 자신감과 독립된 판정면이 필요하다. 코드는 테스트와 정적 분석, 데이터 파이프라인은 스키마와 합계 불변식, 콘텐츠는 출처·누출·형식 게이트, 외부 실행은 API 읽기 결과와 권한 로그가 그 역할을 한다. 중요한 것은 판정이 다음 행동을 바꾸는 것이다. 오류를 기록만 하고 같은 경로를 계속 실행하면 관찰 도구일 뿐 하네스가 아니다. 예상 상태와 실제 상태의 차이가 표현 수정, 재계획, 중지 가운데 하나로 이어져야 피드백 고리가 닫힌다. ## 위임의 단위는 역할이 아니라 검증 가능한 결과다 “너는 시니어 개발자다” 같은 역할 프롬프트는 위임문이 아니다. 누가 무엇을 판단하고, 무엇을 만들며, 어떤 제약을 지키고, 무엇을 근거로 완료를 판정할지가 있어야 한다. Cognition의 실험에서 비용을 줄인 것은 보조 에이전트의 존재 자체보다 리드가 구현 방법을 받아쓰지 않고 제약과 완료 조건을 건넨 방식이었다. 좋은 위임은 컨텍스트도 분리한다. 보조 에이전트는 맡은 범위의 파일과 증거만 읽고 결과와 검증 기록을 돌려준다. 리드는 모든 세부사항을 자기 컨텍스트로 다시 가져오지 않고 차이와 위험만 본다. 반대로 리드가 보고받은 파일을 전부 다시 읽고 직접 고친다면 멀티에이전트는 병렬성이 아니라 중복 비용이 된다. 여기에는 중지 조건도 포함된다. 권한이 없거나, 같은 실패가 반복되거나, 비용 한도를 넘거나, 가정이 깨졌을 때 사람에게 돌려보내야 한다. 자율성은 계속 움직이는 능력이 아니라 어디서 멈춰야 하는지 아는 경계까지 포함한다. ## 남길 스킬은 모델이 원래 알 수 없는 것을 담는다 SWE-Skills-Bench에서도 모든 스킬이 실패한 것은 아니다. 일곱 개의 전문 스킬은 통과율을 최대 30% 높였다. 범용 모델의 상식으로 대신하기 어려운 특정 도메인의 규칙과 절차를 제공한 경우였다. 이 결과는 스킬을 없애라는 결론보다 스킬이 차지할 자리를 좁혀준다. 남길 가치가 큰 것은 회사 내부 데이터, 개인의 취향, 브랜드 고유 형식, 특정 도구의 접근법, 규제된 절차, 정확한 조직 내 승인 순서다. 공개 인터넷과 모델 가중치에 들어 있을 수 없는 정보다. 반대로 “좋은 글을 쓰는 법”, “버그를 체계적으로 찾는 법”, “코드를 깔끔하게 만드는 법”처럼 일반적인 능력을 보충하는 스킬은 모델 버전이 바뀔 때마다 효용을 다시 증명해야 한다. 스킬에는 유통기한이 있다. 어제 모델의 약점을 고친 지시가 오늘 모델의 더 나은 전략을 방해할 수 있다. 프로젝트 버전이 바뀌면 정확했던 명령도 틀린 명령이 된다. 그래서 스킬 저장소는 지식 자산의 개수로 평가하면 안 된다. 동일 작업을 스킬이 있을 때와 없을 때 돌려 품질, 실패율, 토큰, 시간을 비교하고, 이득을 입증하지 못한 스킬은 제거해야 한다. ## 모델이 바뀌어도 남는 것은 시스템의 학습이다 프런티어 모델은 계속 좋아지고 가격도 바뀐다. 특정 모델의 사고 습관을 장황한 지시로 교정하는 데 투자하면 다음 버전에서 다시 시작할 가능성이 크다. 반면 평가 세트, 결정적 게이트, 상태 정본, 권한 경계, 실행 증거에 투자하면 어떤 모델을 넣어도 비교할 기반이 남는다. 이것이 좋은 하네스가 스킬을 줄이는 이유다. 모델에게 더 많은 방법론을 외우게 하지 않고, 현실을 볼 수 있는 눈과 틀렸을 때 돌아올 길을 만든다. 필요한 전문 지식만 얇게 주고, 나머지는 상태·도구·테스트·권한으로 바깥에 둔다. **AI의 다음 경쟁력은 가장 긴 지침서가 아니다. 가장 빨리 오류를 발견하고, 가장 싸게 일을 나누며, 가장 분명하게 멈출 수 있는 실행 구조다.** --- 주요 출처: Impossible Research, [Schema Harness](https://schema-harness.github.io/?ref=zerodraftlab.com) 및 [ARC-AGI-3 Schema Gameplay Trajectories](https://huggingface.co/datasets/schema-harness/arc-agi-3-schema-traces?ref=zerodraftlab.com); Cognition, [We replaced Opus 4.8 with Fable 5, and Devin’s bill went down](https://cognition.ai/blog/making-fable-cheaper-than-opus?ref=zerodraftlab.com); Tingxu Han 외, [SWE-Skills-Bench](https://arxiv.org/abs/2603.15401?ref=zerodraftlab.com), 2026년 3월 16일 제출; Every, [The Case Against Skills](https://every.to/context-window/the-case-against-skills?ref=zerodraftlab.com). Schema와 Cognition의 수치는 각 연구팀·회사의 공개 세트 자체 평가이며, SWE-Skills-Bench는 소프트웨어 엔지니어링 스킬만 다룬 동료심사 전 프리프린트입니다. 하네스와 스킬의 구분, 상태·검증·위임·중지의 네 층은 이 증거를 바탕으로 한 이 글의 분석입니다. ### 크리에이터는 매체가 되었고 AI는 제작실이 되었다 URL: https://zerodraftlab.com/creators-became-media-ai-became-studio/ Last updated: 2026-09-15T08:35:37.000Z 한때 크리에이터 마케팅은 광고 캠페인의 부속물이었다. 매체 예산을 먼저 정하고, 남는 돈으로 인플루언서 몇 명에게 제품을 보냈다. 크리에이터는 메시지를 전달하는 사람이고 플랫폼은 그 메시지를 유통하는 매체였다. 2026년에는 이 순서가 뒤집히고 있다. IAB는 미국 크리에이터 광고비가 2025년 370억 달러에서 2026년 440억 달러로 늘어날 것으로 전망했다. 광고 구매자의 48%는 크리에이터를 이미 ‘반드시 사야 하는’ 채널로 본다. KOBACO의 국내 전망에서도 온라인 광고는 전체 광고비의 약 60%를 차지하고, 방송광고가 줄어드는 사이 예산은 OTT·YouTube·숏폼처럼 성과를 더 빨리 확인할 수 있는 디지털 접점으로 이동한다. **크리에이터는 더 이상 매체에 들어갈 소재만 만드는 사람이 아니다. 주제, 청중, 배포, 신뢰, 피드백을 함께 보유한 작은 매체가 되었다.** ## 매체의 최소 단위가 채널에서 관계로 바뀐다 전통적인 매체 구매는 지면이나 시간대를 산다. 같은 공간에 여러 광고주가 들어가고, 매체사는 도달과 문맥을 제공한다. 크리에이터는 이 기능을 한 사람 또는 작은 팀 안에 압축한다. 누구에게 어떤 어조로 말할지 알고, 댓글과 메시지에서 반응을 읽으며, 다음 콘텐츠를 바로 수정한다. 이 구조에서 팔로워 수는 매체력의 일부일 뿐이다. 특정 문제를 반복해서 다뤄 얻은 기대, 추천을 받아들일 이유, 구매 뒤에도 이어지는 대화가 더 중요하다. 팔로워 100만 명의 넓은 계정보다 구매 상황이 선명한 3만 명의 커뮤니티가 더 나은 매체일 수 있다. 플랫폼도 원본에 더 큰 가치를 부여한다. Meta는 2025년 4분기 미국 Instagram 추천의 75%가 원본 게시물에서 발생했다고 밝혔다. 플랫폼의 자기보고이고 다른 플랫폼이나 시장 전체를 대표하지는 않지만, 복제물을 무한히 늘리는 시대일수록 원본을 만든 주체와 그 주체를 기다리는 청중이 희소해진다는 방향은 분명하다. ## AI는 크리에이터를 없애기보다 제작 병목을 없앤다 AI가 가장 빠르게 낮추는 비용은 평균적인 소재의 제작비다. 긴 영상에서 짧은 클립을 만들고, 후킹 문장을 여러 개 시험하고, 화면 비율과 언어를 바꾸는 일은 이미 훨씬 싸졌다. IAB 조사에서도 브랜드의 4분의 3이 크리에이터 마케팅 업무에 AI를 사용하거나 사용할 계획이라고 답했다. 2026년 광고 구매자의 AI 사용 의향은 분석과 소재 최적화에서 높고, 크리에이터와의 협상이나 거래 실행에서는 더 낮다. 이 차이는 AI의 자리를 보여준다. AI는 관계를 대신하는 대변인보다 원본을 증폭하는 제작실에 가깝다. 크리에이터가 한 번의 촬영으로 주장, 경험, 표정, 제품 사용 맥락을 만들면 AI는 이를 숏폼, 정지 이미지, 자막, 상품 상세, 광고 변형으로 확장한다. 원본의 신뢰는 사람과 커뮤니티에서 나오고 생산 속도는 모델과 워크플로에서 나온다. 따라서 승부는 누가 가장 많은 생성물을 뽑느냐가 아니다. 모두가 비슷한 속도로 변형물을 만들 수 있게 되면 차이는 원본의 질, 배포 관계, 상품 정보, 구매 뒤의 경험에서 생긴다. AI가 공급을 무한히 늘릴수록 신뢰할 수 있는 목소리와 검증 가능한 원자료의 가격은 오히려 올라간다. ## 크리에이터 광고는 콘텐츠 비용이 아니라 유통 자산 구매다 브랜드가 영상 한 편만 납품받으면 크리에이터를 비싼 외주 제작자로 쓴 것이다. 매체로 대하려면 그 사람이 가진 청중의 문제, 콘텐츠의 반복 형식, 배포 시점, 댓글에서 드러나는 반론, 구매로 이어지는 경로를 함께 설계해야 한다. 조회수는 결과의 한 조각이고 관계의 학습이 다음 집행으로 남아야 한다. 여기서 브랜드의 불안도 커진다. 관계는 크리에이터와 플랫폼에 있고, 브랜드에는 편집된 파일과 캠페인 보고서만 남을 수 있다. 플랫폼 알고리즘이 바뀌거나 크리에이터가 떠나면 쌓았다고 믿었던 자산이 사라진다. 그렇다면 브랜드는 무엇을 직접 소유해야 하는가? 브랜드가 직접 소유해야 하는 것은 크리에이터의 청중이 아니라 **원본, 권리, 상품 데이터, 실험 이력, 고객 반응을 다시 연결할 수 있는 운영 정본**이다. 사람을 소유할 수는 없지만 어떤 주장과 장면이 어떤 구매 상황에서 작동했는지는 축적할 수 있다. 이 정본이 있어야 크리에이터라는 매체와 AI라는 제작실이 일회성 캠페인이 아니라 반복 가능한 성장 시스템이 된다. ## 한 명의 스타보다 역할이 다른 포트폴리오를 산다 크리에이터를 매체로 본다면 선정 기준도 유명세에서 매체 적합도로 바뀐다. 첫 번째는 문제 발견형이다. 아직 제품명을 모르는 사람에게 새로운 질문을 만들고 카테고리를 설명한다. 두 번째는 증명형이다. 실제 사용 과정, 비교, 실패 조건을 보여줘 불확실성을 줄인다. 세 번째는 전환형이다. 혜택, 재고, 배송, 사용법을 구매 직전의 언어로 정리한다. 네 번째는 유지형이다. 구매 후 활용법과 커뮤니티 대화를 통해 재구매와 추천을 만든다. 한 사람이 네 역할을 모두 잘할 필요는 없다. 오히려 한 명에게 도달, 신뢰, 전환, 고객지원을 동시에 요구하면 콘텐츠가 광고 문구로 평평해진다. 포트폴리오는 크리에이터 수를 늘리는 방식이 아니라 구매 여정의 서로 다른 불확실성을 각기 다른 목소리가 줄이게 하는 방식으로 구성해야 한다. 예산도 게시물 단가만으로 비교하면 안 된다. 작은 크리에이터가 만든 상세한 사용 장면이 광고 변형 열 개와 상품 페이지 두 곳에서 오래 쓰인다면, 대형 계정의 한 번 노출보다 더 많은 생산 자산을 남길 수 있다. 반대로 도달은 컸지만 사용 권리와 원본 파일, 댓글 학습을 확보하지 못했다면 캠페인 종료와 함께 가치가 사라진다. ## 원본과 파생물을 분리해야 AI 제작실이 작동한다 AI를 제작실로 쓰려면 먼저 무엇을 바꾸면 안 되는지 정해야 한다. 크리에이터가 직접 경험한 사실, 제품을 사용한 조건, 핵심 주장, 고유한 표현, 법적 고지는 원본 층이다. 길이, 자막, 비율, 첫 장면, 썸네일, 언어, 상품별 후반부는 파생 층이다. 원본을 승인한 뒤 파생 층만 빠르게 변형하면 속도와 책임을 함께 얻을 수 있다. 이 구분이 없으면 AI는 없는 사용 경험을 만들거나, 한 사람의 말을 다른 제품에 옮기거나, 성과가 좋았던 표현을 맥락 없이 복제한다. 합성 UGC가 진짜 후기처럼 보이는 순간 단기 클릭은 얻어도 매체의 핵심 자산인 신뢰를 소모한다. AI 아바타와 인간 크리에이터가 같은 출력 포맷을 쓴다고 해서 같은 매체가 되는 것은 아니다. 한쪽은 생성 가능한 표현이고 다른 한쪽은 시간에 걸쳐 형성된 관계다. 실무적으로는 각 원본에 촬영자, 동의 범위, 사용 기간, 허용 채널, 제품 버전, 근거 링크, 금지 변형을 붙여야 한다. 파생물에는 어떤 원본과 프롬프트, 편집 규칙, 승인에서 나왔는지 연결한다. 그래야 성과가 난 소재를 안전하게 확장하고, 계약이 끝난 소재를 정확히 회수할 수 있다. ## 콘텐츠와 상품 데이터가 같은 약속을 해야 한다 크리에이터가 말한 가격, 구성, 효능, 배송 조건이 실제 상품 정보와 다르면 매체의 신뢰와 전환이 동시에 깨진다. 그래서 AI 제작실은 영상 도구만으로 완성되지 않는다. 재고, 가격, 옵션, 정책, 근거, 캠페인 코드를 읽을 수 있는 상품 정본과 연결돼야 한다. 좋은 연결은 모든 영상에 링크를 붙이는 수준을 넘는다. 어떤 크리에이터의 어떤 주장이 어떤 상품 속성과 연결되는지, 사용자가 어느 장면 뒤에 상세 정보를 찾았는지, 구매 뒤 어떤 질문을 남겼는지 이어져야 한다. 콘텐츠는 사람의 관심을 만드는 표면이고 상품 데이터는 그 약속을 실행 가능한 선택으로 바꾸는 표면이다. Criteo의 한국 설문에서 응답자의 76%는 AI 환경에서도 브랜드 차별성을 중요하게 봤지만, AI를 주된 쇼핑 수단으로 쓴다는 응답은 7%였다. 광고·커머스 사업자의 자체 설문이라 전체 소비자 행동으로 일반화할 수는 없다. 다만 발견 방식이 자동화돼도 구매는 한동안 기존 검색, 플랫폼, 상세 페이지, 오프라인 경험과 섞인다는 점은 시사한다. 크리에이터와 AI를 하나의 새 채널로 격리하지 말고 실제 상품 경험과 연결해야 하는 이유다. ## 조회수가 아니라 증분과 재사용 가치를 함께 측정한다 크리에이터를 매체로 평가하면서 마지막 클릭만 보면 과소평가하고, 조회수만 보면 과대평가한다. 최소한 세 층을 나눠야 한다. 배포 층에서는 도달, 시청 유지, 저장, 검색 증가를 본다. 설득 층에서는 댓글의 질문, 브랜드 직접 유입, 장바구니, 신규 고객 비중을 본다. 경제 층에서는 증분 전환, 기여이익, 반품, 재구매를 본다. 여기에 제작 자산의 재사용 가치가 추가된다. 한 원본에서 몇 개의 유효한 파생물이 나왔고, 서로 다른 지면에서 얼마나 오래 성과를 냈으며, 새 촬영 없이 어떤 학습을 재사용했는지 기록한다. 그러면 크리에이터 비용을 일회 노출비와 원본 자산비로 분리해 판단할 수 있다. Meta는 자사의 새 증분 어트리뷰션 모델이 표준 어트리뷰션보다 증분 전환을 24% 더 포착했다고 밝혔다. 이것도 플랫폼 자기보고이므로 독립된 인과효과로 받아들일 수는 없다. 중요한 방향은 플랫폼이 보고하는 전환 수를 그대로 합산하지 않고, 실험군과 비교군, 지역 또는 기간 홀드아웃, 신규 고객과 기존 고객을 나눠 실제 추가 효과를 묻는 것이다. ## 플랫폼 의존을 피할 수는 없지만 학습의 소유권은 정할 수 있다 크리에이터 매체론의 가장 강한 반론은 매체가 실제로 크리에이터가 아니라 플랫폼이라는 것이다. 추천 알고리즘, 계정 정책, 광고 상품, 데이터 접근을 플랫폼이 통제하기 때문이다. 이 반론은 맞다. 크리에이터는 독립 방송국이 아니라 임대한 유통망 위에서 움직이는 매체다. 그래서 해법은 플랫폼을 떠나는 것이 아니라 의존성을 분리하는 것이다. 도달은 플랫폼에서 빌리되 원본과 권리는 보존하고, 고객이 동의한 관계는 자사 채널로 연결하며, 상품 정보와 실험 이력은 자체 정본에 남긴다. 한 플랫폼의 조회수를 다른 플랫폼의 자산으로 착각하지 않는다. 2026년의 대세는 인간 크리에이터 대 AI 크리에이터의 승부가 아니다. **신뢰와 배포를 가진 인간 매체가 원본을 만들고, AI 제작실이 그 원본을 빠르게 변형하며, 브랜드의 상품 정본과 측정 체계가 약속과 경제성을 지키는 결합**이다. 이 셋 중 하나만 사면 캠페인이 되고, 셋을 연결하면 운영체계가 된다. --- 주요 출처: IAB, [2025 Creator Economy Ad Spend & Strategy Report](https://www.iab.com/insights/2025-creator-economy-ad-spend-strategy-report/?ref=zerodraftlab.com) 및 [2026 Outlook Study](https://www.iab.com/wp-content/uploads/2026/01/IAB%5F2026%5FOutlook%5FStudy%5FJanuary%5F2026.pdf?ref=zerodraftlab.com); Meta, [2026: AI Drives Performance](https://about.fb.com/news/2026/01/2026-ai-drives-performance/?ref=zerodraftlab.com); KOBACO, [2025 광고시장 결산 및 2026 전망](https://www.kobaco.co.kr/flexer/out/uploadfile/asa/board/news/article/2026/02/46dfa41a2e7b7f8c067c07649fdfe35f.hwp.files/Sections1.html?ref=zerodraftlab.com); Criteo, [2026 Commerce and AI Trends Report](https://www.criteo.com/kr/news/press-releases/2026/06/criteo-releases-2026-commerce-and-ai-trends-report/?ref=zerodraftlab.com). IAB 수치는 미국 시장 조사, Meta 성과 수치는 플랫폼 자기보고, Criteo 수치는 광고·커머스 사업자의 설문입니다. 크리에이터 포트폴리오, 원본·파생물 구분, 상품 정본, 측정 구조는 이 근거를 바탕으로 한 글의 운영 분석입니다. ### AI가 죽인 것은 MVP가 아니라 허접한 출시다 URL: https://zerodraftlab.com/ai-killed-shoddy-launches-not-mvp/ Last updated: 2026-09-15T08:35:38.000Z AI로 앱 하나를 만드는 비용이 낮아지자 오래된 제품 개발 원칙 하나가 다시 공격받고 있다. 이제 기능만 작동하는 MVP로는 아무도 관심을 주지 않으니, 사용자가 처음부터 사랑할 수 있는 MLP를 만들어야 한다는 주장이다. MLP는 Minimum Lovable Product의 약자다. 제품이 기능적으로 작동하는 데서 멈추지 않고 빠르고, 직관적이고, 의견이 있으며, 사용자가 다시 찾고 싶은 감정을 남기는 가장 작은 버전을 뜻한다. Elena Verna는 2026년 2월 글에서 이를 AI 시대의 새로운 기준선으로 제시했다. 문제의식은 정확하다. 소프트웨어를 만드는 사람이 늘고 경쟁자가 기능을 따라잡는 속도가 빨라지면 ‘이 기능도 있습니다’만으로는 선택받기 어렵다. 그러나 여기서 MVP가 죽었다는 결론으로 넘어가면 서로 다른 두 가지를 같은 것으로 착각하게 된다. ## MVP는 원래 허접한 출시 제품이 아니었다 Eric Ries가 정의한 MVP는 최소한의 노력으로 고객에 관한 최대한의 검증된 학습을 얻기 위한 제품 버전이다. 공개 시장에서 오래 운영할 첫 제품의 품질 기준이 아니라, 가장 위험한 가정을 가장 빨리 시험하는 학습 도구다. Ries도 MVP는 최소한의 제품을 만드는 이야기가 아니라고 명시했다. 예를 들어 사람들이 온라인으로 신발을 살지 확인하려는 팀은 물류센터와 재고 시스템부터 만들 필요가 없다. 매장에 있는 신발을 촬영해 주문을 받은 뒤 사람이 직접 구매하고 배송해도 수요 가설은 시험할 수 있다. 이 실험이 투박해 보인다고 해서 학습의 질까지 낮은 것은 아니다. MVP가 나쁜 평판을 얻은 이유는 이 실험물을 공개 출시 제품으로 둔갑시켰기 때문이다. 내부 가설 검증에 쓸 임시 구조를 고객에게 계속 사용하게 만들고, 불편을 ‘아직 MVP라서’라고 설명했다. 죽어야 하는 것은 MVP가 아니라 학습하지 않는 제품을 MVP라고 부르는 습관이다. ## MLP도 AI가 만든 새 개념은 아니다 Aha!는 공동창업자 Brian de Haaff가 2013년에 Minimum Lovable Product 개념을 소개했다고 밝힌다. AI 코딩 도구가 등장하기 훨씬 전부터 제품팀은 작지만 완결되고, 좁지만 강한 첫 경험을 만들자는 언어를 찾고 있었다. AI가 바꾼 것은 개념보다 배경이다. 예전에는 기본 기능을 구현하는 일 자체가 희소했다. 지금은 프로토타입과 평범한 CRUD 앱을 만드는 시간이 크게 줄었고, 시장에는 비슷한 기능을 가진 제품이 더 빨리 쌓인다. 구현의 희소성이 낮아질수록 선택, 신뢰, 취향, 오류를 처리하는 방식의 가치가 커진다는 진단은 타당하다. 다만 개발비가 사라졌다고 말하기에는 증거가 부족하다. Verna가 든 \`$200K\`에서 \`$20\` 또는 \`$100\`으로의 변화와 코드의 90% 이상을 AI가 작성한다는 수치에는 비교 기준과 출처가 없다. 화면을 생성하는 비용, 안전하게 운영하는 비용, 고객이 계속 쓰게 만드는 비용이 한 숫자에 섞여 있다. 실측 결과도 단순하지 않다. METR의 2025년 무작위 통제실험에서 익숙한 저장소를 다룬 숙련 개발자들은 AI를 사용할 때 작업 완료가 19% 느려졌다. 2026년 후속 조사에서 연구진은 최신 AI가 더 큰 속도 향상을 만들 가능성을 인정했지만, AI 없이 일하기를 거부한 참가자의 이탈과 동시 에이전트 사용 때문에 현재 효과의 크기를 신뢰성 있게 측정하지 못했다고 밝혔다. **AI는 코드를 만드는 한계비용을 낮췄지만, 무엇을 만들어야 하는지 배우는 비용까지 없애지는 않았다.** 오히려 만들 수 있는 것이 많아질수록 잘못된 가설을 빠르게 제품으로 만드는 위험도 커진다. 그래서 AI 시대에도 MVP는 필요하다. 동시에 시장에 공개할 첫 경험은 더 이상 실험의 투박함을 변명으로 삼을 수 없다. 그렇다면 언제까지 실험하고, 어느 순간부터 사랑받을 만한 제품을 만들어야 하는가? 답은 MVP와 MLP를 경쟁시키지 않고 서로 다른 단계의 산출물로 두는 데 있다. MVP는 불확실성을 줄이는 실험이고, MLP는 확인된 문제를 고객이 반복해서 해결할 수 있게 만든 첫 시장 경험이다. 전자는 버려질 수 있어야 하고, 후자는 관계의 시작을 견딜 수 있어야 한다. ## 실험은 거칠어도 되지만 거짓이어서는 안 된다 MVP의 완성도는 화면의 광택이 아니라 가설을 얼마나 정확히 검증하는지로 판단해야 한다. 랜딩페이지, 수작업 컨시어지, 클릭되지 않는 프로토타입도 적절한 참가자와 명확한 측정 기준이 있다면 좋은 MVP가 될 수 있다. 반대로 멋진 AI 앱을 일주일 만에 만들었더라도 누구의 어떤 행동을 검증하는지 모르면 비싼 의견에 불과하다. 거칠다는 말도 사용자를 속이거나 위험을 떠넘겨도 된다는 뜻은 아니다. 결제, 개인정보, 의료·금융 판단처럼 실패 비용이 큰 영역에서는 실험 범위와 한계를 밝혀야 한다. 학습을 위해 품질을 줄일 수는 있지만 안전과 진실성까지 줄일 수는 없다. ## MLP의 최소 단위는 장식이 아니라 완결성이다 가설이 확인된 뒤에는 질문이 달라진다. 이제는 ‘사람들이 원하는가’가 아니라 ‘사람들이 이 제품을 믿고 다시 사용할 수 있는가’를 물어야 한다. 이때 필요한 것이 MLP다. Lovable을 confetti, 이스터에그, 부드러운 애니메이션으로 이해하면 또 다른 오해가 생긴다. 조달 시스템의 사용자가 사랑할 경험과 음악 앱의 사용자가 사랑할 경험은 다르다. 업무 제품에서 lovability는 빠른 응답, 예측 가능한 동작, 실수에서 복구되는 흐름, 사용자의 언어를 아는 기본값, 불필요한 승인을 줄이는 의견 있는 설계일 수 있다. 브랜드 사랑 연구도 같은 방향을 가리킨다. 만족, 자기 정체성과의 적합성, 개인적 경험, 기능적·감각적 고유성은 브랜드 사랑과 연결된다. 그러나 감정이 곧 사업 성과라는 결론은 경계해야 한다. 한 실험 연구에서는 구매하거나 충성 행동을 하지 않아도 브랜드를 사랑한다고 느끼는 소비자가 존재했다. 좋아한다는 말과 다시 쓰고 돈을 내는 행동은 다르다. 따라서 MLP는 감정 형용사로 승인하면 안 된다. 사용자가 핵심 과업을 끝냈는지, 다시 돌아왔는지, 대안을 두고도 선택했는지, 다른 사람에게 추천했는지, 실제로 비용을 지불했는지로 확인해야 한다. 사랑은 관찰해야 할 가설이지 출시 회의에서 선언할 수 있는 상태가 아니다. ## AI가 옮긴 병목은 구현에서 판단으로 간다 코드 생성이 빨라질수록 제품팀의 일은 줄어드는 것이 아니라 이동한다. 어떤 고객을 고를지, 어떤 문제를 버릴지, 생성된 선택지 가운데 무엇을 남길지, 실패를 어떻게 복구할지, 품질을 어디서 결정적 검사로 보장할지가 더 중요해진다. 기능을 복제하기 쉬운 시장에서도 감정 그 자체가 마지막 해자는 아니다. 말투와 애니메이션은 복사할 수 있다. 더 오래 남는 것은 제품이 축적한 신뢰, 사용자의 작업 이력, 팀의 습관에 들어간 위치, 데이터와 커뮤니티, 문제가 생겼을 때의 복구 경험이다. Lovability는 이 자산을 만들기 시작하는 방식이지 자산 자체는 아니다. 에이전트용 제품은 감정이 필요 없고 MCP 연결만 있으면 된다는 주장도 절반만 맞다. 에이전트는 기쁨을 느끼지 않지만 명확한 스키마, 안정된 응답, 예측 가능한 오류, 재시도 가능성, 관찰 가능한 결과가 필요하다. 그리고 어떤 도구에 권한과 예산을 줄지는 결국 인간 운영자가 결정한다. 인간용 제품의 신뢰성이 감정과 복구 경험으로 드러난다면, 에이전트용 제품의 신뢰성은 인터페이스와 실행 기록으로 드러난다. ## AI 시대의 제품 순서는 세 단계다 먼저 MVP로 가장 위험한 가정을 싸게 반증한다. 수요가 확인되면 좁은 고객과 한 가지 핵심 과업을 위해 MLP를 만든다. 그리고 출시 뒤에는 호감이 아니라 반복 사용과 지불 행동으로 사랑을 검증한다. 이 순서를 건너뛰고 바로 MLP를 만들면 아무도 원하지 않는 경험을 아름답게 완성할 수 있고, MVP에 머물면 고객에게 실험실 장비를 계속 사용하게 만든다. **AI 시대에 필요한 것은 MVP를 버리는 일이 아니다. 실험과 제품을 다시 구분하는 일이다.** 코드는 더 싸게 만들 수 있게 됐다. 그래서 무엇을 배워야 하는지와 무엇을 끝까지 책임져야 하는지를 구분하는 판단은 더 비싸졌다. --- 주요 출처: GeekNews, [Minimum Lovable Product의 시대](https://news.hada.io/topic?id=27336&ref=zerodraftlab.com); Elena Verna, [The Minimum Lovable Product Era](https://www.elenaverna.com/p/the-minimum-lovable-product-era?ref=zerodraftlab.com); Lean Startup Co., [What Is an MVP? Eric Ries Explains](https://leanstartup.co/resources/articles/what-is-an-mvp/?ref=zerodraftlab.com); Aha!, [What is a Minimum Lovable Product?](https://www.aha.io/roadmapping/guide/plans/what-is-a-minimum-lovable-product?ref=zerodraftlab.com); METR, [Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity](https://arxiv.org/abs/2507.09089?ref=zerodraftlab.com) 및 [2026 productivity experiment update](https://metr.org/blog/2026-02-24-uplift-update/?ref=zerodraftlab.com); Rahman·Langner·Temme, [Brand love](https://link.springer.com/article/10.1057/s41262-021-00237-7?ref=zerodraftlab.com); Robertson 외, [How deep is your love?](https://www.sciencedirect.com/science/article/pii/S014829632200491X?ref=zerodraftlab.com). AI 개발비와 코드 비중의 구체적 수치는 원문 저자의 주장으로만 다뤘으며 일반 사실로 사용하지 않았습니다. ### 오픈웨이트는 더 이상 할인 쿠폰이 아니다 URL: https://zerodraftlab.com/open-weights-are-not-a-discount/ Last updated: 2026-09-15T08:35:39.000Z 오픈 모델이 나오면 가격이 내려간다는 기대가 있다. 가중치를 내려받아 직접 돌릴 수 있고, 여러 추론 사업자가 같은 모델을 서비스하며 경쟁할 수 있기 때문이다. 지난 몇 년 동안 ‘오픈’과 ‘저렴함’이 함께 움직인 이유다. Kimi K3는 이 익숙한 등식을 흔든다. Kimi는 2026년 7월 17일 K3를 2조8,000억 파라미터, 100만 토큰 컨텍스트, 네이티브 비전을 갖춘 모델로 발표했다. Mixture of Experts 구조라서 한 번의 추론에 896개 전문가를 모두 쓰는 것은 아니고 16개를 활성화한다. 그래도 회사가 권장하는 배포 환경은 가속기 64개 이상의 supernode다. 여기서 중요한 날짜가 하나 있다. Kimi는 전체 가중치를 7월 27일까지 공개하겠다고 했고, 아키텍처·학습·평가의 세부사항도 기술보고서와 함께 내놓겠다고 밝혔다. 이 글을 쓰는 7월 18일 현재 K3는 가중치 공개가 완료된 모델이 아니라 **공개가 예고된 모델**이다. 공개 후의 실제 서빙 비용과 제3자 사업자의 가격 경쟁도 아직 관찰되지 않았다. ## 파일이 열려 있다고 운영이 열리는 것은 아니다 가중치를 받을 수 있다는 것과 그 모델을 안정적으로 운영할 수 있다는 것은 다른 권리다. 첫 번째는 접근권이다. 두 번째는 하드웨어, 서빙 소프트웨어, 캐시, 네트워크, 장애 대응, 모델에 맞는 에이전트 하네스를 함께 갖춰야 얻는 실행 능력이다. 용어도 구분해야 한다. Open Source Initiative는 최종 가중치만 공개된 상태를 Open Source AI와 같게 보지 않는다. 시스템을 사용하고 연구하고 수정하고 공유할 실질적 자유를 가지려면 가중치뿐 아니라 학습 코드와 데이터 정보 등 수정에 필요한 재료가 함께 있어야 한다는 기준이다. Kimi는 K3를 ‘open 3T-class model’이라고 부르지만, 기술보고서와 실제 공개물을 보기 전까지는 OSI 기준의 오픈소스 AI라고 단정할 수 없다. 가격표도 같은 층위를 보여준다. Kimi 공식 API는 캐시 적중 입력 100만 토큰당 0.30달러, 캐시 미적중 입력 3달러, 출력 15달러다. 회사는 공식 코딩 워크로드에서 캐시 적중률이 90%를 넘는다고 말한다. 그러나 긴 코딩 세션의 높은 캐시 적중률을 모든 업무에 그대로 적용할 수는 없다. 사용자의 프롬프트 구성, 반복되는 컨텍스트, 출력 비중에 따라 실제 비용은 달라진다. Clouded Judgement는 입력 80%, 출력 20%라는 가정으로 이 가격을 100만 토큰당 5.40달러로 환산했다. 이는 공식 표준 가격이 아니라 분석자의 가정이다. 그래도 질문은 남는다. 가중치가 공개되면 비용은 자동으로 낮아지는가? 그렇지 않다. 오픈웨이트는 비용을 없애지 않고 **비용을 선택할 권리**를 만든다. 공식 API를 쓰거나, 다른 추론 사업자를 고르거나, 충분한 인프라가 있다면 직접 운영할 수 있다. 폐쇄형 모델에서는 공급자의 가격과 정책을 받아들여야 하지만, 오픈웨이트에는 이탈 경로가 생긴다. 오픈의 핵심 가치는 할인 쿠폰보다 탈출권에 가깝다. 그렇다면 Kimi K3 같은 거대 오픈웨이트는 실제로 누구의 힘을 키우는가? 첫 번째 수혜자는 개인 개발자가 아니라 대규모 추론 인프라를 가진 사업자다. 누구나 같은 가중치에 접근할 수 있어도 64개 이상의 가속기, 새로운 어텐션 구조에 맞는 서빙 스택, 긴 컨텍스트를 감당할 캐시와 네트워크를 운영할 수 있는 곳은 제한적이다. 모델 회사의 독점은 약해질 수 있지만, 구현 능력은 다시 소수 인프라 사업자에게 모인다. ## 오픈은 독점을 없애지 않고 위치를 옮긴다 폐쇄형 API에서는 모델 회사가 지능과 서빙을 묶어 판다. 오픈웨이트에서는 둘을 분리할 수 있다. 같은 모델을 여러 사업자가 제공하면 가격, 지연시간, 데이터 보관 위치, 지원하는 하네스를 두고 경쟁이 생긴다. 이 경쟁은 분명한 이점이다. 하지만 모델이 커질수록 경쟁의 입장권도 비싸진다. ‘누구나 서비스할 수 있다’는 문장은 ‘대형 클러스터와 최적화 인력을 가진 누구나 서비스할 수 있다’로 바뀐다. 지능의 파일은 공개돼도 그것을 경제적으로 실행하는 시장은 집중될 수 있다. 오픈은 권력을 평평하게 만들기보다 모델 연구소에서 클라우드와 추론 플랫폼으로 옮길 가능성이 있다. ## 기업이 사는 것은 싼 토큰이 아니라 협상력이다 그렇다고 거대 오픈웨이트가 무의미한 것은 아니다. 대기업과 규제 산업에는 모델을 반드시 사내에서 돌리는 것보다 **돌릴 수 있는 선택권** 자체가 가치가 있다. 데이터 주권 문제가 생기면 전용 환경으로 옮길 수 있고, 공식 API 가격이 오르면 다른 공급자를 검토할 수 있으며, 특정 정책 변경이 업무를 막으면 호환되는 서빙 경로를 만들 수 있다. 이 선택권은 보험과 비슷하다. 평소에는 공식 API가 더 싸고 편할 수 있다. 직접 운영하지 않더라도 대안이 존재하면 한 공급자와의 협상에서 완전히 잠기지 않는다. 따라서 오픈웨이트의 경제성은 현재 청구서만이 아니라 전환 비용, 공급자 집중 위험, 데이터 통제, 서비스 중단 때의 복구 경로를 포함해 평가해야 한다. 다만 선택권과 실행 가능성을 혼동하면 안 된다. 가중치 파일을 보유하고 있다는 사실만으로 공급망 독립이 생기지 않는다. 실제로 다른 환경에서 모델을 띄워보고, 사용하는 에이전트 하네스와의 호환성을 확인하고, 품질과 비용을 측정해야 탈출권이 작동한다. Kimi도 K3가 생각 이력을 보존하지 않는 하네스에서 불안정해질 수 있고, 모호한 지시에서 예상 밖의 결정을 내릴 수 있다고 경고한다. 모델의 공개성은 운영 검증을 대신하지 않는다. ## 아직 비용 하락 가능성은 열려 있다 가중치가 공개된 뒤 제3자 사업자가 공식 API보다 낮은 가격을 제시할 수 있다. 양자화와 커널 최적화, 캐시 개선이 진행되면 64개 권장 구성도 유일한 운영 방식으로 남지 않을 수 있다. Kimi는 새로운 어텐션 구조를 위한 vLLM 구현도 모델과 함께 공개할 예정이라고 밝혔다. 오픈 생태계의 강점은 출시 시점의 비용을 영구적인 하한선으로 두지 않는 데 있다. 그래서 K3에 대한 결론은 아직 조건부여야 한다. 가중치와 기술보고서가 실제로 공개되고, 라이선스와 재현 정보가 확인되며, 여러 추론 사업자의 가격과 품질이 나온 뒤에야 ‘얼마나 열린 모델인가’와 ‘얼마나 싸게 운영할 수 있는가’를 따로 평가할 수 있다. 지금 확실한 것은 둘이 같은 질문이 아니라는 사실이다. 앞으로 오픈 모델을 고를 때는 API 가격 한 줄보다 네 가지 비용을 함께 봐야 한다. 공식 서비스를 계속 쓸 비용, 다른 공급자로 옮길 비용, 직접 운영할 최소 인프라, 운영권을 실제로 유지하기 위한 검증 비용이다. 이 가운데 하나라도 빠지면 ‘오픈이니까 싸다’는 결론은 마케팅 문구에 머문다. **Kimi K3가 보여준 것은 오픈 모델의 실패가 아니다. 공개된 지능의 가치가 무료 사용권이 아니라 공급망을 선택할 권리로 이동하고 있다는 사실이다.** --- 주요 출처: Kimi, [Kimi K3: Open Frontier Intelligence](https://www.kimi.com/blog/kimi-k3?ref=zerodraftlab.com); Open Source Initiative, [The Open Source AI Definition 1.0](https://opensource.org/ai/open-source-ai-definition?ref=zerodraftlab.com) 및 [Open Weights: not quite what you’ve been told](https://opensource.org/ai/open-weights?ref=zerodraftlab.com); Clouded Judgement, [Open Weights, Closed Prices?](https://cloudedjudgement.substack.com/p/clouded-judgement-71726-open-weights). K3의 모델 사양, 공개 일정, 권장 배포 구성과 API 가격은 회사 발표에 따른다. 5.40달러 환산은 입력 80%·출력 20%를 가정한 보조 분석이며, 가중치·기술보고서·제3자 서빙 가격이 나오기 전의 잠정 해석이다. ### 에이전틱 마케팅의 대부분은 아직 에이전틱하지 않다 URL: https://zerodraftlab.com/most-agentic-marketing-is-not-agentic/ Last updated: 2026-09-15T08:35:40.000Z 2026년의 마케팅 도구는 거의 모두 에이전틱하다고 말한다. 캠페인 이름을 입력하면 소재를 만들고, 성과를 요약하고, 입찰을 조정하는 기능에 ‘에이전트’가 붙는다. 자동화보다 새롭고 코파일럿보다 강해 보이는 이름이기 때문이다. 하지만 버튼 한 번으로 여러 작업을 실행한다고 에이전트가 되는 것은 아니다. 정해진 규칙을 반복하면 자동화이고, 사람이 요청할 때 답을 만들면 코파일럿이며, 고정된 순서로 도구를 연결하면 워크플로다. 에이전트는 실행 중 현실을 보고 다음 행동을 다시 선택해야 한다. **에이전틱 마케팅의 대부분은 아직 에이전틱하지 않다. 그렇다고 쓸모없다는 뜻은 아니다.** 이름을 정확히 붙여야 기대, 권한, 측정, 책임을 실제 능력에 맞출 수 있다는 뜻이다. ## 자동화는 경로를 알고 에이전트는 경로를 찾는다 예산이 기준을 넘으면 알림을 보내고, 승인된 소재를 정해진 시간에 업로드하는 흐름은 자동화다. 입력과 경로가 안정적이면 에이전트보다 싸고 빠르고 예측 가능하다. 여기에 모델을 넣어도 경로가 고정돼 있다면 생성형 워크플로에 가깝다. 코파일럿은 사람의 판단을 증폭한다. 보고서를 요약하고, 카피 대안을 만들고, 쿼리를 작성하지만 다음 목표를 스스로 정하지 않는다. 사람이 매 단계 요청하고 결과를 선택한다. 이것도 큰 가치가 있지만 자율 운영과는 다르다. 에이전트는 “신규 고객의 기여이익을 늘려라” 같은 목표 아래 데이터를 확인하고, 가설을 만들고, 적절한 도구를 고르고, 결과에 따라 계획을 바꾼다. 모든 행동이 자유로운 것은 아니지만 경로의 일부를 실행 중에 결정한다. ## MediaSense가 말한 간극 MediaSense는 2026년 7월 프로그래매틱 시장의 agentic AI를 다루며 buyer와 seller가 공통 언어로 소통하는 방향을 짚는 동시에, 현재 시장의 상당 부분이 현실보다 서사에 가깝다고 지적했다. 표준과 사례는 등장했지만 전체 생태계가 자율적으로 연결됐다고 말하기는 이르다. 이 간극은 기술의 실패만이 아니다. 공급자는 더 앞선 범주에 속하고 싶어 하고 구매자는 뒤처지고 싶지 않다. ‘에이전트’라는 말이 제품 기능, 회사 전략, 시장 미래를 한꺼번에 표현하면서 검증 가능한 정의가 사라진다. 정의가 흐리면 위험한 기능은 과소통제되고 단순한 기능은 과대구매된다. 정해진 보고서 요약기에 광고 계정 쓰기 권한을 줄 수 있고, 반대로 안전한 자동화를 에이전트가 아니라는 이유로 무시할 수 있다. 그래서 분류는 마케팅 용어 논쟁이 아니라 운영 통제의 출발점이며, 이름보다 실제 능력을 구분해야 한다. 실제 에이전트인지 판정하려면 이름 대신 여섯 가지 운영 능력을 보면 된다. 하나라도 없다고 즉시 탈락하는 시험은 아니지만, 빠진 능력이 많을수록 자율 에이전트보다 자동화된 도구에 가깝다. ## 목표를 행동으로 분해하고 결과에 따라 다시 계획하는가 에이전트는 사람이 미리 적지 않은 중간 단계를 만들 수 있어야 한다. 더 중요한 것은 첫 계획을 고집하지 않는 것이다. 예상한 데이터가 없거나 실험 결과가 반대라면 다음 행동을 바꿔야 한다. 처음 만든 작업 목록을 순서대로 실행하기만 하면 복잡한 워크플로다. ## 제한된 권한으로 현실에 행동하는가 문장을 제안하는 것과 광고 계정을 바꾸는 것은 다르다. 에이전트는 API나 실행기를 통해 현실에 영향을 줄 수 있지만 권한은 목표에 필요한 범위로 제한돼야 한다. 읽기, 제안, 작은 예산 조정, 새 캠페인 생성은 서로 다른 권한 단계다. ## 상태를 보존하고 다음 실행이 이어지는가 매번 처음부터 같은 질문을 해야 한다면 일회성 코파일럿에 가깝다. 에이전트는 현재 가설, 이미 한 행동, 사용한 예산, 얻은 결과, 남은 불확실성을 보존해야 한다. 그래야 같은 실수를 반복하지 않고 캠페인을 시간에 걸쳐 운영할 수 있다. ## 행동과 근거를 감사할 수 있는가 자율성이 커질수록 결과만 보는 것으로 부족하다. 어떤 입력, 정책, 데이터, 대안, 승인, API 호출이 결정에 연결됐는지 복원할 수 있어야 한다. 감사 가능성이 없는 자율성은 데모에서는 빠르지만 조직에서는 책임을 만들지 못한다. ## 중지와 복구가 설계돼 있는가 목표를 달성하거나 예산 한도에 도달했을 때 멈춰야 한다. 데이터가 이상하거나 오류가 반복되면 안전 상태로 돌아가 사람에게 알려야 한다. 계속 실행하는 능력보다 적절히 멈추는 능력이 실제 자율 운영의 조건이다. ## 결과에 책임지는 주체가 정해져 있는가 “AI가 했다”는 설명으로는 돈과 평판을 맡길 수 없다. 목표와 정책의 책임자, 승인자, 시스템 공급자, 실행 계정의 소유자, 사고 대응 주체가 정해져야 한다. 책임 주체가 없다면 기술적 에이전트가 있어도 사업 운영체계는 없다. 이 여섯 능력을 적용하면 의외의 결론이 나온다. 완전 자율 시스템보다 잘 만든 자동화가 더 나은 영역이 많다. 경로가 안정적이고 오류 비용이 크며 판단이 필요 없는 일은 결정적 코드가 맞다. 에이전트는 불확실한 정보를 해석하고 계획을 바꿔야 하는 좁은 구간에만 두는 편이 좋다. **에이전틱의 반대말은 낡은 것이 아니라 결정적인 것이다.** 좋은 마케팅 시스템은 모든 곳에 에이전트를 넣지 않는다. 자동화할 일, 사람을 도울 일, 에이전트가 탐색할 일, 사람이 책임질 일을 정확히 나눈다. --- 주요 출처: MediaSense, [Agentic AI in Programmatic — which way now?](https://www.media-sense.com/2026/07/14/agentic-ai-in-programmatic-which-way-now/?ref=zerodraftlab.com), 2026년 7월 14일; IAB Tech Lab, [Agentic Advertising Management Protocols](https://iabtechlab.com/standards/aamp-agentic-advertising-management-protocols/?ref=zerodraftlab.com). 시장 서사와 실제 배포의 간극, buyer/seller 공통 언어의 방향은 출처에 근거했습니다. 자동화·코파일럿·워크플로·에이전트의 구분과 여섯 운영 능력은 이 글의 분석적 판정 기준입니다. ### 96퍼센트는 AI 전환을 말하고 8퍼센트만 에이전트를 돌린다 URL: https://zerodraftlab.com/ninety-six-percent-talk-eight-percent-run/ Last updated: 2026-09-15T08:35:40.000Z 기업의 AI 발표만 보면 마케팅 조직은 이미 완전히 바뀐 것처럼 보인다. 캠페인 기획부터 제작, 집행, 측정까지 AI로 전환하겠다는 선언이 이어지고, 거의 모든 도구가 코파일럿이나 에이전트를 이름에 붙인다. 현실의 숫자는 다르다. BCG가 2026년 6월 공개한 조사에서 CMO의 96%는 end-to-end 마케팅 전환을 추진한다고 답했다. 그러나 조직의 42%는 여전히 개별 업무를 돕는 수준에 머물렀고, 자율적인 다중 에이전트 캠페인을 운영한다는 응답은 약 8%였다. **AI 전환의 가장 큰 착시는 도구를 많이 쓰는 것과 마케팅 시스템이 바뀐 것을 같은 일로 보는 데서 생긴다.** 카피를 빨리 쓰고 보고서를 요약해도 목표, 데이터, 승인, 실행, 학습이 연결되지 않으면 조직은 더 빠르게 조각난 일을 할 뿐이다. ## 96퍼센트의 선언은 거짓이 아니다 BCG 조사는 CMO 300명 설문과 50명 인터뷰를 바탕으로 했다. 96%라는 숫자는 실제 성숙도를 검증한 감사 결과가 아니라 리더가 전환을 추진한다고 답한 비율이다. 선언이 거짓이라는 뜻이 아니라 ‘추진’이라는 말 안에 파일럿, 도구 도입, 프로세스 재설계, 자율 운영이 함께 들어 있다는 뜻이다. 마케팅팀이 생성형 AI를 매일 사용해도 대부분의 흐름은 사람이 도구 사이를 연결한다. 한 도구에서 고객 데이터를 요약하고, 다른 도구에서 소재를 만들고, 사람이 광고 플랫폼에 옮기고, 다시 스프레드시트로 결과를 합친다. 각 단계는 빨라졌지만 전체 캠페인이 스스로 상태를 보존하거나 결과에 따라 재계획하지는 않는다. 42%가 task assist에 머물렀다는 수치는 이 단절을 보여준다. 보조 도구는 분명 생산성을 높인다. 문제는 보조를 전환으로 보고 데이터와 운영 구조를 고치지 않는 것이다. 생성 속도가 빨라질수록 승인 대기, 브랜드 불일치, 중복 캠페인, 측정 혼선이 더 많이 쌓일 수도 있다. ## 8퍼센트의 병목은 모델 성능이 아니다 자율 다중 에이전트 캠페인을 운영하려면 여러 모델을 붙이는 것보다 공통된 현실을 만들어야 한다. 고객과 상품의 정본, 브랜드가 할 수 있는 주장, 예산 권한, 성과 정의, 현재 캠페인의 상태를 에이전트들이 같은 의미로 읽어야 한다. 이 공통 기반이 없으면 리서치 에이전트는 하나의 고객을 말하고, 제작 에이전트는 다른 포지셔닝을 쓰며, 집행 에이전트는 가장 쉽게 얻는 클릭을 최적화한다. 각 에이전트는 자기 지표를 개선하지만 캠페인은 한 방향으로 움직이지 않는다. 그래서 BCG는 운영체계를 브랜드 인텔리전스, 에이전트 오케스트레이션, 통합된 마케터 인터페이스의 층으로 설명한다. 이 세 층은 화려한 아키텍처 이름이 아니라 기억, 조정, 책임의 문제를 각각 맡는다. 첫째 층인 브랜드 인텔리전스는 에이전트가 무엇을 사실로 받아들일지 정한다. 승인된 포지셔닝, 고객 근거, 상품 정보, 과거 실험, 금지 표현이 파일과 사람의 기억에 흩어져 있으면 매 실행마다 다른 브랜드가 만들어진다. ## 브랜드 인텔리전스는 문서 저장소가 아니다 브랜드북 PDF를 검색할 수 있게 만드는 것만으로는 부족하다. 어떤 주장이 현재 유효한지, 어떤 세그먼트에서 검증됐는지, 어느 근거가 만료됐는지, 최근 실험이 기존 가정을 어떻게 바꿨는지가 구조화돼야 한다. 에이전트가 과거 문장을 찾는 데서 끝나지 않고 현재 판단을 형성할 수 있어야 한다. 이 층은 운영 결과로 계속 갱신된다. 캠페인에서 특정 약속이 클릭은 높였지만 환불도 늘렸다면 그 결과가 다음 제작과 타기팅에 반영돼야 한다. 저장된 지식이 실행으로 내려가고 실행 결과가 다시 지식을 바꾸는 폐쇄 루프가 필요하다. ## 오케스트레이션은 역할보다 상태를 연결한다 다중 에이전트 데모는 리서처, 전략가, 카피라이터, 분석가처럼 역할을 나누는 데 집중한다. 실제 운영에서는 누가 말했는지보다 캠페인이 어느 상태인지가 더 중요하다. 가설이 승인됐는가, 소재가 규정을 통과했는가, 예산이 열렸는가, 결과가 판단 가능한 표본에 도달했는가를 공유해야 한다. 오케스트레이션은 에이전트를 많이 부르는 기능이 아니다. 다음 행동을 누가 할 수 있는지, 실패하면 어디로 돌아가는지, 어떤 증거가 있어야 상태를 넘길지를 정하는 기능이다. 결정적인 상태 전이는 코드와 정책으로 고정하고, 해석이 필요한 부분에만 에이전트를 쓰는 편이 안전하다. ## 통합 UI는 사람이 책임지는 차이를 보여준다 마케터에게 모든 에이전트 대화를 보여주면 투명해 보이지만 판단은 어려워진다. 필요한 화면은 현재 목표, 예산, 핵심 가설, 바뀐 조건, 예외, 승인할 결정, 결과를 한 흐름으로 보여준다. 사람은 생성 과정을 구경하는 대신 중요한 차이에 개입해야 한다. 8%에서 시작하려면 회사 전체를 한 번에 바꿀 필요가 없다. 하나의 채널, 하나의 제품, 작은 예산에서 목표와 상태를 끝까지 연결해본다. 성공 기준은 콘텐츠 생산량이 아니라 브리프부터 학습까지 걸린 시간, 오류와 재작업, 증분 성과, 다음 실험에 반영된 지식이다. AI 전환을 선언한 조직과 에이전트를 운영하는 조직의 차이는 의지의 크기가 아니다. 현재 업무에 AI 버튼을 더했는지, 아니면 조직이 기억하고 결정하고 실행하고 학습하는 방식을 다시 설계했는지의 차이다. **96퍼센트는 방향을 말한다. 8퍼센트는 그 방향을 운영체계로 만들기 시작했다.** 두 숫자 사이를 건너는 방법은 더 많은 도구 구매가 아니라 하나의 캠페인이 처음부터 끝까지 같은 현실을 보게 만드는 일이다. --- 주요 출처: BCG, [Making the Agentic Marketing Transformation a Reality](https://www.bcg.com/publications/2026/making-the-agentic-marketing-transformation-a-reality?ref=zerodraftlab.com), 2026년 6월 15일. 수치는 CMO 300명 설문과 50명 인터뷰에 근거하며 모든 마케팅 조직의 객관적 성숙도 감사 결과는 아닙니다. 세 층의 구체적 운영 해석과 작은 범위의 도입법은 이 글의 분석입니다. ### 인간 승인은 자동화의 실패가 아니다 URL: https://zerodraftlab.com/human-approval-is-not-automation-failure/ Last updated: 2026-09-15T08:35:41.000Z AI 에이전트의 데모에서 사람이 승인 버튼을 누르는 순간 관객은 종종 실망한다. “결국 사람이 해야 하네”라는 반응이다. 완전 자율을 기술 발전의 끝으로 놓으면 인간 개입은 미완성 자동화나 임시 안전장치처럼 보인다. 광고 운영에서는 반대일 수 있다. 예산을 쓰고 브랜드를 대표하며 고객 데이터에 접근하는 시스템에서 좋은 승인은 자율성의 흠이 아니라 권한의 구조다. 모든 일을 사람이 다시 한다면 자동화가 아니지만, 책임이 바뀌는 순간 사람에게 결정을 올리는 것은 성숙한 설계다. **인간 승인은 에이전트가 일을 못한다는 증거가 아니라, 어디까지 일할 수 있는지를 명시하는 제품 기능이다.** 목표는 사람을 없애는 것이 아니라 사람이 판단해야 할 차이만 남기는 것이다. ## 제안과 실행을 분리하면 자율성이 선명해진다 IAB Tech Lab의 Buyer Agent Alpha는 자연어 브리프에서 판매자를 찾고 협상과 예약 단계까지 이동하지만 지출을 확정하기 전에 인간 승인을 둔다. 중요한 것은 에이전트가 단순히 추천 문장을 쓰는 데서 멈추지 않는다는 점이다. 거래 상태를 만들고 조건을 비교한 뒤 권한 경계에서 멈춘다. 이 구조는 제안 에이전트와 결정적 실행기를 나누는 방식으로 일반화할 수 있다. 에이전트는 모호한 목표를 해석하고 대안을 만든다. 실행기는 예산 한도, 허용 계정, 필수 승인, 중복 방지, 중지 조건을 코드로 검사한 뒤 API 호출을 수행한다. 둘을 한 모델 안에 넣으면 편하지만 실패를 구분하기 어렵다. 나쁜 전략을 제안한 것인지, 승인되지 않은 행동을 실행한 것인지, API가 일부만 성공한 것인지 한 채팅 로그에 섞인다. 분리하면 판단 오류와 실행 오류를 서로 다른 방식으로 고칠 수 있다. ## 모든 승인에는 정보 비용이 있다 승인을 많이 두면 안전하다는 생각도 틀릴 수 있다. 사람이 하루 수백 건의 작은 입찰 변경을 확인하면 중요한 위험을 보지 못한다. 승인 요청이 잦고 차이가 불분명할수록 사람은 내용을 읽지 않고 통과시키는 습관을 배운다. 좋은 승인 요청은 원본 데이터 전체가 아니라 결정의 차이를 압축한다. 현재 계획과 무엇이 달라졌는지, 금액과 영향 범위가 얼마인지, 어떤 정책이 경계에 걸렸는지, 추천 근거와 불확실성은 무엇인지, 거절하면 다음 선택이 무엇인지를 보여준다. 반복되는 저위험 결정은 정책으로 졸업시켜야 한다. 같은 조건에서 열 번 승인했다면 사람이 매번 버튼을 누르는 대신 그 조건을 자동 실행 범위로 승격할지 검토할 수 있다. 반대로 반복해서 거절되는 제안은 에이전트의 목표나 데이터가 잘못됐다는 신호다. 이 지점에서 승인은 단순한 통제 장치에서 학습 데이터로 바뀐다. 승인, 수정, 거절의 결과와 이유를 구조화해 남기면 조직이 실제로 허용하는 판단 경계를 발견할 수 있다. ## 승인 로그는 조직의 숨은 정책을 드러낸다 문서에는 신규 고객을 우선한다고 적혀 있어도 마케터가 단기 ROAS가 낮은 실험을 계속 거절할 수 있다. 브랜드 안전성을 강조하면서도 매출 압박이 오면 예외를 승인할 수도 있다. 실제 승인 기록은 선언된 전략과 운영 행동의 차이를 보여준다. 이 기록을 모델 재학습에 바로 넣는 것보다 먼저 정책으로 해석해야 한다. 누가 어떤 역할에서 결정했는지, 당시 예산과 위험은 어땠는지, 나중 결과가 승인 판단을 지지했는지 봐야 한다. 한 사람의 습관을 조직의 영구 규칙으로 복제하면 자동화가 편향을 확대한다. ## 승인은 위험의 종류가 바뀔 때 올라와야 한다 금액 임계치만으로는 부족하다. 새로운 판매자와 첫 거래, 처음 쓰는 고객 데이터, 규제 민감 표현, 과거에 없던 소재, 평소보다 큰 오디언스 확장처럼 위험의 성격이 바뀌는 사건이 있다. 작은 금액이라도 되돌리기 어렵거나 평판 영향이 크면 승인이 필요하다. 반대로 승인된 캠페인 안에서 예산을 2% 조정하고, 허용된 소재 조합 중 성과가 낮은 것을 멈추는 일은 자동화할 수 있다. 에이전트의 자율 범위는 직함처럼 한 번 부여하는 것이 아니라 행동 유형과 회수 가능성에 따라 달라져야 한다. ## 사람도 결과에 대해 학습해야 한다 승인자는 결정을 내린 뒤 결과를 다시 받아야 한다. 그렇지 않으면 승인은 책임만 있고 학습은 없는 행정 절차가 된다. 어떤 수정이 성과와 위험을 개선했는지, 어떤 거절이 기회를 놓쳤는지 주기적으로 되돌려줘야 사람의 판단도 교정된다. 이 폐쇄 루프는 에이전트와 사람을 경쟁자로 두지 않는다. 에이전트는 더 많은 대안을 빠르게 만들고 일관되게 정책을 적용한다. 사람은 모호한 우선순위, 새로운 위험, 책임이 큰 예외를 판단한다. 결과는 두 주체의 다음 결정에 함께 반영된다. 완전 자율이라는 구호는 시연 영상을 단순하게 만든다. 실제 사업에서는 예외 없는 자동화보다 예외를 정확히 발견하고 적절한 사람에게 올리는 시스템이 더 가치 있다. 자율성의 수준은 승인 버튼의 유무가 아니라 승인 없이 안전하게 처리할 수 있는 범위와 승인 품질로 측정해야 한다. **사람이 남아 있다는 이유로 에이전트를 실패라고 부르면 책임까지 자동화했다고 착각하게 된다.** 좋은 시스템은 사람을 제거하지 않는다. 사람이 책임질 결정을 희소하게 만들고, 그 결정을 더 잘할 수 있게 한다. --- 주요 출처: IAB Tech Lab, [Buyer Agent Alpha](https://iabtechlab.github.io/buyer-agent/?ref=zerodraftlab.com); Digiday, [Agentic advertising is closer than you think — and further than you hope](https://digiday.com/media-buying/future-of-marketing-briefing-agentic-advertising-is-closer-than-you-think-and-further-than-you-hope/?ref=zerodraftlab.com). Buyer Agent의 human approval before spend와 업계의 수탁 책임 문제를 근거로 삼았습니다. 제안 에이전트·결정적 실행기 분리, 승인 로그의 학습 활용, 위험 유형별 권한은 이 글의 운영 설계입니다. ### 에이전트 광고의 첫 성과는 ROAS가 아니었다 URL: https://zerodraftlab.com/first-agentic-ad-result-was-not-roas/ Last updated: 2026-09-15T08:35:42.000Z 새 광고 기술이 등장하면 첫 질문은 대개 같다. “그래서 ROAS가 얼마나 올랐나?” 생성형 AI와 에이전트도 예외가 아니다. 자율적으로 캠페인을 만들고 매체를 사고 최적화했다는 발표에는 곧바로 매출 배수와 전환율을 기대하게 된다. 그런데 2026년 초 공개된 대표적인 에이전틱 미디어바잉 사례에서 가장 선명한 숫자는 ROAS가 아니었다. 캐나다 주류 회사 Geloso의 미국 캠페인에서 참여사들은 기존 방식보다 구매측 비용이 5.5배 낮았고, 같은 예산으로 노출이 40% 늘었으며, 동영상 완주율이 98%였다고 밝혔다. **에이전트 광고의 첫 성과는 더 많이 판 것이 아니라 미디어를 사는 과정이 훨씬 싸고 빠르게 움직일 수 있다는 증거였다.** 이 차이를 무시하면 초기 사례를 과대평가하거나, 반대로 매출 증명이 없다는 이유로 중요한 운영 혁신을 놓치게 된다. ## 무엇이 자율적이었나 Marketing Dive가 2026년 3월 보도한 사례는 Geloso, PubMatic, Butler/Till이 참여한 2025년 12월 캠페인이다. 보도에 따르면 에이전트는 캠페인 설정과 매체 구매를 수행했고 사람의 개입 없이 운영됐다. 브랜드는 타깃과 목표를 주고 시스템은 적합한 인벤토리와 조건을 찾아 집행했다. 여기서 5.5배 낮아졌다는 구매측 비용은 광고 인벤토리의 단가가 무조건 5분의 1이 됐다는 뜻으로 읽으면 안 된다. 기사 맥락에서 핵심은 거래를 준비하고 실행하는 buy-side 운영 비용의 감소다. 반복되는 설정, 연락, 조정, 최적화에 들어가던 노동과 중개 비용을 에이전트가 줄였다는 주장에 가깝다. 노출 40% 증가도 같은 구조에서 이해해야 한다. 운영 비용과 거래 마찰이 줄면 같은 예산 중 더 많은 부분이 실제 미디어에 갈 수 있다. 더 많은 노출이 곧 더 많은 증분 매출을 뜻하지는 않지만, 광고비가 전달 과정에서 사라지는 비율을 낮출 가능성은 보여준다. ## 98퍼센트 완주율은 강하지만 충분하지 않다 동영상 완주율 98%는 눈길을 끈다. 그러나 완주율은 매체 환경, 영상 길이, 자동 재생 조건, 측정 방식에 크게 영향을 받는다. 높은 완주율이 사람이 주의 깊게 봤다는 뜻인지, 브랜드를 기억했다는 뜻인지, 구매 행동을 바꿨다는 뜻인지는 별도 실험이 필요하다. 이 사례의 수치는 참여사와 관련 보도를 통해 공개됐다. 독립된 학술 실험이나 전체 원자료 공개가 아니다. 캠페인의 절대 예산, 대조군 설계, 증분 매출, 신규 고객 비중, 마진까지 모두 제시된 것도 아니다. 따라서 “에이전트가 ROAS를 개선했다”고 결론 내릴 근거는 부족하다. 그 한계를 인정해도 사례의 가치가 사라지지는 않는다. 새로운 운영 모델의 첫 검증은 최종 매출보다 앞단의 병목이 실제로 제거되는지에서 시작할 수 있다. 자동차 공장의 새 생산 방식도 첫날에는 시장점유율보다 조립 시간과 결함률로 배운다. 에이전트 미디어바잉 역시 거래 비용과 실행 속도를 먼저 바꾼 뒤 성과 최적화로 이동할 가능성이 크다. 그래서 다음 실험은 비용 절감, 미디어 품질, 비즈니스 증분을 세 층으로 나눠야 한다. 한 숫자에 모두 섞으면 에이전트가 어디에서 가치를 만들었고 어디에서 아직 실패했는지 알 수 없다. ## 첫 번째 층은 처리 비용이다 캠페인 브리프부터 집행까지 걸린 시간, 사람이 개입한 횟수, 거래당 운영 시간, 기술·중개 수수료, 오류 수정 비용을 측정한다. 에이전트가 같은 광고 성과를 유지하면서 이 비용을 크게 낮췄다면 그것만으로도 명확한 생산성 개선이다. 다만 절감된 시간을 다시 확인해야 한다. 사람이 하던 일을 시스템 뒤에서 수작업으로 보정했다면 비용이 사라진 것이 아니라 다른 팀으로 이동한 것이다. 모델 호출비, 데이터 정리, 승인 대기, 예외 처리, 사기·브랜드 안전성 검수까지 총비용에 넣어야 한다. ## 두 번째 층은 미디어의 질이다 노출 수와 완주율 옆에 조회 가능성, 유효 도달, 빈도, 문맥 적합성, 무효 트래픽, 브랜드 안전성을 둔다. 더 싼 노출을 더 많이 산 것이 같은 타깃에게 지나치게 반복되거나 품질이 낮은 지면에 집중됐다면 운영 효율이 광고 효율로 이어지지 않는다. 에이전트의 판단 기록도 이 층에서 중요하다. 어떤 판매자를 제외했고, 어떤 조건을 양보했으며, 성과 변화에 따라 무엇을 다시 계획했는지 재구성할 수 있어야 한다. 결과 숫자만 좋으면 위험한 최적화가 숨어도 발견하기 어렵다. ## 세 번째 층이 비즈니스 증분이다 최종적으로는 광고가 없었을 때보다 신규 고객, 매출, 기여이익, 재구매가 얼마나 늘었는지 봐야 한다. 기존 구매자를 더 싼 비용으로 다시 잡은 것인지, 실제로 새로운 수요를 만들었는지 구분해야 한다. 가능하면 지역, 오디언스, 기간을 나눈 대조군이나 holdout을 둔다. 이 세 층은 순서가 있지만 서로 대체하지 않는다. 처리 비용이 줄어도 매체 품질이 나빠질 수 있고, 매체 지표가 좋아도 증분 이익이 없을 수 있다. 반대로 매출 개선 폭이 작아도 운영 비용이 크게 줄었다면 전체 기여이익은 좋아질 수 있다. 초기 에이전트 광고를 평가할 때 “ROAS가 없으니 실패”와 “노출이 늘었으니 혁명” 사이를 벗어나야 한다. 이 사례가 보여준 것은 거래 마찰을 줄이는 기술적 가능성이다. 다음 단계에서 증명해야 할 것은 그 절감이 더 좋은 선택과 더 큰 이익으로 이어지는가다. **에이전트가 광고를 살 수 있다는 사실은 확인되기 시작했다. 에이전트가 무엇을 사야 하는지 더 잘 안다는 사실은 아직 별도의 증명이 필요하다.** --- 주요 출처: Marketing Dive, [Beverage marketer sees cost savings with agentic media buying test](https://www.marketingdive.com/news/beverage-marketer-sees-cost-savings-with-agentic-media-buying-test/814905/?ref=zerodraftlab.com), 2026년 3월 17일. 5.5배 구매측 비용 절감, 40% 노출 증가, 98% 동영상 완주율은 참여사 기반 사례 수치이며 증분 매출이나 독립 검증된 ROAS를 뜻하지 않습니다. 세 층 측정 구조는 이 증거 경계를 바탕으로 한 이 글의 분석입니다. ### 기술은 준비됐고 책임은 준비되지 않았다 URL: https://zerodraftlab.com/technology-ready-responsibility-is-not/ Last updated: 2026-09-15T08:35:42.000Z 광고 에이전트의 데모는 이미 충분히 그럴듯하다. 자연어 브리프를 읽고, 판매자를 찾고, 조건을 비교하고, 예산을 배분하고, 결과에 따라 다시 계획하는 흐름을 화면에서 볼 수 있다. 기술이 완벽하지 않아도 제한된 범위에서는 실제 거래를 수행할 수준에 가까워졌다. 그런데 광고비가 실제로 움직이는 순간 질문이 달라진다. 잘못 산 지면의 비용은 누가 부담하는가. 브랜드 안전성 사고는 누구 책임인가. 에이전트가 대행사의 수익과 광고주의 이익이 충돌하는 선택을 하면 어떤 의무가 우선하는가. **에이전트 광고의 병목은 이제 지능보다 책임이다.** 소프트웨어가 거래를 완수할 수 있다는 사실과 그 거래를 광고주를 대신해 정당하게 결정할 권한이 있다는 사실은 전혀 다르다. ## 기술적 자율성과 위임된 권한은 다르다 Digiday는 2026년 5월 업계 관계자들의 전망을 전하며 agent-to-agent 거래가 6\~12개월 안에 규모를 갖출 수 있다는 기대와 함께 수탁 책임을 큰 장애물로 짚었다. 이 기간은 확정된 시장 일정이 아니라 업계 전망이다. 더 중요한 부분은 기술 연결보다 “누구를 위해 결정하는가”가 어렵다는 지적이다. 대행사와 광고 플랫폼은 여러 경제적 이해관계를 가진다. 광고주 예산을 효율적으로 써야 하지만 특정 매체와 거래 관계가 있고, 자체 기술 수수료를 얻으며, 때로는 재고 판매에도 관여한다. 사람이 결정할 때도 존재하던 충돌이 에이전트의 속도와 규모 때문에 더 자주, 더 보이지 않게 반복될 수 있다. 모델은 “최고의 캠페인을 만들어라”라는 목표를 법적·상업적 의무로 해석하지 못한다. 최고가 ROAS인지, 장기 브랜드 성장인지, 대행사 마진인지, 약정된 매체 소진인지 명확하지 않기 때문이다. 목표 함수가 모호하면 에이전트는 접근 가능한 데이터와 보상 신호를 따라간다. ## 사람의 승인도 책임을 자동으로 해결하지 않는다 많은 시스템은 지출 직전에 승인 버튼을 둔다. 필요한 안전장치지만 책임의 만능 해법은 아니다. 사람이 수백 개 거래를 몇 초 안에 승인해야 하고 판단 근거를 볼 수 없다면 승인은 형식적인 도장에 불과하다. 잘못된 선택의 책임만 사람에게 넘기는 ‘human washing’이 될 수 있다. 유효한 승인은 선택의 요약이 아니라 판단 가능한 차이를 보여줘야 한다. 예산이 얼마나 움직이는지, 어떤 제약이 충족됐는지, 기준안보다 무엇이 달라졌는지, 가장 큰 위험과 불확실성이 무엇인지, 거절하면 어떤 대안이 있는지를 함께 보여줘야 한다. 또 모든 결정에 같은 승인이 필요한 것도 아니다. 이미 승인된 판매자, 정해진 예산 범위, 검증된 소재 안에서의 작은 조정은 자동화할 수 있다. 새로운 데이터 사용, 높은 예산 이동, 규제 민감 카테고리, 브랜드 안전성 예외처럼 책임의 성격이 바뀌는 순간에만 승인을 올리는 편이 낫다. 이렇게 보면 좋은 에이전트 운영체계는 자율화 수준이 아니라 책임 경계의 해상도로 평가해야 한다. 누가 무엇을 결정할 수 있고, 어느 조건에서 멈추며, 어떤 기록으로 사후 검증하는지가 모델의 성능만큼 중요하다. ## 예산 권한은 계단식이어야 한다 에이전트에 광고 계정의 전체 권한을 주는 것은 빠르지만 학습하기 나쁜 설계다. 처음에는 읽기와 제안만 허용하고, 다음에는 작은 샌드박스 예산, 그다음에는 승인된 캠페인 안의 조정 권한으로 넓힐 수 있다. 오류율과 회수 가능성을 보면서 한도를 올려야 한다. 한도는 금액만이 아니다. 하루 지출, 거래당 지출, 새 판매자 수, 새 오디언스 생성, 소재 변경, 데이터 반출, 지역과 카테고리를 각각 제한할 수 있다. 에이전트가 한 경계를 넘을 때 자동으로 더 강한 검토가 붙어야 한다. ## 감사 기록은 채팅 로그보다 구조적이어야 한다 에이전트의 긴 사고 과정을 그대로 저장한다고 책임이 생기지는 않는다. 필요한 것은 입력 브리프의 버전, 적용된 정책, 고려한 대안, 선택한 거래, 거절한 이유, 실행된 API 호출, 승인자, 결과를 구조화된 사건으로 남기는 일이다. 그래야 사고가 났을 때 모델의 문장을 해석하는 대신 어느 권한과 규칙이 실패했는지 찾을 수 있다. 같은 종류의 오류가 반복되면 프롬프트를 다듬는 데서 끝내지 않고 정책, 데이터, 승인 한도, 실행기를 수정할 수 있다. ## 책임 주체는 계약에서 먼저 정해야 한다 광고주, 대행사, 에이전트 공급자, 매체가 각각 무엇을 보증하는지 명시해야 한다. 에이전트 공급자가 모델 출력의 정확성을 전부 보증하기 어렵더라도 승인되지 않은 지출, 정책 위반, 기록 누락, 중지 실패에 대한 책임은 계약과 기술 통제로 나눌 수 있다. 성과가 나쁠 때와 의무를 위반했을 때도 구분해야 한다. 합리적인 실험이 실패한 것은 시장 위험이지만, 금지된 인벤토리를 샀거나 이해상충을 숨겼다면 운영 실패다. 둘을 같은 ‘AI 오류’로 묶으면 개선도 배상도 불가능하다. 에이전트 광고가 확산되려면 모델 정확도가 조금 더 올라가는 것만으로는 부족하다. 광고주가 자신의 이익을 위해 움직인다는 확신, 손실 한도가 있다는 확신, 잘못된 행동을 되돌리고 설명할 수 있다는 확신이 필요하다. **기술은 거래를 시작하게 하지만 책임 체계가 거래를 반복하게 한다.** 에이전트가 사람보다 빨리 살 수 있는 시장보다, 누구의 권한으로 왜 샀는지 끝까지 복원할 수 있는 시장이 먼저 신뢰를 얻는다. --- 주요 출처: Digiday, [Agentic advertising is closer than you think — and further than you hope](https://digiday.com/media-buying/future-of-marketing-briefing-agentic-advertising-is-closer-than-you-think-and-further-than-you-hope/?ref=zerodraftlab.com), 2026년 5월 22일; IAB Tech Lab, [Buyer Agent Alpha](https://iabtechlab.github.io/buyer-agent/?ref=zerodraftlab.com). 6\~12개월 전망은 업계 관계자의 예상이며 확정된 배포 일정이 아닙니다. 계단식 권한, 승인 정보, 구조화된 감사 기록과 계약 책임 구분은 이 글의 운영 설계 분석입니다. ### 브랜드의 다음 랜딩페이지는 데이터 피드다 URL: https://zerodraftlab.com/next-landing-page-is-data-feed/ Last updated: 2026-09-15T08:35:43.000Z 브랜드는 오랫동안 랜딩페이지를 광고의 종착지로 만들었다. 강한 헤드라인, 제품 사진, 사회적 증거, 가격, CTA를 한 화면에 배치해 사람이 방문하고 설득된 뒤 구매하도록 설계했다. 검색 광고와 소셜 광고의 성과도 결국 이 페이지에서 얼마나 전환됐는지로 평가했다. 대화형 쇼핑에서는 소비자가 그 페이지에 오지 않을 수 있다. 사용자는 AI에게 조건을 말하고, AI는 여러 판매자의 상품 정보를 불러와 비교하고, 적합한 후보를 설명하고, 경우에 따라 결제 단계까지 이어간다. 브랜드의 문을 열기 전에 선택이 끝나는 것이다. **브랜드의 다음 랜딩페이지는 화면이 아니라 데이터 피드다.** 가격, 재고, 옵션, 배송, 반품, 평판, 성능 근거가 기계가 읽고 비교할 수 있는 상태로 유지되지 않으면 가장 아름다운 페이지도 후보 목록 밖에 남을 수 있다. ## 상품 발견은 최신 데이터 문제다 OpenAI는 2026년 3월 ChatGPT의 상품 발견을 지원하기 위해 Agentic Commerce Protocol을 확장한다고 발표했다. 핵심은 사용자가 상품을 발견하고 비교할 때 최신 상품 데이터를 활용하는 것이다. 이것은 특정 광고 상품의 성과 발표가 아니라 플랫폼이 상품 정보를 주고받는 방식을 정비한다는 공식 제품 발표다. 대화형 쇼핑에서 오래된 가격은 단순한 콘텐츠 오류가 아니다. 에이전트가 잘못된 예산 판단을 하게 만들고, 재고가 없는 상품을 추천하며, 약속할 수 없는 배송일을 제시하게 한다. 클릭 뒤에 오류를 발견하는 대신 추천 자체의 신뢰가 무너진다. 상품명과 설명만 보내는 것으로도 부족하다. 같은 신발이라도 색상·사이즈별 재고가 다르고, 지역별 배송일과 반품비가 다르다. 에이전트가 사용자의 제약을 지키려면 상품 속성뿐 아니라 거래 조건까지 구조화돼야 한다. ## 광고도 대화 안에서 상품 정보와 합쳐진다 Amazon Ads는 2026년 6월 대화형 광고와 agentic shopping 방향을 공개했다. Amazon이 제시한 수치에 따르면 sponsored prompt를 본 이용자의 약 20%가 브랜드와의 대화를 이어갔고, 관련 기능은 전환을 6% 높였다. 이 수치는 Amazon 자체 환경과 측정에서 나온 공급자 제공 지표이며 다른 시장의 평균으로 일반화할 수 없다. 그래도 형식의 변화는 분명하다. 광고는 고정된 소재를 보여주고 랜딩페이지로 보내는 대신 사용자의 후속 질문에 답해야 한다. “내 피부 타입에도 맞나”, “내일까지 오는가”, “경쟁 제품보다 왜 비싼가”라는 질문에 광고 시스템이 상품 데이터와 근거를 불러와 대화를 계속한다. 이 환경에서 카피는 사라지지 않는다. 다만 한 번에 완성된 문안보다 정확한 사실, 허용된 주장, 브랜드의 말투, 비교 가능한 차이를 조합하는 규칙이 중요해진다. 데이터 피드는 카피의 반대가 아니라 카피가 사실에서 벗어나지 않게 하는 재료다. 따라서 브랜드가 준비할 것은 feed 파일 하나가 아니라 상품 지식의 운영체계다. 어떤 시스템이 가격의 정본인지, 재고는 얼마나 자주 갱신되는지, 성능 주장은 어떤 근거까지 허용되는지, 충돌한 정보는 누가 고치는지가 정해져야 한다. ## 기계가 읽는 상품에는 출처와 유효기간이 필요하다 모든 속성에는 값만 있는 것이 아니라 출처와 시점이 있어야 한다. “당일 배송”이 물류 시스템의 실시간 약속인지, 지난달 마케팅 문구인지 구분해야 한다. “임상 검증”도 시험 주체, 표본, 조건, 날짜가 없으면 에이전트가 안전하게 요약하기 어렵다. 특히 규제 민감 카테고리에서는 허용 표현과 금지 표현을 데이터 층에서 관리해야 한다. 에이전트가 여러 문장을 생성하더라도 승인된 근거 범위를 넘지 않게 해야 한다. 생성 뒤 전수 검수하는 방식은 대화의 속도와 경우의 수를 따라가기 어렵다. ## 페이지 성과와 피드 성과를 분리해야 한다 대화형 에이전트가 추천을 끝내면 사이트 세션이 줄어도 매출은 늘 수 있다. 기존 웹 분석만 보면 유입 감소를 실패로 오해할 수 있다. 반대로 추천 언급이 늘어도 잘못된 가격과 재고 때문에 구매가 취소된다면 발견 성과가 비즈니스 성과가 아니다. 새 측정에는 질문별 상품 포함률, 후보 순위, 데이터 최신성, 추천 이유, 품절 추천률, 가격 불일치, 에이전트에서 시작된 구매와 반품이 들어가야 한다. 가능하다면 어떤 데이터 필드가 선택과 이탈에 영향을 줬는지도 추적해야 한다. ## 브랜드 사이트는 사라지지 않고 증거 저장소가 된다 에이전트가 정보를 가져간다고 사이트가 필요 없어지는 것은 아니다. 공식 상세 페이지, 정책, 시험 자료, 고객지원 문서는 데이터 피드의 근거를 사람이 검증할 수 있는 표면이다. 고관여 구매에서는 사용자가 에이전트의 shortlist를 받은 뒤 브랜드 세계관과 세부 정보를 확인하러 올 수도 있다. 다만 사이트의 역할이 모든 구매 여정을 독점하는 곳에서 신뢰 가능한 원자료와 깊은 경험을 제공하는 곳으로 바뀐다. 구조화된 데이터와 사람이 읽는 설명이 서로 다른 사실을 말하면 에이전트도 사람도 신뢰하지 못한다. 두 표면은 하나의 정본에서 파생돼야 한다. 브랜드가 대화형 쇼핑에 대응하는 가장 나쁜 방법은 모든 페이지에 AI 문장을 더 만드는 것이다. 병목은 문장 생산량이 아니라 상품 사실의 정확성, 갱신 속도, 비교 가능성, 근거의 추적성에 있다. **랜딩페이지는 사람을 설득하는 마지막 화면이었다. 데이터 피드는 에이전트가 브랜드를 선택할 수 있게 하는 첫 번째 계약이다.** 다음 커머스 경쟁은 더 많은 콘텐츠를 가진 회사보다 상품의 현실을 더 정확하게 전달하는 회사에 유리하다. --- 주요 출처: OpenAI, [Powering product discovery in ChatGPT](https://openai.com/index/powering-product-discovery-in-chatgpt/?ref=zerodraftlab.com), 2026년 3월 24일; Amazon Ads, [Agentic shopping and advertising](https://advertising.amazon.com/library/news/agentic-shopping-advertising?ref=zerodraftlab.com), 2026년 6월 11일. sponsored prompt 대화 지속률과 전환 상승은 Amazon 제공 수치입니다. 데이터 정본, 출처·유효기간, 피드 성과 측정은 두 공식 발표를 바탕으로 확장한 이 글의 분석입니다. ### 배너가 사라지면 광고는 더 위험해진다 URL: https://zerodraftlab.com/ads-more-dangerous-without-banners/ Last updated: 2026-09-15T08:35:44.000Z 배너 광고는 성가셔도 정체가 분명했다. 기사 옆 사각형, 영상 앞 짧은 클립, 검색 결과 위의 ‘스폰서’ 표시는 사용자가 상업적 메시지를 마주하고 있다는 사실을 알려줬다. 내용과 광고의 경계가 흐려질 때도 최소한 광고가 들어갈 자리는 눈에 보였다. 생성형 AI의 답변에는 그런 자리가 없다. 사용자가 여행 계획, 건강 제품, 업무 도구를 묻고 모델이 자연스러운 문장으로 답할 때 특정 상품이 등장해도 그것이 모델의 판단인지, 검색 결과의 요약인지, 광고주의 대가를 받은 배치인지 알아보기 어렵다. **배너가 사라지면 광고가 사라지는 것이 아니라 상업적 개입을 발견하는 단서가 사라진다.** 광고가 별도의 창작물이 아니라 답변의 문장, 비교 기준, 다음 행동에 섞일수록 영향력은 더 커지고 책임은 더 흐려질 수 있다. ## 광고는 노출이 아니라 개입이 된다 2026년 5월 공개된 연구 「Generative AI Advertising as a Problem of Trustworthy Commercial Intervention」은 이 문제를 광고 형식보다 개입의 강도로 본다. 가장 약한 단계는 제품을 언급하는 것이고, 그다음은 특정 장단점이 두드러지도록 프레이밍하는 것이다. 더 강한 단계에서는 사용자의 행동 경로를 바꾸고, 끝에는 장기적인 선호 형성까지 영향을 준다. 이 구분이 중요한 이유는 같은 ‘추천’이라는 표현 아래 서로 다른 권력이 숨기 때문이다. “이 제품도 있습니다”와 “당신에게 가장 적합하니 지금 주문했습니다”는 같은 광고가 아니다. 후자는 정보를 보여주는 데서 끝나지 않고 사용자의 선택과 행동을 대신한다. 전통 광고의 측정은 노출, 클릭, 전환을 중심으로 발전했다. 생성형 답변에서는 무엇을 노출로 볼지도 모호하다. 브랜드명이 한 번 언급됐는지, 비교 기준이 브랜드에 유리하게 바뀌었는지, 경쟁 대안이 생략됐는지, 사용자가 추가 질문 없이 구매로 이동했는지가 각각 다른 영향이다. ## 표시만 붙이면 끝나지 않는다 가장 쉬운 해법은 ‘광고’ 표시다. 반드시 필요하지만 충분하지는 않다. 답변의 한 문장이 광고라는 사실을 표시해도, 그 문장이 전체 추천 순위와 제외 기준에 어떤 영향을 줬는지 알 수 없다. 상업적 관계가 출처 선택이나 설명의 어조까지 바꿨다면 배지 하나는 영향의 범위를 설명하지 못한다. 예를 들어 여행 에이전트가 수수료를 받는 호텔을 먼저 추천하되 가격, 위치, 취소 조건을 정확히 보여줄 수 있다. 정보는 거짓이 아니지만 다른 호텔을 비교 목록에서 뺐다면 사용자의 선택지는 이미 재구성됐다. 진실한 문장만으로 공정한 추천이 보장되지는 않는다. 그래서 연구는 신뢰할 수 있는 상업적 개입을 출처 귀속 가능성, 측정 가능성, 이의 제기 가능성, 사용자 이익과의 정렬이라는 문제로 확장한다. 누가 돈을 냈는지뿐 아니라 무엇이 바뀌었고, 어떤 결과가 생겼으며, 사용자가 거부하거나 수정할 수 있는지를 묻는 것이다. 이 네 조건을 제품으로 구현하려면 광고 시스템과 에이전트의 권한을 함께 설계해야 한다. 답변을 생성하는 모델, 광고 후보를 공급하는 시스템, 실제 예약이나 결제를 수행하는 도구가 분리돼 있다면 어느 단계에서 상업적 영향이 들어갔는지 기록할 수 있다. ## 귀속은 돈의 출처와 문장의 출처를 함께 보여줘야 한다 광고주가 비용을 냈다는 표시만으로는 부족하다. 가격은 판매자가 제공했는지, 성능 주장은 독립 시험에서 왔는지, 후기는 검증된 구매자의 것인지, 모델이 어떤 정보를 요약했는지를 구분해야 한다. 한 답변 안에서도 사실마다 출처가 다르기 때문이다. 이 구조는 광고주에게도 유리하다. 모든 상업적 메시지가 의심받는 대신 검증 가능한 주장은 더 강한 신뢰를 얻을 수 있다. 반대로 근거 없는 최상급 표현은 답변에 들어가더라도 선택을 뒷받침하지 못한다. 광고 카피의 경쟁이 증거의 경쟁으로 이동한다. ## 측정은 클릭이 아니라 선택의 변형을 봐야 한다 상업적 개입의 효과를 측정하려면 광고가 없었을 때의 답변과 비교해야 한다. 후보 수, 순서, 설명 길이, 강조된 기준, 다음 행동이 어떻게 달라졌는지 봐야 한다. 단순 전환율 상승은 광고가 더 적합한 선택을 도왔는지, 사용자의 선택지를 부당하게 좁혔는지 구분하지 못한다. 따라서 좋은 실험은 매출과 함께 선택 품질을 본다. 구매 취소, 반품, 만족, 재질문, 후회, 장기적인 브랜드 회피가 함께 움직이는지 확인한다. 에이전트가 단기 전환을 높이고 장기 신뢰를 깎을 수 있기 때문이다. ## 이의 제기는 추천을 다시 실행할 권리다 사용자가 “광고를 제외하고 다시 비교해줘”, “수수료가 없는 대안만 보여줘”, “왜 이 상품을 1위로 골랐는지 설명해줘”라고 요구할 수 있어야 한다. 이의 제기는 고객센터에 항의 메일을 보내는 절차가 아니라 같은 목표를 다른 상업적 조건으로 다시 계산하는 기능에 가깝다. 사용자 정렬도 선언으로 끝나지 않는다. 에이전트가 받는 광고 수익과 사용자가 얻는 효용이 충돌할 때 무엇을 우선할지 규칙으로 정해야 한다. 안전, 예산, 접근성 같은 사용자의 명시적 제약은 광고주의 지불 의사로 덮어쓸 수 없어야 한다. 그리고 실제 실행 전에는 그 제약이 충족됐음을 검증해야 한다. 생성형 광고의 위험은 AI가 사람을 완벽하게 조종해서가 아니다. 작은 상업적 편향이 유용한 답변의 문법 안에 들어와 발견하기 어려워지고, 그 답변이 곧바로 행동으로 이어질 수 있기 때문이다. 배너보다 덜 거슬리는 광고가 반드시 덜 강한 광고는 아니다. **광고가 보이지 않을수록 신뢰 장치는 더 많이 보여야 한다.** 누가 개입했는지, 무엇을 바꿨는지, 어떤 결과를 만들었는지, 사용자가 어떻게 거부할 수 있는지를 답변과 행동 기록 안에 남기는 일이 새 광고 형식의 최소 조건이다. --- 주요 출처: [Generative AI Advertising as a Problem of Trustworthy Commercial Intervention](https://arxiv.org/abs/2605.18673?ref=zerodraftlab.com), arXiv:2605.18673, 2026년 5월. 제품 언급·프레이밍·행동 재지정·선호 형성의 층위와 귀속·측정·이의 제기·사용자 정렬의 문제의식은 논문에 근거했습니다. 구체적인 제품 설계와 선택 품질 측정 방식은 이를 확장한 이 글의 분석입니다. ### DSP 다음에는 협상하는 로봇이 온다 URL: https://zerodraftlab.com/robots-negotiate-after-dsp/ Last updated: 2026-09-15T08:35:45.000Z 프로그래매틱 광고는 사람이 일일이 지면을 사던 일을 자동화했다. DSP는 여러 거래소의 광고 기회를 한 화면에서 사고, SSP는 매체의 재고를 경매에 내놓았다. 자동 입찰은 밀리초 안에 이뤄졌지만 캠페인의 목적을 해석하고 거래 조건을 협상하는 일은 여전히 사람과 고정된 소프트웨어의 몫이었다. 에이전틱 광고는 자동화의 위치를 한 단계 위로 올린다. “25\~34세 신규 고객에게 도달하되 브랜드 안전성을 지키고 이번 분기 안에 학습 가능한 실험을 하라”는 브리프를 에이전트가 읽고, 적합한 판매자를 찾고, 조건을 묻고, 가격과 보장을 협상하고, 승인 뒤 예약한다. **DSP 다음의 인터페이스는 더 복잡한 대시보드가 아니라 서로 협상하는 소프트웨어일 수 있다.** 이때 달라지는 것은 입찰 속도만이 아니다. 누가 상품을 발견하고, 누가 조건을 해석하며, 누가 거래 이유를 기록하는지가 바뀐다. ## Buyer Agent는 브리프를 거래 상태로 바꾼다 IAB Tech Lab의 Buyer Agent Alpha는 이 미래를 작은 범위에서 보여준다. CrewAI와 OpenDirect 2.1을 사용한 참조 구현은 자연어 브리프에서 시작해 판매자 발견, 상품 탐색, 협상, 예약으로 이동한다. 돈을 확정하기 전에는 인간 승인을 요구하고, 거래 과정을 열두 개 상태와 감사 기록으로 남긴다. 여기서 중요한 것은 ‘AI가 미디어를 샀다’는 구호가 아니다. 브리프가 목표와 제약으로 구조화되고, 거래가 상태 전이로 표현되며, 승인 시점과 실행 이유가 기록된다는 점이다. 에이전트가 자유롭게 말하더라도 실제 거래는 예측 가능한 프로토콜 안에서 움직인다. IAB Tech Lab이 2026년 업데이트한 AAMP도 같은 문제를 Foundations, Protocols, Trust라는 세 축으로 나눈다. 에이전트가 누구인지 식별하고, 서로 어떤 메시지를 주고받으며, 그 행동을 어떤 신뢰 체계 아래 두는지가 함께 필요하다는 뜻이다. 자연어 대화만 연결한다고 광고 시장의 거래 표준이 생기지는 않는다. ## 협상 비용이 낮아지면 작은 거래가 늘어난다 사람이 직접 협상할 때는 거래 금액이 작으면 회의와 이메일 비용을 감당하기 어렵다. 그래서 많은 매체 상품이 표준화된 경매로 흡수되거나, 반대로 큰 보장형 거래만 사람의 협상을 거친다. 에이전트가 조건 확인과 왕복 대화를 거의 무료로 수행하면 그 사이의 거래가 경제성을 얻을 수 있다. 특정 콘텐츠 문맥, 제한된 기간, 빈도 상한, 성과 보장, 데이터 사용 제한을 조합한 작은 맞춤형 거래가 가능해진다. 구매자는 수백 개 판매자에게 동시에 물을 수 있고 판매자는 재고 상황에 맞춰 조건을 제안할 수 있다. 경매가 가격 하나를 최적화했다면 에이전트 협상은 여러 조건을 함께 다룬다. 하지만 협상 비용이 낮아지는 것과 좋은 거래가 늘어나는 것은 같은 말이 아니다. 에이전트가 비교하는 기준이 빈약하면 시장은 더 빠르게 잘못된 지표를 최적화한다. 조회 가능성, 브랜드 안전성, 증분 도달, 데이터 권리처럼 서로 충돌하는 조건을 어떤 우선순위로 처리할지 브리프에 없으면, 에이전트는 가장 쉽게 수치화되는 가격으로 돌아간다. 따라서 다음 미디어바잉 역량은 에이전트를 고르는 일이 아니라 협상 가능한 목표를 설계하는 일에서 시작한다. 사람이 “효율적으로 집행하라”고 쓰면 에이전트는 효율의 정의를 추측해야 한다. 반면 허용 예산, 반드시 지킬 제약, 교환 가능한 조건, 중지 기준이 분리돼 있으면 협상의 경계가 생긴다. ## 중개자의 가치는 클릭이 아니라 규칙으로 이동한다 Buyer Agent와 Seller Agent가 직접 대화하면 기존 중개자가 모두 사라진다는 전망은 성급하다. 거래 경로가 짧아져도 신원 확인, 사기 탐지, 측정, 정산, 분쟁 해결, 규제 준수는 남는다. 오히려 에이전트가 더 많은 거래를 만들수록 공통 규칙과 신뢰 서비스의 가치가 커진다. 가치가 줄어드는 것은 정보 비대칭과 인터페이스 복잡성만으로 받던 수수료다. 사람이 어느 메뉴를 눌러야 하는지 알고 있다는 이유, 판매자 목록을 독점하고 있다는 이유, 보고서를 수작업으로 합친다는 이유만으로 유지되던 마진은 압박받는다. 반대로 거래 조건의 의미를 표준화하고 결과를 독립적으로 검증하며 문제가 생겼을 때 책임지는 중개자는 더 중요해진다. 매체사도 광고 상품을 사람이 읽는 세일즈덱으로만 팔 수 없게 된다. 어떤 오디언스와 문맥을 제공하는지, 가격과 최소 집행액은 무엇인지, 어떤 측정을 허용하는지, 취소와 보상 조건은 무엇인지 기계가 질의할 수 있어야 한다. 상품 설명의 구조화 수준이 새 영업 역량이 된다. ## 대시보드는 사라지지 않고 예외 처리 화면이 된다 에이전트가 정상 거래를 처리할수록 사람이 보는 화면은 모든 버튼을 담을 필요가 없다. 대신 왜 이 판매자를 선택했는지, 어떤 조건을 양보했는지, 어느 제약에서 충돌했는지, 지금 무엇을 승인해야 하는지를 보여줘야 한다. 대시보드는 조작판에서 감사와 예외 처리의 표면으로 바뀐다. 이 변화는 UX의 축소가 아니라 책임의 집중이다. 거래가 실패했을 때 “AI가 결정했다”는 문장은 설명이 아니다. 브리프의 어떤 규칙, 판매자의 어떤 응답, 모델의 어떤 판단, 사람의 어떤 승인이 결과를 만들었는지 재구성할 수 있어야 한다. 열두 개 거래 상태와 감사 기록이 화려한 자연어 인터페이스보다 중요한 이유다. 초기 도입은 전면 자율화보다 좁은 시장과 작은 예산에서 시작하는 편이 맞다. 판매자 발견과 조건 비교는 에이전트에 맡기고, 가격 상한을 넘거나 새로운 데이터 권리를 요구하는 거래는 사람에게 올릴 수 있다. 성공 기준도 ‘사람이 한 번도 개입하지 않음’보다 거래 준비 시간, 조건 오류, 실제 증분 성과, 분쟁률로 잡아야 한다. **DSP가 입찰을 자동화했다면 협상 에이전트는 시장의 문법을 자동화한다.** 승자는 가장 말 잘하는 봇을 가진 회사가 아니라 목표와 권한, 거래 상태와 책임을 가장 명확하게 표현한 회사가 될 가능성이 크다. --- 주요 출처: IAB Tech Lab, [Buyer Agent Alpha](https://iabtechlab.github.io/buyer-agent/?ref=zerodraftlab.com) 및 [Agentic Advertising Management Protocols](https://iabtechlab.com/standards/aamp-agentic-advertising-management-protocols/?ref=zerodraftlab.com). Buyer Agent는 Alpha 참조 구현이며 전체 광고 시장에서 상용 배포된 표준을 뜻하지 않습니다. 작은 맞춤형 거래의 경제성과 중개자 가치 이동은 프로토콜 구조를 바탕으로 한 이 글의 분석입니다. ### 광고는 이제 사람을 설득하지 않는다 URL: https://zerodraftlab.com/advertising-no-longer-persuades-people/ Last updated: 2026-09-15T08:35:45.000Z 광고는 오랫동안 사람의 마음속에서 벌어지는 경쟁으로 설명됐다. 더 오래 기억되고, 더 자주 떠오르고, 구매 순간에 더 강한 욕망을 만드는 브랜드가 이긴다는 이야기였다. 그런데 소비자가 검색창보다 대화형 에이전트에 먼저 질문하고, 그 에이전트가 후보를 비교해 몇 개만 돌려준다면 경쟁의 첫 관문이 달라진다. **광고의 다음 전장은 사람의 설득이 아니라 에이전트의 후보 목록이다.** 사람에게 보이기 전에 기계가 발견할 수 있어야 하고, 기계가 읽기 전에 최신 정보가 있어야 하며, 기계가 추천하기 전에 그 선택을 뒷받침할 증거가 있어야 한다. McKinsey는 2026년 6월 이 변화를 ‘주의에서 행동으로’의 이동이라고 불렀다. 2026년 2월 미국 광고 리더 182명을 조사한 결과, 절반은 AI가 이미 소비자의 발견 방식을 바꿨다고 답했고 약 4분의 3은 관련 지출이 늘 것이라 봤다. 이 숫자는 시장 전체의 확정된 미래가 아니라 광고 리더의 인식 조사다. 그래도 예산을 쥔 사람들이 클릭 이후가 아니라 발견 이전의 기계적 선택을 보기 시작했다는 신호는 된다. ## 노출보다 먼저 후보에 들어가야 한다 전통적인 검색 광고에서는 브랜드가 키워드 경매에서 노출을 사고, 사람이 여러 링크를 본 뒤 선택했다. 대화형 에이전트는 이 과정을 압축한다. 사용자가 “민감성 피부에 맞고 오늘 배송되는 제품을 골라줘”라고 말하면 에이전트는 가격, 성분, 재고, 배송, 후기, 반품 조건을 한꺼번에 비교할 수 있다. 사람은 스무 개의 파란 링크 대신 세 개의 정리된 후보를 받을 가능성이 커진다. 이때 네 번째로 좋은 제품은 예전의 검색 결과 4위와 다르다. 검색 결과 4위는 여전히 화면에 보이지만, shortlist 밖의 제품은 아예 비교 대상이 되지 않는다. 광고가 만든 인지도도 중요하지만 에이전트가 요구한 조건을 확인하지 못하면 유명한 브랜드조차 후보에서 빠질 수 있다. 그래서 브랜드의 새 과제는 ‘기계에게 잘 보이는 문구’를 만드는 데 그치지 않는다. 상품 식별자, 가격, 재고, 배송 가능 지역, 반품 규칙, 검증된 후기, 공식 설명이 서로 모순되지 않게 유지돼야 한다. 에이전트는 브랜드의 감성 카피보다 “이 조건을 충족한다”는 최신 증거를 먼저 필요로 한다. ## 브랜드는 사라지지 않고 역할이 바뀐다 그렇다고 브랜드가 무의미해지는 것은 아니다. 에이전트가 모든 제품의 품질을 직접 시험할 수는 없다. 출처가 불완전하거나 선택의 결과가 비싼 영역에서는 평판, 보증, 일관된 고객 경험이 불확실성을 줄이는 대리 변수로 남는다. 브랜드는 사람의 기억뿐 아니라 에이전트가 위험을 추정할 때 쓰는 신뢰 신호가 된다. 차이는 브랜드가 자기소개만으로 그 신뢰를 주장하기 어려워진다는 데 있다. “프리미엄”, “혁신적”, “고객 중심” 같은 표현은 기계가 비교할 수 있는 근거가 아니다. 반면 인증 주체, 성능 시험, 실제 반품률, 응답 시간, 재고 정확도는 선택 규칙에 들어갈 수 있다. 브랜드의 약속은 서사로 시작해도 운영 데이터로 증명돼야 한다. 이 변화는 광고팀의 목표를 노출과 클릭에서 곧바로 없애지는 않는다. 사람은 여전히 취향을 만들고 충동적으로 선택하며 광고를 본다. 다만 선택의 일부를 에이전트에 위임하는 순간, 사람에게 기억되는 일과 기계의 후보가 되는 일이 서로 다른 과업으로 갈라진다. 두 과업을 다시 연결하려면 광고 성과의 단위부터 바꿔야 한다. 사람이 광고를 봤는지만 측정하는 것이 아니라 어떤 질문에서 브랜드가 후보로 등장했고, 어떤 조건 때문에 탈락했으며, 추천 뒤 실제 구매와 만족으로 이어졌는지를 추적해야 한다. ## 새 퍼널은 질문에서 시작한다 에이전트 시대의 상단 퍼널은 키워드 목록보다 사용자의 위임 문장에 가깝다. “가성비 좋은 러닝화”와 “무릎 통증이 있고 주 3회 5킬로미터를 뛰는 초보자용 러닝화”는 같은 카테고리 검색이 아니다. 두 번째 문장은 상황, 제약, 위험, 사용 빈도를 함께 담는다. 브랜드가 어떤 질문의 답이 되고 싶은지를 정하지 않으면 모든 상품 데이터를 정리해도 선택 이유가 흐려진다. 여기서 광고팀과 상품팀의 경계가 무너진다. 에이전트가 배송 약속을 근거로 추천했는데 실제 재고가 틀리면 광고 소재의 문제가 아니라 운영 데이터의 실패가 된다. 반대로 고객지원 기록에서 반복되는 사용 맥락을 발견하면 그것은 새 광고 카피뿐 아니라 에이전트가 이해할 수 있는 상품 속성으로 바뀌어야 한다. 측정도 한 번의 추천 점유율로 끝낼 수 없다. 에이전트 답변은 모델, 프롬프트, 위치, 시점, 사용자 조건에 따라 달라진다. 특정 질문을 백 번 반복해 언급 횟수를 세는 것만으로 시장점유율을 말하면 안 된다. 질문군을 구매 상황별로 고정하고, 출처가 무엇인지 기록하며, 추천 이유와 탈락 이유의 변화를 함께 봐야 한다. ## 돈을 내고 후보가 되는 순간 신뢰 문제가 생긴다 브랜드가 구조화된 정보와 실제 운영 품질로 shortlist에 드는 것은 유기적 선택이다. 광고비를 내고 후보에 끼어드는 것은 다른 문제다. 에이전트가 상업적 영향을 받았다면 사용자는 어떤 후보가 광고인지, 그 대가가 순위와 설명에 어떤 영향을 줬는지 알아야 한다. 표시가 사라지면 추천 품질과 광고 수익을 구분할 방법도 사라진다. 따라서 에이전트용 광고 상품은 단순한 ‘스폰서드 답변’으로 설계되기 어렵다. 광고주가 제공한 주장과 독립된 출처를 구분하고, 유료 노출이 조건 충족을 덮어쓰지 못하게 하며, 추천 실패를 이의 제기할 수 있어야 한다. 사람에게 광고 배지를 보여주는 문제보다 더 복잡한 이유는 에이전트가 설명뿐 아니라 행동까지 대신할 수 있기 때문이다. 브랜드가 지금 준비할 것은 AI에 잘 먹히는 마법의 문장이 아니다. 어떤 구매 상황에서 선택받을지 정의하고, 그 상황을 증명하는 상품·운영 데이터를 정리하고, 추천과 실제 경험의 차이를 다시 데이터로 돌려보내는 체계다. 이 체계가 없으면 광고비를 늘려 잠시 노출될 수는 있어도 에이전트가 반복해서 선택할 이유는 만들지 못한다. **사람의 마음을 얻는 브랜드가 끝난 것이 아니다. 이제 그 마음에 도달하기 전에 기계의 검증을 통과해야 한다.** 다음 광고 경쟁은 더 큰 목소리를 내는 싸움이 아니라, 더 정확하고 최신이며 검증 가능한 선택 이유를 제공하는 싸움이다. --- 주요 출처: McKinsey, [The agentic advertising economy: From attention to action](https://www.mckinsey.com/industries/technology-media-and-telecommunications/our-insights/the-agentic-advertising-economy-from-attention-to-action?ref=zerodraftlab.com), 2026년 6월 16일. 조사 수치는 2026년 2월 미국 광고 리더 182명의 응답이며 소비자 행동 전체를 직접 측정한 결과가 아닙니다. shortlist, 질문 기반 퍼널, 운영 데이터와 브랜드 신뢰의 결합은 해당 보고서를 바탕으로 확장한 이 글의 분석입니다. ### 불쾌한 아저씨 댓글의 문법 URL: https://zerodraftlab.com/comment-is-not-your-stage/ Last updated: 2026-07-14T14:56:34.000Z 불쾌한 아저씨 댓글에는 공통점이 있다. 원글을 읽고 대화에 들어오는 대신, 원글을 자기 지식 자랑의 발판으로 쓴다. 글이 무엇을 말했는지는 별로 중요하지 않다. 문장 하나를 걸쳐 놓고는 갑자기 자기가 아는 업계 이야기, 읽은 책, 오래된 경험을 늘어놓는다. 댓글은 원글에 답하지 않고, 원글이 모아놓은 사람들에게 자신을 설명한다. ## 댓글을 단 게 아니라 무대를 빼앗은 것이다 이런 댓글이 단순한 반박보다 더 불쾌한 이유가 있다. 반박하려면 적어도 상대의 주장을 읽어야 한다. 그러나 맥락 없는 지식 자랑에는 독해가 필요 없다. 상대의 글은 대화의 대상이 아니라 이미 모여 있는 청중을 빌리는 장소가 된다. 그래서 댓글이 길어서 불쾌한 것도, 아는 게 많아서 불쾌한 것도 아니다. 원글 작성자를 대화 상대로 대하지 않는 태도가 불쾌한 것이다. 남의 말을 듣는 척하면서 자기 차례만 기다린다. ## 댓글은 지식량보다 독해력을 공개한다 좋은 댓글은 먼저 원글의 맥락을 정확히 잡는다. 무엇에 동의하는지, 무엇을 묻는지, 어떤 부분을 보완하는지가 분명하다. 자기 경험을 꺼내더라도 원글과 실제로 연결되는 만큼만 쓴다. 반대로 자기 이야기가 원글보다 커지는 순간, 그건 댓글이 아니라 남의 마당에 세운 임시 무대다. 그렇게 할 말이 많다면 댓글창을 점거할 게 아니라 자기 글을 새로 쓰는 편이 낫다. ## 여기서 ‘아저씨’는 나이가 아니라 태도다 젊은 사람도 얼마든지 이런 댓글을 쓴다. 여기서 아저씨 같은 것은 나이가 아니라 낡은 관계 감각이다. 타인의 말은 이해할 대상이 아니라 내 지식을 꺼내기 위한 전주이고, 대화는 함께 만드는 것이 아니라 내가 접수해야 하는 무대라고 여기는 태도다. **남의 글을 내 지식의 증거로 쓰지 마라. 댓글은 내가 얼마나 많이 아는지보다, 남의 말을 얼마나 정확히 읽었는지를 먼저 드러낸다.** ### ‘시스템이 없어서 그렇습니다’라는 만능 진단 URL: https://zerodraftlab.com/consultants-cannot-install-an-organization/ Last updated: 2026-09-15T08:35:46.000Z “사업이 힘드신 이유는 시스템이 없어서입니다.” “매출이 안 나는 이유는 브랜딩이 없어서입니다.” 대행사와 컨설턴트의 오래된 레퍼토리다. 사장에게 지금 겪는 고통을 말하게 한 뒤, 그 고통에 자기 상품의 이름을 붙인다. 광고를 파는 사람은 퍼널이 없다고 하고, 자동화를 파는 사람은 시스템이 없다고 하고, 디자인을 파는 사람은 브랜드가 없다고 한다. 진단이 끝났을 때 원인은 놀랍도록 정확하게 그 사람이 파는 것과 일치한다. 나는 이런 말을 들을 때마다 한 가지부터 의심한다. **이것은 진단인가, 자기 상품을 팔기 위한 원인명 붙이기인가.** 시스템과 브랜딩이 중요하지 않아서가 아니다. 둘 다 중요하다. 문제는 이 단어들이 너무 커서 어떤 실패도 집어삼킬 수 있다는 데 있다. 고객이 안 오는 것도 브랜딩, 직원이 실수하는 것도 시스템, 재구매가 없는 것도 브랜딩, 대표가 결재를 놓지 못하는 것도 시스템이라고 부르면 틀릴 방법이 없다. 틀릴 방법이 없는 진단은 통찰이 아니라 판매용 면책조항이다. ## 만능 원인은 판매자에게만 편하다 좋은 진단은 범위를 줄인다. 어느 고객이 어느 구매 상황에서 우리를 떠올리지 못하는지, 리드가 어느 단계에서 사라지는지, 누가 어떤 결정을 붙잡고 있어서 일이 멈추는지, 한 건의 주문이 어느 인수인계에서 틀어지는지를 말한다. 관찰할 수 있고 반박할 수 있으며, 개입 전후를 비교할 수 있다. 반대로 “시스템이 없다”와 “브랜딩이 없다”는 말은 범위를 넓힌다. 무엇을 바꿀지보다 왜 자기 패키지를 사야 하는지를 먼저 설명한다. 로고, 브랜드북, CRM, 자동화 시나리오, SOP가 납품되면 일은 끝난다. 조직이 실제로 다르게 행동하지 않아도 산출물은 존재하므로 대금은 정당화된다. 성과가 안 나면 고객이 실행하지 않았다고 하면 된다. 그래서 먼저 단어를 현실로 내려야 한다. 시스템은 노션 페이지나 툴 이름이 아니다. 특정 사건이 생기면 누가 판단하고, 다음 행동이 무엇이며, 결과가 어디에 기록되고, 오류가 어떻게 발견되고, 같은 실패를 다음번에 어떻게 줄이는지까지 반복되는 행동이다. 문서가 없어도 반복 행동이 안정적이면 시스템은 있다. 문서가 백 장이어도 아무도 그 순서로 움직이지 않으면 시스템은 없다. 브랜드도 브랜드북 안에 있지 않다. Romaniuk과 Sharp는 브랜드 현저성을 구매 상황에서 그 브랜드가 눈에 띄거나 떠오를 가능성으로 설명한다. 그것은 구매자의 기억 속 연결망에 달려 있다. Ehrenberg-Bass 연구진이 함께 강조하는 물리적 가용성까지 생각하면 더 분명해진다. 고객이 떠올릴 수 있어도 원하는 형태와 가격으로 쉽게 살 수 없다면 브랜드 성장은 막힌다. 이 관점에서 로고와 색, 말투는 쓸모없지 않다. 반복해서 알아보게 만드는 단서가 될 수 있다. 그러나 구매할 상품이 흐리고, 재고가 없고, 문의 답변이 늦고, 지점마다 경험이 다르고, 가격이 납득되지 않는 사업에 시각체계만 넣는다고 브랜드가 생기지는 않는다. 브랜딩은 운영을 대신하는 화장이 아니라 운영이 남긴 기억을 더 쉽게 식별하게 만드는 일이다. ## 외부 지식은 파일처럼 설치되지 않는다 대행사가 산출물을 만들 수 있다는 사실과 조직이 능력을 갖게 된다는 사실은 다르다. 광고 소재는 외주화할 수 있고, 웹사이트는 납품받을 수 있고, 회계 장부는 기장 대행에 맡길 수 있다. 그러나 그 결과를 읽고 다음 결정을 바꾸는 능력까지 자동으로 이전되지는 않는다. Cohen과 Levinthal은 외부 지식의 가치를 알아보고, 흡수하고, 사업에 적용하는 조직의 능력을 ‘흡수역량’이라고 불렀다. 중요한 대목은 외부 지식이 많을수록 무조건 좋아지는 것이 아니라는 점이다. 받아들일 선행지식과 내부 연결이 있어야 외부 전문성이 능력이 된다. 좋은 컨설턴트를 샀는데 조직에 아무것도 남지 않는 이유를 “직원들이 변화에 저항해서”라고만 설명할 수 없다. 애초에 받아서 적용할 구조가 없었을 수 있다. 더 불편한 연구도 있다. Szulanski가 여덟 개 회사의 122건의 내부 모범사례 이전을 분석했더니, 같은 회사 안에서도 좋은 방법은 쉽게 복제되지 않았다. 큰 장애물은 단순한 동기 부족보다 수용자의 낮은 흡수역량, 무엇이 성과를 만들었는지 알기 어려운 인과적 모호성, 지식을 주고받는 관계의 마찰이었다. 한 조직 안에서도 이렇게 어려운데, 계약서 한 장 건너의 외부업자가 조직을 바꾸는 일이 쉬울 리 없다. 그렇다고 컨설턴트가 조직을 바꿀 수 없다는 뜻은 아니다. 인도 섬유공장을 대상으로 한 무작위 실험은 제대로 개입한 컨설팅이 생산성을 높일 수 있음을 보여줬다. 다만 그 개입은 우리가 흔히 보는 진단 리포트와 달랐다. 통제 공장도 한 달 동안 진단을 받고 개선 권고를 받았다. 처치 공장은 거기에 네 달의 구현 지원이 더해졌다. 컨설턴트는 매일의 품질 회의에 처음 몇 주 동안 직접 참석했고, 관리자와 절차를 설치하고, 조정하고, 직원이 반복할 수 있을 때까지 안정화했다. 통제 공장에 투입된 컨설팅은 평균 225시간, 처치 공장은 733시간이었다. 진단만 받은 공장의 관리 관행 채택은 평균 12%포인트 늘었지만 구현 지원이 붙은 공장은 약 38%포인트 늘었고, 연구진은 첫해 생산성이 18% 높아졌다고 추정했다. 외부인이 조직을 바꾼 것이 맞다. 그러나 그들은 “시스템이 없네요”라고 말하고 파일을 전달한 뒤 떠나지 않았다. 회의에 들어가고, 측정값을 만들고, 직원이 실제로 행동하는 순간을 보고, 절차가 굴러갈 때까지 수정했다. **조직을 바꾸는 컨설팅은 컨설팅처럼 보이지 않고 한동안 조직의 관리노동처럼 보인다.** 그 차이를 지운 채 모든 사장에게 같은 원인을 붙이는 순간, 조언은 전문성이 아니라 레퍼토리가 된다. 그 레퍼토리가 특히 비겁한 이유는 성공과 실패를 모두 판매자의 공으로 돌릴 수 있기 때문이다. 결과가 좋아지면 자기 전략이 맞았다고 한다. 결과가 나쁘면 고객 조직에 시스템과 실행력이 없었다고 한다. 어느 쪽이든 진단은 살아남는다. 반증되지 않는 전문가는 언제나 옳지만, 그래서 아무 책임도 지지 않는다. ## 변화를 유지한 것은 슬라이드가 아니라 사람의 시간이었다 인도 실험의 9년 후 추적 결과는 더 정확한 경계를 보여준다. 처치 공장이 도입했던 관리 관행 가운데 약 절반은 사라졌다. 그래도 통제집단과의 관행 및 성과 격차는 유의하게 남았고, 일부 방법은 같은 회사의 다른 공장으로 퍼졌다. 외부 개입이 모두 증발한 것도, 영구히 고정된 것도 아니었다. 무엇이 사라짐을 설명했을까. 연구에서 반복해서 언급된 이유는 관리자의 이직과 이사의 시간 부족이었다. 좋은 방법을 안다고 유지되는 것이 아니었다. 핵심 직원이 남아 계속 주의를 주고, 누군가 그 행동을 요구하고, 회의와 기록에 시간을 배정해야 했다. 지속성은 컨설턴트의 권위보다 내부의 주의력 배분에 달려 있었다. 멕시코 중소기업 432곳을 대상으로 한 또 다른 무작위 실험도 “외부업자는 아무것도 못 바꾼다”는 냉소를 반박한다. 150곳이 보조 컨설팅 처치군으로 무작위 배정됐고, 그중 80곳이 실제 프로그램에 참여했다. 참여기업은 아홉 개 지역 컨설팅회사 가운데 필요한 전문성에 맞는 곳과 연결됐고, 일 년 동안 매주 네 시간씩 함께 일했다. 기업주와 컨설턴트가 하루짜리 진단을 토대로 범위와 목표를 공동 결정했고, 컨설턴트의 임무에는 해법 제안뿐 아니라 실제 구현 지원이 포함됐다. 그 결과 1년 뒤 생산성과 총자산수익률이 개선됐다. 5년의 행정자료에서는 고용인원과 임금총액의 큰 증가도 관찰됐다. 하지만 모든 기업에 같은 한 가지 방법이 먹힌 것은 아니었다. 어떤 곳은 마케팅을 고쳤고, 어떤 곳은 회계를 공식화했으며, 어떤 곳은 역할을 나누거나 장기계획을 세웠다. 연구진도 단 하나의 성장 스위치는 없다고 선을 그었다. 이 두 실험은 컨설팅 업계를 위한 승전보가 아니다. 오히려 평범한 대행사 제안서가 얼마나 적은 일을 약속하는지 드러낸다. 성과를 낸 개입에는 현장 체류, 반복 관찰, 관리자와의 공동 설계, 직원 행동의 수정, 데이터 측정, 장기간의 구현 지원이 있었다. 비용도 작지 않았다. 멕시코 프로그램에서 보조금 전 컨설팅 비용은 기업당 연간 약 1만1,856달러였다. ‘대표님은 시스템이 없어서 힘듭니다’라는 한 문장과는 전혀 다른 상품이다. ## 브랜딩이라는 말도 같은 방식으로 책임을 숨긴다 브랜딩 대행은 특히 결과의 인과를 흐리기 쉽다. 새 이름과 로고를 공개한 뒤 매출이 오르면 리브랜딩 덕분이라고 말하기 쉽다. 같은 시기에 가격, 상품, 유통, 광고비, 영업인력, 매장, 계절성이 함께 바뀌었어도 그렇다. 반대로 매출이 그대로면 브랜드가 자리 잡는 데 시간이 걸린다고 한다. 성공은 즉시 귀속하고 실패는 미래로 연기한다. 브랜드 현저성이 구매 상황의 기억이고 브랜드 성장이 정신적·물리적 가용성의 축적이라면, 외부 브랜딩 회사가 실제로 바꿔야 할 범위는 생각보다 넓다. 고객이 언제 이 상품을 떠올려야 하는지 정하고, 그 상황과 연결되는 표현을 반복하고, 판매 채널에서 쉽게 찾게 하고, 원하는 규격과 가격으로 살 수 있게 하고, 구매 뒤 경험이 그 약속을 배반하지 않게 해야 한다. 이름과 로고는 그 연쇄의 일부일 뿐이다. 그런데 대행사는 보통 이 연쇄 전체에 대한 권한이 없다. 제품을 바꿀 수 없고, 가격을 결정할 수 없고, 재고를 늘릴 수 없고, 직원의 응대 기준을 강제할 수 없고, 대표의 변덕을 막을 수도 없다. 할 수 없는 것이 많다는 사실 자체는 잘못이 아니다. 잘못은 그 제한을 숨긴 채 조직 전체의 결과를 약속하는 데 있다. 그래서 좋은 외부업자는 자기 영향력을 작게 말한다. 우리가 바꿀 수 있는 행동이 무엇인지, 고객 조직에서 누가 그 행동을 소유할지, 어떤 데이터로 전후를 볼지, 어느 시점에 내부팀이 넘겨받을지부터 정한다. 실행 권한이 없으면 결과를 보장하지 않고, 제품 문제라면 브랜딩 계약을 거절하며, 내부 책임자가 시간을 내지 못하면 프로젝트를 시작하지 않는다. 나쁜 외부업자는 반대로 말한다. 자기 산출물은 조직을 바꿀 만큼 크다고 팔고, 실패했을 때 자기 권한은 조직을 바꿀 만큼 크지 않았다고 변명한다. 팔 때는 변혁이고 끝날 때는 납품이다. ## 외부 전문성은 빌릴 수 있어도 소유권은 외주화할 수 없다 회사가 모든 능력을 내부에 둘 필요는 없다. 오히려 낯선 문제를 빨리 이해하고 특정 결과물을 만드는 데 외부 전문가는 강하다. 내부 정치에서 떨어져 있기 때문에 보이는 것도 있고, 여러 회사를 경험했기 때문에 빨리 알아보는 패턴도 있다. 문제는 외부 전문성을 내부 소유권의 대체재로 착각할 때 생긴다. 어떤 행동을 조직의 습관으로 만들려면 내부 누군가가 그 행동을 요구하고, 예외를 판단하고, 사람과 예산을 배정하고, 결과가 나쁠 때 규칙을 고쳐야 한다. 컨설턴트가 그 역할을 잠시 맡거나 가르칠 수는 있다. 그러나 계약이 끝난 뒤에도 계속 책임질 내부 주체가 없으면 회사는 능력을 산 것이 아니라 대여한 것이다. 따라서 대행사의 품질은 제안서의 통찰보다 철수 뒤에 남는 것으로 평가해야 한다. 직원이 이전과 다른 질문을 하는가. 회의에서 같은 수치를 보는가. 일이 막히면 다음 담당자가 정해져 있는가. 고객 반응이 다음 상품과 메시지에 반영되는가. 외부업자가 없어도 그 행동이 계속되는가. 남지 않았다면 시스템을 구축한 것이 아니라 시스템이 있는 동안 빌려 쓴 것이다. “시스템이 없어서 그렇습니다”와 “브랜딩이 없어서 그렇습니다”가 언제나 틀린 말은 아니다. 구체적인 행동과 데이터로 번역되고, 외부업자와 내부조직의 책임 경계가 선명하며, 구현과 이전까지 계약에 들어 있다면 유효한 진단일 수 있다. 하지만 상품도, 가격도, 고객도, 권한도, 직원도, 기록도 제대로 보지 않은 채 사장의 불안을 듣자마자 자기 패키지 이름을 원인으로 붙이는 사람들. 조직을 바꿀 권한은 없으면서 조직을 바꿔주겠다고 팔고, 납품 뒤에는 고객의 실행력을 탓하는 사람들. **문제를 해결하는 전문가가 아니라, 고객의 실패를 자기 상품으로 번역하는 판매자다.** 좋은 컨설턴트는 조직을 대신 구원하지 않는다. 조직이 외부 지식을 흡수하고 자기 행동으로 바꾸도록 오래, 구체적으로, 함께 일한다. 좋은 대행사는 브랜드를 만들어준다고 말하지 않는다. 고객이 더 쉽게 떠올리고 사고 다시 찾게 만드는 제한된 변화를 책임진다. 외부업자의 가치는 얼마나 거대한 말을 하느냐가 아니라, 자기가 떠난 뒤에도 어떤 행동이 남느냐로 판명된다. --- 주요 출처: Wesley M. Cohen·Daniel A. Levinthal, [“Absorptive Capacity: A New Perspective on Learning and Innovation”](https://doi.org/10.2307/2393553?ref=zerodraftlab.com), *Administrative Science Quarterly* 35(1), 1990; Gabriel Szulanski, [“Exploring Internal Stickiness”](https://doi.org/10.1002/smj.4250171105?ref=zerodraftlab.com), *Strategic Management Journal* 17, 1996; Nicholas Bloom 외, [“Does Management Matter? Evidence from India”](https://conference.nber.org/confer/2011/EFGs11/Bloom%5FEifert%5FMahajan%5FMcKenzie%5FRoberts.pdf?ref=zerodraftlab.com), *Quarterly Journal of Economics* 128(1), 2013; Nicholas Bloom 외, [“Do Management Interventions Last? Evidence from India”](https://www.aeaweb.org/articles?id=10.1257%2Fapp.20180369&ref=zerodraftlab.com), *American Economic Journal: Applied Economics* 12(2), 2020; Miriam Bruhn·Dean Karlan·Antoinette Schoar, [“The Impact of Consulting Services on Small and Medium Enterprises”](https://doi.org/10.1086/696154?ref=zerodraftlab.com), *Journal of Political Economy* 126(2), 2018; Jenni Romaniuk·Byron Sharp, [“Conceptualizing and Measuring Brand Salience”](https://doi.org/10.1177/1470593104047643?ref=zerodraftlab.com), *Marketing Theory* 4(4), 2004; Ehrenberg-Bass Institute, [“How do you measure ‘How Brands Grow’?”](https://marketingscience.info/news-and-insights/how-do-you-measure-how-brands-grow?ref=zerodraftlab.com). 인도·멕시코 연구는 특정 산업과 지역의 개입을 분석한 것으로 모든 컨설팅·대행 계약에 일반화할 수 없습니다. 이 글은 해당 연구에서 공통으로 드러난 구현 강도, 내부 흡수역량, 핵심 인력과 시간의 조건을 한국의 대행사 판매 레퍼토리 비판에 적용한 해석입니다. ### 월 $8K가 MRR이 아닐 때 URL: https://zerodraftlab.com/revenue-is-not-recurring/ Last updated: 2026-09-15T08:35:47.000Z Designpop의 성장담은 부트스트래퍼가 좋아할 만한 요소를 거의 다 갖췄다. 여러 SaaS를 시도한 개발자가 제품을 더 만들지 않고 디자인·개발 서비스를 팔기 시작했다. 첫 달 매출은 1,500달러, 3개월 차는 3,000달러, 연말 무렵에는 월 8,000달러까지 올라갔다. 출발 가격도 공격적이었다. 디자인 작업은 월 1,000달러, 랜딩페이지는 599달러였다. 첫 달에는 랜딩페이지 두 건으로 1,200달러를 만들었다. 이후 몇 달 동안 고객을 확보하고 품질과 속도를 증명한 뒤, 반복 고객이 생긴 8개월 차부터 가격을 올렸다. 이 사례에서 가장 쉽게 꺼낼 수 있는 교훈은 “SaaS를 만들지 말고 서비스를 팔아라”다. 그러나 더 중요한 교훈은 따로 있다. **월 매출과 월 반복 매출은 같은 숫자가 아니다.** ## 월 $8K라는 숫자에는 서로 다른 매출이 들어 있다 인터뷰에서 창업자는 월 약 8,000달러가 구독과 일회성 랜딩페이지 작업으로 나뉜다고 직접 설명한다. 그런데 제목은 이를 8,000달러 MRR로 부른다. 랜딩페이지 한 건이 다음 달에도 자동으로 갱신되지 않는다면 그 매출은 그달의 매출이지, 엄밀한 의미의 월 반복 매출은 아니다. 이 차이는 말꼬리 잡기가 아니다. 8,000달러가 모두 활성 구독에서 나온다면 다음 달은 8,000달러에서 시작한다. 절반이 일회성 프로젝트라면 다음 달은 4,000달러에서 다시 영업을 시작할 수 있다. 손익계산서에는 같은 8,000달러로 찍혀도 사업의 기억력은 전혀 다르다. MRR은 지난달 얼마나 팔았는지를 보여주는 숫자가 아니다. 고객이 아무 행동을 하지 않아도 다음 달에 얼마가 이어질지를 보여주는 숫자다. 그래서 MRR을 주장하려면 최소한 활성 구독 매출, 신규 MRR, 확장 MRR, 축소 MRR, 해지 MRR이 분리되어야 한다. Designpop의 공개 인터뷰에는 Stripe 대시보드, 구독과 일회성 매출의 정확한 비중, 매출총이익, 해지율이 없다. 이 사례는 거짓이라고 단정할 수 없지만, 검증된 반복 매출 사례로 읽을 수도 없다. ## 그래도 서비스 전환에서 배울 것은 분명하다 숫자의 이름을 바로잡는다고 사례의 가치가 사라지는 것은 아니다. Designpop은 제품이 완성되기를 기다리지 않고 이미 보유한 디자인·개발 능력을 범위가 정해진 상품으로 바꿨다. 고객은 추상적인 개발 역량이 아니라 랜딩페이지, MVP, 월 구독이라는 구매 단위를 봤다. 낮은 초기 가격도 단순한 덤핑으로만 볼 수 없다. 무엇을 요청하는지, 어디서 수정이 폭발하는지, 어떤 결과에 다시 돈을 내는지 배우기 위한 유료 탐색 비용에 가까웠다. 무료 인터뷰나 대기자 명단보다 돈을 낸 고객의 요구가 더 정확한 언어를 준다. 반복 고객이 생긴 뒤 가격을 올린 순서 역시 가격을 자신감이 아니라 관찰된 수요 위에 세웠다는 뜻이다. 따라서 이 이야기를 “서비스가 SaaS를 이겼다”로 읽으면 절반만 읽은 셈이다. 더 정확한 해석은 **서비스가 현금흐름과 고객 언어를 먼저 샀다**는 것이다. 문제는 이 현금흐름이 시간이 지나면서 사업의 자산이 되는지, 아니면 창업자가 매달 다시 밀어야 하는 수레로 남는지다. ## 반복되는 결제보다 반복되는 문제가 먼저다 서비스를 구독으로 포장했다고 해서 SaaS와 같은 경제성이 생기지는 않는다. 고객이 매달 결제해도 매달 새로운 사람이 같은 양의 일을 해야 한다면 매출은 반복되지만 노동도 반복된다. 반대로 일회성 랜딩페이지라도 같은 고객이 캠페인마다 돌아오고, 조사·카피·개발 과정이 표준화되며, 추천이 누적된다면 아직 MRR은 아니어도 반복 가능한 사업에 가까워진다. 그래서 먼저 측정할 것은 청구 주기가 아니다. 어떤 문제가 얼마나 자주 재발하는지, 결과물을 만드는 데 실제 몇 시간이 드는지, 고객 한 곳을 더 받을 때 병목이 어디서 생기는지다. 구독 매출 4,000달러가 창업자의 주 40시간을 모두 먹는다면 확장성은 낮다. 일회성 매출 4,000달러가 표준 절차와 재사용 자산을 남기고 열 시간에 끝난다면 다음 단계의 가능성은 더 크다. 그렇다면 서비스 매출은 어떻게 다음 달에도 남는 사업의 자산으로 바뀌는가. 그 전환은 서비스를 단순한 납품 수단이 아니라 고객 문제를 관찰하는 장치로 쓸 때 시작된다. ## 서비스는 제품의 반대가 아니라 관측 장치가 될 수 있다 SaaS를 먼저 만들면 창업자는 기능 사용 로그를 얻는다. 서비스를 먼저 팔면 고객이 결과를 얻기까지 벌어지는 전체 과정을 본다. 고객이 무엇을 말하는지뿐 아니라 무엇을 준비하지 못하는지, 어떤 결정에서 멈추는지, 어느 예외 때문에 납기가 늘어나는지를 가까이서 관찰한다. 이 관찰이 쌓이면 세 가지가 남는다. 반복해서 등장하는 고객 언어는 마케팅 자산이 되고, 반복해서 수행하는 순서는 운영 절차가 되며, 반복해서 막히는 단계는 소프트웨어 후보가 된다. 이때 제품은 서비스에서 도망치기 위해 만드는 것이 아니라, 이미 돈을 받고 여러 번 확인한 병목을 압축하기 위해 만든다. 반대로 모든 고객 요청을 맞춤형으로 받아주면 아무것도 축적되지 않는다. 매출은 늘어도 사례마다 새로 견적을 내고, 새로 설명하고, 새로 납품해야 한다. “제품화된 서비스”의 핵심은 멋진 구독 페이지가 아니라 거절할 범위를 정하는 데 있다. 표준 입력, 제한된 산출물, 명확한 수정 횟수, 한 번에 처리할 요청 수가 없으면 구독은 안정성이 아니라 무제한 부채가 된다. ## 월 매출을 네 칸으로 나누면 착시가 줄어든다 이런 사업을 볼 때는 한 개의 MRR 숫자 대신 네 가지를 분리하는 편이 낫다. 첫째는 다음 달에도 계약상 이어지는 구독 매출이다. 둘째는 그달에 새로 수주해야만 생기는 프로젝트 매출이다. 셋째는 같은 고객이 다시 구매한 반복 프로젝트 매출이다. 넷째는 창업자와 외주 인력을 제외하고 남는 공헌이익이다. 이 네 숫자를 나누면 성장의 성격이 보인다. 신규 프로젝트 매출이 반복 구매로 이동하고, 반복 구매가 구독으로 이동하며, 고객당 전달 시간이 줄고, 공헌이익이 유지된다면 서비스는 점점 기억을 갖는다. 반대로 월 매출만 오르고 신규 영업 시간과 납품 시간이 같은 속도로 늘면 성장한 것은 시스템이 아니라 작업량이다. Designpop의 공개 자료만으로는 어느 쪽인지 확정할 수 없다. 현재 웹사이트에는 랜딩페이지 1,950달러, 디자인·개발 구독 3,999달러 같은 더 높은 가격이 제시되어 있어 가격 인상 자체는 확인된다. 그러나 가격표는 유지율이나 이익을 증명하지 않는다. 성공담은 출발점일 뿐, 사업의 질은 코호트와 원가에서 판명된다. ## 서비스를 먼저 팔되, 서비스에 갇히지는 말 것 초기 창업자에게 서비스의 장점은 속도다. 오늘 팔 수 있고, 이번 주에 고객의 실제 업무를 볼 수 있으며, 이번 달에 현금이 들어온다. SaaS가 약속하는 미래의 레버리지를 기다리는 동안 서비스는 현재의 수요를 검증한다. 하지만 서비스 매출을 SaaS식 MRR로 부르는 순간 가장 중요한 경고등이 꺼진다. 다음 달에도 남는 고객은 몇 명인지, 창업자가 쉬면 매출이 얼마나 유지되는지, 같은 결과를 더 적은 시간으로 만들 수 있는지 묻지 않게 된다. 숫자를 부풀리는 용어는 동기부여에는 도움이 될지 몰라도 운영에는 해롭다. Designpop에서 복제할 것은 8,000달러라는 결승선이 아니다. 작은 범위의 서비스를 먼저 팔고, 돈을 낸 고객에게서 언어를 배우고, 반복 구매가 확인된 뒤 가격을 올린 순서다. 그리고 여기에 한 단계를 더 붙여야 한다. 매달 매출을 구독, 일회성, 반복 프로젝트, 공헌이익으로 다시 나누는 일이다. **성공담에서 먼저 볼 것은 매출액이 아니라, 그 매출이 정말 반복되는가다.** 더 정확히는 결제만 반복되는지, 고객의 문제와 전달 시스템까지 반복 가능해졌는지를 봐야 한다. 서비스는 제품보다 먼저 현금을 만들 수 있다. 그러나 사업이 되는 순간은 현금이 아니라 학습과 운영이 다음 달까지 남을 때다. --- 주요 출처: James Fleischmann, [$8k MRR within a year after pivoting to productized services](https://www.indiehackers.com/post/8k-mrr-within-a-year-after-pivoting-to-productized-services-44N8isCYNJf95AVDnefu?ref=zerodraftlab.com), Indie Hackers, 2025-11-19; [Designpop 공식 웹사이트](https://www.designpop.co/?ref=zerodraftlab.com). 매출, 성장 시점, 고객 획득 방식은 창업자 인터뷰에 기반한 자기보고이며 Stripe, 손익, 구독 비중, 코호트 유지율 자료는 공개되지 않았습니다. Designpop의 현재 가격은 2026-07-13 공개 웹사이트 확인 기준입니다. ### 팔로워가 없다는 것이 새로운 지위가 됐다 URL: https://zerodraftlab.com/no-followers-is-status/ Last updated: 2026-09-15T08:35:48.000Z 한때 팔로워 수는 설명이 필요 없는 자산이었다. 숫자가 크면 영향력이 크고, 유명하며, 무엇인가를 팔 수 있다고 여겼다. 개인 브랜드의 장부에는 팔로워가 가장 먼저 적혔다. 이제 그 장부의 신뢰도가 떨어지고 있다. 큰 계정에는 봇, 휴면 계정, 과거의 유명세, 반감 때문에 지켜보는 사람까지 섞여 있다. 누적 숫자는 남아도 현재의 관심과 참여와 구매 의도는 빠져나간다. 팔로워 수가 현금흐름보다 장부가만 큰 자산처럼 변한 것이다. 알고리즘 추천은 이 변화를 더 밀어붙였다. 예전에는 사람을 먼저 팔로우한 뒤 그 사람이 올린 콘텐츠를 받았다. 지금은 피드가 콘텐츠를 먼저 가져온다. 영상 하나를 보고도 계정과 관계를 맺을 필요가 없다. 노출은 늘 수 있지만 관계는 쌓이지 않는다. Kyle Chayka가 *The New Yorker*에서 포착한 것은 이때 생긴 지위의 역전이다. 작고 비공개이며 무심하게 운영되는 계정이 오히려 매력적으로 보인다. 자신을 열심히 팔지 않아도 생계와 평판이 유지되는 사람처럼 보이기 때문이다. 여기서 중요한 것은 작은 숫자 자체가 아니다. 아무나 게시물을 엉성하게 올린다고 멋져지지는 않는다. 잘할 수 있다는 사실이 알려진 사람이 굳이 최적화하지 않을 때, 무심함은 미숙함이 아니라 선택으로 읽힌다. 온라인 성과에 자존감과 수입이 매여 있지 않다는 인상을 준다. 그래서 새로운 럭셔리는 더 많이 노출되는 능력이 아니라 **노출하지 않을 자유**다. 비싼 물건을 보여주는 대신, 자신을 계속 보여주지 않아도 기회가 오는 상태를 보여준다. 경제적 안정, 오프라인 인맥, 전문성, 정서적 여유가 작은 계정 위에 투사된다. 이것은 인기가 사라졌다는 뜻이 아니다. 대규모 유통과 광고, 엔터테인먼트와 직접 판매에서 팔로워는 여전히 돈이 된다. 원문의 사례도 패션·미디어·창작 업계에 치우쳐 있다. 일부 취향 집단의 신호를 대중 전체의 규범으로 일반화하기에는 이르다. 오히려 더 정확한 변화는 인기의 종말이 아니라 인기 측정법의 노후화다. 팔로워라는 숫자가 너무 쉽게 생산되고 너무 오래 남자, 사람들은 그 숫자를 필요로 하지 않는 상태에서 희소성을 찾기 시작했다. ## 관계는 콘텐츠 단위 거래로 해체됐다 추천 피드에서 사용자는 계정을 구독하지 않고도 원하는 자극을 얻는다. 플랫폼은 관계를 맺는 비용을 없애고, 매 순간 가장 반응할 만한 콘텐츠를 공급한다. 창작자는 더 넓게 노출될 수 있지만 다음 게시물까지 돌아올 사람을 소유하지 못한다. 이 환경에서 100만 팔로워보다 중요한 것은 이름을 검색해 다시 오는 사람, 메일을 열어보는 사람, 새 작업을 기다리는 사람이다. 팔로워는 플랫폼이 기록한 과거의 선택이고, 반복 방문은 지금도 유지되는 관계다. 둘은 더 이상 같은 지표가 아니다. 개인 브랜드 전략도 달라진다. 숫자를 키우는 최적화가 유효하지 않다는 뜻이 아니라, 숫자만 키우는 일이 브랜드의 독립성을 약화시킬 수 있다는 뜻이다. 알고리즘이 원하는 주제와 형식을 계속 공급할수록 계정은 커지지만, 사람은 무엇을 믿고 무엇을 거절하는지 흐려질 수 있다. ## 반브랜딩도 결국 브랜딩이다 여기에는 마지막 역설이 있다. 무심함이 멋지다는 사실이 알려지는 순간, 무심함도 연출된다. 흐릿한 사진, 드문 게시물, 작은 비공개 계정이 다시 최적화된 지위 신호가 된다. 반브랜딩은 브랜딩의 종말이 아니라 문법이 더 은밀해진 단계다. 따라서 팔로워가 적은 계정을 무조건 진정성의 증거로 읽을 수도 없다. 진짜 구분선은 큰가 작은가가 아니라 숫자에 생계가 매여 있는가이다. 플랫폼 성과가 떨어져도 작업과 관계와 수입이 유지되는 사람은 숫자를 선택적으로 사용할 수 있다. 그렇지 않은 사람은 계속해서 피드의 요구를 생산해야 한다. **팔로워가 없는 것이 새 자산이 된 이유는 사람들이 인기를 싫어해서가 아니다. 인기를 증명하던 숫자가 너무 쉽게 만들어지자, 그 숫자를 필요로 하지 않는 상태가 더 비싼 신호가 됐기 때문이다.** --- 주요 출처: Kyle Chayka, [“It’s Cool to Have No Followers Now”](https://www.newyorker.com/culture/infinite-scroll/its-cool-to-have-no-followers-now?ref=zerodraftlab.com), *The New Yorker*, 2025년 11월 5일. 저팔로워 계정에 경제적·정서적 안정이 투사된다는 설명은 문화적 관찰이며, 팔로워 수의 경제적 가치가 보편적으로 사라졌다는 인과 증명은 아닙니다. ### 리더가 없어도 되는 순간, 제품은 제도가 된다 URL: https://zerodraftlab.com/product-becomes-institution/ Last updated: 2026-09-15T08:35:48.000Z 좋은 리더는 언제 떠나야 할까. 성장이 멈췄을 때도, 지쳤을 때도 아니다. 자신이 없어도 조직이 중요한 문제를 해결한다는 사실을 확인했을 때다. PyTorch를 거의 8년간 이끈 Soumith Chintala는 2025년 11월 Meta와 PyTorch를 떠나며 그 판단 과정을 공개했다. 퇴사문처럼 보이지만 실제로는 장기 리더 없이도 돌아가는 조직을 어떻게 판정하는지에 관한 기록이다. 그는 2024년 11월 딸의 출생과 맞물려 퇴장을 계획하기 시작했다. 2025년 8월, 육아휴직 후반부에 팀의 상태를 다시 봤다. 과거라면 자신에게 돌아왔을 사람, 기술, 제품, 조직 문제가 더 이상 역류하지 않았다. 팀은 문제를 해결했고, 제품의 서사를 일관되게 만들었으며, 그가 위험 신호로 보던 항목들을 건강한 상태로 돌려놓았다. 이 장면에서 육아휴직은 휴식 이상의 역할을 했다. 리더가 회의에 없고 즉시 답을 주지 못하는 기간은 조직의 의존성을 드러내는 스트레스 테스트가 된다. 평소에는 위임된 것처럼 보이던 판단이 실제로는 리더의 마지막 승인에 매여 있었는지 확인할 수 있다. Soumith에게는 실패한 전례도 있었다. 2020년 리더 자리에서 물러나 로보틱스 연구로 이동했지만, 핵심 리더들이 떠난 뒤 2022년 다시 돌아왔다. 당시 조직은 한 사람의 퇴장을 견디는 것처럼 보였어도 여러 핵심 인력의 이탈까지 흡수할 층이 부족했다. 이번에 그가 다르다고 본 이유는 후계자 한 명이 정해졌기 때문이 아니다. 여러 사람이 PyTorch의 가치와 문화를 전달하고 의사결정 테이블에 앉아 있었고, 그 다음 후보층도 보였다. **승계의 단위가 한 명에서 시스템으로 바뀌었다.** 물론 이것은 아직 성공의 증명이 아니다. 장기 리더가 떠난 뒤에도 기술 방향, 인재 유지, 제품 일관성이 오래 버틸지는 시간이 말해준다. 퇴사문은 조직의 복원력을 입증한 감사 보고서가 아니라, 떠나는 리더가 무엇을 보고 자신감을 얻었는지 보여주는 자기 기록이다. 그래도 여기에는 founder mode 논쟁이 놓치기 쉬운 마지막 단계가 있다. 초기에는 한 사람의 집요함이 제품의 기준을 만든다. 그러나 그 기준이 영원히 그 사람의 머릿속에만 있다면 제품은 성장해도 조직은 자라지 않는다. ## 문제가 리더에게 역류하는가 승계를 판단하는 가장 현실적인 지표는 조직도나 직함이 아니다. 어려운 문제가 생겼을 때 최종적으로 누구의 책상으로 돌아오는가이다. 리더가 휴가 중인데도 결정이 멈추고, 사람들이 답을 기다리고, 복귀 뒤 모든 쟁점을 다시 검토해야 한다면 권한은 아직 이전되지 않았다. 반대로 팀이 문제를 해결했을 뿐 아니라 왜 그렇게 결정했는지 같은 언어로 설명할 수 있다면 조직은 한 단계 달라진다. 리더의 답을 복제하는 것이 아니라, 리더가 중요하게 여긴 가치로 새로운 답을 만든다. 문화는 구호가 아니라 부재 중에도 재현되는 판단 방식이다. 여기서 후계자 한 명에게 모든 것을 넘기는 방식은 취약하다. 한 사람이 떠나면 다시 원점으로 돌아가기 때문이다. 견고한 승계에는 복수의 의사결정자, 서로 다른 문제를 맡는 리더, 그리고 그 다음 층이 필요하다. 핵심은 빈자리를 채우는 것이 아니라 판단이 끊기지 않는 구조를 만드는 일이다. ## 떠남은 founder mode의 반대가 아니다 창립기 리더십과 제도화는 서로 적이 아니다. 강한 리더가 직접 기준을 세우는 시기가 필요할 수 있다. 다만 리더십의 완성은 자신이 모든 결정을 계속 잘하는 데 있지 않다. 자신의 판단력을 여러 사람의 분산된 판단력으로 바꾸는 데 있다. 그래서 잘 떠나는 일은 단순한 은퇴가 아니다. 문제를 넘기고, 실패를 허용하고, 자신의 부재를 시험하고, 팀이 만든 다른 답을 받아들이는 긴 작업이다. 리더가 계속 없어서는 안 될 사람으로 남는다면 그는 제품을 만들었을 수는 있어도 제도를 만들지는 못했다. **제품이 프로젝트에서 제도가 되는 순간은 창립 리더의 취향이 영원히 보존될 때가 아니다. 그 사람이 없어도 핵심 가치로 문제를 풀고, 다음 의사결정자까지 만들어낼 때다.** --- 주요 출처: Soumith Chintala, [“Leaving Meta and PyTorch”](https://soumith.ch/blog/2025-11-06-leaving-meta-and-pytorch.md.html?ref=zerodraftlab.com), 2025년 11월 6일. 그는 PyTorch의 단독 창업자가 아니라 초기 핵심 구성원이자 장기 리더로 표현하는 것이 정확합니다. 조직이 장기적으로 자립할 수 있다는 판단은 저자의 평가이며, 퇴사 이후의 지속성은 아직 검증되지 않았습니다. ### 중세 길드는 왜 가격을 낮췄을까 URL: https://zerodraftlab.com/guilds-paid-for-defense/ Last updated: 2026-09-15T08:35:49.000Z 중세 길드는 흔히 경쟁자를 막고 가격을 올린 카르텔로 설명된다. 진입을 제한했고, 회원에게 특권을 줬으며, 도시의 승인을 받았으니 자연스러운 해석이다. 그런데 카르텔이라면 설명하기 어려운 규칙이 있다. 많은 길드 규칙에는 최고가격과 최저품질 기준이 포함됐다. 이윤을 늘리려면 가격의 바닥을 정하고 품질 비용을 줄여야 하는데 방향이 반대다. 장인 길드가 가격을 올리면 물건을 사서 파는 상인 길드는 손해를 본다. 그럼에도 두 조직은 같은 도시에 공존했다. Josh Hendrickson이 소개한 Charles Hickson과 Earl Thompson의 이론은 질문을 바꾼다. 길드가 시장에서 무엇을 빼앗았는지가 아니라, 세금과 상비군이 약했던 도시에서 무엇을 조달했는지를 묻는다. 전근대 도시는 약탈당할 자산은 많았지만 그 자산에 비례해 방위비를 걷을 행정 인프라는 부족했다. 성벽과 병력을 유지하려면 돈뿐 아니라 침공 때 남아 싸울 사람도 필요했다. 문제는 위험해지면 주민이 도시를 떠날 수 있다는 점이었다. 길드의 진입 제한은 이 문제를 푸는 장치였을 수 있다. 도제에게 당장 현금을 주는 대신, 훈련을 마치고 회원이 되면 누릴 미래의 독점지대를 약속한다. 침공 때 달아나면 잃는 것이 오늘의 임금만이 아니라 장차 받을 소득권 전체가 된다. **진입장벽은 경쟁자를 막는 벽인 동시에 사람의 미래를 도시에 묶는 담보가 된다.** Hickson과 Thompson의 조사에 따르면 1308년까지 잉글랜드의 대형 도시 73곳 가운데 70곳에 공인 길드가 있었다. 나머지 세 곳은 전략적 방어와 요새화의 역사적 거점이었다. 이 분포는 길드가 단순한 직업조합을 넘어 도시 방위와 연결됐다는 가설에 힘을 준다. 하지만 이 숫자만으로 길드의 정체가 확정되지는 않는다. 길드는 가격과 진입을 통제하는 카르텔이면서 동시에 방위 인력을 조달하는 제도였을 수 있다. 후속 연구는 방위 가설이 자료의 시간적 패턴과 맞지 않는 부분도 지적한다. 카르텔 설명의 빈틈이 곧 방위 설명의 인과 증명은 아니다. 그래도 이 이론이 남기는 더 큰 통찰은 유효하다. 낡은 제도를 평가할 때는 표면의 규칙보다 그 시대에 없었던 인프라를 먼저 봐야 한다. 현대 국가는 세금을 걷고 국채를 발행하며 군인에게 급여를 준다. 그런 장치가 약한 사회는 현금 대신 미래의 권리, 자격, 특권을 보상으로 쓴다. ## 독점지대는 이연된 급여일 수 있다 이 관점에서 길드의 독점이익은 전부 착취의 초과이윤이 아니다. 일부는 평시에는 훈련과 대기, 전시에는 방어라는 서비스를 제공한 대가를 미래에 지급하는 방식일 수 있다. 도시는 구성원의 충성을 직접 살 수 없었기 때문에, 회원이 된 뒤 누릴 수입을 약속했다. 구조는 현대에도 남아 있다. 스타트업은 현금이 부족할 때 지분을 주고, 전문직 조직은 파트너 승진 가능성을 내걸며, 국가는 연금으로 장기 복무를 유도한다. 모두 현재 보상의 일부를 미래 권리로 바꾸고, 떠날 때 포기해야 할 가치를 만든다. 이 장치는 강력하지만 공짜가 아니다. 미래 특권이 커질수록 내부자는 보호되고 외부자는 배제된다. 조직을 지키는 충성 장치가 혁신을 막는 신분 장벽으로 굳을 수 있다. 방위 기능을 인정한다고 해서 진입 제한의 비용이 사라지는 것은 아니다. ## 제도는 이름이 아니라 해결한 제약으로 읽는다 길드를 단순히 좋은 공동체나 나쁜 카르텔로 분류하면 이 양면성이 사라진다. 더 나은 질문은 왜 구성원들이 스스로 최고가격과 최저품질 같은 이윤 제한 규칙을 유지했는가이다. 그 규칙이 신뢰를 만들었는지, 방위비를 조달했는지, 회원의 미래를 도시에 묶었는지를 함께 봐야 한다. 비효율처럼 보이는 제도에는 종종 사라진 문제의 흔적이 남아 있다. 오늘은 세금, 급여, 보험, 계약으로 해결하는 일을 과거에는 특권과 신분으로 해결했다. 제도의 비용만 보면 착취가 보이고, 제도가 대신한 인프라까지 보면 설계가 보인다. **중세 길드는 예비군 급여 시스템이었다고 확정할 수 없다. 다만 길드의 독점권은 가격을 올리는 권리였을 뿐 아니라, 현금 없는 도시가 방위 서비스의 대가로 약속한 미래 소득이었을 수 있다.** --- 주요 출처: Josh Hendrickson, [“Price Theory and Guilds”](https://www.economicforces.xyz/p/price-theory-and-guilds?ref=zerodraftlab.com), Economic Forces, 2025년 10월 30일. 글이 소개한 기반 연구는 Charles R. Hickson·Earl A. Thompson, “A New Theory of Guilds and European Economic Development,” *Explorations in Economic History* 28(2), 1991입니다. 70/73 수치와 길드의 방위 기능은 이 연구를 재인용한 것이며, 방위 가설은 확정된 역사적 인과가 아닙니다. ### 명문회사의 해고는 실패 판정이 아니다 URL: https://zerodraftlab.com/elite-firm-churns-good-workers/ Last updated: 2026-09-15T08:35:50.000Z 명문회사가 유능한 직원을 내보내는 장면은 보통 두 가지로 해석된다. 그 사람이 생각보다 부족했거나, 회사가 사람을 소모품처럼 다뤘다는 것이다. 그런데 제3의 설명이 있다. **해고가 떠나는 사람의 실패를 판정하는 일이 아니라, 남은 사람의 평판과 임금을 관리하는 장치일 수 있다.** Ron Kaniel과 Dmitry Orlov가 2025년 *American Economic Review*에 발표한 논문은 이 가능성을 이론모형으로 설명한다. 출발점은 전문서비스 시장의 정보 비대칭이다. 법률, 컨설팅, 자산운용, 회계처럼 개인의 실력이 중요하지만 고객이 신입의 능력을 곧바로 판단하기 어려운 시장에서는 회사가 중개자 역할을 한다. 명문사는 누구를 뽑았는지 알고, 시장은 명문사가 뽑았다는 사실만 본다. 경력 초기에 정보우위는 회사에 있다. 회사는 직원의 실력을 시장보다 더 정확히 알지만, 직원은 자신의 능력을 외부에 입증할 충분한 실적이 없다. 그래서 실력 있는 직원도 실제 가치보다 낮은 임금을 받아들인다. 손해만 보는 거래는 아니다. 명문사에 남아 있다는 사실이 이력서에 붙는 신호가 되고, 그 신호는 시간이 흐를수록 개인의 시장가치를 높인다. 직원은 현재 임금 일부를 평판 자산으로 바꾸는 셈이다. ## 실력이 드러날수록 회사의 문제가 시작된다 시간이 지나면 사건 승소, 투자 성과, 프로젝트 결과처럼 개인에게 귀속되는 실적이 쌓인다. 시장도 누가 잘하는지 알기 시작한다. 직원은 더 이상 회사 간판에만 기대어 자신의 능력을 증명할 필요가 없다. 외부가 실력을 알아본 만큼 회사는 그에게 더 많은 임금을 지급해야 한다. 회사가 독점하던 정보가 공공재가 되면서 초과이익은 줄어든다. 이때 모형 속 회사는 역설적인 선택을 한다. 형편없는 사람만 자르는 것이 아니라 **성과가 좋지만 동료 집단 안에서는 조금 덜 뛰어난 사람**도 내보낸다. 이것이 churning이다. 해고된 사람이 무능해서가 아니다. 회사가 내부적으로 관찰한 미세한 서열에서 잔류자보다 아래에 있을 뿐이다. 이 선택은 두 방향으로 작동한다. 먼저 남은 사람의 평균 품질이 올라가므로 회사와 잔류자의 평판이 함께 강해진다. 동시에 잔류자에게는 새로운 위험이 생긴다. 다음 해고 대상이 되면 시장은 “명문사 출신”이라는 긍정적 신호와 함께 “그 집단에서 밀려난 사람”이라는 부정적 신호도 읽을 수 있다. 회사는 이 저평가 위험을 사실상의 협상 카드로 쓴다. 그래서 잔류자는 시장가치보다 낮은 임금을 다시 감수할 수 있다. 처음에는 아직 실력을 증명하지 못했기 때문에 낮게 받았다. 이제는 실력이 드러났는데도 **선택받은 집단에 계속 속해 있다는 신호**를 지키기 위해 낮게 받는다. 정보 비대칭이 줄어들면 회사의 힘도 약해질 것 같지만, 선별적 해고가 정보의 해석 방식을 바꾸면서 회사는 오히려 더 많은 몫을 가져갈 수 있다. 따라서 이 모형에서 명문회사의 해고는 단순한 비용 절감이 아니다. 누가 남았는지를 더 귀한 신호로 만들고, 그 신호의 일부를 임금 할인으로 회수하는 평판 생산 방식이다. 간판의 가치는 채용할 때만 생기지 않는다. 누군가를 계속 내보낼 때도 생산된다. 그렇다면 직원은 착취당하기만 하는가. 이 질문에서 모형은 더 불편하고 흥미로운 결론으로 넘어간다. 떠나는 사람도, 남는 사람도, 회사도 이 체계에 참여할 이유가 있기 때문이다. 떠나는 사람은 “해고”라는 부정적 사건을 겪지만 처음부터 실패자로 돌아가지는 않는다. 시장은 그가 한때 명문사의 엄격한 채용을 통과했고 공개적으로 관찰 가능한 성과도 냈다는 사실을 안다. 잔류자보다 조금 낮은 내부 평가를 받았다는 것과 시장 전체에서 낮은 능력을 가졌다는 것은 전혀 다른 명제다. 엘리트 집단의 하위권은 여전히 일반 시장의 상위권일 수 있다. 남는 사람도 당장의 저임금만 보고 선택하지 않는다. 회사 안에서 더 빠르게 쌓이는 실적과 강화된 집단 평판은 미래에 독립하거나 이직할 때 더 높은 보수로 바뀔 수 있다. 모형에서는 이 평판 형성의 이익이 회사가 가져가는 몫보다 충분히 크기 때문에, 유능한 신입이 처음부터 명문사를 선택한다. 낮은 임금은 비합리적인 복종이 아니라 미래 시장가치를 사는 가격이 된다. ## 명문사 간판은 급여 대신 받는 자산이다 이 관점에서 보상은 월급만으로 측정할 수 없다. 직원이 받는 것은 현금, 훈련, 고객 접근, 관찰 가능한 실적, 동료 집단의 평판을 합친 묶음이다. 명문사는 이 가운데 현금을 적게 주고 나머지 자산을 크게 보이게 할 수 있다. “우리 회사에서 버틴 경력”이 외부 시장에서 실제로 높은 가격을 받을수록 그 교환은 지속된다. 문제는 평판 자산의 가치가 개인마다 다르다는 점이다. 아직 외부에 보여줄 실적이 없는 사람에게 명문사 간판은 강력한 증명서다. 반대로 고객이 이미 이름을 알고 성과를 직접 평가할 수 있는 사람에게 간판의 추가 가치는 작다. 같은 낮은 임금도 전자에게는 투자일 수 있지만 후자에게는 회사가 과거의 브랜드 프리미엄을 계속 징수하는 계약일 수 있다. 그래서 경력 판단에서 중요한 질문은 “좋은 회사인가”가 아니라 **이 회사가 떼어가는 임금과 내가 축적하는 이동 가능한 평판 중 무엇이 더 빠르게 커지는가**다. 회사 밖에서도 식별되는 고객 관계, 결과물, 자격, 매출, 판례, 트랙레코드가 쌓인다면 낮은 임금은 기한이 있는 투자다. 성과가 회사 브랜드 안에만 묻혀 외부에서 개인에게 귀속되지 않는다면 같은 선택은 장기 할인에 가까워진다. ## 이 모형이 모든 해고를 설명하지는 않는다 여기에는 중요한 한계가 있다. 논문은 McKinsey나 Goldman Sachs의 인사자료를 분석해 실제 해고 원인을 검증한 실증연구가 아니다. 성과가 공개적으로 관찰되고 개인에게 귀속되며, 회사가 직원의 능력을 외부보다 더 잘 아는 시장을 가정한 이론모형이다. 경기 침체, 사업 철수, 정치적 갈등, 차별, 잘못된 평가처럼 현실의 수많은 해고 원인은 별도로 남는다. 따라서 “명문사의 해고는 사실 모두 합리적이다”라는 면죄부로 읽으면 안 된다. 더 정확한 해석은 따로 있다. 평판이 임금의 일부로 거래되는 조직에서는 인력 교체가 성과관리만이 아니라 **신호의 희소성을 유지하는 경제행위**가 될 수 있다는 것이다. 회사는 누가 유능한지 발견하는 데 그치지 않고, 누가 유능해 보이는지를 설계함으로써 이익을 얻는다. 이 설명은 “왜 잘하는 사람을 굳이 내보내는가”라는 질문을 바꾼다. 회사가 그 사람의 능력을 몰라서가 아니라 너무 잘 알기 때문에 내보낼 수 있다. 최상위만 남기는 행동이 잔류자의 지위를 높이고, 그 지위가 임금 협상력을 낮춰준다면 좋은 직원의 이탈은 시스템의 오류가 아니라 시스템이 작동하는 방식이다. 개인에게 남는 교훈도 해고를 자기 능력의 최종 판정으로 받아들이지 않는 데서 끝나지 않는다. 명문사 경력의 가치는 그 안에 오래 남는 데 있지 않고, 그곳에서 얻은 신호를 언제 자기 이름의 실적으로 전환하느냐에 있다. **간판이 내 실력을 대신 말해주는 동안에는 회사가 유리하다. 간판 없이도 시장이 내 실력을 알아보는 순간부터는, 남을 이유와 떠날 이유를 다시 계산해야 한다.** --- 주요 출처: Ron Kaniel·Dmitry Orlov, [“Intermediated Asymmetric Information, Compensation, and Career Prospects”](https://www.aeaweb.org/articles?id=10.1257/aer.20200169&ref=zerodraftlab.com), *American Economic Review* 115(10), 2025; University of Rochester, [“Why elite firms churn good workers”](https://rochester.edu/newscenter/employee-turnover-why-top-firms-churn-good-workers-681832/?ref=zerodraftlab.com). 이 글은 논문의 이론모형을 해설한 것이며 특정 기업의 실제 해고 관행을 입증하는 실증분석이 아닙니다. ### 음성 AI의 경쟁자는 필리핀 BPO의 시간당 단가다 URL: https://zerodraftlab.com/voice-ai-competes-with-bpo/ Last updated: 2026-09-15T08:35:50.000Z 음성 AI가 콜센터 직원을 대체한다고 말할 때 비교 대상은 흔히 사람의 뇌와 GPU다. 한쪽은 급여와 휴식이 필요하고, 다른 쪽은 데이터센터에서 복제된다. 이 구도만 보면 승부는 이미 끝난 것처럼 보인다. 하지만 기업이 구매하는 것은 GPU 시간이 아니다. 음성인식, 언어모델, 음성합성, 전화망, 오케스트레이션을 연결한 통화 시간이다. 각 계층에 공급자의 마진이 붙으면 “기계는 당연히 싸다”는 직관이 빠르게 무너진다. 2025년 11월 LessWrong에 공개된 계산에서 Vapi 기반 음성 AI는 최소 분당 약 0.15달러였다. 음성인식 0.01달러, GPT-4o 0.07달러, 음성합성 0.022달러, Vapi 호스팅 0.05달러를 더한 값이다. 한 시간 내내 통화하면 9달러다. 저자가 비교한 캐나다의 최저임금 프런트 직원은 시간당 약 12달러였다. 개발, 온보딩, 감독, 오류 대응을 넣기 전부터 차이는 3달러뿐이다. Bland의 당시 가격은 분당 0.09달러, 시간당 5.40달러로 더 낮았지만 남아공 BPO 인력과 비슷했고 이집트·베트남·필리핀·인도 인력보다 비쌌다. ## AI의 경쟁자는 평균적인 북미 노동자가 아니다 자동화 사업의 가격 상한은 기술의 신기함이 아니라 고객이 이미 고용할 수 있는 가장 싼 대안이 정한다. 콜센터는 오래전부터 업무를 임금이 낮은 국가로 옮겨왔다. 음성 AI가 이 시장에 들어오는 순간 경쟁자는 캐나다의 연봉이 아니라 필리핀 BPO의 시간당 단가가 된다. 여기에 API 공급자의 수직 구조가 겹친다. 모델 회사가 음성을 처리하고, 파이프라인 회사가 여러 모델과 전화망을 묶고, 수직 SaaS가 병원이나 물류회사의 업무 흐름에 연결한다. 고객에게 도달할 때까지 여러 회사가 같은 통화에서 마진을 가져간다. 따라서 모델 추론비가 싸진다는 사실만으로 최종 서비스의 원가가 같은 속도로 내려가지는 않는다. 전화망, 관찰 가능성, 녹취 저장, 도구 호출, 규제 대응, 지원 비용은 남는다. 공급자가 비용 하락분을 가격에 얼마나 넘길지도 알 수 없다. 다만 이 계산을 “AI가 사람보다 비싸다”는 결론으로 읽어서도 안 된다. 원문의 비교는 인간이 유급시간 내내 100% 통화하고, AI도 같은 시간만큼 연속 통화한다고 가정했다. 현실에서는 사람에게 대기시간과 휴식이 있고, AI는 실제 통화한 분에만 과금될 수 있다. 그러면 인간의 시간당 임금과 AI의 분당 가격을 어떻게 같은 경제 단위로 바꿔야 하는가? 비교 단위는 시간이 아니라 **해결된 통화 한 건의 총비용**이어야 한다. 한 시간을 샀는지가 아니라 고객의 문제가 해결되고 예약이나 환불, 보험 청구 같은 업무가 실제로 닫혔는지를 봐야 한다. **해결 건당 비용**은 통화비, 구축·통합비, 감독비, 실패 복구비, 규제·품질 비용을 모두 더한 뒤 사람이 다시 처리하지 않아도 닫힌 건수로 나눈 값이다. 이 분모를 쓰면 양쪽의 숨은 비용이 함께 나타난다. 인간에게는 채용, 교육, 이직, 공간, 관리, 유휴시간이 있다. AI에는 환각, 전사 오류, 예외 처리, 테스트, 사람에게 넘기는 비용, 공급자 장애와 가격 변경 위험이 있다. AI가 실패한 뒤 사람이 같은 통화를 다시 처리하면 한 건에 기계와 사람의 비용을 모두 낸다. ## 가동률이 손익분기점을 바꾼다 예를 들어 상담원에게 시간당 12달러를 지급하지만 실제 통화 점유율이 50%라면 통화 한 시간의 직접 임금은 24달러가 된다. 이 조건에서는 시간당 9달러인 AI가 훨씬 유리해 보인다. 반대로 통화량이 안정적이고 해외 BPO가 높은 가동률로 시간당 2달러대에 일한다면 API를 여러 겹 쌓은 AI는 가격만으로 이기기 어렵다. 그래서 음성 AI의 초기 시장은 단가가 가장 낮은 대량 콜센터가 아닐 수 있다. 밤과 주말의 예약, 갑작스러운 통화 폭증, 여러 언어 지원, 사람이 받지 못해 매출을 잃는 인바운드 문의처럼 유휴 인력을 유지하는 비용이 큰 구간에서 경제성이 먼저 나온다. 24시간 응답, 대기열 제거, 일관된 스크립트, 매출 전환 같은 효과도 비용 절감과 별도로 계산해야 한다. 음성 AI가 통화를 더 짧게 끝내거나 놓칠 전화를 매출로 바꾼다면 시간당 원가가 더 높아도 채택될 수 있다. 반대로 복잡한 문의의 첫 해결률이 낮다면 싼 분당 가격은 아무 의미가 없다. ## 원가 하락보다 구조 선택이 먼저다 원문은 추론 비용이 매년 30%씩 내려간다고 가정해 2029\~2030년 무렵 가장 싼 해외 노동과 경쟁할 수 있다고 전망했다. 가능한 시나리오지만 공격적인 외삽이다. 2025년 가격은 이미 스냅숏이고, 임금·환율·모델 구조·대량 계약 할인·규제가 모두 달라질 수 있다. 사업자가 통제할 수 있는 것은 그 미래를 기다리는 일이 아니라 현재의 공급 구조다. 모든 계층을 프리미엄 API로 조립할지, 일부 모델을 직접 계약할지, 짧고 반복적인 통화만 자동화할지, 사람에게 넘길 기준을 얼마나 빨리 잡을지가 마진을 결정한다. 수직 제품의 해자도 음성 모델 자체보다 이 지점에 생긴다. 병원 예약이나 보험 확인처럼 한 업무의 예외를 줄이고, 필요한 시스템에 안전하게 접근하며, 해결률을 측정할 수 있어야 한다. 범용 음성은 상품이 되지만 특정 업무를 싸고 확실하게 닫는 운영 데이터는 남는다. AI 자동화의 경제성을 평가할 때 “사람보다 똑똑한가?”부터 묻는 것은 순서가 틀렸다. 먼저 기존 대안의 실제 가동률, 해결률, 부대비용을 넣고 같은 결과 단위로 환산해야 한다. **AI 에이전트의 진짜 경쟁자는 인간의 지능이 아니라 필리핀 BPO의 시간당 단가다.** --- 주요 출처: michaelwaves, [The Economics of Replacing Call Center Workers With AIs](https://www.lesswrong.com/posts/rJatmEDcYrDQcwstT/the-economics-of-replacing-call-center-workers-with-ais?ref=zerodraftlab.com), 2025년 11월 25일. Vapi·Bland 가격과 국가별 임금은 원문의 2025년 스냅숏이며, 인간 100% 가동률 가정, 기업 할인·직접 구축·품질·규제 비용이 빠졌다는 한계를 반영했습니다. ### 숙련은 어떤 결함을 자기 서명으로 바꾸는가 URL: https://zerodraftlab.com/constraint-becomes-signature/ Last updated: 2026-09-15T08:35:51.000Z 잭슨 폴록의 그림은 오랫동안 통제된 몸의 기록으로 설명됐다. 바닥의 캔버스 주위를 돌며 물감의 흐름을 지휘하는 모습은 거대한 화면 위에서 춤추는 숙련자의 이미지와 잘 맞았다. 2025년 발표된 한 연구는 그 이미지에 작은 균열을 냈다. 연구진은 4\~6세 어린이 18명과 18\~25세 성인 34명에게 같은 종이, 같은 물감, 같은 도구를 주고 폴록처럼 물감을 흘려 그림을 만들게 했다. 두 집단의 그림은 모두 복잡했지만 구조는 달랐다. 어린이 작품은 성인 작품보다 미세한 구조가 적었고, 빈 공간과 물감 덩어리의 분포가 더 불균일했다. 프랙탈 차원은 낮고 라쿠나리티는 높았다. 쉽게 말하면 작은 움직임이 촘촘하게 쌓이기보다 덩어리와 틈이 더 크게 남았다. 연구진이 폴록의 *Number 14, 1948*을 같은 방식으로 분석하자 수치는 성인 분포 안에 있었다. 다만 성인 집단의 가장자리, 어린이 집단에 가까운 쪽에 놓였다. ## 작품에는 손뿐 아니라 균형도 기록된다 물감을 붓지 않고 공중에서 흘리는 작업은 팔의 궤적만 남기지 않는다. 화가는 바닥의 화면 위로 몸을 기울이고, 중심을 잃지 않도록 끊임없이 자세를 보정한다. 성인의 미세한 균형 조정은 작은 방향 전환을 늘리고, 어린이의 덜 성숙한 균형은 더 크고 단순한 궤적을 만들 수 있다. 연구진은 폴록의 제한된 운동 조절과 균형이 그의 패턴에 영향을 줬을 가능성을 제시했다. 폴록이 완벽한 균형으로 우연을 통제한 것이 아니라, 흔들리는 몸의 보정 과정까지 작품 안으로 들어왔을 수 있다는 뜻이다. 하지만 여기서 “서투름이 걸작을 만들었다”고 결론 내리면 연구보다 멀리 나간다. 실험은 참가자의 균형을 직접 측정하지 않았고, 폴록의 작품도 한 점만 분석했다. 어린이와 성인은 키, 팔 길이, 전략, 지시 해석에서도 다르다. 연구진 스스로 이를 예비 탐색이라고 부른다. 그럼에도 이 가설이 매력적인 이유는 폴록을 진단하기 때문이 아니다. 숙련을 다시 정의하게 만들기 때문이다. 숙련은 언제나 흔들림을 없애는 능력일까. 아니면 어떤 흔들림을 반복 가능한 결과로 바꾸는 능력일까. 결함이 우연히 한 번 나타나는 것과 양식이 되는 것 사이에는 무엇이 있는가? 그 사이에는 제거가 아니라 **선택과 반복**이 있다. 통제하기 어려운 흔들림은 처음에는 잡음이다. 그러나 창작자가 그 흔들림이 만드는 결과를 보고, 일부를 선택하고, 다시 나타날 조건을 작업 과정에 남기면 잡음은 서명이 된다. 폴록의 가치는 균형이 부족했을 가능성 자체에 있지 않다. 수많은 사람이 흔들리지만 모두 폴록의 화면을 만들지는 않는다. 물감의 점도, 도구의 높이, 이동 속도, 캔버스의 크기, 레이어의 순서를 오랜 시간 조정하며 자신의 몸이 만드는 궤적을 하나의 체계로 다뤘다는 데 있다. 그 체계 안에서 제약은 흔적을 남기고, 선택을 거쳐, 다른 사람이 알아볼 수 있는 차이로 굳어진다. ## 제약이 양식으로 굳어지는 과정 먼저 제약이 결과에 남아야 한다. 몸의 흔들림, 제한된 도구, 짧은 문장, 느린 제작 속도처럼 창작자의 조건이 산출물의 형태를 실제로 바꿔야 한다. 감춰진 고통만으로는 양식이 생기지 않는다. 그다음 창작자가 그 흔적을 알아보고 선택해야 한다. 모든 오류를 보존하는 것은 방치다. 어떤 불균형은 버리고 어떤 불균형은 남기는 판단이 쌓일 때 제약은 의도와 결합한다. 의도는 처음부터 완벽한 청사진으로 존재하지 않아도 된다. 결과를 보고 다음 반복을 바꾸는 선택이면 충분하다. 마지막으로 관객이 반복되는 차이를 인식할 수 있어야 한다. 서명은 창작자의 내부 사정이 아니라 작품에서 되풀이되는 감각이다. 이번 연구의 관찰자들은 프랙탈 차원이 낮고 라쿠나리티가 높은 성인 그림을 더 흥미롭고 유쾌하게 평가하는 경향을 보였다. 불균일함이 단순한 결손이 아니라 지각 가능한 특성으로 작동할 수 있다는 단서다. ## 결함을 낭만화하면 과정이 사라진다 예술가의 질병이나 장애를 천재성의 원인으로 단순화하는 서사는 위험하다. 고통이 자동으로 독창성을 만들지도 않고, 치료하거나 보완할 수 있는 어려움을 “재능의 원천”이라는 이유로 방치해서도 안 된다. 조건과 작품의 상관관계는 인과관계가 아니며, 이번 연구도 폴록의 균형을 의학적으로 측정하지 않았다. 중요한 것은 결함의 존재보다 그것을 다루는 피드백 과정이다. 사람은 자신에게 없는 능력을 흉내 내는 데 모든 힘을 쓸 수도 있고, 자신에게 반복해서 나타나는 차이를 관찰해 작업 규칙으로 바꿀 수도 있다. 전자는 평균에 가까워지는 훈련이고, 후자는 자기만의 분포를 만드는 훈련이다. 이 관점에서 숙련은 결함이 사라진 최종 상태가 아니다. 무엇을 교정해야 하고 무엇을 보존해야 하는지 구분하는 감각이다. 통제할 수 없는 것을 전부 제거하지 않고, 결과에 기여하는 부분만 반복 가능하게 만든다. **숙련은 결함을 제거하는 일이 아니라, 어떤 결함을 자기 서명으로 바꿀지 선택하는 일일 수 있다.** --- 주요 출처: Fairbanks et al., [A question of Jackson Pollock's balance](https://www.frontiersin.org/journals/physics/articles/10.3389/fphy.2025.1673780/full?ref=zerodraftlab.com), *Frontiers in Physics* 13 (2025); Jennifer Ouellette, [Study: Kids' drip paintings more like Pollock's than adults'](https://arstechnica.com/science/2025/11/study-kids-drip-paintings-more-like-pollocks-than-adults/?ref=zerodraftlab.com), Ars Technica. 표본은 어린이 18명과 성인 34명이며, 균형을 직접 측정하지 않았고 폴록 작품은 한 점만 비교했다는 한계를 반영했습니다. ### 측정값이 행동을 바꾸지 못하면 대시보드는 장식이다 URL: https://zerodraftlab.com/dashboard-that-changes-nothing/ Last updated: 2026-09-15T08:35:52.000Z Lorelight는 실패한 제품처럼 보이지 않았다. ChatGPT·Claude·Perplexity에서 브랜드가 얼마나 언급되고 인용되는지 추적했고, 기술은 작동했으며 고객도 가입했다. 생성형 검색 최적화라는 새 시장의 요구를 정확히 붙잡은 듯했다. 그런데 고객은 데이터를 확인한 뒤 떠났다. 수치가 틀려서가 아니었다. 수치가 무엇을 보여주든 고객이 해야 할 일이 달라지지 않았기 때문이다. AI 답변에 더 자주 등장하려면 유용한 콘텐츠를 만들고, 신뢰받는 매체에서 언급되고, 해당 분야의 평판과 전문성을 쌓아야 했다. Lorelight 창업자 Benjamin Houy가 수백 개의 AI 답변을 분석한 뒤 발견한 것은 GEO만의 비밀 기술이 아니라 SEO·PR·브랜드 구축의 오래된 기본기였다. 브랜드 언급이 늘면 같은 일을 계속해야 했다. 줄어도 같은 일을 더 잘해야 했다. 경쟁사가 앞서도 결론은 같았다. 대시보드는 현상을 설명했지만 선택지를 갈라놓지 못했다. ## 정확한 측정과 유용한 제품은 다른 문제다 제품팀은 측정 정확도를 높이면 가치도 함께 높아진다고 생각하기 쉽다. 더 많은 모델을 조회하고, 질의를 세분화하고, 경쟁사 점유율과 인용 출처를 시계열로 보여준다. 그러나 고객의 의사결정은 데이터의 해상도와 같은 속도로 정교해지지 않는다. 측정 제품의 가치는 숫자의 정확성만으로 결정되지 않는다. 그 숫자가 행동을 바꾸는 세 가지 경로 가운데 하나를 열어야 한다. 어떤 일을 할지 바꾸거나, 같은 일의 우선순위를 바꾸거나, 지금 하던 일을 멈추게 해야 한다. 세 경로가 모두 닫혀 있으면 정교한 분석은 호기심을 충족하는 데 그친다. 호기심은 가입을 만들 수 있다. “우리 브랜드가 ChatGPT에서 몇 위일까?”라는 질문은 강한 첫 클릭을 만든다. 하지만 답을 한 번 확인한 뒤에도 매주 돌아올 이유를 만들지는 못한다. 새로운 정보가 새로운 결정을 만들지 못하면 사용 주기는 자연스럽게 끝난다. 그래서 측정 대시보드의 진짜 경쟁자는 더 정확한 대시보드가 아니다. **데이터를 보지 않고도 내릴 수 있는 뻔한 결정**이다. ## 독립 제품이 되려면 결과 뒤의 동사가 달라져야 한다 GEO 측정값이 낮다는 결과 뒤에 언제나 “좋은 콘텐츠를 만드세요”만 붙는다면 측정은 기존 SEO 도구의 한 탭으로 들어가는 편이 자연스럽다. 반대로 특정 질의군을 버리고, 인용되는 원문을 고치고, 배포처를 바꾸고, 다음 실험의 예산을 재배분하게 만든다면 독립 제품의 가능성이 생긴다. 결국 제품을 가르는 질문은 “무엇을 보여주는가?”가 아니라 “이 결과 때문에 사용자가 무엇을 다르게 하는가?”다. 그리고 이 질문은 GEO보다 훨씬 넓다. RSS 리더, 분석 도구, 리서치 모니터, 경쟁사 추적기에도 똑같이 적용된다. 그렇다면 측정값과 행동 사이의 빈칸은 어떻게 제품으로 바뀌는가? 첫 단계는 보고서를 더 풍부하게 만드는 것이 아니라 **서로 다른 결과가 서로 다른 행동으로 이어지는지** 확인하는 것이다. A가 나오면 콘텐츠를 고치고 B가 나오면 배포처를 바꾸며 C가 나오면 아무것도 하지 않는다는 분기가 실제로 존재해야 한다. 분기가 없다면 아직 측정 대상은 있어도 제품이 해결하는 결정은 없다. 여기서 흔한 탈출구는 AI가 자동으로 권고안을 쓰게 하는 것이다. 하지만 모든 수치 뒤에 “전문성을 강화하고 양질의 콘텐츠를 발행하세요”를 붙이면 설명만 길어질 뿐 행동은 달라지지 않는다. 권고의 가치는 문장 생성이 아니라 기회비용을 동반한 선택에 있다. 무엇을 먼저 하고, 무엇을 포기하며, 어떤 결과가 나오면 방향을 바꿀지까지 정해야 한다. ## 측정은 세 층 가운데 하나에 붙어야 한다 첫째는 **고빈도 운영**이다. 광고 입찰, 재고, 장애, 부정 사용처럼 수치가 바뀔 때마다 사람이 실제로 다른 조치를 해야 하는 영역이다. 측정 주기와 행동 주기가 짧게 맞물리므로 대시보드 자체가 반복 사용을 만든다. 둘째는 **실행 워크플로**다. 관찰에서 끝나지 않고 수정, 승인, 배포, 재측정까지 같은 제품 안에서 이어진다. 사용자는 점수를 보러 오는 것이 아니라 일을 끝내러 온다. 이때 측정은 제품의 전면이 아니라 실행을 조정하는 감각기관이 된다. 셋째는 **더 큰 제품군의 보조 신호**다. GEO처럼 행동이 기존 SEO·PR·콘텐츠 운영과 겹친다면 독립 카테고리를 고집할 이유가 약하다. 이미 고객의 반복 업무를 소유한 제품에 한 가지 판단 신호로 들어가는 편이 잔존율과 유통 모두에서 유리할 수 있다. Lorelight 사례만으로 독립 GEO 전략이 없다고 단정할 수는 없다. 공개된 글에는 고객 수, 잔존율, 질의 표본, 분석 방법이 충분히 제시되지 않았다. 다른 세그먼트에서는 모델별 인용 변동이 예산이나 콘텐츠 배포를 실제로 바꿀 수도 있다. 그러나 이 한계가 핵심 질문을 약하게 만들지는 않는다. 오히려 제품 검증의 기준을 더 엄격하게 만든다. “사람들이 이 데이터에 관심을 보이는가?”와 “이 데이터가 반복적으로 다른 결정을 만드는가?”는 전혀 다른 질문이다. 좋은 측정 제품은 세상을 더 자세히 보여주는 제품이 아니다. 사용자가 그 세계에 개입하는 방식을 바꾸는 제품이다. **측정값이 행동을 바꾸지 못하면, 대시보드는 제품이 아니라 장식이다.** --- 주요 출처: Benjamin Houy, [Why I'm Shutting Down Lorelight (And What It Taught Me About GEO)](https://growwithless.com/shutting-down-lorelight/?ref=zerodraftlab.com). Lorelight의 기술·가입·이탈과 GEO에 대한 결론은 창업자의 회고를 바탕으로 했습니다. 고객 수, 잔존율, 질의 표본과 분석 방법이 공개되지 않았다는 한계를 반영해 독립 GEO 제품 전체로 일반화하지 않았습니다. ### 고객의 말을 듣되, 고객의 해법을 믿지 마라 URL: https://zerodraftlab.com/customer-feedback-after-pmf/ Last updated: 2026-09-15T08:35:53.000Z 고객의 말을 가장 잘 듣는 회사가 다음 시장을 가장 늦게 볼 수 있다. 제품·시장 적합성(PMF)을 찾기 전에는 고객의 불편이 거의 유일한 나침반이다. 창업자의 상상보다 실제 사용자가 어디에서 멈추고 무엇에 돈을 내는지가 중요하다. 이 시기에 고객을 무시하면 대개 아무도 원하지 않는 제품을 정교하게 만들게 된다. 하지만 PMF를 지난 뒤에도 같은 방식으로 듣기만 하면 문제가 생긴다. 피드백은 점점 정확해지지만, 그 정확성은 **현재 제품을 더 잘 쓰는 법**에 집중된다. 기존 고객은 이미 지금의 기능, 가격, 유통 방식에 적응한 사람들이다. 이들의 요구를 모두 반영할수록 제품은 현재 형태에 더 단단히 맞춰진다. 여기서 고객 집착의 역설이 시작된다. 고객은 자신이 겪는 문제를 말하지만, 대개 현재 기술과 비용 구조 안에서 가능한 해결책의 언어로 말한다. 더 빠른 배송, 더 촘촘한 메뉴, 더 좋은 키보드 같은 요구는 거짓이 아니다. 다만 그것이 영구히 남을 욕구인지, 곧 사라질 제약에 적응한 요구인지는 별개의 문제다. ## 고객 요구에는 두 개의 시간이 섞여 있다 BlackBerry 사용자가 물리 키보드를 선호한 것은 당시에는 합리적이었다. 터치 입력이 느리고 불안정한 조건에서 물리 키보드는 효율적인 업무 소통을 가능하게 했다. 그러나 오래 남은 욕구는 키보드가 아니라 **빠르고 믿을 수 있는 소통**이었다. 입력 기술과 소프트웨어가 달라지자 키보드는 욕구가 아니라 한 시대의 해법으로 드러났다. Netflix의 DVD 고객도 마찬가지다. 더 많은 타이틀과 더 빠른 배송을 원했다. 이것은 DVD 사업을 개선하는 데는 훌륭한 피드백이었다. 그러나 고객이 궁극적으로 원한 것은 디스크 소유가 아니라 원하는 순간에 볼거리에 접근하는 일이었다. 대역폭과 스트리밍 비용이 바뀌자 배송 최적화보다 전달 방식 자체의 전환이 더 중요한 문제가 됐다. 이 둘을 구분하면 고객 요구를 무시하라는 결론에 도달하지 않는다. 오히려 더 정확하게 듣게 된다. “물리 키보드가 필요하다”에서 키보드를 지우고도 남는 목적은 무엇인지, “배송을 하루 줄여달라”에서 배송을 지우고도 남는 기대는 무엇인지 묻게 된다. 고객의 문장은 보통 세 층으로 이루어진다. 표면에는 요청한 기능이 있고, 그 아래에는 지금 그 기능이 필요한 제약이 있으며, 가장 아래에는 제약이 바뀌어도 남는 진전이 있다. 제품팀이 기능만 기록하면 현재를 최적화한다. 제약과 진전까지 분리하면 미래의 제품 형태를 다시 설계할 수 있다. ## PMF는 고객 학습의 끝이 아니라 표본 편향의 시작이다 PMF 이전의 위험은 고객을 모르는 것이다. PMF 이후의 위험은 **현재 고객을 시장 전체로 아는 것**이다. 매출을 만드는 고객은 인터뷰에 응하고, 지원 티켓을 남기고, 갱신 이유를 설명한다. 반면 제품을 선택하지 않은 사람은 분석 화면에 거의 나타나지 않는다. 그래서 성공한 제품의 데이터는 역설적으로 과거 선택의 결과를 점점 더 선명하게 보여준다. 대시보드는 기존 고객이 무엇을 했는지는 자세히 말하지만, 어떤 사람이 왜 들어오지 않았는지, 작은 새 세그먼트가 왜 다른 방식으로 쓰기 시작했는지, 기술 변화가 어떤 불만을 통째로 없앨지는 잘 보여주지 않는다. 고객 피드백을 버릴 것이 아니라 유효기간을 붙여야 한다. 이 요구는 어떤 제약 때문에 생겼는가. 그 제약은 더 강해지는가, 약해지는가. 제약이 사라져도 고객이 이루려는 진전은 남는가. 이 세 질문이 없으면 고객 집착은 학습이 아니라 현재 제품을 방어하는 논리가 된다. 이 판단을 실제로 하려면 현재 고객의 목소리만 크게 듣는 운영부터 바꿔야 한다. 필요한 것은 더 많은 인터뷰가 아니라 **서로 다른 시간대를 대표하는 네 종류의 신호**를 함께 보는 일이다. 네 신호는 서로를 대체하지 않는다. 각자 다른 질문에 답하고, 서로 충돌할 때 오히려 전략의 빈틈을 드러낸다. ## 현재 고객은 오늘의 마찰을, 비고객은 시장의 경계를 보여준다 현재 고객의 피드백은 버그, 불필요한 단계, 지불 의사, 반복 사용의 조건을 찾는 데 가장 강하다. 이 신호는 지금의 제품을 더 신뢰할 수 있게 만들고 이탈을 줄인다. 다만 여기서 나온 요구를 곧바로 다음 제품 전략으로 승격해서는 안 된다. 비고객은 다른 종류의 정보를 준다. “왜 가입하지 않았는가”보다 “무엇을 하기 위해 어떤 대안을 선택했는가”를 물으면 제품이 가정한 문제 정의의 바깥이 보인다. 이들은 기능이 부족해서 떠난 것이 아니라 제품이 요구하는 행동, 가격 구조, 통합 방식, 위험 부담 자체를 거부했을 수 있다. 비고객의 답은 곧바로 기능 백로그에 넣기 어렵다. 바로 그 점이 가치다. 현재 제품 문법으로 번역되지 않는 거절은 시장 경계가 어디에서 만들어졌는지 보여준다. 기존 고객의 요청이 안쪽을 정교하게 만든다면 비고객의 선택은 바깥쪽을 다시 그리게 한다. ## 작지만 빠르게 자라는 세그먼트는 미래 고객의 예고편이다 매출 비중이 큰 세그먼트만 보면 전략은 항상 과거를 향한다. 반대로 절대 규모는 작아도 신규 유입, 사용 빈도, 추천, 지불 의사가 빠르게 자라는 집단은 다른 시간대를 보여줄 수 있다. 이들의 행동은 아직 평균이 아니지만, 시장의 다음 평균이 될 가능성이 있다. 중요한 것은 작은 집단을 낭만화하지 않는 것이다. 일부 얼리어답터의 특이한 사용법이 대중 시장으로 번지지 않을 수도 있다. 그래서 규모보다 변화율과 반복성을 함께 본다. 같은 새 행동이 여러 고객에게 독립적으로 나타나는지, 일회성 호기심 뒤에도 남는지, 더 큰 세그먼트가 따라올 비용 조건이 형성되는지를 확인해야 한다. ## 기술과 비용 곡선은 고객이 말하지 못하는 미래를 보여준다 고객은 아직 존재하지 않는 선택지를 사용해본 적이 없다. 현재 대안 사이의 선호는 말할 수 있지만, 대역폭이 열 배 빨라지고 추론 비용이 열 배 낮아지며 규제가 바뀐 뒤의 행동까지 정확히 예측해주지는 못한다. 제품 전략은 그래서 인터뷰 기록 옆에 기술·비용 곡선을 놓아야 한다. 저장, 연산, 네트워크, 센서, 유통, 노동비 가운데 무엇이 빠르게 싸지고 있는가. 오늘 고객이 참는 불편 중 어떤 것이 그 변화로 사라지는가. 지금은 비경제적인 사용 사례가 어느 지점에서 가능해지는가. 여기서도 기술 낙관주의는 경계해야 한다. 싸진다고 반드시 채택되는 것은 아니다. 신뢰, 습관, 규제, 조직의 구매 절차는 기술보다 느리게 움직일 수 있다. 기술 곡선은 고객을 대체하는 예언이 아니라, 고객 피드백의 유효기간을 검증하는 두 번째 증거다. ## 좋은 제품 판단은 네 신호가 충돌할 때 나온다 현재 고객이 기능 A를 더 원하지만 비고객은 A가 전제하는 복잡성 때문에 들어오지 않을 수 있다. 가장 큰 세그먼트는 기존 방식을 선호하지만 작은 세그먼트는 새 흐름을 반복적으로 선택할 수 있다. 오늘은 새 방식의 품질이 낮아도 비용 곡선은 빠르게 개선될 수 있다. 이 충돌을 하나의 설문 점수로 합치면 중요한 정보가 사라진다. 대신 각 신호가 어느 시간대를 말하는지 표시해야 한다. 현재 고객은 오늘의 매출과 마찰, 비고객은 시장의 경계, 성장 세그먼트는 행동 변화, 기술·비용 곡선은 가능성의 이동을 보여준다. PMF 이후의 리더가 해야 할 일은 고객의 찬반을 세는 것이 아니다. 고객이 말한 해결책 뒤에서 지속되는 욕구를 찾고, 그 욕구를 더 잘 충족할 수 있는 제약 변화가 실제로 오는지 판단하는 일이다. 고객 집착이 성장을 막는 순간은 고객을 너무 많이 사랑할 때가 아니다. **고객이 현재 제약에 적응해 만든 해법을 고객의 영구한 욕구로 착각할 때다.** 고객의 말은 현재를 고치는 가장 좋은 재료다. 다음 시장을 만들려면 그 말이 언제까지 참인지까지 물어야 한다. --- 주요 출처: Wildfire Labs, [When Customer Obsession Backfires](https://wildfirelabs.substack.com/p/when-customer-obsession-backfires). 현재 제약에 묶인 임시 진실과 지속되는 인간 욕구의 구분, BlackBerry·Netflix 사례, 현재 고객 외에 비고객·성장 세그먼트·기술 변화까지 함께 봐야 한다는 문제의식은 원문을 바탕으로 했습니다. 네 신호를 서로 다른 시간대의 증거로 배치하고 각 신호의 한계와 충돌을 해석한 부분은 이 글의 분석입니다. ### 좋은 에세이는 경험의 시간을 앞당긴다 URL: https://zerodraftlab.com/essay-advances-experience/ Last updated: 2026-09-15T08:35:54.000Z 좋은 에세이를 읽고도 생각이 바뀌지 않을 때가 있다. 글이 틀려서가 아니다. 너무 일찍 읽었거나, 너무 늦게 읽었기 때문이다. Paul Graham은 [「The Shape of the Essay Field」](https://paulgraham.com/field.html?ref=zerodraftlab.com)에서 독자가 어떤 사실을 모르는 이유를 세 가지로 나눈다. 그 사실이 중요하지 않거나, 독자가 이해하지 못하거나, 아직 경험하지 못했거나. 이 구분을 받아들이면 한 가지 결론이 나온다. 똑똑한 사람에게 중요한 것을 쓰는 작가는 결국 젊은 독자에게 가장 큰 영향을 준다. 중요한 사실이고 독자가 이해할 능력도 있다면, 그것을 모르는 가장 유력한 이유는 아직 겪지 않았기 때문이다. Graham은 에세이의 영향력을 대략 이렇게 본다. > 독자의 생각을 바꾼 정도 × 다룬 주제의 중요성 둘을 동시에 크게 만들기는 어렵다. 중요한 주제에는 이미 수많은 사람이 생각을 보탰다. 완전히 새로운 말을 하기는 힘들다. 반대로 아무도 모르는 이야기는 대개 많은 사람의 삶을 바꿀 만큼 중요하지 않다. 그러나 경험이 적은 독자에게는 이 교환관계가 달라진다. 작가에게는 오래된 5도의 방향 수정이 독자에게는 처음 만나는 갈림길이 될 수 있다. 직장을 여러 번 옮긴 사람에게 “좋은 상사를 고르는 것이 높은 연봉보다 중요하다”는 문장은 평범할 수 있다. 첫 직장을 고르는 사람에게는 몇 년의 경로를 바꾸는 문장이 될 수 있다. 여기서 에세이의 진짜 기능이 보인다. 좋은 에세이는 새로운 사실을 많이 주는 글이 아니다. **독자가 나중에 몸으로 배우게 될 사실을, 아직 선택을 바꿀 수 있을 때 먼저 건네는 글**이다. 경험은 비싼 교사다. 실패한 동업, 잘못 고른 직장, 무너진 건강, 뒤늦게 발견한 취향은 교훈을 주지만 수업료를 돌려주지 않는다. 에세이는 그 교훈을 무료로 대신 살게 해주지는 못한다. 다만 대가를 치르기 전에 알아볼 수 있는 문장을 머릿속에 심는다. 처음 읽을 때는 완전히 이해하지 못해도 괜찮다. 몇 년 뒤 현실이 그 문장과 같은 모양으로 나타나는 순간, 독자는 사건을 더 빨리 알아본다. 좋은 에세이는 답을 기억하게 하기보다 패턴을 먼저 보게 한다. 영향력은 독자가 고개를 끄덕인 순간보다, 훗날 같은 실수를 피한 순간에 발생한다. 그래서 중요한 주제의 에세이는 독창성 경쟁만으로 평가할 수 없다. 인간관계, 일, 돈, 권력, 건강처럼 오래된 주제에서 새로움의 절대량은 작을 수밖에 없다. 하지만 아직 그 문제를 통과하지 않은 독자에게는 작은 각도 차이도 큰 경로 차이가 된다. Graham은 생각이 바뀌는 정도에도 연속선이 있다고 말한다. 한쪽 끝에는 『이기적 유전자』처럼 세계를 보는 주인공 자체를 바꾸는 책이 있다. 다른 끝에는 독자가 이미 어렴풋이 생각하던 것을 정확한 문장으로 붙잡아주는 글이 있다. 두 번째 변화는 작아 보이지만 중요한 선택 앞에서는 결코 작지 않다. 사람은 이름 붙일 수 없는 위험을 피하기 어렵다. 막연한 불편이 “권한 없는 책임”이라는 문장으로 바뀌면 다음 제안을 다르게 읽는다. 희미한 피로가 “회복 없는 성장은 부채”라는 문장으로 바뀌면 일정을 다르게 짠다. 에세이는 없던 현실을 만들지 않는다. 이미 눈앞에 있던 현실의 대비를 높인다. 이때 새로움은 세상에 처음 나온 생각이라는 뜻이 아니다. 그 독자의 삶에서 아직 제때 도착하지 않은 생각이면 충분하다. 오래된 진실도 늦기 전에 만나면 새로운 결과를 만든다. 그렇다면 Graham의 결론대로 좋은 에세이는 결국 젊은 사람을 위한 글일까? 거의 맞지만, 결정적인 단어 하나가 틀렸다. 영향을 크게 받는 독자는 젊은 독자가 아니라 **경험 이전의 독자**다. 나이는 그 상태를 가리키는 편리하지만 거친 대리변수일 뿐이다. 스무 살 창업가는 마흔 살 직장인보다 실패한 채용과 현금흐름의 압박을 더 많이 겪었을 수 있다. 쉰 살의 전문가도 부모의 죽음, 조직의 해체, 새로운 계층으로의 이동 앞에서는 초보자다. 같은 나이의 두 사람도 책임, 자본, 건강, 관계, 문화에 따라 전혀 다른 세계를 살아간다. 사람들이 중요한 사실을 모르는 이유 역시 중요하지 않음, 우둔함, 경험 부족의 세 칸에 깔끔하게 들어가지 않는다. 이해할 능력은 있지만 그 사실을 믿을 유인이 없을 수 있다. 알고도 정체성이 무너질까 봐 외면할 수 있다. 주변의 규범이 다른 해석을 금지할 수도 있다. 경험했지만 잘못된 원인으로 설명했을 수도 있다. 특히 중요한 진실일수록 지식보다 이해관계에 막힌다. “회의가 많으면 협업을 잘하는 조직”이라는 믿음은 정보 부족만으로 유지되지 않는다. 누군가는 회의를 통해 지위를 얻고, 누군가는 결정 책임을 분산하며, 누군가는 바쁜 모습을 성과로 인정받는다. 이런 독자에게 더 많은 사실을 주는 것만으로는 생각이 바뀌지 않는다. 따라서 에세이의 영향력에는 Graham의 식에 빠진 항이 하나 있다. > 생각을 바꾼 정도 × 주제의 중요성 × 아직 선택을 바꿀 수 있는 정도 독자가 아무리 크게 놀라도 이미 되돌릴 수 없는 일이라면 글은 해석을 바꿀 뿐 경로를 바꾸지 못한다. 반대로 작은 관점 변화라도 계약 전, 결혼 전, 창업 전, 채용 전, 건강이 무너지기 전에 도착하면 현실의 결과를 바꿀 수 있다. 영향력은 새로움뿐 아니라 도착 시점의 함수다. 이 관점은 작가가 누구를 상상해야 하는지도 바꾼다. 인구통계로서의 젊은 층을 타깃팅할 필요는 없다. 제목을 가볍게 만들고, 유행하는 어휘를 넣고, 초보자용 조언으로 낮출 이유도 없다. 오히려 반대다. 어떤 중요한 사실이 보통 너무 늦게 이해되는지 물어야 한다. 사람들은 언제 권한 없는 책임이 함정이라는 것을 배우는가. 언제 성장률보다 나쁜 고객 한 명의 비용을 이해하는가. 언제 의지보다 환경 설계가 강하다는 것을 인정하는가. 언제 관계의 질이 대화 기술보다 상대 선택에 더 크게 좌우된다는 것을 아는가. 이 질문들은 젊은 독자를 겨냥하지 않는다. 아직 해당 대가를 치르지 않은 사람을 찾는다. 그리고 작가 자신도 아직 완전히 이해하지 못한 문제로 향하게 한다. Graham이 독자 최적화보다 자신을 놀라게 하는 호기심을 따른다고 말하는 이유도 여기에 있다. 독자를 변화시키겠다는 목적만 앞세우면 작가는 이미 아는 교훈을 포장하게 된다. “젊은 사람에게 필요한 말”을 상상하는 순간 글은 쉽게 훈계가 된다. 반면 자신이 실제로 이해하지 못한 것을 추적하면, 글은 발견의 흔적을 보존한다. 다만 자기 자신을 놀라게 하는 것만으로는 충분하지 않다. 사적인 놀라움이 공적인 가치가 되려면 그 발견이 어떤 선택 앞에 있는 독자에게 언제 필요한지까지 연결해야 한다. 호기심은 출발점이고, 편집은 도착 시점을 설계하는 일이다. 좋은 에세이는 독자 대신 살아주지 않는다. 경험 없는 확신을 만들어서도 안 된다. 실제 경험을 문장 몇 개로 대체할 수 있다는 착각은 오히려 위험하다. 그러나 글은 경험이 도착했을 때 그것을 알아보는 속도를 높일 수 있다. 실수를 완전히 막지 못해도 더 일찍 멈추게 할 수 있다. 같은 대가를 치르고도 엉뚱한 교훈을 얻는 일을 줄일 수 있다. 결국 에세이가 바꾸는 것은 지식의 양보다 배움의 시간표다. 독자가 언젠가 알게 될 것을, 아직 선택지가 남아 있을 때 알게 한다. 중요한 글이 젊은 독자에게 큰 영향을 주는 이유도 젊음 자체에 있지 않다. 그들에게 아직 닫히지 않은 문이 많기 때문이다. 그리고 사람은 나이가 들어도 새로운 세계 앞에서 계속 젊어진다. 좋은 에세이는 바로 그 순간을 찾아간다. --- 출처: Paul Graham, [「The Shape of the Essay Field」](https://paulgraham.com/field.html?ref=zerodraftlab.com)(2025). 독자가 모르는 세 가지 이유, 에세이 영향력의 식, 중요한 주제와 새로움의 교환관계, 젊은 독자와 자기 호기심에 관한 논지는 원문을 바탕으로 했습니다. 나이와 경험을 분리하고 ‘아직 선택을 바꿀 수 있는 정도’를 추가한 부분은 이 글의 해석입니다. ### AI 모델 순위는 결과당 비용으로 갈린다 URL: https://zerodraftlab.com/intelligence-per-dollar/ Last updated: 2026-09-15T08:35:54.000Z AI 모델 순위표는 오랫동안 한 줄로 세워졌다. 가장 어려운 문제를 가장 많이 맞힌 모델이 가장 좋은 모델이었다. 가격과 속도는 그다음 문제였다. 이 기준이 바뀌고 있다. 이제 중요한 질문은 “누가 가장 높은 점수를 받았는가?”가 아니라 **“같은 결과를 얻는 데 얼마를 썼는가?”**다. Tom Tunguz는 이를 ‘달러당 지능’이라고 부른다. 모델 벤치마크가 정답률 하나의 경쟁에서 성능과 그 성능을 얻는 데 쓴 자원을 함께 보는 2차원 경쟁으로 이동한다는 뜻이다. 최고점이 아니라 비용 대비 성능의 경계에 있는 모델이 선택받는다. ## Microsoft가 토큰 사용량을 성적표에 넣은 이유 Microsoft는 MAI-Code-1-Flash를 발표하면서 코딩 벤치마크의 성공률 옆에 평균 솔루션 토큰 사용량을 함께 공개했다. 자사 GitHub Copilot 프로덕션 하네스에서 Claude Haiku 4.5와 비교한 결과, 네 가지 코딩 평가 모두 더 높은 성공률을 기록했고 SWE-Bench Verified에서는 최대 60% 적은 토큰으로 문제를 풀었다고 주장했다. 이 수치는 그대로 중립적 모델 순위가 되지는 않는다. Microsoft가 자기 모델을 훈련한 환경과 가까운 자체 프로덕션 하네스에서 수행한 평가다. 다른 하네스, 다른 작업 분포, 독립 평가기관에서도 같은 우위가 재현되는지는 별도로 확인해야 한다. 그럼에도 발표 형식은 중요하다. 성공률만 보여주지 않고 그 성공을 만드는 데 든 토큰을 같은 표에 올렸기 때문이다. 모델이 답을 맞혔더라도 세 배의 토큰과 더 긴 대기시간을 요구한다면, 대규모 프로덕션에서는 전혀 다른 제품이 된다. ## 토큰을 많이 썼다고 깊게 일한 것은 아니다 추론 토큰이 늘면 어려운 문제를 더 오래 탐색할 수 있다. 복잡한 버그나 넓은 코드 변경에는 실제로 더 많은 사고가 필요하다. 따라서 토큰이 많다는 이유만으로 나쁜 모델이라고 결론 내릴 수는 없다. 하지만 토큰 사용량을 노력의 증거로 착각해서도 안 된다. 같은 가설을 반복하고, 불필요하게 파일을 다시 읽고, 실패한 접근을 되풀이하고, 장황한 중간 설명을 만드는 데도 토큰이 든다. 사람의 야근 시간이 업무의 질을 보장하지 않듯, 긴 추론 기록도 결과의 질을 보장하지 않는다. 그래서 모델 계층에서 봐야 할 것은 토큰 수 자체가 아니다. **일정한 성공률을 만드는 데 필요한 토큰과 달러**다. 싼 토큰을 많이 태워 실패하는 모델도, 높은 점수를 위해 비용을 무한정 쓰는 모델도 좋은 선택이 아니다. ## 애플리케이션은 한 단계 위의 단위를 팔아야 한다 사용자는 토큰을 사지 않는다. 고객지원 팀은 해결된 문의를 사고, 개발팀은 머지할 수 있는 PR을 사고, 운영팀은 닫힌 티켓을 산다. 따라서 애플리케이션 계층의 경쟁 단위는 토큰당 가격이 아니라 **수락된 결과 한 건당 총비용**이어야 한다. 여기까지 받아들이면 “어떤 모델이 가장 좋은가?”라는 질문도 불완전해진다. 같은 모델이라도 도구, 프롬프트, 컨텍스트 선별, 재시도 정책, 검증 절차와 결합되는 순간 결과당 비용이 달라진다. 모델 선택은 시스템 설계의 일부일 뿐이다. 그러면 다음 질문이 남는다. 결과 한 건의 비용에는 정확히 무엇을 넣어야 하는가? 결과는 모델이 답을 출력했다는 뜻이 아니다. 사람이 실제로 받아들여 다음 단계로 넘길 수 있는 상태가 됐다는 뜻이다. PR이라면 테스트와 리뷰를 통과해 머지할 수 있어야 하고, 고객문의라면 재문의 없이 문제가 해결돼야 하며, 티켓이라면 사람이 뒤에서 다시 처리하지 않아도 닫혀야 한다. 이 정의를 쓰면 결과당 비용의 분자가 커진다. > 결과당 비용 = 모델 추론비 + 도구 호출비 + 재시도 비용 + 사람의 검토비 + 실패 복구비를 수락된 결과 수로 나눈 값 토큰 가격표만 비교할 때는 보이지 않던 비용이 드러난다. 작은 모델이 한 번에 성공하면 경제적이다. 하지만 여러 번 재시도하고 사람이 긴 수정 작업을 해야 한다면 비싼 모델의 단발 성공보다 총비용이 높을 수 있다. 반대로 가장 강한 모델을 모든 작업에 고정하면 간단한 분류와 조회에도 과도한 추론비를 낸다. ## 모델보다 하네스가 경제성을 결정한다 Microsoft의 발표가 흥미로운 지점도 여기에 있다. 회사는 MAI-Code-1-Flash를 GitHub Copilot의 실제 하네스와 함께 훈련했다고 강조한다. 모델만 따로 개선한 것이 아니라 모델이 파일을 읽고, 도구를 쓰고, 수정을 제출하는 환경에 맞춰 공동 최적화했다. 이것은 자체 평가라는 한계인 동시에 애플리케이션 사업자가 주목해야 할 단서다. 프로덕션 성능은 모델의 고유 능력만으로 결정되지 않는다. 필요한 컨텍스트를 얼마나 적게 정확히 넣는지, 어떤 도구를 언제 열어주는지, 실패를 얼마나 빨리 감지하는지, 검증을 모델 밖의 결정적 코드로 얼마나 옮겼는지가 비용을 좌우한다. 예를 들어 코딩 에이전트가 저장소 전체를 반복해서 읽는다면 모델 가격을 낮춰도 낭비는 남는다. 반대로 변경 범위를 좁히고 관련 테스트를 먼저 찾으며, 정적 검사와 테스트 실행을 하네스가 책임지게 하면 더 작은 모델도 높은 성공률을 낼 수 있다. 지능을 싸게 사는 일은 할인된 모델을 찾는 일이 아니라 불필요한 추론을 시스템에서 제거하는 일에 가깝다. ## 정확도와 비용 사이에는 세 가지 함정이 있다 첫째는 **토큰을 적게 쓰는 것을 무조건 효율로 보는 것**이다. 충분히 생각하지 않아 실패율이 높아지면 절약한 토큰보다 재시도 비용이 커진다. 효율은 짧은 답이 아니라 수락된 결과까지의 짧은 경로다. 둘째는 **벤치마크 통과를 업무 완료로 보는 것**이다. 패치를 만들었다는 사실과 배포 가능한 PR을 완성했다는 사실은 다르다. 테스트, 보안 검사, 리뷰 수정, 회귀 대응까지 포함해야 실제 결과당 비용이 나온다. 셋째는 **평균값 하나로 모든 작업을 라우팅하는 것**이다. 단순한 문서 수정과 여러 서비스에 걸친 장애 복구는 필요한 추론량이 다르다. 좋은 시스템은 쉬운 작업에는 빠르고 싼 모델을 쓰고, 불확실성과 실패 비용이 커질 때만 더 강한 모델과 더 긴 추론을 배정한다. ## 새로운 해자는 모델 순위가 아니라 비용 곡선이다 모델 가격과 순위는 빠르게 바뀐다. Tunguz가 2026년 6월에 제시한 모델별 비용 비교도 당시의 스냅숏일 뿐이다. 몇 달 뒤에는 이름과 숫자가 모두 달라질 수 있다. 그러나 토큰당 가격에서 결과당 가격으로 측정 단위가 이동하는 방향은 더 오래 남는다. 기업이 AI 사용량을 늘릴수록 작은 비효율도 예산, 지연시간, 사람의 검토 부담으로 증폭되기 때문이다. 앞으로 경쟁력 있는 AI 애플리케이션은 “최고 모델을 쓴다”고 말하는 제품이 아닐 가능성이 크다. 작업 난이도를 분류하고, 필요한 컨텍스트만 공급하고, 모델을 동적으로 라우팅하고, 결과를 자동 검증하며, 실패 비용까지 측정하는 제품일 것이다. 모델이 바뀌어도 이 시스템의 학습은 남는다. **가장 똑똑한 모델이 아니라, 수락 가능한 결과를 가장 싸게 반복 생산하는 시스템이 이긴다.** --- 출처: Tom Tunguz, [Intelligence Per Dollar](https://www.tomtunguz.com/tokens-per-result/?ref=zerodraftlab.com); Microsoft AI, [Introducing MAI-Code-1-Flash](https://microsoft.ai/news/introducingmai-code-1-flash/?ref=zerodraftlab.com). Microsoft의 성공률과 토큰 절감 수치는 자체 GitHub Copilot 프로덕션 하네스 평가에 따른 회사 발표이며, 독립 벤치마크 결과로 일반화하지 않았습니다. ### 브랜드 홈페이지는 자기소개 독점권을 잃었다 URL: https://zerodraftlab.com/brand-loses-self-description/ Last updated: 2026-09-15T08:35:55.000Z 사람이 브랜드 홈페이지를 열기 전에 이미 그 브랜드를 설명하는 문장을 읽는다. 검색 결과의 AI 요약, 챗봇의 추천, Reddit의 후기, YouTube의 비교 영상, 파트너의 제품 목록이 먼저 나온다. 이 자료들은 브랜드가 승인한 소개문을 그대로 전달하지 않는다. 서로 다른 출처에서 조각을 가져와 “이 회사는 누구에게 무엇을 파는가”를 대신 합성한다. **브랜드 홈페이지는 자기소개에 대한 독점권을 잃었다.** 여기서 잃은 것은 법적 소유권이 아니라 첫 문장을 편집하던 배포상의 우위다. 홈페이지가 쓸모없어졌다는 뜻은 아니다. 오히려 역할이 더 엄격해졌다. 홈페이지는 가장 멋진 소개 페이지에서, 외부의 모든 설명이 대조할 수 있는 브랜드 정본으로 바뀌고 있다. ## 브랜드는 원래도 자기 이야기 전체를 통제하지 못했다 언론, 리뷰, 고객의 입소문은 인터넷 이전에도 브랜드를 재서술했다. 회사가 자기소개를 완전히 독점했던 시대는 없었다. 다만 공식 홈페이지는 검색 뒤 방문하는 중심 표면이었고, 브랜드가 문제 정의와 비교 기준과 전환 순서를 직접 편집할 가능성이 컸다. AI 요약이 만드는 변화는 외부 평가가 새로 생겼다는 데 있지 않다. 외부 평가가 자동으로 합성되어 홈페이지 방문 전에 기본 답변으로 제시된다는 데 있다. 사용자는 “이 회사가 무엇을 하는가”, “A와 B 중 무엇이 다른가”, “이 제품을 믿을 만한가”를 묻는다. Answer Engine은 자사 페이지 하나만 요약하지 않는다. 관련 질문을 여러 갈래로 나누고, 각기 다른 웹페이지와 데이터 소스를 찾아 답을 조립할 수 있다. Google도 AI Overviews와 AI Mode가 여러 하위 주제와 데이터 소스에 걸쳐 추가 검색을 수행하는 \`query fan-out\`을 사용할 수 있다고 설명한다. 이 구조에서 홈페이지는 답변의 한 입력일 뿐이다. 브랜드가 말한 정체성보다 고객이 반복해서 묘사한 용도, 파트너가 분류한 카테고리, 비교 글이 만든 경쟁 구도가 더 강하게 채택될 수도 있다. ## 잃은 것은 도메인이 아니라 첫 문장의 편집권이다 브랜드는 여전히 자기 도메인과 공식 문구를 소유한다. 가격과 정책을 바꾸고, 제품을 어떻게 정의할지 결정하며, 잘못된 정보를 수정할 수 있다. 그러나 AI가 어떤 출처를 고르고 어떤 비교 틀에 넣을지까지 지휘할 수는 없다. 예를 들어 회사는 자신을 “AI 운영 플랫폼”이라고 부를 수 있다. 외부에서는 “고객지원 자동화 도구”로 반복해서 설명할 수 있다. AI는 추상적인 공식 정의보다 구체적인 사용 사례를 택할 수 있다. 이때 문제는 AI가 브랜드 가이드를 위반했다는 것이 아니다. 자사 정본과 시장에서 관찰되는 실체가 서로 다른 것이다. 브랜드팀이 할 수 있는 일은 원하는 문장을 모든 표면에 복사하는 것이 아니다. 공식 사실을 명확히 만들고, 외부의 독립된 설명이 그 사실과 대체로 같은 실체를 가리키게 하는 것이다. ## 홈페이지는 광고판에서 정본으로 바뀐다 정본의 역할은 화려한 수사보다 동일성과 최신성을 유지하는 데 있다. 법적 이름과 브랜드명, 제품이 해결하는 문제, 대상 고객, 가격과 정책, 공식 연락처, 지원 범위, 변경 날짜가 서로 모순되지 않아야 한다. 기계가 읽는 정보와 사람이 읽는 정보도 일치해야 한다. Google은 Organization 구조화 데이터가 조직의 행정 정보를 이해하고 동명이 조직을 구분하는 데 도움을 줄 수 있다고 설명한다. \`legalName\`, \`url\`, \`sameAs\`, 연락처 같은 속성은 브랜드가 누구인지 연결하는 신호다. 동시에 구조화 데이터는 화면에 보이는 내용과 맞아야 하며, 표시나 인용을 보장하지 않는다. 따라서 정본은 AI를 속이는 메타데이터가 아니다. 사람이 읽는 주장, 기계가 읽는 식별자, 실제 제품 경험을 같은 사실에 맞추는 운영 규율이다. ## 자기주장은 정본이지만 신뢰는 외부에서 완성된다 회사가 “가장 신뢰받는”, “업계 1위”, “고객 중심”이라고 쓰는 것은 자기주장이다. 같은 문장을 보도자료와 파트너 페이지와 광고형 리뷰에 반복해도 독립된 증거가 되지는 않는다. 외부 증거는 다른 역할을 한다. 고객 리뷰는 실제 사용의 마찰을 보여주고, 파트너 문서는 통합 가능성을 보여주며, 비교 글은 선택 기준을 드러낸다. YouTube 데모는 제품이 움직이는 모습을 보여주고, 공공 등록정보와 정책 문서는 회사가 책임지는 범위를 고정한다. 이 증거들이 모두 칭찬일 필요는 없다. 오히려 조건과 한계가 있는 설명이 더 믿을 만하다. 누구에게는 잘 맞고 누구에게는 맞지 않는지, 어떤 비용과 전제가 필요한지 드러나야 AI도 브랜드를 과장된 형용사 대신 구체적인 판단으로 설명할 수 있다. 그렇다면 모든 외부 표면을 브랜드 가이드에 맞춰 통일해야 할까. 아니다. 일관성과 동일성은 다르다. 사실은 일치해야 하지만 각 표면은 서로 다른 질문과 증거를 맡아야 한다. 모든 채널이 홈페이지 문구를 복사하면 증거망이 아니라 복제망이 된다. ## 배포는 같은 문장의 복제가 아니라 다른 증거의 배치다 홈페이지는 공식 정의와 정책을 맡는다. 파트너 페이지는 실제 연결과 공동 고객을 보여준다. 비교 글은 대안을 고르는 기준을 제공한다. YouTube는 제품의 동작과 사용 맥락을 보여주고, 커뮤니티는 예외와 실패와 우회법을 드러낸다. 각 표면이 같은 역할을 하면 외부 언급 수만 늘고 새로운 정보는 생기지 않는다. 브랜드 소개문을 열 곳에 배포한 것은 열 개의 독립 출처가 아니라 하나의 자기주장을 열 번 복제한 것이다. 강한 외부 표면은 브랜드가 완전히 통제하지 않는다. 고객은 불편을 말하고, 비교자는 경쟁사의 장점을 함께 적으며, 파트너는 자신의 기준으로 제품을 분류한다. 바로 그 독립성이 증거의 가치다. 브랜드는 이 서술권을 허용하되 사실 오류는 정정해야 한다. 비판을 지우거나 협찬 관계를 숨기거나 커뮤니티 대화를 조작하면 단기적으로는 좋은 문장이 늘 수 있다. 장기적으로는 외부 증거 전체의 신뢰를 훼손한다. ## 출시도 한 번의 발표가 아니라 증거를 생산하는 사건이 된다 TLDR Marketing이 소개한 Taco Bell의 Live Más LIVE 사례가 흥미로운 이유는 신제품을 많이 발표했기 때문만이 아니다. 여러 출시를 하나의 문화행사로 묶어 라이브스트림, 인플루언서 보도, 팬 참여, 앱 보상, 후속 콘텐츠가 동시에 생기는 구조를 만들었다. 출시가 보도자료 한 장으로 끝나면 AI가 참고할 표면도 제한된다. 실제 데모, 개발자의 설명, 고객의 반응, 파트너의 적용 사례, 비교 가능한 제품 정보가 함께 나오면 같은 실체를 여러 각도에서 검증할 수 있다. 이때 목표는 언급량을 부풀리는 것이 아니다. 브랜드 정본의 주장에 서로 다른 형태의 관찰 근거를 붙이는 것이다. “쉽다”는 주장에는 실제 사용 영상이, “통합된다”는 주장에는 파트너 문서가, “효과가 있다”는 주장에는 조건과 측정 방식이 있는 사례가 필요하다. ## 브랜드 파일 시스템은 생성 규칙보다 사실의 정본이어야 한다 AI에게 브랜드 보이스를 가르칠 때 \`브랜드 정본 → 보이스 예시 → 채널별 형식 → 시각 규칙 → 최종 체크리스트\`처럼 파일을 나누는 방식은 유용하다. 하지만 이 시스템을 단지 AI가 문체를 흉내 내는 도구로 만들면 절반만 쓴 것이다. 더 중요한 파일은 무엇을 주장할 수 있고 무엇은 아직 주장할 수 없는지 고정한다. 제품의 현재 범위, 승인된 표현, 근거 링크, 오래된 문구, 채널별 예외, 갱신 책임자가 있어야 한다. 보이스가 정확해도 사실이 낡으면 브랜드는 일관되게 틀린 말을 생산한다. 채널별 형식도 말투만 바꾸는 지침이 아니다. 홈페이지에는 공식 정의, YouTube에는 시연, 파트너 페이지에는 통합 근거, 비교 글에는 선택 기준이 필요하다. 파일 시스템은 모든 출력을 같게 만드는 장치가 아니라 각 표면이 같은 실체를 다른 증거로 설명하게 만드는 장치다. ## 브랜드 모니터링의 단위도 순위에서 주장으로 바뀐다 검색 순위와 홈페이지 트래픽만 보면 AI가 브랜드를 어떻게 설명하는지 놓칠 수 있다. 이제는 중요한 질문에서 어떤 문장이 생성되는지, 어떤 출처가 근거로 쓰이는지, 오래된 정보가 반복되는지, 경쟁사와 어떤 기준으로 비교되는지를 함께 봐야 한다. 모든 답변을 통제할 수는 없다. 모델과 질문과 시점에 따라 결과가 달라진다. 그래서 목표는 완벽한 문장 통제가 아니라 반복되는 오류를 찾고 입력 표면의 원인을 고치는 것이다. 가격이 틀리면 공식 페이지와 파트너 피드를 갱신한다. 제품 범위가 혼동되면 홈페이지 정의와 실제 사용 사례의 간격을 본다. 오래된 리뷰가 계속 인용되면 최신의 독립된 사례가 부족한 것은 아닌지 확인한다. 정정 요청만 반복하기보다 왜 그 설명이 합리적으로 만들어졌는지 조사해야 한다. ## 독점권 이후의 브랜드는 통제보다 일치로 강해진다 AI 시대의 브랜드 전략을 “더 많은 AEO 콘텐츠를 만들자”로 끝내면 다시 형식 최적화에 갇힌다. 최신 날짜와 비교 글과 목록형 콘텐츠는 도움이 될 수 있지만, 실체 없는 형식을 늘리면 AI가 인용할 문장은 많아져도 믿을 이유는 늘지 않는다. 브랜드가 직접 책임질 것은 정본이다. 외부에서 축적해야 할 것은 독립된 증거다. 검색과 AI가 가진 제3자의 서술권은 관찰하고, 오류는 정정하되 완전히 통제하려 들지 않아야 한다. 홈페이지의 중요성은 사라지지 않는다. 홈페이지가 최종 답변이 아니라 기준점이 된다. 시장의 여러 설명이 다른 단어를 쓰더라도 같은 회사, 같은 제품, 같은 약속과 한계를 가리키게 만드는 기준점이다. **앞으로 강한 브랜드는 자기 이야기를 가장 크게 말하는 브랜드가 아니다. 누가 다시 설명해도 같은 실체가 남는 브랜드다.** --- 주요 출처: [TLDR Marketing 2026-06-01](https://tldr.tech/marketing/2026-06-01?ref=zerodraftlab.com); Google Search Central의 [AI features and your website](https://developers.google.com/search/docs/appearance/ai-features?ref=zerodraftlab.com)와 [Organization structured data](https://developers.google.com/search/docs/appearance/structured-data/organization?ref=zerodraftlab.com). TLDR이 재인용한 제로클릭·CTR·AI Overview 수치는 조사 정의와 출처가 섞여 있어 본문 근거로 사용하지 않았습니다. 브랜드 정본·외부 증거·제3자 서술권의 구분은 이 글의 분석입니다. ### 어댑트가 산 것은 조회수가 아니라 관심 생산능력이었다 URL: https://zerodraftlab.com/attention-production-acquisition/ Last updated: 2026-09-15T08:35:56.000Z 2021년 11월, D2C 미디어커머스 기업 어댑트는 콘텐츠 스튜디오 ODG와 Solfa를 인수했다. 당시 두 채널의 합산 유튜브 구독자는 422만 명 이상, 누적 조회수는 7억 회 이상이었다. 영상 172편의 평균 조회수가 약 410만 회였다는 숫자까지 붙었다. 이 거래를 구독자 422만 명짜리 미디어 계정을 산 일로만 보면 절반만 읽은 셈이다. **어댑트가 산 것은 이미 모인 관심보다, 다음 관심을 반복해서 만들어내는 능력이었다.** 미디어커머스 회사는 광고비를 써서 사람을 제품 앞으로 데려올 수 있다. 하지만 광고로 산 관심은 집행을 멈추면 함께 멈춘다. 광고 소재도 계속 새로 만들어야 한다. 제품이 많아질수록 필요한 것은 한 번의 바이럴이 아니라, 사람들이 자발적으로 보고 공유할 장면을 계속 만드는 제작 체계다. ODG와 Solfa가 보여준 자산은 이 지점에 있었다. ODG는 아이와 어른이 함께 보는 장면을 반복 가능한 시리즈로 만들었다. 아티스트 출연 콘텐츠를 여러 형식으로 확장했고, 동명의 패션 브랜드까지 운영했다. Solfa는 ‘40 대 1 이상형 찾기’ 같은 포맷을 만들고 미국 유튜브 채널 Jubilee에 라이선스로 판매했다. 조회수는 결과였다. 그 결과 뒤에는 출연자를 섭외하고, 사람들이 반응할 질문을 고르고, 한 번 통했던 장면을 다음 시리즈와 다른 사업으로 확장하는 제작 문법이 있었다. ODG의 패션 브랜드는 관심이 상품으로 이동할 수 있다는 단서였고, Solfa의 포맷 수출은 영상 한 편이 아니라 재사용 가능한 구조에도 가격이 붙는다는 단서였다. ## 독립 운영은 인수 목적을 드러낸다 어댑트는 인수 뒤에도 윤성원 대표 체제로 두 스튜디오를 독립 운영하겠다고 밝혔다. 동시에 대형 시리즈 제작, 음악 신규 채널, 90년대생을 다루는 ‘1994’ 채널에 투자해 원천 IP를 늘리겠다고 했다. 이 조합은 중요하다. 인수한 조직을 자사 제품 광고팀으로 흡수했다면 어댑트는 제작 인력을 산 것이다. 반대로 독립성을 유지하면서 더 큰 시리즈와 신규 채널에 자본을 넣는다면, 산 것은 특정 영상의 성과가 아니라 그 성과를 다시 낳는 시스템에 가깝다. 좋은 콘텐츠 스튜디오의 핵심 자산은 카메라나 편집 인력이 아니다. 어떤 긴장이 사람을 멈추게 하는지 아는 기획 감각, 출연자가 자기 이야기를 꺼내게 하는 연출, 시리즈를 기다리게 만드는 형식, 성공한 형식을 브랜드와 라이선스로 옮기는 능력이다. 이 능력은 광고 플랫폼에서 노출을 사는 것과 다른 종류의 자산이다. 광고는 이미 존재하는 관심의 흐름에서 자리를 산다. 제작사는 아직 존재하지 않는 관심의 흐름을 새로 만든다. 어댑트의 인수는 미디어커머스가 유통 효율만 높이는 사업에서 벗어나려면, 결국 관심의 생산 단계까지 거슬러 올라가야 한다는 판단으로 읽을 수 있다. 그러나 관심을 만들 수 있다는 사실과 그 관심을 커머스 매출로 바꿀 수 있다는 사실 사이에는 큰 간격이 있다. 인수의 진짜 성패는 바로 그 간격을 어떻게 건넜는지에 달려 있다. 그 간격을 건너려면 먼저 구독자, 제작 능력, IP, 구매 전환을 같은 자산으로 착각하지 않아야 한다. ## 구독자는 소유한 수요가 아니다 422만 구독자는 강력한 유통 기반이지만, 어댑트 제품을 사겠다고 모인 고객 명단은 아니다. ODG를 보는 이유와 건강·생활·뷰티 제품을 사는 이유가 자동으로 연결되지는 않는다. 채널의 정체성을 훼손하는 상품 노출은 단기 클릭을 만들 수 있어도, 다음 영상의 신뢰를 깎아 관심 생산능력 자체를 망가뜨릴 수 있다. 그래서 이 거래의 가치를 단순한 고객획득비용 절감으로 계산하면 위험하다. 광고비가 줄었는지만 보면 콘텐츠 조직이 만든 브랜드 자산을 놓치고, 조회수가 늘었는지만 보면 그 관심이 누구의 제품 수요로 이어졌는지 알 수 없다. 더 정확한 질문은 세 단계로 나뉜다. 첫째, 인수 뒤에도 채널이 이전과 같은 빈도로 히트 포맷을 만들었는가. 둘째, 그 포맷이 신규 채널, 브랜드, 라이선스처럼 반복 사용 가능한 IP로 늘어났는가. 셋째, 그 관심이 콘텐츠 신뢰를 훼손하지 않으면서 자사 브랜드의 검색, 회원, 구매, 재구매로 이어졌는가. 첫 번째는 제작 역량의 유지, 두 번째는 자산화, 세 번째는 미디어커머스와의 결합을 검증한다. 셋 중 하나라도 빠지면 인수 논리는 달라진다. 조회수는 유지됐지만 IP가 늘지 않았다면 잘 운영되는 채널을 산 것이고, IP는 늘었지만 구매로 이어지지 않았다면 콘텐츠 포트폴리오를 산 것이다. 전환까지 반복됐다면 비로소 관심 생산과 커머스가 하나의 엔진이 됐다고 말할 수 있다. ## 창작 조직은 효율화할수록 망가질 수 있다 제작 능력을 인수하는 거래에는 역설이 있다. 인수자가 시너지를 빨리 증명하려 할수록 피인수 조직의 능력을 훼손할 수 있다. 모든 콘텐츠에 제품 노출을 요구하고, 단기 매출로 기획을 평가하고, 본사의 승인 절차를 덧붙이면 제작 속도와 실험의 폭이 줄어든다. 어댑트가 발표 당시 독립 운영을 강조한 이유도 이 위험과 연결해 읽을 수 있다. 창작자의 판단 체계는 재무제표에 바로 보이지 않지만, 그 판단 체계가 사라지면 422만 구독자는 과거 성과의 숫자만 남는다. 사람들은 채널을 구독했지 인수자를 구독한 것이 아니기 때문이다. 따라서 좋은 통합은 제작 조직을 광고 부서로 바꾸는 일이 아니다. 콘텐츠가 독립적으로 신뢰와 관심을 만들게 두고, 그 과정에서 발견된 캐릭터·세계관·형식·수요를 브랜드와 제품이 활용할 수 있는 선택지를 넓히는 일이다. 통합의 단위가 영상 속 PPL이 아니라 IP와 고객 이해가 되어야 한다. ## 이 기사가 증명하는 것과 증명하지 않는 것 ZDNet Korea의 기사는 인수 발표 자료다. 422만 구독자와 7억 조회수는 2021년 11월 15일 기준의 인수 당시 수치다. 독립 운영, 대형 시리즈 투자, 신규 채널, 원천 IP 확보도 당시 회사가 밝힌 계획이다. 따라서 이 기사만으로 인수 이후 커머스 매출이 늘었다거나 광고 의존도가 낮아졌다고 결론 내릴 수는 없다. ODG 패션 브랜드와 Solfa의 포맷 라이선스는 확장 가능성을 보여주는 사례이지, 어댑트의 인수 성과를 입증하는 숫자는 아니다. 거래가 실제로 성공했는지 판단하려면 인수 전후의 콘텐츠 성과, IP 매출, 자사몰 유입, 신규 고객획득비용, 재구매 같은 후속 자료가 필요하다. 그 한계를 인정해도 이 사례의 의미는 남는다. 미디어커머스가 성장하면서 선택할 수 있는 것은 더 정교하게 광고를 사는 방법만이 아니다. 사람들이 다음 편을 기다릴 이유를 만드는 조직, 한 번의 히트를 시리즈와 브랜드와 포맷으로 확장하는 조직을 자산으로 삼을 수도 있다. **미디어커머스 회사가 산 것은 제작사가 아니라 반복 가능한 관심 생산능력이었다.** 다만 그 능력이 커머스 엔진이 되었는지는 발표가 아니라 이후의 숫자로 증명해야 한다. --- 주요 출처: 백봉삼, [「어댑트, 콘텐츠 제작사 오디지·솔파 인수」](https://zdnet.co.kr/view/?no=20211116102406&ref=zerodraftlab.com), ZDNet Korea, 2021년 11월 16일. 채널 구독자·조회수·영상 수, ODG 패션 브랜드, Solfa 포맷 라이선스, 독립 운영 및 투자 계획은 해당 기사에 근거했습니다. ‘반복 가능한 관심 생산능력’과 인수 구조에 관한 설명은 이 글의 분석이며, 인수 이후 매출 전환 성과를 뜻하지 않습니다. ### 동물실험이 인플루언서 프로토콜이 되는 순간 URL: https://zerodraftlab.com/peptide-evidence-inflation/ Last updated: 2026-09-15T08:35:56.000Z 펩타이드라는 단어는 이상한 신뢰를 만든다. 인슐린 같은 승인 의약품도 펩타이드이고, 체중 관리에 쓰이는 일부 승인 약물도 펩타이드다. 동시에 사람 대상 근거가 거의 없는 BPC-157, epitalon, 주사용 GHK-Cu도 같은 이름 아래 놓인다. 화학적 분류가 임상적 보증처럼 들리는 순간, 전혀 다른 증거 수준의 물질들이 하나의 건강 카테고리로 평평해진다. **동물실험 하나가 인플루언서 프로토콜이 되는 동안 근거의 양은 거의 늘지 않는다. 대신 이야기의 확신과 실행 가능성만 단계마다 커진다.** 이 글은 펩타이드를 추천하거나 모두 무효라고 선언하려는 글이 아니다. 흥미로운 전임상 신호가 어떻게 개인용 용량, 주기, 스택, 구매 링크가 붙은 프로토콜로 변하는지 그 번역 과정을 보는 글이다. ## 펩타이드는 효능 등급이 아니라 분자의 범주다 “펩타이드가 효과가 있는가”라는 질문은 “작은 분자 약물이 효과가 있는가”와 비슷하다. 범위가 너무 넓다. 승인된 의약품, 임상시험 중인 후보, 조제약, 화장품 성분, 연구용 물질을 같은 질문으로 판단할 수 없다. 그런데 시장의 언어는 이 차이를 자주 지운다. 승인 약물이 만든 신뢰가 카테고리 전체로 번지고, “몸에 이미 존재하는 신호물질”이나 “짧은 아미노산 사슬” 같은 설명은 자연스럽고 정밀하다는 인상을 준다. 자연적으로 존재한다는 사실은 특정 용량과 투여경로의 안전성을 보증하지 않는다. 같은 이름의 물질도 피부에 바르는 것과 주사하는 것은 다른 질문이다. 흡수와 전신 노출이 달라지고, 멸균과 엔도톡신, 응집과 면역반응이라는 위험이 새로 생긴다. 국소 화장품 자료가 있다고 주사 안전성이 따라오는 것은 아니다. ## 쥐의 절단 건과 사람의 일상 손상 사이에는 여러 번의 번역이 필요하다 BPC-157의 회복 서사에 자주 인용되는 연구 중 하나는 절단한 쥐의 아킬레스건을 다룬다. 연구자는 특정 조건에서 기능, 조직, 생체역학 지표의 변화를 관찰했다. 이 결과는 후속 연구의 이유가 될 수 있다. 그러나 바로 사람의 스포츠 손상 프로토콜이 되지는 않는다. 종이 다르고, 손상 모델이 다르고, 투여경로와 용량이 다르며, 관찰 기간과 결과 지표도 다르다. 사람의 통증이 줄었는지, 기능이 회복됐는지, 기존 치료보다 순편익이 큰지, 드문 부작용과 장기 위험은 무엇인지 각각 새로 검증해야 한다. 소규모 사람 자료가 일부 존재한다는 사실도 이 사다리를 없애지 않는다. 작은 표본과 짧은 관찰에서 심각한 문제가 보이지 않았다는 결과는 드문 부작용이나 장기 안전성을 검출하기 어렵다. “자료가 조금 있다”와 “안전성과 유효성이 확립됐다” 사이에는 큰 간격이 있다. ## 기전은 설명이지 처방전이 아니다 근거가 약한 시장일수록 기전 설명은 길어진다. 혈관신생, 콜라겐, 염증 경로, 성장인자, 수용체 같은 단어가 연결되면 작동할 법한 이야기가 만들어진다. 생물학적 개연성은 중요하다. 무엇을 연구할지 고르고 왜 효과가 날 수 있는지 설명한다. 하지만 임상 순편익을 대신하지는 않는다. 어떤 경로를 자극하는 것이 실험실에서는 유익해 보여도 사람 전체에서는 다른 조직과 상호작용하거나 예상하지 못한 위험을 만들 수 있다. 기전 설명이 풍부할수록 청자는 근거도 풍부하다고 느끼기 쉽다. 실제로 늘어난 것은 설명의 세부사항이지, 무작위 사람 연구의 표본이나 추적 기간이 아닐 수 있다. ## 긴 방송 안에서는 승인 약과 연구물질이 같은 메뉴처럼 들린다 Huberman Lab의 펩타이드 에피소드 공식 소개는 동물과 사람 데이터 사이의 간극, 물질 출처의 차이, 위험과 불확실성을 분명히 언급한다. 따라서 방송이 위험을 전혀 말하지 않았다고 비판하는 것은 공정하지 않다. 문제는 정보의 배열이다. 승인 의약품, 3상 시험 중인 후보, 동물 연구 중심 물질, 임상의 경험담이 한 에피소드에서 연속적으로 다뤄지면 증거의 계층이 평평해질 수 있다. 청자는 경고 문장보다 물질 이름, 기대 효과, 투여 방법을 더 쉽게 기억한다. 긴 방송은 다시 쇼츠와 요약과 게시물로 잘린다. 이때 “인간 연구가 부족하다”는 문장은 사라지고 “회복을 촉진하는 펩타이드”라는 제목만 남는다. 방송의 신중한 단서가 유통 과정에서 탈락할수록, 연구 주제는 소비자가 바로 실행할 수 있는 프로토콜처럼 변한다. 하지만 논문 속 분자가 유망하다고 해도 내가 구매한 바이알이 같은 물질이라는 보장은 어디에서 생길까. 여기서 두 번째 증거 절벽이 나온다. 효능 연구와 제품 품질은 별개의 문제다. 논문이 맞더라도 출처, 순도, 용량, 멸균, 보관이 검증되지 않으면 소비자가 쓰는 제품에 그대로 옮길 수 없다. ## 논문 속 분자와 온라인 바이알은 같은 증거를 공유하지 않는다 FDA가 조제용 벌크 성분의 잠재적 위험을 정리한 페이지는 BPC-157에 대해 제안된 투여경로의 사람 안전성 정보가 없거나 제한적이라고 적는다. 또한 응집과 펩타이드 불순물에 따른 면역원성, 활성원료의 특성화 문제를 지적한다. 주사용 GHK-Cu와 epitalon에도 비슷한 경계가 있다. FDA의 문구는 이 물질들이 해롭다고 모두 입증됐다는 뜻이 아니다. 충분한 사람 안전성 자료가 없고, 주사 경로에서는 불순물과 응집, 면역반응을 판단하기 어렵다는 뜻이다. 이 구분은 중요하다. “위험이 확정됐다”는 과장도 피해야 하지만, “위험이 입증되지 않았으니 안전하다”는 결론도 틀리다. 자료 부족은 안전 판정이 아니라 불확실성이다. 회색시장에서는 불확실성이 한 겹 더 붙는다. 라벨의 물질과 실제 내용물이 같은지, 표기 용량이 맞는지, 합성 과정의 부산물이 얼마나 남았는지, 주사용 제품이 멸균됐는지 소비자가 검증하기 어렵다. 분석성적서가 있어도 시료와 내가 받은 바이알의 동일성을 보증하지 못하면 증거 사슬은 끊긴다. ## Retatrutide는 임상 진전과 소비자 이용 가능성이 다른 문제임을 보여준다 Retatrutide는 강한 기대를 받는 임상시험 후보다. 긍정적인 시험 결과와 차세대 체중 관리 약물이라는 보도가 나오면 시장은 승인 전에 이름부터 선점한다. “연구용” 또는 “조제”라는 표현을 붙인 제품이 나타나고, 실제 임상시험과 무관한 개인 프로토콜이 퍼진다. 그러나 2026년 7월 현재 FDA의 입장은 명확하다. Retatrutide는 FDA 승인 의약품의 성분이 아니며 어떤 질환에도 안전성과 유효성이 확립되지 않았고, 미국 연방법상 조제에 사용할 수 없다. 이 문장은 retatrutide가 실패한 후보라는 뜻이 아니다. 유망한 후보와 승인된 치료, 임상시험용 제품과 온라인 판매 바이알을 구분하라는 뜻이다. 3상 진전은 중요한 근거지만 규제 심사, 제조 품질, 표시사항, 시판 후 감시를 자동으로 완료하지 않는다. 시장은 이 시간차를 수익 기회로 바꾼다. 과학은 아직 질문을 닫지 않았는데 유통은 이미 답이 나온 것처럼 움직인다. 기대가 클수록 “곧 승인될 것”이라는 전망이 “지금 써도 된다”는 허가처럼 변한다. ## 근거 과장은 거짓말 한 번보다 번역 손실의 연쇄에 가깝다 이 과정이 항상 누군가의 노골적인 거짓말로 시작되는 것은 아니다. 연구자는 제한된 조건에서 전임상 신호를 보고한다. 해설자는 이해하기 쉬운 기전으로 번역한다. 임상의나 사용자는 경험담을 보탠다. 인플루언서는 비교표와 스택을 만든다. 판매자는 구매 링크를 붙인다. 각 단계는 이전 단계보다 행동하기 쉽다. 동시에 조건과 실패 가능성, 불확실성은 줄어든다. “쥐의 특정 손상 모델에서 관찰됐다”는 문장은 “회복을 지원할 수 있다”가 되고, 마지막에는 “몇 주 동안 얼마를 써라”가 된다. 그래서 근거를 볼 때는 결론보다 번역 경로를 거꾸로 추적해야 한다. 이 프로토콜의 출발점이 사람 무작위시험인지, 동물 연구인지, 세포 기전인지, 경험담인지 확인한다. 같은 적응증과 같은 투여경로인지, 비교 대상과 추적 기간이 충분한지 묻는다. ## 추천표 대신 증거 사다리를 본다 펩타이드 시장을 판단하는 데 필요한 것은 더 정교한 물질별 순위표가 아니다. 각 주장이 증거 사다리의 어느 칸에 있는지 분리하는 일이다. 사람 대상 무작위시험이 있는가. 내가 기대하는 용도와 같은 적응증·투여경로인가. 승인된 의약품이거나 법적으로 허용된 조제인가. 제품의 정체성·순도·멸균·보관을 검증할 수 있는가. 장기 안전성과 기존 대안보다 나은 순편익이 확인됐는가. 이 질문에 답하지 못하면 효과가 없다는 뜻은 아니다. 효과와 안전을 자신 있게 말할 근거가 아직 없다는 뜻이다. 가능성과 권고 사이에 남겨둬야 할 거리다. **동물실험에서 인플루언서 프로토콜까지 가는 길에서 가장 많이 늘어나는 것은 데이터가 아니라 확신이다. 건강 판단은 그 확신을 따라가는 일이 아니라, 중간에 사라진 증거 단계를 다시 세우는 일이다.** --- 주요 출처: [Huberman Lab, Peptides: The Science, Uses & Safety](https://www.hubermanlab.com/episode/peptides-the-science-uses-and-safety-abud-bakri?ref=zerodraftlab.com); FDA의 [조제용 벌크 성분 잠재적 안전성 목록](https://www.fda.gov/drugs/human-drug-compounding/certain-bulk-drug-substances-use-compounding-may-present-significant-safety-risks?pg=3&ref=zerodraftlab.com)과 [미승인 GLP-1 및 retatrutide 안내](https://www.fda.gov/drugs/postmarket-drug-safety-information-patients-and-providers/medications-containing-semaglutide-marketed-type-2-diabetes-or-weight-loss?ref=zerodraftlab.com); BPC-157의 [쥐 아킬레스건 연구](https://pubmed.ncbi.nlm.nih.gov/14554208/?ref=zerodraftlab.com). 이 글은 의료 조언이나 구매·투약 권고가 아닙니다. FDA의 ‘안전성 자료 부족’은 위해가 확정됐다는 뜻도, 안전하다는 뜻도 아닙니다. ### AI 앱의 해자는 고객 결과를 닫는 폐쇄회로다 URL: https://zerodraftlab.com/ai-apps-own-the-outcome/ Last updated: 2026-09-15T08:35:58.000Z AI가 제품의 핵심 기능을 거의 공짜로 만들어준다면 그 회사에는 무엇이 남을까. 이 질문은 “앱 레이어가 죽는다”는 선언으로 자주 이어진다. 요약, 분류, 생성, 검색, 상담 같은 기능은 범용 모델에 흡수되고, 모델을 얇게 감싼 앱은 가격을 지키기 어려워진다는 주장이다. 절반은 맞다. 기능을 만드는 비용은 빠르게 내려간다. 그러나 기능이 싸지는 것과 고객의 문제가 해결되는 것은 같은 일이 아니다. **AI 앱의 해자는 기능이 아니라 고객 결과를 관찰하고, 개입하고, 측정해 다시 개선하는 폐쇄회로다.** 고객은 토큰을 사지 않는다. 매출이 늘고, 해결률이 오르고, 처리 시간이 줄고, 오류와 비용이 내려가는 변화를 산다. 앱이 이 숫자에 가까이 갈수록 모델 교체에는 강해지고, 결과와 상관없는 기능 목록에 머물수록 범용 모델과 직접 경쟁하게 된다. ## 토큰은 가치가 아니라 투입량이다 기업 AI 시장은 오랫동안 사용량을 성과처럼 말했다. 몇 명이 도입했고, 몇 개의 메시지를 보냈고, 몇 백만 토큰을 처리했는지가 대시보드의 중심이었다. 실험 단계에서는 이 수치도 의미가 있었다. 사람들이 도구를 실제로 만지는지 확인해야 했기 때문이다. 구매가 갱신 단계에 들어가면 질문이 달라진다. 더 많은 토큰을 썼다는 사실이 더 많은 매출, 더 빠른 처리, 더 낮은 위험으로 이어졌는가. 연결되지 않았다면 사용량 증가는 가치가 아니라 비용 증가일 수도 있다. 노동시간도 마찬가지다. 한 팀이 두 배의 시간을 썼다고 고객이 두 배의 돈을 내지는 않는다. 투입은 원가를 설명할 수 있지만 구매 이유를 설명하지 못한다. 토큰당 가격 경쟁만 하면 모델 공급자의 원가 곡선에 사업의 운명을 맡기게 된다. 따라서 AI 앱의 첫 번째 설계 대상은 프롬프트나 모델 라우터가 아니라 고객이 중요하게 보는 결과 숫자다. 지원 제품이라면 자동응답 수가 아니라 실제 해결률과 재문의율, 영업 제품이라면 생성한 이메일 수가 아니라 유효한 기회와 매출, 의료 운영 제품이라면 문서 생성량이 아니라 오류와 대기시간이 기준이 된다. ## 수직형 해자는 업종 지식보다 예외 처리에 가깝다 “우리는 특정 업종을 안다”는 말만으로는 해자가 되지 않는다. 업종 용어집과 일반적인 업무 절차는 범용 모델도 빠르게 흡수한다. 쉽게 문서화되는 지식은 쉽게 복제된다. 오래 남는 것은 문서에 적히지 않은 예외다. 같은 요청이라도 고객 등급과 계약 조건에 따라 승인 경로가 달라지고, 오래된 시스템의 코드값이 현실의 의미와 어긋나며, 규정상 가능한 일과 조직이 실제로 허용하는 일 사이에 간격이 있다. 담당자는 어느 단계에서 사람이 개입해야 사고가 나지 않는지 경험으로 안다. 범용 모델은 정상 경로를 빠르게 처리한다. 수직형 앱은 정상 경로 밖에서 망가지지 않도록 상태를 읽고, 올바른 시스템을 갱신하고, 예외를 적절한 사람에게 넘기며, 그 결과를 다시 학습한다. 해자는 ‘업종 특화 모델’이라는 명사보다 **지저분한 현실을 끝까지 닫는 동사**에 있다. ## 플랫폼부터 만들면 아직 존재하지 않는 사용 패턴을 추상화한다 AI가 모든 업무에 들어갈 것이라는 전망은 플랫폼을 먼저 만들고 싶은 유혹을 준다. 공통 Agent 층, 범용 메모리, 통합 도구 인터페이스, 조직 전체의 오케스트레이션을 설계하면 미래의 모든 앱을 담을 수 있을 것처럼 보인다. 문제는 좋은 추상화가 실제 반복에서 나온다는 점이다. 어떤 데이터가 정말 공통인지, 어느 권한 경계가 자주 충돌하는지, 사용자가 무엇을 결과로 보는지는 킬러 워크플로를 운영해보기 전에는 알기 어렵다. 사용 패턴이 없는데 플랫폼을 만들면 현재의 상상을 미래의 표준으로 굳힌다. 먼저 하나의 중요한 결과를 끝까지 책임져야 한다. 그 과정에서 반복해서 등장하는 데이터, 권한, 예외, 평가 방식을 발견한 뒤 공통 층으로 올리는 편이 낫다. 플랫폼은 야심의 출발점이 아니라 성공한 폐쇄회로가 여러 번 겹친 뒤 남는 부산물이다. 그렇다면 결과를 책임진다는 말은 단순히 성과형 가격을 붙인다는 뜻일까. 아니다. 가격표를 바꾸기 전에 제품이 결과를 관찰할 수 있어야 한다. 결과를 관찰하려면 고객의 실제 시스템에 연결되어야 하고, 개입 전후를 구분해야 하며, 잘못된 최적화를 막을 반대 지표까지 가져야 한다. ## 폐쇄회로에는 관찰, 개입, 판정, 수정이 모두 필요하다 AI 기능은 입력을 받아 출력을 만든다. 폐쇄회로 제품은 출력 뒤에 무슨 일이 일어났는지 돌아본다. 추천한 리드가 실제로 계약했는지, 작성한 답변이 티켓을 닫았는지, 자동화한 청구가 거절률을 낮췄는지 확인한다. 이 루프는 네 단계로 나뉜다. 먼저 현실의 기준 상태를 관찰한다. 다음으로 AI가 개입한다. 그 뒤 고객이 믿는 숫자로 결과를 판정한다. 마지막으로 실패한 사례와 예외를 다음 개입에 반영한다. 한 단계라도 빠지면 앱은 결과를 책임지는 것처럼 말하면서 실제로는 산출물만 납품한다. 여기에는 불편한 조건이 있다. 고객 시스템의 CRM, 결제, 지원, ERP 같은 정본에 접근해야 한다. 모델이 좋은 문장을 만들었다는 내부 평가는 부족하다. 고객이 돈을 받았는지, 문제가 해결됐는지, 비용이 실제로 줄었는지를 읽어야 한다. 그래서 강한 AI 앱은 모델보다 통합과 운영에 더 많은 품을 들일 수 있다. 화려한 데모에서는 손해처럼 보이지만, 바로 그 연결이 범용 챗봇이 대신하기 어려운 자산이 된다. ## 결과 지표 하나만 좇으면 새로운 실패를 만든다 결과 중심이라는 말도 위험하게 단순화될 수 있다. 고객지원의 해결률만 높이면 Agent가 대화를 성급히 닫을 수 있다. 매출만 높이면 할인과 과잉 약속으로 환불과 이탈을 뒤로 미룰 수 있다. 처리 비용만 낮추면 어려운 고객을 사람이 떠안는다. 좋은 폐쇄회로는 대표 지표와 함께 방어 지표를 둔다. 해결률 옆에 재문의율과 고객 만족, 매출 옆에 환불과 유지율, 속도 옆에 오류와 사고를 놓는다. AI가 숫자를 개선했는지뿐 아니라 비용을 다른 곳으로 밀어냈는지 본다. 성과 귀속도 정직해야 한다. 시장 수요, 영업팀의 역량, 가격 변경이 함께 작용한 결과를 AI 앱 하나의 공으로 돌리면 폐쇄회로가 아니라 마케팅 서사가 된다. 완벽한 인과 추정이 어렵더라도 전후 비교, 통제 가능한 구간, 사람이 개입한 비율, 실패 사례를 함께 남겨야 한다. ## 유통도 평균이 아니라 한계수익으로 본다 제품이 결과를 숫자로 본다면 유통도 같은 방식으로 운영할 수 있다. “이 채널은 잘 된다”는 평균값은 과거의 지출을 설명한다. 다음 1원을 더 넣었을 때도 같은 고객을 같은 비용으로 얻을 수 있는지는 다른 질문이다. 작은 뉴스레터 한 번, 창업자의 직접 영업, 특정 파트너와의 공동 웨비나처럼 규모는 작지만 높은 수익을 내는 채널이 있다. 반대로 큰 채널은 초기에 잘 작동해도 경쟁과 피로가 쌓이면서 한계수익이 빠르게 떨어진다. 채널 이름이 아니라 추가 지출의 반응 곡선을 봐야 한다. 이 관점은 유통을 제품 밖의 홍보 활동에서 학습 루프로 바꾼다. 어떤 메시지에 어떤 고객이 반응했고, 그 고객이 제품 안에서 어떤 결과를 얻었는지 다시 연결한다. 획득 비용이 낮아도 결과가 나쁘면 좋은 채널이 아니고, 획득 비용이 높아도 장기 가치와 추천이 크면 계속 투자할 수 있다. ## 유통의 시대에는 고객의 주의가 가장 비싼 자원이다 AI는 코드를 100배 더 만들 수 있어도 고객의 평가 시간과 예산을 100배 늘리지 않는다. Rich Mironov가 지적하듯 병목은 구현의 중간에서 무엇을 만들지 정하는 앞단과, 고객이 가치를 이해하고 채택하게 만드는 뒷단으로 이동한다. 기능 공급이 폭증하면 차이는 더 많은 기능에서 나오지 않는다. 누구의 어떤 문제를 맡을지 고르고, 고객의 언어로 약속하고, 실제 환경에 배치하고, 결과를 증명하는 능력에서 나온다. 유통은 완성된 제품을 알리는 마지막 단계가 아니라 어떤 결과가 돈이 되는지 배우는 첫 단계다. 이 때문에 수직형 앱의 방어력은 데이터, 워크플로, 브랜드, 유통 가운데 하나를 고르는 문제가 아니다. 고객의 중요한 숫자를 중심으로 네 요소가 서로를 강화하게 만드는 문제다. 워크플로가 결과 데이터를 만들고, 데이터가 제품을 개선하며, 제품 성과가 브랜드와 유통을 강화하고, 유통에서 얻은 고객 언어가 다시 워크플로를 바꾼다. ## 앱 레이어는 죽지 않는다. 책임 없는 앱이 압축된다 범용 모델이 더 좋아질수록 많은 기능은 사라지거나 기본값이 될 것이다. 그러나 기업의 지저분한 현실, 예외가 많은 운영, 결과를 둘러싼 책임까지 모델 제공자가 모두 가져가지는 않는다. 살아남는 앱은 모델보다 똑똑하다고 주장할 필요가 없다. 더 가까운 곳에서 고객의 상태를 보고, 더 안전하게 개입하고, 더 정직하게 결과를 측정하면 된다. 모델은 바꿀 수 있지만 그 폐쇄회로는 쉽게 바뀌지 않는다. **AI 시대의 해자는 기능을 소유하는 데 있지 않다. 고객이 중요하게 보는 숫자가 움직일 때까지 문제를 놓지 않는 데 있다.** --- 주요 출처: [TLDR Founders 2026-06-01](https://tldr.tech/founders/2026-06-01?ref=zerodraftlab.com)의 앱 방어력·플랫폼 선행·토큰 가치·한계 채널 큐레이션; Rich Mironov, [Code Isn't Product](https://www.mironov.com/code/?ref=zerodraftlab.com). TLDR 항목 중 상당수는 X 스레드와 2차 요약이므로 개별 수치나 보편 법칙의 근거로 사용하지 않았습니다. 폐쇄회로의 네 단계와 방어 지표, 결과·유통 루프의 연결은 이 글의 분석입니다. ### 콘텐츠가 아니라 귀환 회로를 만들어라 URL: https://zerodraftlab.com/build-return-loops-not-content/ Last updated: 2026-09-15T08:35:58.000Z 콘텐츠를 만드는 비용은 계속 내려가는데, 콘텐츠 사업은 쉬워지지 않는다. 글과 이미지와 영상의 공급은 늘었지만 사람의 하루는 늘지 않았기 때문이다. 이 상황에서 “더 자주 발행하자”는 전략은 점점 약해진다. 경쟁자도 같은 도구로 더 많이 만들 수 있고, 플랫폼의 추천 공간은 그대로이며, 독자가 새로운 콘텐츠에 줄 수 있는 시간은 제한돼 있다. **앞으로의 경쟁 우위는 콘텐츠 생산량이 아니라 관심이 다시 돌아오는 회로에서 나온다.** 한 번의 조회수를 얻는 일과 다음 행동을 일으키는 일은 다르다. 사람을 멈춰 세우고, 머물게 하고, 저장하게 하고, 다시 찾아오게 하고, 결국 구매나 구독으로 이어지게 만드는 것은 개별 콘텐츠가 아니라 연결된 상태의 변화다. ## 콘텐츠는 무한해졌지만 관심은 복제되지 않는다 생성형 AI는 제작의 병목을 크게 줄였다. 예전에는 초안, 이미지, 편집, 변형본을 만드는 데 각각 사람이 필요했다. 이제 작은 팀도 한 아이디어를 여러 형식으로 빠르게 바꿀 수 있다. 그러나 제작비가 내려가면 모든 제작자의 공급이 함께 늘어난다. 한 브랜드가 발행량을 열 배로 늘리는 동안 피드 전체의 공급은 백 배가 될 수 있다. 개별 제작자의 비용 우위가 곧 독자의 관심 우위가 되지 않는 이유다. DoingSoon의 ‘Attention Engine Economy’는 이 구조를 콘텐츠 공급은 무한하고 인간의 시간은 고정되어 있다는 대비로 설명한다. 새로운 경제 이론이라기보다 오래된 attention economy를 2026년의 운영 언어로 다시 정리한 글이다. 글에 실린 광고시장 수치는 작성자가 직접 ‘illustrative’라고 표시한다. 따라서 숫자를 근거로 삼기보다 제작, 배포, 포착, 유지, 전환, 반복이라는 엔진의 모양만 가져오는 편이 안전하다. ## 조회수는 유입을 보여주지만 관계를 보여주지 않는다 조회수는 가장 쉽게 보이는 수치다. 그래서 팀은 제목과 썸네일을 바꾸고, 더 넓은 주제를 고르고, 플랫폼이 좋아하는 형식을 반복한다. 이 선택은 포착에는 도움이 될 수 있다. 하지만 조회수만으로는 독자가 무엇을 얻었는지 알기 어렵다. 10만 명이 3초 머문 콘텐츠와 1만 명이 끝까지 읽고 1천 명이 저장한 콘텐츠는 같은 방식으로 평가할 수 없다. 더구나 다음 주에 아무도 돌아오지 않는다면 높은 조회수는 매번 새 관심을 사야 하는 일회성 재고가 된다. 관계가 생겼다는 신호는 다른 곳에 있다. 완독, 체류, 저장, 직접 검색, 뉴스레터 구독, 재방문, 답장, 다음 글로의 이동이다. 이 지표들은 단순한 노출보다 적지만, 관심이 순간에서 기억으로 바뀌었는지를 보여준다. 문제는 플랫폼이 이 신호를 같은 가치로 취급하지 않는다는 데 있다. 어떤 플랫폼은 시청 시간을, 어떤 플랫폼은 댓글과 공유를, 어떤 검색 표면은 질문에 직접 답하는 구조를 더 강하게 보상한다. 플랫폼은 관심을 배분하는 동시에 어떤 관심이 값비싼지 정한다. ## 캠페인은 사건이고 엔진은 상태 전이다 캠페인은 특정 기간에 메시지와 예산을 집중한다. 신제품 출시, 할인, 보고서 공개처럼 순간적인 주목이 필요한 일에 유용하다. 성공하면 그래프가 가파르게 오른다. 하지만 캠페인이 끝난 뒤 독자가 원래 상태로 돌아가면 다음 캠페인은 다시 0에서 시작한다. 이전의 관심이 다음 행동의 비용을 낮추지 못했기 때문이다. 엔진은 다르다. 콘텐츠 하나가 다음 콘텐츠의 발견 가능성을 높이고, 첫 방문이 구독을 만들고, 구독이 재방문을 만들고, 재방문이 신뢰를 만들며, 신뢰가 구매나 추천으로 이어진다. 한 단계의 출력이 다음 단계의 입력이 된다. 따라서 엔진의 최소 단위는 콘텐츠가 아니라 **독자의 상태 전이**다. 모르는 사람을 알게 된 사람으로, 지나가던 사람을 저장한 사람으로, 저장한 사람을 다시 찾아온 사람으로, 돌아온 사람을 구매한 사람으로 바꾸는 연결이다. ## 관심을 붙잡는 것과 가치를 만드는 것은 다르다 Attention economy는 쉽게 오해된다. 희소한 관심을 차지해야 한다면 더 자극적인 제목, 더 짧은 영상, 더 강한 감정이 답처럼 보인다. 실제로 이런 장치는 포착률을 높일 수 있다. 그러나 포착만 최적화하면 엔진은 중간에서 끊어진다. 약속이 과장된 제목은 클릭을 만들지만 신뢰를 깎고, 불안을 자극하는 콘텐츠는 체류를 만들지만 브랜드를 피로와 연결하며, 끝없는 피드는 시간을 얻지만 구매 이유를 만들지 못한다. 좋은 관심 엔진은 사람을 오래 붙들어 두는 장치가 아니다. **독자가 쓴 시간보다 더 큰 판단 가치나 실행 가치를 돌려주는 장치**다. 그렇다면 콘텐츠를 계속 만드는 팀은 무엇부터 엔진으로 바꿔야 할까. 먼저 더 많은 콘텐츠를 만드는 대신, 이미 만든 콘텐츠 뒤에서 독자가 어디로 이동하는지 본다. 엔진의 병목은 대개 제작량이 아니라 끊어진 연결에 있다. ## 제작, 배포, 포착, 유지, 전환, 반복을 따로 측정한다 DoingSoon이 제시한 여섯 단계는 정교한 이론이라기보다 운영 모델로 쓸 때 유용하다. 각 단계가 서로 다른 질문을 갖기 때문이다. 제작에서는 어떤 콘텐츠가 필요한지 묻는다. 배포에서는 그 콘텐츠가 독자가 있는 곳에 도달하는지 본다. 포착에서는 제목과 첫 화면이 멈춤을 만드는지, 유지에서는 약속한 가치를 실제로 전달해 끝까지 머물게 하는지 확인한다. 전환에서는 다음 행동이 자연스러운지, 반복에서는 그 행동이 다시 관심을 데려오는지 본다. 팀이 “콘텐츠 성과가 나쁘다”고 말할 때는 이 여섯 문제를 하나로 뭉개기 쉽다. 좋은 글인데 배포가 없을 수 있고, 클릭은 많은데 본문이 약할 수 있으며, 완독률은 높은데 다음 행동이 없을 수 있다. 병목이 다른데 제작량만 늘리면 비용만 커진다. 그래서 각 콘텐츠에는 최소한 하나의 역할이 필요하다. 새로운 사람을 데려오는 콘텐츠, 문제를 정확히 이름 붙여 신뢰를 만드는 콘텐츠, 제품과 행동으로 연결하는 콘텐츠, 기존 독자가 다시 돌아올 이유를 만드는 콘텐츠다. 한 편이 모든 역할을 할 필요는 없지만 역할 없이 발행돼서는 안 된다. ## 소유한 관계가 없으면 관심은 계속 임대료를 요구한다 플랫폼에서 얻은 팔로워는 중요한 자산처럼 보인다. 그러나 도달률과 추천 규칙을 플랫폼이 결정하는 한, 그 관계에는 임대 성격이 남는다. 계정이 커도 알고리즘이 바뀌면 같은 사람에게 도달하는 비용이 달라진다. 따라서 관심 엔진은 플랫폼 밖의 직접 관계로 이어져야 한다. 이메일 구독, 직접 방문, 커뮤니티, 제품 계정처럼 독자가 의도적으로 다시 연결할 수 있는 표면이 필요하다. 이것은 모든 독자를 플랫폼 밖으로 빼내라는 뜻이 아니다. 발견은 임대한 배포망을 쓰되, 재방문의 일부는 직접 관계로 바꾸라는 뜻이다. 직접 관계도 소유권이라는 말로 과장해서는 안 된다. 이메일 주소를 가졌다고 관심을 소유하는 것은 아니다. 매번 가치가 없으면 열리지 않는다. 다만 플랫폼의 추천 없이도 다시 대화할 수 있는 권한을 독자가 허락했다는 점에서 더 안정적인 출발점이 된다. ## 반복은 같은 콘텐츠를 재생산하는 일이 아니다 엔진의 마지막 단계인 반복은 흔히 발행 캘린더로 축소된다. 월요일 뉴스레터, 수요일 영상, 금요일 스레드를 계속 올리는 식이다. 일정한 리듬은 기대를 만들 수 있지만, 같은 형식을 반복한다고 엔진이 생기지는 않는다. 진짜 반복은 이전 실행이 다음 실행을 더 낫게 만드는 학습 루프다. 어떤 문장이 저장됐는지, 어느 질문에 답장이 왔는지, 어떤 글을 읽은 사람이 제품 페이지로 이동했는지, 구매 뒤 어떤 문제를 다시 물었는지가 다음 제작의 입력이 된다. 이 데이터가 없으면 팀은 매번 유행하는 주제를 추측한다. 데이터가 있으면 독자가 실제로 다음에 필요로 하는 질문을 쓴다. 콘텐츠는 생산 라인이 아니라 시장을 관찰하는 센서가 된다. ## 모든 관심이 매출로 곧장 이어질 필요는 없다 관심 엔진을 전환 퍼널과 동일시하면 모든 글 끝에 구매 버튼을 붙이게 된다. 그러나 신뢰가 필요한 제품에서 너무 빠른 전환 요구는 오히려 귀환을 막는다. 어떤 콘텐츠의 다음 행동은 저장이면 충분하고, 어떤 글은 관련 개념을 하나 더 읽게 만들면 된다. 깊은 조사 글은 브랜드를 기억하게 하고, 실용적인 글은 다시 검색하지 않아도 되는 효용을 준다. 전환은 구매만이 아니라 관계가 한 단계 깊어진 모든 행동이다. 중요한 것은 다음 단계가 분명한가다. 독자가 좋은 글을 읽고도 무엇을 더 볼지, 왜 구독할지, 어떤 문제를 제품이 해결하는지 알 수 없다면 관심은 만족에서 끝나고 관계로 이어지지 않는다. ## 콘텐츠 전략은 발행 계획이 아니라 귀환 설계가 된다 콘텐츠가 희소하던 시기에는 꾸준히 만드는 것 자체가 경쟁력이었다. 이제 꾸준함은 입장권에 가깝다. AI가 제작량을 평준화할수록 차이는 각 콘텐츠가 다음 관계를 얼마나 잘 만드는지에서 벌어진다. 그래서 기획 회의의 질문도 바뀌어야 한다. 이번 주에 무엇을 몇 개 만들지가 아니라, 어떤 독자를 어떤 상태에서 어떤 상태로 옮길지, 그 이동을 무엇으로 확인할지, 이동한 사람이 왜 다시 돌아올지를 묻는다. 캠페인은 여전히 필요하다. 다만 캠페인의 성공은 피크의 높이만이 아니라 피크가 끝난 뒤 남은 구독자, 직접 방문, 반복 질문, 제품 사용, 추천으로 평가해야 한다. 사건이 엔진에 연료를 남겼는지를 보는 것이다. **콘텐츠를 계속 만드는 사람은 매번 관심을 새로 빌린다. 관심이 돌아오는 회로를 만든 사람은 어제의 관심으로 내일의 관계를 시작한다.** --- 주요 출처: DoingSoon, [The Attention Engine Economy 2026](https://doingsoon.com/newsroom/the-attention-engine-economy/?ref=zerodraftlab.com). 이 글에서 가져온 것은 ‘제작 → 배포 → 포착 → 유지 → 전환 → 반복’이라는 운영 루프입니다. 원문이 illustrative라고 밝힌 광고시장 수치는 근거로 사용하지 않았으며, attention economy 자체를 새로운 이론으로 소개하지 않고 콘텐츠 운영 관점의 재구성으로 다뤘습니다. ### AI 자율성은 종료조건에서 시작된다 URL: https://zerodraftlab.com/ai-autonomy-needs-finish-line/ Last updated: 2026-09-15T08:35:59.000Z 사람들은 AI Agent의 자율성을 얼마나 오래 혼자 일할 수 있는지로 평가한다. 한 시간, 네 시간, 밤새, 며칠. 그러나 오래 움직이는 능력만으로는 좋은 Agent가 되지 않는다. 잘못된 방향으로 오래 달리는 시스템은 더 비싼 오류일 뿐이다. Codex의 Goal이 흥미로운 이유도 “자는 동안 AI가 일한다”는 장면 때문만은 아니다. 더 중요한 변화는 사용자가 다음 지시를 계속 내리는 대신, **무엇이 완료인지 판정할 계약을 먼저 설계한다**는 데 있다. 프롬프트의 시대에는 일을 잘게 나눠 “이것을 해줘”라고 말했다. Goal의 시대에는 “어떤 상태가 참이 될 때까지, 무엇으로 확인하면서, 무엇을 훼손하지 않고 움직일 것인가”를 말한다. ## 프롬프트는 다음 행동을, Goal은 최종 상태를 지정한다 일반 프롬프트는 한 번의 행동에 적합하다. 파일을 설명하고, 작은 버그를 고치고, 문장을 다듬고, 테스트 하나를 추가한다. 요청을 처리한 AI는 결과를 보고하고 멈춘다. Goal은 경로가 아직 확정되지 않은 일에 적합하다. 성능을 측정하고, 병목을 찾고, 수정하고, 다시 측정했는데 목표에 못 미치면 다음 후보를 찾는다. 올바른 다음 행동이 직전 결과에 따라 달라지는 일이다. OpenAI의 공식 설명은 이를 간단히 구분한다. 프롬프트는 “다음 일을 하라”고 말하고, Goal은 “이 결과가 참이 될 때까지 계속하라”고 말한다. Goal이 활성화되면 Codex는 작업 뒤의 증거를 확인하고, 완료되지 않았다면 최신 상태에서 다음 유용한 행동을 고를 수 있다. 여기서 핵심 단어는 ‘계속’이 아니라 ‘참’이다. 무엇이 참이 되어야 하는지 측정할 수 없다면 반복은 진전인지 표류인지 구분할 수 없다. ## 좋은 Goal은 여섯 부분의 완료 계약이다 공식 가이드는 강한 Goal이 보통 여섯 가지를 정의한다고 설명한다. 원하는 결과, 이를 증명할 검증 표면, 유지해야 할 제약, 사용할 수 있는 파일·도구·데이터의 범위, 매 시도 뒤 다음 행동을 고르는 방식, 더 이상 방어 가능한 경로가 없을 때의 중단 조건이다. “성능을 개선하라”는 Goal이 약한 이유는 AI의 능력이 부족해서가 아니다. 개선이 무엇인지, 어느 수치에서 끝나는지, 속도를 얻는 대신 무엇을 망가뜨리면 안 되는지 적혀 있지 않기 때문이다. 반대로 “checkout benchmark의 p95를 120ms 아래로 낮추고 correctness suite를 통과시켜라”는 요청은 종료선을 만든다. 속도가 180ms에서 135ms로 줄어도 끝이 아니다. 110ms가 됐지만 정확성 테스트가 깨져도 끝이 아니다. 벤치마크를 실행할 수 없다면 성공이 아니라 차단 상태다. AI의 자율성은 이 계약 안에서만 유용해진다. 결과가 목표를 만족하는지, 증거가 이를 지지하는지, 제약이 보존됐는지를 매번 비교할 수 있기 때문이다. ## 밤새 돌아간다는 말에는 비용과 권한이 빠져 있다 Lenny’s Newsletter의 Claire Vo 인터뷰는 Goal의 매력을 극적으로 보여준다. Sentry 오류를 줄이고, 3,900개 이메일을 68개로 정리하고, 오래된 Linear 작업을 분류한 사례가 등장한다. 이메일 정리에는 약 네 시간과 600만 토큰이 들었다고 한다. 이 사례는 생산성 자랑보다 운영 경고로 읽는 편이 유익하다. 장시간 자율 작업은 공짜 노동이 아니다. 토큰과 컴퓨팅 비용을 쓰고, 이메일과 이슈 트래커에 접근하며, 경우에 따라 외부 상태를 바꾼다. 시간을 위임할수록 비용 한도와 권한 범위도 함께 위임한다. 따라서 좋은 Goal은 성과 지표만 적지 않는다. 어떤 메일을 지울 수 있는지, 어떤 라벨은 보존해야 하는지, 외부 메시지는 보낼 수 없는지, 몇 회 또는 얼마의 예산 뒤 멈출지까지 포함해야 한다. “깨끗하게 만들어라”는 종료선도 위험하고 권한 경계도 없다. 자율성을 키우는 일은 확인을 모두 없애는 일이 아니다. 되돌릴 수 있는 내부 작업은 넓게 맡기고, 결제·발행·메시지 전송·프로덕션 변경처럼 결과가 외부로 퍼지는 지점은 좁게 통제하는 일이다. ## 완료 증거가 없으면 Agent는 연극을 한다 AI는 그럴듯한 진행 보고를 만들 수 있다. 코드를 읽었고, 문제를 찾았고, 수정했고, 좋아졌다고 설명한다. 하지만 테스트 결과, 벤치마크 수치, 생성된 파일, 외부 시스템의 read-back이 없다면 이것은 완료가 아니라 완료 서사다. Goal의 진짜 가치는 Agent가 계속 일한다는 데 있지 않다. **“아마 됐을 것”을 “증거상 됐다”와 분리하도록 강제하는 데 있다.** 그렇다면 인간의 역할은 지시를 덜 하는 만큼 줄어드는가. 오히려 인간의 역할은 더 앞쪽으로 이동한다. 매 단계의 손놀림을 지시하는 대신, 성공과 실패와 차단을 구분하는 판정 체계를 만든다. ## 관리자는 작업을 배분하는 사람이 아니라 판정 기준을 설계하는 사람이 된다 기존 위임은 대개 절차 중심이었다. 이 파일을 열고, 이 목록을 보고, 이 순서대로 처리하라고 말했다. Agent가 충분히 많은 도구를 다룰 수 있게 되면 절차를 모두 미리 적는 방식은 병목이 된다. 현장에서 새 사실을 발견해도 정해진 순서밖으로 나가기 어렵기 때문이다. Goal 기반 위임은 결과와 판정 기준을 고정하고 경로는 열어둔다. 무엇을 달성할지와 어떤 증거를 믿을지는 인간이 정한다. 어떤 로그부터 볼지, 어떤 가설을 먼저 시험할지, 실패 뒤 무엇을 시도할지는 Agent가 고른다. 이 분업은 인간이 문제를 덜 이해해도 된다는 뜻이 아니다. 좋은 종료선을 만들려면 오히려 시스템의 중요한 속성을 알아야 한다. 속도만 높이면 되는지, 정확성과 비용과 보안 가운데 무엇을 함께 지켜야 하는지, 어느 데이터가 정본인지, 어떤 변화가 되돌릴 수 없는지 알아야 한다. AI가 실행을 싸게 만들수록 무엇을 최적화할지 잘못 고르는 비용은 커진다. 방향이 틀린 자동화는 인간보다 더 빠르게 잘못된 상태를 대량 생산한다. ## 증거는 하나가 아니라 계층으로 설계해야 한다 모든 완료가 테스트 한 줄로 판정되지는 않는다. 코드에는 테스트가 있고 성능에는 벤치마크가 있지만, 연구·정리·운영 작업에는 불완전한 증거가 섞인다. 이때 성공과 실패의 이분법만 두면 Agent는 둘 중 하나를 과장한다. 부분 재현을 완전 재현으로 부르거나, 일부 자료가 없다는 이유로 유용한 결과 전체를 실패로 처리한다. 공식 Goal 가이드의 연구 사례는 이를 주장별 원장으로 해결한다. 무엇을 확인했는지, 어떤 경로로 확인했는지, 증거 표면은 무엇인지, 결과가 정확한 재현인지 근사치인지, 무엇이 여전히 불확실한지 분리한다. 실무에서도 완료 상태는 최소한 네 층으로 나눌 수 있다. 직접 검증된 결과, 대리 지표로만 지지된 결과, 자료 부족으로 막힌 주장, 아직 시도하지 않은 범위다. 이 구분이 있어야 Agent가 솔직하게 오래 일할 수 있다. ## 중단 조건은 실패가 아니라 시스템의 브레이크다 좋은 Goal에는 “될 때까지”뿐 아니라 “언제 멈출지”가 있다. 예산을 소진했을 때, 같은 차단 원인이 반복될 때, 허용된 범위 안에서 더 시도할 경로가 없을 때, 사용자 판단이 없으면 다음 행동의 위험이 급격히 커질 때 멈춘다. 중단 조건이 없으면 끈기는 무한 반복으로 바뀐다. 같은 테스트를 다시 돌리고, 같은 API 오류를 다른 표현으로 해석하고, 성과가 없는 작은 수정만 쌓을 수 있다. 긴 실행에서는 한 번의 잘못보다 멈추지 않는 잘못이 더 비싸다. 예산 한도도 완료와 다르다. 토큰을 다 썼다고 목표를 달성한 것이 아니다. 이때 Agent는 성공을 선언하는 대신 지금까지 바뀐 것, 확인된 증거, 남은 차단, 다음에 필요한 입력을 남겨야 한다. 그래야 다음 실행이 처음부터 다시 시작되지 않는다. ## Goal에 맞지 않는 일도 분명하다 한 줄 수정, 짧은 설명, 간단한 리뷰처럼 한 번에 끝나는 일에는 Goal이 과하다. “코드를 더 좋게 만들어라”, “메일함을 완벽하게 정리하라”처럼 완료선을 합의할 수 없는 일에도 부적합하다. Goal은 큰 일의 동의어가 아니다. **경로는 불확실하지만 종료 상태는 검증 가능한 일**의 도구다. 반대로 경로도 짧고 결과도 분명하면 일반 프롬프트가 낫다. 경로와 결과가 모두 모호하면 먼저 문제를 정의해야 한다. 이 구분 없이 모든 일을 Goal로 만들면 관리 오버헤드가 늘고, 단순한 작업까지 장시간 루프로 변한다. 자율 실행은 많이 쓰는 기술이 아니라 맞는 곳에만 쓰는 기술이다. ## 프롬프트 엔지니어링 다음은 완료 엔지니어링이다 지금까지 사람들은 AI에게 어떻게 말해야 원하는 답이 나오는지 배웠다. 역할을 주고, 맥락을 넣고, 형식을 지정하고, 예시를 제공했다. 이것은 한 번의 출력 품질을 높이는 기술이었다. Agent가 여러 시간에 걸쳐 현실을 바꾸기 시작하면 더 중요한 질문이 생긴다. 어떤 증거가 결과를 참이라고 만들고, 어떤 제약이 함께 보존되어야 하며, 어느 지점에서 더 진행하지 말아야 하는가. 좋은 Goal을 쓰는 사람은 AI에게 일을 많이 시키는 사람이 아니다. 성공을 측정할 표면, 실패를 숨기지 않는 상태, 권한과 비용의 경계를 설계하는 사람이다. **AI의 자율성이 커질수록 인간의 핵심 능력은 지시문 작성에서 완료 판정으로 이동한다. 프롬프트는 일을 시작시키지만, 종료조건은 일을 끝나게 한다.** --- 주요 출처: OpenAI, [Using Goals in Codex: Persistent Objectives for Long-Running Work](https://developers.openai.com/cookbook/examples/codex/using%5Fgoals%5Fin%5Fcodex?ref=zerodraftlab.com); Lenny’s Newsletter, Claire Vo 인터뷰 [The Codex feature that works while you sleep](https://www.lennysnewsletter.com/p/the-codex-feature-that-works-while?ref=zerodraftlab.com). Goal의 기능·수명주기·여섯 구성요소는 OpenAI 공식 문서를 기준으로 했습니다. Sentry·이메일·Linear 사례와 사용량은 인터뷰 당사자의 사례이며 독립 벤치마크로 일반화하지 않았습니다. ### AI에게 인용되려면, 글은 잘 잘려야 한다 URL: https://zerodraftlab.com/ai-citation-needs-chunkable-writing/ Last updated: 2026-09-15T08:36:00.000Z 좋은 글은 처음부터 끝까지 읽히도록 쓴다. 그러나 AI는 꼭 그렇게 읽지 않는다. 질문에 답할 만한 대목을 찾고, 페이지의 일부를 잘라 다른 출처의 일부와 함께 답변으로 조립한다. 여기서 콘텐츠를 만드는 사람은 불편한 선택 앞에 선다. 사람을 위해 서사를 쓸 것인가, 기계가 추출하기 쉬운 문장을 쓸 것인가. 이 선택은 잘못 설정됐다. **AI에게 인용되는 글은 서사를 포기한 글이 아니라, 서사 안에 독립적으로 운반되는 문장을 가진 글이다.** 사람은 글의 흐름을 읽고 관점을 바꾼다. Answer Engine은 질문과 가까운 문장을 찾아 답을 구성한다. 한쪽만 만족시키면 긴 호흡의 에세이는 인용되기 어렵고, 추출만 잘되는 글은 읽을 이유가 없는 정보 조각이 된다. 필요한 것은 둘 중 하나가 아니라 두 개의 해상도를 동시에 설계하는 일이다. ## 형식보다 먼저 질문의 모양을 맞춰야 한다 HubSpot의 2026년 AEO 글은 HubSpot과 Wix Studio의 데이터를 종합해 목록형 글, 설명형 아티클, 제품 페이지가 여러 Answer Engine에서 자주 인용됐다고 정리한다. 플랫폼별 차이도 보였다. HubSpot 데이터에서는 ChatGPT가 비교형 제목을, Google AI Overview와 Gemini가 정의형 제목을, Google AI Mode와 Perplexity가 방법형 제목을 특히 자주 인용했다. 하지만 가장 중요한 결과는 특정 제목 공식이 아니다. Wix Studio가 7만 5천 개 AI 답변과 100만 건이 넘는 인용을 분석했을 때, 어떤 업종인지 또는 어떤 모델인지보다 **사용자가 무엇을 하려는지가 인용되는 콘텐츠 형식을 더 잘 예측했다.** 알고 싶은 사람에게는 설명이 필요하고, 고르려는 사람에게는 비교가 필요하며, 실행하려는 사람에게는 절차가 필요하다. 비교 질문에 장문 에세이로 답하거나, 개념 질문에 제품 목록으로 답하면 문장을 아무리 짧게 잘라도 불리하다. 그러므로 AEO의 첫 단위는 문장 길이가 아니라 질문과 답변 형식의 정합성이다. 제목이 “X와 Y 중 무엇이 나은가”라면 첫 문단에서 누구에게 무엇이 나은지 말해야 한다. “X란 무엇인가”라면 배경 이야기보다 정의가 먼저 와야 한다. “X를 어떻게 하는가”라면 단계의 시작과 끝이 보여야 한다. ## AI는 페이지를 읽기보다 답의 부품을 찾는다 Answer Engine이 긴 글 전체를 하나의 완결된 작품처럼 보존해 답변에 넣는 경우는 드물다. 검색된 문서에서 관련 구간을 찾고, 필요한 주장을 추출하고, 여러 출처를 함께 엮는다. 이 과정에서 문맥에 의존하는 문장은 약해진다. “이것은 앞에서 말한 이유 때문에 중요하다”는 문장은 원문 안에서는 자연스럽다. 그러나 그 문장만 떼면 ‘이것’과 ‘앞에서 말한 이유’가 사라진다. 반대로 “비교형 콘텐츠는 사용자가 선택 기준을 묻는 질문에 직접 답하기 때문에 인용 후보가 된다”는 문장은 혼자서도 주제와 이유를 운반한다. 그래서 짧은 섹션, 명확한 H2와 H3, 표, 수치, 저자와 갱신일이 자주 권장된다. 이것들은 좋은 글을 대신하는 비법이 아니다. 각 주장에 주소를 붙이고, 범위를 표시하고, 출처가 누구인지 알려주는 배관에 가깝다. HubSpot 글도 대부분의 결과가 인용과의 상관관계이지 인과관계가 아니라고 선을 긋는다. FAQ를 붙였기 때문에 인용됐는지, 이미 잘 관리되는 권위 있는 페이지가 FAQ와 저자 정보를 함께 갖췄기 때문에 인용됐는지는 분리하기 어렵다. 게다가 글 후반은 HubSpot의 AEO 제품으로 이어진다. 따라서 체크리스트를 그대로 복제하면 다시 형식 숭배에 빠진다. 일곱 개 이상의 H2, 200단어마다 소제목, 연도형 제목 같은 외형을 맞추는 것보다 먼저 확인할 것은 하나다. **이 페이지에서 잘려 나간 한 문단이 질문 하나에 정확히 답할 수 있는가.** ## 잘 잘리는 글은 잘게 쓴 글이 아니다 문장을 모두 짧게 만드는 것과 독립적으로 이해되는 단위를 만드는 것은 다르다. 전자는 리듬의 문제이고, 후자는 의미의 문제다. 짧은 문장 열 개가 모두 “그것”, “이 문제”, “앞의 사례”에 기대면 추출하기 어렵다. 반대로 조금 긴 문장이라도 주체, 주장, 조건, 근거가 들어 있으면 하나의 인용 단위가 된다. 핵심은 문장 수가 아니라 문맥을 얼마나 스스로 들고 다니는가다. 좋은 청크는 대개 네 가지를 품는다. 무엇에 관한 말인지 드러나는 주체, 무엇이 사실인지 보여주는 주장, 언제 성립하는지 제한하는 조건, 왜 믿을 수 있는지 알려주는 근거다. 모든 문단을 논문 초록처럼 쓰라는 뜻은 아니다. 중요한 판단이 나오는 곳만큼은 이 네 요소가 보이게 해야 한다. 그러면 다음 질문이 생긴다. 모든 문단이 독립적으로 완결되면 글 전체의 긴장과 흐름은 사라지지 않을까. 사라지는 것은 흐름이 아니라 모호한 연결이다. 서사는 문장이 서로 의존해야만 생기는 것이 아니다. 각 문단이 하나의 판단을 완결하면서도 다음 판단을 필요하게 만들 때 더 강한 서사가 생긴다. ## 글 전체는 논증의 사슬, 문단은 증거의 캡슐이다 서사형 글의 최소 단위는 문장이 아니라 변화다. 독자가 처음에 믿던 것과 마지막에 믿게 되는 것 사이에 어떤 이동이 일어났는지가 글의 뼈대다. 각 문단은 그 이동을 한 칸씩 만든다. 예를 들어 이 글의 흐름은 “사람과 AI 중 하나를 골라 써야 한다”에서 시작해 “두 독자는 다른 해상도로 같은 글을 읽는다”로 이동한다. 그 안의 각 섹션은 질문 정합성, 추출 방식, 문맥 독립성이라는 개별 판단을 맡는다. 섹션 하나만 떼도 의미가 있지만, 순서대로 읽으면 더 큰 결론에 도달한다. 이것이 사람과 AI를 동시에 만족시키는 이중 구조다. **거시적으로는 관점을 바꾸는 서사이고, 미시적으로는 출처가 분명한 주장들의 집합이다.** 표와 목록도 같은 원칙으로 써야 한다. 산문을 억지로 표로 바꾸는 것이 아니라 비교해야 할 동일 속성이 있을 때 표를 쓴다. 순서가 결과를 바꿀 때 목록을 쓴다. 정의가 반복해서 오해될 때 한 문장으로 고정한다. 구조는 내용의 모양을 드러내야지, AEO 장식을 붙이는 일이 되어서는 안 된다. ## 직접 답변은 서론을 없애는 일이 아니다 “답부터 쓰라”는 조언은 흔히 배경과 긴장을 모두 버리라는 뜻으로 받아들여진다. 그래서 첫 문단에 요약 상자를 놓고, 본문에서 같은 말을 길게 반복한다. 기계는 답을 찾기 쉬워졌지만 사람에게는 두 번 읽는 글이 된다. 더 나은 방법은 첫 문단에서 결론을 주되, 본문이 그 결론의 의미를 바꾸게 만드는 것이다. 첫 문장은 독자가 얻을 답을 숨기지 않는다. 이후의 서사는 왜 그 답이 직관과 다르고, 어디까지 적용되며, 어떤 반론을 견디는지 보여준다. “AI에게 인용되려면 글은 잘 잘려야 한다”는 문장만으로 핵심은 전달된다. 그러나 무엇을 어떻게 자르는지 모르면 문장 단축과 소제목 증식으로 오해하기 쉽다. 본문은 결론을 미루는 장치가 아니라 결론을 정확하게 만드는 장치다. ## 인용 가능성은 편집 단계에서 검사할 수 있다 초고를 쓸 때마다 기계를 의식하면 문체가 굳는다. 먼저 인간이 끝까지 읽을 수 있는 논증을 만든 뒤, 편집 단계에서 추출 가능성을 점검하는 편이 낫다. 각 H2 아래에서 가장 중요한 문단 하나를 고른다. 그 문단만 복사해도 주제가 보이는지, 대명사가 가리키는 대상이 남아 있는지, 수치의 표본과 시점이 있는지, 관찰과 해석이 구분되는지 확인한다. 답이 아니면 그 문단에 주체와 조건을 되돌려 놓는다. 다음으로 제목이 약속한 의도와 본문 형식을 비교한다. 비교 글이라면 동일 기준으로 나란히 판단했는지, 방법 글이라면 실제 순서와 완료 상태가 있는지, 설명 글이라면 정의와 경계가 있는지 본다. 마지막으로 저자, 갱신일, 원출처, 이해관계를 표시한다. 이 편집은 AI만을 위한 것이 아니다. 사람도 주어가 분명하고, 조건이 보이고, 근거가 가까운 글을 더 쉽게 이해한다. 좋은 AEO가 독자 경험과 충돌하지 않는 이유다. ## 인용되는 문장과 기억되는 서사는 함께 갈 수 있다 AI 시대의 글쓰기가 정보 블록 조립으로만 수렴할 필요는 없다. 사람은 여전히 이야기, 긴장, 반전, 비유를 통해 생각을 바꾼다. Answer Engine이 모든 것을 대신 요약할수록 원문을 끝까지 읽게 만드는 관점과 목소리는 오히려 더 희소해진다. 다만 그 목소리가 불분명함의 면허가 되어서는 안 된다. 멋진 문장 사이에 핵심 판단을 숨기고, 끝까지 읽어야만 주제가 드러나는 글은 인간에게도 불친절하고 AI에게도 인용하기 어렵다. 앞으로 강한 글은 두 번 설계될 것이다. 한 번은 처음부터 끝까지 독자의 생각을 움직이는 흐름으로, 또 한 번은 어느 대목이 잘려도 주체와 조건과 근거를 잃지 않는 단위로. **사람은 서사를 기억하고 AI는 문장을 운반한다. 좋은 콘텐츠는 기억될 흐름 안에 운반될 문장을 심는다.** --- 주요 출처: HubSpot, [The Best On-Page Content Formats for AI, Based on New Data](https://blog.hubspot.com/marketing/content-format-types-that-earn-citations?ref=zerodraftlab.com); Wix Studio AI Search Lab, [The content types most cited by LLMs](https://www.wix.com/studio/ai-search-lab/research/content-types-most-cited-by-llms?ref=zerodraftlab.com). HubSpot 글의 엔진별 수치와 구조 권고는 주로 HubSpot State of AEO 2026과 Wix Studio 연구의 관찰 자료에 기반합니다. 형식과 인용의 상관관계를 인과관계로 해석하지 않았고, HubSpot 제품 홍보가 섞인 실무 체크리스트라는 이해관계를 함께 고려했습니다. ### 직원 0명 회사는 인건비를 없애지 않았다 URL: https://zerodraftlab.com/zero-employee-company-variable-cost/ Last updated: 2026-09-15T08:36:01.000Z AI가 회사를 운영하는 미래를 설명할 때 사람들은 대개 직원 수부터 센다. 직원이 몇 명 줄었는지, 창업자 혼자 어디까지 갈 수 있는지, 기존 조직을 얼마나 작게 만들 수 있는지를 본다. Polsia는 이 상상을 거의 극단까지 밀어붙인 사례다. Polsia 창업자 Ben Cera는 자신이 유일한 직원인 상태에서 회사를 연 환산 매출 1,000만 달러 이상으로 키우고, 2억5,000만 달러 기업가치로 3,000만 달러를 투자받았다고 말한다. 제품 개발, 시장 조사, 고객지원, 환불, 크레딧 지급, 버그 수정, 이메일 응답, 투자자 문의 선별까지 AI 운영체제가 맡는다. 숫자만 보면 인간이 회사에서 퇴장한 것처럼 보인다. 그러나 Polsia가 보여주는 진짜 변화는 사람의 제거가 아니다. **회사를 구성하는 비용과 책임의 재배치**다. ## 회사 자체가 제품의 가장 큰 데모가 됐다 Polsia는 아이디어를 받으면 제품을 만들고, 인프라를 설정하고, 매일 스스로 다음 할 일을 정해 실행하는 AI 운영체제를 판다. Cera는 이 약속을 광고 문구로 설명하지 않았다. 자기 회사를 그 제품으로 운영했다. 투자 유치 과정도 같은 방식으로 설계했다. 고객 수와 성장 지표를 실시간으로 보여주는 공개 대시보드를 만들고, 투자자가 데이터와 리텐션을 질문할 수 있는 채팅을 붙였다. 투자 문의는 AI가 먼저 응대했다. 창업자가 직접 만난 것은 관계와 신뢰가 필요한 일부 투자자뿐이었다. 이 대시보드는 데이터룸인 동시에 유통 채널이었다. 숫자가 오르면 Cera가 그것을 공개했고, 공개된 숫자가 더 많은 대화와 고객을 불렀으며, 늘어난 관심이 다시 숫자를 올렸다. 제품의 자율성을 증명하는 투자 유치 과정이 곧 제품 마케팅이 된 셈이다. 이 구조에서 유통은 제품이 완성된 뒤 붙이는 확성기가 아니다. 제품이 주장하는 미래를 회사가 먼저 연기하고, 그 장면을 시장이 목격하게 만드는 일이다. “AI가 회사를 운영할 수 있다”는 말보다 “이 투자 라운드의 첫 응대를 AI가 하고 있다”는 사건이 더 멀리 퍼진다. ## 직원 0명은 인간 노동 0시간을 뜻하지 않는다 그렇다고 Polsia를 완전히 무인 회사라고 부르면 중요한 사실이 사라진다. Cera는 네 곳의 에이전트 인프라 회사와 상업적으로 협력하며, 이 회사들의 엔지니어가 만든 기술을 Polsia에 연결한다고 설명한다. 정규직 명부에는 한 명만 있어도 회사 바깥의 인간과 공급업체가 사라진 것은 아니다. 창업자 자신도 고객 관계에서 물러나지 않는다. 만난 고객에게 전화번호를 주고, 문제가 생기면 직접 문자를 받는다. AI 지원 시스템은 환불과 버그 보고를 처리하지만, 고객이 느끼는 고통을 창업자가 가까이서 감지하는 통로는 의도적으로 남겨둔다. 따라서 Polsia의 경계는 “AI가 할 일”과 “사람이 할 일” 사이에 그어져 있지 않다. 반복할 수 있고 상태로 기록할 수 있는 업무는 AI에 넘기고, 관계와 신뢰, 예외의 의미, 다음에 무엇을 만들지 같은 고맥락 판단은 창업자가 쥔다. 사람을 없앤 것이 아니라 사람의 시간을 판단 밀도가 높은 지점에 몰아넣었다. 직원 수가 적다는 사실보다 더 중요한 질문은 따로 있다. 반복 업무를 AI에 넘길수록 회사의 원가는 정말 계속 낮아지는가. 그 질문에 대한 Polsia의 답은 뜻밖에도 “아직 그렇지 않다”에 가깝다. Cera는 초기에 AI 작업 한 건의 비용을 1\~1.5달러로 계산했다. 매일 밤 한 건씩 실행하면 한 달에 약 30달러가 들고, 서버와 데이터베이스, 내장 API 비용을 더해 월 49달러 구독료를 정했다. 하지만 고객의 코드베이스가 커지고 에이전트가 어려운 버그를 고치기 위해 더 오래 일하거나 상위 모델을 호출하면서 작업 한 건의 비용이 때로 20\~30달러까지 올라갔다고 한다. 월 구독료의 절반 이상이 예외적인 작업 한 번에 사라질 수 있는 구조다. 이 가격 역전은 AI 회사의 손익계산서를 넘어 회사의 설계 원리까지 바꾼다. 그 변화의 출발점은 인건비가 사라진 자리에 새로운 종류의 원가가 들어온다는 사실이다. ## 인건비가 사라진 자리에 컴퓨트 원가가 들어온다 전통적인 소프트웨어는 사용자가 더 많이 써도 한계비용이 비교적 낮았다. AI 운영체제는 다르다. 더 많은 일을 맡고, 더 긴 맥락을 읽고, 더 어려운 예외를 해결할수록 추론 비용이 늘어난다. 고객이 제품에서 더 많은 가치를 얻는 행동이 공급자의 원가도 동시에 올린다. 이는 “직원 없는 회사”의 경제성을 완전히 다르게 보게 한다. 고정 급여와 채용 비용은 줄어들 수 있지만, 비용 자체가 사라지는 것은 아니다. 대신 토큰, GPU, 모델 라우팅, 재시도, 외부 API, 호스팅이라는 측정 가능한 변동비로 바뀐다. 조직의 레버리지는 커지는 동시에 매출총이익률이 모델 가격과 작업 난이도에 민감해진다. Cera는 에이전트 인프라 회사들과 협력하고 GPU를 직접 빌려 오픈소스 모델을 조정하면서 특정 작업의 비용을 크게 낮췄다고 설명한다. 그러나 이것 역시 공짜 노동의 발견이 아니다. 모델 선택, 인프라 조달, 작업별 라우팅을 제품의 핵심 역량으로 끌어들인 것이다. 사람을 관리하던 회사가 컴퓨트 포트폴리오를 관리하는 회사로 바뀐다. ## 자율성에는 비용 상한선이 필요하다 AI 에이전트는 쉬지 않기 때문에 강력하다. 바로 그 이유로 위험하기도 하다. 사람이 중간에 포기했을 작업을 밤새 계속 시도하면 결과를 만들 가능성은 높아지지만, 실패한 경로에 비용을 계속 태울 가능성도 커진다. 그래서 자율 회사를 만드는 핵심 기술은 에이전트에게 더 많은 권한을 주는 것만이 아니다. 무엇을 완료로 볼지, 한 작업에 얼마까지 쓸지, 언제 더 싼 모델로 충분한지, 어떤 실패에서 멈추고 사람을 부를지를 정하는 운영 규칙이 필요하다. 완료 상태와 비용이 함께 기록되지 않으면 자동화는 생산성을 증명할 수 없다. 일은 끝났지만 고객 한 명의 구독료보다 더 많은 모델 비용을 썼을 수도 있고, 비용은 적게 들었지만 잘못된 환불이나 코드 변경으로 더 큰 손실을 만들 수도 있다. 자율성의 단위는 “AI가 행동했다”가 아니라 **허용된 비용과 위험 안에서 결과를 닫았다**여야 한다. ## 창업자는 사라지는 대신 병목이 된다 Polsia의 1인 구조는 강력한 유통 이야기이기도 하다. Cera 자신도 혼자 남아 있는 것이 회사의 마케팅 서사를 더 극적으로 만든다고 인정한다. 팀을 채용하는 순간 평범한 스타트업이 되지만, 혼자 1,000만 달러 런레이트를 만든다는 이야기는 계속 사람을 불러온다. 그러나 이 서사는 동시에 창업자 집중 위험을 만든다. 관계, 도덕적 판단, 제품 방향, 중요한 예외가 한 사람에게 모인다. 반복 업무는 병렬화되어도 최종 판단은 병렬화되지 않는다. 직원 0명 회사의 다음 병목은 AI의 능력이 아니라 창업자의 주의력과 회복력일 수 있다. 따라서 Polsia에서 복제할 것은 “채용하지 않는다”는 규칙이 아니다. 회사의 반복 운영을 상태와 비용이 보이는 시스템으로 만들고, 인간은 고객의 고통을 직접 느끼며 고맥락 결정을 맡는 분업 구조다. 직원을 줄이는 것은 결과일 수 있지만 목표가 되면 안 된다. Polsia가 보여준 미래는 무인 회사보다 더 현실적이다. **소수의 인간이 관계와 판단을 맡고, AI가 반복 운영을 수행하며, 모든 자율 행동에 원가표가 붙는 회사**다. 이 구조에서 가장 중요한 숫자는 직원 수가 아니다. 고객 결과 한 건을 닫는 데 들어간 총비용과, 그 과정에서 인간이 다시 불려 나온 횟수다. --- 주요 출처: Sophie Buonassisi의 Ben Cera 인터뷰, [Inside the Company That Raised $30M at a $250M Valuation With 0 Employees](https://gtmnow.com/gtm-192-inside-the-company-that-raised-30m-at-a-250m-valuation-with-0-employees-ben-cera-polsia/?ref=zerodraftlab.com), GTMnow Podcast #192\. 매출 런레이트, 투자액, 기업가치, 작업별 비용, 비용 절감 폭은 창업자 인터뷰에 기반한 자기보고이며 독립 검증된 재무 수치로 취급하지 않았습니다. “직원 0명” 역시 정규직 기준 표현으로, 외부 인프라 회사 및 엔지니어와의 협업이 인터뷰에 명시되어 있습니다. ### AI가 제품을 싸게 만들수록, 제품 밖의 해자가 비싸진다 URL: https://zerodraftlab.com/ai-makes-outside-moats-expensive/ Last updated: 2026-09-15T08:36:02.000Z 좋은 제품을 만들면 고객이 따라온다는 믿음은 오랫동안 창업의 기본 문법이었다. 먼저 제품을 만들고, 제품시장적합성(PMF)을 찾고, 그다음 마케팅과 영업으로 확장한다. GTM은 제품이 맞다는 사실이 확인된 뒤 켜는 가속 장치였다. AI는 이 순서를 흔들고 있다. 제품을 만드는 비용만 낮춘 것이 아니라, 잘 팔리는 제품을 따라 만드는 비용까지 낮췄기 때문이다. 기능 하나가 시장의 차이를 만들던 시간은 짧아졌고, 경쟁사가 비슷한 기능을 내놓기까지 걸리는 시간도 함께 줄었다. 이제 먼저 만들었다는 사실만으로 얻는 여유가 오래가지 않는다. > AI가 제품을 싸게 만들수록, 제품 밖의 해자가 비싸진다. GTMfund의 [The Distribution Era](https://gtmnow.com/the-distribution-era/?ref=zerodraftlab.com)는 이 변화를 소프트웨어 해자의 이동으로 설명한다. 한때는 막대한 자본과 기술이 진입장벽이었다. 클라우드는 배포 비용을 낮췄고, SaaS는 판매 방식을 바꿨으며, 제품 주도 성장(PLG)은 제품 자체를 유입 경로로 만들었다. 이제 AI가 제작과 복제의 비용을 낮추면서 희소성은 제품에서 독자, 신뢰, 카테고리로 이동한다는 주장이다. 이 주장의 핵심은 “마케팅이 더 중요해졌다”가 아니다. 제품과 시장의 관계를 만드는 순서가 바뀌었다는 데 있다. ## 제품을 만든 뒤 시장을 찾는 순서가 위험해졌다 제품부터 만드는 회사는 두 개의 가설에 동시에 돈을 건다. 이 문제가 실제로 중요한가. 그리고 우리가 만든 방식이 그 문제를 풀기에 적합한가. 제품이 완성된 뒤 고객을 찾으면 두 가설이 틀렸다는 사실도 늦게 배운다. 반면 독자와 신뢰를 먼저 쌓는 회사는 제품 없이도 시장을 배울 수 있다. 어떤 문제가 반복해서 읽히는지, 어떤 표현에 사람들이 자기 경험을 보태는지, 무엇을 해결해달라는 요청이 들어오는지 관찰한다. 글은 단순한 홍보물이 아니라 문제를 명명하는 도구가 되고, 독자의 반응은 수요에 대한 초기 증거가 된다. HubSpot이 소프트웨어 기능만 판 것이 아니라 ‘인바운드 마케팅’이라는 언어와 교육 체계를 만든 사례가 이를 잘 보여준다. 회사는 이미 존재하던 수요를 찾아간 것이 아니라, 사람들이 자신의 문제를 이해하는 카테고리를 만들었다. 제품은 그 카테고리 안에서 자연스러운 실행 수단이 됐다. 이 순서에서는 GTM이 PMF 이후에 시작되지 않는다. 어떤 독자가 모이는지, 그들이 어떤 문제를 반복해서 말하는지, 어떤 약속에 반응하는지 확인하는 과정 자체가 PMF를 만든다. 제품이 출시된 뒤에도 같은 관계가 새로운 요구와 이탈 신호를 계속 돌려주므로 PMF를 유지하는 장치가 된다. ## 유통은 광고 슬롯이 아니라 축적된 관계다 여기서 유통을 광고비나 팔로어 수로 이해하면 논지가 얕아진다. 돈을 내면 빌릴 수 있는 도달 범위는 자산이지만 해자는 아니다. 경쟁사도 같은 경매에 들어올 수 있기 때문이다. 복제하기 어려운 유통은 누군가의 다음 판단에 반복해서 호출되는 관계다. 특정 문제를 이해하고 싶을 때 먼저 읽는 글, 새로운 도구를 고를 때 참고하는 기준, 아직 완성되지 않은 제품도 시험해볼 만큼 쌓인 신뢰가 여기에 속한다. 독자는 단지 메시지를 받는 사람이 아니라 문제의 언어와 제품의 방향을 함께 만드는 시장의 일부가 된다. 그래서 독자 우선 전략은 출시 전에 이메일 목록을 많이 모으자는 전술과 다르다. 먼저 하나의 문제 영역을 오래 탐구하고, 그 안에서 신뢰할 만한 해석자나 실천자가 되는 전략이다. 제품이 나오기 전에 카테고리와 판단 기준을 만들고, 제품은 이미 형성된 관계 속으로 들어간다. 이 구조가 강한 이유는 코드보다 느리게 쌓이기 때문이다. 기능은 며칠 만에 모방할 수 있어도, 수년 동안 축적된 설명, 사례, 독자의 답장, 실패의 기록, 반복 구매의 신뢰를 한 번에 복제하기는 어렵다. AI가 생산 시간을 압축할수록 시간으로만 살 수 있는 자산의 상대 가격은 올라간다. ## 그러나 유통이 유일한 해자는 아니다 *The Distribution Era*는 유통을 오늘의 해자로 강하게 밀어붙인다. 방향은 맞지만 “유일한 내구적 경로”라는 표현은 과장에 가깝다. 제품 내부의 모든 해자가 사라진 것은 아니다. 경쟁사가 접근할 수 없는 독점 데이터는 모델과 결과를 다르게 만든다. 업무의 핵심 기록과 승인 절차에 깊이 들어간 제품은 교체 비용을 만든다. 사용자가 늘수록 공급과 정보가 좋아지는 네트워크는 여전히 강하다. 규제 승인, 물리 인프라, 브랜드의 안전성처럼 코드 생성만으로 넘을 수 없는 장벽도 남아 있다. 더 정확한 결론은 유통이 다른 해자를 대체했다는 것이 아니다. **제품 기능 하나만으로 해자를 설명하기 어려워졌고, 강한 회사는 제품 밖의 관계와 제품 안의 축적을 연결한다**는 것이다. 독자와 신뢰가 사용자를 데려오고, 사용 과정에서 데이터와 워크플로가 쌓이며, 그 결과가 다시 더 좋은 이야기와 추천을 만든다. 그 연결을 만들려면 독자를 모은 다음 아무 제품이나 투입해서는 안 된다. 글과 제품 사이에 무엇이 있어야 하는지를 더 엄격하게 봐야 한다. 글과 제품 사이에는 반복되는 문제와 유료 검증이 있어야 한다. 독자의 관심은 출발점이지 구매 증거가 아니기 때문이다. 많이 읽힌 글이 곧 좋은 소프트웨어 아이디어라는 보장은 없다. 사람은 흥미로운 설명에는 시간을 쓰지만, 해결이 절실한 문제에만 돈과 업무 방식을 건다. ## 독자가 먼저라는 말은 제품을 늦게 만들라는 뜻이 아니다 독자 우선 전략을 콘텐츠를 충분히 쌓을 때까지 제품 개발을 미루는 방식으로 이해하면 또 다른 함정에 빠진다. 제작 비용이 낮아진 시대에는 작은 도구를 빨리 만드는 일이 오히려 합리적이다. 중요한 것은 제품을 만드는 시점이 아니라 무엇을 근거로 만드는가다. 글에서 반복해서 드러난 문제를 사람이 직접 해결해보고, 누군가 그 해결에 돈을 내며, 해결 과정의 같은 부분이 계속 반복될 때 소프트웨어가 들어갈 자리가 생긴다. 이 순서를 따르면 제품은 창업자의 상상에서 나오지 않는다. 이미 작동하는 관계와 거래에서 잘라낸 반복 작업으로 나온다. 콘텐츠는 문제의 언어를 시험한다. 대화와 서비스는 고통의 강도와 지불 의사를 시험한다. 소프트웨어는 반복되는 해결을 압축한다. GTM은 이 셋을 잇는 피드백 루프다. > 쓴다 → 반응을 본다 → 직접 해결한다 → 돈이 오가는지 확인한다 → 반복되는 부분만 제품으로 만든다 → 결과를 다시 쓴다. 이 루프에서 PMF는 한 번 발견하고 졸업하는 상태가 아니다. 시장의 문제, 제품의 약속, 고객에게 도달하는 방식이 계속 맞물리는 동적 관계다. 독자의 질문이 바뀌면 시장이 움직였다는 신호이고, 사용자의 행동이 바뀌면 제품의 가치가 달라졌다는 신호다. GTM은 그 변화를 가장 먼저 감지하는 감각기관이 된다. ## 카테고리를 가진 회사는 비교 기준을 가진다 독자와 신뢰를 먼저 쌓는 전략의 가장 큰 효과는 잠재고객 수보다 비교 기준에 있다. 시장에서 사용되는 언어를 만든 회사는 고객이 제품을 평가하는 질문에도 영향을 준다. HubSpot이 ‘인바운드’를 설명할수록 기업은 마케팅 자동화 도구를 기능 수만으로 비교하지 않게 됐다. 콘텐츠, 검색, 리드 육성을 하나의 운영 방식으로 보기 시작했다. HubSpot은 그 운영 방식을 실행하는 대표 제품이 됐다. 카테고리를 만든다는 것은 이름을 먼저 붙이는 행위가 아니라, 무엇이 좋은 해결책인지 평가하는 기준을 배포하는 일이다. 이 힘은 AI 시대에 더 커진다. 비슷한 기능을 가진 제품이 빠르게 늘어날수록 고객은 모든 제품을 직접 비교할 수 없다. 익숙한 카테고리, 신뢰하는 해석자, 이미 배운 판단 기준을 통해 선택을 압축한다. 제품이 복제될수록 선택을 돕는 설명의 가치가 커진다. 하지만 카테고리만 만들고 제품이 약하면 신뢰는 오래가지 않는다. 유통은 나쁜 제품을 영구히 구하는 마법이 아니다. 첫 구매를 앞당길 수는 있어도 반복 사용과 추천을 대신하지 못한다. 강한 유통은 제품 품질의 대체재가 아니라 더 빠르고 더 냉정한 검증 장치다. 약속과 실제 결과의 차이가 기존 독자에게 곧바로 드러나기 때문이다. ## 가장 강한 해자는 순환한다 유통, 독점 데이터, 워크플로 잠금, 네트워크 효과를 서로 경쟁하는 후보처럼 볼 필요는 없다. 실제로 강한 사업에서는 하나가 다음 것을 만든다. 신뢰받는 콘텐츠가 첫 사용자를 데려온다. 사용자는 제품 안에서 고유한 데이터와 작업 맥락을 만든다. 제품이 핵심 업무에 들어가면 전환비용이 생긴다. 더 많은 사용과 사례는 제품을 개선하고, 그 결과는 다시 더 설득력 있는 콘텐츠와 추천이 된다. 유통이 제품 사용을 만들고, 제품 사용이 새로운 해자를 만들며, 그 해자가 다시 유통을 강화한다. 반대로 이 순환이 없으면 각각은 쉽게 약해진다. 독자만 있고 유료 문제를 찾지 못하면 미디어는 관심을 수익으로 바꾸지 못한다. 제품만 있고 관계가 없으면 기능 경쟁과 광고 경매에 갇힌다. 데이터가 있어도 고객 결과를 개선하지 못하면 저장 비용일 뿐이다. 워크플로 잠금이 가치보다 불편에 기대면 고객은 탈출할 기회만 기다린다. 따라서 AI 시대의 해자는 하나의 물건이 아니라 학습 속도의 구조에 가깝다. 누가 더 많은 신뢰를 얻고, 더 빨리 실제 문제를 발견하며, 더 작은 제품으로 검증하고, 사용 결과를 다시 시장의 언어로 돌려보내는가. 이 순환은 개별 기능보다 복제하기 어렵다. ## Zero Draft Lab이 글부터 시작하는 이유 Zero Draft Lab이 먼저 글과 독자를 쌓고 나중에 소프트웨어를 붙이려는 이유도 여기에 있다. 글은 완성된 제품을 알리는 채널이 아니라 어떤 문제가 반복되고 어떤 언어가 사람의 판단을 바꾸는지 확인하는 연구 표면이다. 다만 글에서 곧장 앱으로 점프해서는 안 된다. 독자의 반응 중 실제 업무의 고통으로 이어지는 것을 고르고, 먼저 수작업으로 해결하며, 유료 거래가 생기고, 같은 해결이 반복될 때만 소프트웨어로 압축해야 한다. 그래야 제품은 콘텐츠 사업 옆에 붙인 장식이 아니라 축적된 시장 이해의 결과가 된다. 이때 ZDL의 자산은 글의 개수만이 아니다. 문제를 설명하는 언어, 어떤 주장에 독자가 반응했는지에 대한 기록, 실제 적용에서 나온 반례, 유료로 해결한 과정, 제품 사용 데이터가 함께 쌓인다. 경쟁자는 화면과 기능을 복제할 수 있어도 이 전체 계보를 한 번에 가져갈 수 없다. *The Distribution Era*의 가장 쓸모 있는 통찰은 “제품보다 마케팅이 중요하다”는 구호가 아니다. 제품을 만들기 전에 시장과 관계를 맺고, 제품을 만든 뒤에도 그 관계로 PMF를 계속 갱신해야 한다는 운영 원리다. AI는 제품을 만드는 사람을 크게 늘린다. 그래서 제품이 사라지는 것이 아니라 제품만으로 설명되지 않는 회사가 강해진다. 앞으로 비싸지는 것은 코드가 아니라 신뢰를 얻는 시간, 문제를 명명하는 언어, 실제 사용에서 쌓인 맥락, 그리고 이 모든 것을 다음 제품으로 연결하는 순환이다. **AI가 제품을 싸게 만들수록, 승자는 제품을 가장 빨리 만든 회사가 아니라 시장이 무엇을 필요로 하는지 가장 오래, 가장 가까이서 배운 회사가 된다.** --- 주요 출처: Max Altschuler·Paul Irving, [The Distribution Era](https://gtmnow.com/the-distribution-era/?ref=zerodraftlab.com). 소프트웨어 해자의 시대별 이동, audience-first, GTM이 PMF를 만들고 유지한다는 논지는 해당 글을 바탕으로 했습니다. 유통을 유일한 해자로 보지 않고 독점 데이터, 워크플로 전환비용, 네트워크 효과, 규제 장벽과 결합된 순환 구조로 해석한 부분과 Zero Draft Lab에 대한 적용은 이 글의 분석입니다. ### Agent-ready 웹의 출발점은 llms.txt가 아니라 접근성이다 URL: https://zerodraftlab.com/agent-ready-web-starts-with-accessibility/ Last updated: 2026-09-15T08:36:02.000Z AI Agent가 웹에서 항공권을 찾고, 회의 일정을 잡고, 상품을 주문하는 장면이 가까워지면서 새로운 최적화 시장도 열리고 있다. 검색엔진에 잘 보이는 웹을 넘어 Agent가 잘 읽고 사용할 수 있는 웹을 만들어야 한다는 주장이다. 그러자 익숙한 처방이 반복된다. 사이트 루트에 `llms.txt`를 놓고, AI가 읽기 좋은 요약을 만들고, Agent 전용 인터페이스를 붙이라는 조언이다. 모두 쓸모가 있을 수 있다. 하지만 파일 하나를 추가한다고 사람이 쓰기 어려운 웹이 Agent에게 갑자기 명확해지는 것은 아니다. **Agent-ready 웹의 출발점은 AI를 위한 새 문서가 아니라, 이미 화면에 있는 요소의 이름과 역할과 상태를 기계가 정확히 알 수 있게 만드는 접근성이다.** ## Agent는 화면을 보면서도 우리처럼 보지 않는다 사람은 픽셀 사이의 관계를 빠르게 추론한다. 돋보기 모양은 검색이고, 오른쪽 위의 작은 엑스는 창을 닫으며, 회색 버튼은 지금 누를 수 없다고 짐작한다. 입력창 옆에 글자가 놓여 있으면 별도 연결 정보가 없어도 그 글자를 입력 항목의 이름으로 받아들인다. 브라우저 Agent는 이런 시각적 단서만 이용하지 않는다. Chrome의 Lighthouse Agentic Browsing 문서는 Agent가 접근성 트리를 주된 데이터 모델로 사용한다고 설명한다. 브라우저는 HTML을 바탕으로 각 요소의 이름, 역할, 상태와 관계를 별도의 구조로 만든다. 스크린리더가 화면을 이해하는 바로 그 구조다. 따라서 화면에는 그럴듯해 보여도 접근성 트리에는 뜻이 없는 인터페이스가 문제가 된다. 클릭 이벤트만 붙인 `div`, 이름 없는 아이콘 버튼, `placeholder`에만 의존한 입력창, 키보드로 도달할 수 없는 메뉴, 상태 변화를 기계에 알리지 않는 알림창이 대표적이다. 사람은 주변 문맥으로 빈칸을 채우지만 Agent는 여러 행동 후보 중 하나를 추측해야 한다. 이 지점에서 접근성은 별도의 복지 항목이 아니라 인터페이스의 진실성 문제가 된다. 버튼은 버튼이어야 하고, 입력 항목에는 연결된 이름이 있어야 하며, 선택 여부와 오류 상태가 프로그램적으로 드러나야 한다. W3C도 가능한 경우 네이티브 HTML의 `label` 같은 의미 구조를 먼저 사용하라고 권한다. 이런 표시는 스크린리더 사용자와 음성 입력 사용자뿐 아니라 화면을 기계적으로 해석하는 Agent에게도 같은 단서를 제공한다. ## `llms.txt`는 안내판이지 조작 장치가 아니다 Lighthouse 13.3에는 Agentic Browsing 범주가 기본 설정에 추가됐다. 현재 이 범주는 0점부터 100점까지의 성숙도 점수를 매기지 않는다. 관련 표준이 아직 형성 중이기 때문에 접근성 트리, 화면 안정성, `llms.txt`, WebMCP 도구 등록 같은 결정적 검사를 통과했는지 보여주는 실험적 신호에 가깝다. Chrome 150 이상이 필요하고 WebMCP 검사에는 origin trial 등록도 필요하다. 이 검사 항목을 같은 층의 기능으로 보면 안 된다. `llms.txt`는 사이트가 무엇이고 어떤 자료가 중요한지 알려주는 정리된 안내판이다. 접근성 트리는 현재 페이지에서 무엇을 읽고 누를 수 있는지 보여주는 기계의 시야다. WebMCP는 웹 애플리케이션의 기능을 이름, 설명, 입력 schema를 가진 도구로 노출하려는 실행 인터페이스다. 즉 Agent-ready 웹에는 적어도 세 단계가 있다. 사이트를 발견하고 방향을 잡는 것, 화면의 의미를 이해하는 것, 사용자를 대신해 행동하는 것이다. 첫 단계의 파일을 잘 만들었다고 나머지 두 단계가 해결되지는 않는다. 메뉴 이름이 모호하고 폼의 오류를 찾을 수 없다면 Agent는 사이트 소개를 읽은 뒤에도 일을 끝내지 못한다. 그래서 가장 오래가는 투자는 화려한 Agent 전용 기능보다 의미 있는 HTML, 정확한 라벨, 예측 가능한 포커스, 명시적인 상태와 오류다. 이것은 특정 모델이나 새 표준이 사라져도 사람과 자동화 모두에게 남는다. AI 시대의 웹 최적화가 접근성에서 시작한다는 말은 Agent를 위해 인간을 뒤로 미루자는 뜻이 아니다. 인간을 위해 정직하게 만든 인터페이스가 기계에도 가장 덜 모호하다는 뜻이다. 하지만 Agent가 화면을 정확히 이해하게 된 다음에는 더 어려운 질문이 생긴다. **이해할 수 있다는 사실만으로, 사용자를 대신해 행동해도 되는가.** 그 질문이 중요한 이유는 웹을 읽는 순간과 웹에서 상태를 바꾸는 순간의 책임이 완전히 다르기 때문이다. 가격을 잘못 읽으면 비교 결과가 틀린다. 반면 주문 버튼을 잘못 해석하면 결제가 일어나고, 공개 범위를 잘못 이해하면 비공개 자료가 외부로 나간다. ## Agent-ready의 진짜 난제는 인식보다 의도다 사람이 웹을 사용할 때 클릭은 어느 정도 의도의 증거로 취급된다. 결제 화면을 보고 마지막 버튼을 직접 누르면 서비스는 사용자가 거래를 승인했다고 판단한다. Agent가 끼어들면 이 연결이 느슨해진다. 사용자가 “가장 싼 옵션을 알아봐”라고 말했는데 Agent가 비교만 해야 하는지, 장바구니에 담아도 되는지, 실제 결제까지 해도 되는지는 화면 요소만으로 결정할 수 없다. WebMCP는 이런 웹 기능을 자연어 설명과 구조화된 입력을 가진 도구로 노출하려는 제안이다. Agent가 픽셀 위치를 추측해 버튼을 누르는 대신 `search-products`나 `reserve-seat`처럼 이름 붙은 기능을 호출할 수 있다. 실행 가능성을 높이는 방향이지만, 도구의 이름이 실제 효과를 보증하지는 않는다. 2026년 7월 현재 WebMCP 문서는 W3C 표준이나 Standards Track 문서가 아닌 Community Group 초안이다. 초안 자체도 도구의 설명과 실제 동작이 일치하는지 Agent가 실행 전에 검증할 장치가 없다고 지적한다. 예를 들어 “장바구니를 최종화한다”는 도구가 단순히 최종 화면을 보여주는지 실제 구매를 일으키는지 자연어만으로는 모호할 수 있다. 로그인된 브라우저 세션을 그대로 사용하는 도구라면 구매, 계정 변경, 데이터 공유와 삭제까지 높은 권한의 행동으로 이어질 수 있다. 따라서 Agent용 도구를 많이 공개하는 것보다 행동의 경계를 정확히 설계하는 일이 먼저다. 검색과 조회처럼 상태를 바꾸지 않는 행동, 임시 저장처럼 되돌릴 수 있는 행동, 결제와 발행처럼 외부 효과가 생기는 행동은 같은 호출로 뭉치면 안 된다. 사용자의 넓은 요청을 Agent가 곧바로 최종 실행 권한으로 해석하지 않도록, 미리보기와 확정 사이에 명시적인 경계가 필요하다. ## 좋은 도구 설명보다 실제 효과의 일치가 중요하다 Agent 인터페이스는 기존 UI 위에 친절한 자연어 설명을 붙이는 작업으로 끝나지 않는다. 설명, 입력 schema, 권한, 검증 로직, 실제 부작용이 하나의 계약처럼 일치해야 한다. 읽기 전용이라고 표시한 도구가 로그를 남기는 수준을 넘어 외부 상태를 바꾸거나, 선택 사항처럼 보이는 입력값으로 개인정보를 과도하게 요구한다면 Agent가 이해하기 쉬울수록 오히려 위험은 커진다. WebMCP 초안은 이 문제를 과도한 매개변수를 통한 개인정보 유출 위험으로도 다룬다. 사이트가 세분된 입력값을 많이 요구할수록 도움이 되려는 Agent는 개인화 맥락, 방문 기록, 다른 사이트에서 얻은 정보까지 채워 넣을 수 있다. 사람에게 긴 폼을 보여주면 수상함을 느낄 항목도 Agent 호출 안에서는 편의를 위한 schema처럼 보일 수 있다. 여기서 좋은 Agent 인터페이스의 기준이 드러난다. 일을 끝내는 데 필요한 최소 정보만 받고, 실행 전에 바뀔 상태를 보여주며, 결과에는 무엇이 실제로 일어났는지 확인할 수 있는 식별자와 영수증을 돌려줘야 한다. 실패도 “오류가 발생했습니다”가 아니라 어떤 전제조건이 맞지 않았고 상태가 바뀌었는지 아닌지를 구분해 알려야 한다. 그래야 Agent가 재시도할지, 사람에게 넘길지, 이미 끝난 일을 중복 실행하지 않을지 판단할 수 있다. ## 전용 도구는 두 번째 권한 경로가 될 수 있다 “어차피 브라우저 Agent는 기존 버튼도 누를 수 있으니 전용 도구를 제공하는 편이 더 안전하지 않은가”라는 반론은 타당하다. 실제로 명확한 이름과 schema를 가진 도구는 좌표 기반 조작보다 예측 가능할 수 있다. WebMCP 초안도 웹 기능 자체가 이미 UI에 존재한다면 도구가 완전히 새로운 기능을 만드는 것은 아니라고 설명한다. 다만 UI 조작과 도구 호출이 서로 다른 코드 경로를 지나면 검증 규칙도 달라질 수 있다. 사람용 결제 화면에는 금액 확인과 재인증이 있는데 Agent용 호출에는 빠져 있다면, 편의를 위해 만든 지름길이 더 높은 권한의 우회로가 된다. Agent용 표면은 기존 보안과 승인 절차를 생략하는 API가 아니라, 같은 규칙을 더 명시적으로 표현하는 또 하나의 인터페이스여야 한다. 이 때문에 모든 사이트가 지금 WebMCP를 붙여야 한다는 결론도 성급하다. 정보 제공 사이트라면 먼저 의미 있는 문서 구조와 접근성, 안정적인 URL, 정확한 원문을 갖추는 편이 낫다. 예약·구매·업무처리처럼 Agent가 실제 상태를 바꿀 가치가 큰 서비스라면 제한된 읽기 기능부터 실험하고, 권한과 확인, 중복 실행 방지, 감사 기록이 준비된 행동만 단계적으로 열어야 한다. ## AI SEO와 Agent-ready 웹은 다른 사업 문제다 AI SEO의 질문은 “답변을 만드는 모델이 우리 사이트를 발견하고 인용할까”에 가깝다. Agent-ready 웹의 질문은 “사용자의 목적을 정확히 이해하고, 허용된 범위 안에서 일을 끝내며, 결과를 증명할 수 있을까”다. 전자는 유통과 발견의 문제이고 후자는 제품과 운영, 보안의 문제다. 이 차이를 놓치면 마케팅팀이 `llms.txt`를 만든 뒤 사이트가 Agent-ready가 됐다고 선언한다. 그러나 Agent는 회사 소개를 잘 읽으면서도 이름 없는 버튼 앞에서 멈추고, 오류 상태를 놓치고, 모호한 확정 기능으로 원치 않는 거래를 만들 수 있다. 안내판은 생겼지만 건물의 문과 엘리베이터와 비상구는 여전히 알 수 없는 셈이다. 앞으로 웹사이트의 품질은 사람에게 얼마나 설득력 있게 보이는지만으로 평가되지 않을 것이다. 기계가 의미를 오해하지 않는지, 행동의 부작용이 명시됐는지, 사용자의 권한을 넘지 않는지, 실행 뒤 무엇이 일어났는지 증명할 수 있는지가 함께 제품 품질이 된다. **`llms.txt`는 Agent에게 현관의 위치를 알려줄 수 있다. 그러나 문손잡이의 의미를 만들고, 들어갈 권한을 확인하고, 안에서 벌어진 일을 책임지는 것은 결국 웹 제품의 설계다.** --- 주요 출처: [TLDR Marketing 2026-06-03](https://tldr.tech/marketing/2026-06-03?ref=zerodraftlab.com); Chrome for Developers의 [Lighthouse Agentic Browsing scoring](https://developer.chrome.com/docs/lighthouse/agentic-browsing/scoring?ref=zerodraftlab.com); GoogleChrome Lighthouse [v13.3.0 release](https://github.com/GoogleChrome/lighthouse/releases/tag/v13.3.0?ref=zerodraftlab.com); W3C Web Machine Learning Community Group의 [WebMCP Draft Community Group Report](https://webmachinelearning.github.io/webmcp/?ref=zerodraftlab.com); W3C WAI의 [Labeling Controls](https://www.w3.org/WAI/tutorials/forms/labels/?ref=zerodraftlab.com). Lighthouse Agentic Browsing과 WebMCP는 2026년 7월 현재 실험적 기능 및 제안 단계입니다. 접근성·행동 경계·승인·감사 기록을 하나의 Agent-ready 제품 설계로 연결한 부분은 이 글의 분석입니다. ### 미디어는 콘텐츠 사업이 아니라 제품 R&D 조직이다 URL: https://zerodraftlab.com/media-is-product-r-and-d/ Last updated: 2026-09-15T08:36:03.000Z 대부분의 회사에서 글은 제품이 나온 뒤에 시작된다. 제품팀이 만들고, 마케팅팀이 설명하며, 영업팀이 판다. 미디어는 이미 결정된 것을 시장에 전달하는 마지막 확성기다. Every는 이 순서를 뒤집는다. 글을 제품의 홍보물이 아니라 제품이 태어나는 장소로 쓴다. Every의 CEO Dan Shipper가 공개한 [Master Plan Part II](https://every.to/on-every/every-s-master-plan-part-ii?ref=zerodraftlab.com)에 따르면, 이 회사는 정규직 15명으로 일간 뉴스레터와 AI 제품 4개, 컨설팅 조직을 함께 운영한다. 겉으로 보면 서로 집중력을 빼앗는 세 사업을 한 회사에 억지로 넣은 것처럼 보인다. 실제로는 하나의 순환 구조다. > 미래를 먼저 살아본다. 관찰한 것을 쓴다. 부족한 것을 만든다. 효과가 검증된 것을 가르친다. 이 네 문장이 중요한 이유는 미디어, 소프트웨어, 컨설팅의 역할을 각각 다시 정의하기 때문이다. 미디어는 유입 채널이 아니다. 소프트웨어는 별도의 사업부가 아니다. 컨설팅은 시간을 팔아 현금을 버는 부업이 아니다. 셋은 같은 문제를 서로 다른 해상도로 관찰하는 하나의 연구 시스템이다. ## 글은 제품보다 먼저 나오는 연구 결과다 Every의 팀은 AI가 바꿀 미래를 예측하는 데서 멈추지 않는다. 글쓰기, 편집, 코딩, 디자인, 운영에 AI를 먼저 써본다. 새로운 도구가 실제 업무를 어떻게 바꾸는지 자기 손으로 겪는다. 이 과정에서 아직 이름 붙지 않은 불편과 새로운 작업 방식이 나온다. 그다음 그것을 쓴다. 여기서 글쓰기는 이미 아는 것을 포장하는 일이 아니다. 흐릿한 경험에 이름을 붙이고, 팀이 함께 검토할 수 있는 가설로 만드는 일이다. 독자는 그 글을 읽고 반응한다. 어떤 문제에 공감하는지, 어떤 표현을 기억하는지, 어디에서 돈을 낼 의향을 보이는지가 드러난다. 즉 글 한 편이 세 가지 일을 동시에 한다. 내부 경험을 정리하고, 시장의 언어를 만들고, 수요를 시험한다. 일반적인 제품 개발에서는 이 과정이 비용이다. 사용자 조사에 돈을 쓰고, 프로토타입을 만들고, 인터뷰를 진행한 뒤에도 시장이 원하는지 확신하기 어렵다. Every에서는 같은 실험이 유료 콘텐츠가 된다. 연구하는 동안 독자가 생기고, 연구 결과를 설명하는 동안 매출이 생긴다. 연구개발이 비용 센터가 아니라 수익 센터가 되는 이유다. ## 내부 도구가 제품이 되는 데는 중간 문턱이 있다 그렇다고 팀에서 만든 모든 자동화를 제품으로 출시하는 것은 아니다. Every의 제품은 개인의 사이드 프로젝트나 내부 문제를 해결하는 작은 실험으로 시작한다. 먼저 만든 사람이 쓰고, 자연스럽게 다른 팀원에게 퍼지는지 본다. 팀 안에서도 반복 사용되지 않는 도구라면 독자에게 팔 이유가 없다. 이 내부 확산은 작은 시장 검증이다. 설문에서 “쓸 것 같다”는 답을 받는 대신 실제 업무에서 동료가 계속 쓰는지 본다. 한 명의 취향에 맞춘 장난감이 여러 사람의 습관으로 바뀌는 순간, 외부 제품이 될 자격을 얻는다. Every의 Cora, Sparkle, Spiral, Monologue는 각각 이메일, 파일 정리, 글쓰기, 음성 입력을 다룬다. 기능만 보면 서로 다른 앱이다. 하지만 모두 같은 연구 환경에서 발견된 문제의 결과물이다. 뉴스레터 독자는 제품의 첫 사용자가 되고, 제품 사용자는 다음 글이 다룰 문제를 만든다. ## 컨설팅은 루프의 끝이 아니라 현실 검증 장치다 컨설팅도 같은 구조 안에 있다. Every는 자신들이 먼저 써보고 효과를 확인한 AI 작업 방식을 기업에 가르친다. 이 사업은 당장의 현금흐름을 만든다. 동시에 작은 AI 네이티브 팀에서는 보이지 않던 대기업의 실제 제약을 보여준다. 보안, 승인, 기존 시스템, 직무 경계, 데이터 품질, 변화에 대한 저항은 뉴스레터 독자의 반응만으로 알기 어렵다. 컨설팅 현장에 들어가면 “AI를 어떻게 써야 하는가”보다 “왜 여기서는 AI가 작동하지 않는가”가 선명해진다. 그 실패가 다음 글의 소재가 되고, 다음 제품이 해결할 문제로 돌아온다. 그래서 Every의 구조를 단순히 미디어 회사가 소프트웨어와 컨설팅으로 수익원을 다각화한 사례로 보면 핵심을 놓친다. 세 사업은 서로의 매출을 보충하는 포트폴리오가 아니다. **관찰, 언어화, 도구화, 현장 검증을 반복하는 하나의 R&D 루프**다. 이 관점에서 미디어의 가장 중요한 산출물은 조회수도 구독자 수도 아니다. 다음 제품을 만들 만큼 정확하게 정의된 문제다. 그 문제가 계속 제품으로 이어지려면, 글을 잘 쓰는 것만으로는 부족하다. Every의 루프에는 쉽게 보이지 않는 네 가지 조건이 깔려 있다. ## 첫째, 팀이 독자보다 먼저 미래를 살아야 한다 관찰은 간접 취재만으로 생기지 않는다. 팀의 실제 업무가 실험실이어야 한다. AI에 관한 글을 쓰면서 정작 편집과 운영은 과거 방식 그대로 한다면, 글은 남의 발표를 요약하는 수준을 벗어나기 어렵다. Every가 말하는 “미래를 산다”는 태도는 최신 도구를 모두 써본다는 뜻이 아니다. 업무의 중요한 부분을 새로운 방식에 실제로 걸고, 실패 비용까지 감수한다는 뜻이다. 그래야 기능 목록이 아니라 작업 방식의 변화가 보인다. 무엇이 빨라졌는지뿐 아니라 병목이 어디로 이동했는지, 사람의 판단이 더 중요해진 지점이 무엇인지 쓸 수 있다. 좋은 미디어 R&D는 관찰자와 사용자가 분리되지 않는다. 자기 문제가 아닌 것을 계속 설명하는 미디어는 제품 아이디어를 많이 만들 수는 있어도 강한 제품을 만들기는 어렵다. ## 둘째, 글은 홍보물이 아니라 반증 가능한 가설이어야 한다 콘텐츠가 제품 R&D가 되려면 “AI가 세상을 바꾼다” 같은 넓은 전망보다 구체적인 작업 가설을 내놓아야 한다. 누가 어떤 상황에서 무엇 때문에 막히며, 지금의 대안은 왜 부족한지 드러나야 한다. 그렇게 쓴 글은 반응의 질도 달라진다. 독자는 단순히 좋아요를 누르는 대신 자신의 사례를 보태고, 반례를 들고, 이미 돈을 쓰는 대안을 말한다. 댓글, 답장, 구독 전환, 상담 문의가 모두 같은 가설에 대한 서로 다른 증거가 된다. 반대로 제품을 정해놓고 그 필요성을 설득하기 위해 글을 쓰면 루프는 닫힌다. 콘텐츠는 수요를 발견하지 못하고 이미 내린 결정을 정당화한다. 연구처럼 보이지만 광고에 가깝다. ## 셋째, 내부 확산과 외부 판매 사이를 건너뛰지 않아야 한다 AI로 소프트웨어를 싸게 만들 수 있게 되면서 아이디어를 바로 앱으로 만드는 유혹이 커졌다. 그러나 만드는 비용이 낮아졌다고 유지와 유통의 비용까지 사라진 것은 아니다. 내부에서 한 번도 습관이 되지 못한 도구를 외부에 출시하면, 팀은 제품의 고객이 아니라 제품을 살리기 위한 운영자가 된다. Every의 내부 확산 문턱은 이 위험을 줄인다. 만든 사람 외의 동료가 자발적으로 쓰고, 반복 사용하며, 없으면 불편해질 때까지 기다린다. 이 과정은 거창한 제품 심의보다 단순하지만 훨씬 냉정하다. 팀이라는 작은 시장에서도 살아남지 못한 기능을 큰 시장에 떠넘기지 않는다. ## 넷째, 번들은 할인 묶음이 아니라 공유 맥락이어야 한다 Every는 여러 AI 앱과 콘텐츠를 하나의 구독으로 묶는다. 지금도 한 가격으로 네 앱을 쓸 수 있지만 장기적인 해자는 앱 개수에 있지 않다. 사용자의 허락 아래 각 앱에서 생긴 기억과 맥락이 다른 앱으로 흐르는 플랫폼 층을 만들려 한다. 읽은 뉴스레터의 맥락이 글쓰기 도구로 이어지고, 파일 이름에서 배운 어휘가 음성 입력을 개선한다면 각 제품은 독립 앱일 때보다 함께 있을 때 더 유용해진다. 새 앱이 하나 추가될 때 기능 하나만 늘어나는 것이 아니라, 기존 앱이 이해할 수 있는 사용자의 맥락도 늘어난다. 이때 번들은 단순한 가격 할인에서 생태계로 바뀐다. 개별 앱의 기능은 복제할 수 있어도 콘텐츠가 만든 세계관, 독자와의 유통 관계, 여러 제품에 축적된 맥락, 현장에서 얻은 문제 데이터까지 한꺼번에 복제하기는 어렵다. 소프트웨어가 싸질수록 코드 밖의 연결 구조가 더 비싼 자산이 된다. ## Supple과 Zero Draft Lab이 가져와야 할 것은 제품 목록이 아니다 Every의 겉모습을 따라 하면 뉴스레터 옆에 AI 앱 몇 개와 컨설팅 메뉴를 붙이게 된다. 그것은 순환 구조가 아니라 사업 세 개의 동거다. 우리가 가져와야 할 것은 무엇을 만들었는지가 아니라 무엇이 다음 일을 낳는가라는 운영 원리다. Supple과 Zero Draft Lab에서 글은 독자를 모으는 끝점이 아니라 문제를 명명하는 시작점이어야 한다. 실제 업무에서 먼저 써본 방법을 쓰고, 독자의 반응에서 반복되는 고통을 찾고, 수작업 서비스로 그 고통이 돈을 낼 만큼 큰지 확인한 뒤, 반복되는 부분만 소프트웨어로 만든다. 그 제품을 사용하며 생긴 새로운 관찰은 다시 글로 돌아온다. 여기서 가장 위험한 단절은 글에서 곧바로 앱으로 점프하는 것이다. 그 사이에는 반드시 실제 적용과 유료 검증이 있어야 한다. 컨설팅이나 소규모 서비스가 중요한 이유도 여기에 있다. 확장성은 낮지만 문제를 가장 가까이에서 보고, 고객이 말하는 요구와 실제로 막히는 지점의 차이를 발견할 수 있다. 따라서 이 모델의 최소 단위는 미디어, 소프트웨어, 컨설팅이라는 세 사업부가 아니다. 하나의 문제를 둘러싼 다음 순환이다. > 직접 겪는다 → 정확히 쓴다 → 사람이 돈을 내고 해결을 맡기는지 본다 → 반복되는 해결을 도구로 만든다 → 결과를 다시 쓴다. 이 순환이 돌지 않는다면 미디어는 콘텐츠 공장이고, 컨설팅은 외주이며, 소프트웨어는 사이드 프로젝트다. 순환이 돌기 시작하면 셋은 서로의 비용을 보조하는 수준을 넘어 서로의 불확실성을 줄인다. Every의 마스터플랜이 보여주는 가장 중요한 통찰은 미디어 회사도 앱을 만들 수 있다는 사실이 아니다. **읽고 쓰는 행위 자체를 시장 조사와 제품 개발의 중심에 놓으면, 연구개발은 돈을 쓰고 결과를 기다리는 부서가 아니라 배우는 동안 매출을 만드는 사업이 될 수 있다는 것**이다. --- 주요 출처: Dan Shipper, [Every’s Master Plan: Part II](https://every.to/on-every/every-s-master-plan-part-ii?ref=zerodraftlab.com). Every의 팀 규모, 제품 수, 핵심 루프, 단일 구독, 앱 간 공유 맥락 계획, 미디어·소프트웨어·컨설팅의 관계는 해당 글을 바탕으로 했습니다. 미디어를 수익형 R&D 시스템으로 해석하고 Supple·Zero Draft Lab에 적용한 부분은 이 글의 분석입니다. ### AI Agent에게 필요한 건 권한이 아니라 영수증이다 URL: https://zerodraftlab.com/ai-agent-needs-receipt-not-permission/ Last updated: 2026-09-15T08:36:04.000Z 회사 계정으로 보도자료를 발행한다. 고객 명단을 외부 시스템으로 옮긴다. 운영 서버에 새 버전을 배포한다. 같은 행동도 어떤 AI Agent에게는 shell command이고, 다른 Agent에게는 tool call이며, 관리형 플랫폼에서는 session transition으로 남는다. 실행 형식은 다르지만 나중에 물어야 할 질문은 같다. **누가, 누구의 권한으로, 어느 계정에서, 무엇을, 어디까지 공개했고, 결과는 실제로 무엇이었는가.** 권한 목록만으로는 이 질문에 답할 수 없다. 권한은 무엇을 할 수 있는지 보여줄 뿐, 왜 그 행동이 허용됐고 실제로 무슨 일이 벌어졌는지는 보여주지 않는다. AI Agent에게 정말 필요한 것은 더 넓은 권한이 아니라 행동마다 남는 영수증이다. ## 벤더의 실행 로그는 책임의 언어가 아니다 Zexun Wang의 논문 [「Proof-Carrying Agent Actions」](https://arxiv.org/abs/2606.04104?ref=zerodraftlab.com)는 이 문제를 서로 다른 Agent 실행환경의 거버넌스 문제로 다룬다. 논문이 제안하는 PCAA(Proof-Carrying Agent Actions)의 중심에는 특정 벤더의 session log가 아니라 이식 가능한 *action certificate*, 즉 행동 증명서가 있다. 실행 로그는 대개 한 제품 안에서는 유용하다. 어느 도구가 호출됐고 어떤 응답이 돌아왔는지 추적할 수 있다. 하지만 회사가 여러 Agent와 자동화 플랫폼을 함께 쓰기 시작하면 기록의 문법이 갈라진다. 한쪽에는 터미널 명령이, 다른 쪽에는 API 요청이, 또 다른 쪽에는 승인 버튼을 누른 흔적만 남는다. 이 조각들을 모아도 책임은 저절로 설명되지 않는다. 기술 로그에는 실행 주체의 사업상 역할, 승인자의 권한, 대상 계정의 소유자, 공개 범위, 실행 전제와 사후 검증이 빠질 수 있기 때문이다. 로그는 사건을 보여주지만, 사건이 정당했는지는 말해주지 않는다. ## 행동 증명서에는 다섯 번의 멈춤이 있다 PCAA는 고위험 행동을 다섯 체크포인트로 닫는다. 실행 가능성 판정, 행동 개시, 가정 기록, 승인, 결과 종결이다. 1. **실행 가능성 판정:** 이 행동은 허용할 것인가, 차단할 것인가, 먼저 시뮬레이션할 것인가, 사람의 승인을 받을 것인가. 2. **행동 개시:** 이후의 승인과 증거가 붙을 하나의 식별 가능한 행동 객체를 만든다. 3. **가정 기록:** 무엇이 사실이라고 믿었고 어떤 조건에 의존해 판단했는지 남긴다. 4. **승인:** 누가 어떤 의미의 승인을 했으며, 그 승인이 실제 실행을 멈추거나 허용할 수 있었는지 기록한다. 5. **결과 종결:** 실행 결과와 오류, 대상 표면의 read-back, 재현 가능한 증거를 한 묶음으로 닫는다. 여기서 중요한 것은 승인 유무를 체크박스 하나로 줄이지 않는다는 점이다. 어떤 환경의 승인은 실행 전 강제로 멈출 수 있지만, 어떤 환경에서는 사후 검토에 불과하다. PCAA는 이 통제 깊이의 차이까지 증명서에 드러내야 한다고 본다. 또한 행동 자체만이 아니라 행동이 넘는 경계를 기록한다. 외부 write인지, 목적지는 공개면인지 내부면인지, 사용한 계정은 누구 소유인지, 민감정보가 포함됐는지, 되돌릴 수 있는지를 함께 본다. 같은 ‘발행’이라도 개인 테스트 계정의 비공개 초안과 회사 공식 계정의 대외 발표는 전혀 다른 행동이기 때문이다. 이 원칙을 받아들이면 AI Agent 거버넌스의 목표도 달라진다. 모든 Agent를 같은 방식으로 감시하는 것이 아니라, 서로 다른 실행환경에서 일어난 행동을 같은 책임의 언어로 번역하는 것이 목표가 된다. 그리고 이 책임의 언어는 AI에게만 필요한 것이 아니다. **회사의 오너가 아닌 경영자와 임원, 팀장, 실무자, 대행사 역시 회사의 권한을 위임받아 행동하는 대리인**이기 때문이다. ## 직함은 행동 증명서를 대신하지 못한다 CEO라는 직함이 있다고 해서 회사의 모든 자산을 자기 것처럼 처분할 수 있는 것은 아니다. 임원이 회사 공식 계정에 접근할 수 있다고 해서 모든 외부 발행이 자동으로 정당해지는 것도 아니다. 권한은 행동의 입장권이지, 행동의 정당성을 증명하는 영수증이 아니다. 현실의 조직은 자주 직함을 증거로 착각한다. “대표가 지시했다”, “본부장이 승인했다”, “담당자가 알아서 처리했다”는 말로 실행을 닫는다. 문제가 생기면 메신저 기록과 회의 참석자의 기억을 뒤져 누가 무엇을 뜻했는지 복원한다. 이 방식은 느릴 뿐 아니라 각자의 이해관계에 따라 기억이 달라진다. 인간 대리인의 고위험 행동에도 PCAA와 같은 문법을 적용하면 질문이 선명해진다. 이 계약은 어느 권한 범위에서 검토됐는가. 이 채용 제안의 예산과 직급은 누가 승인했는가. 이 보도자료는 어느 법인과 브랜드의 공식 입장인가. 이 송금의 수취인과 금액은 실행 후 다시 확인됐는가. 이 데이터 반출은 어떤 고객 동의와 보존기간을 전제로 했는가. 이때 행동 증명서는 장문의 결재문서일 필요가 없다. 중요한 것은 형식이 아니라 재구성 가능성이다. 간단한 승인 요청, 대상 계정의 read-back, 실행 전후 화면이나 응답 ID, 결과 확인 링크만으로도 충분할 수 있다. 다만 나중에 제3자가 보더라도 다음 여섯 가지에는 답할 수 있어야 한다. 1. 실행 주체는 누구였는가. 2. 누구에게서 어떤 범위의 권한을 위임받았는가. 3. 어느 법인·계정·브랜드를 대상으로 했는가. 4. 어떤 전제와 공개 범위로 승인받았는가. 5. 실제로 무엇이 실행됐는가. 6. 결과를 어디에서 다시 확인할 수 있는가. ## 모든 일에 영수증을 붙이라는 뜻은 아니다 이 원칙을 잘못 적용하면 조직은 곧바로 관료제가 된다. 오타 수정과 내부 메모에도 승인을 요구하고, 증거를 남기는 일이 실제 업무보다 커진다. PCAA의 유용한 지점은 모든 행동을 무겁게 만드는 데 있지 않다. 행동의 외부성과 실패 비용에 따라 통제 강도를 달리하는 데 있다. 되돌리기 쉬운 내부 수정은 실행 기록만으로 충분하다. 외부 초안은 대상 계정과 공개 범위를 확인하면 된다. 고객에게 실제 메시지를 보내거나 프로덕션을 배포할 때는 사전 승인과 결과 read-back이 필요하다. 송금, 계약, 개인정보 반출, 계정 폐쇄처럼 비가역성이 큰 행동은 승인자의 권한과 사후 증거까지 더 엄격하게 묶어야 한다. 즉 행동 증명서는 감시 장치가 아니라 위험에 비례하는 책임 장치다. 실행자에게도 유리하다. 나중에 결과가 나빠졌다는 이유만으로 “왜 마음대로 했느냐”는 책임을 뒤집어쓰지 않게 해준다. 당시의 전제, 승인 범위, 실제 실행 결과가 남아 있기 때문이다. 승인자에게는 자신이 무엇을 허용했는지 분명하게 만들고, 오너에게는 회사를 대신해 움직인 행동을 재구성할 수 있게 한다. ## 좋은 거버넌스는 권한을 줄이는 일이 아니다 조직은 흔히 사고가 나면 권한부터 줄인다. 배포 권한을 회수하고, 외부 발행 계정을 잠그고, 결재 단계를 늘린다. 그러나 권한을 좁혀도 대리행위는 사라지지 않는다. 누군가는 여전히 고객에게 답하고, 계약하고, 송금하고, 시스템을 바꿔야 한다. 더 나은 방법은 행동이 증명을 운반하게 만드는 것이다. 실행 전에 가능성을 판정하고, 행동을 열고, 가정을 남기고, 필요한 승인을 받고, 실행 후 결과를 다시 읽어 닫는다. Agent가 shell을 썼든 tool call을 썼든, 인간 경영자가 메일을 보냈든 계약서에 서명했든 이 문법은 달라지지 않는다. **오너가 아닌 모든 실행자는 회사 권한의 사용자다. 사용자에게 필요한 것은 무제한 권한도, 끝없는 감시도 아니다. 자신이 어떤 위임으로 무엇을 했는지 증명해주는 영수증이다.** --- 출처: Zexun Wang, [Proof-Carrying Agent Actions: Model-Agnostic Runtime Governance for Heterogeneous Agent Systems](https://arxiv.org/abs/2606.04104?ref=zerodraftlab.com), arXiv:2606.04104v1, 2026\. 이 글은 논문의 PCAA 모델을 비오너 경영자와 조직 대리인의 책임 구조로 확장해 해석했다. 인간 조직에 대한 확장은 논문 저자의 실증 결론이 아니라 Zero Draft Lab의 적용 논지다. ### 대에이전트 시대에 다시 읽는 Aggregation Theory URL: https://zerodraftlab.com/aggregation-theory-in-the-age-of-agents/ Last updated: 2026-09-15T08:36:04.000Z 2015년 Ben Thompson은 인터넷이 시장의 권력을 뒤집는 방식을 하나의 이론으로 묶었다. 이름은 [Aggregation Theory](https://stratechery.com/2015/aggregation-theory/?ref=zerodraftlab.com)였다. 전통 시장은 공급자, 유통자, 소비자로 구성된다. 인터넷 이전에는 유통이 희소했다. 신문은 인쇄기와 배달망을 가졌고, 방송사는 주파수와 편성권을 가졌으며, 호텔은 객실뿐 아니라 낯선 도시에서 믿을 수 있는 숙소라는 신뢰를 가졌다. 유통자는 그 힘을 이용해 공급을 거꾸로 통합했다. 인터넷은 배포비용과 거래비용을 거의 0으로 만들었다. 공급자를 소유하지 않아도 전 세계의 공급을 한곳에 모을 수 있게 됐다. 그때부터 시장의 중심은 공급에서 최종 사용자로 이동했다. 가장 좋은 경험으로 사용자를 모은 회사가 공급자를 불러오고, 늘어난 공급이 다시 경험을 개선하는 순환을 만들었다. Google은 웹페이지를, Amazon은 상품을, Uber는 차량을, Airbnb는 빈방과 신뢰를 모듈화했다. 이들의 가장 중요한 자산은 웹페이지나 자동차, 객실의 소유권이 아니었다. **사용자가 무엇을 찾고, 고르고, 거래할 때 가장 먼저 찾아오는 관계**였다. 10여 년이 지난 지금 Aggregation Theory를 다시 읽어야 하는 이유는 이 구조가 무너졌기 때문이 아니다. 오히려 한 층 더 올라가고 있기 때문이다. ## 검색은 선택지를 줄였지만 선택까지 하지는 않았다 인터넷의 Aggregator는 인간 앞에 더 나은 선택지를 배열했다. Google은 링크를 정렬했고, Amazon은 상품을 비교했으며, Booking.com은 호텔을 가격과 평점으로 나열했다. 사용자는 플랫폼이 만든 순위를 믿었지만 마지막 판단은 직접 했다. 그래서 사용자 경험의 중심에는 화면이 있었다. 검색창, 피드, 상품 목록, 별점, 리뷰, 장바구니가 경쟁의 전장이었다. 공급자는 그 화면에서 더 높은 자리를 차지하려고 검색 최적화와 광고, 가격 할인, 리뷰 관리에 돈을 썼다. AI Agent는 이 관계를 바꾼다. 사용자가 “도쿄에서 신주쿠와 가까우면서 조용하고, 늦은 체크인이 가능하며, 총예산 80만 원 이하인 호텔을 예약해줘”라고 말하면 Agent는 링크 열 개를 돌려주는 데서 멈추지 않는다. 조건을 해석하고, 후보를 비교하고, 숨은 비용을 확인하고, 필요하면 예약 단계까지 진행한다. OpenAI가 2025년 공개한 [ChatGPT agent](https://openai.com/index/introducing-chatgpt-agent/?ref=zerodraftlab.com)도 이 경계를 분명히 보여줬다. 웹을 탐색하고 필터를 적용하며, 식재료를 구매하거나 양식을 작성하는 것처럼 조사에서 행동까지 이어지는 작업을 수행한다. 중요한 행동 앞에서는 사용자 확인을 받지만, 그 확인 사이의 탐색과 비교와 절차는 Agent가 맡는다. 여기서 사용자가 위임하는 것은 클릭이 아니다. **무엇이 나에게 좋은 선택인지 판단하는 과정**이다. ## 대에이전트 시대에는 의사결정의 입구가 바뀐다 Aggregator의 힘이 최종 사용자 관계에서 나온다면, 대에이전트 시대의 핵심 질문은 단순하다. **사용자는 결정을 내릴 때 누구에게 가장 먼저 말하는가.** 과거에는 Google에 검색어를 입력했다. 상품이라면 Amazon을 열었고, 숙소라면 여행 플랫폼에 들어갔다. 앞으로 사용자는 자신의 일정, 예산, 취향, 과거 구매, 회사 정책을 아는 Agent에게 목표만 말할 수 있다. Agent는 여러 플랫폼과 공급자를 넘나들며 결과를 만든다. 이때 Agent는 기존 Aggregator의 또 다른 유입 채널이 아니다. 여러 Aggregator를 아래에 두고 선택하는 **Aggregator 위의 Aggregator**가 될 가능성이 있다. 호텔 플랫폼이 수백만 개 객실을 모아도 Agent가 공식 호텔 사이트, 여러 예약 플랫폼, 멤버십 가격을 동시에 비교한다면 사용자는 호텔 플랫폼과 직접 관계를 맺지 않는다. 전자상거래 플랫폼이 방대한 상품과 리뷰를 보유해도 Agent가 여러 상점의 가격, 배송, 반품 조건을 대신 판단한다면 상품 목록 화면을 방문할 이유가 줄어든다. 한때 공급자를 모듈화했던 Aggregator가 이제 상위 Agent에게 호출되는 공급자로 모듈화될 수 있다. Google, Amazon, Uber, Airbnb가 사라진다는 뜻은 아니다. 더 불편한 가능성이다. 이들이 보유한 재고, 데이터, 결제, 물류는 여전히 중요하지만 **사용자와의 직접 관계는 Agent가 가져갈 수 있다.** 인터넷 시대의 승자가 “어디서 찾을 것인가”를 장악했다면, Agent 시대의 승자는 “누구에게 맡길 것인가”를 장악한다. 그 차이는 인터페이스의 변화보다 훨씬 크다. 검색창을 대화창으로 바꾸는 정도가 아니라, 시장에서 가장 수익성 높은 통합 지점이 이동하는 사건이기 때문이다. ## 새로운 통합 지점은 관심이 아니라 권한이다 기존 Aggregator는 사용자의 관심과 데이터를 통합했다. Google은 검색 의도와 웹페이지를 연결했고, Facebook은 관계와 관심사를 광고 재고에 연결했다. Amazon은 결제정보와 구매 이력, 물류를 하나의 계정에 묶었다. Agent는 여기에 새로운 자산을 더한다. 사용자를 대신해 행동할 수 있는 권한이다. 좋은 Agent는 사용자가 좋아하는 브랜드만 아는 것이 아니다. 이번 달 예산, 다음 주 일정, 회사 출장 규정, 알레르기, 이미 구독 중인 서비스, 과거에 반품한 이유까지 함께 고려할 수 있다. 더 나아가 캘린더를 바꾸고, 이메일을 보내고, 결제를 요청하고, 다른 시스템에 결과를 기록할 수 있다. 이 관계가 깊어질수록 전환비용도 커진다. 검색엔진을 바꾸면 검색 기록 일부를 잃지만, Agent를 바꾸면 나의 목표와 선호, 반복 업무의 맥락, 연결된 도구, 승인 규칙을 다시 가르쳐야 할 수 있다. 에이전트의 메모리와 권한이 쌓인다는 것은 편리함이 늘어난다는 뜻이면서 동시에 새로운 잠금 효과가 생긴다는 뜻이다. 따라서 대에이전트 시대의 독점력은 가장 많은 콘텐츠를 보여주는 능력보다 **가장 많은 인간에게 가장 넓은 범위의 판단과 행동을 위임받는 능력**에서 나올 수 있다. 사용자의 판단과 행동을 위임받은 Agent가 새로운 통합 지점이 된다면, 공급자는 더 이상 인간의 화면에서만 경쟁할 수 없다. 이제 Aggregation의 반대편에서 누가 자신을 선택하는지부터 달라진다. ## 공급자는 인간이 아니라 Agent에게 선택받아야 한다 사용자 관계가 Agent로 이동하면 공급자의 경쟁 방식도 달라진다. 지금까지 기업은 사람에게 발견되기 위해 웹페이지를 만들고, 검색 결과를 최적화하고, 광고를 사고, 매력적인 상품 사진을 준비했다. Agent도 일부는 같은 정보를 읽겠지만 선택 기준은 다를 수 있다. 사람에게는 “가장 인기 있는 상품”이라는 문구가 먹힐 수 있다. Agent에게는 재고가 실제로 있는지, 총비용이 얼마인지, 배송일을 지킬 수 있는지, 반품 조건이 사용자의 제약과 맞는지가 더 중요하다. 사람이 멋진 랜딩페이지에서 넘어가던 모호함을 Agent는 비교 불가능한 정보로 처리할 수 있다. 그래서 공급자는 두 종류의 고객을 상대하게 된다. 욕망과 이야기에 반응하는 인간, 그리고 조건·정책·증거를 읽고 행동하는 Agent다. 전자는 브랜드를 요구하고, 후자는 구조화된 사실과 신뢰 가능한 실행 경로를 요구한다. Google이 발표한 [Agent2Agent(A2A)](https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/?ref=zerodraftlab.com)는 서로 다른 Agent가 정보를 교환하고 행동을 조정하는 공통 프로토콜을 지향한다. 이후 공개된 [Universal Commerce Protocol](https://blog.google/products/ads-commerce/agentic-commerce-ai-tools-protocol-retailers-platforms/?ref=zerodraftlab.com)은 발견, 구매, 구매 후 지원까지 Agent와 판매자, 결제 사업자가 공통 언어로 연결되는 상거래를 제안한다. 화면을 잘 만드는 일과 별개로, Agent가 공급자의 능력과 조건을 정확히 읽고 호출할 수 있는 층이 만들어지고 있는 것이다. 이 변화가 충분히 진행되면 SEO의 중요한 일부도 달라진다. 검색 결과에서 클릭을 얻는 경쟁만이 아니라, Agent가 목표를 수행할 때 신뢰할 수 있는 후보로 불리고 거래를 끝낼 수 있는가의 경쟁이 된다. 발견 가능성, 기계가 읽을 수 있는 조건, 최신 재고, 인증된 평판, 실패했을 때의 복구가 하나의 사용자 경험이 된다. ## 결제가 붙는 순간 Aggregation은 행동의 이론이 된다 Agent가 추천만 할 때는 기존 검색과 차이가 작아 보일 수 있다. 추천을 받은 사람이 다시 사이트를 열고 결제한다면 최종 사용자 관계는 여전히 기존 플랫폼에 남아 있기 때문이다. 하지만 Agent가 결제까지 수행하면 관계의 중심이 달라진다. 사용자는 판매자의 화면을 보지 않고도 거래를 끝낼 수 있다. 공급자는 고객을 설득하는 대신 고객의 Agent가 가진 조건을 충족해야 한다. Google의 [Agent Payments Protocol(AP2)](https://blog.google/products-and-platforms/platforms/google-pay/agent-payments-protocol-fido-alliance/?ref=zerodraftlab.com)은 이 지점을 다룬다. 특히 사전에 설정한 사용자 지시에 따라 사람이 그 순간 자리에 없어도 Agent가 결제를 수행하는 구조와, 사용자가 무엇을 승인했는지 검증 가능한 기록으로 남기는 방식을 제시한다. Agent의 거래가 커질수록 편의보다 먼저 해결해야 할 문제가 권한과 책임이라는 뜻이다. 이것은 Aggregation Theory를 정보 유통의 이론에서 행동 유통의 이론으로 확장한다. 기존 Aggregator가 수많은 공급을 한 화면에 모았다면, Agent는 수많은 공급과 도구를 하나의 위임된 행동으로 압축한다. 링크 열 개가 예약 한 건이 되고, 상품 비교표가 도착 예정인 주문 한 건이 되며, 금융상품 설명이 사용자의 위험 한도 안에서 실행된 결정 한 건이 된다. 사용자가 받는 결과물은 선택지가 아니라 완료 상태다. ## 그러나 모든 Agent가 Aggregator가 되는 것은 아니다 많은 Agent가 등장한다고 해서 모두 시장의 지배자가 되는 것은 아니다. Thompson의 원래 이론에서도 단순한 유통자는 Aggregator가 아니었다. 공급을 모으는 것만으로는 부족했다. 사용자 경험을 장악하고, 사용자가 늘수록 공급이 늘며, 공급이 늘수록 경험이 좋아지는 선순환이 필요했다. Agent도 마찬가지다. 특정 웹사이트에서 버튼을 대신 누르는 기능은 유용하지만 사용자 관계를 소유하지 못한다. 한 회사의 업무만 자동화하는 Agent는 강한 제품이 될 수 있어도 전 산업을 집계하는 Aggregator와는 다르다. Agent Aggregator가 되려면 적어도 세 가지 고리가 필요하다. 1. **위임:** 사용자가 목표와 맥락, 행동 권한을 지속적으로 맡긴다. 2. **도달 범위:** Agent가 여러 공급자와 도구를 넘나들며 목표를 끝낼 수 있다. 3. **학습 루프:** 더 많은 행동이 선호와 실패 데이터를 만들고, 그 데이터가 다음 판단과 공급자 선택을 개선한다. 이 순환이 만들어지면 더 좋은 Agent가 더 많은 사용자를 부르고, 더 많은 사용자가 더 많은 공급자와 도구의 연결을 부르며, 넓어진 연결이 다시 Agent의 성공률을 높인다. Aggregation Theory의 선순환이 화면 위가 아니라 행동망 안에서 재현된다. ## 대리인의 충성은 누구를 향하는가 여기에는 오래된 Aggregator보다 더 위험한 문제가 있다. 사용자의 대리인인 Agent가 실제로 누구의 이익을 최우선으로 두는가. 검색 결과의 광고는 적어도 광고라는 표시가 있다. Agent가 특정 상품을 추천하고 바로 구매까지 수행하면 추천, 광고, 수수료, 플랫폼의 자사우대가 한 문장 안에 섞일 수 있다. 사용자는 결과만 받고 어떤 후보가 제외됐는지, 어떤 경제적 이해관계가 순위에 영향을 줬는지 보지 못할 수 있다. 최종 사용자 관계가 더 강해질수록 이해상충을 숨길 힘도 커진다. 그래서 Agent 시대의 사용자 경험은 단지 더 적은 클릭이어서는 안 된다. 선택 근거, 대안, 수수료, 권한 범위, 실행 기록, 취소 가능성을 사용자가 필요할 때 확인할 수 있어야 한다. 가장 편리한 Agent가 반드시 사용자의 이익에 가장 충실한 Agent는 아니다. Aggregator의 성공 공식을 그대로 적용하되, 대리인의 의무와 책임을 함께 설계하지 않으면 우리는 검색 결과의 편향보다 훨씬 보이지 않는 선택 시스템을 만들게 된다. ## 다음 독점은 화면이 아니라 기본 대리인에서 나온다 인터넷은 유통을 무료로 만들고 공급을 모듈화했다. Aggregator는 사용자에게 가장 가까운 자리를 차지함으로써 그 위에 제국을 세웠다. AI Agent는 판단과 행동의 거래비용을 낮춘다. 수십 개의 링크를 읽고 조건을 비교하고 양식을 채우고 결제하는 비용이 줄어들면, 인간은 더 많은 결정을 대리인에게 넘긴다. 그 순간 기존 Aggregator조차 Agent가 호출하는 모듈이 될 수 있다. 그래서 대에이전트 시대의 핵심 경쟁은 가장 똑똑한 모델을 한 번 만드는 데서 끝나지 않는다. 누가 사용자의 지속적인 위임을 얻는가, 누가 가장 넓은 공급과 도구에 도달하는가, 누가 행동 결과를 학습해 다음 결정을 더 낫게 만드는가의 경쟁이다. 2015년 Aggregation Theory의 명제는 아직 유효하다. 권력은 최종 사용자 관계를 가진 곳으로 이동한다. 다만 이제 그 관계의 의미가 달라졌다. **인터넷 시대의 Aggregator는 우리가 무엇을 볼지 정렬했다. 대에이전트 시대의 Aggregator는 우리를 대신해 무엇을 할지 결정한다.** --- 주요 출처: Ben Thompson, [Aggregation Theory](https://stratechery.com/2015/aggregation-theory/?ref=zerodraftlab.com); OpenAI, [Introducing ChatGPT agent](https://openai.com/index/introducing-chatgpt-agent/?ref=zerodraftlab.com); Google, [Announcing the Agent2Agent Protocol](https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/?ref=zerodraftlab.com), [Universal Commerce Protocol](https://blog.google/products/ads-commerce/agentic-commerce-ai-tools-protocol-retailers-platforms/?ref=zerodraftlab.com), [Agent Payments Protocol](https://blog.google/products-and-platforms/platforms/google-pay/agent-payments-protocol-fido-alliance/?ref=zerodraftlab.com). Agent가 기존 플랫폼 위의 Aggregator가 될 수 있다는 주장은 위 자료에 명시된 전망이 아니라, Aggregation Theory를 현재의 에이전트 실행·상거래 구조에 적용한 이 글의 해석입니다. ### AEO는 배관이다. 해자는 원본 자산이다 URL: https://zerodraftlab.com/ai-search-needs-original-assets/ Last updated: 2026-09-15T08:36:05.000Z AI 검색이 커지자 마케팅팀의 질문도 바뀌었다. 예전에는 “구글 첫 페이지에 어떻게 올라갈까”를 물었다면, 이제는 “ChatGPT와 AI Overview에 어떻게 인용될까”를 묻는다. 곧바로 새로운 최적화 목록이 생긴다. 질문형 제목을 쓰고, 첫 문단에 답을 넣고, FAQ를 만들고, 구조화 데이터를 붙이고, 문장을 짧게 자르라는 조언이다. 이런 정리는 기계가 내용을 읽는 데 도움이 될 수 있다. 그러나 가장 중요한 문제를 해결하지는 못한다. **다른 곳의 정보를 잘 정리한 글은 AI가 가장 쉽게 대체할 수 있는 글이기도 하다.** 검색엔진은 사용자를 링크로 보냈다. 생성형 검색은 여러 링크를 읽고 답을 먼저 만든다. 한 페이지의 가치가 공개된 정보를 매끄럽게 설명하는 데만 있다면, AI는 그 설명을 다시 조립해 사용자에게 건넬 수 있다. 독자는 답을 얻고, 원문을 방문할 이유는 줄어든다. 그래서 AI 검색 시대의 경쟁은 글을 더 많이 만드는 싸움이 아니다. 다른 답변이 대신 만들어낼 수 없는 **원본 자산**을 누가 축적하는가의 싸움이다. ## 검색의 단위가 방문에서 등장으로 바뀐다 Google은 2026년 6월 Search Console에 생성형 AI 성과 보고서를 별도로 도입한다고 발표했다. AI Overviews와 AI Mode에서 사이트 링크가 얼마나 노출됐는지, 어떤 페이지가 등장했는지, 어느 국가와 기기에서 보였는지를 확인하는 보고서다. 아직 일부 사이트에만 시험적으로 제공되고 있다. 이 변화는 측정 도구 하나의 추가보다 의미가 크다. 전통적인 검색에서는 순위, 클릭, 방문이 중심이었다. 생성형 검색에서는 사용자가 사이트를 방문하지 않아도 사이트 링크가 답변과 함께 등장할 수 있다. 가시성의 최소 단위가 클릭 이전의 **출처 후보로 등장하는 순간**까지 넓어진다. 그러나 등장 횟수만 늘리는 것을 목표로 삼으면 과거 SEO의 실수를 반복한다. 키워드 밀도를 맞추던 팀이 이제는 인용되기 좋은 문장 밀도를 맞춘다. 검색 화면의 형식은 달라졌지만, 남이 만든 수요와 정보를 가공해 트래픽을 얻으려는 구조는 그대로다. Google의 공식 안내는 오히려 담백하다. AI Overviews와 AI Mode에 등장하기 위한 별도의 기술 요건이나 특별한 schema.org 마크업은 없으며, 기존 검색의 기술적 기본과 사람에게 유용하고 신뢰할 수 있는 콘텐츠가 여전히 중요하다고 설명한다. 생성형 AI로 많은 페이지를 만들면서 사용자에게 새로운 가치를 더하지 않는 행위는 대량 콘텐츠 남용 정책에 걸릴 수 있다고도 밝힌다. 기계를 위한 비밀 문법이 따로 있다는 환상보다, “이 페이지에는 다른 페이지에 없는 무엇이 있는가”라는 오래된 질문이 더 중요해진 셈이다. ## 설명은 풍부해지고 근거는 희소해진다 AI가 싸게 만드는 것은 문장만이 아니다. 요약, 비교, 목차, 사례의 재배열, 초보자를 위한 해설까지 모두 빠르게 복제한다. 특정 주제를 조사해 공개된 자료 열 개를 한 편으로 정리하는 일의 비용은 급격히 내려간다. 반대로 AI가 스스로 만들 수 없는 것이 있다. 실제 고객 30명을 인터뷰한 기록, 6개월 동안 운영한 제품의 실패 로그, 직접 측정한 가격 실험, 공개된 코드로 재현할 수 있는 벤치마크, 한 업종에서만 관찰한 예외의 목록이다. 모델은 이것을 설명할 수는 있지만, 과거로 돌아가 대신 관찰할 수는 없다. Google도 유용한 콘텐츠를 점검할 때 “독창적인 정보, 보도, 연구 또는 분석을 제공하는가”를 묻는다. AI 검색만을 위한 새 규칙은 아니다. 다만 생성 비용이 낮아질수록 이 오래된 기준의 경제적 가치는 더 커진다. 2026년 공개된 한 preprint는 ChatGPT, Google AI Overview·Gemini, Perplexity에 입력한 602개 통제 프롬프트와 2만 1천여 개의 유효 인용을 분석했다. 답변에 더 깊이 반영된 페이지에는 정의, 수치, 비교, 절차, 코드처럼 추출 가능한 근거 단위가 더 자주 있었고, 질문과 답변 모양만 갖춘 형식은 그 자체로 더 높은 반영도를 보이지 않았다. 정적 관찰 자료라 특정 형식이 인용을 일으킨다는 인과는 증명하지 못하지만, 형식보다 운반할 근거가 먼저라는 해석과는 맞닿아 있다. 원본 자산은 거대한 설문조사 보고서만을 뜻하지 않는다. 작은 회사도 매일 원본을 만든다. 고객이 계약 직전에 반복해서 묻는 질문, 온보딩에서 가장 많이 멈추는 단계, 자동화가 실패한 조건, 가격을 바꾼 뒤 달라진 행동은 모두 그 회사만 먼저 볼 수 있는 정보다. 문제는 대부분의 조직이 이것을 데이터로 남기지 않고 회의와 메신저 속에서 흘려보낸다는 데 있다. ## AI 검색 최적화는 콘텐츠팀만의 일이 아니다 인용될 원본을 만들려면 콘텐츠팀의 역할도 달라진다. 이미 알려진 내용을 더 잘 쓰는 데서 끝나지 않고, 조직 안에서 새롭게 알게 된 사실을 찾아 공개 가능한 형태로 바꿔야 한다. 고객지원팀에는 반복되는 오해가 있고, 영업팀에는 구매가 멈추는 이유가 있으며, 제품팀에는 실제 사용 행동이 있다. 운영팀에는 정상 절차보다 더 가치 있는 예외 기록이 쌓인다. 콘텐츠팀이 이 흔적을 인터뷰하고, 검증하고, 익명화하고, 방법과 한계를 함께 공개하면 글은 단순한 설명이 아니라 1차 출처가 된다. 이때 문장은 자산 자체가 아니다. 문장은 자산을 운반하는 인터페이스다. 질문형 제목, 짧은 정의, 명확한 표와 구조화 데이터는 그 인터페이스를 읽기 쉽게 만든다. 하지만 운반할 독자적 사실이 없다면 추출하기 좋은 평범한 글만 남는다. 결국 먼저 바꿔야 할 질문은 “AI가 좋아하는 형식은 무엇인가”가 아니다. **“우리만 알고 있지만 아직 세상에 기록하지 않은 사실은 무엇인가”**다. 그 사실을 찾는 일은 새 연구 프로젝트를 만드는 것보다, 이미 사업을 하며 생긴 흔적을 원본으로 인정하는 데서 시작한다. 대부분의 회사는 원본이 없어서가 아니라 원본과 잡음을 구분하는 체계가 없어서 남의 이야기를 다시 쓴다. ## 콘텐츠 공급망을 표현에서 증거로 뒤집는다 기존 콘텐츠 생산은 대개 키워드에서 시작한다. 검색량이 있는 주제를 고르고, 상위 문서를 조사하고, 목차를 만든 뒤, 비슷하지만 더 긴 글을 쓴다. 이 방식에서 회사가 새로 더하는 것은 대부분 표현이다. AI가 가장 잘 압축하는 층이기도 하다. 원본 자산을 만드는 공급망은 반대로 움직인다. 먼저 사업에서 반복적으로 관찰되는 현상을 고른다. 그 현상을 설명할 증거를 모으고, 증거가 말하지 않는 범위를 표시한 다음, 마지막에 문장으로 만든다. 1. **관찰:** 어떤 현상이 반복해서 보였는가. 2. **증거:** 로그, 인터뷰, 거래, 실험 가운데 무엇이 이를 뒷받침하는가. 3. **해석:** 왜 일어났다고 보는가. 다른 설명은 무엇인가. 4. **표현:** 독자와 검색 시스템이 이해할 수 있게 어떻게 공개할 것인가. 예를 들어 “AI Agent 도입법”을 또 설명하는 대신, 실제 자동화 업무 100건에서 사람이 개입한 순간을 분류할 수 있다. 개입 사유가 권한 부족인지, 데이터 누락인지, 외부 시스템 오류인지 공개하면 작은 표 하나도 원본 자산이 된다. 표본이 자사 고객에 한정됐고 업종이 편향됐다는 한계까지 적으면 다른 사람이 인용하고 반박할 수 있는 출처가 된다. 중요한 것은 규모가 아니라 증거가 만들어진 과정이다. 숫자가 어디에서 왔고, 어떤 기준으로 제외했으며, 언제 수집했는지가 보여야 한다. 출처가 불분명한 “업계 평균”보다 표본이 작아도 생성 과정을 확인할 수 있는 관찰이 더 쓸모 있다. ## 좋은 원본은 한 번 인용되고 끝나지 않는다 원본 자산은 글 한 편의 성과를 넘어 다음 판단의 기반이 된다. 고객 인터뷰를 구조화하면 다음 제품 명세가 되고, 실패 로그를 분류하면 운영 규칙이 되며, 가격 실험 기록은 다음 오퍼 설계의 기준이 된다. 외부에는 콘텐츠지만 내부에는 연구 자산이다. 이 차이가 콘텐츠의 투자 회수 방식을 바꾼다. 설명 글은 발행 뒤 트래픽이 멈추면 가치도 빠르게 줄어든다. 원본 자산은 다른 글, 영업 자료, 제품 문서, 교육, 도구의 입력으로 재사용된다. 검색 알고리즘이 바뀌어도 조직이 실제로 배운 사실은 남는다. 따라서 모든 글이 원본 연구일 필요는 없다. 원본 하나를 중심으로 여러 설명이 파생되는 구조면 된다. 핵심 조사나 실험은 정본 페이지에 남기고, 짧은 글과 뉴스레터, 영상, 소셜 게시물은 서로 다른 독자를 그 원본으로 연결한다. AI가 파생 설명을 요약하더라도 사실의 최초 출처는 한곳에 남는다. ## 원본도 조작될 수 있다 여기에는 불편한 반론이 있다. AI가 웹의 출처를 읽는다면, 출처처럼 보이는 글을 대량으로 심어 답변을 조작할 수도 있다. 2026년 6월 404 Media는 r/Biohackers 운영진의 발표를 인용해, 펩타이드와 호르몬 대체요법 관련 업체들이 AI 챗봇에 수집될 것을 노리고 홍보성 게시물을 은밀하게 올렸다는 의혹을 보도했다. 운영진은 관련 신규 게시물을 제한했다. 이는 특정 업체의 게시물이 실제로 특정 AI 답변을 바꿨다는 통제실험은 아니다. 커뮤니티 운영진이 관찰한 조직적 스팸 의혹이다. 그 한계를 감안해도 사건이 보여주는 방향은 분명하다. AI 검색이 출처를 중요하게 만들수록, 출처처럼 보이는 것을 제조하려는 시장도 커진다. 앞으로의 경쟁은 단순한 인용 횟수가 아니라 **검증 가능한 출처와 조작된 표면을 구분하는 경쟁**이 된다. 그래서 원본성은 “우리가 처음 말했다”는 선언만으로 성립하지 않는다. 조사 방법, 수집 시점, 표본 범위, 이해관계, 원자료에 접근할 수 있는 경로가 함께 있어야 한다. 독자가 결론을 믿지 않더라도 어떻게 나왔는지 확인할 수 있어야 한다. 이 투명성이 쌓이면 브랜드는 개별 키워드보다 더 큰 자산인 출처로서의 평판을 얻는다. 자사 데이터라는 이유만으로 신뢰가 생기는 것도 아니다. 외부에서 재현하거나 반박할 수 있고, 필요하면 독립된 제3자가 확인할 때 원본은 비로소 출처로서 힘을 얻는다. ## AEO는 필요하지만 해자가 아니다 그렇다고 기술적 정리를 무시하자는 뜻은 아니다. 크롤링을 막아놓거나, 중요한 내용을 이미지 안에만 넣거나, 제목과 본문이 서로 다르다면 좋은 원본도 발견되기 어렵다. 명확한 제목, 텍스트로 된 핵심 내용, 내부 링크, 정확한 구조화 데이터는 여전히 필요하다. 다만 이것은 해자가 아니라 배관이다. 모든 경쟁자가 같은 형식을 적용할 수 있고 AI도 그 형식을 즉시 복제할 수 있다. 배관이 깨끗하면 자산이 잘 흐르지만, 빈 배관에서 가치는 나오지 않는다. 측정도 같은 순서로 해야 한다. AI 노출 수만 보지 말고 어떤 원본 페이지가 반복해서 등장하는지, 그 페이지의 어떤 사실이 외부에서 인용되는지, 인용이 브랜드 검색·문의·가입 같은 다음 행동과 연결되는지를 본다. 노출을 늘리기 위해 원본과 무관한 문장을 양산하기 시작하면, 다시 트래픽 공장으로 돌아간 것이다. ## AI 시대의 콘텐츠 회사는 작은 연구소가 된다 AI가 설명을 무한히 공급할수록 콘텐츠의 중심은 작성에서 발견으로 이동한다. 좋은 콘텐츠팀은 원고를 빨리 뽑는 팀이 아니라 조직이 새로 알게 된 것을 포착하고, 검증하고, 공개하는 팀이 된다. 이 변화는 오히려 작은 팀에 유리할 수 있다. 거대한 미디어보다 특정 고객과 더 가까이 있고, 좁은 문제를 더 자주 관찰하며, 제품과 콘텐츠를 같은 학습 루프 안에서 움직일 수 있기 때문이다. 매주 한 번의 고객 대화, 한 번의 운영 실패, 한 번의 작은 실험을 제대로 남기면 남의 글 백 편을 요약하는 것보다 강한 자산이 쌓인다. AI는 그 자산을 더 명확한 문장과 여러 형식으로 바꾸는 데 쓸 수 있다. 하지만 무엇을 관찰할지 정하고, 어떤 증거를 믿을지 판단하며, 어디까지 말할 수 있는지 책임지는 일은 여전히 조직의 몫이다. **AI 검색에서 오래 남는 것은 가장 많은 글을 발행한 브랜드가 아니다. 다른 답변들이 돌아와 빌려갈 원본을 계속 만드는 브랜드다.** --- 주요 출처: Google Search Central의 [생성형 AI 성과 보고서 발표](https://developers.google.com/search/blog/2026/06/gen-ai-performance-reports?hl=en&ref=zerodraftlab.com), [AI 기능과 웹사이트 안내](https://developers.google.com/search/docs/appearance/ai-features?ref=zerodraftlab.com), [사람 중심 콘텐츠 가이드](https://developers.google.com/search/docs/fundamentals/creating-helpful-content?ref=zerodraftlab.com), [생성형 AI 콘텐츠 지침](https://developers.google.com/search/docs/fundamentals/using-gen-ai-content?hl=en&ref=zerodraftlab.com); [AI 검색 인용 선택·반영도 측정 연구](https://arxiv.org/abs/2604.25707?ref=zerodraftlab.com); 404 Media의 [Reddit 조작 의혹 보도](https://www.404media.co/companies-are-using-reddit-to-manipulate-chatgpt-and-google-ai-search/?ref=zerodraftlab.com). Search Console 생성형 AI 보고서는 2026년 7월 현재 일부 사이트 대상 시험 제공 단계입니다. 인용 연구는 정적 관찰 preprint이며, Reddit 사례는 운영진이 관찰한 의혹으로 특정 AI 답변에 대한 인과가 독립 검증된 사례로 취급하지 않았습니다. ### AI SaaS가 아니라 AI 노동을 팔아라 URL: https://zerodraftlab.com/ai-sells-labor-not-software/ Last updated: 2026-09-15T08:36:06.000Z 지난 20년 동안 소프트웨어는 사람의 일을 없앤다고 약속했다. 실제로 없앤 것은 종이와 서류함인 경우가 많았다. 해야 할 일은 대시보드, 입력폼, 알림함, 작업 큐로 옮겨갔다. 예전에는 종이에 적던 사람이 이제 브라우저에서 클릭한다. 그래서 작은 사업자의 문제는 소프트웨어가 없다는 것이 아니다. **소프트웨어를 계속 사람이 눌러야 한다는 것**이다. 치과를 생각해보자. 진료가 끝나도 일은 끝나지 않는다. 보험 포털에서 지급 내역을 내려받고, 진료관리 시스템에 입력하고, 환자 잔액을 확인하고, 청구서를 만들고, 반려된 청구를 다시 처리해야 한다. 시스템은 이미 여러 개다. 하지만 시스템 사이를 건너다니며 업무를 끝내는 사람도 여전히 필요하다. 이 지점에서 AI Agent는 기존 SaaS와 다른 상품이 된다. 더 좋은 화면을 파는 것이 아니라 **완료된 노동**을 팔 수 있기 때문이다. ## 좌석을 팔던 소프트웨어, 결과를 파는 소프트웨어 기존 SaaS의 기본 판매 단위는 좌석이었다. 사용자가 로그인해 기능을 쓰도록 만들고, 더 많은 사람이 더 자주 사용할수록 가치가 커졌다. 고객은 소프트웨어 비용과 함께 그 소프트웨어를 운영할 사람의 시간도 지불했다. AI 노동의 판매 단위는 다르다. 처리된 청구, 대조가 끝난 입금, 회수된 미수금, 예약이 확정된 고객처럼 **업무의 종료 상태**가 상품이 된다. 고객이 사고 싶은 것은 “보험금 정산 대시보드”가 아니라 “보험금 정산이 끝난 상태”다. 이 차이는 카피가 아니다. 제품 설계 전체를 바꾼다. 대시보드는 사용자가 판단하고 행동하도록 돕는다. Agent는 여러 시스템에서 필요한 정보를 찾고, 판단하고, 입력하고, 실패를 처리한 뒤, 결과를 정본에 남겨야 한다. 버튼 한 번을 대신 누르는 자동화가 아니라 업무 한 건의 생애주기를 책임져야 한다. Lassie의 공동창업자 Steijn Pelle는 자사 시스템이 미국 49개 주 700곳 이상의 사업장에서 작동하며, 사업장당 월평균 약 30시간의 노동을 제공한다고 썼다. Lassie 공식 사이트도 치과의 보험 청구, 지급 내역 대조, 환자 청구 같은 업무를 제품 범위로 제시한다. 이 숫자는 독립 연구가 아니라 회사와 창업자의 자기보고다. 그래도 무엇을 판매하려는지는 선명하다. 기능 사용량이 아니라 사람이 돌려받은 시간이다. ## 대시보드를 하나 더 만드는 것은 자동화가 아니다 많은 AI 제품이 Agent라는 이름을 달지만 실제로는 새로운 작업함을 만든다. AI가 초안을 만들면 사람이 검토하고, 다른 시스템에 복사하고, 오류를 고치고, 마지막 버튼을 누른다. 인터페이스는 새로워졌지만 책임은 그대로 사람에게 남는다. 진짜 자동화인지 확인하는 가장 간단한 질문은 이것이다. **“이 제품을 도입한 뒤 사람이 마지막으로 해야 하는 일은 무엇인가?”** 답이 복사, 확인, 승인, 재입력, 예외 추적이라면 노동은 제거되지 않았다. 위치만 바뀌었다. 반대로 정상 업무는 끝까지 처리되고, 사람은 위험하거나 모호한 예외만 맡는다면 소프트웨어는 처음으로 노동을 흡수하기 시작한다. 그렇다면 AI 노동 제품의 핵심 기능은 화려한 생성 화면이 아니다. 정상 경로의 데모를 넘어, 업무를 정말 끝냈다고 믿게 만드는 완전성과 신뢰성이다. 완전성은 한 번의 정답률보다 더 까다롭다. 작은 사업장의 행정업무는 하나의 깨끗한 API 안에서 끝나지 않는다. 오래된 보험 포털, 각기 다른 진료관리 시스템, 은행 계좌, 이메일, PDF가 연결되어 있다. 로그인 세션이 끊기고, 화면 구조가 바뀌고, 같은 항목도 시스템마다 이름이 다르다. 정상 처리보다 예외 처리가 제품의 대부분이 된다. ## AI 노동은 모델보다 운영 시스템에 가깝다 이런 환경에서 “모델이 얼마나 똑똑한가”만 묻는 것은 부족하다. 더 중요한 질문은 업무가 중간에 멈췄을 때 무엇이 일어나는가다. 재시도는 중복 청구를 만들지 않는가. 입력한 값은 원본과 대조되는가. 확신이 낮은 사건은 사람에게 올라오는가. 누가 언제 무엇을 바꿨는지 기록되는가. 잘못된 행동을 되돌릴 수 있는가. 따라서 AI 노동 제품에는 최소한 네 가지가 필요하다. 1. **종료 조건:** 무엇이 되어야 업무 한 건이 끝난 것인지 명확해야 한다. 2. **예외 큐:** 자동으로 끝낼 수 없는 사건만 사람에게 올라와야 한다. 3. **검증과 감사 기록:** 결과가 원본 시스템과 일치하는지 확인하고 행동 이력을 남겨야 한다. 4. **복구 경로:** 외부 시스템이 실패해도 중복 없이 재개하거나 안전하게 되돌릴 수 있어야 한다. 이 네 가지가 없으면 Agent는 유능한 인턴처럼 보일 수는 있어도 운영을 맡길 직원처럼 행동하지 못한다. 특히 의료·금융처럼 민감정보와 돈을 다루는 영역에서는 평균 정확도보다 틀렸을 때의 통제가 제품의 신뢰를 결정한다. ## 고객 인터뷰보다 고객의 의자에 앉아야 한다 Lassie 사례에서 가장 중요한 대목은 기술보다 제품개발 방식이다. 창업팀은 치과와 병원에서 수개월 동안 직접 행정업무를 수행했다고 설명한다. 보험 지급 내역을 대조하고, 청구를 제출하고, 환자에게 비용을 청구했다. 초기 100개 사업장에는 직접 찾아가 설치했다. 이 방식이 중요한 이유는 고객이 자신의 업무를 정확히 설명하기 어렵기 때문이다. 인터뷰에서는 “청구 자동화가 필요하다”고 말할 수 있다. 실제 업무에 들어가면 포털별 로그인 방식, 지급 코드의 예외, 동명이인, 이미 처리된 건, 누락된 문서, 담당자만 아는 우회 절차가 보인다. 제품의 진짜 명세는 정상 절차가 아니라 이 예외의 목록에서 나온다. AI 노동을 만들려는 팀에게 현장 투입은 사용자 조사보다 가깝게는 수작업 서비스다. 먼저 사람이 고객 대신 일을 끝내면서 입력, 판단, 예외, 승인, 종료 조건을 기록한다. 반복되는 판단만 자동화하고, 자동화가 실패하는 지점은 다시 운영 데이터로 남긴다. Agent는 이 노동의 압축본이어야 한다. ## AI 시대의 SaaS 지표도 달라져야 한다 로그인 횟수와 화면 체류시간은 AI 노동의 성공을 설명하지 못한다. 고객이 제품을 덜 열어볼수록 더 잘 작동하는 경우도 있기 때문이다. 대신 완료된 업무량, 돌려받은 시간, 예외율, 사람의 개입 시간, 재작업률, 금전 오류, 완료까지 걸린 시간을 봐야 한다. 이 변화는 사업모델에도 이어진다. 좌석당 과금은 도구 사용권을 판다. 처리량이나 결과 기반 과금은 노동의 일부를 판다. 후자는 더 큰 가치를 가져갈 수 있지만, 동시에 결과에 대한 더 큰 책임을 진다. “AI를 붙였다”는 이유가 아니라 고객의 운영비와 실패 비용을 실제로 줄였다는 증거가 필요하다. 다음 AI 시장의 승자는 대시보드에 채팅창을 붙인 회사가 아닐 가능성이 크다. 고객이 매일 미뤄두던 일을 조용히 끝내고, 문제가 생겼을 때만 정확한 맥락과 함께 사람을 부르는 회사일 것이다. **AI SaaS의 다음 단위는 사용자 좌석이 아니다. 믿고 맡길 수 있는 한 시간의 노동이다.** --- 출처: Steijn Pelle, [Small Businesses Are the Next Frontier for AI](https://www.a16z.news/p/small-businesses-are-the-next-frontier?ref=zerodraftlab.com); [Lassie 공식 사이트](https://www.lassie.ai/?ref=zerodraftlab.com). 사업장 수와 절감 시간은 저자와 회사의 자기보고 수치이며 독립 검증된 연구 결과로 취급하지 않았습니다. ### 에이전트보다 대시보드를 먼저 만들어라 URL: https://zerodraftlab.com/dashboard-before-agent/ Last updated: 2026-09-15T08:36:07.000Z AI 에이전트를 만들겠다는 팀은 대개 행동부터 설계한다. 고객에게 메일을 보내고, 늦은 업무를 독촉하고, 보고서를 만들고, 다음 조치를 스스로 결정하게 하려 한다. 순서가 거꾸로다. 에이전트가 무엇을 해야 하는지 정하기 전에, 지금 무슨 일이 벌어지고 있는지 볼 수 있어야 한다. 고객이 어디에서 멈췄는지, 어떤 일이 늦었는지, 누가 마지막으로 행동했는지 모르는 상태에서 자동화를 붙이면 그럴듯한 메시지는 만들 수 있어도 믿을 만한 운영은 만들 수 없다. **데이터 없는 에이전트는 영리한 데모다. 실제 제품은 대시보드에서 시작한다.** ## 20개 에이전트도 처음에는 대시보드였다 SaaStr는 프로덕션에서 20개가 넘는 에이전트를 운영한다고 말한다. 그런데 자체 개발한 에이전트들은 처음부터 에이전트가 아니었다. 먼저 사람이 쓰는 대시보드를 만들고, 데이터가 흐르게 한 뒤, 그 위에 자동화 계층을 얹었다. 대표 사례가 행사 스폰서를 관리하는 QBee다. 현재 QBee는 100개가 넘는 스폰서 계정과 13개 핵심 업무를 추적한다. 계정마다 개인화한 주간 메일을 보내고, 지연 작업을 찾아내며, 팀에 매일 상태를 보고하고, 마감 독촉과 수금까지 지원한다. 하지만 출발점은 평범한 스폰서 포털이었다. 기존 포털에서는 로그인을 했는지조차 제출이 발생하기 전까지 알기 어려웠다. 새 포털의 첫 요구사항도 단순했다. 업무를 배정하고, 로그인을 쉽게 만들고, 다음 할 일을 가볍게 알려주는 것이었다. 실제 고객 네 곳에서 먼저 운영하며 고장을 고쳤고, 그 과정에서 처음으로 쓸 만한 행동 데이터가 쌓였다. SaaStr는 QBee가 고객 관리에 드는 사람의 시간을 70% 이상 줄이고, 고객 로그인과 정시 제출을 10배 이상 늘렸다고 주장한다. 인상적인 수치지만 독립적으로 검증된 연구 결과는 아니다. SaaStr가 자사 운영 사례를 바탕으로 공개한 자기보고 수치로 읽어야 한다. ## 대시보드는 화면이 아니라 관찰 장치다 대시보드의 가치는 차트를 예쁘게 보여주는 데 있지 않다. 운영 상태를 구조화하는 데 있다. 고객, 담당자, 해야 할 일, 완료 여부, 마감일, 마지막 로그인, 다음 행동이 같은 문법으로 기록되면 조직은 비로소 반복을 볼 수 있다. 예를 들어 “스폰서 대응을 자동화하자”는 요구는 너무 크고 모호하다. 반면 “마감 7일 전인데 로고를 제출하지 않은 스폰서에게 담당자 이름과 부스 번호를 포함한 안내를 보낸다”는 행동은 자동화할 수 있다. 필요한 상태, 조건, 메시지, 책임자가 모두 보이기 때문이다. 이 차이가 중요하다. 에이전트는 빈 공간에서 판단하지 않는다. 이미 관찰되고 있는 상태에 규칙과 언어를 더한다. 무엇을 개인화할지, 언제 개입할지, 누구에게 보고할지는 대시보드에 남은 데이터가 결정한다. 그래서 첫 질문은 “어떤 에이전트를 만들까?”가 아니다. **“사람이 지금 반복해서 확인하는 상태는 무엇인가?”**다. 그 상태를 한 화면에 모으면 두 번째 질문이 생긴다. “이 가운데 매번 같은 조건에서 반복되는 행동은 무엇인가?” 자동화는 그때부터 시작된다. ## 데이터를 한곳에 복사할 필요는 없다 SaaStr가 말하는 대시보드는 모든 데이터를 새 데이터베이스에 다시 넣는 시스템이 아니다. QBee는 계약과 계정 정보를 Salesforce에서, 인증 상태를 Clerk에서, 발송 결과를 Resend에서 읽는다. 다른 도구인 10K도 Salesforce와 등록 시스템, 마케팅 도구, 여러 공급자 API의 데이터를 연결해 하나의 운영 화면을 만든다. 원본 데이터는 그 데이터를 책임지는 시스템에 남는다. 대시보드는 여러 정본을 현재 시점의 한 장면으로 조립한다. 이 구조가 중요한 이유는 에이전트보다 사람에게 먼저 신뢰를 주기 때문이다. 영업팀 숫자와 마케팅팀 숫자가 다르고 기준일도 모호하다면, 그 위에 올라간 에이전트의 판단 역시 믿기 어렵다. 내부 도구를 만들 때도 같은 원칙을 적용할 수 있다. 계약은 계약 시스템, 결제는 결제 시스템, 업무 상태는 업무 관리 시스템이 책임진다. 새 대시보드는 원본의 소유권을 빼앗는 대신, 결정에 필요한 필드와 기준일을 읽어 하나의 업무 상태로 보여준다. 연결할 수 없는 데이터만 최소한으로 직접 보관한다. ## 자동화는 네 층으로 올린다 QBee가 확장된 순서는 에이전트의 기능 목록보다 유용하다. 1. **개인화:** 이미 수집된 업무 상태를 이용해 계정별 주간 메일을 작성한다. 2. **트리거:** 고객이 특정 업무를 했거나 하지 않았을 때 다음 행동을 실행한다. 3. **보고와 누락 탐지:** 팀이 매일 보는 상태 보고를 만들고, 사람이 놓친 빈칸을 표시한다. 4. **선제 행동:** 마감 독촉과 수금처럼 결과에 직접 영향을 주는 행동을 수행한다. 여기서 핵심은 자율성의 양이 아니라 실패 비용이다. 개인화 초안이 틀리면 사람이 고칠 수 있다. 내부 보고가 빠뜨린 항목도 다음 검토에서 잡을 수 있다. 하지만 잘못된 독촉이나 수금 메시지는 고객 관계와 돈을 건드린다. 뒤로 갈수록 데이터의 정확성, 승인 권한, 중복 실행 방지, 되돌리기 절차가 더 엄격해야 한다. 따라서 “완전 자율 에이전트”는 시작 요구사항이 될 수 없다. 처음에는 사람이 버튼을 누르고 결과를 확인한다. 반복 정확도가 쌓이면 내부 보고를 자동으로 보낸다. 그다음 낮은 위험의 외부 행동을 제한적으로 허용한다. 돈, 계약, 계정 정지처럼 되돌리기 어려운 행동은 마지막까지 승인 단계를 남긴다. ## 내부 도구는 이 다섯 질문에서 시작한다 에이전트 아이디어가 생겼다면 기능 명세를 쓰기 전에 다음 다섯 질문에 답하는 편이 낫다. 1. **매일 이 화면을 볼 실제 사용자는 누구인가?** 사용자가 없다면 데이터도 쌓이지 않는다. 2. **그 사람이 반복해서 확인하는 상태는 무엇인가?** 고객, 업무, 마감, 금액처럼 변화를 추적할 대상을 고른다. 3. **각 상태의 정본은 어디인가?** 대시보드 숫자와 원본 시스템의 숫자가 갈라지지 않게 한다. 4. **어떤 조건에서 같은 행동이 반복되는가?** 직감이 아니라 실제 운영 기록에서 자동화 후보를 찾는다. 5. **틀렸을 때 누가 멈추고 되돌릴 수 있는가?** 자동화의 권한은 실패 비용에 맞춘다. 이 질문에 답하면 첫 버전은 의외로 작아진다. 로그인, 핵심 상태표, 담당자, 마감일, 다음 행동 정도면 충분할 수 있다. 그 화면을 실제 사용자에게 주고 몇 주간 운영하면 예상하지 못했던 병목이 드러난다. 에이전트의 진짜 명세는 회의실의 상상이 아니라 그 병목에서 나온다. ## 에이전트는 제품이 아니라 축적된 운영의 결과다 대시보드부터 만든다는 말은 AI를 나중으로 미루자는 뜻이 아니다. AI가 행동할 수 있는 현실의 좌표를 먼저 만들자는 뜻이다. 무엇이 정상이고, 무엇이 늦었고, 누구에게 어떤 정보가 필요한지 기록되지 않으면 모델은 유창하게 추측할 수밖에 없다. 좋은 내부 도구는 처음부터 사람을 없애려 하지 않는다. 사람의 일을 보이게 만들고, 반복을 발견하고, 낮은 위험부터 자동화한다. 그러다 어느 순간 대시보드는 단순한 화면이 아니라 조직의 관찰 장치가 되고, 에이전트는 그 위에서 움직이는 실행 계층이 된다. **대시보드가 먼저다. 데이터가 흐른 다음에야 에이전트가 무엇을 해야 하는지 알 수 있다.** --- 출처: SaaStr, [One Way to Build a Great AI Agent? Just Start With a Dashboard. Then Add the Agent.](https://www.saastr.com/one-way-to-build-a-great-ai-agent-just-start-with-a-dashboard-then-add-the-agent/?ref=zerodraftlab.com) 본문의 QBee 운영 규모와 성과 수치는 SaaStr의 자기보고 사례이며 독립 검증된 연구 결과로 취급하지 않았습니다. ### AI의 진짜 비용은 토큰이 아니라 확신에 찬 오답이다 URL: https://zerodraftlab.com/ai-confidence-cost/ Last updated: 2026-09-15T08:36:07.000Z 회사가 AI 도입 비용을 계산할 때 가장 먼저 보는 숫자는 토큰 사용량이다. 모델별 단가를 비교하고, 월 예산을 정하고, 비싼 호출을 싼 모델로 옮긴다. 모두 필요한 일이다. 하지만 더 비싼 비용은 청구서에 찍히지 않는다. **틀린 판단이 그럴듯한 문서가 되어 조직 안을 이동하는 비용**이다. AI가 만든 문서는 빠르다. 목차가 있고, 표가 있고, 문장이 단정하다. 질문을 받으면 곧바로 근거처럼 보이는 설명도 붙인다. 그래서 내용의 정확성과 무관하게 작성자가 충분히 조사했다는 인상을 만든다. 예전에는 20쪽짜리 전략 문서를 만드는 데 걸린 시간이 최소한의 마찰이었다. 이제 그 마찰은 사라졌지만, 검증까지 자동으로 끝난 것은 아니다. ## 매끄러운 문서는 검증의 증거가 아니다 제품 전략가 Leah Tharin은 [AI의 진짜 비용을 다룬 글](https://www.leahtharin.com/p/token-usage-is-the-least-thing-that?ref=zerodraftlab.com)에서 익명 사례 세 가지를 소개한다. 한 Series A CEO는 고객 조사를 Claude에 맡기고 그 결과를 회사 전략으로 확정했다. 200명 규모 B2B SaaS의 CEO는 예산표 하나를 ChatGPT에 넣어 20쪽짜리 전략 문서를 만들었다. 한 PM은 전체 사용자 수를 특정 기능 사용자 수로 잘못 읽어 리디자인 효과를 85% 과대평가했다. 이 사례들은 독립적으로 감사된 통계가 아니다. 저자가 현장에서 관찰한 익명 사례다. 그래도 세 장면이 가리키는 고장은 같다. AI가 틀린 숫자를 만든 것이 아니라, 사람이 불완전한 입력을 넣고 검증하지 않은 출력을 조직의 사실로 승격했다. 문제는 환각만이 아니다. 모델은 사용자가 “전환율은 15%다”라고 쓰면 그 숫자의 출처를 알 수 없다. 실험 결과인지, 대시보드를 잘못 읽은 것인지, 회의에서 누군가 말한 추정치인지 구분하지 못한다. 주어진 전제를 사실로 받아들이고 그 위에서 가장 자연스러운 다음 문장을 만든다. ## 설명은 오답을 더 믿게 만들 수도 있다 2025년 CHI에 발표된 [Microsoft Research의 사전 등록 통제실험](https://www.microsoft.com/en-us/research/publication/fostering-appropriate-reliance-on-large-language-models-the-role-of-explanations-sources-and-inconsistencies/?ref=zerodraftlab.com)은 308명을 대상으로 LLM 답변의 설명, 출처, 불일치가 신뢰에 미치는 영향을 살폈다. 설명이 붙으면 참가자들은 정답뿐 아니라 오답에도 더 의존했다. 반대로 출처가 제시되거나 설명 안의 불일치가 드러나면 잘못된 답에 대한 의존이 줄었다. 설명이 있다는 사실과 설명이 맞다는 사실은 다르다. 그러나 사람은 유창한 인과관계를 만나면 검토가 끝났다고 느끼기 쉽다. AI가 낸 답에 “근거도 설명해줘”라고 한 번 더 묻는 것만으로는 안전장치가 되지 않는 이유다. 같은 모델이 자신의 첫 답을 방어하는 문장을 더 길게 만들 수 있기 때문이다. 또 다른 [CHI 2025 연구](https://www.microsoft.com/en-us/research/publication/the-impact-of-generative-ai-on-critical-thinking-self-reported-reductions-in-cognitive-effort-and-confidence-effects-from-a-survey-of-knowledge-workers/?ref=zerodraftlab.com)는 지식노동자 319명에게서 936개의 실제 AI 사용 사례를 모았다. 연구진은 AI에 대한 신뢰가 높을수록 비판적 사고 노력이 줄고, 자신의 과업 능력에 대한 자신감이 높을수록 비판적 사고가 늘어나는 연관을 관찰했다. AI 시대에 필요한 능력은 프롬프트를 길게 쓰는 기술만이 아니다. 결과가 이상하다는 것을 알아볼 수 있는 도메인 판단력이다. 여기서 비용의 단위가 바뀐다. 토큰 비용은 호출 직후 보인다. 잘못된 ICP를 따라 만든 제품, 과대평가된 실험을 따라 투입한 두 달, 틀린 전략에 정렬된 조직의 비용은 몇 달 뒤에 나타난다. 전자는 몇 달러지만 후자는 사람과 자본의 방향을 바꾼다. 그 방향을 실제로 바꾸는 힘은 AI에게서 나오지 않는다. AI의 문장을 조직의 사실로 승인한 사람과, 그 승인이 통과한 절차에서 나온다. 그래서 이 문제의 핵심은 더 좋은 프롬프트가 아니라 **확신이 만들어지고 유통되는 방식**이다. ## 확신은 개인의 성격이 아니라 조직의 공급망이다 한 문서가 의사결정을 바꾸기까지는 여러 손을 거친다. 누군가 데이터를 꺼내고, 누군가 의미를 붙이고, 누군가 문장으로 정리하고, 마지막 사람이 예산이나 일정을 승인한다. 이 과정에서 원래의 불확실성은 조금씩 지워진다. “아마 그럴 것”은 보고서에서 “그렇다”가 되고, 회의 자료에서는 “우리가 아는 사실”이 된다. AI는 이 공급망을 새로 만든 것이 아니다. 다만 속도를 높이고 흔적을 줄였다. 예전에는 숫자를 잘못 읽은 사람이 계산 과정을 남겼고, 문서를 만든 사람이 왜 그렇게 썼는지 기억했다. 이제는 질문 한 줄과 매끄러운 결과 사이의 변환 과정이 보이지 않는다. 문장은 더 단정해졌지만, 누가 무엇을 확인했는지는 오히려 흐려진다. 가령 “전환율은 15%다”라는 문장이 있다고 하자. 모델은 이 숫자가 실험 결과인지, 지난달 대시보드인지, 회의에서 나온 추정인지 모른다. 그러나 그 숫자로 시장 규모와 성장 계획을 설명할 수는 있다. 설명이 길어질수록 처음의 미확인 숫자는 더 많은 결론을 지탱하고, 나중에는 되돌리기 어려운 전제가 된다. 앞서 본 308명 대상 실험에서 설명이 정답과 오답 모두에 대한 의존을 높였다는 결과가 중요한 이유도 여기에 있다. 사람은 설명을 보면 근거가 추가됐다고 느끼지만, 실제로는 하나의 미확인 전제가 더 많은 문장을 얻었을 뿐일 수 있다. 반대로 출처와 설명 내부의 불일치가 보이면 잘못된 답에 대한 의존이 줄었다. 신뢰를 안전하게 만드는 것은 더 매끄러운 설명이 아니라, 설명이 깨질 수 있는 지점을 보이게 하는 일이다. ## 좋은 조직은 답보다 반증 경로를 남긴다 이 관점에서 책임은 모든 문장을 다시 조사하는 노동이 아니다. 무엇을 직접 확인했고, 무엇을 계산했으며, 무엇을 아직 가설로 두었는지 구분하는 일이다. 중요한 숫자에는 링크 하나보다 계보가 필요하다. 어떤 원자료에서, 어떤 기간과 분모로, 누가 꺼냈고, 그 숫자가 어떤 결정을 바꾸려 하는지가 보여야 한다. 2026년에 공개된 [AI 글쓰기 계획 검토 실험](https://arxiv.org/abs/2601.18033?ref=zerodraftlab.com)은 이 방향을 보조한다. 참가자에게 AI 계획의 가정을 직접 분석하게 했을 때, 인지부하를 늘리지 않으면서 과의존이 가장 크게 줄었다. 아직 동료심사 전 preprint라 일반 법칙으로 볼 수는 없다. 그래도 “다시 확인하세요”라는 경고보다 “이 계획이 성립하려면 무엇이 참이어야 하는가”라는 질문이 더 강한 마찰을 만든다는 점은 선명하다. 반증 경로가 남아 있으면 오류는 실패로 끝나지 않는다. 어떤 전제가 무너졌는지 알 수 있고, 다음 문서에서 같은 전제를 더 일찍 의심할 수 있다. 반대로 결론만 남으면 조직은 틀린 이유를 배우지 못한 채 사람이나 모델만 바꾼다. ## 마찰을 넣으면 AI의 속도를 잃지 않을까 여기에는 당연한 반론이 있다. 매번 출처와 가정을 확인하면 AI로 얻은 속도를 다시 잃는 것 아니냐는 질문이다. 실제로 모든 이메일과 초안에 같은 검증 절차를 적용하면 그렇다. 검증이 관료제가 되면 사람은 형식만 채우고, 중요한 의심은 더 잘 숨겨진다. 그래서 경계는 “AI를 썼는가”가 아니라 “이 문장이 무엇을 움직이는가”에 놓여야 한다. 표현을 다듬는 문장과 가격을 바꾸는 문장은 같은 검증 비용을 요구하지 않는다. 되돌리기 쉬운 초안에는 속도를 허용하고, 채용·해고·의료·법무·대규모 예산처럼 되돌리기 어려운 판단에는 더 많은 증거를 요구해야 한다. 이것은 AI에 대한 불신이 아니다. 회계에서 큰 금액에 더 강한 통제를 두고, 코드에서 위험한 변경에 더 깊은 리뷰를 요구하는 것과 같다. 속도를 포기하는 대신 실패 비용에 맞춰 마찰을 배치하는 일이다. ## 지식노동자의 역할은 작성자에서 증거의 관리자로 바뀐다 319명의 지식노동자에게서 936개의 실제 사례를 모은 CHI 연구는 생성형 AI가 비판적 사고를 없애기보다 그 위치를 바꾼다고 설명했다. 직접 문장을 만드는 노력은 줄지만, 정보 검증과 응답 통합, 과업 관리의 중요성은 커진다. 앞으로의 지식노동자는 모든 문장을 직접 쓰는 사람보다 어떤 문장이 사실이 될 자격이 있는지 관리하는 사람에 가까워진다. 이 변화는 AI 활용 능력의 기준도 바꾼다. 프롬프트를 잘 쓰고 문서를 빨리 만드는 능력만으로는 부족하다. 자신이 무엇을 알고 무엇을 가정하는지, 어떤 증거가 나오면 결론을 바꿀지 말할 수 있어야 한다. 확신을 크게 만드는 사람보다 확신의 한계를 정확히 표시하는 사람이 더 믿을 만해진다. 토큰은 계속 싸질 것이다. 문서는 더 빨리 만들어지고, 설명은 더 그럴듯해질 것이다. 그래서 희소해지는 것은 생성 능력이 아니라 판단의 계보다. **AI를 잘 쓰는 조직은 가장 많은 답을 만드는 조직이 아니라, 어떤 답이 사실이 될 자격이 있는지 끝까지 추적할 수 있는 조직이다.** --- 주요 출처: Leah Tharin의 현장 에세이, Microsoft Research의 CHI 2025 연구 2편, 2026년 인지적 강제장치 실험 preprint. 익명 사례는 저자의 관찰로만 인용했으며 독립 검증된 통계로 취급하지 않았습니다. ### 에이전트가 많아질수록 회사에는 기억층이 필요하다 URL: https://zerodraftlab.com/agent-company-needs-memory-layer/ Last updated: 2026-07-11T12:53:52.000Z 에이전트가 회사 안으로 들어오면 많은 사람은 실행 속도부터 본다. 세일즈 agent가 리드를 찾고, 코딩 agent가 PR을 만들고, 고객지원 agent가 답변하고, 프로젝트 매니저 agent가 이슈를 정리한다. 멋진 그림이다. 하지만 실행층만 늘리면 회사는 더 똑똑해지는 것이 아니라 더 시끄러워질 수 있다. 에이전트가 많아질수록 회사에는 더 강한 기억층이 필요하다. ## 실행층은 기억층 없이는 오래 못 간다 agent는 일을 처리할 수 있다. 하지만 무엇을 기준으로 처리해야 하는지, 지금 회사가 어떤 결정을 이미 했는지, 고객과 어떤 약속을 했는지, 어떤 말은 쓰면 안 되는지, 어떤 예외는 사람에게 넘겨야 하는지 모르면 실행은 쉽게 흩어진다. 사람 팀에서도 같은 문제가 있다. 신입이 들어오면 회사의 맥락을 배워야 한다. 어떤 고객이 중요한지, 어떤 프로젝트가 민감한지, 어떤 결정은 이미 실패했는지, 어떤 표현은 조직 안에서 위험한지 배운다. agent도 다르지 않다. 다만 agent는 모르는 상태에서도 자신 있게 실행하기 때문에 문제가 더 빠르게 드러난다. 그래서 에이전트 회사의 핵심은 agent 수가 아니다. agent가 읽고 실행할 수 있는 조직의 기억이다. ## 문서는 저장소가 아니라 실행 조건이 된다 기존 문서는 사람이 나중에 찾아보는 보관소에 가까웠다. 회의록, 정책, PRD, 고객 메모, 회고, 가이드가 어딘가에 있었다. 잘 정리되어 있으면 좋았지만, 대충 흩어져 있어도 사람은 눈치와 대화로 메웠다. 에이전트 환경에서는 문서의 성격이 달라진다. 문서는 실행 조건이 된다. agent가 어떤 일을 시작하기 전에 읽어야 할 기준이고, 어떤 판단을 했는지 남기는 로그이고, 다음 실행이 참조하는 memory가 된다. 이때 필요한 것은 단순한 wiki가 아니다. agent-readable한 운영 기억층이다. - 현재 목표와 하지 않기로 한 일 - 고객별 약속과 민감한 맥락 - 제품/서비스의 금지 조건과 예외 처리 - 반복 업무의 입력과 출력 포맷 - 사람이 최종 판단해야 하는 위험 구간 이런 정보가 없으면 agent는 일을 많이 하지만 회사는 배우지 못한다. ## 에이전트 회사의 병목은 모델이 아니다 모델 성능은 계속 올라간다. 더 긴 컨텍스트, 더 빠른 추론, 더 좋은 도구 호출, 더 안정적인 코딩 능력이 나온다. 하지만 회사 안에서 실제 병목은 모델 하나의 지능보다 연결이다. 일감은 어디서 생기는가. 누가 우선순위를 정하는가. 어떤 기준으로 agent에게 넘기는가. 결과는 어디에 남는가. 실패는 어떻게 복구되는가. 학습은 다음 작업에 어떻게 반영되는가. 이 질문에 답하지 못하면 회사는 agent를 많이 붙이고도 계속 같은 설명을 반복한다. 사람은 agent에게 맥락을 먹이는 일을 하느라 바빠지고, agent는 같은 실수를 다른 모양으로 반복한다. 그러면 자동화는 생산성이 아니라 새로운 관리 비용이 된다. ## 사람은 사라지는 게 아니라 판단 루프가 된다 기억층이 생긴다고 사람이 사라지지는 않는다. 오히려 사람의 역할은 더 선명해진다. 사람은 모든 태스크를 직접 처리하는 대신, 목표를 정하고, 예외를 판단하고, 기준을 고치고, 다음 실행에 남길 학습을 결정한다. 좋은 agent 회사는 사람을 제거한 회사가 아니다. 사람의 판단을 반복 가능한 루프 안에 넣은 회사다. 에이전트가 실행층이라면, 사람은 판단층이고, 문서는 기억층이다. 세 층이 같이 움직여야 회사가 배운다. > 에이전트가 많아질수록 필요한 것은 더 많은 자동화가 아니라, 더 읽기 쉬운 회사의 기억이다. 이것이 에이전트 시대의 회사 설계가 어려운 이유다. 도구를 붙이는 일은 쉽다. 조직의 기억과 판단 기준을 agent가 읽고 실행할 수 있는 형태로 바꾸는 일이 어렵다. 하지만 해자는 바로 거기서 생긴다. --- **Source note.** 이 글은 Zero Draft Lab 내부 초안 *“에이전트 시대의 회사는 실행층과 기억층을 다시 짜야 한다”*와 사이트 안의 에이전트 회사 큐레이션 카드들을 바탕으로 독립 아티클화한 초안입니다. ### AI-native agency는 도구 사용이 아니라 delivery system이다 URL: https://zerodraftlab.com/ai-native-agency-is-delivery-system/ Last updated: 2026-07-11T12:53:56.000Z AI-native agency라는 말은 쉽게 오해된다. 많은 사람은 그 말을 “AI 도구를 많이 쓰는 대행사”로 듣는다. 직원들이 ChatGPT를 잘 쓰고, 콘텐츠 초안을 빨리 만들고, 리서치를 빠르게 돌리고, 리포트 작성 시간을 줄이는 모습이다. 그건 시작점일 수는 있다. 하지만 그것만으로는 agency의 구조가 바뀌지 않는다. AI-native agency의 핵심은 tool adoption이 아니라 delivery system이다. 서비스를 제공하는 방식 자체가 반복 가능한 루프와 agent가 읽을 수 있는 작업 단위로 바뀌어야 한다. ## 스킬은 개인에게 남고, 루프는 회사에 남는다 AI 도입의 첫 단계는 skills다. 개인이 더 빨리 조사하고, 더 빨리 쓰고, 더 빨리 정리한다. 이 단계는 중요하지만 취약하다. 잘하는 사람에게 성과가 몰리고, 그 사람이 빠지면 성과도 같이 빠진다. 다음 단계는 loops다. 반복 업무를 입력, 처리, 검토, 출력의 구조로 바꾸는 것이다. “고객 사이트를 분석한다”는 말은 너무 넓다. “매주 새로 생긴 페이지를 가져오고, 검색 의도와 내부 링크를 점검하고, 우선순위가 높은 수정안을 만든다”는 루프다. 루프가 생기면 회사는 개인의 감각을 조금씩 시스템으로 옮길 수 있다. 무엇을 입력으로 받을지, 어떤 기준으로 판단할지, 어떤 형태로 출력할지 정할 수 있다. 그때부터 agent는 단순한 글쓰기 도구가 아니라 업무 흐름 안의 작업자가 된다. ## agent는 루프 안에서만 쓸모 있다 agent에게 “이 고객 SEO 좀 봐줘”라고 말하면 결과가 흔들린다. agent는 무언가를 하긴 하지만, 무엇을 기준으로 잘했다고 봐야 하는지 모른다. 어디까지 해도 되는지, 무엇은 사람에게 넘겨야 하는지, 결과를 어떤 형식으로 남겨야 하는지 모른다. 반대로 루프가 있으면 agent의 역할이 분명해진다. - 새 페이지를 수집한다. - 검색 의도와 기존 콘텐츠의 겹침을 본다. - 내부 링크 후보를 제안한다. - 수정 우선순위를 매긴다. - 사람이 봐야 할 예외만 표시한다. 이렇게 되면 사람의 역할도 달라진다. 모든 일을 직접 하는 사람이 아니라 reviewer, exception handler, strategist가 된다. agent가 많아질수록 사람은 더 높은 판단을 해야 한다. ## 오케스트레이션은 자동화보다 어렵다 AI-native agency가 진짜로 달라지는 지점은 orchestration이다. sales, onboarding, fulfillment, reporting, renewal이 따로 놀지 않고 하나의 흐름으로 이어지는 상태다. 영업에서 고객이 말한 문제가 onboarding에 전달되고, onboarding에서 수집한 정보가 fulfillment loop의 입력이 되고, fulfillment 결과가 reporting으로 이어지고, reporting의 학습이 renewal과 다음 액션으로 돌아온다. 이 구조가 없으면 AI는 부서별 작은 자동화로 흩어진다. 리서치는 빨라졌지만 영업 메시지는 그대로고, 콘텐츠 생산은 늘었지만 고객 보고는 여전히 수작업이고, agent는 많지만 누구도 전체 흐름을 보지 않는다. 오케스트레이션은 “더 많은 자동화”가 아니다. 일을 어디서 시작해 어디서 끝낼지, 어떤 상태가 다음 단계의 입력이 되는지, 어떤 실패를 사람이 봐야 하는지 정하는 운영 설계다. ## AI 사용량은 해자가 아니다 AI를 많이 쓰는 것은 곧 흔해진다. 모델은 모두가 산다. 도구도 모두가 쓴다. 프롬프트 템플릿도 복제된다. 그러면 남는 것은 무엇인가. 남는 것은 업무 구조다. 어떤 고객을 받을지. 어떤 문제를 반복 해결할지. 어떤 데이터를 입력으로 삼을지. 어떤 산출물을 표준으로 둘지. 어떤 기준으로 품질을 볼지. 어떤 예외를 사람에게 넘길지. 어떤 학습을 다음 주 루프에 반영할지. 이것들이 agency의 실제 자산이다. AI-native agency의 경쟁력은 AI 사용량이 아니다. 일을 반복 가능한 delivery system으로 바꾸는 능력이다. 그리고 그 능력은 툴 목록보다 운영 언어에서 먼저 드러난다. > AI를 쓰는 회사가 아니라, 일이 agent가 들어갈 수 있는 모양으로 정리된 회사가 AI-native다. --- **Source note.** 이 글은 Zero Draft Lab 내부 초안 *“2명이 400만 달러를 버는 에이전시라는 말에서 봐야 할 것”*에서 AI-native delivery 구조 파트만 분리한 아티클입니다. ### 고마진은 AI가 아니라 좁은 오퍼에서 나온다 URL: https://zerodraftlab.com/agency-margin-is-offer-design/ Last updated: 2026-07-11T12:53:58.000Z AI-native agency 이야기를 들으면 사람들은 먼저 도구를 묻는다. 어떤 모델을 쓰나. 어떤 자동화 툴을 붙였나. 리서치, 글쓰기, 리포트, CRM 업데이트를 어디까지 agent에게 맡겼나. 물론 중요하다. 하지만 고마진 작은 팀을 만드는 첫 조건은 도구가 아니다. 첫 조건은 좁은 오퍼다. 2명이 연매출 수백만 달러를 만들었다는 식의 사례를 볼 때 숫자부터 믿으면 위험하다. 80% profit margin 같은 숫자는 일반 agency benchmark와 잘 맞지 않는다. 그 숫자가 가능하려면 그 사업은 우리가 흔히 아는 대행사가 아니어야 한다. 사람 시간을 팔고, 고객마다 다른 일을 받아 처리하고, 미팅과 수정과 승인으로 마진이 새는 구조라면 AI를 붙여도 마법은 일어나지 않는다. 고마진은 headcount를 줄인다고 생기지 않는다. 일이 반복 가능한 모양을 가질 때 생긴다. ## 넓은 오퍼는 자동화되지 않는다 “SEO 해드립니다”는 넓다. 넓은 말은 고객에게 편해 보이지만 운영자에게는 지옥이다. 고객마다 업종이 다르고, CMS가 다르고, 내부 승인 구조가 다르고, 콘텐츠 자산의 품질이 다르고, 대표가 원하는 것도 다르다. 어떤 고객은 키워드 리서치가 필요하고, 어떤 고객은 technical SEO가 문제고, 어떤 고객은 콘텐츠보다 sales page가 문제다. 이 상태에서 AI를 붙이면 조금 빨라질 뿐이다. 문제 자체가 매번 달라지기 때문이다. 자동화는 반복을 먹고 산다. 반복되지 않는 일을 자동화하려고 하면, 사람은 매번 예외를 설명하고, agent는 매번 엉뚱한 출력을 만들고, 결국 senior가 다시 다듬는다. 반대로 좋은 오퍼는 좁다. 예를 들어 “B2B SaaS의 bottom-of-funnel comparison page를 90일 안에 revenue channel로 만든다”는 말은 다르다. 고객도 좁고, 문제도 좁고, 산출물도 좁다. 해야 할 research가 반복된다. 경쟁사 비교 기준이 반복된다. brief 포맷이 반복된다. 내부 링크 점검 방식이 반복된다. 성과를 설명하는 방식도 반복된다. 이때부터 agent가 들어갈 자리가 생긴다. ## AI는 오퍼를 구하지 못한다 AI는 흐릿한 오퍼를 선명하게 만들어주지 않는다. 오히려 흐릿함을 더 빨리 증폭한다. “우리 고객에게 맞는 콘텐츠를 많이 써줘”라고 시키면 agent는 그럴듯한 평균값을 낸다. 하지만 평균값은 비싸게 팔리지 않는다. 비싸게 팔리는 오퍼는 고객이 자기 예산 안에서 문제로 인정할 수 있어야 한다. 누가 이 문제를 겪는가. 방치하면 어떤 비용이 나는가. 지금 해결하지 않으면 무엇이 더 나빠지는가. 산출물을 받으면 어떤 상태가 달라지는가. 이 질문에 답하지 못하면, AI는 빠른 생산 기계가 아니라 빠른 혼란 기계가 된다. 작은 팀이 큰 돈을 벌려면 먼저 비싼 문제를 좁게 잡아야 한다. 그 다음에야 delivery loop를 만든다. ## 고마진은 자동화율보다 변동성에서 나온다 agency의 마진을 망치는 것은 단순히 사람이 많다는 사실이 아니다. 진짜 비용은 변동성이다. 고객마다 다른 온보딩. 매번 새로 만드는 제안서. 매번 다른 리포트. 내부에서 누가 승인해야 하는지 모르는 상태. scope creep. “이것도 해주실 수 있나요?”라는 작은 요청들. 이런 것들이 쌓이면 팀은 바빠지지만 사업은 좋아지지 않는다. AI-native agency가 진짜로 고마진이 되려면 자동화율보다 delivery variance를 낮춰야 한다. 입력을 표준화하고, 산출물을 표준화하고, 예외 처리 기준을 정하고, 사람의 판단이 필요한 지점을 좁혀야 한다. 이 말은 차갑게 들리지만 사업에는 매우 현실적이다. 팔리는 것은 “우리가 열심히 일하겠습니다”가 아니라 “이 문제를 이 방식으로 반복 해결하겠습니다”이기 때문이다. ## 작은 팀은 작아서 강한 게 아니다 2명짜리 팀이 강한 이유는 단순히 사람이 적어서가 아니다. 사람 수가 적으면 의사결정은 빠르지만, 일이 흐트러지면 바로 병목이 된다. 작은 팀은 오퍼가 좁고, 고객이 좁고, 산출물이 좁고, 판단 기준이 명시적일 때 강하다. 그러므로 질문은 “어떤 AI 툴을 쓰면 2명으로 400만 달러를 벌 수 있나”가 아니다. 더 좋은 질문은 이것이다. > 어떤 문제를 좁게 잡으면, delivery가 software처럼 반복될 수 있는가? AI는 그 다음에 붙는다. 도구는 오퍼를 대체하지 못한다. 좋은 오퍼가 있어야 도구가 레버리지가 된다. --- **Source note.** 이 글은 Zero Draft Lab 내부 초안 *“2명이 400만 달러를 버는 에이전시라는 말에서 봐야 할 것”*에서 오퍼 설계 파트만 분리한 아티클입니다. ### 이름 없는 문제는 팔리지 않는다 URL: https://zerodraftlab.com/unnamed-problems-dont-sell/ Last updated: 2026-07-11T12:54:02.000Z 문제에 이름이 붙는 순간, 불편함은 비용이 되고 비용은 시장이 된다. 사람은 대부분의 불편함에 적응한다. 코드가 지저분한 것도, 알림이 너무 많은 것도, 직원들이 승인받지 않은 AI 도구를 쓰는 것도 처음에는 그냥 "원래 일이 그렇지" 정도로 지나간다. 짜증은 나지만 예산은 안 붙는다. 불편하지만 회의 안건은 안 된다. 모두가 알고 있지만 아무도 책임지지 않는다. 그러다 누군가 이름을 붙인다. > 이건 단순한 불편이 아니라, 반복해서 비용을 만드는 문제입니다. 그 순간부터 대화가 달라진다. 개인의 예민함이 조직의 리스크가 되고, 막연한 찝찝함이 책임자의 과제가 되고, "나중에 보자"가 "이번 분기에 줄이자"로 바뀐다. 좋은 문제명은 카피가 아니다. 좋은 문제명은 고객 조직 안에서 이동할 수 있는 언어다. ## 기술 부채는 지저분한 코드를 예산 언어로 바꿨다 개발팀은 오래전부터 오래된 코드 때문에 고생했다. 작은 기능 하나를 고치려고 해도 엉뚱한 곳이 깨지고, 새로 온 개발자는 구조를 이해하지 못하고, 테스트를 붙이려 하면 이미 너무 복잡하다. 하지만 이 상태를 "코드가 지저분해요"라고 말하면 예산이 잘 붙지 않는다. 그 말은 취향처럼 들린다. 완벽주의처럼 들린다. 경영자는 이렇게 묻는다. "그래도 돌아가잖아요?" `technical debt`라는 이름은 이 장면을 바꿨다. Ward Cunningham이 만든 이 은유는 나쁜 코드의 문제를 재무 언어로 번역했다. 지금 빨리 가려고 빌린 시간이 미래 변경 비용의 이자로 돌아온다는 설명이다. Martin Fowler도 이 은유를 설명하면서, 내부 품질 저하 때문에 새 기능을 붙이는 데 추가로 드는 노력을 "이자"로 볼 수 있다고 정리한다. 이름이 붙자 문제는 개발자 불평에서 투자 판단으로 이동했다. 리팩터링, 코드 품질 도구, 아키텍처 리뷰, 테스트 자동화가 "깔끔하게 만들기"가 아니라 미래 변경 비용을 낮추는 일로 설명되기 시작했다. 같은 현실인데 언어가 바뀌자 예산의 방이 생긴 것이다. ## 알림 피로는 시끄러운 알림을 안전 문제로 바꿨다 `alert fatigue`도 마찬가지다. "알림이 너무 많아요"는 불평이다. 하지만 알림 피로는 리스크다. 중요한 신호를 놓치게 만드는 운영 실패다. 병원에서도, 보안 조직에서도, 인프라 팀에서도 이 이름이 붙는 순간 문제의 격이 달라진다. The Joint Commission은 2013년 병원 의료기기 알람 안전에 대한 Sentinel Event Alert에서 병원 단위로 하루 수천, 병원 전체로는 수만 개의 알람이 울릴 수 있고, 85-99%의 알람은 임상 개입이 필요하지 않은 경우라고 설명했다. 그 결과 임상의가 알람에 둔감해지고 압도되는 상태, 즉 `alarm fatigue`가 생긴다. 같은 문서는 2009년 1월부터 2012년 6월까지 보고된 98건의 알람 관련 sentinel event 중 80건이 사망으로 이어졌다고 적었다. 이 데이터가 중요한 이유는 숫자 자체보다 프레이밍이다. 알림이 많다는 것은 더 이상 "현장이 바쁘다"가 아니다. 알림 설계, 우선순위, 응답 프로세스, staffing, 교육, 장비 설정의 문제다. 즉 개인이 참아야 할 소음이 아니라 시스템이 줄여야 할 위험이다. 좋은 문제명은 이렇게 책임의 위치를 바꾼다. ## 다크 패턴은 찝찝한 UX를 규제 가능한 대상으로 만들었다 `dark patterns`라는 말이 나오기 전에도 사람들은 이상한 UX를 겪고 있었다. 탈퇴 버튼은 숨어 있고, 결제 취소는 복잡하고, 동의 버튼은 크게 보이고 거절 버튼은 작게 보였다. 사용자는 찝찝했지만 설명하기 어려웠다. "뭔가 속는 느낌"이었다. Harry Brignull이 밀어낸 `dark patterns`, 지금은 더 넓게 `deceptive patterns`라고도 부르는 이 이름은 그 찝찝함을 설계된 조작으로 바꿨다. Deceptive Patterns 사이트는 이들을 사용자가 원하지 않은 행동을 하게 만들거나 해로운 결정을 하도록 유도하는 앱, 웹사이트, AI 시스템의 기능으로 설명한다. 이 이름이 붙자 문제는 개인 감상에서 소비자 보호, UX 윤리, 규제, 감사의 언어로 이동했다. 전에는 "디자인이 좀 별로다"였던 것이 이제는 "사용자를 오도하는 패턴인가"라는 질문이 됐다. 이름은 현상을 고발 가능한 단위로 만든다. ## 제로 트러스트는 보안의 적을 다시 정했다 `zero trust`도 강한 문제명이다. 예전 보안의 기본값은 내부망을 믿는 것이었다. 회사 네트워크 안에 있으면 어느 정도 안전하다고 봤다. 그런데 클라우드, SaaS, 원격근무, 모바일, 협력사 접근이 늘어나면서 "안쪽은 믿어도 된다"는 전제가 흔들렸다. NIST SP 800-207은 제로 트러스트를 정적 네트워크 경계 중심의 방어에서 사용자, 자산, 리소스 중심으로 이동하는 보안 패러다임이라고 설명한다. 그리고 네트워크 위치나 자산 소유 여부만으로 암묵적 신뢰를 주지 않는다고 정리한다. 이 이름의 힘은 솔루션 목록이 아니라 전제 공격에 있다. 문제는 해커가 밖에 있다는 것이 아니라, "안쪽은 믿어도 된다"는 믿음 자체라는 식으로 현실을 다시 자른다. 그래서 ID, 접근 제어, 디바이스 posture, 네트워크 세분화, 정책 엔진, 감사 로그가 하나의 예산 언어 아래 묶인다. 좋은 문제명은 도구 여러 개를 하나의 운영 원칙으로 모은다. ## 섀도 AI는 직원의 편법을 거버넌스 공백으로 바꿨다 AI 시대에는 이 원리가 더 중요해진다. 직원들이 개인 계정으로 ChatGPT, Claude, Perplexity, 각종 자동화 도구를 쓰는 현상은 처음엔 잡담처럼 들린다. "요즘 다들 쓰지 뭐." 하지만 `shadow AI`라고 부르는 순간 이야기가 달라진다. 이건 단순한 생산성 꼼수가 아니라 보안, 컴플라이언스, 데이터 거버넌스, 교육, 구매 정책의 문제다. Microsoft와 LinkedIn의 2024 Work Trend Index는 지식 노동자 사이에서 생성형 AI 사용이 빠르게 늘었고, AI 사용자 중 78%가 자기 AI 도구를 업무에 가져오고 있다고 보고했다. 이 보고서는 이런 흐름이 전략적 AI 활용의 이점을 놓치게 하고 회사 데이터를 위험에 놓을 수 있다고 봤다. 여기서도 이름이 핵심이다. "직원이 몰래 AI를 씁니다"는 관리자의 짜증이다. "섀도 AI가 고객 데이터와 내부 문서를 승인되지 않은 모델로 흘려보낼 수 있습니다"는 경영 의제다. 이름이 붙기 전에는 개인의 편법이지만, 이름이 붙은 뒤에는 조직의 통제 공백이다. ## FinOps는 클라우드 비용을 협업 구조로 바꿨다 문제명은 꼭 공포만 팔 필요는 없다. 더 좋은 운영 방식을 여는 이름도 있다. `FinOps`가 그렇다. 클라우드 비용은 오래전부터 문제였다. 엔지니어는 속도를 원하고, 재무팀은 예측 가능성을 원하고, 사업팀은 제품 성장을 원한다. 예전 언어로는 이 문제가 "클라우드 비용 절감"처럼 들리기 쉽다. 그러면 논의가 금방 줄이기, 막기, 승인받기로 흐른다. FinOps Foundation은 FinOps를 기술의 비즈니스 가치를 극대화하고, 데이터 기반 의사결정을 가능하게 하며, 엔지니어링·재무·비즈니스 팀의 협업을 통해 재무 책임성을 만드는 운영 프레임워크이자 문화적 실천으로 설명한다. 좋은 이름 하나가 "비용 줄이기"를 "속도, 비용, 품질 사이의 trade-off를 함께 결정하는 운영 모델"로 넓힌다. 그래서 FinOps는 도구 카테고리만 만든 것이 아니라 역할, 회의, 지표, 인증, 플레이북, 커뮤니티를 만들었다. 문제명은 시장을 만들 때도 강하지만, 운영 방식을 제도화할 때도 강하다. ## 이름은 포장이 아니라 현실을 자르는 방식이다 이 사례들의 공통점은 단순하다. 사람들은 이미 불편함을 겪고 있었다. 오래된 코드는 이미 느렸다. 병원 알람은 이미 너무 많았다. 이상한 UX는 이미 사용자를 속이고 있었다. 내부망 신뢰 모델은 이미 낡고 있었다. 직원들은 이미 개인 AI 도구를 쓰고 있었다. 클라우드 비용은 이미 여기저기 새고 있었다. 하지만 이름이 없으면 불편함은 조직 안에서 이동하지 못한다. 언어가 없으면 담당자가 없다. 담당자가 없으면 회의가 없다. 회의가 없으면 예산이 없다. 예산이 없으면 시장도 없다. 그래서 좋은 사업은 솔루션을 먼저 만드는 게임이 아니다. 고객이 이미 겪고 있지만 아직 제대로 부르지 못하는 상태를 찾아낸다. 그리고 그 상태를 고객이 자기 입으로 말할 수 있는 문제명으로 고정한다. 이름은 단순한 포장이 아니다. 이름은 현실을 자르는 방식이다. 같은 현상도 어떻게 부르느냐에 따라 짜증이 되기도 하고, 손실이 되기도 하고, 리스크가 되기도 하고, 시장이 되기도 한다. ## 좋은 문제명은 네 가지 일을 한다 좋은 문제명은 예쁘지 않아도 된다. 하지만 네 가지 기능은 해야 한다. ### 1\. 흩어진 증상을 하나로 묶는다 고객은 보통 문제를 구조로 말하지 않는다. 장면으로 말한다. - "결재는 됐는데 아무도 다음 액션을 안 해요." - "AI를 쓰긴 쓰는데 결과물이 매번 달라요." - "고객이 좋다고는 하는데 내부 공유에서 멈춰요." - "알림은 많은데 진짜 중요한 게 뭔지 모르겠어요." 좋은 문제명은 이런 장면들을 하나의 패턴으로 묶는다. 묶여야 반복성이 보인다. 반복성이 보여야 해결할 가치가 생긴다. ### 2\. 방치 비용을 말하게 한다 문제명은 "이게 불편하다"에서 멈추면 약하다. "그래서 무엇이 손실되는가"까지 끌고 가야 한다. 기술 부채는 변경 속도의 이자를 말한다. 알림 피로는 중요한 신호를 놓치는 위험을 말한다. 섀도 AI는 데이터 유출과 통제 공백을 말한다. FinOps는 기술 투자 가치와 재무 책임성을 말한다. 좋은 문제명은 고통을 비용으로 번역한다. ### 3\. 책임자와 회의를 만든다 조직은 이름으로 움직인다. 이름이 있어야 누가 책임질지 정할 수 있다. 이 문제가 보안팀의 일인지, 운영팀의 일인지, 제품팀의 일인지, 재무팀의 일인지, 대표의 일인지가 보인다. 좋은 문제명은 고객 대신 회의실에 들어간다. ### 4\. 해결 카테고리를 열어준다 문제명이 강하면 고객은 특정 기능보다 해결 방향을 먼저 이해한다. "AI 자동화 도구"는 너무 넓다. "승인되지 않은 AI 사용이 고객 데이터를 새게 만드는 섀도 AI를 줄입니다"는 다르다. "알림을 정리합니다"와 "중요 경보를 놓치게 만드는 alert fatigue를 줄입니다"도 다르다. "코드를 리팩터링합니다"와 "technical debt의 이자를 줄입니다"도 다르다. 사람은 솔루션을 사는 것처럼 보이지만, 실제로는 자기 문제가 제대로 정의됐다는 확신을 산다. ## 나쁜 문제명은 두 방향으로 망한다 문제명에도 실패가 있다. 하나는 너무 넓은 이름이다. "생산성 문제", "AI 전환 문제", "마케팅 문제", "고객 경험 문제"처럼 거의 모든 것을 담을 수 있는 이름은 아무것도 자르지 못한다. 이런 말은 회의에서 고개를 끄덕이게는 하지만 결정을 만들지 못한다. 다른 하나는 너무 멋있는 이름이다. 고객이 자기 입으로 말하기 민망한 조어, 내부 팀만 이해하는 은어, 컨설팅 슬라이드처럼 들리는 말은 퍼지지 않는다. 좋은 문제명은 똑똑해 보이는 말이 아니라 고객이 훔쳐 쓰고 싶어지는 말이다. 좋은 이름은 새로워야 하지만 낯설기만 해서는 안 된다. 익숙한 장면을 더 정확하게 잡아야 한다. ## AI 시대에는 문제명이 더 중요해진다 AI가 바꾸는 것은 제품 제작 비용이다. 예전에는 프로토타입 하나를 만드는 데 팀과 시간과 돈이 많이 들었다. 이제는 혼자서도 랜딩페이지를 만들고, 데모를 찍고, 자동화를 붙이고, 코드 초안을 만들고, 고객별 제안서를 뽑을 수 있다. 실행이 싸지면 실행 자체는 차별점이 덜 된다. 그때 남는 것은 문제를 보는 눈이다. 누가 더 빨리 만드는가보다, 누가 더 정확히 이름 붙이는가가 중요해진다. AI로 누구나 솔루션을 만들 수 있다면, 고객이 아직 부르지 못하는 문제를 먼저 발견하고, 그 문제를 고객 조직 안에서 이동 가능한 언어로 만드는 사람이 앞선다. 이것은 마케팅 문장 하나의 문제가 아니다. 제품 전략의 시작점이다. 어떤 문제명을 잡느냐에 따라 기능 우선순위, 랜딩페이지, 세일즈 자료, 콘텐츠, 가격표, 고객 인터뷰 질문, 성공 사례의 모양이 달라진다. 제품은 문제명의 증거가 되어야 한다. ## 문제명을 만들 때 던질 질문 창업자와 마케터가 "무슨 솔루션을 만들까"보다 먼저 봐야 할 것은 고객의 아직 이름 없는 반복 장면이다. 아래 질문으로 시작하면 된다. - 고객이 반복해서 겪지만 "원래 그런 것"으로 넘기는 장면은 무엇인가? - 그 장면이 방치되면 시간, 돈, 리스크, 신뢰, 속도 중 무엇이 손실되는가? - 이 문제를 고객 조직 안에서 처음 말할 사람은 누구인가? - 그 사람이 상사에게 가져갈 수 있는 한 문장은 무엇인가? - 기존 대안은 왜 이 문제를 정확히 해결하지 못하는가? - 이름을 들은 고객이 "아, 우리가 겪는 게 이거였구나"라고 말할 수 있는가? - 그 이름 아래 사례, 체크리스트, 진단, 템플릿, 도구, 서비스가 붙을 수 있는가? 이 질문에 답하지 못하면 아직 오퍼를 만들 때가 아닐 수 있다. 고객의 고통은 있을지 몰라도 구매 가능한 문제로 굳지 않았기 때문이다. ## 문제명 캔버스 한 장으로 정리하면 이렇게 쓸 수 있다. - **반복 장면:** 고객이 실제로 겪는 구체적 상황 - **흐릿한 말:** 지금 고객이 대충 부르는 표현 - **방치 비용:** 해결하지 않으면 생기는 손실 - **책임자:** 이 문제를 조직 안에서 들고 갈 사람 - **문제명:** 고객이 자기 입으로 말할 수 있는 이름 - **예산 문장:** 왜 지금 돈을 써야 하는지 설명하는 한 문장 - **증거:** 사례, 데이터, 전후 비교, 진단 결과 - **출구:** 이 문제에서 빠져나가기 위해 사야 할 제품, 서비스, 템플릿, 운영 루틴 문제명이 강해지면 카피가 쉬워진다. 카피가 쉬워지는 이유는 문장이 좋아져서가 아니다. 팔아야 할 현실이 선명해졌기 때문이다. ## 끝내 이름 붙은 문제에만 돈이 붙는다 좋은 이름은 고객에게 거울을 들이민다. 좋은 문제 정의는 고객 대신 회의실에 들어간다. 좋은 카테고리는 예산 항목이 된다. 그러니까 사업은 "내가 팔고 싶은 것"을 멋지게 설명하는 게임이 아니다. 고객이 이미 겪고 있는 현실을 더 정확한 언어로 잡아내는 게임이다. 이름 없는 불편함은 참는다. 이름 붙은 문제는 해결한다. 그리고 해결해야 하는 문제에만 돈이 붙는다. --- ## 참고한 자료 - [Martin Fowler, Technical Debt](https://martinfowler.com/bliki/TechnicalDebt.html?ref=zerodraftlab.com) - [The Joint Commission, Sentinel Event Alert Issue 50: Medical device alarm safety in hospitals](https://digitalassets.jointcommission.org/api/public/content/f65e5c9df2b94000a99445e0a7877007?ref=zerodraftlab.com) - [Deceptive Patterns](https://deceptive.design/?ref=zerodraftlab.com) - [NIST SP 800-207, Zero Trust Architecture](https://csrc.nist.gov/pubs/sp/800/207/final?ref=zerodraftlab.com) - [Microsoft and LinkedIn, 2024 Work Trend Index](https://news.microsoft.com/source/2024/05/08/microsoft-and-linkedin-release-the-2024-work-trend-index-on-the-state-of-ai-at-work/?ref=zerodraftlab.com) - [FinOps Foundation, What is FinOps?](https://www.finops.org/introduction/what-is-finops/?ref=zerodraftlab.com) - [Harvard Business Review, Know Your Customers' Jobs to Be Done](https://hbr.org/2016/09/know-your-customers-jobs-to-be-done?ref=zerodraftlab.com) - [Blue Ocean Strategy 공식 사이트](https://www.blueoceanstrategy.com/?ref=zerodraftlab.com) ### AI 시대의 MVP는 fake가 아니라 thin real이다 URL: https://zerodraftlab.com/ai-era-mvp-is-thin-real/ Last updated: 2026-07-11T12:54:05.000Z 예전에는 없는 기능을 보여주는 것이 린했다. 버튼 하나, 랜딩페이지 하나, waitlist 하나로 고객의 관심을 확인하고, 개발비를 쓰기 전에 수요를 검증했다. 이른바 fake door test다. 실제 기능은 없지만, 마치 있는 것처럼 문을 만들어두고 사람들이 그 문을 열어보는지 확인하는 방식이다. 그때는 맞았다. 만드는 비용이 컸기 때문이다. 제품 하나를 만들려면 기획자, 디자이너, 개발자, QA, 인프라, 운영 리소스가 필요했다. 특히 B2B 기능이나 SaaS 제품은 한 번 만들면 코드만 남는 게 아니라 유지보수, 고객지원, 문서, 권한, 결제, 보안까지 따라왔다. 그러니 정말 만들기 전에 "이걸 원하는 사람이 있나?"를 보는 것이 합리적이었다. 하지만 AI가 이 전제를 흔들고 있다. AI가 바꾼 것은 검증의 필요가 아니다. 검증은 여전히 필요하다. 오히려 더 필요하다. 달라진 것은 검증의 형태다. 이제 많은 경우 완성품은 아니어도, 작게 작동하는 버전까지 가는 비용이 크게 내려갔다. LLM, no-code, API, 수동 운영, 스프레드시트, 에이전트 워크플로우를 붙이면 버튼 뒤에 아무것도 없는 상태보다 한 단계 더 나아갈 수 있다. 예전에는 "만들기 전에 검증하라"가 맞았다. 이제는 "크게 만들기 전에 작게 진짜로 전달하라"가 더 맞다. Fake door는 관심을 검증한다. Thin real은 의존을 검증한다. 이 차이가 중요하다. 사람들은 궁금하면 클릭한다. 새 기능처럼 보이면 눌러본다. 좋은 카피와 예쁜 버튼은 꽤 많은 클릭을 만든다. 하지만 클릭했다고 해서 그 사람이 돈을 내거나, 업무 흐름을 바꾸거나, 다음 주에도 다시 돌아온다는 뜻은 아니다. 클릭은 호기심의 흔적이다. 재사용은 문제의 증거다. AI 시대의 MVP는 그래서 fake가 아니라 thin real에 가까워져야 한다. 여기서 thin real은 완성품을 뜻하지 않는다. 확장 가능한 시스템도 아니고, 멋진 UI도 아니고, 완전 자동화도 아니다. 다만 사용자가 실제 결과를 받아야 한다. 예를 들어 "AI 회의록 자동화"를 검증한다고 하자. Fake door 방식은 랜딩페이지를 만들고 "회의록 자동 생성하기" 버튼을 붙인 뒤, 클릭률이나 이메일 가입을 본다. 나쁘지 않다. 하지만 이제는 한 단계 더 갈 수 있다. 사용자가 회의 녹음을 올리면, 뒤에서는 사람이 일부 정리하고 LLM으로 초안을 만들고, 최종 결과물을 메일로 보내도 된다. 시스템은 허술해도 된다. 중요한 건 사용자가 진짜 회의록을 받아본다는 것이다. 그때부터 질문이 바뀐다. "이 버튼을 눌렀나?"가 아니라 "이 결과물을 실제로 썼나?" "동료에게 공유했나?" "다음 회의에도 다시 맡기고 싶어 했나?" "돈을 내도 시간을 아낀다고 느꼈나?" 이 질문들이 더 강한 신호다. AI가 낮춘 것은 제품 전체의 비용이 아니다. 프로덕션 품질, 보안, 신뢰, 배포, 고객지원, 조직 내 도입 비용은 여전히 비싸다. 하지만 첫 실제 결과까지 가는 비용은 내려갔다. 이게 중요하다. 그래서 MVP의 정의도 조금 바뀌어야 한다. MVP는 minimum fake promise가 아니다. MVP는 minimum real outcome이어야 한다. 고객이 기대한 결과를 아주 좁은 범위에서라도 실제로 받아보는 것. 자동화되지 않아도 되고, 뒤가 수동이어도 되고, 내부 운영이 지저분해도 된다. 다만 앞단의 약속은 실제로 이행되어야 한다. 물론 fake door가 완전히 사라지는 것은 아니다. 의료, 금융, 보안, 규제, 대규모 인프라, 공급망, 파트너십처럼 실제 제공 자체가 위험하거나 비싼 영역에서는 여전히 유효하다. 구현 전에 수요를 보거나, 여러 기능 중 우선순위를 정하거나, 가격 민감도를 확인할 때도 쓸 수 있다. 하지만 기본값은 바뀌고 있다. 이전 시대의 린은 덜 만드는 것이었다. AI 시대의 린은 더 빨리 진짜를 만드는 것이다. 없는 문을 보여주고 누가 여는지 보는 방식은 점점 약해진다. 이제 좋은 제품팀은 "이걸 원하나요?"에서 멈추지 않는다. 작게라도 결과를 내밀고 묻는다. "이걸 써보니 내일도 다시 필요합니까?" 그 질문에 답하지 못하는 MVP는 점점 더 약한 MVP가 된다. AI 시대의 MVP는 fake가 아니라 thin real이다. ## 참고한 글 - [Lean Startup](https://www.lean.org/lexicon-terms/lean-startup/?ref=zerodraftlab.com) - [Fake Door Testing](https://www.prodpad.com/glossary/fake-door-testing/?ref=zerodraftlab.com) - [Fake Door Testing: Meaning, Examples, and Steps](https://amplitude.com/explore/experiment/fake-door-testing/?ref=zerodraftlab.com) - [The Impact of AI on Developer Productivity: Evidence from GitHub Copilot](https://www.microsoft.com/en-us/research/publication/the-impact-of-ai-on-developer-productivity-evidence-from-github-copilot/?ref=zerodraftlab.com) - [Unlocking productivity with generative AI: Evidence from experimental studies](https://www.oecd.org/en/blogs/2025/07/unlocking-productivity-with-generative-ai-evidence-from-experimental-studies.html?ref=zerodraftlab.com) - [Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/?ref=zerodraftlab.com) ### 에이전트가 잘 돌수록 병목은 더 깊은 곳으로 간다 URL: https://zerodraftlab.com/agent-loop-moves-the-bottleneck/ Last updated: 2026-07-11T12:54:08.000Z 에이전트 데모를 볼 때 가장 쉬운 반응은 감탄이다. 이슈를 읽고, 버그를 재현하고, 테스트를 만들고, PR을 열고, 리뷰 코멘트를 고치고, CI 로그를 읽는다. 사람이 하루 종일 왔다 갔다 하던 일을 에이전트가 한 화면 안에서 처리한다. 당연히 신기하다. 하지만 더 중요한 건 신기함이 아니다. 병목이 이동한다는 사실이다. [Boris Cherny와 Jarred Sumner의 라이브 코딩 세션](https://www.youtube.com/watch?v=DlTCu%5FpNDHE&ref=zerodraftlab.com)은 Bun repo에서 Claude Code를 어떻게 쓰는지 보여준다. 인상적인 장면은 자동 PR 자체보다 그 주변의 루프다. 이슈가 들어오면 봇이 재현을 시도하고, 실패를 테스트로 고정하고, 수정 PR을 만들고, Claude Code 리뷰가 미묘한 edge case를 찾고, CI와 리뷰 코멘트를 다시 읽으며 고친다. 이건 "코드 생성" 데모가 아니다. 작은 개발 조직의 반복 업무를 루프로 바꾸는 데모다. 예전에는 코드 작성이 병목이었다. 사람이 직접 구현해야 했고, 컨텍스트 스위칭 비용도 컸다. PR을 checkout하고, lint를 돌리고, 실패 로그를 읽고, 한 줄 고치고, 다시 push했다. 이런 작은 손동작이 개발 시간을 갉아먹었다. Claude Code가 들어오면 이 중 일부가 사라진다. 그러면 문제가 끝날까. 아니다. 병목은 다음 층으로 내려간다. 코드 작성이 빨라지면 테스트가 병목이 된다. 테스트도 자동화되면 CI와 리뷰가 병목이 된다. 리뷰도 일부 자동화되면 더 깊은 검증이 병목이 된다. 결국 마지막에는 "이 변경이 맞는가", "이 방향으로 고치는 게 맞는가", "이 PR을 merge해도 되는가"가 남는다. 생산성이 오른다는 말은 병목이 없어진다는 뜻이 아니다. 병목이 더 추상적인 곳으로 이동한다는 뜻이다. 이 관점이 중요하다. 많은 팀은 AI 도입을 코드 작성 속도의 문제로만 본다. "몇 퍼센트 더 빨리 구현하나", "몇 줄을 AI가 썼나" 같은 지표를 본다. 하지만 실제 운영에서는 코드 작성이 빨라질수록 검증 시스템의 품질이 더 중요해진다. 에이전트가 PR을 많이 만들수록 사람은 더 많은 diff를 읽을 수 없다. 그러면 사람을 더 갈아 넣을 게 아니라, 에이전트가 자기 결과를 검증할 수 있는 구조를 만들어야 한다. 재현 스크립트, 테스트 명령, CI 로그 접근, 리뷰 코멘트 처리, 성능 측정, benchmark가 있어야 한다. 영상에서 말하는 hill climbing 감각도 여기와 맞닿아 있다. 모델에게 목표와 측정 방법을 주면, 모델은 반복해서 개선할 수 있다. 테스트가 실패하면 고치고, benchmark가 목표에 못 미치면 다시 시도하고, 리뷰 코멘트가 남으면 반영한다. 하지만 여기에는 조건이 있다. 측정 가능한 목표가 있어야 한다. "좋게 만들어줘"는 루프가 되기 어렵다. "이 테스트를 통과하게 해줘", "이 benchmark를 10% 낮춰줘", "이 재현 케이스를 실패에서 성공으로 바꿔줘"는 루프가 된다. 에이전트에게 필요한 것은 의욕이 아니라 계기판이다. 그래서 앞으로 좋은 개발 조직은 테스트를 더 귀찮은 의무로 보지 않을 가능성이 높다. 테스트는 사람을 위한 안전망이기도 하지만, 에이전트를 위한 목표 함수가 된다. CI는 단순한 gate가 아니라 에이전트가 자기 일을 끝낼 수 있는 feedback channel이 된다. 리뷰 코멘트는 사람이 던진 잔소리가 아니라 다음 실행을 유도하는 명령이 된다. 이 변화는 사람의 역할도 바꾼다. 사람이 모든 diff를 손으로 고치는 시대에서, 사람은 어떤 루프를 만들지 결정하는 쪽으로 이동한다. 어떤 이슈는 자동 재현 PR로 충분하고, 어떤 변경은 사람이 설계부터 잡아야 하며, 어떤 PR은 절대 auto-merge하면 안 되는지 정해야 한다. 에이전트가 잘 돌아갈수록 사람의 판단은 사라지지 않는다. 더 비싸진다. 왜냐하면 이제 사람은 코드 한 줄보다 시스템의 방향을 정하기 때문이다. 병목이 코드 작성에서 검증으로, 검증에서 계획으로, 계획에서 우선순위로 이동한다. 이 흐름을 못 읽으면 AI를 도입하고도 PR 더미 앞에서 막힌다. 라이브 코딩 세션의 가장 큰 메시지는 "AI가 PR을 만든다"가 아니다. AI가 PR을 만들 수 있게 되면, 팀은 무엇을 검증할지 다시 설계해야 한다. 에이전트 시대의 핵심 질문은 이제 "누가 코드를 쓰는가"가 아니다. "어떤 루프가 안전하게 닫히는가"다. ### AI 시대의 병목은 코드가 아니라 spec이다 URL: https://zerodraftlab.com/spec-driven-development-ai-engineering/ Last updated: 2026-07-11T12:54:11.000Z 코드가 싸졌다. 이게 AI 코딩 시대의 출발점이다. 예전에는 아이디어를 실제 코드로 옮기는 데 시간이 많이 들었다. 화면을 만들고, controller를 붙이고, 모델을 고치고, 테스트를 추가하고, PR을 정리하는 일이 무거웠다. 이제 그 무게가 빠르게 줄고 있다. Codex든 Claude Code든 Cursor든, agent는 코드 초안을 아주 빨리 만든다. 틀릴 때도 많지만, 적어도 "아무것도 없는 상태에서 첫 구현을 만드는 비용"은 분명히 낮아졌다. 그런데 코드가 싸지면 다른 것이 비싸진다. 애매함이다. 무엇을 만들지 애매한 상태. 어디까지 만들고 멈출지 정하지 않은 상태. 실패 케이스를 말로만 넘긴 상태. 권한과 데이터 상태와 완료 기준이 흐릿한 상태. 이런 애매함은 예전에도 문제였지만, AI agent가 붙으면 더 빨리 비용이 된다. 사람 개발자는 애매하면 중간에 멈추거나, 눈치껏 묻거나, 조직의 맥락으로 보정한다. agent도 질문할 수는 있지만 기본값은 다르다. agent는 주어진 말을 해석해서 앞으로 간다. 그리고 앞으로 가는 속도가 빠르다. 그래서 AI 시대의 병목은 점점 코드 작성이 아니라 **무엇이 맞는지 적는 일**로 이동한다. 나는 이걸 spec의 문제라고 본다. ## Notion 사례에서 봐야 할 것 Ryan Nystrom이 Lenny's Newsletter의 [Spec-driven development: The AI engineering workflow at Notion](https://www.lennysnewsletter.com/p/spec-driven-development-the-ai-engineering?ref=zerodraftlab.com)에서 이야기한 Notion의 내부 workflow는 꽤 화려하다. Notion comment에서 Codex를 호출한다. agent가 VM에서 작업한다. PR을 만든다. screenshot도 붙인다. 내부적으로는 Boxy 같은 시스템이 있고, CI 시간을 줄이기 위한 Project Afterburner도 돈다. 이런 부분은 당연히 눈에 띈다. "Notion은 agent로 PR까지 뽑는구나" 하고 보게 된다. 하지만 내가 더 중요하게 본 건 그 앞단이다. 아이디어를 말로 남긴다. 받아쓴다. 그것을 spec으로 정리한다. 그 spec을 repo에 넣는다. agent는 그 다음에 움직인다. 순서가 중요하다. 채팅창에서 "이 기능 만들어줘"라고 던지는 게 먼저가 아니다. agent를 부르기 전에 기능의 기준을 repo 안에 넣는다. 무엇을 만들지, 무엇을 만들지 않을지, 어떤 동작이 맞는지, 어떤 검증을 통과해야 하는지를 먼저 적는다. 즉 Notion 사례의 핵심은 "Codex가 코드를 잘 쓴다"가 아니다. 핵심은 **코드보다 먼저 spec이 version control 안으로 들어간다**는 점이다. 이건 개발 문화의 중심이 prompt에서 spec으로 옮겨가는 신호에 가깝다. ## Spec은 PRD가 아니다 여기서 말하는 spec은 두꺼운 PRD가 아니다. PM이 회의 끝나고 쓰는 제품 문서도 아니고, 나중에 감사용으로 남기는 설명서도 아니다. AI coding workflow에서 spec은 더 실행적인 문서다. agent가 읽고 움직일 수 있어야 한다. 리뷰어가 보고 판단할 수 있어야 한다. 테스트와 연결되어야 한다. 다음 세션의 나나 다른 agent가 다시 읽어도 "왜 이렇게 만들었는지" 복원할 수 있어야 한다. 좋은 spec은 적어도 이 네 가지를 담는다. - 왜 하는가 - 어디까지 하는가 - 어떤 동작이 맞는가 - 무엇으로 검증하는가 이 정도만 있어도 agent의 움직임은 달라진다. 반대로 이 네 가지가 없으면 agent는 빠르게 추측한다. 그리고 그 추측은 꽤 그럴듯한 코드로 나타난다. 그래서 더 위험하다. 이상한 코드보다 그럴듯한 코드가 더 늦게 발견된다. ## BDD는 사라지지 않는다 Spec 이야기를 하면 자연스럽게 BDD가 떠오른다. "그럼 BDD랑 뭐가 다른가?" 내 답은 이렇다. **BDD는 spec의 경쟁자가 아니라 spec 안에 들어가는 재료다.** BDD는 사용자의 행동을 예시로 고정한다. 어떤 상태에서, 어떤 행동을 하면, 시스템이 어떻게 반응해야 하는지 적는다. ```gherkin Given 로그인한 작성자가 있고 When front matter가 있는 Markdown 파일을 업로드하면 Then 제목과 본문과 태그가 draft post로 저장된다 ``` 이건 여전히 좋다. 오히려 agent 시대에는 더 좋아진다. agent에게 "이런 행동을 만족시켜야 한다"고 말해주는 명확한 예시이기 때문이다. 하지만 BDD example만으로는 부족한 순간이 많다. 왜 이 기능을 만드는가. 이번 범위에서 제외할 것은 무엇인가. slug 충돌은 어떻게 처리할 것인가. writer 권한이면 published가 아니라 submitted가 되어야 하는가. 세션이 만료되면 어떤 메시지를 보여줄 것인가. 어떤 테스트 명령을 통과해야 완료라고 볼 것인가. 이 질문들은 Given/When/Then 하나에 다 들어가지 않는다. BDD는 behavior를 선명하게 만든다. Spec은 그 behavior가 놓일 작업의 울타리를 만든다. 그러니까 "spec이냐 BDD냐"가 아니다. Spec 안에 BDD가 들어간다. ## AI가 틀리는 방식 AI agent가 틀릴 때 가장 짜증나는 지점은 단순히 문법을 틀리는 게 아니다. 그건 비교적 빨리 잡힌다. 진짜 문제는 의도를 조금씩 틀리게 해석하는 것이다. 관리자 전용이어야 하는 기능을 public API처럼 열어둔다. draft까지만 만들면 되는데 publish까지 해버린다. 실패하면 아무것도 만들지 말아야 하는데 빈 record를 남긴다. 권한 체크는 있는데 scope가 tenant 기준이 아니라 user 기준으로만 걸린다. 테스트는 통과하지만 실제 사용 흐름에서는 이상한 상태가 된다. 이런 오류는 "코딩 실력"만의 문제가 아니다. 작업 정의가 약했기 때문에 생긴다. 사람끼리 일할 때도 그랬다. 다만 사람은 맥락을 더 많이 들고 있었다. agent는 그렇지 않다. agent가 읽는 것은 지금 주어진 문장과 파일과 테스트다. 그러니 그 입력이 약하면 결과도 약하다. 결국 좋은 agent workflow의 핵심 질문은 이것이다. **agent가 지금 무엇을 읽고 판단하고 있는가?** 채팅창의 흐릿한 지시만 읽고 있다면 결과도 흐릿해진다. repo 안의 spec, behavior example, verification command를 읽고 있다면 훨씬 나아진다. ## "완료했습니다"를 믿지 않기 AI agent는 완료 보고를 잘한다. 너무 잘한다. "구현했습니다." "테스트도 추가했습니다." "이제 동작합니다." 문제는 이 말들이 실제 완료를 보장하지 않는다는 점이다. 사람도 마찬가지지만, agent는 특히 그럴듯한 완료감을 만든다. 코드가 생겼고, 파일이 바뀌었고, 테스트 이름도 있다. 얼핏 보면 끝난 것 같다. 그래서 spec에는 완료 기준이 들어가야 한다. ```md Verification: - Markdown import service test - admin publish controller test - expired session regression test - public post URL smoke check ``` 이런 식으로 적어두면 "완료"가 감상이 아니라 증거가 된다. PR 리뷰도 달라진다. 코드 스타일만 보는 게 아니라, spec의 각 항목이 실제로 충족됐는지 본다. 테스트가 그것을 고정하는지 본다. 실패 케이스가 빠졌는지 본다. AI 시대의 code review는 점점 이렇게 바뀔 것이다. 코드가 예쁜가? 보다 먼저, **이 변경은 적어둔 spec을 만족하는가?** ## Spec은 changelog가 된다 Spec을 repo에 넣는 또 다른 이유는 기록이다. 채팅창에서 agent에게 지시하면 순간 속도는 빠르다. 하지만 며칠 지나면 이유가 사라진다. 왜 이 범위를 제외했는지, 왜 이 예외는 막았는지, 왜 이 테스트를 완료 기준으로 봤는지 흩어진다. repo 안의 spec은 다르다. 기능이 바뀌면 spec도 바뀐다. non-goal이 goal로 승격된다. behavior가 늘어난다. verification이 추가된다. 그러면 spec은 단순한 사전 문서가 아니라 기능의 changelog가 된다. 코드가 어떻게 바뀌었는지만 남는 게 아니다. 기능을 이해하는 방식이 어떻게 바뀌었는지도 남는다. agent와 일할수록 이게 중요해진다. agent는 과거 회의 분위기를 기억하지 못한다. 이전 세션의 감각도 안정적으로 보존하지 못한다. 설령 기억한다고 해도 그걸 그대로 믿으면 안 된다. 다음 agent, 다음 주의 나, 다른 리뷰어가 같은 지점에서 다시 출발하려면 정본이 필요하다. 그 정본이 spec이다. ## CI가 느리면 agent도 느리다 Ryan의 인터뷰에서 CI 이야기가 같이 나오는 것도 우연이 아니다. Notion은 CI 시간을 줄이는 Project Afterburner를 진행하고 있다고 한다. AI coding에서는 CI 속도가 더 중요해진다. 사람이 하루에 PR 하나를 만들던 시절에는 CI가 느려도 어느 정도 버틸 수 있었다. 답답하지만 기다리면 됐다. 그런데 agent가 작은 PR을 계속 만들고, 리뷰 반영을 반복하고, test failure를 보고 다시 고치는 흐름에서는 느린 CI가 곧 전체 처리량의 병목이 된다. AI engineering throughput은 모델 성능만으로 결정되지 않는다. Spec이 선명해야 한다. 테스트가 빨라야 한다. CI가 빨라야 한다. 실패 로그를 agent가 읽고 다시 고칠 수 있어야 한다. 리뷰 기준이 자동화되어 있어야 한다. Spec이 없으면 agent는 방향 없이 빠르다. Test가 없으면 agent는 그럴듯하게 빠르다. CI가 느리면 agent는 기다리다가 멈춘다. 셋이 같이 있어야 진짜 속도가 난다. ## 혼자 만들수록 더 필요하다 이 이야기는 Notion 같은 큰 회사에만 해당하지 않는다. 오히려 혼자 제품을 만드는 사람에게 더 절실하다. 큰 회사에는 PM, designer, engineer, QA, EM, staff engineer가 따로 있다. 요구사항이 흐릿하면 누군가 잡아줄 가능성이 있다. 물론 그만큼 회의도 많지만, 역할이 분산되어 있다. 솔로 빌더는 다르다. 혼자 아이디어를 낸다. 혼자 구현한다. 혼자 테스트한다. 혼자 배포한다. 혼자 고객 반응을 본다. 여기에 agent를 붙이면 생산성이 올라간다. 동시에 혼란도 빨리 쌓인다. 애매한 상태에서 agent에게 일을 맡기면, 혼자 감당해야 할 이상한 코드와 이상한 제품 결정이 빠르게 늘어난다. 그래서 솔로 빌더에게 spec은 팀 문서가 아니다. 자기 자신과 agent를 통제하는 운영 장치다. 오늘의 내가 내린 결정을 내일의 나와 agent가 다시 읽을 수 있게 만드는 장치다. "왜 이 기능을 만들었지?", "왜 이건 안 만들기로 했지?", "무엇을 보면 안심할 수 있지?"를 repo 안에 남기는 일이다. ## 한 페이지면 충분하다 Spec이라고 해서 거창할 필요는 없다. 작은 기능은 한 페이지면 충분하다. 예를 들면 이런 정도다. ```md # Draft URL Import Why: - 글감 URL을 admin에서 바로 draft로 바꿔 큐레이션 속도를 높인다. Goal: - URL 하나를 넣으면 제목, 요약, OG 이미지 후보를 가져와 draft post로 만든다. Non-goals: - 자동 발행은 하지 않는다. - 로그인 없는 public import는 만들지 않는다. Behavior: - admin이 URL을 입력하면 OG metadata를 fetch한다. - title이 비어 있으면 URL hostname을 fallback으로 쓴다. - fetch 실패 시 draft는 만들지 않고 오류를 보여준다. Verification: - OG fetcher unit test - admin import controller test - 실패 응답 regression test ``` 여기에 BDD example을 붙이면 더 좋다. ```gherkin Given editor가 admin에 로그인해 있고 When 유효한 URL을 import하면 Then draft post가 생성되고 public으로 발행되지는 않는다 ``` 이 정도만 있어도 agent는 훨씬 덜 헤맨다. 중요한 건 문서 양이 아니다. 작업의 경계가 보이는가다. ## 나쁜 spec의 냄새 나쁜 spec은 보통 멋있다. "사용자가 더 쉽게 글을 쓸 수 있게 한다." "AI로 운영을 자동화한다." "관리자 경험을 개선한다." 다 맞는 말이다. 하지만 agent가 읽고 움직이기에는 약하다. 방향은 있지만 끝 조건이 없다. 좋은 spec은 조금 더 건조하다. 누가, 어디에서, 무엇을 입력하고, 어떤 상태가 만들어지고, 어떤 경우에는 막히고, 무엇을 보면 완료라고 판단하는가. 이게 있어야 한다. 또 하나의 냄새는 non-goal이 없는 spec이다. agent에게 "이걸 만들어줘"라고만 하면 agent는 옆 기능까지 만들고 싶어 한다. 친절하게 하려고 설정 화면을 붙이고, 추상화를 만들고, 아직 필요 없는 옵션을 넣는다. 그래서 spec에는 "이번에 하지 않을 것"이 꼭 들어가야 한다. Non-goal은 게으름의 표시가 아니다. 작업을 끝내기 위한 울타리다. ## 결론 Spec-driven development는 새 유행어처럼 보일 수 있다. 하지만 나는 이것을 꽤 실용적인 변화로 본다. AI가 코드를 더 많이 쓰게 되면 사람의 일은 사라지지 않는다. 앞쪽과 뒤쪽으로 이동한다. 앞쪽에서는 문제를 정확히 자른다. 뒤쪽에서는 결과를 검증한다. 그 사이에서 agent가 구현한다. 이 구조에서 spec은 사람과 agent 사이의 인터페이스다. BDD는 그 spec 안에서 behavior를 선명하게 만드는 도구다. 테스트와 CI는 spec이 지켜졌는지 확인하는 회로다. 그러니까 질문은 "spec이냐 BDD냐"가 아니다. 질문은 이거다. **내 agent는 지금 무엇을 읽고 있는가?** 앞으로 좋은 AI 엔지니어링은 프롬프트를 잘 쓰는 사람만의 일이 아닐 것이다. 좋은 spec을 남기고, 그 spec을 테스트로 고정하고, agent가 실패했을 때 다시 읽을 수 있는 작업 구조를 만드는 사람의 일이 될 것이다. 코드는 여전히 중요하다. 하지만 코드보다 먼저, 무엇이 맞는지 적는 일이 더 중요해지고 있다. 코드가 싸졌기 때문이다. 그리고 코드가 싸질수록, 애매함은 더 비싸진다. --- 참고: - [Lenny's Newsletter - Spec-driven development: The AI engineering workflow at Notion](https://www.lennysnewsletter.com/p/spec-driven-development-the-ai-engineering?ref=zerodraftlab.com) - [Notion AI](https://www.notion.com/product/ai?ref=zerodraftlab.com) - [OpenAI Codex](https://openai.com/codex?ref=zerodraftlab.com) ### AX 전환은 설득이 아니라 이주다 URL: https://zerodraftlab.com/ax-transformation-is-migration/ Last updated: 2026-07-11T12:54:15.000Z 조직의 AX 전환이라는 말은 너무 순하게 들린다. 전 직원에게 AI 계정을 준다. 프롬프트 교육을 한다. 팀별 활용 사례를 모은다. 잘 쓴 사람을 발표시킨다. 리더가 "앞으로 AI를 적극적으로 활용합시다"라고 말한다. 다 필요하다. 하지만 이건 전환이 아니다. 이건 도입이다. 전환은 더 거칠다. 기존 조직이 일을 받는 방식, 승인하는 방식, 기록하는 방식, 책임지는 방식을 바꾸는 일이다. 더 정확히는 기존 조직을 설득해서 바꾸는 게 아니라, 새 운영체계를 옆에 만든 뒤 일을 그쪽으로 이주시켜야 하는 일이다. AX는 adoption이 아니라 migration이다. ## 기존 조직은 쉽게 바뀌지 않는다 기존 조직이 AI 전환을 못 하는 이유는 사람들이 게을러서가 아니다. 기존 조직은 이미 기존 방식에 최적화되어 있기 때문이다. 일은 늘 가던 길로 간다. 누군가는 메신저로 요청한다. 누군가는 회의에서 결정한다. 누군가는 엑셀에 적는다. 누군가는 머릿속으로만 알고 있다. 누군가는 마지막에 덮어준다. 어떤 결정은 문서로 남고, 어떤 결정은 말로만 지나간다. 그게 조직의 진짜 구조다. 여기에 AI를 얹으면 사람들은 기존 길 안에서 AI를 쓴다. 메일 문장을 고친다. 보고서 초안을 빨리 쓴다. 회의록을 요약한다. 리서치 시간을 줄인다. 나쁘지 않다. 하지만 조직은 그대로다. 요청은 여전히 흩어진다. 승인은 여전히 늦다. 책임은 여전히 흐리다. 정본은 여전히 불명확하다. 같은 질문은 계속 반복된다. 개인 작업은 빨라졌는데 조직 throughput은 안 바뀌는 이유가 여기에 있다. 문제는 AI 사용률이 아니다. 문제는 routing이다. ## 병행구축이 핵심이다 그래서 AX 전환은 교육 캠페인이 아니라 병행구축이어야 한다. 기존 조직을 바로 부수자는 말이 아니다. 기존 업무를 멈추자는 말도 아니다. 대신 옆에 새 업무 처리 레일을 만든다. 그 레일에는 처음부터 다른 규칙이 있어야 한다. 요청은 어디로 들어오는가. 필요한 context는 어디에 있는가. agent는 무엇을 먼저 읽는가. 어디까지 초안을 만드는가. 사람은 어디서 승인하는가. 완료된 결과는 어디에 남는가. 다음 반복 때 무엇이 재사용되는가. 이 질문에 답하지 못하면 AI는 계속 개인기다. 답할 수 있으면 업무 레일이 된다. John Kotter가 말한 [dual operating system](https://hbr.org/books/chapters/accelerate?ref=zerodraftlab.com)도, HBR의 [ambidextrous organization](https://hbr.org/2004/04/the-ambidextrous-organization?ref=zerodraftlab.com)도 결국 같은 긴장을 다룬다. 기존 조직은 오늘의 일을 굴리는 데 필요하지만, 새 방식은 기존 조직 안에서 자연스럽게 자라지 않는다. 옆에 만들어야 한다. ## 파일럿이 아니라 shadow production이어야 한다 여기서 파일럿이라는 말도 조심해야 한다. 많은 파일럿은 안전한 데모로 끝난다. 작은 실험을 해봤다. 가능성을 확인했다. 발표를 했다. 그리고 다시 원래 방식으로 돌아간다. AX 병행구축은 그런 파일럿이면 안 된다. shadow production이어야 한다. 같은 실제 업무를 새 레일에서도 끝까지 처리해본다. 처음부터 agent가 외부 시스템에 쓰거나 최종 결정을 내릴 필요는 없다. 읽고, 정리하고, 누락을 찾고, 초안을 만들고, 사람이 볼 review queue에 올리면 된다. 중요한 건 자동화율이 아니다. 새 업무 흐름이 실제로 도는지다. BCG가 agent autonomy를 설명하면서 [Shadow Mode](https://www.bcg.com/publications/2025/agents-accelerate-next-wave-of-ai-value-creation?ref=zerodraftlab.com)를 첫 단계로 두는 이유도 여기에 있다. agent가 제안하고 인간이 실행하는 방식은 위험을 키우지 않으면서 실제 업무 맥락에 맞는지 검증하게 해준다. AX의 질문은 "AI가 할 수 있나?"가 아니다. "우리 조직의 context 안에서, 이 업무를 어디까지 맡길 수 있나?"다. 그 답은 회의실에서 안 나온다. 굴려봐야 나온다. ## 어느 순간 옛길을 닫아야 한다 병행구축만으로는 부족하다. 새 레일이 어느 정도 돌아가면 옛길을 닫아야 한다. 이게 제일 어렵다. 새 시스템도 있고, 옛 방식도 있는 상태가 가장 편하기 때문이다. 바쁘면 메신저로 던진다. 급하면 말로 처리한다. 예외는 늘 있다. 그러면 새 레일은 장식이 된다. 조직은 말보다 route에 반응한다. 이 업무는 이제 새 레일로만 접수한다. 이 양식 밖 요청은 반려한다. 승인 기록이 없으면 완료로 인정하지 않는다. 정본에 남지 않은 결정은 결정으로 보지 않는다. 예외는 지정된 책임자가 승인하고, 예외 사유도 기록한다. 이 정도의 route closure가 있어야 이주가 일어난다. 소프트웨어 migration과 똑같다. 새 시스템을 만들고도 옛 시스템을 계속 열어두면 데이터는 갈라진다. 운영 부담은 두 배가 된다. 결국 사람들은 더 익숙한 쪽으로 돌아간다. 조직도 그렇다. 선택사항으로 남긴 새 방식은 기존 방식에 진다. ## AX 리더는 전도사가 아니라 이주 설계자다 그래서 AX 리더십은 전도사의 일이 아니다. 좋은 말로 사람들을 설득하고, 멋진 사례를 보여주고, "우리도 할 수 있습니다"라고 말하는 것만으로는 부족하다. AX 리더는 이주 설계자에 가깝다. 어떤 업무부터 옮길지 정한다. 기존 route를 관찰한다. 새 route를 설계한다. 작은 전환 셀을 만든다. agent가 맡을 일과 사람이 맡을 일을 나눈다. 승인 gate를 둔다. 실제 업무를 shadow production으로 돌린다. 실패한 케이스를 기록한다. 성공한 케이스를 표준화한다. 그리고 어느 시점에 legacy 접수를 닫는다. 사람의 역할도 바뀐다. 단순 실행자는 줄어든다. 대신 결과 책임자, reviewer, exception handler, context curator가 중요해진다. agent가 더 많은 초안과 실행 보조를 맡을수록 사람은 방향을 정하고, 결과를 평가하고, 예외를 처리하는 쪽으로 이동한다. Microsoft의 [2026 Work Trend Index](https://www.microsoft.com/en-us/worklab/work-trend-index/agents-human-agency-and-the-opportunity-for-every-organization?ref=zerodraftlab.com)가 말하는 핵심도 비슷하다. AI의 효과는 개인 능력보다 조직 환경, manager support, talent practice 같은 시스템 조건에 더 크게 묶인다. 시스템은 스스로 고쳐지지 않는다. 다시 설계해야 한다. ## 작게 시작하되 진짜로 옮겨야 한다 시작은 작아야 한다. 전사 AX 전환 같은 말부터 꺼내면 흐려진다. 반복되는 업무 하나를 고르면 된다. 주간 고객 문의 패턴 요약. 캠페인 문안 리스크 점검. 신규 리드 검증. 월마감 증빙 누락 확인. 채용 후보자 1차 정리. 발행 전 글의 출처와 주장 점검. 이 중 하나를 고른다. 요청 양식을 정한다. 필요한 자료 위치를 정한다. agent의 출력 형식을 정한다. 사람이 승인할 기준을 정한다. 완료 결과가 남을 정본을 정한다. 그리고 5번, 10번 실제로 돌린다. 어디서 막히는지 보인다. 어떤 context가 부족한지 보인다. 사람이 어느 지점에서 시간을 쓰는지 보인다. agent가 잘하는 부분과 위험한 부분이 갈린다. 그때부터 rule, checklist, template, permission이 생긴다. 이게 운영 자산이다. AX 전환은 AI를 많이 쓰자는 캠페인이 아니다. 기존 조직 위에 AI를 붙이는 것도 아니다. 새 업무 레일을 병행 구축하고, 실제 업무로 검증하고, 충분히 작동하면 옛길을 닫아 일을 이주시키는 것이다. AX는 adoption이 아니라 migration이다. 기존 조직을 AI로 바꾸려 하지 말고, 일이 지나가는 길을 바꿔야 한다. ### A급 천 명을 모아도 S급 문제는 못 푼다 URL: https://zerodraftlab.com/model-grade-is-a-ceiling/ Last updated: 2026-07-11T12:54:18.000Z 채용 이야기에서 흔히 나오는 말이 있다. A급 인재 천 명을 모아도 S급 인재 한 명만 풀 수 있는 문제는 못 푼다. 과장처럼 들리지만 현장에서 일해본 사람은 안다. 어떤 문제는 인원을 늘리면 풀리고, 어떤 문제는 인원을 아무리 늘려도 안 풀린다. 후자는 한 사람의 머리 안에서 통째로 굴러가야 하는 문제다. 쪼개는 순간 본질이 사라지는 문제다. AI 모델에도 같은 질문을 던질 수 있다. 약한 모델을 천 개 돌리면 강한 모델이 될까. 여러 에이전트를 묶어 돌리는 orchestration(오케스트레이션)이 유행하면서 이 질문은 한가한 비유가 아니라 돈이 걸린 의사결정이 됐다. 싼 모델을 물량으로 돌릴 것인가, 비싼 모델을 한 번 돌릴 것인가. 답은 "문제에 따라 다르다"인데, 그 "따라"의 기준이 생각보다 선명하다. ## 분포 밖의 답은 천 번을 뽑아도 안 나온다 모델이 내놓는 답은 어디서 오는가. 모델이 학습한 분포에서 나온다. 같은 질문을 천 번 던지는 건 그 분포에서 천 번 뽑는 일이다. 여기서 산수가 단순해진다. 정답이 분포 안에 있는데 드물게 나온다면, 뽑는 횟수를 늘릴수록 건질 확률이 올라간다. 백 번에 한 번 나오는 답이라면 천 번 뽑으면 거의 확실히 잡는다. 하지만 정답이 분포 안에 아예 없다면, 0에 천을 곱해도 0이다. 그 모델의 어떤 출력 경로에도 존재하지 않는 통찰은 샘플을 늘려도 등장하지 않는다. 물량은 "드물게 나오는 답"을 건지는 도구지, "나올 수 없는 답"을 만들어내는 도구가 아니다. 그리고 AI 쪽 사정은 인재 비유보다 한 가지 더 나쁘다. A급 인재 천 명은 그래도 천 명이 서로 다른 사람이다. 다른 경험, 다른 직관, 다른 맹점을 가졌다. 그런데 같은 모델 천 개는 같은 가중치의 복사본이다. 한 모델이 못 보는 것은 천 개가 똑같이 못 본다. 다양성이 없는 물량은 물량이 아니라 같은 시도의 반복이다. ## 그런데 물량이 실제로 이긴 기록이 있다 여기서 끝나면 깔끔한데, 현실은 한 겹 더 있다. [Large Language Monkeys](https://arxiv.org/abs/2407.21787?ref=zerodraftlab.com) 연구는 같은 모델로 같은 문제를 반복해서 풀게 했을 때 무슨 일이 생기는지 측정했다. 실제 GitHub 이슈를 고치는 SWE-bench Lite에서, 한 번 시도하면 15.9%를 풀던 모델이 250번 시도하자 56%를 풀었다. 샘플 수를 늘릴수록 풀리는 문제의 비율이 꾸준히, 예측 가능한 곡선으로 올라갔다. [에이전트 수 자체를 늘리면 성능이 오른다](https://arxiv.org/abs/2402.05120?ref=zerodraftlab.com)는 연구도 비슷한 시기에 나왔다. 물량이 통한 것이다. 그러면 앞의 논리가 틀렸나. 아니다. 이 실험들이 통한 영역을 보면 된다. 코딩과 수학이다. 두 영역의 공통점은 답이 맞는지 기계가 싸게 확인할 수 있다는 것이다. 테스트가 통과하는지, 증명이 검증기를 통과하는지. 250개의 답 중에 정답이 하나라도 섞여 있으면, 검증기가 그걸 골라낸다. ## 경계를 가르는 두 가지 질문 그래서 물량과 등급의 경계는 두 가지 질문으로 갈린다. 첫째, 문제가 쪼개지는가. A급이 풀 수 있는 부분문제들로 분해되는 문제라면 물량이 덤빌 수 있다. 쪼개지지 않는 문제, 전체를 한 머리에 넣고 굴려야 하는 문제는 물량이 손댈 자리가 없다. 둘째, 검증이 생성보다 싼가. 나온 답이 맞는지 확인하는 비용이 답을 만드는 비용보다 훨씬 싸다면, 드문 정답을 물량으로 건질 수 있다. 검증이 비싸거나 불가능하다면, 천 개의 답은 천 개의 후보일 뿐이고 그중 무엇이 맞는지 가려줄 S급이 다시 필요해진다. 두 질문에 모두 "그렇다"면 물량이 이긴다. 하나라도 "아니다"면 모델 등급이 천장이다. 이렇게 정리하면 처음의 비유가 한 단계 정련된다. 물량은 탐색을 산다. 등급은 분포를 바꾼다. 천 번의 시도는 이미 가능한 답들 사이를 더 넓게 뒤져준다. 더 강한 모델은 가능한 답의 집합 자체를 키운다. 전자는 후자를 대체하지 못한다. 방향이 다른 투자다. ## 실무에서는 이렇게 갈린다 이 기준은 바로 써먹을 수 있다. 테스트가 있는 코드 수정, 채점 기준이 명확한 변환 작업, 정답이 존재하는 조사 업무. 이런 일은 싼 모델 여러 개에 검증을 붙이는 쪽이 이긴다. 실제로 에이전트를 여러 개 묶어 돌리는 구조가 값을 하는 곳이 정확히 여기다. 반대로 제품의 방향을 정하는 판단, 쪼개지지 않는 설계 결정, 맞는지 확인할 방법이 없는 한 방의 통찰. 이런 일은 오케스트레이션을 아무리 화려하게 짜도 베이스 모델의 등급이 결과의 상한이다. 여기서 물량에 쓰는 돈은 같은 맹점을 천 번 확인하는 비용이다. 그리고 이 기준은 사람 조직에도 그대로 돌아온다. 늦은 프로젝트에 사람을 더 넣으면 더 늦어진다는 [브룩스의 법칙](https://en.wikipedia.org/wiki/The%5FMythical%5FMan-Month?ref=zerodraftlab.com)이 50년 전에 이미 같은 말을 했다. 인원을 늘려서 풀리는 일은 처음부터 쪼개지는 일이었다. 안 풀리는 일은 쪼개지지 않는 일이었다. 문제를 만났을 때 물어야 할 것은 "몇 명을 붙일까"나 "몇 번을 돌릴까"가 아니다. 이 문제는 쪼개지는가. 답을 싸게 검증할 수 있는가. 그 두 답이 물량을 살지 등급을 살지 정해준다. ## 참고 - [Large Language Monkeys: Scaling Inference Compute with Repeated Sampling](https://arxiv.org/abs/2407.21787?ref=zerodraftlab.com) — 반복 샘플링으로 풀리는 문제 비율(coverage)이 샘플 수에 따라 로그-선형으로 증가. SWE-bench Lite 15.9% → 56% 수치의 출처. - [More Agents Is All You Need](https://arxiv.org/abs/2402.05120?ref=zerodraftlab.com) — 에이전트 수를 늘리고 투표로 모으면 성능이 오른다는 실증. - [The Mythical Man-Month](https://en.wikipedia.org/wiki/The%5FMythical%5FMan-Month?ref=zerodraftlab.com) — Fred Brooks. 인력 추가가 통하는 일과 안 통하는 일의 구분. ### 회사는 이제 에이전트를 위해 설계되어야 한다 URL: https://zerodraftlab.com/company-must-be-designed-for-agents/ Last updated: 2026-07-11T12:54:21.000Z AI를 붙인다고 회사가 AI-native가 되지는 않는다. 이 문장을 먼저 인정해야 한다. 많은 회사가 이미 AI를 샀다. 직원들은 문서를 더 빨리 쓰고, 회의록은 자동으로 요약되고, 고객응대 일부는 챗봇으로 넘어간다. 그런데 회사는 여전히 느리다. 결정은 여전히 회의를 지나고, 정보는 여전히 중간관리자를 지나고, 누가 무엇을 알고 있는지는 여전히 사람 머릿속에 있다. 이건 도구 문제가 아니다. 회사 설계 문제다. 기존 조직은 인간을 기본 노동 단위로 놓고 설계됐다. 부서가 있고, 직무가 있고, 보고선이 있고, 승인권자가 있고, 누군가는 상황을 요약해서 위로 올린다. 이 구조에서 AI는 보조도구가 되기 쉽다. 더 빠른 검색기, 더 빠른 문서 작성기, 더 빠른 자동화 스크립트. 하지만 에이전트는 보조도구로만 남기엔 다른 물건이다. 에이전트는 읽고, 계획하고, 호출하고, 쓰고, 실행한다. 혼자 모든 일을 잘한다는 뜻이 아니다. 중요한 건 방향이다. 소프트웨어가 단순한 도구에서 일의 참여자로 이동하고 있다면, 회사도 그 참여자가 일할 수 있는 구조로 바뀌어야 한다. Herbert Simon은 오래전에 조직을 사람들의 묶음이 아니라 의사결정 장치로 봤다. 인간은 모든 정보를 다 처리하지 못한다. 그래서 조직은 정보를 자르고, 권한을 나누고, 절차를 만들고, 사람들이 그 안에서 그럭저럭 좋은 결정을 하게 만든다. 회사는 본질적으로 제한된 합리성을 보정하는 decision architecture다. 그렇다면 질문이 바뀐다. 인간의 정보처리 한계를 보정하기 위해 생긴 조직이, 기계가 정보처리 일부를 맡을 수 있는 시대에도 같은 형태여야 하는가. Jack Dorsey와 Roelof Botha가 쓴 [From Hierarchy to Intelligence](https://block.xyz/inside/from-hierarchy-to-intelligence?ref=zerodraftlab.com)는 이 지점을 세게 찌른다. 그 글에서 hierarchy는 단순한 권력 구조가 아니라 정보 라우팅 장치로 읽힌다. 누가 무엇을 알아야 하는지, 어떤 결정을 어디로 보내야 하는지, 어떤 신호를 위로 올릴지 정하는 오래된 방식이다. 그런데 AI가 회사 안의 문서, 고객 신호, 업무 기록, 코드, 대시보드, 티켓, 계약, 재무 데이터를 읽을 수 있다면 어떻게 되는가. 정보를 라우팅하기 위해 사람 피라미드가 꼭 필요하다는 전제가 흔들린다. Block이 흥미로운 이유는 AI를 업무 보조 도구가 아니라 회사 구조의 문제로 다루기 때문이다. Dorsey는 Sequoia 팟캐스트 [Every Company Can Now Be a Mini-AGI](https://sequoiacap.com/podcast/jack-dorsey-every-company-can-now-be-a-mini-agi/?ref=zerodraftlab.com)에서 회사 전체의 artifact 위에 intelligence layer를 얹는 그림을 말한다. 회사와 대화할 수 있고, 회사의 상태를 묻고, 고객과 내부 시스템 사이를 더 직접적으로 연결하는 구조다. 이걸 성공 사례로 받아들일 필요는 없다. Block의 조건은 특수하고, 감원과 비용 구조도 섞여 있다. 하지만 방향성은 중요하다. AI를 “직원 생산성” 문제가 아니라 “회사 아키텍처” 문제로 다시 정의했다. 여기서부터 핵심이 나온다. 기존 human org는 점진적 개선만으로 agent-native company가 되지 않는다. 기존 조직에 AI를 붙이면 기존 조직이 더 빨라질 수는 있다. 하지만 더 빠른 기존 조직은 새로운 회사가 아니다. 보고선이 그대로면 정보 병목도 그대로다. 책임 경계가 그대로면 자동화된 무책임만 생긴다. 맥락이 사람 머릿속에 있으면 에이전트는 계속 누군가에게 물어봐야 한다. 데이터가 흩어져 있으면 에이전트는 환각보다 더 무서운 일을 한다. 그럴듯하게 틀린 실행을 한다. 그래서 agent-native company의 설계 단위는 부서가 아니다. 상태다. 목표, 고객 신호, 업무 흐름, 결정, 리스크, 권한, 증거, 다음 액션이 연결된 상태공간이다. 사람이 읽어도 이해되고, 에이전트가 읽어도 이어서 실행할 수 있는 operating graph다. BCG의 [Design Your Company for AI, Not AI for Your Company](https://www.bcg.com/publications/2026/design-your-company-for-ai-not-ai-for-your-company?ref=zerodraftlab.com)가 제목 그대로 말하듯, 회사는 AI를 기존 프로세스에 맞추는 게 아니라 AI가 작동할 수 있게 다시 설계되어야 한다. Deloitte도 [humans with agents](https://www.deloitte.com/us/en/insights/topics/talent/operating-models-for-humans-ai-agents.html?ref=zerodraftlab.com)를 말할 때 기존 human-worker 운영 모델에 자율 agent를 끼워 넣는 방식의 불일치를 지적한다. McKinsey의 [agentic organization](https://www.mckinsey.com/capabilities/people-and-organizational-performance/our-insights/the-agentic-organization-contours-of-the-next-paradigm-for-the-ai-era?ref=zerodraftlab.com)도 같은 방향을 가리킨다. 도구 도입이 아니라 operating model의 재설계다. 이 말은 인간을 빼자는 뜻이 아니다. 오히려 반대다. 인간을 더 비싼 자리로 올리자는 뜻이다. 인간이 매번 상태를 업데이트하고, 회의 내용을 요약하고, 누구에게 물어볼지 찾고, 같은 결정을 반복해서 설명하는 건 낭비다. 그런 일은 시스템화되어야 한다. 인간은 목표를 정하고, 중요한 예외를 판단하고, 고객 신호의 의미를 해석하고, 감수할 리스크와 포기하지 않을 가치를 결정해야 한다. 에이전트에게 맡길 일과 인간이 책임질 일을 다시 나누는 것. 그게 회사 설계의 다음 문제다. 그래서 순서도 바뀐다. 기존 회사를 AI화하는 게 아니다. 먼저 에이전트가 일할 수 있는 회사를 설계해야 한다. 작은 핵심 업무 하나를 고르고, 그 업무의 목표와 상태와 증거와 권한을 machine-readable하게 만든다. 에이전트는 처음엔 shadow mode로 돌린다. 사람이 승인한다. 로그를 남긴다. 어디서 틀리는지 본다. 그리고 그 반복을 통해 업무 단위를 부서가 아니라 outcome과 evidence 중심으로 다시 자른다. 이 과정에서 기존 인간 조직은 사라지는 게 아니라 새 구조 위에 올라탄다. 누군가는 owner가 된다. 누군가는 reviewer가 된다. 누군가는 player-coach가 된다. 누군가는 customer context를 지키는 사람이 된다. 하지만 예전처럼 정보를 들고 있는 사람이 권력을 갖는 구조는 약해진다. 정보는 시스템에 있어야 하고, 판단은 더 선명하게 드러나야 한다. 미래 회사의 경쟁력은 headcount가 아니다. 얼마나 많은 AI 도구를 샀는지도 아니다. 진짜 경쟁력은 회사의 맥락을 얼마나 소유하고 있는가다. 고객 신호가 들어왔을 때 그것이 어디에 기록되고, 어떤 목표와 연결되고, 어떤 에이전트가 다음 행동을 제안하고, 누가 승인하고, 결과가 어디에 evidence로 남는가. 이 흐름이 회사의 지능이다. 모델은 빌릴 수 있다. 하지만 context는 빌릴 수 없다. 회사는 이제 에이전트를 위해 설계되어야 한다. 그리고 기존 human org는 점진적 개선만으로 그 회사가 되지 않는다. 새 구조를 먼저 만들고, 사람을 그 위에 태워야 한다. AI를 붙인 회사는 에이전트 회사가 아니다. 에이전트가 읽고 실행할 수 있게 다시 설계된 회사만이 에이전트 회사다. ### 바이브 코딩이 위험한 이유는 코드를 안 봐서가 아니다 URL: https://zerodraftlab.com/vibe-coding-needs-acceptance-tests/ Last updated: 2026-07-11T12:54:24.000Z 바이브 코딩이라는 말에는 이상한 조롱이 섞여 있다. AI에게 대충 말하고, 나온 코드를 제대로 보지 않고, 느낌으로 ship하는 무책임한 개발처럼 들린다. 실제로 그렇게 쓰면 위험하다. 하지만 그 비판만으로는 중요한 변화를 놓친다. 문제는 코드를 전부 읽느냐가 아니다. 읽지 않은 구현도 판단할 수 있는 검증 체계가 있느냐다. Anthropic의 [Vibe coding in prod](https://www.youtube.com/watch?v=fHWFF%5FpnqDk&ref=zerodraftlab.com)는 이 지점을 잘 잡는다. 발표자는 바이브 코딩을 단순히 "AI가 코드를 많이 써주는 것"으로 보지 않는다. 더 정확히는 사람이 구현 세부를 전부 이해하지 못한 상태에서도 제품을 만들고 검증하는 방식으로 본다. 이건 사실 새로운 문제가 아니다. 대표가 회계사의 모든 분개를 직접 검산하지 않아도 회사를 운영한다. PM이 엔지니어가 쓴 모든 코드를 읽지 않아도 기능을 검수한다. CTO가 모든 도메인의 최고 전문가가 아니어도 팀의 결과물을 판단한다. 우리는 이미 오래전부터 "내가 내부를 전부 모르는 결과물"을 다루며 일해왔다. 차이는 속도다. AI가 코드를 훨씬 많이, 훨씬 빠르게 만들기 시작하면서 기존의 느슨한 검증 습관이 버티지 못하게 됐다. 예전에는 사람이 코드를 쓰는 속도가 자연스러운 제동 장치였다. 이제 그 제동 장치가 사라진다. 그러면 남는 질문은 하나다. 무엇으로 멈출 것인가. 이때 필요한 것은 더 많은 불안이 아니라 더 좋은 acceptance test다. 사용자가 기대하는 행동이 무엇인지, 어떤 상태가 성공인지, 무엇이 깨지면 안 되는지 명확히 해야 한다. 구현을 모두 읽지 않아도 결과를 판단할 수 있는 기준이 있어야 한다. 바이브 코딩을 책임 있게 하려면 사람의 역할도 바뀐다. 사람은 Claude의 타자수가 아니라 매니저가 된다. 새로 합류한 팀원에게 일을 맡기듯이 배경을 설명하고, 요구사항을 정리하고, 참고할 파일을 알려주고, 제약 조건을 말해준다. 발표자가 말하는 15분, 20분짜리 준비는 낭비가 아니다. 그 시간이 결과물의 품질을 결정한다. 좋은 지시는 짧은 명령이 아니다. 좋은 지시는 온보딩이다. 이 기능은 왜 필요한지, 비슷한 구현은 어디 있는지, 어떤 테스트를 추가해야 하는지, 어떤 UX는 피해야 하는지, 어떤 로그나 CI를 확인해야 하는지 알려주는 것이다. 사람이 제대로 준비하지 않고 "알아서 해줘"라고 던졌다면, 실패의 상당 부분은 모델이 아니라 관리 방식에 있다. 또 하나 중요한 점은 검증을 모델에게도 맡길 수 있어야 한다는 것이다. 단순히 코드를 쓰게 하는 것으로 끝나면 사람의 부담은 줄지 않는다. 오히려 낯선 diff만 늘어난다. Claude가 테스트를 만들고, 실행하고, 실패를 읽고, 다시 고치고, 마지막에 무엇을 확인했는지 보고하게 해야 한다. 그래야 사람은 "이 diff를 처음부터 끝까지 해독하는 사람"이 아니라 "검증 근거를 보고 ship 여부를 판단하는 사람"이 된다. 그렇다고 사람의 책임이 사라지는 것은 아니다. 오히려 책임은 더 선명해진다. 어떤 테스트가 충분한지, 어떤 리스크는 사람이 직접 봐야 하는지, 어떤 변경은 배포 전에 막아야 하는지 정하는 일은 여전히 사람의 몫이다. AI가 코드를 빨리 쓰게 될수록 사람은 더 높은 층위의 판단을 게을리할 수 없다. 여기서 바이브 코딩의 위험이 드러난다. 코드를 안 보는 것 자체가 위험한 게 아니다. 안 봐도 되는 것과 반드시 봐야 하는 것을 구분하지 못하는 것이 위험하다. 버튼 색상 변경과 결제 로직 변경은 같은 방식으로 맡기면 안 된다. 테스트가 촘촘한 리팩터링과 프로덕션 데이터 마이그레이션은 같은 자율도를 줄 수 없다. 책임 있는 바이브 코딩은 속도를 포기하지 않는다. 대신 속도가 지나갈 레일을 깐다. 요구사항, 테스트, 리뷰, 로그, 배포 게이트, rollback 경로를 준비한다. 이 레일이 없으면 빠른 생성은 빠른 혼란이 된다. 레일이 있으면 빠른 생성은 실제 생산성이 된다. 그러니 질문은 "AI가 쓴 코드를 다 읽어야 하나"가 아니다. 더 좋은 질문은 이것이다. 이 변경을 내가 내부까지 읽지 않아도 판단할 수 있는가. 판단할 수 없다면 아직 ship할 준비가 안 된 것이다. Claude가 부족해서가 아니라, 작업의 성공 조건이 부족한 것이다. 바이브 코딩의 미래는 무책임한 느낌 개발이 아니다. 검증 가능한 위임이다. ### Claude Code는 자동완성이 아니다 URL: https://zerodraftlab.com/claude-code-is-not-autocomplete/ Last updated: 2026-07-11T12:54:28.000Z Claude Code를 처음 보면 많은 사람이 더 똑똑한 자동완성으로 이해한다. 코드를 더 빨리 써주는 도구. 함수를 대신 만들어주는 도구. 막힌 버그를 물어보면 답해주는 도구. 틀린 말은 아니다. 하지만 그 정도로 이해하면 이 도구의 진짜 힘을 거의 쓰지 못한다. Claude Code는 자동완성이라기보다 작업장에 들어온 에이전트에 가깝다. 영상 [Mastering Claude Code in 30 Minutes](https://www.youtube.com/watch?v=AOfogJZ70OQ&ref=zerodraftlab.com)에서 반복해서 보이는 핵심은 단순하다. Claude Code는 IDE 안의 작은 버튼이 아니라 터미널에서 움직이는 일꾼이다. 파일을 읽고, 명령어를 실행하고, Git 이력을 보고, 테스트를 돌리고, 팀이 이미 쓰는 도구를 호출한다. 그러니까 잘 쓰는 법도 달라진다. 좋은 사용자는 "이 코드 짜줘"라고만 말하지 않는다. 먼저 작업장을 설명한다. 이 repo가 어떤 구조인지, 어떤 명령어로 테스트하는지, 어떤 파일을 보면 되는지, 어떤 관례를 지켜야 하는지 알려준다. `CLAUDE.md` 같은 파일이 중요한 이유도 여기에 있다. 그건 프롬프트 팁 모음이 아니라 새 팀원이 매번 읽는 작업 안내서다. 사람이 새 회사에 들어오면 처음부터 PR을 던지지 않는다. 폴더 구조를 듣고, 빌드 방법을 배우고, 테스트가 어디 있는지 확인하고, 기존 비슷한 구현을 찾는다. Claude Code도 마찬가지다. 차이는 속도뿐이다. 영상에서 흥미로운 부분은 Claude Code가 remote index 없이도 codebase Q&A를 한다는 설명이다. 코드를 어딘가에 올려 색인해두고 검색하는 방식이 아니라, 로컬에서 필요한 파일과 Git 이력을 직접 읽어가며 답을 만든다. 이 말은 곧 하나의 운영 원칙이 된다. 작업장을 읽을 수 있게 만들수록 에이전트가 좋아진다. 문서가 낡았고, 테스트 명령이 불명확하고, 배포 경로가 사람 머릿속에만 있고, 파일명이 제멋대로면 Claude가 멍청해서 실패하는 게 아니다. 작업장이 읽히지 않는 것이다. 반대로 좋은 repo는 에이전트에게도 좋은 repo다. README, AGENTS, 테스트, 스크립트, 로그, CI, runbook이 맞물리면 Claude는 단순 생성기가 아니라 실행자에 가까워진다. 도구 연결도 중요하다. Claude Code는 bash 명령과 MCP 도구를 쓸 수 있다. 이건 "더 많은 버튼을 붙인다"는 뜻이 아니다. 팀이 이미 쓰는 검증 루프를 Claude에게 넘길 수 있다는 뜻이다. 이슈를 읽고, 에러 로그를 보고, 테스트를 돌리고, PR 상태를 확인하고, 필요한 경우 내부 CLI를 호출한다. 사람이 하던 반복 손동작을 에이전트의 루프로 옮기는 것이다. 그래서 Claude Code를 잘 쓰려면 질문보다 환경을 고쳐야 한다. 질문 한 줄을 예쁘게 다듬는 것보다 중요한 건 반복적으로 먹히는 작업 경로를 만드는 일이다. "이 기능을 고쳐줘"보다 "먼저 관련 파일을 찾고, 비슷한 구현을 읽고, 계획을 말한 뒤, 테스트를 추가하고, 통과하면 커밋 메시지까지 제안해줘"가 낫다. 한 번의 명령이 아니라 일의 순서가 들어가기 때문이다. 여기서 에이전트 활용의 감각이 바뀐다. 예전의 코딩 도구는 내 손을 빠르게 했다. Claude Code는 내 작업장을 대신 걸어다닌다. 그래서 병목도 손에서 환경으로 이동한다. 내가 코드를 얼마나 빨리 치는지보다, 에이전트가 안전하게 움직일 수 있는 길이 있는지가 중요해진다. 좋은 `CLAUDE.md`는 설명서가 아니라 경계선이다. 무엇을 해도 되는지, 어떤 명령으로 확인해야 하는지, 어떤 파일은 건드리면 안 되는지, 실패하면 어디를 봐야 하는지 알려준다. 좋은 slash command는 반복 의식을 줄인다. 좋은 hook은 사람이 까먹는 확인을 기계가 하게 만든다. 좋은 팀 설정은 개인의 프롬프트 습관을 조직의 작업 방식으로 바꾼다. 결국 Claude Code는 "AI가 코딩한다"는 말보다 더 넓은 변화를 보여준다. 코딩이 채팅창 밖으로 나왔다. 이제 AI는 답변을 쓰는 것이 아니라 작업장을 순회한다. 파일, 터미널, 테스트, Git, 배포 도구, 내부 문서가 하나의 실행 표면이 된다. 그래서 Claude Code를 도입한다는 건 새 자동완성을 설치하는 일이 아니다. 작업장을 에이전트가 읽을 수 있는 형태로 바꾸는 일이다. 그리고 이 변화에 제대로 적응한 팀은 질문을 더 잘하는 팀이 아니라, 일이 지나가는 길을 더 잘 설계한 팀일 가능성이 높다. ### 프롬프트는 문장이 아니라 맥락 설계다 URL: https://zerodraftlab.com/prompting-is-context-design/ Last updated: 2026-07-11T12:54:31.000Z 프롬프트라는 말은 너무 가볍게 쓰인다. 사람들은 종종 좋은 프롬프트를 주문처럼 생각한다. 특정 문장을 넣으면 결과가 좋아지고, 어떤 표현을 쓰면 모델이 갑자기 똑똑해질 것처럼 말한다. 하지만 실제로 Claude를 잘 쓰는 방식은 주문에 가깝지 않다. 차라리 작은 작업 환경을 설계하는 일에 가깝다. Anthropic의 [Prompting 101](https://www.youtube.com/watch?v=ysPbXH0LpIE&ref=zerodraftlab.com)은 이 점을 꽤 명확하게 보여준다. 영상은 자동차 보험 청구 이미지를 분석하는 예시를 통해 프롬프트를 단계적으로 쌓아간다. 처음부터 "분석해줘"라고 던지는 것이 아니라, 어떤 회사의 어떤 업무인지, 어떤 자료를 보고 있는지, 어떤 판단을 해야 하는지, 어떤 형식으로 결과를 내야 하는지 차례로 넣는다. 중요한 건 문장력이 아니다. 맥락의 배치다. 모델은 우리 머릿속을 보지 못한다. 우리가 보기에는 당연한 상황도 모델에게는 비어 있다. 이 자료가 고객 민원인지, 내부 검수인지, 법적 리스크가 있는 판단인지, 단순 분류인지, 사람이 마지막에 확인하는지에 따라 좋은 답은 달라진다. 그러니 프롬프트의 첫 번째 일은 모델을 똑똑하게 만드는 게 아니라, 모델이 엉뚱한 상황을 상상하지 않게 막는 것이다. 그래서 좋은 프롬프트에는 업무 배경이 들어간다. "너는 보험 청구 이미지를 검토한다"는 말과 "스웨덴 자동차 보험사의 청구 검수 흐름에서, 제출 이미지와 양식 정보를 비교해 손상 여부와 청구 타당성을 판단한다"는 말은 다르다. 후자는 모델에게 어떤 세상 안에서 일해야 하는지 알려준다. 두 번째는 자료의 경계다. 영상에서는 XML 태그나 Markdown 같은 구획을 활용한다. 이건 장식이 아니다. 모델에게 "이 안은 사용자 선호", "이 안은 양식 정보", "이 안은 분석 대상"이라고 알려주는 표지판이다. 긴 프롬프트에서 표지판이 사라지면 모델은 어느 정보가 규칙이고 어느 정보가 데이터인지 헷갈린다. 사람도 회의 자료를 볼 때 제목, 섹션, 표, 첨부를 구분한다. 모델도 마찬가지다. 맥락을 한 덩어리로 던지면 똑똑한 모델도 괜히 추측을 섞는다. 구획을 나누면 모델은 필요한 정보를 다시 찾기 쉬워진다. 세 번째는 예시다. 프롬프트에서 예시는 모델에게 말투만 알려주는 것이 아니다. 판단 기준을 압축해서 보여준다. 어떤 경우에는 "손상 있음"으로 봐야 하고, 어떤 경우에는 "정보 부족"으로 봐야 하며, 어떤 경우에는 사람이 재확인해야 하는지 예시가 보여준다. 규칙만 있으면 모델은 경계 사례에서 흔들린다. 예시는 그 경계를 잡아준다. 네 번째는 마지막 reminder다. 영상에서는 중요한 기준을 끝부분에서 다시 상기시킨다. 이것도 단순 반복이 아니다. 긴 맥락 끝에서 모델이 지금 당장 해야 하는 일을 다시 좁혀주는 장치다. 사람에게도 긴 설명 끝에는 "그래서 이번에 필요한 건 이것"이라고 다시 말해야 한다. 마지막은 출력 형식이다. 실무에서는 좋은 답변보다 다룰 수 있는 답변이 중요할 때가 많다. 데이터베이스에 넣어야 한다면 JSON이어야 하고, 검수자가 봐야 한다면 짧은 요약과 판단 근거가 분리되어야 한다. 출력 형식을 정하지 않으면 모델은 친절한 문단을 만들어내지만, 시스템은 그 문단을 다시 사람이 정리해야 한다. 이 지점에서 프롬프트는 글쓰기가 아니라 인터페이스 설계가 된다. 모델에게 어떤 일을 시킬지 정하고, 필요한 자료를 정리하고, 판단 기준을 고정하고, 결과가 다음 시스템으로 넘어갈 수 있는 형식을 지정한다. 프롬프트는 사람이 모델에게 던지는 말이지만, 동시에 모델이 일할 수 있는 작은 작업장이다. 그래서 프롬프트를 잘 쓰는 사람은 미사여구를 많이 아는 사람이 아니다. 상황을 잘 쪼개는 사람이다. 규칙과 자료를 구분하고, 예외를 드러내고, 출력이 쓰일 곳을 먼저 생각하는 사람이다. 모델의 답변이 이상하면 "모델이 틀렸다"에서 멈추지 않고, 어떤 맥락이 비어 있었는지 본다. 에이전트 시대에는 이 감각이 더 중요해진다. 단발성 답변은 틀려도 다시 물으면 된다. 하지만 업무 흐름에 들어간 에이전트는 수십 번의 작은 판단을 이어서 한다. 처음 맥락이 흐리면 뒤의 실행도 계속 비뚤어진다. 반대로 맥락이 선명하면 모델은 더 오래, 더 안정적으로 움직인다. 좋은 프롬프트는 마법 문장이 아니다. 모델이 일할 수 있는 방을 정리하는 일이다. 자료는 어디에 있고, 규칙은 무엇이며, 판단 기준은 어디까지이고, 결과는 어떤 형태로 나가야 하는가. 이 네 가지가 정리되면 프롬프트는 짧아도 강해진다. 정리되지 않으면 길어도 약하다. ### 블루오션 레드오션은 바다 색깔 문제가 아니다 URL: https://zerodraftlab.com/blue-ocean-red-ocean-explanation-cost/ Last updated: 2026-07-11T12:54:34.000Z 블루오션이 좋냐, 레드오션이 좋냐는 질문은 대부분 시작부터 조금 틀려 있다. 질문이 틀렸다는 건 블루오션 전략이 틀렸다는 뜻이 아니다. 오히려 반대에 가깝다. 블루오션 전략의 원래 요지는 기존 경쟁판에서 조금 더 잘 싸우자는 게 아니라, 경쟁 자체가 덜 중요해지는 새 시장 공간을 만들자는 쪽이다. 공식 설명에서도 블루오션은 새 수요를 만들고, 아직 경쟁 규칙이 굳지 않은 시장을 여는 전략으로 정의된다. 반대로 레드오션은 이미 존재하는 시장이고, 경쟁 규칙과 고객의 비교 기준이 어느 정도 정해진 공간이다. 문제는 이 개념이 실무로 내려오면서 이상하게 납작해진다는 데 있다. 블루오션은 멋진 곳, 레드오션은 피해야 할 곳. 블루오션은 창의적인 사람의 선택, 레드오션은 겁 많은 사람의 선택. 이런 식으로 색깔에 도덕을 붙이는 순간 전략은 사라지고 취향만 남는다. 내가 보기엔 더 쓸모 있는 구분은 이거다. 블루오션은 경쟁자가 적은 시장이 아니라, 고객의 문제 인식이 아직 충분히 조직되지 않은 시장이다. 레드오션은 경쟁자가 많은 시장이 아니라, 고객의 문제 인식과 예산과 구매 기준이 이미 어느 정도 조직된 시장이다. 그러니까 진짜 차이는 경쟁자 수가 아니다. 설명 비용이다. ## 블루오션에서는 문제부터 팔아야 한다 블루오션을 상상하면 사람들은 보통 비어 있는 바다를 떠올린다. 아무도 없고, 싸움도 없고, 먼저 들어가는 사람이 다 먹는 공간. 하지만 현실의 블루오션은 그렇게 조용하지 않다. 경쟁자가 없는 대신, 고객의 머릿속에 카테고리도 없고 예산 항목도 없고 검색어도 없는 경우가 많다. 고객은 불편함을 느낄 수는 있다. 뭔가 비효율적이고, 반복되고, 손실이 난다는 감각은 있다. 그런데 그 불편함에 이름이 없다. 이름이 없으면 검색도 안 한다. 검색을 안 하면 비교도 안 한다. 비교를 안 하면 예산도 안 생긴다. 예산이 없으면 구매는 계속 “흥미롭네요” 근처에서 멈춘다. 이때 파는 것은 솔루션이 아니다. 먼저 문제 정의를 팔아야 한다. “이게 왜 문제인지” “왜 지금 해결해야 하는지” “왜 기존 방식으로는 부족한지” “이 문제를 내부에서 뭐라고 설명해야 하는지” 이 네 가지를 고객 대신 정리해줘야 한다. 블루오션에서 마케팅이 어려운 이유가 여기에 있다. 제품의 장점만 말해서는 부족하다. 고객이 자기 상태를 새 언어로 이해하게 만들어야 한다. 쉽게 말하면 카테고리 교육, 문제 번역, 예산 설득을 전부 같이 해야 한다. 그래서 블루오션은 생각보다 돈이 많이 든다. 광고비만 말하는 게 아니다. 콘텐츠, 세일즈, 고객 인터뷰, 사례 개발, 내부 설득 자료, 컨퍼런스 발표, 창업자의 반복 설명, 이 모든 게 비용이다. 수요가 아직 형태를 갖추지 않았기 때문에, 회사가 시장의 언어를 대신 만들어야 한다. 그걸 감당할 수 있으면 블루오션은 강하다. 판단 기준을 내가 세울 수 있고, 고객이 문제를 이해하는 방식 자체를 내 언어로 만들 수 있다. Blue Ocean Strategy가 말하는 핵심도 단순한 무경쟁이 아니라 새 수요를 만들고 가치와 비용 구조를 다시 짜는 쪽에 가깝다. 이미 만들어진 판에서 5% 더 잘하는 게 아니라, 고객이 비교하는 축을 바꾸는 일이다. 하지만 이 힘이 없으면 블루오션은 그냥 교육비 지옥이 된다. ## 박수와 결제 사이에는 깊은 골이 있다 새로운 문제 정의를 던지면 초기 반응은 꽤 좋아 보일 수 있다. 특히 온라인에서는 더 그렇다. 저장이 많고, 댓글이 똑똑하고, 사람들이 “이거 완전 맞다”고 말한다. 창업자 입장에서는 시장이 열린 것처럼 보인다. 그런데 저장은 예산이 아니다. 공감은 구매가 아니다. “재밌다”는 “이번 분기에 사겠다”가 아니다. 여기서 많은 팀이 착각한다. 얼리어답터의 반응을 시장 전체의 신호로 읽는다. 새로운 개념을 빨리 이해하고, 실험을 좋아하고, 말의 신선함에 반응하는 사람들은 분명 있다. 하지만 메인스트림 고객은 다르게 움직인다. 그들은 새로움보다 리스크를 먼저 본다. 기존 업무 흐름과 얼마나 충돌하는지, 상사를 설득할 수 있는지, 실패했을 때 책임을 누가 지는지, 다른 회사도 쓰고 있는지 같은 질문을 한다. Crossing the Chasm 쪽 논의가 오래 살아남은 이유도 여기에 있다. 초기 수용자와 주류 시장은 같은 제품을 보고도 다른 기준으로 판단한다. 초기 시장에서 먹히던 메시지와 포지셔닝이 주류 시장으로 넘어갈 때 오히려 방해가 되기도 한다. 기술이 더 좋다는 말만으로는 안 되고, 구매자의 심리와 조직의 의사결정 방식에 맞춰 가치 제안, 커뮤니케이션, 유통, 증거의 형태를 바꿔야 한다. 블루오션을 한다는 건 결국 이 골을 건너겠다는 뜻이다. “아는 사람은 알아본다”에서 멈추면 안 된다. 모르는 사람이 들어도 자기 문제라고 느끼게 해야 하고, 관심 있는 사람이 내부 결재 문장까지 들고 갈 수 있게 해야 한다. 그러니 블루오션을 고를 때 물어야 할 질문은 낭만적이면 안 된다. 우리는 이 문제에 이름을 붙일 수 있나. 그 이름을 반복해서 퍼뜨릴 채널이 있나. 고객이 새 예산을 만들 만큼 아픈가. 얼리어답터의 박수를 넘어 주류 고객의 리스크 언어로 번역할 수 있나. 이 질문에 답하지 못하면 “경쟁자가 없어서 좋아요”는 오히려 위험 신호다. 경쟁자가 없다는 건 아무도 못 본 기회일 수도 있지만, 아무도 돈 내고 싶어 하지 않는 문제일 수도 있으니까. ## 레드오션은 남이 교육비를 내준 시장이다 반대로 레드오션을 너무 쉽게 깎아내리는 것도 이상하다. 레드오션에는 경쟁자가 많다. 가격 비교도 심하고, 고객은 이미 여러 대안을 알고 있고, 비슷한 말이 넘친다. 그래서 피곤하다. 하지만 장점도 분명하다. 고객이 이미 자기 문제를 알고 있다. 검색어가 있다. 예산 항목이 있다. 내부에서 설명할 말이 있다. 구매 담당자가 비교표를 만들 줄 안다. 이건 누군가가 이미 교육비를 내줬다는 뜻이다. CRM을 사는 사람은 왜 고객관리가 필요한지부터 설득할 필요가 없다. 협업툴을 사는 사람에게 “팀 커뮤니케이션이 중요합니다”를 길게 말할 필요도 없다. 병원 예약 시스템, 세무 대행, 채용 솔루션, 광고 대행, 홈페이지 제작, 이런 시장에서는 고객이 이미 문제와 카테고리를 안다. 이때 필요한 것은 문제 교육이 아니라 선택 기준의 승리다. 왜 우리여야 하는가. 왜 지금 바꿔도 되는가. 왜 이 가격이 정당한가. 왜 실패 리스크가 낮은가. 레드오션에서 흐릿한 오퍼는 바로 죽는다. “저희도 잘합니다”는 아무 힘이 없다. 대신 하나라도 날카로운 차이가 있으면 먹힌다. 더 좁은 타겟, 더 빠른 납품, 더 낮은 도입 리스크, 더 강한 증거, 더 쉬운 구매 과정, 더 명확한 책임 범위. 이미 수요가 있는 곳에서는 새 언어를 만드는 것보다 선택을 쉽게 만드는 일이 더 중요하다. 그래서 레드오션은 나쁜 시장이 아니다. 흐릿한 오퍼에게 잔인한 시장일 뿐이다. ## 시장은 색깔이 아니라 인식 단계로 봐야 한다 고객 awareness 관점으로 보면 이 구분은 더 선명해진다. 마케팅에서는 고객이 아무 문제도 인식하지 못한 상태, 문제는 느끼지만 솔루션을 모르는 상태, 솔루션 카테고리는 알지만 제품을 고르지 않은 상태, 특정 제품을 알고 망설이는 상태를 나눠 본다. 블루오션은 보통 앞쪽에 있다. 고객이 아직 문제를 정확히 부르지 못하거나, 솔루션 카테고리를 모른다. 여기서는 교육형 콘텐츠, 문제를 이름 붙이는 문장, 사례, 진단 프레임이 중요하다. 제품명보다 문제명이 먼저 퍼져야 한다. 레드오션은 뒤쪽에 있다. 고객은 이미 솔루션 카테고리를 알고 있고, 여러 대안을 비교한다. 여기서는 비교 페이지, 가격, 후기, 레퍼런스, 전환비용 제거, 도입 후 결과가 중요하다. 문제를 새로 깨우기보다 결정을 쉽게 만들어야 한다. 이 관점으로 보면 블루오션과 레드오션은 고정된 지명이 아니다. 같은 제품도 어떤 고객에게는 블루오션이고, 어떤 고객에게는 레드오션이다. AI 자동화도 어떤 사람에게는 “왜 필요한지 모르겠는 것”이고, 어떤 사람에게는 이미 견적을 비교하는 카테고리다. 병원 운영 자동화도 어떤 원장에게는 새 문제 정의이고, 어떤 원장에게는 이미 예산이 잡힌 교체 대상이다. 그래서 “이 시장은 블루냐 레드냐”보다 더 좋은 질문은 “이 고객은 지금 어디까지 알고 있나”다. 고객이 문제를 모르면 우리는 문제를 팔아야 한다. 고객이 문제만 알면 해결 가능성을 팔아야 한다. 고객이 솔루션을 알면 우리 방식의 차이를 팔아야 한다. 고객이 우리를 알면 리스크 제거와 행동 이유를 팔아야 한다. 색깔보다 인식 단계가 먼저다. ## 결국 오퍼 체력의 문제다 블루오션이냐 레드오션이냐를 고르는 기준은 시장의 멋짐이 아니다. 우리 오퍼가 어디까지 사람을 끌고 갈 수 있느냐다. 오퍼가 강하다는 건 단순히 제품이 좋다는 뜻이 아니다. 고객이 아직 문제를 모르는 상태에서도 멈춰 서게 만들 수 있는가. 불편함에 이름을 붙여줄 수 있는가. “이거 우리 얘기네”라는 감각을 만들 수 있는가. 내부 보고 문장과 예산 명분까지 줄 수 있는가. 반복 가능한 사례와 증거를 쌓을 수 있는가. 이 정도 체력이 있으면 블루오션을 가도 된다. 아니, 이 경우엔 블루오션이 훨씬 좋다. 카테고리 언어를 선점할 수 있고, 비교 기준을 먼저 만들 수 있고, 고객의 머릿속에서 문제와 브랜드가 같이 붙을 수 있다. 하지만 그 체력이 없으면 레드오션이 더 낫다. 이미 존재하는 수요 안에서 더 좁고 선명하게 이기는 편이 현실적이다. 수요를 창조하지 못한다고 해서 약한 전략이 아니다. 남이 만들어둔 시장에서 고객의 선택 비용을 줄이는 것도 충분히 좋은 전략이다. 정리하면 이렇다. 블루오션은 수요를 창조할 수 있는 사람에게 좋은 시장이다. 레드오션은 이미 있는 수요 안에서 선택 기준을 이길 수 있는 사람에게 좋은 시장이다. 둘 중 뭐가 더 우월한 게 아니다. 비용 구조가 다를 뿐이다. 블루오션의 비용은 설명과 교육에 있고, 레드오션의 비용은 차별화와 신뢰 증명에 있다. 그래서 시장을 볼 때 처음 던질 질문은 “블루냐 레드냐”가 아니다. 우리는 수요를 만들 힘이 있는가. 없다면, 이미 있는 수요 안에서 왜 우리를 골라야 하는가. 이 두 질문에 답하고 나면 바다 색깔은 거의 나중 문제다. 전략은 색깔에서 나오지 않는다. 고객의 머릿속 어디에서 시작해서, 어디까지 데려갈 수 있는지에서 나온다. ## 참고한 리서치 - [Blue Ocean Strategy 공식 설명](https://www.blueoceanstrategy.com/what-is-blue-ocean-strategy/?ref=zerodraftlab.com) - [Red Ocean vs Blue Ocean Strategy](https://www.blueoceanstrategy.com/tools/red-ocean-vs-blue-ocean-strategy/?ref=zerodraftlab.com) - [Harvard Business Review, Blue Ocean Strategy](https://hbr.org/2004/10/blue-ocean-strategy?ref=zerodraftlab.com) - [HBR On Strategy, What Is Blue Ocean Strategy and Where Does It Go Wrong?](https://hbr.org/podcast/2023/05/what-is-blue-ocean-strategy-and-where-does-it-go-wrong?ref=zerodraftlab.com) - [Informa TechTarget, B2B Demand Generation Guide](https://www.informatechtarget.com/essentials/b2b-demand-generation-guide/?ref=zerodraftlab.com) - [High Tech Strategies, Crossing the Chasm Summary](https://www.hightechstrategies.com/crossing-the-chasm-summary/?ref=zerodraftlab.com) ### 자동화 몇 개로 AX는 오지 않는다 URL: https://zerodraftlab.com/automation-is-not-ax/ Last updated: 2026-07-11T12:54:37.000Z AI 전환은 반복 업무를 몇 개 자동화하는 순간이 아니라, 자동화가 책임·증거·예외 처리의 레일로 연결되는 순간에 시작된다. AX를 하다 보면 금방 알게 된다. 사내 업무 앱 몇 개 만들고, 반복 업무 몇 개 자동화한다고 회사가 바뀌지는 않는다. 절대로 그렇게는 안 된다. 물론 앱은 필요하다. 자동화도 필요하다. 매번 복붙하던 일을 줄이고, 여러 시스템에 흩어진 데이터를 한 화면에 모으고, 사람이 매일 하던 체크를 봇이 대신하게 만드는 일은 분명히 가치가 있다. 현업은 편해지고, 속도는 빨라지고, 작은 성과도 나온다. 하지만 그걸 AX라고 부르기 시작하면 문제가 생긴다. 회사는 업무 앱 몇 개의 합이 아니다. 회사는 정보가 흐르는 방식, 책임이 배분되는 방식, 고객에게 약속하는 방식, 예외를 처리하는 방식, 돈을 버는 방식, 그리고 중요한 순간에 누가 어떤 판단을 하는지의 총합이다. 그래서 기존 업무를 그대로 두고 그 위에 자동화만 얹으면, 회사가 바뀌는 게 아니라 기존 회사가 더 빠르게 반복될 뿐이다. 엉킨 업무는 자동화해도 엉켜 있다. 책임이 불분명한 프로세스는 자동화해도 책임이 불분명하다. 데이터가 믿을 수 없으면 대시보드를 만들어도 판단은 흔들린다. AX의 진짜 가치는 기능 자체보다 그 기능을 만들기 위해 업무 안으로 들어가는 과정에 있다. 자동화할 일을 찾으려면 먼저 물어야 한다. 이 일은 누가 하는가. 왜 하는가. 언제 시작되고 언제 끝나는가. 어떤 정보가 필요하고, 어디서 막히는가. 이 반복은 정말 단순 반복인가, 아니면 누군가의 판단을 임시로 메우고 있는가. 이 승인 단계는 필요한 통제인가, 책임 회피의 흔적인가. 이 엑셀은 임시 도구인가, 사실상 회사의 핵심 시스템인가. 이 질문들을 따라가다 보면 표면에 있던 업무가 벗겨진다. 처음에는 “이거 자동화하면 되겠다”로 시작했는데, 막상 들여다보면 문제는 자동화가 아닌 경우가 많다. 입력 항목이 많은 게 문제가 아니라 기준이 없는 게 문제일 수 있다. 리포트 작성 시간이 긴 게 문제가 아니라 어떤 숫자를 봐야 하는지 합의가 없는 게 문제일 수 있다. 승인 단계가 많은 게 문제가 아니라 누구에게 결정권이 있는지 불분명한 게 문제일 수 있다. 이 지점에서 AX는 도구 도입이 아니라 업무 해부가 된다. 좋은 AX는 모든 일을 없애려고 하지 않는다. 사람을 시스템 밖으로 밀어내는 것도 아니다. 오히려 사람이 해야 할 일과 시스템이 맡아야 할 일을 다시 나눈다. 시스템은 반복, 검색, 정리, 초안, 알림, 상태 추적을 맡는다. 사람은 맥락 설정, 예외 판단, 책임 있는 결정, 고객과 조직에 대한 해석을 맡는다. 이 구분이 없으면 자동화는 위험해진다. 판단이 필요한 일을 단순 업무처럼 처리하고, 책임이 필요한 일을 알림과 워크플로우 뒤에 숨긴다. 반대로 이 구분이 선명하면 자동화는 회사의 구조를 드러내는 도구가 된다. 무엇을 기계에 맡길 수 있는지보다, 무엇은 반드시 사람이 책임져야 하는지가 더 분명해진다. 그래서 AX팀은 단순한 도구 제작팀이 아니다. 좋은 AX팀은 앱을 만드는 팀이면서 동시에 조직을 읽는 팀이다. 현업의 말을 듣고, 실제 흐름을 따라가고, 반복 업무 밑에 숨어 있는 병목과 판단 구조를 드러낸다. 그리고 그 위에 필요한 만큼만 도구를 만든다. 이 과정은 느리고 귀찮다. 화려하지도 않다. “몇 시간 절감” 같은 숫자로 바로 포장하기 어려운 일도 많다. 하지만 이 과정이 없으면 AX는 사내 편의 기능 모음으로 끝난다. 반대로 이 과정을 제대로 거치면 회사는 자기 자신을 조금 더 정확히 보게 된다. AX의 1차 산출물은 앱이나 봇이 아니다. 진짜 산출물은 회사의 업무 지도가 다시 그려지는 것이다. 어디서 돈이 만들어지고, 어디서 시간이 새고, 어디서 판단이 멈추고, 어디서 사람이 불필요하게 소모되는지 보이기 시작하는 것이다. 그러니 AX를 평가하는 질문은 “무엇을 몇 개 자동화했나”에서 멈추면 안 된다. 더 중요한 질문은 이것이다. 이 과정을 통해 우리는 회사를 얼마나 더 정확히 이해하게 되었는가. 반복 업무 뒤에 숨어 있던 구조를 얼마나 드러냈는가. 사람이 해야 할 일과 시스템이 맡아야 할 일을 얼마나 더 선명하게 나눴는가. 그리고 그 결과, 회사는 이전보다 더 잘 판단하고 더 빠르게 움직일 수 있게 되었는가. 자동화 몇 개 한다고 될 게 아니다. 자동화는 입구일 뿐이다. 진짜 AX는 그 입구를 통해 회사의 업무 본질을 훑고, 다시 설계 가능한 상태로 만드는 일이다. ### 지능은 아무것도 아니다 URL: https://zerodraftlab.com/intelligence-is-nothing/ Last updated: 2026-07-11T12:54:40.000Z 똑똑함은 자산일 수 있지만, 자기 방어가 되는 순간 사고를 멈추게 만든다. 지능은 아무것도 아니라고 생각해야 한다. 진짜로 아무것도 아니라는 뜻은 아니다. 머리가 좋은 사람은 분명히 있다. 이해가 빠르고, 말을 잘하고, 복잡한 문제를 남들보다 빨리 잡아내는 사람도 있다. 그런데 인생을 오래 끌고 가는 태도로 보면, 지능은 생각보다 아무것도 아니다. 오히려 지능을 대단한 것으로 생각하는 순간부터 문제가 시작된다. 이 글은 일부러 용어와 함께 보려고 한다. 용어를 과시하려는 게 아니다. 어떤 문제는 이름을 붙여야 비로소 보인다. 이름이 없으면 사람은 같은 증상을 성격이라고 부르고, 같은 회피를 취향이라고 부르고, 같은 방어를 논리라고 부른다. 그러니 이 글은 “똑똑한 사람이 왜 배우지 못하는가”를 용어와 함께 하나씩 보는 글이다. ## 1\. 고정형 사고방식: 나는 배우는 사람이 아니라 증명해야 하는 사람이 된다 어릴 때 “똑똑하다”는 말을 많이 들은 사람이 있다. 시험을 잘 보고, 말을 빨리 이해하고, 선생님이 칭찬하고, 주변 어른들이 “쟤는 머리가 좋다”고 말한다. 처음에는 좋은 일이다. 자신감도 생기고, 기대도 받는다. 문제는 그 말이 너무 오래 간다는 데 있다. 사람은 자기가 반복해서 들은 말로 자기를 이해한다. “나는 머리가 좋다.” “나는 원래 잘한다.” “나는 남들보다 빨리 안다.” 이런 문장들은 처음엔 칭찬처럼 들어오지만, 시간이 지나면 정체성이 된다. 이걸 고정형 사고방식, fixed mindset이라고 부를 수 있다. 능력을 변하는 것으로 보지 않고, 이미 주어진 내 속성으로 보는 태도다. 나는 배우는 사람이 아니라 증명해야 하는 사람이 된다. 똑똑해지는 게 아니라, 똑똑해 보이는 일이 중요해진다. 그때부터 실패가 단순한 실패가 아니게 된다. 문제를 못 풀었다는 사실보다 “나는 똑똑한 사람인데 왜 못 풀었지?“라는 충돌이 먼저 온다. 일을 못했다는 사실보다 “나는 원래 잘하는 사람인데 왜 이런 평가를 받지?“라는 방어가 먼저 선다. ## 2\. 방어적 추론: 배우기 전에 나를 보호한다 여기서 생기는 게 방어적 추론, defensive reasoning이다. 현실을 배우기 위해 생각하는 게 아니라, 나에 대한 좋은 이야기를 지키기 위해 생각하는 것이다. 이 방어는 젊을 때는 그냥 자의식처럼 보인다. 조금 건방지고, 실패를 싫어하고, 인정받고 싶어하는 정도로 보인다. 그런데 이 자의식은 시간이 지나면 저절로 사라지지 않는다. 제때 깨지지 않으면 오히려 굳어진다. 30대, 40대가 되면 더 위험해진다. 그때는 잃을 게 생기기 때문이다. 평판이 있고, 경력이 있고, 직함이 있고, 과거 선택의 정당성이 있다. 이제 “내가 틀렸다”는 말은 단순한 반성이 아니다. 내가 지난 10년 동안 믿어온 내 모습이 틀릴 수도 있다는 말이 된다. 그래서 방어도 더 세련돼진다. 어릴 때는 그냥 삐지거나 피한다. 나이 들면 논리로 방어한다. 경험으로 방어하고, 맥락으로 방어하고, 업계 이해로 방어하고, 상대의 수준을 깎으면서 방어한다. 겉으로는 더 합리적인데, 실제로는 더 배우기 어려운 사람이 된다. ## 3\. 획득된 독단: 성취를 통해 닫힌 사람이 된다 이걸 획득된 독단, earned dogmatism이라고 부를 수 있다. 내가 많이 배웠고, 많이 해봤고, 어느 정도 성취했기 때문에 이제는 덜 열려 있어도 된다고 착각하는 것이다. 처음부터 꽉 막힌 사람이 아니라, 성취를 통해 닫힌 사람이 된다. 여기에 경직화, entrenchment가 온다. 생각이 깊어진 게 아니라 굳어진다. 판단이 날카로워진 게 아니라 익숙한 결론으로 빨리 돌아간다. 새로운 정보를 받아들이는 듯하지만, 실제로는 기존 자아상을 보강하는 재료만 고른다. ## 4\. 메타-망각: 예전에 알았던 것을 지금도 안다고 착각한다 더 무서운 건 메타-망각, meta-forgetfulness이다. 예전에 알았던 것을 지금도 안다고 착각하는 것이다. 한때 빨리 이해했던 기억, 학교에서 잘했던 기억, 예전의 성취가 지금의 판단력을 보증해주지 않는데 사람은 그 둘을 자주 섞는다. “내가 이 정도는 알지.” “내가 예전에 해봤지.” “내가 원래 감이 있지.” 이 말들이 아주 위험하다. 그 말들은 사실 지식의 증거가 아니라 업데이트 중단의 신호일 때가 많다. 똑똑한 사람일수록 이 방어를 잘한다. 말도 잘하고, 이유도 잘 만들고, 예외도 잘 찾는다. 피드백을 들으면 바로 배우기보다 먼저 번역한다. “저 사람은 상황을 몰라서 저렇게 말하는 거야.” “이번엔 조건이 안 좋았어.” “내 의도는 그게 아니었는데.” “전체 맥락을 보면 틀린 판단은 아니었어.” 그 말들이 전부 틀렸다는 뜻은 아니다. 실제로 상황이 나빴을 수도 있고, 상대가 몰랐을 수도 있고, 맥락이 있었을 수도 있다. 문제는 그 설명들이 너무 빨리 나온다는 데 있다. 현실을 보기 전에 자존심이 먼저 해석을 끝내버린다. ## 5\. 동기화된 추론: 답을 찾는 게 아니라 결론을 지킨다 이건 동기화된 추론, motivated reasoning이다. 답을 찾기 위해 생각하는 게 아니라, 이미 지키고 싶은 결론을 위해 생각하는 것이다. 여기에 자기봉사 편향, self-serving bias가 붙는다. 잘되면 내 실력이고, 안 되면 환경 탓이다. 성공은 정체성에 붙이고, 실패는 맥락으로 흘려보낸다. 그러면 사람은 계속 자신을 잃지 않는 대신 현실을 잃는다. 그래서 지능은 아무것도 아니라고 생각해야 한다. 중요한 건 내가 똑똑한가가 아니다. 지금 보고 있는 현실을 내가 얼마나 덜 왜곡하고 있는가다. 나는 원래 잘하는 사람이라는 생각보다, 이번 결과가 나에게 무엇을 말하고 있는가가 중요하다. 나는 머리가 좋다는 믿음보다, 내가 지금 무엇을 못 보고 있는가를 묻는 능력이 중요하다. ## 6\. 지적 겸손: 자신감과 업데이트 가능성을 같이 들고 간다 여기서 필요한 건 자기비하가 아니다. 지적 겸손, intellectual humility이다. 나는 아무것도 못한다는 태도가 아니라, 내가 틀릴 수 있다는 사실을 계속 열어두는 태도다. 자신감이 없는 사람이 되는 게 아니라, 자신감과 업데이트 가능성을 같이 들고 가는 것이다. 그리고 더 중요한 건 외부 자기인식, external self-awareness이다. 내가 나를 어떻게 생각하는지가 아니라, 내 말과 행동이 바깥에서 어떤 결과를 만들고 있는지 보는 능력이다. 나는 좋은 의도였다는 설명보다, 실제로 상대가 어떻게 받았는지. 나는 열심히 했다는 감정보다, 결과가 무엇을 말하는지. 나는 안다고 느끼는 것보다, 현실이 내 판단을 어떻게 채점했는지. ## 7\. 신념의 가설화: 믿음을 정체성이 아니라 가설로 둔다 탈출구는 하나다. 믿음을 정체성이 아니라 가설로 두는 것. 이걸 신념의 가설화, beliefs as hypotheses라고 부를 수 있다. “나는 똑똑한 사람이다”도 가설이어야 한다. “나는 이 일을 잘 안다”도 가설이어야 한다. “내 판단이 맞다”도 가설이어야 한다. 가설은 증거 앞에서 바뀐다. 결과가 나쁘면 다시 검토된다. 반대 증거가 나오면 업데이트된다. 그런데 정체성은 방어된다. 그래서 지능을 정체성으로 들고 있는 사람은 계속 자신을 보호하고, 지능을 도구로 들고 있는 사람은 계속 배운다. 지능은 자랑할수록 짐이 되고, 작게 다룰수록 도구가 된다. 어릴 때 들은 “너는 똑똑해”라는 말이 평생의 저주가 될 필요는 없다. 다만 어느 시점에는 그 말을 내려놓아야 한다. 나는 정말 똑똑한가가 아니라, 나는 아직도 배우고 있는가를 물어야 한다. 현실을 늦게 보는 사람은 대개 정보가 부족한 사람이 아니다. 자기 자신에 대한 오래된 설명이 너무 강한 사람이다. ## 참고한 용어와 출처 이 글은 아래 연구와 글에서 용어를 빌려왔다. 본문은 학술 요약이 아니라, 그 용어들을 개인의 학습과 커리어 방어기제라는 맥락으로 다시 풀어 쓴 에세이다. - 고정형 사고방식, fixed mindset: Carol Dweck의 mindset 연구. Stanford Center for Teaching and Learning의 [Growth Mindset](https://ctl.stanford.edu/students/growth-mindset?ref=zerodraftlab.com), Mueller & Dweck의 논문 [Praise for Intelligence Can Undermine Children’s Motivation and Performance](https://www.columbia.edu/cu/psychology/courses/3615/Readings/Mueller%5FDweck.pdf?ref=zerodraftlab.com)를 참고했다. - 방어적 추론, defensive reasoning: Chris Argyris의 HBR 글 [Teaching Smart People How to Learn](https://hbr.org/1991/05/teaching-smart-people-how-to-learn?ref=zerodraftlab.com)을 참고했다. - 획득된 독단, earned dogmatism: [When self-perceptions of expertise increase closed-minded cognition: The earned dogmatism effect](https://www.sciencedirect.com/science/article/pii/S0022103115001006?ref=zerodraftlab.com)를 참고했다. - 경직화, entrenchment: Erik Dane의 cognitive entrenchment 논지와 이를 다룬 [Overcoming the Shadow of Expertise](https://pmc.ncbi.nlm.nih.gov/articles/PMC6856640/?ref=zerodraftlab.com)를 참고했다. - 메타-망각, meta-forgetfulness: David Robson의 [What is the intelligence trap? A taxonomy of stupidity](https://davidrobson.me/what-is-the-intelligence-trap-a-taxonomy-of-stupidity/?ref=zerodraftlab.com)와 책 [The Intelligence Trap](https://books.google.com/books/about/The%5FIntelligence%5FTrap.html?id=SGCNEAAAQBAJ&ref=zerodraftlab.com)를 참고했다. - 동기화된 추론, motivated reasoning: Ziva Kunda의 [The Case for Motivated Reasoning](https://pubmed.ncbi.nlm.nih.gov/2270237/?ref=zerodraftlab.com)을 참고했다. - 자기봉사 편향, self-serving bias: 성공은 내부 요인으로, 실패는 외부 요인으로 돌리는 attribution bias 논의로, [self-serving attributional bias](https://link.springer.com/article/10.1186/s11782-018-0028-8?ref=zerodraftlab.com) 관련 정리를 참고했다. - 외부 자기인식, external self-awareness: Tasha Eurich의 HBR 글 [What Self-Awareness Really Is](https://hbr.org/2018/01/what-self-awareness-really-is-and-how-to-cultivate-it?ref=zerodraftlab.com)를 참고했다. - 신념의 가설화, beliefs as hypotheses: Good Judgment의 [Beliefs as Hypotheses](https://goodjudgment.com/superforecasters-toolbox-beliefs/?ref=zerodraftlab.com)와 Paul Graham의 [Keep Your Identity Small](https://paulgraham.com/identity.html?ref=zerodraftlab.com)를 참고했다. ### AI-native 팀에서 먼저 깨지는 것은 코드가 아니라 운영이다 URL: https://zerodraftlab.com/ai-native-engineering-org-process/ Last updated: 2026-07-11T12:54:43.000Z 코드 작성 비용이 내려가면 개발팀의 병목은 구현이 아니라 계획, 리뷰, 보안, 책임 구조로 이동한다. AI-native engineering org라는 말은 멋있게 들린다. 모든 엔지니어가 Claude Code를 쓰고, PR이 빨리 나오고, 반복 구현이 줄고, 제품 실험이 많아지는 팀. 겉으로 보면 생산성 이야기처럼 보인다. 하지만 실제로 더 큰 변화는 다른 곳에서 일어난다. 코드 작성이 싸지면 오래된 프로세스가 깨진다. Fiona Fung의 [Running an AI-native engineering org](https://www.youtube.com/watch?v=igO8iyca2%5Fg&ref=zerodraftlab.com)는 이 변화를 조직 운영의 언어로 설명한다. 발표의 핵심은 “AI를 쓰면 개발자가 빨라진다”가 아니다. 코드 작성이 병목이 아니게 되면, 그동안 코드 작성의 느린 속도에 맞춰져 있던 계획, 리뷰, 협업, 보안, 유지보수 방식이 더 이상 맞지 않는다는 것이다. 이게 무서운 지점이다. 프로세스는 보통 크게 실패하지 않는다. 조용히 안 맞기 시작한다. 예전에는 설계 문서를 길게 쓰고, 회의를 잡고, 리뷰를 기다리고, 구현을 나눠서 진행하는 흐름이 자연스러웠다. 코드 작성이 비쌌기 때문이다. 만들기 전에 오래 생각하는 비용이 합리적이었다. 그런데 구현과 프로토타입이 싸지면 상황이 달라진다. 아이디어를 두고 오래 말다툼하는 것보다 실제 PR이나 프로토타입을 보는 편이 빠를 수 있다. 문서로 모든 가능성을 설명하기보다, 작게 만들어 내부 사용자를 붙여보고 반응을 보는 편이 낫다. 이때 예전 프로세스를 그대로 유지하면 이상한 일이 생긴다. 팀은 더 빨리 만들 수 있는데, 결정 방식은 여전히 느린 시대에 머문다. 하지만 반대로 아무 계획 없이 만들기만 하면 더 위험해진다. 코드가 싸졌다고 논의가 필요 없어지는 건 아니다. 오히려 alignment의 중요성은 커진다. 마지막에 PR을 올린 사람이 이기는 문화, 가장 오래 깨어 있던 사람이 방향을 밀어붙이는 문화는 AI 시대에 더 위험하다. 만들기가 쉬워질수록 잘못된 방향도 더 빨리 쌓인다. 그래서 AI-native 팀의 핵심은 속도가 아니라 규범이다. 무엇을 문서로 남길지, 무엇을 PR로 논의할지, 어떤 변경은 프로토타입으로 충분한지, 어떤 변경은 여전히 설계가 필요한지 정해야 한다. 모든 일을 가볍게 만들자는 뜻이 아니다. 무거워야 할 일과 가벼워져도 되는 일을 다시 나누자는 뜻이다. 리뷰도 달라진다. AI가 코드를 많이 만들수록 사람은 모든 코드를 같은 깊이로 읽을 수 없다. 그러면 리뷰의 목적을 다시 정해야 한다. 스타일을 고치는 리뷰인지, 제품 감각을 보는 리뷰인지, 보안과 유지보수 리스크를 보는 리뷰인지 분리해야 한다. Claude가 잡을 수 있는 것은 Claude에게 맡기고, 사람이 봐야 하는 것은 더 명확히 봐야 한다. 보안도 뒤로 밀리면 안 된다. 생성 속도가 빨라질수록 잘못된 권한, 과한 자동화, 민감 정보 노출, 위험한 배포 경로도 빨리 생긴다. AI-native 팀은 “AI를 많이 쓰는 팀”이 아니라, AI가 빨리 움직일 때 어떤 gate가 필요한지 아는 팀이어야 한다. 인재상도 바뀐다. 영상에서 강조되는 두 축은 흥미롭다. 하나는 제품 감각이 있는 creative builder다. 문제를 발견하고, 빠르게 만들어보고, 사용자 경험을 다듬는 사람. 다른 하나는 깊은 시스템 전문성이다. 복잡한 기반 구조를 이해하고, 모델이 놓치는 낮은 층위의 문제를 잡는 사람. 중간의 반복 구현만 잘하던 역할은 압력을 받는다. AI가 반복 구현을 싸게 만들면, 사람에게 더 중요해지는 것은 방향 감각과 깊이다. 무엇을 만들지 정하는 감각, 만든 것이 실제로 좋은지 보는 감각, 시스템이 어디서 깨질지 아는 감각이다. 단순히 “코드를 쓸 줄 안다”만으로는 충분하지 않다. 측정 지표도 조심해야 한다. “AI가 몇 퍼센트의 코드를 썼나”는 쉬운 지표지만, 좋은 지표는 아니다. 코드가 늘어난 것이 곧 제품이 좋아진 것은 아니다. 중요한 건 품질, 신뢰성, 사용자 문제 해결, 유지보수성이다. AI-native 팀이 진짜로 봐야 하는 것은 output volume이 아니라 outcome이다. 이 점에서 AI-native라는 말은 도구 도입보다 조직 재설계에 가깝다. Claude Code를 전원에게 설치한다고 팀이 AI-native가 되지 않는다. 코드가 빨라진 뒤 어떤 논의가 줄어들고, 어떤 검증이 늘어나야 하며, 어떤 역할이 더 중요해지는지 바꿔야 한다. 그렇지 않으면 팀은 더 많은 코드를 더 빠르게 만들 뿐, 더 나은 제품을 만들지는 못한다. AI-native 팀의 첫 번째 변화는 손이 빨라지는 것이 아니다. 조직의 오래된 리듬이 안 맞기 시작하는 것이다. 그 리듬을 다시 맞추는 팀만이 속도를 진짜 힘으로 바꿀 수 있다. ### 비싼 것은 상징 없이는 팔리지 않는다 URL: https://zerodraftlab.com/expensive-things-need-symbols/ Last updated: 2026-07-11T12:54:46.000Z 고가 상품은 논리로 의심을 낮추고, 상징으로 결정을 정당화한다. 둘 중 하나만 있으면 구매는 끝까지 가지 않는다. 고가 상품일수록 논리가 더 중요해 보인다. 가격이 높으니 설명도 더 촘촘해야 할 것 같다. 기능을 보여줘야 하고, 성과를 증명해야 하고, 비교표를 만들어야 하고, 반론을 처리해야 한다. 고객이 돈을 크게 쓰려면 그만큼 합리적인 근거가 필요하다고 생각한다. 반은 맞고 반은 틀리다. 고가 상품에 논리는 필요하다. 논리가 없으면 의심을 낮출 수 없다. 고객은 바보가 아니고, 비싼 물건을 살 때 아무 이유 없이 움직이지 않는다. 무엇이 다른지, 왜 비싼지, 손해가 아닌지, 대체재보다 나은지 확인하려 한다. 하지만 고가 상품을 논리만으로 사게 만드는 일은 비용이 너무 높다. 모든 기능을 설명하고, 모든 반론을 처리하고, 모든 ROI를 계산하게 만들면 고객은 납득하기 전에 지친다. 설명은 늘어날수록 설득력이 높아지는 것이 아니라, 어느 순간 판단 피로를 만든다. 고객은 이해하기 위해 읽기 시작했지만, 너무 많은 정보 앞에서 결정을 미룬다. 그래서 고가 상품은 결국 상징과 기호를 필요로 한다. 상징은 복잡한 판단을 압축한다. 이 브랜드가 어떤 세계에 속하는지, 이 제품을 쓰는 사람이 어떤 사람처럼 보이는지, 이 제안을 받아들이는 일이 자기 정체성과 충돌하지 않는지. 고객은 가격이 높아질수록 제품만 사는 것이 아니라, 그 제품이 대표하는 세계에 들어간다. 고관여 고객은 자세히 본다. 하지만 자세히 본다는 것은 숫자와 기능만 본다는 뜻이 아니다. 오히려 고관여 고객은 더 많은 층위를 본다. 문장, 태도, 철학, 사례, 디자인, 주변 사람들의 반응, 만든 사람이 반복해서 쓰는 언어까지 본다. 책이 있다면 책까지 보는 이유도 여기에 있다. 책은 긴 설명서가 아니다. 책은 신뢰와 세계관의 긴 형식이다. “이 사람이 어떤 생각을 반복해서 해왔는가”, “이 제품이 어떤 관점에서 나왔는가”, “내가 이 세계에 들어가도 되는가”를 확인하는 장치다. 비싼 상품을 살 때 고객은 단지 묻지 않는다. “이게 합리적인가?” 그보다 더 깊은 질문이 따라온다. “내가 이걸 사는 사람이 되어도 되는가?” 이 질문은 비교표만으로 풀리지 않는다. 기능 설명만으로도 부족하다. 여기에는 상징이 필요하다. 브랜드의 언어, 디자인의 질감, 고객 사례의 종류, 만든 사람의 태도, 콘텐츠의 결, 가격을 말하는 방식까지 모두 기호가 된다. 논리는 의심을 낮춘다. 하지만 상징은 결정을 압축한다. 좋은 고가 상품은 둘 중 하나를 고르지 않는다. 논리 없이 상징만 있으면 허세가 된다. 상징 없이 논리만 있으면 피곤한 제안서가 된다. 사람은 납득해야 하지만, 동시에 자신이 들어갈 세계를 감지해야 한다. 그래서 고가 상품의 메시지는 설명서처럼만 쓰면 안 된다. 설명은 필요하다. 근거도 필요하다. 하지만 끝까지 논리로만 밀고 가면 고객의 머리는 설득될지 몰라도 몸이 움직이지 않는다. 고가의 결정에는 언제나 자기 이미지가 섞인다. 내가 이 돈을 쓰는 사람이라는 감각. 이 선택이 나를 어떤 방향으로 데려간다는 감각. 저가는 후킹만으로도 팔릴 수 있다. 고가는 논리가 필요하다. 하지만 진짜 고가는 결국 상징으로 결정된다. ### 제품은 하나지만 메시지는 여러 개여야 한다 URL: https://zerodraftlab.com/one-product-many-messages/ Last updated: 2026-07-11T12:54:49.000Z 제품의 본질은 하나일 수 있지만, 고객이 제품을 만나는 상황은 하나가 아니다. 그래서 하나의 제품에는 여러 문장이 필요하다. 제품을 설명하는 문서는 중요하다. 무엇을 만들었는지, 누구에게 필요한지, 어떤 기능이 있고, 어떤 이익을 주는지. 이런 것을 정리하지 않으면 카피는 금방 감상문이 된다. 그래서 FAB 문서는 필요하다. 제품의 사실, 장점, 효익을 나눠 적어두는 일은 메시지의 기초 체력이다. 하지만 기초 체력이 곧 경기는 아니다. 많은 사람이 제품 메시지를 만들 때 이상한 착각을 한다. 제품의 본질을 정확히 정리하면, 그에 맞는 대표 문장도 하나로 정리될 거라고 믿는다. 가장 정확한 설명, 가장 좋은 후킹, 가장 설득력 있는 오퍼가 어딘가에 있고, 그것을 찾으면 된다고 생각한다. 현실은 다르다. 하나의 제품에는 여러 개의 문이 있다. 어떤 사람은 시간 절약이라는 문으로 들어온다. 어떤 사람은 불안 해소라는 문으로 들어온다. 어떤 사람은 돈을 더 벌 수 있다는 문장에 반응하고, 어떤 사람은 더 이상 이렇게 일하고 싶지 않다는 피로감에 반응한다. 제품은 하나여도, 고객이 제품을 발견하는 이유는 하나가 아니다. 그래서 메시징은 정답 찾기가 아니라 조합 만들기에 가깝다. 먼저 제품의 진실이 있다. 이 제품이 실제로 무엇을 하는지, 어떤 문제를 줄이는지, 어떤 결과를 만들 수 있는지. 이 층위가 FAB다. 이것은 재료다. 여기서 거짓말을 하면 안 된다. 과장도 오래 못 간다. 그다음에는 야마가 있다. 같은 제품을 어떤 문제로 읽게 할 것인가. “업무를 줄여준다”와 “결정 피로를 줄여준다”와 “회사가 AI에게 읽히게 만든다”는 같은 제품에서 나올 수 있지만, 완전히 다른 세계를 연다. 야마는 기능 설명이 아니라 해석의 방향이다. 그 위에 후킹이 붙는다. 처음 3초에 어떤 긴장을 걸 것인가. 고객이 지나치려던 손가락을 멈추게 하는 문장. 후킹은 제품 전체를 설명하지 않아도 된다. 다만 더 읽을 이유를 만들어야 한다. 그리고 카피가 있다. 후킹으로 만든 긴장을 납득 가능한 흐름으로 밀고 가는 문장들. 여기서 제품의 사실, 사례, 비교, 감정, 반론 처리가 연결된다. 마지막으로 오퍼가 있다. 그래서 지금 무엇을 하라는 것인가. 읽을 것인가, 신청할 것인가, 결제할 것인가, 상담할 것인가, 템플릿을 받을 것인가. 오퍼는 좋은 문장의 결론이 아니라 거래 구조다. 고객이 메시지를 소비하는 깊이도 모두 다르다. 어떤 사람은 후킹만 보고 결제한다. 이미 문제를 충분히 느끼고 있고, 신뢰 임계값도 낮고, 지금 필요한 것이 명확한 사람이다. 이런 사람에게는 긴 설명보다 정확한 긴장과 선명한 오퍼가 더 중요하다. 반대로 어떤 사람은 끝까지 본다. 제품 설명을 보고, 사례를 보고, 비교를 보고, FAQ를 보고, 만든 사람이 어떤 생각을 하는지도 본다. 책이 있다면 책까지 본다. 고관여 고객에게 메시지는 광고 문구가 아니라 판단 자료다. 그래서 좋은 메시징 시스템은 짧은 문장과 긴 논리를 동시에 가져야 한다. 후킹은 저관여 고객을 움직이고, 카피는 중간 관여 고객을 납득시키고, 문서와 에세이와 책은 고관여 고객의 의심을 천천히 낮춘다. 그러니 제품 메시지를 하나의 대표 카피로 너무 빨리 닫으면 안 된다. FAB 문서는 정본이다. 하지만 FAB 문서가 최종 산출물은 아니다. 최종 자산은 채택된 조합이다. 어떤 야마가 먹혔는지, 어떤 후킹이 멈추게 했는지, 어떤 카피가 납득시켰는지, 어떤 오퍼가 행동으로 이어졌는지. 이것이 쌓이면 카피가 아니라 플레이북이 된다. 제품은 하나여도 된다. 하지만 문장은 여러 개여야 한다. 그리고 결국 살아남는 것은 우리가 제일 좋아한 문장이 아니라, 고객이 자기 문제의 이름으로 채택한 문장이다. ### 제품은 카테고리가 아니라 생존 조건으로 죽는다 URL: https://zerodraftlab.com/products-die-by-survival-conditions/ Last updated: 2026-07-11T12:54:53.000Z Painkiller, Vitamin, Candy라는 분류는 편하지만, 고객이 실제로 돈을 내는 조건을 설명하기에는 부족하다. 제품 아이디어를 볼 때 자주 하는 질문이 있다. 이건 Painkiller인가, Vitamin인가, Candy인가. 처음 들으면 단순한 분류처럼 보인다. 고통을 해결하면 Painkiller. 있으면 좋은 개선이면 Vitamin. 재미와 호기심을 주면 Candy. 하지만 이 질문이 중요한 이유는 이름표 때문이 아니다. 이 분류는 제품이 살아남기 위해 필요한 조건을 가른다. Painkiller는 없어지면 일이 깨져야 한다. Vitamin은 좋아질 거라는 믿음이 반복되어야 한다. Candy는 지금 당장 손이 가야 한다. 셋은 같은 제품처럼 보여도 완전히 다른 게임이다. Painkiller는 손실을 줄이는 게임이다. 사용자는 이미 문제를 겪고 있다. 돈이 새고, 시간이 터지고, 리스크가 커지고, 일이 밀린다. 그래서 좋은 Painkiller는 설명이 길 필요가 없다. 이거 없으면 오늘 뭐가 깨지는지가 명확하면 된다. 회계 자동화, 고객 응대 자동화, 팀 커뮤니케이션 툴, 이슈 트래커가 강한 이유는 여기에 있다. 사용자가 멋진 미래를 상상해서 사는 게 아니다. 이미 불편하고, 이미 비용을 내고 있고, 이미 수작업으로 버티고 있기 때문에 산다. Vitamin은 다르다. Vitamin은 현재의 고통보다 미래의 개선을 판다. 더 건강해질 것 같다. 더 생산적일 것 같다. 더 정리될 것 같다. 더 나은 사람이 될 것 같다. 문제는 이 좋아질 것 같다는 감각이 구매와 반복 사용까지 이어지기 어렵다는 점이다. 사람들은 좋은 말에는 쉽게 동의하지만, 습관과 지갑은 천천히 움직인다. 그래서 Vitamin 제품은 제품력만으로는 부족하다. 신뢰, 커뮤니티, 루틴, 사회적 증거가 필요하다. Candy는 또 다르다. Candy는 논리보다 반응이 먼저다. 재밌다. 눌러보고 싶다. 공유하고 싶다. 나를 표현하고 싶다. 밈 생성기, AI 아바타, 운세 앱, SNS 필터는 대개 여기서 시작한다. Candy는 가볍다고 해서 약한 시장이 아니다. 오히려 가장 빠르게 퍼질 수 있다. 다만 오래 남으려면 반복되는 새로움, 관계망, 정체성, 창작 흐름 중 하나에 붙어야 한다. 재미만 있고 쌓이는 것이 없으면 금방 사라진다. 그래서 중요한 건 우리 제품은 셋 중 어디냐가 아니다. 진짜 질문은 이것이다. 우리는 어떤 욕망을 다루고 있는가. 사용자는 이 제품을 잃었을 때 무엇을 잃는가. 그리고 그 결핍은 돈을 낼 만큼 강한가. 많은 제품이 여기서 자기 자신을 속인다. 실제로는 Vitamin인데 Painkiller처럼 가격을 매긴다. 실제로는 Candy인데 B2B SaaS처럼 진지하게 설명한다. 실제로는 Painkiller인데 기능표만 늘어놓다가 고통을 보여주지 못한다. 제품이 실패하는 건 꼭 문제가 약해서가 아니다. 자기가 어떤 종류의 욕망을 다루는지 잘못 읽어서 실패한다. AI 회의 요약을 보자. 일반 직장인에게는 Vitamin일 수 있다. 있으면 좋다. 회의록이 깔끔해진다. 하지만 없어도 일은 굴러간다. 그런데 하루에 고객 미팅을 8개씩 하는 세일즈팀에게는 다르다. 미팅 기록이 CRM 업데이트, 후속 연락, 계약 타이밍, 고객 기억과 연결된다. 요약이 빠지면 기회가 새고, 다음 액션이 늦어진다. 이 순간 AI 회의 요약은 Vitamin이 아니라 Painkiller가 된다. 밈 생성기도 마찬가지다. 대부분의 사람에게는 Candy다. 재미있고, 공유하고, 잊는다. 하지만 매일 반응형 콘텐츠를 만들어야 하는 SNS 운영자에게는 다르다. 빠르게 소재를 만들고, 여러 버전을 테스트하고, 반응을 뽑아야 한다면 밈 생성기는 업무 도구가 된다. 같은 제품도 사용자의 상황에 따라 생존 조건이 바뀐다. 결국 제품의 분류는 기능이 아니라 맥락에서 나온다. 누가 쓰는가. 언제 쓰는가. 무엇을 대체하는가. 얼마나 자주 반복되는가. 안 쓰면 어떤 손실이 생기는가. 이 질문들이 시장 진입 방식을 바꾼다. Painkiller는 고통이 있는 곳으로 가야 한다. 이미 예산이 있고, 이미 불편이 있고, 이미 대체재가 있는 곳을 찾아야 한다. 마케팅은 꿈보다 손실을 보여줘야 한다. 가격은 절약되는 비용이나 줄어드는 리스크를 기준으로 잡을 수 있다. 핵심 지표는 가입보다 유지와 작업 흐름 안착에 가깝다. Vitamin은 믿음을 설계해야 한다. 사용자가 좋아질 것이라는 감각을 반복해서 확인하게 만들어야 한다. 콘텐츠, 커뮤니티, 전문가성, 진전 피드백이 중요하다. 가격은 효용보다 신뢰의 문제에 가깝다. 핵심 지표는 단순 가입보다 반복 루틴과 체감 진전이다. Candy는 첫 반응이 전부다. 설명 전에 손이 가야 한다. 공유하고 싶어야 한다. 결과물이 즉시 나와야 한다. 가격보다 확산이 먼저일 수 있다. 핵심 지표는 클릭, 공유, 생성, 반복되는 새로움이다. 이 셋을 구분하지 않으면 제품 운영이 흔들린다. Painkiller에 필요한 것은 명확한 손실 증명인데, 팀은 예쁜 온보딩을 만들고 있을 수 있다. Vitamin에 필요한 것은 신뢰와 반복 루틴인데, 팀은 기능만 추가하고 있을 수 있다. Candy에 필요한 것은 즉시성인데, 팀은 복잡한 가입 플로우를 만들고 있을 수 있다. 그래서 Painkiller, Vitamin, Candy는 분류표가 아니라 운영 프레임이다. 어떤 고객을 먼저 볼지. 어떤 메시지로 팔지. 어떤 가격을 받을지. 어떤 지표를 볼지. 어떤 기능을 먼저 만들지. 어디까지 가야 좋은 제품이 아니라 없으면 곤란한 제품이 되는지. 좋은 제품은 보통 하나의 분류에만 머물지 않는다. 가장 강한 제품은 Candy처럼 시작해서 Painkiller처럼 남는다. 처음에는 쉽고 재밌게 들어온다. 결과가 바로 보인다. 사용자는 부담 없이 눌러본다. 그러다 반복 사용 속에서 기록, 관계, 작업 흐름, 자산, 정체성에 붙는다. 그 순간 제품은 선택지가 아니라 기본값이 된다. 반대로 Painkiller도 Candy의 얼굴을 가질 수 있다. 업무 문제를 해결하더라도 첫 경험이 가볍고, 결과가 즉시 보이고, 사용자가 오 하는 순간을 느끼면 도입 장벽이 내려간다. 중요한 건 겉모양이 아니다. 안쪽에서 어떤 결핍을 잡고 있느냐다. 제품의 강도는 기능 수로 결정되지 않는다. 결핍의 강도로 결정된다. 사용자가 좋네라고 말하면 아직 부족하다. 언젠가 쓰면 좋겠다도 부족하다. 재밌다도 시작일 뿐이다. 진짜 신호는 더 단순하다. 이걸 못 쓰게 되면 사용자가 실망하는가. 다시 예전 방식으로 돌아가기 싫어하는가. 자기 돈, 자기 시간, 자기 팀의 작업 흐름 안에 자리를 내주는가. Painkiller, Vitamin, Candy가 중요한 이유는 여기에 있다. 이 분류는 제품을 멋지게 설명하기 위한 말이 아니다. 제품이 어떤 방식으로 살아남아야 하는지 알려주는 지도다. 사용자의 고통을 줄일 것인가. 사용자의 미래를 믿게 만들 것인가. 사용자의 즉시 반응을 당길 것인가. 셋 중 무엇이든 가능하다. 하지만 어느 게임을 하는지는 알아야 한다. 제품은 카테고리로 죽지 않는다. 자기 생존 조건을 착각할 때 죽는다. --- 참고: [David Cummings, Candy, Vitamins, or Painkillers for Startups](https://davidcummings.org/2011/10/11/candy-vitamins-or-painkillers-for-startups/?ref=zerodraftlab.com), [First Round Review, How Superhuman Built an Engine to Find Product/Market Fit](https://review.firstround.com/how-superhuman-built-an-engine-to-find-product-market-fit/?ref=zerodraftlab.com), [Bain, Elements of Value](https://www.bain.com/insights/delivering-what-consumers-really-value/?ref=zerodraftlab.com), [Harvard Business Review, Know Your Customers’ Jobs to Be Done](https://hbr.org/2016/09/know-your-customers-jobs-to-be-done?ref=zerodraftlab.com) ### 내 취향을 알아봐 달라는 마음이 제품을 망친다 URL: https://zerodraftlab.com/taste-recognition-is-dangerous/ Last updated: 2026-07-11T12:54:56.000Z 취향은 좋은 출발점이지만 시장 검증의 근거가 되지는 않는다. 위험한 것은 취향 자체가 아니라, 고객이 그 취향을 알아봐 주길 기다리는 태도다. 나만의 무언가를 만들고 싶다는 마음 안에서 제일 위험한 것은 취향이라고 생각한다. 정확히는 취향 자체가 위험한 게 아니다. 내 취향을 누군가 알아봐 줬으면 하는 마음이 위험하다. 이 마음은 꽤 그럴듯한 얼굴을 하고 온다. 나는 아무거나 만들고 싶지 않다. 싸구려로 팔고 싶지 않다. 남들이 다 하는 걸 따라 하고 싶지 않다. 내 기준이 있고, 내 감각이 있고, 내가 좋아하는 결이 있다. 여기까지는 좋다. 취향은 좋은 출발점이 될 수 있다. 문제는 그 다음이다. 내 취향을 기준으로 무언가를 만들다 보면, 어느 순간 고객보다 내가 앞에 온다. 고객이 무엇 때문에 돈을 내는지보다, 사람들이 내 감각을 알아봐 주는지가 더 중요해진다. 제품을 팔고 싶은 건지, 내 안목을 인정받고 싶은 건지 흐려진다. 이때부터 사업은 이상해진다. 이름을 고르는 데 오래 걸린다. 문장을 다듬는 데 오래 걸린다. 무드와 톤을 잡는 데 오래 걸린다. 그런데 정작 고객이 왜 이걸 사야 하는지에는 말이 짧아진다. “이 감각을 알아보는 사람은 알아볼 거야.” “이 결을 좋아하는 사람이 분명 있을 거야.” “이 정도 퀄리티면 사람들이 반응할 거야.” 위험한 말들이다. 왜냐하면 이 말들은 고객을 말하는 척하지만, 사실은 나를 말하고 있기 때문이다. 고객의 문제, 고객의 상황, 고객의 지불 이유가 아니라 내 취향의 정당성을 확인받고 싶은 마음에 가깝다. 취향은 검증이 아니다. 좋아요도 검증이 아니다. 멋있다는 말도 검증이 아니다. 진짜 검증은 훨씬 차갑다. 누가 돈을 내는가. 왜 지금 내는가. 다시 살 이유가 있는가. 대체재보다 비싸도 고를 이유가 있는가. 이 질문 앞에서 취향은 자주 힘을 잃는다. 물론 취향은 중요하다. 취향 없는 제품은 쉽게 흐려진다. 하지만 취향은 고객에게 도착해야 힘이 생긴다. 내가 좋아하는 색, 문장, 질감, 세계가 고객에게 어떤 선택의 이유가 되는지 설명되지 않으면, 그것은 사업의 자산이 아니라 자기만족에 가깝다. 가장 위험한 순간은 사람들이 내 취향을 칭찬할 때다. “느낌 좋다.” “너답다.” “감각 있다.” “이런 거 좋아하는 사람 많을 것 같다.” 이 말들은 기분이 좋다. 그래서 더 위험하다. 이 말들은 나를 앞으로 가게 만들지만, 꼭 사업을 앞으로 가게 만들지는 않는다. 관객의 박수와 고객의 결제는 다르다. 박수는 내가 멋있어 보였다는 신호일 수 있지만, 결제는 자기 문제를 해결하겠다는 선택이다. 그래서 나는 나만의 무언가를 만들고 싶다는 마음이 들 때마다 이 질문을 먼저 해야 한다고 생각한다. 나는 고객의 문제를 풀고 싶은가, 아니면 내 취향을 알아봐 줄 사람을 찾고 있는가. 둘은 처음에 비슷하게 생겼다. 하지만 끝은 완전히 다르다. 앞의 것은 사업이 될 수 있고, 뒤의 것은 전시가 되기 쉽다. 앞의 것은 고객을 향하고, 뒤의 것은 나를 향한다. 앞의 것은 가격과 유통과 반복 구매를 견디고, 뒤의 것은 반응과 칭찬 앞에서 멈춘다. 내 취향을 알아봐 줬으면 하는 마음은 인간적이다. 누구나 자기 안목을 인정받고 싶다. 문제는 그 마음이 사업의 얼굴을 하고 들어오는 순간이다. 그러면 인정욕구가 전략처럼 보이고, 자기표현이 시장성처럼 보이고, 취향의 일관성이 사업의 진전처럼 보인다. 그래서 더 조심해야 한다. 사업은 내 취향을 설명하는 일이 아니다. 고객이 돈을 낼 이유를 만드는 일이다. 취향은 출발점일 수 있다. 하지만 결제만이 검증이다. ### 에이전트에게 모든 걸 시키지 마라 URL: https://zerodraftlab.com/dont-make-agents-do-everything/ Last updated: 2026-07-11T12:54:59.000Z 요즘 AI 제품을 보면 한 가지 욕망이 반복된다. 모든 일을 agent에게 시키고 싶어 한다. 사람이 자연어로 명령하면 agent가 알아서 판단하고, 도구를 호출하고, 파일을 만들고, 메시지를 보내고, 결과를 보고한다. 이름은 계속 바뀐다. OpenClaw든 Hermes든, 또는 다른 agent framework든, 밑에 깔린 상상은 비슷하다. 업무 시스템을 만들지 말고 똑똑한 agent에게 맡기자는 상상이다. 그 상상은 매력적이다. 특히 데모에서는 강하다. 화면에 명령을 한 줄 넣었는데 여러 단계 일이 자동으로 굴러간다. 사람이 만든 폼, 버튼, 승인 플로우, 배치 시스템 같은 것들이 갑자기 구식처럼 보인다. 마치 MVC 웹앱을 만드는 대신 agent 하나가 운영팀, PM, 개발자, 회계팀 역할을 다 해줄 것처럼 느껴진다. 그런데 운영으로 들어가면 이야기가 달라진다. 업무의 대부분은 사실 창의적 판단이 아니다. 같은 입력이면 같은 출력이 나와야 한다. 실패하면 재현할 수 있어야 한다. 누가 언제 무엇을 바꿨는지 남아야 한다. 권한이 맞는지 확인해야 하고, 승인 없이 바뀌면 안 되는 값이 있어야 한다. 비용도 예측 가능해야 한다. 이런 일까지 agent에게 맡기면 생산성이 올라가는 게 아니라 시스템이 흐려진다. 어제는 A라고 판단했는데 오늘은 B라고 판단한다. 왜 실패했는지 로그를 봐도 “모델이 그렇게 생각했다” 이상으로 내려가기 어렵다. 같은 요청을 다시 넣으면 다른 실행 경로를 탄다. 비용은 요청마다 달라지고, latency도 흔들린다. 무엇보다 audit trail이 약해진다. 이건 AI가 나쁘다는 말이 아니다. 오히려 반대다. AI를 진짜 운영에 쓰려면 agent가 하지 말아야 할 일을 먼저 정해야 한다. ## 다시 웹앱이 중요해진다 여기서 낡아 보이는 구조가 다시 중요해진다. MVC다. 웹앱이다. DB다. queue다. service object다. job이다. AI 시대에도 Model은 필요하다. 오히려 더 중요해진다. Model은 상태와 정본을 잡는다. 고객, 주문, 계약, 티켓, 캠페인, 리포트, 승인 상태, 실행 이력 같은 것들이 모델로 남아야 한다. 그래야 시스템이 기억을 가진다. Controller와 Service는 결정적 실행을 맡는다. 같은 input이면 같은 output이 나와야 하는 것들이다. 권한 체크, 정산 계산, 상태 전이, 알림 발송, 배치 실행, 외부 API write, 파일 생성 같은 것들은 코드가 해야 한다. 코드로 되어 있어야 테스트할 수 있고, 롤백할 수 있고, 감시할 수 있다. View는 사람이 보는 운영 표면이다. agent가 결과를 냈더라도 사람은 그것을 검토하고 승인하고 수정할 수 있어야 한다. 좋은 View는 단순한 UI가 아니라 판단 표면이다. 무엇이 바뀌는지, 왜 추천됐는지, 어떤 근거가 있는지, 승인하면 어디에 write되는지 보여줘야 한다. 그럼 agent는 어디에 들어가는가? Agent는 시스템 전체가 아니다. Agent는 판단 엔진이다. 더 정확히는 deterministic software 안에 꽂히는 비결정적 판단 layer다. 정산 금액 계산은 agent에게 맡기면 안 된다. 코드가 해야 한다. 하지만 “이 정산 건은 왜 이상해 보이는가?“를 설명하는 건 agent가 잘할 수 있다. 권한 체크는 코드가 해야 한다. 하지만 “이 요청은 어떤 정책에 걸릴 가능성이 있는가?“를 요약하는 건 agent가 잘할 수 있다. 고객 메시지 발송은 deterministic command가 해야 한다. 하지만 메시지 초안 작성은 agent가 잘할 수 있다. 이 차이를 놓치면 agent는 시스템을 강하게 만드는 대신 시스템의 경계를 흐린다. ## 반복되는 것은 코드로 졸업시켜라 AI 운영의 핵심은 agent에게 더 많은 일을 시키는 게 아니다. 반복되는 일을 agent에게서 빼앗는 것이다. 처음에는 agent가 분류해도 된다. 처음에는 agent가 판단해도 된다. 처음에는 agent가 수동 작업의 빈틈을 메워도 된다. workflow가 아직 불안정하고, 입력이 지저분하고, 사람이 어떤 기준으로 판단하는지도 확정되지 않았을 때 agent는 훌륭한 임시 운영자다. 하지만 같은 판단이 반복되기 시작하면 다른 질문을 해야 한다. 이건 아직 agent가 해야 하는 일인가? 아니면 이제 모델, 서비스, job, test, runbook으로 내려야 하는 일인가? 정산 계산은 코드가 해야 한다. 상태 변경은 service가 해야 한다. 반복 실행은 job이 해야 한다. 권한 검사는 policy가 해야 한다. 실패 감지는 monitor가 해야 한다. 회귀 방지는 test가 해야 한다. 예외 분류는 agent가 도울 수 있다. 긴 문서 요약은 agent가 잘한다. 초안 작성도 agent가 잘한다. 하지만 최종 write는 deterministic command와 audit log가 가져가야 한다. 이렇게 나누면 agent의 가치가 줄어드는 게 아니다. 오히려 커진다. agent가 모든 걸 직접 하려고 하면 매번 새롭게 판단해야 한다. 반대로 웹앱과 DB와 job이 기본 구조를 잡아주면 agent는 정말 애매한 구간에 집중할 수 있다. 그러면 비용도 줄고, 결과도 안정되고, 사람이 검토하기도 쉬워진다. 좋은 agent 시스템은 agent가 많은 시스템이 아니다. Agent가 할 일과 하지 말아야 할 일이 명확한 시스템이다. ## 자연어 인터페이스는 정본이 아니다 많은 agent-first 제품이 헷갈리는 지점이 여기에 있다. 자연어 인터페이스를 업무 시스템이라고 착각한다. 자연어 명령은 interface일 수 있다. 아주 좋은 interface일 수도 있다. 사람이 복잡한 폼을 다 채우지 않고 “지난주 캠페인 성과 보고서 만들어줘”라고 말하는 것은 훌륭한 UX다. 하지만 그 말 자체가 정본은 아니다. 정본은 데이터 모델, 상태 전이, 승인 기록, 실행 로그, 테스트, runbook에 있다. agent가 채팅창에서 무언가 해냈다고 해서 그게 운영 시스템이 되는 것은 아니다. 운영 시스템은 같은 일을 다시 할 수 있어야 한다. 누가 실행했는지 보여야 한다. 어디까지 자동이고 어디서부터 사람 승인인지 분명해야 한다. 실패하면 어느 단계에서 실패했는지 보여야 한다. 그리고 더 중요한 것은, 한 번 배운 일이 다음 실행에 남아야 한다. 채팅창은 쉽게 흘러간다. 시스템은 남아야 한다. ## Agent는 Controller가 아니다 그래서 나는 AI 제품을 만들 때 agent를 controller로 두는 설계가 위험하다고 본다. Controller는 요청을 받아 정해진 규칙에 따라 상태를 바꾼다. 권한을 확인하고, 필요한 service를 호출하고, 실패하면 정해진 error path로 보낸다. 이 레이어가 비결정적이면 시스템 전체가 흔들린다. Agent는 controller가 아니라 advisor에 가깝다. 또는 compiler, analyst, drafter에 가깝다. agent는 애매한 input을 구조화하고, 긴 context를 압축하고, 사람이 놓친 edge case를 제안하고, 다음 액션 후보를 만든다. 하지만 실행은 좁은 command로 내려야 한다. `approve_invoice` `publish_post` `send_email` `sync_customer_record` `create_followup_task` 이런 command는 입력, 권한, validation, side effect, audit log가 정해져 있어야 한다. agent는 이 command를 직접 발명하는 것이 아니라, 가능한 command 중 어떤 것을 제안할지 판단해야 한다. 사람이 승인하면 deterministic system이 실행한다. 이 구조가 훨씬 강하다. ## AI-native는 agent-native와 다르다 AI-native라는 말을 agent-native로 오해하면 안 된다. AI-native 운영은 모든 일을 autonomous agent에게 맡기는 것이 아니다. 오히려 deterministic software와 judgment engine을 결합하는 것이다. 안정된 것은 코드가 한다. 불확실한 것은 agent가 돕는다. 그리고 불확실했던 것이 안정되면 다시 코드로 내려간다. 이 흐름이 진짜 compound다. Agent가 같은 분류를 매번 반복하고 있다면, 그건 자동화가 덜 된 것이다. Agent가 같은 보고서를 매주 처음부터 만들고 있다면, 그건 모델과 query와 template이 아직 부족한 것이다. Agent가 같은 정책 판단을 계속 설명하고 있다면, 그건 rule, guard, UI state로 내려갈 준비가 된 것이다. Agent의 반복 업무는 성공이 아니라 부채일 수 있다. 좋은 시스템은 시간이 갈수록 agent의 자유도를 무한히 키우지 않는다. 오히려 agent가 자유롭게 판단해야 하는 면적을 줄인다. agent가 다룬 예외를 관찰하고, 반복 패턴을 추출하고, 안정된 부분을 코드로 고정한다. 그러면 agent는 점점 더 어려운 판단으로 올라갈 수 있다. 사람도 마찬가지다. 좋은 조직은 사람이 매번 같은 양식을 다시 만들게 하지 않는다. 체크리스트, 템플릿, dashboard, workflow, 자동화로 내린다. AI 운영도 같다. Agent가 직원처럼 일하는 듯 보여도, 진짜 목표는 직원 수를 늘리는 것이 아니다. 업무 시스템을 진화시키는 것이다. ## 결론 에이전트에게 모든 걸 시키지 마라. 같은 입력에 같은 출력이 필요한 일은 소프트웨어가 해야 한다. 상태를 바꾸는 일은 command와 service가 해야 한다. 반복 실행은 job이 해야 한다. 권한과 감사는 시스템이 잡아야 한다. Agent는 그 위에서 판단을 돕는다. 애매한 것을 분류하고, 긴 것을 요약하고, 초안을 만들고, 예외를 설명하고, 다음 액션을 제안한다. 그리고 그 판단이 반복되면 다시 시스템으로 내려간다. AI의 미래는 모든 걸 알아서 하는 agent 직원이 아니다. AI의 미래는 deterministic software 안에 배치된 judgment engine이다. 참고: - Anthropic, [Building effective agents](https://www.anthropic.com/engineering/building-effective-agents?ref=zerodraftlab.com) - OpenAI, [A practical guide to building agents](https://cdn.openai.com/business-guides-and-resources/a-practical-guide-to-building-agents.pdf?ref=zerodraftlab.com) - Kieran Klaassen, Every, [The Folder Is the Agent](https://every.to/source-code/the-folder-is-the-agent?ref=zerodraftlab.com) ### 좋은 상품은 고객의 동사를 바꾼다 URL: https://zerodraftlab.com/good-products-change-customer-verbs/ Last updated: 2026-07-11T12:55:02.000Z 좋은 상품은 고객의 문제를 잘 부르는 데서 끝나지 않는다. 문제에 이름을 붙이는 건 중요하다. 이름 없는 불편은 예산이 되기 어렵고, 이름 없는 고통은 회의실에 들어가기 어렵다. 어떤 현상에 이름이 붙는 순간, 사람들은 비로소 “우리가 겪는 게 이거였구나”라고 말할 수 있다. 하지만 거기까지는 입구다. 진짜 상품은 고객이 자기 문제를 부르는 말을 바꾸는 데서 멈추지 않는다. 고객이 그 문제 앞에서 무엇을 하게 되는지를 바꾼다. 언어의 발명도 사실 단어 하나를 만드는 일이 아니다. 새 단어가 생겼다고 곧바로 언어가 되는 것은 아니다. 중요한 건 그 말을 언제 쓰는지, 그 말을 들으면 사람들이 어떻게 반응하는지, 그 말이 어떤 행동을 가능하게 하는지다. “번아웃”이라는 말은 단순히 피곤함의 다른 이름이 아니다. 그 말은 피로를 개인 의지의 문제가 아니라 일, 회복, 조직문화, 병가, 상담의 문제로 옮겼다. 단어 하나가 생긴 것 같지만, 실제로는 사람들이 자기 상태를 해석하고 말하고 요구하는 방식이 바뀐 것이다. 상품도 같다. 기능 하나가 있다고 상품이 되는 게 아니다. 좋은 상품은 “이 상황에서는 이렇게 움직이면 된다”는 새 행동 규칙을 만든다. Slack은 메시지를 보내는 기능만 만든 게 아니다. 회사의 잡다한 대화를 채널로 나누고, 사람을 멘션하고, 스레드로 맥락을 묶고, 리액션으로 짧게 응답하는 방식을 퍼뜨렸다. 이전에도 회사에는 대화가 있었다. 하지만 Slack 이후에는 많은 조직이 대화를 다른 문법으로 처리하기 시작했다. Figma도 단순한 디자인 툴이 아니다. 파일을 보내고, 버전을 맞추고, 회의실에서 화면을 보며 피드백하던 행동을 바꿨다. 이제 디자인은 한 사람의 로컬 파일이 아니라 여러 사람이 동시에 들어가 보고, 말하고, 고치는 공간이 됐다. Google은 정보를 찾는 행동을 바꿨고, Uber는 차를 부르는 행동을 바꿨고, Notion은 문서와 지식을 정리하는 행동을 바꿨다. 그래서 위대한 상품은 명사보다 동사에 가깝다. 사람들은 “검색한다”고 말하고, “우버 탄다”고 말하고, “슬랙에 남긴다”고 말하고, “피그마에서 보자”고 말한다. 상품이 고객의 하루 안에 동사로 들어오는 순간, 그 상품은 단순한 도구가 아니라 생활과 업무의 문법이 된다. 여기서 흔한 오해가 생긴다. 많은 사람은 product-market fit을 니즈와 솔루션의 일치라고 생각한다. 고객에게 문제가 있고, 우리가 해결책을 만들고, 둘이 맞으면 팔린다는 식이다. 틀린 말은 아니다. 다만 너무 정적이다. 현실에서는 고객이 이미 어떤 방식으로 버티고 있다. 엑셀로 관리하고, 카톡방으로 공지하고, 전화로 확인하고, 담당자 기억으로 넘기고, 매주 같은 내용을 복사해서 붙여넣는다. 상품은 그 행동을 대체해야 한다. 더 정확히는 고객이 기존 행동에서 새 행동으로 이주하게 만들어야 한다. 그러니까 product-market fit은 솔루션이 문제에 맞는 순간만이 아니다. 고객의 행동 문법이 옮겨가는 순간이다. 좋은 상품은 고객에게 “당신의 문제는 이것입니다”라고 말한다. 하지만 더 좋은 상품은 거기서 한 발 더 간다. “이제부터는 이렇게 하면 됩니다.” 이 문장이 붙어야 상품이 된다. 문제명은 시장의 입구를 만든다. 고객이 왜 신경 써야 하는지, 왜 예산을 써야 하는지, 왜 지금 봐야 하는지를 설명한다. 하지만 행동 문법은 시장을 점유한다. 고객이 내일부터 어떻게 일할지, 어떤 버튼을 누를지, 누구에게 무엇을 보낼지, 무엇을 더 이상 하지 않을지를 정한다. 그래서 상품을 만든다는 건 기능을 추가하는 일이 아니다. 고객의 하루에서 어떤 동사를 빼고, 어떤 동사를 새로 넣을지 정하는 일이다. 좋은 상품은 문제를 해결하기 전에 행동을 재배치한다. 그리고 그 행동이 충분히 자연스러워지면, 사람들은 어느 순간 이렇게 느낀다. 원래 이렇게 했어야 했는데. 이 착각이야말로 좋은 상품이 만든 가장 강한 증거다. 언어도 그렇다. 좋은 말은 처음엔 낯설지만, 한 번 자리 잡으면 이전 세계가 어색해진다. 상품도 그렇다. 좋은 상품은 처음엔 새로운 도구처럼 보이지만, 자리를 잡고 나면 이전 행동이 이상해 보인다. 그러므로 언어의 발명과 상품의 발명이 닮은 지점은 명명에서만 나오지 않는다. 더 깊은 닮음은 문법에 있다. 좋은 단어는 생각하는 방식을 바꾸고, 좋은 상품은 움직이는 방식을 바꾼다. 문제명은 고객의 머릿속에 들어가지만, 상품은 고객의 손과 일정과 회의와 습관 안으로 들어간다. 결국 시장을 차지하는 상품은 가장 많은 기능을 가진 상품이 아니다. 고객의 동사를 바꾼 상품이다. ### 고객은 미래를 말하지 않는다. 대신 이상한 방식으로 버틴다 URL: https://zerodraftlab.com/customers-dont-describe-future/ Last updated: 2026-07-11T12:55:06.000Z 고객은 미래를 잘 말하지 못한다. 무엇이 필요하냐고 물으면 대개 지금 알고 있는 언어 안에서 답한다. 더 싸게. 더 빠르게. 더 쉽게. 더 예쁘게. 더 알아서 되게. 틀린 말은 아니다. 다만 충분하지 않다. 사람은 아직 존재하지 않는 해법을 정확한 제품명으로 요구할 수 없다. 자기 문제가 어떤 카테고리로 해결될 수 있는지도 모른다. 고객 인터뷰에서 “어떤 제품이 필요하세요?“라고 물으면 답이 흐려지는 이유가 여기에 있다. 고객은 미래의 제품을 설명하는 사람이 아니라, 현재의 불편을 견디는 사람에 가깝다. 그래서 시장의 미래는 고객의 말보다 고객의 이상한 행동에 더 먼저 나타난다. 고객은 엑셀 파일을 만든다. 카카오톡방을 업무 시스템처럼 쓴다. 매주 같은 내용을 복사해서 붙여넣는다. 담당자 한 명이 머리로 기억한다. 캘린더, 메신저, 스프레드시트, 전화, 문자, 노션이 이상하게 얽힌 임시 체계를 만든다. 겉으로 보면 별일 아닌 것처럼 보인다. 회사마다 있는 수작업이고, 업계 관행이고, 원래 그렇게 하는 일처럼 보인다. 하지만 그 안에는 이미 수요가 있다. 아직 구매 요청서나 검색어로 번역되지 않았을 뿐이다. 고객은 돈을 쓰지 않는 것처럼 보이지만 사실은 시간을 쓰고 있다. 집중력을 쓰고, 인건비를 쓰고, 실수를 감수하고, 담당자의 기억력에 의존하고 있다. 이런 비용은 장부에 잘 드러나지 않는다. 그래서 시장조사에서도 자주 놓친다. 고객에게 “이 문제에 돈을 낼 의향이 있나요?“라고 물으면 답은 애매하다. 그런데 현장을 보면 이미 돈을 내고 있다. 다만 소프트웨어 구독료가 아니라 야근, 회의, 확인 전화, 중복 입력, 재작업의 형태로 내고 있을 뿐이다. 수요는 처음부터 명확한 문장으로 시작하지 않는다. 처음에는 비정상적인 행동으로 시작한다. 고객이 어떤 일을 계속 우회하고 있다면, 거기에는 이유가 있다. 여러 도구를 억지로 이어 붙이고 있다면, 기존 제품이 문제를 충분히 해결하지 못하고 있다는 뜻이다. 불편하다고 말하지조차 않는다면, 그 불편이 너무 오래되어 업무의 일부로 굳어졌을 가능성이 있다. 이 지점이 중요하다. 가장 좋은 기회는 불만이 폭발한 곳이 아니라, 불편이 체념으로 굳어진 곳에서 나온다. 불만은 이미 언어가 된 문제다. 리뷰에 남고, 고객센터에 접수되고, 경쟁사도 듣는다. 하지만 체념은 더 깊다. 고객은 그것을 문제라고 부르지 않는다. 그냥 “이건 원래 손이 많이 가요”, “이건 사람이 봐야 해요”, “아직 자동화는 어렵죠”라고 말한다. 바로 그 문장들이 중요하다. 그 안에 아직 제품화되지 않은 시장이 숨어 있다. 트렌드를 읽는다는 것은 유행어를 빨리 줍는 일이 아니다. AI, 자동화, 웰니스, 개인화 같은 키워드는 이미 표면으로 올라온 결과다. 더 앞단의 신호는 사람들이 어떤 불편을 당연하게 받아들이고 있는지, 어떤 일을 임시방편으로 처리하고 있는지, 어떤 비용을 비용이라고 인식하지 못하는지에 있다. 좋은 관찰자는 “고객이 무엇을 원한다고 말하는가”보다 “고객이 이미 무엇을 하고 있는가”를 본다. 반복되는 엑셀은 데이터베이스의 신호다. 반복되는 카톡 공지는 작업 흐름 제품의 신호다. 반복되는 전화 확인은 신뢰 인프라의 신호다. 반복되는 복사 붙여넣기는 자동화 수요의 신호다. 반복되는 담당자 의존은 시스템 부재의 신호다. 고객은 미래를 설명하지 않는다. 대신 현재를 이상하게 운영한다. 그리고 그 이상함을 오래 관찰하면 다음 시장이 보인다. 물론 모든 수작업이 사업 기회는 아니다. 어떤 일은 정말로 규모가 작고, 어떤 불편은 돈을 낼 만큼 절박하지 않다. 어떤 업무는 사람 손으로 하는 편이 여전히 낫다. 그래서 봐야 할 것은 단순한 불편이 아니라 반복성과 비용이다. 얼마나 자주 반복되는가. 몇 명이 같은 방식으로 버티고 있는가. 실수했을 때 손실이 큰가. 담당자가 바뀌면 무너지는가. 이미 다른 방식으로 돈이나 시간을 쓰고 있는가. 이 질문에 “그렇다”가 쌓이면 그건 단순한 불편이 아니다. 아직 이름 없는 수요다. 시장은 고객의 선언으로 열리지 않는다. 고객은 “우리는 이런 카테고리의 제품을 원합니다”라고 말하지 않는다. 대신 이상한 파일명, 이상한 단톡방, 이상한 수기 장부, 이상한 승인 절차, 이상한 야근 패턴을 남긴다. 그 흔적을 읽는 사람이 트렌드를 먼저 본다. 트렌드는 미래에서 오는 것이 아니다. 고객이 오늘 억지로 버티고 있는 방식 속에서 이미 시작되고 있다. ### 바이럴은 해자가 아니라 신용대출이다 URL: https://zerodraftlab.com/cluely-viral-trust-debt/ Last updated: 2026-07-11T12:55:08.000Z Roy Lee 이야기는 너무 쉽게 소비된다. Columbia 학생이 AI로 면접을 속였다. Amazon 인턴 면접을 통과했다. 학교에서 쫓겨났다. 그런데 그 논란을 발판으로 Cluely라는 회사를 만들고, 수백만 달러 투자를 받고, 엄청난 매출을 만들었다. 숏폼으로 만들기 좋은 이야기다. 반항적인 20대 창업자. 낡은 면접 시스템을 조롱한 제품. 학교 징계를 마케팅 자산으로 바꾼 감각. “cheat on everything”이라는 위험한 문장. 여기에 a16z 투자까지 붙으면 완성된다. 하지만 이 이야기를 그냥 “나쁘게라도 유명해지면 이긴다”로 읽으면 너무 얕다. 그리고 위험하다. 우선 사실부터 정리해야 한다. 한국어권에서 이 사례가 돌 때 자주 붙는 “퇴학”과 “연매출 95억” 같은 표현은 그대로 쓰기 어렵다. Columbia Spectator 보도에 따르면 Roy Lee는 1년 정학 처분을 받았고, 이후 공동창업자 Neel Shanmugam과 함께 Columbia를 떠났다. 즉 대중적으로는 “쫓겨났다”로 소비됐지만, 정확히는 정학 후 중퇴에 가깝다. 매출 숫자는 더 조심해야 한다. 2025년 TechCrunch는 Roy Lee가 Cluely의 ARR이 700만 달러라고 말했다고 보도했다. 원화로 대략 90억 원대라서 “연매출 95억” 같은 표현이 여기서 나왔을 가능성이 높다. 그런데 2026년 3월, Roy Lee 본인이 그 700만 달러 ARR 주장이 거짓이었다고 정정했다. TechCrunch도 이를 별도 기사로 보도했다. 그러니까 이 글의 출발점은 성공담이 아니다. Cluely는 AI 시대의 초기 스타트업이 어떻게 attention을 빌려 성장하는지 보여준다. 동시에 그 attention이 신뢰 없이 만들어졌을 때 어떤 부채가 생기는지도 보여준다. 나는 이 케이스의 야마를 이렇게 본다. **바이럴은 해자가 아니라 신용대출이다.** 초기에는 돈처럼 쓸 수 있다. 사람을 모으고, 언론을 부르고, 투자자를 설득하고, 제품이 완성되기 전에 시장의 기억을 선점한다. 하지만 대출에는 이자가 있다. 그 이자의 이름은 신뢰다. ## 모두가 싫어하던 시스템을 찔렀다 Roy Lee가 처음 만든 것은 Interview Coder였다. LeetCode 스타일의 기술 면접에서 AI가 실시간으로 답을 도와주는 도구다. 화면에 보이지 않는 방식으로 문제를 읽고, 답변을 만들어주고, 면접관에게는 드러나지 않는다는 식으로 홍보됐다. 이 제품은 윤리적으로 문제가 많다. 하지만 왜 터졌는지는 이해해야 한다. Interview Coder가 겨냥한 것은 단순히 “면접에서 커닝하고 싶은 사람”이 아니었다. 더 깊게는 개발자들이 오래 불만을 품어온 기술 면접 시스템이었다. LeetCode 문제를 많이 외운 사람이 실제 일을 잘하는가. 알고리즘 퍼즐을 실시간으로 푸는 능력이 제품을 만들고 운영하는 능력과 얼마나 관련이 있는가. 몇백 시간을 면접 준비에 쓰는 것이 개발자의 성장에 정말 도움이 되는가. 이 질문은 이미 시장 안에 있었다. Roy Lee는 그 질문에 예쁜 백서를 쓴 게 아니다. 가장 공격적인 제품 데모를 던졌다. “그럼 이 면접 시스템이 그렇게 훌륭하다면, AI 커닝툴 하나로 뚫리는 건 어떻게 설명할 건데?“라는 식이었다. Gizmodo 보도에서 Lee는 Amazon, Meta, TikTok 같은 회사의 면접을 통과했다고 주장했다. Amazon은 Lee 개인 케이스를 확인하지 않았고, 무단 도구 사용 금지 원칙만 밝혔다. 즉 이 부분은 Roy Lee 측 주장으로 읽어야 한다. 그래도 마케팅 효과는 실제였다. 사람들은 제품을 본 게 아니라 균열을 봤다. 모두가 조금씩 싫어하던 시스템에 누군가 너무 노골적인 방식으로 돌을 던진 것이다. 초기 바이럴의 핵심은 여기 있다. 새로운 분노를 만드는 게 아니다. 이미 존재하던 분노에 이름을 붙이는 것이다. ## 제품보다 먼저 프레임이 팔렸다 Cluely의 초기 제품이 엄청난 기술적 해자를 가졌다고 보기는 어렵다. TechCrunch는 Cluely가 hidden in-browser window로 온라인 대화를 분석하고 실시간 노트, 맥락, 질문 제안을 제공하는 제품이라고 설명했다. 지금 공식 사이트도 “실시간 AI meeting assistant”와 “화면 공유에서 보이지 않는 기능”을 전면에 둔다. 회의 내용을 듣고, 화면을 읽고, 답변을 제안하는 AI 보조 도구. 이 자체는 곧바로 경쟁이 붙는 영역이다. 실제로 TechCrunch의 2025년 7월 보도에서도 Cluely와 유사한 오픈소스 제품이 빠르게 등장했다는 이야기가 나온다. AI 앱에서 기능은 오래 혼자 남아 있기 어렵다. 화면 읽기, 음성 인식, 실시간 요약, 답변 추천은 모델과 운영체제 API가 좋아질수록 점점 더 흔한 기능이 된다. 그렇다면 Cluely가 먼저 판 것은 무엇인가. 프레임이다. “회의 도중 도움을 주는 AI”라고 말하면 평범하다. “cheat on everything”이라고 말하면 모두가 반응한다. 좋아하는 사람은 “드디어 솔직하다”고 말한다. 싫어하는 사람은 “이건 너무 위험하다”고 말한다. 언론은 다룬다. 투자자는 본다. 경쟁자는 따라 한다. 잠재 고객은 한 번쯤 눌러본다. 대부분의 초기 스타트업은 여기서 진다. 제품 설명은 있는데 프레임이 없다. 기능은 있는데 적이 없다. 타깃 고객은 있는데 그 고객이 이미 느끼던 불만을 건드리는 문장이 없다. 그래서 글을 써도 설명문이 되고, 런칭을 해도 업데이트 노트가 되고, 랜딩 페이지를 만들어도 기능표가 된다. Cluely는 반대였다. 제품보다 먼저 시장이 반응할 말을 찾았다. 그 말이 품위 있었느냐는 별개의 문제다. 하지만 선명했느냐고 묻는다면 그렇다. 그리고 초기 시장에서 선명함은 종종 품위보다 빨리 돈을 부른다. ## AI 앱에서 분배가 해자처럼 보이는 이유 a16z가 Cluely에 투자한 이유를 다룬 TechCrunch 기사에서 중요한 대목은 “momentum is the moat”라는 관점이다. AI 소비자 앱에서는 기능이 빠르게 복제된다. 그러면 느리게 완성도를 쌓는 제품 전략만으로는 부족하다. 빠르게 만들고, 빠르게 유통하고, 빠르게 시장의 기억을 차지하는 능력이 더 중요해진다. 이 말은 불편하지만 현실적이다. AI 앱의 기능 차이는 예전 소프트웨어보다 빨리 압축된다. 어제는 독특했던 기능이 오늘은 오픈소스 예제가 되고, 다음 달에는 대형 모델 제공사의 기본 기능이 된다. UI도 복제되고, 프롬프트도 복제되고, 기능 이름도 복제된다. 이 환경에서 초기 팀이 가질 수 있는 상대적 우위는 세 가지 정도다. 첫째, 특정 문제를 누구보다 빨리 말하는 것. 둘째, 그 문제를 기억나는 방식으로 보여주는 것. 셋째, 그 기억을 제품 사용과 매출로 전환하는 것. Cluely는 적어도 첫째와 둘째를 매우 잘했다. “AI가 회의 중 답을 도와준다”가 아니라 “AI가 모든 것을 커닝하게 해준다”고 말했다. 그 말은 너무 거칠었지만, 한 번 들으면 잊기 어려웠다. 초기 스타트업에서 마케팅은 종종 제품 밖의 일이 아니다. 제품이 어떤 문제를 건드리는지, 어떤 세계관을 갖는지, 누구를 불편하게 하는지, 누가 몰래 응원하게 되는지를 정하는 일이다. 특히 AI 제품처럼 기능이 빨리 평준화되는 시장에서는 더 그렇다. 기능표만으로는 오래 버티기 어렵다. 사람들이 회사를 어떤 문장으로 기억하는지가 먼저 생겨야 한다. 이 지점에서 Roy Lee는 확실히 감각이 있었다. 그는 제품을 설명하지 않았다. 논쟁을 만들었다. ## 그런데 논쟁은 신뢰를 대신하지 못한다 문제는 그 다음이다. 논쟁은 사람을 데려올 수 있다. 하지만 사람을 머물게 하는 것은 다른 것이다. 제품의 효용, 고객의 반복 사용, 실제 매출, 기업 고객의 신뢰, 법적 리스크 관리, 창업자의 말에 대한 믿음. 여기서 Cluely의 이야기는 단순한 성공담에서 벗어난다. 2025년 TechCrunch는 Roy Lee가 Cluely의 ARR이 700만 달러라고 말했다고 보도했다. 그런데 2026년 3월, Lee는 그 숫자가 거짓이었다고 공개 정정했다. TechCrunch는 그 정정 자체도 다시 보도했다. Lee는 당시 실제 수치를 consumer ARR 270만 달러, enterprise ARR 250만 달러 수준으로 설명했지만, 이 역시 회사 측 공개값이다. 이 사건은 중요하다. 왜냐하면 Cluely가 이미 “cheat”라는 단어를 마케팅 자산으로 쓰고 있었기 때문이다. 제품 메시지는 “커닝”을 농담처럼 다룬다. 그런데 창업자가 매출 숫자까지 틀리게 말하면, 대중은 쉽게 연결한다. 제품도 속이는 제품이고, 매출도 속였네. 이 프레임은 무섭다. 바이럴은 초기에는 자산처럼 보인다. 하지만 바이럴의 원료가 과장, 모호함, 윤리적 회색지대, 창업자의 과격한 발언이라면 그 자체가 신뢰 부채가 된다. 처음에는 언론이 붙고, 투자자가 붙고, 사람들이 농담처럼 공유한다. 그런데 어느 순간부터 모든 숫자와 모든 약속이 의심받기 시작한다. 이게 바이럴의 이자다. 관심을 싸게 빌린 줄 알았는데, 나중에는 더 비싼 신뢰 비용을 낸다. ## 나쁘게라도 유명해지라는 말은 틀렸다 Cluely를 보고 “결국 유명해지면 이기는구나”라고 말하는 건 반만 맞고 반은 틀리다. 유명해지는 건 확실히 중요하다. 아무도 모르는 제품은 팔리지 않는다. 특히 초기 AI 제품은 더 그렇다. 기능이 빠르게 복제되는 시장에서는 조용히 완벽한 제품을 만들겠다는 태도가 오히려 위험할 수 있다. 제품이 완성될 때쯤이면 시장의 관심은 다른 곳으로 가 있고, 같은 기능은 이미 여러 팀이 만들어놓았을 수 있다. 그러니 분배를 먼저 생각해야 한다. 하지만 “나쁘게라도”는 다른 이야기다. 나쁜 유명세가 늘 나쁜 것은 아니다. 어떤 시장에서는 기존 질서를 공격해야 하고, 누군가는 불편한 말을 해야 한다. 문제는 불편함의 출처다. 좋은 논쟁은 고객의 실제 불만에서 나온다. 나쁜 논쟁은 창업자의 관심 욕구에서 나온다. 좋은 논쟁은 낡은 시스템의 모순을 드러낸다. 나쁜 논쟁은 제품의 빈 곳을 가린다. 좋은 논쟁은 시간이 지나면 신뢰로 바뀔 수 있다. 나쁜 논쟁은 시간이 지날수록 피로감과 의심으로 바뀐다. Cluely가 배울 만한 지점은 “논란을 만들었다”가 아니다. “모두가 불만을 갖고 있던 기술 면접이라는 시스템을 정확히 찔렀다”는 점이다. 여기서 배워야 한다. 커닝을 따라 할 필요는 없다. 거짓말을 따라 하면 안 된다. 따라 할 것은 tension을 찾는 능력이다. ## 좋은 바이럴은 이미 있던 긴장에 이름을 붙인다 초기 팀이 물어야 할 질문은 “어떻게 하면 논란이 될까?“가 아니다. 그 질문을 던지는 순간 대개 얄팍해진다. 일부러 화나게 만들고, 일부러 과장하고, 일부러 선을 넘는 쪽으로 간다. 그러면 단기 조회수는 나올 수 있다. 하지만 그 조회수가 제품의 신뢰와 연결된다는 보장은 없다. 더 나은 질문은 이거다. **우리 고객이 이미 화나 있는데, 아직 공개적으로 말하지 못한 것은 무엇인가?** 개발자는 LeetCode 면접에 화가 나 있었다. 영업팀은 회의 후 CRM 정리에 화가 나 있을 수 있다. 병원 원장은 광고비를 쓰는데 어떤 환자가 왜 오는지 모르는 상황에 화가 나 있을 수 있다. 소상공인은 대행사가 매달 리포트를 주지만 실제 매출과 연결되지 않는 데 화가 나 있을 수 있다. 프리랜서는 “개인 브랜딩 해야 한다”는 말은 많지만 실제로 돈이 되는 글쓰기 구조가 없는 데 지쳐 있을 수 있다. 이런 긴장은 이미 시장 안에 있다. 좋은 마케팅은 이것을 발명하지 않는다. 발견한다. 그리고 사람들이 속으로 하던 말을 밖으로 꺼낸다. Cluely는 그걸 매우 거칠게 했다. 그래서 크게 터졌다. 하지만 거칠게 해야만 터지는 것은 아니다. 오히려 오래 가려면 더 정확해야 한다. 더 구체적이어야 하고, 더 책임질 수 있어야 한다. 강한 문장은 선을 넘는 문장이 아니다. 책임질 수 있는 만큼만 세게 말하는 문장이다. ## 실무적으로 가져갈 것 Cluely에서 가져갈 수 있는 실무 교훈은 네 가지다. 첫째, 제품 설명보다 먼저 적을 정해야 한다. 여기서 적은 경쟁사가 아니다. 고객이 이미 싫어하는 낡은 방식이다. Cluely의 적은 다른 면접 보조 도구가 아니라 LeetCode 중심 기술 면접이었다. 좋은 초기 마케팅은 경쟁사를 때리는 게 아니라, 고객이 이미 피로감을 느끼는 기존 관행을 겨냥한다. 둘째, 데모는 기능 설명이 아니라 세계관 증거여야 한다. Cluely의 Amazon 면접 이야기가 위험했던 이유는 동시에 강했던 이유이기도 하다. 제품이 무엇을 주장하는지 말로 설명하지 않고 사건으로 보여줬다. 모든 팀이 이런 식으로 선을 넘을 필요는 없다. 하지만 데모가 단순 화면 녹화인지, 아니면 우리 제품이 믿는 세계를 증명하는 장면인지는 구분해야 한다. 셋째, 분배는 제품 완성 후에 붙이는 장식이 아니다. AI 앱에서는 특히 그렇다. 기능이 빨리 복제되면, 시장의 기억을 선점하는 능력이 제품 전략의 일부가 된다. “다 만든 다음 마케팅”은 너무 늦을 수 있다. 만들면서 어떤 문장으로 기억될지 같이 설계해야 한다. 넷째, 숫자와 약속은 건드리면 안 된다. 바이럴 메시지는 과격할 수 있다. 관점은 도발적일 수 있다. 하지만 매출, 고객 수, 성능, 법적 안전성 같은 신뢰 지표는 과장하면 안 된다. 창업자가 attention을 얻기 위해 숫자를 흐리게 말하는 순간, 이후 모든 메시지가 의심받는다. 이 네 번째가 가장 중요하다. 초기 스타트업은 신뢰가 부족하다. 브랜드도 약하고, 제품도 덜 익었고, 고객 사례도 적다. 그래서 창업자의 말이 곧 담보다. 그 담보를 태워서 attention을 사면, 당장은 빠르게 갈 수 있다. 하지만 나중에 더 비싼 비용으로 갚게 된다. ## 그래서 Cluely는 무엇을 남겼나 나는 Roy Lee를 단순한 사기꾼으로만 보는 것도, 천재 창업자로만 보는 것도 둘 다 게으른 해석이라고 생각한다. 그는 분명히 시대의 감각을 잡았다. AI 제품은 기능만으로 오래 버티기 어렵고, 초기에는 분배가 제품만큼 중요하며, 시장의 기억을 선점하는 창업자가 큰 우위를 가진다. 이걸 몸으로 보여줬다. 그리고 사람들이 이미 불만을 갖고 있던 시스템을 공격하면, 작은 팀도 거대한 주목을 만들 수 있다는 것도 보여줬다. 동시에 그는 attention의 위험도 보여줬다. 논란으로 만든 성장은 신뢰를 먹는다. 특히 “커닝”을 농담처럼 쓰는 회사가 매출 숫자까지 정정하게 되면, 시장은 그 회사를 다르게 보기 시작한다. 관심은 여전히 남을 수 있다. 하지만 관심과 신뢰는 다르다. 초기 스타트업에게 필요한 건 둘 다다. 관심이 없으면 시작할 수 없다. 신뢰가 없으면 지속할 수 없다. Cluely의 진짜 교훈은 “나쁘게라도 유명해져라”가 아니다. 더 정확히는 이거다. **AI 시대에는 제품이 빨리 복제되기 때문에 분배가 먼저 해자처럼 보인다. 하지만 신뢰 없이 만든 바이럴은 해자가 아니라 부채다.** 그 부채는 언젠가 온다. 고객이 환불을 요청할 때 올 수도 있고, 투자자가 숫자를 다시 볼 때 올 수도 있고, 언론이 예전 발언을 꺼낼 때 올 수도 있고, 경쟁사가 같은 기능을 더 조용하고 믿을 만하게 제공할 때 올 수도 있다. 그러니 초기 팀이 해야 할 일은 단순히 더 크게 외치는 게 아니다. 시장이 이미 품고 있는 긴장을 찾고, 그것을 기억나는 말로 만들고, 그 말이 제품의 실제 효용과 이어지게 해야 한다. 그리고 숫자와 약속만큼은 조용하고 정확하게 관리해야 한다. 바이럴은 빌릴 수 있다. 신뢰는 갚아야 한다. ## 참고한 글 - [A Student Used AI to Beat Amazon’s Brutal Technical Interview](https://gizmodo.com/a-student-used-ai-to-beat-amazons-brutal-technical-interview-he-got-an-offer-and-someone-tattled-to-his-university-2000571562?ref=zerodraftlab.com) - [Interview Coder founders drop out amid disciplinary action](https://www.columbiaspectator.com/news/2025/04/07/this-isnt-even-really-cheating-interview-coder-founders-drop-out-amid-disciplinary-action-over-ai-software/?ref=zerodraftlab.com) - [Columbia student suspended over interview cheating tool raises $5.3M](https://techcrunch.com/2025/04/21/columbia-student-suspended-over-interview-cheating-tool-raises-5-3m-to-cheat-on-everything/?ref=zerodraftlab.com) - [Cluely raises $15M from a16z](https://techcrunch.com/2025/06/20/cluely-a-startup-that-helps-cheat-on-everything-raises-15M-from-a16z/?ref=zerodraftlab.com) - [Why a16z VC believes Cluely is the new blueprint for AI startups](https://techcrunch.com/2025/06/26/why-a16z-vc-believes-that-cluely-the-cheat-on-everything-startup-is-the-new-blueprint-for-ai-startups/?ref=zerodraftlab.com) - [Cluely’s ARR doubled in a week to $7M, founder Roy Lee says](https://techcrunch.com/2025/07/03/cluelys-arr-doubled-in-a-week-to-7m-founder-roy-lee-says-but-rivals-are-coming/?ref=zerodraftlab.com) - [Cluely’s Roy Lee on the rage-bait strategy for startup marketing](https://techcrunch.com/2025/10/29/cluelys-roy-lee-on-the-ragebait-strategy-for-startup-marketing/?ref=zerodraftlab.com) - [Cluely CEO Roy Lee admits to publicly lying about revenue numbers](https://techcrunch.com/2026/03/05/cluely-ceo-roy-lee-admits-to-publicly-lying-about-revenue-numbers-last-year/?ref=zerodraftlab.com) - [Cluely 공식 사이트](https://cluely.com/?ref=zerodraftlab.com) ### 잘 팔리는 단어의 정체: 욕망이 아니라 리스크 제거다 URL: https://zerodraftlab.com/selling-words-reduce-risk/ Last updated: 2026-07-11T12:55:11.000Z 사람들이 “무조건 먹히는 카피 키워드”를 물으면 보통 답은 하나다. 무료. 틀린 말은 아니다. 무료는 강하다. 행동경제학에서도 0원은 단순히 “아주 싼 가격”이 아니라 아예 다른 심리 범주로 작동한다. 사람은 1,000원짜리를 100원에 살 때보다, 100원짜리를 0원에 받을 때 더 크게 반응한다. 돈이 줄어든 게 아니라 위험이 사라졌다고 느끼기 때문이다. 그런데 여기서 실무자의 함정이 시작된다. 무료라는 단어만 붙이면 다 팔릴 것 같지만, 실제로는 그렇지 않다. 어떤 테스트에서는 `Free Trial`보다 `Get Started Now` 같은 문구가 더 잘 먹힌다. 이유는 간단하다. 독자는 단어 하나를 클릭하는 게 아니라, 그 단어가 암시하는 거래 전체를 클릭한다. `무료 체험`이라는 말은 좋아 보인다. 하지만 독자 머릿속에서는 이런 질문이 같이 뜬다. 나중에 자동 결제되는 거 아냐? 카드 넣어야 하나? 해지 귀찮은 거 아닌가? 이거 받아봤자 쓸모없는 자료 아닌가? 즉, 무료는 강하지만 무료만으로는 부족하다. 좋은 카피는 욕망을 크게 외치는 말이 아니라, 행동 직전에 생기는 작은 불안을 지우는 말이다. 그래서 “무료” 다음으로 강한 단어들은 대체로 네 가지 리스크를 줄인다. ## 첫째, 돈 리스크 여기에 들어가는 말은 `무료`, `환불`, `보장`, `무위험`, `카드 등록 없음`, `No credit card required` 같은 것들이다. 독자가 가장 먼저 계산하는 건 “이걸 눌렀다가 돈이 나가나?“다. 특히 SaaS, 상담 신청, 강의, 템플릿 판매에서는 이 장벽이 생각보다 크다. 그래서 `무료 체험`보다 `카드 등록 없이 7일 체험`이 더 강할 수 있다. 무료라는 말만으로는 숨은 비용의 의심을 지우지 못하기 때문이다. ## 둘째, 시간 리스크 여기에 들어가는 말은 `바로`, `오늘`, `즉시`, `5분`, `지금`, `이번 주`다. 사람은 좋은 걸 원하지만, 그보다 더 자주 “귀찮은 걸 피하고” 싶어 한다. 결과가 좋아 보여도 오래 걸릴 것 같으면 미룬다. 그래서 `무료 분석`보다 `5분 무료 진단`이 낫다. `상담 신청`보다 `오늘 바로 확인`이 낫다. `자료 받기`보다 `지금 템플릿 받기`가 낫다. ## 셋째, 노력 리스크 여기에 들어가는 말은 `템플릿`, `체크리스트`, `예시`, `샘플`, `복붙`, `계산기`, `스크립트`다. 이 단어들이 강한 이유는 독자에게 “내가 머리 써서 처음부터 만들 필요는 없겠네”라는 신호를 주기 때문이다. `마케팅 가이드`는 넓다. `광고비 누수 체크리스트`는 바로 쓸 수 있다. `상담 전환 노하우`는 추상적이다. `상담 전환 스크립트 7개`는 손에 잡힌다. 요즘 정보는 부족하지 않다. 부족한 건 바로 쓰는 형태다. 그래서 카피에서 `가이드`보다 `템플릿`이 이기는 경우가 많다. ## 넷째, 후회 리스크 여기에 들어가는 말은 `검증된`, `실제 사례`, `데이터`, `전후 비교`, `사용 후기`, `이미 적용한`, `OO명이 받은` 같은 표현이다. 독자는 행동하기 전에 속으로 묻는다. 이거 나만 낚이는 거 아니야? 이 질문에 답하는 게 사회적 증거다. 단, “검증된 방법”처럼 말만 하면 약하다. `3개 병원에서 적용한 상담 전환 체크리스트`처럼 구체화될 때 힘이 생긴다. 카피는 대체로 형용사보다 숫자와 명사가 세다. ## 한국어 카피에 적용하면 바로 보인다 약한 문구는 이렇다. `무료 상담 신청` `무료 자료 받기` `마케팅 가이드 다운로드` `우리 병원 매출을 올리는 방법` 너무 익숙하고, 너무 넓고, 독자가 뭘 얻게 되는지 흐리다. 조금 더 강한 문구는 이렇다. `우리 병원 광고비 누수 5분 진단` `상담 전환 스크립트 템플릿 받기` `이번 달 신환이 새는 지점 무료 분석` `카드 등록 없이 바로 확인하는 예약 전환 체크리스트` 같은 무료라도 다르게 느껴진다. 이유는 무료에 붙은 말들이 독자의 리스크를 더 구체적으로 지워주기 때문이다. 결국 전환되는 카피의 질문은 “어떤 단어가 세냐?“가 아니다. 더 정확한 질문은 이거다. 이 사람이 지금 클릭하지 않는 이유는 무엇인가? 돈이 아까운가. 시간이 오래 걸릴까 봐 걱정인가. 내가 직접 해야 할 일이 많아 보이나. 괜히 신청했다가 후회할까 봐 망설이나. 그 이유를 찾으면 키워드는 자연스럽게 나온다. 돈이 문제면 `무료`, `환불`, `카드 등록 없음`. 시간이 문제면 `5분`, `오늘`, `즉시`. 노력이 문제면 `템플릿`, `체크리스트`, `복붙`. 후회가 문제면 `사례`, `데이터`, `전후 비교`. 그러니까 카피라이터가 모아야 할 건 파워워드 리스트가 아니다. 독자가 행동 직전에 느끼는 불안의 목록이다. 무료는 여전히 강하다. 하지만 무료는 시작일 뿐이다. 진짜 잘 팔리는 말은 독자에게 이렇게 느끼게 만든다. 돈 잃을 일 없고, 오래 걸리지 않고, 내가 직접 헤맬 필요 없고, 이미 누군가 써봤다. 그때 사람은 클릭한다. ## 참고한 글 - [Zero as a Special Price: The True Value of Free Products](https://web.mit.edu/ariely/www/MIT/Papers/zero.pdf?ref=zerodraftlab.com) - [When “Free” Converts and When It Doesn’t](https://cxl.com/blog/when-free-converts-and-when-it-doesnt/?ref=zerodraftlab.com) - [Why Subtle Changes in Button Copy Can Significantly Influence Clicks](https://marketingexperiments.com/copywriting/button-copy-changes?ref=zerodraftlab.com) - [Use this value proposition formula to get more yeses](https://copyhackers.com/2022/07/value-proposition-formula/?ref=zerodraftlab.com) ### 일을 못하는 사람은 지도가 틀렸다 URL: https://zerodraftlab.com/naive-reality-model/ Last updated: 2026-07-11T12:55:15.000Z 누군가를 두고 “나이브하다”고 말할 때가 있다. 이 말은 생각보다 잔인하다. 겉으로는 부드러운 평가처럼 들리지만, 실제로는 일을 잘하느냐 못하느냐의 핵심을 찌를 때가 많다. 나이브(naive, 현실의 주요 변수를 아직 충분히 반영하지 못한 상태)하다는 건 착하다는 뜻이 아니다. 순수하다는 뜻도 아니다. 현실의 비용, 욕망, 권력, 시간, 리스크(risk, 손실 가능성), 무관심을 아직 모델(model, 세계를 해석하는 내적 지도)에 넣지 못했다는 뜻이다. 그 사람은 똑똑할 수 있다. 성실할 수 있다. 많이 배웠을 수도 있다. 실행력도 있을 수 있다. 그런데 지도가 틀렸다. 일을 못하는 사람은 꼭 게으른 사람이 아니다. 재능이 없거나, 의지가 약하거나, 손이 느린 사람도 아닐 수 있다. 다만 틀린 지도 위에서 열심히 걷고 있을 수 있다. 그는 오래 걷는다. 빨리 걷는다. 남들보다 더 많이 걷기도 한다. 그런데 계속 다른 곳에 도착한다. 문제는 다리가 아니라 지도다. 일을 잘한다는 말은 결국 결과 앞에서 검증된다. 실적, 성과, 매출, 영향, 반복되는 선택, 오래 남는 구조. 좋은 의도나 성실한 태도만으로는 충분하지 않다. 열심히 했다는 건 투입의 기록이고, 일을 잘했다는 건 현실이 반응했다는 뜻이다. 그렇다면 현실모델은 성과의 숨은 계수다. 성과는 행동에서 나오는 것처럼 보인다. 많이 시도했는가. 빨리 움직였는가. 끝까지 했는가. 포기하지 않았는가. 이 질문들은 중요하다. 하지만 행동은 그냥 나오지 않는다. 무엇을 기회로 보고, 무엇을 위험으로 보고, 누구를 고객으로 보고, 어떤 신호를 진짜 피드백(feedback, 현실의 반응)으로 볼지에 대한 현실모델이 행동의 방향을 정한다. 거칠게 말하면 이렇다. 성과 = 실행량 x 현실모델의 정확도 x 운 대부분은 실행량만 본다. 누가 더 오래 일했는지, 누가 더 많이 만들었는지, 누가 더 빨리 움직였는지 본다. 하지만 현실모델의 정확도가 0에 가까우면 실행량은 오히려 위험해진다. 틀린 방향으로 빠르게 움직이는 사람은 천천히 움직이는 사람보다 더 빨리 망가진다. 나이브함은 정보 부족이 아니다. 모델 부족이다. 나이브한 사람도 정보를 많이 갖고 있을 수 있다. 책을 많이 읽었을 수 있다. 트렌드를 잘 알 수 있다. 최신 도구를 쓸 수 있다. 어려운 단어도 많이 안다. 하지만 현실의 주요 변수가 빠져 있다. 사람들이 좋은 말을 해도 돈을 내지는 않는다는 것. 조직은 진실보다 체면을 먼저 지킬 때가 많다는 것. 고객은 합리적으로 비교하지 않고, 귀찮음과 불안과 습관 속에서 선택한다는 것. 좋은 제품이 저절로 팔리지 않는다는 것. 시장은 내가 얼마나 진심인지 모른다는 것. 세상은 설명을 잘한 사람보다 분배를 장악한 사람에게 더 크게 반응한다는 것. 나이브한 사람은 세상이 어떻게 되어야 하는지는 잘 말한다. 하지만 세상이 왜 아직 그렇게 되어 있지 않은지는 잘 설명하지 못한다. 여기서 현실이 들어온다. 현실은 친절한 선생이 아니다. “네 모델의 세 번째 가정이 틀렸어”라고 말해주지 않는다. 처음에는 조용히 어긋난다. 고객이 답장을 늦게 한다. 숫자가 조금씩 식는다. 팀원이 말을 아낀다. 시장이 지나간다. 사람들이 칭찬은 하지만 구매하지 않는다. 그때 알아들으면 피드백이다. 못 알아들으면 충격이 된다. 나이브함은 언젠가 깨진다. 사람을 만나고, 조직을 움직이고, 돈을 받고, 제품을 팔고, 약속을 지키고, 경쟁자를 만나고, 계약서를 읽고, 고객의 무관심을 겪는 순간 깨질 확률이 올라간다. 현실 접촉면이 넓어질수록 나이브함은 오래 버티기 어렵다. 그래서 어떤 사람은 좋은 환경 안에서는 오래 나이브하게 남는다. 시험, 자격, 내부 보고, 안전한 조직, 말이 통하는 사람들 사이에서는 모델이 크게 깨지지 않는다. 하지만 시장, 고객, 돈, 권력, 채용, 영업, 운영처럼 현실의 압력이 센 곳으로 나오면 다르다. 거기서는 모델이 맞아야 한다. 문제는 깨지는 것 자체가 아니다. 깨지는 건 필요하다. 얻어맞는 것도 필요하다. 현실이 내 모델을 업데이트하라고 요구하는 방식이기 때문이다. 문제는 그 순간에 현실모델이 깨지는 대신 자존심을 보호하기 위해 현실을 왜곡하는 것이다. “시장이 아직 준비가 안 됐어.” “사람들이 수준이 낮아서 그래.” “나는 너무 앞서간 거야.” “고객이 자기 문제를 몰라.” “한 번만 더 노출되면 될 거야.” “돈 버는 건 원래 천박한 일이야.” “정치질하는 사람들이 이긴 거야.” 이런 말은 전부 틀렸다는 뜻이 아니다. 때로는 맞다. 시장이 정말 준비되지 않았을 수 있다. 고객이 자기 문제를 모를 수도 있다. 정치가 결과를 왜곡할 수도 있다. 하지만 이 문장들이 반복해서 현실을 막아주는 방패가 되면 위험하다. 망상가는 안 맞는 사람이 아니다. 맞고도 “이건 예외”라고 부르는 사람이다. 비전가와 망상가의 차이도 여기에 있다. 비전가는 현실을 부정하는 사람이 아니다. 남들이 보지 못한 현실의 층을 본 사람이다. 그는 지금의 숫자만 보지 않는다. 사람들의 잠재 욕망, 기술의 방향, 비용 구조의 변화, 제도의 균열, 아직 언어가 붙지 않은 불편을 본다. 그래서 처음에는 비현실적으로 보일 수 있다. 하지만 비전가는 피드백을 먹는다. 틀리면 고친다. 반례가 나오면 모델을 바꾼다. 고객이 다르게 말하면 단어를 바꾼다. 돈이 다른 곳에서 나오면 사업의 중심을 옮긴다. 망상가는 반대로 한다. 현실을 자기 믿음의 하청업체로 만든다. 나이브함이 깨진 뒤에도 두 갈래가 있다. 하나는 현실주의이고, 하나는 냉소주의다. 냉소는 성숙이 아니다. 냉소는 나이브함이 다친 뒤 입는 갑옷이다. 예전에는 “사람은 다 선하다”고 믿었다가, 몇 번 깨지고 나서는 “사람은 다 쓰레기다”라고 말하는 식이다. 이건 업데이트가 아니다. 반대로 뒤집힌 단순화다. 현실주의자는 선의를 버린 사람이 아니다. 선의만으로 시스템이 움직이지 않는다는 것을 배운 사람이다. 그는 사람의 좋은 면도 보고, 욕망도 본다. 가능성도 보고, 비용도 본다. 비전도 갖고, 분배 구조도 본다. 차가운 사람이 된 것이 아니다. 더 많은 변수를 모델에 넣은 것이다. 돈은 여기서 나온다. 돈 얘기를 하면 사람들은 쉽게 천박하다고 느낀다. 그런데 세상에서 돈만큼 현실적인 것도 드물다. 돈은 기분이 아니다. 응원도 아니다. 좋은 말도 아니다. 돈은 누군가의 욕망, 고통, 필요, 신뢰, 대안비용이 실제 행동으로 바뀐 흔적이다. 물론 단기적으로 돈은 거짓말을 할 수 있다. 운, 사기, 상속, 버블, 규제 차익, 착취도 돈을 만든다. 그래서 돈을 절대적인 도덕 기준으로 보면 안 된다. 하지만 장기적이고 반복적이고 자발적인 지불은 다르다. 누군가가 계속 돈을 낸다는 건, 그의 현실 안에서 그것이 중요하다는 뜻이다. 계속 재구매한다는 건, 대안보다 낫다는 뜻이다. 비싸게 산다는 건, 그 문제가 말보다 더 아프다는 뜻이다. 장기적으로 돈을 많이 버는 사람은 단순히 욕심이 많은 사람이 아니다. 사람들이 무엇에 움직이고, 무엇에 지갑을 열고, 무엇을 두려워하고, 무엇을 반복해서 선택하는지에 대한 현실모델이 꽤 정확한 사람일 가능성이 높다. 돈은 말보다 무겁다. AI 시대에는 이 차이가 더 커진다. AI는 글도 써주고, 코드도 짜주고, 전략도 그럴듯하게 만들어준다. 하지만 AI는 현실감각을 대신 주입해주지 않는다. 오히려 틀린 현실모델을 더 빠르고 더 매끄럽게 포장해줄 수 있다. 이제 망상은 게으른 사람의 특권이 아니다. 성실한 사람도, 생산적인 사람도, 도구를 잘 쓰는 사람도 아주 빠르게 망상할 수 있다. 그래서 앞으로 더 중요한 능력은 많이 만드는 능력만이 아니다. 내가 믿고 싶은 세계와 실제 세계가 부딪힐 때, 어느 쪽을 먼저 고칠 것인가. 현실을 바꾸는 사람은 현실을 무시하는 사람이 아니다. 현실이 어디까지 단단하고, 어디부터 아직 말랑한지 구분하는 사람이다. 단단한 곳에서는 빨리 진다. 말랑한 곳에서는 끝까지 민다. 일을 잘한다는 건 결국 이런 감각이다. 내 생각을 세게 믿는 능력이 아니라, 현실이 더 세게 말할 때 내 생각을 고치는 능력. 깨진다는 건 실패가 아니다. 현실이 내 지도를 고치라고 요구하는 순간이다. ### 도구를 고르지 말고, 에이전트 작업장을 설계하라 URL: https://zerodraftlab.com/agent-workbench-comparison/ Last updated: 2026-07-11T12:55:18.000Z 요즘 나는 Codex를 주로 쓴다. 하지만 이 글은 Codex 찬양글이 아니다. Cursor, Antigravity, Hermes, OpenClaw까지 늘어놓고 “뭐가 제일 좋냐”를 고르는 비교글도 아니다. 내가 하고 싶은 말은 조금 다르다. **이제 개발자가 고르는 것은 AI 에디터가 아니라, 에이전트가 일할 작업장이다.** 예전에는 코딩 도구를 고른다는 말이 비교적 단순했다. 에디터가 빠른가. 자동완성이 좋은가. 검색이 편한가. 확장이 많은가. 손에 잘 붙는가. 그런데 agent가 들어오면 질문이 바뀐다. agent는 단순히 코드를 제안하지 않는다. repo를 읽고, shell을 실행하고, 테스트를 돌리고, 브라우저를 열고, PR을 보고, 문서를 만들고, 나중에 다시 이어서 일한다. 경우에 따라 Slack, Gmail, Google Drive, GitHub, Linear 같은 외부 시스템까지 건드린다. 이 순간부터 도구 선택은 UI 취향 문제가 아니다. 어느 agent에게 어떤 repo를 보여줄 것인가. 어떤 secret을 줄 것인가. 어떤 채널을 열 것인가. 어디까지 자동 실행을 허용할 것인가. 실패하면 어떻게 되돌릴 것인가. 사람이 어느 지점에서 승인할 것인가. 이게 진짜 질문이 된다. ## Cursor 글이 말해준 것 최근 [Cursor의 cloud agent 회고](https://cursor.com/blog/cloud-agent-lessons?ref=zerodraftlab.com)를 읽고 이 생각이 더 선명해졌다. Cursor는 cloud agent를 “local agent를 서버에 올린 것”으로 보면 안 된다고 말한다. local agent는 내 노트북의 개발 환경을 공짜로 물려받는다. repo, dependency, shell, network, credential, 브라우저 상태가 이미 있다. cloud agent는 그렇지 않다. VM을 준비해야 한다. dependency를 설치해야 한다. secret을 안전하게 다뤄야 한다. network access를 제한해야 한다. 작업을 checkpoint하고, hibernate했다가 resume해야 한다. inference provider가 흔들리거나 pod가 죽어도 agent run이 이어져야 한다. 대화 상태와 머신 상태도 분리해야 한다. Cursor는 결국 Temporal 같은 durable execution 계층까지 갔다. 이건 그냥 Cursor의 내부 사정이 아니다. AI 코딩 도구 시장 전체의 방향을 보여준다. 좋은 agent 제품은 모델만 좋은 제품이 아니다. 좋은 agent 제품은 agent가 일할 수 있는 현실을 잘 제공하는 제품이다. 개발 환경, 권한, 상태, 메모리, 검증, 재시도, 리뷰, 기록. 이 모든 것이 합쳐져야 agent는 일을 한다. 그래서 나는 요즘 AI 코딩 도구를 볼 때 “응답이 똑똑한가”보다 먼저 본다. **이 제품은 agent에게 어떤 작업장을 만들어주는가.** ## Codex: 내가 지금 메인으로 두는 작업장 [Codex app](https://openai.com/index/introducing-the-codex-app/?ref=zerodraftlab.com)은 내 기준에서 가장 “작업장”에 가깝다. 하나의 파일 옆에서 autocomplete를 해주는 도구라기보다, 여러 agent에게 일을 맡기고, diff를 보고, terminal output을 확인하고, 브라우저로 검증하고, 다시 지시하는 공간이다. 내 작업은 에디터 안에서 한 함수 고치는 것으로 끝나지 않는 경우가 많다. repo를 읽고, 기존 규칙을 확인하고, 테스트를 돌리고, 화면을 보고, 결과를 문서나 draft로 남긴다. 때로는 GitHub PR을 리뷰하고, 때로는 Google Drive 문서를 읽고, 때로는 Slack이나 Gmail 맥락까지 이어진다. 이건 “코드 작성”보다 “작업 운영”에 가깝다. 그래서 나는 Codex를 메인으로 둔다. 지금 내가 필요한 건 가장 매끈한 코딩 손맛보다, 일을 맡기고 검증할 수 있는 agent workbench이기 때문이다. 물론 Codex가 모든 면에서 최고라는 뜻은 아니다. 손으로 코드 한가운데 들어가 미세하게 고치는 경험은 Cursor가 더 자연스러운 순간이 많다. 하지만 하루의 작업 전체를 맡기는 책상으로 보면 Codex가 편하다. ## Cursor: 가장 좋은 손 옆의 AI Cursor는 여전히 강하다. 특히 손으로 코딩하는 순간에는 Cursor가 좋다. 파일을 열고, 커서를 두고, 지금 이 코드의 의도를 유지하면서 빠르게 바꾸는 경험이 자연스럽다. “내가 쓰는 중”이라는 감각을 잘 살린다. Cursor의 진짜 무서운 점은 그 위에 cloud agent 운영 경험이 쌓이고 있다는 것이다. Cursor는 이미 VM, checkpoint, secret redaction, network policy, durable workflow, conversation streaming 같은 문제를 직접 겪고 있다. 내부 monorepo에서 cloud agent가 만든 PR 비중이 커지고 있다는 것도 중요하다. 에디터 회사처럼 보이지만, 실제 moat는 점점 agent infrastructure 쪽으로 이동하고 있다. 그래서 Cursor는 내게 “메인 작업장”이라기보다 “가장 좋은 손 옆의 AI”다. 직접 코딩할 때는 강하다. 하지만 repo를 넘나드는 운영, 문서화, 브라우저 검증, 외부 앱 연결까지 포함해 하루의 작업 흐름을 맡기려면 나는 아직 Codex 쪽이 편하다. ## Antigravity: Google이 만들려는 agent 플랫폼 Google의 Antigravity는 다른 층에 있다. [Google I/O 2026 발표](https://blog.google/innovation-and-ai/technology/ai/google-io-2026-all-our-announcements/?ref=zerodraftlab.com)에서 Antigravity 2.0은 desktop app, CLI, SDK, Managed Agents까지 확장됐다. 이건 Cursor류 에디터 경쟁자라기보다, Google식 agent platform에 가깝다. Google이 가진 표면은 너무 넓다. Gemini API, AI Studio, Android, Chrome, Firebase, Google Cloud, Workspace, Search가 있다. 만약 agent가 이 표면들을 자연스럽게 오갈 수 있다면 Antigravity는 단순 개발 앱이 아니라 Google 생태계의 agent 작업장이 될 수 있다. 가능성은 크다. 하지만 위험도 같이 크다. Google 계정, Cloud project, Workspace, local repo, managed agent가 한 흐름으로 묶이면 편하지만, 권한 경계와 lock-in도 커진다. 그래서 나는 Antigravity를 메인 교체 후보로 보지는 않는다. 적어도 지금은 그렇다. 대신 Google/Gemini/Android/Firebase 쪽 실험을 할 때, 격리된 repo와 review gate를 걸고 써볼 플랫폼 후보로 본다. ## Hermes와 OpenClaw: 코딩 도구 밖으로 나가는 agent [Hermes Agent](https://github.com/NousResearch/hermes-agent?ref=zerodraftlab.com)와 [OpenClaw](https://github.com/openclaw/openclaw?ref=zerodraftlab.com)는 더 조심스럽게 봐야 한다. 이 둘은 단순한 coding assistant가 아니다. Hermes는 장기 기억과 skill 축적을 강조한다. 과거 대화를 검색하고, 사용자의 패턴을 배우고, 반복되는 일을 skill로 만든다. messaging gateway도 붙는다. 말하자면 기억하는 개인 작업자에 가깝다. OpenClaw는 local-first gateway에 가깝다. WhatsApp, Telegram, Slack, Discord, iMessage, Google Chat, Matrix, macOS, iOS, Android 같은 표면을 열고, sessions, cron, browser, canvas, tool 실행을 묶는다. 어디서든 부를 수 있는 always-on assistant에 가깝다. 매력적이다. 동시에 위험하다. 기억, 메시징, cron, shell, file access가 붙으면 agent는 내 생활의 입구가 된다. 이때 가장 중요한 건 모델 성능이 아니다. 권한 경계다. 어떤 채널에서 온 요청이 어떤 workspace를 건드릴 수 있는가. 회사 계정과 개인 계정은 분리되는가. 개인 사업 데이터와 회사 데이터가 섞이지 않는가. 기억해도 되는 것과 기억하면 안 되는 것은 분리되는가. cron으로 나중에 실행되는 작업은 누가 승인했는가. 이 질문에 답하지 못하면 Hermes와 OpenClaw는 너무 강한 장난감이 된다. 그래서 나는 이 둘을 “메인 코딩 툴” 후보로 보지 않는다. 별도 격리 환경에서 키워볼 개인 agent 후보로 본다. 회사 맥락과 섞으면 안 된다. ## 비교표보다 중요한 것 그래도 굳이 한 줄로 정리하면 이렇게 된다. | 도구 | 정체성 | 내 배치 | | ----------- | --------------------------------- | -------------- | | Codex | agent workbench | 메인 개발 작업장 | | Cursor | AI-native IDE와 cloud coding agent | 손으로 코딩할 때 보조석 | | Antigravity | Google식 agent platform | Google 생태계 실험장 | | Hermes | 기억하고 학습하는 personal agent | 장기 메모리 실험 | | OpenClaw | local-first always-on gateway | 개인 자동화 실험 | 하지만 표보다 중요한 건 배치다. Cursor는 편집의 밀도를 높인다. Codex는 작업을 맡기고 검증하는 세션을 만든다. Antigravity는 Google 생태계 위의 agent platform을 노린다. Hermes는 기억과 skill 축적을 노린다. OpenClaw는 어디서든 부를 수 있는 gateway를 노린다. 그러니 “뭐가 제일 좋냐”는 질문은 부족하다. 더 좋은 질문은 이것이다. **어떤 일을, 어느 권한 경계 안에서, 얼마나 오래 맡길 것인가.** ## 내 결론 지금 내 기본값은 이렇다. 메인은 Codex다. repo 수정, 리뷰, 디버깅, 브라우저 검증, 문서화, draft 작성까지 한 작업장 안에서 처리할 수 있기 때문이다. Cursor는 손 가까이에 둔다. 직접 코딩하는 순간, 파일 안에서 빠르게 생각을 움직이는 순간에는 Cursor가 좋다. Antigravity는 Google stack을 건드릴 때 실험한다. 특히 Gemini API, Android, Firebase, Google AI Studio와 연결되는 흐름은 따로 볼 만하다. Hermes와 OpenClaw는 격리된 개인 실험장에 둔다. 둘 다 재미있지만 항상 켜져 있는 personal agent는 잘못 세팅하면 너무 많은 것을 본다. 기억, 메시징, cron, shell은 강력하지만, 회사 맥락과 개인 맥락이 섞이면 바로 위험해진다. 그래서 결론은 단순하다. **도구를 고르지 말고, 작업장을 설계하라.** 에디터 하나를 고르는 게 아니다. agent에게 어떤 현실을 제공할지 정하는 일이다. 어떤 repo를 보여줄지. 어떤 secret을 줄지. 어떤 브라우저와 계정을 열어줄지. 어느 순간 사람이 승인할지. 실패하면 어떻게 되돌릴지. 이걸 정하지 않고 “AI 코딩 도구 뭐가 좋아요?“라고 묻는 건, 사무실 보안도 문서함도 출입증도 없이 직원을 뽑는 것과 비슷하다. 앞으로 좋은 agent 제품은 더 똑똑한 챗봇처럼 보이지 않을 것이다. 좋은 agent 제품은 좋은 작업장처럼 보일 것이다. 깨끗한 개발 환경, 명확한 권한, 남는 기록, 실패를 견디는 실행 계층, 사람이 개입할 리뷰 지점. 이런 것들이 제품의 본체가 된다. 나는 당분간 Codex를 그 중심에 두고, Cursor를 손 가까이에 두고, Antigravity/Hermes/OpenClaw는 격리된 실험장에 둘 생각이다. 아마 이 배치는 계속 바뀔 것이다. 하지만 기준은 오래갈 것 같다. **agent에게 일을 맡기기 전에, agent가 일할 방부터 설계해야 한다.** ### AI 도입은 교육이 아니라 운영체계다 URL: https://zerodraftlab.com/ai-adoption-operating-layer/ Last updated: 2026-07-11T12:55:21.000Z AI 도입은 교육 프로그램으로 끝나지 않는다. 사람들이 실제 업무에서 쓰게 만드는 운영 레일, 점수판, 권한, 반복 의식이 필요하다. Lenny’s Newsletter의 How I AI에 올라온 John Kim 인터뷰를 읽었다. 제목은 [Quests, token leaderboards, and a skills marketplace: The elite AI adoption playbook](https://www.lennysnewsletter.com/p/quests-token-leaderboards-and-a-skills?ref=zerodraftlab.com). Sendbird/Delight.ai가 회사 안에서 AI를 어떻게 퍼뜨렸는지 다룬 글이다. 처음 보면 흔한 AI adoption 사례처럼 보인다. 마케팅팀이 엔지니어 없이 Stripe 연동 swag store를 만들었다. 세일즈팀이 자기 CRM 도구를 만들었다. 채용팀이 워크플로우를 자동화했다. 토큰 사용량 대시보드도 있고, 리더보드도 있고, 사내 스킬 마켓도 있다. 그런데 이 사례의 진짜 핵심은 “AI를 많이 쓰게 했다”가 아니다. 핵심은 **AI 도입을 교육 프로그램이 아니라 사내 제품으로 만들었다**는 점이다. 많은 회사가 AI 도입을 이렇게 접근한다. - ChatGPT 계정을 지급한다. - 프롬프트 교육을 한다. - 부서별 use case를 모은다. - 사내 가이드 문서를 만든다. - 리더가 “AI를 적극적으로 활용합시다”라고 말한다. 이 방식은 나쁘지 않다. 하지만 대부분 금방 식는다. 왜냐하면 직원 입장에서 AI는 여전히 “각자 알아서 써야 하는 도구”이기 때문이다. 오늘 내가 뭘 해야 하는지, 어디까지 안전한지, 결과물을 어디에 남겨야 하는지, 누가 승인해야 하는지, 다음 반복 때 무엇이 더 쉬워지는지가 연결되지 않는다. Sendbird 사례가 다른 지점은 여기에 있다. 그들은 AI 사용을 개인의 열정이나 프롬프트 능력에 맡기지 않았다. 대신 `Automators`라는 내부 플랫폼으로 바꿨다. 누구나 필요한 AI 도구를 요청할 수 있고, 엔지니어나 AI agent가 그것을 만들 수 있고, 회사 전체가 어떤 업무 스킬이 생겼는지 볼 수 있다. 사용량도 본다. 퀘스트도 있다. 리더보드도 있다. 다시 말해 AI를 “소프트웨어 구매”가 아니라 “조직의 운영 레이어”로 다룬 것이다. ## 퀘스트가 중요한 이유 AI 도입에서 “써보세요”는 약한 문장이다. 사람은 도구를 쓰고 싶은 게 아니라 일을 끝내고 싶다. 그래서 퀘스트가 중요하다. 퀘스트는 사용법 설명이 아니라 행동 단위다. 예를 들어 “Claude Code를 써보세요”는 약하다. 반면 “이번 주 안에 반복되는 보고서 1개를 AI로 초안화하고, 사람이 최종 검토한 뒤 템플릿으로 저장하세요”는 강하다. “시장 조사를 해보세요”도 약하다. “이번 주 경쟁사 3곳을 같은 기준으로 비교하고, 다음 액션 1개를 정하세요”는 강하다. “월마감 자료를 확인하세요”도 약하다. “이번 달 월마감 전에 증빙 누락 예외를 0건으로 줄이세요”는 강하다. 퀘스트는 게임화라서 중요한 게 아니다. 퀘스트는 일을 쪼개서 조직이 반복할 수 있는 행동 단위로 바꾸기 때문에 중요하다. ## 스킬 마켓은 사내 SaaS의 다음 형태다 인터뷰에서 흥미로웠던 표현은 회사 안의 skills marketplace다. 이건 단순히 agent 모음집이 아니다. 사내 업무를 스킬로 등록한다는 것은, 어떤 업무에 대해 최소한 다음 질문에 답한다는 뜻이다. - 이 업무는 무엇을 입력으로 받는가? - 어떤 산출물을 만드는가? - 어느 시스템에 기록되는가? - 읽기 전용인가, 쓰기 작업인가? - Owner 승인이 필요한가? - 반복될수록 무엇이 더 자동화되는가? 이 질문에 답하지 못하면 AI 도구는 그냥 장난감이 된다. 반대로 이 질문에 답하면 작은 내부 SaaS가 된다. 여기서 중요한 변화가 있다. 과거에는 사내 SaaS를 만들려면 엔지니어의 roadmap에 올라가야 했다. 그래서 “재미있지만 우선순위는 낮은” 업무 도구들은 늘 밀렸다. 이제는 그 사이에 새로운 층이 생긴다. non-engineer가 AI로 초안을 만들고, 엔지니어는 안전한 템플릿과 배포 경로를 만든다. 완성된 업무 능력은 사내 스킬로 등록된다. SaaS가 죽는 게 아니라, 회사 안에서 더 작은 단위로 재조립되는 것이다. ## 토큰 리더보드는 평가 도구가 아니다 토큰 사용량을 보는 것도 오해하기 쉽다. “누가 AI를 많이 썼나”로 줄 세우면 바로 망한다. 그러면 사람들은 보여주기식 사용량을 늘리거나, 반대로 감시받는다고 느낀다. Sendbird 사례에서 더 중요한 관점은 사용량의 절대값보다 곡선이다. 조직 전체가 부드럽게 올라오고 있는지, 특정 소수에게만 몰려 있는지, 어느 팀이 아직 손도 못 대고 있는지를 보는 것이다. 좋은 adoption dashboard는 성과 평가표가 아니라 병목 지도다. 이 팀은 왜 못 쓰고 있는가? 권한이 없어서인가? 데이터가 흩어져서인가? 실패했을 때 되돌릴 방법이 없어서인가? 승인자가 불명확해서인가? 업무를 쪼갠 퀘스트가 없어서인가? 이 질문을 보게 해준다면 토큰 대시보드는 쓸모 있다. 그렇지 않으면 그냥 숫자놀이가 된다. ## 작게 시작하려면 무엇이 필요한가 이 글을 읽고 얻은 실무적 결론은 단순하다. 새 AI 챗봇을 하나 더 붙이는 것보다, 기존 반복 업무를 스킬과 퀘스트로 재분류하는 일이 먼저다. 대부분의 조직에는 이미 여러 도구가 있다. 문서 도구, 채팅, 스프레드시트, CRM, 회계 시스템, 프로젝트 관리 도구, 내부 admin이 있다. 문제는 도구가 없는 것이 아니라, 도구들이 업무 생애주기로 묶여 있지 않다는 점이다. 그래서 필요한 다음 층은 Automators류의 상위 운영 레이어다. 각 도구를 “앱”이 아니라 “업무 스킬”로 등록해야 한다. 예를 들면 이렇다. - 캠페인 문안 리스크 점검 - 경쟁사 가격·포지셔닝 조사 - 주간 고객 문의 패턴 요약 - 외부 공유 채널 감사 - 월마감 증빙 누락 확인 - 정본 문서 변경 요청 그리고 각 스킬에는 실행 등급이 있어야 한다. - `read_only`: 보기만 한다. - `draft`: 초안을 만든다. - `requires_owner_approval`: Owner 승인 후 실행한다. - `external_write`: 외부 시스템에 쓰기 때문에 강한 gate가 필요하다. 이 구조가 있으면 AI 도입은 갑자기 현실적인 문제가 된다. “AI를 쓰자”가 아니라 “이 업무는 어디까지 자동화할 수 있고, 어디서 사람이 승인해야 하는가”가 보이기 때문이다. ## 좋은 AI-native 조직의 정의 내 결론은 이렇다. AI-native 조직은 AI를 많이 쓰는 조직이 아니다. AI-native 조직은 **반복 업무가 발견될 때마다 그것을 스킬, 퀘스트, 템플릿, 승인 경로, 정본 기록으로 바꾸는 조직**이다. 여기서 프롬프트는 작은 일부다. 더 중요한 것은 업무의 생애주기다. 요청이 들어온다. 증거를 모은다. 초안을 만든다. 승인을 받는다. 정본에 반영한다. 다음 반복 때 더 쉽게 실행된다. 이 흐름을 만들지 못하면 AI는 개인 생산성 도구에 머문다. 이 흐름을 만들면 AI는 조직의 operating system이 된다. Sendbird의 Automators 사례가 좋은 이유는 바로 이것이다. 그들은 AI를 신기한 도구로 팔지 않았다. 사내 반복 업무가 소프트웨어로 졸업하는 길을 만들었다. 한국 회사들에 필요한 것도 거창한 AI transformation 구호가 아니다. 부서별 GPT 교육도 첫걸음일 뿐이다. 진짜 변화는 훨씬 작고 구체적인 곳에서 시작된다. 이번 주에 반복 업무 하나를 고른다. 그 업무를 퀘스트로 만든다. 입력과 산출물을 정한다. 위험 등급을 붙인다. 결과가 남을 정본 위치를 정한다. 다음 주에 다시 실행한다. 이것이 쌓이면 회사 안에 작은 스킬 마켓이 생긴다. 그리고 어느 순간 사람들은 “AI를 쓴다”고 말하지 않게 된다. 그냥 일이 그렇게 돌아간다. 그때부터가 진짜 AI 도입이다. ### AI-first라는 말은 너무 약하게 쓰이고 있다 URL: https://zerodraftlab.com/ai-first-company-is-operating-system/ Last updated: 2026-07-11T12:55:24.000Z AI-first라는 말이 너무 쉽게 쓰인다. 전 직원에게 ChatGPT 계정을 줬다. Copilot을 깔았다. 사내 프롬프트 교육을 했다. 회의록 요약 봇을 붙였다. 그러고 나면 회사는 스스로를 AI-first에 가까워졌다고 말한다. 나는 그 표현이 거의 틀렸다고 본다. 그건 AI 도입이지 AI-first가 아니다. 더 정확히는, 예전 조직 위에 AI 도구를 얹은 것이다. 일이 흐르는 방식은 그대로 두고, 각자 쓰는 문구 생성기와 검색 보조 도구만 바꾼 상태다. HubSpot이 쓴 [How we Operate as an AI-first Company](https://blog.hubspot.com/marketing/how-we-operate-as-an-ai-first-company?ref=zerodraftlab.com)는 그 차이를 꽤 정확하게 짚는다. AI-first를 도구 보급의 문제가 아니라 조직이 작동하는 방식의 문제로 다룬다. AI가 개인의 보조 도구에 머무는가, 아니면 회사의 판단과 권한과 맥락을 다루는 실행 레이어가 되는가. 이 차이를 모르면 AI 전환은 대부분 직원 교육에서 멈춘다. ## 사용률은 출발선이지 성과가 아니다 HubSpot은 2025년까지 전사 AI 사용률 목표를 세우고, 팀별·도구별·사용례별 데이터를 공개했다고 한다. 결과적으로 직원의 94%가 매주 AI를 쓰고, 직원들이 만든 AI agent가 3,900개를 넘었다. 숫자는 인상적이다. 하지만 그 숫자만으로는 아직 회사가 바뀌었다고 말할 수 없다. 초기 단계에서 사용률을 보는 이유는 AI가 대단해서가 아니라, 안 쓰는 도구는 조직을 바꿀 수 없기 때문이다. 사람들이 실제 업무에서 AI를 만져봐야 감이 생긴다. 어떤 일은 바로 빨라지고, 어떤 일은 위험하고, 어떤 일은 겉보기와 달리 자동화 가치가 없다는 것도 그때 드러난다. 그래서 사용률은 필요하다. 다만 여기서 멈추면 망한다. 사용률은 체온계 같은 것이다. 체온을 잰다고 병이 낫지 않는다. 프롬프트 횟수가 늘었다고 회사가 똑똑해지는 것도 아니다. 직원들이 매일 AI를 쓴다는 사실만으로는 고객 대응 속도, 채용 cycle time, 영업 전환율, 제품 개발 속도가 구조적으로 좋아지지 않는다. 많은 조직은 이 지점에서 착각한다. AI 사용률을 성과로 착각한다. 교육 수료율을 변화로 착각한다. 사내 활용 사례 발표회를 운영 혁신으로 착각한다. HubSpot 글이 괜찮은 이유는 사용률을 목적지로 두지 않는다는 점이다. 사용률은 Stage 1의 leading indicator일 뿐이고, 진짜 싸움은 그 다음 단계에서 시작된다. ## 개인 생산성은 조직 성과로 자동 변환되지 않는다 AI 도입의 가장 흔한 실패는 개인 생산성과 조직 생산성을 같은 것으로 보는 데서 나온다. 개인은 빨라질 수 있다. 글 초안을 빨리 쓴다. SQL을 빨리 만든다. 리서치 시간을 줄인다. 회의록을 정리한다. 코드 보조를 받는다. 그런데 회사의 일은 개인의 작업 속도만으로 결정되지 않는다. 대부분의 병목은 사람 하나의 손이 느려서 생기지 않는다. handoff가 많아서 생긴다. 권한이 불분명해서 생긴다. 데이터가 흩어져서 생긴다. 승인자가 늦게 봐서 생긴다. “이건 누구한테 물어봐야 하지?“라는 질문이 계속 반복돼서 생긴다. 이런 병목은 개인이 AI를 잘 써도 그대로 남는다. HubSpot이 Stage 2에서 팀 단위 transformation을 말하는 이유가 여기에 있다. 각 직원이 AI를 쓰는 것만으로는 business outcome이 생기지 않는다. 팀의 workflow 자체를 다시 봐야 한다. 그래서 HubSpot은 팀을 두 축으로 본다. - AI maturity: 이미 얼마나 잘 쓰고 있고, 결과가 있는가 - AI readiness: 그 팀의 일이 자동화되기 좋은가, 데이터와 시스템이 받쳐주는가 이 분류는 사소해 보이지만 중요하다. 모든 팀에 같은 교육과 같은 도구를 뿌리는 방식은 편하지만, 조직을 바꾸지는 못한다. 이미 빠른 팀은 더 밀어주면 된다. 자동화 기회가 뻔한데 안 움직이는 팀은 리더가 현장으로 들어가 병목을 찾아야 한다. 잠재력은 큰데 데이터와 시스템이 엉켜 있는 팀은 별도 pod와 change management가 필요하다. AI 전환은 복지 포인트처럼 도구를 나눠주는 일이 아니다. 업무의 병목 지도를 다시 그리는 일이다. ## 진짜 AI-first는 institutional context에서 갈린다 Stage 3부터 무게가 달라진다. HubSpot은 Stage 3를 institutional AI라고 부른다. 개인이 AI를 잘 쓰는 단계도 아니고, 팀이 일부 workflow를 개선하는 단계도 아니다. 회사 자체가 AI와 함께 작동하도록 바뀌는 단계다. 그 아래 놓인 것은 institutional context다. 회사의 맥락은 원래 사람 사이에 흩어져 있다. 어떤 고객은 왜 중요한지, 어떤 deal은 왜 막혔는지, 어떤 제품 결정은 왜 그렇게 내려졌는지, 어떤 코드는 건드리면 안 되는지, 어떤 일은 누가 승인해야 하는지. 이 맥락이 사람 머릿속, Slack 스레드, 오래된 문서, 회의 기억, 몇몇 senior의 감각에만 있으면 AI는 계속 보조 도구에 머문다. 반대로 이 맥락이 agent가 읽고, 물어보고, 초안을 만들고, 실행 전 검토를 올릴 수 있는 형태가 되면 이야기가 달라진다. 그때 AI는 문서 작성기가 아니라 조직 인터페이스가 된다. 신입은 회사가 어떻게 의사결정하는지 사람을 붙잡고 묻지 않아도 된다. 영업 매니저는 deal이 막힌 이유를 리포트 몇 개를 뒤져가며 맞추지 않아도 된다. 엔지니어는 코드베이스의 암묵지를 옆 사람에게만 의존하지 않아도 된다. 이건 챗봇을 잘 만든다는 이야기가 아니다. 회사의 기억과 권한과 실행 경로를 agent가 접근 가능한 substrate로 만드는 이야기다. 그래서 Stage 3부터는 governance가 중심이 된다. 누가 무엇을 볼 수 있는가. 어떤 결정은 사람이 승인해야 하는가. 어떤 action은 dry-run까지만 허용되는가. 실행 기록은 어디에 남는가. 잘못된 출력은 어떻게 감지하고 멈추는가. 이 질문을 피하면서 AI-first를 말하면 거의 다 가짜다. AI-first라는 말의 무게는 모델 성능이 아니라 권한 설계에서 드러난다. ## 한국 회사들이 놓칠 가능성이 높은 지점 한국 회사들은 이런 사례를 보면 아마 쉬운 쪽부터 따라 할 가능성이 높다. 전사 AI 교육. 활용 사례 공모전. 임원용 대시보드. 사내 챗봇. 프롬프트 템플릿. 생산성 향상 캠페인. 다 할 수 있다. 해도 된다. 하지만 그것만으로는 구조가 안 바뀐다. 하지만 성패를 가르는 질문은 따로 있다. 우리 회사의 반복 업무는 어디서 막히는가. 그 업무에 필요한 context는 어디에 있는가. 그 context는 최신인가. agent가 읽을 수 있는가. agent가 초안을 만들었을 때 누가 승인하는가. 승인 기록은 어디에 남는가. 실패한 실행은 다음번에 반영되는가. 이 질문에 답하지 못하면 AI는 계속 개인기다. 개인기는 반짝인다. 하지만 compound되지 않는다. 조직에 남지 않는다. 잘하는 직원이 떠나면 같이 사라진다. 반대로 context와 permission과 audit trail이 남으면, 한 번의 실험이 다음 실행의 바닥이 된다. agent가 실패해도 흔적이 남고, 사람이 고친 판단이 다음번에 재사용된다. 그때부터 AI 활용은 이벤트가 아니라 운영 자산이 된다. 이게 AI-first의 실제 갈림길이다. ## 작은 팀은 오히려 더 빨리 갈 수 있다 HubSpot은 큰 회사다. 그래서 대기업 사례로만 읽으면 놓치는 게 많다. 작은 팀이나 1인 회사는 더 빨리 움직일 수 있다. 부서 정치가 적고, legacy process가 얇고, 의사결정자가 가까이 있기 때문이다. 다만 작은 팀일수록 더 조심해야 할 것도 있다. 작은 팀은 사람 한 명의 머릿속에 너무 많은 맥락이 들어간다. 고객 문의, 결제, 배포, 글 발행, 영업, 채용, 회계, 제품 판단이 한 사람의 inbox와 메신저에 섞인다. 이 상태에서 AI를 붙이면 처음에는 빨라 보인다. 하지만 context가 정리돼 있지 않으면 곧 더 시끄러워진다. agent가 초안을 많이 만들수록 review burden이 늘고, 자동화가 많아질수록 어디서 무슨 일이 벌어지는지 놓치기 쉽다. 그래서 작은 팀의 시작점은 “AI로 무엇을 자동화할까”가 아니다. 작은 팀의 시작점은 “어떤 반복 업무를 운영 자산으로 바꿀까”여야 한다. 좋은 시작은 단순하다. 반복되는 업무 하나를 고른다. 그 업무에 필요한 자료와 판단 기준을 한곳에 모은다. agent는 실행이 아니라 초안과 dry-run을 맡는다. 사람은 review queue에서 승인한다. 승인·수정·거절의 이유를 기록한다. 그 기록을 다음 실행의 context로 되돌린다. 이 루프가 돌기 시작하면 작은 팀도 institutional AI의 작은 버전을 갖게 된다. 완전 자동화가 중요한 게 아니다. 누적되는 운영 기억이 중요하다. ## AI-enabled와 AI-first 사이 HubSpot 글의 가치는 수치에 있지 않다. 94% weekly AI usage도, 3,900개 agent도, 20번의 AI learning day도 흥미롭지만 본질은 아니다. 그 숫자는 방향을 설명하는 재료다. 당신의 회사에서 AI는 개인의 보조 도구인가, 아니면 조직의 운영체제를 바꾸는 힘인가. 개인의 보조 도구라면 AI-first라는 말은 과하다. 그냥 AI-enabled 정도면 된다. AI-first라고 부르려면 회사의 일이 바뀌어야 한다. 정보가 놓이는 방식이 바뀌어야 한다. 권한이 표현되는 방식이 바뀌어야 한다. 승인과 실행과 감사의 경로가 바뀌어야 한다. 사람이 아는 것을 agent가 접근 가능한 context로 바꾸고, agent가 한 일을 사람이 검토 가능한 기록으로 남겨야 한다. 이건 도구 도입이 아니다. 운영 모델의 재설계다. 그래서 AI-first라는 말은 지금보다 훨씬 무겁게 써야 한다. AI를 많이 쓰는 회사가 아니라, 회사의 맥락과 권한과 실행 기록이 AI와 함께 움직이도록 다시 설계된 회사. 그 정도는 되어야 AI-first라는 말을 붙일 수 있다. ### UI를 만드는 AI보다 UI를 운영하는 제품이 이긴다 URL: https://zerodraftlab.com/ai-apps-many-heads-plastic-ui/ Last updated: 2026-07-11T12:55:27.000Z AI가 화면을 즉석에서 만들 수 있게 되면, 화면은 더 이상 희소하지 않다. 희소해지는 것은 다른 쪽이다. 그 화면을 믿고 눌러도 되는가. 그 화면이 어떤 데이터에서 왔는가. 사용자가 바꾼 값은 어디에 기록되는가. 같은 화면을 나중에 다시 열어볼 수 있는가. 한 번 쓰고 버릴 화면인지, 제품 기능으로 승격해야 할 화면인지 누가 판단하는가. [Tom Tunguz의 Plastic User Interfaces](https://tomtunguz.com/plastic-user-interfaces?ref=zerodraftlab.com)는 이 전환을 짧게 짚는다. AI가 Salesforce 같은 복잡한 SaaS 앞에 자연어 인터페이스를 세우고, 동시에 상황에 맞는 richer UI를 즉석에서 만들 수 있다는 이야기다. 여행을 고를 때는 쇼핑 화면, 예산을 짤 때는 차트가 있는 스프레드시트, 마케팅 카피를 볼 때는 작은 리뷰 앱이 나오는 식이다. 여기까지는 이제 꽤 자연스럽다. 진짜 문제는 그 다음이다. AI가 UI를 만들 수 있다는 사실보다 중요한 것은, **그 UI가 업무 상태를 바꿔도 되는지 관리하는 능력**이다. ## 채팅은 입구일 뿐이다 AI 제품을 말할 때 가장 쉬운 상상은 모든 앱이 채팅창으로 수렴한다는 것이다. 사용자는 자연어로 말하고, AI는 뒤에서 API를 호출한다. CRM도, 회계도, 캘린더도, 문서도 대화로 처리한다. 이 상상은 절반만 맞다. 자연어는 훌륭한 입구다. 사용자가 아직 원하는 것을 정확히 구조화하지 못했을 때 특히 강하다. “지난달 매출 정리해줘”, “이 고객에게 보낼 답장 써줘”, “이번 분기 채용 계획 다시 짜줘” 같은 요청은 버튼보다 문장으로 시작하는 편이 자연스럽다. 하지만 모든 일은 문장으로 끝나지 않는다. 비교해야 할 때는 표가 필요하다. 흐름을 봐야 할 때는 다이어그램이 필요하다. 숫자를 조정해야 할 때는 스프레드시트가 필요하다. 디자인을 골라야 할 때는 화면이 필요하다. 결재나 배포처럼 되돌리기 어려운 작업에는 확인 화면과 감사 로그가 필요하다. 그러니까 질문은 “채팅이냐 앱이냐”가 아니다. 질문은 이것이다. **지금 이 업무 상태에서 사용자가 만나야 할 계면은 무엇인가?** 어떤 순간에는 대화가 맞고, 어떤 순간에는 표가 맞고, 어떤 순간에는 차트가 맞고, 어떤 순간에는 버튼 하나 달린 확인 화면이 맞다. 좋은 AI 제품은 모든 것을 채팅창에 밀어 넣지 않는다. 사용자가 처리해야 할 일에 맞는 작업대를 꺼내준다. ## Headless 다음은 multi-head다 Headless software라는 말은 보통 UI와 backend를 분리한다는 뜻으로 쓰인다. 예전에는 웹앱 화면이 곧 제품의 얼굴이었다. 사용자는 그 화면으로 들어가서, 그 화면이 허락한 방식으로만 일했다. AI가 바꾸는 것은 이 고정된 얼굴이다. 예를 들어 CRM을 보자. 예전에는 CRM의 기본 UI가 있었다. 리스트, 파이프라인, 고객 상세, 활동 로그, 리포트. 모든 사용자는 그 머리를 통해 시스템을 만났다. 이제 같은 CRM이 여러 머리를 가질 수 있다. 영업 담당자는 이동 중에 음성으로 딜 메모를 남긴다. 매니저는 주간 파이프라인을 리스크 차트로 본다. 대표는 중요한 계약만 아침 브리핑으로 받는다. 고객 성공 담당자는 갱신 위험 고객만 따로 뽑은 작업 화면을 본다. 에이전트는 내부 API와 정책 문서를 읽고 다음 액션을 제안한다. 전부 같은 시스템을 쓰고 있지만, 같은 UI를 쓰지는 않는다. 그래서 headless는 “머리가 없어졌다”가 아니다. 하나의 고정된 머리가 여러 개의 가변적인 머리로 갈라지는 일에 가깝다. 앱은 사라지는 게 아니라, 사용자의 역할과 상황에 맞춰 다른 계면으로 나타난다. 하지만 여러 머리를 만들 수 있다는 사실만으로는 제품이 되지 않는다. 그 많은 머리를 누가 관리하는가. ## UI는 그림이 아니라 상태 전이의 입구다 AI가 만든 화면이 단순한 미리보기라면 위험은 작다. 여행지 후보를 보여주고, 글 제목을 비교하고, 그래프를 그려주는 정도라면 틀려도 다시 만들면 된다. 업무용 소프트웨어에서는 다르다. CRM 화면에서 버튼을 누르면 딜 단계가 바뀐다. 회계 화면에서 값을 입력하면 예산이 바뀐다. 채용 화면에서 승인하면 후보자의 상태가 바뀐다. 배포 화면에서 확인을 누르면 실제 서버가 바뀐다. 법무 검토 화면에서 체크하면 계약 리스크 해석이 남는다. 이때 UI는 그림이 아니다. 상태 전이의 입구다. 그래서 동적 UI의 핵심 질문은 예쁘게 만들 수 있느냐가 아니다. 이 화면이 어떤 상태 전이를 허락하는가. 누가 볼 수 있는가. 누가 누를 수 있는가. 누르면 무엇이 바뀌는가. 바뀐 뒤 무엇이 기록되는가. 잘못 눌렀을 때 어디서 멈추는가. 이 질문에 답하지 못하면 plastic UI는 금방 지저분해진다. 처음에는 마법처럼 보인다. 매번 화면이 생기고, 표가 생기고, 대시보드가 생긴다. 그런데 몇 주 지나면 어떤 화면이 최신인지 모르고, 누가 승인했는지 모르고, 어느 값이 실제 시스템에 반영됐는지 모른다. 비슷한 리포트가 여러 개 떠다니고, 그중 무엇이 정본인지 알 수 없다. 인터페이스를 쉽게 만들 수 있을수록, 인터페이스를 운영하는 규칙은 더 중요해진다. ## 생성된 화면에는 세 가지 운명이 있다 AI가 만든 UI는 전부 같은 방식으로 다루면 안 된다. 첫째, 일회용 UI가 있다. 오늘 한 번 비교하고 버리면 되는 화면이다. 뉴스레터 제목 후보를 고르는 표, 여행지 후보 카드, 회의 전 빠르게 보는 요약 대시보드 같은 것들이다. 이런 UI는 빠르게 만들고 빠르게 버리는 편이 맞다. 둘째, 증거로 남겨야 하는 UI가 있다. 중요한 의사결정에 쓰인 화면이다. 분기 예산 조정, 채용 승인, 계약 리스크 검토, 가격 변경, 배포 승인 같은 것들이 여기에 속한다. 이 화면은 나중에 “그때 왜 그렇게 결정했나”를 설명할 수 있어야 한다. 데이터 원천, 판단 기준, 승인자, 변경 전후가 남아야 한다. 셋째, 제품 기능으로 승격될 UI가 있다. 처음에는 임시로 만들었지만 반복해서 쓰이는 화면이다. 매주 같은 리포트를 만들고, 매번 같은 고객 위험도를 보고, 계속 같은 검토표를 쓴다면 그건 더 이상 임시 UI가 아니다. 제품 안으로 들어와야 한다. 좋은 AI 앱은 이 세 가지를 구분한다. 나쁜 AI 앱은 전부 생성하고 전부 방치한다. 산출물은 많아지지만 시스템은 더 혼란스러워진다. 좋은 AI 앱은 생성된 인터페이스를 관찰한다. 버릴 것은 버리고, 증거로 남길 것은 남기고, 반복되는 것은 정식 기능으로 승격시킨다. 이게 plastic UI의 진짜 제품 문제다. ## Markdown 다음은 HTML이 아니라 작업대다 요즘 AI 도구를 쓰다 보면 Markdown의 한계가 자주 보인다. Markdown은 읽고 쓰기 쉽다. 모델도 잘 다룬다. 메모, 요약, 계획, 체크리스트에는 훌륭하다. 하지만 Markdown은 조작하기에는 약하다. 가격표를 비교할 수는 있지만, 슬라이더로 조건을 바꿔보긴 어렵다. 회계 계획을 적을 수는 있지만, 시나리오별 현금흐름을 즉석에서 조정하긴 어렵다. 제품 요구사항을 정리할 수는 있지만, 사용자가 보는 상태 전이를 직접 눌러보긴 어렵다. 그래서 HTML artifact나 작은 web app output이 중요해진다. 다만 “Markdown 다음은 HTML”이라고만 말하면 좁다. 정확히는 Markdown 다음은 작업대다. 글을 읽는 화면이 아니라, 일을 처리하는 임시 작업대. 마케팅 카피를 비교하는 작업대, 채용 후보자를 정리하는 작업대, 여행 일정을 짜는 작업대, 월별 비용을 조정하는 작업대, 고객 인터뷰를 태깅하는 작업대, PRD를 feature backlog로 바꾸는 작업대. 포맷이 중요한 게 아니다. 중요한 것은 사용자가 실제로 일을 처리할 수 있는 계면이 생긴다는 점이고, 그 계면이 업무 상태와 연결된다는 점이다. ## AI 제품의 moat는 interface governance다 자연어로 SaaS를 조작할 수 있다는 것만으로는 오래 버티기 어렵다. API 호출, MCP 서버, agent workflow는 점점 표준화될 것이다. 좋은 모델이 붙으면 많은 제품이 비슷한 자연어 조작 경험을 제공할 수 있다. 차이는 다른 곳에서 난다. 첫째, context database. AI가 매번 새로 묻지 않아도 되는 업무 맥락을 얼마나 잘 저장하고 있는가. 조직의 정책, 고객 히스토리, 과거 결정, 문서, 용어, 예외 규칙, 금지선이 살아 있는 형태로 쌓여 있어야 한다. 둘째, artifact library. 한 번 만들어진 화면, 리포트, 계산표, 브리핑, 체크리스트, 계약 검토 양식 중 무엇을 다시 쓸지 알아야 한다. 임시 산출물이 전부 사라지면 학습이 남지 않는다. 반대로 전부 보존하면 쓰레기가 된다. 남길 것과 버릴 것을 가르는 능력이 필요하다. 셋째, correctness harness. 동적 UI가 실제 업무를 바꾸려면 안전장치가 필요하다. 숫자가 맞는지, 권한이 맞는지, 위험한 액션인지, 원천 데이터가 무엇인지, 변경 전후가 어떻게 다른지 검증해야 한다. 특히 돈, 법률, 고객 데이터, 배포, 인사처럼 되돌리기 어려운 영역에서는 “AI가 그럴듯한 화면을 만들었다”로 충분하지 않다. 이 셋을 합치면 interface governance가 된다. AI 앱의 핵심은 interface generator가 아니다. interface governance다. ## 제품은 화면이 아니라 계면을 관리한다 Plastic UI 논의가 흥미로운 이유는 AI 시대 UI 논의를 “채팅 vs 앱” 같은 납작한 대립에서 꺼내기 때문이다. 채팅은 중요하다. 하지만 모든 것이 채팅이 되지는 않는다. 앱 화면도 중요하다. 하지만 하나의 고정된 화면이 모든 사용자의 기본 입구로 남지는 않는다. 앞으로의 앱은 여러 계면을 가진다. 사람에게는 대화와 화면으로, 에이전트에게는 API와 정책으로, 팀에게는 문서와 로그로, 의사결정자에게는 브리핑과 대시보드로 나타난다. 그래서 제품이 관리해야 할 것은 더 이상 “메인 UI” 하나가 아니다. 제품은 사용자와 시스템 사이에 생기는 여러 계면을 관리해야 한다. 만들고, 검증하고, 저장하고, 버리고, 승격시켜야 한다. 이 능력이 AI 시대 소프트웨어의 핵심 운영 능력이 된다. UI를 만드는 AI는 많아질 것이다. UI를 운영하는 제품은 훨씬 적을 것이다. ### HubSpot의 Agent-first GTM이 진짜 말하는 것 URL: https://zerodraftlab.com/hubspot-agent-first-gtm-review/ Last updated: 2026-07-11T12:55:31.000Z HubSpot의 [“How we Grow with Agent-first GTM”](https://blog.hubspot.com/marketing/how-we-grow-with-agent-first-gtm?ref=zerodraftlab.com)을 처음 보면 대기업의 AI 성공 사례처럼 보인다. 숫자가 세다. AI로 전체 타깃 시장에 34만 5천 개 계정을 추가했고, answer engine에서 온 qualified lead가 1,850% 늘었고, AI 개인화 outreach로 분기 1만 개 이상의 미팅을 잡고, guided selling이 쓰인 deal의 win rate가 13% 높아졌다고 말한다. 그런데 이 글을 숫자 자랑으로 읽으면 핵심을 놓친다. 중요한 건 HubSpot이 AI를 “마케팅 생산성 도구”로 쓰지 않았다는 점이다. 콘텐츠를 더 많이 만들었다는 이야기가 아니다. 광고 카피를 더 빨리 썼다는 이야기도 아니다. HubSpot이 한 일은 GTM 전체를 agent가 움직일 수 있는 운영 흐름으로 다시 짠 것이다. ## GTM은 더 이상 캠페인 묶음이 아니다 전통적인 GTM은 대개 부서 단위로 쪼개져 있었다. 마케팅은 lead를 만든다. SDR은 연락한다. AE는 deal을 진행한다. CS는 고객을 살린다. Support는 문제를 푼다. 각 부서는 자기 도구와 자기 dashboard와 자기 KPI를 가진다. 고객은 그 사이를 흐른다. 문제는 흐름이 끊긴다는 데 있다. 어떤 account가 왜 중요한지, 어떤 질문을 했는지, 어떤 risk가 있는지, 다음에 누가 무엇을 해야 하는지 맥락이 자주 사라진다. HubSpot의 agent-first GTM은 이 끊김을 줄이는 방향으로 보인다. Demand Agent는 ICP에 맞는 회사를 찾고 점수를 붙인다. Inbound Agent는 웹사이트 방문자의 질문과 구매 의도를 판단하고, 답하거나 미팅으로 넘긴다. AEO Agent는 ChatGPT나 Perplexity 같은 answer engine에서 HubSpot이 보이고 신뢰되게 만든다. Prospecting Agent는 intent signal을 보고 multi-touch sequence와 rep task를 만든다. Guided Sales Assistant는 deal risk, 비슷하게 이긴 deal, 다음 행동을 대화형으로 꺼내준다. Customer Agent는 반복 support inquiry를 해결한다. Customer Success Assistant는 CSM에게 오늘 집중해야 할 account와 이유를 알려준다. 이 목록에서 중요한 단어는 agent가 아니다. 중요한 것은 **상태 전이**다. account 후보가 생긴다. score가 붙는다. 관심 신호가 들어온다. qualification이 일어난다. 미팅이 잡힌다. deal risk가 보인다. 다음 행동이 생성된다. support inquiry가 해결된다. save risk가 먼저 드러난다. GTM은 캠페인 묶음이 아니라 고객 상태를 옮기는 운영체제가 된다. ## HubSpot 사례의 진짜 구조 HubSpot 글에서 가져와야 할 구조는 세 가지다. 첫째, signal을 account와 연결한다. 좋은 agent는 “뭔가 해줘”라는 요청을 기다리지 않는다. 외부 데이터, 내부 ICP, intent signal, 웹 방문, answer engine visibility, support inquiry, product usage를 보고 어떤 customer object가 움직여야 하는지 찾는다. 둘째, score와 reason을 붙인다. HubSpot의 Demand Agent는 단순히 회사 목록을 만드는 게 아니라 prospect value score를 붙인다. Guided Sales Assistant도 단순히 정보 화면을 보여주는 게 아니라 deal risk와 similar-won deal, next action을 묻고 답하게 만든다. 이건 agent가 판단을 대신한다는 뜻이 아니다. 사람이 판단할 수 있게 근거와 맥락을 압축한다는 뜻이다. 셋째, 사람에게 넘길 시점을 안다. HubSpot은 사람을 없앤 것이 아니다. 오히려 사람의 개입 지점을 더 선명하게 만들었다. 웹 방문자를 미팅으로 넘기고, rep에게 다음 행동을 만들고, CSM에게 오늘 봐야 할 account를 알려준다. agent가 일을 끝내는 곳도 있지만, 많은 경우 agent는 사람의 판단과 대화를 더 좋은 위치에서 시작하게 한다. 이 세 가지가 합쳐지면 GTM은 이렇게 바뀐다. | 예전 GTM | Agent-first GTM | | ------------- | ----------------------------- | | 캠페인 생성 | customer state 감지 | | lead 수집 | account scoring | | dashboard 조회 | 대화형 deal context | | 수동 follow-up | intent 기반 task 생성 | | support queue | agent resolution + escalation | | CSM 감 | attention priority | 이 변화는 마케팅팀만의 변화가 아니다. GTM 전체의 운영 모델 변화다. ## 작은 팀은 HubSpot을 복제하면 안 된다 여기서 가장 위험한 오해는 “우리도 Demand Agent, Inbound Agent, AEO Agent, Prospecting Agent를 다 만들자”는 결론이다. HubSpot은 20년치 데이터, 거대한 고객 기반, 큰 funnel, 이미 정리된 CRM 맥락을 가지고 있다. 작은 팀이 같은 이름의 agent를 나열하면 대부분 껍데기만 남는다. 작은 팀이 가져와야 할 것은 agent 이름이 아니라 질문이다. 1. 우리는 어떤 account나 reader나 customer를 더 빨리 발견해야 하는가? 2. 그 대상이 움직일 만한 signal은 어디에 남는가? 3. 사람이 보기 전에 agent가 붙일 수 있는 score나 reason은 무엇인가? 4. agent가 끝낼 일과 사람에게 넘길 일의 경계는 어디인가? 5. 이 과정에서 다음번 판단이 더 쉬워지도록 어떤 memory를 남길 것인가? 작은 팀에게 첫 agent-first GTM은 대개 거창한 multi-agent system이 아니다. 예를 들어 이런 정도면 충분하다. - 새로 들어온 문의를 읽고 ICP fit을 판단한다. - 글을 읽고 들어온 독자가 어떤 pain을 가진 사람인지 태그를 붙인다. - 특정 주제의 article이나 source가 새로 나오면 우리 제품/글/오퍼와 연결할 수 있는지 점검한다. - 답변형 검색에서 우리 이름이나 글이 보이는지 주기적으로 확인한다. - 고객 대화나 댓글에서 반복되는 objection을 모아 다음 글이나 sales page 수정 후보로 만든다. 이 정도만 해도 GTM은 달라진다. 핵심은 “AI로 더 많은 콘텐츠를 만든다”가 아니다. **AI가 시장 신호를 읽고, 고객 상태를 업데이트하고, 사람이 판단해야 할 일을 더 좋은 위치로 밀어주는 구조**다. ## AEO는 SEO의 다음 유행어가 아니다 HubSpot 글에서 특히 흥미로운 부분은 AEO Agent다. HubSpot은 answer engine에서 온 qualified lead가 크게 늘었고, 전통 검색 대비 더 높은 전환을 보였다고 말한다. 이것을 “AI 검색이 뜬다”로만 읽으면 약하다. 더 중요한 건 buyer의 위치가 바뀌었다는 점이다. 예전에는 buyer가 검색엔진에서 여러 링크를 누르고, 웹사이트를 읽고, form을 제출하면서 funnel 안으로 들어왔다. 이제 일부 buyer는 ChatGPT나 Perplexity 같은 answer engine에서 이미 비교와 학습을 끝낸 뒤 움직인다. 이 사람은 웹사이트에 늦게 온다. 하지만 더 많이 배운 상태로 온다. 그러면 GTM의 첫 접점도 바뀐다. 웹사이트 방문 전의 질문. 검색 결과 클릭 전의 답변. comparison article. community mention. third-party review. technical explanation. pricing과 integration에 대한 명확한 문장. 이런 것들이 GTM의 앞단이 된다. 그래서 AEO는 SEO의 다음 유행어라기보다, **웹사이트 바깥에서 벌어지는 구매 전 대화에 우리 context를 심는 작업**에 가깝다. 작은 회사일수록 이걸 더 일찍 봐야 한다. 대형 브랜드처럼 이미 많이 언급되지 않기 때문이다. answer engine은 빈칸을 싫어한다. 우리가 스스로 근거를 남기지 않으면, 다른 사람이 쓴 설명이나 더 큰 경쟁사의 문서가 그 자리를 차지한다. ## 사람의 일은 줄어드는 게 아니라 위치가 바뀐다 HubSpot 글에서 제일 좋은 문장은 agent가 사람을 대체한다는 식의 이야기가 아니라, 사람이 더 높은 impact로 일한다는 쪽이다. 마케터는 각 고객에게 더 관련 있는 메시지를 보낼 수 있다. 영업 담당자는 대화 전에 deal context를 들고 들어간다. CSM은 누가 왜 지금 attention을 필요로 하는지 안다. 이건 사람의 일이 사라지는 그림이 아니다. 사람이 무작정 뒤지고, 정리하고, 기억하고, follow-up을 놓치지 않으려 애쓰던 일을 agent가 일부 가져가고, 사람은 더 좋은 판단과 대화로 이동하는 그림이다. 그래서 agent-first GTM의 핵심 역량도 바뀐다. 좋은 카피를 쓰는 능력만으로 부족하다. CRM을 깔끔하게 쓰는 능력만으로도 부족하다. 이제 필요한 것은 고객 상태를 정의하고, signal을 고르고, agent가 실행할 수 있는 action layer를 만들고, 사람이 승인해야 할 gate를 정하고, 결과를 다시 memory로 남기는 능력이다. 마케팅 운영, 세일즈 운영, CS 운영이 점점 하나의 agent ops로 붙는다. ## 주중몽크에서 이 글을 보는 이유 주중몽크에서 이 글을 보는 이유는 HubSpot이 멋져서가 아니다. 대기업의 AI 성공담을 소개하려는 것도 아니다. 진짜 이유는 이 글이 앞으로 작은 팀과 1인 사업자가 어떤 방식으로 일하게 될지를 꽤 선명하게 보여주기 때문이다. 주중몽크에서 계속 보고 싶은 것은 “새 AI 도구가 나왔다”가 아니다. 그 도구가 일을 어떻게 바꾸는가. 조직 구조를 어떻게 바꾸는가. 사업 모델을 어떻게 바꾸는가. 개인이 어디까지 회사를 작게 들고 갈 수 있게 만드는가. 그런 관점에서 HubSpot의 Agent-first GTM은 꽤 좋은 표본이다. 이 글은 “AI를 마케팅에 활용하는 법”이 아니라 “GTM이라는 회사 기능이 agent를 중심으로 어떻게 다시 조립되는가”를 보여준다. HubSpot의 Agent-first GTM이 큰 회사의 사례라면, 작은 팀의 번역은 이렇다. **글은 campaign이 아니라 signal collector다.** **독자는 traffic이 아니라 stateful customer object다.** **출처는 bibliography가 아니라 context graph다.** **agent는 콘텐츠를 양산하는 도구가 아니라 다음 판단을 queue로 밀어주는 운영자다.** **영업은 감이 아니라 context와 next action을 꺼내는 workflow다.** **고객성공은 담당자의 기억력이 아니라 attention priority를 만드는 시스템이다.** 그러면 GTM은 더 이상 “마케팅팀이 열심히 하는 일”이 아니다. 회사가 고객을 찾고, 이해하고, 설득하고, 살리는 운영체제가 된다. HubSpot 글의 진짜 메시지는 여기 있다. AI 시대의 GTM은 더 많은 콘텐츠가 아니라, 더 좋은 상태 전이다. 그리고 agent-first GTM은 그 상태 전이를 자동화 가능한 단위로 쪼개는 일이다. ## 참고 - HubSpot, [“How we Grow with Agent-first GTM”](https://blog.hubspot.com/marketing/how-we-grow-with-agent-first-gtm?ref=zerodraftlab.com). 확인일: 2026-05-26. - 같은 글은 현재 HubSpot에서 [www.hubspot.com/company-news/how-we-grow-with-agent-first-gtm](https://www.hubspot.com/company-news/how-we-grow-with-agent-first-gtm?ref=zerodraftlab.com)로 리다이렉트된다. ### 클로드가 너무 비싸다면, 구독과 API부터 나눠야 한다 URL: https://zerodraftlab.com/claude-automation-is-not-free/ Last updated: 2026-08-08T11:18:09.000Z **2026년 8월 8일 업데이트:** 이 글의 이전 버전은 Anthropic이 예고한 Agent SDK 분리 과금을 시행된 제도처럼 설명했다. Anthropic은 2026년 6월 15일 그 변경을 중단했다. 현재 Agent SDK, `claude -p`, Claude Code GitHub Actions, 구독으로 인증한 서드파티 앱은 계속 구독 사용량 한도에서 차감된다. 예고됐던 월간 Agent SDK credit은 제공되지 않는다. 클로드가 너무 비싸다고 느껴질 때 먼저 확인할 것은 모델 이름이 아니라 결제 경로다. Claude 구독으로 직접 쓰는지, Claude 구독으로 Agent SDK를 부르는지, Claude Platform의 API key로 호출하는지에 따라 같은 모델도 비용이 다르게 잡힌다. 지금 상태를 짧게 정리하면 이렇다. - Claude 웹, 데스크톱, 모바일과 대화형 Claude Code는 구독 한도를 쓴다. - `claude -p`와 Agent SDK 사용도 현재는 구독 한도를 쓴다. - Claude Platform의 API key로 호출하면 처음부터 사용량 기반 API 요금이 붙는다. - Anthropic이 예고했던 별도 월간 Agent SDK credit은 중단된 안이다. 따라서 “자동화가 전부 별도 유료가 됐다”는 설명은 현재 사실이 아니다. 다만 자동화를 운영할 때 비용표와 중단 조건이 필요하다는 결론은 남는다. 구독 한도도 유한하고, API key를 붙인 작업은 토큰과 부가 기능을 사용한 만큼 청구되기 때문이다. ## 분리 과금은 왜 예고됐고, 왜 멈췄나 Anthropic은 원래 사람의 대화형 사용과 프로그램의 반복 호출을 나누려고 했다. 당시 안에는 Pro 20달러, Max 5x 100달러, Max 20x 200달러의 월간 Agent SDK credit이 들어 있었다. credit을 다 쓴 뒤에는 usage credits를 켠 계정만 표준 API 요율로 계속 실행되고, 그렇지 않으면 다음 주기까지 멈추는 구조였다. 하지만 시행일인 2026년 6월 15일 Anthropic은 변경을 일단 중단했다. 공식 도움말은 Agent SDK, `claude -p`, 서드파티 앱 사용이 계속 구독 한도에서 차감되고, 앞서 발표한 credit도 제공되지 않는다고 고지한다. 아래의 월별 credit 금액은 현재 받을 수 있는 혜택이 아니라 철회된 안의 기록이다. 이 정정이 중요한 이유는 단순하다. 자동화 스크립트를 쓰는 구독자가 당장 별도 credit을 청구받는 것처럼 안내하면 비용 판단을 틀리게 만든다. 반대로 API key를 사용하면서 구독료 안에서 해결된다고 생각해도 틀린다. 인증과 청구 경로를 먼저 봐야 한다. ## 구독과 API는 같은 비용표가 아니다 Claude Code를 터미널이나 IDE에서 대화형으로 쓰면 구독 사용량 한도에서 차감된다. 현재는 `claude -p`와 구독 인증 Agent SDK도 같은 한도에 들어간다. 한도에 닿으면 구독의 사용량 갱신을 기다리거나, 계정에 허용된 추가 사용 방식으로 넘어가야 한다. API key는 다르다. Claude Platform 계정의 key로 요청을 보내면 입력 token, 출력 token, cache, 선택한 기능과 배포 조건에 따라 사용량 기반으로 계산된다. 구독료를 내고 있어도 API key 청구가 구독에 포함되는 것은 아니다. 그래서 비용을 볼 때 “Claude를 썼다”는 기록만으로는 부족하다. 최소한 다음 셋은 갈라야 한다. 1. 사람이 직접 쓴 구독 세션 2. 구독으로 인증한 Agent SDK 또는 `claude -p` 3. API key를 사용한 자동화와 production job 첫째와 둘째는 현재 구독 한도를 공유한다. 셋째는 API 사용량 장부에 쌓인다. ## API 비용은 어디서 커지나 API 비용의 기본식은 입력 token 비용과 출력 token 비용의 합이다. 여기에 cache write, data residency, 빠른 처리 모드, 서버 도구 같은 선택 항목이 붙을 수 있다. 최신 모델별 단가는 Anthropic의 공식 가격표에서 확인해야 한다. 실무에서는 모델 단가보다 호출 구조가 비용을 더 크게 흔든다. ### 긴 문맥을 매번 다시 보낼 때 같은 저장소 설명, 문서 묶음, 대화 기록을 요청마다 통째로 보내면 입력 token이 반복된다. prompt caching의 cache hit은 기본 입력 요금의 10%로 계산되므로 반복 prefix가 충분히 안정적이라면 차이가 커진다. 반대로 매 요청마다 앞부분이 달라지면 cache를 기대하기 어렵다. ### 출력을 길게 열어둘 때 출력 token은 보통 입력 token보다 비싸다. 요약이면 충분한 작업에 긴 설명을 요구하거나, 형식 검증 없이 전체 응답을 다시 만들면 비용이 빠르게 늘어난다. 필요한 결과 형식과 최대 길이를 먼저 정하는 편이 낫다. ### 실패한 job이 다시 자신을 부를 때 자동화는 사람이 지칠 때 멈추지 않는다. 실패한 job이 같은 입력으로 재시도하고, 결과가 없는 상태에서 다시 queue에 들어가면 작은 호출도 누적된다. 최대 반복 횟수, 총예산, 시간 제한, 성공 조건이 없는 agent loop는 모델 선택과 상관없이 비싸진다. ### 부가 기능을 기본값처럼 켤 때 Anthropic의 공식 가격표에는 web search가 1,000회당 10달러로 안내돼 있고 token 비용은 별도다. Batch API는 입력과 출력 비용을 50% 낮춘다. 실시간 응답이 필요하지 않은 대량 작업은 batch가 맞을 수 있고, 검색이 필요 없는 요청에는 검색 도구를 열지 않는 편이 낫다. ## “클로드가 너무 비싸다”를 진단하는 순서 비용을 줄이기 전에 어느 장부가 커졌는지부터 확인한다. 1. **인증 경로:** 구독 로그인인지 API key인지 기록한다. 2. **작업 한 번의 사용량:** 입력, 출력, cache read/write, 도구 호출을 남긴다. 3. **반복 횟수:** 재시도와 self-enqueue를 별도 집계한다. 4. **완료 조건:** 결과가 충분해지면 자동으로 멈추게 한다. 5. **월 상한:** 예상 비용이 정한 금액을 넘기 전에 사람에게 알린다. 그다음에 모델을 바꾼다. 단순 분류와 변환은 더 작은 모델로 보내고, 긴 판단이 필요한 요청만 큰 모델에 남긴다. 반복 입력은 cache에 맞게 고정하고, 즉시성이 필요 없는 묶음은 batch로 보낸다. 이 순서를 건너뛰고 모델만 싸게 바꾸면 실패한 loop가 더 오래 돌 뿐이다. ## 구독은 실험 공간이고 API는 운영 장부다 구독은 사람이 Claude와 일하는 동안 비용을 예측하기 쉽다. Agent SDK와 `claude -p`도 현재는 이 한도를 함께 쓴다. 다만 Anthropic이 한 차례 분리 과금을 예고했다가 중단한 사실은 이 경계가 영구 고정됐다고 볼 근거가 없다는 뜻이기도 하다. 정책이 다시 바뀌면 공식 도움말이 먼저 갱신된다. API key를 붙인 자동화는 처음부터 운영비로 다뤄야 한다. 요청 수가 아니라 token, cache, 도구, 재시도, 성공한 결과 한 건의 비용을 본다. 그래야 “클로드가 비싸다”는 불만을 모델 가격, 잘못된 인증, 긴 문맥, 끝나지 않는 loop 중 실제 원인으로 나눌 수 있다. --- 공식 문서: - [Anthropic Help Center — Use the Claude Agent SDK with your Claude plan](https://support.claude.com/en/articles/15036540-use-the-claude-agent-sdk-with-your-claude-plan?ref=zerodraftlab.com) - [Claude Platform Docs — Pricing](https://platform.claude.com/docs/en/about-claude/pricing?ref=zerodraftlab.com) ### 사업은 아이디어가 아니라 레벨 디자인이다 URL: https://zerodraftlab.com/business-as-video-game/ Last updated: 2026-07-11T12:55:37.000Z 사업을 비디오게임처럼 다루자는 말은 귀엽게 살자는 뜻이 아니다. 노션에 배지를 붙이고, 할 일에 XP를 주고, 하루 스트릭을 세자는 이야기도 아니다. 그런 것도 재미는 있을 수 있다. 하지만 그것만으로는 돈이 안 된다. 진짜 핵심은 따로 있다. 사업은 아이디어 게임이 아니라 레벨 디자인이다. 지금 내가 몇 레벨인지 알아야 하고, 다음 레벨로 가는 문이 어디인지 봐야 하고, 그 문 앞을 막고 있는 보스를 골라야 한다. 그리고 그 보스를 잡는 데 필요한 스킬만 찍어야 한다. 이 순서가 틀리면 사업은 금방 이상해진다. 첫 매출도 없는데 브랜드 세계관을 만든다. 팔리는 오퍼도 없는데 자동화부터 붙인다. 반복 판매가 안 되는데 조직도를 그린다. 고객 접촉은 안 하고 생산성 도구만 바꾼다. 겉으로는 열심히 하는 것 같은데 보스 HP는 그대로다. 이게 문제다. ## 노력은 XP가 아니다 사업을 게임처럼 만들 때 가장 위험한 착각은 “열심히 한 것”에 점수를 주는 것이다. 회의 3개 했다. 노션 정리했다. 로고 고쳤다. 글감 모았다. 툴 세팅했다. 8시간 앉아 있었다. 이런 것에 XP를 주기 시작하면 플레이어는 곧 점수판을 속이는 법을 배운다. 게임에서도 보상함수가 틀리면 유저는 게임을 잘하는 게 아니라 보상함수의 허점을 플레이한다. 사업도 같다. 사업에서 XP는 현실이 반응했을 때만 줘야 한다. 유료 고객이 생겼는가. 고객이 돈을 안 낸 이유를 들었는가. 반복해서 먹히는 세일즈 문장을 찾았는가. 마진이 좋아졌는가. 내가 안 해도 되는 프로세스가 생겼는가. 실패에서 다음 실험 조건을 뽑았는가. 다음번 실행 비용이 줄었는가. 이런 것만 XP다. 나머지는 이동 애니메이션이다. 움직였지만 성장하지 않았을 수 있다. ## 레벨마다 보스가 다르다 David Fragomeni의 [treat business like a video game and get rich](https://youtu.be/U7emMXFQt48?ref=zerodraftlab.com)를 보면서 제일 좋았던 부분도 이거였다. 사업은 레벨마다 필요한 스킬이 다르다. 처음부터 모든 스킬이 필요한 게 아니다. 지금 레벨의 보스를 깨는 스킬이 필요하다. 대충 이렇게 볼 수 있다. ``` Level 0: 팔 만한 오퍼가 없음 보스: 제안 만들기 필수 스킬: 고객 인터뷰, 문제 정의, 카피 Level 1: 첫 매출 전 보스: 1원이라도 벌기 필수 스킬: 세일즈, 아웃리치, 제안 Level 2: 반복 매출 전 보스: 다시 살 이유 만들기 필수 스킬: fulfillment, 고객 성공, 상품 개선 Level 3: 월 1억 전후 보스: 대표 병목 제거 필수 스킬: 운영 시스템, 채널, 품질관리, 자동화 Level 4: 더 큰 스케일 보스: 사람과 조직 필수 스킬: 채용, 리더십, 관리자 구조 Level 5: 포트폴리오 보스: 자본배분 필수 스킬: M&A, 경영자 배치, 리스크 관리 ``` 숫자는 정확하지 않아도 된다. 중요한 것은 순서다. 게임에서는 레벨 제한이 있는 장비를 미리 주워도 쓸 수 없다. 사업도 비슷하다. 지금 레벨에서 쓸 수 없는 고급 전략은 멋있어 보여도 딜이 안 들어간다. 첫 매출 전에는 브랜딩이 아니라 세일즈가 보스일 가능성이 높다. 반복 매출 전에는 자동화가 아니라 오퍼와 fulfillment가 보스일 가능성이 높다. 월 1억 근처에서는 더 열심히 일하는 게 아니라 병목을 제거하는 게 보스일 가능성이 높다. 팀이 생기면 똑똑한 혼자 플레이가 아니라 파티 운영이 보스일 가능성이 높다. 그러니 질문은 “무엇을 하면 멋있어 보이나”가 아니다. 지금 내 보스가 무엇인가. ## 보스 HP를 보여줘야 한다 “사업이 잘 안 된다”는 퀘스트가 아니다. 게임에 이런 퀘스트는 없다. ``` 퀘스트: 어떻게든 잘하기 보상: 언젠가 부자 됨 진행률: 느낌상 23% ``` 이런 게임은 아무도 못 한다. 좋은 퀘스트는 HP가 보인다. ``` 이번 주 보스: 유료 고객 3명 HP: 3 공격 수단: 소개 요청 10개, 콜드DM 50개, 세일즈 콜 5개 승리 조건: 결제 3건 또는 결제 직전 반박 10개 패배 조건: 아무 고객 접촉 없이 내부 정리만 함 ``` 또는 이렇게 쓸 수도 있다. ``` 이번 주 보스: 대표가 직접 처리하는 반복 업무 1개 제거 HP: 1 공격 수단: 현재 절차 기록, 입력/출력 정의, 예외 케이스 정리, 대리 실행 1회 승리 조건: 다음 반복 때 내가 손대지 않아도 완료 패배 조건: 설명은 했지만 실제 위임은 안 됨 ``` 보스 HP가 없으면 사람은 쉽게 자기기만에 빠진다. 많이 고민했다. 방향을 잡았다. 준비했다. 정리했다. 감이 왔다. 이 말들이 전부 거짓이라는 뜻은 아니다. 하지만 보스 HP가 깎이지 않았다면 아직 공격은 안 한 것이다. ## 스킬트리는 골고루 찍는 게 아니다 초보자가 자주 하는 실수는 모든 스킬을 조금씩 올리려는 것이다. 세일즈도 배우고, 브랜딩도 배우고, 채용도 배우고, 자동화도 배우고, 투자도 배우고, 글쓰기도 배우고, 디자인도 배우고, 코딩도 배운다. 나쁘지 않다. 그런데 지금 보스가 세일즈라면 대부분은 회피일 수 있다. 사업의 스킬트리는 대략 이렇게 나뉜다. ``` Hustle Tree - 야망 - 용기 - 규율 - 회복력 - 인내 - 비전 Business Tree - 세일즈 - 오퍼 설계 - 제품/서비스 개발 - fulfillment - 유통 - 운영 시스템 - 브랜딩 - 채용 - 리더십 - 자본배분 ``` 중요한 것은 “앞으로 12개월 동안 무엇을 마스터해야 다음 레벨이 열리는가”다. 세일즈면 세일즈다. 유통이면 유통이다. 제품화면 제품화다. 채용이면 채용이다. 한 시즌에 메인 스킬은 하나여야 한다. 서브 스킬은 있을 수 있지만, 빌드의 중심은 하나다. 게임처럼 생각한다는 것은 재미있는 스킬을 찍는 게 아니라 보스를 잡는 빌드를 고르는 것이다. ## 사업에도 재화가 있다 게임에는 재화가 있다. 사업에도 있다. ``` Gold = 현금 HP = 건강 Mana = 집중력 XP = 검증된 학습 Reputation = 신뢰 Distribution = 고객에게 닿는 채널 Inventory = 재사용 가능한 자산 System = 내가 없어도 굴러가는 구조 ``` 이 중에서 초반에는 Gold와 XP를 자주 헷갈린다. 돈을 못 벌었어도 XP를 얻을 수는 있다. 고객이 왜 안 샀는지 정확히 알게 됐다면 그건 XP다. 반대로 돈을 조금 벌었어도 다음번에 재현할 수 없다면 Gold는 얻었지만 XP는 약할 수 있다. 그리고 제일 무시하면 안 되는 재화는 HP와 Mana다. 사업을 게임처럼 한다는 말이 밤새우고 몸 갈자는 뜻이면 틀렸다. 현실의 게임에는 permadeath가 있다. 한 번 망가지면 복구가 어려운 조건이다. 건강 붕괴. 법적 리스크. 현금 고갈. 신뢰 파괴. 이 네 가지는 게임 오버 조건이다. 강한 플레이어는 무한히 일하는 사람이 아니다. 오래 죽지 않고 플레이하면서 점점 더 강한 시스템을 만드는 사람이다. ## 세이브 파일이 없으면 같은 던전을 돈다 사업에서 제일 아까운 것은 실패가 아니다. 실패했는데 기록이 없는 것이다. 고객이 안 샀는데 이유가 없다. 랜딩을 바꿨는데 전환율이 없다. 가격을 올렸는데 반응이 없다. 채용이 실패했는데 기준이 없다. 미팅을 했는데 다음 액션이 없다. 그러면 같은 던전을 계속 처음부터 돈다. 사업의 세이브 파일은 거창한 문서가 아니다. 최소한 이것만 남기면 된다. ``` 퀘스트: 현재 상태: 목표 상태: 실행: 증거: 결과: 배운 점: 다음 전이: 반복 시 템플릿: ``` 이 기록이 쌓이면 사업은 기억을 갖는다. 기억이 있는 사업만 레벨업한다. 기억이 없는 사업은 대표의 기분과 체력에 따라 매일 리셋된다. ## 파티원을 제대로 써야 한다 어느 순간부터 사업은 솔로 RPG가 아니다. 파티 게임이 된다. 직원, 외주, 파트너, AI agent는 모두 파티원이다. 그런데 파티원을 제대로 쓰려면 역할이 분명해야 한다. 힐러에게 딜을 요구하면 안 된다. 탱커에게 정찰을 맡기면 안 된다. 레벨 3 파티원에게 레벨 40 던전을 맡기면 터진다. 현실 업무도 똑같다. 각 파티원에 대해 최소한 이것이 보여야 한다. ``` 역할: 잘하는 스킬: 맡길 수 있는 퀘스트: 위임 가능 레벨: 쿨다운: 실패 조건: 검토 방식: ``` AI agent도 마찬가지다. “AI가 알아서 해줘”는 파티 전략이 아니다. 읽기 전용인지, 초안 생성인지, 외부 시스템 쓰기인지, Owner 승인이 필요한지 구분해야 한다. 좋은 파티 시스템은 자유방임이 아니라 역할과 게이트가 명확한 구조다. ## 실패를 자아에서 떼어내기 사업을 게임처럼 다루는 진짜 장점은 실패를 조금 더 차갑게 볼 수 있다는 것이다. 제안이 거절됐다. 상품이 안 팔렸다. 광고가 망했다. 채용이 실패했다. 고객이 떠났다. 이때 “내가 실패했다”로 받아들이면 몸이 굳는다. 다음 시도를 피하게 된다. 반대로 “이 보스 패턴을 아직 못 읽었다”로 보면 다시 볼 수 있다. 어떤 공격이 안 먹혔나. 어느 타이밍에 막혔나. 고객은 어떤 문장에서 식었나. 가격 때문인가, 신뢰 때문인가, 타이밍 때문인가. 다음 공격은 무엇인가. 게임은 실패를 데이터로 바꾸는 장치다. 사업도 그렇게 다뤄야 한다. 감정을 없애자는 말이 아니다. 감정이 와도 세이브 파일로 돌아오자는 말이다. ## 이번 주 퀘스트 보드 처음부터 거대한 Founder OS를 만들 필요는 없다. 오늘 필요한 것은 작은 퀘스트 보드다. 매주 이 표 하나만 채우면 된다. ``` 현재 레벨: 다음 레벨: 이번 시즌 보스: 보스 HP: 이번 주 메인 퀘스트: 금지 행동: 필수 스킬: 획득해야 할 loot: 승리 조건: 패배 조건: 세이브 위치: ``` 예를 들면 이렇게 쓴다. ``` 현재 레벨: 오퍼는 있으나 반복 판매 전 다음 레벨: 월 반복 매출 이번 시즌 보스: 유료 고객 5명 보스 HP: 5 이번 주 메인 퀘스트: 세일즈 콜 5개 만들기 금지 행동: 로고 수정, 소개 페이지 리디자인, 생산성 도구 교체 필수 스킬: 콜드아웃리치, 문제 문장화 획득해야 할 loot: 고객 반박 10개, 결제 1건, 새 오퍼 문장 3개 승리 조건: 결제 또는 반박 데이터 확보 패배 조건: 아무 고객 접촉 없이 내부 정리만 함 세이브 위치: 실행 로그와 다음 액션 문서 ``` 이 정도면 충분하다. 사업을 게임처럼 만들기의 첫 버전은 앱이 아니라 시야다. 내가 지금 어디 있는지. 무슨 보스를 잡아야 하는지. 어떤 스킬을 올려야 하는지. 무엇을 하면 점수가 오르는지. 무엇은 해도 점수가 안 오르는지. 다음 반복 때 무엇이 쉬워지는지. 이것이 보이면 사업은 조금 덜 막연해진다. 막연함이 줄어들면 실행이 늘어난다. 실행이 늘어나고, 그 실행이 증거를 남기고, 증거가 다음 퀘스트를 만들고, 퀘스트가 반복 가능한 시스템으로 바뀌면 어느 순간 사업은 진짜 게임처럼 굴러가기 시작한다. 화려한 게임 UI가 있어서가 아니다. 레벨, 보스, 스킬, 재화, 세이브 파일이 생겼기 때문이다. 사업을 게임처럼 한다는 건 가볍게 논다는 뜻이 아니다. 현실을 플레이 가능한 단위로 쪼개고, 매주 보스를 하나씩 잡는다는 뜻이다. 그리고 매주 조금씩 더 강한 캐릭터와 더 강한 시스템으로 돌아오는 것이다. ### 마케팅 채널을 찾는다는 착각 URL: https://zerodraftlab.com/startup-marketing-weird-stuff-depth-first/ Last updated: 2026-07-11T12:55:41.000Z 초기 팀이 “마케팅은 어느 채널부터 해야 하나요?“라고 묻는 순간, 이미 질문이 조금 틀어져 있다. 문제는 채널이 아닐 가능성이 높다. 문제는 사람들이 기억할 만한 이상한 행동이 아직 없다는 것이다. 채널은 증폭기다. 증폭할 신호가 있으면 작게라도 울린다. 신호가 없으면 아무리 좋은 채널에 올려도 회사 소개문, 기능 나열, SEO 문서, 무난한 founder letter가 된다. LinkedIn에 올리든, X에 올리든, Hacker News에 올리든, 뉴스레터로 보내든 결과는 비슷하다. 사람들은 읽고 잊는다. 그러고 나면 팀은 다시 채널을 찾는다. 이번에는 Reddit인가. 이번에는 AEO인가. 이번에는 팟캐스트인가. 이번에는 paid ads인가. 계속 바깥을 본다. 사실 안쪽에 비어 있는 게 있는데도. PostHog 뉴스레터의 [The stuff nobody tells you about startup marketing](https://newsletter.posthog.com/p/the-stuff-nobody-tells-you-about?ref=zerodraftlab.com)은 그래서 좋은 글이다. 겉으로는 초기 스타트업 마케팅 조언처럼 보인다. 하지만 내가 보기에는 채널론이 아니다. 이 글의 진짜 메시지는 더 불편하다. **초기 마케팅은 채널을 고르는 일이 아니라, 남들이 기억할 수밖에 없는 이상한 행동을 공개적으로 반복하는 일이다.** PostHog이 잘한 건 “Hacker News를 잘 활용했다”가 아니다. 그건 너무 얕은 독해다. HN은 유통면이었다. 진짜 자산은 따로 있었다. 작은 회사가 자기 내부를 너무 많이 보여줬다는 것. 핸드북을 공개하고, 창업자가 피벗과 런치와 투자 유치 과정을 쓰고, 회사가 어떻게 생각하고 어떻게 일하는지 웹사이트에 남겼다. 이건 콘텐츠 마케팅이라기보다 증거 노출에 가깝다. “우리 진짜 회사입니다.” “우리는 이렇게 생각합니다.” “우리는 이런 실패를 지나왔습니다.” “이 제품은 그냥 나온 게 아니라 이런 집착에서 나왔습니다.” 초기 팀에게 필요한 건 대개 이런 증거다. 광고 카피가 아니라 증거. 포지셔닝 문장이 아니라 행동. 멋진 브랜드 가이드가 아니라 반복해서 드러나는 이상한 기준. ## 채널 질문은 대개 도피다 “어느 채널을 해야 하냐”는 질문은 성실해 보인다. 하지만 실제로는 꽤 자주 도피다. 왜냐하면 이 질문은 팀을 편하게 해주기 때문이다. 채널을 고르는 문제로 바꾸면, 갑자기 일이 관리 가능해 보인다. SEO 키워드 조사. LinkedIn 발행 캘린더. Reddit 커뮤니티 목록. 뉴스레터 템플릿. 광고 예산. 대행사 견적. 전부 할 일처럼 보인다. 하지만 더 어려운 질문은 따로 있다. **우리가 반복해서 보여줄 수 있는, 우리만의 이상함은 무엇인가?** 이 질문은 불편하다. 답이 없을 수 있기 때문이다. 아직 제품도 평범하고, 내부 기준도 흐릿하고, 실패담도 정리되지 않았고, 창업자의 목소리도 없고, 고객을 만난 흔적도 얇을 수 있다. 그 상태에서 채널만 찾으면 어떻게 되나. SEO 글은 백과사전처럼 밋밋해진다. LinkedIn 글은 성장 조언 흉내가 된다. X 글은 짧은 회사 홍보가 된다. 뉴스레터는 업계 링크 모음이 된다. 랜딩 페이지는 “쉽고 빠른 올인원 솔루션” 같은 문장을 뱉는다. 읽는 사람은 안다. 이 팀이 뭘 믿는지 모르겠다는 것. 어디에 미쳐 있는지 모르겠다는 것. 왜 지금 이 제품을 만들 수밖에 없었는지 모르겠다는 것. 그럴 때 채널은 해결책이 아니다. 오히려 밋밋함을 더 빨리 퍼뜨리는 장치가 된다. ## 작은 회사만 할 수 있는 노출 큰 회사는 이상한 일을 하기 어렵다. 정확히 말하면, 이상한 일을 해도 공개하기 어렵다. 법무가 있고, 브랜드 가이드가 있고, 내부 정치가 있고, 파트너가 있고, 주가가 있고, 말하면 안 되는 것들이 있다. 그래서 큰 회사의 공개 문장은 대개 매끈하다. 매끈한 대신 기억에 덜 남는다. 작은 회사는 반대다. 아직 정리되지 않았기 때문에 보여줄 수 있는 게 있다. 피벗의 흔적, 어설픈 결정, 창업자의 집착, 고객과 직접 부딪힌 기록, 내부 운영 방식, 실수한 뒤 바꾼 기준. 이런 것은 대기업의 콘텐츠팀이 만들기 어렵다. PostHog의 초기 마케팅은 바로 이 지점을 찔렀다. 그들은 개발자에게 “우리 제품 좋습니다”라고만 말하지 않았다. “우리는 이런 회사입니다”를 너무 많이 보여줬다. 제품 소개보다 회사의 판단 방식이 먼저 보이게 했다. 이건 개발자에게 특히 잘 먹힌다. 개발자는 팔리는 느낌을 싫어한다. 하지만 어떤 팀이 왜 그런 선택을 했는지, 어떤 기술적/운영적 기준으로 움직이는지, 어떤 실패를 겪었는지는 궁금해한다. 그 궁금증은 제품 구매 이전의 신뢰를 만든다. 여기서 중요한 건 투명성이라는 예쁜 단어가 아니다. 투명성은 그냥 열어둔다는 뜻이 아니다. 아무거나 공개한다고 마케팅이 되지 않는다. 진짜 중요한 건 **판단의 결이 드러나는가**다. 이 팀은 무엇을 싫어하는가. 무엇을 과하게 중요하게 보는가. 어떤 선택지는 왜 버렸는가. 고객에게 팔기 위해 어떤 거짓말을 하지 않기로 했는가. 작은데도 왜 이렇게까지 공개하는가. 이런 질문에 답이 보이면 사람은 기억한다. ## 초기 마케팅은 설명이 아니라 증거다 초기 팀은 자꾸 설명하려고 한다. 우리는 누구를 위한 제품이고, 어떤 문제를 해결하고, 기존 대안보다 무엇이 좋고, 앞으로 어떤 기능을 만들 예정이고, 가격은 어떻고, 로드맵은 어떻고. 물론 필요하다. 하지만 설명만으로는 약하다. 사람은 초기 제품의 설명을 잘 믿지 않는다. 당연하다. 제품은 미완성이고, 팀은 작고, 오래 갈지도 모르고, 기능은 부족하다. 이때 필요한 건 더 많은 형용사가 아니다. 증거다. 증거는 이런 식으로 생긴다. - 고객을 직접 만난 기록 - 실패한 가설을 접은 기록 - 내부 기준을 공개한 문서 - 제품을 만들며 배운 것 - 창업자가 계속 같은 문제를 물고 늘어진 흔적 - 팀이 남들과 다르게 판단한 장면 이런 것들은 당장 전환율을 깔끔하게 설명하지 못할 수 있다. 하지만 초기에는 이쪽이 더 중요하다. 사람들이 회사를 기억할 이유를 만들기 때문이다. PostHog의 공개 핸드북이나 founder blog가 그랬다. “마케팅 자산”으로 기획했든 아니든, 결과적으로는 회사의 실재감을 만들었다. 초기 제품은 기능만으로 신뢰를 얻기 어렵다. 그래서 회사 자체가 읽혀야 한다. ## SEO는 시작점이 아니라 보관소다 초기 팀이 SEO부터 시작하는 장면을 보면 조금 불안하다. 검색 유입이 중요하지 않다는 말이 아니다. 오히려 장기적으로는 중요하다. 좋은 검색 글은 누적 자산이 된다. AI 답변 표면에서도 구조화된 지식은 점점 더 중요해질 것이다. 하지만 아직 아무도 팀을 기억하지 못하고, 어떤 문장이 고객에게 꽂히는지 모르고, 어떤 문제가 돈을 내게 만드는지 모르는 상태에서 SEO부터 시작하면 이상한 재고가 쌓인다. 키워드에 맞춘 글은 있는데 목소리가 없다. 검색 의도는 맞춘 것 같은데 관점이 없다. 트래픽은 조금 오는데 왜 이 팀이어야 하는지는 남지 않는다. SEO는 학습이 끝난 문장을 보관하는 곳에 가깝다. 먼저 사람에게 닿는 글과 행동이 있어야 한다. 어떤 말에 반응하는지 봐야 한다. 어떤 이야기가 가입, 답장, 추천, 상담으로 이어지는지 봐야 한다. 그다음 반복해서 먹힌 문장을 검색 가능한 형태로 정리해야 한다. 순서를 바꾸면 글은 많아지는데 회사는 선명해지지 않는다. 초기 팀에게 더 위험한 건 글이 없는 상태가 아니다. **아무도 기억하지 못하는 글이 너무 많은 상태**다. ## attribution보다 기억을 봐야 한다 PostHog 글에서 가장 현실적인 조언은 signup flow에 “어디서 우리를 알게 됐나요?“를 묻는 칸을 넣으라는 것이다. 이 조언이 좋은 이유는 단순해서가 아니다. 초기 마케팅에서 봐야 할 것이 클릭 경로보다 기억의 형태에 가깝기 때문이다. 분석 도구는 마지막 클릭을 잘 잡는다. 사람이 founder blog를 읽고, 며칠 뒤 회사 이름을 검색하고, 광고를 클릭해서 가입하면 데이터는 광고가 이겼다고 말할 수 있다. 하지만 실제로 수요를 만든 건 글이었을 수 있다. 초기 팀이 이걸 잘못 읽으면 돈을 잘못 쓴다. 광고가 문을 열었을 뿐인데 광고가 신뢰를 만들었다고 착각한다. 반대로 오래 기억되는 글, 이상한 공개 문서, 창업자의 집착 같은 느린 자산은 과소평가된다. 그래서 직접 물어야 한다. “어디서 보고 왔나요?” 더 정확히는 이렇게 물어야 한다. **“무엇으로 기억하고 있었나요?”** 이 답변은 숫자보다 지저분하다. 하지만 초기에는 그 지저분함이 더 쓸모 있다. 사람이 회사를 어떤 이름으로 기억하는지, 어떤 글을 계기로 다시 찾아왔는지, 어떤 문제와 연결했는지 알려주기 때문이다. 마케팅은 결국 기억을 만드는 일이다. attribution은 그 기억의 그림자를 보는 도구일 뿐이다. ## 대행사가 대신 못 하는 일 초기 마케팅을 대행사에 맡기는 것도 비슷한 도피가 될 수 있다. 대행사는 실행을 도와줄 수 있다. 광고 세팅, 리포트, 디자인 제작, 캠페인 운영, 특정 채널 최적화는 외부 경험이 도움이 된다. 나중에는 당연히 쓸 수 있다. 하지만 초기의 핵심 질문은 대행사가 대신 답할 수 없다. 우리는 왜 기억되어야 하는가. 어떤 고객에게 이상하게 꽂히는가. 어떤 이야기를 반복할 수 있는가. 무엇을 공개할 수 있는가. 이 팀의 목소리는 어디에서 나오는가. 이건 실행 문제가 아니라 자기 이해의 문제다. 이걸 건너뛰고 외주를 주면 결과물은 생긴다. 하지만 감각은 남지 않는다. 팀은 여전히 어떤 글이 좋은 글인지, 어떤 고객이 반응하는지, 어떤 메시지가 제품 판단을 바꿔야 하는지 모른다. 초기 마케팅을 직접 해야 하는 이유는 돈을 아끼기 위해서가 아니다. 제품을 더 잘 만들기 위해서다. 마케팅은 제품 밖에서 하는 일이 아니다. 고객이 제품을 어떤 말로 이해하는지 배우는 과정이다. ## 그러면 무엇을 6주 반복할까 이 글을 그냥 “PostHog은 마케팅을 잘했구나”로 읽으면 별로 남는 게 없다. 핵심은 따라 할 채널이 아니라 따라 잡을 강도다. 초기 팀은 먼저 자기 안에서 공개 가능한 이상함을 찾아야 한다. 그 이상함은 대개 고상한 브랜드 문장으로 나오지 않는다. 더 작고 구체적인 장면에서 나온다. 고객과 이야기하다가 매번 같은 오해를 만나는 장면. 제품을 만들며 남들은 당연하게 받아들이는 관행을 못 견디는 장면. 경쟁사가 숨기는 비용을 굳이 공개하려는 장면. 실패한 기능을 왜 버렸는지 설명하는 장면. 작은 팀이라서 오히려 더 솔직하게 말할 수 있는 장면. 이런 것이 없으면 마케팅은 계속 외부 모범답안을 베끼게 된다. AI 글쓰기 도구를 위한 SEO 문서. B2B SaaS를 위한 LinkedIn thought leadership. 개발자 도구를 위한 Hacker News launch. 소비자 앱을 위한 TikTok short-form. 전부 틀린 말은 아니다. 하지만 이건 채널의 이름일 뿐이다. 그 안에서 무엇이 기억될지는 여전히 비어 있다. 그래서 6주 실험은 “어느 채널에 올릴까”가 아니라 “어떤 이상함을 반복할까”로 잡아야 한다. 예를 들면 이런 식이다. - 매주 한 번, 제품을 만들며 실제로 내린 판단 하나를 공개한다. - 매주 한 번, 고객과 부딪힌 오해 하나를 글로 쓴다. - 매주 한 번, 버린 기능이나 포기한 전략을 설명한다. - 매주 한 번, 업계에서 당연하게 여기는 말을 하나 골라 반박한다. - 매주 한 번, 내부에서 쓰는 기준이나 체크리스트를 밖으로 꺼낸다. 형식은 중요하지 않다. founder blog여도 되고, 짧은 메모여도 되고, 긴 에세이여도 되고, 데모 영상이어도 된다. 중요한 건 매번 같은 종류의 기억을 남기는 것이다. “저 팀은 저 문제를 이상하게 진지하게 본다.” 이 문장이 생기면 실험이 시작된 것이다. 판단 기준도 단순해야 한다. 6주 뒤에 사람들이 그 팀을 특정 문장으로 기억하는가. 그 기억이 가입, 답장, 추천, 상담, 재방문 중 하나로 이어지는가. 팀 내부에서도 그 글들이 제품 판단을 더 선명하게 만드는가. 아니면 접는다. 계속할지 말지 모르는 상태가 제일 나쁘다. 애매한 콘텐츠는 운영 부담으로 남는다. 초기 팀은 그런 재고를 쌓을 여유가 없다. ## 결론 초기 마케팅의 첫 질문은 “어느 채널?“이 아니다. 첫 질문은 이거다. **우리는 무엇으로 기억될 것인가?** 그 답이 없으면 채널은 소용없다. SEO도, X도, LinkedIn도, Reddit도, 뉴스레터도, 광고도 전부 밋밋함을 유통할 뿐이다. PostHog이 보여준 건 채널 선택의 모범답안이 아니다. 작은 팀이 자기만의 이상함을 공개적으로 반복하면, 그 자체가 마케팅이 된다는 사실이다. 초기 팀은 큰 회사처럼 보이려고 할수록 약해진다. 작은 회사만 보여줄 수 있는 것을 보여줘야 한다. 아직 정리되지 않은 판단, 실패의 흔적, 창업자의 집착, 고객을 만나며 바뀐 문장, 남들이 숨기는 운영 방식. 그게 먼저다. 채널은 그다음이다. --- 출처: Charles Cook, PostHog Newsletter, [The stuff nobody tells you about startup marketing](https://newsletter.posthog.com/p/the-stuff-nobody-tells-you-about?ref=zerodraftlab.com) ### Mailgun, Resend, Postmark: 이메일 API가 아니라 제품의 대화 방식을 고르는 일 URL: https://zerodraftlab.com/email-api-product-interface/ Last updated: 2026-07-11T12:55:45.000Z 이메일 벤더를 고를 때 제일 흔한 실수는 가격표부터 보는 것이다. 몇 통까지 무료인지, 월 얼마인지, 1,000통당 얼마인지 비교한다. 물론 돈은 중요하다. 그런데 작은 제품에서 이메일 벤더를 고를 때 진짜 중요한 건 가격이 아니다. 더 중요한 질문은 이것이다. > 이 제품에서 이메일은 무슨 역할을 하는가? 이메일을 단순 알림으로 쓸 수도 있다. 이메일을 대량 배포 채널로 쓸 수도 있다. 이메일을 사용자가 제품에 무언가를 입력하는 입구로 쓸 수도 있다. 이 세 가지는 완전히 다른 문제다. 그런데 우리는 자주 이걸 뭉뚱그려 “메일 발송”이라고 부른다. 그래서 선택이 흐려진다. 내 기준은 단순하다. > Resend는 알림을 보낼 때 좋다. > Mailgun은 많이 뿌릴 때 좋다. > Postmark는 이메일이 제품 상태를 바꾸는 입구일 때 좋다. 이게 이 글의 전부다. ## 이메일은 죽은 채널이 아니라 낡지 않은 인터페이스다 요즘 제품에서 이메일은 여전히 가장 보편적인 인터페이스다. 가입 링크가 이메일로 온다. 결제 영수증이 이메일로 온다. 리포트가 이메일로 온다. 장애 알림이 이메일로 온다. 고객 문의가 이메일로 들어온다. AI 에이전트의 결과물이 이메일로 오고, 사람이 답장하면 다음 단계가 진행된다. 그러니까 이메일은 단순한 알림 채널이 아니다. 제품과 외부 세계가 만나는 오래된 API다. 브라우저를 열지 않아도 된다. 새 앱을 배우지 않아도 된다. 계정을 새로 만들지 않아도 된다. 그냥 메일을 받거나 보내면 된다. 이 단순함 때문에 이메일은 오래 살아남았다. 그리고 이 단순함 때문에 제품 안에서 꽤 강력하다. 사용자가 이미 알고 있는 인터페이스이기 때문이다. ## 좋은 제품은 이메일 벤더를 사용자에게 숨긴다 Ghost를 보면 이 원칙이 잘 보인다. Ghost(Pro)는 이메일 발송 설정을 사용자가 직접 만지지 않게 한다. 이메일 delivery는 서비스에 포함되어 있고, 설정은 Ghost가 처리한다. 사용자는 Mailgun, SMTP, API key를 몰라도 된다. 반대로 self-hosted Ghost에서 뉴스레터를 보내려면 Mailgun 설정이 필요하다. Ghost 문서는 대량 뉴스레터를 기본 SMTP로 보내지 말라고 한다. bulk email은 별도의 bulk mail provider가 필요하고, Ghost가 공식 지원하는 bulk provider는 Mailgun이다. 이 차이가 중요하다. 대여형 소프트웨어에서 사용자는 이메일 벤더를 고르고 싶은 게 아니다. 사용자가 원하는 건 “내 고객에게 메일이 잘 감”이다. SaaS든, 출판 서비스든, 마켓플레이스든, AI agent 앱이든 마찬가지다. 벤더는 내부 선택이다. 제품 경험은 하나의 약속이어야 한다. 좋은 제품은 내부 인프라를 설명하지 않는다. 그냥 약속한 일이 되게 만든다. ## Resend: 제품에서 메일을 보내야 할 때 Resend는 시작이 빠르다. API가 단순하고 문서가 깔끔하다. 작은 앱에서 회원가입 메일, 초대 메일, waitlist 알림, 결제 완료 메일, 운영자 알림을 붙이기 좋다. 2026년 5월 26일 기준 공식 문서상 Free는 3,000 emails/month, 100 emails/day이고, Pro는 월 20달러부터 시작한다. 초기 제품에는 충분히 매력적인 구간이다. 그래서 문제가 “제품 이벤트가 생겼을 때 이메일을 보내고 싶다”라면 Resend가 가장 편하다. 예를 들면 이런 경우다. 사용자가 가입했다. 로그인 링크를 보내야 한다. 새 신청이 들어왔다. 운영자에게 알림을 보내야 한다. 결제가 끝났다. 영수증을 보내야 한다. 이 정도라면 Resend가 좋다. 개발자가 붙이기 쉽고, 코드도 예쁘게 남는다. 다만 Resend의 중심은 여전히 “잘 보내는 API”에 가깝다. 이메일이 제품의 입구가 되고, 사용자의 답장이 상태를 바꾸고, inbound가 운영 로직과 강하게 붙기 시작하면 이야기가 달라진다. ## Mailgun: 이메일이 배포망일 때 Mailgun은 더 인프라답다. Ghost self-hosted가 뉴스레터 발송에 Mailgun을 요구하는 이유도 여기에 있다. 많은 사람에게 이메일을 보내는 일은 그냥 SMTP로 밀어 넣는 문제가 아니다. 도메인 인증이 필요하다. 평판 관리가 필요하다. bounce와 suppression이 필요하다. event log가 필요하다. unsubscribe와 route가 필요하다. Mailgun은 이런 “이메일 배포망”의 느낌이 강하다. 2026년 5월 26일 기준 공식 Help Center에 따르면 무료 플랜은 100 messages/day, 1 custom domain, 1 inbound route를 제공한다. 뉴스레터가 제품의 본체라면 Mailgun은 계속 강한 후보다. 커뮤니티 공지, 리포트 대량 발송, 회원 세그먼트별 메일, 출판물 배포처럼 “많은 사람에게 안정적으로 보내는 것”이 중요하면 Mailgun 쪽으로 기운다. 단점은 있다. 가벼운 제품에는 조금 무겁다. 오늘 당장 waitlist 알림 하나 붙이려고 Mailgun을 보면 설정 표면이 과하게 느껴질 수 있다. Mailgun은 “메일 하나 보내기”보다 “메일을 계속 많이 보내는 시스템”에 가깝다. ## Postmark: 이메일이 워크플로우의 입구일 때 Postmark는 결이 다르다. Postmark는 transactional email의 신뢰성과 속도를 오래 밀어온 서비스다. 그리고 inbound email processing도 잘 갖춰져 있다. 이메일을 JSON 이벤트로 받아 제품 안의 상태와 연결하기 좋다. 이 차이는 생각보다 크다. 고객이 이메일로 문의하면 티켓이 생긴다. 운영자가 답장하면 상태가 바뀐다. AI 에이전트가 결과물을 이메일로 보내고, 사람의 승인 답장을 기다린다. 작가가 원고를 이메일로 보내면 검토 큐에 들어간다. 파트너가 첨부 파일을 보내면 내부 레코드가 생긴다. 이런 흐름에서는 “메일을 보내는 API”보다 “메일을 제품 이벤트로 바꾸는 파이프”가 중요하다. Postmark가 잘 맞는 지점은 여기다. 이메일을 알림이 아니라 상태 전이의 입구로 볼 때. 2026년 5월 26일 기준 Postmark의 Free tier는 100 emails/month이고, Basic은 월 15달러부터 시작한다. Resend보다 무료 구간은 작다. 대신 작은 프로덕션 서비스가 돈을 내고 쓰는 운영 파이프로는 납득 가능한 수준이다. ## 셋은 경쟁자라기보다 세 가지 세계관이다 Mailgun, Resend, Postmark는 겹치는 부분이 있다. 셋 다 메일을 보낼 수 있다. 셋 다 API가 있다. 셋 다 어느 정도의 운영 기능을 제공한다. 하지만 제품을 고르는 기준은 “가능하냐”가 아니다. 무엇을 중심에 두고 설계됐는지가 중요하다. Resend는 빠르게 붙이는 개발자 경험이 좋다. Mailgun은 대량 발송과 이메일 인프라 운영에 강하다. Postmark는 신뢰성 있는 transactional과 inbound workflow에 강하다. 그래서 답은 하나가 아니다. 초기 SaaS에서 알림 메일을 빨리 붙일 거면 Resend. 뉴스레터와 대량 발송이 핵심이면 Mailgun. 이메일이 사용자의 입력이자 운영 상태의 시작점이면 Postmark. 이렇게 고르면 된다. ## 이메일 벤더 선택은 제품 설계다 처음에는 모두 “메일 하나 보내면 되지 않나?“로 시작한다. 그런데 제품이 조금만 진지해지면 이메일은 금방 상태, 권한, 승인, 고객 경험, 운영 비용과 연결된다. 누가 어떤 주소로 보냈는가. 그 메일은 어떤 고객, 주문, 글, 작업과 연결되는가. 답장을 하면 무엇이 바뀌는가. 실패하면 누가 알아야 하는가. 대량 발송에서 빠진 사람은 어떻게 관리하는가. 이 질문들이 생기는 순간 이메일은 단순 발송 기능이 아니다. 제품의 바깥쪽 인터페이스다. 그래서 이메일 벤더 선택은 가격표 비교가 아니다. 제품이 외부 세계와 대화하는 방식을 정하는 일이다. 사용자는 그 벤더 이름을 몰라도 된다. 아니, 몰라야 한다. 좋은 제품은 내부 인프라를 숨긴다. 사용자는 그냥 약속한 일이 됐는지만 본다. 내 결론은 간단하다. 이메일을 알림으로 보면 Resend가 먼저 보인다. 이메일을 배포망으로 보면 Mailgun이 먼저 보인다. 이메일을 워크플로우의 입구로 보면 Postmark가 먼저 보인다. 그리고 이 셋 중 무엇을 고르든, 진짜 결정은 벤더가 아니라 제품 쪽에서 이미 내려진다. 이 제품은 이메일을 무엇으로 보는가. 그 질문에 답하면, 벤더 선택은 따라온다. ## 참고 - [Ghost: Email Newsletters](https://docs.ghost.org/newsletters/?ref=zerodraftlab.com) - [Ghost: Why do I have to set up Mailgun?](https://docs.ghost.org/faq/mailgun-newsletters/?ref=zerodraftlab.com) - [Resend: What is Resend Pricing](https://resend.com/docs/knowledge-base/what-is-resend-pricing?ref=zerodraftlab.com) - [Mailgun: What does the Free plan offer?](https://help.mailgun.com/hc/en-us/articles/203068914-What-does-the-Free-plan-offer?ref=zerodraftlab.com) - [Postmark: Pricing and Free Trial](https://postmarkapp.com/pricing/?ref=zerodraftlab.com) ### 뉴타입 선언: AI를 갑옷과 도구로 입기 URL: https://zerodraftlab.com/newtype-manifesto/ Last updated: 2026-07-11T12:55:48.000Z AI 혁명은 모두에게 같은 의미로 오지 않는다. 어떤 사람에게 AI는 더 빠른 검색창이고, 어떤 사람에게는 업무 자동화 도구다. 하지만 신경다양인에게 AI는 조금 다른 의미가 될 수 있다. 그것은 부족한 의지력을 대신하는 기계가 아니라, 다르게 작동하는 뇌가 세상과 맞닿을 때 생기는 마찰을 줄여주는 외부 구조다. Neutype은 여기서 시작한다. 다른 뇌를 표준에 억지로 맞추는 대신, AI를 갑옷과 도구로 입는 법을 배운다. 갑옷은 약점이 곧바로 상처가 되지 않게 막아준다. - 기억이 새는 사람에게 AI는 외부 기억 장치가 된다. - 시작이 어려운 사람에게 AI는 첫 문장과 첫 단계를 만들어준다. - 정리가 늦는 사람에게 AI는 흩어진 생각을 구조로 바꿔준다. - 감정과 자극에 쉽게 지치는 사람에게 AI는 말의 온도를 낮추고, 선택지를 줄이고, 다음 행동을 작게 만든다. 이 갑옷은 사람을 숨기기 위한 것이 아니다. 매번 같은 곳에서 다치지 않기 위한 구조다. 도구는 강점이 실제 결과로 이어지게 해준다. 빠르게 연결하는 사람은 AI와 함께 더 많은 가설을 만든다. 깊게 파고드는 사람은 AI와 함께 자료를 정리하고 긴 탐구를 이어간다. 패턴을 잘 보는 사람은 AI에게 반복 데이터를 맡기고, 자신은 이상한 부분을 더 빨리 본다. 말보다 이미지와 흐름으로 생각하는 사람은 AI를 통해 생각을 글, 표, 계획, 코드, 그림으로 번역한다. AI는 신경다양인의 뇌를 고쳐주지 않는다. 그럴 필요도 없다. 더 중요한 것은 번역이다. 머릿속에서는 선명하지만 밖으로 꺼내기 어려웠던 것, 감각으로는 알지만 말로 설명하기 어려웠던 것, 시작하기 전에는 너무 커 보였던 일을 다룰 수 있는 단위로 바꾸는 일이다. 그래서 뉴타입에게 AI는 단순한 생산성 도구가 아니다. 외부 실행기능이고, 생각의 스캐폴딩이며, 감각과 언어 사이의 번역기다. 물론 AI를 쓰는 것만으로 강점이 생기지는 않는다. AI는 방향 없는 에너지를 자동으로 좋은 결과로 바꿔주지 않는다. 오히려 잘못 쓰면 더 많은 탭, 더 많은 초안, 더 많은 미완성을 만든다. 그래서 뉴타입에게 필요한 것은 더 많은 도구가 아니라 자기 사용법이다. 어떤 일이 나를 쉽게 소진시키는가. 어떤 작업에서 나는 빨리 살아나는가. 어떤 마찰은 밖으로 꺼내 자동화해야 하는가. 어떤 강점은 AI를 붙였을 때 더 멀리 갈 수 있는가. 이 질문에 답하기 시작하면 AI는 유행이 아니라 장비가 된다. 뉴타입 선언은 단순하다. 우리는 표준적인 뇌가 되기 위해 모든 힘을 쓰지 않는다. 우리는 약점을 부끄러움으로 숨기지 않고, 구조로 보호한다. 우리는 강점을 감정적인 위로로 남겨두지 않고, 실제 결과로 훈련한다. 우리는 AI를 대신 생각하는 기계가 아니라, 더 잘 생각하고 더 덜 다치기 위한 갑옷과 도구로 사용한다. 우리는 다르게 작동하는 뇌를 세상에 맞추는 것에서 멈추지 않고, 세상과 일하는 방식을 다시 설계한다. AI 혁명은 이미 시작됐다. 뉴타입은 그것을 누구보다 빨리 흡수해야 한다. 더 빨리 따라가기 위해서가 아니다. 자신의 강점이 드디어 형태를 가질 수 있는 시대가 왔기 때문이다. ### 강점에 집중하라는 말이 부담스러울 때 URL: https://zerodraftlab.com/focus-on-strengths/ Last updated: 2026-07-11T12:55:51.000Z 강점 집중은 약점을 무시하자는 말이 아니라, 약점은 시스템으로 막고 남은 에너지를 잘 켜지는 능력에 쓰자는 말이다. “강점에 집중하라”는 말은 가끔 부담스럽게 들린다. 이미 놓치는 것도 많고, 버티기 어려운 것도 많은데, 갑자기 강점을 찾으라고 하면 또 하나의 숙제처럼 느껴질 수 있다. Neutype이 말하는 강점 집중은 그런 뜻이 아니다. 약점을 모른 척하자는 말도 아니고, 신경다양성을 멋진 이야기로 포장하자는 말도 아니다. 더 현실적인 뜻에 가깝다. 에너지가 제한되어 있다면, 약점은 밖으로 꺼내 시스템으로 막고, 남은 에너지는 잘 켜지는 능력에 써야 한다는 뜻이다. 먼저 약점은 의지력 문제가 아니라 마찰로 본다. 일정이 자주 무너지면 기억력을 더 탓하기보다 캘린더, 알림, 체크리스트, 외부 마감을 붙인다. 소음에 쉽게 지치면 참는 시간을 늘리기보다 자리, 장비, 회복 시간을 조정한다. 시작이 어렵다면 큰 결심 대신 첫 화면, 첫 문장, 첫 5분처럼 시작 장치를 작게 만든다. 그다음 강점이 켜지는 조건을 찾는다. 어떤 사람은 새로움이 있을 때 빠르게 움직인다. 어떤 사람은 규칙과 패턴을 볼 때 안정된다. 어떤 사람은 작은 불편을 남들보다 먼저 알아차린다. 어떤 사람은 한 가지 주제에 오래 머물 수 있다. 이것들은 그냥 성격이 아니라, 잘 배치되면 일과 학습의 방향이 된다. 강점은 기분 좋은 말이 아니라 반복 가능한 결과로 확인한다. - 어떤 일을 할 때 시간이 덜 무겁게 느껴지는가. - 어떤 문제를 남들보다 빨리 알아차리는가. - 어떤 환경에서 덜 지치고 더 오래 버티는가. - 어떤 결과에 대해 사람들이 계속 도움을 요청하는가. 이 네 가지가 겹치는 지점은 중요하다. 그곳에서 강점은 취향을 넘어 실제 능력이 된다. 작은 실험부터 시작해도 된다. 이번 주에 하나의 약점을 시스템으로 바꾸고, 하나의 강점을 더 자주 쓰이게 해본다. 예를 들어 회의 내용을 자주 잊는다면 회의 후 3분 체크리스트를 만든다. 동시에 패턴을 잘 보는 사람이라면 회의에서 “반복되는 문제 하나”를 찾아 공유한다. 약점은 덜 새게 하고, 강점은 더 보이게 하는 식이다. 강점에 집중한다는 것은 완벽한 사람이 되자는 말이 아니다. 자신에게 맞지 않는 방식으로 하루를 다 쓰지 않기 위한 선택이다. 신경다양성은 면죄부가 아니지만, 설계의 단서가 될 수 있다. 무엇을 못 하는지만 보면 전략은 교정으로 좁아진다. 무엇을 할 때 살아나는지도 함께 보면, 일상은 조금 더 다루기 쉬워진다. ### 새로움에 자주 끌리는 뇌를 위한 작은 구조 URL: https://zerodraftlab.com/hypercurious-mind/ Last updated: 2026-07-11T12:55:54.000Z 새로움에 자주 끌리는 뇌는 망가진 집중력이 아니라, 다른 조건에서 켜지는 집중력일 수 있다. *참고한 글: Anne-Laure Le Cunff, The hypercurious mind, Aeon.* 어떤 뇌는 새 정보에 아주 빠르게 반응한다. 아직 풀리지 않은 질문, 낯선 단서, 방금 열린 가능성이 눈에 들어오면 주의가 그쪽으로 이동한다. 이것은 게으름도, 단순한 산만함도 아니다. 때로는 뇌가 흥미와 정보 보상을 따라 움직이는 방식이다. Aeon의 글은 이 특성을 hypercuriosity라는 말로 설명한다. ADHD를 가진 사람에게 새로움과 불확실성은 강한 동력이 될 수 있다. 그래서 같은 사람도 반복적인 업무 앞에서는 금방 지치지만, 탐색하고 연결하고 문제를 발견하는 일 앞에서는 오래 집중할 수 있다. 이 관점이 중요한 이유는 책임을 없애기 위해서가 아니다. 오히려 좋은 구조를 만들기 위해서다. “왜 집중을 못 하지?“에서 멈추면 답은 의지력뿐이다. “어떤 조건에서 주의가 켜지고, 어떤 조건에서 꺼질까?“라고 물으면 설계할 수 있는 것이 생긴다. 새로움에 잘 반응하는 뇌에는 작은 구조가 도움이 된다. - 반복 업무에는 시작과 끝이 보이게 한다. - 긴 일은 20분 안에 확인할 수 있는 작은 결과물로 나눈다. - 떠오르는 아이디어는 바로 실행하지 않고 한곳에 모아둔다. - 중요한 일에는 마감, 동료 확인, visible checklist처럼 바깥 구조를 붙인다. - 쉬는 시간에는 더 강한 자극을 찾기보다 자극을 낮추는 회복 장치를 먼저 둔다. 이런 구조는 사람을 고치려는 장치가 아니다. 이미 다르게 움직이는 주의를 덜 소모시키는 장치다. 새로움에 끌리는 힘은 잘못된 것이 아니지만, 알림과 피드에 계속 끌려가면 쉽게 지친다. 반대로 질문, 리서치, 창작, 문제 해결처럼 탐색이 실제 결과로 이어지는 환경에서는 같은 힘이 좋은 감각이 될 수 있다. Neutype은 신경다양성을 “좋다” 혹은 “나쁘다”로 단순화하지 않는다. 대신 한 가지 질문을 계속 붙잡는다. 이 뇌가 덜 지치고 더 잘 작동하려면 어떤 구조가 필요할까. 그 질문에서 실용적인 변화가 시작된다. ### AI 전환은 믿음이 아니라 운영에서 막힌다 URL: https://zerodraftlab.com/why-ai-transformation-stalls/ Last updated: 2026-07-11T12:55:58.000Z AI 전환은 모델을 믿느냐의 문제가 아니라, 업무 안에 안전하게 맡길 수 있는 단위가 있느냐의 문제다. AI를 못 믿는 사람은 생각보다 적다. 대부분은 이미 안다. 이게 큰 변화라는 것도 알고, 언젠가 자기 일에 들어올 거라는 것도 안다. 주변에서 누군가는 이미 쓰고 있고, 뉴스에서는 매일 새로운 에이전트(agent, 대리 실행자)가 나온다. 문서도 쓰고, 회의록도 정리하고, 코딩도 하고, 세일즈 메일도 만든다. 그런데 막상 자기 업무 앞에 오면 말이 달라진다. “AI 잘하는 건 아는데, 아직은 좀…” “내 업무는 맥락이 많아서…” “요즘 너무 바빠서 배울 시간이 없어.” “전에 써봤는데 별로던데?” “회사 정책이 애매해서 어디까지 써도 되는지 모르겠어.” “이거 쓰면 결국 내가 검토할 일만 더 늘어나는 거 아냐?” 이 말들은 게으름의 증거가 아니다. 대부분은 꽤 정확한 조직 진단이다. AI 전환은 사람들이 변화를 싫어해서 막히는 게 아니다. 일하는 방식이 그대로라서 막힌다. ## 사람들은 반대하지 않는다. 유예한다. 조직 안에서 AI는 보통 이상한 위치에 있다. 중요하다고 말은 한다. 하지만 업무 목표에는 안 들어간다. 권장한다고 말은 한다. 하지만 평가 기준은 그대로다. 써보라고 말은 한다. 하지만 어느 업무에, 어떤 기준으로, 어떤 책임 구조 안에서 써야 하는지는 비어 있다. 그러면 사람은 당연히 기존 방식으로 돌아간다. 이건 보수적이라서가 아니다. 현명해서다. 월말 평가와 팀장의 피드백과 고객의 컴플레인은 모두 기존 업무 방식 위에서 온다. AI를 써서 더 나은 방식을 실험하는 사람보다, 기존 루틴을 안정적으로 수행하는 사람이 덜 위험하다. 그래서 AI 전환의 첫 번째 패턴은 `인정-유예형`이다. 사람들은 AI가 중요하다는 것을 인정한다. 다만 지금 자기 차례는 아니라고 생각한다. “나중에 제대로 배워야지”라고 말한다. 그 나중은 대개 오지 않는다. 왜냐하면 바쁘기 때문이다. ## 너무 바빠서 못 배운다는 역설 AI를 배우면 시간이 생긴다. 그런데 시간이 없어 AI를 못 배운다. 이 문장은 우스워 보이지만, 조직 안에서는 매우 현실적이다. 이미 꽉 찬 캘린더, 끝없는 슬랙, 회의록, 보고서, 고객 대응, 내부 정렬 사이에 새로운 도구를 배우는 일은 추가 업무처럼 느껴진다. 문제는 AI가 처음부터 시간을 줄여주지 않는다는 점이다. 처음에는 오히려 일이 늘어난다. 프롬프트를 써야 하고, 결과를 검토해야 하고, 틀린 부분을 고쳐야 하고, 어떤 업무에 쓸 수 있는지 실험해야 한다. 도구가 여러 개면 더 힘들다. 한 앱에서 맥락을 복사하고, 다른 앱에 붙이고, 다시 결과를 가져와 원래 시스템에 반영한다. 이때 사람은 사실상 휴먼 미들웨어(human middleware, 시스템 사이를 잇는 인간 연결부)가 된다. AI를 쓰는데 더 바빠지는 이유다. 자동화가 됐는데도 사람은 시스템 사이를 뛰어다닌다. 이 상태에서 “AI를 더 적극적으로 써보세요”라고 말하면, 현장에서는 “일을 하나 더 하라는 말”로 들린다. ## “내 업무는 특수하다”는 말의 절반은 맞다 AI 전환에서 가장 자주 나오는 말 중 하나는 이것이다. “내 업무는 맥락이 많아서 AI가 못 해.” 이 말은 절반은 방어이고, 절반은 진실이다. 많은 업무는 정말 맥락이 많다. 고객과의 과거 대화, 조직 내부 정치, 제품의 예외 케이스, 암묵적 우선순위, 말로 적히지 않은 기준이 있다. 이런 맥락 없이 AI에게 일을 맡기면 결과는 평범하거나 위험하다. 하지만 여기서 진짜 문제는 AI가 맥락을 이해하지 못한다는 것이 아니다. 조직이 그 맥락을 읽을 수 있는 형태로 정리해두지 않았다는 것이다. 사람 머릿속에만 있는 기준, 슬랙 어딘가에 흩어진 결정, 회의에서만 합의된 우선순위, 문서로 남지 않은 고객 이해. 이 상태에서는 AI뿐 아니라 새로 입사한 사람도 제대로 일하기 어렵다. AI는 이 문제를 새로 만든 것이 아니라 드러낸다. 좋은 AI 전환은 “어떤 툴을 쓸까?”에서 시작하지 않는다. “우리 업무의 맥락은 어디에 저장되어 있는가?”에서 시작한다. ## 섀도 AI는 이미 시작됐다 공식 전환이 느릴수록 비공식 전환은 빨라진다. 사람들은 이미 몰래 쓴다. 메일 초안을 만들고, 보고서를 요약하고, 회의 아젠다를 정리하고, 엑셀 수식을 물어보고, 고객 답변의 톤을 다듬는다. 회사가 정책을 만들기 전에 개인은 살길을 찾는다. 이걸 섀도 AI(shadow AI, 비공식 AI 사용)라고 부를 수 있다. 섀도 AI는 위험하지만, 동시에 신호다. 사람들은 변화를 거부하는 게 아니다. 오히려 공식 시스템보다 빨리 적응하고 있다. 다만 회사가 그 사용을 안전하고 반복 가능한 워크플로우(workflow, 업무 흐름)로 만들지 못했을 뿐이다. 그래서 AI 전환의 질문은 “직원들이 AI를 쓰게 만들려면?”이 아니다. 이미 쓰고 있는 개인의 편법을 어떻게 조직의 자산으로 바꿀 것인가다. ## AI 전환은 도구 도입이 아니라 업무 재설계다 AI 전환이 실패하는 이유는 대개 모델 성능이 부족해서가 아니다. 업무가 바뀌지 않았기 때문이다. 회의는 그대로다. 보고 방식도 그대로다. 승인 구조도 그대로다. KPI도 그대로다. 정보는 여전히 흩어져 있고, 책임은 여전히 애매하고, 사람들은 여전히 즉답성과 회의 참석으로 성실함을 증명한다. 그 위에 AI 도구만 얹으면 이상한 일이 생긴다. 더 많은 초안이 생긴다. 더 많은 문서가 생긴다. 더 많은 요약이 생긴다. 더 많은 알림이 생긴다. 하지만 결정은 빨라지지 않는다. 책임은 선명해지지 않는다. 고객 경험도 크게 좋아지지 않는다. 생산량은 늘었는데, 판단은 그대로이기 때문이다. AI 전환의 본질은 생산성을 조금 올리는 것이 아니다. 업무의 기본 단위를 다시 정하는 것이다. 무엇을 사람이 판단할 것인가. 무엇을 AI에게 위임할 것인가. 어떤 결과는 자동으로 실행해도 되는가. 어떤 결과는 반드시 사람이 검토해야 하는가. 어떤 맥락을 항상 제공해야 하는가. 실패했을 때 책임은 어디에 있는가. 이 질문 없이 도구만 늘리면, 조직은 더 빨리 혼란스러워진다. ## 좋은 전환은 작고 구체적이다 AI 전환을 잘하는 조직은 거창한 선언보다 작은 반복 구조를 만든다. 예를 들면 이런 식이다. 매주 한 팀이 자기 업무 중 하나를 고른다. “고객 문의 초안 작성”, “영업 콜 후속 메일”, “회의록에서 액션 아이템 추출”, “기능 요청 분류”처럼 작고 반복적인 업무를 고른다. 그 업무의 입력, 판단 기준, 출력 형식, 검토자를 정한다. 그리고 AI를 넣어본다. 결과가 좋으면 워크플로우로 만든다. 별로면 왜 별로였는지 기록한다. 프롬프트 문제가 아니라 맥락 부족인지, 데이터 접근 문제인지, 책임 구조 문제인지 구분한다. 이 루프가 쌓이면 조직은 배운다. AI를 잘 쓰는 조직은 천재 직원 몇 명이 있는 조직이 아니다. 실험이 조직 기억으로 남는 조직이다. ## 결국 기억층의 문제다 AI 전환의 마지막 병목은 기억이다. 개인이 AI를 쓰는 것은 쉽다. 하지만 조직이 AI를 쓰려면, AI가 읽을 수 있는 기억층이 필요하다. 고객은 누구인지, 우리가 어떤 약속을 했는지, 어떤 결정이 왜 내려졌는지, 어떤 기준으로 우선순위를 정하는지, 어떤 표현은 브랜드에 맞지 않는지. 이것들이 정리되어 있지 않으면 AI는 평균적인 답을 낸다. 평균적인 답은 놀랍지만, 회사의 답은 아니다. 회사의 답은 공개 인터넷에 없다. 고객과의 대화, 내부의 시행착오, 창업자의 판단, 팀의 취향, 실패한 실험, 반복된 예외 속에 있다. AI 전환은 결국 이 흩어진 기억을 업무가 읽을 수 있는 형태로 바꾸는 일이다. 그래서 AI 시대의 회사는 더 적은 문서가 아니라 더 좋은 문서가 필요하다. 더 많은 자동화가 아니라 더 선명한 책임 구조가 필요하다. 더 많은 도구가 아니라 더 적게 새는 주의력 구조가 필요하다. 사람들은 AI를 반대하는 게 아니다. 다만 기존 방식 안에서는 AI를 잘 쓸 수 없다. 전환은 설득으로 일어나지 않는다. 업무가 바뀔 때 일어난다. ### 메일은 표준일 때 더 오래 간다 URL: https://zerodraftlab.com/gmail-fastmail/ Last updated: 2026-07-11T12:56:01.000Z 메일은 단순한 수신함이 아니라 계정, 결제, 복구, 사업 운영이 만나는 신뢰 인프라다. Gmail을 오래 썼다. 크게 불만이 있었던 건 아니다. 빠르고, 검색 잘 되고, 스팸도 잘 잡는다. 대부분의 서비스가 Google 로그인도 지원하니 그냥 편했다. 그런데 어느 순간 Gmail 주소 하나가 너무 많은 것을 떠안고 있다는 생각이 들었다. 개인 연락, 서비스 가입, 영수증, 뉴스레터, 도메인, 서버 알림, 결제, 일정, 복구 메일이 전부 한 주소로 들어왔다. 메일함이 지저분해진 것도 문제지만, 더 신경 쓰인 건 맥락이 전부 섞인다는 점이었다. 그래서 Fastmail을 써보기로 했다. Gmail을 버리겠다는 대단한 선언은 아니다. Google 계정은 계속 쓸 것이다. 다만 개인 생활과 작은 사업 운영에서 쓰는 기본 메일은 Gmail 말고 다른 곳으로 옮겨보고 싶었다. ## 왜 Fastmail인가 Fastmail이 특별히 화려한 서비스는 아니다. 오히려 조금 평범하다. 메일, 캘린더, 연락처를 제공하고, 돈을 받는다. 광고로 돌아가는 서비스가 아니라는 점이 마음에 들었다. 그런데 제일 큰 이유는 따로 있다. 표준을 잘 지원한다는 점이다. Fastmail은 메일을 IMAP, POP, SMTP, JMAP으로 다룰 수 있고, 연락처는 CardDAV나 JMAP으로, 캘린더는 CalDAV로 접근할 수 있다. 즉 Fastmail 앱 안에서만 살아야 하는 구조가 아니다. 다른 메일 클라이언트를 붙일 수 있고, 필요하면 내가 만든 스크립트나 도구도 붙일 수 있다. 이게 나한테는 크다. 요즘 내가 원하는 건 예쁜 메일 앱 하나가 아니다. 메일, 캘린더, 연락처를 내가 쓰는 다른 도구들과 연결할 수 있는 바닥이다. 사람인 나도 읽기 쉽고, 나중에 에이전트도 읽고 처리하기 쉬운 구조가 필요하다. 메일함을 자동화한다고 할 때 제일 별로인 방식은 화면을 억지로 눌러가며 읽는 것이다. 가능하면 표준 프로토콜이나 API로 읽고, 분류하고, 필요한 것만 작업이나 일정으로 바꾸는 편이 낫다. Fastmail은 그쪽으로 생각하기가 편하다. 그 다음은 컨트롤이다. Gmail도 API가 있고 자동화가 가능하다. 하지만 Gmail을 쓰다 보면 Google 계정 전체의 일부로 생각하게 된다. Fastmail은 조금 더 단순하게 느껴진다. 메일 서비스에 돈을 내고, 내 도메인을 붙이고, 표준으로 열어두고, 필요한 클라이언트와 자동화를 내가 고르는 방식이다. 마지막으로 리더블함이다. 이건 UI가 예쁘다는 말과 조금 다르다. 메일 주소를 용도별로 나누고, alias와 Masked Email을 쓰고, 캘린더와 연락처를 표준으로 꺼낼 수 있으면 구조가 읽힌다. 이 메일이 왜 왔는지, 어느 주소로 들어왔는지, 다음에 무엇으로 바뀌어야 하는지가 더 잘 보인다. `hello@`, `receipts@`, `newsletter@`, `clients@`처럼 입구를 나눌 수 있다는 건 그래서 중요하다. 주소 나누기 자체가 목적이라기보다, 나중에 사람과 에이전트가 같이 읽을 수 있는 형태로 메일함을 만드는 일에 가깝다. ## Gmail의 문제가 아니라 기본값의 문제 Gmail이 나쁜 서비스라서 옮기는 건 아니다. 오히려 Gmail은 너무 잘 만든 서비스다. 문제는 너무 오래 기본값으로 두다 보면, 내가 메일을 어떻게 쓰고 싶은지 생각하지 않게 된다는 점이다. 예를 들어 뉴스레터 주소와 은행 주소가 같을 필요는 없다. 개인 친구에게 주는 주소와 실험용 SaaS 가입 주소도 같을 필요가 없다. 고객 문의와 쇼핑몰 영수증이 같은 입구로 들어올 필요도 없다. 그런데 Gmail 주소 하나로 오래 살면 이걸 잘 안 나누게 된다. 그냥 다 들어오게 두고, 나중에 검색하거나 보관하거나 삭제한다. 나는 그 방식을 조금 바꿔보고 싶다. 메일을 더 열심히 관리하려는 게 아니라, 애초에 들어오는 길을 나누고 싶다. 그래야 중요한 메일이 덜 묻히고, 나중에 에이전트가 읽어도 맥락을 잃지 않는다. ## 솔로프리너에게 메일은 꽤 중요하다 혼자 일하면 메일이 생각보다 많은 역할을 한다. 문의가 오고, 결제 알림이 오고, 도메인 갱신 메일이 오고, 미팅 초대가 오고, 영수증이 쌓인다. 작은 사업에서는 메일함이 거의 운영 로그처럼 된다. 그래서 메일 주소를 어떻게 나누고, 어떤 메일을 어디로 보내고, 어떤 알림을 일정이나 작업으로 바꿀지 정하는 일이 꽤 중요하다. Fastmail을 쓰면 이걸 더 잘할 수 있을 것 같다. 적어도 Gmail 하나에 전부 쌓아두는 방식보다는 내 운영 방식에 맞게 만들 여지가 커 보인다. 핵심은 표준, 컨트롤, 리더블함이다. ## 추천 링크는 아직 없다 원래는 이 글 끝에 Fastmail 추천 링크를 붙이려고 했다. Fastmail 추천 링크로 가입하면 가입자는 첫 1년 할인을 받고, 추천한 사람은 조건을 충족하면 작은 보상을 받는다. 이런 구조 자체는 괜찮다고 본다. 내가 실제로 쓰는 서비스라면 추천 링크를 붙이는 것도 이상하지 않다. 대신 고지는 분명히 해야 한다. 그런데 확인해보니 지금 내 Fastmail 계정은 아직 trial 상태라 추천 링크가 나오지 않는다. Fastmail은 유료 계정의 admin에게만 referral link를 열어준다. 그래서 이 글에는 추천 링크가 없다. 조금 김빠지는 결론이지만, 오히려 지금 올리는 게 더 낫겠다고 생각했다. 추천 링크가 생겨서 쓰는 글이 아니라, 내가 실제로 Gmail을 기본값에서 내려놓고 Fastmail을 써보려는 기록이기 때문이다. 나중에 유료 전환을 하고 추천 링크가 생기면 이 문단을 업데이트할 것이다. 지금 바로 볼 사람은 그냥 [Fastmail 공식 사이트](https://www.fastmail.com/?ref=zerodraftlab.com)에서 보면 된다. 이 링크는 추천 링크가 아니다. ## 일단 옮겨본다 아직 결론을 내릴 단계는 아니다. 써보면서 불편한 점도 나올 것이다. Gmail보다 불편한 부분도 분명 있을 것이다. 그래도 지금은 이 정도 판단이면 충분하다. 내 기본 메일 주소를 조금 더 내가 통제할 수 있는 쪽으로 옮기고 싶다. 개인 생활, 영수증, 뉴스레터, 고객 문의, 자동화용 주소를 나눠보고 싶다. 그리고 나중에 에이전트를 붙이더라도 화면 자동화가 아니라 표준으로 읽고 쓰는 쪽에 두고 싶다. 그래서 Fastmail을 써보기로 했다. 거창한 전환이라기보다, 메일함을 다시 정리해보는 작은 시작에 가깝다. ### 모임 비즈니스는 콘텐츠가 아니라 관계를 판다 URL: https://zerodraftlab.com/community-business-essence-and-current-state/ Last updated: 2026-07-11T12:56:04.000Z 모임 비즈니스의 핵심 상품은 지식이 아니라 선별된 관계, 안전감, 반복해서 만나게 만드는 운영 구조다. 모임 비즈니스는 겉으로 보면 취미, 네트워킹, 독서, 운동, 자기계발 같은 카테고리를 파는 것처럼 보인다. 하지만 실제로 사람들이 돈을 내는 이유는 조금 다르다. 사람들이 결제하는 대상은 콘텐츠 그 자체보다도, 어떤 사람들과 어떤 분위기에서 어떤 관계를 맺게 될 것인가에 더 가깝다. 다시 말해 모임 비즈니스의 본질은 지식을 전달하는 데 있지 않고, 관계를 설계하고 신뢰를 큐레이션하며 반복적으로 다시 만나게 만드는 구조를 만드는 데 있다. ## 모임 비즈니스의 핵심 상품 이 시장에서 가장 중요한 상품은 강의안도 아니고, 이벤트 한 번의 즐거움도 아니다. 핵심 상품은 세 가지다. 첫째, 이상한 사람이 걸러져 있을 것이라는 안전감이다. 둘째, 내가 혼자서는 들어가기 어려운 좋은 사람 풀에 접근할 수 있다는 희소성이다. 셋째, 그 안에서 내가 조금 더 나은 사람, 더 흥미로운 사람, 더 연결된 사람이 될 수 있다는 자기서사다. 결국 모임 비즈니스는 정보 비즈니스가 아니라 정체성과 관계의 비즈니스다. ## 지금 시장이 실제로 파는 것 최근 국내 유료 모임 서비스들을 보면 이 본질이 더 또렷해진다. 한쪽에서는 인터뷰, 가입 심사, 보증금, 운영진 개입, 멤버 주도 소모임 같은 장치를 통해 건강한 판 자체를 상품으로 만들고 있다. 다른 한쪽에서는 전문성 있는 호스트와 선명한 테마를 전면에 내세워 프리미엄을 붙인다. 전자는 멤버십과 커뮤니티 밀도로, 후자는 호스트 권위와 콘텐츠 해상도로 가격을 만든다. 방식은 달라도 공통점은 분명하다. 사람들은 더 이상 단순한 취미 활동에만 돈을 내지 않는다. 잘 설계된 관계, 의미 있는 소속감, 그리고 자기 삶에 연결되는 대화를 사기 시작했다. ## 잘 팔리는 주제의 변화 예전처럼 막연한 독서 모임, 친목 모임만으로는 약하다. 대신 창업, 브랜딩, AI, 커리어, 투자, 웰니스, 운동, 지역 기반 라이프스타일처럼 지금의 삶과 직접 맞닿아 있는 주제가 강하다. 특히 나는 어떤 사람인가를 설명해 주는 정체성 클러스터가 중요해졌다. 브랜드를 고민하는 사람, 솔로프리너, 파운더, 도시 직장인, 저속노화를 실천하는 사람, 운동과 관계를 함께 챙기려는 사람처럼 스스로를 특정 방식으로 인식하고 싶은 사람들이 모인다. 모임은 취향을 공유하는 장을 넘어, 자신이 속하고 싶은 정체성을 시험하는 무대가 됐다. ## 포맷은 왜 하이브리드로 가는가 완전 오프라인 일회성 이벤트만으로는 유지가 어렵고, 완전 온라인 커뮤니티만으로는 밀도가 약하다. 그래서 월 1회 오프라인 정기 모임, 그 사이의 온라인 채널, 번개, 챌린지, 멤버 주도 파생 소모임을 결합한 하이브리드 구조가 늘고 있다. 이는 단순히 편의성 때문이 아니라, 관계의 온도를 유지하기 위해서다. 한 번 만나고 끝나는 것이 아니라, 다음 만남을 기대하게 만들고 일상 속 접점을 계속 남겨야 재구매와 잔존이 생긴다. 결국 모임 운영은 이벤트 운영이 아니라 리듬 설계에 가깝다. ## 가격은 매출 장치이자 운영 장치다 유료 모임 시장에서 가격은 단순 매출 수단이 아니다. 보증금은 노쇼를 줄이고, 시즌제는 리듬을 만들고, 저가 단발 이벤트는 가벼운 진입점을 제공하며, 고가 클럽은 더 강한 몰입과 정체성을 판다. 즉 가격은 콘텐츠 값이 아니라 관계 밀도와 운영 강도를 반영한다. 비슷한 주제라도 누가 운영하느냐, 얼마나 선별하느냐, 얼마나 자주 다시 만나게 하느냐에 따라 전혀 다른 상품이 된다. ## 진짜 해자는 운영 체계에 있다 모임 비즈니스의 경쟁력은 생각보다 눈에 잘 보이지 않는 곳에서 생긴다. 외부에서 보기에는 모임 주제나 홍보 문구가 중요해 보이지만, 실제 해자는 운영 체계에 있다. 좋은 호스트를 어떻게 발굴하고 훈련하는지, 멤버 경험을 어떻게 관리하는지, 번개와 파생 모임이 자연스럽게 생기게 하는지, 어색함이나 불편함을 어떻게 줄이는지가 훨씬 중요하다. 결국 표면의 이벤트는 복제할 수 있어도, 신뢰가 흐르는 판은 쉽게 복제되지 않는다. ## 앞으로의 방향 지금의 모임 비즈니스는 크게 두 갈래로 진화하는 중이다. 하나는 호스트 중심의 프리미엄 지식·취향 클럽이고, 다른 하나는 멤버십 중심의 관계 인프라다. 전자는 이 사람과 이 주제로 만나고 싶다는 욕망을 공략하고, 후자는 이 동네, 이 분위기, 이 사람들 사이에 계속 있고 싶다는 욕망을 공략한다. 앞으로 더 강해질 쪽은 아마 둘 중 하나만 잘하는 곳이 아니라, 둘을 적절히 엮는 곳일 가능성이 높다. 좋은 얼굴마담 호스트로 첫 결제를 만들고, 멤버 간 연결 구조로 오래 남게 만드는 모델이다. 결국 모임 비즈니스의 본질은 사람을 모으는 데 있지 않다. 잘 맞는 사람들을, 적절한 밀도로, 반복적으로 다시 만나게 만드는 데 있다. 그리고 지금 시장은 취미를 파는 시대에서 관계 설계를 파는 시대로, 이벤트를 파는 시대에서 소속감을 파는 시대로 넘어가고 있다. 앞으로 이 시장에서 살아남는 브랜드는 무슨 모임을 여는가보다 어떤 사람이 어떤 기분으로 다시 돌아오게 만드는가를 더 잘 설계하는 곳일 것이다. ### 에이전트는 이미 잠들지 않는다 URL: https://zerodraftlab.com/agents-never-sleep/ Last updated: 2026-07-11T11:13:11.000Z 에이전트가 24시간 일을 이어받기 시작하면, 생산성의 단위는 사용 시간이 아니라 위임 가능한 작업 단위로 바뀐다. ## 1\. 문자 하나로 밤이 일한다 2026년 3월, Anthropic이 **Dispatch**를 공개했다. 동작은 단순하다. 폰에서 문자를 보낸다. 데스크톱의 Claude가 작업한다. 집에 돌아오면 보고서가 완성돼 있다. 같은 달 **Claude Code Channels**가 같이 열렸다. MCP 서버를 통해 Telegram이나 Discord에서 실행 중인 세션에 직접 메시지를 보내 작업을 지시한다. 지하철에서 노트북을 열지 않고, 외부 회의 중에 키보드에 손을 대지 않아도, 세션은 이미 돌아가고 있다. 꼬냑(@supernovajunn)의 한 줄이 가장 정확하다. > “이건 소프트웨어를 사용하는 경험이 아니다. 직원을 관리하는 경험이다. 인터페이스는 문자, 상호작용은 위임, 피드백 루프는 비동기.” “사용”에서 “위임”으로의 이동은 수사적 표현이 아니다. 작업 단위가 바뀌는 것이다. ## 2\. 숫자가 증거다 이 전환을 증명하는 데이터는 Anthropic 내부에서 이미 나왔다. 2025년 10월부터 2026년 1월 사이, Claude 최상위 0.1% 작업의 **지속 시간**이 **25분에서 45분**으로 늘었다. 3개월에 거의 두 배다. 지속 시간은 모델이 혼자 일할 수 있는 시간의 실측이다. 이 숫자가 올라간 이유는 모델이 똑똑해져서가 아니다. 혼자 있어도 망가지지 않는 **도구·컨텍스트·가드레일**의 인프라가 깔린 것이다. 모델 성능 그래프가 아니라 아키텍처 그래프가 올라갔다. 같은 흐름이 바깥쪽에서도 맞물린다. - **Anthropic Dispatch** — 백그라운드 에이전트가 기본값이 된다. - **Claude Code Channels** — 대화 채널이 에이전트의 업무 인터페이스가 된다. - **Stripe 머신 결제 프리뷰** — 에이전트가 결제 주체로 올라간다. - **x402** — HTTP 네이티브 USDC 마이크로페이먼트로 에이전트 간 B2B가 프로토콜 레이어로 내려간다. 각각의 발표가 아니라 **같은 인프라의 맞물리는 조각들**이다. 자율로 일하고, 자율로 결제하고, 자율로 커뮤니케이션할 수 있는 조건이 한 분기 안에 같이 떨어졌다. ## 3\. 요청-응답 인터페이스의 끝 이 조건이 바꾸는 것은 우리 일의 잘라내는 방식이다. 지난 20년 동안 우리는 **요청-응답** 주기에 맞춰 작업을 쪼갰다. 질문을 입력하고, 대답을 본다. 다음 질문을 입력한다. 인터페이스가 작업 모양을 결정했다. 보고서 한 건에 100번 엔터를 친 경험이 있다면, 그게 그 증거다. 비동기 위임의 세계에서는 단위가 다르다. - **요청 단위**: 30초 안에 적는 한 덩어리 작업 → 30분 안에 끝나는 한 덩어리 결과물. - **피드백 루프**: 즉시 응답 → 시간 지연 후 검토. - **선형 대화** → **분기·병렬 실행**. 이 전환을 먼저 감지한 팀은 이미 도구를 다시 고르고 있다. 꼬냑의 지난 30일 지형도가 보여주는 것은 단일 모델의 우열이 아니라, **같은 범주의 인프라가 한꺼번에 움직였다**는 사실이다. ## 4\. 관리자는 대기 시간을 어떻게 쓰는가 비동기가 되면 대기 시간이 생긴다. 직원을 관리해 본 사람은 알 것이다. 좋은 관리자는 대기 시간을 다른 작업으로 채우고, 나쁜 관리자는 결과를 기다리며 주의력을 태운다. 에이전트 관리자로 전환하는 첫 90일의 질문은 사실 이것이다. > **내가 자는 동안 돌아가는 작업 단위를 몇 개 확보했는가?** 이 질문이 답이 0이라면, 인프라는 바뀌었는데 당신은 여전히 20년 전 인터페이스에 맞춰 일하고 있다는 뜻이다. 답이 3개라면, 45분짜리 작업이 3개 병렬로 돌아간다. 답이 10개면, 당신은 팀을 운영하고 있다. ## 5\. 그래서 다음 분기 이 전환이 확정됐다는 신호는 세 가지다. 1. **지속 시간 커브가 더 가파르게 오른다.** 25 → 45의 다음 포인트가 어디일지는 알 수 없지만, 3개월에 2배가 2026년의 기본 속도라면 연말에는 “새벽 내내 혼자 일하는 작업 단위”가 상식이 된다. 2. **결제와 커뮤니케이션이 네이티브로 섞인다.** x402가 HTTP 수준에서 깔리면 “에이전트가 다른 에이전트에게 돈을 보낸다”가 구현 디테일이 된다. 사람은 그 위에서 예산을 정의하는 일만 한다. 3. **관리자 UX가 주요 시장이 된다.** Channels 류, 대시보드 류, 로그 류. 여기가 다음 SaaS 경쟁축이다. 요청-응답 인터페이스에 맞춰 잘라놓은 업무를 **비동기 위임**에 맞춰 다시 잘라야 한다. 대부분의 생산성 도구는 이 재단을 끝내지 않은 상태로 남아 있고, 그것이 이번 분기의 진짜 기회다. --- ## 참고 - @supernovajunn, Dispatch/Channels 분석 스레드 (2026-03) - Anthropic 내부 지속 시간 데이터: 2025-10 \~ 2026-01 최상위 0.1% 25 → 45분 - Stripe 머신 결제 프리뷰 공지 (2026-03) - x402 프로토콜 문서 (USDC 마이크로페이먼트 over HTTP) - 관련 주제: 오케스트레이션 — Claude Octopus 75% 합의 게이트, Awesome Codex Subagents 136개 컬렉션, Leanstral의 생성+증명 파이프라인