http://www.dtfe.co.kr/

행 사 명 : 2009 대한민국 SW 개발자 컨퍼런스
캐치프레이즈 : Change The World!
주 최 : 데브멘토
일 시 : 2009. 9.14(월)~19일(토)
장 소 : 데브멘토 온라인 (http://www.dtfe.co.kr)
참 가 비 : 무료
참 가 방 법 :
본 컨퍼런스는 온라인 화상 강연으로 이뤄지며 참여 방법은 아래와 같습니다.
1) 데브멘토(http://www.devmento.co.kr) 세미나 사이트(http://www.dtfe.co.kr)에 접속
2) 컨퍼런스(Conference) 또는 세미나(Seminar) 클릭
3) 프로그램에서 원하는 행사 선택 사전접수 클릭
4) 사전접수 후 컨퍼런스 당일 강연 입장하여 청취

OAuth란?

Open API를 사용하기 위해선 인증이 필요합니다.
인증방식의 표준이 없기 때문에 제 각각의 방법으로 개발되고 있는 실정인데요
구글의 AuthSub, AOL의 OpenAuth, 야후의 BBAuth
OAuth는 제각각의 인증방식을 표준화하고 가장 좋은 방법만 가져다 만들었습니다.

즉 매쉬업 서비스로 만들어진 어플리케이션이 다른 어플리케이션의 사용자 정보를 접근할 수 있는
표준화된 방법을 제공하는 스펙입니다.

OAuth 인증방식을 이해하기 위해선용어를 미리 숙지하셔야 합니다.

◦ 서비스 프로바이더(Service Provider) – OPENAPI를 제공하는 서비스를 말합니다.

◦ 사용자(users) - 서비스 프로바이더 혹은(그리고) 컨수머를 사용하는 이를 말합니다.

◦ 컨수머(Consumer) – API를 사용하여 개발된 애플리케이션 서비스를 말합니다.

◦ 보호된 자원(Protected Resources): 서비스 프로바이더에 존재하는 사용자의 데이터를 의미합니다.

◦ 컨수머 개발자(Consumer Developer) : 컨수머를 개발하는 개인 혹은 단체

◦ 컨수머 키(Consumer Key) : 서비스 프로바이더에게 컨수머 자신임을 인증하기 위한 키

◦ 컨수머 시크릿(Consumer Secret) : 컨수머의 컨수머 키 소유권한이 있는지 인증하기 위한 키

◦ 토큰(Tokens) – 컨수머에서 서비스 프로바이더에 있는 사용자의 보호된 자원에 접근하기 위해 사용되는

사용자의 인증정보입니다.

▪ 리퀘스트 토큰(Request Token) : 컨수머가 사용자에게 접근권환을 획득하는 과정에서 사용하는

값이며, 이것은 차후 액세스 토큰으로 교환됩니다.

▪ 리퀘스트 토큰 시크릿(Request Token Secret) : 리퀘스트토큰이 사용자의 것임을 인증하기 위한

값입니다.

▪ 액세스 토큰(Access Token) : 컨수머가 사용자의 서비스 프로바이더를 통해서가 아닌 컨수머를

통해서 보호된 자원에 접근할 수 있는 권한을 받기 위한 값입니다.

▪ 액세스 토큰 시크릿(Access Token Secret) : 액세스토큰이 사용자의 것임을 인증하기 위한

값입니다.

OAuth 인증방식의 흐름도입니다.

OAuth 인증 방식에는 7가지의 인증과정으로 이루어져 있습니다.

A; Consumer가 Request Token 요청
B; Service Provider가 Request Token 발급

C; Consumer는 사용자를 Service Provider로 이동, 사용자를 인증하고 토큰 발급을 확인함

D; Service Provider는 사용자를 Consumer로 이동

E; Consumer는 Access Token 요청

F; Service Provider는 Consumer의 신원과 Request Token 확인, Access Token 발급

G; Consumer는 Access Token으로 사용자 정보에 접근

끝으로 관련 사이트입니다.

http://oauth.net/

http://wiki.oauth.net/OAuthSummit2008

현재 오픈마루에서 OAuth 인증방식을 지원하고 있습니다.

http://dev.springnote.com/pages/1083036

OAuth 인증 관련 예제

http://myruby.net/pages/1168058

Internationalization ( i18n ) : 번역하기를 "국제화" 라고 한다. 이 단어는 패키지화 된 프로그램이 있을때 그 프로그램이 다양한 언어를 지원하도록 만들어진 것을 의미한다. 이는 다시말해 영어로 된 문자열을 사용하여 이루어지는 행동과, 영어 이외의 다른 언어로 이루어지는 행동이 "차이 없는" 일반화 과정(Generalization process)이라고 할 수 있다. 프로그램 개발자는 자신의 프로그램에 국제화를 적용할때 다양한 기술을 사용할 수 있는데, GNU gettext는 이들 표준중에 하나를 제공하는 것이라고 할 수 있다.

