한 잠재 고객이 나의 아웃리치(outreach)에 대해 모든 서비스 기업이 두려워하면서도 동시에 갈망하는 문장으로 답했습니다: "무언가 보내주시면 검토해 보겠습니다." 예전의 나는 그 답장에 저녁 시간을 통째로 쓰곤 했습니다. 범위(scope), 일정(timeline), 과거 작업 스크린샷, 가격이 담긴 PDF 파일 말이죠. 괜찮은 방식이었습니다. 하지만 결국 깨달은 점은, 그것이 나의 다섯 명의 경쟁자가 동일한 문장에 대응하여 보낼 내용과 전혀 구별되지 않는다는 것이었습니다. 모두의 PDF는 유능해 보였습니다. 하지만 유능함은 더 이상 승리를 가져다주지 않습니다. 왜냐하면 유능함은 이제 경쟁자가 우연히 열어본 어떤 모델(model)이든 즉각적으로 무료로 내놓는 결과물이 되었기 때문입니다.

이것이 바로 명명할 가치가 있는 실제적인 변화입니다. 과거에 제안서(Proposals)는 비용이 드는 신호(costly signal)였습니다. 문서 하나를 만드는 데 밤을 지새우는 것은 당신이 진지하다는 것을 증명했습니다. 이제 그 비용은 모두에게 거의 제로(zero)로 수렴했습니다. 즉, 잘 작성된 제안서는 당신 또한 언어 모델(language model)을 사용할 수 있다는 사실 외에는 아무것도 증명하지 못한다는 뜻입니다. 당신을 다른 이들과 구별해 주는 유일한 것은, 그들에게 특화되어 당신이 실제로 이미 수행한 작업이 포함된 제안서뿐입니다.

그래서 나는 대신 이것을 보내기 시작했습니다: 제안서를 대체하는 대신, 단 한 페이지짜리 제안서에 첨부된, 오직 그 잠재 고객만을 위해 만들어진 작고 실제적인 작동 데모(demo)입니다.

이것이 갑자기 저렴해진 이유

이 전략은 에이전트(agents)가 등장하기 전에도 존재했습니다. 유능한 영업 사원들은 항상 말하는 것보다 보여주는 것이 낫다는 것을 알고 있었습니다. 변한 것은 경제성(economics)입니다. 과거에 맞춤형 데모(custom demo)를 만든다는 것은 모든 잠재 고객(warm lead)에게 할애할 수 없는 개발자의 며칠간의 시간을 의미했기에, 가장 큰 거래에만 제한적으로 사용했습니다. 하지만 코딩 에이전트(coding agent)는 "이 특정 잠재 고객의 실제 페이지나 데이터를 바탕으로 얇고 실제적인 프로토타입(prototype)을 구축하라"는 작업을 에이전트의 몇 시간과 아마도 한 시간 정도의 내 검토 시간으로 바꿔 놓았습니다. 이는 일상적으로 수행하기에 충분히 저렴하지만, 공짜는 아닙니다. 이것이 공짜인 척하는 것이 바로 영업 노력으로 위장된 무보수 고객 작업을 하게 되는 정확한 방식입니다. 이에 대해서는 아래에서 더 자세히 다루겠습니다.

며칠이 아닌 몇 시간 안에 범위를 정하기

플레이북(playbook)에는 특정한 순서가 있으며, 단계를 건너뛰는 것이 바로 문제가 발생하는 지점입니다.

첫째, 브라우저 에이전트(browser agent)가 잠재 고객의 공개된 표면(public surface)—상점, 제품 페이지, 콘텐츠 주기(content cadence), 리뷰 등 귀하의 서비스가 실제로 접하는 모든 것—을 감사(audit)하고 결과 목록(findings list)을 생성합니다. 모호한 관찰이 아닙니다. 구체적이고 검증 가능한 내용이어야 합니다: "제품 페이지에 FAQ 섹션이 없습니다", "가장 반복되는 리뷰 불만 사항은 배송 시간에 관한 것이며 이에 대한 응답이 없습니다"와 같이, 추측이 아닌 스크린샷이나 인용문이 첨부된 형태여야 합니다.

