[인턴] Sentry를 이용한 에러 Alert 핸들링

March 13, 2026

Sentry 에러 우선순위 정비 및 Alert Rule 개선 가이드

1. 문서 목적

이 문서는 백엔드 서비스에서 수집되는 Sentry 에러를 단순 발생량 기준이 아니라 실제 운영 영향도 기준으로 분류하고,
향후 Slack 알람 정책 및 Nest.js 기반의 Sentry 에러 태깅 구현까지 일관되게 이어가기 위한 기준 문서이다.

현재 Sentry에는 다양한 유형의 에러가 함께 쌓이고 있으며, 최근 30일 기준으로 발생량이 높은 에러들 중에는 실제로 즉시 대응이 필요한 에러와,
봇/스캐너/잘못된 요청처럼 실시간 알람 대상에서 제외해도 되는 에러가 혼재되어 있다.

따라서 본 문서는 아래 목표를 가진다.

최근 자주 발생하는 에러를 운영 우선순위 기준으로 재분류
Sentry 기본 Priority(High / Medium / Low)와 팀 내부 우선순위(P0 / P1 / P2 / P3)를 구분하여 정의
Slack 알람 노이즈를 줄이고, 실제 중요한 에러만 빠르게 인지할 수 있도록 기준 마련
추후 백엔드 Sentry 설정 수정 및 커스텀 태깅 구현을 위한 기준선 확보

2. 배경

2-1. 현재 Sentry 운영 상의 문제

현재 Sentry에는 다양한 성격의 에러가 함께 기록되고 있다.

예를 들어 최근 30일 동안 많이 발생한 에러에는 다음과 같은 것들이 있었다.

외부 메시징/알림 서비스 연동 에러
비정상 경로 접근으로 인한 NotFoundException
UnauthorizedException: Unauthorized
query failed error
잘못된 사용자 식별자 관련 예외 처리

이 중 일부는 실제 비즈니스 플로우를 막을 수 있는 중요한 에러이지만,
일부는 외부 비정상 접근, 잘못된 사용자 입력, 스캐너/봇 유입, 혹은 예상 가능한 예외 처리 범주에 속할 수 있다.

그런데 현재 알람 기준이 단순 발생 여부에 가까우면,
실제 중요한 이슈가 노이즈 속에 묻힐 가능성이 높아진다.

3. 현재 Alert Rule 상태

현재 적용되어 있는 알람 조건은 다음과 같다.

새로운 이슈가 생성될 때 알람
기존 이슈가 짧은 시간 내에 재발생할 때 알람

이 조건은 사실상 다음 의미를 가진다.

새로운 issue가 생성되면 알람
기존 issue라도 짧은 시간 내에 재발생하면 알람

즉, 현재 구조는 우선순위 기반 알람 구조라기보다 광범위 수집형 알람 구조에 가깝다.

3-1. 문제점

이 구조의 가장 큰 문제는 아래와 같다.

모든 에러가 비슷한 무게로 Slack에 유입될 수 있음
노이즈성 에러도 실시간 알람 대상이 될 수 있음
중요한 에러와 중요하지 않은 에러가 채널에서 섞여 보임
운영자가 “지금 당장 봐야 하는 이슈”를 빠르게 분리하기 어려움
향후 priority를 조정해도, alert rule이 이를 사용하지 않으면 알람 그룹화 효과가 약함

따라서 현재 상태에서는 Sentry UI 상의 issue 분류와 Slack 알람 정책을 분리해서 보지 말고,
하나의 운영 정책으로 연결해서 설계하는 것이 필요하다.

4. 기본 원칙

에러 우선순위는 에러 메시지 이름만으로 결정하지 않는다.

반드시 아래 요소를 함께 고려해야 한다.

4-1. 비즈니스 영향도

인증, 핵심 트랜잭션, 주요 조회/저장 등 핵심 기능에 직접 영향을 주는가
서비스 핵심 가치, 사용자 주요 행동, 운영 업무에 직접 차질을 주는가

4-2. 영향 대상

일반 사용자
서비스 운영자
내부 관리자
일부 테스트 계정
외부 스캐너/봇

4-3. 영향 범위

affected users 수
event 발생량
특정 애플리케이션 인스턴스에만 발생하는지
여러 애플리케이션 인스턴스에 공통으로 발생하는지

