4개의 SaaS를 모두 100K MRR까지 키운 사람, 무엇이 진짜 비결인가

100K MRR SaaS를 네 번 만든 사람, 우리가 먼저 봐야 할 포인트

퇴근 후 노트북을 열고 사이드 프로젝트를 켜는 사람이라면 한 번쯤 이런 계산을 해본 적이 있습니다. 월 10만 원도 벌기 힘든 SaaS를, 누군가는 네 개나 10만 달러 이상으로 키웠다는 사실이 꽤 얄밉게 느껴집니다. 같은 인터넷, 같은 AI를 쓰는데 왜 결과는 이렇게 다를까 하는 생각이 자연스럽습니다.

프랑스 개발자 티보가 만든 그림은 단순합니다. 여러 개의 앱을 동시에 굴리고, 각 앱이 매달 10만 달러 이상을 벌어들이며, 전체 포트폴리오가 매달 수십 퍼센트씩 성장합니다. 화려한 숫자 뒤에 있는 핵심은 거창한 전략이 아니라 아주 지독한 습관에 가깝습니다. 몇 주 안에 만들 수 있는 것만 만들고, 초기 사용자에게 매일 말을 걸고, 그들이 떠나지 못할 정도로 집착스럽게 제품을 뜯어고치는 태도입니다.

국내 환경에서 이 이야기가 의미를 가지려면 한 가지를 먼저 짚어야 합니다. 대규모 자본과 영업조직에 기대는 B2B 솔루션 비즈니스가 아니라, 개발자나 소규모 팀이 빠르게 만들고 바로 판매하는 인터넷 네이티브 SaaS라는 전제입니다. 월급에 더해 두 번째 소득원을 만들고 싶은 1인 개발자에게는 꽤 현실적인 모델이지만, 이미 한 제품에 수십 명이 매달린 스타트업이라면 오히려 독이 되는 철학일 수도 있습니다. 저라면 조직의 크기와 의사결정 속도를 먼저 점검한 뒤, 이 플레이북을 어디까지 들여올 수 있을지부터 따져보겠습니다.

포트폴리오 전략, 겁 많은 개발자의 '리스크 헤지'

티보가 여러 개의 앱을 동시에 키우는 이유는 의외로 단순합니다. 가족을 먹여 살려야 하기 때문이라고 말합니다. AI가 하루가 멀다 하고 발표되고, 트위터 API 정책이 바뀌는 순간 매출 20만 달러짜리 서비스가 한 번에 흔들릴 수 있다는 것을 이미 경험했기 때문입니다.

이 관점은 국내 개발자에게도 중요합니다. 특정 플랫폼에 지나치게 의존한 SaaS, 예를 들어 특정 소셜 네트워크 자동화 도구나 특정 AI API에 과도하게 묶인 서비스는 정책 변경 한 번에 무너질 수 있습니다. 반대로 여러 시장, 여러 문제를 동시에 겨냥하면 각 제품의 성장 속도는 느려질 수 있지만 생존 확률은 분명 높아집니다. 자원이 한정된 1인 개발자에게 이 전략이 항상 옳은 것은 아닙니다. 첫 제품에서 아직 월 1만 원도 못 벌고 있다면, 포트폴리오라는 말은 멋있는 말로 포장한 현혹에 가깝습니다. 저라면 첫 제품이 적어도 매달 자연 유입과 재구매가 확인되는 수준까지는, 하나에 오래 매달리는 쪽을 선택하겠습니다.

빠른 실패율을 전제로 하는 사고방식

티보는 실패 확률을 90%라고 거의 전제로 깔고 갑니다. 그 전제 위에서 "1년짜리 실험을 할 것인가, 1주짜리 실험을 50번 할 것인가"라는 질문을 던집니다. 이 지점이 많은 한국 개발자와 창업자가 특히 힘들어하는 부분입니다. 완성도 높은 첫 제품, 근사한 디자인, 안정적 인프라를 갖추려는 욕심이 실험 속도를 망가뜨립니다.