둘째, 해당 결과 목록으로부터 에이전트 작업 시간 기준 약 4시간 내에 구축 가능한 단 하나의 데모 범위를 정합니다. 이 데모는 잠재 고객의 실제 제품, 실제 카피(copy), 실제 데이터를 사용하여 앞서 발견된 문제 중 두세 가지를 실체화(tangible)해야 합니다. 단순히 그들의 로고만 붙여놓은 일반적인 템플릿이 아닙니다. 그들의 실제 페이지를 재설계한 목업(mockup), 그들의 공개 수치를 기반으로 작동하는 프로토타입 대시보드(prototype dashboard), 혹은 그들의 실제 콘텐츠로 만든 샘플 결과물이어야 합니다. 이러한 구체성이 핵심입니다. 일반적인 데모는 그저 더 화려한 PDF일 뿐입니다.

셋째, 데모가 설득 역할을 수행하므로 제안서 자체는 짧아집니다: 그들의 수치로 명시된 문제점, 데모 링크, 범위(scope), 일정(timeline), 가격, 그리고 프로젝트가 실제로 어떻게 운영될지에 대한 한 단락의 설명만 포함합니다. 다섯 페이지가 아닌 단 한 페이지면 충분합니다.

이 방식을 사용하지 말아야 할 때

이 방식은 거래 규모가 일정 임계값(threshold) 이상일 때만 의미가 있습니다. 시간이 저렴하더라도 그 시간은 공짜가 아니기 때문입니다. 저의 기준은 에이전트 및 검토 비용의 대략 20~50배입니다. 이보다 낮은 경우에는 잘 만들어진 템플릿 기반의 제안서(proposal)가 적절한 도구이며, 작은 거래를 위해 데모를 만드는 것은 적절한 성사율(close rate)을 기록하더라도 비용을 회수하지 못하는 값비싼 연극에 불과합니다. 또한, 데모가 인상적이기보다는 주제넘게 느껴지는 잠재 고객(prospect) 유형도 있습니다. 먼저 묻지도 않고 누군가의 브랜드와 제품을 모형으로 만드는 것은 상황을 악화시킬 수 있으며, 특히 초대받지 않은 상태에서 "웹사이트를 다시 만들어 왔습니다"라고 나타나는 것은 도움이 되기보다는 선을 넘는 행동으로 비춰질 수 있습니다. 그래서 저는 이제 무엇인가를 만들기 전에 첫 번째 답장에서 가벼운 허락을 구하는 질문을 던집니다. 예를 들어 "귀하의 실제 페이지로 무언가를 만들어 봐도 괜찮을까요?"와 같은 질문입니다. 이는 비용이 들지 않으면서도, 답변 자체가 유용한 구매 의도 신호(buying-intent signal)가 됩니다. 열정적인 '예', 미온적인 '예', 혹은 침묵 모두 에이전트 작업 시간을 단 1시간도 쓰기 전에 무언가를 알려줍니다.

잠재 고객: [회사/URL]. 서비스: [판매 제품]. 1단계: 고객의 [상점/사이트/콘텐츠]를 감사(audit)하고 증거(각각 스크린샷/인용구/URL 포함 — 추측 금지)와 함께 구체적이고 검증 가능한 5~8개의 발견 사항을 나열합니다.
...

잘못되는 지점

발견 사항 목록은 잠재 고객의 주의가 집중되는 첫 10초 동안 신뢰가 쌓이거나 파괴되는 지점이며, 또한 에이전트의 자신감이 정확성을 가장 빠르게 앞지르는 지점이기도 합니다. 초기에 수행한 한 감사(audit)에서는 잠재 고객의 사이트에 "이메일 수집(email capture) 기능이 없다"라고 자신 있게 보고했습니다. 하지만 수집 양식은 실제로 존재했으며, 에이전트의 브라우징 세션이 확인하기도 전에 이미 닫아버린 팝업창 뒤에 숨겨져 있었습니다. 그러한 주장을 실제 잠재 고객에게 보냈다면 이는 사소한 부정확함이 아니라 즉각적인 신뢰 상실로 이어졌을 것입니다.

