Alan's Blog

지금까지 쓴 AOP 개념정리 시리즈 모음입니다:

1. Obliviousness
2. Quantification
3. 주요 Decomposition
4. 다차원적인 관심사 분리
5. 비대칭적 AOP와 대칭적 AOP

간단히 요약하자면... AOP의 두 가지 핵심 개념인 Obliviousness와 Quantification에 대해 정리하였고, 기존 프로그래밍 패러다임의 문제인 "주요 Decomposition의 폭정"에 대해 다룬 후 이를 해결하기 위해 AOP가 제시하고 있는 개념인 다차원적인 관심사 분리를 설명했습니다. 마지막으로, 다차원적인 관심사 분리의 두 가지 형태인 비대칭적 AOP와 대칭적 AOP에 대해 알아보았습니다.

중간에 잠깐 밝혔듯이 갑자기 이 쌩뚱맞은 AOP 개념정리 시리즈를 쓰게 된 이유는 "정보 관리"라는 주제로 글을 써보고 싶었기 때문입니다. 위 다섯 개의 글들은 앞으로 쓸 글에서 종종 인용될 소지가 있습니다.

에 또, 앞으로 별로 인용하게 될 것 같지 않은 Advice, Join point, Pointcut 등의 AOP 관련 개념들은 그냥 정리 안하고 넘어가렵니다. ㅎㅎ

AOP 개념정리 시리즈 #5

다차원적인 관심사 분리에서는 AOP가 주요 Decomposition의 폭정 문제를 해결하기 위하여 하나의 시스템을 동시에 여러 측면(dimension, aspect, viewpoint, ...)으로 나누는 것에 대해 이야기했습니다.

이번에는 다차원적 관심사 분리의 두 가지 종류인 비대칭적 AOP와 대칭적 AOP에 대해 설명하겠습니다.

비대칭적 AOP(Asymmetric AOP)는 시스템을 하나의 주요 측면(dominant dimension)과 나머지 측면들의 집합으로 봅니다. 따라서 주요 측면에 해당하는 코드들(이를 baseline code라고 합니다)과 나머지 측면들에 해당하는 코드들로 나뉠 수 있습니다. 나머지 측면에 해당하는 코드들이 적절한 시점(컴파일 시점 혹은 실행 시점)에 기반 코드(baseline code)에 엮어지는 것이죠(이를 weaving이라고 합니다).

대칭적 AOP는 주요 측면과 나머지 측면을 구별하지 않고, 시스템이 다양하고 서로 동등한 측면들로 구성된다고 보는 것입니다. 비대칭적 AOP에 비해 조금 더 기존 패러다임에서 벗어난 것이죠. 이렇게 되면 시스템의 전체적인 설계는 대충 다음과 같은 모듈들의 집합으로 볼 수 있게 됩니다:


비대칭적 AOP도 약간 그렇지만 대칭적 AOP의 경우 어떠한 코드가 정확히 어느 시점에 어떤 순서로 실행될지 쉽게 알 수 없게 됩니다. 이를 Obliviousness라고 표현하죠. 일견 크게 혼란스러울 것 같지만, 기존의 이벤트 기반 아키텍쳐(Event Driven Architecture)도 이와 유사하다는 것을 떠올려보면 또 그렇게 이상하기만 한 것도 아닙니다.


언어가 비대칭적 AOP를 지향한다고 해서 반드시 해당 언어를 쓰는 프로그래머가 비대칭적 AOP만 해야 한다는 법은 없습니다. 이를테면 C나 Assembly 등을 사용하면서도 객체 지향 프로그래밍을 하는 것이 가능한것과도 같습니다.

예를 들어, (아마도 가장 널리 쓰이는 AOP 언어인) AspectJ는 기존 자바 코드를 기반 코드로 하며 엄밀히 구분된 나머지 코드들(aspect 키워드로 정의된)을 갖는다는 점에서 비대칭적 AOP 언어이지만 class 키워드의 사용을 최소화 하고 대부분의 코드를 aspect definition 안으로 몰아 넣으면 대칭적 AOP에 가까워지는 것이죠.

