1988년 서울올림픽부터 시작해서
2008년 베이징올림픽에 이르기까지
6번의 올림픽을 제대로 본 적이 없읍니다.

그렇다고 스포츠경기를 유달리 싫어하는것도 아닙니다.
그러면 왜 못봤냐.

항상 그때마다 공부(수험생)를 하던가
프로젝트 Due에 맞추어 개발을 하던가 했읍니다.

미리미리 해두었다면, 여유롭게 올림픽을 즐겨가며
할것도 다 하면서 살수도 있었읍니다만,
게으름때문에 '올림픽이 뭐가 중요한가'를 외치며
오늘도 컴퓨터앞에서 뭔가 열심히 프로그램만 짭니다.

그러면 대가라도 되어있어야 되는데, 그렇지도 않습니다.

대가가 되던지.. 아니면
다음 올림픽부터는 챙겨볼수 있도록 해야겠읍니다.

Joel Spolsky가 이야기한 다음의 말입니다.

All non-trivial abstractions, to some degree, are leaky.

(누구나 그렇겠지만) 왕년에는 천재였으나 30대에 바보가 되어버린 머리로는
어느정도 복잡도가 넘어가면 머리속에서 발산해버리고 마는 특성으로 인해
개발에 있어서 제일의 화두는 abstraction이라고 생각하고 있읍니다.
Joel의 말에 저도 동감을 하는데, Leaky한 abstraction이라도 적용하지 않으면
바로 발산해버리기 대문에, 계속 적용을 해나갈 수 밖에 없읍니다.
따라서 아무래도 평생동안의 소프트웨어 개발 제일 화두는 abstraction이 될 것입니다.

그런데 이 법칙은 디자인 패턴에도 적용할 수 있읍니다.

All non-trivial design patterns, to some degree, are leaky also.

leaky한 abstraction을 잘 활용하려면, 어차피 해당 abstraction의 detail까지 일단
파고 들어가 다 소화한후에, 활용해야되듯이 (무엇을 깨쳤는가.. 다 잊었읍니다.. 그것이 Zen이다.)
design pattern도 잘 활용하려면, 즉 non-trivial한 design pattern을 활용하여 무엇인가 얻으려면,
해당 design pattern의 본질적인 부분까지 파고들어가야 합니다.
기계적으로 '이럴땐 이거'로 적용하지는 마시라는 것입니다.

디자인 패턴의 가장 큰 가치는 커뮤니케이션을 원활하게 한다입니다.
시스템/모듈 디자인을 설명할때, '이건 adapter 패턴을 이용하여 어쩌고 저쩌고..'
'요 widget에 대해서는 observer 패턴을 이용해서 어쩌고 저쩌고'
라고 설명하면, 화자와 청자가 둘다 용어를 알고 있다고 하면
의미가 간단명료하게 전달되기 때문입니다.

두번째 가치는 소프트웨어 구현테크닉을 모르는 사람이 패턴을 공부함으로써
자신의 구현방법 repository를 확장하는 것입니다.

그런데 현업에서 많이 이미 구를대로 굴렀다, 알만큼 안다, 라는 분들은
굳이 디자인 패턴을 보면서 시간을 낭비(?)할 필요가 있을까 싶습니다.

디자인 패턴을 책이나 기타 매체등을 통해 접하면서
'아, 내가 그때 이렇게 한게 이 패턴이었군' 이라고 느끼면서
'역시 디자인패턴은 배워볼만한 것이야' 라고 느낀다면
본말이 전도된 것입니다.
'이렇게 하면 내가 고생하던 문제를 깨끗이 정리할수 있겠네'
라고 느낀다면 공부측면에서 디자인 패턴을 배울 필요는 있읍니다.
그런데, 많은 경우에 디자인 패턴을 전파하시는 분들이
전자에 속하는, 즉 '자신이 이미 알고 있는 것을 다른 경로를
통해 Re-assure해줌으로써 기분이 좋아져서 그것이 실제 가치보다
더욱 가치가 있는 것이라고 생각하는', 경향이 많은 것 같습니다.

