사이드 프로젝트·SaaS 첫 100명 사용자 모으는 법

첫 100명의 사용자는 거의 틀림없이 기발한 그로스 트릭 하나에서 오지 않습니다. 작고 손이 많이 가는 단계들이 쌓여서 옵니다. 실제 문제를 가진 좁은 집단을 고르고, 그 사람들이 이미 이야기를 나누는 곳을 찾고, 한 사람씩 연락하고, 그들이 살펴보는 곳에 제품을 두고, 새 사용자가 실제로 가치를 얻는지 확인하는 것입니다. 처음에는 느리지만, 무엇이 통하는지 알아 갈수록 빨라집니다.

목표는 가입자 100명이 아닙니다. 제품이 실제로 도움이 된 순간에 도달한 사람 100명입니다. 호기심에 들렀다가 다시 오지 않은 방문자의 계정 100개보다, 매주 제품을 쓰면서 무엇이 부족한지 말해 주는 20명에게서 더 많이 배웁니다.

마케팅 예산 없이, 누구에게도 스팸을 보내지 않고 사이드 프로젝트나 작은 SaaS로 그 지점에 이르는 실용적인 방법을 소개합니다.

첫 100명의 사용자가 특별한 이유

초기 사용자는 주된 매출원이 아닙니다. 가장 좋은 정보원입니다. 누가 실제로 제품을 필요로 하는지, 그들이 문제를 어떤 말로 설명하는지, 어디서 막히는지, 무엇에 돈을 낼지 보여 줍니다.

그래서 일하는 방식도 달라져야 합니다. 사용자가 몇 명 되지 않으니 한 명에게 한 시간씩 써도 됩니다. 아직 아무도 제품에 의존하지 않으니 매주 제품을 바꿔도 됩니다. 그리고 찾아오는 사람을 아무나 받는 대신, 원하는 사용자를 정확히 고를 수 있습니다.

사용자를 좁게 정의하는 것부터 시작하세요

"소상공인"이나 "크리에이터"는 실행에 옮기기엔 너무 넓습니다. 세 가지를 담은 한 문장을 써 보세요. 구체적인 유형의 사람, 그들이 처한 구체적인 상황, 그리고 지금 쓰고 있는 번거로운 우회 방법입니다.

예를 들면 이렇습니다. 여러 통화로 고객에게 청구서를 보내면서 지금은 청구서를 하나하나 스프레드시트로 직접 만드는 프리랜서 번역가. 이런 문장은 어디를 찾아봐야 하는지(번역가 포럼과 그룹), 무엇을 말해야 하는지(스프레드시트 없이 여러 통화를 처리하는 청구서), 그리고 당분간 누구를 신경 쓰지 않아도 되는지 알려 줍니다.

대상은 나중에 넓히면 됩니다. 좁게 시작하면 이 가이드의 다른 모든 단계가 쉬워집니다.

확장되지 않는 일을 하세요

Paul Graham의 에세이 Do Things That Don't Scale은 창업자들 사이에서 이 조언을 유명하게 만들었고, 지금도 유효합니다. 처음에는 나중에 자동화할 일을 손으로 하세요.

• 짧은 통화나 채팅으로 사용자 온보딩을 직접 진행합니다.
• 사용자 대신 계정을 설정하고, 데이터를 가져오거나 첫 프로젝트를 만들어 줍니다.
• 직접 쓴 환영 이메일을 내 주소로 보냅니다.
• 제보받은 버그는 당일에 고치고, 제보한 사람에게 알립니다.
• 제품의 일부가 아직 만들어지지 않았다면, 간단한 인터페이스 뒤에서 그 부분을 수작업으로 처리합니다.

이건 친절함만의 문제가 아닙니다. 실제 사람들이 제품을 쓰는 모습을 지켜보는 것이 헷갈리는 화면, 빠진 기능, 그리고 사용자가 시간을 들일 가치가 있다고 판단하는 순간을 찾는 가장 빠른 방법입니다.

사용자들이 이미 이야기하는 곳을 찾으세요

사용자들은 이미 어딘가에서 자신의 문제를 이야기하고 있습니다. 무언가를 올리기 전에 그곳을 찾는 것이 여러분의 일입니다.

살펴볼 만한 곳은 다음과 같습니다.

• 그들의 직업이나 취미를 다루는 서브레딧과 포럼.
• 유료 커뮤니티를 포함한 Discord와 Slack 커뮤니티.
• Facebook과 LinkedIn 그룹.
• Q&A 사이트, 그리고 여러분의 제품과 비슷한 도구의 GitHub 이슈.
• 해당 분야 튜토리얼과 영상에 달린 댓글.
• 경쟁 제품의 리뷰. 불만 속에 채워지지 않은 니즈가 보입니다.
• 지역 밋업, 직능 협회, 니치 뉴스레터.

