프로덕션 운영 준비 필수 항목 정리

[Goder-0]

Overview

• 현재 프로덕션 로그에는 운영상 의미 있는 장애 신호보다 노이즈와 민감정보가 더 많이 남고 있다.
• 특히 요청 로그, SQL 바인딩 로그, 인증 관련 경고, 외부 스캐너 트래픽, 비동기 AI 처리 실패가 한데 섞여 있어 장애 탐지와 사후 분석 비용이 높다.
• 이 이슈는 배포 전 반드시 정리해야 할 운영 기본선을 묶는 부모 이슈다.

Details

• 로그에 실제 authorization 헤더와 cookie, accessToken, refreshToken, 요청 본문이 남는다.
• Token not found (missing in both header and cookie) 경고가 하루 수천~수만 건씩 발생해 운영 신호를 오염시킨다.
• 프로덕션 로그에 org.hibernate.SQL / org.hibernate.orm.jdbc.bind 가 노출되어 파라미터 값과 개인정보가 그대로 보인다.
• access/app/audit 같은 로그 카테고리 설계와, requestId 로 같은 요청을 이어 보는 상관관계 추적 설계가 아직 분리되어 있지 않다.
• swagger-ui, mock, /.env.{{DN}}, index.php?... 같은 외부 탐색/스캐너 요청이 반복되는데, 일부는 애플리케이션 ERROR 로그로 남는다.
• @Async 작업이 SimpleAsyncTaskExecutor-* 로 실행되고 있어 bounded executor, 큐, 백프레셔, 공통 MDC 전파가 없다.
• Actuator 의존성은 있지만 운영용 readiness/liveness/metrics 체계는 보이지 않고, /health-check 커스텀 문자열 응답만 있다.

Sub Issues

• 민감정보가 남지 않는 요청 로깅 정책으로 전환
• prod 로그 레벨/프로필 drift 제거 및 SQL 바인딩 로그 차단
• 로그 카테고리 분리와 MDC 기반 요청 상관관계 구축
• 예외 레벨 정책 정립: 예상 가능한 4xx 와 실제 5xx 분리
• 관측성 기본선 구축: health/readiness/liveness/metrics
• 공개 표면 하드닝: Swagger/H2/mock 노출 정책과 스캐너 노이즈 분리
• 비동기/AI 처리 안정화: bounded executor, 재처리, 알림, 복구 루트
• RequestLoggingFilter 응답 본문 로깅 추가 (DEBUG 레벨)
• 운영 로그에서 스캐너·정적리소스 요청 제외

Expected Outcome

• 운영 로그가 민감정보 없이도 요청 흐름과 장애 원인을 재구성할 수 있는 형태가 된다.
• 정상 사용자 요청, 봇/스캐너 트래픽, 예상 가능한 4xx, 실제 5xx/외부 장애가 서로 분리된다.
• 로그 카테고리와 요청 추적 방식이 구분되어, 파일 분리 여부와 관계없이 설계 의도가 명확해진다.
• AI 연동 실패나 비동기 처리 실패가 재현 가능하고 복구 가능한 운영 이벤트로 바뀐다.