[토비의 스프링 3.1 Vol.1] 6장 AOP

  [사족]

  토비의 스프링을 접한 이후로 7년만에 처음 펴보는 장이 아닌가 싶다. 생각보다 분량도 많고(약 150페이지) 쉬운 내용이 아니라 읽는데 오래 걸렸다. DI/IoC, 서비스 추상화와 더불어 스프링의 3대 핵심으로 불리우는 AOP이다. Transactional을 대충 갖다 쓰는것과 원리와 처리 과정 등을 명확히 아는 것에는 정말 차이가 있다고 느껴졌다.

 

  [내용]

  6장의 목차

6.1 트랜잭션 코드의 분리

6.2 고립된 단위 테스트

6.3 다이내믹 프록시와 팩토리 빈

6.4 스프링의 프록시 팩토리 빈

6.5 스프링 AOP

6.6 트랜잭션 속성

6.7 애노테이션 트랜잭션 속성과 포인트컷

6.8 트랜잭션 지원 테스트

6.9 정리

 

  5장까지 서비스 추상화 기법을 도입해서 데이터 엑세스 기술에 독립적으로 깔끔하게 코드를 개선시켰다. 하지만 여기서 한 가지 문제가 생겼는데 바로 데이터 엑세스 로직과 트랜잭션 로직이 한데 묶이게 되었다. 어떻게 하면 비즈니스로직과 트랜잭션 로직을 깔끔하게 분리할 수 있을까?

  첫 번째로 할 수 있는 것은 전략패턴을 이용한 로직의 분리이다. 기존의 UserService를 인터페이스로 두고, UserServiceImpl에 비즈니스 로직을, UserServiceTx에 트랜잭션을 적용할 클래스를 만든다. 그러면 요청은 UserService로 받고 UserSerivceTx에서 트랜잭션을 적용 한 뒤, 위임을 통해 UserServiceImpl에서 실제 기능을 수행하면 된다. 하지만 여기에도 단점들이 존재한다. 일일히 하나의 인터페이스에 트랜잭션용 클래스를 새로 만들고 또 거기에서 일일히 위임까지 시켜줘야 한다. 기능이 하나 늘어날 때마다, Tx클래스에도 추가해주어야 한다. 상당히 번거롭고 한치의 실수도 용납되어서는 안되는 작업이다.

  두 번째로 할 수 있는 것은 다이내믹 프록시를 활용하는 것이다. 여기서 잠깐 데코레이터 패턴과 프록시 패턴에 대해 짚고 넘어가자.

• 데코레이터 패턴: 타깃에 부가적인 기능을 런타임 시에 다이내믹하게 부여해줌. 여러 층을 활용해 많은 기능을 확장 또는 추가할 수 있음(p.431)
• 프록시 패턴: 타깃의 기능을 확장하거나 추가하지 않음. 대신 클라이언트가 타깃에 접근하는 방식을 변경(p. 433)

다이내믹 프록시는 프록시 팩토리에 의해 런타임 시 다이내믹하게 만들어지는 오브젝트다. 리플렉션을 이용해 공통적인 부분을 뽑아내서 트랜잭션을 적용하고 실제 기능을 하는 메소드를 invoke 시킬 수 있다. 여기에도 단점들이 등장한다. 비슷한 설정들이 오브젝트마다 추가해주어야 한다는 점이다.

  세 번째로 할 수 있는 것은 스프링의 ProxyFactoryBean을 사용하는 것이다. 이것을 활용하면 타깃 오브젝트마다 새 인스턴스가 생기는 문제를 해결 할 수 있다. 하지만 부가기능이 필요한 곳마다 ProxyFactoryBean 설정을 추가해 주어야 한다. 이것 또한 불편한 일이 아닐 수 없다.

  여기서 이제 AOP가 등장한다. 

이렇게 애플리케이션의 핵심적인 기능에서 부가적인 기능을 분리해서 애스펙트라는 독특한 모듈로 만들어서 설계하고 개발하는 방법을 애스펙트 지향 프로그래밍(Aspect Oriented Programming)또는 약자로 AOP라고 부른다. 이름만 들으면 마치 OOP가 아닌 다른 프로그래밍 언어 또는 패러다임이라고 느껴지지만, AOP는 OOP를 돕는 보조적인 기술이지 OOP를 완전히 대체하는 새로운 개념은 아니다. ... AOP는 애스펙트를 분리함으로써 핵심기능을 설계하고 구현할 때 객체지향적인 가치를 지킬 수 있도록 도와주는 것이라고 보면 된다. (p. 505)

스프링의 AOP는 프록시를 사용한 AOP이다. AOP에 관한 용어들은 위키나 책을 참고하자.