검증 도구를 팔아보려다 알게 된 것

BUSINESS EXPERIMENTS · AUGUST–SEPTEMBER 2026 · MARKET TEST · CONTRACTS 0

내가 팔아보려던 것은 ‘증명’이 아니었다

제안의 범위는 새로운 정리를 만들거나 기존 증명을 심사하는 일이 아니었다. 공개 예제나 전달받은 검증 산출물을 정해진 환경에서 다시 실행하고, 버전과 실행 결과를 확인할 수 있는 짧은 기록을 남기는 일이었다. handoff 뒤에 “내 컴퓨터에서도 같은 결과가 났는가”를 확인하는 운영 서비스에 가까웠다.

release gate는 같은 문제를 배포 시점에 놓았다. 제품팀이 릴리스를 확정하기 전에 독립된 외부 검토 단계를 두자는 제안이었다. 두 이름을 따로 붙였지만 시장에 던진 질문은 하나였다. 조직이 외부의 재실행과 판정에 비용을 낼까.

답신은 네 가지 다른 문제를 보여줬다

날짜	제안	마지막 확인 상태
2026-08-31	독립 release gate	내부 검토 뒤 진행하지 않음
2026-09-01	Lean handoff 독립 검증	검토 후 답변 예정
2026-09-02	공개 Lean 예제 replay receipt	기존 공개 로드맵에 집중
2026-09-02	상용 형식검증 도구 replay receipt	제품에 유사 기능이 이미 있음

‘로드맵에 집중한다’는 답은 문제가 없다는 뜻이 아니었다. 그 조직이 지금 외부 서비스에 시간을 쓰지 않겠다는 뜻이었다. ‘이미 유사 기능이 있다’는 답은 더 직접적이었다. 제안을 보내기 전에 제품의 기존 기능을 충분히 조사하지 못했다. 구현 능력보다 먼저 확인했어야 할 부분이었다.

내부 검토 뒤 진행하지 않겠다는 판정은 release gate의 수요를 확인해 주지 못했다. 검토 중이라는 답도 계약이나 구매 의향으로 세지 않았다. 답장이 왔다는 사실은 전달 성공의 증거일 뿐, 시장 검증이 아니다.

같은 ‘아니오’로 묶으면 다음 행동을 고를 수 없다

네 결과를 한 줄짜리 거절률로 합치면 중요한 차이가 사라진다. 기존 기능과 겹친다면 제품 조사가 먼저다. 로드맵 밖이라면 지금의 구매자를 바꿔야 한다. 내부 검토 뒤 거절됐다면 제안의 위험과 비용을 다시 봐야 한다. 답변 대기라면 정해 둔 시점까지 기다린 뒤 종료 여부를 판단하면 된다.

이 구분을 하고 나니 다음 제품을 곧바로 만드는 대신 제안을 중단할 기준이 생겼다. 비슷한 기능이 이미 존재하거나, 실제 릴리스 과정에서 외부 검증에 예산을 쓰는 담당자를 찾지 못하면 구현으로 넘어가지 않는다.

답신 네 건은 고객 네 명이 아니었다. 제품 중복 한 건, 우선순위 불일치 한 건, 거절 한 건, 아직 끝나지 않은 검토 한 건이었다.

확인된 결과

외부로 보낸 제안과 여러 답신이 있었고, 한 제안은 기존 제품 기능과 겹친다는 사실을 확인했다. 다른 제안들은 조직의 현재 우선순위와 맞지 않거나 진행되지 않았다. 2026년 9월 3일 현재 한 건은 검토 중이었고, 계약과 매출은 0이었다.

따라서 이 기록은 형식검증 서비스가 필요 없다는 결론도, 수요가 있다는 결론도 아니다. 확인된 범위는 내가 보낸 두 형태의 제안이 계약으로 이어지지 않았다는 데까지다. 다음 시험이 있다면 제안서를 쓰기 전에 기존 기능과 실제 구매 책임자를 먼저 확인한다.

---

Project record
기간: 2026년 8월 31일–9월 3일
역할: replay-receipt·release-gate 제안 설계, 외부 문의, 응답 분류와 중단 기준 정리
외부 확인: 네 조직의 응답 또는 상태 사건
마지막 상태: 세 제안 종료, 한 제안 검토 중
확인되지 않은 것: 유료 수요, 계약, 사용, 매출 또는 형식검증 품질 향상
공개하지 않은 것: 조직·담당자 식별정보, 메일 본문과 주소

Read this project in English