4-4. 지속성

일시적 예외인지
최근 24시간/14일 기준으로 계속 반복되는지
특정 배포 이후 급증했는지

4-5. 우회 가능성

사용자가 재시도/새로고침/다른 경로 사용 등으로 우회 가능한가
운영자가 수동으로 대응할 수 있는가

4-6. 발생 문맥

실제 사용자 요청에서 발생했는가
배치성 작업, 스케줄러, 백그라운드 잡에서 발생했는가
중복 요청, 재시도, 병렬 처리 충돌로 인해 증폭된 에러인가

5. 우선순위 체계 정의

본 문서에서는 팀 내부 정책으로 아래와 같이 우선순위를 정의한다.

P0: 서비스 핵심 장애 / 즉시 대응 필요
P1: 운영 영향 큼 / 우선 대응 필요
P2: 제한적 영향 / 추적 및 개선 필요
P3: 노이즈성 / 후순위 검토

또한 Sentry의 기본 Priority는 아래와 같이 매핑한다.

P0 → High
P1 → High
P2 → Medium
P3 → Low

즉, Sentry의 High / Medium / Low는 표현 수단이고,
실제 운영 정책은 P0 / P1 / P2 / P3로 관리하는 것을 원칙으로 한다.

6. 우선순위 상세 정의

6-1. P0

정의

비즈니스 핵심 기능이 전면적으로 막히거나, 즉각적인 운영 장애를 유발하는 에러

판단 기준

인증, 핵심 트랜잭션, 주요 API가 정상적으로 동작하지 않음
정상 사용자 다수가 즉시 영향받음
우회가 사실상 불가능함
여러 인스턴스에서 동시에 급증함
실제 비즈니스 손실 또는 서비스 중단으로 이어짐

예시

모든 인증 요청이 실패로 처리되는 경우
핵심 DB 장애로 주요 기능이 모두 실패하는 경우
핵심 트랜잭션 API가 전면 장애를 일으키는 경우

Sentry 매핑

Priority: High

Slack 운영

즉시 알람
핵심 운영 채널 전달
담당자 빠른 확인 필요

6-2. P1

정의

서비스 전면 장애는 아니지만, 운영이나 주요 사용자 플로우에 실질적 영향을 주는 에러

판단 기준

운영 업무 또는 주요 API 플로우가 반복적으로 실패
일반 사용자 또는 운영자가 명확한 불편을 겪음
users 수 / events 수가 높음
공통 설정/외부 연동 문제로 여러 인스턴스에서 발생함

예시

외부 서비스 연동 장애로 인증/알림 발송이 차질을 빚는 경우
특정 인증 흐름에서 정상 사용자 다수가 Unauthorized 를 받는 경우
DB query 오류가 핵심 흐름 일부를 지속적으로 실패시키는 경우

Sentry 매핑

Priority: High

Slack 운영

실시간 알람 유지
운영 채널 또는 백엔드 채널 전달

6-3. P2

정의

영향이 제한적이거나 일부 케이스에만 발생하지만, 반복될 경우 개선이 필요한 에러

판단 기준

일부 사용자 / 일부 상황 / 일부 기능에서만 발생
우회가 가능함
즉각적인 장애는 아니지만 운영 품질 저하를 유발함
추적 및 후속 개선이 필요함

예시

일부 만료 토큰 요청으로 인한 Unauthorized
일부 잘못된 사용자 입력으로 발생하는 예외
특정 기능의 부가적 연동 실패
사용자 재시도 또는 다른 경로 사용으로 우회 가능한 오류
스케줄러/배치 잡에서 반복되지만 핵심 기능은 직접 막지 않는 오류
중복 요청 또는 병렬 처리 충돌로 인해 예외가 다량 누적되었으나 최종 상태는 정상 반영된 경우

Sentry 매핑

Priority: Medium

Slack 운영

일반 에러 채널 또는 리뷰 채널 전달
즉시 대응보다 추적/개선 중심

6-4. P3

정의

실제 서비스 영향이 낮고, 실시간 알람 대상으로 보기 어려운 노이즈성 에러

판단 기준

봇/스캐너/잘못된 경로 접근
의도된 validation/guard 예외
비정상 요청이나 무의미한 외부 접근
운영상 긴급한 대응이 불필요함

