### 이슈 배경 - 현재 `RequestLoggingFilter`는 요청만 로깅하고 응답에 대한 로깅이 없다. - 4xx/5xx 디버깅 시 서버가 실제로 어떤 응답(에러 코드/메시지)을 내려줬는지 로그로 확인할 수 없다. - 상태코드·소요시간 외에 에러 응답 포맷 등을 확인해야 하는 상황이 있다. ### 📄 작업 내용 or 논의 내용 - 응답을 `ContentCachingResponseWrapper`로 감싸 본문을 읽는다 - 읽은 뒤 반드시 `copyBodyToResponse()` 호출 (누락 시 클라이언트가 빈 응답 수신 — 필수) - 응답 본문은 DEBUG 레벨에서만 기록 (요청 헤더 정책과 동일) - JSON/텍스트 content-type 만 기록, 이미지·파일 등 바이너리는 스킵 - 최대 길이 제한(예: 2000자) 후 초과분 truncate (대용량 응답 로그 폭증 방지) - status / 소요시간은 INFO 한 줄에 유지 - 논의: 응답 본문에도 토큰/PII 포함됨(로그인 응답 JWT, `/member/me` 이메일). - auth/login 응답 경로는 본문 로깅에서 제외할지 정책 결정 필요. - DEBUG 활성화 시 로그 수집 시스템 적재 여부도 고려. ### 🙋🏻 참고 자료 _No response_
이슈 배경
RequestLoggingFilter는 요청만 로깅하고 응답에 대한 로깅이 없다.📄 작업 내용 or 논의 내용
ContentCachingResponseWrapper로 감싸 본문을 읽는다copyBodyToResponse()호출 (누락 시 클라이언트가 빈 응답 수신 — 필수)/member/me이메일).🙋🏻 참고 자료
No response