사용자가 구매자가 아닐 때 어떻게 판매할 것인가

• ‘사용자는 제품을 쓰지만 결제 권한자는 아닌’ 상황에서 핵심은 누가 실제 권한과 영향력을 갖고 있는지 파악하는 것
• 실제 권한을 가진 의사결정자가 반드시 구매자나 최초 사용자와 동일 인물이 아닐수 있음
• 소규모 조직에서는 시간 절감이 중요하므로 개발자가 직접 도구를 도입하고 상부 설득으로 구매로 이어질 가능성이 큼
• 대규모 조직에서는 보안·절차 제약이 강해 구매 결정권이 CTO나 경영진에 있으며, 긴 영업 사이클이 필요함
• 구매 권한자는 반드시 예산 보유자와 일치하지 않으며, 제품 가치를 가장 크게 느끼고 추진할 수 있는 사람이 핵심 타깃이 됨
• 효과적인 전략은 사용자가 경영진을 설득할 수 있도록 구체적 데이터와 설득 자료를 제공하고, 그 과정을 지원하는 것
• 최종적 성공은 사용자가 내부 세일즈 역할을 할 수 있도록 뒷받침하는 프로세스 설계임

---

서두 – 질문의 출발점

• 제품을 실제로 사용하는 사용자와 구매 결정을 내리는 고객이 서로 다를 때 어떻게 접근해야 할까?
• 전형적으로 개발자가 제품을 시도해 보고, CTO 또는 Director of Engineering이 최종 의사결정을 하는 B2B 소프트웨어 영업 맥락을 배경으로 함

권한에 대한 본질적 질문

• '누가 진짜 힘을 갖고 있는가?'라는 질문이 가장 핵심적인 포인트임
• 단순히 카드 결제 권한 또는 제품 시도의 우선순위가 아니라, 실제 영향력과 동기가 구매 흐름에 결정적임

조직 구조별 시나리오

소규모 조직의 경우 : 조직 구조가 평평하고 의사결정이 빠름

• 개발자가 제품을 알아보고, 실제로 도입을 주도하는 경우가 많음
• CTO의 주요 동기는 빠른 시장 진입 및 반복이므로, 개발자의 툴 제안이 의사결정에 중대한 영향력을 행사함
• 개발자가 빠르게 무료로 도구를 시도하고, 이후 유료로 전환하는 Trojan-horse 방식의 확산이 자주 나타남

대규모 조직의 경우 : 보안·규정 준수가 주요 제약

• 보안 등 시간 이외의 제약조건이 존재하며, 리더십의 의사결정이 모든 과정에 중요하게 작용함
• 사용자(개발자)의 자율적 설치나 구매는 허용되지 않으며, 세일즈 사이클이 길고 복잡함
• 가치/위험 인식 기준이 UI/UX 또는 DX 보다는 보안 및 최종 산출물에 집중됨

진정한 영향력과 가치의 관점

• 예산권자가 항상 실질적 권한자는 아닐 수 있음
• 중요한 것은 '누가 레버리지를 갖고 있고', '누구의 인센티브가 프로세스 진행에 가장 크게 작용하는가'임
• 가격만큼의 가치를 실제 교환 가능한 주체가 누구인지 현실적으로 파악해야 함

구체적인 제품 도입 플로우 예시

1. 사용자/개발자가 제품 회원가입 진행
2. 무료 트라이얼을 로컬 환경에서 사용
3. 실제 기능 가치(예: Pull Request 전/후 비교, 문제 하이라이트)를 직접 경험
4. 가치 인지 → 업무 효율·자동화 기대
5. 사용자가 리더십에게 필요성을 설득
6. 리더십이 내부 테스트 및 예산 검토 후 승인 또는 거절
7. 리더십이 최종 구매 승인
8. 제품 구매 완료, 조직 내 추가 확산

양쪽 인센티브에 대한 질문

