목차
API가 새벽 3시에 다운되는 것 자체는 문제가 아닙니다. 진짜 문제는 사용자들이 이미 지원 메일함을 가득 채운 뒤인 오전 9시에야 그 사실을 알게 된다는 점입니다.
대부분의 모니터링 도구는 장애를 감지하는 데는 뛰어납니다. 하지만 누군가 적절한 시점에 그 알림을 실제로 확인하도록 만드는 데는 형편없습니다. 일반 푸시 알림은 누군가 우연히 휴대폰을 집어 들 때까지 잠금 화면에 그대로 남아 있습니다. Slack 메시지는 밤중에 아무도 보지 않는 채널 속에 묻힙니다. 이메일은 월요일 아침이 될 때까지 읽히지 않은 채로 남습니다.
전화 알림은 이 공식을 바꿔 놓습니다. API 헬스 체크가 실패하면 휴대폰이 실제로 울립니다. 다른 긴급한 용건으로 걸려 오는 전화와 똑같은 방식입니다. 전화를 받아 무엇이 잘못되었는지 듣고, 몇 시간 뒤가 아니라 즉시 문제 해결에 착수할 수 있습니다.
중요한 서비스에 푸시 알림이 통하지 않는 이유
일반적인 스마트폰은 하루에 50~100개의 푸시 알림을 받습니다. API 장애 알림은 앱 업데이트, 소셜 미디어 알림, 뉴스 알림을 비롯해 기기에 설치된 다른 모든 앱과 경쟁해야 합니다. 모든 것이 긴급하면 어떤 것도 긴급하게 느껴지지 않습니다.
이는 위험한 패턴을 만듭니다:
- 모니터링 도구가 API에서 500 오류가 반환되는 것을 감지합니다
- 도구가 휴대폰으로 푸시 알림을 보냅니다
- 휴대폰은 화면이 아래를 향한 채 책상 위에 놓여 있고, 집중 모드가 켜져 있습니다
- 알림은 누군가 알아차릴 때까지 조용히 그 자리에 남아 있습니다. 몇 시간이 지난 뒤에 말입니다
중요하지 않은 마이크로서비스라면 이 지연은 성가신 정도에 그칩니다. 하지만 결제 API, 인증 서비스, 또는 주력 제품의 백엔드라면 이 지연은 실제 매출과 신뢰를 잃게 만듭니다.
Echobell에서 전화 알림이 작동하는 방식
Echobell은 세 가지 긴급도 수준으로 알림을 전달합니다:
- 일반(Active): 표준 푸시 알림
- 긴급(Time-sensitive): iOS 집중 모드를 뚫고 전달되지만 벨은 울리지 않습니다
- 전화(Calling): 일반 전화처럼 휴대폰 벨을 울립니다
사용자에게 영향을 주는 API 장애에는 전화 수준이 적합합니다. 다른 긴급한 전화를 대하는 방식과 똑같습니다. 벨이 울리기 때문에 전화를 받게 되는 것입니다.
설정은 간단합니다:
- Echobell에서 채널을 만듭니다
- 알림 유형을 전화(Calling)로 설정합니다
- Webhook으로 모니터링 도구를 연결합니다
- 헬스 체크가 실패하면 Echobell이 휴대폰으로 전화를 겁니다
모니터링 도구에서 전화 알림 설정하기
대부분의 모니터링 플랫폼은 확인이 실패했을 때 Webhook을 보낼 수 있습니다. 연결하는 방법은 다음과 같습니다.
기존 헬스 체크 활용하기
/health나 /status 같은 상태 확인 엔드포인트가 이미 있다면, 모니터가 일정한 간격으로 해당 엔드포인트를 확인하도록 설정하세요. 응답이 200이 아니면 Webhook을 실행합니다.
Echobell은 title과 body를 담은 Webhook 페이로드를 받습니다:
curl -X POST https://hook.echobell.one/t/<channel-token> \
-H "Content-Type: application/json" \
-d '{
"title": "API DOWN: payment-service",
"body": "Health check failed - 500 error at 03:42 UTC",
"notificationType": "calling",
"externalLink": "https://your-dashboard.example.com/incidents/123"
}'휴대폰 벨을 울리게 하는 것은 바로 notificationType: calling 필드입니다.
알림에 담아야 할 내용
알림 내용은 한눈에 파악할 수 있게 유지하세요. 새벽 3시에 전화를 받았을 때 문제를 즉시 이해할 수 있어야 합니다:
- 서비스 이름 — 어떤 API 또는 마이크로서비스에 장애가 발생했는지
- 오류 유형 — 타임아웃, 5xx, 연결 거부
- 타임스탬프 — 장애가 시작된 시각
- 링크 — 즉시 확인에 착수할 위치
여기는 장황한 메시지를 담을 자리가 아닙니다. 목표는 즉각적인 맥락을 전달해서 완전히 잠에서 깨어야 할지, 아니면 확인만 하고 다시 잠들어도 될지 판단할 수 있게 하는 것입니다.
적절한 긴급도 수준 선택하기
모든 API 장애에 전화가 필요한 것은 아닙니다. 다음과 같은 경우에 전화 알림을 사용하세요:
- 결제 및 청구 서비스
- 인증 및 로그인 엔드포인트
- 사용자가 직접 사용하는 주력 제품 API
- 다른 중요한 시스템이 의존하는 서비스
다음과 같은 경우에는 긴급 알림을 사용하세요:
- 중요하지만 매출에 직결되지는 않는 보조 서비스
- 개발 또는 스테이징 환경
- 경고 신호(아직 완전한 장애는 아닌 높은 오류율)
다음과 같은 경우에는 일반 알림을 사용하세요:
- 중요하지 않은 백그라운드 작업
- 조치가 필요하지 않은 참고용 지표
이렇게 단계를 나누면 알림 피로를 만들지 않으면서도 필요한 상황을 놓치지 않을 수 있습니다.
여러 서비스로 확장하기
API를 두 개 이상 운영한다면 서비스 또는 서비스 그룹마다 별도의 채널을 만드세요:
production-payment-api— 전화 수준production-user-api— 전화 수준production-analytics-api— 긴급staging-all— 긴급
이렇게 하면 서비스별로 긴급도를 조정할 수 있습니다. 결제 API는 전화를 받을 만하지만, 분석 파이프라인은 아마 그렇지 않을 것입니다.
진짜 이점
전화 알림의 가치는 벨이 울린다는 사실 자체에 있지 않습니다. 그로 인해 생기는 행동의 변화에 있습니다:
- 문제를 즉시 알게 되므로 더 빨리 해결합니다
- 무언가 잘못되면 확실히 깨어날 수 있다는 것을 알기에 더 편히 잠듭니다
- 몇 시간이 아니라 몇 분 안에 대응하므로 사용자가 겪는 다운타임이 짧아집니다
중요한 서비스에서는 바로 그 차이가 핵심입니다.