오늘날의 시스템은 분산되어 있고, 느슨하게 결합되어 있습니다. 느슨하게 결합된 시스템을 구축하는 것은 조금 귀찮은 작업입니다.,  우리는 왜 이런 귀찮은 작업을 해야 될까요? 우리는 조그만 변화로 시스템들이 산산이 부서지는 것을 원하지 않기 때문에,  우리의 시스템들이 (변화에) 유연하길 원합니다.

오늘날의 환경에서 유연함은  매우 중요한 자산입니다. 여기서 우리는 어플리케이션의 작은 부분만을 제어할 수 있습니다. 분산 서비스나 써드-파티 패키지들에서 작동하는 나머지 부분들은 다른 부분이나 외부 밴더 들에 의해 제어됩니다.

그래서, 변화에 유연하고 시간이 흐름에 따라 진화할 수 있게 시스템을 구축하는 것은 좋은 노력처럼 보입니다. 하지만, 이것은 우리의 시스템이 시간이 흘러감에 따라 변할 수 있음을 의미합니다.  “오늘날의 시스템은 더 이상 어제의 시스템이 아니다.” 라는 것처럼..

불행하게도, 변화는 문서화하는 것도 어렵게 만듭니다. 항상 변경되는 시스템에서는, 문서가 프린터 되는 순간 그 문서는 구식으로 되어 버리고, 이러한 상황들이 심해질 수 있습니다. 게다가, 일반적으로 유연하게 시스템을 구축 하는 것은 아키텍쳐가 좀더 복잡해 지는 것을 의미하며, 잘 알려진 “Big Picture (큰 그림)”[1]을 얻기 어렵습니다.

예를 들어 만약 모든 시스템의 컴포넌트들이 꼭 설정 가능한 채널을 통해 다른 구성요소들과 통신을 한다면, 컴포넌트들은 어떤 행위를 (무엇을 해야) 할지에 대한 정보를 얻기 위하여 채널 설정부만 바라보면 됩니다.

논리적인 채널인 la-la-land[2]에 메시지를 보내는 것은 컴파일러 에러를 발생시키지 않지만, 메시지를 변환하여 보낸 사용자가 (아무런 결과나 응답을 받지 못해) 실망하는 것은 당연합니다.

제어를 중요시 여기는 아키텍트가 되는 것은 오래 전 얘기입니다. 제어를 중요시 여기다 보면, 강한 결합과 불안정한 솔루션을 만듭니다. 그렇다고 소프트웨어를 손대지 않고 가만히 내버려 두면, 혼돈이 발생되는 것도 당연합니다. 그래서 특정한 도구(방법론, 정책 등) 없이 소프트웨어를 유지(계기 비행) 하는 것을 피하기 위해, 제어의 부족함을 다른 메커니즘으로 보완해야만 합니다.

그럼 우리가 가지고 있는 도구는 어떤 종류가 있을까요? 많습니다. 실제로 오늘 날의 프로그래밍 언어는 리플랙션을 지원합니다. 그리고 거의 모든 런타임 플랫폼들은 런타임 매트릭스들을 지원합니다.

당신의 시스템이 좀더 설정 가능하게 됨으로써, 현재 시스템 설정 부는 정보를 나타내는 또 다른 좋은 예(본보기 – Source)가 됩니다. 왜냐면 너무 많은 Raw 데이터들은 이해하기 어렵고, Raw 데이터들로부터 정확히 모델을 추출하기도 어렵습니다.

예를 들어, 어떤 컴포넌트가 논리적인 채널들에 메시지를 보낸 것을 한번에 알았다면, 컴포넌트 간에 실제 커뮤니케이션 정보를 그래프 모델[3]로 생성할 수 있습니다. 당신은 매 몇 분, 몇 시간 동안 그래프 모델에 변화를 반영함으로써, 시스템의 형태가 정확해지고 항상 최신의 정보를 제공할 수 있습니다.

이것을 “Reverse MDA [4](역 MDA)”로 생각하면 됩니다.  아키텍쳐로부터 모델을 이끌어 내는 것 대신에, 당신은 유연한 아키텍쳐를 구축하고, 실제 시스템의 상태로부터 모델을 추출하십시오.

많은 경우, 모델을 시각화 하고, 정확한 큰 그림을 생성하는 것은 쉽습니다. 하지만, 시스템의 모든 클래스를 포함하는 박스(클래스와 같은 UML에서 표시되는 Element)들과 줄(연관관계를 나타내는 Element)들을 3×5 미터의 커다란 광고판 형태로 만드는 유혹을 뿌리쳐야 합니다.

이런 그림은 현재 기술로서 만들어 질 수 있지만, 유용한 소프트웨어 모델이 아닙니다. 대신 Erik Doernenburg가 묘사한 1.000 피트 (적절히 추상화된) 뷰를 사용하십시오. 적절한 추상화는 실제적으로 당신이 어떤 것을 해야 할지 말해 줍니다. 높은 추상화 단계의 관점에서는, (종속성을 표현하는 그래프에서 순환 의존 관계 (circular dependency)의 존재 유무, 논리적 채널로 보낸 메시지가 없다면, 이 메시지를 대기하고 있는 부분이 없는 것과 같은) 기본적인 유효성 룰들을 표현해야 합니다.

제어하지 않는 것은 무서운 일입니다. 심지어 이런 일이 시스템 아키텍쳐에서 일어난다면….

그러나 관찰, 모델 추출, 유효성 검증을 통해 보완할 수 있습니다. 이건 아마도 오직 21세기의 아키텍트만 사용할 수 있는 혜택(방법)일 겁니다.

Written by Gregor Hohpe

이 자료는 Creative Commons Attribution 3 라이센스를 준수합니다.

[2] 꿈의 나라, 비현실적인 세계, 특히, 영화·TV 산업과 연관 지어 Los Angeles, Hollywood, 남 캘리포니아를 가리킴

[3] UML의 Sequence Diagram, Collaboration Diagram 을 말한다.

[4] Model Driven Architecture