라이브러리
프로그래밍언어, 각종코드, 관련동향, 논문 등의 저장소
[기업 환경에 닷넷 적용하기] ③ 솔루션 패턴 해부하기

[기업 환경에 닷넷 적용하기] ③ 솔루션 패턴 해부하기

 

연재순서
1.제대로 된 컴포넌트를 위한 프리젠테이션 레이어 설계하기
2.비즈니스 로직 레이어 설계와 물리적 구현을 위한 필요 사항
3.엔터프라이즈 솔루션 패턴 해부하기
4.닷넷의 웹 프리젠테이션 패턴
5.닷넷 개발에서 UML과 케이스 툴의 사용

 

디자인 패턴은 양날의 검이다. 최근 들어 특히 패턴을 최대한 반영하지 않은 것이 차라리 좋은 설계라는 말이 공공연히 나돌고 있으며, 안티 패턴 웹 사이트도 생겨나고 있다.

하지만 패턴은 엔터프라이즈 솔루션을 설계하고 작성할 때 그리고 결정 사항들을 효율적으로 공유하기 위한 목적으로 사용될 때 프로젝트의 성공에 기여할 수 있는 훌륭한 선물이 된다. 이번 호에서는 닷넷 기반 기업용 응용 프로그램의 설계와 구현에서 사용될 수 있는 디자인 패턴들에 대해 살펴보자.

디자인 패턴은 버클리 대학 명예 교수이자 건축가인 크리스토퍼 알렉산더에 의해 처음 제안된 개념이다. 알렉산더 교수는 패턴을 다음과 같이 정의했다.

“각각의 패턴은 우리를 둘러싸고 있는 환경에서 반복적으로 나타나는 특정한 문제와 그에 대한 해결책을 설명한다. 그리고 그 해결책은 계속 사용될 수 있기 때문에 동일한 과정을 반복할 필요가 없다.”

알렉산더 교수는 여러 책을 저술했는데, 『The Timeless Way of Building』과 『A Pattern Language』등에서 그의 세계관을 철학적으로 풀어냈다. 소프트웨어 설계에서 나타나는 패턴은 결국 건축가인 알렉산더 크리스토퍼의 아이디어에서 나온 것이며, 켄트 벡과 커닝헌에 의해 소프트웨어 세계로 끌어들였고, 에릭 감마를 위시한 네 명의 일당들(Gangs of Four, 이하 GoF)이 전산에서의 디자인 패턴을 정리했다. 곧, 소프트웨어 전문가들은 패턴의 가치를 디자인 경험을 공유하기 위한 언어로 인식하였다.

엔터프라이즈 솔루션들은 매우 복잡하다. 또한 솔루션이라도 시간과 의뢰인에 따라 시시각각 변화하는 요구사항을 모두 만족하기에는 거의 불가능하다. 지금 설계 또는 작성하고 있는 솔루션의 요구사항이 어떻게 변화할지 정확하게 예측하지는 못한다 하더라도 앞으로의 변화에 대해 적응하고 확장 가능할 수 있도록 작성되어야 한다. 그렇다면 설계자 또는 개발자는 어떻게 설계하고 코드를 작성하는 것이 좋은 설계인지에 대해 의문이 생기게 된다. 지금 작성하고 있는 설계 문서 또는 코드가 바른 설계인지 나쁜 설계인지 믿을 수 없다는 것이다.

이런 경우, 설계자에게 오아시스 같은 해답을 내려줄 수 있는 것이 바로 ‘디자인 패턴’이다. 문제를 해결하기 위한 간단하고 작은 메커니즘에서 시작하여 크고 복잡한 시스템으로 결합되는 형태의 여러 디자인 패턴들은 경험 많은 개발자들과 설계자들의 노력 및 시행착오 속에서 정립된 것이고, 그들의 갖은 노하우에서 비롯된 귀중한 지식들이자 산출물이다.

