Skip to content
Published on

Micro-SaaS와 1인 비즈니스 2026 — 경제학, 스택, 실제 케이스 정밀 분석

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Authors

프롤로그 — 왜 2026년에 1인 SaaS인가

1인 비즈니스라는 말은 인터넷이 있던 시절 내내 떠돌았다. 1999년에도 누군가는 "혼자서도 회사를 굴릴 수 있다"고 말했고, 2014년 Pieter Levels가 Nomad List를 만들었을 때 그 말이 처음으로 진짜처럼 들렸고, 2020년 코로나 이후 디지털 노마드 붐과 함께 다시 한 번 주목받았다. 그리고 2026년, 이 말은 마침내 통계적으로 정상화된다.

이유는 단순하다. 혼자 만들 수 있는 것의 천장이 너무 높아졌다. 2024년만 해도 한 명이 SaaS를 만들어 6자리 ARR을 내려면 디자인·프론트·백엔드·인프라·결제·고객 지원·SEO·이메일 마케팅·세무를 전부 손에 쥐어야 했다. 손이 모자라면 사람을 뽑아야 했다. 그게 2025-2026 사이에 깨졌다.

  • 코드 생성 — Cursor, Claude Code, Junie 같은 도구가 보일러플레이트를 사실상 0으로 만들었다. 작년의 2주짜리 작업이 이제 사흘이다.
  • 에이전트형 운영 — Slack 봇, CS 트리아지, SEO 콘텐츠 파이프라인, 인보이싱이 에이전트로 돌아간다.
  • 엣지 인프라 — Cloudflare Workers와 Vercel Edge의 무료 티어에서 수천 MAU를 견딘다. 첫 청구서까지 18개월이 걸리는 게 정상이다.
  • 결제 인프라 — Stripe + Lemon Squeezy + Polar 조합이 글로벌 결제·세금·VAT·체크아웃을 위임 가능한 박스로 만들었다.
  • 유통 채널 — X (Twitter), Beehiiv, Substack, YouTube가 미디어 회사 없이도 청중을 구축할 수 있는 거리 위에 있다.

이게 1인 SaaS라는 카테고리를 "괴짜 한 명의 예외"에서 "통계적으로 재현 가능한 패턴"으로 옮긴다. Marie Martens의 Tally는 5M ARR을 11명의 팀(완전 부트스트랩)으로 돌린다. Damon Chen의 Testimonial.to는 1.3M ARR에 도달할 때까지 솔로였다. Pieter Levels는 250K USD/월의 포트폴리오를 직원 없이 운영한다. 이건 더 이상 행운이 아니다.

그렇다고 모두가 성공한다는 뜻은 아니다. 90%는 실패한다. 이 글은 그 10%가 어떻게 살아남았는지와, 90%가 어디서 죽었는지를 같이 본다. 8개 케이스, 2026년 표준 스택, audience-first vs build-first 논쟁, 한국 메이커 씬, 그리고 실전 체크리스트까지.

1인 SaaS는 더 이상 "외로운 천재"의 게임이 아니다. 검증된 플레이북, 표준 스택, 풍부한 실패 데이터가 갖춰진 카테고리다. 2026년의 핵심 질문은 "가능한가?"가 아니라 "당신이 정직할 준비가 되었는가?"이다.

이 글에 나오는 모든 MRR·ARR 숫자는 공개된 자료에 기반하며, 2026년 4-5월 기준이다. 솔로 파운더 비즈니스는 빠르게 움직이니, 시점을 함께 기억하길 바란다.

1장 · 2026년 1인 SaaS의 경제학

핵심은 단가가 아니라 비대칭성이다. 1인 SaaS는 다음 세 가지가 동시에 성립해야 작동한다.

1.1 비용 곡선이 거의 평평하다

전통적인 스타트업은 ARR이 늘수록 비용이 함께 늘었다. 영업, 마케팅, CS, 제품, 인프라가 단계별로 사람을 잡아먹었다. 2026년의 1인 SaaS는 다르다. Cloudflare Workers · Vercel Edge · Supabase · Stripe 같은 인프라가 사용량당 과금이라 ARR이 10배 늘어도 인프라 비용은 2-3배만 늘어난다. 영업·CS는 자동화·에이전트·셀프서브 결제로 대체된다. 핵심은 사람을 뽑는 결정을 끝까지 미룰 수 있다는 것이다.

Marie Martens가 Tally를 5M ARR까지 11명으로 돌릴 수 있는 이유, Damon Chen이 Testimonial.to를 400K ARR까지 솔로로 돌릴 수 있었던 이유가 여기에 있다.

1.2 분배 비용이 시간으로 옮겨졌다

전통 SaaS의 분배는 돈이었다. 페이스북 광고, 구글 광고, 콘텐츠 마케터 채용, 콘퍼런스 부스. 2026년의 1인 SaaS는 시간으로 분배한다. X에서 빌드 인 퍼블릭 (build in public), Beehiiv 뉴스레터, YouTube 데모, 인디 해커스·디스콰이엇 같은 커뮤니티. 돈이 없어도 1년의 시간이 있으면 청중을 만들 수 있다.

