한빛출판네트워크

저자: 천영환(blueing@unitel.co.kr)

들어가기에 앞서…

안녕하세요. 이번에 새롭게 한빛에 글을 올리게 된 천영환이라고 합니다. 요즘들어 여러 가지 일로 바쁘다 보니 어쩐지 다람쥐 쳇바퀴 돌듯 사는 것 같더군요. 깊은 매너리즘에 빠졌다고나 할까요. 자기 개발을 등한시하는 개발자는 살아남을 수 없는 현실에서 자꾸 도태되어가는 생각이 들어 글을 쓰기로 했답니다. 그동안 여기저기 기사도 내보고 책도 몇 권 집필해 봤지만 일단 글을 쓰겠다고 공언한 다음에는 시간이 너무 빡빡하더군요. 하지만 다른 분들에게 도움도 드리고 제 자신도 정리할 수 있는 시간을 갖게 하는 데에는 글을 쓰는 것 이상 좋은 일이 없다는 생각이 듭니다. 자신은 없지만 열심히 해보려구요. 이제 자주 뵙게 될 것 같아 먼저 인사드립니다. 꾸벅~ 어여쁘게 봐주시고 혹 제 글에 불만이 있으시거나 시비 걸고 싶으신 분은 언제라도 제 이메일(blueing@unitel.co.kr)로 연락주세요~

일단 글을 쓰기로 한 이상 글을 쓰기는 써야겠는데... 맨 처음 주제로 뭘 정할까 몇 일동안이나 생각했어요. 사실 지금 한빛 네트워크는 자바, LAMP(리눅스, 아파치, MySQL, 파이썬), XML, 웹, 닷넷, 시스템, 프로그래밍 네트워크로 분류되어 있고 다른 부분은 그나마 뚜렷한 주제가 있는 반면, 제가 글을 쓰기로 한 프로그래밍 네트워크는 그 범위가 정말 광범위한지라 딱히 어떤 주제를 잡아야 할지 난감했거든요. 가장 광범위한 분야인 만큼 다른 분야랑 중복될 소지가 너무 다분하다고나 할까요... 그래서 고심하고 고심한 끝에 첫 주제를 AOP로 정했습니다. "AOP가 뭘까?" 궁금해 하실 분들이 많을 텐데 쉽게 설명한다면 OOP의 자식뻘되는 방법론이라 할 수 있답니다.

AOP 시작하기에 앞서 - 객체지향 프로그래밍

자, 이제 그럼 제가 다루는 첫 번째 주제인 AOP를 시작하실까요?

시작하기에 앞서 우선 질문 하나~! 90년대를 주름잡았던 개발 방법론은 무엇일까요?

여러분 대부분이 아마 객체지향 프로그래밍, 즉 OOP(Object-oriented Programming)를 꼽으실 겁니다. 그만큼 객체지향 프로그래밍은 90년대 그리고 현재까지도 가장 큰 주류를 이루고 있는 개발 방법론이지요.

과거에는 프로그래밍 언어를 처음 배운다고 하면 거의 대부분 C나 베이직, 파스칼로부터 시작했지만 최근에는 이런 프로그래밍 언어를 건너뛰고 바로 자바나 C++부터 시작하는 경우가 많더군요. 이런 분들한테는 객체지향 이외의 방법론이 오히려 낯설게 느껴질지도 모르겠습니다.

사실 아실 분은 다 아시겠지만 기존의 구조적 프로그래밍 언어와 현재의 객체지향 프로그래밍 언어는 그 근본 사상부터가 완전히 다릅니다. 비록 겉으로 보기에는(언어상의 문법은) 비슷하게 보일지도 모르겠지만 말이죠. 기존에는 컴퓨터 프로그램을 입력된 데이터를 가져와서 처리하고 출력하는 일련의 과정으로 보았습니다. 즉, 컴퓨터 프로그램을 "입력 → 처리 → 출력"이라는 과정으로 인식했던 것이였지요. 이 때에는 구조적 프로그래밍이 강조되어 함수니 서브루틴이니 하는 것들을 통해 입출력이 중복되는 부분들을 하나의 모듈로 처리하기 위해 무진 애를 썼었답니다.