AOP 개념정리 시리즈 #4

이전 글에서 기존 언어들이 가지는 주요 Decomposition의 횡포 문제에 대해 정리했었는데요:

... 시스템에는 가장 중요한 하나의 관심사 혹은 고려해야할 사항(primary concern)이 있고, 이것에 의해 시스템이 모듈화된다는 것이죠.

그러나 이러한 방식에는 중요한 문제가 있습니다. 주요 관심사(primary concern)에 의해 시스템을 모듈화하고 나면 나머지 부차적인 관심사들(secondary concerns)에 해당하는 코드는 여기저기에 분산될 수 밖에 없게 된다는 것이죠(이렇게 분산되는 것을 scattering이라고 합니다). 부차적인 관심사들의 대표적인 예는 보안/로깅/성능 프로파일링 등입니다. ...

이번에는 이에 대한 해결책으로 AOP가 제시하고 있는 다차원적인 관심사의 분리(Multi-dimensional Separation of Concerns - MDSOC)에 대해 요약해보겠습니다.

하나의 측면(주요 관심사)를 기준으로 시스템을 나누면 나머지 측면에 해당하는 관심사(concern)들이 시스템의 여러 부분에 분산 됩니다. 따라서 하나의 시스템을 여러 관점(viewpoints, aspects, facets, ...)에 따라 다양한 방식으로 나눌 수 있다면 이러한 문제를 제거할 수 있게 됩니다. 하나의 시스템을 한 가지 방식으로만 나누어야 한다는 것이 기존 패러다임이었다면, AOP는 하나의 시스템을 여러 가지 방식으로 동시에 나눌 수 있도록 해줍니다. 이러한 방식을 다차원적인 관심사의 분리라고 부르는 것이죠.

참고로, "다차원적"이라는 말에서의 각 차원을 다른 말로는 aspect(그래서 AOP 입니다), hyper-slice(HyperSpace라는 패러다임의 용어입니다) 등으로 표현합니다.

(도서관학에서 Faceted Classification이라고 부르는 정보 분류의 방법이 있는데, AOP에서 말하는 Aspect와 FC에서 말하는 Facet은 사실 동일한 개념입니다. 제가 얼마 전부터 쌩뚱맞게 AOP 용어정리를 하고 있는 이유는 사실 정보 분류에 대한 얘기를 하고 싶었기 때문입니다. 용어정리 시리즈가 끝나면 이 얘기를 해보고 싶습니다.)

AOP 개념정리 시리즈 #3

기존 언어가 제공하는 모듈화 메커니즘은 시스템이 단 하나의 주요 구조만을 가질 수 있도록 제한되어 있습니다.

예를 들어 객체 지향 프로그래밍 패러다임으로 업무용 애플리케이션을 설계하면 해당 업무 도메인(business domain)의 주요 개념들이 핵심 클래스 및 핵심 클래스들이 이루는 각종 의존성(composition, aggregation, generalization, ...)으로 표현되는데, 이것이 "주요 decomposition(dominant decomposition 혹은 primary decomposition)" 입니다.

다른 말로 표현하면, 시스템에는 가장 중요한 하나의 관심사 혹은 고려해야할 사항(primary concern)이 있고, 이것에 의해 시스템이 모듈화된다는 것이죠.

그러나 이러한 방식에는 중요한 문제가 있습니다. 주요 관심사(primary concern)에 의해 시스템을 모듈화하고 나면 나머지 부차적인 관심사들(secondary concerns)에 해당하는 코드는 여기저기에 분산될 수 밖에 없게 된다는 것이죠(이렇게 분산되는 것을 scattering이라고 합니다). 부차적인 관심사들의 대표적인 예는 보안/로깅/성능 프로파일링 등입니다.

