한빛출판네트워크

by 최진호 디자인패턴에 대해 컴퓨터 게임을 잘하는 사람들을 보면 그들만의 노하우를 엿볼 수가 있다. 즉, 자신의 움직임에 따라 컴퓨터가 어떻게 움직이는 지를 관찰하고 그 패턴을 외웠다가 유사한 상황이 발생할 때 써먹는다는 것이다. 특히 이런 방법은 오락실 슈팅게임에서는 거의 절대적으로 필요한 것이어서 대부분의 고수들은 어떤 스테이지의 어느 시점에서 어떤 몬스터가 어떻게 나오는지를 완벽하게 외우고 있기 마련이다. 사실 우리가 살고있는 대부분의 것들은 일종의 패턴으로 살아간다. 아침에 일어나서 잠자리에 들기까지 우리가 행동하는 것 역시 자신만의 고유한 패턴이 있다. 물론 자신은 인식하지 못하겠지만 우리는 우리가 특별히 어느 시점에 어떻게 행동해야 할 지 깊게 생각하지 않아도 이제까지의 경험과 습관으로 힘겨운 하루를 아주 능수능란하게 대처하고 있는 것을 가만히 일상을 살펴보면 느낄 수가 있을 것이다. 뒤에서 들리는 자동차 지나가는 소리만 듣고도 어느 쪽으로 피해서 가야 할 지를 안다거나 누군가가 인사를 하면 자연스레 손을 흔든다거나 파란 불이 켜지면 잡생각 중에도 자연스레 횡단보도를 건너는 자신을 발견하는 것은 그리 어려운 일이 아닐 것이다. 당신은 당신 일상에 있어서 패턴을 끊임없이 축적하여 당신 일상의 고수(?)가 된 것이다. 이뿐만 아니라 이러한 패턴은 개인적인 차원에서만 유용한 것은 아니다. 패턴이 적절한 사회적인 동의과정을 거치면 더할 나위 없이 편리한 의사소통의 수단이 될 수 있다. 머리가 아프고 콧물이 나고 열이 나는 현상은 개인적인 체험이지만 그것이 "감기"라는 증상의 패턴임을 일찍 깨닫게 된다면 타인들로부터 그 증상을 해결할 수 있는 효과적인 방법을 더 빨리 얻을 수 있을 것이다. 요컨대 패턴이라는 것은 충분히 개인적인 문제해결 방법인 동시에 사회적인 문제 해결 방법이기도 한 것이다. 그렇다면 전산 분야에 있어서 패턴은 없는가? 아니다 있다. 우리는 분명 수많은 패턴을 공부해왔다. 자료구조와 알고리즘등 우리가 익힌 많은 것들은 바로 경험한 이들의 노하우를 바탕으로 만들어진 패턴의 모음이라고 해야겠다. 이렇게 많은 패턴을 익히고 졸업을 하여 개발자의 길을 처음 걷게 되면 대부분의 사람들은 기가 죽는다. 세상에는 너무나 많은 고수들이 있고 배워야 할 것은 넘쳐 나기 때문이다. 일단 자기 위의 팀장부터가 남달라보인다. 소위 다양한 필드경험으로 무장한 사람들의 재빠른 판단 능력을 보면서 이제 개발자로서 첫 발을 디딘 우리의 초보 개발자들은 어리둥절할 뿐이다. 하지만 어쩌면 이런 상황 역시 위의 슈팅게임을 잘하는 이라면 어떻게 해야 할 지를 알 것이다. 결국은 자신이 직접 필드에 나서야만 하고 필드 경험을 통해 패턴을 익혀가는 수밖에. 동전을 오락기에 쑤셔 박아가며 투자하는 수밖에…. 하지만 선배들의 경험을 활용하는 방법은 없을까? 선배들의 각각의 노하우가 패턴으로 정의 될 수 있다면, 그래서 그것들을 습득할 수 있다면 그것은 고수가 되는 지름길이 될 수도 있을 것이다. 그렇게 놓고 본다면 패턴에는 수도 없이 많은 종류가 있을 것이다. 알고리즘 수준의 테크닉도 있을 것이고 설계적인 측면에서 능력, 프로세스를 관리하는 방법, 게다가 팀원 관리나 리스크 관리까지 다양한 분야에 패턴은 존재할 것이다. 하지만 여기서는 설계적인 측면에서 패턴, 즉 디자인 패턴을 알아보려 한다. 서론이 참으로 길었다. 디자인 패턴이란 경험 있는 개발자들이 오랜 경험을 통해 유용하다고 생각하는 객체들간의 일반적인 상호작용 방법들을 모아놓은 패턴의 목록이라고 할 수 있다. 또한 어떻게 하면 객체들이 다른 객체와 뒤엉킴 없이 상호간에 통신이 이루어지고 서로 구조적인 조화를 이루어 낼 수 있겠는가에 대한 기술이라고 할 수가 있겠다. 에릭 감마는 다음과 같은 말로 디자인패턴이 필요함을 역설한다. "객체지향적인 소프트웨어를 설계하는 것은 어렵다. 하지만 재사용 가능한 객체지향적인 소프트웨어를 설계하는 것은 더더욱 어렵다" 즉, 디자인 패턴의 목적은 개발자 혹은 설계자 상호간의 의사 소통을 위한 수단만이 아니라 재활용성이 있는 프로그래밍 솔루션을 만들기 위해서 필요한 것이다. 디자인 패턴의 역사는 그리 길지 않다. 건축가인 크리스토퍼 알렉산더의 패턴 연구를 기초로 커닝햄과 벡의 스몰토크에서 패턴 연구를 시작으로 일명 Gang of Four(GOF)라 불리는 감마와 헬름, 존슨, 블리사이즈 이들 네 명이 저술한 『Design Patterns』가 나와서 세상에 알려지고 지금에 이르기까지 고작 10여년밖에 되질 않았다. 하지만 이들이 펴낸 『Design Patterns:Elements of Reusable Object-Oriented Software』는 90년대에 나온 컴퓨터서적 중 가장 영향력있는 서적으로 손꼽히고 있으며 지금까지도 많은 개발자들에게 영감을 주고 있다(아마 앞으로도 그러할 것이다). 물론 디자인패턴이 GOF의 것만 있는 것은 아니다. 그 외에도 수많은 종류의 패턴들이 즐비하다. 많은 사람들이 GOF에서 시작을 하고 있고 그것은 적당한 방법이며 최고의 안내자를 만난 것이다. 하지만 어떠한 서적으로 공부를 시작하든지 간에 객체지향 프로그래밍에 대한 전반적인 지식과 UML표기법에 대한 어느 정도의 이해가 우선적으로 요구된다. 때론 GOF가 초보자에게 디자인패턴에 대해 잘못된 인식을 갖게 하거나 고정 관념을 갖게 할 우려도 있을 수 있다. 디자인 패턴은 이론이 아닌 실제이며 현장에서 몸으로 느끼고 생각으로 담아야만 제대로 된 맛이 나올 수 있는 것이기 때문이다. 그것에 대해서는 존 블리사이즈의 『Pattern Hatching』의 첫번째 장에 잘 설명하고 있다. 결국 중요한 것은 디자인 패턴 자체가 아니라 디자인 패턴을 통해 배운 영감과 자신의 경험을 토대로 한 실제 설계에서의 유연한 적용이며 자신만의 디자인 패터닝 방법을 익히는 것이다. 만약 여러 서적이나 웹상의 정보를 통해 디자인패턴 분야에 매력을 느낀다면 블리사이즈의 『Pattern Hatching』이나 코우드의 『Java Design』을 읽어보기를 권한다. GOF의 Design Patterns가 디자인패턴에 대한 레퍼런스라면 이 두권의 서적은 그런 각각의 패턴들을 어떻게 실무적으로 응용할 수 있는지에 대해 설명할 것이다. 이미 『Pattern Hatching』이나 『Java Design』까지 읽었다면 당신은 개발방법론의 세계에 처음 발을 들인 셈이다. 자 이제 디자인패턴의 구체적인 이해를 돕기 위해서 MVC(Model/View/Controller) 개념을 살펴보자. MVC는 스몰토크라는 프로그래밍 언어에서 사용자 인터페이스를 사용하기 위해 고안된 것으로서 Model은 데이터 및 정보를 나타내는 모든 객체, View는 화면에 보여지는 형태들을 나타내는 객체, 그리고 Controller는 사용자의 입력 및 행동에 따른 사용자 인터페이스의 결과 출력을 나타내는 방식을 정의하고 있다. 따라서 MVC를 이용하여 시스템을 설계하고 구현하면 각 객체들을 기능별로 분리할 수 있기 때문에 시스템의 유동성과 재사용성이 증가하게 된다. 이런 맥락에서 MVC는 패턴과 많은 유사점을 지니고 있다. 실제로 MVC 안에는 다양한 패턴들이 담겨있다.