국내에서도 여전히 "한 번 제대로 만들어 두면 나중에 편하다"는 말이 강하게 작동합니다. 그러나 AI 기반 SaaS는 기술 자체의 수명이 짧고 경쟁 속도가 빠릅니다. 여기서는 두세 달짜리 '제대로'보다, 두세 주짜리 '대충 작동하는 것'이 훨씬 큰 전략이 됩니다. 빠른 실패를 허용하는 마음가짐이 없다면 이 플레이북은 시작부터 어긋납니다.

티보의 12단계, 결국 '빨리 만들고 매일 대화하라'는 이야기

많은 사람이 새로운 SaaS 아이디어를 떠올리면 기능 목록부터 엑셀에 적습니다. 로그인, 결제, 온보딩 튜토리얼, 관리자 페이지 같은 것들입니다. 티보의 순서는 정반대입니다. 처음 한두 주에는 기능이 아니라 사람을 상정합니다. 누가 이걸 쓸지, 어디서 이 사람을 찾을지, 어떻게 말을 걸지부터 설계합니다.

이 플레이북의 앞부분은 기술보다 용기에 가깝습니다. 허술한 MVP를 들고, 소수의 잠재 고객에게 직접 메시지를 보내고, 매일 불편한 질문을 던지는 행동입니다. 알고 있어도 대부분 실행하지 않는 일입니다.

'며칠 안에 만드는 MVP'의 숨은 조건

티보는 MVP를 며칠에서 몇 주 안에 만들라고 말합니다. 여기서 많은 사람이 헷갈립니다. 진짜로 단 며칠 만에 백엔드부터 프론트까지 다 만들 수 있느냐는 의문이 생깁니다. 중요한 포인트는 완성도가 아니라 약속의 범위입니다. 사용자가 실제로 느끼는 가치를 중심으로, 딱 한 가지 결과만 잘 나오게 만드는 것입니다.

한국 개발자에게 특히 위험한 함정이 있습니다. 보안과 확장성을 너무 일찍 고민하는 습관입니다. 물론 금융이나 의료 같은 고위험 영역이라면 예외입니다. 그러나 소규모 마케팅 자동화 도구나 콘텐츠 생성 툴 수준에서, 초기에 완벽한 아키텍처를 짜느라 한 달을 보내는 순간 이미 승산이 줄어듭니다. 저라면 첫 버전에서는 노코드 툴과 레디메이드 템플릿을 적극적으로 섞고, 사용자가 직접 마주하는 핵심 기능 한 가지만 내 코드로 만들겠습니다.

'5~10명의 사용자와 매일 이야기'의 위력

티보의 말 중 가장 거칠지만 진짜 같은 부분은 이것입니다. 빌더들은 대체로 소심한 개발자이며, 그래서 코딩은 열심히 하면서 사용자와는 말을 섞지 않는다는 지적입니다. 그는 각 제품이 월 1만 달러를 벌기 전까지, 고객센터 링크를 자신의 개인 X(트위터) DM으로 연결해 두었다고 말합니다. 사용자의 불만과 요청이 그대로 자신의 메시지함으로 쏟아지게 만든 셈입니다.

이 방식은 내향적인 개발자에게는 악몽처럼 들립니다. 그러나 SaaS에서는 사용자의 불평이 바로 '안 떠나는 고객'이라는 역설적인 지표가 됩니다. 조용히 떠나버린 사람은 다시 돌아오지 않습니다. 불평하는 사람은 아직 기대를 가지고 있습니다. 국내 서비스 환경에서는 카카오톡 채널이나 디스코드 서버를 활용해 비슷한 구조를 만들 수 있습니다. 다만 한 가지를 미리 알아야 합니다. 이렇게 하면 하루 대부분을 '고객 응대'에 쓰게 될 수도 있습니다. 저라면 이 단계를 제품별로 기간을 한정해 운영하겠습니다. 런칭 후 3개월 동안만 창업자가 1차 응대를 도맡고, 그 이후에는 패턴을 정리해 다른 채널로 이관하는 식입니다.

