SoC와 복잡성에 대한 고찰..

전 왜 이런 소리(Toby님, 안영회님) 를 들어야 할지 모르겠네요.   일단 전 문제 그 자체에 집중해서 포스팅 하겠습니다.  🙂

복잡성(Complexity) 에 대한 생각들..

먼저 Complex (복잡하다)에 대한 명확한 정의를 내리고자 합니다.

어원적으로 보면 Com(Together) + Ple (Tie , Bind) 의 의미로 구성되어 있습니다.  여러개가 묶여 있는 것을 복잡하다고 말을 합니다.  그것이 서로 얽히고 섥혀 있으면 복잡하다는 것이지요.  결국 복잡의 의미는 Toby님과의 말에 별 의견이 없습니다.

우리가 느끼는 복잡성(Complexity)를 숨길 수는 있어도 결코 사라지지는 않는 다는 것입니다. 누군가는 떠 안아야 된다는 거지요..

우리가 심플함의 대명사로 말하는 Apple 제품이 기존 타사 제품의 복잡함과 비교 설명할 때 자주 보여지는 그림이 한 장 있습니다.

이 그림만 본다면, 아 복잡성이 줄어 들었구나 라고 말할수 있습니다. 하지만 사실 그럴까요?   결국 둘다 동일한 기능을 해야 한다면, 결국 그 기능을 선택할 수 있는 것이 어디상에는 존재해야 될겁니다.

결국 Remote Controller는 간단해 졌을진 모르지만, 실제 사용자가 화면을 통해서 제어하는 프로그램은 더욱 복잡해 졌을 겁니다.   이 UI에서는 이 버튼을 누르면 A라는 기능을 또 이 상황에서는 이 버튼을 누르면 B라는 기능을 할수 있는 Context-Aware 기반의 Programming이 더 들어갔을 겁니다.

거기다 친숙한 UI를 통해서 이걸 전혀 불편하게 느끼지 않기 위한 UI, 흥미, 기술들이 곳곳에 존재하기 때문입니다.  결국 구현하는 입장에서는 더 많은 비용이 들어갔다는 것이지요.   결국 외부로 보이는 복잡성을 줄일지 몰라도 프로그램 자체는  내부적으로는 더 큰 복잡성을 안고 갔다는 것입니다.

SoC 복잡성을 줄여준다.

SoC는 복잡성을 줄여주는 대명사 입니다.  그건 당연하죠.

Divide and Conquer는 우리가 객체 지향 이전인 Functional한 언어에서도 잘 사용했던 개념입니다.  잘게 나누어진 각 Feature에 그 분야의 문제에만 집중을 하면 됩니다.  DB 접근 모듈은 DB만,  Network Infra는 Infra만 , Business Logic은 Business Logic만 다루면 되는 거죠 🙂  그러니  Feature 하나 하나의 입장에서만 본다면 분명 복잡성은 줄어든 것입니다.  쉽게 말해 인식할수 있는 범위를 줄여 생각의 복잡성을 줄여준 것입니다. 당연히 인간의 인식이나 생각의 한계로 인해 나누는 것은 기본적인 요소입니다.   그러나 Feature를 나누다 보니 이 Feature간에 Realtionship과 Chain을 구성하게 됩니다.  문제는 여기서 또 다른 복잡도(Complexity)가  생기게 된다는 것입니다.

SoC 잘 게 나누기가 발생시키는  또 다른 복잡성 이야기 (Ripple Effect)

유지보수, 배포, 관리의 복잡성이죠.   이렇게 잘게 나누어진 모듈들이 하나로 잘 엮여야 작동한다는 점이죠.  물론 처음 생성하는 것만 보자면 일시적인 작업의 양(?)의 문제라고 할수 있지만, 유지 보수/ 관리의 차원에서 보자면 결코 일시적인 양의 문제가 아니라, 발생한  Chain이 복잡성을 야기시키게 됩니다.