함정도 같이 있다. 시간은 무한히 들어가도 보장이 없다. Pieter Levels가 12개 제품을 실패한 후 Nomad List가 터졌고, Damon Chen은 두 개 제품을 죽인 후 Testimonial이 터졌다. 80%의 실패율을 받아들이고 시작해야 한다.

1.3 한 명의 결정 속도가 무기다

대기업이 한 분기 회의에서 결정하는 일을, 1인 파운더는 두 시간 만에 한다. 가격을 올릴까? 기능을 자를까? 이 시장을 떠날까? 솔로 파운더의 진짜 우위는 속도이지 비용이 아니다. 2026년 AI 도구가 코드·디자인·카피 작성의 마찰을 더 줄이면서 이 우위가 폭증했다.

1인 SaaS의 수학적 우위는 분자(매출)는 평범한 SaaS와 같고, 분모(인건비)가 1이라는 것. 한 사람의 연봉이 200K USD인 시장에서 1M ARR은 평범한 비즈니스지만 80% 마진의 1인 비즈니스다.

2장 · 케이스 스터디 1 — Pieter Levels, 솔로 SaaS의 정전(Canon)

이 카테고리의 정전. Pieter Levels가 없었다면 이 글의 모든 다른 케이스가 가능하지 않았을 것이다. 2014년 Nomad List를 만들었고, 그 후 12년 동안 무수한 제품을 만들었다 죽였다.

2026년 5월 기준 공개 숫자

  • Photo AI — 약 132-138K USD/월 MRR (1.6M ARR)
  • Remote OK — 약 35-41K USD/월 (2M ARR 수준)
  • Nomad List — 약 38K USD/월 (700K ARR 수준)
  • Interior AI — 약 38-45K USD/월
  • 포트폴리오 합산 — 250K USD/월, 약 3M USD/년

직원: 0명. 위치: 어디든. 12년차 1인 파운더.

2.1 스택의 정직한 모습

흥미로운 건 Pieter의 스택이 2026년 기준에선 "구식"이라는 것이다. 그는 PHP + jQuery + 단일 VPS + SQLite를 쓴다. Cursor·Claude Code도 쓰지만, 인프라는 거의 그대로다. 그가 X에서 자주 하는 말은: "새 기술은 새 버그를 만든다. 나는 5년 동안 같은 버그만 본다."

이게 무엇을 의미하는가. 1인 SaaS의 스택 선택에서 최우선 기준은 "당신이 깊게 알고 있는가"이다. Pieter는 PHP를 너무 잘 알아서 새 프레임워크로 갈아탈 이유가 없다. 새로 시작하는 솔로 파운더는 자기가 가장 빠른 스택을 골라야지, 트위터 트렌드를 좇으면 안 된다.

2.2 분배 — 12년 동안 X에서 빌드 인 퍼블릭

Pieter의 진짜 무기는 코드가 아니라 X 계정이다. 50만+ 팔로워가 그가 만드는 모든 것의 첫 청중이다. 그가 매년 강조하는 건 **"제품보다 청중을 먼저 만들어라"**다.

함정: 이건 12년이 걸린다. Pieter의 X는 2014년부터 매일 작동했고, 그 누적이 지금의 분배 채널이다. 신규 솔로 파운더가 6개월 만에 Pieter처럼 되겠다는 건 비현실적이다. 대신 작은 청중부터 시작해서 누적하는 게 더 정직한 길이다.

2.3 배울 것과 흉내 내지 말 것

배울 것:

  • 빌드 인 퍼블릭으로 청중을 누적
  • 제품 포트폴리오로 리스크 분산 (한 제품이 죽어도 나머지가 산다)
  • 빠른 실험, 빠른 죽이기 (12개 실패는 정상이다)

흉내 내지 말 것:

  • 12년 누적 청중 없이 그의 출시 속도를 흉내내는 것
  • "혼자 다 한다"는 정체성에 집착해서 외주를 거부하는 것 (Pieter도 디자인 외주를 쓴다)

3장 · 케이스 스터디 2 — Andrey Azimov, "Hardcore Year"

Pieter의 직접 영향을 받은 1세대. 2018년 우크라이나 출신 개발자가 "하드코어 이어"라는 1년 도전을 선언하고 발리로 떠났다. 3K USD의 현금으로 시작해서 1년 안에 흑자를 만들겠다는 목표.

만든 제품:

  • ProgressBarOSX (macOS 메뉴바 진척률 표시 앱)
  • Sheet2Site (Google Sheets를 사이트로 변환)
  • Dark Mode List
  • PushToDeploy
  • WhenToSurf

결과: 2018년 1K USD/월 평균에서 2020년 10K USD/월 돌파. Sheet2Site와 Chart2Site는 매각. Product Hunt "Maker of the Year" 수상.

3.1 핵심 교훈 — 작게, 빠르게, 여러 번

Andrey의 방식은 Pieter의 "한 제품 5년"과 정반대다. 1년 안에 5개 제품을 만들고, 그중 하나가 살아남으면 거기에 베팅한다. 죽으면 매각하거나 메인테넌스 모드로 전환. 이게 "포트폴리오 접근"의 또 다른 변형이다.

2026년 기준 이 접근의 매력은 더 커진다. Cursor·Claude Code가 1주짜리 MVP를 2-3일로 만든다. 1년에 10개 MVP를 출시하고, 그중 1-2개가 트랙션을 얻으면 거기서 성장시키는 게 통계적으로 합리적이다.