'내가 직접 쓰는 제품'이라는 위험한 장점

티보는 자신이 만든 대부분의 툴을 직접 사용하면서 개선점을 찾는다고 말합니다. 이는 분명 강력한 방법입니다. 문제를 몸으로 겪기 때문입니다. 그러나 국내 창업자들이 이 말을 그대로 따라 하면 함정에 빠지기 쉽습니다. 본인의 워크플로와 고객의 워크플로가 미묘하게 다른데도, 스스로를 '대표 사용자'라고 착각하는 순간 제품은 점점 자기 취향으로 흘러갑니다.

자신이 사용자라는 사실은 어디까지나 보조 수단입니다. 핵심은 여전히 외부 사용자와의 대화입니다. 특히 한국 시장처럼 조직 문화와 예산 구조가 특이한 환경에서는, 프리랜서 개발자가 느끼는 문제와 중견기업 마케터가 느끼는 문제 사이에 큰 간극이 있습니다. 저라면 "내가 쓰고 싶다"를 아이디어 발견의 출발점으로만 두고, 가격 구조와 반복 사용 패턴은 반드시 타인의 데이터를 기준으로 설계하겠습니다.

콘텐츠와 채널의 시대, SaaS도 결국 '미디어 회사'가 된다

티보의 플레이북 후반부는 제품이 아니라 유입에 관한 이야기입니다. 어느 순간부터는 좋은 기능이 더 이상 성장을 보장하지 않습니다. 누가 알게 할 것인가라는 질문이 훨씬 중요해집니다. 그가 말하는 해답은 단순합니다. 어느 회사든 결국 미디어 회사가 되어야 한다는 선언입니다.

이 선언은 한국 SaaS 업계에도 곧 그대로 닥칠 흐름입니다. 검색과 소셜, 유튜브와 뉴스레터, 각 채널에서 반복적으로 눈에 띄지 못하는 서비스는 쉽게 잊히는 제품으로 남습니다. 문제는 대부분의 개발자와 창업자가 콘텐츠 제작을 '시간 남으면 하는 일'로 취급한다는 점입니다.

10K 이전의 채널, 그 이후의 채널

티보는 초반에는 제품 런칭 플랫폼과 소셜에서의 공개 개발 과정을 활용해 월 1만 달러 선까지 끌어올린다고 말합니다. 이후에는 SEO, 광고, 제휴 같은 더 '무거운' 채널을 도입합니다. 핵심은 단계 구분입니다. 초기에는 실시간 피드백과 관계 구축이 중심이 되고, 어느 정도 매출이 자리 잡으면 재현 가능한 채널에 자원을 몰아 넣습니다.

국내에서도 비슷한 패턴을 상상할 수 있습니다. 초반에는 브런치, 기술 블로그, X, 유튜브 같은 채널에서 만들고 있는 과정을 그대로 드러내면서 첫 사용자 50명을 찾습니다. 이후에는 검색 광고, 콘텐츠 SEO, 파트너사와의 리셀 제휴 같은 구조를 붙입니다. 여기서 많이들 헷갈리는 지점이 있습니다. 모든 채널을 동시에 하려 한다는 점입니다. 이 플레이북의 마지막 단계가 말해 주듯, 결국 각 제품에 맞는 채널은 한두 개뿐입니다. 저라면 세 채널 이상에서 의미 있는 수치를 만들지 못한다면, 새로운 채널을 늘리기보다 지금 돌리는 채널의 메시지와 랜딩 페이지를 먼저 갈아엎겠습니다.

'콘텐츠 엔진' 없이는 장기 성장이 멈춘다