문제는 각각 쪼개진 모듈들이 잘 나누어서 아주 변화에 유연하게 대처할 수 있다면 나이스겠지만, 어떠한 요구사항이 변경되지 모르는 입장에서 잘 설계한다는 것은 매우 어렵습니다.  특히 한국같이 고객의 요구사항이 절대적인 갑이며, 자주 흔들리는 곳은요.  Software 고전에서 항상 언급 하는 애기인 Software는 결코 Soft하지는 않다는 것입니다.

결국 한 모듈에서 변경 사항이 발생하면 그 변경사항들을 잘 완화할 수 잇는 장치(Interface, 메세징 기반의 전송등)을 마련해 줘야 하며, 이 Interface를 얼마나 잘 설계 할수 있을까 그것이 문제입니다.  될수록 하나의 Feature나 Layer에서 그러한 변화를 잘 수용할 수 있게 설계되었다면 감사하죠 :).

하지만 그렇지 못한 경우가 더 많습니다.  기존의 Interface가 뒤 엎는 경우는 없더라도,  추가되는 경우는 없나요?  그럼 그 여파는 여기저기로 확산되어 갑니다.   특히 각각의 모듈 들이 물리적으로(dll) 나뉘어져 있으면, 하나의 변경으로 인해 모든 모듈을 재 컴파일 해야 되는 버거움이 발생합니다.

출처 - http://www.adoptionblogs.com/media/ReactiveAttachmentDisorder/Ripple%20Effect.jpg

서로 얽히고 섥혀서 이때는 한숨을 쉬며, xDepend (JDepend, NDepend)와 같은 툴을 이용해 조심히 따라가는 수 밖에요.   이러한 것을  Change Propagation 또는  파문 효과(Ripple Effect)라고 합니다.

결국 변화를 잘 수용할 수 있게 잘 나누지  못하면, Dependency의 문제로 배포와 의존성 파악으로 골치 아픈 머리가 발생합니다.

결국 완충제들을 잘 두는 방법과 Dependency가 한 방향으로 흘러 갈수 있게 잘 설계해야 됩니다.

( Circular Dependency가 발생하면 여러분을 지옥으로 인도하기 때문이지요..   )

이러한 문제를 해결하기 위해 Aspect, Meta 지향적인 기술(Reflection)등을 사용하면 상황에 따라서는 기술 습득의 비용, 가독성,  Performance와 같이  무언가에 대한 비용을 지불해야 되는 상황이 발생하기도 합니다.

객체의 사이즈 잘 자르기?  응집도와 결합도

이건 객체 지향 Principle에 언급하는 상당히 상충되는 개념이 다시 애기된 것에 불과합니다.

바로 응집도와 결합도죠.  하나의 모듈에 많은 기능이 응집되면 다른 모듈과 Dependency가 작아지기 때문에 좋습니다.  하지만 책임성(Responsibility)은 커지죠.

하지만 하나의 객체가 많은 책임(Responsiblity)를 가지는 것이 좋지않습니다. 결국 결합도나 SRP(Single Responsibility Principle)  입장에서 보자면, 객체가 적은 책임(Responsibility)을 가지는 것으로   나누는 것이 필요합니다.   결국 문제는 이 적절한 사이즈로 나누기가 그리 쉽지는 않다는 것입니다.

CORBA와 WCF에서 배우는 교훈들.

1. Ripple Effect의 좋은 예 – IDL  Compiler

실례로   CORBA와  Microsoft 사의 Web Service (WCF)에서 생성되는 코드들을 기반으로 예로 들어보도록 하겠습니다.

CORBA나 Java 진영의 초창기 Web Service 같은 경우는 IDL 이라는 매개어를 만들어 놓고 이 녀석을 IDL 컴파일로러 컴파일 한 다음, 생성된 코드들을 기반으로 우리가 추가 코드를 넣는 작업을 했습니다. 이때 가장 당혹 스러웠던 것이 새로운 인터페이스가 추가 되거나 변경되었을때 였습니다.

