스프링 AOP(Aspect Oriented Programing)
스프링의 핵심 철학 '비침투성'
스프링은 EJB 같은 무거운 프레임워크가 주류이던 시절에 등장했습니다. 여기서 말하는 EJB는 Spring 이전에 주로 사용되던 자바 엔터프라이즈 애플리케이션 프레임워크입니다.
그때의 프레임워크들은 다음과 같은 문제가 있었습니다.
- 도메인 로직이 프레임워크 코드와 강하게 결합
- 비즈니스 로직을 작성하려 해도, 상속 구조나 라이프사이클에 제약을 받아야 했음
- 테스트하려면 컨테이너를 띄워야만 가능
스프링 창시자인 Rod Johnson은 이 문제를 해결하고자 스프링을 설계하면서 이런 철학을 전면에 내세웠습니다.
"J2EE should not invade your domain model. Your domain model should be free of framework dependencies.”
- 스프링 창시자 Rod Johnson 《Expert One-on-One J2EE Development without EJB》(2004)
이 말은 곧, 기술적인 제약과 비즈니스 로직을 분리하는 것이 스프링의 핵심 철학 중 하나라는 의미입니다.
스프링은 이를 실현하기 위해 비침투성(Non-Invasiveness)을 중요한 설계 원칙으로 삼았습니다.
비침투성(Non-Invasiveness)이란?
프레임워크나 기술 스택의 흔적이 비즈니스 로직에 드러나지 않도록 설계하는 것
즉, 도메인 객체나 서비스 로직은 스프링의 API에 의존하지 않고, 순수하게 비즈니스 로직만을 담고 있어야 합니다.
이 철학이 지금의 PSA, DI, AOP 구조로 이어졌습니다. 이 3가지 중에서 AOP에 대해서 얘기해보겠습니다.
비즈니스 로직과 부가 기능, 어떻게 분리할 수 있을까?
어떤 서비스 클래스에 doSomething()이라는 메서드가 있다고 가정해보겠습니다.
이 메서드는 특정한 작업을 처리하는 핵심 비즈니스 로직입니다.
그런데 어느 날, 새로운 요구사항이 들어옵니다.
"이 메서드가 실행되는 시간을 로그로 남겨주세요."
이를 만족시키기 위해 timeCheck() 같은 메서드를 만들어 시간 측정을 할 수 있습니다.
public void timeCheck() {
Stopwatch stopwatch = Stopwatch.createStarted();
doSomething();
stopwatch.stop();
log.info("실행 시간: " + stopwatch.elapsed(MILLISECONDS));
}
비즈니스 로직을 감싸는 방식으로 시간 측정 코드를 작성하는 것이죠.
하지만 이후에 또 다른 메서드 doSomething_2()에도 같은 요구사항이 생긴다면,
그때마다 새로운 timeCheck_2() 같은 메서드를 만들어야 할까요?
이런 방식의 문제점은?
- 메서드 수가 늘어날수록 중복되는 코드가 많아짐
- 비즈니스 로직과 부가 기능이 뒤섞여 코드가 지저분해짐
- 로깅 형식을 바꾸려면 모든 곳을 일일이 수정해야 함
이런 문제를 해결할 수 있는 대표적인 방법 중 하나가 바로 AOP(Aspect Oriented Programming, 관점 지향 프로그래밍)입니다.
AOP가 무엇인가요?
AOP는 공통 기능(로깅, 보안, 트랜잭션 등)을 비즈니스 로직과 분리해,
재사용 가능하고 깔끔하게 관리할 수 있도록 해주는 프로그래밍 방식입니다.
AOP를 적용하면, 클래스 내부에는 핵심 로직만 남기고,
부가적인 기능들은 별도의 Aspect로 분리할 수 있게 됩니다.
그래서 AOP는 흔히 횡단 관심사(Cross-Cutting Concerns)를 처리한다고 표현하기도 합니다.
AOP의 핵심 용어 정리
용어 | 설명 |
Aspect | 부가 기능을 모듈화한 단위. (ex. 시간 측정, 트랜잭션, 로깅 등) |
Advice | 실제로 실행되는 코드. Aspect 내부의 메서드라고 보면 됨 |
Join Point | Advice가 적용될 수 있는 지점. 스프링 AOP에선 주로 메서드 실행 시점 |
PointCut | 어떤 Join Point에 Advice를 적용할지 결정하는 규칙 |
Target | Advice가 적용되는 실제 객체 또는 메서드 |
AOP Proxy | 스프링이 런타임에 생성하는 프록시 객체로, Advice를 래핑한 후 Target을 호출 |
Weaving | Aspect를 실제 코드에 적용하는 과정 |
Introduction | AOP를 통해 기존 클래스에 새로운 메서드나 필드를 추가하는 기능 (Spring에서는 제한적 사용) |
정리
AOP는 스프링 프레임워크가 제공하는 매우 강력한 기능 중 하나입니다.
비즈니스 로직과 반복적인 부가 기능을 분리하여, 코드의 가독성, 유지보수성, 재사용성을 크게 향상시킬 수 있습니다.
앞으로는 AOP를 활용해 Spring Boot 애플리케이션에서
직접 시간 측정, 로깅, 트랜잭션 등을 구현해보는 실습을 진행할 예정입니다.
'Dev Framework > Spring' 카테고리의 다른 글
[Spring] @Configuration과 CGLIB 프록시 마법 (0) | 2025.04.01 |
---|---|
[Spring] HttpServlet 완벽 정리 (0) | 2025.03.31 |
[JPA] JPA 영속성 컨텍스트 with 프록시 - 2 (0) | 2025.03.23 |
[JPA] JPA 영속성 컨텍스트 완전 정복 - 1 (0) | 2025.03.23 |
[SpringBoot] Lombok 사용 시 부모 생성자 호출 문제와 해결 방안 (0) | 2024.05.15 |
스프링 AOP(Aspect Oriented Programing)
스프링의 핵심 철학 '비침투성'
스프링은 EJB 같은 무거운 프레임워크가 주류이던 시절에 등장했습니다. 여기서 말하는 EJB는 Spring 이전에 주로 사용되던 자바 엔터프라이즈 애플리케이션 프레임워크입니다.
그때의 프레임워크들은 다음과 같은 문제가 있었습니다.
- 도메인 로직이 프레임워크 코드와 강하게 결합
- 비즈니스 로직을 작성하려 해도, 상속 구조나 라이프사이클에 제약을 받아야 했음
- 테스트하려면 컨테이너를 띄워야만 가능
스프링 창시자인 Rod Johnson은 이 문제를 해결하고자 스프링을 설계하면서 이런 철학을 전면에 내세웠습니다.
"J2EE should not invade your domain model. Your domain model should be free of framework dependencies.”
- 스프링 창시자 Rod Johnson 《Expert One-on-One J2EE Development without EJB》(2004)
이 말은 곧, 기술적인 제약과 비즈니스 로직을 분리하는 것이 스프링의 핵심 철학 중 하나라는 의미입니다.
스프링은 이를 실현하기 위해 비침투성(Non-Invasiveness)을 중요한 설계 원칙으로 삼았습니다.
비침투성(Non-Invasiveness)이란?
프레임워크나 기술 스택의 흔적이 비즈니스 로직에 드러나지 않도록 설계하는 것
즉, 도메인 객체나 서비스 로직은 스프링의 API에 의존하지 않고, 순수하게 비즈니스 로직만을 담고 있어야 합니다.
이 철학이 지금의 PSA, DI, AOP 구조로 이어졌습니다. 이 3가지 중에서 AOP에 대해서 얘기해보겠습니다.
비즈니스 로직과 부가 기능, 어떻게 분리할 수 있을까?
어떤 서비스 클래스에 doSomething()이라는 메서드가 있다고 가정해보겠습니다.
이 메서드는 특정한 작업을 처리하는 핵심 비즈니스 로직입니다.
그런데 어느 날, 새로운 요구사항이 들어옵니다.
"이 메서드가 실행되는 시간을 로그로 남겨주세요."
이를 만족시키기 위해 timeCheck() 같은 메서드를 만들어 시간 측정을 할 수 있습니다.
public void timeCheck() {
Stopwatch stopwatch = Stopwatch.createStarted();
doSomething();
stopwatch.stop();
log.info("실행 시간: " + stopwatch.elapsed(MILLISECONDS));
}
비즈니스 로직을 감싸는 방식으로 시간 측정 코드를 작성하는 것이죠.
하지만 이후에 또 다른 메서드 doSomething_2()에도 같은 요구사항이 생긴다면,
그때마다 새로운 timeCheck_2() 같은 메서드를 만들어야 할까요?
이런 방식의 문제점은?
- 메서드 수가 늘어날수록 중복되는 코드가 많아짐
- 비즈니스 로직과 부가 기능이 뒤섞여 코드가 지저분해짐
- 로깅 형식을 바꾸려면 모든 곳을 일일이 수정해야 함
이런 문제를 해결할 수 있는 대표적인 방법 중 하나가 바로 AOP(Aspect Oriented Programming, 관점 지향 프로그래밍)입니다.
AOP가 무엇인가요?
AOP는 공통 기능(로깅, 보안, 트랜잭션 등)을 비즈니스 로직과 분리해,
재사용 가능하고 깔끔하게 관리할 수 있도록 해주는 프로그래밍 방식입니다.
AOP를 적용하면, 클래스 내부에는 핵심 로직만 남기고,
부가적인 기능들은 별도의 Aspect로 분리할 수 있게 됩니다.
그래서 AOP는 흔히 횡단 관심사(Cross-Cutting Concerns)를 처리한다고 표현하기도 합니다.
AOP의 핵심 용어 정리
용어 | 설명 |
Aspect | 부가 기능을 모듈화한 단위. (ex. 시간 측정, 트랜잭션, 로깅 등) |
Advice | 실제로 실행되는 코드. Aspect 내부의 메서드라고 보면 됨 |
Join Point | Advice가 적용될 수 있는 지점. 스프링 AOP에선 주로 메서드 실행 시점 |
PointCut | 어떤 Join Point에 Advice를 적용할지 결정하는 규칙 |
Target | Advice가 적용되는 실제 객체 또는 메서드 |
AOP Proxy | 스프링이 런타임에 생성하는 프록시 객체로, Advice를 래핑한 후 Target을 호출 |
Weaving | Aspect를 실제 코드에 적용하는 과정 |
Introduction | AOP를 통해 기존 클래스에 새로운 메서드나 필드를 추가하는 기능 (Spring에서는 제한적 사용) |
정리
AOP는 스프링 프레임워크가 제공하는 매우 강력한 기능 중 하나입니다.
비즈니스 로직과 반복적인 부가 기능을 분리하여, 코드의 가독성, 유지보수성, 재사용성을 크게 향상시킬 수 있습니다.
앞으로는 AOP를 활용해 Spring Boot 애플리케이션에서
직접 시간 측정, 로깅, 트랜잭션 등을 구현해보는 실습을 진행할 예정입니다.
'Dev Framework > Spring' 카테고리의 다른 글
[Spring] @Configuration과 CGLIB 프록시 마법 (0) | 2025.04.01 |
---|---|
[Spring] HttpServlet 완벽 정리 (0) | 2025.03.31 |
[JPA] JPA 영속성 컨텍스트 with 프록시 - 2 (0) | 2025.03.23 |
[JPA] JPA 영속성 컨텍스트 완전 정복 - 1 (0) | 2025.03.23 |
[SpringBoot] Lombok 사용 시 부모 생성자 호출 문제와 해결 방안 (0) | 2024.05.15 |