하지만 객체지향에서는 이런 함수니 서브루틴이니 하는 개념이 아예 없습니다. 과거 개발자의 생각을 완전히 뒤집어 놓은 것이지요. 객체지향 프로그래밍에서는 기존의 "입력 → 처리 → 출력"이라는 사고의 틀을 깨고 "프로그램 = 객체 + 객체들간에 주고받는 메시지"라는 단순 명료한 명제를 도입했습니다. 객체지향 프로그래밍에서는 더 이상 데이터를 어떻게 처리할 것인가는 중요한 문제가 아니며 오히려 어떤 객체가 데이터를 처리할 것인가가 더 중요한 문제이지요.

객체지향 방법론이 널리 퍼지기 전 개발자들은 큰 문제에 봉착해 있었습니다. 프로그램 크기는 자꾸 커져가서 개발자는 더 투입해야겠는데 각 모듈들을 공통화하기가 점점 더 어려워졌던 것이지요. 그도 그럴 것이 구조적 프로그래밍에서는 웬만큼 잘 설계하지 않는 한 프로그램래밍의 일부분을 고치려면 수많은 다른 부분들도 함께 고쳐야 했거든요. 기능하나 추가하려고 프로그램의 절반을 뜯어고쳐야 하는 일들이 비일비재 했었답니다. 혼자서 짜는 프로그램이라면 프로그램 전반을 자신이 통제하며 작성해 나가기 때문에 그나마 나았지만 여러 개발자가 투입되는 덩치 큰 프로그램에서는 이런 방식이 통할리가 없기 때문입니다. 프로그램들의 덩치가 점점 커져 갈수록 구조적 프로그래밍의 한계가 들어나기 시작한거죠.

이러한 예는 오늘날에도 볼 수 있습니다. 최근들어 .NET이다 뭐다 하면서 MS에서 떠들어대고 있지만 그래도 윈도우즈 프로그래밍의 기본이 되는 것은 Win32 API입니다. Win32 API는 구조적 프로그래밍 언어의 대명사격인 C 언어로 짜여져 있죠. 혹시 여러분 중에 MFC나 Qt같은 클래스 라이브러리를 전혀 사용하지 않고 Win32만 가지고 프로그래밍 해보신 적이 있나요? 만약 있다면 Win32로 프로그래밍하는 보다는 필요한 API를 찾아보는데 더 시간이 걸린다는 말이 실감나실 겁니다. 게다가 여러 명이 Win32 API만을 가지고 협업(協業)하는 것도 정말 힘들고요. 그만큼 구조적 프로그래밍은 프로그램의 크기에 따라 프로그램의 복잡도가 기하급수적으로 늘어나는 단점이 있었습니다. 이런 단점들을 해결하기 위해 객체지향 방법론이 프로그래밍계의 전면에 부각되었으니 "필요는 발명의 어머니"라는 말이 틀린 말은 아닌 것 같네요.

대부분의 프로그래머들이 그렇겠지만 제가 객체지향 프로그래밍을 처음으로 접한 것은 90년대 중반 C++이라는 언어를 통해서 였습니다. 지금은 조금 부끄러운 말이지만 당시 객체지향을 처음 배울 때만 해도 왜 힘들게 정보 은닉을 해야 하는지, 구현되어 있지도 않은 추상 클래스는 왜 힘들게 만들어 놓는지… 이런 것들이 전혀 이해가 되지 않았습니다. 하지만 시간이 지나고 객체지향 방식에 점점 익숙해지면서 이제는 오히려 구조적 프로그래밍 방식이 더 어렵게 느껴지더군요. 역시 방법론의 변화는 사람의 생각을 완전히 바꾸어 놓더군요.

지금 널리 사용되고 있는 닷넷이나 자바와 같은 주요 상업용 언어는 모두 순수 객체지향언어(엄연히 순수라는 단어가 들어가지 못할 요인이 많은 언어들임에도 불구하고)를 표방할 정도로 객체지향이 대세를 이루고 있습니다.

AOP 시작하기에 앞서 - 기존 객체 지향 방법론의 문제점과 AOP 방법론의 대두

이번에는 이 객체지향을 뛰어넘는 새로운 방법론을 소개할까 합니다. 아직까지는 많이 알려지지는 않은 방법론이지만 제 개인적으로는 시간이 갈수록 더욱 더 많이 접하게 되고 듣게될 방법론이 아닐까 생각됩니다.