누군가 이름붙인 특정 디자인 패턴을 그대로 도입한다고 해서 문제가 곧 해결되는 경우는 드물지만, 디자인 패턴들은 좋은 설계와 코드 구현의 올바른 가이드가 되어줄 수 있다. 또한, 패턴은 간단한 메커니즘을 문서화할 수 있어 업데이트와 후임 개발자들의 소중한 교육 자료로 활용될 수 있다.

디자인 패턴은 마이크로소프트(이하 MS) 플랫폼 기반 개발에서는 그다지 중요한 역할을 해오지 않은 것 같아 보였다. 하지만 주로 객체지향 환경에 맞춰진 디자인 패턴을 비주얼 베이직에서 활용하는 방법에 대한 연구 등이 활발하게 이뤄졌고, GotDotNET 등의 여러 커뮤니티에서는 몇 해 동안 시스템 아키텍처와 소프트웨어의 개발에 적용되는 패턴들을 발견해 왔다. 또한 MS는 여러 고객과 파트너 기업, 그리고 내부 개발자들의 피드백에 의해 MS 플랫폼에 특화된 디자인 패턴들을 정리할 필요가 있다고 느꼈다. 그 산물이 바로 ‘엔터프라이즈 솔루션 패턴(Enterprise Solution Patterns)’이다.

MS는 몇 년 전에 닷넷 엔터프라이즈 아키텍처 센터(.NET Enterprise Architecture Center)를 통해 이 디자인 패턴들을 정리해서 공개했고, MSDN 웹 사이트의 「Enterprise Solution Patterns Using Microsoft.NET(참고자료)」을 통해 이를 확인해 볼 수 있다. 여기서는 단지 이 패턴들을 정리 요약하고, 이런 패턴들을 적용해 설계 및 작성해 본 경험을 풀어보고자 한다. 필자가 참여한 몇몇 기업용 응용 프로그램에서 이 패턴들은 솔루션의 재사용성과 확장 가능성을 높이는데 커다란 기여를 했다. 이번 호에서는 이러한 엔터프라이즈 솔루션을 작성하기 위한 패턴이 어떻게 구성되는지에 대해 알아보도록 한다.

디자인 패턴 책을 달달 외운다?
먼저 디자인 패턴과 관련해서 겪은 몇 번의 황당한 얘기들로 시작해 보자. 필자가 근무하는 기관에서 개발자를 고용하기 위해 공고를 내고 몇 번의 면접을 실시했다. 면접을 본 몇몇 개발자들에게 디자인 패턴에 대해 아느냐고 물어봤다. 한 개발자는 당연한 듯이 “그건 기본 아닙니까?”라고 당당하게 얘기하기에 패턴 기반 프로그래밍의 경험이 아주 풍부할 것으로 생각하고 이야기를 계속 진행하다보니, 그가 이야기하는 디자인 패턴은 웹 디자인을 이야기하는 것이었다. 다른 개발자는 디자인 패턴이라는 말이 나오자마자 GoF의 『디자인 패턴』에 나오는 패턴의 이름들을 좔좔 외워댔다. 디자인 패턴의 이름을 다 외우고 있는 건 좋은데, 어떤 경우에 어떤 패턴을 적용했느냐는 질문에는 대답하지 못하고, 다음과 같은 대답이 돌아왔다.


“그냥 책 사서 책대로 코드만 짜봤습니다”


패턴 기반 개발 경험이 많은 개발자들은 패턴을 익히는 것은 바둑에서 정석을 익히는 것과 같다고 이야기한다. 바둑에서 정석의 이름을 외우거나 내용을 암기하는 것은 실전에 아무런 도움이 되지 못하듯이 패턴의 기계적 학습은 실무에 아무런 도움을 주지 못한다고 이구동성으로 이야기한다. GoF는 소프트웨어 디자인 패턴을 다음과 같이 이야기한다.