간단하게 시작하려면 문제 자체를 "reddit", "포럼", "추천" 같은 단어와 함께 검색해 보세요. 스레드를 읽으세요. 사람들이 쓰는 정확한 표현, 언급하는 도구, 계속 반복되는 질문을 적어 두세요.

장소마다 자기 홍보 규칙과 그곳에서 사람들이 묻는 내용을 스프레드시트에 정리해 두세요. 아웃리치, 콘텐츠, 런칭을 위한 지도가 됩니다.

정중한 직접 아웃리치

직접 아웃리치는 첫 사용자를 얻는 가장 확실한 방법이면서, 가장 잘못하기 쉬운 방법이기도 합니다. 도움이 되는 연락과 스팸의 차이는 대부분 관련성과 말투에서 갈립니다.

1. 문제를 공개적으로 이야기한 사람을 찾으세요. 도구를 찾는 포럼 글, 우회 방법에 대한 불평, 커뮤니티에 올라온 질문 같은 것입니다.
2. 먼저 공개적으로 도우세요. 질문에 제대로 답하세요. 제품은 잘 맞을 때만 언급하고, 직접 만들었다고 밝히세요.
3. 개인 메시지는 짧고 구체적으로 쓰세요. 상대가 쓴 글을 언급하고, 무엇을 만들었는지 한두 문장으로 설명한 뒤, 써 보고 헷갈리는 점을 알려 달라는 식으로 작은 부탁 하나만 하세요.
4. 실질적인 것을 제안하세요. 초기 기간 무료 이용, 설정 도움, 또는 그 사람의 상황에 맞춘 기능 같은 것입니다.
5. 후속 연락은 한 번만 하고 멈추세요. 침묵도 대답입니다.

메시지는 이 정도로 간단해도 됩니다. "세 가지 통화로 청구서를 관리하느라 고생하신다는 글을 봤습니다. 딱 그 문제를 위한 작은 도구를 만들었어요. 청구서 하나만 만들어 보시고 헷갈리는 점을 알려 주실 수 있을까요? 설정은 제가 해 드릴게요."

대량 콜드 메시지를 보내지 말고, 이메일 주소를 스크래핑하지 말고, 각 플랫폼의 규칙은 물론 여러분과 연락받는 사람들에게 적용되는 스팸 방지법과 개인정보 보호법을 지키세요.

빌드 인 퍼블릭

빌드 인 퍼블릭은 진행 상황을 공개적으로 공유하는 것입니다. 무엇을 출시했는지, 무엇을 배웠는지, 무엇이 잘못됐는지, 그리고 공개해도 괜찮은 수치까지요. 사람들은 이야기를 따라갑니다. X, LinkedIn, Indie Hackers나 개인 블로그에 솔직한 업데이트를 꾸준히 올리면, 제품에 관심을 갖는 독자층이 천천히 쌓입니다.

주의할 점이 두 가지 있습니다. 첫째, 빌드 인 퍼블릭은 고객보다 다른 메이커를 더 많이 끌어들이는 경우가 많으니, 자신의 여정만이 아니라 사용자의 문제에 대해서도 쓰세요. 둘째, 효과가 천천히 쌓입니다. 아웃리치를 대신하는 것이 아니라 아웃리치와 함께 하는 일로 생각하세요.

실제 질문에 답하는 콘텐츠

커뮤니티를 조사하며 모은 질문들은 그대로 콘텐츠 계획이 됩니다. 가장 자주 나오는 질문을 골라 할 수 있는 최고의 답을 쓰세요. 가이드, 짧은 영상, 템플릿, 체크리스트, 작은 무료 도구 등 어떤 형태든 좋습니다.

제품은 정말로 문제를 해결하는 곳에서만 언급하고, 가입하지 않는 독자에게도 유용한 콘텐츠로 만드세요. 그런 다음 그 질문이 나왔던 커뮤니티에 공유하면, 다음에 같은 질문을 하는 사람에게 답이 됩니다. 시간이 지나면 검색 유입도 생길 수 있지만, 새 사이트라면 보통 몇 달이 걸립니다.

런칭 플랫폼으로 첫 사용자를 한꺼번에 모으세요

런칭 플랫폼과 디렉터리는 짧은 시간에 많은 첫 방문자를 데려올 수 있습니다. Product Hunt, Hacker News의 Show HN, Indie Hackers, 카테고리 디렉터리, 쇼케이스 사이트에는 모두 새로운 것을 써 보길 좋아하는 사람들이 모여 있습니다.

