AI는 구축 속도를 극적으로 높여주었습니다. 하지만 구매를 자동으로 만들어주지는 않았습니다.

이러한 차이는 1인 개발자들이 흔히 빠지는 함정을 설명해 줍니다. 앱은 작동하고, 인터페이스는 신뢰할 수 있어 보이며, 또 다른 개선 단계가 이미 계획되어 있지만—정작 아무도 결제하지 않는 상황 말입니다. 이에 대한 자연스러운 반응은 기능을 추가하거나, 랜딩 페이지를 다듬거나, 가격을 낮추는 것입니다. 이러한 행동들은 개발자의 편안한 영역(comfort zone) 안에 머물기 때문에 생산적인 것처럼 느껴집니다. 하지만 이는 원래의 실수를 심화시킬 수도 있습니다.

부족한 증거는 더 많은 코드가 아닙니다. 그것은 특정 문제를 가진 구매자, 행동할 만큼 충분한 긴급성, 그리고 테스트를 위해 비용을 지불할 가치가 있는 작은 결과물입니다.

'유료 파일럿 우선 (paid-pilot-first)' 계획은 일반적인 순서를 뒤집습니다. 완전한 제품을 만든 다음 수요를 찾는 것이 아닙니다. 비용이 많이 드는 워크플로우 (workflow) 하나를 식별하고, 이를 경험하는 사람들과 대화하며, 좁은 범위의 유료 참여를 제안하고, 약속된 결과를 전달하는 데 필요한 엔드 투 엔드 (end-to-end) 조각만을 구축하는 것입니다. 목표는 72시간 안에 하이프 (hype)를 제조하는 것이 아닙니다. 가설을 점진적으로 더 강력한 증거로 대체하는 것입니다.

1. 앱을 제안(offer)으로 취급하는 것을 멈추세요

구매자들이 새로운 AI 앱을 원하며 잠에서 깨어나는 경우는 드뭅니다. 그들은 기존의 작업이 더 빨라지거나, 더 안전해지거나, 비용이 덜 들거나, 혹은 검증하기 쉬워지기를 원합니다.

"AI 회의 어시스턴트"는 카테고리를 설명합니다. "고객 성공 (customer-success) 통화를 어카운트 매니저의 다음 회의 전까지 검토된 후속 초안으로 변환해 드립니다"는 결과를 설명합니다. 두 번째 문장은 구매자에게 평가할 수 있는 구체적인 무언가를 제공합니다.

더 많은 코드를 작성하기 전에, 한 문장으로 된 제안을 작성해 보세요:

**[관찰 가능한 워크플로우 (observable workflow)]**로 어려움을 겪는 **[특정 구매자 (specific buyer)]**를 위해, 저는 **[합의된 데이터 (agreed data)]**만을 사용하여 [짧은 기간 (short period)] 내에 **[제한된 결과 (bounded result)]**를 **[고정된 파일럿 가격 (fixed pilot price)]**으로 제공하겠습니다.

모든 대괄호가 중요합니다. "소규모 비즈니스"는 특정 구매자가 아닙니다. "시간 절약"은 관찰 가능한 결과가 아닙니다. "AI 기반 (AI-powered)"은 무엇이 전달될지에 대해 아무것도 말해주지 않습니다. 만약 이 문장이 여전히 모호하다면, 제품은 여전히 구매 결정이 아닌 기술을 중심으로 설계되고 있는 것입니다.

2. 테스트할 준비가 되었는지 결정하기 위해 PACT를 사용하세요

이 책의 PACT 스크리닝은 기능 목록(feature list)이 상업적 증거를 대신하는 것을 방지합니다.

• Pain (고통): 특정 실패가 시간, 비용, 리스크 또는 신뢰도를 소모합니다.
• Access (접근성): 이를 경험하는 사람을 최소 20명 이상 식별하고 연락할 수 있습니다.
• Clarity (명확성): 전후 상태(before-and-after state)가 며칠 이내에 관찰 가능합니다.
• Trust (신뢰): 첫 번째 버전이 위험한 권한이나 숨겨진 데이터 사용 없이 작동할 수 있습니다.