“설계 패턴은 객체지향 시스템 안에서 반복해 등장하는 설계와 관련된 문제들을 해결하기 위한 일반적인 기법에 이름을 붙이고 동기를 부여하고 설명을 한다. 그것은 문제와 해결책을, 그리고 그 해결책을 언제 적용해야 하는지, 적용한 결과는 무엇인지 등을 설명한다. 또한 실질적인 구현에 대한 힌트와 예제도 제공한다. 해결책은 문제를 해결하기 위한 필요한 객체와 클래스를 일반적인 방식으로 배치한다. 해결책은 주어진 문제를 특정한 문맥 안에서 해결하기 위해서 다듬어지고 구현된다(참고자료)”

중요한 것은 패턴의 이름이나 구현된 코드가 아니라 그 이름이 담고 있는 내용이라는 것이다. 패턴은 소프트웨어의 설계에서 어떤 문제에 직면했을 때, 그 문제가 주어진 환경 내에서 반복하여 발생되는 것이라면, 그 문제를 기술하고 그 문제에 대한 솔루션을 제시해주는 역할을 한다. 패턴 기반 프로그래밍에서 가장 중요한 것은 특정 패턴이 어떻게 생겼느냐, 그 패턴의 이름은 무엇이냐, 그 패턴에 참여하는 객체들은 어떤 역할로 구성되느냐 하는 것이 아니고 당면한 문제가 무엇인지를 파악하는 것이다.

패턴은 어떠한 환경에서 자주 발생하는 문제들을 해결하기 위한 솔루션을 제시하고, 그 솔루션은 문제를 해결하기 위해서 함께 동작하는 두 개 이상의 클래스, 객체, 서비스, 프로세스, 서비스, 쓰레드, 컴포넌트, 노드 등이 유기적으로 엮여 있는 간단한 메커니즘일 뿐이다.

설계 패턴들은 ‘문제-해결책’의 쌍으로 제공되고 이해되어야 한다. 특히 디자인 패턴을 처음 접하는 개발자들은 어떠한 문제를 해결하건 간에 설계 패턴을 활용해야 한다는 강박증에 사로잡혀 있는 경우가 많다. 하지만 설계 패턴을 적용하지 않고도 해결할 수 있는 그것을 적용하지 않는 것이 바람직한 설계가 되는 경우가 대부분이다. 문제를 파악하는 것이 설계에서 가장 중요한 요소가 되고, 어떠한 패턴을 적용할 것인지는 그 다음에 생각할 문제가 되어야 한다.

MS의 「Pattern & Practice」에서는 시스템 내의 모든 쿼트(Quote)들을 관리하는 프로그램의 예를 설명하면서singleton 패턴을 예로 들어 설명한다. 전체 시스템에서 인용부호는 수도 없이 등장한다. 쿼트 하나를 관리하기 위해서 하나의 인스턴스를 생성하는 것은 틀림없는 낭비이다. 이런 경우, 시스템 내의 모든 인용부호는 오직 하나의 클래스 인스턴스에서만 관리되도록 설계되어야 한다. 이 문제에 대한 간단한 해결책은 다른 클래스가 해당 클래스를 생성할 수 없도록 생성자가 Private인 QuoteManager 클래스를 생성하도록 설계하는 것이다. 이런 식의 ‘문제-해결책’의 쌍으로서 Singleton 패턴을 살펴보자.


◆ 상황 : 초기화 과정을 제어함으로써 클래스에 대한 액세스를 제어한다.
◆ 문제 : 응용 프로그램은 전역적으로 접근되거나 유지되어야 하는 특정한 형식의 데이터를 포함한다. 동시에, 종종 이 데이터 형식은 시스템 내에서 고유하다. 어떻게 하면 클래스에 대한 액세스 가능한 인터페이스를 제공하면서 시스템 내의 인스턴스의 수를 제어할 수 있을까?
◆ 솔루션 : 클래스는 단일 인스턴스를 생성하고 해당 인스턴스에 대한 전역적인 액세스를 제공해야 한다. GetInstance라는 정적 메쏘드가 반환하는 Singleton 클래스의 정적 인스턴스를 포함하는 클래스를 생성한다.


 