3.2 함정

  • 메인테넌스 폭증 — 매각 안 한 제품 5개가 동시에 작동하면 한 명이 감당하기 힘들다. Andrey는 그래서 매각을 했다.
  • 콘텍스트 스위칭 — 5개 제품을 동시에 운영하면 깊이 있게 한 제품을 키우기 어렵다.

4장 · 케이스 스터디 3 — Marie Martens (Tally), 부트스트랩의 모범

Tally는 2020년 Marie Martens와 Filip Minev가 시작한 폼 빌더. "Notion 같은 UI의 폼"이라는 명확한 포지셔닝.

2026년 4월 기준

  • 5M USD ARR 돌파
  • 직원 11명 (여전히 완전 부트스트랩)
  • 외부 투자 0원
  • 사용자 150K+

4.1 솔로는 아니지만 솔로 정신

Marie와 Filip은 부부다. 그래서 정확히는 "1인 비즈니스"가 아니라 "2인 비즈니스"로 시작했다. 하지만 이 모델은 1인 SaaS 카테고리에 들어간다 — VC 없이, 영업팀 없이, 광고 없이.

Tally의 스택 (공개된 만큼):

  • Next.js
  • Tailwind CSS
  • PostgreSQL (Supabase 또는 Neon)
  • Vercel
  • Stripe
  • Plausible Analytics

2026년 표준 스택의 거의 정확한 모습이다.

4.2 핵심 교훈 — 무료 티어가 분배 채널이다

Tally의 가장 큰 결정은 "무료 티어에 거의 모든 기능을 넣었다"는 것이다. 다른 폼 빌더(Typeform, Jotform)는 무료에서 결정적인 기능을 잠가서 사용자가 빠져나가게 만들었다. Tally는 반대로 갔다 — 무료로도 충분히 쓸 수 있게 하고, 팀·통합·고급 분석에 유료를 두었다.

결과: 무료 사용자가 분배 채널이 되었다. 그들이 만든 폼이 인터넷 곳곳에 퍼지면서 SEO와 입소문이 자동으로 발생했다.

4.3 흉내 낼 점

  • 부부·팀 구성으로 솔로의 외로움을 줄이는 모델 — 솔로 파운더의 80%가 외로움으로 죽는다는 통계가 있다. 작은 팀이 더 오래 산다.
  • 무료를 분배로 쓰는 결정 — 모든 SaaS가 freemium에 적합한 건 아니지만, 폼·테스트·노트 같은 viral 제품은 freemium이 강력하다.

5장 · 케이스 스터디 4 — Tony Dinh (TypingMind, BlackMagic), 베트남 인디 메이커

Tony Dinh는 베트남 출신 개발자. 2022-2023 사이에 BlackMagic.so (Twitter 분석 도구)로 처음 14K USD/월 MRR을 만들었고, Twitter API 가격 정책 변경으로 매각했다. 그 다음 TypingMind (ChatGPT용 데스크탑 클라이언트)를 만들었다.

2024년 말 공개 숫자

  • TypingMind: 45K USD/월 MRR (B2C)
  • 엔터프라이즈 계약 포함 시 한 달에 80K USD+까지 도달
  • 마진: 약 85%

2026년 5월 기준 정확한 MRR은 공개되지 않았으나, TypingMind는 여전히 활발한 제품이고 모델 추가·기능 확장이 계속되고 있다.

5.1 LLM Wrapper의 정직한 현실

TypingMind는 "ChatGPT 위에 더 좋은 UI를 얹은" 제품이다. LLM wrapper로 불리는 카테고리. 2023-2024년 사이 수천 개의 LLM wrapper가 만들어졌고, 대부분 죽었다. TypingMind가 살아남은 이유는:

  1. BYOK (Bring Your Own Key) 모델 — 사용자가 자기 OpenAI/Anthropic API 키를 넣는다. Tony는 API 비용을 안 지불한다. 마진이 85%인 이유.
  2. 데스크탑 네이티브 — 웹 클라이언트가 아니라 데스크탑 앱이라 데이터가 로컬에 있고, 기업 사용자에게 매력적이다.
  3. 워크스페이스·팀 기능 — 단순 챗 클라이언트에서 시작했지만, 팀·프롬프트 라이브러리·MCP 지원으로 확장하며 B2B 영역에 진입했다.

5.2 핵심 교훈 — wrapper도 정직하게 만들면 산다

"LLM wrapper는 끝났다"는 말은 절반만 맞다. 단순 ChatGPT 복사품은 끝났지만, 특정 사용자 페르소나에 깊게 최적화한 wrapper는 여전히 산다. TypingMind는 "기술적인 파워 유저"라는 페르소나에 정확히 맞춰져 있다.

2026년에 시작하는 LLM wrapper 솔로 파운더에게 솔직한 조언: 단순 챗봇 빌더는 죽음이다. 특정 페르소나·도메인·워크플로에 깊게 박힌 wrapper만 산다.

6장 · 케이스 스터디 5 — Damon Chen (Testimonial.to), B2B 솔로의 정전

Damon Chen은 미국 거주 중국 출신 개발자. Testimonial.to는 "고객 리뷰·증언을 영상·텍스트로 모으는 도구"다. 2021년 출시.

