---
title: "API가 다운되었을 때 전화 알림 받기"
description: "API 장애를 알리는 일반 푸시 알림은 수많은 알림 속에 묻혀 버립니다. 중요한 서비스에 장애가 발생했을 때 실제로 잠을 깨워 주는 전화 알림을 설정하는 방법을 알아보세요."
date: 2026-03-13
author: Nooc
authorAvatarLink: /images/avatars/nooc.webp
authorLink: https://nooc.me
tags:
  - API 모니터링
  - 전화 알림
  - 서버 다운타임
  - 중요 알림
  - Webhook
---

# API가 다운되었을 때 전화 알림 받기

API가 새벽 3시에 다운되는 것 자체는 문제가 아닙니다. 진짜 문제는 사용자들이 이미 지원 메일함을 가득 채운 뒤인 오전 9시에야 그 사실을 알게 된다는 점입니다.

대부분의 모니터링 도구는 장애를 감지하는 데는 뛰어납니다. 하지만 누군가 적절한 시점에 그 알림을 실제로 확인하도록 만드는 데는 형편없습니다. 일반 푸시 알림은 누군가 우연히 휴대폰을 집어 들 때까지 잠금 화면에 그대로 남아 있습니다. Slack 메시지는 밤중에 아무도 보지 않는 채널 속에 묻힙니다. 이메일은 월요일 아침이 될 때까지 읽히지 않은 채로 남습니다.

전화 알림은 이 공식을 바꿔 놓습니다. API 헬스 체크가 실패하면 휴대폰이 실제로 울립니다. 다른 긴급한 용건으로 걸려 오는 전화와 똑같은 방식입니다. 전화를 받아 무엇이 잘못되었는지 듣고, 몇 시간 뒤가 아니라 즉시 문제 해결에 착수할 수 있습니다.

## 중요한 서비스에 푸시 알림이 통하지 않는 이유

일반적인 스마트폰은 하루에 50~100개의 푸시 알림을 받습니다. API 장애 알림은 앱 업데이트, 소셜 미디어 알림, 뉴스 알림을 비롯해 기기에 설치된 다른 모든 앱과 경쟁해야 합니다. 모든 것이 긴급하면 어떤 것도 긴급하게 느껴지지 않습니다.

이는 위험한 패턴을 만듭니다:

1. 모니터링 도구가 API에서 500 오류가 반환되는 것을 감지합니다
2. 도구가 휴대폰으로 푸시 알림을 보냅니다
3. 휴대폰은 화면이 아래를 향한 채 책상 위에 놓여 있고, 집중 모드가 켜져 있습니다
4. 알림은 누군가 알아차릴 때까지 조용히 그 자리에 남아 있습니다. 몇 시간이 지난 뒤에 말입니다

중요하지 않은 마이크로서비스라면 이 지연은 성가신 정도에 그칩니다. 하지만 결제 API, 인증 서비스, 또는 주력 제품의 백엔드라면 이 지연은 실제 매출과 신뢰를 잃게 만듭니다.

## Echobell에서 전화 알림이 작동하는 방식

Echobell은 세 가지 긴급도 수준으로 알림을 전달합니다:

- **일반(Active):** 표준 푸시 알림
- **긴급(Time-sensitive):** iOS 집중 모드를 뚫고 전달되지만 벨은 울리지 않습니다
- **전화(Calling):** 일반 전화처럼 휴대폰 벨을 울립니다

사용자에게 영향을 주는 API 장애에는 전화 수준이 적합합니다. 다른 긴급한 전화를 대하는 방식과 똑같습니다. 벨이 울리기 때문에 전화를 받게 되는 것입니다.

설정은 간단합니다:

1. Echobell에서 채널을 만듭니다
2. 알림 유형을 **전화**(Calling)로 설정합니다
3. Webhook으로 모니터링 도구를 연결합니다
4. 헬스 체크가 실패하면 Echobell이 휴대폰으로 전화를 겁니다

## 모니터링 도구에서 전화 알림 설정하기

대부분의 모니터링 플랫폼은 확인이 실패했을 때 Webhook을 보낼 수 있습니다. 연결하는 방법은 다음과 같습니다.

### 기존 헬스 체크 활용하기

`/health`나 `/status` 같은 상태 확인 엔드포인트가 이미 있다면, 모니터가 일정한 간격으로 해당 엔드포인트를 확인하도록 설정하세요. 응답이 200이 아니면 Webhook을 실행합니다.

Echobell은 title과 body를 담은 Webhook 페이로드를 받습니다:

```bash
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는 전화를 받을 만하지만, 분석 파이프라인은 아마 그렇지 않을 것입니다.

## 진짜 이점

전화 알림의 가치는 벨이 울린다는 사실 자체에 있지 않습니다. 그로 인해 생기는 행동의 변화에 있습니다:

- 문제를 즉시 알게 되므로 더 빨리 해결합니다
- 무언가 잘못되면 확실히 깨어날 수 있다는 것을 알기에 더 편히 잠듭니다
- 몇 시간이 아니라 몇 분 안에 대응하므로 사용자가 겪는 다운타임이 짧아집니다

중요한 서비스에서는 바로 그 차이가 핵심입니다.

---

## 관련 글

- [중요한 장애를 위한 전화 알림](/ko/features/call-notifications)
- [iPhone용 Webhook 알림](/ko/features/webhooks)
- [집중 모드 알림](/ko/focus-mode-alerts)
- [서버 다운 전화 알림](/ko/server-down-phone-call-alerts)
- [Grafana 전화 알림](/ko/blog/grafana-call-notification)
- [Echobell로 가동 시간 모니터링하기](/ko/blog/upptime-alerts-with-echobell)
- [중요 알림을 위해 iOS 집중 모드 우회하기](/ko/blog/how-to-bypass-ios-focus-mode-for-critical-alerts)