사용자 삽입 이미지
<그림 1> 클래스 설계


여러 설계 패턴들은 이러한 문제-해결책 형태로서의 쌍으로 인식되어야 한다. 예로 보여준 Singleton 패턴을 닷넷 기반 개발에 적용하여 사용하는 방법은 무엇일까? 그것은 닷넷 개발자들이 알아서 해야 할 일이다. <그림 1>과 같이 설계된 구조라면 구현하는 것은 그리 어렵지 않다. 패턴 기반 개발에서 가장 중요한 것은 문제를 제대로 파악하는 것이다. 어떤 패턴을 적용하여 개발할 것인가 하는 것은, 문제가 제대로 파악된 다음에 생각해야 한다.

패턴의 추상화 수준
설계 패턴을 공부하기 위해 가장 많이 접하게 되는 책, 설계 패턴의 바이블이기도 한 GoF의 『디자인 패턴』은 주로 코드 차원에서의 설계 패턴들을 다루고 있다. 앞에서 예로 들었던 Singleton 패턴 역시 코드 수준에서 생각할 수 있는 패턴들이다. 그래서 설계 패턴이라고 하면 GoF가 정리한 패턴 위주의 코드 수준 활용을 생각하기가 쉬운데, 응용 프로그램의 추상화 수준이 여러 단계 이듯이 설계 패턴에서의 추상화 수준도 존재한다. 다음과 같은 상황에 처해있다고 하자.

상황 :크고 복잡한 시스템을 다루고 있으며, 시스템을 분해하여 복잡성을 관리하고자 한다.

이 상황에서 시스템 복잡성을 어떻게 관리할 것인가 하는 것이 문제로 던져진다. 솔루션을 잘 작성하기 위해 다음과 같은 문제를 제시할 수 있다.

질문 :유지 보수 가능, 재사용성, 확장성, 견고성, 보안과 같은 기능적인 요구사항들을 만족하기 위하여 응용 프로그램을 어떻게 작성할 것인가?

원망같이 들리는 저 ‘어떻게’를 위하여 수없이 많은 개발자들이 밤 새워가며 고민들을 했을 것이다. 이 문제를 해결하기 위해 제시되는 것은 의존성 관리와 상호 교환이 가능한 컴포넌트의 사용이라는 간단한 방법이다. 이 문제는 『Pattern & Oriented Software Architecture』에 소개된 Layers 패턴을 적용하여 해결할 수 있다.

해결책 :솔루션을 계층 집합으로 구성한다. 각 계층은 반드시 응집되어야 하고 동일한 추상화 수준이어야 한다. 각 계층은 아래 계층과 느슨한 결합(Loosely Coupled)으로 이루어져야 한다.

사용자 삽입 이미지
<그림 2> Layers 패턴


구현은, 물론 특정 플랫폼 하에서 개발하는 개발자들의 몫이 된다. 닷넷 플랫폼 기반 개발이라면 이러한 구현은 너무도 간편하게 할 수 있다. 이러한 높은 수준의 메커니즘은 앞에서 예제로 살펴본 Singleton 패턴의 메커니즘보다 훨씬 복잡하다(물론 GoF의 여러 패턴 중에서 Singleton 패턴이 가장 간단한 구조를 가지고 있긴 하다).

Layers 패턴의 경우, 장점은 계층화된 조직이 소스 코드의 변경 효과를 코드가 속한 계층에 국한시켜, 전체 시스템에 영향을 주는 것을 막아준다. 이는 각 계층 간의 의존성 관계를 잘 설계함으로서 가능해진다. 각 계층 내의 독립적인 컴포넌트들이 시스템의 다른 영역들과의 충돌을 방지해 주는 메커니즘을 가지게 된다. Layers 패턴은 일반적으로 네트워크 프로토콜, 시스템 소프트웨어, VM 등과 같은 분야에 활용된다.

