free-vahn

본문

패턴의 설명을 일축할때 신상호님이 말했던 '패턴은 우라다'란 명언을 사용합니다. 패턴은 흔히 반복적으로 발생하는 일반적인 문제와 요구영역에서 해결책을 인도하고 있습니다.

이제와서 패턴을 디자인의 관점으로만 보지 않습니다. 물론 상당부분 디자인의 문제를 포함하고 있지만 POSA 1(Pattern Oriented Software Architecture)[1]의 분류처럼 Architecture, Design, Idiom의 단계와 범위에 따라 분류하기도 하고 Process Pattern[2]이나 Analysis Pattern[3]에서 처럼 소프트웨어 공정과정에서 패턴을 적용하기도 합니다.

좀 더 영역을 확대한다면 형태와 행동을 갖는 모든 것이 패턴일 수 있습니다. 그런 의미에서 가라데의 형이나 태권도의 품세, 태극권의 식(式)은 유명한 패턴이라 할 수 있습니다.

무엇보다도 패턴을 간단명료하게 설명하기위해선 패턴의 아버지인 알렉산더의 말을 빼놓을 수가 없습니다.

“Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice”- Christopher Alexander [AIS+77]


하지만 패턴이란 무공을 펼치는 것은 쉽지 않습니다. 그것은 당구에서 맛세이(=찍어치기)를 하기 위해서 300 다마 정도 되어야 하는 것과 같습니다. 아무나 당구공을 찍어칠 수 있지만 찍어칠 때를 구분하는 것과 때를 안다 하더라도 적절히 적용하기란 아무나 할 수 없죠... 그래서 Fowler는 패턴을 '반쯤 익은 빵'으로 비유합니다. 나머지 반은 내가 지지고 볶아야한다는 거져...

여기에 패턴의 위력과 허수가 존재합니다. customizing해야만 쓸 수 있는거져... 왜냐하면 패턴은 일반적인 내용을 말하지만 나의 컨텍스트는 일반적이지 않기 때문이죠.. (참고로 패턴적용시에 도움이 되는 항목은 - GoF 분류법 기준으로 - Applicability, Consequences, Implementation이 있습니다. 어떤 경우 Structure와 Sample Code는 더욱 혼선을 가져오기도 합니다.)

본인도 그러하거니와 패턴을 적용해서 패턴을 욕하는 대부분의 사례가 이 허수에 빠지는 것입니다. 적용할 경우와 적용법을 모르고 Structure로 대들었을 때죠..


기계론적 세계관에 대한 회의...

근래들어 패턴의 이런 모습에 회의를 느꼈습니다. 사실 패턴 뿐만 아니라 Software Engineering에 대한 회의인데요.. '적용자에 따라 결과가 달라진다면 '공학적'이라 할 수 없다. 적어도 공학이라 한다면 A가 해도 B가 해도 똑같은 결과가 나와야하지 않은가?'란 내용입니다. Software Engineering적 접근은 모든 경우의 수를 predictable할 수 있거나 그렇지 않다면 모든 것을 해치울 수 있는 준비에 그 목적이 있다고 할 수 있습니다. 다분히 공학적이고 기계론적이죠..
하지만 대부분 '모든 것'에 대한 범위나 정도 설정은 겪고나서 정의/해석하게 됩니다.
이런 맥락에서 Software Engineering은 Software Engineering Oriented의 성격이 강합니다. 근대에 이르러 뉴튼과 칸트의 출현은 모든 기계론적 세계관을 일단락했습니다. 인간의 모든 성격을 오성으로 표현할 수 있으며 떨어지는 사과 하나도 역학으로 충분한 설명이 가능합니다. 이런 가정과 전제에서 인간의 인생까지도 기계론적으로 설명 가능합니다. 그래서 기계론을 결정론이라고 부르기도 합니다만...

사실 Software Engineering의 패러다임들은 인문학과 다른 학문의 그것을 많이 차용한 듯 합니다. 50년을 조금 넘는 역사의 문제가 크겠지만 적어도 그것을 능가할 수 없는 무엇이 아쉽습니다. 더구나 Software Engineering 노력이 칸트나 뉴튼이 완결한 세계관에 이르지도 못 한다는게 거듭 아쉽습니다.

다시 패턴의 문제로 돌아가서 패턴은 이런 Software Engineering의 성격을 그대로, 정확히 반영하고 있습니다. 근래들어 전술한 생각과 함께 들었던 회의는 패턴이란 현상의 원리를 정의하는건데 본질에 미치지 않나 싶습니다. 다시 말하자면 패턴이란 반복적이고 유사한 현상에 대한 설명일 뿐이지 본질은 아니지 않는가? - 사실 이 논의를 위해선 현상과 본질, 그리고 원리에 대한 심도있는 개념정리가 필요하겠지만 일단은 유보하겠습니다.
아마도 이 본질, 즉 원리안에 원리가 밝혀진다면 구력 30과 500이 같이 맛세이를 쳐도 같은 결과가 오지 않을까?


[1] Pattern-Oriented Software Architecture, Volume 1: A System of Patterns by Frank Buschmann (Author), Regine Meunier (Author), Hans Rohnert (Author), Peter Sommerlad (Author), Michael Stal (Author)

[2] Process Patterns, : http://www.bell-labs.com/user/cope/Patterns/Process/index.html

[3] Analysis Pattern, Reusable Object Models (Object-Oriented Software Engineering Series) -- by Martin Fowler; Hardcover