분산된 관심사들을 표현하는 말이 바로 AOP 관련 문서에서 익숙하게 보아온 "crosscutting concerns"입니다(crosscutting concern들이 crosscut 하는 대상은 바로 "주요 decomposition"에 의한 모듈들 - 혹은 primary concern - 입니다).

AOP는 바로 이 문제 - 주요 decomposition의 폭정으로 인해 나타나는 crosscutting concerns - 를 해결하기 위해 만들어진 패러다임인 것입니다. 그리고 AOP가 들고 나온 두 가지 도구가 바로 전에 소개한 Obliviousness와 Quantification 입니다.

AOP 개념정리 시리즈 #2

이전글(Obliviousness)에서 썼다시피 AOP의 두 축을 이루는 개념은 Obliviousness와 Quantification 입니다. Quantification이란:


는 식의 문장에서 조건 C에 해당하는 것입니다. 즉, 어떠한 코드가 어떠한 상황에서 수행될 것인지를 지정할 수 있게 해주는 것이죠.

Quantification은 그 속성에 따라 동적인 Quantification과 정적인 Quantification으로 나누기도 합니다. 이는 마치 객체 지향 프로그래밍에서 다형성을 동적인 다형성(dynamic polymorphism)과 정적인 다형성(static polymorphism)으로 나누는 것과도 비슷합니다.

예를 들어 동적인 Quantification이란

• Exception이 발생할 때
• 함수 Y에 의해 함수 X가 호출될 때
  

등과 같이 실행 중(runtime)에 발생하는 사건에 대한 Quantification입니다.

마지막으로, 정적인 Quantification을 또 둘로 구분하는 경우도 있는데 하나는 컴포넌트의 public interface에 대한 Quantification만이 가능한 black-box quantification이며, 다른 하나는 컴포넌트 내부의 모든 코드에 대해 Quantification이 가능한 clear-box quantification 입니다.

AOP 개념정리 시리즈 #1

Obliviousness는 Quantification과 함께 AOP의 두 축을 이루는 개념 입니다. OOP에 다형성(polymorphism), 정보은닉(information hiding), 캡슐화(encapsulation)가 있다면 AOP에는 Obilviousness와 Quantification이 있습니다.

객체 지향 프로그래밍의 다형성(polymorphism)은 "무엇"과 "어떻게"를 분리합니다. 즉 객체의 오퍼레이션(operation)을 호출했을 때(무엇) 그게 정확히 어떤 메서드를 호출하게 될지, 즉 어떻게 작동할 것인지(how)를 숨길 수 있게 합니다. AOP의 obliviousness는 "어떻게"와"어디"를 분리합니다. 즉 특정 코드(advice)가 언제(when) 호출되는지를 구체적으로 명시하지 않을 수 있습니다.

여기에서 중요한 점은 다형성과 obliviousness가 직교적이라는 사실입니다. "무엇"과 "어떻게"가 분리되었는지 여부와 무관하게 "어떻게"와 "어디"가 분리될 수 있습니다. 이는 AOP가 객체 지향 프로그래밍 패러다임에 국한되지 않음을 의미합니다.

다음은 Aspect Oriented Software Development에서 인용한 글입니다:

Obliviousness states that one can't tell that the aspect code will execute by examining the body of the base code. Obliviousness is desirable because it allows greater Separation of Concerns in the system creation process.

(...omitted...)

This is not to ignore the disadvantages of obliviousness - that systems melded from separate minds may not function the way anyone intended and that systems composed by formal rules may produce surprising behavior. Nor is it the assertion that AOP techniques must always be used obliviously - there's no great harm in knowing what's going on, either. The argument is that one of the two things that distinguish Aspect Oriented Programming languages from their predecessors is the ability to oblivious.

--p24

1. GOTO

4년~5년 쯤 전에 다익스트라의 "Goto Statement Considered Harmful"이라는 유명한 논문을 읽은 적이 있습니다. 선정적인 제목과 달리 제가 이해한 논문의 핵심은 "GOTO 문장이 나쁘니까 쓰지 말아야 한다"가 아니라 다음 문장이었습니다:

