AI가 Critical로 고른 알림만 받기: Vercel 호출 지연·webhook 범위·비용 확인

새벽에 오류 알림이 발생했는데 당직자의 호출 시스템에는 아무것도 도착하지 않는다면, 탐지가 실패한 것일까? Vercel의 Critical Only를 켠 목적지에서는 그렇지 않을 수 있다. 탐지된 알림을 Agent가 조사하고 Critical로 분류해야 그 목적지로 전달되기 때문이다. 따라서 이 기능을 평가할 질문은 “알림을 얼마나 줄여 주나”보다 “어떤 알림이 어떤 판단을 거쳐 언제 전달되나”에 가깝다.

Vercel은 2026년 10월 26일 발표에서 Agent가 호출 전에 로그와 지표를 조사할 수 있다고 설명했다. 이 글은 10월 27일 선정 과정에서 보존한 공식 발표와 설정·가격 문서를 기준으로, 호출 지연과 endpoint 범위, 비용을 나눠 읽는다. 당직 목적지 하나에 적용할지 결정할 때 바로 쓸 수 있는 비교표가 핵심이다. 제품 사용 후기나 독립 성능 검증은 아니다.

1. 탐지와 호출 사이에 판단 단계가 생긴다

custom monitor는 하나의 지표 또는 두 지표의 비율을 평가한다. 예를 들어 전체 요청 대비 오류 요청의 비율에 고정 임계값이나 통계적 이상 탐지를 적용하고, 탐지 구간·필터·그룹을 설정할 수 있다. 여기서 두 지표는 분자와 분모이지, 장애를 두 번 독립 확인한다는 뜻이 아니다. 이 탐지 조건과 Critical Only라는 전달 조건은 별개다.

알림이 생성되면 Agent는 로그와 지표를 살펴 영향을 판단한다. 공식 발표에는 고객에게 영향을 주지 않는 health-check 오류와 결제 요청에 지속적으로 영향을 주는 5xx 오류가 예시로 나온다. 이는 제품이 설명하는 구분의 예이지, 이 글에서 같은 상황을 재현해 정확도를 측정했다는 뜻은 아니다. 각 monitor에 조사 맥락을 추가할 수도 있다.

탐지와 목적지 전달은 별개다. Critical은 Agent의 판단이며, 실제 장애 전체의 전달 보장이나 측정된 정확도를 뜻하지 않는다. 출처: vercel.com/changelog/vercel-agent-can-now-validate-alerts-before-paging-you.

Critical Only는 연결한 webhook 목적지 옆에서 선택하는 옵션이다. 선택한 목적지에는 Agent가 Critical로 분류한 알림만 전달된다. “실제로 중요한 장애는 모두 도착한다”는 보장과는 다르다. CLI에서는 vercel monitors notifications의 목적지 연결·업데이트에 --critical-only를 붙일 수 있다고 발표했다. 여기서는 실행하지 않았으며, 운영 endpoint를 바꾸는 명령 예제를 실행 결과처럼 제시하지 않는다.

2. 조사 지연을 탐지 구간과 섞지 않기

공식 설정 문서는 Agent의 Critical 평가가 전달 전에 이루어지므로 monitor의 전체 심각도 임계값 기준에 비해 알림이 늦어질 수 있다고 명시한다. 반면 이 자료에는 Critical Only 조사 지연의 평균이나 최대 시간이 없다. “즉시 호출”이나 “몇 분 안에 반드시 전달”이라고 해석할 근거가 없다.

지연을 확인하려면 탐지 시각, Agent 판단이 확인된 시각, 목적지 수신 시각을 따로 기록하는 편이 낫다. 이 구분은 이 글의 운영 제안이다. 공식 문서의 다른 부분에 나오는 below/anomalously-low 조건의 10분 수집 대기는 별도의 custom monitor 조건이며, 이를 Agent의 조사 지연으로 대입해서는 안 된다. 또한 원래 알림 기록 없이 최종 호출만 보면, 조용해진 이유가 정상 상태인지 분류 결과인지 전달 경로 누락인지 구별하기 어렵다.

3. 기존 webhook을 연결하면 수신 범위가 줄 수 있다

더 조심할 부분은 endpoint 재사용이다. 기존 account-wide alert webhook은 모든 alert 이벤트를 계속 받지만, 이를 monitor에 연결하면 이후 전달 범위가 그 endpoint에 연결된 monitor들로 제한된다. 한 endpoint를 여러 monitor에 연결할 수 있다는 것과 account-wide 수신이 그대로 유지된다는 것은 같은 말이 아니다.

기존 전체 수신 endpoint 재사용은 단순한 구독 추가가 아니다. monitor 연결이 이후 전달 범위를 제한한다는 공식 경고를 비교했다. 출처: vercel.com/docs/alerts/configure-alerts.

따라서 전체 알림용 endpoint에 monitor 하나를 연결하는 변경은, 그 monitor만 추가로 구독하는 안전한 덧셈으로 볼 수 없다. 기존 수신 범위와 연결 목록을 먼저 남겨야 한다. 연결 대상이 없는 monitor-scoped webhook은 alert 이벤트를 받지 않는다는 점도 구분해야 한다. 이 설명을 “기존 account-wide webhook도 연결하지 않으면 전부 중단된다”로 일반화하면 틀린다.

incident.io 목적지는 Critical Only가 미리 선택된다고 문서에 나온다. 낮은 심각도도 받고 싶다면 해당 옵션을 해제할 수 있다. 설정 문서는 Test Notification이 incident.io에 나타나는지 확인하고, 이후 조건에 맞는 실제 알림이 발생했을 때도 나타나는지 확인하라고 나눠 설명한다. 테스트 이벤트 성공은 실제 탐지부터 당직 호출까지의 전체 경로가 검증됐다는 뜻이 아니다.