내가 빠졌던 함정: 이제 감사 (audit)의 모든 결과에는 스크린샷, 정확한 인용구, URL과 같은 증거가 반드시 첨부되어야 합니다. 그리고 저는 이 내용이 잠재 고객에게 전달되기 전에 직접 하나하나 검증합니다. 누군가의 비즈니스에 대해 확신에 차서 내뱉은 단 하나의 잘못된 주장이, 데모가 구축하려 했던 모든 신뢰를 무너뜨릴 수 있기 때문입니다.

두 번째 실패는 범위 확장 (scope creep)입니다. 이는 그 순간에는 관대함처럼 느껴지기 때문에 더 교묘한 함정이 됩니다. 명확한 중단 지점 없이 제작된 저의 두 번째 데모는, 계약이 체결되기도 전에 실제 제안된 프로젝트의 약 60%에 달하는 수준으로 조용히 변질되었습니다. 해결책은 의지력이 아니라 기계적인 제약이었습니다. 제작 시간을 4시간으로 제한하고, 프롬프트 (prompt) 자체에 다음과 같은 프레임을 반복하여 설정했습니다. "역량을 증명하되, 가치 (value)를 전달하지 마라." 데모의 역할은 잠재 고객이 당신이 그 일을 할 수 있다고 믿게 만드는 것입니다. 데모 자체가 그 일이 되어서는 안 됩니다.

저는 여전히 모든 내용이 발송되기 전에 검토합니다. 특히 결과 목록 (findings list)을 주의 깊게 보는데, 에이전트 (agent)가 낯선 이의 비즈니스에 대해 잘못된 주장을 하는 것은 복구할 방법이 없는 유일한 실패 모드 (failure mode)이기 때문입니다. 또한 발송 과정의 어떤 부분도 방치된 채로 실행되게 두지 않고 제가 직접 발송합니다. 계약의 성사 여부와 관계없이, 결과는 제가 사용하는 다른 모든 것과 동일한 후속 추적 (follow-up tracking) 시스템에 기록되며, 저는 무엇이 실제로 결정을 내렸는지 직접 묻습니다. 그 답변은 다음 결과 목록과 다음 데모 범위로 피드백되어, 이 과정이 단순히 한 번 해본 멋진 기술로 남지 않고 계속해서 개선될 수 있게 만드는 유일한 동력이 됩니다.

영향: 데모 기반의 제안서는 에이전트가 소요한 시간 외에 제가 직접 검토하고 맞춤화하는 데 약 1시간이 추가로 들지만, 텍스트로만 구성된 취약한 버전이 저녁 전체를 소요하는 것에 비하면 효율적입니다. 또한 소규모의 정직한 샘플을 기준으로 했을 때, 데모 기반 제안서의 계약 성사율 (close rate)은 텍스트 전용 제안서보다 대략 두 배 높습니다. 1인 기업에게 이는 분기당 단 한 번의 추가적인 승리만으로도 분기 전체의 형국을 바꿀 수 있음을 의미합니다.

이 근저에 깔린 논리는 단순한 판매를 넘어 일반화될 수 있으며, 다음과 같이 명확히 말할 가치가 있습니다. 진지함을 증명하기 위해 통상적으로 제작하던 결과물(artifact)을 누구나 저렴하게 가짜로 만들어낼 수 있게 된 시점에는, 저렴하게 조작할 수 없는 증거만이 유일하게 남은 신호(signal)가 됩니다. 즉, 실제로 사실이기 때문에 작동하는 무언가 말입니다. 누군가의 실제 데이터 위에서 실행되는 데모(demo)는 해당 범주에 속하는 몇 안 되는 것 중 하나입니다.

원문 게시 위치: https://methezone.github.io/solo-operator-playbook/working-demo-proposals.html

30개의 모든 워크플로우(workflows)는 프롬프트(prompts) 및 실패 사례와 함께 작성되었습니다. 이 중 5개는 전체 내용을 무료로 제공합니다: the sampler.