예외 레벨 정책 정립: 예상 가능한 4xx 와 실제 5xx 분리

[Goder-0]

Overview

• 현재 예외 로그는 예상 가능한 사용자 오류와 실제 서버 장애가 같은 톤으로 남는다.
• 운영에서는 무엇이 정상적인 실패이고 무엇이 실제 장애인지 로그 레벨에서 먼저 구분돼야 한다.

Details

• No static resource ... 같은 외부 탐색 요청도 ERROR 로 남는다.
• validation, type mismatch, business exception 같은 예상 가능한 4xx 도 현재 구조상 ERROR + stack trace 로 쌓일 가능성이 높다.
• 이런 구조에서는 진짜 5xx, 외부 API 장애, 재처리 필요한 실패가 묻힌다.

작업 내용

• 예외 레벨 정책을 아래처럼 명시한다.
• 예상 가능한 4xx/비즈니스 예외: INFO 또는 WARN
• 인증 누락, 잘못된 파라미터, validation 오류: 기본 INFO 또는 샘플링된 WARN
• 예상 못한 5xx, 데이터 손상, 외부 시스템 장애: ERROR + stack trace
• NoResourceFoundException, MethodArgumentNotValidException, ConstraintViolationException, BusinessException 의 기본 레벨을 재정의한다.
• 스캐너/봇 요청에서 발생하는 404, 잘못된 request target 파싱 실패는 애플리케이션 장애 로그와 분리한다.
• 어떤 예외에 stack trace 를 남길지 기준을 정한다.
• 최종 정책을 팀 규칙으로 문서화한다.

Expected Outcome

• 운영자가 ERROR 로그만 봐도 실제 조치가 필요한 문제에 더 가깝게 수렴한다.
• 사용자 입력 오류, 봇 탐색, 예상 가능한 비즈니스 실패가 장애 페이지를 차지하지 않는다.