"혼자 SaaS 만들어 운영하면 서버·장애·업데이트 다 어떻게 감당하세요?"라는 질문을 받습니다. 정답은 "처음부터 혼자 감당 가능한 구조로 짓는다"입니다. 팀 사이즈가 커지면 감당되는 구조가 달라지기 때문에, 초기 선택이 중요합니다. 실제로 제가 운영 중인 1인 SaaS의 스택과 원칙을 공개합니다.
원칙 — "새벽 3시에 일어나지 않는 구조"
1인 운영의 품질 지표는 기능 수가 아니라 "장애로 깨는 횟수"입니다. 저는 이 숫자를 월 0회로 유지하는 것을 목표로 설계합니다. 그러려면 세 가지가 필요합니다: 관리형 서비스 최대 사용, 의존성 최소화, 알림 우선순위 정립.
현재 사용 중인 스택
- 프론트: SvelteKit + Vercel. SSR·ISR·CDN·도메인이 한 번에. 배포는 git push 뒤 1~2분.
- 백엔드: FastAPI + AWS Lightsail(서울) 또는 Fly.io. 관리형이 아니지만 월 5~20달러에 간단하고 안정적.
- DB: PostgreSQL — 초반엔 동일 Lightsail 안, 규모 커지면 RDS로 분리. 백업은 자동 스냅샷.
- 파일: S3(서울 리전). 썸네일·첨부·이미지 전부. 버저닝 + 수명정책 필수.
- 인증: 직접 JWT. Supabase/Clerk도 좋지만 단순 구조면 자작이 오히려 빠름.
- 결제: Stripe 또는 Toss Payments. 두 서비스 다 구독 플로우가 표준화돼 있음.
- 이메일: Resend 또는 SES. 월 1만 건까지 거의 무료.
- 모니터링: Sentry(에러) + UptimeRobot(가동). 무료/저가 조합.
의도적으로 "쓰지 않는" 것들
Kubernetes: 1인에게 과잉. 단일 서버 + systemd로 충분. 마이크로서비스: 트래픽이 없으면 분리의 이점이 0. 단일 레포 + 단일 앱이 압도적으로 운영 편함. 실시간 시스템: 필요해질 때 도입. 초기엔 폴링으로 충분한 경우가 대부분.
배포·운영 자동화 — 1인의 생존 요소
- git push → 자동 배포: GitHub Actions가 서버에 ssh + git pull + systemctl restart. 5분 세팅, 이후 평생 유지.
- DB 마이그레이션: Alembic 또는 수동 SQL 파일 폴더. 1인일 땐 수동 스크립트가 오히려 정확함.
- 백업: Lightsail 자동 스냅샷 + S3 야간 pg_dump 복사. 이중화 원칙은 1인도 지키는 편이 낫습니다.
- 비밀 관리: .env + 서버 환경변수. 초기엔 Vault 같은 거 필요 없음.
알림 우선순위 — "진짜 급한 것만 깨우기"
- P0 (휴대폰 알림): 전체 서비스 다운, DB 접속 실패, 결제 실패율 급증.
- P1 (이메일 즉시): 특정 엔드포인트 에러율 상승, 디스크 사용량 80% 돌파.
- P2 (일간 요약): 버그 리포트 누적, 사용자 문의, 트래픽 변화.
알림이 너무 많으면 결국 아무것도 보지 않게 됩니다. P0만 깨우고 나머지는 아침에 10분으로 처리하는 구조가 오래갑니다.
성장 시 다음 단계
MRR 월 300~500만 원 도달: RDS 분리, 전용 모니터링(Datadog/NewRelic), CDN 분리. MRR 월 1천만 원: 보조 인력(파트타임 개발자·CS) 1명 합류. 여기까지는 1인이 거뜬히 감당됩니다.
한 가지만 기억
1인 SaaS의 적은 "확장성"이 아니라 "복잡성"입니다. 복잡성을 꾸준히 낮추는 설계가 곧 장수의 기술입니다. 매달 스택의 한 구석을 정리하는 시간을 30분씩 배정하면 3년 뒤에도 새벽에 깨지 않는 시스템으로 남습니다.