고객 지원 대화를 요약하는 AI 도구를 만들었다고 가정해 봅시다. "고객 지원 팀에 티켓이 너무 많다"는 너무 모호합니다. 더 강력한 사례는 갱신(renewal) 통화 전에 해결되지 않은 약속 사항을 수동으로 재구성해야 하는 고객 성공 매니저(customer-success manager)입니다. 누락된 약속이 고통(Pain)이며, 연락 가능한 역할과 고객 명단이 접근성(Access)을 제공합니다. 검토된 갱신 브리프(renewal brief)는 눈에 보이는 전후 결과(Clarity)를 만들어내며, 합의된 소스 자료로만 만들어져 사람이 승인한 초안은 첫 번째 버전을 방어 가능한 신뢰 경계(trust boundary) 내에 유지합니다(Trust).

PACT가 수요를 증명하는 것은 아닙니다. PACT는 가설이 테스트할 수 있을 만큼 구체적이고 도달 가능한지를 알려줍니다. 만약 고통(Pain)이 약하다면, 더 비용이 많이 드는 실패를 찾으세요. 만약 접근성(Access)이 부족하다면, 세그먼트(segment)나 채널을 변경하세요. 만약 명확성(Clarity)이 부족하다면, 결과의 범위를 좁히세요. 만약 신뢰(Trust)가 약하다면, 권한을 제거하고 데이터를 제한하며, 진행하기 전에 사람의 검토(human review)를 추가하세요.

3. 칭찬이 아니라 과거의 행동을 인터뷰하세요

"이것을 사용하시겠습니까?"라는 질문은 예의 바른 답변을 유도합니다. 대신 마지막으로 실제로 발생했던 상황을 조사하세요:

1. "이 일이 마지막으로 발생했을 때의 과정을 설명해 주세요."
2. "처음부터 끝까지 무엇을 하셨나요?"
3. "어느 부분에서 가장 많은 확인이나 재작업(rework)이 필요했나요?"
4. "만약 결과가 늦어지거나 틀리면 어떻게 되나요?"
5. "변경 사항이나 구매를 승인하는 사람은 누구인가요?"
6. "외부 도구가 사용할 수 있는 데이터는 무엇이며, 무엇이 접근 금지 상태로 유지되어야 합니까?"
7. "이전에 임시방편(workaround), 계약직, 또는 도구에 비용을 지불한 적이 있습니까?"

산출물(artifacts)에 귀를 기울이세요: 스프레드시트(spreadsheets), 복사된 이메일, 스크린샷, 체크리스트, 인수인계(handoffs), 반복적인 회의, 그리고 승인 단계 등이 이에 해당합니다. 이러한 것들은 실제 워크플로우(workflow)를 드러내며, 일반적인 데모가 어디에서 실패할지를 보여줍니다. 칭찬이 아니라 행동의 증거를 찾으세요. 이미 할당된 시간, 기존 예산, 수동 임시방편(manual workaround), 마감 기한, 또는 적극적으로 탐색 중인 담당자(owner)와 같은 증거를 찾아야 합니다.

다음 단계에 대한 테스트로 마무리하세요: “짧은 유료 파일럿(paid pilot) 기간 동안, 정의된 하나의 입력값(input)으로부터 검토된 하나의 출력값(output)을 제공할 수 있습니다. 고정된 범위(scope)와 가격을 검토해 보는 것이 도움이 될까요?” ‘아니오’라는 답변도 그 이유를 기록한다면 유용합니다. 이는 잘못된 가정(false assumption)을 바탕으로 한 달 치의 개발을 더 진행하는 것보다 비용이 적게 듭니다.

4. 미완성된 SaaS 구독이 아닌, 범위가 제한된 유료 파일럿을 판매하세요

유료 파일럿(paid pilot)은 하나의 실제 질문에 답하기 위해 설계된 작은 상업적 계약입니다: '이 워크플로우가 명시적인 제약 조건 하에서 이 구매자에게 유용한 결과를 만들어낼 수 있는가?'