하지만 Layers 패턴이 모든 문제를 해결해 주지는 못한다. 특히, 기업용 응용 프로그램 분야에서 개발자들은 비즈니스 로직을 효율적으로 관리할 수 있도록 해야 하고, 데이터베이스와 같이 복잡하고 가변적이며 비싼 리소스를 활용해야 한다. 비즈니스 솔루션들은 비즈니스 로직을 효율적으로 사용하고 데이터베이스 리소스를 관리하는 것이 관건이 되므로 Layers 패턴은 기업용 응용 프로그램을 작성할 때 당면하는 문제에 대한 해결책이 되어 줄 수가 없게 된다. 그러면 다음과 같은 상황에 직면한다.

상황 :응용 프로그램을 구성하기 위해서 계층을 사용하는 비즈니스 솔루션을 작성하고 있다.

상황에 직면하면 다음과 같은 문제가 제시된다.

문제 :비즈니스 로직을 재사용하고 융통성 있는 배포를 제공하며 데이터베이스와 같은 리소스에 효율적으로 연결하기 위하여 응용 프로그램을 어떻게 구성할 것인가?

해결책은 여러 가지 생각해 볼 수 있겠지만, 이러한 문제에 대한 해결책을 제시해 주는 패턴은 Therr-Layered Application 패턴이다.

해결책 :프리젠테이션, 비즈니스 로직, 데이터액세스라는 3계층을 생성한다. 각 계층은 다음과 같이 구성한다.


◆ 프리젠테이션 계층 - 뷰와 관련된 모든 컴포넌트를 이 계층에 위치시킨다.
◆ 비즈니스 계층 - 비즈니스 로직을 구현하는 모든 컴포넌트들을 이 계층에 위치시킨다.
◆ 데이터 액세스 계층 - 데이터베이스 클라이언트 액세스와 헬퍼 클래스들을 포함한 모든 데이터베이스 관련 코드를 이 계층에 위치시킨다.


각 계층을 구성할 때 주의 사항은 다음과 같다.


◆ 비즈니스 로직의 컴포넌트는 잘 알려진 인터페이스(닷넷의 예를 들면 리스트를 표현하는 IList 인터페이스 등)를 구현하게 구성하여 각 계층 간의 통합 가능성과 교체 가능성을 높이도록 설계한다.
◆ 데이터 액세스 계층은 리소스를 관리할 때 커넥션 풀링을 처리할 수 있어야 하며, 비즈니스 계층의 컴포넌트들과 상호의존 관계를 가져서는 안된다.


 

사용자 삽입 이미지
<그림 3> Three Layered Application 패턴


이런 구현은 너무도 당연시 되는 구조이지만 문제를 생각하지 않고 무조건 이런 구조를 따라 설계하거나, 이런 문제가 제시됨에도 불구하고 이러한 구조를 따르지 않는 경우가 허다하다. 무조건 이러한 패턴을 따르는 것이 정답이라는 것은 아니지만, 경험 많고 능력 있는 개발자들이 정리한 이러한 패턴에 따라 문제를 해결하는 것이 대부분의 경우 정답이 되어준다.

잊지 말아야 할 것은 패턴과 패턴 응용 프로그램을 잘 구분해야 한다는 것이다. 패턴 그 자체가 응용 프로그램일 수는 없다. 패턴은 문제-해결책 쌍으로서의 일반화된 해결책일 뿐이다. 그 문제의 해결책인 패턴을 응용하여 작성된 프로그램이 패턴 응용 프로그램이 된다. 패턴은 일반화된 문제 해결책 모음이고, 특정 요구사항을 특정 패턴을 사용하여 특정한 문제를 해결한 것이 패턴 응용 프로그램이라는 것을 알고 설계해야 한다.

