11-3. AOP (Aspect Oriented Programming)

[설계 원칙]
   └─ 관심사 분리 (SoC)

        ↓ 구현 방식들

   ├─ 일반적인 공통 로직 분리
   └─ AOP (관점 지향 프로그래밍)

1. 관심사 분리(Separation of Concerns)

1️⃣ 관심사 분리(Separation of Concerns)란? — “왜 나누는가”

1) 핵심 정의

서로 다른 책임·목적·변경 이유를 가진 코드를 각각 분리해서 관리하려는 설계 원칙

• 개념 수준의 철학 / 원칙

• 특정 기술이나 문법 아님

• “어떻게”가 아니라 “왜”의 문제

2) 예시 (넓은 개념)

• 화면 로직 vs 비즈니스 로직 (MVC)

• 컨트롤러 vs 서비스 vs 레포지토리

• 결제 로직 vs 배송 로직

2. 공통 로직 분리

1️⃣ 일반적인 공통 로직 분리 — “가장 단순한 구현 방식”

1) 정의

여러 곳에서 반복되는 코드를 함수나 클래스로 뽑아서 재사용하는 방식

2) 특징

• 개발자가 직접 호출

• 언어 기능만으로 가능

• 가장 직관적이고 흔함

checkAuth();   // 공통 로직
sell();        // 핵심 로직
log();         // 공통 로직

3) 장점

• 이해하기 쉽다

• 구현이 단순하다

4) 한계

• 호출을 강제할 수 없음

• 빠뜨리면 버그

• 핵심 로직이 부가 관심사에 오염됨

3. AOP(Aspect Oriented Programming)

1️⃣ AOP란? — “관심사 분리를 강하게 강제하는 방법”

1) 정의

핵심 로직을 건드리지 않고 부가 관심사를 자동으로 끼워 넣는 프로그래밍 방식

2) 중요한 키워드

• 자동으로

• 선언적으로

• 코드 수정 없이

3) AOP가 해결하려는 문제

2️⃣ AOP가 성립하기 위한 필수 조건

1) 명확한 실행 지점(Join Point)이 있어야 한다

어디에 끼어들지 “정의할 수 있어야” AOP가 된다.

• 메서드 실행 전

• 메서드 실행 후

• 예외 발생 시

• “어느 줄 코드 중간”

• “if 문 안쪽 한 줄”

2) 핵심 로직과 부가 로직이 물리적으로 분리되어야 한다

같은 메서드 안에 섞여 있으면 AOP 아님

sell() {
    log();
    doSell();
}

sell() {
    doSell(); // 이것만 존재
}

3) 적용 대상이 선언적으로 정의되어야 한다 (Pointcut)

“어디에 적용할지”를 코드 호출이 아니라 규칙으로 정한다

• 패키지 기준

• 클래스 이름 패턴

• 어노테이션 기준

@Around("@annotation(Transactional)")

4) 자동 적용 메커니즘이 존재해야 한다

개발자가 직접 호출하면 AOP 아님

5) 부가 로직이 비즈니스 의미를 바꾸지 않아야 한다

AOP는 보조 역할이어야 한다

• 로깅

• 트랜잭션

• 인증

• 성능 측정

• 판매 가격 변경

• 도메인 규칙 추가

• 핵심 알고리즘 변경

6) 횡단 관심사(Cross-cutting Concern)여야 한다

한두 군데면 AOP 쓸 이유가 없다

• 여러 클래스

• 여러 레이어

• 반복 적용

3️⃣ ❌ AOP가 성립하지 않는 경우 (헷갈리기 쉬운 것)

4. 비유로 이해하기

🏠 아파트 방문 판매 비유

🔹 관심사 분리 (개념) - WHY

“물건 파는 일”과 “집에 들어가기 전 절차”는 서로 다른 일 → 나눠야 함

🔹 일반 공통 로직 분리 - 수동

각 집마다 내가 직접:

• 벨 누르고

• 신분 말하고

• 물건 판다

🔹 AOP - 자동/강제

어느 집을 가든:

• 문 앞에 자동 시스템이 있어서

• 벨 + 신분 확인이 자동 실행됨

• 나는 물건만 판다