• 개발자가 툴을 제안하는 본질적 동기를 파악 (업무 편의성, 개인 역량 부각, 회사 목표 달성 등)
• 리더십의 구매 동기 파악 (개발 효율성 증대, 회사 목표 신속 달성 등)
• 이러한 핵심 동기들이 존재한다면 다음과 같은 전략을 제안함

실질적인 대응 전략

1. 사용자가 리더십을 설득할 수 있도록, 정확한 전·후 비교 리포트 등 설득 도구를 제공
   • 이 과정에서 추상적 조언이 아니라 정량 데이터 기반 결과가 중요
   • "이전 방식 대비 얼마나 시간이 단축되었는지" 등의 실질 수치가 설득의 열쇠
2. 실제 구매 대화가 어떻게 진행되는지 고객(개발자) 인터뷰로 파악해, 설득 과정의 장애 요소 미리 해결

• 즉, 구매 권한자를 직접 설득하기보다, 사용자가 내부 세일즈 역할을 성공적으로 수행할 수 있도록 모든 환경적 지원과 구체적 자료를 제공해야 함
• 이러한 프로세스에서 사용자의 성공이 곧 벤더의 성공으로 직결됨 (사용자-벤더-리더십-회사 전원의 win 구조)

결론 및 요약

• 사용자가 제품의 내부 세일즈 역할을 성공적으로 하도록 지원하는 것이 최고의 전략임
• 리더십 설득에 필요한 정량 근거와 구체적 가치자료 제공에 초점을 맞춰야 함
• 조직 규모와 제약조건별로 의사결정 구조를 면밀하게 분석하는 작업이 선행되어야 함
• 최종적으로, 사용자가 성공하면 벤더와 회사 모두가 동시에 성공하는 구조임을 강조함

[GN⁺]

Hacker News 의견

• 다운로드 하나 하려는데 연락처 정보를 요구하고, 잠깐이 후부터 영업 사원들이 전화나 이메일로 계속 연락하며 정중히 거절해도 무시하고 미팅 요청을 반복적으로 하는 상황에 염증을 느낌, 나는 구매 권한은 없지만 우리 팀 내에서 불만 전파는 가능하므로 결국 제품 이미지가 나빠짐, 엔지니어가 추천을 물어보면 당연히 이런 점을 말하게 됨, Veeam, AWS, Keyence에 해당하는 사례임

  • IT Manager로서 거의 매주 이런 경험을 하고 있음, 나한테 답변 못 받으니 내 동료들이나 회사 내 다른 사람들에게 무작위로 이메일을 보내 우회하는 경우가 있는데 이렇게 하면 빠르게 해당 도메인을 전체 차단하게 됨, 그리고 견적 하나 받으려고 데모를 억지로 보게 하지 말아줬으면 함, 이미 제품을 알아보고 필요하다면 트라이얼도 해봤을 것이므로 영업 프레젠테이션이나 데모보다는 견적부터 알려주는 것이 합리적임

  • Auth0, Okta도 같은 문제를 겪음, 실제 구매 권한과 예산까지 쥐고 있었지만 연락이 너무 지나치게 많아서 그냥 싫어짐

  • "불만 파워"라는 개념이 너무 좋음, 특히 무료로 제공해도 세일즈나 마케팅 팀이 너무 열정적이면 오히려 회사 인식이 나빠질 수 있음, 고객이 원하는 방법으로 연락해야지 자기들이 원하는 방식대로만 하면 역효과임, 하지만 이는 인센티브 디자인 측면에서 어려움이 있음

  • 일부 SaaS 마케팅 팀에서 5~15분마다 이메일 보내는 극단적인 경험을 해봤음, 때로는 직원 개인의 돌발 행동일 수도 있지만 조직 윗선이나 CEO가 직접 이메일 마케팅 도구 세팅을 최대로 해버린 경우도 있는 듯함

  • Microsoft 제품도 여기에 추가해야 함, 등록하려면 "프로페셔널 계정"을 만들어야 하고, 이를 위해 gmail 계정은 허용하지 않는 등 진입장벽이 높음, 30일 트라이얼을 쓰고 제품을 평가하려 해도 계정 문제 때문에 아예 접근조차 못 하는 경우, 이런 불편으로 인해 트라이얼도 힘든데 실제 도입 과정은 더 상상도 못 하겠음, AI 기반 CRM, ERP, Dataverse 등 사용할 마음이 안 생김

