E D R , A S I H C RSS

How To Study Design Patterns


DPSC를 구입한 분들이 좀 있는 것으로 보아, DP를 공부하려는 움직임 같은 게 있지 않을까 하는 생각에 "조금 먼저 공부한 사람"으로서 몇 가지 조언을 드릴까 합니다. (DPSC 이야기가 안나왔으면 이런 글 쓰지 않았을텐데... 이것도 인연이라면 인연이네요)

기본적으로는 제 교육철학과 언어교습론, 그리고 공부론에서 크게 벗어나지 않으므로 저번 영어(및 기타) 강의를 들으셨던 분들에겐 익숙한 이야기가 많을 겁니다.

기본적으로 "교육은 교육자가 피교육자가에게 지식을 고대로 전달하는 행위가 아닙니다. 진정한 교육은 피교육자의 개인적 체험에 기반한 전폭적 동의에서 출발합니다. 저는 이를 동의에 의한 교육이라고 합니다."

내가 여러분에게 "주석문을 가능하면 쓰지 않는 것이 더 좋다"라는 이야기를 했을 때 이 문장을 하나의 사실로 받아들이고 기억하면 그 시점 당장에는 학습이 일어나지 않는다고 봅니다. 대신 여러분이 차후에 여러가지 경험을 하면서도 이 화두를 놓치지 않고 있다가 어느 순간엔가, "아!!! 그래 주석문을 쓰지 않는게 좋겠구나!!"하고 자각하는 순간, 바로 그 시점에 학습이, 교육이 이뤄지는 것입니다. 이는 기본적으로 컨스트럭티비즘이라고 하는 삐아제와 비곳스키의 철학을 따르는 것이죠. 지식이란 외부에서 입력받는 것이 아니고, 그것에 대한 모델을 학습자 스스로가 내부에서 축조(construct)할 때 획득할 수 있는 것이라는 철학이죠.

제가 일전에 썼던 글을 인용하겠습니다:

''최소한 언어 교육에 있어서는 피교육자의 "기쁨에 찬" 동의가 없으면 별로 효과를 볼 수 없다는 게 제 생각입니다. 모르는 사람은 아예 모르기 때문에 아직 공부할 필요가 없으며 아는 사람은 이미 알기 때문에 다시 공부할 필요가 없습니다. 아는 것도 모르는 것도 아니고 어중간한 상태에서 나름의 문제의식을 갖고 있는 경우, 이 사람에게 누군가가 "제대로 된" 한두마디만 던져줘도 그는 열가지 스무가지 일사천리로 소화하고 이해하며 자발적인 학습을 하게 됩니다.

예컨데 자신의 삶의 목표에 대해 문제의식 조차도 형성되지 않은 사람에게는 백날 종교니, 철학이니 떠들어 봐야 헛수고입니다만, 이미 개별적이고 구체적인 체험들을 통해 자신만의 문제의식을 나름대로 형성한 사람은 공부하고 남의 말을 들을 준비가 된 사람입니다.

아담이 세상의 모든 "것"들을 보고 일일이 이름을 붙였던 것은, 보았기 때문에 가능했던 것입니다. 그러나 우리나라 교육의 대부분은 horse를 보기 이전에 horse라는 이름을 가르치고, 문제의식을 외부에서 학생에게 주입하려 합니다. 그러한 지식의 필요성까지도 암기하고, 이해하도록 강요하는 것이지요.

저는 후학들이 난생 처음 어떤 학문을 공부할 때 처음부터 최고의 대가에게 가서 강의를 듣는다든가 하는 것을 그다지 권하지 않습니다 -- 강의자와 피강의자의 노력에 비해 크게 도움이 되지 않습니다. 이것은 결국, 스스로가 자신만의 문제의식을 갖고 있어야 하며, 또한 그 문제의식은 철저히 자신의 삶에서 우러 나와야 하는 것이기 때문입니다. 그 이후에 훌륭한 선생들을 만나면 정말 비약적인, 계단을 서너칸 뛰어오르는 발전을 할 수 있습니다.

