상황중심 vs 관점지향 프로그래밍 : AOP

물개가 쓴 기사가 실린 마소9월호가 얼마전에 사무실에 배달되었길래 읽어보다가 임백준씨가 쓴 “상황중심 프로그래밍”이라는 발견했다. 상황중심프로그래밍? Situation Centered Programming이나 Context Centered Progarmming이라는 새로운 프로그래밍 패러다임이 나온 줄 알고 흥미를 가지고 자세히 글을 읽어보니 다른게 아니라 AOP에 관한 간단한 소개의 글이었다.

저자는 AOP를 관점지향이라고 번역한 것이 의미가 분명하지 않고 정확하지 않아서 차라리 상황중심이라고 불려야 한다고 주장한다. 나도 작년에 AOP에 관한 컬럼을 마소에 쓰면서 한글로 뭐라고 번역해야 할지 많은 고민을 했다. 국내에서 쓰이고 있는 여러가지 표현을 찾아보았는데 내 생각엔 관점지향프로그래밍이라는 것이 그나마 그 의미를 가깝게 전달해주는 적절한 표현이라고 생각되어서 관점지향프로그래밍이라는 말을 사용했다. 그런데 그 글에선 관점지향이라는 말은 의미가 애매하고 상황중심이라는 말이 정확하다고 해서 왜 그런가 아무리 그 글을 읽어보아도 관점지향은 왜 의미가 맞지 않고 상황중심은 AOP를 표현하는 적당한 말인지 설명을 찾을 수가 없었다. 기껏해야 정보조직과 보안브로커의 예를 들어가면서 AOP를 설명하는 것을 보면 어떤 특정한 상황을 중심으로 프로그래밍 하는 것이 AOP이다라는 식의 접근인 것 같은데…

아무리 생각해봐도 그의 주장은 매우 설득력없어 보인다. AOP는 영어로도 그 뜻이 직관적으로 쉽게 이해되는 단어는 아니다. 저자 말대로 OOP라는 표현을 차용해서 쓴 것이 분명하다. 그럼 왜 Aspect라는 말을 썼고 그것을 지향한다고 했을까? Aspect는 어떤 사물의 특성의 한부분 특별히 바라보는 관점에 따라서 다른 모습을 가리키는 단어이다. 우리말로 보통 번역할때 어떤 사물 또는 특성의 한 측면이라고 하면 적절하지 않을까 싶다. AOP는 지금까지 OOP가 바라보는 객체의 특성을 평면적이라고 본다. 그래서 OOP는 그 안에 많은 추상화가 가능함에도 불구하고 2차원적인 설계를 넘어설 수 없게 되어있다. 상속구조를 이용해서 일반화, 추상화를 한다고 해도 그 그림은 평면에 그려지는 구조일 뿐이다. 하지만 실제 애플리케이션을 구성하는 객체는 다차원적이다. 해당 도메인의 문제를 투영한 핵심관심(Main Concern)을 표현한 OOAD적인 관점말고 다른 관점으로 모델을 틀어서 보면 보안이라던가, 성능, 로그와 같은 새로운 측면을 찾아볼 수 있다는 것이다.

그림으로 AOP를 설명할때 보통 세로 길게 늘어선 여러 객체를 놓고 가로로 이를 가로지르는 횡단관심을 그리는 식으로 설명한다. 역시 2차원 지면의 한계이다. 사실 그렇게 공통적인 관심은 오브젝트의 추상화를 통해서 구성하면 된다. 문제는 2차원안에서 표현하지 못하는 공통적인 특성은 3차원 또는 그 이상의 다차원적인 관점으로 전체구조를 해석하고 바라볼 때 그려질 수 있는 부분이다. 그래서 Aspect라는 말은 어떤 도메인을 바라보는 또 각각 다른 기술적인 관점(Aspect)이라고 표현하는 것이 가장 적절한 표현이라고 생각된다.