티보는 회사가 콘텐츠 생산 파이프라인을 가져야 한다고 강조합니다. 실제 사용 사례, 고객 인터뷰, 기능 설명, 업계 트렌드 해설 같은 콘텐츠가 계속 만들어져야 광고와 SEO, 소셜이 동시에 살아납니다. 이 부분에서 한국 팀들은 특히 인력 구조의 벽을 만납니다. 개발자와 디자이너는 있는데, 글을 써 줄 사람이 없습니다.

그렇다고 전문 에이전시에 블로그를 통째로 외주 주는 방식은 이미 한계를 드러냈습니다. 검색 엔진이 AI와 자동 생성 콘텐츠에 점점 더 엄격해지고 있기 때문입니다. 결국 제품을 가장 잘 아는 사람이 직접 쓰거나, 최소한 아웃라인과 메시지를 잡아 줘야 합니다. 생성형 AI를 보조 도구로 쓰면 진입장벽은 상당히 낮아질 수 있습니다. 다만 "AI가 써 준 글을 그대로 올리면 된다"는 기대는 버리는 편이 낫습니다. 제 기준에서는 콘텐츠는 아직도 가장 '사람 손이 많이 가는 자동화 영역'입니다.

이 전략이 통하는 사람, 그리고 피해야 하는 사람

어떤 플레이북이든 모든 사람에게 정답일 수는 없습니다. 티보의 방식도 예외가 아닙니다. 오히려 이 전략은 특정 종류의 사람에게만 강력하게 작동하고, 나머지에게는 번아웃을 앞당기는 처방이 될 수 있습니다.

이 플레이북이 맞는 사람과 맞지 않는 사람

먼저 이 전략이 잘 맞는 사람은 코드와 제품을 직접 손댈 수 있는 1인 개발자나 소규모 팀입니다. 특히 이미 여러 번 사이드 프로젝트를 만들어 본 경험이 있고, 완성도보다 속도를 중시하는 성향이라면 티보의 접근은 큰 힘을 발휘합니다. X나 디스코드 같은 열린 공간에서 사용자와 매일 대화할 수 있는 사람, 고객 응대에 대한 두려움이 상대적으로 적은 사람에게도 잘 맞습니다.

반대로 아이디어는 많지만 스스로 만들 수 없고, 외주 개발에 의존해야 하는 사람에게는 이 플레이북이 거의 작동하지 않습니다. 매주 새로운 MVP를 만드는 전략은, 외주 환경에서는 비용 폭탄으로 이어집니다. 또 조직 내 의사결정 단계가 많은 대기업이나 공공기관 대상 솔루션이라면, DM으로 고객과 수다를 떨며 기능을 바꾸는 방식이 오히려 신뢰를 해치는 요인이 됩니다. 이런 경우에는 느린 대신 안정적인 요구사항 수집과 정형화된 로드맵 관리가 더 현실적입니다.

지금 당장 취할 수 있는 첫 행동

이 글을 여기까지 읽었다면 이미 머릿속에 떠오르는 아이디어가 한두 개는 있을 가능성이 큽니다. 중요한 것은 어떤 아이디어가 더 '멋져 보이는가'가 아니라, 어느 아이디어가 더 빨리 실험 가능하냐는 기준입니다. 저라면 일단 메모 앱을 열고, 2주 안에 만들 수 있는 SaaS 아이디어를 세 가지 정도만 적겠습니다. 그다음 각 아이디어마다 "어디서 첫 사용자 다섯 명을 찾을 수 있는가, 누구에게 어떤 메시지로 말을 걸 것인가"를 정리합니다.

이 단계까지가 명확해지면, 비로소 기술 스택과 구현 방식을 결정할 차례입니다. 코드로 만들지, 노코드로 만들지, 혹은 아예 손으로 직접 처리하면서 프론트만 자동화할지 같은 선택입니다. 중요한 것은 '완성'이 아니라 '대화의 시작'입니다. 제품의 가치를 설명할 수 있는 한 페이지와, 이를 보여 줄 다섯 명의 사용자를 찾는 것, 그 지점이 티보의 플레이북이 실제로 작동하기 시작하는 최소 단위입니다.

출처 및 참고 :