결국 제 후배가 한달 정도만에 그렇게 껍질을 깨고 나오는 발전을 할 수 있었던 것은 그 자신이 늘 "반성적인 학습"을 해오며 자기 영어 공부에 대한 문제의식을 형성했고 궁리해 왔기 때문입니다. 물론 절대적인 영어 공부량(input)이 이미 어느 정도 되어 있었기 때문이기도 합니다. 물길을 열어줄 "열쇠"가 필요했었던거죠. 이미 물은 어느 정도 차 있었고요.

......

권법에서 주먹에 대해 달통한 도사가 "권을 내지르는 법"에 대한 규칙들을 정리를 해서 애제자의 대갈통 속에 아무리 쑤셔넣는데 성공을 한들 그 제자가 도사만큼의 주먹이 나갈리는 만무합니다. "권을 내지르는 법"을 유추해 내기까지 그 스승이 겪은 과정을 제자는 완죤히 쏙 빼먹고 있기 때문입니다. 소위 '몸'이 만들어 지지 않은 것이지요. 제자는 마당 쓸기에서부터 해서, 물 긷기, 기타 등등의 몸의 수련의 과정을 겪어야만 하고, 그 제자가 스승이 정리한 그 규칙의 일련에 손뼉을 치고 춤을 추며 기쁨의 동의를 할 수 있을 정도로 과정의 축적이 이루어진 이후에야 비로소 진정한 '가르침'이 이뤄지는 것이며, 청출어람의 가능성도 생각해 볼 수 있는 것입니다.

......''

이런 동의라는 것은 학습자 자신만의 컨텍스트와 문제의식을 바탕으로 한 것입니다. 우리는 많은 경우, 어떤 지식과 동시의 그 지식의 필요성까지도 지식화해서 외부에서 주입을 받습니다. 하지만 진정 체화된 지식을 위해서는 스스로가 이미 문제의식을 갖고 있어야 합니다.

패턴도 마찬가지인데, 대부분 그 패턴의 필요성을 체감하지 못한 채 그냥 도식적 구조를 외우기에만 주력하는 사람이 많습니다만, 사실 그렇게 되면 어떤 경우에 이 패턴이 필요하고 어떤 경우에는 사용하면 안되는지 등을 알기 힘듭니다. 설령 책에 나온 가이드를 암기했더라도요. 자신의 삶 속에서 문제의식이 구체적으로 실제 경험으로 형성되지 않았기 때문입니다.

DP의 저자(GoF) 중 한 명인 랄프 존슨은 다음과 같이 말합니다:
We were not bold enough to say in print that you should avoid putting in patterns until you had enough experience to know you needed them, but we all believed that. I have always thought that patterns should appear later in the life of a program, not in your early versions.

결국은 어떤 패턴의 필요성을 자신의 경험 속에서 "절감"하지 못한다면 그 패턴을 제대로 아는 것이 아니라고 말할 수 있을 겁니다.

따라서, 패턴 하나를 공부할 때에는 가능한 한 실제 예를 많이 접하도록 해야 합니다. 그리고 패턴을 적용하지 않은 경우에서 그 필요를 느끼고 설명할 수 있게끔 다양한 코드를 접해야 합니다.

패턴 중에 보면 서로 비슷비슷한 것들이 상당히 많습니다. 그 구조로는 완전히 동일한 것도 있죠 -- 초보자들을 괴롭히는 것 중 하나입니다. 이것은 외국어를 공부할 때 문법 중심적인 학습을 하는 것과 비슷합니다. "주어+동사+목적어"라는 구조로는 동일한 두 개의 문장, 즉 "I love you"와 "I hate you"가 구조적으로는 동일할 지라도 의미론적으로는 완전히 반대가 될 수 있는 겁니다. 패턴을 공부할 때에는 그 구조보다 의미와 의도를 우선해야 하며, 이는 다양한 실례를 케이스 바이 케이스로 접하면서 추론화 및 자신만의 모델화라는 작업을 통해 하는 것이 최선입니다. 스스로 문법을 발견하고 체득하는 것이라고 할까요.

