본문 바로가기
Study/Software Engineering

AOP 란 무엇인가?

by SeulKom 2009. 8. 5.

Contents
1. 정의
2. 등장 배경
3. Crosscutting Concerns
4. Concern 분리
5. Crosscutting Concern 모듈화 순서 (AspectJ 예)
6. Weaving 방법 분류
7. 장점







1. 정의

AOP는 Aspect-Oriented Programming 의 약자로 관점 지향 프로그래밍이라 한다.
AOSD (Aspect-Oriented Software Development) 의 한 측면을 표현한다.




2. AOP 등장배경

절차지향 프로그래밍 →
객체지향 프로그래밍 (OOP) : 유지보수성과 확장성 &
관점지향 프로그래밍 (AOP) : 객체지향적인 프로그래밍을 지향하면서 유지보수를 좀 더 편리하게 하기 위한 방법

컴포넌트계의 구루(guru)들이 이야기하는 중요한 사항은 '재사용' 보다는 급변하는 비즈니스로 인한 요구사항의 변화에 탄력적으로 대응할 수 있는 '변화가 쉬운 컴포넌트 구조'라고 이야기하고 있다.

이런 측면에서 봤을 때 코드 변화가 쉬운 구조를 만들어야 하는데, 코드 중복 구조 문제가 생기면 코드 변화가 어려워 진다. 클래스의 이곳저곳에 흩어져 있는 정보들로 인해 코드 중복 구조가 발생하는 문제가 생긴다.* 코드 중복은 간결성을 해침으로써 코드의 구조와 의미를 불명확하게 만들며, 여기저기 흩어져 있는 코드의 구조를 이해하려면 코드 전체를 모두 봐야 하는 문제가 생기며 이로 인해 무엇보다도 코드 변화가 어려워진다는 사실이다.

* XP (Extreme Promgramming) 에서는 'Once and Only Once' 라 하고
  리팩토링 (Refactoring) 에서는 '중복 코드 (Duplicate Code' 의 냄새가 난다고 표현한다.

OOP를 사용하다 보면 inter-object message가 너무 많아 코드 변경이 어렵고, 그로 인해 코드 재사용이 불가능한 경우가 발생한다. 이를 해결 하기 위해 AOP가 생겨났다.

AOP로 만들어낼 수 있는 모든 기능은 OOP로 할 수 있는 것들이다. 하지만 OOP만으로는 객체지향 원칙에 타협을 해야 할 수 밖에 없기 때문에 AOP를 사용하는 것이 훨씬 유리한 선택일 것이다.




OOP 원칙을 지키지 못하였을 경우 생기는 결과

  - 분산 (Scattering) : 하나의 기능을 하나의 모듈로 캡슐화하기 불가능하여 여러 모듈에 분산되어 코드가 반복적으로 나타남.  분산된 기능의 코드는 유지보수를 힘들게 한다. 분산된 코드에 침범 당한 모듈은 의존성이 강해지기 때문.

  - 혼란 (Tangling) : 여러 개의 모듈에 분산, 중복되어 있어 모듈화가 불가능한 코드들은 각 모듈의 코드 자체를 혼란에 빠드리게 된다. (직접적인 연관성의 기능이 뒤엉켜 지저분한 코드가 되어 버린다. - 다양한 기능이 뒤엉킴)   두 concern 이상이 한 모듈에 포함되는 현상. 주로 개발하는 시스템의 핵심 로직을 담은 핵심 도메인 로직과는 다른 차원에 존재하면서 도메인 오브젝트에 분산되어 존재할 수 밖에 없는 것들이다.  (e.g., Tracing, Logging, Error and Exception handling, Monitoring. Statistic gathering, Transaction, Session Management, Threading, Synchronization, Caching, Remote access) 

- Nonfunctional concerns





3. Crosscutting Concerns

복잡도가 높은 시스템일 수록 다양한 Concern 이 존재한다. 동기화, 예외, 에러처리, 보안, 지속성(Transaction), 자원 공유, 분산, 메모리 관리, 로깅* 등이 Concern 의 예가 될 수 있다.

   * Logging : 업데이트를 실시간으로 처리하지 않고 한꺼번에 모아 해결 할 때, 로그 형식으로 기록 후 처리



