패턴들을 자세히 살펴보면, 패턴 내의 컴포넌트들과 그것들의 관계가 항상 '원자적(atomic)'이지만은 않다는 것을 알수 있다. 어떤 문제를 해결하기 위해서는 패턴 내의 컴포넌트가 서로 밀접하게 상호작용해야 하며, 문제의 성격이나 그 문제가 발생한 상황에 따라 컴포넌트의 결합이 불가피할 수도 있기 때문이다.
이것은 패턴간의 관계에서도 마찬가지다. 패턴을 통해 어떤 문제를 해결하기 위한 과정에서 또다른 문제가 야기되기도 하고, 그 문제를 또 다른 패턴으로 해결할 수도 있기 때문이다.
이런 점들을 통해, 특정 패턴 내에 있는 컴포넌트들이나 그것들의 관계는 더 작은 패턴에 의해 서술될 수 있으며, 그것들을 포함하고 있는 더 큰 패턴에 통합될수도 있다는 것을 알수 있다. 실제로도 이런 패턴들은 변형되고 일반화되어 새로운 형태의 패턴으로 발전하기도 한다. [POSA1]

여기서는 가장 널리 알려진 패턴중 하나인 MVC(Model-View-Control)패턴과 그로부터 파생된 패턴들의 관계에 대해 다뤄보도록 하겠다.
― 이 글의 목적은 MVC 패턴과 그로부터 파생된 패턴들의 관계를 설명하는데 있다. 여기서 언급되는 각 패턴의 세부 내용은 다음기회에 다루도록 하겠다. ―


MVC(Model-View-Control) 패턴

MVC 패턴은 애플리케이션을 '프로세싱(processing)', '출력(ouput)', '입력(input)'의 세 개 영역으로 분리한다. MVC 패턴에서는 각 영역을 Model, View, Controller라는 컴포넌트로 표현하는데, 각 컴포넌트가 담당하는 일을 정리하면 다음과 같다.

- Model : 데이터와 그 처리 로직(logic)을 가지고 있다.
- View : 실제 UI요소를 그려준다.
- Controller : 사용자의 입력 정보를 이벤트(event) 형태로 수신한다.

이어 소개할 PAC 패턴은 MVC 패턴에 기반을 두고, 시스템 구성 관점으로 발전시킨 패턴이며, Document-View, MVP, MVVM 패턴은 모두 UI 구조 관점에서 MVC 패턴을 발전시킨 패턴이다.


PAC(Presentation-Abstraction-Control) 패턴
PAC 패턴은 MVC 패턴을 시스템 구조적 관점으로 변형한 패턴이다. PAC 패턴에서는 계층구조(hierarchy)를 이룬 에이전트(agent)들이 서로 협력·상호작용하는 소프트웨어 시스템의 구조를 형성한다.

PAC 패턴의 특징과 MVC 패턴과의 차이점을 그림으로 표현하면 다음과 같다.

- Model : 데이터와 그 처리 로직을 가지고 있다.
- View : 실제 UI 요소를 그려준다.
- Presenter : View와 Model간의 상호작용을 담당한다.

MVP 패턴의 핵심 목표는 View와 Model간의 결합도를 낮추는 데 있다. 여기서는 Presenter가 Model의 데이터를 View에 출력할 수 있도록 할 뿐만 아니라, 이벤트를 View에서 받아 Model의 데이터를 갱신하기도 한다. 실제 구현에서는 Presenter는 View와의 결합도를 감소시키기 위해서, View를 직접 참조하는 대신 View의 Interface를 참조한다. 이를 통해 Presenter는 View의 실제 UI 요소가 어떻게 구현되는지에 관계없이 데이터를 올바르게 표현하도록 할 수 있다. [MSDN]


MVVM(Model-View-ViewModel)

MVVM 패턴은 아래 그림과 같이 사용자와의 상호통신이 활발하고 동적인 사용자 인터페이스를 가지는 클라이언트 응용프로그램에게 적합하도록 MVP패턴을 개선한 패턴이다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

알파치노, 콜린파렐 주연의 이 영화는 개봉한지 벌써 7년이나 지난 "구식(?)" 영화다. 개봉했을 당시에 이미 본바 있지만, 이번에 케이블TV를 통해 다시 보니 이전에는 들지 않았던 이런저런 생각이 들어 이렇게 글을 남긴다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

이 글을 시작하기에 앞서 미리 밝혀두지만, 나는 비교적 보수적이고 유교적 문화에 익숙해 있기 때문에 섹스(sex)에 대한 얘기를 남앞에서 하는것 자체를 터부(taboo)시 하는 편이다. 하지만 주로 그 '섹스'에 대해, 혹은 그에 연관된 '사랑'에 대해 다루고 있는 영화 '오감도'에 대해 글을 쓰고자 마음먹었기에 나 스스로의 금기(?)를 이번만큼은 깨보기로 했다.

