1.3 범용 서비스가 실패하는 구조

리텐션을 확인하고 아하 모먼트를 정의했다면 이제 진짜 마케팅을 시작해도 될까요? 아직 한 가지 더 확인해야 할 것이 있습니다. 지금 서비스가 모두를 위한 것인지, 아니면 특정 집단을 위한 것인지 확인하는 것입니다.

초기 서비스를 만들 때 가장 흔한 실수가 있습니다. 가능한 한 많은 사람에게 유용한 서비스를 만들려는 것입니다. 누구나 쓸 수 있고, 누구에게나 필요한 서비스를 목표로 합니다. 할일 관리는 누구나 하니까 모든 직장인을 위한 할일 앱을 만듭니다. 메모는 누구나 하니까 모든 사람을 위한 메모 앱을 만듭니다. SNS는 모두가 쓰니까 모든 사람을 위한 새로운 SNS를 만듭니다.

하지만 실제로는 대부분 실패합니다.

이런 범용 서비스는 대부분 실패합니다. 시작 단계에서 모두를 대상으로 하면 결국 아무도 붙잡지 못합니다. 왜 그럴까요? 범용 서비스는 특정 집단에게 필수가 되지 못하기 때문입니다. 누구에게나 조금씩 쓸모 있지만 누구에게도 꼭 필요하지 않습니다. 사용자는 한두 번 써보고 "괜찮네"라고 생각하지만 다음 날 다시 찾지 않습니다. 대체할 수 있는 다른 서비스가 이미 너무 많기 때문입니다.

성공한 서비스들은 처음부터 범용으로 시작하지 않았습니다. 아주 좁은 집단을 정했습니다. 그 집단에게 완벽한 서비스를 만들었습니다. 그들이 매일 쓰는 필수 도구가 되었습니다. 그러고 나서 조금씩 확장했습니다. 이번 절에서는 왜 범용 서비스가 실패하는지, 그리고 어떻게 최초의 핵심 사용자 집단을 설정해야 하는지 다룹니다.

1.3.1 모두를 위한 서비스가 아무도 붙잡지 못하는 이유

범용 서비스의 문제는 명확합니다. 특정 집단의 구체적인 문제를 해결하지 못합니다. 대신 모든 사람의 평균적인 문제를 조금씩 건드립니다. 결과적으로 누구에게도 깊은 인상을 주지 못합니다.

예를 들어 모든 직장인을 위한 할일 관리 앱을 만든다고 가정합니다. 영업 사원도 쓸 수 있고, 개발자도 쓸 수 있고, 디자이너도 쓸 수 있는 앱입니다. 할일을 등록하고, 마감일을 설정하고, 체크하는 기본 기능이 있습니다. 심플하고 깔끔합니다. 누가 써도 무난합니다.

하지만 영업 사원에게는 부족합니다. 영업 사원은 할일 관리보다 고객 관리가 중요합니다. 어떤 고객과 언제 연락했는지, 다음 미팅 일정은 언제인지, 거래 단계는 어디까지 진행되었는지 추적해야 합니다. 단순한 할일 앱으로는 이런 정보를 관리할 수 없습니다. 결국 Salesforce 같은 CRM 도구를 씁니다. 할일 앱은 가끔 참고용으로만 씁니다.

개발자에게도 부족합니다. 개발자는 할일을 체크하는 것보다 작업 흐름을 관리하는 게 중요합니다. 어떤 이슈가 진행 중인지, 어떤 브랜치에서 작업하는지, PR 리뷰는 누가 하는지를 추적해야 합니다. 단순한 할일 앱은 코드 작업과 연결되지 않습니다. 결국 Jira나 Linear 같은 이슈 트래커를 씁니다. 할일 앱은 개인 메모 정도로만 씁니다.

디자이너에게도 부족합니다. 디자이너는 작업 파일과 피드백을 함께 관리해야 합니다. 어떤 디자인에 어떤 피드백이 달렸는지, 수정 요청은 어떤 것인지 추적해야 합니다. 할일 앱은 파일과 연결되지 않습니다. 결국 Figma의 댓글 기능이나 Notion을 씁니다. 할일 앱은 간단한 리마인더 정도로만 씁니다.

결과는 어떻게 될까요? 세 집단 모두 할일 앱을 한두 번 써봅니다. 괜찮다고 생각합니다. 하지만 본업에는 쓰지 않습니다. 각자의 전문 도구를 이미 쓰고 있기 때문입니다. 할일 앱은 보조 도구로만 남습니다. 매일 쓰지 않습니다. Day 7 리텐션은 낮습니다. 결국 떠납니다.