Localization ( l10n ) : 번역하기를 "지역화" 라고 한다. 지역화는 국제화(I18n)가 모집합인 집합 구성원으로 (쉽게 말해 이미 국제화가 된 소프트웨어만 국제화를 진행 할 수 있다는 뜻이다), 관련된 정보를 특정 지역의 언어/문화에 관련된 행동양식에 맞추어 (예를 들자면 화폐단위, 지역시간 등) 사용할 수 있게 하는 것이라고 할 수 있다. 이는 특정방법으로 이미 국제화로 일반화된(Generalized) 프로그램을 부분화시키는 작업이라고도 할 수 있다. 이들 지역화의 구분은 특별한 환경 변수를 바탕으로 프로그램 실행전에 "어느 로케일에서 사용되고 있는지"를 파악, 실행시간대에 그것을 적용하게 하는 것이다.


보다 자세한 내용은 아래 링크를 클릭하십시오

• http://www.gnome.or.kr/web/default/88
• http://www.gnu.org/software/gettext/manual/html_mono/gettext.html

정규표현식 시트 자료입니다.
유용하게 사용하세요~~!!

출처 : Added Bytes

Internet Explorer Collection 은 multiple IE versions 설치 프로그램입니다.
아래 설치 가능한 IE 버전의 내역입니다. 선택 설치 하시면 되고,
standalone 실행으로 이미 설치된 브라우져에 영향을 주지 않습니다.
다만, 기본브라우져로 사용할 수 없으니 이점 유의 하시면 될거 같습니다.

Internet Explorer Collection contains the following versions of IE:

• Internet Explorer 1.0 (4.40.308)
• Internet Explorer 1.5 (0.1.0.10)
• Internet Explorer 2.01 (2.01.046)
• Internet Explorer 3.0 (3.0.1152)
• Internet Explorer 4.01 (4.72.3110.0)
• Internet Explorer 5.01 (5.00.3314.2100)
• Internet Explorer 5.5 (5.51.4807.2300)
• Internet Explorer 6.0 (6.00.2800.1106)
• Internet Explorer 6.0 (6.00.2900.2180)
• Internet Explorer 7.0 (7.00.5730.13)
• Internet Explorer 8.0 (8.00.6001.18372)

요즘 웹표준, 웹접근 때문에 모든 브라우져에서의 래더링이 동일하게 보이기 위해 꼭 필요한 유틸입니다.
디자이너, 퍼블리셔, 개발자에게 꼭 필요할거 같습니다.

IETester 라는 브라우져도 있지만 멀티엔진을 탑재해서 그런지 완성도 면에서 좀 부족한 느낌이 들더군요..

구글 Chart API
구글에서 차트 API를 선보였다.
REST 방식으로 차트 데이터와 형식을 보내면 간단하게 차트를 만들어 준다.

http://chart.apis.google.com/chart?cht=p3&chd=s:FI&chs=400x200&chl=Firefox|IE

위의 URL에서 3차원 파이(cht), F와 I의 ASCII값(chd)를 인코딩 해서 400x200 사이즈 캔버스에 Firefox와 IE라는 레이블(chl)로 그리라는 이야기다.


아래 차트를 보면 알겠지만 복잡해 보이는 차트도 GET 방식으로 넘긴 데이터를 가지고 만들어 낸다.
GET 방식의 경우 최대 2,047byte 까지만전달 할 수 있기 때문에 값을 Number 값으로 전달햇다면 아래와 같은 복잡한 차트를 구현하기 힘들었을 것이다.
역시 발상의 전환이랄까... ASCII값을 인코딩해서 수치로 처리 한다는..
간단한거 같지만 이런걸 생각한다는것이 존경 스럽다.
발상의 전환





일분 내용은 Channy’s Blog 에서 발췌하였습니다.

올블에 화두내용중 파이어폭스 애드온스에 대한 글이 눈에 띄어 봤더니
국내 개발자이신 강병욱님께서 만든 파이어폭스 애드온스대한 내용이 올라와 있어
유용한 플러그인이라 소개 하고자 한다.

하나는 웹메일알림이 아래에 설명글을 보시면 알겠지만 한가지 메일만지원하지 않고 다수의 메일서비스를 등록할수 있어 자동으로 각 메일 웹페이지로 이동할 수 있어 간편하게 메일을 확인 할 수 있다.

둘째로는 LightSMS 로 문자를 보낼 수 있는 플러그인 이다. tworld 에 가입되어 있으면 네이트온의 무료문자 서비스를 이용할 수 있게 되는것이다.
테스트로 한통보내봤더니 정말 잘간다.... ㅎㅎ
문제점으로 한가지 제시하자면 보낸문자 히스토리 기능인데 이건 개인프라이버시 노출이 될거 같아 문자 내용은 히스토리에 등록안되었으면 하는 바람이다.