런칭은 그 자체로 성과가 아니라 사용자로 전환해야 할 일시적인 급증으로 보세요. 런칭 전에 새 방문자가 제품을 빠르게 써 볼 수 있는지, 어느 단계를 활성화로 볼지 정했는지, 피드백을 쉽게 보낼 방법이 있는지 확인하세요. 앱을 출시한다면 모바일 앱 출시 가이드에서 스토어별 단계를 다룹니다.

쇼케이스 사이트는 여기에 더하는 작지만 영구적인 채널입니다. 예를 들어 One Dollar Planet에서는 1달러로 프로젝트를 행성 위에 올릴 수 있고, 행성을 둘러보거나 프로젝트 카탈로그를 살펴보는 사람들을 위해 계속 그 자리에 남습니다. 아웃리치를 대신하지는 못하지만, 호기심 많은 사람들이 여러분의 작업을 우연히 발견할 수 있는 곳이 하나 더 생기는 셈입니다.

파트너십과 연동

다른 제품과 사람들은 이미 여러분이 원하는 사용자들의 관심을 받고 있습니다. 그들과 협업하는 편이 처음부터 독자층을 쌓는 것보다 빠른 경우가 많습니다.

• 연동. 사용자들이 의존하는 도구가 있다면, 그 도구와 연동하고 마켓플레이스나 연동 디렉터리에 제품을 등록하세요. 그런 디렉터리를 둘러보는 사람들은 이미 애드온을 찾고 있습니다.
• 뉴스레터, 크리에이터, 커뮤니티 운영자. 그들의 독자에게 유용한 것을 제안하세요. 무료 이용권, 튜토리얼, 기고 글 같은 것입니다. 홍보해 달라고 부탁하기보다 무엇이 도움이 될지 물어보세요.
• 보완 제품. 같은 사용자를 대상으로 하지만 경쟁하지 않는 도구는 공동 튜토리얼, 번들, 상호 언급을 위한 좋은 파트너가 될 수 있습니다.
• 프리랜서와 에이전시. 매일 여러분의 사용자를 상대하는 사람들은 여러분을 한 번에 많은 사람에게 추천해 줄 수 있습니다.

작은 제품에 맞는 추천 루프

추천은 위에 덧붙인 캠페인이 아니라 공유가 제품 사용의 일부일 때 가장 잘 작동합니다.

• 공유할 수 있는 결과물. 공개 페이지, 공유 문서, 보고서처럼 사용자가 만든 것을 다른 사람들이 보게 된다면, 거기에 여러분에게 돌아오는 작은 링크를 넣을 수 있습니다. 사용자가 끌 수 있게 해 주세요.
• 협업. 팀원이나 고객을 초대해 함께 작업하게 하면 새 사용자가 자연스럽게 들어옵니다.
• 양쪽 모두 받는 보상. 초대한 사람과 초대받은 사람이 모두 추가 크레딧이나 한 달 무료 같은 보상을 받습니다.
• 그냥 물어보세요. 누군가 제품이 마음에 든다고 말하면, 이 제품이 유용할 만한 사람을 한 명 알고 있는지 물어보세요.

추천 장치는 이미 있는 것을 증폭할 뿐입니다. 초기 사용자가 실제 가치를 얻지 못하고 있다면, 그것부터 고치세요.

가입 수가 아니라 활성화를 측정하세요

가입 수는 세기 쉽고, 잘못 해석하기도 쉽습니다. 중요한 건 제품이 실제로 유용한 일을 해 준 지점에 도달한 사람이 몇 명인가입니다.

1. 활성화 이벤트를 정의하세요. 실제 가치를 처음 경험하는 순간입니다. 첫 청구서 발송, 첫 보고서 생성, 첫 프로젝트 게시 같은 것입니다.
2. 매주 세 가지 숫자를 추적하세요. 신규 가입자, 그중 활성화된 사람, 그리고 다음 주에 다시 돌아온 사람입니다.
3. 각 사용자가 어디서 왔는지 추적하세요. 링크에 UTM 파라미터를 붙이고, 가입할 때 "저희를 어떻게 알게 되셨나요?"라고 물어보세요.
4. 활성화되지 않은 사람들과 이야기하세요. 무엇 때문에 멈췄는지 묻는 짧고 친근한 이메일 한 통이 온보딩의 가장 큰 문제를 드러내는 경우가 많습니다.
5. 채널을 비교하세요. 가입자는 더 적어도 활성화된 사용자를 더 많이 보내는 채널이 더 나은 채널입니다.

