MRR $14,043. 유료 고객 652명. 팀원은 창업자 혼자.
Healthchecks.io 창업자가 9년 운영 회고록과 기술 스택 공개 글을 올렸습니다. 서버 비용은 Hetzner 9대 €484/월. 더 벌거나 더 키우는 것보다, 지금 이 삶을 유지하는 게 목표라고 했습니다.
크론잡(cron job) 모니터링 서비스입니다.
개념은 단순합니다. 내 서버에서 백업 스크립트가 새벽 2시에 돌아야 하는데, 정말 잘 돌았는지 어떻게 압니까? 서버가 죽었거나 스크립트가 실패했을 때 아무도 모르면 문제입니다.
Healthchecks.io는 이걸 해결합니다. 크론잡이 성공하면 특정 URL로 HTTP 요청을 보냅니다. 정해진 시간 안에 신호가 안 오면 알림을 쏩니다. 이게 전부입니다.
이 개념을 데드맨 스위치(Dead Man's Switch)라고 합니다. 사람이 살아있으면 계속 버튼을 눌러야 하고, 버튼을 안 누르면 뭔가 작동하는 장치입니다. 여기서는 "크론잡이 살아있으면 핑을 보내고, 핑이 없으면 장애로 판단"하는 구조입니다.
기능이 단순하기 때문입니다.
핑 수신 → DB 업데이트 → 타임아웃 감지 → 알림 발송. 이 네 단계가 전부입니다. 기능을 늘릴 이유가 없고, 그래서 혼자 유지보수할 수 있습니다.
기술 스택도 그렇습니다. Django + PostgreSQL + Hetzner. 화려하지 않지만 9년 동안 돌아가고 있습니다. 창업자는 자동 페일오버도 없다고 했습니다. 장애가 나면 수동으로 대응한다고 합니다. 그게 지금까지 통한 것 같습니다.
국내 시장을 타깃으로 한다면 차별화 포인트가 명확합니다.
카카오톡 알림톡 기본 탑재, 네이버 클라우드 연동 템플릿, 세금계산서 자동 발행과 원화 결제입니다. Healthchecks.io에서 이것들을 쓰려면 커스텀 웹훅을 직접 짜야 합니다. 국내 기업 입장에서는 번거롭습니다.
기술 스택은 NestJS + Next.js + BullMQ + Redis + PostgreSQL 조합이 맞을 것 같습니다.
데드맨 스위치 모니터링에서 핵심 문제는 타임아웃 감지입니다.
"12시간마다 돌아야 하는 크론잡이 신호를 안 보냈다"를 어떻게 감지하느냐입니다.
단순하게 생각하면 1분마다 전체 DB를 스캔해서 last_pinged_at이 오래된 것들을 찾으면 됩니다. 고객 수가 적을 때는 됩니다. 수만 개의 크론잡이 등록되면 마비됩니다.
BullMQ로 해결합니다. 마지막 핑이 들어온 시점에 "지금으로부터 N시간 후에 이 작업을 실행해"라는 Delayed Job을 예약합니다. N시간 후에 새 핑이 왔으면 기존 예약을 취소하고 다시 예약합니다. 핑이 안 오면 Delayed Job이 실행되어 알림을 쏩니다.
DB 풀스캔 없이 정확한 타임아웃 감지가 됩니다.
AWS SQS를 검토했는데 안 됩니다. SQS는 메시지 지연이 최대 15분입니다. 12시간짜리 타이머를 SQS 단독으로 구현할 수 없습니다. Step Functions나 DynamoDB TTL을 엮어야 하는데 복잡해집니다.
BullMQ는 밀리초 단위부터 며칠 뒤까지 지연 예약이 자유롭습니다. 이 서비스에 딱 맞습니다.
한 가지 주의사항이 있습니다. BullMQ는 처리 완료된 작업 기록을 Redis에 계속 쌓습니다. 방치하면 메모리가 꽉 찹니다. 작업을 추가할 때 removeOnComplete: true 옵션을 반드시 줘야 합니다.
Redis와 BullMQ 자체는 오픈소스라 무료입니다. 서버 비용만 납니다.
초기 MVP는 VPS 한 대에 NestJS와 Redis를 같이 띄우면 됩니다. Vultr나 DigitalOcean 기준 월 7,000원~14,000원짜리 서버면 수천 개의 핑을 처리하기에 충분합니다.
Healthchecks.io가 Hetzner 9대를 쓰는 건 652명의 유료 고객을 9년 동안 운영한 결과입니다. 처음부터 그렇게 시작하지 않았습니다.
Healthchecks.io 요금제는 공개되어 있습니다. 무료 플랜은 모니터링 20개까지, 유료는 $20/월(100개), $80/월(무제한) 정도입니다.
MRR $14,043 ÷ 652명 = 평균 약 $21.5/월. 대부분이 $20짜리 기본 유료 플랜을 쓰고 있다는 뜻입니다. 소수의 대형 고객이 MRR을 끌어올리는 구조가 아니라, 중소규모 고객이 고르게 분포한 구조입니다.
국내 가격은 다르게 잡아야 합니다. $20는 한화로 약 28,000원인데, B2B 기준으로는 낮지 않습니다. 월 1만 원짜리 입문 플랜부터 시작해 알림 채널 수나 모니터링 개수로 상위 플랜을 구분하는 방식이 국내 SMB 시장에 맞을 것 같습니다.
이 서비스에서 알림이 한 번이라도 잘못 가면 끝입니다.
정상인데 장애라고 알림을 보내거나, 장애인데 알림을 안 보내거나. 둘 다 고객이 즉시 이탈하는 시나리오입니다. 그래서 기능보다 신뢰성이 먼저입니다.
반대로 이게 기존 서비스를 보호하는 요인이기도 합니다. 한 번 신뢰가 쌓인 서비스는 쉽게 안 바꿉니다. 크론잡 모니터링은 인프라에 박혀있는 설정이라 교체 비용이 작지 않습니다.
신규 진입자 입장에서는 초기에 소수의 고객에게 집중해서 신뢰를 쌓는 게 유일한 방법입니다. 무료 플랜을 넉넉히 주면서 실제로 알림이 정확하게 간다는 걸 체감시키는 수밖에 없습니다.
Healthchecks.io 외에도 유사한 서비스가 있습니다. Cronitor, Dead Man's Snitch, Better Uptime 등이 글로벌에서 같은 포지션을 노리고 있습니다.
공통점은 전부 해외 서비스라는 것입니다. 국내 전용 서비스는 사실상 없습니다. AWS CloudWatch나 Datadog 같은 대형 모니터링 플랫폼도 크론잡 데드맨 스위치를 전문적으로 다루지는 않습니다.
다만 대기업 클라우드 서비스는 잠재적 위협입니다. AWS EventBridge나 Azure Monitor가 비슷한 기능을 무료에 가깝게 번들로 제공하면 이 시장 자체가 흔들릴 수 있습니다. Healthchecks.io가 9년을 버틴 건 이 위협이 아직 본격화되지 않았기 때문이기도 합니다.