한 명의 구매자와 유스케이스(use case), 하나의 입력-출력 워크플로우(input-to-output workflow), 짧은 기간, 고정된 가격 및 결제 시점, 정확한 인도물(deliverable), 수락 기준(acceptance criteria), 구매자의 책임, 데이터 처리 및 삭제 규칙, 지원 및 수정 제한, 그리고 중단 옵션을 포함하여 파일럿 종료 후의 상황을 명시하세요.

결제는 증거를 강화합니다. 무료 사용자는 불분명한 워크플로우를 참거나, 온보딩(onboarding)을 건너뛰고 사라질 수 있습니다. 하지만 비용을 지불하는 파일럿 구매자는 실제적인 트레이드오프(tradeoff)를 수행한 것이며, 약속된 결과를 더 주의 깊게 평가할 가능성이 높습니다.

그렇다고 해서 임의적인 가격 책정이나 희소성 연출(scarcity theater)이 정당화되는 것은 아닙니다. 가격을 좁은 범위(scope), 여전히 요구되는 수동 작업, 그리고 결과의 가치에 맞추세요. 구매자가 반대한다면, 자동으로 가격을 낮추기 전에 범위를 먼저 줄이십시오. 신뢰할 수 있게 제공할 수 없는 대규모 할인 약속보다는, 작더라도 신뢰할 수 있는 약속이 더 낫습니다.

엄격한 매출 게이트(revenue gate)를 적용하세요: 결제가 완료되고 구매자가 약관을 수령한 후에만 매출로 집계하십시오. 구두상의 승인, 결제 링크 전송, 제안서 열람, 결제 완료는 모두 서로 다른 상태입니다.

5. 실제 입력부터 수락된 결과까지 하나의 버티컬 슬라이스(vertical slice)를 구축하세요

파일럿 약속(pilot commitment)을 받은 후에는 제품 전체를 다시 구축하려는 유혹을 뿌리치세요. 대신 하나의 버티컬 슬라이스(vertical slice)를 구축하십시오. 즉, 구매자의 결과물을 위해 필요한 모든 레이어를 통과하는 하나의 실제 입력을 만드는 것입니다.

이 책에서 제시하는 슬라이스는 액세스 제어 (access control) → 입력 검증 (input validation) → 모델 상호작용 (model interaction) → 출력 검증 (output validation) → 인간의 검토 (human review) → 영속성 (persistence) → 오류 복구 (error recovery) 과정을 가로지릅니다. InquiryBrief의 예시를 들면, 유용한 경로는 간단합니다. 문의 사항을 붙여넣고, 구조화된 브리프(brief)를 생성하며, 이를 검토 및 편집한 다음, 승인된 브리프를 저장하는 것입니다. 그 경로는 좁지만 실제적입니다. 이는 완벽한 프롬프트(prompt)에 연결된 화면보다 훨씬 더 많은 것을 테스트합니다.

데모(demo)는 샘플 데이터 뒤에 숨을 수 있습니다. 하지만 버티컬 슬라이스는 구매자가 허용한 입력을 견뎌내고, 그들이 수락하거나 거부할 수 있는 결과물에 도달해야 합니다. 수동 단계(manual steps)는 공개될 경우 허용됩니다. 즉, 모든 출력을 직접 검토하거나, 계정을 수동으로 설정하거나, 최종 파일을 수동으로 전송할 수 있습니다. 인간의 지원을 받는 파일럿을 완전히 자율적인 소프트웨어인 것처럼 제시하지 마십시오. 수동 작업은 자동화가 가치 있는 지점이 어디인지 밝혀내는 데 도움이 되지만, 숨겨진 수동 작업은 잘못된 기대를 심어줍니다.

6. 전달하기 전에 품질 경계(quality boundary)와 데이터 경계(data boundary)를 정의하세요

AI 출력물은 틀렸을 때조차 그럴듯해 보일 수 있습니다. “무언가를 생성했다”는 것만으로는 수락 테스트(acceptance test)가 될 수 없습니다.

