Aspect-Oriented Programming in Java

본 글은 Markus Voelter에 의해 작성된 글 중 일부이다. 원문은 AOP 기본 개념, Xerox
PARC에 의해 구현된 Java의 AOP 확장 버전인 AspectJ 소개, Metaclass 프로그래밍과의 비교 등 총 3 파트로 구성되어 있으며, 번역문은 이 중 첫 번째 파트만 커버한다. 참고로 원문의 AspectJ 관련 코드는 상당히 오래된 문법에 기반하여 현재의 그것과 많은 차이를 보인다.

Introduction

최근 몇 년에 걸쳐 객체지향 프로그래밍(Object-Oriented Programming, OOP)은 절차적 방법론을 거의 완벽히 대체하며 프로그래밍 방법론의 새 주류로 떠오르게 되었다. 객체지향적 방식의 가장 큰 이점 중 하나는 소프트웨어 시스템이 여러 개의 독립된 클래스들의 집합으로 구성된다는 것이다. 이들 각각의 클래스들은 잘 정의된 고유 작업을 수행하게 되고, 그 역할 또한 명백히 정의되어 있다. 객체지향 어플리케이션에서는 어플리케이션이 목표한 동작을 수행하기 위해 이런 클래스들이 서로 유기적으로 협력하게 된다. 하지만 시스템의 어떤 기능들은 특정 한 클래스가 도맡아 처리할 수 없다. 이들은 시스템 전체를 들쑤시며 해당 코드들을 여러 클래스들에 흩뿌려 놓는다. 이런 현상을 횡단적(cross-cutting)이라 표현한다. 분산 어플리케이션에서의 락킹(locking, 동기화) 문제, 예외 처리, 로깅 등이 그 예이다. 물론 필요한 모든 클래스들에 관련 코드를 집어 넣으면 해결될 문제이다. 하지만 이런 행위는 각각의 클래스는 잘 정의된(well-defined) 역할만을 수행한다
는 기본 원칙에 위배된다. 이런 상황이 바로 Aspect-Oriented Programming (AOP)이 잉태된 원인이 되었다.
AOP에서는 aspect라는 새로운 프로그램 구조를 정의해 사용한다. 이는 쉽게 struct, class, interface 등과 같이 특정한 용도의 구조라 생각하면 된다. Aspect 내에는 프로그램의 여러 모듈들에 흩어져 있는 기능(하나의 기능이 여러 모듈에 흩어져 있음을 뜻한다)을 모아 정의하게 된다. 전체적으로, 어플리케이션의 각각의 클래스는 자신에게 주어진 기능만을 수행하고, 추가된 각 aspect들이 횡단적인 행위(기능)들을 모아 처리하며 전체 프로그램을 이루는 형태가 만들어진다.

AOP Basics

이해를 돕기 위해, 그리고 설명을 쉽게 하기 위해 예를 들어가며 AOP 개념을 설명토록 하겠다. 어플리케이션의 여러 스레드들이 하나의 데이터를 공유하는 상황을 가정해보자. 공유 데이터는 Data라는 객체(Data 클래스의 인스턴스)로 캡슐화되어 있다. 서로 다른 여러 클래스의 인스턴스들이 하나의 Data 객체를 사용하고 있으나 이 공유 데이터에 접근할 수 있는 객체는 한 번에 하나씩이어야만 한다. 그렇다면 어떤 형태이건 동기화 메커니즘이 도입되어야 할 것이다. 즉, 어떤 한 객체가 데이터를 사용중이라면 Data 객체는 잠겨(lock)져야 하며, 사용이 끝났을 때 해제(unlock)되어야 한다. 전통적인 해결책은 공유 데이터를 사용하는 모든 클래스들이 하나의 공통 부모 클래스("worker" 라 부르도록 하자)로부터 파생되는 형태이다. worker 클래스에는 lock()과 unlock() 메소드를 정의하여 작업의 시작과 끝에 이 메소드를 호출토록 하면 된다. 하지만 이런 형태는 다음과 문제들을 파생시킨다.

