Marc Lou 딥다이브 | 작은 SaaS를 만들고 콘텐츠로 연결하는 솔로프리너의 사업 구조
NEXT STAGE · 006 아이디어·사례 · 해외 솔로프리너 딥다이브
안녕하세요. 일이 잘되는 공간과 방식을 고민하는 찬스, 이종찬입니다.
작은 서비스를 만들어 보고 싶은데, 배우고 준비할 것이 너무 많아서 시작이 늦어질 때가 있습니다. 로그인, 결제, 홈페이지부터 갖추다가 정작 누가 이 서비스를 쓸지는 뒤로 밀리기도 하죠. 오늘 살펴볼 Marc Lou는 이 순서를 다시 생각하게 하는 개발자이자 창업가입니다.
이전 Dan Koe 딥다이브가 생각과 지식을 콘텐츠·교육 상품으로 연결하는 관점을 다뤘다면, 이번에는 작은 소프트웨어를 만들고 판매하고 그 과정을 다시 콘텐츠로 만드는 구조에 집중합니다. 전체 지형은 해외 솔로프리너 유튜브 10선에서 함께 볼 수 있습니다.
Marc Lou에게서 볼 것은 매출보다 문제를 줄이는 방식입니다
Marc Lou의 공식 홈페이지에는 자신이 혼자 여러 스타트업을 만들었다는 소개와 제품 목록이 나옵니다. 유튜브에서는 제품 화면, 개발 도구, 출시 과정, 유입과 결제 지표를 설명합니다. 완성된 성공담만 듣기보다 한 사람이 어떤 불편을 발견하고 어디까지 구현했는지 따라가기 좋은 채널입니다.
다만 제목의 큰 숫자가 이 채널의 전부는 아닙니다. 영상 속 수익, 홈페이지의 월간 금액, 제품 페이지의 고객 사례는 대부분 본인 또는 판매자가 제시한 자료입니다. 이 글은 이를 독립적으로 감사한 실적으로 취급하지 않습니다. 매출과 순이익, 누적 판매와 월 반복 매출도 같은 값이 아닙니다.
제가 주목하는 부분은 많이 만드는 사람이 아니라, 같은 불편을 두 번 해결하지 않으려는 사람이라는 점입니다. 직접 제품을 운영하면서 반복하던 로그인·결제 설정을 코드 묶음으로 만들고, 그 묶음을 다른 개발자에게 판매합니다. 코딩을 배우고 싶다는 수요에는 교육으로, 방문자가 어디에서 와서 구매했는지 알고 싶다는 수요에는 분석 서비스로 답합니다.
이 흐름은 중소기업 대표와 팀장에게도 익숙합니다. 견적서 작성, 교육 신청 접수, 고객 문의 분류처럼 내부에서 반복되는 일을 개선하다 보면 다른 회사에도 비슷한 문제가 있을 수 있습니다. 단, 우리에게 불편하다는 사실만으로 외부 고객의 구매 의사가 증명되지는 않습니다. 내부 개선과 판매 가능한 상품 사이에는 별도의 검증이 필요합니다.
제품 운영이 다음 아이디어와 콘텐츠의 재료가 됩니다
대표 영상들을 함께 보면 운영 구조는 비교적 선명합니다. 자신의 업무에서 문제를 발견하고, 핵심 기능만 갖춘 작은 제품을 만듭니다. 공개한 뒤 실제 사용자의 질문과 행동을 살피고, 그 경험을 영상과 글로 설명합니다. 콘텐츠를 본 사람 중 일부가 제품을 이해하고 고객이 될 수 있습니다. 이것이 다시 다음 제품의 출발점이 됩니다.
여기서 유튜브는 광고 수익만을 위한 채널이라고 보기 어렵습니다. 제품을 실제로 보여주는 설명서이자 만든 사람의 판단을 드러내는 신뢰 장치입니다. 시청자가 화면을 보면서 문제에 공감하고, 어떤 도구로 해결했는지 이해하고, 필요하면 공식 제품 페이지로 이동하는 흐름입니다. 영상 설명란에 자신의 제품 링크를 놓는 것도 확인됩니다.
판매 대상도 서로 이어집니다. ShipFast는 이미 개발할 수 있지만 반복 설정을 줄이고 싶은 사람에게, CodeFast는 아이디어를 구현할 기초를 배우려는 사람에게, DataFast는 출시한 서비스의 유입과 매출을 함께 보고 싶은 운영자에게 맞춰져 있습니다. 한 고객이 반드시 세 상품을 모두 사는 것은 아니지만, 만들기 전·만드는 중·운영 후의 문제가 연결됩니다.
핵심은 제품을 많이 늘리는 것이 아니라, 한 번 해결한 문제를 재사용 가능한 자산으로 바꾸는 것입니다.
이것은 공식 자료를 토대로 제가 정리한 해석입니다. 모든 제품의 내부 운영 시간이 공개된 것은 아니므로 실제 업무가 자동으로 굴러간다고 단정할 수는 없습니다. 채널에서도 개발 설명, 사업 일지, 긴 작업 영상 등 서로 다른 형식이 보입니다. 이번 확인으로 일정한 업로드 주기나 팀의 제작 분업까지 확정하지는 않았습니다.
대표 영상 세 편은 아이디어·개발·운영 순서로 보세요
아래 세 편은 인기 순위가 아니라 서로 다른 판단을 비교하기 위해 골랐습니다. 제목과 게시일은 유튜브 메타데이터로, 설명은 타임스탬프가 있는 자막으로 확인했습니다. 게시일은 유튜브 원본 메타데이터의 날짜 기준이며, 자동 자막의 제품명 표기에는 오류가 있어 공식 페이지와 대조했습니다.
How I built 21 startups in 2 years
2024-02-12 게시 · 원본 영상. 이 영상에서 먼저 볼 구간은 00:23 자신의 문제에서 아이디어 찾기입니다. Marc는 고객에게서 제대로 된 청구서를 요청받는 일이 반복됐고, Stripe를 사용하는 사업자가 고객에게 청구서 조회·수정 경로를 제공하는 Zenvoice를 만들고 있다고 설명합니다. 추상적인 아이디어 회의보다 이미 들어오는 요청을 제품의 출발점으로 삼는 장면입니다.
04:26 빠르게 만드는 이유에서는 오랫동안 혼자 개발한 뒤 사용자를 얻지 못했던 경험을 이야기합니다. 오래 만들수록 기대가 커져 실패의 부담도 커진다는 설명입니다. 이어 05:51 최소 기능 정하기에서는 없어지면 제품 자체가 성립하지 않는 기능을 남기라고 합니다.
여기서 배울 점은 무작정 개발 시간을 줄이는 기술이 아닙니다. 고객에게 확인받기 전에 쌓아 올리는 가정을 줄이는 태도입니다. 예를 들어 교육 신청 업무를 개선한다면 처음부터 회원 등급과 추천 기능까지 만들기보다, 신청 정보를 빠뜨리지 않고 담당자에게 전달하는 한 가지 기능으로 시작할 수 있습니다. 이 예시는 영상의 실제 프로젝트가 아니라 국내 업무에 옮긴 설명용 예시입니다.
I launched a SaaS in 3 days with 3 shortcuts
2024-03-26 게시 · 원본 영상. 웹사이트에 알림을 띄우는 PoopUp을 소개하며, 자신의 다른 제품을 운영하다 새로운 수요를 발견한 과정을 설명합니다. 01:15 아이디어가 이어진 과정에서는 기존 서비스에 넣은 알림을 보고 사람들이 관심을 보여 별도 제품으로 발전시켰다고 말합니다.
02:23 기존 코드 재사용에서는 자신이 만든 ShipFast로 소개 페이지, 로그인, 결제 처리 같은 공통 부분을 마련합니다. 이어 03:01 GitHub Copilot 활용에서는 자연어로 코드를 요청하고, 화면 이동 시 알림을 정리하는 동작이나 소개 문구를 만드는 장면을 보여줍니다. 반복 기반은 코드로, 새 기능의 일부는 AI 도움으로 처리하는 조합입니다.
동시에 주의해서 볼 구간도 있습니다. 09:16 세 번째 지름길에서 TypeScript, Git 브랜치, 코드 테스트를 생략한 자신의 방식을 말합니다. 이는 당사자의 당시 선택이지 누구에게나 맞는 개발 지침이 아닙니다. 테스트 생략을 속도의 비결로 일반화하면 고객 데이터와 결제 운영의 위험까지 함께 복제하게 됩니다. 영상의 짧은 출시 기간은 배울 수 있지만 그때 감수한 위험까지 따라갈 필요는 없습니다.
I locked myself for 90 days to build this SaaS...
2024-11-07 게시 · 원본 영상. DataFast를 소개하는 이 영상은 앞의 3일 출시와 나란히 볼 때 더 유용합니다. 01:11 제품 시연에서는 방문 기록과 결제 데이터를 연결하고, 유입 경로·전환·고객의 이동 과정을 살펴보는 화면을 보여줍니다. 조회수가 높은가보다 어떤 방문이 구매로 이어졌는가를 묻는 도구입니다.
10:11 AI로 개발하는 과정에서는 Cursor를 이용해 기능 변경에 필요한 코드 수정을 제안받습니다. 특히 11분대에는 코드가 어떻게 작동하는지 알고 있기 때문에 제안이 맞는지 확인한다고 설명합니다. 일을 전혀 모르는 상태에서 AI에 통째로 맡기는 이야기와는 다릅니다. 개발자의 역할이 작성만이 아니라 검토로 옮겨가는 장면에 가깝습니다.
11:33 최소 버전의 기준에서는 지금 당장 출시해야 한다면 무엇을 남길지 묻습니다. 그런데 같은 영상 12분대에서는 이번 최소 제품에는 약 3개월이 걸렸다고 말합니다. 빠르게 출시한다는 원칙이 언제나 며칠이라는 뜻은 아닌 셈입니다. 데이터 수집과 결제를 연결하는 서비스는 작은 알림 도구와 필요한 작업이 다릅니다.
마지막으로 12:47 유입과 매출 공개에서는 기존 독자층이 초기 유입에 도움이 됐다고 인정합니다. 이를 보면 이미 관심을 가진 사람들에게 출시하는 조건과 처음 고객을 찾는 조건을 구분해야 합니다. 화면에 공개한 수치는 당시 본인 설명이며, 현재 매출이나 앞으로의 성과를 보장하는 자료는 아닙니다.
ShipFast·CodeFast·DataFast는 서로 다른 사업입니다
이름이 비슷해도 구매하는 것은 다릅니다. ShipFast는 개발의 출발점을 제공하는 코드, CodeFast는 배우는 과정, DataFast는 운영 중 사용하는 온라인 서비스입니다. 셋을 모두 월 구독형 소프트웨어로 묶으면 매출 구조도 고객 지원의 성격도 잘못 읽게 됩니다. 아래는 2026-10-18 확인한 공식 판매 페이지 기준입니다.
| 제품 | 고객이 사는 것 | 결제 구조 | 도입 전 판단 |
|---|---|---|---|
| ShipFast | Next.js 기반의 보일러플레이트. 로그인·결제·메일 등 공통 설정을 담은 시작용 코드 | 일회 결제. 페이지는 여러 프로젝트 사용과 업데이트를 안내 | 완성 서비스나 대신 운영해 주는 계약이 아님. 기술 조합과 수정·배포 역량 확인 |
| CodeFast | 기초부터 SaaS 제작까지 다루는 영상 강좌. 공식 안내 약 12시간·215개 짧은 수업 | 일회 결제, 구독 아님. 강사 지원·커뮤니티 안내 | 수강 완료와 제품 성공은 별개. 실습 시간과 영어 이해, 지원 범위 확인 |
| DataFast | 방문·목표·유입과 결제 데이터를 연결하는 웹 분석 서비스 | 월·연 단위 구독. 이벤트 규모와 요금제에 따른 과금 | 수집 범위, 결제 연동, 개인정보, 이벤트 증가에 따른 비용 확인 |
보일러플레이트는 자주 쓰는 뼈대 코드를 미리 묶어 놓은 것입니다. 집을 바로 제공한다기보다 반복되는 기초 공사를 덜어주는 자재에 가깝습니다. 구입하면 자신의 고객에게 맞게 수정하고 배포하고 유지해야 합니다. 공식 페이지의 시간 절약 문구도 판매자의 설명이지 모든 개발 환경에서 측정된 보편적 결과는 아닙니다.
CodeFast의 짧은 강의도 같은 기준으로 읽으면 좋습니다. 강의를 보는 시간과 실제로 이해하고 오류를 해결하는 시간은 다릅니다. DataFast 역시 분석 도구를 설치했다고 고객이 늘지는 않습니다. 어떤 경로가 유효한 문의나 구매로 이어졌는지 읽고, 소개 문구와 신청 흐름을 바꾸는 운영자의 행동이 필요합니다. 가격은 할인·통화·요금 조건에 따라 달라질 수 있어 본문에서는 고정 금액보다 결제 구조를 중심으로 비교했습니다.
혼자 만든다는 말과 혼자 모든 일을 한다는 말은 다릅니다
Marc는 공식 홈페이지에서 여러 스타트업을 혼자 만들었다고 소개하고, 2024년 DataFast 영상에서도 자신이 대기업이 아니라 혼자 일한다고 설명합니다. 따라서 개인 창업자 중심의 사례로 보는 근거는 있습니다. 다만 이 자료만으로 2026년 모든 제품의 개발·수업 지원·영상 편집·회계까지 전부 한 사람이 처리한다고 확정할 수는 없습니다.
CodeFast 페이지에는 강사의 지원과 커뮤니티가 안내돼 있지만 지원 담당자의 수나 고용 형태는 이번 확인에서 알 수 없었습니다. 제품이 쓰는 결제·메일·호스팅·AI 서비스도 외부 기반입니다. 솔로프리너를 볼 때는 직원 수만이 아니라 어떤 일을 제품과 외부 서비스로 분리했는지를 보는 편이 실무에 도움이 됩니다.
성과 공개에는 마케팅 목적도 함께 있습니다. 잘된 출시와 만족한 고객의 후기가 눈에 잘 띄지만 전체 구매자의 결과, 실패자의 비율, 환불과 지원 비용까지 같은 비중으로 드러나지는 않습니다. 이미 확보한 독자층, 개발 경험, 여러 번의 실패에서 얻은 자산도 신규 창업자와 다른 출발 조건입니다. 공개된 좋은 사례만으로 기대 수익이나 성공 확률을 계산해서는 안 됩니다.
AI 코드를 사용할 때도 속도와 책임을 분리해야 합니다. 최소한 로그인한 사용자만 자기 정보를 보는지, 결제 알림이 중복돼도 권한이 잘못 부여되지 않는지, 비밀 키가 화면이나 저장소에 노출되지 않는지 확인해야 합니다. 패키지 업데이트, 입력값 검증, 백업과 복구, 오류 기록, 환불 절차도 실제 운영에서는 빠지기 어렵습니다. 이는 특정 제품에 결함이 있다는 주장이 아니라 도입하는 쪽의 일반적인 검수 기준입니다.
작게 시작한다면 먼저 가상 데이터로 시험하고, 실제 고객정보나 결제를 붙이기 전에는 검토할 수 있는 사람을 정하는 편이 좋겠습니다. 장애가 났을 때 누가 답하고 어디까지 지원하는지도 정해야 합니다. 코드 구매나 강의의 평생 접근이라는 문구를 내 서비스에 대한 영구 운영 보장으로 해석해서는 안 됩니다.
한국의 작은 팀에는 이렇게 세 가지로 옮겨볼 수 있습니다
아래는 Marc의 실제 국내 적용 실적이 아니라 제가 제안하는 설명용 적용안입니다. 그대로 제품을 따라 사기보다 우리 팀의 불편을 줄이는 작은 실험으로 바꾸는 것이 목적입니다.
반복 문의 하나를 먼저 줄여봅니다. 공간 운영팀이라면 이용 시간·장비·주차 정보를 반복해서 안내하는 일을 골라볼 수 있습니다. 처음부터 종합 예약 앱을 만들지 않고, 검증된 안내 내용과 신청 양식만 연결합니다. 개인정보는 필요한 항목만 받고, 잘못된 안내를 고칠 담당자를 둡니다. 관찰할 것은 방문자 수보다 같은 질문이 얼마나 줄었는지, 신청 누락이 생기지 않았는지입니다.
상품보다 먼저 만드는 과정을 짧게 기록합니다. 교육 담당자라면 신청자 명단을 정리하는 작은 도구를 가상 데이터로 만들고, 기존 방식의 불편·바꾼 부분·사람이 확인한 지점을 남길 수 있습니다. 성과가 없는데 성공 사례로 포장할 필요는 없습니다. 반복할 수 있는 절차와 아직 해결하지 못한 예외가 다른 담당자에게는 오히려 유용한 정보가 됩니다. 기관명과 실제 참가자 정보는 공개 자료에서 분리해야 합니다.
유입보다 유효한 문의를 연결해 봅니다. 작은 사업자는 글이나 영상에 유입 구분용 링크를 두고, 문의 폼에서 실제 업무 문제와 요청 내용을 확인할 수 있습니다. 처음에는 기존 분석 도구와 간단한 기록표만으로도 시험할 수 있습니다. 나중에 결제 연동과 분석 범위가 필요해졌을 때 DataFast 같은 서비스를 비교하면 됩니다. 도구 이름보다 무엇을 바꾸기 위해 측정하는지가 먼저입니다.
이 세 가지를 동시에 할 필요는 없습니다. 반복 업무 하나, 제한된 시험 범위 하나, 결과를 판단할 기록 하나면 출발하기에 충분합니다. 반응이 없으면 더 많은 기능을 붙이기 전에 문제를 잘못 골랐는지부터 확인하는 것이 좋겠습니다.
출처를 확인하고 내 일에 맞는 작은 버전으로 시작하세요
Marc Lou의 사례를 한 문장으로 정리하면, 직접 겪는 불편을 작은 소프트웨어로 해결하고 그 기반과 배움을 다시 판매 가능한 형태로 바꾸는 방식입니다. 배울 부분은 분명하지만 출시 속도, 매출, 혼자 일하는 모습 중 어느 하나만 떼어내 정답으로 삼기는 어렵습니다. 고객을 만나는 시점은 앞당기되 보안과 지원의 책임까지 줄이지 않는 것이 중요합니다.
이번 글은 공식 홈페이지·제품 페이지와 실제 채널 영상 세 편의 메타데이터·자막을 바탕으로 작성했습니다. 자료 확인일은 2026-10-18입니다. 제품 설명과 요금 구조는 확인 당시 페이지 기준이며, 영상의 사업 수·실적·도구 선택은 해당 영상의 과거 시점 자료입니다. 공식 사이트 간 사업 수와 수익 표기도 서로 달라 최신 합산 수익으로 재구성하지 않았습니다.
- Marc Lou 공식 홈페이지: 본인 소개, 제품 목록과 공식 연결 경로. 수익 표시는 본인 제시 자료.
- Marc Lou 유튜브 채널: 공개 소개와 콘텐츠 구성, 대표 영상 확인.
- ShipFast 공식 페이지: Next.js 코드 묶음, 기능·일회 결제 안내.
- CodeFast 공식 페이지: 강의 구성, AI 활용·지원·비구독 결제 안내.
- DataFast 공식 페이지: 웹 분석·매출 연결·목표 기능과 구독 요금 구조.
- How I built 21 startups in 2 years: 2024-02-12, 아이디어와 최소 기능.
- I launched a SaaS in 3 days with 3 shortcuts: 2024-03-26, 재사용 코드·AI·생략한 개발 절차.
- I locked myself for 90 days to build this SaaS...: 2024-11-07, DataFast 시연·코드 검토·초기 유입.
오늘의 작은 적용 아이디어는 반복 문의를 줄이기, 만드는 과정을 기록하기, 유입과 유효한 문의를 연결하기입니다. 내 일에서 가장 부담이 작은 한 가지부터 골라보시면 좋겠습니다. 각자의 자리에서 배우고 만드는 과정을 응원합니다. 다음 글에서 또 뵙겠습니다.
우리 조직의 반복 업무를 AI와 작은 도구로 바꾸는 교육이 필요하시다면 넥스트코웍 교육·프로젝트 문의로 실제 업무 상황을 남겨주세요.
댓글
댓글 쓰기