피드로 돌아가기
Dev.toBackend
원문 읽기
I Built an Uptime Monitoring SaaS in a Weekend — Here's What I Learned
개발자가 주말 3일에 업타임 모니터링 SaaS를 구축해 50명 사용자와 3명 유료 고객 확보
AI 요약
Context
기존 업타임 모니터링 서비스(Uptime Robot)에 월 $15를 지불하면서도 전체 기능의 30%만 사용하고 있었다. 실제 필요한 기능은 단순했다: HTTP 요청 30초 주기 확인과 장애 발생 시 알림 기능뿐이었다.
Technical Solution
- HTTP 엔드포인트 모니터링 엔진 구축: Node.js + Express로 HEAD 요청을 사용하여 30초 주기 체크 구현
- 재시도 로직으로 거짓 양성 제거: DNS 타임아웃 발생 시 10초 대기 후 재시도, 2회 연속 타임아웃 시에만 알림 발송 (거짓 양성 10% → <1%)
- 타임아웃 처리 추가: 각 체크마다 10초 타임아웃 설정으로 무한 대기 상태 방지
- 동시 연결 제한과 HTTP/2 Keep-Alive 활용: 1000개 사이트당 초당 1개 요청으로 부하 분산
- SQLite 데이터베이스 스키마 설계: 모니터(monitors), 체크 기록(checks), 알림(alerts) 테이블로 단순화
- Stripe 결제 통합: webhook 이벤트(customer.subscription.created, charge.succeeded) 처리와 결제 실패 시 자동 다운그레이드 로직 구현
- DigitalOcean $5/month 드롭렛에 배포 및 Let's Encrypt로 HTTPS 구성
Impact
- 첫 24시간 내 50명 사용자 확보 (IndieHackers ~20, Dev.to ~15, Reddit ~8, Twitter ~5)
- 3명의 유료 고객 확보
- 거짓 양성 비율 10%에서 1% 미만으로 감소
Key Takeaway
SaaS 제품의 성공은 완벽한 기능보다 단순함에 있다. 빌드하지 않기로 결정한 항목(인공 사용자 여정, 고급 대시보드, 다중 플랫폼 통합)이 빌드하기로 결정한 항목과 같은 가치를 가진다. 실제 사용자 피드백을 받으면서 최소 기능 집합(HTTP 체크, 이메일/webhook 알림, 단순 대시보드)으로 72시간 내 출시하는 것이 3개월 계획보다 효과적이다.
실천 포인트
업타임 모니터링이나 정기 헬스 체크가 필요한 서비스에서 재시도 로직(첫 타임아웃 후 대기 → 재시도 → 2회 연속 실패 시 알림)을 구현하면 환경 변수로 인한 거짓 양성을 10% 이상 감소시킬 수 있다. 또한 동시 연결 수를 제한하고 HTTP/2 Keep-Alive를 활용하면 대량의 주기적 요청 부하를 효율적으로 분산할 수 있다.