로그 위생 정리 및 레이어별 로깅 규칙 수립

[ckdals4600]

이슈 배경

• 서비스 전반의 로그가 레이어·상황에 관계없이 INFO 위주로 남아, 운영 로그에 노이즈와 민감정보가 섞여 있다.
• 어떤 로그를 어느 레벨로 남길지에 대한 공통 규칙이 없어, 같은 성격의 처리도 클래스마다 다르게 로깅된다.
• 로그 카테고리/상관관계(로그 카테고리 분리와 MDC 기반 요청 상관관계 구축 #242)와는 별개로, "무엇을 어느 레벨로 남길 것인가"의 기준과 위반 사례 정리에 초점을 둔다.

이슈 내용

로그 정리 규칙 (Logging Convention)

레벨 기준

• ERROR: 시스템이 처리하지 못한 진짜 장애. 5xx, 예상치 못한 예외. 스택트레이스 포함.
• WARN: 클라이언트 잘못(4xx), 외부 연동 실패 후 graceful fallback, 비정상이지만 서비스가 죽지 않는 분기. 스택트레이스 미포함(메시지만).
• INFO: 앱 생애주기 이벤트(기동/종료), 감사 성격의 상태 변화 정도로 최소화.
• DEBUG: 정상 흐름 추적, 요청/응답 본문, 처리 단계별 로그.

레이어별 기준

• Filter: 모든 요청의 access 로그(메서드·경로·상태·응답시간). 이미 RequestLoggingFilter가 담당.
• Controller: 직접 로깅하지 않는다. 요청 로그는 필터가 대신한다.
• Service: 상태 전이, 외부 연동 결과, 비정상 분기만 남긴다. 메서드 시작/끝·단순 조회 성공은 남기지 않는다.
• Repository: 직접 로깅하지 않는다. SQL은 Hibernate 설정으로 제어.
• 예외 로깅: GlobalExceptionHandler 한 곳에서 처리(4xx→WARN, 5xx→ERROR). 각 레이어에서 catch 후 log.error + rethrow 하지 않는다(이중 로깅 금지).

공통 원칙

• 민감정보(이메일·토큰·비밀번호·사용자 입력 콘텐츠)는 운영 기본 레벨(INFO)에 남기지 않는다.
• 파라미터 바인딩(log.info("id={}", id))을 사용한다. 문자열 연결 금지.
• 같은 성격의 처리는 같은 레벨로 일관되게 로깅한다.

참고 자료

No response