일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
- 스케줄링
- 렌더링 파이프라인
- 컨디션 변수
- codility
- 다이나믹 프로그래밍
- 타입 객체
- 백준
- 다이나믹프로그래밍
- 그리디알고리즘
- 영속성
- 파일시스템 구현
- 자료구조
- 동적계획법
- DirectX 12
- 알고리즘
- 병행성 관련 오류
- 쓰레드
- Direct12
- 운영체제
- 디자인패턴
- 프로그래머스
- 멀티쓰레드
- 병행성
- 멀티프로세서
- directx
- OS
- 그리디 알고리즘
- 락
- DirectX12
- I/O장치
- Today
- Total
기록공간
AOP라는 패러다임 본문
AOP(Aspect Oriented Programming)은 흔히 '관점 지향 프로그래밍'이라는 용어로 번역되는데, 이때 '관점(Aspect)' 이라는 용어가 현실적으로 와닿지 않기 때문에 어렵게 느껴질 수 있다. '관점'이라는 용어는 개발자들에게는 '관심사(concern)'라는 말로 통용된다. '관심사'는 개발 시 필요한 고민이나 염두에 두어야 하는 일이라고 생각할 수 있는데, 코드를 작성하면서 염두에 두는 일들은 주로 다음과 같다.
- 파라미터가 올바르게 들어왔는가?
- 이 작업을 하는 사용자가 적절한 권한을 가진 사용자인가?
- 이 작업에서 발생할 수 있는 모든 예외는 어떻게 처리해야 하는가?
위와 같은 고민들은 핵심 로직은 아니지만, 코드를 온전하게 만들기 위해서 필요한 고민들인데 전통적인 방식에서는 개발자가 반복적으로 이런 고민을 코드에 반영하게 된다. AOP는 이러한 고민에 대한 문제를 조금 다른 방식으로 접근한다. AOP가 추구하는 것은 '관심사의 분리(separate concerns)'이다. AOP는 개발자가 염두에 두어야 하는 일들은 별도의 관심사로 분리하고, 핵심 비즈니스 로직만을 작성할 것을 권장한다.
이러한 관심사는 쉽게 생각하면 주변 로직과 같은 의미이다. 예를 들어 나눗셈을 구현한다고 해보자. 여기서 핵심 로직은 두 개의 숫자를 나누는 것이다. 하지만 0으로 나눌 경우 문제가 생기기 때문에 이 경우를 제외 시켜 줘야 한다. 이런것이 바로 주변 로직이다.
AOP는 과거에 개발자가 작성했던 '관심사 + 비즈니스 로직'을 분리해서 별도의 코드로 작성하도록 하고, 실행할 때 이를 결합하는 방식으로 접근한다. 즉, 개발자가 작성한 코드와 분리된 관심사를 구현한 코드를 컴파일 혹은 실행 시점에 결합시킨다. 실제 실행은 결합된 상태의 코드가 실행되기 때문에 개발자들은 핵심 비즈니스 로직에만 근거하여 코드를 작성하고, 나머지는 어떤 관심사들과 결합할 것인지를 설정하는 것 만으로 모든 개발을 마칠 수 있게 된다.
예를 들어 AOP를 이용하면 작성된 모든 메서드의 실행 시간이 얼마인지를 기록하는 기능을 기존 코드의 수정 없이도 작성할 수 있고, 잘못된 파라미터가 들어와서 예외가 발생하는 상황을 기존 코드의 수정 없이도 제어할 수 있다. 스프링이 AOP를 지원한다는 것이 스프링의 가장 중요한 특징 중에 하나인 이유 역시 복잡한 설정이나 제약 없이 스프링 내에서 간편하게 AOP의 기능을 구현할 수 있기 때문이다.
AOP 용어들
AOP를 구현하기 위해서는 다음과 같은 핵심적인 그림들을 이해할 필요가 있다.
개발자 입장에서 AOP를 적용한다는 것은 기존의 코드를 수정하지 않고도 원하는 관심사들을 엮을 수 있다는 점이다. 위 그림에서 Target에 해당하는 것이 바로 개발자가 작성한 핵심 비즈니스 로직을 가지는 객체이다.
Target은 순수한 비즈니스 로직을 의미하고, 어떠한 관심사들과도 관계를 맺고 있지 않는다. Target을 전체적으로 감싸고 있는 존재를 Proxy라고 한다. Proxy는 내부적으로 Target을 호출하지만, 중간에 필요한 관심사들을 거쳐서 Target을 호출하도록 자동 혹은 수동으로 작성된다. Proxy의 존재는 직접 코드를 통해서 구현하는 경우도 있지만, 대부분은 스프링 AOP 기능을 이용해서 자동으로 생성되는(auto-proxy) 방식으로 이용한다. JoinPoint는 Target 객체가 가진 메서드이다. 외부에서의 호출은 Proxy 객체를 통해서 Target 객체의 JoinPoint를 호출하는 방식이라고 이해할 수 있다.
그림을 통해 Advice와 JoinPoint의 관계를 좀 더 상세히 표현하면 다음과 같다.
JoinPoint는 Target이 가진 여러 메서드이다. Target에는 여러 메서드가 존재하기 때문에 어떤 메서드에 관심사를 결합할 것인지를 결정해야 하는데 이 결정을 'Pointcut'이라고 한다.
Pointcut은 관심사와 비즈니스 로직이 결합되는 지점을 결정하는 것이다. 앞의 Proxy는 이 결합이 완성된 상태이므로 메서드를 호출하게 되면 자동으로 관심사가 결합된 상태로 동작하게 된다. 관심사는 위의 그림에서 Aspect와 Advice라는 용어로 표현된다. Aspect는 관심사 자체를 의미하는 추상명사라고 볼 수 있고, Advice는 Aspect를 구현한 코드이다.
Advice는 실제 걱정거리를 분리해 놓은 코드를 의미한다. Advice는 그 동작 위치에 따라 다음과 같이 구분된다.
- Before Advice : Target과 JoinPoint를 호출하기 전 실행되는 코드. 코드의 실행 자체에 관여할 수 없다.
- After Returning Advice : 모든 실행이 정상적으로 이루어 진 후에 동작하는 코드
- After Throwing Advice : 예외가 발생한 뒤에 동작하는 코드
- After Advice : 정상적으로 실행되거나 예외가 발생했을 때 구분 없이 실행되는 코드
- Around Advice : 메서드의 실행 자체를 제어할 수 있는 가장 강력한 코드. 직접 대상 메서드를 호출하고 결과나 예외를 처리할 수 있다.
과거 스프링에서는 별도의 인터페이스로 구현되고, 이를 클래스로 구현하는 방식으로 제작했지만 스프링 3버전 이후에는 어노테이션만으로도 모든 설정이 가능하다. Target에 어떤 Advice를 적용할 것인지는 XML을 이용한 설정을 이용할 수 있고, 어노테이션을 이용하는 방식을 이용할 수 있다.
Pointcut은 Advice를 어떤 JoinPoint에 결합할 것인지를 결정하는 설정이다. AOP에서 Target은 결과적으로 Pointcut에 의해서 자신에게는 없는 기능들을 가지게 된다. Pointcut은 다양한 현태로 사용할 수 있는데 주로 사용되는 설정은 다음과 같다.
- execution(@execution) : 메서드를 기준으로 Pointcut을 설정
- within(@within) : 특정한 타입(클래스)을 기준으로 Pointcut을 설정
- this : 주어진 인터페이스를 구현한 객체를 대상으로 Pointcut을 설정
- args(@argsㅠ: 특정한 파라미터를 가지는 대상들만을 Pointcut으로 설정
- @annotation : 특정한 어노테이션이 적용된 대상들만을 Pointcut으로 설정
'BackEnd > Spring' 카테고리의 다른 글
RedirectAttributes (0) | 2021.03.16 |
---|---|
[Spring 에러] Unable to find Log4j2 as default logging library. (0) | 2021.03.12 |
servlet-context.xml, root-context.xml, web.xml 차이점 (0) | 2021.03.11 |
[Spring 에러] @GetMapping, @PostMapping 등 어노테이션 import 에러 (0) | 2021.03.11 |
스프링 MVC 프로젝트의 기본 구성 (0) | 2021.03.09 |