출처: http://aeternum.egloos.com/2517525
소프트웨어 아키텍처와 시스템 메타포(System Metaphor)
소프트웨어 개발은 도메인에 적합한 추상화를 발견하고 코드로 옮기는 작업이다. 소프트웨어 개발의 태동기부터 사람들은 문제 영역에 적합한 솔루션을 개발하기 위해 다양한 메타포를 적용해 왔다. 메타포는 프로그램 작성과 관련된 거의 대부분의 활동에 영향을 미친다. 객체를 명명하고, 객체 간의 관계를 규정하고, 메소드와 클래스, 패키지에 적절한 이름을 부여하는 모든 작업이 적절한 메타포를 찾는 일과 관련되어 있다. 이런 관점에서 프로그래밍이란 도메인이라는 문제 영역을 연상할 수 있는 적절한 메타포를 소프트웨어에 새겨 넣는 과정이라고 정의할 수도 있을 것이다.
메타포가 격렬한 논쟁의 수면 위로 떠오른 것은 XP의 창조자들이 메타포를 아키텍처의 영역으로 확장하면서부터이다. 모든 것은 크라이슬러의 급여 지급 시스템을 개발하는 C3(Chrysler Comprehensive Compensation) 프로젝트로부터 시작되었다. C3 프로젝트 팀은 급료를 계산하는 과정을 조립 라인(assembly line)을 따라 흐르는 컨테이너를 조립하는 과정으로 보았으며 급료를 여러 개의 부분으로 구성된 복합체로 간주했다[Kerievsky METAPHOR]. Kent Beck은 “Extreme Programming Explained” 1판[Beck XPExplained1]에서 XP의 프랙티스로 시스템 메타포(System Metaphor)를 포함시켰으며 이후 C3의 조립 라인 메타포는 아키텍처 레벨에 시스템 메타포를 적용한 대표적인 사례가 되었다. 그리고 이때부터 전통적인 아키텍처주의자들과 애자일 아키텍처주의자들 간의 격렬한 논쟁이 시작된다.
크라이슬러는 제조 회사로 자동차를 생산한다. 프로젝트를 정의하기 위해 제조 메타포를 사용하는 것은 팀을 (그리고 관리자들을) [모든 지식을 공유하는] 동등한 위치에 올려놓기 위한 중요한 최초의 전진이었다. 라인(line), 부품(part), 상자(bin), 작업(job), 그리고 작업소(station)의 개념은 회사에 속한 모든 사람들이 이해하고 있는 메타포다. 팀은 프로젝트의 첫 번째 반복에서 개발된 매우 풍부한 도메인 모델로부터 이익을 얻을 수 있었다. 이러한 메타포를 통해 프로젝트 구성원들이 극도로 복잡한 도메인을 쉽게 이해할 수 있었다.
- Chet Hendrickson 외[Hendrickson C3]
시스템 메타포란 모든 사람들–고객, 프로그래머, 그리고 관리자–이 시스템의 작동 방법에 대해 이야기할 수 있는 스토리다[Beck XPExplained1]. 시스템 메타포에는 두 가지 목표가 있다. 첫 번째는 프로젝트 참여 인력들 간의 의사소통을 향상시키는 것이다. 여러 작업을 동시에 처리할 수 있는 작업 공간으로서의 데스크톱(desktop) 메타포는 GUI 운영체제에 대한 의사소통과 지식 공유를 촉진시킨다. 두 번째 목표는 적절한 소프트웨어 아키텍처를 구축하기 위한 통찰력을 얻는 것이다. 데스크톱 메타포에서 자료들은 책상에 펼쳐져 있는 서류(file)에 기록하고 관련된 서류들을 서류철(folder)에 보관한다. 데스크톱 메타포를 사용하는 GUI 운영체제의 아키텍처는 desktop, file, folder로 명명된 컴포넌트들이 포함하며 전체적인 구조 역시 이들 간의 관계를 기반으로 구성된다.
William C. Wake는 “Extreme Programming Explored”에서 공통 비전(Common Vision), 공유 용어집(Shared Vocabulary), 창조성(Generativity), 아키텍처(Architecture)의 4가지를 시스템 메타포를 탐구하는 이유로 들었다. 처음 3가지는 일반적으로 소프트웨어 아키텍처를 구축하는 이유로 언급된다는 사실에 주목할 필요가 있다.
- 공통 비전(Common Vision) : 모든 사람들이 시스템의 작동 방식에 동의할 수 있도록 함. 메타포는 문제와 해결방법을 인식하는 핵심 구조를 제안한다. 이것은 시스템이 무엇인가 뿐만 아니라 무엇일 수 있는가를 쉽게 이해할 수 있도록 한다.
- 공유 용어집(Shared Vocabulary) : 메타포는 객체와 이들의 관계에 대한 공통 이름 체계를 고안할 수 있도록 한다. 용어집은 최선의 경우 도메인에서 사용되는 특수한 용어로 구성될 것이다 : [도메인] 전문가를 위한 강력하고, 특화된, 간결한 용어집. 어떤 것에 명칭을 부여하는 것은 그것을 제어할 수 있는 힘을 제공한다.
- 창조성(Generativity) : 메타포에 의한 비유는 (문제와 솔루션 영역 모두에 있어) 시스템에 대한 새로운 아이디어를 제시한다. “고객 서비스는 조립 라인이다”라는 메타포를 살펴보자. 이 메타포는 업무 담당 그룹 간에 문제가 전달될 것이라는 점을 제시하지만, 그와 동시에 의문점을 제시한다. “문제가 라인의 최종 지점에 도달한다면 어떻게 할 것인가? 그냥 바닥으로 떨어지고 말 것인가?” 메타포는 숨겨진 채 부패할지도 모르는 중요한 이슈를 드러낸다.
- 아키텍처(Architecture) : 메타포는 핵심적인 객체를 식별하고 핵심 객체의 인터페이스 측면을 제시함으로써 시스템을 구체화한다. 메타포는 시스템의 정적인 측면과 동적인 측면 모두를 지원한다.
- William C. Wake[Wake XPExplored]
자, 이제 논점으로 돌아가자. 시스템 메타포와 아키텍처 모두 시스템에 대한 전반적인 이해를 공유하고 설계를 가이드하는 것을 목표로 한다. 그렇다면 시스템 메타포의 어떤 측면이 전통적인 아키텍처주의자들의 거센 반발을 불러일으킨 것인지에 의문이 생긴다. XP를 중심으로 한 애자일 방법론은 아키텍처의 중요성을 무시하는가? XP 프로젝트에는 견고한 아키텍처가 존재하지 않는가? 그렇지 않다면 이러한 논쟁의 원인은 전통적인 아키텍처주의자들의 오해로부터 기인한 것인가? 세 가지 질문에 대해 고민해봄으로써 정확한 해답은 구할 수 없을지라도 문제의 본질에 가까이 접근할 수는 있을 것이다.
시스템 메타포, 그리고 애자일에 대한 오해와 진실
- XP를 중심으로 한 애자일 방법론은 아키텍처의 중요성을 무시한다?
그렇지 않다. XP 역시 아키텍처가 중요하다는 사실에 동의한다. Kent Beck은 “Extreme Programming Explained” 1판에서 “다른 프로젝트에서와 동일하게 XP에서도 아키텍처는 중요하다”라고 이야기했다. 다만 시스템 메타포의 중요성을 강조하면서 “아키텍처의 일부는 시스템 메타포를 사용하여 포착할 수 있다. 훌륭한 메타포를 적절하게 가지고 있다면 팀의 모든 사람들은 시스템이 전반적으로 어떻게 동작하는 지를 이야기할 수 있다.”라고 부연했다.
아키텍처 관점에서 시스템 메타포를 강조하는 이유는 시스템 메타포가 응집도 높은 이야기를 통해 아키텍처에 대한 원활한 의사소통을 돕기 때문이다. 즉, 단순히 컴포넌트와 컴포넌트 간의 관계가 아닌 일관된 이야기 흐름 속에서 시스템의 전반적인 구조를 논의하고 유추할 수 있도록 한다는데 시스템 메타포의 가치가 있다.
XP의 메타포는 많은 사람들이 “아키텍처”라고 부르는 것의 많은 부분을 대체한다. 10,000미터 상공에서 바라본 시스템에 대한 뷰를 아키텍처라고 할 경우의 문제점은 아키텍처가 반드시 시스템을 응집도 높게 보여주지는 않는다는 것이다. 이 경우 아키텍처는 큰 박스와 박스 간의 연결일 뿐이다. … 여기에서는 모든 사람에게 작동하는 응집된 이야기, 비즈니스 담당자와 기술 담당자에 의해 쉽게 공유될 수 있는 이야기를 제공한다는 아키텍처의 목적을 강조할 필요가 있다. 메타포를 찾음으로써 우리는 쉽게 의사소통하고 다듬을 수 있는 아키텍처를 얻을 수 있을 것이다.
- Kent Beck[Beck XPExplained1]
- XP 프로젝트는 견고한 아키텍처 없이 진행된다?
XP 역시 프로젝트 초기에 견고한 아키텍처를 구축한다. RUP의 ELABORATINO PHASE에서 아키텍처 베이스라인을 구축하는 것과 유사하게 최초 반복(iteration) 시에 아키텍처 스파이크(Architecture Spike)를 통해 아키텍처를 확립한다. 스파이크란 사용자 스토리에 포함된 불확실한 요소에 관해 충분히 알기 위해 수행하는 일종의 실험이다. 일반적으로 추정을 명확하기 위해 개발하는 프로토타입으로 해결방법에 대한 충분한 지식을 습득한 후에는 폐기 처분된다[Philippus Spike]. 아키텍처 스파이크란 최초 반복 시에 견고한 아키텍처를 구축하기 위한 실험을 의미하며 스파이크의 개념을 아키텍처 영역으로 확장한 것이다. RUP의ELABORATION PHASE와 XP의 최초 반복 모두 개발 과정을 인도할 예광탄 코드[Hunt PRAGMARTIC]를 개발하는 것을 목적으로 한다.
다음 단계는 스토리를 객체로 전환하는 방법을 조사하는 것이다. 계획 게임의 규칙은 최초 반복의 결과물로 총괄적으로 동작하는 시스템의 스켈레톤을 구축해야 한다는 것이다. … 최초 반복에서 전체적인 아키텍처를 구축할 것이라고 기대되는 단순하고, 기본적인 스토리들을 선택하라. 그 후 대상 범위를 제한하고 동작하는 가장 단순한 방법으로 스토리를 구현하라. 반복이 종료될 때 아키텍처를 구축하게 될 것이다.William C. Wake에 따르면 XP는 명시적으로 아키텍처를 언급하지는 않지만 스파이크(Spike), 메타포(Metaphor), 최초 반복(First Iteration), 작은 배포(Small Release), 리팩토링(Refactoring), 팀 프랙틱스(Team Practice)와 같은 메커니즘의 조합을 통해 실제적으로 아키텍처를 구축한다고 한다[Wake XPExplored].
- Kent Beck[Beck XPExplained1]
따라서 XP가 견고한 아키텍처 없이 진행된다고 이야기하는 것은 옳지 않다. XP에서 시스템 메타포는 아키텍처를 구축할 수 있는 영감을 제공하고 특정 뷰를 이끌어내기 위한 수단일 뿐이지 아키텍처 구축과 관련된 모든 것이 아니다. 특히 시스템 메타포는 시스템의 정적인 측면을 표현하는 논리 뷰와 관련이 있다.
이러한 오해에는 XP진영의 잘못된 반응도 일조한 것이 아닌가 추측된다. Martin Fowler의 글에서 알 수 있듯이 시스템 메타포가 아키텍처라는 XP 진영의 주장 역시 틀렸다. 뒤에서 다루겠지만 시스템 메타포는 아키텍처 구축에 있어 필수사항이 아니다. 시스템 메타포를 아키텍처와 동일시하는 것은 시스템 메타포의 가치를 훼손시킬 뿐이다.메타포는 부분적으로는 RUP에서의 논리 설계와 유사하다. 메타포는 핵심 객체와 그들간의 상호작용을 정의한다. 이것은 최상위 레벨에서 기능을 이해하고자 할 때 방향성을 잡을 수 있도록 한다.
- William C. Wake[Wake XPExplored]
XP 역시 초기에 견고한 아키텍처를 구축하며 이를 통해 시스템을 성장시켜 나간다. XP에 아키텍처가 없다는 주장은 사실과 다르다. 단지 일반적으로 널리 퍼져 있는 아키텍처에 관한 몇 가지 불편한 편견을 거부할 뿐이다.자, 시스템 메타포에 관해 공개적으로 언급한 적이 있지만, 여전이 이 메타포라는 것을 어떻게 사용하는지 모르겠다. … 적어도 시스템의 윤곽에 관한 설계가 필요하다는 이론으로 종종 XP 를 비판한다. XP 진영은 "그것이 메타포다"라고 답한다. 하지만 여전히 난 메타포가 설득력 있게 설명된 적이 없다고 생각한다. 이게 바로 XP 가 해결해야 할 실제적인 빈틈이며 XP 진영이 정리해야 하는 부분이다.
- Martin Fowler[Fowler DESIGNDEAD]
- 논쟁의 원인은 전통적인 아키텍처주의자들의 오해로부터 기인한 것인가?
시스템 메타포에 대한 논쟁이 잘못된 전제를 기반으로 한다면 소프트웨어 아키텍처에 대한 대립은 양 진영 모두 어느 정도 타당한 근거를 기반으로 한다. 소프트웨어 개발자로서 우리의 목적이 효과적이고 유연한 소프트웨어를 개발하는 것이라면 어느 한 쪽의 주장에 치우치기 보다는 모든 가능성을 열어 놓고 양 진영의 장점을 취하는 접근방법이 타당하다.
개인적인 견해로 전통주의자와 애자일 진영 간의 갈등은 몇 가지 요소에 대해 상반된 견해를 보이고 있는 것에서 기인한 것이 아닌가 생각된다. 갈등의 요인 중 하나는 가역성(reversibility)이며, 또 다른 하나는 문서화(documentation)와 관련된 것이다.
전통적으로 소프트웨어 아키텍처를 초기에 구축하려는 이유는 나중에 변경할 경우 큰 비용이 요구되는 결정사항들을 고정시키기 위해서이다. 관계형 데이터베이스를 사용하던 시스템을 프로젝트 도중에 객체 지향 데이터베이스를 사용하도록 변경하는 것은 큰 비용이 드는 작업이다. 프로젝트 도중에 분산 아키텍처를 추가하는 것은 프로젝트 초반에 분산 아키텍처를 구축해 놓는 것에 비해 비용이 많이 든다. 국제화를 고려하지 않고 구축된 시스템에 국제화를 추가하는 것은 생각처럼 쉽지 않다. 소프트웨어 아키텍처는 차후에 변경될 경우 큰 비용을 치르게 될 모든 요소를 고정시키려고 한다.
애자일은 다른 견해를 가진다. 애자일의 견해는 비록 그것이 아키텍처와 관련되어 있다고 하더라도 모든 결정사항은 되돌릴 수 있어야 한다는 것이다. 이것이 XP를 비롯한 애자일 진영이 아키텍처라는 용어의 사용을 꺼리는 가장 큰 이유다.
린 소프트웨어 개발방식[Poppendieck LEAN]에서는 책임이 따르는 마지막 순간까지 결정을 미루라고 충고한다. 소프트웨어 개발에 있어 돌에 새겨진 것은 아무것도 없다. 모든 것은 시간에 따라 변하며 불확실성에 대한 투자는 낭비를 초래한다. 낭비를 제거하기 위해서는 정말 필요해지는 최후의 순간까지 이에 대한 결정을 미뤄야 한다.아키텍처는 종종 변경하기 어렵고 전역적으로 파급효과를 미치는 결정 사항들을 포함하는 시스템의 척추(spine) 또는 골격(skeleton)으로 묘사된다. XP에 대한 아키텍처의 영향도는 미미하기 때문에 XP의 경우 다른 방법론에 비해 아키텍처에 대한 사전 설계를 강조하지 않는다. XP의 모토가 “변경을 환영하라”인 반면, 아키텍처 주도적인 접근 방법의 모토는 “어떤 것을 변경하는 것은 어렵기 때문에 스켈레톤에 대한 계획을 먼저 수립하라”이다.
- William C. Wake[Wake XPExplored]
결정을 미루기 위해서는 옵션 기반 접근 방식을 채택해야 한다. 모든 가능성을 열어 두고 다수의 옵션을 동시에 개발하는 집합 기반 개발방법(Set-Based Development)을 적용하라. 결정을 내릴 수 있을 정도로 충분한 지식이 축적되었을 때 적절한 옵션을 선택하라. 결정을 미루기 위해서는 변화를 수용할 수 있는 유연한 아키텍처를 보유해야 하며 리팩토링, 테스트 주도 개발, 지속적 통합과 같은 프랙티스를 기반으로 해야 한다.
결정이 돌에 새겨지는 것이라 가정하고, 발생할지도 모를 우연한 사건에 대해 준비하지 않는 데에서 실수가 나온다. 결정이 돌에 새겨진 것이 아니라 해변가의 모래 위에 쓰인 글씨라 생각해 보자. 언제든지 큰 파도가 글씨를 지워버릴 수 있다.
- Andrew Hunt 외[Hunt PRAGMARTIC]
XP를 위시로 한 애자일 진영은 소프트웨어 아키텍처를 돌에 새기려고 하지 않는다. 대부분의 소프트웨어 아키텍처라는 용어가 비가역성을 의미하는 영역에서 사용되기 때문에 변화를 수용하려고 하는 애자일 진영에서는 소프트웨어 아키텍처라는 용어를 가급적 사용하지 않으려고 한다. 이것이 애자일이 소프트웨어 아키텍처를 무시한다고 생각하는 이유다.
진화적인 디자인(Evolutionary Design)에서 아키텍처는 어떤 역할을 하는가? XP에 대한 비판론자들은 또 다시 이렇게 말한다. 'XP는 빠르게 코딩에 돌입하고 리팩토링을 통해 모든 설계 이슈를 해결하기 때문에 아키텍처를 무시한다.' 흥미롭게도 그들의 말이 사실이며 그것이 XP의 약점일 수도 있다. Kent Beck, Ron Jeffries, Bob Martin과 같은 대표적인 XP 지지자들은 확실히 아키텍처 디자인을 미리 하지 않으려는 데에 에너지를 더욱더 쏟고 있다. 정말 필요하다는 것을 알기 전까지는 데이타베이스를 적용하지 마라. 파일로 먼저 작업하고 이후의 반복 중에 데이타베이스를 추가하도록 리팩토링하라.
- Martin Fowler[Fowler DESIGNDEAD]
과연 어느 쪽의 주장이 옳은 것일까? 소프트웨어 개발과 관련된 대부분의 질문이 그런 것처럼 정답이란 존재하지 않는다. 소프트웨어 아키텍처에 포함되는 요소는 프로젝트마다 다르기 때문에 무엇이 아키텍처적인 요소인가에 대한 보편적인 설명을 하기란 쉽지 않다. 나중에 변경하는 것이 어렵다고 판단된다면-여기에는 재정적, 정치적 이슈도 포함된다- 아키텍처에 새겨 놓는 것이 유용하다. 반드시 필요하다고 생각된다면 미리 비용을 투자하는 것도 적절하다.
그러나 가장 중요한 것은 아키텍처에 새겨 놓는다고 하더라도 되돌릴 수 있도록 유연한 아키텍처를 수립하는 것이다. 그리고 필요한 시점에 결정사항을 되돌릴 수 있도록 리팩토링, 테스트와 같은 프랙티스를 연마하는 것 역시 중요하다. Ralph Johnson의 말처럼 가역성의 적은 우리 자신이다.
소프트웨어는 건물처럼 물리적 특성으로 인해 제한되지 않는다. 소프트웨어는 상상력, 설계, 조직에 의해 제한된다. 요약하면, 소프트웨어는 세상이라는 속성이 아니라 사람이라는 속성에 의해 제한된다. “우리는 적을 만났다. 그리고 그 적은 바로 우리 자신이다.”
- Ralph Johnson[Fowler WNA]
XP를 중심으로 한 모든 애자일 개발 방법에서는 문서 작성을 최소화하기 위해 노력한다. 린의 용어를 빌자면 참조되지 않는 모든 문서는 낭비다. 따라서 참조되지 않는 아키텍처 문서를 만드는 것 역시 낭비다. 이에 비해 전통적인 아키텍처 진영은 소프트웨어 아키텍처 문서(Software Architecture Document)의 작성을 매우 중요하게 생각한다. 소프트웨어 아키텍처 문서화에 대한 부족은 결국 체계적이고 형식적인 아키텍처 구축 계획이 존재하지 않는 것으로 인식된다. 대부분의 애자일 방법론에서 소프트웨어 아키텍처 문서와 형식주의를 배제하고 커뮤니케이션 활성화를 통한 팀 프랙티스로 공백을 메우려 시도한다. 그리고 이것은 XP를 중심으로 한 애자일 방법론이 아키텍처의 중요성을 무시한다고 이야기되는 또 다른 근거로 작용한다.
XP는 RUP가 가치를 두는 소프트웨어 아키텍처 문서를 작성하지는 않지만 여전히 아키텍처를 가진다. 짝 프로그래밍은 사람들로 하여금 팀이 사용하는 접근방법을 익히고 사용할 수 있도록 한다. 더 나은 방법을 찾게 되면 팀은 이를 공유하고 학습한다. 열린 작업 공간은 커뮤니케이션을 원활하게 한다. 코딩 표준은 작성된 코드가 일관성을 지니게 한다.
- William C. Wake[Wake XPExplored]
XP의 아키텍처 접근 방법에 대한 또 다른 반대 의견은 아키텍처에 영향을 미치는 비기능적 요구사항을 구체적으로 다루지 않는다는 점이다[Philippus Spike]. 이 견해 역시 틀렸다. 산출물을 정의하지 않는 XP의 경우 비기능적 요구사항을 요약하는 RUP의 보충 명세서(Supplementary Specification)와 같은 정형화된 문서[Larman AUP]는 존재하지 않지만 사용자 스토리를 통해 이를 보완한다.
Ron Jeffries는 “Extreme Programming Installed”에서 비기능적 요구사항을 명시하고 싶은 경우 이를 고객이 원하는 특정 스토리와 연관 지어 처리할 것을 권고한다[Jeffries XPInstalled]. Mike Cohn은 “사용자 스토리”에서 이와 관련된 구체적인 지침을 제공하고 있다.
비기능 요구사항들은 시스템의 동작에 제약을 가하는 경우가 많다. … 이 요구사항은 분명히 시스템 설계 전반에 영향을 주는 제약사항이다. … 제약사항은 그 내용을 카드에 기록하고 ‘제약사항’이라고 표시해 두는 것이 좋다. 제약사항들을 만족하는지 확인하기 위해서는 (적어도 하루에 한 번 이상 수행되는) 자동화된 테스트를 사용하라. … 제약사항이 아닌 다른 비기능 요구사항들이 있다면 적절한 양식을 사용하여 서로 이해할 수 있게 하라. 예를 들어 시스템에서 사용되는 변수들의 크기 및 타입 정보를 저장 관리하는 데이터 사전이 필요하다고 판단되면 그것을 만들어 활용하도록 하라.
- Mike Cohn[Cohn STORY]
따라서 XP에서 비기능적 요구사항을 다루지 않는다는 주장은 옳지 않다. 단지 정형화된 형식의 문서가 존재하지 않을 뿐이다. 형식주의와 문서화의 부재는 아키텍처에 있어 XP가 공격을 받을 수 있는 취약한 백도어다.
시스템 메타포 발굴
카네기멜론 대학의 James Tomayko와 James Herbsleb은 “How Useful Is the Metaphor Component of Agile Methods?”와 “The eXtreme Programming (XP) Metaphor and Software Architecture”에서 “시스템 메타포를 개발하기 위해 소요되는 비용은 그렇게 크지 않는 것으로 보인다. 그러나 메타포의 유용성은 메타포 자체의 특성보다는 개인적인 선호도에 좌우되는 경향이 크며 … 연구 결과 메타포가 프로젝트 멤버간의 의사소통을 촉진시키고 아키텍처를 개발하는데 유용하지 않는 것으로 보인다”는 연구 결과를 발표했다.
동일한 애자일 진영에 속한 Martin Fowler조차 “하지만 여전히 난 메타포가 설득력 있게 설명된 적이 없다고 생각한다. 이게 바로 XP 가 해결해야 할 실제적인 빈틈이며 XP 진영이 정리해야 하는 부분이다.”라며 시스템 메타포에 대해 회의적인 견해를 보였다[Fowler DESIGNDEAD]. Ron Jeffries는 “Extreme Programming Installed”에서 “아직은 프로그램에 대한 좋은 메타포를 어떻게 생성하는지를 가르쳐줄 수는 없다. 왜냐하면 지금까지 우리가 시도한 것 중 절반 정도만이 수행하는 데 성공했기 때문이다.”라며 “하지만 일반 원장 프로그램이 아무리 봐도 그냥 일반 원장처럼 보이거나, 항공 관제 프로그램이 개미왕국처럼 보이지 않는다면, 다른 방법으로 개념적인 상태를 구축하라. 우리가 메타포에 관해 더 많은 것을 알게 되면 여기에 관해 나중에라도 더 많은 이야기를 해 줄 수 있을 것이다.”라는 중도적인 입장을 취했다[Jeffries XPInstalled].
시스템 메타포에 대한 전방위적인 공격으로 인해 Kent Beck은 OOPSLA 2002에서 "우리는 XP의 모든 실천사항을 수행하고 있습니다. (물론 메타포만 제외하고) "라는 이메일을 받았다면서 “메타포에 대해 설명하기 위해 노력했지만 사람들은 이를 받아들이지 않는다. … 메타포에 대해 마지막으로 설명한 후 … 사람들이 이를 이해하면 최상이겠지만 그렇지 않다면 영원히 메타포에 대해 노력하지 않을 것임을 맹세한다.”라고 선언했다[Beck METAPHOR]. 그 후 Kent Beck은 “Extreme Programming Explained” 2판에서 시스템 메타포를 XP의 프랙티스에서 제외시켰으며 “나는 일관성 있고 명시적인 메타포 집합에서 이름을 골라 쓴다. 그러면 내 개발 속도도 높아지고 새로 오는 프로그래머들에게도 코드가 더 명확하게 보인다” 정도로 간단하게 언급하는 선에서 한 발 물러서는 입장을 취한다[Beck XPExplained2].
그렇다면 시스템 메타포는 정말 유용하지 않은 것일까? 그렇지는 않다. 도메인에 적절한 시스템 메타포를 찾을 수 있다면 시스템에 대한 통찰력이 깊어지고 이해하기 쉽고 의사소통하기 쉬운 시스템으로의 도약을 경험할 수 있을 것이다. “패턴을 향한 리팩토링”의 저자인 Joshua Kerievsky는 최근 infoQ와의 인터뷰에서 시스템 메타포가 여전히 유용하며 이를 포기해서는 안 된다고 주장한다.
… 나는 이번 학회에서 시스템 메타포에 관해 이야기할 예정이며, 우리 분야가 시스템 메타포에 관해 다시 고려해야 한다고 생각하기 때문에 발표 준비에 최선을 다했다. 메타포에는 우리가 처음에 생각했던 것 보다 더 많은 것이 들어있으므로 이를 포기해서는 안 된다고 생각한다. 나는 사람들이 메타포를 더 쉽게 만들 수 있는 방법을 찾을 수 있기를 바라며 내 튜토리얼이 도움이 되기를 희망한다. … 우리는 이해(illumination), 영감(inspiration), 그리고 무결성(integrity)이라는 메타포를 바라보는 3가지 관점에 관해 이야기하고 있다. 훌륭한 메타포는 설계를 이해하기 쉽게 한다. 메타포는 우리에게 새로운 아이디어에 대한 영감을 제공한다 … 메타포의 무결성은 시스템 설계가 서로 잘 어우러지며 응집도가 높다고 느끼게 만든다. … 많은 사람들이 이 프랙티스가 제 몫을 하지 못한다고 느꼈다는 사실을 알고 있다. 메타포를 적용하는 것이 너무 어렵기 때문에 이를 사용하기 쉽도록 만드는 방법과 메타포의 효과와 이것이 얼마나 강력한지를 보여줌으로써 다른 이들이 함께 방법을 강구하도록 영감을 줄 수 있는 방법을 찾기를 희망한다.
- Joshua Kerievsky[Kerievsky METAPHOR]
시스템 메타포에 대한 격렬한 논쟁을 불러일으키는 원인은 모든 프로젝트에 시스템 메타포를 적용해야 하고 아키텍처가 반드시 시스템 메타포를 통해 구성되어야 한다는 초기 XP의 경직성 때문이라고 생각한다. 유연성은 소프트웨어 개발뿐만 아니라 소프트웨어 개발 행위 자체에도 적용되어야 하는 품질 속성이다.
결론은 간단하다. 도메인 대한 적절한 시스템 메타포가 있다면 이를 의사소통과 아키텍처 구축 시에 적극적으로 활용하라. 그러나 시스템 메타포를 적용해야 한다는 강박관념에 사로잡히지 말라. 지속적인 학습 과정을 통해 얻어진 풍성한 도메인 모델이 있다면 시스템 메타포 없이도 원하는 결과를 얻을 수 있다. Domain-Driven Design의 관점에서 시스템 메타포는 프로젝트의 공통 언어인 UBIQUITOUS LANGUAGE의 일부이며 도메인 모델링을 위한 영감을 제공하는 역할을 수행한다. 시스템 메타포는 도구이지 목적이 아니다.
팀 멤버들의 상상을 표현하고 유용한 방향으로 사고를 이끌 수 있을 것으로 보이는 시스템에 대한 구체적인 비유가 나타날 때, 이를 큰 규모의 구조로 채택하라. 이 메타포를 중심으로 설계를 구성하고 이를 UBIQUITOUS LANGUAGE에 포함시켜라. SYSTEM METAPHOR는 시스템에 대한 의사소통을 촉진시키고 개발을 가이드한다. 이것은 시스템의 서로 다른 부분 간에 일관성을 증진시키며 잠재적으로 서로 다른 BOUNDED CONTEXT 간의 일관성을 증진시킨다. 그러나 모든 메타포는 엄밀하지 못하기 때문에 지나친 확장이나 부적절하게 사용되고 있지는 않는지 여부를 지속적으로 재검토하고, 개발에 방해가 된다면 메타포를 포기할 준비를 하라. … SYSTEM METAPHOR는 모든 프로젝트에서 유용한 것은 아니다. 큰 규모의 구조는 일반적으로 필수적인 것이 아니다. … XP의 12가지 프랙티스 중에서 SYSTEM METAPHOR의 역할은 UBIQUITOUS LANGUAGE에 의해 실현될 수 있다. 프로젝트는 적절하다고 판단될 경우 SYSTEM METAPHOR나 큰 구조의 구조를 사용해서 UBIQUITOUS LANGUAGE를 확장해야 한다.
- Eric Evans[Evans DDD]
참고자료
- [Beck METAPHOR] Kent Beck, The Metaphor Metaphor, http://www.oopsla.org/2002/fp/files/spe-metahpor.html
- [Beck XPExplained1] Kent Beck, Extreme Programming Explained: Embrace Change, Addison-Wesley Professional, 1999
- [Beck XPExplained2] Kent Beck, 익스트림 프로그래밍, 인사이트, 2006
- [Cohn STORY] Mike Cohn, 사용자 스토리, 인사이트, 2006
- [Evans DDD] Eric Evans, Domain-Driven Design, Addison-Wesley, 2003
- [Fowler DESIGNDEAD] Martin Fowler, Is Design Dead, http://martinfowler.com/articles/designDead.html
- [Fowler WNA] Martin Fowler, Who Needs An Architect? http://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf
- [Hendrickson C3] Garzaniti, R., Haungs, J., Hendrickson, C.: Everything I Need to Know I Learned from the Chrysler Payroll Project. In: SIGPLAN Conference on Object-Oriented Programming, Systems, Languages, and Applications (Addendum), ACM Press(1997), 33-38
- [Hunt PRAGMARTIC] Andrew Hunt, David Thomas, 실용주의 프로그래머, 인사이트, 2006
- [Jeffries XPInstalled] Ron Jeffries, Extreme Programming Installed, 인사이트, 2002
- [Kerievsky METAPHOR] Interview: Joshua Kerievsky on System Metaphor, http://www.infoq.com/interviews/kerievsky-metaphor
- [Larman AUP] Craig Larman, UML과 패턴의 적용 2/e, 홍릉과학출판사, 2003
- [Philippus Spike] Erik Philippus, Architecture Spike, http://www.agile-architecting.com/Architecture%20Spikes.pdf
- [Poppendieck LEAN] Mary Poppendieck, Tom Poppendieck, 린 소프트웨어 개발, 인사이트, 2007
- [Wake XPExplored] William C. Wake, Extreme Programming Explored, Addison-Wesley, 2001
'IT_Architecture > Design Pattern' 카테고리의 다른 글
| Resource Release Patterns (0) | 2014.03.31 |
|---|---|
| [펌] 단일 접근 원칙(Uniform Access Principle)을 통한 캡슐화 (0) | 2014.03.31 |
| Framework (0) | 2014.03.31 |
| [펌] 객체지향 개발 5대 원리: SOLID (0) | 2014.03.25 |
| [펌] 객체지향 SW 설계의 원칙 (0) | 2013.01.25 |