위의 그림에서 보는 바와 같이 MVC에서는 뷰와 모델을 철저하게 분리하기 때문에 단일 시스템에 대해 다양한 형태의 뷰를 제공할 수 있도록 한다. 즉, 모델을 한번 정의하면 새로운 뷰를 다시 만들어도 모델을 다시 정의할 필요는 없다. 이러한 MVC모델을 사용하고 있는 대표적인 사례는 자바의 Swing, 즉 JFC를 들 수가 있다. JFC는 MVC를 크게는 Model과 UI로 분리하여 MVC에 근접한 시스템을 사용하여 재사용성과 확장성을 제공하고 있다. 자바에 관심이 있는 독자라면 제공되는 각종 소스를 통해 JFC의 멋진 구조를 탐험해보길 바란다.

이러한 MVC기반의 패턴에는 Observer 패턴이나 Composite 패턴, Strategy 패턴, Factory, Decorator 패턴 등 다양한 디자인패턴이 담겨있다. 이러한 다양한 패턴들을 부족한 지면에 모두 소개하는 것은 힘들므로 여기서는 디자인패턴의 종류를 살펴보기로 한다. 패턴 카탈로그라고 불리는 GOF의 Design Pattern에서는 패턴을 크게 세 종류로 나누고 있다. 즉, 생성 패턴(Creational Pattern), 구조화 패턴(Structural Pattern), 행위 패턴(Behavioral Pattern)으로 나누고 있다.