나는 사실 영화 '오감도'를 극장에서 보지는 않았다. 더 솔직히 말하자면 극장에서 볼 생각은 전혀 없었고, 그 이후에라도 찾아서 볼 생각조차 없었다. 이 영화는 '에로스(eros), 그 이상의 사랑 이야기', '사랑의 편견을 벗어라!'라는 문구로 어느 정도의 선정성을 내세워 홍보를 했고, 그것이 영 내 취향에 맞지 않았기 때문이다. ―같은 팀 직원들과 퇴근 후 영화를 보곤 했었는데, 팀 직원중 한명이 '오감도'를 추천했음에도 불구하고 거절했다.―
그럼에도 불구하고 이 영화를 접하게 된 케이블TV를 통해서였다. 다소 부정적이었던 영화에 대한 기대치와는 달리, ―내 감정의 기복 탓일지 모르겠지만― 이 영화의 첫번째 세그먼트(segment)는 긍정적인 측면에서 많은 생각을 하게 했다.
―'오감도'는 총 5개의 에피소드(episode, 혹은 세그먼트)로 구성되어있는 옴니버스 영화다. 이 글에서는 첫번째 에피소드인 'His concern'에 대해서만 다루도록 하겠다.―

"혼자 다니는 사람에게 좌석 티켓이라는 것은, 어쩌면 일종의 즉석복권일지도 모른다."
현실에서도 혼자 다니는 사람에게 옆에 앉게 될 사람은 매우 중요하다. 즐거운 마음으로 여행을 시작했으나, 너무나 지독한 냄새를 풍기는 사람이 옆에 앉는다고 상상해 보자. 그 얼마나 곤욕스러운 일인가? 10분의 동행이 10시간 같을 것이고, 심지어 숨쉬기 조차도 곤욕스러울 것이다.
반면, 약간은 침울하게 시작한 여행이라 할지라도, 옆에 앉은 사람이 유쾌하고 대화가 통하는 사람이라면 아무리 긴 시간의 이동도 지극히 즐거운 일일 것이다.
이점은 살아가는데 있어서도 마찬가지일 것이다. 나와 같이 일하는 사람, 혹은 배우자, 삶의 곳곳에서 부딪히거나 엮일 사람을 내 의지대로 선택하기란 사실상 불가능하다. 그리고 그 사람들이 어떤 사람이냐에 따라 삶의 질이 천차만별이 되기 때문이다. 말 그대로 그 사람들이 나의 "복권(福卷)"이라 할만 하다.

"그녀와 섹스를 해서 좋은 것이 아니라 그녀와 섹스를 하는 사이라서 좋은 것이라면 사랑이라 부를만한다."
앞서 밝혔듯, 이 말은 내가 지극히 터부시 하던 영역에 해당하는 대사다. 하지만 이 대사는 근래 하고 있는 한가지 고민에 괜찮은(?) 답을 해주고 있다.
그 동기는 불분명하지만, 근래 '사랑'이라는 말과 행동, 그 감정의 정체에 대해 원론적으로 생각해보고 있다. 어떤 철학자는 사랑의 근본을 '희생'이라고 했고, 어떤이는 '섹스'라고도 했다. 이것은 정신적인 것이냐, 육체적인 것이냐에 대한 것인데 이들은 모두 내 기준에 명확한 정의는 아니었다. '희생'으로 시작된 '사랑'이라 할지라도, 남녀간의 사랑이라면 육체적으로 끌릴 수도 있는 것이고, 그렇다고 해서 그것이 '사랑'이 아닌것은 아니다. '섹스'라는 행위 자체 만으로는 번식의 본능을 설명할 수 있겠지만 '사랑'이라 부르기엔 부족함이 많기 때문이다.
이런 점들을 고려했을 때, '사랑'에 대해 객관적으로―'사랑'이라는 것 자체가 객관적일 수 없는 개념일지 모른다. 여기서는 어디까지나 '비교적' 객관적인 것을 말하는 것이다.― 정의하기 위해서는 '육체적'요소와 '정신적' 요소가 적절히 조화가 되어야 한다고 생각된다. 이 대사는 비교적 명쾌하게 기준선을 제시해준다. '섹스'라는 행위 자체에 대한 감정이 '사랑'인지 여부를 결정짓는 것이 아니라, '섹스의 대상'에 따른 감정이 '사랑'인지 여부를 결정짓는 것이라면, 내 고민에 대한 납득할 만한 답이 된다라는 판단이 선 것이다. '섹스'라는 행위 그 자체가 좋은 것이 아니라 '그 사람과의 섹스'이기 때문에 좋은 것이라면, 내가 그 사람을 사랑한다고 말하기에 충분한 것이 아닐까?