이게 범용 서비스의 구조적 문제입니다. 모든 직군을 대상으로 하면 어떤 직군의 핵심 문제도 제대로 해결하지 못합니다. 각 직군은 이미 자신에게 맞는 도구를 쓰고 있습니다. 그 도구들은 해당 직군의 특수한 니즈를 정확히 해결합니다. 범용 서비스는 그 틈에 끼어들 수 없습니다.

실제로 이런 일이 2018년 국내 한 협업 도구 스타트업에서 일어났습니다. 이 서비스는 모든 팀을 위한 프로젝트 관리 도구를 표방했습니다. 개발팀도 쓸 수 있고, 마케팅팀도 쓸 수 있고, 영업팀도 쓸 수 있는 도구였습니다. 보드 뷰, 리스트 뷰, 캘린더 뷰를 모두 제공했습니다. 파일 공유, 댓글, 알림 기능이 있었습니다.

초기 3개월간 500개 팀이 가입했습니다. 다양한 업종과 팀 크기였습니다. 스타트업부터 중견기업까지, 개발팀부터 컨설팅 회사까지 다양했습니다. 운영자는 만족했습니다. 범용 전략이 통하는 것 같았습니다.

하지만 3개월 후 데이터를 보니 문제가 명확했습니다. 월간 활성 팀은 85개에 불과했습니다. 500개 팀 중 83%가 이미 이탈했습니다. 남은 85개 팀도 활발하게 쓰는 건 아니었습니다. 주 1회 미만 접속이 대부분이었습니다.

왜 그랬을까요? 각 팀에게 물어봤습니다. 개발팀은 이렇게 말했습니다. "코드 연동이 안 돼서 불편했어요. Jira는 GitHub과 연결되는데 여기는 안 되더라고요." 마케팅팀은 이렇게 말했습니다. "캠페인 성과를 추적할 수 없어서 결국 스프레드시트로 돌아갔어요." 영업팀은 이렇게 말했습니다. "고객 정보를 관리할 수 없어서 Salesforce를 계속 썼어요."

모든 팀이 같은 이유로 떠났습니다. 자신의 핵심 업무에 필요한 기능이 없었습니다. 범용 도구는 모든 팀의 공통 기능만 제공했습니다. 하지만 각 팀은 공통 기능이 아니라 자신만의 특수 기능이 필요했습니다. 개발팀은 코드 연동, 마케팅팀은 성과 추적, 영업팀은 고객 관리. 이런 기능 없이는 본업에 쓸 수 없었습니다.

외부 자문을 받은 운영팀은 방향을 전환하기로 했습니다. 한 집단만 선택하자. 그 집단의 문제를 완벽하게 해결하자. 데이터를 보니 개발팀의 리텐션이 상대적으로 높았습니다. 다른 팀은 첫 주에 80% 이상 이탈했지만 개발팀은 60% 수준이었습니다. 그래서 개발팀에만 집중하기로 했습니다.

모든 기능을 개발팀 관점으로 재설계했습니다. GitHub 연동을 추가했습니다. 이슈를 생성하면 자동으로 브랜치가 만들어지게 했습니다. PR이 머지되면 이슈가 자동 완료되게 했습니다. 코드 리뷰 상태를 보드에서 확인할 수 있게 했습니다. 배포 파이프라인과도 연결했습니다.

마케팅팀, 영업팀을 위한 기능은 모두 제거했습니다. 캠페인 관리 기능, 고객 정보 필드, 매출 추적 같은 건 다 없앴습니다. 오직 개발팀만을 위한 도구로 전환했습니다.

6개월 후 결과가 나타났습니다. 신규 가입 팀 수는 줄었습니다. 500개에서 200개로 떨어졌습니다. 하지만 활성 팀은 늘었습니다. 85개에서 150개로 올랐습니다. 리텐션이 17%에서 75%로 상승한 겁니다. 더 중요한 건 활성도였습니다. 개발팀은 매일 이 도구를 썼습니다. 일일 활성 사용자가 급격히 증가했습니다.

1년 후 입소문이 나기 시작했습니다. 한 회사의 개발팀이 쓰면 다른 회사 개발자가 추천받아 가입했습니다. 개발자 커뮤니티에서 입소문이 났습니다. 유료 전환율도 올랐습니다. 개발팀에게 이 도구는 필수가 되었기 때문에 기꺼이 돈을 냈습니다.

이 사례에서 배울 점은 명확합니다. 범용으로 500개 팀을 얻는 것보다 특정 집단에게 필수가 되어 150개 팀을 붙잡는 게 낫습니다. 150개 팀은 매일 쓰고, 입소문을 내고, 유료로 전환합니다. 500개 팀은 한 번 써보고 떠납니다.