예시

비정상 경로 접근으로 인한 NotFoundException
스캐너나 봇이 임의 URL을 탐색한 흔적
처리된 잘못된 입력값 예외
실제 정상 사용자 영향이 거의 없는 Unauthorized
관측성/추적 데이터 전송 실패처럼 서비스 핵심 기능과 직접 연결되지 않는 예외

Sentry 매핑

Priority: Low

Slack 운영

실시간 알람 제외 또는 최소화
주기적 리뷰 대상으로 관리

7. 최근 30일 주요 에러 재분류

아래는 최근 30일 주요 에러를 기준으로 한 1차 우선순위 분류안이다.

에러 유형	1차 우선순위	근거
query failed error	P1	DB 계층 장애 가능성, 기능 영향 범위가 넓을 수 있음
외부 메시징/알림 서비스 연동 에러	P1	외부 연동 실패, 인증/알림/업무 플로우에 영향 가능
Unauthorized 에러	P2	기본값은 P2, 단 정상 사용자 대량 영향 시 P1 이상
잘못된 사용자 식별자 예외처리	P2	입력값/도메인 검증 계열 가능성, 영향이 제한적일 수 있음
비정상 경로 접근에 따른 NotFoundException	P3	스캐너/비정상 접근 가능성이 높음

8. 각 주요 에러에 대한 상세 판단

8-1. `query failed error`

기본 분류

이유

DB query 실패는 단순 에러처럼 보여도, 실제로는 서비스 여러 기능에 영향을 줄 수 있다.
특히 DB 계층의 오류는 조회, 저장, 인증, 상태 변경 등 공통 로직과 연결되는 경우가 많다.

상향 조건

아래 조건 중 하나라도 만족하면 P0 검토 대상이다.

핵심 트랜잭션/인증 등 핵심 기능이 직접 실패
여러 인스턴스에서 동시에 발생
users 수가 높음
재시도해도 복구되지 않음
특정 배포 이후 급증

하향 조건

아래 조건이면 P2 로 하향 가능하다.

관리자 전용 기능
부가적인 조회/통계성 쿼리
실제 사용자 영향이 낮음
중복 요청 충돌로 인한 예외 폭증이지만, 최종 데이터는 정상 반영됨
스케줄러/배치 잡 중 일부 작업 실패로만 관측됨

추가 검토 포인트

같은 키 또는 같은 리소스에 대해 병렬 요청이 몰리면,
실제 비즈니스 장애라기보다 중복 처리 충돌, unique constraint 충돌, 재시도 로직에 의한 예외 증폭일 수도 있다.
이 경우 event 수가 많아 보여도 우선순위는 실제 사용자 영향 기준으로 다시 판단해야 한다.

8-2. 외부 메시징/알림 서비스 연동 에러

기본 분류

이유

메시지 발송 서비스는 본인인증, 계정 관련 처리, 알림 발송, 업무 통지 등과 연결될 수 있다.
이 경우 외부 연동 실패가 단순 서드파티 오류가 아니라, 실제 서비스 기능 차질로 이어질 수 있다.

상향 조건

로그인/회원가입 등 핵심 인증 단계에 필수
주요 업무 알림이 필수적
실패 시 우회 수단이 없음

위 경우 P0 ~ P1 로 판단할 수 있다.

하향 조건

단순 보조 알림
재시도 큐나 대체 수단 존재
사용자의 핵심 행동과 직접 연결되지 않음
스케줄러 기반 발송 작업에서 일부 실패했으나 후속 보정 가능

위 경우 P2 로 하향 가능하다.

8-3. `UnauthorizedException: Unauthorized`

기본 분류

이유

Unauthorized는 흔히 발생할 수 있는 인증 실패이다.
예를 들어 만료된 토큰, 잘못된 Authorization 헤더, 비정상 접근 등으로도 쉽게 발생할 수 있다.

그러나 다음과 같은 경우에는 단순 401로 보면 안 된다.

상향 조건

여러 애플리케이션 인스턴스에서 거의 동시에 발생
정상 사용자 요청까지 대량으로 실패
JWT 시크릿/키/인증 설정 문제 가능성 존재
로그인 이후 핵심 기능 호출이 연쇄적으로 막힘

위와 같은 경우 P1 이상으로 판단해야 한다.