'오감도'라는 영화가 평단이나 관객으로부터 그리 좋은 평가를 받은 영화는 아닌것 같다. 사실 나는 영화의 극히 일부분(약 20% 수준)만을 본 것이고, 그 부분에서 역시 '감동'에 가까운 느낌을 받았다고 말하기는 어렵다. 하지만 내가 본 그 일부분의 영화에서는 어느정도 곱씹어 볼 이야기들이 있었고, 다른 사람들도 그 대사 하나하나를 곱씹어볼만 하다 이야기할 수는 있다. 그리고 인류가 영원히 정의하기 어려울 일이겠지만, '사랑'이라는 개념에 대해 다시 한번 생각해보기를 권해보고 싶다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

전문가들이 어떤 문제(problem)와 맞닥뜨렸을 때, 기존에 사용했던 해결책(solution)과는 완전히 다른 방법으로 그 문제에 접근하는 경우는 매우 드물다. 그들은 일반적으로 이미 해결해 본 문제들 중, 당면한 것과 유사한 문제를 찾아 당시의 해결방법을 당면한 문제 해결에 응용하곤 한다. 여기서 '유사한 문제'란 구체적이고 세세한 사항은 다를 수 있지만, 그 해결책이 가지는 핵심적인 방법은 같은 것을 말한다.
이런 일련의 과정을 효과적으로 수행하기 위해 만든 개념이 바로 패턴(pattern)이다. 패턴에서는 빈번히 발생하는 ‘문제'와 그 문제에 대한 '해법’을 쌍으로 구성해, 특정 문제에 대한 해법을 손쉽게 재활용 할 수 있도록하고 있다.

소프트웨어 영역에서 사용되는 '패턴'의 특징을 보면 다음과 같다.('패턴'이라는 개념은 소프트웨어 영역 뿐만 아니라 건축·경제 등의 분야에서도 사용된다.)

패턴은 특정한 상황(context)에서 반복적으로 발생하는 설계상의 문제와 그에 대한 해법을 제시한다. 많이 알려진 MVC 패턴에서의 문제는 UI가 쉽게 변할 수 있다는 것이다. 이 문제는 사용자와 컴퓨터가 상호작용해야 하는 소프트웨어를 개발할 때 흔히 대두되는데, 이런 문제를 해결하기 위해서는 책임(responsibility)을 엄밀히 구분하면 된다. MVC 패턴에서는 소프트웨어의 핵심 데이터와 기능을 UI로부터 분리하는 방법을 제시했다.

패턴은 이미 그 효과가 입증된 경험을 정리한 것이다. 패턴은 인위적으로 발명되거나 창조되는 것이 아니다. 경험 많은 전문가가 얻은 설계에 대한 지식을 모아, 재사용할 수 있는 형태로 정리한 것이 패턴인 것이다. 그렇기 때문에, 이미 많은 패턴을 숙지하고 있는 사람이라면, 패턴에 해당하는 문제의 해결책을 다시 찾을 필요 없이, 기존의 지식만으로도 즉각 설계에 그 해결책을 적용 할 수 있다.
극소수 전문가들끼리 비밀리에 전수하는 ‘비법(秘法)’과는 달리, 패턴은 누구나 공개적으로 사용할 수 있다. 즉, 패턴은 특정 상황에서 고품질 소프트웨어를 설계할 때, 전문가 수준의 지식을 누구나 쉽게 사용할 수 있게 해준다. MVC 패턴 역시도 수년 간 상호작용 시스템을 개발하며 얻은 경험을 정리한 것이라 할 수 있다.

패턴은 컴포넌트나, 단일 클래스, 객체 같은 수준보다 높은 단계의 추상 레벨에서 발견되고 정의된다. 대체로 패턴은 몇몇 컴포넌트, 클래스, 객체를 서술하며 그것들의 책임, 관계(relationship), 협력(cooperation)에 대한 내용을 상세히 정의한다.
모든 컴포넌트나 클래스, 객체들은 패턴이 해결하고자 하는 문제를 함께 풀어가는데, 단일 컴포넌트로 해결하는 것보다 훨씬 효과적이다. 실제로, MVC 패턴에서는 모델, 뷰, 컨트롤러라는 세가지 컴포넌트의 상호 협력에 대해 명시하고 있으며, 결과적으로 단일 컴포넌트로 만드는 것보다 유연하고 효과적인 시스템을 만들어내고 있다.

