AndreaSmalltalkLecture:QnA 05
- 질문과 답변-5
- :패턴: 객체지향 패러다임의 철학
패턴: 객체지향 패러다임의 철학
정남님의 글 잘 읽었습니다. 아래 MVC에 대해서 설명을 해 주셨는데요, 결국 리눅스용으로 나온 Smalltalk도 역시 MVC나 기타 다른 짜임새(framework)를 사용해서 GUI를 구현하는군요. 아주 재미있습니다. 저는 Smalltalk를 처음 공부할 때에는 Smalltalk/V를 사용했습니다. 그쪽에서는 Model-Pane이라는 조금은 독특한 체계를 사용했었는데, 배우기도 어렵고 그 당시는 OO에 대한 개념이 아직 덜 정립되던때로 그냥 관둬버렸습니다. 그러나 Dolphin을 알게되면서 나름대로 GUI의 짜임새를 터득하게 됐습니다. 물론 저는 프로그래밍만 들입다 공부하는 입장이 아니기 때문에 Smalltalk에서 GUI의 짜임새를 어느 정도 이해하는데 6개월이라는 시간이 걸렸습니다. :) 아무튼 Dolphin의 MVP(Model-View-Presenter)에 대해서도 인제 개념이 잡히려고 합니다. 말씀하신 MVC와 상당히 흡사한 구조로 되어있다는 것도 이제야 깨달을 수 있어서 다행입니다. 아무튼 Visual Basic이나 Delphi와는 사뭇 다른 GUI 작업 방식이라서 많이 힘들었지만, 아예 예전 것을 완전히 잊어버리려 하고 새롭게 적응하려고 하니 이제 조금씩 뭔가 보이는것 같습니다.
정남님께서도 말씀하셨지만, 저는 디자인 패턴은 결국 "객체지향 패러다임의철학"이라고 생각하고 싶습니다. 1970년대에 구조적 패러다임이 프로그래밍의 주류를 이루고 있을 때, 그 때는 갖가지 알고리듬과 자료구조가 등장했었습니다. 결국 패턴이라는 것도 객체지향 패러다임의 특성을 이용해서 공통으로 쓰기 위한 방법론을 제시한 거라고 생각합니다. 예를 들면 "퀵 소트를 할 때는 어떤 알고리듬이 필요한가?" "스택을 구현할 때는 어떤 알고리듬과 자료구조를 써야 하는가"와 같이 철저히 기능중심의 사고를 해 오던 기능주의에서, 각각의 기능을 어떻게 객체로 만들것인지를 생각하는 구성주의로 패러다임이 바뀌었다고 해야겠지요.
제가 객체지향에 대해서 공부하기 시작한 건 1993년 정도입니다. 그 때 C++이 많이 뜨던 시기였죠. 저도 그래서 함 공부를 해 볼 참으로 C++ 책을 구해서 봤는데, 역시 객체지향 책에서 등장하는 상속성, 다형성, 포장성(encapulation) 등의 개념이 들어있더군요. 그런데 대부분의 C++책이 그렇듯이, 제가 본 대부분의 책들도 C++ 언어의 문법을 위주로해서 설명을 한 것이었습니다. 즉 기존 구조화 프로그래밍의 틀 속에서 C++을 바라보려고 했고, 그래서 결국 C++의 복잡한 문법에 치중한 설명이 나오게 된 것이지요. "음, 과연 이러한 객체지향적인 기법을 어떻게 써먹을까"에 대해서 생각해 봤지만, 상대적으로 구조적 프로그래밍보다는 그 개념이 방대하고 낮설었기에 많은 어려움을 가지고 있었습니다.
1995년 Delphi라는 놈을 보면서 저는 또 한번 경악했습니다. "와, 객체지향이라는게 이렇게 편한거구나"라고 그 때 생각했습니다. 물론 그 때는 엄밀히 말하면 객체지향적이 아니라 "GUI 지향"이라고 해야 옳았습니다. 지금도 그 때 만들어 놓은 바탕글(source)을 들여다보면 제 자신이 한심해집니다. 프로그램이 UI와 완전히 밀착되어있어서 요구사항이 조금만 바뀌어도 프로그램은 거의 엉망이 됩니다. 흡사 GOTO를 남발해서 만들어진 스파게티 코드라고도 생각이 들었습니다. 그러나 그때까지만 해도 "왜 따로 갈래(class)를 만들거나 상속을 받아서 쓰는지"에 대한 생각이 없었습니다.
그런데... 98년부터 Smalltalk 공부를 하면서 저의 이런 생각은 많은 변화를 겪었습니다. 솔직히 98년과 99년까지는 지금까지 내가 생각했던 객체지향이라는 패러다임을 다시 음미해보고, 제 나름대로 이 패러다임을 소화해 가는 시기였습니다. 이제 나름대로 객체지향에 대해서 어느 정도 기반을 다지고 있다고 생각하니, 정남님이 말씀하신 "패턴"이라는 것이 보이더군요.
우리가 의자를 만들기 위해서는 여러 가지 부품이 필요합니다. 작은 나무도막, 큰 나무도막, 나무 판, 못, 망치... 이런 연모들을 잘 조립하면 하나의 의지가 됩니다. 물론 작은 물건을 만들 때에는 아무런 생각 없이 마구 만들면 되지만, 자동차나 집을 만들거라면 좀 더 체계적인 방법을 사용해야 합니다. 이른바 '공법'이라고 하는게 그래서 생긴 것이지요. 똑같은 집을 만들어도 어떤 방법을 사용해서 만들 것인가....
패턴은 바로 그런 공법이라고 생각되어집니다. 패턴이란 게 나올 수 있는 것은, 객체지향의 가장 기본적인 구성 요소인 객체와 지시(message), 그리고 갈래(class)가 있기 때문이라는 정남님의 말씀은 정말 천번만번 옳습니다. 실제적으로 C++이나 Delphi처럼 혼합 객체지향 프로그래밍에서는 생각해 보지 않은 것입니다. 왜냐? 그쪽 언어에서는 맘만 먹으면 쉽게 구조적 프로그래밍의 해법으로 프로그램을 짤 수 있었기 때문이죠. 그러나 Smalltalk는 날랐습니다. 아니, 달라보였습니다. 이제 약 1년 반 정도 Smalltalk를 공부하다 보니, 어느새 "짜임새"(framework)라는게 무언지, 이게 왜 필요한건지, 그리고 패턴이란게 어떤 건지 이제 감이 잡힙니다. 그 동안 Smalltalk의 문법과 바탕 본(base image)에 있는 객체들의 기능을 익히는 단계에서, 이제 제 스스로도 한 단계 더 발전했다는 생각이 들 정도죠.
여러 가지 물건을 조립해서 다른 물건을 만들듯이, Smalltalk에서도 여러 가지의 객체를 조립하거나, 이미 있던 갈래에서 새로운 아랫갈래를 지어내서 문제를 해결하는 여러 가지 방법들이 이제서야 눈에 들어오기 시작했습니다. Smalltalk 시스템 자체가 여러 가지 객체들이 서로 의사소통하면서 이루어지는 것이란 게 정말 신기하기까지 했습니다.
그래서, 며칠 전에 저는 "Design Pattern"과 "Design Pattenr Smalltalk Companion"이라는 두 개의 책을 구입했습니다. 결과적으로 패턴이란 것이 공부할 만한 충분한 가치가 있다는 것, 그리고 이러한 패턴을 잘 공부해 두면 비로소 객 향 프로그래밍의 한 단계를 더 알아나갈 수 있다는게 제 믿음입니다. 여태까지는 객체지향 설계 쪽으로 관심을 갖고 있다가, 구현 쪽에서도 이러한 방법이 있음을 깨닫게 된 제가, 너무 한심합니다. 좀만 일찍 깨달았어도... 결국 정남님의 글이 저에게 아주 큰 도움을 준 셈입니다.
"Design Pattern Smalltalk Companion"에서는 "언어가 다르면 생각이 달라지고, 생각이 다르면 언어도 달라진다"는 말이 있더군요. 솔직히 Delphi나 Visual Basic 같은 여러 가지 도구들은 비슷한 개념을 형성하고 있습니다. 그래서 어느 하나의 도구나 언어에 얽메이지 말라는 선배의 충고가 마음에 와닿았습니다. 그러나 Smalltalk를 쓰면서 생각이 바뀌었습니다. 정남님의 말과 같이, 분명히 Smalltalk에서 생각하는 것과 다른 언어에서 생각하는 것은 많이 다릅니다. 물론 이러한 것들을 잘 조합해서 전체적인 것을 조망할 수 있는 능력은 꼭 필요하겠지요.
여하튼간에, 이제는 객체지향에서 컴포넌트지향으로 옮아가고 있는 이 시점에서, 객체지향 설계 기법과 구현 기법은 나름대로 공부해 볼 충분한 가치가 있다고 생각합니다. 정말, Smalltalk를 배우고 나서는 객체지향이라는 패러다임을 바라보는 시각이 훨씬 다양해짐을 느낍니다.... 아, 이게 객체지향이구나... 이제 조금씩 감이 잡힙니다.
저도 단순히 프로그래밍적이나 기능적인 것에만 치우치지 않고, 그 속에 숨어 있는 철학을 발견할 수 있도록 좀 더 깊이 있게 공부를 해야할 것 같습니다. 정남님, 다음에 또 좋은 글 올려주세요. 고맙습니다.
그럼.