하향 조건

만료된 토큰 재사용
비정상 요청
봇/외부 공격 시도
권한 없는 접근을 시스템이 정상 차단한 경우
스케줄러/백그라운드 작업에서 사용한 인증 정보 만료로 반복 발생하나, 서비스 핵심 사용자 흐름에는 직접 영향이 없는 경우

위 경우 P3 까지도 가능하다.

참고 판단

동일한 Unauthorized가 여러 인스턴스에서 동시에 발생한다면,
개별 서버 문제가 아니라 공통 인증 설정 또는 공통 토큰 상태 문제일 가능성이 높다.
다만 동일한 시점의 반복 패턴이 정기적이라면, 사용자 요청이 아니라 스케줄러/배치 잡에서 호출하는 내부 작업일 가능성도 함께 검토해야 한다.

8-4. 잘못된 사용자 식별자 예외처리

기본 분류

이유

도메인 검증, 입력값 검증, 잘못된 사용자 참조 방지 등과 연관된 예외일 가능성이 있다.
이는 시스템이 예외 상황을 적절히 방어하고 있다는 뜻일 수도 있다.

상향 조건

정상적인 사용자 플로우에서도 반복 발생
프론트엔드 또는 외부 시스템과의 계약 오류로 대량 발생
운영자 업무를 반복적으로 막음

위 경우 P1 검토 가능

하향 조건

잘못된 요청을 의도대로 차단하는 예외
일부 사용자 입력 실수
실제 서비스 장애가 아님

위 경우 P3 도 가능하다.

8-5. 비정상 경로 접근에 따른 `NotFoundException`

기본 분류

이유

이 유형은 일반적인 정상 사용자 경로라기보다,
외부 스캐너, 봇, 잘못된 링크, 비정상 파라미터 접근처럼 보일 가능성이 높다.

특히 경로가 아래와 같은 특징을 보이면 더욱 노이즈 가능성이 높다.

의미 없는 redirect 값 포함
외부 IP / 포트 조합 포함
서비스 정상 라우팅 체계와 맞지 않음
짧은 시간에 다양한 URL을 탐색

운영 방침

이 유형은 기본적으로 실시간 장애 채널에 올리는 것보다,
로그성/노이즈성 트래픽으로 분리하여 관리하는 것이 적절하다.

9. 보조 판단 규칙

9-1. 우선순위 상향 규칙

아래 조건이 있으면 한 단계 상향한다.

여러 애플리케이션 인스턴스에서 동시에 발생
users 수 급증
events 수 급증
Last Seen이 매우 최근이며 계속 재발
핵심 비즈니스 기능과 직접 연결
운영 업무가 막힘

예시:

Unauthorized 기본 P2 → 정상 사용자 대량 영향 시 P1
query failed 기본 P1 → 핵심 기능 전면 실패 시 P0

9-2. 우선순위 하향 규칙

아래 조건이 있으면 한 단계 하향한다.

봇/스캐너 유입
비정상 경로 접근
의도된 validation 예외
이미 시스템이 정상적으로 차단하고 있는 요청
실제 사용자 영향이 거의 없음
스케줄러/배치 잡 실패이지만 서비스 핵심 기능과 직접 연결되지 않음
동일 리소스에 대한 중복 요청/재시도로 인해 event 수만 버스트하게 증가함

예시:

비정상 경로 접근성 NotFoundException → P3 유지
일부 Unauthorized → P3 가능
잘못된 사용자 식별자 처리 → P2 또는 P3
중복 PUT/병렬 업데이트 충돌 → 실제 영향이 낮다면 P2 또는 P3

10. Slack 알람 운영 제안

10-1. 기본 원칙

Slack 알람은 “발생 여부”가 아니라 “운영 우선순위”를 기준으로 재정비한다.

10-2. 권장 운영 방식

P0 / P1
- 실시간 알람 유지
- 운영/백엔드 채널 발송
- 즉시 대응 대상
P2
- 일반 에러 채널 또는 리뷰 채널
- 지나친 멘션/과도한 알람은 지양
- 추적 및 개선 대상
P3
- 실시간 알람 제외 또는 최소화
- 주기적 리뷰만 수행
- 노이즈 관리 대상

10-3. 현재 알람 구조와의 차이

