🎯 학습 목표
- 횡단 관심사(cross-cutting concern)가 무엇인지 이해한다.
- AOP가 OOP의 어떤 한계를 보완하는지 설명할 수 있다.
- AOP를 적용하기 좋은 상황을 구분한다.
📖 개념 설명
애플리케이션을 만들다 보면 핵심 비즈니스 로직과 무관하게 여기저기 반복되는 코드가 있습니다. 로깅, 실행 시간 측정, 트랜잭션 처리, 권한 검사 같은 것들입니다. 이런 기능은 “여러 모듈을 가로질러(cross-cutting) 공통으로 필요한 관심사”라서 횡단 관심사라고 부릅니다.
OOP만으로 이를 처리하면, 모든 메서드 앞뒤에 같은 로깅·측정 코드를 복사해 넣어야 합니다. 핵심 로직이 부가 코드에 파묻히고, 정책이 바뀌면 수십 곳을 고쳐야 합니다. AOP(Aspect Oriented Programming, 관점 지향 프로그래밍)는 이 부가 기능을 Aspect라는 별도 모듈로 떼어내, 원하는 지점에 자동으로 끼워 넣습니다.
비유하자면, 모든 방마다 “불 끄고 나가기” 메모를 붙이는 대신, 출입구에 자동 소등 센서를 다는 것과 같습니다. 각 방(비즈니스 로직)은 본연의 역할만 하고, 공통 동작(소등)은 한 곳에서 관리됩니다.
결과적으로 AOP는 (1) 코드 중복 제거, (2) 비즈니스 로직의 가독성 향상, (3) 공통 정책의 일관된 변경이라는 이점을 줍니다.
💻 AOP 없이 (문제 상황)
public Order placeOrder(OrderRequest req) {
long start = System.currentTimeMillis(); // ← 측정 코드
log.info("placeOrder 시작"); // ← 로깅 코드
try {
// === 진짜 비즈니스 로직 ===
Order order = orderService.create(req);
return order;
} finally {
long elapsed = System.currentTimeMillis() - start; // ← 측정 코드
log.info("placeOrder 종료 ({}ms)", elapsed); // ← 로깅 코드
}
}
// 모든 메서드마다 이 부가 코드가 반복됨 → AOP로 분리 대상
💡 AOP를 쓰기 좋은 경우
- 로깅 / 실행 시간 측정 / 감사(audit) 기록
- 트랜잭션 경계 처리 (스프링
@Transactional도 내부적으로 AOP) - 권한·인증 검사, 예외 공통 처리, 캐싱, 재시도
⚠️ 주의사항
- AOP는 “부가 기능”에 쓰는 도구입니다. 핵심 비즈니스 분기를 AOP에 숨기면 흐름 추적이 어려워집니다.
- 남용하면 “코드를 봐도 무슨 일이 일어나는지 모르는” 마법이 됩니다. 적용 범위를 명확히 하세요.