그림1. 한 모듈에서 Concern들의 예



불행히도 이러한 시스템 속성들은 한 두개의 클래스에 지역화되지 않고 시스템을 구성하는 모듈의 여기저기에 흩어져 있는 경향이 있다는 것이다. 이러한 현상을 crosscutting concerns 라고 한다. 현재는 crosscutting concer을 과거에 비해 많이 줄인 상황이다. (지속성-Transaction에 관한 구현 메커니즘을 지역화하는데 성공했으며, SocketImpl과 SocketImplFactory를 이용해 직접 제작한 소켓 사용에 대한 시스템 속성, 즉 분산 메커니즘의 구현을 지역화 했다. 그 외에도 여러 concern을 모듈화 하는데 성공했다.)




그림2. Crosscutting concerns (세로) 과 Core concerns (가로)



Crosscutting concern 의 문제점

1. 코드 변경이 어렵다.
2. 분업이 어렵게 된다.
3. 코드의 가독성이 떨어진다.

용어
횡단 관심(Crosscutting concerns) : 쉽게 분리된 모듈로 작성하기 힘든 요구사항
핵심 관심(Core concerns) : 해당 시스템의 핵심 가치와 목적이 그대로 드러난 관심 영역




4. Concern 분리

그림1 은 AOP로 개발하지 않았을 때의 일반적인 현상이다. 현재까지 대부분의 프로젝트에서 발생하는 것으로 비지니스 로직을 고민할 코드에서 Persitence(Transaction), Security, Logging등을 모두 고민해야 한다. 소스코드 또한 이러한 Concern들을 동시에 해결할 수 있도록 구현한다.


그림3. Concern의 분리

이와 같은 개발환경하에서 AOP의 의도는 각 Concern들을 찾아 분리한 다음 별도의 코드에서 구현하자는 것이다. 위 그림처럼 Concern Identifier과정을 거쳐 Concern들을 분리한 다음 각 기능들을 별도로 구현한다. 이와 같인 Concern들을 별도로 구현한 것을 하나의 Aspect라고 한다.


그림4. 분리된 여러 Concern들을 핵심 비지니스 로직과 결합

이렇게 별도로 구현되어 있는 Aspect들이 최종적으로는 핵심 비지니스 로직과 결합하여 작동해야 한다. 위 그림에서 보는 바와 같이 각 Concern별로 구현되어 있는 것을 Weaving 작업을 통하여 핵심 비지니스 로직에 통합하여 실행하는 방법이다.

Crosscutting Concern을 분리 했을 때 장점
1. 개발이 빨라진다. (개발인력간의 상호의존도가 떨어지므로)
2. 변화가 쉽다. (해당 모듈만 수정하면 되므로)
3. 코드 가독성이 증가한다. (다른 모듈을 볼 필요가 없으므로)
4. 시스템의 안정성이 증가
5. 시스템 성능이 향상




5. Crosscutting concern 모듈화 순서

  a. Define join points
  Join point 는 어떠한 연산이 발생하는 지점을 뜻한다. AspectJ 에서는 method와 생성자 호출, 실행, 초기화, 예외 처리, 필드 참조, 정적 초기화 등의 여러 지점을 정의하고 있다.
  Point cut 은 Designator로 Join point 들을 정의한다.


  b. Write the cross-cutting concern
  Java의 클래스와 유사한 aspect를 정의 함으로써 Crosscutting Concern을 만들 수 있다.
  프로그램 수행중에 Pointcut 에 의해 지정된 Joint point 에 다다랐을 때 어떤 부가적인 작업을 수행할지 수행 코드를 정의하는 Advice 가 존재한다. Advice 은 before(실행 전), after(실행 후), around(실행을 대체해서) 의 3가지 방식이 존재하며, Pointcut과 advice 등을 캡슐화하는 단위로 자바의 클래스에 해당하는 Aspect 를 지정한다.


  c. Compile and test
  AOP로 구현된 code를 기존에 존재하는 code와 통합시킨 후 컴파일 하여 제대로 동작하는지 확인한다.
  pointcut 에 의해서 결정된 join point에 지정된 advice를 삽입하는 과정을 Weaving 이라 한다. AOP가 기존의 핵심 관심 모듈의 코드에 전혀 영향을 주지 않으면서 필요한 Crosscutting concern을 추가할 수 있게 해주는 핵심적인 처리 과정이다.




