OpenStatus

OpenStatus란

장애 커뮤니케이션은 보통 서로 다른 제품에 나뉘어 있는 두 부분으로 이루어집니다. 하나는 서버와 사이트, API를 지켜보다가 멈추거나 느려지면 알려 주는 쪽입니다. 다른 하나는 문제가 자기 쪽인지 상대 쪽인지 확인하려고 고객이 여는 공개 페이지입니다. 작은 팀은 대개 모니터링 서비스와 상태 페이지 호스팅에 따로 돈을 내고, 그다음 둘을 손으로 맞춰 갑니다. OpenStatus는 둘 다 AGPL-3.0으로 내놓고, 원한다면 전부 직접 돌릴 수 있게 해 둡니다. 한 업체가 멀쩡하다는 사실을 알리기 위해 다른 업체에 의존하고 싶지 않다면 의미 있는 선택지입니다.

프로젝트는 2023년 6월에 시작했고 실제로 활발합니다. 수집 시점 기준 최신 커밋은 하루 전 것이었고, 모니터 URL 검증에서 사설 주소 대역을 막는 보안 강화도 포함돼 있었습니다. 구조는 TypeScript 모노레포로, 대시보드는 Next.js, API 서버는 Hono, 체커는 Go로 작성돼 있고 그 아래에 Turso와 Drizzle, Tinybird가 있습니다. 업그레이드 계획을 세우기 전에 알아 둘 점이 하나 있습니다. GitHub에 태그된 릴리스가 없습니다. 프로젝트는 메인 브랜치에서 배포하고 미리 빌드된 컨테이너 이미지를 게시하므로, 고정하는 것은 버전 번호가 아니라 이미지 다이제스트입니다.

기본으로 제공되는 것

README가 기능 범위를 구체적으로 적어 두어서, 실제로 필요한 것과 맞춰 보기 쉽습니다.

• 상태 페이지 자체 도메인, 비밀번호 보호, 점검 시간대 안내, 이메일과 RSS를 통한 구독자 알림을 제공합니다. 호스팅 요금제는 좌석당이나 구독자당이 아니라 정액이고 멤버 수에 제한이 없습니다. 이 분야가 전통적으로 '장애를 알고 싶어 하는 사람 수'로 청구해 왔기 때문에 짚어 둘 만합니다.
• 28개 리전 점검 모니터가 3개 클라우드에 걸친 28개 리전에서 병렬로 돕니다. 단일 리전 체커는 언젠가 한 리전만 상태가 나쁠 뿐인 상황을 두고 사이트가 죽었다고 알려 오며, 그 사실을 알게 되는 시각은 대개 새벽 3시입니다.
• 코드로서의 모니터링 모니터와 알림, 상태 페이지를 YAML로 선언하고 CLI로 다루며 GitHub Actions 안에서 실행하거나 Terraform으로 관리할 수 있습니다. 인프라가 이미 버전 관리 아래 있다면 점검도 그 옆에 두고 같은 방식으로 리뷰할 수 있습니다.
• 알림, API, 그리고 MCP 서버 알림은 Slack, Discord, PagerDuty, 이메일로 갑니다. 여기에 더해 Node SDK가 붙은 타입 지정 JSON over HTTP API, 에이전트를 겨냥한 `--json` 모드를 갖춘 CLI, 그리고 MCP 서버가 있어 어시스턴트가 대시보드를 긁는 대신 워크스페이스에 바로 질의할 수 있습니다.
• 셀프호스팅 Docker Compose 파일 하나로 로컬에 스택이 올라오고, 게시된 이미지와 Coolify 배포 가이드도 있습니다. 공개 인터넷이 닿지 않는 대상을 사내 네트워크 안에서 점검하는 프라이빗 로케이션은 8.5MB짜리 이미지 하나로 배포됩니다.

아닌 것도 분명합니다. OpenStatus는 엔드포인트를 보지, 애플리케이션 내부를 보지 않습니다. 고객이 만지는 것이 응답하는지, 얼마나 빠른지에는 답하지만 왜 멈췄는지에는 답하지 않습니다. 트레이싱과 로그 집계는 다른 범주의 도구이고, 프로젝트도 그런 척하지 않습니다.

창업자의 성장 스택에서 놓이는 자리

상태 페이지는 획득 채널이 아니고, 이 점은 분명히 말해 둘 가치가 있습니다. 트래픽을 데려오지 않습니다. 대신 두 순간의 마찰을 없앱니다. 잠재 고객이 '여기가 진짜 회사인가'를 판단하는 순간과, 기존 고객이 '메일을 쓸까 5분 기다릴까'를 정하는 순간입니다. 둘 다 마케팅보다는 신뢰의 일이고 사회적 증거에 가깝습니다. Documenso를 직접 돌릴 만하다고 느끼게 하는 감각이 여기에도 그대로 적용됩니다. 작은 회사를 책임감 있어 보이게 하는 산출물은 운영 비용이 싸고, 정작 필요한 날에 없으면 비쌉니다.

만들 시점은 첫 장애가 아니라 첫 유료 고객입니다. 장애 도중에 만든 상태 페이지는 구독자가 없고, 아무도 모르는 도메인 위에 있으며, 지금 대단히 바쁜 사람이 쓴 페이지입니다. 준비 자체는 한 시간이지만 그 가치는 전부 '대상이 되는 사건보다 먼저 존재했는가'에 달려 있습니다. 개발자에게 판다면 이유가 하나 더 있습니다. 상태 페이지와 변경 기록은 기술적인 구매자가 시키지 않아도 직접 찾아보는 몇 안 되는 페이지이고, 문서와 나란히 놓입니다. 그 독자층에 관해서는 개발자 도구는 어떻게 마케팅하나도 함께 보세요.

우리 서비스 군집에 체커를 겨눠 보고 배운 것

이 부분은 읽어서가 아니라 운영해서 얻은 이야기입니다. AgentCeres — agentceres.com의 AI Growth Officer — 는 고객 워크스페이스마다 별도 컨테이너를 돌리고, 유휴 상태인 것은 비용을 줄이려고 0까지 축소합니다. 그래서 '응답하지 않음'과 '잠들어 있음'이 서로 다른 상태가 되고, 그 탓에 모니터링 감각이 두 번 깨졌습니다. 첫째, 프로브는 공짜가 아닙니다. 0까지 축소되는 서비스에 대한 점검은 매번 그 서비스를 깨우므로, 모니터가 콜드 스타트 비용을 대신 치르고 애초에 지키라고 붙여 둔 절감분을 조용히 지워 버립니다. 거의 항상 깨어 있던 워크스페이스 하나를 추적해 보니, 로그인한 채 잊힌 브라우저 탭이 몇 분마다 백그라운드 엔드포인트를 두드리고 있었습니다. 나머지 군집은 한 자릿수에 머물러 있었는데도요. 둘째, 우리 헬스 체크는 아무것도 프로브하지 않은 채 '잠들어 있음'이라고 보고하는 법을 배워야 했습니다. 자기 아키텍처에서 '살아 있음'이 무엇인지 정하고 나서야 뜻이 통하는 문장입니다.