**품질 경계 (quality boundary)**는 전달 전에 반드시 충족되어야 하는 사항을 명시합니다: 필수 필드가 존재해야 함; 소스(source)와 연결된 주장이 제공된 자료를 추적할 수 있어야 함; 근거 없는 주장은 플래그(flag)가 지정되어야 함; 합계, 날짜, 이름 또는 식별자가 결정론적 검사(deterministic checks)를 통과해야 함; 인간이 최종 버전을 승인해야 함; 그리고 실패 시 침묵 속에서 추측하는 대신 명확한 중단 상태(stop state)를 생성해야 함.

**데이터 경계 (data boundary)**는 파일럿이 접할 수 있는 범위를 명시합니다: 허용된 소스, 민감한 필드, 저장 위치, 보관 기간, 삭제 프로세스, 제3자 서비스 및 승인된 액세스 권한. 만약 운영 데이터(production data)를 사용하는 것이 부적절하다면, 비식별화된 데이터(redacted data)나 합성 데이터(synthetic data)를 사용하고, 그로 인해 파일럿이 증명하지 못하는 부분이 무엇인지 명시하십시오.

이러한 경계가 40페이지짜리 보안 문서가 될 필요는 없습니다. 다만 그 주장이 정직해야 합니다. 합성 데이터(synthetic data)를 사용한 파일럿은 워크플로우의 적합성(workflow fit)은 증명할 수 있지만, 운영 준비성(production readiness)을 증명할 수는 없습니다. 사람이 검토한 결과는 유용성(usefulness)은 증명할 수 있지만, 안전한 무인 자동화(safe unattended automation)를 증명할 수는 없습니다. 증거의 범위가 증거 자체보다 크지 않을 때 신뢰가 쌓입니다.

7. 정직한 장부를 유지하십시오

활동량은 세기 쉽습니다. 게시물, 메시지, 데모, 또는 "흥미롭네요"라고 말한 사람들의 수 같은 것들 말입니다. 정직한 장부는 중요한 상태 변화(state changes)를 기록합니다.

잠재 고객(lead)을 조용히 부풀리지 마십시오. "관심 있음"은 "제안됨"이 아닙니다. "제안됨"은 "결제됨"이 아닙니다. "전달됨"은 "수락됨"이 아닙니다. 이러한 구분은 무엇을 수정해야 하는지 알려줍니다. 제안이 없는 인터뷰는 약한 포지셔닝(positioning)이나 요청을 주저하는 태도를 드러낼 수 있습니다. 결제가 없는 제안은 긴급성, 권한, 가격 또는 신뢰의 문제를 나타냅니다. 결제 후 전달이 거부되는 것은 품질 경계(quality boundary)나 수락 기준(acceptance criteria)의 문제를 나타냅니다.

각 사이클이 끝날 때 다섯 줄을 작성하십시오: 무엇을 약속했는지, 무엇을 결제했는지, 무엇을 전달했는지, 무엇을 배웠는지, 그리고 다음에 무엇을 이행해야 하는지. 그것이 정직한 상업적 기록이지, 동기 부여용 대시보드가 아닙니다.

8. 실질적인 72시간 시퀀스

72시간은 의사결정의 창(decision window)이지, 수익을 보장하는 시간이 아닙니다. 이를 증거를 만들어내는 행동을 강제하는 데 사용하십시오.

0~8시간: 하나의 케이스를 선택하십시오

하나의 PACT 스크린을 완료하십시오. 연락 가능한 구매자 한 명, 반복되는 워크플로우 하나, 그리고 트리거(trigger) 하나를 선택하십시오. 한 문장으로 된 제안(offer)을 작성하십시오. 제한된 결과(bounded result)를 위해 필요하지 않은 모든 기능은 제거하십시오.

8~24시간: 구매자 증거를 수집하십시오

작고 관련성 있는 연락처 목록을 만들고 짧은 대화를 나누십시오. 과거의 행동과 제약 사항에 대해 물어보십시오. 배운 내용을 바탕으로 PACT를 업데이트하십시오. 대량의 아웃리치(outreach)를 자동화하거나 관계를 허위로 꾸며내지 마십시오.