Three-Layered Application 패턴을 조금 응용하면 더 확장성 높은 응용 프로그램을 만들 수 있다. 최근 크게 이슈화되고 있는 웹 서비스 응용 프로그램을 생각해 보자. 작성한 응용 프로그램을 스마트 클라이언트에서 동작하게 한다거나 언제, 어디서든 실행될 수 있는 웹 서비스 응용 프로그램으로 확장해야 할 필요가 있을 때, Three-Layered Application 패턴을 활용하기가 곤란해진다. 그렇다면 다음과 같은 질문이 대두된다.

문제 :응용 프로그램이 매우 유동적인 소스로부터 데이터와 논리적인 요소들을 제공하고 사용하기 위해서 응용 프로그램을 어떻게 구성해야 할까?

해결책은 Three-Layered Service Application 패턴이 제시한다. 문제 해결을 위해서 비즈니스 계층이 서비스를 제공하는 Service Interface들을 제공하는 것이다. 또한, 유동적인 데이터 소스로부터 데이터를 제공받기 위해서 데이터 액세스 컴포넌트들이 아닌 서비스 에이전트 컴포넌트들로부터 소스를 제공받을 수 있도록 설계하는 것이 해결책이다.

해결책 :응용 프로그램의 로직을 전체 시스템 기능의 일부를 제공하는 협력 서비스 집합으로 분해시킨다. 다음으로 도메인 계층에서 내부 구현에 독립적인 각각의 서비스에 대한 Service Interface를 명시한다. 마지막으로 다른 서비스 제공자와 커뮤니케이션하기 위하여 Service Agent를 사용하기 위해서 데이터 액세스 계층을 확장한다.

사용자 삽입 이미지
<그림 4> Three-Layered Services Application 패턴


Three-Layered Service Application 패턴은 연재 첫 회에서 살펴보았던 응용 프로그램 아키텍처의 구조와 거의 일치한다. 물론, 응용 프로그램의 요구사항이 유동적인 소스로부터 데이터를 제공받거나 유동적인 클라이언트에 서비스를 제공하는 경우가 아니라면 Three-Layered Application 패턴으로 충분하다.

패턴 클러스터
지금까지 살펴본 바와 같이 Three-Layered Services Application 패턴은 Three-Layered Application 패턴에서 확장되었고, Three-Layered Application 패턴은 Layers 패턴에서 확장되었다. Layers 패턴의 변형은 응용 프로그램의 계층화에 대한 공통적인 접근 방법을 표현하는 패턴 클러스터를 구현한다. 패턴 클러스터링은 이러한 상황에서 그룹지어질 때 유사한 패턴 간의 논리적인 그룹화를 의미하게 된다. 패턴을 굳이 그룹화하여 분류할 필요는 없지만, 이런 클러스터된 패턴의 개념은 전체 응용 프로그램을 구성하기 위해 패턴 뷰를 확장하고 솔루션 영역에서 유사한 개념을 설명하는 패턴 클러스터를 명시할 때 상당히 유효할 뿐만 아니라, 프로젝트에 새로 투입되는 개발자의 교육 자료로도 훌륭히 활용된다.

사용자 삽입 이미지
<그림 5> Layers 패턴에서 확장되는 패턴 클러스터


GoF가 정리한 디자인 패턴을 살펴보면 각 패턴들은 생성, 구조, 동작 등의 세 집합으로 분류된다. 객체를 생성하는 작업을 위해서라면 추상 팩토리 패턴이나 singleton 패턴을, 구조를 결정해야 한다면 Composite 패턴이나 Facade 패턴을, 동작을 결정하는 작업이라면 Visitor 패턴이나 Observer 패턴을 사용할 수 있다.