DP는 사전과 같습니다. 이 책은 순서대로 소설 읽듯이 읽어나가라고 집필된 것이 아니고, 일종의 패턴 레퍼런스로 쓰인 것입니다.

역시 GoF의 한명인 존 블리스사이즈는 다음과 같이 말합니다:
''The other thing I want to underscore here is how to go about reading Design Patterns, a.k.a. the "GoF" book. Many people feel that to fully grasp its content, they need to read it sequentially. But GoF is really a reference book, not a novel. Imagine trying to learn German by reading a Deutsch-English dictionary cover-to-cover;it just won't work! If you want to master German, you have to immerse yourself in German culture. You have to live German. The same is true of design patterns: you must immerse yourself in software development before you can master them. You have to live the patterns.

Read Design Patterns like a novel if you must, but few people will become fluent that way. Put the patterns to work in the heat of a software development project. Draw on their insights as you encounter real design problems. That’s the most efficient way to make the GoF patterns your own.''

제가 여러번 강조한, 어떤 지식을 체화하기 위해선 그 지식으로 살아야 한다는 말을 여기서도 확인할 수 있군요. 영어를 배우려면 영어로 살고, DP를 배우려면 DP로 살아라. 단순하면서도 아주 강력한 말 아닙니까.

어떤 특정 문장 구조(as much as ...나, no more than ... 같은)를 학습하는데 최선은 그 문장 구조를 이용한 실제 문장을 나에게 의미있는 실 컨텍스트 속에서 많이 접하고 스스로 나름의 모델을 구축(constructivism)하여 교과서의 법칙에 "기쁨에 찬 동의"를 하는 것입니다.

주변에서 특정 패턴이 구현된 코드를 구하기가 힘들다면 이 패턴을 자신이 만지고 있는 코드에 적용해 보려고 노력해 볼 수 있습니다. 이렇게 해보고 저렇게도 해보고, 그러다가 오히려 복잡도만 증가하면 "아 이 경우에는 이 패턴을 쓰면 안되겠구나"하는 걸 학습할 수도 있죠. GoF는 한결 같이 패턴을 배울 때에는 "이 패턴이 적합한 상황과 동시에 이 패턴이 악용/오용될 수 있는 상황"을 함께 공부하라고 합니다.