물론 Google Docs나 Dropbox처럼 처음부터 범용으로 시작한 서비스도 있습니다. 하지만 이들은 막대한 기술력과 자본이 있었습니다. Google Docs는 Google의 검색 기술과 인프라가 뒷받침되었고, Dropbox는 기존에 없던 파일 동기화라는 완전히 새로운 개념을 제시했습니다. 0원 마케팅을 해야 하는 초기 창업자는 이런 예외에 속하지 않습니다.

범용 서비스가 실패하는 이유를 정리하면 이렇습니다.

다음 그림은 범용 서비스와 특화 서비스의 차이를 명확하게 보여줍니다.

범용 서비스는 모든 사람에게 70점이지만 특화 서비스는 특정 집단에게 100점입니다. 초기 서비스는 넓게 시작하는 것보다 좁고 깊게 시작하는 것이 성공 확률이 훨씬 높습니다.

첫째, 차별화가 불가능합니다.

모든 사람을 대상으로 하면 경쟁자도 많아집니다. 할일 관리 앱은 이미 수백 개가 있습니다. Todoist, Asana, Trello, TickTick, Microsoft To Do, Google Tasks. 모두 비슷한 기능을 제공합니다. 할일 등록, 마감일 설정, 체크 기능. 여기에 새로운 범용 할일 앱을 추가하면 어떻게 될까요. 사용자는 구분하지 못합니다. "또 할일 앱이네" 하고 넘어갑니다.

차별화하려면 특정 집단의 특수한 문제를 해결해야 합니다. Superhuman은 이메일 앱이지만 범용 이메일 앱이 아닙니다. 하루에 100통 이상의 이메일을 받는 바쁜 임원과 투자자를 위한 앱입니다. 키보드 단축키로 모든 작업을 3초 안에 끝낼 수 있습니다. Inbox Zero를 달성하는 데 최적화되어 있습니다. 이 집단에게는 Gmail과 완전히 다른 경험입니다. 그래서 월 30달러를 내고 씁니다.

둘째, 입소문이 나지 않습니다.

사람들은 "괜찮은" 서비스를 추천하지 않습니다. "완벽한" 서비스를 추천합니다. 범용 서비스는 대부분 괜찮은 수준에 머뭅니다. 누구에게나 70점입니다. 하지만 아무도 70점짜리 서비스를 친구에게 추천하지 않습니다.

반면 특정 집단에게 완벽한 서비스는 입소문을 탑니다. 그 집단 내에서 100점입니다. 사용자는 자발적으로 같은 집단의 사람들에게 추천합니다. "너 개발자지? 이거 써봐. 정말 좋아."

Notion이 초기에 성장한 방식이 이겁니다. Notion은 처음에 모든 사람을 위한 메모 앱이 아니었습니다. 복잡한 지식 작업을 하는 프로덕트 매니저와 엔지니어를 위한 도구였습니다. 이들은 문서를 쓰면서 동시에 데이터베이스를 관리하고, 작업 흐름을 설계하고, 지식을 체계화해야 했습니다. Notion은 이 모든 걸 하나의 도구에서 할 수 있게 만들었습니다. 이 집단에게는 완벽했습니다. 그래서 입소문이 났습니다. PM 커뮤니티, 스타트업 커뮤니티에서 퍼졌습니다.

Notion이 대중화된 건 그 이후입니다. 핵심 사용자 집단이 만족하고 입소문을 내면서 점점 더 많은 사람이 유입되었습니다. 학생, 프리랜서, 작가들도 쓰기 시작했습니다. 지금은 누구나 쓰는 범용 도구가 되었지만 시작은 범용이 아니었습니다.

셋째, 피드백이 산발적입니다.

초기 서비스는 사용자 피드백을 듣고 제품을 개선해야 합니다. 하지만 범용 서비스는 피드백이 일관되지 않습니다. 개발자는 코드 연동을 요청하고, 마케팅 담당자는 성과 추적을 요청하고, 디자이너는 파일 미리보기를 요청합니다. 모두 다릅니다. 어떤 피드백을 먼저 반영해야 할지 판단할 수 없습니다.

결국 모든 요청을 조금씩 반영하려고 합니다. 기능은 늘어나지만 방향은 흐려집니다. 제품은 복잡해지지만 누구에게도 완벽하지 않습니다. 1년이 지나도 핵심 사용자가 생기지 않습니다.