첫 100명이라면 스프레드시트로 충분합니다. 대시보드는 한자리에서 다 읽을 수 없을 만큼 데이터가 쌓인 뒤에 만들어도 됩니다.

첫 100명 사용자를 위한 6주 계획

저녁과 주말 시간에 맞춘 대략적인 계획입니다.

1. 1주 차: 사용자를 정의하는 한 문장을 쓰고, 그 사용자들이 이야기하는 곳 20군데를 목록으로 만들고, 활성화를 정의하고, 추적을 설정합니다.
2. 2주 차: 공개 답변과 개인 메시지로 실제 대화를 20번에서 30번 나누고, 새 사용자마다 직접 온보딩합니다.
3. 3주 차: 지켜보며 발견한 가장 큰 문제 세 가지를 고치고, 자주 나오는 질문에 답하는 콘텐츠 두 편을 발행합니다.
4. 4주 차: 플랫폼 한 곳과, 허용하는 커뮤니티들에서 런칭합니다.
5. 5주 차: 디렉터리에 등록하고, 파트너가 될 만한 곳에 연락하고, 간단한 추천 요청을 시작합니다.
6. 6주 차: 채널별 활성화를 검토하고, 가장 잘 되는 두 채널에 시간 대부분을 쏟습니다.

이 숫자들은 예측이 아니라 노력의 목표치입니다. 이 기간 안에 활성 사용자 100명에 도달하는 제품도 있고, 여러 번 반복해야 하는 제품도 있습니다. AI 도구로 빠르게 만들었는데 제품이 아직 불안정하게 느껴진다면, 바이브 코딩 가이드에서 더 많은 사람을 초대하기 전에 제품을 안정시키는 방법을 다룹니다.

핵심 정리

• 첫 100명의 사용자는 하나의 트릭이 아니라 손이 많이 가는 작은 단계들에서 옵니다.
• 사용자를 좁게 정의한 다음, 그 사람들이 이미 이야기하는 곳을 찾으세요.
• 아웃리치는 개인적이고, 관련 있고, 내가 누구인지 솔직하게 밝힐 때 효과가 있습니다.
• 런칭, 콘텐츠, 파트너, 추천은 도달 범위를 넓혀 주지만, 제품이 초기 사용자에게 제대로 작동한 다음의 일입니다.
• 가입 수가 아니라 활성화된 사용자 수와 그들이 어디서 왔는지를 세세요.

자주 묻는 질문

첫 100명의 사용자를 모으는 데 얼마나 걸리나요?

제품, 대상, 들이는 시간에 따라 크게 다릅니다. 파트타임으로 만든 사이드 프로젝트라면 몇 주에서 몇 달까지 걸리는 경우가 흔합니다. 보통 런칭 날짜보다 꾸준한 아웃리치와 빠른 수정이 더 중요합니다.

첫 사용자를 모으려면 광고를 해야 하나요?

맨 처음에는 보통 필요 없습니다. 광고로 방문자를 데려올 수는 있지만, 가장 좋은 사용자가 누구이고 무엇이 그들을 활성화시키는지 알기 전에는 광고 타기팅도 결과 판단도 어렵습니다. 먼저 사용자와 이야기하고, 좋은 사용자가 어떤 모습인지 알게 된 뒤에 적은 예산으로 테스트하세요.

초기 사용자에게 제품을 무료로 제공해도 괜찮나요?

네. 피드백을 받는 대가로 무료나 할인 이용을 제공하는 것은 흔하고 공정한 일입니다. 얼마 동안 유지되는지, 그 뒤에는 어떻게 되는지 분명히 알리세요. 유료화할 계획이라면 초기 사용자에게 돈을 낼 의향이 있는지 묻고, 적절한 시점이 되는 대로 몇 명을 유료 사용자로 전환해 보세요.

사용자로 세는 기준은 가입자인가요, 활성 사용자인가요?

의사결정에는 활성 사용자를 세세요. 활성화 이벤트에 도달했고, 이상적으로는 다시 돌아온 사람들입니다. 가입자 수는 퍼널 상단 지표로는 유용하지만, 제품이 실패하는 동안에도 늘어날 수 있습니다. 정의를 한 번 정하고 일관되게 쓰세요.

아웃리치에 아무도 답하지 않으면 어떻게 하나요?

세 가지를 확인하세요. 문제를 분명히 이야기한 사람에게 연락하고 있는지, 메시지가 짧고 구체적인지, 부탁이 작은지입니다. 그래도 답이 오지 않는다면 그 문제가 생각보다 덜 절실한 것일 수 있습니다. 대화를 몇 번 더 나눠 보면 문제를 더 날카롭게 정의할 방향이 보입니다.