Railway가 가입자의 사용 기록으로 영업 대상을 고른 방법

하루 1만 명이 가입하는 서비스의 영업 대상 선정

최근 사이드 프로젝트로 금융상품 분석 사이트를 만들면서 클라우드 배포 플랫폼 Railway를 처음 써봤어요. 그전에는 Vercel과 Supabase로 충분하다고 생각했고, 오류 추적 도구인 Sentry도 꼭 필요할지 고민하던 참이었어요. 비용 문제로 Railway를 써보니 기술뿐 아니라 고객을 유치하고 지원하는 방식에도 참고할 점이 많더라고요. 마침 Railway가 2026년 5월 6일 공개한 「Kill your onboarding」이라는 글을 읽었어요. 가입자에게 보내는 일률적인 영업 이메일을 바꾼 경험을 다룬 글이에요.

당시 Railway는 하루 1만 건 이상 신규 가입이 들어오고, 2026년 4월 이전 누적 가입자는 약 290만 명이라고 밝혔어요. 영업팀이 찾는 고객 조건인 ICP¹에 맞는 계정 약 2만 1천 개를 식별했지만, 접촉한 비율은 1% 미만이었어요. 회사 소속 이용자도 개인 프로젝트를 하는지, 팀의 실제 운영 환경을 구축하는지에 따라 필요한 지원이 달랐는데 같은 안내 이메일을 보내고 있었어요. 이 글은 매출 부진의 원인이나 매출 개선을 입증한 보고서가 아니라, 영업 대상을 찾아 연락하는 방식을 바꾼 초기 사례예요.

사용 기록을 영업팀이 활용할 수 있게 만들기

제품 사용 경험으로 고객을 확보하는 PLG²에서는 가입 절차를 간단하게 만드는 일이 중요해요. 다만 회사와 팀 규모를 묻지 않으면, 영업팀은 다른 자료를 통해 이용 목적을 파악해야 해요.

저처럼 개인 프로젝트를 만드는 사람도 있고, 회사 업무에 쓰는 팀도 있겠죠. Railway는 GitHub 계정이나 이메일로 가입한 뒤 바로 배포할 수 있게 하고, 회사명이나 엔지니어 수를 묻는 설문은 의도적으로 넣지 않았다고 해요. 먼저 제품을 써보게 하되, 기업 고객을 찾는 과정은 별도로 마련해야 했어요.

당시 영업팀은 AE(영업 담당자) 1명과 SE(솔루션 엔지니어) 2명이었어요. 이 작은 팀이 2만 1천 개의 잠재 기업 계정 중 어디에 먼저 연락할지 판단하도록 돕는 체계가 필요했어요.

창업자 쿠퍼도 이미 확보한 잠재 고객과 사용 기록을 영업에 충분히 활용하지 못하고 있다고 지적했어요.

Railway는 PostHog로 제품 사용 이벤트를 오래 수집해 왔어요. 내부 시스템인 backboard에도 프로젝트의 서비스 구성, 인스턴스 크기, 데이터베이스 연결, 배포 결과가 기록돼 있었고요. 분석에 필요한 자료는 있었지만, 그 자료로 영업팀이 연락할 계정을 골라내는 과정이 빠져 있었던 거예요.

맥킨지의 PLG 연구도 제품을 사용한 경험과 기업 정보를 함께 살펴보고, 적절한 시점에 영업팀이 개입하는 방식을 설명해요. 사용 행동을 바탕으로 구매 가능성을 평가한 고객을 PQL³이라고 불러요. 가입자 수를 늘리는 것에 더해, 어느 이용자에게 어떤 지원이 필요한지 파악하는 일이에요.