We should do (as wise programmers aware of our limitations) our utmost to shorten the conceptual gap beween the static program and the dynamic process, to make the correspondence between the program(spread out in text space) and the process(spread out in time) as trivial as possible.

우리는(자신의 한계를 잘 인식하고 있는 현명한 프로그래머로서) 정적인 프로그램과 동적인 프로세스 사이의 개념적 격차를 줄이기 위해 최선을 다해야 한다. 이를 통해 텍스트 공간 상에 펼쳐져 있는 프로그램과 시간 상에 펼쳐져 있는 프로세스 사이의 대응을 가능한 한 쉽게 만들 수 있다.

프로그래밍을 한다는 것은

• 소스 코드를 읽으면서 이 코드의 실행 결과, 즉 프로세스를 그려내거나
• 원하는 프로세스로부터 소스 코드를 만들어내는

것인데, 소스 코드라는 것은 2차원 평면(종이 혹은 편집기 화면)이라는 공간 상에 펼쳐진 문자열인 반면, 프로세스는 시간 상에 펼쳐진 개념입니다. 따라서 이 둘 사이의 차이가 적을 수록 프로그래밍이 (읽고/쓰기에) 쉬워진다는 것입니다.

예를 들어 제어문(조건문/반복문 등)이 전혀 없는 코드는 위에서 아래로 순서대로 실행되는데, 이러한 코드는 시간과 공간 사이의 대응이 아주 쉽습니다. 반면 GOTO가 들어가면 시간과 공간 사이의 대응이 어려워지기 때문에 GOTO가 나쁘다고 말하는 것입니다. (물론 while, for, function 등도 GOTO와 비슷하지만 이들은 나쁘다고 말하지 않습니다. GOTO와 이들 - 즉, Structured Programming을 위한 개념들 - 사이의 차이를 설명하기 위해 다익스트라는 Programmer Independent Coordinate System이라는 개념을 도입하는데, 이에 대한 설명은 생략하겠습니다)

2. Aspect Oriented Programming

예전에 하이텔 자바동(8년 쯤 전?)에서 AOP에 대한 글을 접한 후로 관심을 가지고 조금씩 살펴보고 있다가, 3년 쯤 전에 사내 세미나 주제로 AOP가 선정되는 바람에 Aspect Oriented Software Development 라는 책을 읽을 기회가 생겼습니다. 이 덕에 그마나 대략적인 개념탑재가 되었습니다.

이 책에서는 프로그래밍 언어의 발전 방향에 대해 다음과 같이 설명하고 있습니다:

The earliest computer machine-language programs had a strict correspondence between the program text and the execution pattern. Generally, each programming language statement was both unitary and local - unitary in that it ended up having effect in precisely one place in the elaborated program, and local in that it was almost always proximate to the statements executing around it.

The history (of this part) of programming languages has been about moving away from purely local and unitary languages and toward mechanisms that let the programmer separate concepts into pragmatic assemblages or modules, instead of being tied to saying things just where they happen. The first exceptions to locality were subprograms (i.e., procedures, subroutines, functions). Subprograms were a great invention, enabling abstracting out some behavior to someplace else. (...omitted...)

Inheritance (and related mechanisms like Delegation) in Object Oriented Programming was another important introduction of non-locality. Executing inherited behavior is non-local.

초창기의 기계어 프로그램에는 프로그램 텍스트와 실행 패턴 사이에 정확한 대응이 존재했었다. 일반적으로 각각의 문장은 일원적이면서 동시에 지역적이었다. 일원적이라는 것은 문장이 정확히 한 지점에만 영향을 미친다는 의미이고, 지역적이라는 것은 그 영향이 거의 항상 해당 문장의 주변 문장들로만 한정된다는 의미이다.