• 생성 패턴 객체 생성 과정을 추상화하는 패턴을 말한다. 굳이 객체를 직접 생성하지 않고 캡슐화하고 생성 방식을 숨기고 일반화하는 이유는 우선 전체적인 시스템 구성의 유동성이 향상되어 객체 생성 방식을 다양한 방식으로 진행할 수 있기 때문이다.
• 구조화 패턴 객체간의 협력을 통해 어떤 일을 취하고자 할 때, 객체들을 조직화하는 방식을 정의하고 있다. 무엇보다 새로운 기능을 구현하고 추가하고자 할 때 객체들을 구성하는 방식에 초점을 맞추고 있다. 예를 들면 런타임시에 객체들간의 구조를 변경하는 컴포지트 패턴을 통해 객체 구성에 유동성과 확장성을 꾀할 수가 있다.
• 행위 패턴 객체간의 연동에 대한 유형을 정의하고 있다. 특히 런타임시에 어려운 복잡한 제어 흐름을 결정지을 때 사용되는 패턴들이다.

지금까지 디자인패턴에 대한 소개를 하였다. 만약 디자인패턴에 대해 익숙하지 않은 독자라면 정말로 디자인패턴이 유용한 것인가라는 의구심을 품을 것이다. 하지만 백문이 불여일견. 실제로 몸으로 체득하지 않고는 디자인패턴의 실제의 유용성을 알 길이 없다. 독자가 충분히 개발자로서의 경험을 갖고 있다면 이미 독자의 경험속에는 디자인패턴처럼 일반화되지 않았을 뿐, 자신만의 패턴을 갖고 있을 것이다. 만약 그렇다면 디자인패턴은 새로운 매력으로 다가갈 수 있을 것이라고 본다. 물론 초보 개발자에게 디자인패턴은 너무 막연할 것이다. 하지만 초보 개발자도 디자인패턴을 익히면 짧은 시간에 많은 것을 보는 눈을 키울 수 있을 것이라고 본다. 아는 것만으로는 소용이 없다. 자신이 직접 현장에서 패턴을 적용하고 자신만의 패턴을 고안하다보면 디자인 패턴이 얼마나 중요하고 편리한 방법인지를 느낄 수 있을 것이다.