본문으로 건너뛰기

Sentry 주간 에러 리뷰 runbook

목적: production 에서 사용자(특히 staff)가 맞는 에러를 제보 전에 발견한다. 2026-06-12 staff 권한 격차 감사의 교훈 — "직원들이 오류가 많아 사용을 못 한다"는 제보가 오기 전까지, 설정 화면 거부·가짜 성공·permission-denied 가 수 주간 무관측이었다. Sentry DSN 은 처음부터 설정돼 있었으나 보는 루틴이 없었다.

전제 (코드 측)

  • web 클라이언트는 NEXT_PUBLIC_SENTRY_DSN 으로 초기화 (apps/web/sentry.client.config.ts, production 한정).
  • (workspace) layout 이 SentryContextTag 를 mount — 모든 이벤트에 role(owner|staff)·tenantId 태그 부착. PII 최소화 원칙: 이메일·이름·uid 는 전송하지 않는다.
  • 에러 바운더리(app/error.tsx)와 unhandled rejection 이 자동 수집된다. Firestore permission-denied 류는 console.error 만으로는 안 잡히므로, 반복 거부가 의심되면 콘솔 로그 → 코드의 fail-loud 경로(throw/captureException) 여부를 확인.

주간 절차 (매주 월요일, 10분)

  1. 신규 이슈: Sentry → Issues → 필터 is:unresolved firstSeen:-7d — 지난 7일 처음 등장한 이슈 전수 훑기.
  2. staff 필터: 같은 화면에서 role:staff 태그 필터 — staff 만 맞는 이슈가 있으면 권한 격차 클래스 의심 (UI 표면 ↔ 서버 게이트 불일치, rules default-deny). staff 감사 체크리스트 의 클래스와 대조.
  3. 빈도 상위: is:unresolved 이벤트 수 정렬 상위 5개 — 새 배포(release) 직후 급증 여부 확인 (배포 skew·회귀 신호).
  4. triage 기준:
    • 사용자 플로우 차단(저장 실패·dead-end·무한 스피너) → 즉시 수정 (P0/P1)
    • 조용한 기능 무동작(permission-denied·silent catch) → 당주 내 수정 (P1)
    • 소음(서드파티 스크립트·취소된 요청) → ignore 규칙 추가
  5. 처리한 이슈는 Sentry 에서 Resolve — 다음 주 리뷰가 신규분만 보게 유지.

알림 연결 (1회 설정 권장)

Sentry → Alerts → "이슈가 처음 발생했을 때" + "이벤트 수가 1시간에 N 회 초과" 두 룰을 이메일(또는 기존 Slack 피드백 웹훅 채널)로 연결하면 주간 루틴 사이의 급성 장애를 보완한다.