6. AOP Weaving 방식

  a. 컴파일시 Weaving
  초기에는 AspectJ가 지원하는 컴파일러를 통해 컴파일을 해야 한다는 제약에 따라 point cut 변경에 따른 관련된 모든 클래스를 매번 재컴파일을 해야하는 문제점이 있었지만 최근 IDE 툴이 지원되면서 대표적인 AOP 지원툴로 자리매김 하였다. (AspectJ 방식)

  b. 클래스 로딩시 Weaving
 JVM이 클래스를 로딩할 때 클래스 정보를 변경할 수 있는 에이전트를 제공함으로써 클래스의 바이너리 정보를 변경하여 알맞은 위치에 공통 코드를 삽입한 새로운 클래스 바이너리 코드를 사용하도록 한다. 즉, 원본 클래스 파일은 변경하지 않고 클래스를 로딩할 때 JVM이 변경 한 바이트 코드를 사용한다. (AspectWerkz 방식)

  c. 런타임식 Weaving
  소스코드나 클래스를 변경하지 않고 프록시를 이용해 AOP를 적용한다. 즉, 기존 코드에 속한 객체에 직접 접근하지 않고 중간에 공통코드가 적용된 프록시를 생성하여 접근한다. 단점은 기존 코드를 실행하기 전/후의 join point 만 적용 가능하며, 필드값 변경 같은 join point에 대해서는 적용이 불가능 하다. (Spring AOP 방식)




7. AOP의 장점
  a. 중복되는 코드 제거
  b. Unit testing 의 편의성
  c. 유지보수성 향상



더 자세한 것은

- John Cheesman, John Daniels, "UML, Components", Addision-Wesley (CBD 설명)

- Steve Mcconnell, "Code Complete", Microsoft Press (구조적 프로그래밍의 패러다임)

- Erich Gamma, Richard Helm, Ralph Johnson, John Vissides, "Design Patterns", Addision-Wesley

- Martin Fowler, Kent Beck, John Brant, Wiliam Opdyke, don Roberts, "Refactoring", Addision-Wesley

- Kent Beck, "Extreme Programming Explained", Addison-Wesley

- Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, Michael Stal, "Pattern-Oriented Software Architecture(POSA) Volume 1", Addison-Wesley (Layer 패턴, 아키텍처 패턴)

- Douglas Schmidt, Michael Stal, Hans Rohnert, Frank Buschmann, "Pattern Oriented Software Architecture(POSA) Volume 2", Addision-Wesley (네트워크, 동시성을 지닌 객체지향 미들웨어를 개발하기 위한 Pattern Language)


- Ramnivas Laddad, "Aspect In Action", Manning (2003)

- Rod Johnson, "One-to-one J2EE Development without EJB", Wrox (2004)

- The AspectJ Project, http://www.eclipse.org/aspectj/

- Spring 2.0 reference manual,
   http://static.springframework.org/spring/docs/2.0.x/reference/index.html 

- AOP@Work: AOP myth and realities,
   http://www-128.ibm.com/developerworks/java/library/j-aopwork15/

- Introduction to Practical AspectJ Programming, SpringOne 2006

- Avoing AOP pitfalls. The Spring Experience 2006

- AspectJ for Spring Developer. The Spring Experience 2006




Reference
[1] http://blog.naver.com/jiruchi?Redirect=Log&logNo=10030863709
[2] Gary Pollice, "A look at aspect-oriented programming", IBM the Rational edge , 200 , http://www-106.ibm.com/developerworks/rational/library/2782.html
[3] 박재성, "Spring 프레임워크를 이용한 효율적인 개발 전략 1차 오픈 스터디", http://www.javajigi.net/pages/viewpage.action?pageId=280
[4] Ramnivas Laddad, JavaWorld.com, "Separate software concerns with aspect-oriented programming". http://www.javaworld.com/javaworld/jw-01-2002/jw-0118-aspect.html?page=1
[5] 박성운, 특집3-1 | 개발자를 똑똑하게 만드는 새로운 대안, AOP - AOP를 통해 바라본 Separation of Concerns, 마이크로소프트웨어 2001년 12월호
반응형

댓글5