그 이름도 생소한 AOP! 과연 어떤 방법론이길래 이렇게 잔뜩 기대를 걸게 하는 걸까요? AOP는 Aspect-oriented Programming의 약자입니다. OOP(Object-oriented Programming)는 객체지향 프로그래밍이라는 좋은 번역어가 있었는데 AOP는 뭐로 번역해야 좋을지 잘 모르겠네요. 좋은 생각 있으신 분은 연락주시기 바랍니다. 어쨌거나 Aspect라는 단어를 사전에서 찾아보면 다음과 같이 나와 있으니 참고하시면 되겠네요.

 
aspect 
－ n. 
1 [Ｕ][Ｃ] (물건의) 외관, 모양, 양상. 
2 [Ｕ][Ｃ] (사람의) 표정, 용모; 생김새, 외견; 태도, 몸가짐 ☞ APPEARANCE [동의어]. 
3 (문제·사태 등의 한) 국면, 측면, 상(相); 견지, 각도. 
4 (집 등의) 방향(exposure), 방위; (물건의 어떤 방향을 향한) 측면. 
5 [Ｕ] 『문법』 상(相); 『占星』 성위(星位). 
[어원] 
☞ 라틴어 aspectus에서. (a- 으로 ＋ spicere 보다 ＋ -tus 과거 분사 어미 ＝보이는 것 → 전망). 
▷ SPECTACLE, EXPECT, PROSPECT 
▷ as·pec·tu·al adj. 『문법』 상(相)의. 

그렇다면 왜 AOP라는 방법론이 생겨났는지부터 살펴볼까요? AOP가 생겨난 이유는 과거 구조적 프로그래밍이 유행일 때 객체지향 방법론이 서서히 부각되던 이유와 비슷합니다. 구조적 프로그래밍이 해결할 수 없는 것을 객체지향 프로그래밍이 해결할 수 있었듯이, 객체지향 프로그래밍이 해결할 수 없는 것이 있어 AOP라는 방법론이 나오게 된 것이지요.

객체지향에 뭔가 문제가 있다니... "객체지향만이 궁극의 방법론이며 더 이상의 진보는 없다!"라고 굳건히 믿고 계신 분이라면 무슨 헛소리 쯤으로 치부하실 수도 있다고 생각됩니다. 하지만 분명히 현재 객체지향 프로그래밍에도 문제가 있기는 합니다. 그럼 천천히 현재 객체지향 프로그래밍이 갖고 있는 문제점들을 살펴볼까요?

문제점을 살펴보는 데 어떤 방법이 가장 좋을까 생각해봤는데 역시나 문제가 되는 코드를 보여드리는 게 제일 좋을 것 같네요. 저 같은 경우 말로는 이해 안가는 디자인 패턴들도 코드를 보면 쉽게 이해가 가는 경우가 많더군요. 저와 비슷한 분들도 꽤 되실거라 믿고 코드를 사용해서 설명하겠습니다. 설명은 최근에 가장 대중적인 언어라고 할 수 있는 자바 언어로 나갑니다~.

 
public class Board { 
    public Bulletin read(User usr, int bulletinIndex) throws AuthenticationException { 
        // 사용자가 어떤 게시물을 요청했는지 로그 파일에 남긴다. 
        // 사용자가 게시물을 읽기에 적절한 권한을 갖고 있는지 판단한다. 
        // 게시판으로부터 게시물을 읽는다. 
        // 사용자가 어떤 게시물을 읽었는지 로그 파일에 남긴다. 
        // 읽어놓은 게시물을 반환한다. 
    } 
    public void write(User usr, Bulletin newBulletin) throws AuthenticationException { 
        // 사용자가 새로운 게시물을 쓰려 했음을 로그 파일에 남긴다. 
        // 사용자가 게시물을 쓰기에 적절한 권한을 갖고 있는지 판단한다. 
        // 게시판에 새로운 게시물을 써넣는다. 
        // 사용자가 새로운 게시물을 썼음을 로그 파일에 남긴다. 
    } 
    public void delete(User usr, int bulletinIndex) throws AuthenticationException { 
        // 사용자가 어떤 게시물을 지우려 했는지 로그 파일에 남긴다. 
        // 사용자가 게시물을 지우기에 적절한 권한을 갖고 있는지 판단한다. 
        // 게시판에 있는 게시물을 지운다. 
        // 사용자가 게시물을 지웠음을 로그 파일에 남긴다. 
    } 
} 