또한 각각의 패턴들은 다른 패턴들과 관계를 가지고 여러 가지의 패턴을 묶어 다른 하나의 패턴으로 사용하기도 한다. Observer 패턴은 MVC(Model-View-Controller) 패턴의 일부분을 구현하기 위해서 사용되고, Command 패턴은 Front Controller 패턴의 일부 구현에 사용된다. 이런 패턴들 간의 관계가 없다면, 엄청난 패턴의 바다에서 표류하게 될 가능성이 높다. 객체지향 프로그램 개발자들이 패턴을 받아들인 이유는 패턴이 관계들을 기술할 수 있기 때문이다.

이렇듯이 패턴 간의 관계를 도표화하면 하나의 패턴에서 그와 관련된 다른 패턴을 찾아 응용 프로그램을 구성하는데 큰 도움을 준다. 하지만 응용 프로그램을 작성하기 위해 어디에서 어떻게 시작해야 할지에 대해서는 알려주지 않는다. 하지만 단순히 분류에 그치지 않고 <그림 5>처럼 패턴을 클러스터링하면, 어떤 패턴에서 응용 프로그램을 시작하여야 할지를 잘 알 수 있게 된다. MS의 「Patterns & Practices」에서는 현재 크게 다섯 가지의 패턴들을 분류한다.


◆ Enterprise Solution Patterns Using Microsoft .NET
◆ Data Patterns
◆ Integration Patterns
◆ Describing the Enterprise Architectural Space Testing Software Patterns


가장 유명하며, 가장 많이 활용되는 Enterprise Solution Patterns using Microsoft .NET에서는 현재 <표 1>과 같은 패턴 클러스터들을 구분하고 있다.

사용자 삽입 이미지
<표 1> Enterprise Solution Patterns using Microsoft .NET의 패턴 클러스터


또 반드시 알아야 할 것은, 각 패턴들은 서로 다른 추상화 수준에 존재한다는 것이다. 개발자는 수없이 많은 페이지에 대한 요청을 중앙 집중화하기 위하여 Front Controller 패턴을 가장 효율적으로 구성하는데 관심이 많겠지만, 설계자는 Layers 패턴을 사용할 것인지 Three-Layered Application 패턴을 사용할 것인지에 관심이 많을 것이다. MS의 「Pattern & Practice」에서는 이러한 서로 다른 추상화 수준에서의 분류를 패턴 그래프를 이용해서 세 가지 계층으로 구분한다.

사용자 삽입 이미지
<그림 6> 추상화 수준(출처 :참고자료)


Architecture 수준의 패턴은 MS의 「Architecture Center(참조자료)」을 참조하기 바란다.

구현 수준 패턴
패턴의 집합들을 <그림 6>과 같이 세 가지 추상화 수준으로 나누면 개발에 참여하는 설계자, 개발자 등의 다른 사용자 그룹이 자신의 전문적인 기술에 관련된 패턴을 쉽게 찾아볼 수 있게 된다.

모든 언어 또는 플랫폼에서 사용할 수 있는 패턴들이 아닌, C#이나 닷넷 플랫폼 같은 특화된 언어 또는 환경 특화된 패턴을 idiom이라고 부른다. MS의 Enterprise Solution Patterns Using Microsoft .NET에서는 모든 응용 프로그램 개발 단계를 아우르기 위한 집약적인 시스템을 위해서 구현 수준 설계 패턴들을 정리했다. Enterprise Solution Pattern에 등장하는 거의 모든 패턴들은 구현 수준의 패턴에 해당한다. Enterprise Solution Pattern의 한 클러스터인 Web Presentation Pattens 다음 패턴들은 모두 구현 수준의 패턴들이다.


