프론트엔드 에러 버짓: 배포 속도와 안정성의 균형

"요즘 오류가 좀 많긴 한데 배포는 계속해야죠"라는 말이 반복되면, 이미 기준이 없는 상태입니다. 에러 버짓의 목적은 팀을 느리게 만드는 게 아니라, 위험 신호가 보일 때 자동으로 브레이크를 걸게 만드는 겁니다. 특히 프론트엔드는 브라우저/디바이스 조합이 많아 재현이 늦기 때문에, 기준이 없으면 항상 대응이 뒤로 밀립니다.

1) 먼저 정할 것: 무엇을 에러로 볼지

Sentry 이벤트 총량만 보면 거의 쓸모가 없습니다. 사용자에게 실제 영향이 있는지로 나눠야 합니다.

• 치명: 결제/로그인/저장 같은 핵심 흐름 실패
• 중간: 화면 일부 기능 불가, 새로고침으로 복구 가능
• 경미: 콘솔 경고, 사용자 영향 없음

버짓 차감은 치명/중간만 대상으로 하고, 경미는 개선 백로그로 분리하는 게 실무적으로 가장 깔끔합니다.

2) 바로 적용 순서

1. 월간 허용치 정의: 예) 핵심 흐름 실패 세션 비율 0.3% 이하
2. 구간 정의: 정상(<0.2), 경고(0.2~0.3), 제한(0.3~0.5), 중단(>=0.5)
3. 구간별 행동 고정:
   • 경고: 고위험 기능 배포 제한
   • 제한: 신규 기능 배포 중단, 안정화 작업 우선
   • 중단: 핫픽스 전용 체제 전환
4. CI/CD에 현재 버짓 상태를 표시해 릴리스 승인 단계에 노출
5. 주간 회고에서 "어떤 변경이 버짓을 깎았는지"를 원인 단위로 기록

버짓 숫자보다 중요한 건 3번, 즉 행동 규칙입니다. 이게 없으면 버짓은 차트로만 끝납니다.

3) 최소 대시보드 구성

• fatal_error_session_rate
• checkout_fail_rate
• sign_in_fail_rate
• release_version_by_error_spike

여기에 버전 태그를 꼭 붙여야 "이번 배포가 원인인지"를 바로 판단할 수 있습니다.

4) 흔한 실패 패턴

• 모든 오류를 같은 무게로 차감해서 팀이 지표를 신뢰하지 않음
• 버짓이 넘어도 비즈니스 이유로 계속 배포해 규칙이 무력화됨
• 버짓 소진 원인을 기술팀만 리뷰하고 기획/운영은 빠짐

에러 버짓은 기술 지표가 아니라 팀 운영 규칙입니다. "누가 잘못했나"가 아니라 "언제 속도를 줄일지"를 자동으로 정하는 도구로 쓰면 효과가 확실히 납니다.