• 이런 현상은 Principal-Agent 문제에서 비롯됨, 회사의 경영진이 예산을 쥐고 있으나 실제로 제품/도구를 쓰는 건 개발자와 현장 직원임, 창업가 입장에서는 사용자를 내 편으로 만들어 리더십을 설득하게 해야 한다고 조언받는데, 핵심은 실제 신용카드 가진 사람과 얘기할 수 없으니 사용자가 리더십을 설득할 수 있도록 최대한 지원해야 한다는 것임, 즉 사용자/개발자가 실질적으로 세일즈 역할을 하게 만드는 방식임, 하지만 이런 접근이 프리미엄 모델 등에는 적용될 수 있지만, 병원 시스템과 EHR(전자 건강 기록)처럼 구매 결정을 아예 관리자가 일방적으로 내리는 산업에서는 실질적으로 사용자가 제품을 경험해볼 기회조차 없으므로 이를 극복할 방법이 궁금함

  • 실제 현장에서는 그 반대 상황도 자주 겪음, 세련된 세일즈맨이 예산 권한자를 노리면서 실제 사용자와는 소통을 차단시키고 계약을 먼저 체결함, 이용자들이 불만을 느끼고 문제를 지적할 때는 이미 돈이 지불된 후임

  • "리더십을 설득할 최적의 기회를 주고, 리더십에 이런 선택을 알릴 수 있는 것만으로도 사용자를 돋보이게 만들어야 한다"는 조언을 실천하기 위해 우리도 "CEO Page"를 별도로 제작한 경험 있음 https://www.rsync.net/products/ceopage.html

• 엔터프라이즈 세일즈 방식에 대해 부연하면, 의사 결정자 본인조차도 실제 기업의 파워 다이나믹을 제대로 파악하지 못한 경우가 있음, 추가로 챙겨야 할 부분은 이 사람이 비용 센터에 속하는지, 수익을 만드는 부서에 속하는지, 새로운 기술 도입을 추진하는 것인지 아니면 표준화된 제품인지, 그리고 누가 이 제품을 리스크나 권력에 대한 위협으로 여길지를 미리 생각해야 함, 누구에게 판매하고 누구를 피할지, 언제 사소하게 또는 대규모로 접근할지를 정하는 전략에 이런 정보들이 반영되어야 함

• Slack과 Postman이 자주 쓰는 방식은 "이미 귀하 팀의 96%가 우리 제품을 쓰고 있습니다. 이제 사는 게 합리적으로 보이지 않나요?" 식의 접근임

  • "이미 다들 쓰고 있는데 굳이 사야 하나요?"라는 반문을 듣게 되는데, 이는 구매자와 사용자의 괴리 수준을 드러내주는 질문임, 특히 중소기업 환경에서 그런 괴리가 큼

  • 학생들에게 소프트웨어를 무료로 제공하는 것도 같은 이유임

  • 대기업 내의 소규모 팀에서도 이런 일이 자주 발생함, 보안팀이 있으면 여러 개의 Slack 워크스페이스로 분산된 사용을 문제 삼을 수 있기 때문에 "400명이 12개 워크스페이스 쓰는 대신 하나의 공식 계정으로 관리하시죠" 같은 논리가 먹힘

  • 상용 오픈소스나 유사 모델의 숨겨진 장점은 개인 사용자 채택이 늘수록 회사 차원의 채택도 늘어난다는 점임

• 내가 이전에 창업했던 회사도 이 문제에 직면했었음, 실제 구매 결정권 없는 개발팀에 세일즈를 해야 했고, 규모가 작은 회사나 예외적으로 권한자가 있는 경우엔 계약이 쉬웠지만 대부분은 긴 세일즈 사이클에 코스트 세이빙을 상위 의사 결정자에게 설득해야 했음, 결국 이 과정이 오래 걸리고 성공률은 낮아 회사 실패의 주요 원인 중 하나였음, 이런 이야기가 더 공개적으로 다뤄져서 기쁨, 많은 소기업이 겪지만 공식적인 조언은 의외로 많지 않음