임백준씨의 AOP는 “상황중심”이라는 말은 그야말로 애매모호한 그 뜻을 명확히 드러내지 못하는 단어를 잘못 선택한 것으로 밖에 보이지 않는다. 상황이라는 것은 오브젝트를 구조적인 관점이 아니라 시간적인 관점으로 늘어놓고 볼 때 어느 특정 “상황”을 짚어서 설명하려는 뜻으로밖에 해석이 되지 않는다. 그것은 AOP의 특성을 설명하기에는 매우 부적절한 방법이다.

그 글에서 그가 잘못 선택한 단어는 그뿐이 아니다. Cross-cutting concerns를 계속 “공통의 관심사”라고 이야기 하고 있다. 객체사이의 공통의 관심(Common Concern)은 Main Concern에도 얼마든지 등장할 수 있는 것이다. 그런 공통의 관심사를 모아서 추상화도 하고 일반화도 시키는 것이 OOP의 기본이다. Cross-cutting concern은 횡단관심이나 또는 그와 유사한 특성을 가진 말로 번역해야 맞다. 도메인의 주관심사는 아니나 객체의 메인관심을 관통하는 어떠한 특별한 관심영역이라는 뜻이기 때문이다.

또 한가지 지적하고 싶은 것은 Join Point와 Pointcut을 두가지 다 접점이라고 번역해서 쓰고 있는 점이다. AOP의 기초만 충실히 공부해도 Join Point와 Pointcut이 어떻게 다른지는 잘 알 수 있다. 뒤따라는 내용을 읽어보면 저자는 그것을 같은 의미로 착각하고 있지 않나 싶다.

AOP는 그 단어들을 번역하거나 설명하기가 쉽지 않다. 특히 기본적인 Aspect를 Class와 유사한 추상화된 개념으로 사용할 때는 더더욱 그 단어를 번역할 적당한 말이 떠오르지 않는다. Class는 그대로 클래스라고 부를 수 밖에 없는 것 처럼 말이다. OOP는 Object/Class가 있는데 AOP는 왜 Aspect/Aspect라고 쓰는지 모르겠다. 사실 AOP를 주장하고 구현하는 사람들 사이에서도 단어사용의 차이가 있다. 실제 언어적인 차원으로 접근해서 aspect라는 키워드를 써서 class같은 aspect를 만드는 AspectJ계열에서는 Aspect라는 말을 Pointcut+Advice같은 개념으로 사용하지만 그렇지 않은 AOP계열에서는 Adviser라고도 부른다. 지금은 나도 AspectJ기반으로 AOP를 많이 쓰기 때문에 Aspect라는 단어를 많이 쓰지만 처음 AOP를 쓰기 시작할때는 SpringAOP에서 많이 쓰던 Adviser라는 단어를 사용했다. 사실 Adviser라는 것이 더 적절한 표현이라고 생각된다. 특정 Pointcut에 특정 Advice를 조합한 것이라면 결국 적절한 point에 advice를 제공한다는 뜻에서 Adviser가 낫지 않을까? 하지만 AspectJ가 AOP영역을 거의 평정해가고 있는 지라 아마도 Aspect라고 계속 써야 할 듯. 아무튼 AOP의 Aspect와 Adviser와 같은 개념의 Aspect는 용어는 같으나 개념은 좀 다르다고 생각해야 한다.

AOP에 대해서 아직도 표준화작업이 본격적으로 이뤄지지 못하고 있는 것으로 알고있다. 표준화할만한 조직조차 없다. 이와 관련해서 몇가지 시도들이 있다고 들었는데 AOP가 많이 사용되기 시작하면서 빨리 용어나 개념의 정립을 하지 않으면 개발자 입장에서 많은 혼란이 생길 수도 있을 것이다.

아무튼 이번 마소에 실린 임백준씨의 글은 매우 실망스럽다. 내용도 너무 가벼울 뿐더러 적절치 못한 단어선택과 애매한 설명은 한심스럽기까지 하다. 외국에서 오래 살아서 그런 것인지 아니면 시간에 쫒겨 급히 원고를 쓰느라 잘 알지 못하는 내용을 성급히 다루어서 그런 것인지… 마소를 창간호부터 구독하고 마소를 통해서 컴퓨터에 관한 기초적인 지식들을 쌓아왔던 나한테 점점 기사의 질이 떨어지는 마소의 모습이 안타깝기만 하다.