이런 분이 읽으면 좋습니다
요약: SaaS는 “소프트웨어를 만드는 일”이 아니라 “서비스를 운영하는 일”이다. 한 번 팔고 끝나는 패키지 소프트웨어와 달리 SaaS는 계약을 구독으로 유지하고, 인프라를 24/7 살아 있게 하고, 데이터를 격리하며, 지속적으로 배포해야 한다. 이 문서는 SaaS를 0에서부터 만들고 운영하는 전 과정을 기획·설계·개발·인프라·런칭·운영·성장·조직까지 9단계로 나누어 정리한 실무 가이드다.
이 글은 0→1 SaaS 창업자, 1→10 단계에서 조직과 시스템을 정비하는 CTO/Lead Engineer, 그리고 SaaS 전환을 검토하는 기존 소프트웨어 팀을 위해 썼다. 모든 주제를 깊게 다루기보다, 각 단계에서 반드시 결정해야 할 지점과 그 결정이 뒤의 단계에 어떻게 파급되는지를 잡아내는 데 초점을 맞춘다.
0. 들어가며 — SaaS의 본질
SaaS의 핵심은 세 가지다.
첫째, 멀티테넌시(Multi-tenancy). 여러 고객이 하나의 시스템을 공유하면서도, 서로의 데이터가 완벽히 격리되어야 한다. 이 설계를 어떻게 하느냐가 확장성, 비용, 보안 전부를 좌우한다.
둘째, 구독 기반 수익 모델. 매출이 한 번에 들어오지 않고 매달/매년 반복된다. 따라서 “고객이 떠나지 않는 것(Retention)“이 “새 고객을 얻는 것(Acquisition)“만큼 중요하다. MRR, Churn, LTV 같은 지표가 회사의 건강을 판단하는 기준이 된다.
셋째, 지속 배포(Continuous Delivery). 고객은 항상 최신 버전을 쓴다. 버저닝, 호환성, 롤백, 데이터 마이그레이션을 매일 신경 써야 한다.
1. 기획 단계 — 무엇을, 누구에게, 왜 파는가
1.1 문제 발굴과 시장 검증
좋은 SaaS는 언제나 “반복되고, 돈이 걸려 있고, 현재 해결책이 불편한 문제”에서 시작한다. 아이디어가 있다면 다음을 먼저 검증한다.
- Painful: 고객이 실제로 돈을 낼 만큼 아픈 문제인가, 아니면 “있으면 좋은” 정도인가.
- Frequent: 자주 발생하는 문제인가. 1년에 한 번만 겪는 문제는 구독 모델과 맞지 않는다.
- Urgent: 지금 해결해야 하는가, 미루어도 되는가.
- Underserved: 기존 솔루션이 부족하거나 비싸거나 쓰기 나쁜가.
검증 방법은 고전적이지만 유효하다. 잠재 고객 인터뷰 30명 이상(이하면 샘플이 부족하다), 경쟁 제품 리뷰 스크래핑, 커뮤니티/Reddit/링크드인에서의 불만 수집, 그리고 가장 강력한 신호인 “사전 결제 의향” 확인. “관심 있다”는 말은 거짓말이 많지만, 신용카드를 꺼내는 손은 정직하다.
1.2 ICP(Ideal Customer Profile) 정의
“모두를 위한 제품”은 아무도 위하지 않는다. ICP는 최소한 다음 항목으로 구체화한다.
- 회사 규모(종업원 수, 매출)
- 산업군
- 역할/직함(누가 사고, 누가 쓰는가 — 이 둘은 다를 수 있다)
- 기존에 사용하는 도구 스택
- 예산 의사결정 구조
- 고통의 심각도와 빈도
B2B라면 구매자(Buyer), 사용자(User), 챔피언(내부에서 도입을 밀어주는 사람), 가드(보안/법무 등 막는 사람)를 분리해서 그려야 한다. 이 넷이 다른 사람일 가능성이 매우 높다.
1.3 가치 제안과 포지셔닝
April Dunford의 포지셔닝 프레임이 실무에서 가장 쓸모 있다.
- Competitive alternatives: 고객이 우리 제품이 없을 때 쓰는 것(경쟁사일 수도, 엑셀일 수도, 수동 업무일 수도 있다)
- Unique attributes: 우리만 가진 특징
- Value: 그 특징이 고객에게 주는 실질적 가치
- Target: 그 가치를 가장 절실히 원하는 고객
- Market category: 고객이 우리를 어느 카테고리로 인식하게 할지
이 다섯을 정리하지 않으면 랜딩 페이지의 헤드라인이 흔들리고, 세일즈 토크가 흔들리고, 결국 제품 방향도 흔들린다.
1.4 비즈니스 모델과 가격 전략
주요 SaaS 가격 모델:
- Per-seat(좌석당): Slack, Notion. 사용자 수에 비례. 단순하지만 고객이 “라이선스를 아끼려” 계정을 공유한다.
- Usage-based(사용량): AWS, Twilio, OpenAI API. 사용량에 비례. 확장성은 좋지만 고객이 청구서를 예측하기 어려워한다.
- Tiered(티어링): Free / Pro / Business / Enterprise. 가장 흔하고 안정적. 티어 간 이동 경로(업그레이드 트리거)를 명확히 설계해야 한다.
- Flat fee: 작은 도구에 적합. 확장이 제한된다.
- Hybrid: 좌석당 + 사용량, 기본료 + 사용량 등. 현실적으로 가장 많이 쓰인다.
가격 책정 원칙:
- Value-based pricing: 원가가 아니라 고객에게 주는 가치를 기준으로. 고객이 월 $10,000를 절약한다면 $500은 충분히 싸다.
- 3-tier 심리: 3개 플랜일 때 중간 플랜이 가장 많이 팔린다(앵커링 효과). 실제로 팔고 싶은 플랜을 중간에 둔다.
- Annual discount: 연 결제 시 15~20% 할인. 현금 흐름과 Retention을 동시에 개선한다.
- Enterprise = Contact Sales: 상단 플랜은 가격을 공개하지 않는다. 협상 여지를 남기고, 가격 민감도가 낮은 큰 계약을 높여 잡기 위함이다.
1.5 MVP 정의와 로드맵
MVP는 “최소”가 아니라 “Viable(생존 가능한)“이 핵심이다. 고객이 실제로 가치를 얻고 돈을 낼 수 있는 최소 제품.
MVP 범위를 정할 때 유용한 원칙:
- Walking Skeleton: 처음부터 end-to-end가 동작하는 얇은 버전을 만든다. 회원가입 → 핵심 기능 1개 → 결제까지 이어지는 뼈대.
- No-GO 리스트를 명시: 무엇을 안 만들 것인가를 적어둬야 스코프 크립을 막는다.
- 6~12주: 그 이상은 MVP가 아니다.
로드맵은 Now / Next / Later 3단 구조가 실용적이다. 날짜를 못 박는 간트차트는 거의 항상 틀린다. “Now는 확정, Next는 방향, Later는 가설” 정도의 뉘앙스로 관리한다.
2. 제품 설계 단계
2.1 요구사항 분석
기능 요구사항(Functional)과 비기능 요구사항(Non-functional)을 분리해서 정리한다. SaaS에서 비기능 요구사항이 특히 중요하다.
비기능 요구사항 체크리스트:
- 가용성(Availability): 목표 SLA(99.9% = 월 43분 다운, 99.95% = 월 21분, 99.99% = 월 4분)
- 성능: p50/p95/p99 응답시간 목표
- 확장성: 동시 사용자, 초당 요청, 데이터 증가율 추정
- 보안: 인증 방식, 암호화, 접근 제어
- 컴플라이언스: GDPR, SOC 2, ISO 27001, HIPAA 등 타겟 시장에 필요한 것
- 관찰 가능성(Observability): 로그, 메트릭, 트레이스
- 데이터 레지던시: 특정 국가에 데이터가 저장되어야 하는가
2.2 UX 리서치와 디자인
SaaS UX의 두 축:
- First-run experience (온보딩): 신규 사용자가 “Aha moment”에 얼마나 빨리 도달하는가. Time-to-value(TTV)가 짧을수록 전환율이 높다.
- Daily usage: 매일 쓰는 핵심 플로우가 얼마나 빠르고 효율적인가.
실무에서 꼭 설계하는 것들:
- Empty state (데이터 없을 때 화면)
- Loading state (로딩 스켈레톤)
- Error state (오류 메시지와 복구 경로)
- Permissions state (권한 없을 때의 안내)
- Paywall / Upgrade state (플랜 한도 도달 시)
디자인 시스템은 초기부터 도입한다. Tailwind + shadcn/ui, Radix, Material 등. 한 번 스타일이 퍼진 뒤 통일하는 것은 거의 재작업에 가깝다.
2.3 시스템 아키텍처 설계
모놀리스 vs 마이크로서비스 초기에는 거의 항상 모놀리스가 정답이다. Shopify, GitHub, Basecamp 전부 초창기(와 많은 경우 지금까지도) 모놀리스다. 팀이 20명을 넘고 배포 주기가 서로 다른 도메인이 생겼을 때 비로소 쪼개는 것이 일반적이다. “Majestic Monolith”라는 표현이 괜히 나온 게 아니다. 결정 전에 모듈러 모놀리스 vs 마이크로서비스 트레이드오프를 한 번 훑고 가는 쪽이 안전하다.
동기 vs 비동기 결제, 메일 발송, 리포트 생성, 외부 API 호출, 대용량 처리는 워커 큐로 비동기화한다. 주로 Sidekiq, Celery, BullMQ, AWS SQS + Lambda, RabbitMQ 등이 쓰인다. “사용자 요청 → 즉시 200 응답 → 백그라운드에서 처리 → 완료되면 알림” 패턴이 기본이다.
2.4 멀티테넌시 전략 (SaaS의 핵심 결정)
세 가지 모델이 있고, 선택에 따라 이후 모든 것이 달라진다.
1. Shared Database, Shared Schema (풀 공유)
- 모든 테넌트가 같은 DB, 같은 테이블. 모든 행에
tenant_id컬럼. - 장점: 운영/비용 효율 최고. 스키마 변경 한 번에 끝.
- 단점: 데이터 격리는 애플리케이션 코드에 전적으로 의존.
WHERE tenant_id = ?를 빼먹으면 바로 데이터 유출. - 적합: 초기 스타트업, SMB 타겟.
- 필수 대책: Row-Level Security(PostgreSQL RLS), ORM 레벨 강제 스코프(Rails
default_scope, Django Manager), 정기 감사 쿼리.
2. Shared Database, Separate Schema
- 같은 DB에 테넌트별 스키마. PostgreSQL의 schema 개념 활용.
- 장점: 격리 수준 중간. 스키마 단위 백업/복구 가능.
- 단점: 테넌트 수가 수천 개를 넘으면 관리가 어려워진다. 마이그레이션도 복잡.
- 적합: 중간 규모, 중견기업 타겟.
3. Separate Database (완전 분리)
- 테넌트마다 DB 인스턴스 또는 클러스터.
- 장점: 격리 최고. 성능 격리, 규제 대응(데이터 레지던시), 대형 고객 별도 관리 용이.
- 단점: 비용, 운영 복잡도 폭증. 마이그레이션 N번.
- 적합: 엔터프라이즈, 헬스케어, 금융.
현실적으로는 하이브리드가 많다. 일반 고객은 공유, 엔터프라이즈 고객은 전용 DB/전용 인프라. 이를 위해 초기부터 테넌트 라우팅 계층(어떤 테넌트가 어느 DB에 있는지 찾아주는 레이어)을 추상화해두는 것이 좋다. 테넌트 내 권한·역할 모델의 상세 설계는 멀티테넌트 권한 아키텍처에서 따로 다뤘다.
2.5 데이터 모델 기본 원칙
- 모든 테이블에
tenant_id,created_at,updated_at,deleted_at(soft delete). 예외를 두지 않는다. - UUID vs 자동증가 ID: 외부 노출되는 식별자는 UUID(특히 UUIDv7은 인덱스 친화적). 내부 PK는 bigint가 성능 면에서 유리.
- 감사 로그(audit log): 누가 언제 무엇을 바꾸었는지. 엔터프라이즈 판매에 필수.
- 소프트 삭제: 고객 실수 복구, GDPR 대응, 규제 대응에 필요.
- 시계열/이벤트 테이블 분리: 고 쓰기 테이블은 트랜잭션 테이블과 분리.
2.6 API 설계
- REST가 기본, GraphQL은 프론트엔드가 복잡하고 클라이언트가 많을 때, gRPC는 내부 서비스 간.
- 버저닝:
/v1/,/v2/URL 버전이 가장 명확하다. Header 버전은 캐싱과 운영에 불리. - 페이지네이션: Cursor-based(
?cursor=xxx)가 offset보다 확장성이 좋다. - Idempotency-Key: 결제 등 중요한 POST는 클라이언트가 같은 요청을 두 번 보내도 한 번만 처리되도록.
- Rate Limiting: 기본적으로 모든 API에 적용. 플랜별로 다르게.
- Webhook: 고객이 우리 이벤트를 받을 수 있도록. 재시도, 서명(HMAC), 리플레이 방지를 반드시 구현.
- 공식 SDK: 최소한 JavaScript/Python은 초기에 제공. TypeScript 타입이 있는 SDK는 개발자 체감 품질을 크게 올린다.
2.7 보안과 컴플라이언스 설계
초기부터 고려해야 할 기본:
- 전송 중 암호화: HTTPS/TLS 1.2+ 강제.
- 저장 시 암호화: DB 암호화, 디스크 암호화. 민감 필드(PII, 결제정보, 토큰)는 애플리케이션 레벨에서 추가 암호화(KMS 사용).
- 비밀 관리: 환경변수 하드코딩 금지. AWS Secrets Manager, HashiCorp Vault, Doppler 등.
- RBAC (Role-Based Access Control): 테넌트 내 역할(Owner, Admin, Member, Viewer). 엔터프라이즈는 ABAC이나 세부 권한까지 요구.
- 감사 로그: 로그인, 권한 변경, 데이터 접근, 삭제 전부 기록.
- 세션 관리: 세션 만료, 동시 세션 제한, 수상한 로그인 알림.
컴플라이언스는 타겟 시장에 따라:
- GDPR (EU): 개인정보 처리 동의, 데이터 이동권(export), 삭제권(right to be forgotten).
- SOC 2 Type II: B2B SaaS에서 사실상 필수. 최소 6~12개월 운영 기록 필요.
- ISO 27001: 글로벌 엔터프라이즈 판매 시.
- HIPAA: 의료 데이터.
- PCI DSS: 카드 정보를 직접 다루면(보통 Stripe에 위임하면 SAQ-A 수준만 유지하면 된다).
SOC 2는 처음부터 Vanta, Drata, Secureframe 같은 자동화 도구를 쓰는 것이 표준이 되었다. 수작업으로 하면 엔지니어 수개월이 날아간다.
3. 개발 단계
3.1 기술 스택 선택
“재미”가 아니라 “팀이 빠르게 만들 수 있는가”가 기준이다.
일반적인 조합 예시:
- 풀스택 생산성: Ruby on Rails, Django, Laravel, Next.js + Node/Bun
- 타입 안정성: TypeScript + NestJS/Nest 스타일, Go, Kotlin
- DB: PostgreSQL이 거의 항상 정답. MySQL도 가능. NoSQL은 “구체적 이유가 있을 때만”.
- 캐시/큐: Redis.
- 검색: 초기에는 PostgreSQL Full-text search, 커지면 Elasticsearch/OpenSearch/Meilisearch.
- 프론트엔드: React + TypeScript가 생태계상 가장 안전. Vue, Svelte도 충분.
- 인프라: AWS/GCP/Azure 중 팀이 익숙한 것. 초기에는 Vercel, Render, Fly.io, Railway 같은 PaaS도 강력한 선택지.
3.2 인증/인가 시스템
자체 구축 vs 서비스 사용.
자체 구축이 합리적인 경우: 기본 이메일/패스워드 + 소셜 로그인 정도. Auth0, Clerk, WorkOS, Supabase Auth 같은 서비스가 합리적인 경우: SSO(SAML, OIDC), SCIM(자동 프로비저닝), MFA, 엔터프라이즈 기능이 필요할 때.
엔터프라이즈 고객이 오기 시작하면 거의 반드시 SAML SSO와 SCIM을 요구한다. 이걸 자체 구현하는 건 엔지니어 한 명의 수개월짜리 프로젝트다. WorkOS가 이 영역의 표준이 된 이유다.
토큰 전략:
- JWT: 상태를 가지지 않는 API에 적합. 단, 취소가 어려운 것이 약점 → 짧은 수명(15분) + refresh token 패턴.
- 세션 쿠키: 웹 앱에 적합. 서버 사이드 취소 용이.
- 많은 SaaS가 웹 앱은 세션 쿠키, API는 JWT 또는 API Key로 혼합해서 쓴다.
3.3 결제와 구독 시스템
Stripe가 사실상 표준이다. 결제 자체는 Stripe에 위임하되, 구독 상태와 플랜/한도 관리는 우리 DB에 미러링한다.
구현해야 할 것:
- 플랜 정의와 가격 관리
- 체크아웃 (Stripe Checkout 또는 Elements)
- 웹훅 처리 (
invoice.paid,customer.subscription.updated,customer.subscription.deleted등) - 멱등성(Idempotency): 웹훅은 여러 번 올 수 있음
- 연체/결제 실패 처리 (Dunning)
- 플랜 변경 시 비례 청구(Proration)
- 환불, 크레딧
- 세금 처리 (Stripe Tax, Avalara)
- 청구서 발행, VAT, 사업자 번호 수집
- 무료 체험, 쿠폰, 추천 할인
3.4 테스트 전략
SaaS에서 필수적인 테스트 레이어:
- 단위 테스트: 비즈니스 로직
- 통합 테스트: DB, 외부 API를 포함한 기능
- E2E 테스트: Playwright, Cypress로 주요 사용자 플로우
- 계약 테스트(Contract test): 외부 API와의 계약이 깨지지 않는지 (Pact 등)
- 성능 테스트: k6, Locust로 부하 테스트
- 보안 테스트: 정적 분석(SAST), 의존성 취약점 스캔(Dependabot, Snyk), DAST, 정기 모의침투
테스트 커버리지 수치보다 **“핵심 플로우에 대한 확신”**이 더 중요하다. 결제, 권한, 멀티테넌시 격리는 반드시 자동화된 테스트로 보호한다.
3.5 멀티테넌시 격리 실전
가장 많이 나는 사고가 테넌트 격리 누락이다. 방어 전략:
- 애플리케이션 레벨: 모든 쿼리에
tenant_id스코프 자동 적용. ORM의 미들웨어/스코프 사용. - DB 레벨: PostgreSQL Row-Level Security(RLS) 활성화. 애플리케이션 코드가 실수해도 DB가 막는다.
- 테스트: “Tenant A로 로그인 후 Tenant B의 리소스 ID로 접근 시 404/403이 반환되는가”를 모든 리소스에 대해 자동화 테스트.
- 감사 쿼리: 주기적으로 “tenant_id가 NULL이거나 잘못된 레코드”를 찾는 쿼리.
4. 인프라 구축
4.1 클라우드 전략
AWS, GCP, Azure 중 선택. 실무적 기준:
- AWS: 가장 넓은 서비스, 생태계. 초기 설정이 복잡.
- GCP: 데이터/ML 강점, UX 깔끔. 엔터프라이즈 인지도는 AWS보다 낮음.
- Azure: 엔터프라이즈/MS 중심 고객에 유리.
스타트업 관점의 3사 비교는 AWS · GCP · Azure 스타트업 선정 가이드에서, 프론트엔드 PaaS 선택은 Vercel · Netlify · Cloudflare Pages 비교에서 별도로 다뤘다.
초기 스타트업이라면 PaaS 계층부터 시작해도 된다:
- Vercel (Next.js 배포)
- Render, Railway, Fly.io (범용 컨테이너)
- Supabase, Neon (Postgres)
- Cloudflare (CDN, R2, Workers, D1)
이들은 속도를 극적으로 올려준다. 규모가 커지거나 비용이 부담되면 그때 IaaS로 내려가면 된다.
4.2 컨테이너와 오케스트레이션
Docker는 사실상 필수. Kubernetes는 필요해질 때까지 미룬다. 초기에는 ECS, Cloud Run, App Runner, Fly Machines 같은 관리형 컨테이너로 충분하다.
K8s가 필요한 시점의 신호:
- 서비스 수가 10개를 넘어감
- 팀이 20명을 넘어감
- 엔터프라이즈 고객이 “Helm 차트로 온프렘 배포”를 요구
4.3 CI/CD
기본 파이프라인:
PR 생성 → 린트 → 단위/통합 테스트 → 빌드 → 미리보기 배포 → 리뷰 → 머지
머지 → 스테이징 배포 → E2E 테스트 → (수동/자동) 프로덕션 배포배포 전략:
- Rolling: 가장 흔함. 무중단.
- Blue-Green: 두 환경을 번갈아. 롤백이 빠르다.
- Canary: 새 버전을 1% → 10% → 100%로 점진적으로. 대규모 서비스에서 표준.
- Feature Flag: 배포와 릴리스를 분리. LaunchDarkly, Unleash, PostHog flags 등.
4.4 옵저버빌리티 (3대 기둥)
Logs (로그): 구조화된 JSON 로그. 모든 로그에 tenant_id, user_id, request_id 필수. Datadog, Grafana Loki, CloudWatch 등.
Metrics (메트릭): 시스템(CPU, 메모리, DB 커넥션), 애플리케이션(요청 수, 응답 시간, 에러율), 비즈니스(가입, 결제, MRR). Prometheus + Grafana 또는 Datadog. 모니터링 스택 3사 비교는 Datadog · Grafana · New Relic 비교에서 정리했다.
Traces (분산 추적): 요청이 서비스들을 어떻게 흘렀는가. OpenTelemetry가 표준. Datadog APM, Tempo, Honeycomb 등.
Error tracking: Sentry가 사실상 표준.
Uptime monitoring: Better Stack, Pingdom, UptimeRobot.
4.5 보안 하드닝
- 모든 인프라를 IaC(Infrastructure as Code)로 관리. Terraform, Pulumi.
- VPC로 격리, 퍼블릭 서브넷 최소화.
- 보안 그룹/방화벽은 최소 권한 원칙.
- DB는 퍼블릭 액세스 금지.
- IAM 역할은 최소 권한. 장기 액세스 키 지양.
- Secrets은 Vault/Secrets Manager.
- WAF(Web Application Firewall): Cloudflare, AWS WAF.
- DDoS 방어: CDN 레벨.
- 의존성 스캔: Dependabot, Renovate.
- 컨테이너 이미지 스캔: Trivy, Grype.
4.6 백업과 재해 복구(DR)
RPO (Recovery Point Objective): 얼마만큼의 데이터 손실을 허용하는가 (예: 15분). RTO (Recovery Time Objective): 얼마 만에 복구해야 하는가 (예: 1시간).
- DB 자동 백업 + Point-in-time Recovery (PITR) 최소 7일, 일반적으로 30일.
- 백업은 별도 리전/계정에 복제.
- 장애 시나리오별 Runbook 작성: “DB 마스터 장애”, “전체 리전 장애”, “삭제 사고” 등.
5. 런칭 단계
5.1 베타와 점진적 오픈
- Closed Alpha: 팀 내부 + 친한 고객 5~10명. 제품이 완전히 깨져 있어도 괜찮음.
- Closed Beta: 초대제 50~200명. 실제 데이터, 실제 사용. 피드백 채널 적극 운영.
- Open Beta / Early Access: 공개 대기열. 쿠폰/할인.
- GA (General Availability): 공식 런칭.
각 단계에서 “이걸 통과했으면 다음 단계로 간다”는 성공 기준(exit criteria)을 정의해둔다.
5.2 온보딩 설계
핵심은 Time-to-Value(가치 체험까지의 시간)를 줄이는 것.
- 회원가입은 최소 필드 + 소셜 로그인.
- 첫 로그인 후 즉시 데모 데이터 제공(Sample project).
- 체크리스트식 온보딩(Linear, Notion 방식).
- Empty state에서 다음 액션을 명확히 제시.
- “Aha moment”까지의 평균 시간을 측정하고 줄여나간다.
Product-led growth(PLG) 전략이라면 온보딩 품질이 전환율을 지배한다.
5.3 Go-to-Market
- PLG (Product-Led Growth): Free → Pro → Team으로 제품 안에서 자연스럽게 업그레이드. Slack, Notion, Figma, Linear 모델. SMB/개발자 중심 SaaS에 적합.
- SLG (Sales-Led Growth): Outbound + Inbound 영업 → 데모 → POC → 계약. 엔터프라이즈/고 ACV 제품에 적합.
- Hybrid: PLG로 저변 확대 + SLG로 엔터프라이즈 확장. 요즘 대다수의 B2B SaaS가 이 방향.
초기 마케팅 채널:
- 콘텐츠 SEO (블로그, 비교 페이지, 대안 페이지)
- 커뮤니티(Reddit, HN, Dev.to, 링크드인)
- Product Hunt
- 파트너십 (통합 디렉토리 등재)
- 설립자 개인 브랜드
5.4 고객 지원과 CS
- 초기에는 설립자가 직접 지원한다. 예외 없음. 가장 풍부한 제품 인사이트가 여기서 나온다.
- 도구: Intercom, HelpScout, Zendesk, Plain, Front.
- 지식베이스: 초기부터 작성. 같은 질문이 3번 오면 문서화.
- SLA는 플랜별로 차등(무료: 48시간, Pro: 12시간, Enterprise: 2시간 등).
6. 운영 단계
6.1 신뢰성 관리(SRE)
- SLI (Service Level Indicator): 측정할 지표 (예: 가용성, 응답시간).
- SLO (Service Level Objective): 우리 내부 목표 (예: 가용성 99.95%).
- SLA (Service Level Agreement): 고객 계약상 약속 (보통 SLO보다 살짝 느슨).
Error Budget: 100% - SLO가 우리가 “실패해도 되는 예산”. 이 예산을 다 쓰면 새 기능 배포를 멈추고 안정성에 집중한다. Google SRE의 핵심 아이디어다.
6.2 인시던트 관리
장애는 반드시 온다. 준비가 전부다.
프로세스:
- 탐지: 모니터링 알림, 고객 리포트.
- 분류(Severity): Sev1(전체 다운), Sev2(주요 기능 영향), Sev3(부분 영향), Sev4(경미).
- 대응(On-call): PagerDuty, Opsgenie, Better Stack. 로테이션.
- 커뮤니케이션: Status page(Statuspage, Instatus) 실시간 업데이트. 엔터프라이즈 고객에게는 별도 이메일.
- 복구.
- 포스트모템: Blameless 원칙. 사람이 아니라 시스템을 고친다. Root cause와 재발 방지 조치를 공개.
6.3 릴리스 관리
- 기본은 매일 혹은 매주 릴리스. “금요일 배포 금지”는 관습이지만 신뢰할 수 있는 CI/CD와 Feature flag가 있으면 크게 개의치 않아도 된다.
- Feature flag로 배포와 출시를 분리. 코드는 배포되어 있고, 기능은 flag로 점진적으로 켠다.
- 브레이킹 체인지는 최소화, 불가피할 경우 사전 공지 + deprecation 기간 + 마이그레이션 가이드.
- Changelog 공개 운영 (Linear, Headwayapp).
6.4 데이터 운영
- 쿼리 성능 모니터링: Slow query 로그, pg_stat_statements.
- 주기적 인덱스 리뷰.
- 데이터 증가 추세 모니터링. 용량 예측.
- 아카이빙 전략(오래된 데이터를 별도 스토리지로).
- 데이터 마이그레이션은 항상 뒤에서 먼저(shadow write → backfill → read 전환 → 구 테이블 드랍).
6.5 재무 운영
- MRR (Monthly Recurring Revenue): 월간 반복 매출. SaaS의 심장 지표.
- ARR (Annual Recurring Revenue): MRR × 12.
- Churn rate: 고객/매출 이탈률. 월 1% 이하가 SMB의 건강한 기준, 엔터프라이즈는 연 5% 이하.
- Net Revenue Retention (NRR): 기존 고객의 업셀/다운셀/이탈 반영한 매출 유지율. 100% 초과면 제품이 자생적으로 자란다는 뜻. 120% 이상이면 최상급.
- Gross Margin: SaaS는 70~80%가 표준. 낮으면 인프라 비용 또는 외부 API 비용(OpenAI 등) 구조 재검토.
- **CAC (Customer Acquisition Cost)**와 LTV (Lifetime Value), LTV/CAC > 3, CAC Payback < 12개월이 공식.
- Rule of 40: 성장률 + 영업이익률 ≥ 40%. 상장 SaaS의 건강 기준.
7. 성장과 확장 단계
7.1 데이터 기반 의사결정
- 제품 분석: PostHog, Amplitude, Mixpanel. 퍼널, Retention, Cohort 분석.
- 세션 리플레이: PostHog, Fullstory, Hotjar.
- 데이터 웨어하우스: BigQuery, Snowflake, Redshift. 프로덕션 DB에서 분석하지 말 것.
- ELT: Fivetran, Airbyte로 운영 DB → DW 복제. dbt로 모델링.
- BI: Metabase, Looker, Mode.
“가설 → 실험(A/B test) → 측정 → 학습” 루프를 내재화한다. 주간 단위 실험 리뷰.
7.2 Retention과 Expansion
새 고객 1명을 얻는 것보다 기존 고객 1명이 떠나지 않게 하는 것이 보통 5~10배 싸다.
- Activation: 첫 24~72시간 내 핵심 액션 유도.
- Habit loop: 주 단위 반복 사용 유도.
- In-app 메시지: 핵심 기능 미사용 시 힌트.
- Churn 예측 모델: 사용 빈도 감소, 팀원 감소, 결제 실패 등을 신호로.
- Expansion: 좌석 추가, 기능 업셀, 업 플랜 전환.
7.3 엔터프라이즈화
SMB SaaS가 엔터프라이즈 고객을 받기 시작하면 다음이 필요해진다.
- SSO (SAML, OIDC)
- SCIM (자동 사용자 프로비저닝)
- 감사 로그 API
- 세부 권한 제어(Custom roles)
- 데이터 레지던시 (EU 데이터는 EU에)
- 커스텀 MSA, DPA
- SOC 2, ISO 27001 인증서
- 전담 CSM (Customer Success Manager)
- SLA 99.9% 이상 보장
- Sandbox / Staging 환경 제공
이 패키지가 “Enterprise Plan”의 실체다.
7.4 국제화
- i18n: 초기부터 문자열 하드코딩 금지. 번역 키 사용.
- l10n: 단순 번역을 넘어 날짜/통화/숫자 포맷, 우→좌(RTL).
- 결제 통화와 세금(VAT, GST).
- 지역별 인프라: 미국/EU/APAC 리전.
- 법적: 개인정보, 세무, 현지 법인.
8. 조직과 문화
8.1 초기 팀 구성
0~10명 단계의 일반적 구성:
- 공동 창업자 2~3명 (제품, 기술, 세일즈 중 하나씩)
- 풀스택 엔지니어 2~4명
- 디자이너 1명
- 고객 지원/CS 1명 (초기엔 창업자가 겸직)
10~30명 단계에서 추가되는 역할:
- Product Manager
- DevOps/SRE
- 세일즈, 마케팅
- 데이터 분석가
8.2 개발 프로세스
- 2주 스프린트 또는 Kanban. 초기 스타트업은 Kanban이 더 유연.
- 주간 제품 리뷰: 지표와 배운 것 공유.
- Writing culture: RFC/Design doc 작성 문화. Stripe, Amazon, GitLab의 공통 패턴.
- On-call 로테이션: 엔지니어 전원이 본인 코드의 운영 결과를 책임진다.
9. 단계별 체크리스트 요약
기획
- 문제 검증 완료(인터뷰 30+)
- ICP 정의
- 가격 모델 3개 비교 후 결정
- MVP 범위와 No-GO 리스트 확정
설계
- 멀티테넌시 모델 결정
- 비기능 요구사항 정의
- 데이터 모델과 API 설계
- 보안/컴플라이언스 목표 설정
개발
- 인증/결제 시스템 구현
- 테넌트 격리 자동화 테스트
- Observability 계측
- 테스트 자동화 파이프라인
인프라
- IaC로 전 환경 관리
- CI/CD 파이프라인
- 로그/메트릭/트레이스/에러 트래킹
- 백업 + 복구 리허설 완료
런칭
- 온보딩 플로우 최적화
- Status page 오픈
- 지원 채널과 SLA 정의
- 쿠폰/체험 정책
운영
- On-call, 인시던트 프로세스
- 주간 SLO 리뷰
- 포스트모템 템플릿
- MRR/Churn/NRR 주간 리포트
성장
- 제품 분석, DW 구축
- 실험 프로세스
- Retention 프로그램
- 엔터프라이즈 패키지(SSO, SCIM, 감사 로그, 보안 인증)
맺으며
완벽한 SaaS는 없다. 다만 위의 각 단계에서 적어도 한 번씩 “우리는 지금 이걸 제대로 하고 있는가”를 스스로 점검하는 팀이 살아남는 SaaS를 만든다.