◆ MVC 패턴
- 문제 : 개별적인 부분을 쉽게 수정하기 위해서 웹 응용 프로그램의 사용자 인터페이스 기능을 어떻게 모듈화 할 것인가
◆ Page Controller 패턴
- 문제 : 코드 중복을 피하여 재사용과 융통성을 갖기 위해서 어느 정도 복잡한 웹 응용 프로그램에 대한 컨트롤러를 구성하기 위한 최상의 방법은 무엇인가?
◆ Front Controller 패턴
- 문제 : 코드 중복을 피하여 재사용과 융통성을 갖기 위해서 아주 복잡한 웹 응용 프로그램에 대한 컨트롤러를 구성하기 위한 최상의 방법은 무엇인가?
◆ Intercepting Filer 패턴
- 문제 : 웹 페이지 요청에 대하여 공통적인 선행 처리와 후행 처리 단계를 어떻게 구현할 것인가?
◆ Page Cache 패턴
- 문제 : 자주 요청되지만 생성하기 위해서 엄청난 시스템 리소스를 소비하는 동적으로 생성되는 웹 페이지의 응답 시간을 어떻게 줄일 수 있을 것인가?
◆ Observer 패턴
- 문제 : 다른 클래스에 의존하기 않고 다른 객체의 상태가 변경되었음을 어떻게 알릴 수 있을까?


각 패턴의 상세한 사항들은 다음 호에서 상세히 알아보도록 한다.

연구된 모든 패턴은 닷넷에서 구현된다
경험 많은 개발자라면 프로그램을 설계할 때 예전에 했던 일을 그대로 반복하고 있다는 느낌을 받을 때가 많다. 경험이 축적되면, 그 경험을 살려서 다음 개발에 적용할 때가 있다. 설계 패턴(디자인 패턴)은 이러한 경험과 내공을 정리한 것에 지나지 않는다.

학생들이 프로젝트를 진행할 때 if문으로 점철된 너무 복잡한 코드를 쓰는 경우가 많다. 그런 경우 필자는 “이런 경우에는 이런 패턴을… “ 이라는 말로 코드 개선을 요구한다. 보통 학생들은 디자인 패턴이라는 말이 나오면 한숨부터 쉬게 된다. 너무 어렵다는 것이다. 하지만 디자인 패턴은 결코 어려운 것이 아니다. 디자인 패턴이 어렵게 느껴지는 이유는 문제를 파악하려 하지 않고 패턴만을 외우려 하기 때문이다. 꼼꼼한 요구사항 분석으로 문제들을 파악했다면, 패턴 응용 프로그램을 작성하는 것은 전혀 어려운 일이 아니고, 조금 더 많은 생각으로 아주 재사용성과 활용성 높은 프로그램을 작성할 수 있게 된다.

2년쯤 전, 필자는 어떤 솔루션을 구축하면서 Page Controller 패턴을 활용했다. 코드를 본 다른 회사의 개발자는 “이거 닷넷 구조가 아니고 자바 구조군요 이런 건 처음 봅니다. 아주 재미있네요”라고 이야기했다. 이상하게도 닷넷 개발자들은 디자인 패턴 같은 것은 자바 쪽에서 사용되는 것이라고 생각하는 경우가 많다.

심지어 국내 굴지의 개발사 사장님은 “자바는 천재들이나 하는 것이고 닷넷은 아무나 할 수 있는 것이므로 닷넷을 하는 게 좋다”라는 망언(?)까지 하셨다.

연구된 모든 패턴들은 닷넷 환경에서 제대로 구현하고 있고, MS는 커뮤니티를 운영하고 조합하면서 연구된 기술들을 활용하여 닷넷 플랫폼에 특화된 패턴들을 내 놓았다. 이런 패턴들은 별 다른 의심의 여지없이 닷넷 기반 응용 프로그램 개발에 사용될 수 있고, 좋은 성능과 높은 확장성을 기대할 수 있다. MS가 이번에는 제대로 하고 있는 것 같다.@

* 이 기사는 ZDNet Korea의 제휴매체인마이크로소프트웨어에 게재된 내용입니다.

 

김상훈 (동명정보대학 정보기술원 연구원)

2005/08/24

 

사용자 삽입 이미지

 

 

 

 

원문 :http://www.zdnet.co.kr/builder/dev/dotnet/0,39031607,39136897,00.htm

  Comments,     Trackbacks