GTM은 Go-To-Market의 줄임말입니다. 제품을 만든 뒤 광고나 영업으로 알리는 일만 뜻하는 것은 아닙니다. 어떤 고객에게 어떤 가치를 제안하고, 그 고객이 제품을 처음 발견한 순간부터 실제 가치를 경험하고 계속 사용하는 과정까지 연결하는 일에 가깝습니다.
그래서 GTM에는 마케팅과 영업뿐 아니라 제품, 고객 지원, 데이터가 함께 들어갑니다. 좋은 메시지로 고객을 데려와도 제품 안에서 막히면 성과로 이어지지 않습니다. 반대로 좋은 기능을 만들어도 필요한 고객에게 제대로 전달되지 않으면 사용되지 않습니다.
저는 주로 개발을 맡고 있고, GTM은 다른 동료가 이끌고 있습니다. 그렇다고 두 일이 멀리 떨어져 있는 것은 아니었습니다. 고객이 어디에서 관심을 보이고 어디에서 멈추는지는, 결국 무엇을 먼저 만들고 고칠지와 연결되기 때문입니다. 그래서 GTM에서 발견한 고객의 반응과 막힘을 개발 우선순위에 어떻게 반영할 수 있을지 생각해봤습니다.
최근 Clay, Ramp, Exa, Cloudflare의 GTM 엔지니어링 사례를 살펴보면서, 개발자에게 필요한 연결 고리를 조금 구체적으로 정리해볼 수 있었습니다.
네 사례에서 정리한 GTM 구조
GTM은 고객을 데려오는 일에서 끝나지 않았습니다
Clay의 Everett Berry는 고객과 회사 정보가 계속 변한다는 점에서 출발했습니다. 회사는 인수되거나 새 사무실을 열고, 사람은 입사하거나 퇴사합니다. 한 번 수집한 고객 정보가 계속 정답으로 남아 있지 않기 때문에, 여러 데이터 공급자를 확인하고 정보마다 갱신 주기를 다르게 운영했습니다.
Exa의 Jeffrey Wang은 GTM의 기반을 에이전트가 행동할 수 있는 살아 있는 시장 모델이라고 설명했습니다. 어떤 회사를 고객으로 볼지 분류하는 것과, 그 고객에게 지금 의미 있는 변화가 생겼는지 알아차리는 것은 서로 다른 문제였습니다.
Ramp의 사례에서는 이렇게 모은 신호가 실제 실행으로 이어졌습니다. 고객군을 만들고, 콘텐츠와 랜딩 페이지를 준비하고, 제품 안의 행동까지 연결했습니다. Cloudflare는 분석, 검토, 문체 정리를 서로 다른 에이전트에 맡기면서도 사람이 몇 달 동안 모든 결과를 확인했습니다.
네 사례를 함께 놓고 보니 공통된 구조가 있었습니다.
고객의 신호를 모으고, 현재 상태를 판단하고, 다음 행동을 실행한 뒤, 그 결과를 다시 고객 상태에 반영합니다.
GTM을 캠페인의 목록이 아니라 고객 상태가 계속 변하는 과정으로 보면, 개발팀과 연결되는 지점도 분명해집니다.
개발자는 GTM 신호를 제품의 문제로 번역할 수 있습니다
GTM 담당자가 “참여자는 많은데 코칭을 시작하지 않는다”는 사실을 발견했다고 가정해봤습니다. 이 말을 그대로 개발 요청으로 받아들이면 알림 기능이나 새로운 온보딩 화면부터 떠올리기 쉽습니다.
하지만 먼저 어느 상태에서 멈췄 는지 나누어 봐야 합니다.
챌린지에는 참여했지만 Rona Coach를 연결하지 못했을 수 있습니다.
앱은 연결했지만 기간 계획을 만들지 못했을 수 있습니다.
계획은 만들었지만 첫 코칭을 어디에서 시작하는지 몰랐을 수 있습니다.
코칭을 시작했지만 결과물을 완성하지 못했을 수 있습니다.
같은 “미시작”처럼 보여도 원인에 따라 필요한 개발은 전혀 달라집니다. 연결 오류라면 복구 경험이 우선이고, 다음 버튼을 찾지 못한 문제라면 안내 구조가 우선입니다. 운영 메시지만으로 해결된다면 기능을 새로 만들 필요가 없을 수도 있습니다.
Rona 챌린지에 대입한 고객 상태 흐름
이때 개발자의 역할은 GTM 담당자의 판단을 대신하는 것이 아니었습니다. 고객과 시장에서 나온 신호를 제품에서 확인할 수 있는 상태로 바꾸고, 실제로 막힌 지점을 찾는 일이었습니다.
개발 우선순위를 정할 때 세 가지를 먼저 묻게 됐습니다
GTM의 관찰을 개발 우선순위로 옮길 때는 다음 세 가지 질문이 필요했습니다.
1. 어떤 고객이 어느 단계에서 멈췄는가?
“사용률이 낮다”는 말만으로는 개발 범위를 정하기 어렵습니다. 챌린지 참여, 앱 연결, 계획 생성, 첫 코칭 시작처럼 고객 상태를 나누면 병목이 보입니다. 이를 확인할 데이터가 없다면 새 기능보다 상태를 정확히 관찰할 수 있게 만드는 작업이 먼저일 수 있습니다.
2. 제품을 고쳐야 하는가, 운영으로 해결할 수 있는가?
모든 고객 문제를 기능으로 해결할 필요는 없습니다. 안내 문구나 운영자의 한 번의 연락으로 충분한지 먼저 확인해야 합니다. 같은 문제가 반복되고 사람이 매번 같은 방식으로 해 결하고 있을 때 제품화나 자동화를 검토할 수 있습니다.
3. 무엇이 달라지면 해결됐다고 볼 수 있는가?
알림을 보냈다는 사실이나 화면을 배포했다는 사실은 성공 기준이 아닙니다. 안내를 받은 사람이 앱을 연결했는지, 기간 계획을 만들었는지, 첫 코칭을 시작했는지처럼 고객의 다음 행동이 달라졌는지를 봐야 합니다.
GTM 신호를 개발 우선순위로 바꾸는 과정
이 기준으로 보면 Rona에서 당장 거대한 GTM 자동화 시스템을 만들 필요는 없습니다. 먼저 소수 참여자의 상태를 사람이 확인하고, 어디에서 멈췄는지와 어떤 안내가 효과가 있었는지를 기록하면 됩니다.
예를 들어 다음 질문 하나에서 시작할 수 있습니다.
챌린지에 참여했지만 코칭을 시작하지 못한 사람에게 지금 필요한 다음 행동은 무엇인가?
참여, 앱 연결, 기간 계획, 첫 코칭 시작 상태를 확인한 뒤 필요한 안내를 사람이 보냅니다. 같은 판단과 안내가 반복해서 효과를 낼 때만, 그 부분을 개발하거나 자동화할 우선순위가 생깁니다.
GTM과 개발은 같은 일을 하지 않지만 같은 흐름을 봐야 합니다
GTM 담당자는 어떤 고객에게 어떤 가치를 전달할지 정하고, 고객의 반응을 가장 가까운 곳에서 관찰합니다. 개발자는 그 관찰을 제품의 상태와 행동으로 구체화하고, 실제 병목을 줄일 수 있는 변경을 만듭니다.
두 역할이 분리되어 있어도 개발 우선순위는 GTM과 무관할 수 없습니다. 고객이 아직 겪지 않은 문제를 예상해서 기능을 늘리는 것보다, 실제 고객이 다음 단계로 넘어가지 못하는 지점을 먼저 해결하는 편이 제품의 성과에 직접 연결되기 때문입니다.
이번에 GTM을 공부하며 얻은 가장 큰 변화는 새로운 도구를 알게 된 것 이 아니었습니다. 개발할 기능의 목록부터 보는 대신, 고객이 지금 어느 상태에 있고 다음 행동을 무엇이 막고 있는지부터 묻게 됐다는 점이었습니다.
아직 이 흐름을 실제 데이터와 자동 발송에 연결하지는 않았습니다. 먼저 참여자 몇 명을 대상으로 사람이 같은 기준을 적용해보고, 반복되는 문제와 판단이 확인되면 그때 개발 우선순위에 반영해보려고 합니다.
