애플리케이션을 개발하다 보면, 로깅처럼 여러 계층에 걸쳐 반복적으로 필요한 작업들이 있다.
이러한 작업을 횡단 관심사 라고 부르며, Spring에서는 이를 처리할 수 있는 여러 수단을 제공한다.
그중에서도 AOP와 Interceptor는 가장 많이 사용되는 대표적인 방식이다.
하지만 이 둘은 동작 위치도 다르고, 주로 쓰이는 목적도 다르기 때문에
로깅을 한다면 AOP를 써야 할까, Interceptor를 써야 할까?라는 고민이 생기게 된다.
이번 TIL에서는 AOP와 Interceptor의 역할을 간단히 정리하고,
로깅 상황에서 어떤 기준으로 선택해야 할지에 대해 생각해보았다.
API 명세서도 AOP 가 해줬으면... 이전에 작성했던 AOP 글이다.
이전에 작성했던 Interceptor 의
책임이다.
1번. Controller 앞에 AOP 가 실행되는 상황
이 구조는
@Controller,@RestController같은컨트롤러 레이어에 AOP를 적용한 경우다.
2번. Service 앞에 AOP 가 실행되는 상황
이 구조는
@Service 레이어에 AOP를 적용한 경우다.
트랜잭션 처리, 비즈니스 로직 실행 전후의 로깅, 실행 시간 측정 등
핵심 로직을 감싸는 형태로 자주 사용된다.
정리하면
AOP는 적용 대상에 따라 실행 위치가 달라지며,
컨트롤러에 적용하면 요청 처리 관점, 서비스에 적용하면 비즈니스 로직 관점의 공통 처리를 할 수 있다
※어디서, 무엇을, 어떻게 로깅할 것인가? 를 구조적으로 정리하는 것
어디서:Controller 레벨 이전(요청 진입 시점)
무엇을:요청 정보 (URI, 헤더, 파라미터 등)
어떻게:로깅 도구(SLF4J, Logback)를 사용해 일관된 포맷으로 출력
기술:Interceptor 활용
가정: 모든 경로에 대해서 로그가 남게 작성
어디서:Controller 레벨 이전(요청 진입 시점)
무엇을:요청 정보 (URI, 헤더, 파라미터 등)
어떻게:로깅 도구(SLF4J, Logback)를 사용해 일관된 포맷으로 출력
기술:AOP 활용
가정: AuthController 내부만 적용
다른 컨트롤러의 요청은 로깅되지 않음을 볼 수 있다.
# 1 LoggingInterceptor or AOP logging
AOP는 반환값 기반의 정밀 조건(예: null 반환 시만 로깅 등)에 적합하다.
# 2 Interceptors vs Aspects in Spring?
Spring MVC의 Interceptor와 Spring AOP는 동작 범위와 목적이 다르다.
쉽게 정리하면, 모든 컨트롤러에 대해서 전부 적용하고 싶다면 Interceptor
특정 메서드만 적용하고 싶다면 AOP 를 추천한다.