들어가며

구독자님, 지난달 클라우드 배포 플랫폼 Railway의 엔지니어링 블로그에 흥미로운 글이 올라왔어요. 제목부터 도발적이었죠. "Kill your onboarding(온보딩을 죽여라)." 전 최근 사이드 프로젝트로 금융상품 분석 사이트를 만들었는데요. 이때 Railway를 처음 사용해 봤어요. 사실 Vercel과 Supabase로 충분했거든요. 최근에 이상탐지 Sentry 정도 써볼까 했지만 이것도 굳이? 였다가 비용 이슈로 Railway를 처음 써봤는데 생각보다 괜찮았거든요. 근데 이 서비스가 기술적으로도 생각보다 괜찮았는데 재밌는 영업 및 마케팅 사례가 많더라구요.

Railway는 하루 1만 건 이상의 가입이 들어오는 서비스에요. 2026년 4월 기준 누적 가입자 290만 명. 그런데 내부 분석을 열어보니, 세일즈 ICP^[1]​에 해당하는 기업 계정 21,000개를 식별해놓고, 그중 1% 미만에만 연락한 상태였어요. 결론부터 말씀드리면, 이건 이메일이 나빠서가 아니라 보내는 대상이 틀려서 생긴 문제였고, 해법은 놀라울 만큼 단순했어요.

🛢️ 석유는 이미 있었다. 데이터를 모으고도 안 쓰는 기업들

PLG^[2]​기업의 구조적 딜레마가 있어요. 사용자 경험을 극대화하려고 가입 시 아무것도 묻지 않는데, 그 결과 누가 취미로 쓰는 개인이고 누가 프로덕션 인프라를 구축하려는 기업 팀인지 구분할 수 없게 돼요.

그러니까, 저처럼 개인 취미로 사이트를 만드는 사람도 있고, 어떤 사람은 회사 단위의 프로젝트로 이걸 쓰는 사람도 있는데 Railway 입장에선 당연히 B2B 고객을 잡아야겠죠. Railway가 정확히 이 상태였어요. GitHub 계정 하나로 몇 초 만에 배포가 가능한 극도로 매끄러운 온보딩을 자랑하지만, "어떤 회사 소속이세요?"나 "엔지니어가 몇 명이에요?" 같은 질문은 의도적으로 하지 않아요. 요즘 유행하는 Granola 스타일 온보딩 "가입 직후 직무·팀 규모·사용 목적을 줄줄이 묻는 방식" 을 "우리는 의도적으로 거부한다"고 명시할 정도죠. 보통은 저런 질문을 많이하긴 해요. (많이들 당해?보셨을 거에요.)

문제는 그 대가예요. AE(영업 담당자) 1명, SE(솔루션 엔지니어) 2명으로 구성된 초소형 세일즈팀이 21,000개 잠재 기업 계정을 상대해야 하는데, 누가 우선인지 알 방법이 없었어요. Railway 창업자 Cooper는 이렇게 표현했어요.

흥미로운 건 Railway에 데이터가 없었던 게 아니라는 점이에요. PostHog로 제품 이벤트를 수년간 수집해왔고, 내부 시스템 'backboard'에는 각 프로젝트의 서비스 구성, 인스턴스 규모, 데이터베이스 연결, 배포 결과까지 세밀하게 기록되어 있었어요. 이 패턴, 익숙하지 않으세요? "데이터가 부족하다"는 게 아니라, 이미 쌓인 데이터에 질문을 던지지 않고 있었던 거예요.

이건 Railway만의 문제가 아니에요. 2026년 현재 PLG 모델을 채택한 기업이 전체의 58%에 달하지만, 제품 사용 데이터를 기반으로 리드를 평가하는 PQL^[3]​ 프레임워크를 도입한 곳은 25%에 불과해요. 나머지 75%는 사용자의 행동 데이터를 갖고 있으면서도 여전히 마케팅 퍼널에만 의존하고 있다는 뜻이에요.

🔍 SOC 2 보고서를 다운받는 취미 개발자는 없다. 신호 선별의 기술