패턴은 설계 원칙에 대한 공통 어휘(vocabulary)와 공감대를 형성시켜준다. 패턴의 이름이 적절히 붙는다면, 설계 용어로 쉽게 사용할 수 있다. 패턴의 이름이 설계 용어로 사용되면, 설계에 대해 의견을 나눌 때, 그 효율성이 배가된다. 특정 문제에 대한 해법을 설명할 때, 패턴 이름만 알고 있다면 해법의 메커니즘을 복합하고 장황하게 설명하지 않아도 되기 때문이다. 해법의 어떤 부분들이 패턴의 어떤 컴포넌트에 해당하는지, 혹은 컴포넌트들 간의 어떤 관계가 패턴의 어느 부분과 관계 있는 것 인지만 설명하면 되는 것이다. 예를 들어, 패턴에 대해 익숙한 동료들끼리 “이 소프트웨어의 아키텍처에는 MVC 패턴을 적용합시다” 라고 말할 경우, 동료들은 이 애플리케이션의 기본 구조와 특성들을 부연 설명 없이도 쉽게 파악할 수 있게 된다.

패턴은 소프트웨어 아키텍처를 문서로 정리하는 방법이다. 패턴을 사용하면 특정한 문제에 대한 복안(腹案)을 쉽게 문서로 정리할 수 있는 것이다. 이런 점은 소프트웨어를 확장할 때도 매우 유리하게 작용한다. 소프트웨어를 확장할 때, 기존의 소프트웨어가 MVC 패턴에 맞게 설계되었다는 것을 알고 있다면, 새로운 기능이 모델, 뷰, 컨트롤러 중, 어떤 컴포넌트에 해당하는 확장인지 쉽게 파악할 수 있고, 기존의 설계 원칙에 어긋나지 않게 새로운 기능을 추가해 넣을 수 있기 때문이다.

패턴은 고유한 특성(property)을 제공해야 하는 소프트웨어를 개발할 수 있도록 도와준다. 패턴은 각 컴포넌트가 제공해야 하는 기능적인 골격을 제시하고 있다. 예를 들어 Peer-To-Peer 패턴은 프로세스간 통신에 대한 특성을 포함하고 있고, MVC 패턴은 UI의 가변성과 핵심 기능의 재사용성에 대한 특성을 포함하고 있다. 실제로 개발하고자 하는 소프트웨어가 프로세스간 통신을 필요로 한다면 Peer-To-Peer 패턴을, UI가 자주 변경된다면 MVC 패턴을 적용하거나 참고하면 보다 쉽게 소프트웨어를 설계개발 할 수 있다.

패턴은 복잡한 소프트웨어의 아키텍처를 구축하는 데 도움을 준다. 모든 패턴은 컴포넌트들과 그것들 사이의 역할 및 관계를 정의해 놓고 있다. 이런 패턴은 복잡한 설계를 위한 빌딩블록(Building-Block)으로 사용할 수 있는데, 이를 통해 이미 검증된 설계 방식을 응용하게 되어 설계에 들이는 시간은 단축하고, 그 질은 향상시킬 수 있다. 물론 많이 알려진 패턴이 항상 개발자 스스로가 고안한 해법보다 우수한 것은 아니지만, 설계 방안을 검토할 때 충분히 참고하거나 응용할만한 가치가 있다.
반면, 패턴은 문제 해결을 돕는 것이지, 완전한 해법을 제공하지는 않는다. 패턴이 특정 문제에 대한 해법의 기본 구조를 결정할지라도, 해법의 세부 내용까지 모두 정의하고 있지는 않다. 패턴은 특정 문제 유형의 일반적인 해법에 대한 스키마(scheme)만을 제공할 뿐이지, 사전에 미리 제조되어 그대로 가져다 쓰기만 하면 되는 완전한 조립식 모듈은 아닌 것이다. 그러므로 패턴을 적용하려는 개발자는 설계의 구체적인 세부 내용은 스스로 구현해야 한다. 패턴은 아키텍처 수준의 설계를 돕기 때문에, 패턴을 적용한 해법의 포괄적인 구조는 비슷할 수 있지만, 세부적인 내용에서는 상당히 차이가 날 수 밖에 없다.

패턴을 사용하면 소프트웨어 복잡성을 관리하는 데 유용하다. 모든 패턴은 해결하고자 하는 문제의 해법을 서술한다. 이때 해법에는 필요한 컴포넌트의 종류, 각 컴포넌트의 역할, 숨겨져야 하는 세부 구현, 노출되어야 하는 추상화 부분, 그리고 이것들이 동작하는 방법 등이 서술되어야 한다. 그렇기 때문에 어떤 패턴이 다루고 있는 문제와 맞닥뜨렸을 때, 문제에 대한 해법을 찾느라 시간 들여 골몰할 필요가 없다. 패턴을 올바르게 구현하면, 그 패턴이 제공하는 해법은 자연스레 따라오는 것이다.

<참고자료>

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.