반면 특정 집단만 대상으로 하면 피드백이 일관됩니다. 개발팀만을 위한 도구라면 피드백도 개발 관련입니다. "GitHub Issue와 동기화되면 좋겠어요", "코드 리뷰 상태를 보드에서 보고 싶어요", "배포 상태를 추적하고 싶어요". 모두 같은 맥락입니다. 우선순위를 정하기 쉽습니다. 가장 많이 요청되는 기능부터 만들면 됩니다. 제품은 한 방향으로 진화합니다.

넷째, 유료 전환이 어렵습니다.

사람들은 필수 도구에 돈을 냅니다. 가끔 쓰는 도구에는 돈을 내지 않습니다. 범용 서비스는 대부분 가끔 쓰는 도구로 남습니다. 누구에게나 조금씩 유용하지만 누구에게도 필수가 아닙니다. 무료로 쓰다가 유료 전환 메시지가 나오면 떠납니다. 대체재가 많기 때문입니다.

특정 집단의 핵심 문제를 해결하는 서비스는 다릅니다. 그 집단에게는 필수입니다. 이 도구 없이는 일을 할 수 없습니다. 그래서 기꺼이 돈을 냅니다. Figma는 디자이너에게 필수입니다. 월 12달러를 냅니다. Linear는 개발팀에게 필수입니다. 팀원 한 명당 월 8달러를 냅니다. Ahrefs는 SEO 전문가에게 필수입니다. 월 99달러를 냅니다.

이들은 비싼 편입니다. 하지만 해당 집단은 가격이 문제가 아닙니다. 이 도구가 없으면 일의 효율이 절반으로 떨어지기 때문입니다. 반면 범용 할일 앱에 월 5달러를 내라고 하면 대부분 거절합니다. 꼭 필요한 도구가 아니기 때문입니다.

범용 서비스가 실패하는 이유를 한 문장으로 정리하면 이렇습니다. 누구에게나 조금씩 유용하지만 누구에게도 필수가 되지 못하기 때문입니다. 초기 서비스는 10만 명의 단순 방문자보다 100명의 필수 사용자가 필요합니다. 100명이 매일 쓰고 입소문을 내면 1000명이 됩니다. 1000명이 같은 일을 하면 1만 명이 됩니다. 하지만 10만 명의 가끔 사용자는 아무도 데려오지 않습니다. 그냥 조용히 떠납니다.

1.3.2 반드시 설정해야 하는 최초의 핵심 사용자 집단

그렇다면 어떤 집단을 선택해야 할까요? 처음에는 가능한 한 좁게 정의해야 합니다. 직군, 산업, 상황, 문제를 모두 구체적으로 지정해야 합니다. "모든 직장인"이 아니라 "시리즈 A 스타트업의 프로덕트 매니저"처럼 좁혀야 합니다.

좁게 정의하면 시장이 작아지지 않느냐고 걱정합니다. 맞습니다. 작아집니다. 하지만 그게 장점입니다. 시장이 작으면 도달하기 쉽습니다. 100만 명을 대상으로 하면 어디서부터 시작해야 할지 모릅니다. 하지만 1000명을 대상으로 하면 그들이 어디 있는지 찾을 수 있습니다. 특정 커뮤니티, 특정 행사, 특정 온라인 포럼에 모여 있습니다. 직접 찾아가서 말을 걸 수 있습니다.

핵심 사용자 집단을 설정하는 기준은 크게 네 가지입니다.

다음 그림은 핵심 사용자 집단을 선정할 때 반드시 확인해야 하는 4가지 체크리스트를 보여줍니다.

이 4가지 기준을 모두 만족하는 집단을 찾아야 합니다. 하나라도 빠지면 초기 서비스의 성공 가능성이 낮아집니다.

첫째, 명확하고 반복되는 문제를 가진 집단입니다.

문제가 애매하면 안 됩니다. "가끔 불편함"이 아니라 "매일 겪는 명확한 문제"여야 합니다. 그리고 그 문제가 반복되어야 합니다. 한 번 겪고 마는 문제를 해결하는 서비스는 일회성입니다. 1.1절에서 본 것처럼 일회성 서비스는 리텐션이 낮습니다.

예를 들어 프리랜서 디자이너를 대상으로 한다면 어떤 문제가 반복될까요? 클라이언트와의 커뮤니케이션, 수정 요청 관리, 작업 버전 관리, 인보이스 발행. 이런 문제들은 프로젝트마다 반복됩니다. 이 문제를 해결하는 도구는 매일 씁니다.

반면 "이력서 작성"은 어떨까요? 명확한 문제지만 반복되지 않습니다. 이력서는 몇 달에 한 번, 많아야 1년에 두세 번 씁니다. 이력서 작성 도구는 필요할 때만 씁니다. 리텐션이 낮습니다. 초기 서비스로는 적합하지 않습니다.