이런 식의 "사례 중심"의 공부를 위해서는 스터디 그룹을 조직하는 것이 좋습니다. 혼자 공부를 하건, 그룹으로 하건 조슈아 커리프스키의 유명한 A Learning Guide To Design Patterns (http://www.industriallogic.com/papers/learning.html)을 꼭 참고하세요. 그리고 스터디 그룹을 효과적으로 꾸려 나가는 데에는 스터디 그룹의 패턴 언어를 서술한 Knowledge Hydrant (http://www.industriallogic.com/papers/khdraft.pdf) 를 참고하면 많은 도움이 될 겁니다 -- 이 문서는 뭐든지 간에 그룹 스터디를 한다면 적용할 수 있습니다.

LG2DP에는 뒷 부분에 보면 DP를 공부하는 순서와 각 패턴에서 던질만한 질문이 같이 정리되어 있습니다. DP는 순차적으로 공부해야만 하는 것은 아닙니다. 효과적인 공부의 순서가 있습니다.

sorry라는 단어를 모르면서 remorseful이라는 단어를 공부하는 학생을 연상해 보세요. 제 강의에서도 강조를 했지만, 외국어 공부에서는 자기 몸에 가까운 쉬운 단어부터 공략을 하는 것이 필수적입니다 -- 이런 걸 Proximal learning이라고도 하죠. 등급별 어휘 목록 같은 게 있으면 좋죠. LG2DP에서 제안하는 순서가 그런 것 중 하나입니다.

랄프존슨은 이런 "순서"의 중요성에 관해 이런 말을 했습니다:
...but I always teach Composite Pattern, Strategy Pattern, Template Method Pattern, and Factory Method Pattern before I teach Singleton Pattern. They are much more common, and most people are probably already using the last two. ...

그런데 사실 GoF의 DP에 나온 패턴들보다 더 핵심적인 어휘군이 있습니다. 마이크로패턴이라고도 불리는 것들인데, delegation, double dispatch 같은 것들을 말합니다. DP에도 조금 언급되어 있긴 합니다. 이런 마이크로패턴은 우리가 알게 모르게 매일 사용하는 것들이고 그 활용도가 아주 높습니다. 실제로 써보면 알겠지만, DP의 패턴 하나 쓰는 일이 그리 흔한 게 아닙니다. 마이크로패턴은 켄트벡의 SBPP에 잘 나와있습니다. 영어로 치자면 관사나 조동사 같은 것들입니다.

그리고, 이런 마이크로패턴과 함께, 리팩토링을 공부하는 게 좋습니다. 리팩토링은 패턴의 필요를 느끼게 해줍니다. (마틴 파울러의 리팩토링이란 책을 참고하면 됩니다.)

우리가 갖고 있는 지식이라는 것은 한가지 표현양상(representation)으로만 이뤄져 있지 않습니다. "사과"라는 대상을 음식으로도, 그림의 대상으로도 이해할 수 있어야 합니다. 실제 패턴이 적용된 "다양한 경우"를 접하도록 하라는 것이 이런 겁니다. 동일 대상에 대한 다양한 접근을 시도하라는 것이죠. 자바로 구현된 코드도 보고, C++로 된 것도 보고, 스몰토크로 된 것도 봐야 합니다. 설령 "오로지 자바족"(전 이런 사람들을 Javarian이라고 부릅니다. Java와 barbarian을 합성해서 만든 조어지요. 이런 "하나만 열나리 공부하는 것"의 병폐에 대해서는 존 블리스사이즈가 C++ Report에 쓴 Diversify라는 기사를 읽어보세요 http://www.research.ibm.com/people/v/vlis/pubs/gurus-99.pdf) 이라고 할지라도요. 그래야 비로소 자바로도 "상황에 맞는" 제대로 된 패턴을 구현할 수 있습니다. 패턴은 그 구현(implementation)보다 의도(intent)가 더 중요하다는 사실을 꼭 잊지 말고, 설명을 위한 방편으로 채용된 한가지 도식에 자신의 사고를 구속하는
우를 범하지 않기를 빕니다.

하긴, 패턴도 "문제해결"을 위한 한가지 방편에 지나지 않겠군요. 주변에서 "이 경우에는 무조건 이 패턴을 써야 합니다"라고 생떼를 쓰는 사람을 보면 씁쓸한 기분을 감출 수 없습니다.

工夫 열심히 하세요.

--김창준

디자인패턴 커리큘럼:
  1. Design Patterns Explained by Shalloway, and Trott : 최근 DP 개론서로 급부상하고 있는 명저
  2. Design Patterns Java Workbook by Steven John Metsker : DPE 다음으로 볼만한 책으로, 쏟아져 나오는 허접한 자바 패턴 책들과는 엄연히 다름
  3. Refactoring by Martin Fowler : DP 공부 이전에 봐서 문제의식 형성하기 (망치를 들면 모든 것이 못으로 보이는 오류 탈피)
  4. DesignPatterns : Gang Of four가 저술한 디자인패턴의 바이블
  5. DesignPatternSmalltalkCompanion : GoF가 오른쪽 날개라면 DPSC는 왼쪽 날개
  6. Pattern Hatching by John Vlissides : DP 심화학습
  7. Smalltalk Best Practice Patterns by Kent Beck : 마이크로 패턴. 개발자의 탈무드
  8. Pattern Languages of Program Design 1,2,3,4 : 패턴 컨퍼런스 논문 모음집으로 대부분은 인터넷에서 구할 수 있음
  9. PatternOrientedSoftwareArchitecture 1,2 : 아키텍춰 패턴 모음
  10. Concurrent Programming in Java by Doug Lea
  11. Patterns of Software by Richard Gabriel : 패턴에 관한 중요한 에세이 모음.
  12. Analysis Patterns by Martin Fowler : 비지니스 분석 패턴 목록
  13. A Timeless Way of Building by Christopher Alexander : 프로그래머들이 가장 많이 본 건축서적. 패턴의 아버지
  14. A Pattern Language by Christopher Alexander : 상동
  15. Problem Frames by Michael Jackson : Beyond DP(DP를 넘어서). 사실 DP는 더 이상 트랜디하지 못함. DP의 해결(solution) 지향식의 문제점과 극복방안으로서의 문제 지향식 방법

DP를 처음 공부한다면, DPE와 DPJW를 RF와 함께 보면서 앞서의 두권을 RF적으로 독해해 나가기를 권합니다. 이게 된 후에는 ~cpp GoF와 DPSC를 함께 볼 수 있겠습니다. 양자는 상호보완적인 면이 강합니다. 이 쯤 되어서 SBPP를 보면 상당히 충격을 받을 수 있습니다. 스스로가 생각하기에 코딩 경험이 많다면 다른 DP책 이전에 SBPP를 먼저 봐도 좋습니다.

이 정도의 책을 봤다면 POSA와 PLOPD 등에서 자신이 관심이 가는 패턴들을 찾아 읽는 것이 좋습니다. 그리고 동시에 알렉산더의 원저들을 꼭 읽기를 권합니다. 알렉산더를 모르고 패턴을 논하는 것은 칸트를 읽지 않고 순수이성을 논하는 것과 같습니다. 가브리엘의 책이 알렉산더의 사상 이해에 많은 도움이 될 것입니다.

--김창준


오늘 짬이 나서 최근 우리나라의 IT 잡지에 연재되는 DesignPatterns 강좌를 훑어봤습니다. 소감은 한마디로, "이건 패턴을 가르치는 게 아니다!"라는 느낌이었습니다.

몇가지 문제점을 지적하자면:
  • 패턴을 지나치게 실체화, 정형화해서 설명한다.
  • 컨텍스트와 문제상황에 대한 설명이 없거나 부족하다 -- 결과적으로 문제를 해결하기 위해 패턴이 도입된 것이 아니라 패턴을 써먹기 위해 패턴이 도입된 느낌을 준다.
  • 문제의식을 먼저 형성하게 하지 않고 답을 먼저 보여준 뒤 그걸 어디에 써먹을지 가르친다 -- 왜 이걸 쓰는 게 좋은지는 일언반구 언급이 없다. 독자는 "어린아이가 망치를 들고있는 오류"에 빠질 것이다.
  • 패턴이 어떻게 생성되었는지 그 과정을 보여주지 못한다. 즉, 스스로 패턴을 만들어내는 데에 전혀 도움이 안된다. (NoSmok:LearnHowTheyBecameMasters)
  • 해당 패턴이 현실적으로 가장 자주 쓰이는 맥락을 보여주지 못한다. 대부분이 Toy Problem에서 끝난다.

패턴 강좌를 진행하시는 분들이 최소한 알렉산더의 저작 한 권이라도 제대로 읽어봤다면 이런 병폐는 없을 것이라 생각합니다 -- 알렉산더의 저작을 접해보지 못하고서 패턴을 가르치는 사람은 성경을 읽어보지 않은 전도사와 같을 것입니다.

알렉산더가 The Timeless Way of Building의 마지막에서 무슨 말을 하는가요?

At this final stage, the patterns are no longer important ...

The patterns have taught you to be receptive to what is real.

--김창준


Valid XHTML 1.0! Valid CSS! powered by MoniWiki
last modified 2009-05-27 07:09:19
Processing time 0.5839 sec