공개된 성장 궤적

  • 출시 9개월: 100K USD ARR
  • 17개월: 300K USD ARR
  • 이후 800K USD ARR 돌파
  • 2026년 2월 기준: 약 840K USD ARR
  • 400K ARR 시점에 첫 직원 고용 (마케팅)

6.1 핵심 교훈 — B2B SaaS에서 분배가 SEO와 빌드 인 퍼블릭의 결합

Damon의 성장 채널은 두 가지다.

  1. 빌드 인 퍼블릭 (Twitter/X) — 초기 80-90%의 고객이 X에서 왔다. Damon은 매일 빌드 진척, 매출, 실수를 공유했다.
  2. SEO·콘텐츠 — "video testimonial software", "testimonial form", "social proof tool" 같은 키워드에 정밀하게 콘텐츠를 만들었다. 6-12개월이 걸렸지만 누적되었다.

이 두 채널의 결합이 1인 B2B SaaS의 정전이다. X가 단기·실험·고품질 청중, SEO가 장기·누적·구매 의도 청중. 둘 다 돈이 들지 않는다 (시간만 든다).

6.2 솔로의 한계와 첫 직원 시점

Damon은 400K ARR 시점에 첫 직원을 뽑았다. 마케팅 담당. 그 전까지는 완전 솔로였다. 이 패턴 — 첫 직원을 매출이 정착한 후에 뽑는다 — 가 1인 SaaS의 통계적 패턴이다.

너무 빨리 직원을 뽑으면 캐시가 마르고, 너무 늦게 뽑으면 본인이 번아웃된다. Damon의 사례에서 보듯 400-500K ARR이 "솔로의 한계"라는 경험칙이 있다 (정답은 없지만 참고할 만한 숫자).

7장 · 케이스 스터디 6 — Arvid Kahl (FeedbackPanda → 크리에이터), 엑싯 후 크리에이터로

Arvid Kahl은 독일 출신 개발자. 파트너 Danielle Simpson과 함께 FeedbackPanda (온라인 영어 강사용 SaaS)를 만들었다.

역사

  • 2017년 시작
  • 2년 만에 55K USD/월 MRR
  • 2019년 SureSwift Capital에 7자리 USD에 매각 (정확한 금액 미공개)
  • 직원: 끝까지 본인 + 파트너 둘 뿐

엑싯 후 Arvid는 "크리에이터"로 피벗했다. 책 (The Embedded Entrepreneur, Zero to Sold), 팟캐스트 (The Bootstrapped Founder), 뉴스레터, 그리고 Podscan.fm이라는 새 SaaS.

7.1 핵심 교훈 — 솔로 파운더의 두 번째 챕터

Arvid의 사례가 보여주는 건 솔로 SaaS 엑싯 이후의 패턴이다. 수백만 달러를 받고 매각했지만, 그는 다시 일한다 — 이번엔 크리에이터로. 그가 자주 하는 말: "매각한 돈은 다음 비즈니스의 캐시플로가 아니라 자유의 보장이다."

2026년 봄 Arvid의 가장 흥미로운 글 중 하나는 "빌드 인 퍼블릭의 위험"에 관한 것이었다. AI 에이전트 도구가 공개된 정보를 빠르게 복제하는 시대에, 너무 많은 디테일을 공개하면 누군가 그걸 그대로 클론한다는 경고. 솔직히 동의할 만한 지적이다.

7.2 핵심 - 빌드 인 퍼블릭의 새로운 룰

Arvid가 제안하는 2026년의 빌드 인 퍼블릭 규칙:

  • 고수준 인사이트는 공개 — "이 시장은 이런 사람들이 있다", "이 채널이 작동했다"
  • 저수준 디테일은 비공개 — 정확한 카피, 광고 타기팅, 가격 실험, 신기능 로드맵
  • 공개 도구 (Podscan 같은 모니터링)로 클론을 감지 — 누군가 당신을 베끼고 있는지 모니터링하라

8장 · 케이스 스터디 7 — Pat Walls (Starter Story), 미디어 회사로의 진화

Pat Walls는 미국 출신. Starter Story는 "성공한 1인·소규모 비즈니스 파운더의 인터뷰" 미디어. 2017년 시작.

역사

  • 매월 1.4-1.6M 방문자
  • 약 1.1M USD/년 매출
  • 2026년 2월 HubSpot에 인수 (정확한 금액 미공개, "7자리"로만 공개)
  • 동시 인수: The Hustle, My First Million

8.1 핵심 교훈 — 콘텐츠 비즈니스도 1인 비즈니스가 된다

Starter Story는 엄밀히는 SaaS가 아니다. 미디어·콘텐츠 비즈니스다. 하지만 같은 패턴이 작동한다 — 한 사람이 시작, SEO와 콘텐츠가 분배, 광고·구독·강의로 수익화.

2026년 콘텐츠 비즈니스는 AI 시대에 압박을 받고 있다. ChatGPT가 모든 정보의 첫 소스가 되면서 검색 트래픽이 줄고 있다. 그럼에도 Pat의 모델이 살아남은 이유:

  1. 인터뷰는 AI가 흉내 못 낸다 — 실제 파운더의 정확한 데이터·실수·결정은 LLM이 환각할 수 없다.
  2. 커뮤니티 락인 — Starter Story는 단순 콘텐츠 사이트가 아니라 유료 커뮤니티를 운영했다. 회원은 떠나지 않는다.
  3. 인수 가능한 자산 — 1.4M 월간 방문은 광고주에게 직접 팔거나 미디어 회사가 인수할 수 있는 자산이다.