둘째, 기존 해결책이 불완전한 집단입니다.

이미 완벽한 도구가 있는 문제를 다시 풀 필요는 없습니다. 대신 기존 도구가 있지만 불만족스러운 영역을 찾아야 합니다. "이 도구를 쓰긴 하는데 불편해", "이 도구는 비싸서 대안을 찾고 있어", "이 도구는 우리 상황에 안 맞아" 같은 불만이 있는 집단을 찾습니다.

예를 들어 소규모 개발팀의 프로젝트 관리를 보겠습니다. Jira가 있지만 복잡합니다. 5명 이하 팀에는 과합니다. 설정에 하루가 걸립니다. 가격도 부담됩니다. 이 불만이 있다면 기회가 있습니다. Linear가 이 틈을 공략했습니다. Jira보다 훨씬 간단하고, 빠르고, 직관적인 도구를 만들었습니다. 소규모 스타트업 개발팀이라는 명확한 집단을 대상으로 했습니다.

반면 회계 소프트웨어는 어떨까요? 이미 완성도 높은 도구들이 있습니다. 회계 법인도 쓰고, 세무사도 쓰고, 기업도 씁니다. 불만이 거의 없습니다. 새로운 회계 소프트웨어로 이 시장에 진입하기는 매우 어렵습니다. 초기 서비스로는 적합하지 않습니다.

셋째, 도달 가능한 집단입니다.

아무리 좋은 대상이어도 찾을 수 없으면 소용없습니다. 그들이 어디 모이는지 알아야 합니다. 온라인 커뮤니티, 슬랙 채널, 디스코드 서버, 페이스북 그룹, 레딧 서브레딧, 오프라인 밋업. 어디든 모이는 곳이 있어야 합니다. 그래야 직접 찾아가서 피드백을 받고, 베타 테스트를 요청하고, 입소문을 낼 수 있습니다.

예를 들어 한국의 초기 스타트업 창업자를 대상으로 한다면 어디서 찾을 수 있을까요? 퍼블리, 디스콰이엇, 링크드인의 스타트업 그룹, 각종 창업 커뮤니티. 오프라인으로는 스타트업 얼라이언스, 디캠프, 구글 캠퍼스 같은 곳에서 밋업이 열립니다. 찾을 수 있습니다.

반면 "부업으로 쇼핑몰을 운영하는 30대 주부"는 어떨까요? 명확한 집단이지만 어디 모이는지 찾기 어렵습니다. 특정 커뮤니티가 없습니다. 도달하기 어렵습니다. 초기 서비스로는 적합하지 않습니다.

넷째, 지갑을 열 의향이 있는 집단입니다.

초기 서비스는 결국 수익을 만들어야 생존합니다. 문제를 해결해도 돈을 내지 않는 집단은 피해야 합니다. 특히 예산이 없거나, 무료에 익숙하거나, 결제 의사 결정권이 없는 집단은 초기 대상으로 적합하지 않습니다.

예를 들어 중학생을 대상으로 하면 어떨까요? 명확한 집단이고, 도달 가능하고, 반복되는 문제도 있습니다. 하지만 스스로 결제할 수 없습니다. 부모를 설득해야 합니다. 의사결정 과정이 복잡합니다. 초기 서비스로는 어렵습니다.

반면 스타트업 창업자는 어떨까요? 명확한 문제가 있고, 해결책에 기꺼이 돈을 냅니다. 본인이 직접 결제를 결정합니다. 좋은 도구라면 당장 유료 전환합니다. 초기 대상으로 적합합니다.

이 네 가지 기준을 모두 만족하는 집단을 찾아야 합니다. 그 집단을 최대한 좁게 정의합니다. 그리고 그들의 문제를 완벽하게 해결하는 데 집중합니다.

실제로 성공한 서비스들의 초기 대상을 보면 얼마나 좁게 시작했는지 알 수 있습니다.

Airbnb는 2008년에 샌프란시스코에서 열린 디자인 컨퍼런스 참가자를 대상으로 시작했습니다. 컨퍼런스 기간에 호텔이 만석이어서 숙소를 구하지 못한 디자이너들. 이게 최초의 핵심 사용자 집단이었습니다. 며칠짜리 행사 참가자라는 아주 좁은 집단이었습니다. 하지만 명확한 문제가 있었고, 도달 가능했고, 돈을 낼 의향이 있었습니다.