현재는 “새 issue 또는 최근 5분 내 1회 이상 재발”만으로 넓게 알람이 가기 쉬운 구조다.
향후에는 반드시 priority 또는 custom tag 기반으로 알람을 분기할 수 있어야 한다.

11. 향후 구현 방향

현재 문서는 수동 우선순위 정비 기준을 정의하는 데 목적이 있지만,
이후에는 백엔드 코드 수준에서 동일한 기준을 Sentry 이벤트에 반영할 필요가 있다.

11-1. 백엔드 측 구현 목표

에러 발생 시 우선순위 관련 custom tag 부여
인증/인가, 외부 연동, DB 오류, validation 오류 등을 구분하는 tag 추가
스케줄러/배치 잡과 사용자 요청 기반 에러를 구분하는 tag 추가
이후 Slack alert rule에서 해당 tag를 조건으로 사용

11-2. 예시 태그 설계

ops.priority = P0 | P1 | P2 | P3
ops.category = auth | db | external | validation | route | job
ops.feature = login | messaging | user | query | scheduler
ops.impact = business_core | field_ops | limited | noise
ops.origin = user_request | cron_job | batch_job | internal_call
ops.concurrent = true | false

11-3. 기대 효과

UI에서 에러를 빠르게 필터링 가능
Slack 알람을 등급별로 분리 가능
단순 발생량이 아닌 운영 의미 기반 분류 가능
노이즈 감소 및 대응 속도 향상
스케줄러 유발 에러와 사용자 유발 에러를 구분 가능
중복 요청/병렬 충돌에 의한 예외 증폭 여부를 파악 가능

12. 운영 예시

예시 1. 모든 로그인 요청에서 JWT 인증 실패

에러 유형: Unauthorized
영향: 정상 사용자 다수 로그인 불가
인스턴스: 여러 애플리케이션 인스턴스 공통
판단: P1 또는 P0

예시 2. 일부 만료 토큰 요청에서 Unauthorized

에러 유형: Unauthorized
영향: 제한적
판단: P2 또는 P3

예시 3. 비정상 경로 요청 다수

에러 유형: NotFoundException
영향: 실제 정상 사용자 영향 거의 없음
판단: P3

예시 4. 외부 메시지 발송 실패로 인증 절차 불가

에러 유형: 외부 메시징 서비스 연동 에러
영향: 인증 플로우 차질
판단: P1, 심하면 P0

예시 5. 관리자성 페이지의 query failed

에러 유형: query failed error
영향: 제한적
판단: P2

예시 6. 핵심 트랜잭션 API의 query failed

에러 유형: query failed error
영향: 핵심 기능 장애
판단: P0 또는 P1

예시 7. 스케줄러가 같은 작업을 각 인스턴스에서 동시에 실행하여 동일 예외 반복

에러 유형: job 기반 반복 예외
영향: 실제 사용자 영향은 제한적
판단: P2 또는 P3

예시 8. 동일 리소스에 대한 중복 PUT 요청으로 unique 충돌 예외가 버스트하게 증가

에러 유형: query failed / duplicate 처리 계열
영향: 최종 상태가 정상 반영되면 제한적
판단: P2
참고: 최종 상태가 깨지거나 핵심 기능 실패율이 높아지면 P1 이상으로 상향

13. 최종 정리

최근 30일간 자주 발생한 에러를 단순 발생량 기준으로만 보면,
실제 대응해야 할 장애와 노이즈성 이슈가 구분되지 않는다.

따라서 본 문서에서는 아래 원칙을 채택한다.

에러 이름만이 아니라 비즈니스 영향도로 분류한다.
Sentry 기본 Priority와 팀 내부 Priority를 구분한다.
DB 오류, 외부 연동 실패, 대량 인증 실패는 우선적으로 관리한다.
비정상 경로 접근은 기본적으로 P3로 본다.
스케줄러/배치 잡 유발 에러는 사용자 영향과 분리해서 판단한다.
중복 요청/병렬 처리 충돌에 의한 예외 버스트는 최종 상태와 사용자 영향 기준으로 재평가한다.
향후 백엔드에서 custom tag를 붙여 Slack 알람과 Sentry 필터링을 일관되게 운영한다.

14. 현재 기준 요약표