Railway의 솔루션 엔지니어 Des Conlon이 택한 접근은 놀라울 정도로 고전적이었어요. ML 모델을 돌린 게 아니라, 모든 행동 차원(dimension)을 하나씩 꺼내서 '기업 계정 대비 취미 계정의 발생 비율'을 계산한 거예요. Hex라는 분석 도구 위에서 dbt 모델을 쌓고, 수십 개의 GROUP BY 쿼리를 반복하며 후보 신호를 추려냈어요.

여기서 중요한 한 수가 있었어요. 겉보기에 가장 예측력이 높은 신호를 과감하게 버렸다는 점이에요.

예를 들어 SSO 사용 여부는 "이 계정이 기업이냐"를 거의 100% 맞추는 지표였지만, SSO는 이미 세일즈 대화를 마친 고객만 활성화할 수 있는 기능이에요. 이미 알고 있는 사람을 다시 알려주는 것에 불과하죠. 데이터 분석에서 흔히 말하는 레이블 누수(label leakage)^[4]​인 답이 입력에 섞여 있는 현상이에요. Conlon은 이걸 "1 = 1"이라고 표현했어요. 자명한 사실을 검증해봤자 의미 없다는 거죠.

살아남은 규칙은 하나였어요. "취미 개발자도 이론적으로는 할 수 있지만, 실제로는 거의 하지 않는 행동"만 신호로 인정해요. 최종적으로 남은 다섯 가지가 흥미로워요.

이 다섯 가지를 업리프트 비율로 가중 합산해서 점수를 만들었어요. 그래디언트 부스팅도, 랜덤 포레스트도 아닌, 선형 가중합. 왜 이렇게 단순하게 갔을까요?

이유가 두 가지였어요. 첫째, 행동 데이터가 대부분 하루치뿐이라 복잡한 모델은 과적합될 게 뻔했어요. 둘째, 이 점수를 보고 행동하는 건 AE 한 명이에요. "Trust doc + 좌석 8개 + DB 연결"이라는 이유는 바로 이해할 수 있지만, 모델이 뱉은 "0.87점"만으로는 그 판단이 틀렸을 때 알아챌 수가 없거든요. Conlon의 표현을 빌리면, "읽을 수 있는 모델이 한계 정확도를 이기는 모델보다 거의 항상 낫다."

📧 드립하지 마, 트리거하라. 이메일의 재발명.

이렇게 만든 점수는 두 갈래로 흘러요. 중간 점수는 Customer.io를 통한 자동 이메일로, 높은 점수는 사람이 직접 연락하는 경로로요.

그런데 이 자동 이메일이 기존 온보딩 시퀀스와 완전히 다른 구조예요. "가입 후 1일차, 3일차, 7일차"라는 시간 기반 드립이 아니라, 특정 행동이 발생한 시점에 발송하는 이벤트 트리거 방식이거든요.

발송 조건도 까다로워요. 두 가지를 동시에 충족해야 해요.

그리고 이메일 내용은 미팅 요청이 아니에요. 엔터프라이즈 티어를 홍보하지도 않아요. 실제 영업 담당자의 이름으로 발송되며, 내용은 "이런 작업을 하시는 것 같은데, 도움 드릴 게 있을까요?" 수준이에요.

결과가 극적이었어요. 기존 범용 온보딩 이메일의 오픈율은 27%였는데, 트리거별 오픈율이 50~70% 범위로 올라갔어요. 첫날 300~400통 발송에서 실제 답장이 2건 나왔고요.

물론 이 수치에는 중요한 맥락이 있어요. Apple Mail의 프라이버시 보호 기능이 오픈율을 부풀릴 수 있고, 애초에 가장 관심 있을 사람에게 가장 적절한 타이밍에 보낸 것이니 선택 편향이 크죠. Railway 스스로도 이걸 인정하면서 A/B 테스트를 설계 중이라고 밝혔어요.