Uber는 2010년 샌프란시스코의 테크 업계 종사자를 대상으로 시작했습니다. 밤늦게 퇴근할 때 택시를 잡기 어려운 엔지니어와 디자이너들. 이들은 스마트폰을 쓸 줄 알았고, 새로운 앱을 시도하는 데 거부감이 없었고, 편의를 위해 프리미엄을 낼 의향이 있었습니다.

Instagram은 2010년 샌프란시스코의 얼리어답터를 대상으로 시작했습니다. 아이폰 사진을 멋지게 꾸미고 싶어 하는 사람들. 이들은 새 앱을 매일 찾아보고, 친구들에게 추천하는 습관이 있었습니다. 입소문이 빠르게 퍼졌습니다.

공통점이 보입니까. 모두 지역과 집단을 아주 좁게 시작했습니다. 전 세계가 아니라 샌프란시스코. 모든 사람이 아니라 특정 직군이나 상황의 사람들. 이렇게 좁게 시작했기 때문에 그 집단의 문제를 완벽하게 해결할 수 있었습니다. 그리고 그 집단 안에서 입소문이 났습니다. 확산은 그 다음 일입니다.

한국의 경우도 마찬가지입니다. 당근마켓은 판교 신도시 주민을 대상으로 시작했습니다. 신도시라서 이사 온 지 얼마 안 된 사람들이 많았습니다. 쓰지 않는 물건이 많고, 동네에서 거래할 의향이 높았습니다. 이 집단에게 완벽한 서비스를 만들었고, 판교에서 입소문이 났습니다. 그 다음 분당, 그 다음 수도권, 그 다음 전국으로 확산되었습니다.

토스는 20대 직장인을 대상으로 시작했습니다. 은행 앱이 불편하고, 송금 수수료가 부담스럽고, 간편한 금융 서비스를 원하는 집단. 이들에게 송금 기능 하나만 완벽하게 만들었습니다. 계좌번호 입력 없이 전화번호만으로 송금. 수수료 무료. 이 하나의 기능으로 입소문이 났습니다. 그 다음 다른 금융 서비스를 추가했습니다.

오늘의집은 20~30대 1인 가구를 대상으로 시작했습니다. 원룸이나 작은 아파트에 사는 사람들. 인테리어에 관심은 있지만 전문 업체를 쓸 예산은 없는 집단. 이들이 모방할 수 있는 저렴한 인테리어 사례를 모았습니다. 이 집단 안에서 입소문이 났습니다.

이 사례들에서 배울 점은 명확합니다. 처음부터 모두를 대상으로 하지 않았습니다. 아주 좁은 집단을 정했습니다. 그 집단의 문제를 완벽하게 해결했습니다. 그 집단이 입소문을 냈습니다. 확산은 자연스럽게 일어났습니다.

그렇다면 어떻게 최초의 핵심 사용자 집단을 찾을 수 있을까요? 구체적인 방법은 이렇습니다.

다음 그림은 핵심 사용자 집단을 찾는 5단계 프로세스를 보여줍니다.

이 5단계를 순서대로 진행하면 최초의 100명을 찾을 수 있습니다. 각 단계를 건너뛰지 말고 충분한 시간을 투자해야 합니다.

1단계: 자신이 속한 집단에서 시작합니다.

가장 쉬운 방법은 자신이 겪는 문제를 해결하는 것입니다. 자신이 개발자라면 개발자의 문제를 풉니다. 디자이너라면 디자이너의 문제를 풉니다. 왜냐하면 그 집단을 가장 잘 알기 때문입니다. 어떤 도구를 쓰는지, 무엇이 불편한지, 어디서 시간을 낭비하는지 직접 경험으로 알고 있습니다.

GitHub는 개발자가 개발자를 위해 만들었습니다. 창업자들이 Git을 쓰면서 불편했던 점을 해결했습니다. Figma는 디자이너가 디자이너를 위해 만들었습니다. 창업자가 Photoshop과 Sketch를 쓰면서 느낀 불편함을 해결했습니다.

명확한 직군이 없다면 어떻게 할까요? 최근 1년간 가장 많은 시간을 보낸 활동을 생각해보세요. 취미, 부업, 관심사도 괜찮습니다. 또는 주변에서 자주 들어온 불평이 무엇인지 생각해보세요. "요즘 이거 진짜 불편해" 같은 말을 반복해서 들었다면, 그게 시작점이 될 수 있습니다.

자신이 속하지 않은 집단의 문제를 풀고 싶다면 최소 3개월은 그 집단을 관찰하고 인터뷰하는 데 투자하세요. 그들의 일상을 깊이 이해해야 합니다. 최소 수십 명과 인터뷰하고, 그들의 작업 과정을 관찰하고, 몇 달간 함께 지내야 합니다. 시간이 오래 걸립니다. 초기 창업자에게는 부담됩니다.