위의 Board 클래스 과연 문제가 뭘까요? 이렇게 말하면 뭐가 문제인지 모르시는 분들이 많겠죠. 그렇다면 위 Board 클래스의 역할이 뭘까요? 척 보면 척이라고 아실 분은 다 아실 겁니다. 바로 게시물을 관리하는 역할이죠. 그렇다면 이러한 게시물 관리자로써의 역할을 하기 위해서는 어떠한 일들을 해야 할까요? 즉, Board 클래스가 해야 하는 업무(Concern)는 무엇일까요? 크게 보아 다음과 같은 세 가지 업무가 있을 것 같네요.

1. 게시물을 읽어 반환한다.
2. 새로운 게시물을 써넣는다.
3. 게시물을 지운다.

그런데 위 코드를 유심히 살펴보면 Board 클래스에서 해야 하는 업무에는 비단 이런 업무만 있는 것이 아님을 알 수 있습니다. 모든 코드 앞에는 사용자의 권한을 체크하고 사용자의 행위를 로깅하는 부분이 들어가 있습니다. 따라서 결국 다시 생각해보면 Board 클래스가 해야 할 일에는 다음과 같은 것들이 더 들어가게 되어 있습니다.

4. 사용자의 읽기/쓰기/지우기 행위를 로깅한다.
5. 사용자의 행위를 하기에 적절한 권한을 가지는지 판단한다.

분명 Board 클래스의 주요 업무는 게시물 읽기/쓰기/지우기인데 구현을 하다보니 두 가지 업무를 더 해야만 하는 사태가 발생했습니다. 그렇다고 로깅이나 인증을 안 할 수도 없는 노릇이고... 이처럼 객체지향 디자인을 코드로 옮기는 데에는 모듈화를 어렵게 하는 여러 가지 장애물들이 있습니다. 사실 로깅이나 인증은 어떻게 보면 Board 클래스 자체의 업무라기보다는 시스템 전체의 업무라고 할 수 있잖아요. 그런데 구현을 하다보면 이런 부분들이 (비록 별도의 클래스로 뽑아 처리한다고 해도) 개별 모듈의 구현에 영향을 미칠 수 밖에 없지요. 이렇게 시스템이 해야할 일들을 개별 모듈들이 맡게 되면 시스템에 대한 처리 요건이 바뀌었을 때 프로그램에 전반적인 수정을 가해야 하는 경우도 생기게 됩니다. 디자인상으로는 별 문제가 없어 보이던 모듈들도 실제로 구현을 하다보면 이런 문제가 생기게 되는군요. 이렇게 어떠한 업무를 해결하는 데에 다른 업무가 끼여드는 것을 전문적으로는 "횡단 업무(Crosscutting Concern)"라고 합니다.

그렇다면 지금까지는 이런 문제들을 어떻게 해결해왔을까요? 지금까지 대부분의 객체지향 디자이너들은 이러한 문제들을 디자인 패턴을 응용해서 구조적으로 해결하려고 했습니다. 이러한 시도들이 극대화되고 정규화된 것들이 바로 여러 가지 프레임워크들이지요. 즉, 어떤 프레임워크에 맞춰 제작을 하면 로깅이나 인증처리는 자동으로 됩니다.

하지만 이런 방식 또한 문제에 따라 해결책이 달라져야 한다는 문제점이 있습니다. 따라서 아무리 프레임워크를 잘 만든다고 해도 범용성은 떨어진다고 밖에 볼 수 없지요. 그래서 사람들은 뭔가 더 좋은 방법들을 찾아보게 되었고, 바로 우리가 다루는 AOP가 그 대안이지요.

계속 언급하긴 했지만 아직 실체를 들어내지 않은 AOP! 막연하긴 하지만 많이 기대되시죠? 그 기대는 다음으로 미루도록 하지요. 지식의 여신은 쉽게 옷은 벗지 않는다나 뭐라나… 다음 기사에서는 AOP의 여러 가지 개념들에 대해 살펴보겠습니다.