따라서 디자인 패턴은 다음과 같이 접근하는것이 좋겠읍니다.
 1. 자신이 사는 세계에서 패턴 world의 단어가 많이 출몰하는 경우
     커뮤니케이션을 위해 익혀둔다.
 2. Enterprise SW를 개발하는 경우에는 해당 시스템의 본질적 복잡도를
    회피하기 위해 구조화된 디자인이 매우 필요하므로 익혀둔다.
 3. 1,2가 아니라면 간단한 세미나나 간단한량의 book(let)을 통해
    파악만 해 둔다.
 4. 만약 컴퓨터 엔지니어링쪽 Job을 가는 초심 개발자 ( == 학생)
    라면 미래를 위해 잘 익혀둔다.

뭐, 잘 알아서 나쁠건 없읍니다만, 제 의견은, 시간은 한정되어있고
배울것이 많다면 굳이 디자인패턴쪽에 시간을 투자하는것은 고려해봐라
라는 것입니다.

Engineer의 궁극적인 목표는 창조(Creation)이고
Scientist의 궁극적인 목표는 발견(Discovery)입니다.

세상에 없던 것을 만들어 내는 것이 창조라면,
이미 세상에 존재하지만 아무도 몰랐던 것을 알아내는 것이 발견입니다.

하늘아래 새로운 것이 없다라는 견해라면
창조라는것도 신이 어딘가에 만들어놓고 숩겨놓았던 것을 끄집어내는
발견이 되겠죠. 그러나 많은 경우에 사용되는 Engineer의 창조 - 협의의 창조 -
는 인간계에 없었던 것으로 생각되고 있던 것을 만들어 내는 것입니다.

소프트웨어를 개발하는 입장에서, 많은 시간동안 고객이 원하는 기능을
개발하고 있다보면 단순 노동을 하고 있다는 생각이 들기 마련입니다.
따라서 항상 새로운 것을 만들어보고 싶다는 욕구 - 가지 못하고 있는 길
The road not taken YET -가 머릿속에 맴돌게 되는데,
실제로 짬을 내어 새로운것을 만들어 보려고 한다면
많은 경우 벽에 부딪혀서, 일상속으로 다시 돌아가게 됩니다.

사실 창조와 발견 모두 어려운 일입니다. 특히나 가치있는 창조와 발견은
어려운 일입니다.

따라서 지금으로서는, 언젠가 예고없이 방문할 영감의 때를 막연히 기다리면서,
대신 변화를 꿈꿔야 합니다. 새로운것이 없어도 세상은 바뀝니다.
어느세계의 상식이라는 것이 다른 세계에서는 귀중한 영감입니다.
최근 M.Stonebreaker가 Google의 MapReduce에 대해서
"Not Novel at All"이라고 비판했다고 합니다.
M.Stonebreaker는 많이 유명한 Computer Scientist입니다.
Scientist는 Novelty를 주요시하기때문에 그렇게 말할수 있읍니다만,
제가 말하고 싶은것은 어찌됐건 Google의 Not Novel at All한 MapReduce 역시
세상을 변화시키고 있다는 겁니다.

어떻게 보면 Scientist는 신의 유물을 인간계로 끌어내긴 하는데, 그들만의
금고에다가 잘 보관해놓고 있을뿐인지도 모릅니다.
그것을 인간계로 퍼뜨리는것은 Engineer의 몫입니다.
Scientist의 금고 (학술지입니다. 쉽게 말해)를 항상 뒤져가면서
널리 퍼뜨려서, 세상을 변화시킬수 있는 무엇인가가 있는지 확인해야합니다.

Science세계에서는 새로운 것을 발견하지 않으면 Perish되기 때문에,
가치를 떠나서 새로운 것들이 쏟아져 나옵니다만, Engineer세계에서는
굳이 혁신적인 것을 만들지 않아도 면장은 하기 때문에 Scientist가 끄집어낸
신의 유물이 인간에게 쉽게 퍼지지 않습니다.

따라서, Engineer라면 공부를 해야합니다. 열심히 공부하다보면, 어느순간
창조의 영감이 찾아와서 붙을것 같다는 생각이 드니까요.

$ cc -o foo foo.c
$ ./foo
Hello, World!