(이러한 관점에서) 프로그래밍 언어의 역사란 순수하게 지역적이고 일원적인 언어에서 벗어나, 실행이 되는 해당 지점에 모든 사항을 써내려가는 것이 아닌 실용적 묶음 혹은 모듈 단위로 개념을 분리할 수 있도록 변해가는 과정이었다. 지역성에 대한 첫 번째 예외는 서브 프로그램(프로시저, 서브루틴, 함수)이었다. 서브 프로그램은 특정 행위에 대한 상세한 기술을 다른 위치에 적을 수 있게 하여 추상화를 가능케 해준 위대한 발명이었다. (...중략...)

객체지향 프로그래밍의 상속(및 델리게이션 등의 유사한 메커니즘)은 또다른 주요한 비-지역성의 하나이다. 상속된 행위를 실행하는 것은 비-지역적이기 때문이다.

통찰력 있는 글입니다.

하지만 이 글을 읽자마자, 전에 읽었던 다익스트라의 글이 떠오르면서 "뭔가 충돌이 있다"는 생각이 들었습니다. 다익스트라는 정적 프로그램과 동적 프로세스 사이의 차이를 최소화 하는 것에 대해 말하고 있고, AOP는 프로그램 텍스트와 실행 패턴 사이의 결속으로부터 벗어나는 것에 대해 말하고 있기 때문이죠.

2005년에 쓰인 Carl Zetie의 AOP Considered Harmful? 이라는 글에서는 AOP가 다익스트라가 지적한 문제점을 가지고 있기 때문에 해롭다고 말하고 있습니다(비싸서 요약만 읽었습니다만 ㅎㅎ)만, 별로 동의할 수는 없었습니다. 둘 사이에 충돌이 있는 것은 맞지만 그렇다고 해서 둘 중 하나가 잘못된 것이라고 생각해버릴 수는 없었던거죠.

3. Subtext

별 다른 결론을 얻지 못하고 몇 년이 지났는데, 어제 38분짜리 Subtext2의 동영상을 보고서야 답을 찾았다는 느낌이 들었습니다. (아래 글은 위 동영상을 보신 후에 읽으면 좋습니다)

다익스트라가 강조한 것은 소스 코드와 프로세스 사이의 간극을 최소화해야 한다는 것이고, AOSD에서 강조한 것은 모듈화와 추상화입니다. 문제는 모듈화/추상화의 결과로 인하여 소스 코드와 프로세스 사이의 간극이 벌어질 수 밖에 없다는 점입니다. 결국 둘 중 하나를 포기하거나 적당히 타협을 해야하는데, 이 부분이 찝찝한 것이죠.

하지만, Subtext는 다른 방식으로 이 충돌을 해결합니다. 소스 코드가 2차원 평면 상에 펼쳐진 문자열이어야 할 필요가 없다는 것이죠. Subtext에서는 프로그램과 프로세스가 "동일"합니다. 소스 코드는 코드인 동시에 실행 결과이기도 합니다. 코드를 수정하면 결과도 수정됩니다. 코드 내에 다섯 가지 분기가 존재하면 화면 상에 다섯 가지 흐름이 나타납니다.

그 결과 모듈화/추상화를 하면서도 여전히 지역성을 유지할 수 있게 됩니다. 뿐만 아니라 OOP의 핵심적인 개념에 대해서도 매우 직관적으로 익힐 수 있는데, 이를테면 기존 언어의 조건문(if/else 혹은 switch)과 OOP의 다형성(polymorphism)이 결국은 같은 것이라는 사실이 Subtext에서는 시각적으로 명확하게 표현됩니다.

몇 년 동안 찜찜하게 남아있던 고민 하나를 해결하고나서 괜히 혼자 들 뜬 마음에 주절거려봤습니다.

PS) 요즘 관심 있게 보고 있는 것 중 하나가 Xanadu Project 인데(완전 뒷북이죠 ㅎㅎ), 이게 또 Subtext와 재미있는 유사성을 가지고 있는 것 같습니다. 인간은 언제 쯤 "네모난/평평한 종이"에 대한 강박에서 완전히 해방될 수 있을까요?