2단계: 집단을 계속 좁힙니다.

처음 떠오른 집단은 대부분 너무 넓습니다. "개발자"는 너무 넓습니다. 프론트엔드 개발자, 백엔드 개발자, 데이터 엔지니어, DevOps 엔지니어가 모두 다릅니다. 한 단계 더 좁힙니다. "프론트엔드 개발자"도 여전히 넓습니다. 대기업, 스타트업, 프리랜서가 다릅니다. 한 단계 더 좁힙니다. "시리즈 A~B 스타트업의 프론트엔드 개발자". 이제 구체적입니다. 이 집단은 몇천 명 수준입니다. 도달 가능합니다.

좁힐 때는 이런 기준을 씁니다.

• 회사 규모: 대기업 vs 스타트업 vs 프리랜서
• 경력: 주니어 vs 시니어
• 산업: 핀테크 vs 이커머스 vs SaaS
• 지역: 서울 vs 지방 vs 글로벌
• 상황: 혼자 일하는 vs 팀으로 일하는

이 중 한두 가지를 조합해서 집단을 정의합니다. 너무 좁으면 어쩌나 걱정하지 않아도 됩니다. 1000명만 있어도 충분합니다. 그들 모두가 당신의 서비스를 쓴다면 입소문이 납니다.

3단계: 그 집단이 모이는 곳을 찾습니다.

집단을 정의했으면 그들이 어디 있는지 찾아야 합니다. 온라인이든 오프라인이든 모이는 곳이 있어야 합니다. 없다면 잘못 정의한 겁니다. 다시 정의해야 합니다.

찾는 방법은 간단합니다. 구글에서 검색합니다. "프론트엔드 개발자 커뮤니티", "프론트엔드 개발자 슬랙", "프론트엔드 개발자 밋업". 한국에서는 네이버 카페, 오픈카톡, 단톡방, 퍼블리, 디스콰이엇 같은 플랫폼을 먼저 확인합니다. 글로벌 대상이라면 페이스북 그룹, 디스코드 서버, 레딧 서브레딧을 찾습니다. 링크드인에서 해당 직군 사람들을 검색합니다.

찾았으면 직접 들어갑니다. 며칠간 관찰합니다. 어떤 이야기를 하는지, 무엇을 불평하는지, 어떤 도구를 추천하는지 봅니다. 패턴이 보입니다. "요즘 이 도구 쓰는 사람 있어요?" "이거 어떻게 해결하세요?" 같은 질문이 반복됩니다. 이게 바로 해결해야 할 문제입니다.

4단계: 10명과 직접 대화합니다.

커뮤니티에서 관찰만 하지 말고 직접 대화를 시작합니다. "프론트엔드 개발하시는 분들께 질문 있습니다"라고 글을 올립니다. 또는 DM을 보냅니다. 실제 메시지 예시는 이렇습니다.

"안녕하세요. 저는 프론트엔드 개발자를 위한 도구를 만들고 있는 김개발입니다. 현업자의 의견을 듣고 싶어서 연락드렸습니다. 30분 정도 화상 통화나 텍스트로 이야기 나눌 수 있을까요? 감사의 표시로 스타벅스 기프티콘을 보내드리겠습니다."

10명에게 DM을 보내면 3~4명만 응답하는 게 정상입니다. 거절당해도 포기하지 마세요. 계속 시도하면 결국 10명과 대화할 수 있습니다. 줌이나 구글 미트로 진행하면 부담이 적습니다. 카메라는 꺼도 됩니다.

10명과 대화하면 충분합니다. 문제가 진짜인지, 기존 해결책이 왜 부족한지, 어떤 대안을 원하는지 알 수 있습니다. 10명이 모두 비슷한 이야기를 한다면 확신을 가져도 됩니다. 이게 진짜 문제입니다.

대화할 때 주의할 점이 있습니다. 자신의 아이디어를 설명하지 않습니다. 대신 그들의 현재 상황을 물어봅니다. "지금 어떤 도구를 쓰세요?" "어떤 점이 불편하세요?" "이상적으로는 어떻게 되면 좋겠어요?" 이런 질문을 합니다. 그들의 답변에서 진짜 문제를 찾습니다.

5단계: 가설을 세우고 빠르게 검증합니다.

10명과 대화한 후 가설을 세웁니다. "시리즈 A 스타트업의 프론트엔드 개발자는 컴포넌트 버전 관리가 어렵다. 기존 도구는 복잡하거나 비싸다. 간단하고 저렴한 대안이 필요하다." 이런 가설입니다.

