예시: 개발자(dev)는 사용자, CTO는 구매자(buyer)

최근에 “가장 내 제품의 가치를 높게 평가하는 사람이 바로 이상적인 고객이다”라는 글을 올린 적이 있어요. 그런데 바로 한 비공개 커뮤니티에서 이런 질문이 나왔죠.
만약 내가 이상적인 고객과 대화해야 한다면, 그 사람이 실제로 제품을 써보는 사람이 아니라면 어떻게 접근해야 할까요?
제 경우엔 완전히 동의해요. CTO나 엔지니어링 디렉터가 최종 의사결정을 내리는 것 같아요. 하지만 실제로 제품을 처음 써보는 건 개발자잖아요.
아티클에서 “메시지를 어떻게 전달할 것인가”는 이해가 가요. 그런데 실제로 의사결정권자를 어떻게 접촉할 수 있나요?
이 질문을 같이 파헤쳐보고, 근본적인 이슈를 지금 바로 짚어보죠.
이게 바로 “사용자가 구매자가 아닌 상황(the user is not the buyer)”이죠.
이 문제, 쉽지 않습니다. 정답이 하나로 딱 떨어지는 유형이 아니에요.
여기서 핵심은 단 한 가지입니다:
→ 실제 실권을 쥐고 있는 사람이 누구냐? (힌트: 신용카드를 쥐고 있다고 해서 꼭 힘이 있는 건 아니에요)
시나리오 1 – 작은 조직 구조
당신의 제품이 소규모 회사에서 쓰이고 구매될 때를 상상해보세요. CTO나 디렉터가 분명히 있지만, 조직이 수평적이고 모두가 직접 만들고 있는 상황입니다. 대부분 시장에서 자리를 잡으려 하거나, 제품의 가치 제안을 찾기 위한 초기 단계의 회사들이죠.
이런 소규모 회사에선, 실제로 개발자(사용자)가 영향력을 가질 수 있습니다. 왜 그럴까요?
CTO 입장에서 가장 중요한 동기는 ‘빠른 출시와 반복’입니다. 빨리 시장에 내놓고, 반복적으로 개선해나가야 빨리 배우고, 제품-시장 적합성(PMF)을 찾을 수 있죠. 이 과정이 빨라야 모두 회사에 남을 수 있고, CEO가 약속한 3~10년 후 대박도 꿈꿀 수 있으니까요.
이렇게 시간에 쫓기는 상황에서는, 개발자가 자연스럽게 힘을 갖게 됩니다.
개발자들은 대개 트렌드와 최신 도구에 밝아서, 이런 도구를 직접 제안하는 경우가 많습니다. “왜 이 툴을 왜 써야 하는지”, “이게 우리한테 얼마나 도움이 되는지”를 설명해 주죠.
때로는 아무도 모르게 무료 계정을 만들어 제품을 먼저 써보기도 합니다. “일단 되는 걸 먼저 해보자”는 거죠.
결국 제품을 써보다가, 기능이 더 필요해서 유료로 업그레이드하는데, 이때 이미 조직 전체가 자연스럽게 제품에 스며든 셈입니다. 일종의 트로이 목마식 침투라고 볼 수 있죠.
시나리오 2 – 큰 조직 구조
이번엔 규모가 크고 복잡한 조직을 생각해봅시다. 여기서는 CTO, 디렉터, 경영진이 명확한 권한을 쥐고 있습니다. 시간 이슈가 아니라 ‘보안’이나 다른 제약들이 더 크게 작용하죠.
예를 들어, 회사 방침상 개발자나 사용자가 직접 소프트웨어를 설치하는 일이 아예 허용되지 않습니다. 모든 결정과 배포가 위에서부터 내려와요.
이런 환경에선 제품을 실제로 조직에 도입하기까지 시간이 오래 걸리고, 가치 제안 방식 자체가 완전히 달라집니다. 기업마다 검증과 심사, 내부 승인 과정이 길게 이어지기 때문에 경쟁 제품과 비교해가며 최종 선택까지 단계가 많죠.
결국 개발자나 사용자는 큰 선택권이 없습니다. 이들의 기준이 UI/UX/DX 등 사용자 경험이 아니라, 보안과 실제 조직이 얻을 수 있는 결과(output)가 더 우선순위가 됩니다.
여기서 중요한 건, 흔히 “결정권자(decision maker)”라고 하면 신용카드를 가진 사람이라고 생각하기 쉽지만, 실제로 힘을 가진 사람이 누구인지는 그들이 처한 제약(리스크, 규칙)에 따라 바뀝니다.
제품을 처음 써본 사람이 누구인지가 중요한 게 아니라,
“누가 실제로 영향력(leverage)을 행사할 수 있나?”
즉, 권한·제약·인센티브를 가장 많이 쥐고 밀어붙일 수 있는 사람이 결국 제품의 ‘가치를 가장 높게 평가’하는 셈입니다.
중요 포인트: 여기서 “가치(value)”라는 개념을 엄밀하게 정의할 필요가 있어요. 실제로 행동으로 옮길 수 있는, 현실적으로 실현 가능한 것이어야만 진짜 가치라고 볼 수 있습니다. 예를 들어, 누군가 “이 제품 나한테 N만큼 가치 있어요”라고 해도, 실제로 N을 지불할 수 없는 입장이라면 결국 그건 무의미하다는 거죠.
다시 본론으로 돌아가자면,
만약 사용자(혹은 개발자)가 제품의 가치를 더 크게 느끼지만 예산을 쥔 사람이 아니라면? 결국 선택지는 하나밖에 없습니다.
아무리 개발자가 극찬해도, CTO가 그만큼을 투자해주지는 않을 겁니다.
물론 나도 개발자로 일할 때, 정말 필요하다면 내 돈을 들여서 툴을 사본 적이 있어요. 이때는 회사가 잘 되는 게 중요한 게 아니라, ‘내가 이걸로 회사에서 빛나고 싶어서’ 투자하는 거죠.
동기(incentive)가 다르고, 보상(payoff)도 다르다는 얘기입니다.
이 점을 염두에 두고, 좀 더 구체적으로 들어가 볼게요.
좀 더 구체적으로 얘기해봅시다
이 부분을 원글 작성자에게 다시 물었어요. “네가 경험상 가장 잘 작동했던 솔루션의 도입 경로는 어떻게 되나요?”
예를 들면 이런 흐름이 있을 수 있습니다:
- 사용자/개발자가 회원가입을 한다
- 사용자/개발자가 로컬 환경에서 무료 체험을 한다
- 사용자/개발자가 직접 사용해보고, 예를 들어 PR(pull request)을 올리기 전후의 효과를 직접 체감하며 이슈가 무엇인지 파악한다
- 사용자/개발자가 “아, 이거다!” 싶은 가치를 직관적으로 느낀다 (“aha moment”를 제대로 경험). 예를 들어 QA 자동화나 시간 절감 같은 이점이 한눈에 보일 수 있음
- 사용자/개발자가 조직 내 리더십에게 이 제품은 유료로 써야만 한다고 설득한다
- 리더십 측에서 직접 써보거나 프로세스를 확인 후, 예산을 검토하고 도입 여부를 결정한다
- 리더십의 승인이 떨어진다
- 사용자/개발자 혹은 리더십이 실제로 결제 및 도입한다
- 사용자/개발자가 계속 사용하며, 조직 내 다른 동료 개발자들에게도 확산시킨다
이렇게 (조직의 크기, 사용자 흐름 등 전제에 따라 다르지만) 실제로 이런 경로가 주로 발생한다면, 다음과 같은 질문을 해봐야 합니다:
개발자가 이 툴을 추천하는 ‘진짜 동기(incentive)’는 뭘까? 정말로 자신의 일이 더 쉬워지거나, 본인이 돋보이기 위해서일까? 아니면 회사의 목표에 기여한다고 믿어서일까?
반대로, 경영진이 구매를 결정하는 ‘진짜 동기’는 뭘까? 실제로 개발자 업무가 더 빨라지고, 효율적이 돼서 결국 회사가 이득을 보니까 그런 걸까?
만약 위 질문들의 답이 그렇다면, 저는 두 가지를 권하고 싶어요.
- 사용자(개발자)가 리더십을 설득할 수 있도록 필요한 도구를 제공하세요. 그들이 가진 동기에 맞춰, 사용자 입장에서 느끼는 가치를 리더가 이해할 수 있는 언어로 바꿔주는 겁니다.
참고로, “이렇게 리더십을 설득하세요”라고 직접 알려주는 것보다는, “기존 방식대로 했을 때 쓰던 시간과 실제 이 방법으로 쓴 시간을 비교한 리포트”를 보여주는 게 훨씬 효과적입니다. 그리고 이 데이터는 최대한 정확한 실제 숫자가 되어야 해요. 개발자가 신뢰하지 않는 부정확한 데이터라면 이 보고서를 안 쓰려 할 테니까요.
- 아울러 개발자와 인터뷰해서, 평소 리더십과의 대화가 어떻게 진행되는지, 어떤 게 대화를 빠르고 쉽게 만드는지, 구매 결정에 어떤 걸림돌이 있는지 파악하세요.
문제의 마찰 지점을 찾아내서 부드럽게 만드는 게 중요합니다.
요점은, 당신이 신용카드를 쥐고 있는 의사결정자와 직접 얘기하지 않는다는 겁니다. 실제로는 사용자나 개발자가 그 역할을 대신해 줍니다.
그들에게 리더십을 설득할 최고의 기회를 주세요. 이런 중요한 선택을 리더에게 직접 묻느라 수고했다고 개발자가 돋보이도록 만들어야 합니다. 그리고 리더가 “당연히 이렇게 해야지!” 하고 쉽게 결정을 내릴 수 있게 명확하게 보여줘야 합니다.
이 사용자와 개발자들이 바로 당신의 최고의 세일즈맨입니다. 그들이 성공하면(제품이 사용자가 기대하는 대로 작동해 그들이 원하는 결과를 얻으면) 당신도 성공하고(매출과 성장), 그들은 또 한 번 성공하는 셈이죠(자신의 업무 과정이 매끄럽고 성과가 좋아져 돋보이고). 당연히, 리더십과 회사도 윈윈입니다.
이제 가서 그 개발자들을 적극적으로 포교(proselytize) 하세요. 😉
원문: How to Sell if Your User is not the Buyer
blog by ash에서 더 알아보기
구독을 신청하면 최신 게시물을 이메일로 받아볼 수 있습니다.