Spring AOP Fundamentals

Overview

AOP는 Logging, Transaction, Authorization처럼 여러 Business Method를 가로지르는 횡단 관심사를 업무 코드에서 분리해 일관된 규칙으로 적용하는 설계 방식이다. Spring AOP는 주로 Bean Method 호출을 Runtime Proxy로 감싼다.

한 문장 설명: 여러 방에 반복 설치할 보안 검색대를 각 방 안이 아니라 공통 입구에 두는 방식이다.

핵심 용어

왜 필요한가

각 Service가 Transaction 시작·Rollback, 실행시간 기록, 권한 검사를 복사하면 누락과 정책 불일치가 생긴다. AOP는 적용 대상과 부가기능을 분리해 변경 지점을 한곳으로 모은다.

면접에서는 “핵심 관심사와 횡단 관심사의 분리”로 설명한다. 주문 생성, 결제 승인, 재고 차감은 핵심 관심사다. Transaction, Logging, 권한 검사, Metric은 여러 Use Case를 가로지르는 횡단 관심사다. AOP는 후자를 별도 모듈로 빼서 적용 규칙에 따라 끼워 넣는다.

핵심 원리와 내부 동작

Client가 Target 대신 Proxy를 호출한다. Proxy는 Interceptor Chain을 실행하고 최종적으로 Target Method를 호출한 뒤 결과 또는 예외를 Advice에 전달한다. @Transactional은 이 구조로 Transaction 경계를 만든다.

sequenceDiagram; participant C as Client; participant P as Proxy; participant T as Target; C->>P: method(); P->>P: begin/log/auth; P->>T: invoke; T-->>P: result or exception; P->>P: commit/rollback; P-->>C: result

Example

@Around("@annotation(Measured)")
Object measure(ProceedingJoinPoint pjp) throws Throwable {
  long started = System.nanoTime();
  try { return pjp.proceed(); }
  finally { timer.record(System.nanoTime() - started); }
}

Metric 이름에 Method Argument를 무제한 Label로 넣으면 Cardinality가 폭증한다. Business Event를 AOP로 숨기기보다 명시적으로 발행하는 것이 나을 수 있다.

Spring AOP의 적용 범위

Spring AOP는 기본적으로 Spring Bean의 Method 호출을 Proxy로 감싸는 방식이다. 그래서 외부 Client가 Proxy를 통해 호출할 때 Advice가 실행된다. 같은 객체 내부에서 this.inner()처럼 자기 Method를 호출하면 Proxy를 거치지 않아 @Transactional, Metric, Security Advice가 적용되지 않을 수 있다.

JDK Dynamic Proxy는 Interface 기반 Proxy를 만들고, CGLIB Proxy는 Class를 상속해 Proxy를 만든다. 둘 다 호출 입구를 감싼다는 원리는 같지만 final Class/Method, Visibility, Self Invocation 같은 제약을 이해해야 한다.

실무에서 발생하는 문제와 Trade-off

흐름이 코드에서 바로 보이지 않아 Debugging이 어려워질 수 있다. 넓은 Pointcut은 예상하지 않은 Method와 Startup을 가로챈다. Advice 순서가 Transaction과 Retry 의미를 바꾼다. Proxy 기반이라 Self Invocation 같은 한계가 있다.

흔한 오해

• AOP는 Annotation 자체가 아니다. Annotation은 Pointcut 메타데이터 한 방식이다.
• 모든 중복 코드를 AOP로 옮겨야 하는 것은 아니다.
• Spring AOP와 Compile/Load-time Weaving은 적용 범위가 다르다.
• Proxy가 없는 객체 호출에는 Advice가 적용되지 않는다.

Production Considerations

Pointcut 범위를 Test하고 Advice 실패가 Business 요청을 망칠지 결정한다. Logging에서 개인정보와 Payload 크기를 제한한다. Transaction·Retry·Metric Aspect의 Order를 문서화하고 Trace로 실제 Chain을 확인한다.

다른 사람에게 설명한다면

30초: “AOP는 Transaction·Logging 같은 횡단 관심사를 Business 코드에서 분리하는 방식입니다. Spring은 보통 Proxy가 Method 호출을 가로채 Pointcut으로 대상을 고르고 Advice를 전후에 실행합니다.”

2분: Join Point·Pointcut·Advice 용어를 호출 Sequence에 배치하고, @Transactional, Self Invocation, Advice Order Trade-off까지 설명한다. “AOP는 반복 정책에는 강하지만, 업무 의미가 숨겨지면 오히려 이해하기 어려워진다”는 한계까지 덧붙인다.

Interview Questions

1. AOP가 해결하는 문제는?
2. Join Point와 Pointcut의 차이는?
3. Advice 순서가 Transaction에 영향을 주는 예는?
4. AOP를 쓰지 말아야 할 신호는?

Related Topics

Proxy·Advice·Pointcut, IoC와 Container를 본다.