8.2 SaaS는 아니지만 솔로 비즈니스의 본보기

이 글의 다른 케이스가 SaaS인 반면, Pat의 사례는 콘텐츠다. 하지만 솔로 파운더의 길은 SaaS만 있는 게 아니다. 콘텐츠·뉴스레터·교육 (Beehiiv, Maven), 마켓플레이스, 디지털 제품도 1인 비즈니스의 카테고리다.

2026년의 1인 비즈니스 카테고리는 5개로 정리된다: ① SaaS, ② 콘텐츠 미디어, ③ 디지털 제품·강의, ④ 컨설팅·DFY (Done For You), ⑤ 인포메이션 마켓플레이스. 어느 게 맞는지는 본인의 강점·청중·시장 사이즈가 결정한다.

9장 · 비교 매트릭스 — 8개 케이스 한눈에

파운더제품카테고리정점 ARR/MRR (공개치)직원 (현재)분배 채널스택결말
Pieter LevelsPhoto AI · Nomad List · RemoteOKB2C SaaS 포트폴리오약 250K USD/월0명X (50만+ 팔로워)PHP · jQuery · VPS · SQLite운영 중
Andrey AzimovSheet2Site · ProgressBarOSX · Chart2SiteB2C 도구 포트폴리오10K+ USD/월 (정점)0명Twitter · Product Hunt다양 (제품별)매각
Marie MartensTally.soB2B 폼 빌더5M USD ARR11명 (부부 + 9)Freemium · 입소문Next.js · Postgres · Vercel · Stripe운영 중
Tony DinhTypingMind (BlackMagic 매각)LLM Wrapper · B2C/B2B45K USD/월 (단일 월 80K+)0-소수X · Product Hunt데스크탑 + 클라우드운영 중
Damon ChenTestimonial.toB2B SaaS약 840K USD ARR소수 (400K 이후)X · SEO · 콘텐츠Next.js · Stripe운영 중
Arvid KahlFeedbackPanda → PodscanB2B SaaS → 크리에이터55K USD/월 (매각 시점)0 (FeedbackPanda)빌드 인 퍼블릭 · 팟캐스트일반적 SaaS 스택매각 후 신규
Pat WallsStarter Story미디어 콘텐츠약 1.1M USD/년소수SEO · YouTube · 커뮤니티콘텐츠 사이트HubSpot 인수

이 표만 보면 패턴이 보인다:

  • 포트폴리오 vs 단일 제품 — Pieter, Andrey는 포트폴리오. Marie, Damon은 단일 제품에 집중.
  • B2C vs B2B — B2C는 분배가 X·바이럴, B2B는 SEO·콘텐츠·세일즈.
  • 분배 채널의 공통점 — 거의 모두가 X (Twitter)에서 청중을 시작했다. 단일 채널의 압도적 비중.

10장 · 2026년 표준 스택 해부

이제 도구를 보자. 2026년 5월 기준 솔로 파운더가 SaaS를 시작한다면 표준 스택은 다음과 같다.

10.1 코드 — Cursor + Claude Code + Junie (세트)

2026년 한 명의 개발자가 가장 많이 쓰는 조합은:

  • Cursor — IDE 안에서의 대화·자동 완성·코드 변환
  • Claude Code — 터미널에서 도는 자율 에이전트. 멀티 파일 작업, 리팩토링, 테스트 실행
  • Junie CLI / Codex CLI — 백그라운드에서 도는 장시간 작업 (1시간+ 걸리는 마이그레이션 등)

이 셋을 동시에 쓰는 솔로 파운더가 일반적이다. 비용은 월 100-300 USD 정도 (모델 사용량에 따라).

10.2 백엔드 — Bun + Hono (또는 Node + Hono)

Bun은 2026년 솔로 파운더의 디폴트가 되었다. 빠르고, TypeScript가 네이티브이고, npm·node 호환이고, 패키지 매니저까지 통합되어 있다. Hono는 그 위의 웹 프레임워크 — 가볍고 (14KB), Cloudflare Workers/Bun/Deno/Node 어디서나 도는 멀티 런타임 디자인.