• 사용자가 직접 제품을 쓸 수 있고 같은 조직에 속해 있을 땐 이런 모델이 잘 맞음, 하지만 사용자가 의사결정자와 직접 관련 없거나 구매 타당성 입증이 어려운 경우(예: 자동차용 키리스 엔트리 팝처럼)는 어떻게 접근해야 할지 궁금함, 드라이버에겐 큰 이득이지만 Ford CTO 입장에선 미팅 제안 자체가 불필요하게 느껴질 수 있음, 이런 상황에서 제품 개발 후 어떻게 시장에 접근해야 할지 조언을 구함

  • 이런 경우는 바텀업(하향식) 전략이 매력적임, Ford 본사 대신 중고차 딜러, 자동차 수리점, 액세서리 판매점을 타겟으로 시작하는 것이 유효함, 원격 시동장치를 예로 들면, 사용자는 필요하지만 자동차 제조사는 관심이 적어서 처음에는 오디오 샵에서 교차판매 식으로 시장이 형성되었고, 이후 제조사도 옵션으로 도입하게 되었음, 나도 도난방지 장치로 이런 방식의 경험이 있는데, 소규모로 시작해 고객기반을 만들어 점차 큰 기업에 접근하는 것이 효과적임

  • 경쟁업체에서 이미 팝을 도입하고 있다는 사실을 부각해서 FOMO(놓치면 안 된다는 두려움)를 자극하는 방식도 방법임

• 엔터프라이즈에서는 CTO에게만 세일즈하면 되는 게 아님, AWS나 Azure처럼 정말 핵심 역할을 하는 기업이면 CTO와 주요 엔지니어만 설득하면 조직 전체 변경도 가능하지만, 대부분의 소프트웨어는 라인 매니저나 디렉터, 혹은 부서장이 결정하는 경우가 많음, 심지어 각 부서마다 도입하는 소프트웨어가 다르기 때문에 타겟을 세분화해야 함

• B2B2C 마켓플레이스는 특히 재미있음, "B2B" 사용자에게는 비용을 부과하지 않고 거래당 수수료를 취하는 모델에서, 사용자들을 분산된 세일즈포스로 활용함, 각 사용자가 자신만의 인스턴스를 통해 B2C 고객을 유치하도록 도와줘야 함, 창업팀 입장에서는 개발할 게 많아지고 혼란스럽게 느껴질 때도 많지만, 초기 진입장벽이 낮아서 각 계정이 최종 고객에게 가치를 잘 전달할 때마다 자연스럽게 매출이 크게 늘어나는 장점이 있음

• 우리 회사도 공감하는 이야기임, 우리는 entity resolution 관련 비즈니스 인텔리전스 API를 만들고 있는데, 엔지니어링, 제품, 데이터 사이언스 팀이 모두 엮이니 구매자와 사용자의 분리가 복잡해짐, 엔지니어들은 복잡한 회사 데이터 매칭의 어려움을 직감적으로 이해하지만 임원들은 그냥 프로젝트가 늦어진 걸로만 여김, 그래서 요즘엔 "팀이 데이터 매칭에 몇 달씩 쏟아붓고 있습니다"라는 식으로 접근하는 쪽이 더 설득력이 있음, 한 회사는 10년간 자체적으로 구축을 시도했는데 여전히 제대로 작동하지 않음, 물론 회사와 상황에 따라 접근법이 다르다는 점도 느끼고 있음

  • 이런 기술적 가치를 사용자에게 어떻게 전달하고 있는지 궁금함, 엔지니어에게 콜드 메일을 먼저 보내 대화를 시작한 후 확장하는 방식인지 묻고 싶음

• TikTok처럼 거래별로 중간에서 퍼센트만 받는 방식도 하나의 모델이 될 수 있음