이 가설을 검증하려면 MVP를 만듭니다. 최소 기능만 있는 버전입니다. 화려할 필요 없습니다. 핵심 문제만 해결하면 됩니다. 1~2주 안에 만들 수 있는 수준이어야 합니다.

만들었으면 대화했던 10명에게 보여줍니다. "이거 써보시겠어요?" 반응을 봅니다. "오, 이거 괜찮은데요"라고 하면 성공입니다. "음, 근데 이건 좀..."이라고 하면 다시 물어봅니다. "어떤 점이 아쉬우세요?" 피드백을 받고 수정합니다.

10명 중 3명 이상이 "이거 계속 쓰고 싶어요"라고 하면 방향이 맞습니다. 이제 더 많은 사람에게 공개합니다. 커뮤니티에 "베타 테스터 모집합니다"라고 글을 올립니다. 50명이 신청하면 좋은 신호입니다.

이렇게 최초의 핵심 사용자 집단을 설정하고 검증합니다. 처음에는 10명, 다음에는 50명, 다음에는 200명. 조금씩 늘려갑니다. 하지만 집단은 계속 좁게 유지합니다. 시리즈 A 스타트업의 프론트엔드 개발자에게 완벽한 도구를 만드는 데 집중합니다. 시리즈 C 대기업이나 백엔드 개발자는 나중 일입니다.

집단을 좁게 유지하는 게 불안할 수 있습니다. 시장이 너무 작은 것 같고, 성장이 제한될 것 같습니다. 하지만 실제로는 반대입니다. 좁은 집단에게 완벽한 서비스를 만들면 입소문이 납니다. 그 입소문이 인접 집단으로 퍼집니다. 시리즈 A 프론트엔드 개발자가 만족하면 시리즈 B 개발자도 관심을 갖습니다. 다음에는 백엔드 개발자도 써봅니다. 자연스럽게 확장됩니다.

반대로 처음부터 모든 개발자를 대상으로 하면 아무도 만족시키지 못합니다. 프론트엔드 개발자는 "내 문제를 해결 못하네" 하고 떠나고, 백엔드 개발자도 "나랑 안 맞네" 하고 떠납니다. 입소문이 나지 않습니다. 성장이 멈춥니다.

1.3.3 정리

범용 서비스는 초기 단계에서 실패합니다. 모든 사람을 위한 서비스는 누구에게도 필수가 되지 못하기 때문입니다. 차별화가 불가능하고, 입소문이 나지 않고, 피드백이 산발적이고, 유료 전환이 어렵습니다.

성공한 서비스들은 처음부터 범용이 아니었습니다. 아주 좁은 집단을 정했습니다. 그 집단의 문제를 완벽하게 해결했습니다. 그 집단 안에서 필수 도구가 되었습니다. 입소문이 났습니다. 그 다음 조금씩 확장했습니다.

최초의 핵심 사용자 집단을 설정할 때는 네 가지 기준을 확인해야 합니다. 명확하고 반복되는 문제를 가진 집단인가. 기존 해결책이 불완전한가. 도달 가능한가. 지갑을 열 의향이 있는가. 이 네 가지를 모두 만족하는 집단을 찾아야 합니다.

집단은 가능한 한 좁게 정의해야 합니다. 직군, 회사 규모, 경력, 산업, 지역을 구체적으로 지정합니다. 1000명 정도면 충분합니다. 그들이 모이는 곳을 찾고, 직접 대화하고, 문제를 검증합니다. MVP를 만들어 보여주고 피드백을 받습니다.

10명이 만족하면 50명에게 공개합니다. 50명이 만족하면 200명에게 공개합니다. 하지만 집단은 계속 좁게 유지합니다. 그 집단에게 완벽한 서비스를 만드는 데 집중합니다. 확장은 그 다음입니다.

지금 당신의 서비스는 누구를 위한 것입니까. "모두"라고 답한다면 다시 생각해야 합니다. 최초의 100명은 누구입니까. 그들은 어디 모입니까. 그들에게 어떤 문제가 있습니까. 이 질문에 구체적으로 답할 수 있다면 0원 마케팅을 시작할 준비가 된 것입니다.

1.1절에서 리텐션을 확인했습니다. 1.2절에서 아하 모먼트를 정의했습니다. 1.3절에서 핵심 사용자 집단을 설정했습니다. 이 세 가지가 준비되었다면 이제 진짜 마케팅을 시작할 수 있습니다. 다음 장부터는 예산 없이 이 핵심 사용자 집단에게 도달하는 구체적인 방법을 다룹니다.