사이드 프로젝트 만드는 건 재밌다. 문제는 사람들이 실제로 쓰기 시작한 다음이다.

100명의 벽

Threads에서 1인 마이크로 SaaS 운영자가 쓴 글이 계속 머릿속에 맴돈다. 핵심은 이거였다 — "100명만 되어도 고객 CS 이메일 응대가 시간을 다 잡아먹는다."

겨우 100명이다. MRR로 치면 월 500~1,000 수준, 어디 가서 자랑하기도 민망한 숫자다. 그런데 그 100명이 만들어내는 문의, 버그 리포트, 기능 요청, 결제 오류를 퇴근 후에 혼자 감당하려면 하루가 48시간이어도 모자란다. 주말에 노트북 덮을 수가 없다. 슬랙 알림이 멈추질 않는다.

수치로 보면 감이 온다. 유저 100명 중 5%만 한 달에 문의 한 건을 넣어도 주당 최소 한두 건이다. 실제로는 결제 실패, 비밀번호 초기화, "이 기능 어디 있어요" 같은 단순 질문까지 합치면 주당 5~10건으로 뛴다. 건당 평균 응대 시간 15분이면, 퇴근 후 가용 시간의 절반 이상이 증발한다. 코드 한 줄 안 건드리고 하루가 끝나는 주가 생긴다.

만들어서 돈 벌겠다는 꿈은 좋은데, "돈 버는 제품"과 "운영 가능한 제품"은 전혀 다른 이야기다.

코드는 한 번이지만 CS는 매일이다

사이드 프로젝트를 시작할 때 머릿속에 그리는 로드맵은 대충 이렇다:

  1. 아이디어 떠오름

  2. MVP 빌드

  3. 출시

  4. 수익화

  5. 퇴사

현실에선 3번과 4번 사이에 거대한 블랙홀이 숨어 있다. 온보딩 문서 만들고, FAQ 정리하고, 이메일에 답하고, 환불 처리하고, 오류 재현하고... 코드 짜는 시간보다 운영에 쓰는 시간이 세 배는 된다. 이걸 퇴근 후 두 시간으로 커버하려면 금방 번아웃이 온다.

Dmytro Krasun이라는 인디 해커가 있다. 여러 프로젝트에서 연달아 실패하다가, 자기 기준을 확 낮추고 나서야 월 $25k까지 올렸다. 그가 낮춘 건 기술적 야망이 아니라 운영 복잡도다. CS가 적게 드는, 셀프서브가 되는 제품을 골랐다.

비슷한 사례가 또 있다. Plausible Analytics는 Google Analytics 대안으로 시작했는데, 초기부터 철저하게 셀프서브 온보딩에 집중했다. 스크립트 태그 하나 복붙하면 끝이라는 구조 자체가 CS 볼륨을 억제한다. 반대로 Basecamp의 DHH는 37signals 초창기에 "CS는 전원이 돌아가며 한다"는 원칙을 세웠다. 회사 규모가 되니까 그게 가능하지, 1인 운영에서 그 방식은 자살 행위다.

여기서 반론 하나. "그래도 CS 과정에서 유저 니즈를 직접 듣는 게 제품 개선에 필수 아니냐"는 주장이 있다. 틀린 말은 아니다. 초기 50명의 피드백은 금이다. 하지만 같은 질문이 열 번째 반복될 때도 직접 타이핑하고 있으면 그건 학습이 아니라 낭비다. 패턴이 보이는 순간 문서화하거나 자동화로 넘겨야 한다. 듣는 것과 반복 응대를 혼동하면 안 된다.

자동화가 답인가

2026년 1인 SaaS 운영자들 사이에서 반복되는 패턴이 있다. 고객 대응의 70~80%를 어떻게든 자동화한다는 것.

  • 반복 질문은 챗봇이 처리

  • 결제·환불은 Stripe webhook으로 즉시 해결

  • 에러 로그가 Slack 채널에 자동으로 올라옴

  • 온보딩 이메일 시퀀스 5통을 가입 시점에 맞춰 자동 발송

대단한 기술 스택이 아니다. 노가다를 줄이는 배관 공사에 가깝다. 그런데 이 배관 공사를 MVP 단계에서 안 해두면, 유저가 50명만 넘어도 숨이 막힌다.

구체적으로 뭘 먼저 깔아야 하나. 경험상 ROI가 가장 높은 세 가지가 있다. 첫째, Stripe Customer Portal 연동. 유저가 직접 플랜 변경, 카드 수정, 구독 취소를 할 수 있게 하면 결제 관련 문의의 60% 이상이 사라진다. 둘째, 앱 내 상태 페이지. 서버가 느려질 때 "지금 장애인가요?" 문의가 쏟아지는데, status 배지 하나면 된다. 셋째, 가입 직후 인터랙티브 온보딩 — 별도 가이드 문서를 읽으라고 하면 아무도 안 읽는다. 제품 안에서 3단계로 끝내는 게 맞다.

물론 자동화 만능론도 경계해야 한다. 챗봇이 엉뚱한 답변을 뱉어서 유저를 더 화나게 만드는 경우, 환불 자동화가 남용돼서 매출이 새는 경우도 실제로 겪는다. 자동화는 "인간 개입이 필요 없는 케이스"에만 적용해야 한다. 감정이 섞인 불만, 복잡한 기술 이슈, 보안 문제 — 이런 건 직접 손으로 답해야 한다. 자동화 범위를 잘못 잡으면 오히려 이탈률이 올라간다.

빌드 전에 CS 플로우부터

"어떤 프레임워크 쓸까"는 열심히 고민하면서 "유저 200명일 때 CS를 어떻게 처리하지"는 아무도 생각 안 한다. 다음 프로젝트에서는 기능 명세 옆에 문의 발생 포인트를 리스트업해 보자. 각 포인트를 문서 하나로 막을 수 있는지, 자동화할 수 있는지 따지는 게 두 번째 MVP다.

실무에서 써먹을 수 있는 간단한 프레임워크가 있다. 기능 하나를 설계할 때마다 옆에 "이 기능에서 유저가 막힐 수 있는 지점"을 적는 것이다. 예를 들어 파일 업로드 기능이면 — 용량 제한 초과, 지원하지 않는 포맷, 업로드 중 타임아웃. 이 세 가지 각각에 대해 에러 메시지를 명확하게 쓰고, 해결책을 UI 안에 넣어두면, 관련 문의의 대부분은 발생 자체가 안 된다. 코드 100줄이면 되는 일을 안 해서 매주 3시간씩 이메일을 쓰고 있다면, 그건 기술 부채가 아니라 운영 부채다.