웹메일 알림이 (WebMail Notifier)

LightSMS

친구에게 파일을 전해주려고
http://www.mediafire.com 의 무료파일호스팅을 받아 공유하려고 했는데
오랜만에 접속을 했더니 이게 왠일인가?

도메인은 살아 있지만 접속하면 백색 페이지만 덩그러니.. 아무것도 없다.
헉 망한걸까?
네이버에서 검색을 했더니 1월 3일에 이같은 증상을 보인다는 제보가 올라와 있다.

아무래도 영세 업체에서 개발해서 그런가 서비스를 중단시켰을 지도 모른다는 추리를 해본다.
젠장 내가 올려 놨던 파일 들은 그럼 어쩌란 말이냐..

웹 2.0 트렌드에 맞춰 ajax와 업로드 progress 를 지원하고 사이트도 잘 만들고 서비스도 맘에 들어 짬짬이 이용하던차인데 뒷통수를 맞는 듯한 이 느낌..

제발 원상 복귀 하길 기대해본다....

패스터폭스 파이어폭스의 성능을 좀더 upgrade 시켜주는 플러그인

설치 해보고 사용하고 있지만 아주 빨르진 않다 기존보다 쬐금더 빨라진 느낌이랄까.. ㅋㅋ

http://fasterfox.mozdev.org/

출처 : SJSTORY

GMail Drive shell extension

GmailFS는 Gmail을 File System으로 인식하게 해주는 프로그램이다.
설치를 하게 되면 탐색기에 Gmail Drive가 생겨서 Gmail 계정으로
로그인 하여 2.7G의 Gmail 용량이 가상의 드라이브로 설정된다.
마우스로 드래그해서 넣기만 하면 email에 파일첨부 형태로 전송되어지고
탐색기에서는 그냥 파일로만 표시 되지만 메일 홈페이지에 들어가보면
메일로 온것을 알수 있다.
탐색기에서 폴더만들기도 된다.

다운로드 & 설명 : http://www.viksoe.dk/code/gmail.htm

프로그램을 설치 후 탐색기 "내컴퓨터 > Gmail Drive" 가 보입니다.

Mediafire.com
파일의 크기 및 업로드수에 제한이 없는 무료 파일 호스팅서비스입니다.

회원가입 없이도 사용이 가능하지만, 이메일과 비번입력만으로 회원가입이 끝나므로 회원가입 후 이용하는것이 자신의 파일을 관리하는데 있어서 유용하겠지요


파일 업로드중인 이미지 샷입니다.
직관적인 UI이를 보여주고 있습니다. Status 에는 현재 업로드 속도 까지 보여 주고 있죠.


업로드가 끝난뒤 파일에 대한 링크를 Download Link, HTML Link, Forum Link 3가지 type의 링크를 제공하고 Email로 Download Link도 발송이 가능합니다.

웹하드처럼 사용하면 좋을거 같습니다.

발췌 : 웹초보의 Tech 2.1

소니 브라비아TV 광고 입니다.
첨에는 CG를 이용한거라 생각했었는데 실제 페인트를 이용했더군요
제작되는 영상도 한번 보긴 한거 같은데.. ^^

정말 대단합니다.
리허설 없이 한번에 끝냈을 터인데
브라보!!!

원문 : Channy's 2nd. Blog

OpenDNS라는 서비스가 소개 되었다. (via TechCrunch) 한마디로 인터넷 설정할 때 KT는 168.128... 데이콤은 164.124... 로 시작하는 IP 주소를 외워 적던 DNS 서버를 공개해 주는 것이다.

사실 DNS 서버를 자체적으로 운용한다는 게 쉬운 일은 아니다. 그래서 우리 나라 대부분 기업이나 사용자들은 ISP의 DNS서버를 사용한다. 그 때문에, 넷피아 같은 회사가 ISP랑 계약해서 DNS 스니핑으로 한글 키워드를 빼돌리는 서비스가 가능한 것이다.

말이 옆으로 샜는데... Open DNS 역시 다른 DNS 서버랑 비슷한 역할을 하지만 여러 가지 장점이 있다. 일단 DNS를 쉽게 쓸 수 있다는 점에서 좋고, (미국 내에서 만큼은) 캐시 용량도 많고 밴드위스가 빵빵해서 빠르다고 한다. 게다가 도메인 스펠 체크나 피싱 방지 서비스도 해 줄 만큼 똑똑하단다.

좀 더 똑똑해 지면 넷피아가 하던 키워드 서비스도 가능할 것 같다. OpenDNS는 브라우저나 DNS를 해킹하는 꼼수가 아니라 사용자들이 필요한 서비스를 제공함으로서 부가 가치를 창출하려고 한다는 것이다.

원문 : http://network.hanbitbook.co.kr/view.php?bi_id=299

저자: 천영환(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의 여러 가지 개념들에 대해 살펴보겠습니다.