`Express는 10년의 표준이었지만, 2026년 신규 프로젝트에서는 Hono가 사실상 디폴트다. Express는 멀티 런타임 지원이 없고, TypeScript 우선 디자인이 아니다.

대안: Elysia (Bun 전용, 더 빠르지만 멀티 런타임 X), Next.js API Routes (풀스택 통합 시).

10.3 프론트엔드 — Next.js (또는 Astro · SvelteKit)

Next.js는 여전히 디폴트지만, SEO 중심 사이트는 Astro도 흔하다. Tally가 Next.js를 쓰는 이유는 dashboard·앱 영역이 SaaS의 핵심이기 때문이고, 콘텐츠가 중심인 사이트 (Starter Story 같은)는 Astro/SvelteKit이 더 가볍다.

10.4 데이터베이스 — Postgres (Supabase / Neon)

2026년 솔로 파운더의 디폴트 DB는 Postgres이고, 호스팅은 Supabase 또는 Neon이다. Supabase는 Postgres + Auth + Storage + Realtime을 한 박스에 묶어준다. Neon은 더 가볍고 브랜치 기능이 강하다 (개발용 분기).

Pieter Levels처럼 SQLite를 쓰는 솔로도 있지만, 새로 시작하는 솔로 파운더에게는 Postgres + 호스팅 서비스가 더 안전하다.

10.5 인프라 — Vercel (또는 Cloudflare Workers + Pages)

Vercel은 Next.js의 디폴트. 무료 티어에서 수천 MAU를 견딘다. 트래픽이 늘면 Cloudflare Workers로 옮기는 솔로 파운더도 많다 (대역폭 비용이 압도적으로 저렴).

Pieter는 여전히 단일 VPS에 모든 걸 올린다. 작동한다. 다만 새로 시작하는 솔로 파운더는 무료 티어부터 시작해서 트래픽이 늘면 옮기는 게 합리적이다.

10.6 결제 — Stripe (또는 Lemon Squeezy · Polar)

Stripe는 글로벌 결제의 디폴트. 다만 솔로 파운더가 부딪히는 문제는 세금이다. 유럽 VAT, 미국 주별 세금, 일본 소비세, 한국 부가가치세 — 이걸 직접 처리하면 회계가 폭발한다.

해결책: Lemon Squeezy (지금은 Stripe에 인수됨), Polar, Paddle 같은 "Merchant of Record" 서비스. 이들은 결제·세금·환불을 대신 처리하고, 솔로 파운더는 영수증 한 장만 받는다. 수수료가 좀 더 비싸지만 (5-8% vs Stripe 2.9%), 세무 처리의 마찰이 사라진다.

10.7 청중 — Beehiiv (뉴스레터) + X (Twitter) + YouTube

청중 구축의 스택은 다음과 같다:

  • X (Twitter) — 빠른 실시간 청중. 단점: 알고리즘 의존.
  • Beehiiv 또는 Substack — 이메일 리스트. 알고리즘 독립.
  • YouTube — 장기 SEO 자산. 콘텐츠 비용이 높지만 누적이 강하다.

가장 흔한 솔로 파운더 패턴: X로 시작해 청중을 모으고, 이메일 리스트로 이주시키고, YouTube에 깊이 있는 콘텐츠를 천천히 누적.

10.8 운영 — 에이전트형

2026년의 1인 비즈니스가 1인을 유지할 수 있는 건 운영의 자동화 덕분이다. 대표적 스택:

  • CS 트리아지 — Intercom + LLM agent로 1차 응대, 복잡한 케이스만 사람
  • Slack 봇 — 매출, 신규 가입, 환불을 실시간 알림
  • 콘텐츠 파이프라인 — Claude/GPT로 블로그 초안 → 사람이 편집 → Beehiiv 발행
  • 결제·인보이스 — Stripe + Polar가 자동
  • 세무 자료 — Bench, Pilot 같은 SaaS가 자동 기록

이 모든 게 솔로 파운더 한 명의 시간을 "더 많은 사용자 확보"에 집중시킨다.

11장 · Audience-first vs Build-first — 정직한 결론

1인 SaaS 커뮤니티에서 매년 반복되는 논쟁. 청중을 먼저 만들고 거기에 제품을 팔 것인가, 제품을 먼저 만들고 청중을 찾을 것인가?

11.1 Audience-first의 주장

대표적 옹호자: Arvid Kahl, Daniel Vassallo, Justin Welsh.

논리: 청중이 있으면 제품 출시 첫 날 1000명이 본다. 청중이 없으면 출시 첫 날 0명이 본다. 청중이 있으면 사용자의 진짜 문제를 안다 (그들과 매일 대화하니까). 청중이 없으면 추측한다.

증거: Pieter Levels의 X 50만 팔로워가 그의 모든 출시의 초기 추진력. Damon Chen의 80-90% 초기 고객이 X에서 왔다.

11.2 Build-first의 주장

대표적 옹호자: Pieter Levels (초기 시절), Tony Dinh.

논리: 청중 빌딩에 1년을 쓰는 동안 시장이 바뀐다. 일단 제품을 만들고 시장에 내놓아서 "사람들이 이게 필요한가?"를 빨리 검증해야 한다. 청중은 결과로 따라온다.

증거: Tony Dinh가 BlackMagic을 만든 시점에 그는 큰 청중이 없었다. 그가 X 청중을 구축한 건 BlackMagic의 성공 이후다.

11.3 솔직한 결론 — 둘 다 맞고, 시간 순서가 다르다

내가 본 패턴은 이렇다. 첫 출시 전에는 100-500명의 작은 청중을 만든다. 1년 걸리는 대규모 청중이 아니라, 같은 문제를 가진 100명의 진짜 청중. 이 사람들이 첫 50명 고객의 후보다.

그 다음 제품을 출시하고 사용자에게서 청중을 키운다. 사용자 인터뷰, 빌드 인 퍼블릭, 콘텐츠. 첫 출시 후에 청중 빌딩이 더 빠르다 — 진짜 사용자가 있으니까.

이게 audience-first도 build-first도 아닌, "작은 청중 → 제품 → 큰 청중"의 순환이다. 거의 모든 성공 케이스가 이 패턴을 따른다.

청중 0에서 제품을 출시하면 죽고, 청중 빌딩에만 매달려도 죽는다. 100-500명의 작은 청중으로 제품을 출시해서 진짜 피드백을 받고, 그 피드백으로 청중을 키운다. 이게 2026년의 정직한 길.

12장 · 90%가 실패하는 진짜 이유

이 글의 모든 케이스는 살아남은 10%다. 정직하려면 죽은 90%도 봐야 한다. 1인 SaaS 시장에서 가장 흔한 실패 패턴 7가지.

12.1 시장이 너무 작다

가장 흔한 실패. "이 도구가 있으면 좋겠다"는 친구 다섯 명의 말로 제품을 만들고, 정작 시장 전체에 100명의 잠재 고객만 있는 경우. 1인 SaaS도 충분한 시장이 필요하다. 보통 글로벌 잠재 고객 50K+, 5% 전환 가정 시 2500명, ARPU 30 USD/월로 75K MRR이 솔로 파운더의 합리적 시장 사이즈 하한이다.

12.2 분배 채널이 1개에 의존

X에만, SEO에만, Product Hunt에만 의존하면 그 채널이 변할 때 매출이 30-70% 사라진다. Pieter도 X 알고리즘 변경으로 도달이 줄어든 시기를 겪었다. 2-3개의 독립 채널이 안전선이다.

12.3 가격이 너무 싸다

솔로 파운더가 가장 자주 하는 실수. "9 USD/월"로 시작해서 100명을 모아도 900 USD/월. 직장 다니는 게 낫다. 정직한 1인 SaaS는 ARPU 30-100 USD/월에서 출발하고, B2B는 100-500 USD/월이 흔하다. 가격은 낮추기 쉽고 올리기 어렵다.

12.4 본인이 사용자가 아니다

본인이 매일 쓸 제품을 만들지 않으면, 진짜 사용자가 뭘 원하는지 모른다. Pieter는 노마드여서 Nomad List를 만들었다. Damon은 본인의 마케팅에 testimonial이 필요해서 Testimonial.to를 만들었다. Marie는 폼 빌딩에 좌절해서 Tally를 만들었다. 본인의 가려운 곳 → 진짜 제품의 패턴은 우연이 아니다.

12.5 시간 한정 도전을 했지만 시간이 모자랐다

"1년 안에 흑자 만들기" 같은 도전은 좋다. 다만 1인 SaaS의 통계는 흑자까지 18-24개월이다. Damon은 9개월에 100K ARR을 만들었지만, 이게 평균이 아니라 상위 5%다. 1년 안에 흑자 못 만들었다고 죽이지 말라.

12.6 외로움·번아웃

솔로 파운더의 80%가 처음 12개월 안에 외로움·번아웃으로 그만둔다는 통계가 있다. 같이 일할 사람이 없고, 매주 일요일이 월요일이고, 휴가가 자기 회사를 무방비로 두는 느낌이다.

해결책:

  • 동료 솔로 파운더의 작은 커뮤니티 (인디 해커스, MicroConf, 디스콰이엇)
  • 매주 1일은 일에서 강제 차단
  • 6개월에 한 번 진짜 휴가 (대부분의 솔로 파운더가 어기지만 어겨야 한다)

12.7 회계·세무를 무시한다

가장 무서운 함정. 1인 SaaS가 6자리 ARR을 만들기 시작하면 세무가 폭증한다. 글로벌 결제는 VAT, 미국 주별 세금, 한국 부가가치세, 종합소득세, 4대 보험, 법인세 vs 개인사업자. 회계사를 처음부터 두는 게 안전하다. 월 30-50만원의 비용이 1년 후 1000만원의 가산세를 막는다.

13장 · 한국 인디 메이커 씬

한국의 1인 SaaS 씬은 글로벌 메인스트림과 다른 패턴이 있다.

13.1 디스콰이엇 — 메이커 커뮤니티

디스콰이엇은 2020년 박현솔·홍은 (Jenny Hong)이 만든 한국 메이커 커뮤니티. Product Hunt의 한국형 버전 + 메이커 SNS. 2026년 기준 한국의 인디 메이커가 가장 많이 모이는 공간.

디스콰이엇에서 흔히 보이는 패턴:

  • 부업으로 시작한 SaaS
  • 본인의 가려운 곳을 긁는 제품 (생산성, 시간 관리, 학습)
  • B2C 중심 (한국 B2B SaaS의 진입 장벽이 높아서)

13.2 한국 1인 SaaS의 구조적 어려움

글로벌 솔로 파운더와 비교한 한국 시장의 차이:

  1. 결제·세무 마찰 — 한국 결제는 PG사 (이니시스, KCP) 의존이 강하고, 부가세·종합소득세 처리가 복잡하다. 글로벌 Stripe만으로 출시하면 한국 사용자가 결제 못 한다.
  2. 시장 사이즈 — 한국어 단일 시장은 5천만 명. 글로벌 영어 시장의 1/30 사이즈. ARPU도 보통 더 낮다.
  3. 언어 우위 부재 — 글로벌 영어 시장은 미국·EU·인도 등이 다 영어로 결제한다. 한국어 시장은 한국인만.

13.3 한국 1인 SaaS의 합리적 전략

이 구조적 어려움 때문에 한국 솔로 파운더가 흔히 가는 길은 두 가지다.

전략 A — 한국 특화 시장에서 독점

한국어·한국 문화·한국 법규에 깊게 박힌 제품. 부동산, 한국형 회계, 군대, 한국형 결제, 한국 학원 같은 영역. 글로벌 SaaS가 들어오기 어려운 해자.

예시: 줌인터넷의 사적·공적 결제 솔루션, 한국 학원 관리 SaaS, 한국 부동산 매물 도구. 시장은 작지만 한국 메이커만 진입 가능한 영역.

전략 B — 처음부터 글로벌

한국 시장 무시. 처음부터 영어 사이트, 글로벌 Stripe, X·Product Hunt 분배. Tony Dinh의 베트남 모델과 같다.

예시: TaskAde (한국인 파운더 John Xie의 글로벌 협업 도구). 한국 사용자 비중이 5% 미만일 가능성. 처음부터 영어권 시장 타겟.

두 전략의 중간 — "한국에서 시작해서 글로벌로" — 은 가능하지만 어렵다. 한국어 제품을 영어로 번역해서 글로벌에서 통하려면 메시지·기능·문화가 다 다시 디자인되어야 한다.

13.4 한국 1인 메이커의 흔한 실패

  • 법인 vs 개인사업자 결정 미루기 — 매출 1억 원 넘으면 법인이 유리한 경우가 많다. 회계사와 상담을 미루지 말 것.
  • 부가세 무시 — 글로벌 결제만 받다가 한국 사용자에게 부가세를 받지 않은 채로 매출 신고 시 폭탄.
  • 건강보험·국민연금 — 1인 사업자도 4대 보험 의무. 매출이 늘면 보험료가 같이 늘어난다.

한국 1인 SaaS의 진짜 차별 변수는 기술이 아니라 세무·법무·결제의 마찰을 얼마나 빨리 처리하는가이다. 시작 첫 3개월 안에 회계사·세무사와 한 번 상담하라. 이게 2년 후의 죽음을 막는다.

에필로그 — 1인 SaaS를 시작하기 전 체크리스트

이 글의 모든 케이스를 합쳐서 만든 정직한 체크리스트.

시작 전 체크리스트

[ ] 본인이 매일 쓸 제품인가? (사용자 = 본인)
[ ] 글로벌 잠재 고객 50K+ 인가? (시장 사이즈 확인)
[ ] 6-18개월 캐시 런웨이가 있는가? (현실의 시간)
[ ] X 또는 LinkedIn에 100명 이상의 진짜 청중이 있는가?
[ ] 24개월간 매일 일할 의지가 있는가?
[ ] 외로움·번아웃에 대한 대비책이 있는가? (커뮤니티, 친구, 휴식)
[ ] 회계사·세무사와 첫 상담을 잡았는가?
[ ] 가격을 30 USD/월 이상으로 시작할 수 있는가?

첫 90일 액션 플랜

1-30일:
  - 5명의 잠재 사용자와 인터뷰 (그들의 진짜 문제 확인)
  - 최소 가능 제품 (MVP) 설계
  - 도메인 등록 + 랜딩 페이지 (Beehiiv·Substack로 이메일 수집)
  - X·LinkedIn에 매일 빌드 진척 공유 시작

31-60일:
  - MVP 코드 시작 (Cursor + Claude Code + Next.js + Stripe)
  - 초기 청중 100명 목표 (이메일 리스트)
  - 베타 사용자 10명 모집

61-90일:
  - 유료 출시 (가격 50-100 USD/월)
  - 첫 10명 유료 사용자 확보
  - 모든 사용자와 1:1 통화
  - 첫 분기 매출·환불·교회 패턴 분석

안티 패턴 (피해야 할 것)

- 분배 채널 1개에 100% 의존 (X든 SEO든)
- 무료 티어를 너무 관대하게 (대부분의 1인 SaaS는 freemium에 부적합)
- 본인이 안 쓰는 제품 만들기
- 직원을 매출 정착 전에 뽑기 (400K ARR 전까지는 솔로 추천)
- 외주에 의존해 핵심 기술을 모름
- "올해 안에 100만 달러" 같은 비현실적 목표
- 세무·법무를 미루기 (6개월 후 폭탄)
- 모든 기술을 새 트렌드로 (Pieter는 PHP로 3M ARR을 만든다)
- 6개월간 매출 0이라고 죽이기 (18-24개월이 정상)
- 청중 빌딩 없이 출시 후 "왜 아무도 안 사는가?"

다음 글 예고

다음 글에서는 "한 사람이 36개월 동안 무엇을 했는가" — 이 글의 케이스 중 한 명의 매일의 시간 분배를 디테일하게 본다. 코드 시간, 마케팅 시간, CS 시간, 쉬는 시간. 1인 비즈니스의 진짜 일상.

그 다음은 AI 시대의 솔로 파운더 — 에이전트가 운영의 70%를 자동화한 후 인간이 남은 30%에서 무엇을 해야 하는가. 2027년의 1인 SaaS는 어떤 모습일지에 관한 정직한 추측.

참고 / References

Discuss on Twitter • View on GitHub