• 공유 데이터를 사용하는 메소드는 상당히 주의해서 작성되어야 한다. 동기화 코드를 잘못 삽입하면 데드락(dead-lock)이 발생하거나 데이터 영속성이 깨질 수 있다. 또한 메소드 내부는 본래의 기능과 관련 없는 동기화 관련 코드들로 더럽혀질 것이다.
• Java와 같은 단일 상속 모델에서는 worker를 만든다는 것이 불가능할 수 있다. 어떤 클래스들은 이미 다른 클래스들로부터 확장되었을 수도 있기 때문이다. 이는 특히 클래스 계층 구조 설계가 마무리된 후, 뒤늦게 동기화의 필요성을 깨달았을 때 흔히 발생한다. 동기화를 신경 쓰지 않은 범용 클래스 라이브러리를 통해 공유 데이터에 접근하려 하는 경우가 한 예가 될 수 있다.
• 재활용성(reusability)이 감소된다. worker 클래스는 동기화가 필요치 않는 클래스나 심지어 다른 동기화 메커니즘이 필요한 상황에서도 사용하길 원할 수 있다. 동기화 관련 코드를 삽입함으로써 worker 클래스는 특정 어플리케이션에 종속적인 클래스로 전락하게 된다.

우리가 앞서 가정한 어플리케이션에서 동기화 개념은 다음과 같은 속성들을 갖는다.

• 동기화는 worker 클래스에 할당된 최우선 작업이 아니다.
• 동기화 메커니즘은 worker 클래스의 최우선 작업과 독립적이다.
• 한 객체에 대한 동기화 관련 코드가 시스템 전체에 횡단적으로 존재한다. 다수의 클래스와 더 많은 수의 메소드들이 이 동기화 메커니즘에 영향 받는다.

AOP에서는 이런 형태의 문제를 해결하기 위해 새로운 형태의 접근 방법을 제기하고 있다. AOP는 새로 도입된 프로그램 구조를 통해 시스템에 횡단되어 있는 기능들을 정의해 처리하도록 했다. 이 새로운 구조를 우리는 aspect라 부른다.

우리의 예에 Lock이라는 aspect를 도입해보자. Lock aspect는 다음과 같은 역할이 할당될 것이다.

• Data 객체를 사용하는 클래스들을 위해 lock 및 unlock 메커니즘을 제공한다(lock(), unlock()).
• Data 객체를 수정하는 모든 메소드들이 수행 전에 lock()을 호출하고, 수행 후에는 unlock()을 호출함을 보장한다.
• 이상의 기능을 Data 객체를 사용하는 클래스의 자바 소스를 변경하지 않고 투명하게 수행한다.

Aspect는 또 어떤 일들을 수행할 수 있을까?

특정 메소드(ex. 객체 생성 과정 추적) 호출을 로깅할 경우 aspect가 도움이 될 수 있다. 기존 방법대로라면 log() 메소드를 만들어 놓은 후, 자바 소스에서 로깅을 원하는 메소드를 찾아 log()를 호출하는 형태를 취해야할 것이다. 여기서 AOP를 사용하면 원본 자바 코드를 수정할 필요 없이 원하는 위치에서 원하는 로깅을 수행할 수 있다. 이런 작업 모두는 aspect라는 외부 모듈에 의해 수행된다.
또 다른 예로 예외 처리가 있다. Aspect를 이용해 여러 클래스들의 산재된 메소드들에 영향을 주는 catch() 조항(clause)을 정의해 어플리케이션 전체에 걸친 지속적이고 일관적으로 예외를 처리할 수 있다.

그렇다면 두 가지 의문이 떠오를 것이다.

먼저 'Aspect는 꼭 필요한가?''' 질문에 답해보자. 물론 그렇지는 않다. 이상에서 언급한 모든 문제들은 aspect 개념 없이 해결될 수 있다. 하지만 aspect는 새롭고 고차원적인 추상 개념을 제공해 소프트웨어 시스템의 설계 및 이해를 보다 쉽게 한다. 소프트웨어 시스템의 규모가 계속 커져감에 따라 """(understanding)"" 중요성은 그만큼 부각되고 있다(OOP가 현재처럼 주류로 떠오르는데 있어 가장 중요한 요인 중 하나였다). 따라서 aspect 개념은 분명 가치 있는 도구가 될 것임에 틀림없다.
다음의 의문은 'Aspect는 객체의 캡슐화 원칙을 거스르지 않느냐?'' 것이다. 결론부터 말하자면 '''''' 이다. 하지만 제한된 형태로만 그렇게 한다는데 주목하도록 하자. aspect는 객체의 private 영역까지 접근할 수 있지만, 다른 클래스의 객체 사이의 캡슐화는 해치지 않는다.

Aspect-Oriented Programming in Java

Markus Voelter, voelter@acm.org
번역: 자바스터디 이클립스 & 모델링도구 시삽 wegra (Bok-Youn, Lee) wegra@wegra.org