24~36시간: 유료 파일럿 제안을 하십시오

산출물(deliverable), 일정(timing), 고정 가격(fixed price), 수락 기준(acceptance criteria), 데이터 경계(data boundary), 그리고 중단 조건(stop condition)이 포함된 짧은 범위(scope)를 전달하십시오. 정당한 결제 또는 인보이스(invoicing) 경로를 제공하십시오. 실제 상태를 원장(ledger)에 기록하십시오.

36~60시간: 수직적 슬라이스 (vertical slice)를 구축하거나 조정하십시오

실제적인 약속(commitment)이 이루어진 후에만, 가장 작은 규모의 엔드 투 엔드(end-to-end) 워크플로우를 구현하십시오. 허용된 데이터로 이를 테스트하고, 품질 경계(quality boundary)에서 요구되는 체크 사항을 추가하며, 자동화가 아직 신뢰할 수 없는 곳에는 인간의 검토(human review)를 유지하십시오.

60~72시간: 증거를 전달하고 결정하십시오

합의된 결과물(artifact)을 전달하고, 수락 또는 거절을 수집하며, 발생한 일을 기록하십시오. 그런 다음 하나의 정직한 결과 중 하나를 선택하십시오:

• 계속 (Continue): 구매자가 결제했고, 결과를 수락했으며, 신뢰할 수 있는 다음 사용 사례가 있는 경우.
• 수정 (Revise): 문제는 실재하지만, 범위(scope), 품질, 또는 전달 방식에 제한적인 수정이 필요한 경우.
• 중단 또는 재포지셔닝 (Stop or reposition): 긴급성, 권한, 접근성, 또는 지불 의사가 없는 경우.

세 가지 결과 모두 유용합니다. 오직 하나만이 매출(revenue)입니다.

진짜 해결책은 증거의 순서를 바꾸는 것입니다

'유료 파일럿 우선' 접근 방식은 제품 리스크(product risk)를 제거하지 않습니다. 다만, 더 많은 기능 뒤로 그 리스크를 숨기는 것을 방지해 줍니다.

구매자의 실제 워크플로우(workflow)에서 시작하십시오. 고통(Pain), 접근성(Access), 명확성(Clarity), 그리고 신뢰(Trust)로 이를 스크리닝하십시오. 과거 행동에 대해 인터뷰하십시오. 제한적인 유료 약속(paid commitment)을 요청하십시오. 하나의 정직한 수직적 슬라이스(vertical slice)를 구축하십시오. 품질 및 데이터 경계를 명시하십시오. 모든 상업적 상태를 부풀림 없이 기록하십시오.

여전히 거절을 들을 수도 있습니다. 트리거(trigger)가 약하거나, 구매자에게 권한이 없거나, 데이터를 사용할 수 없거나, 결과가 충분히 가치 있지 않다는 것을 배우게 될 수도 있습니다. 그것은 또 다른 과잉 구축(overbuilding) 사이클을 돌기 전에 획득한 증거입니다.

목표는 단순히 더 빠르게 출시하는 것이 아닙니다. 구축하는 매 시간이 구매와 관련된 질문에 답할 수 있도록 만드는 것입니다.

전체 72시간 현장 가이드(field guide)를 원하시나요?

_Get Paid Before You Overbuild_는 이 프레임워크를 구매자 인터뷰 스크립트, 1페이지 분량의 오퍼 (offer) 템플릿, 유료 파일럿 약관, AI 품질 및 데이터 경계 (data-boundary) 체크리스트, 완전한 72시간 운영 일정, 그리고 실질적인 수익 및 인도 (delivery) 워크시트가 포함된 전문적으로 설계된 97페이지 분량의 영어 가이드로 확장합니다.

Evidence Gate Studio에서 19달러에 가이드 받기

제목은 순차적 방법론 (sequencing method)을 설명하는 것이며, 수익을 보장하는 것은 아닙니다. 결과는 구매자 접근성, 적합성 (fit), 신뢰, 가격 책정, 인도 (delivery) 및 기타 요인에 따라 달라집니다.