결국 자동 생성되어야 하는 Marshaling / Unmarshaling 하는 코드들 때문에 IDL로 재 컴파일 하고, 기존에 완성되었던 코드들을 CV 신공으로 대치하거나 변경해야 했지요.  그때 인터페이스를 누가 바꾸었냐며 투덜거리죠 🙂  IDL로 부터 그 여파가 전형적으로 미치는 경우입니다.   좋은 Ripple Effect의 예입니다.

2. Metadata가 발생시키는 문제 – 학습 곡선

또한 다양한 변화를 수용하기 위해서, 결국 Metadata 또느 Aspect와 같은  Approach 를 취하게 됩니다.

Microsoft의 Windows Communication Foundation이 대표적인 예라고 할수 있습니다.  변할 수 있는 많은 부분들을 Metadata 형태로 제공을 하게 되죠. 하지만 또 하나의 문제는 많은 학습 곡선을 요구한다는 겁니다.  실제 Framework  설계시 중요한 부분이 기존의 다른 사람의 경험을 얼마나 살려 익숙하게 사용할 수 잇는냐가 관건입니다.

좋은 일례로 제가 번역에 참여하고 있는 Framework Design Guideline 2nd Edition 에서 .NET Framewokr 설계자인 Krzysztof Cwalina느  기존의 VB 개발자에게 많은 욕을 먹었습니다.  VB.NET 같은 경우는 VB 개발자의 입장에서는 기존의 경험을 거의 살리지 못했기 때문이죠. 그래서 학습 곡선을 얼마나 쉽게 완하시키느냐가 중요한 요소입니다.

관련 의견 - http://channel9.msdn.com/shows/Code+To+Live/Code-to-Live-Richard-Hale-Shaw-on-WCF/

다시 돌아와 애기하면, Microsoft 분야의 유명 컨설턴트인 Richard Hale Shaw의 의견과 같이, 너무나 수많은 설정 파일로 변화를 유지할 수 있게  했지만 기대만큼 WCF는 활성화되지 못했습니다.  그 이유는 이 메타지향적인 Approach였고 기존 .NET 개발자에게는 익숙하지 못했기 때문입니다.

그래서  Microsoft 는 요즘 별도의 Pattern&Practice 팀을 만들어 학습 곡선을 최소화 할수 있는 Software Factory(Application Block)을 만들게 됩니다.

재미난 것은 이게  Graphical Modeling Tool이라는 겁니다.  메뉴얼 보다는 학습 곡선을 줄일 수 있을 뿐만 아니고,  Guideline에 맞춰서 Tool이 동작하기 때문에 Step by Step으로 설계시 준수사항들을 줄여줄수 있습니다.

그냥 그래픽 나부랭이 툴이 아니라, WCF 개발자에게는 아주 유용한 경험이 담긴  DSL이라는 겁니다.

그럼 제가 언급한 것 처럼 EA를 통해서 안정화된 경험이 담긴 Frmaework들을 사용하여 잘 정리된 Template Code를 만들어 놓고  찍어 낸다면 더 좋고 효율적이지 않을까요?  과연 이것과 무슨 차이인지 저로서는 잘 이해가 안됩니다.

안영회님이 언급한 것처럼 사람은 인식할수 있는 인지의 양의 한계가 있습니다.   SoC로 인해 잘게 나누게 되면 하나의 시나리오를 파악하기 위해 긴 Chain을 따라가면 흐름을 파악해야 됩니다.  그것보다는 모델링 툴에서 일괄적으로 흐름을 파악하는 것이 더 낫지 않을까요?

결국 Framework이나 모델링 툴도 그냥 하나의 Tool일 뿐입니다. 현재 SoC 문제가 발생하는 인식의 문제, 배포의 문제를 해결을 잘해주는 Framework은 잘 찾지 못했습니다.   전 이것을 EA를 접목해 잘 사용하고 있다고 말씀 드렸을 뿐이고 그걸 공유하려고 했을 뿐입니다.   더 좋은 말씀 있으시거나 가르침이 있으시면 겸허히 받아들이겠습니다.   감사합니다.