하지만 방향성 자체가 의미 있어요. 대부분의 PLG 이메일 마케팅 가이드는 "행동 기반 트리거"를 추천하지만, Railway가 다른 점은 트리거 조건 자체에 ICP 필터를 겹쳤다는 거예요. 단순히 "DB를 연결한 사용자에게 이메일 보내기"가 아니라, "DB를 연결했으면서, 동시에 기업 계정일 가능성이 높은 사용자에게만 보내기"라는 이중 조건이에요. 이 차이가 발송 대상을 하루 수천 명에서 300~400명으로 압축시켰고, 오히려 그 압축이 품질을 만들어냈어요.

오스왈드의 시선

솔직히 이 사례를 처음 봤을 때 무릎을 쳤어요. GTM 전략을 수립하면서 수없이 봐왔던 가장 흔한 실패 패턴이 그대로 드러나 있었거든요.

그 패턴은 이래요. 기업이 성장이 더딜 때, 가장 먼저 손대는 건 이메일 카피나 랜딩 페이지 디자인이에요. 눈에 보이니까요. 그런데 실제로 문제가 있는 곳은 "누구에게 말하고 있는가"라는 타겟팅 레이어예요. Railway처럼 하루 만 명이 들어오는데 기업 고객 21,000개 중 1%만 접촉했다면, 카피를 아무리 바꿔봤자 소용없어요. 엉뚱한 사람에게 완벽한 메시지를 보내는 건 완벽한 낭비니까요.

그리고 이 사례에서 제가 가장 주목하는 건 따로 있어요. Conlon이 Looker 시절(이후 Google에 인수)과 Railway에서 겪은 문제가 완벽히 대칭이라는 점이에요. Looker에서는 고객이 합리적인 질문을 갖고 있었지만 그걸 답할 데이터 인프라가 없었고, Railway에서는 인프라가 갖춰져 있는데 질문을 안 던지고 있었어요. 두 경우 다 "데이터가 없어서"가 아니에요. 데이터와 질문 사이의 연결이 빠져 있었던 거예요.

"GTM 엔지니어"라는 직무가 올해 들어 채용 공고 3,000건을 넘겼다는 건 우연이 아니에요. 세일즈팀이 직감으로 "기업스러운 신호"를 추측하는 대신, 업리프트 비율을 계산하고, 레이블 누수를 걸러내고, 읽을 수 있는 점수 체계를 만드는 이 일련의 과정이 지금 가장 빠르게 몸값이 오르고 있는 역량이에요. 그리고 이 역량은 AI가 대체하는 게 아니라, AI 시대에 더 중요해지는 역량이에요. 모델이 아무리 좋아도, 어떤 신호를 넣을지 판단하는 건 사람이니까요.

국내에는 여전히 GTM 관련 직군이 이상하게 인기가 없는데 언젠가 붐이 온다고 생각하며... 꾸준글을 쓰고 있어요. 결국은 돈은 벌어야하니까요. 언제까지 꿈만 팔순 없을테니...

마치며

정리하면 이래요.

다음에 우리 조직의 온보딩 이메일 성과를 점검할 때, 카피를 고치기 전에 한 가지만 먼저 확인해 보세요. 지금 그 이메일, 정말 보내야 할 사람에게 가고 있나요?

구독자님의 조직에서는 가입 후 행동 데이터를 세일즈에 연결하고 있나요? 아니면 아직 "범용 환영 이메일" 단계인가요? 댓글로 들려주세요.

참고자료 & 더 읽기

핵심 출처

배경 지식

필자 안광섭은 세종대학교 경영학과 교수이자 OBF(Oswarld Boutique Consulting Firm) 리드 컨설턴트이다. 대학에서 경영데이터 관리, 비즈니스 애널리틱스 등 통계 및 데이터 분석을 가르치는 한편, 현장에서는 GTM 전략과 인공지능 전략 컨설팅을 이끌며 기술과 비즈니스의 접점을 설계하고 있다. AI 대화 시스템의 기억 아키텍처(HEMA) 연구로 학술 논문을 발표했으며, 매일 글로벌 AI 논문을 큐레이션하는 Daily Arxiv 프로젝트를 운영하고 있다. 고려대학교 기술경영전문대 석사과정와 KMBA을 졸업했다. 지은 책으로 《생각을 맡기는 사람들: 호모 브레인리스》가 있다.