에러 유형	기본 분류	상황에 따른 조정
query failed error	P1	핵심 기능 장애면 P0, 부가 기능이거나 중복 충돌이면 P2
외부 메시징/알림 서비스 연동 에러	P1	핵심 인증/업무 연동이면 유지, 부가 알림이면 P2
Unauthorized 에러	P2	정상 사용자 대량 영향이면 P1+, 비정상 접근이면 P3
잘못된 사용자 식별자 예외처리	P2	정상 플로우 영향 크면 P1, 의도된 방어면 P3
비정상 경로 접근에 따른 NotFoundException	P3	일반적으로 유지
스케줄러/배치 잡 유발 반복 예외	P2	핵심 잡이면 P1, 비핵심 잡이면 P3
중복 PUT/병렬 업데이트 충돌	P2	최종 상태 이상/핵심 기능 실패 시 P1 이상

15. 추후 보완 항목

향후 실제 운영 과정에서 아래 항목을 추가로 보완한다.

최근 30일 issue 샘플 20~30건에 대한 실제 분류 결과 반영
users 수 / events 수 기준 정량화
운영 담당자 영향 기준 구체화
release/environment/tag 기반 세부 규칙 추가
Slack 채널 분리 정책 반영
백엔드 Sentry tagging 구현 반영
스케줄러/배치 잡별 중요도 정의
병렬 요청/재시도/중복 처리 정책 문서화

16. 결론

이 문서는 Sentry 에러를 단순 로그가 아니라 운영 우선순위 자산으로 다루기 위한 첫 기준 문서이다.

핵심은 다음과 같다.

중요한 에러는 더 빨리 보여야 한다
중요하지 않은 에러는 노이즈로 분리되어야 한다
같은 기준이 Sentry UI, Slack 알람, 백엔드 태깅 코드에 모두 반영되어야 한다
스케줄러와 사용자 요청에서 발생한 에러는 분리해서 해석해야 한다
이벤트 수가 많다는 이유만으로 무조건 높은 우선순위로 보지 않는다

이후 단계에서는 본 문서를 기준으로:

실제 issue 샘플 분류
alert rule 재설계
백엔드 Sentry tagging 구현

순으로 이어서 개선을 진행한다.

Sentry 에러 우선순위 정비 및 Alert Rule 개선 가이드

1. 문서 목적

2. 배경

2-1. 현재 Sentry 운영 상의 문제

3. 현재 Alert Rule 상태

3-1. 문제점

4. 기본 원칙

4-1. 비즈니스 영향도

4-2. 영향 대상

4-3. 영향 범위

4-4. 지속성

4-5. 우회 가능성

4-6. 발생 문맥

5. 우선순위 체계 정의

6. 우선순위 상세 정의

6-1. P0

정의

판단 기준

예시

Sentry 매핑

Slack 운영

6-2. P1

정의

판단 기준

예시

Sentry 매핑

Slack 운영

6-3. P2

정의

판단 기준

예시

Sentry 매핑

Slack 운영

6-4. P3

정의

판단 기준

예시

Sentry 매핑

Slack 운영

7. 최근 30일 주요 에러 재분류

8. 각 주요 에러에 대한 상세 판단

8-1. query failed error

기본 분류

이유

상향 조건

하향 조건

추가 검토 포인트

8-2. 외부 메시징/알림 서비스 연동 에러

기본 분류

이유

상향 조건

하향 조건

8-3. UnauthorizedException: Unauthorized

기본 분류

이유

상향 조건

하향 조건

참고 판단

8-4. 잘못된 사용자 식별자 예외처리

기본 분류

이유

상향 조건

하향 조건

8-5. 비정상 경로 접근에 따른 NotFoundException

기본 분류

이유

운영 방침

9. 보조 판단 규칙

9-1. 우선순위 상향 규칙

9-2. 우선순위 하향 규칙

10. Slack 알람 운영 제안

10-1. 기본 원칙

10-2. 권장 운영 방식

10-3. 현재 알람 구조와의 차이

11. 향후 구현 방향

11-1. 백엔드 측 구현 목표

11-2. 예시 태그 설계

11-3. 기대 효과

12. 운영 예시

예시 1. 모든 로그인 요청에서 JWT 인증 실패

8-1. `query failed error`

8-3. `UnauthorizedException: Unauthorized`

8-5. 비정상 경로 접근에 따른 `NotFoundException`