4. 포함 조사량·스캔·추론을 서로 다른 장부로 보기

알림 검증의 이용 조건은 Observability Plus가 있는 Pro 또는 Enterprise다. 설정 문서에서 custom monitor는 Beta이며 팀당 최대 5개로 설명된다. 무제한 정식 기능이나 무료 기본 알림의 보편적 대체물로 소개하면 조건이 빠진다.

조사 횟수·스캔 GB·토큰은 같은 과금 단위가 아니다. 스캔 단가는 공식 알림 발표, 추가 조사 단가는 Agent 가격 문서에 근거하며 기본 구독료를 포함한 전체 청구 예측은 아니다. 출처: vercel.com/docs/agent/pricing.

비용은 세 항목을 분리해서 읽어야 한다. 첫째, Observability Plus에는 청구 주기당 Agent 조사 10회가 포함된다. 하루 10회나 사용자당 10회가 아니다. 둘째, custom monitor는 스캔한 데이터 GB당 미화 $0.0035이며, 이벤트 한 건이나 조사 한 번의 고정 요금이 아니다. built-in alert가 Observability Plus에 포함된다는 설명도 모든 Agent 조사가 무제한 무료라는 뜻은 아니다.

셋째, 추가 조사는 기반 제공자의 추론 비용에 Vercel Token Rate가 더해진다. 문서상의 추가 단가는 백만 토큰당 미화 $0.25이고 입력·출력·캐시 토큰에 적용된다. $0.25를 조사 1회 요금이나 전체 추론 요금으로 쓰면 틀린다. 실제 조사량과 분석한 로그·지표에 따라 달라지며, 이 글은 기본 Observability Plus 구독료를 확인한 전체 월 청구서 추정이 아니다. 절감액이나 고객 청구 내역도 측정하지 않았다.

5. 호출 목적지에 적용할지 결정하는 비교표

아래 비교표는 공식 동작을 바탕으로 작성한 운영 제안이며, 실제 장애 주입·webhook 변경·유료 조사나 전달 지연 측정을 수행한 결과가 아니다.

현재 운영 조건	먼저 할 선택	적용을 미룰 이유 또는 확인할 점
탐지 직후 호출이 가장 중요하다	기존 전달 경로를 유지하고 조사 후 호출과 분리해 비교한다	Critical Only의 조사 지연 상한이 이 자료에 없다
당직 소음을 줄이되 원래 알림도 비교할 수 있다	원래 알림의 관측 경로를 보존한 상태에서 특정 목적지 적용을 검토한다	탐지·판단·수신 기록을 대조하기 전에는 조용함을 정확도 향상으로 부르지 않는다
기존 전체 알림 endpoint를 재사용해야 한다	연결 전 해당 endpoint의 수신 범위를 먼저 기록한다	monitor 연결 뒤 다른 알림이 빠질 수 있으므로 단순한 필터 추가로 취급하지 않는다
조사·스캔 예산을 별도로 관리하지 않는다	포함 조사량과 스캔량, 추가 추론 사용량을 각각 확인한다	청구 주기당 10회를 넘는 조사와 GB 기준 스캔 비용을 섞으면 원인을 놓친다

미전달과 지연을 구분하려는 이 글의 운영 제안이다. 이 도식은 실제 이벤트 기록이나 공급자의 정확도 보장이 아니며, 판단 시각이 보이지 않으면 추정하지 않는다. 출처: vercel.com/docs/alerts/configure-alerts.

적용을 검토한다면 비교 기록에는 monitor 식별자, 원래 탐지 시각, Agent 분류, 목적지와 연결 범위, 최종 수신 여부를 남기는 것이 유용하다. 값이 보이지 않으면 추정해서 채우지 말고 미확인으로 기록한다. 탐지는 있었으나 호출이 없었던 경우에는 Critical로 분류되지 않은 것인지, 연결 범위가 달라진 것인지부터 나눠 본다. 이 절차는 제안하는 진단 방식이지 공급자가 보장하는 누락 탐지법이나 이 글에서 완료한 테스트가 아니다.

도입 판단의 핵심은 AI가 호출을 줄인다는 문구가 아니라, 분류 이전의 신호를 계속 관측할 수 있는지다. Critical Only는 목적지로 가는 알림을 Agent의 판단으로 거르는 기능이다. 기존 전체 수신 범위, 조사로 생기는 미정량 지연, 서로 다른 과금 단위를 함께 관리할 수 있을 때 운영상 선택지를 평가할 수 있다.

6. 출처와 확인 범위

• Vercel 발표: 호출 전 Agent 알림 검증 — 2026년 10월 26일 발표의 destination별 동작, CLI 옵션과 이용 조건.
• custom monitor 발표 — 지표·비율·탐지 조건과 전달 채널의 구분.
• 알림 설정 공식 문서 — custom monitor Beta·팀당 한도, Critical Only의 지연 경고, account-wide endpoint 연결 범위, incident.io 테스트 절차.
• Agent 가격 공식 문서 — 포함 조사와 추가 추론 과금, 토큰 단가의 적용 대상.

이 글은 AI를 활용해 공식 공개 자료를 정리하고, 별도의 비교표와 진단 관점을 작성한 해설이다. 오탐·누락률, 전달 시간, 비용 절감을 실측하지 않았다. 본문 그림은 문서의 관계를 다시 그린 자체 도식이며 실제 대시보드 화면이나 실험 데이터가 아니다.