관점 지향 프로그래밍 AOP

지난 포스팅에서 프로그래밍 패러다임인 객체 지향와 절차형 프로그래밍에 대해서 알아보았다. 그런데 스프링을 공부하다보면 튀어나오는 AOP, 즉 관점 지향 프로그래밍이라는 개념. 객체 지향을 알고있으니 뭔가 프로그래밍 패러다임이라는 것은 알고 있는데 정확히 관점 지향 프로그래밍은 명령형인지 선언형인지 그리고 무엇인지 도통 알 수가 없다.

AOP의 개요

---

프로그래밍 언어에서 절차적은 프로시저를 통해, 그리고 OOP는 클래스를 통해서 분리된 관심과 개념들을 통해 모듈로 분해했다. 앞선 포스팅에서 OOP를 현대에 들어 수 많이 늘어나고 복잡해진 상호작용들과 대응하기 위해서 등장한 개념이라고 설명했다. 하지만 OOP를 적용한다고 할지라도 충분히 분리해 낼 수 없는 부분이 있다는 문제 제기에서 부터 AOP의 개념이 들어서게 된다.

관점 지향 프로그래밍(Aspect Oriented Programming)

---

 

기능별로 class를 분리했음에도 불구하고 생기는 중복코드의 단점을 해결하고자 나온 방식, 공통기능과 핵심부분을 분리하여, 필요할 때에만 공통기능을 핵심부위에 넣어주는 방식

조금더 심층화해서 이를 개념화한다면 횡단 분할 기법(seperation of cross-cutting concerns)을 사용함으로써 모듈성을 증가시키는 것이 목적인 프로그래밍 패러다임이다.

횡단 분할 기법이란 OOP와 같은 모듈화가 뛰어난 방법을 사용하더라도 결코 쉽게 분리된 모듈로 작성하기 힘든 요구사항이 실제 어플리케이션 설계와 개발에서 자주 발견된다는 점이다. 이를 AOP에서는 횡단 관심이라고 한다.

기능을 핵심 비지니스 로직과 공통 모듈로 구분하고, 핵심 로직에 영향을 미치지 않고 사이사이에 공통 모듈을 효과적으로 잘 끼워넣도록 하는 개발 방법이다.

공통 모듈(보안 인증, 로깅 같은 요소등)을 만든 후에 코드 밖에서 이 모듈을 비지니스 로직에 삽입하는 것이 바로 AOP 적인 개발이다. 코드 밖에서 설정된다는 것이 핵심이다.

예를 들어 MMORPG게임을 AOP로 설계를 한다고 가정해보자. 핵심 관심, 즉 클래스 화 되어서 구현 되어야할 기술들은 아이템, 사냥, 캐릭터, 맵 등 여러 핵심 관심들이 있다. 하지만 핵심에서 살짝 벗어나 보안에 관련된 부분들 가령 매크로를 가려낸다던가 하는 부분은 필요없을까? 당연히 필요하다. 자동 판매 매크로나 자동 사냥 매크로 등 아이템이나 사냥 모듈 등 여러 핵심 관심 등에 걸쳐서 필요한 모듈이다. 또 로그 처리라던가 DB와 연동되는 것은 어떤가. 이런 부가적인 기능들까지 핵심 기술에 나눠 클래스로 작성될 수 있지만 이것들이 호출되고 사용하는 코드들이 이 핵심 모듈 안에 모두 포함시킬 수 밖에 없다. 한마디로 아이템 모듈 안에 매크로 감지 보안 모듈을 넣어놔야하고 사냥 모듈에도 매크로 감지 보안 모듈을 넣어야만 하는 번거로움과 수정 시 일일히 핵심 모듈에 대해 하나씩 해당 모듈들을 찾아 수정해야하므로 필요한 시간 낭비 등의 문제가 발생한다.

여기서 핵심 관심은 위 사진처럼 아이템, 사냥, 캐릭터 등이 될 수 있고 횡단 관심은 보안, 통계, DB 등의 그밖에 것들을 이야기한다. 이처럼 흩어진 횡단 관심사들을 Aspect로 모듈화하고 핵심 관심에서 분리하여 재사용한다는 것이 AOP의 취지이자 핵심이다.

AOP의 주요 개념

---

• Aspect(에스팩트) : 부가기능 모듈을 애스펙트라고 부름. 핵심기능에 부가되어 의미를 갖는 특별한 모듈
• Target(타겟):부가기능을 부여할 대상을 이야기함
• Advice(어드바이스) : 실질적으로 부가기능을 담은 구현체를 이야기함
• JoinPoint(조인포인트) : Advice가 적용될 위치, 다른 AOP 프레임워크와 달리 Spring에서는 메소드 조인포인트만 제공
• PointCut(포인트컷) : JoinPoint의 상세한 스펙을 정의함으로써 Advice가 실행될 지점을 정할 수 있다.

 

AOP가 사용되는 경우

---

1. 간단한 메소드 성능 검사
   개발 도중 특히 DB에 다량의 데이터를 넣고 빼는 등의 배치 작업에 대하여 시간을 측정해보고 쿼리를 개선하는 작업은 매우 의미가 있다. 이 경우 매번 해당 메소드 처음과 끝에 System.currentTimeMills();를 사용하거나, 스프링이 제공하는 StopWatch코드를 사용하기는 매우 번거롭다. 이런 경우 해당 작업을 하는 코드를 밖에서 설정하고 해당 부분을 사용하는 편이 편리하다.
2. 트랜잭션 처리
   트랜잭션의 경우 비지니스 로직의 전후에 설정된다. 하지만 매번 사용하는 트랜잭션 (try~catch부분)의 코드는 번거롭고, 소스를 더욱 복잡하게 보여준다.
3. 예외 반환
   스프링에는 DataAccessException이라는 매우 잘 정의되어 있는 예외 계층 구조가 있다. 예전 하이버네이트 예외들은 몇 개 없었고 그나마도 Uncatched Exception이 아니였다. 이렇게 구조가 별로 안 좋은 예외들이 발생했을 때, 그걸 잡아서 잘 정의되어 있는 예외 계층 구조로 변환해서 다시 던지는 애스팩트는 제 3의 프레임워크를 사용할 때, 본인의 프레임워크나 애플리케이션에서 별도의 예외 계층 구조로 변환하고 싶을 때 유용하다.
4. 아키텍처 검증
5. 기타

• 하이버네티스와 JDBC를 같이 사용할 경우, DB 동기화 문제 해결
• 멀티쓰레드 Safety 관련하여 작업해야 하는 경우, 메소드들에 일괄적으로 락을 설정하는 애스팩트
• 데드락 등으로 인한 PessimisticLockingFailureException등의 예외를 만났을 때 재시도하는 애스팩트
• 로깅, 인증, 권한 등

 

스프링 AOP의 특징

---

1. 스프링에서 AOP 구현은 접근 제어 및 부가기능을 추가하기 위해서 Proxy를 이용한다. 이 때문에 다른 AOP의 기능과 비교해서 매우 제한적인 부분만을 지원한다.
2. 스프링 내에 프록시 빈에서만 AOP를 적용 가능하다. 설정 구조 상 다른 XML기반의 AOP에 비해 복잡한 편이다.
3. 모든 AOP 기능을 제공하는 것이 아닌 스프링 IoC(제어의 역전)와 연동하여 엔터프라이즈 애플리케이션에서 가장 흔한 문제에 대한 해결책을 지원하는 것이 목적이다.

스스로에게 질문해보기

---

Q. 스프링에서 AOP를 사용해본 경험이 있나?

Q.스프링 AOP의 특징은?