이전 글에서는 복잡하다는 정의가 무엇인지 살펴보고, 단순히 작업의 양이 일시적으로 증가했다는 것 만으로 복잡하다고 말하는 것은 잘못된 설명이라고 지적했다. 참조한 글의 전체적인 내용에 대해서 비판한 것은 아니었고 그럴 의도도 없었으므로 S1A 2008이후에 자주 생각했던 복잡함의 문제에 대해서 그간 생각하면서 항상 걸렸던 복잡하다는 개념에 대해서 생각해봤던 간단히 정리해본 것이다.

그런데 arload님이 자신의 글에 대한 부가적인 설명을 올리고 피드백을 직접 요청하셔서 조금 더 생각을 적어본다. (한창 바쁜데.. 블로그는 역시 시간 잡아먹는 괴물이닷)

 

SoC(Seperation of Concerns)가 가져오는 복잡성을 극복하는 법이라는 글을 다시 살펴보자.

각 모듈마다 특정 문제에만 집중해서, 해결할 수 있게 나누어서 생각하자는 것입니다.  N – Tier 기반의 Application이 좋은 예라고 할 수 있을 겁니다. (물론 성능적인 이슈도 있지만요)

하지만 이 철학으로 인해 너무나 잘게 클래스들이 쪼개져서,  실제 프로젝트를 할때 기능 하나를 추가하기 위해 여러개의 객체를 수정해야 하는 엄청난 고통을 가져오는 상황이 발생합니다.

 

SoC는 소프트웨어 개발에서는 매우 일반적인 원칙이다. 객체지향의 모듈화, 캡슐화, 정보은닉이나 아키텍처에서 말하는 멀티 레이어 기반의 접근방법 등은 그저 SoC의 철학을 적용한 특별한 방법일 뿐이다. 하지만 위에서 인용한 부분을 읽을때 불편했던 점은 arload님이

  1. SoC = 자신이 경험한 멀티티어(레이어) 개발방법으로 너무 제한시켜버렸고
  2. 너무나 잘게 쪼개졌다는 표현에서 볼 수 있듯이 SoC는 과도한 분할, 분리를 가져올 수 밖에 없는 것으로 묘사되었으며
  3. SoC개념이 적용되어 분리된 애플리케이션에 기능이 추가할 때는 여러 객체가 수정되야 하는 고통이 있다고

주장한 부분이다.

하나씩 살펴보자.

 

SoC는 멀티 레이어 아키텍처를 말하는가?

아니다. 프로그램의 다양한 측면(aspect)에 대해서 한번에 한가지에 집중할 수 있도록 분리하는 모든류의 작업의 원칙을 말한다. 예를 들어 전체 알고리즘에서 특별한 작업을 하는 부분을 별도의 메소드로 뽑아내어 분리하는 것도 SoC이다. 추상화 작업을 통해서 클래스 계층구조를 만들고 상하위 클래스에 각각 책임레벨을 구분해서 주고 추상화 정도에 따라 이를 구분해서 접근하는 것도 SoC이다. 아예 클래스를 분리하고, 인터페이스를 이용한 객체조합(composition)을 사용하는 것도 SoC이다. AOP처럼 아예 분산되어 나타날 수 밖에 없는 관심사항(cross-cutting concerns)를 애스팩트로 분리해내 일괄적으로 적용하도록 하는 것도 SoC이다.

물론 멀티티어,레이어 방식의 아키텍처나 시스템 구성도 SoC의 한가지 실현이라고 본다. 하지만 멀티레이어라는 것도 사실은 매우 다양한 실체화가 가능하다. 코로케이션 방식으로 한 시스템의 한 VM의 한 모듈화된 파일의 한 로더를 사용하면서도 그 안에 얼마든지 3-tier 이상의 멀티 레이어 구조를 만들어서 사용할 수 있다. 이를 좀 다르게 접근해서 별도 모듈레벨로 분리하고, 별도로 개발,배포하는 구조를 만들 수 있다. 더 나아가 아예 서버를 분리해서 원격호출을 사용한 분산 레이어를 만들 수도 있다.

자, 이렇게 다양한 SoC의 실체화가 가능하다는 얘기는, 다른 면으로 말하자면 SoC의 원칙이 가장 효과를 발휘할 수 있는 구체적인 전략을 찾아내는 수고가 필요하다.

하지만 arload님은 SoC를 바로 레이어 아키텍처로 특화시켰다. 그것도 글을 읽어보면 DLL이 달라지면 컴파일을 다시 해야 하는 멀티(파일)모듈을 사용하는 것으로 매우 제한적으로 설정한 뒤에 그런 특별한 SoC의 실체에 대한 비판을 SoC전반에 대한 비판으로 확대해석하는 오류를 범하고 있다.

 

SoC는 너무 잘개 쪼겨지거나 과도한 분리를 가져온다

반박할 가치도 없는 말이다. SoC가 과도하게 잘게 쪼개라는 원칙이라는 것은 도대체 어디서 나온 발상인지 모르겠다. SoC에서 아마도 S(분리)만 뜯어내서 생각한 것이 아닌가 싶다. SoC의 C(관심사)에도 관심을 가져주면 좋지 않을까? SoC는 그저 쪼개자는 분리주의가 아니다. 공통의 관심, 함께 모아서 생각하고, 관리하고, 같이 다니면 좋은 것들로 분리하자는 것이다. 사실 때론 이것이 기계적인 분리가 아니라 통합일 수도 있다. 불필요하게 쪼개진 분산된 공통의 관심은 모아주기도 하는 것이 SoC이다. 왜 AOP를 SoC라고 할 수 있는가? 그것은 각 오브젝트에 흩어진 횡단관심을 모아주기 때문이다. SoC에게 과도한 분리, 너무 잘개 쪼개는 바보 같은 짓의 책임을 떠넘길 수 없다.

CORBA, EJB2등과 같이 오버엔지니어링 때문에 불필요한 복잡함을 도입한 기술들이 주는 부작용들을 SoC원칙에 떠넘기지 말아야 한다.

 

SoC는 기능을 추가할 때 여러 객체가 수정되어야 한다

내가 가장 이해할 수 없는 주장이다. SoC는 공통의 관심사를 따로 모이게 한다. 이를 제대로 적용한다면 기능이 변경될 때에 바뀌는 부분이 작은 영역으로 한정되어야 한다. 왜냐면 변화는 항상 특정 관심에 집중하게 되기 때문이다. SoC야 말로 기능이 추가되고, 변경될 때 변경되는 영역을 최소화 해준다. 심지어 아키첵터가 변경이 되어도 최소한의 변화를 가져다 줄 수 있다. 개발이라는 것은 기능의 추가 이상의 수정, 변화의 작업이 요구되는데 SoC는 이 때에 빨리 대응할 수 있게 해준다.

만약 책임이 여러곳에 분산되어 있다면, 리팩토링에서 말하는 산탄총수술과 같은 문제가 발생해서 하나의 변경요구가 많은 객체로 퍼저나간다. 그럼 SoC를 적용해서 이를 한곳으로 모아야 한다.

아마도 arload님의 이 주장은 새로운 모듈을 통채로 만들 경우 초기에 만들어야 할 파일의 갯수가 많아진다는 것이 아닌가 싶기도 하다. 이전 글에서 지적했듯이, 그것은 양적인 문제이고 복잡도의 문제가 아니므로 arload님이 좋아하는 초기 코드생성이나 템플릿 엔진을 사용하면 된다. 하지만, 애플리케이션이 점점 복잡해지면 모듈간에 상호 의존도가 높아지고, 결국 새로운 모듈을 추가할 때도 기존의 기능을 재활용하게 되는 경우가 많아진다. 따라서 이런 경우에도 SoC는 작업을 줄여주지 늘리지 않는다.

혹시 모르겠다. 애플리케이션에는 로직이란 없고 그저 UI와 DB사이에 트랜잭션 스크립트 처럼 동작해서 기능 하나하나가 완전히 분리되어, 마구 중복로직이 들어감에도 독립적으로 만든다면 매번의 작업이 레이어를 나누고, 클래스의 갯수를 증가시켰으니 늘어날지도 모르겠다. 그런데 그걸 SoC의 책임으로 떠넘겨야 하는 것일까?

이 주장에 대해서는 얼마전 조엘이 한 "TDD를 하면 기능 하나 변경하면 10%의 테스트가 깨지더라"는 궤변에 대해서 객체지향설계원칙으로 유명한 엉클 밥이 한 대답인 "그런 수준이라면 차라리 직업을 바꾸지그래?"라는 것을 답변으로 돌려주고 싶다.

 

물론 arload님의 글쓴 의도는 잘 이해한다. 코드생성기나, 잘 만들어진 모델-코드 전환 툴이 유용한 경우가 있다는 것에도 동의한다. 내가 불만인 것은 단어의 선택이다. 멋진 개념을 담은 어휘들을 가져다가 적절치 않은 예에 부합시켜서 설명한다는 것이 내 불만이다. 그것을 일반화 시켜서 SoC는 복잡함을 가져오는 문제가 많은 레이어 아키텍처의 원흉이라고 소개되는 것이 맘에 들지 않는다.

 

특히 IDL컴파일러의 예는 특히 적철지 않았다. 그것은 SoC와 하등의 관계가 없다. 이건 SoC에 대한 중상모략이다. 분산객체기술을 도입하려면 네트웍을 설치해야 하는 번거로움이 있으니 SoC는 고통스럽다고 말하는 수준과 뭐가 다른가. 오히려 SoC는 인터페이스(contract)를 이용해서 적절한 분리(낮은 결합도)를 유지하게 하는 것을 통해서 한 모듈이 원격에 배치되든, 같은 VM안에 배치되는 상관없이(또는 그것이 중간에 변한다고 해도) 모듈의 순수한 책임과 로직에만 집중해서 개발할 수 있게 해주는 장점을 주는 것이라고 설명해야 한다. 구지 실패한 구시대 기술인 CORBA의 스텁생성에 대해서 비판하려면, 그 분산객체기술의 구현전략에 대해서 비판해야 할 것 아닌가?

 

이에 대한 보충 설명으로 오늘 올리고 피드백을 요청한 글인 Separation of Concerns와 복잡성에 대한 고찰을 살펴보자.

복잡성에 대한 생각이라는 내용을 보면

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

라고 되어있다.

복잡성이 사라지지 않는 것이다라는 것은 반만 맞는 주장이다. 소프트웨어 개발에서 사라지지 않는 복잡성이 있다. 고객의 요구사항, 업무 프로세스, 비즈니스 로직 또는 특별한 기술적 요구사항이다. 근본적인 복잡도는 개발과 상관없이 유지된다. 하지만 제거 가능한 복잡함이 있다. 그것은 불필요한 복잡함이다. 잘못 설계된, 관심사가 섞이고, 개발이 복잡해지고, 시간이 지날 수록 파악하기 힘들고, 수정하려면 큰 비용이 들게 만드는 복잡함이 있다. SoC가 관심을 가지는 것은 후자이다.

그런면에서 복잡성은 사라지지 않지만, 줄일 수 있다. 동시에 불필요한 복잡함은 근본적으로 제거 가능하다. 그런면에서 복잡함은 숨길수는 있지만 사라지지 않는 다는 말은 틀렸다.

거기다 친숙한 UI를 통해서 이걸 전혀 불편하게 느끼지 않기 위한 UI, 흥미, 기술들이 곳곳에 존재하기 때문입니다.

결국 구현하는 입장에서는 더 많은 비용이 들어갔다는 것이지요.   결국 외부로 보이는 복잡성을 줄일지 몰라도 프로그램 자체는  내부적으로는 더 큰 복잡성을 안고 갔다는 것입니다.

이건 참으로 엉뚱한 설명이다.

UI의 불편함을 없애고 편리하게 쓰게 만들어주느라 프로그램은 복잡해졌다는 것과 지금 SoC와 관련해서 말하는 복잡함은 아무 관련이 없는 내용이다. UI의 복잡함이 줄었다는 것은 "요구사항, 기능"과 관련한 것이다. 그때문에, 즉 기능을 추가 또는 개선하므로 프로그램이 복잡해졌다는 것은 너무나 당연한 얘기다. 지금 우리가 말하는 SoC가 복잡함을 줄인다는 얘기는 같은 조건하에서 SoC를 적용해서 프로그램을 개발하는 것이 그렇지 않았을 때보다 덜 복잡할 수 있다는 것이다.

복잡함이라는 개념을 엉뚱한 층위에다 부여하고 설명을 하려는 이유를 알 수 없다.

 

물론 복잡함을 다루는 기술에는 기술적인 복잡함을 줄이기 힘든 업무로직구현의 복잡함과 분리(SoC)시키고, 그 기술적인 복잡함을 하위 프레임워크에 전이 시킴으로 해서 개발자들이 다뤄야 하는 복잡도의 문제를 줄이는 방법을 얼마든지 사용할 수 있다. 이때 복잡함은 사라졌다기 보다는 효과적으로 다뤄지고 있다고 보는 것이고, 결국 기술과 로직 구현의 복잡도의 총량은 그 분리된 복잡함을 프레임워크나 서브 기술이 다뤄주는만큼 감소하는 것이다. 진작에 기술과 로직의 복잡함의 분리가 없었다면 과연 그럴 수나 있었을까?

 

계속 보면, 결국 arload님이 주장하려는 것은 정리해보면 분리를 하면 분리된 사이에 관계라는 새로운 복잡함의 근거가 발생한다는 것이다. 클래스 하나 일때보다 두개로 나눌 때가 관리하기가 번거로워진다는 것은 사실이다. 관계설정이라는 부분(인터페이스 도입)이 생긴다는 것도 사실이다. 그건 트레이드 오프이다. 일반적으로는 그렇게 발생하는 새로운 복잡함이 원래의 복잡함보다 훨씬 작다고 판단되어지기 때문에 SoC를 한다. 앞에서 지적했듯이 불필요하게 세분화해서, 오히려 하나의 관심을 퍼뜨려서 만들어버리면 더 지저분해진다. 나는 이것도 SoC의 원칙이 포용하는 부분이라고 본다.

다시 말하지만 SoC의 C는 arload님이 얘기한 feature에 제한되는 것이 아니다. 유지보수, 배포, 관리에 대한 관심도 공유된다면 가까이 모으면 된다. 그리고 클래스 한두개 쪼개는 것이 유지보수 배포 관리에 큰 지장을 줄까? 그것은 유지보수, 배포, 관리에 대한 기술의 문제이지, 관심사를 분리하기 때문에 나는 것이 아니다.

경험에서 나온 것이라고 추측되지만 이부분에 대해서 arload님은 너무 과장하고 확대해서 일반화 시키는 경향이 있는 듯 하다.

 

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

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

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

결국 결론은 이것인 것 같다. 잘못설계된 구조에서는 많은 문제를 일으킬 수있다는 것 아닌가? Arload님 경험이나 관찰로는 그렇지 못한 경우(변화를 잘 수용할 수 있게 설계지 못한)가 많다니 안타까울 뿐이다.

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

결국 arload님의 주장을 어렵싸리 정리해보면 이런 것 같다.

"SoC가 레이어 아키텍처나 분산객체의 방식의 만들어질 때 잘못 설계되어지면 변화에 더 대응하기 힘든 경우가 생기니 SoC는 어렵다"

차라리 처음부터  "내가 경험한 레이어 아키텍처의 경우에는 잘못 설계되어서 오히려 변경시 고통이 따른 적이 많다. 그런 경우에는 툴의 지원을 받아보는 방법이라도 사용해보자." 라는 식으로 설명했다면 낫지 않았을까 싶다.

 

그리고 이어서 다시 코바의 IDL컴파일러 설명이 나오는데, 그럼 코바와 같은 원격객체기술을 사용하지 않으면 퍼블리슁된 인터페이스가 주는 변화의 부담이 없어지는가? 같은 모듈 안에서 그 기능을 통합했다면 그 인터페이스의 변화에 더 빨리 대응이 되는가? 아니, 그 기능이 SoC가 전혀 안되서 다른 모듈에 여기저기 중복되어 있으면 그것을 모두 수정하는게 더 빠르고 쉽게 되는가?

그리고 원시시대 코바나 자바 고리쩍 얘기는 제발이지 그만했으면 좋겠다. 닷넷은 잘 모르겠지만 자바의 경우 원격 인터페이스에 대해서 코드 생성 방식을 버린게 벌써 언제쩍 얘기인데, 아직도 그것을 가지고 설명하려고 하는지 모르겠다.

이어지는 메타데이터가 주는 학습 부분을 잠깐 보면 (이건 사실 관심사가 아니지만)

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

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

WCF가 활성화 되지 못한 것은 사용자들의 수준을 고려하지 못한 잘못된 설정방식, 설계의 문제였나보다. 비슷한 문제가 있었던 EJB2, 스트럿츠가 오래전에 그랬듯이 툴을 통한 해법으로 가려는 듯하다. 툴은 임시방편일 뿐이다.

 

그리고 자꾸 반복하게 되는데 "SoC는 그저 잘게 나누어 고통을 주자는게 아니다". 모델링 툴을 통한 접근 방법에 대해서는 모델링 컨설턴트인 영회가 제대로 답변을 해주면 될 것 같다.

 

arload님은 왜 나와 영회에게서 이런 소리를 들어야 하는지 모르겠다고 하셨는데, 영회가 한 말에 대해서는 언급하고 싶지 않고, 내가 왜 이런 설명까지 해야 하는지에 대해서 잘 모르시겠다면… 뭐 어쩔 수 없지. :)

 

나는 복잡함은 효과적으로 다뤄질 수 있다고 믿으며, 그 중심에는 SoC와 같은 좋은 원칙이 있다고 생각한다. 어쩌면 너무나 당연한 상식과 갈은 이 개념이 어설픈 실현과 적용으로 인해서 개념적으로 아예 모욕당하는 것에 대해서 답답하다.

강규영님이 올린 컬럼에 나오는 부분을 인용하며 대충 마치고 밥먹으러 가야겠다. 영회 때문에 나까지 이게 먼 고생이람…

돌이켜보면 프로그래밍의 역사는 복잡성을 효과적으로 다루기 위한 사고의 발전 과정으로 볼 수 있다. 복잡한 논리의 흐름을 몇 가지 기본적인 제어 구조로 분해하는 방법(structured programming theorem), 거대한 시스템을 작은 모듈들로 나누는 효과적인 방법(modular programming), 시스템을 객체 간 메시지 교환이라는 관점에서 풀어내는 방법(object oriented programming), 시스템의 다차원적 관심사(concern)를 식별하고 각각을 모듈화하는 방법(aspect oriented programming), 이러한 사고 방식을 적절히 표현하기 위한 시각화 언어(UML) 등이 그러한 발전 과정에서 나타났다.

Related posts:

  1. SoC(Separation of Concerns)는 복잡도를 증가시키는가?

Facebook comments:

to “복잡함을 상대하는 기본적인 전략 – SoC”

  1. Pretty! This was an extremely wonderful post. Many thanks for supplying this info.

  2. You’ve made some decent points there. I looked on the net for more information about the issue and found most people will go along with your views on this site.

  3. Very nice post. I certainly love this website. Keep it up!

  4. Very good post! We are linking to this particularly great post on our site. Keep up the great writing.

  5. A fascinating discussion is definitely worth comment. I do think that you need to write more on this issue, it may not be a taboo matter but generally folks don’t discuss such subjects. To the next! Best wishes.

  6. Oh my goodness! Awesome article dude! Thank you, However I am having troubles with your RSS. I don’t understand the reason why I am unable to subscribe to it. Is there anybody having the same RSS issues? Anyone who knows the answer can you kindly respond? Thanx!!

  7. I couldn’t resist commenting. Perfectly written!

  8. I blog often and I genuinely appreciate your content. This great article has truly peaked my interest. I’m going to take a note of your website and keep checking for new information about once per week. I opted in for your RSS feed too.

  9. Very nice article. I absolutely appreciate this website. Stick with it!

  10. I really like it when people come together and share ideas. Great website, keep it up.

  11. Can I simply just say what a comfort to discover an individual who really understands what they’re talking about on the web. You certainly realize how to bring an issue to light and make it important. More people need to look at this and understand this side of the story. I can’t believe you are not more popular because you certainly have the gift.

  12. I used to be able to find good information from your content.

  13. I love it when individuals get together and share ideas. Great website, continue the good work.

  14. An intriguing discussion is worth comment. I believe that you need to write more about this issue, it might not be a taboo matter but generally people do not talk about these topics. To the next! Cheers!

  15. Aw, this was a really nice post. Taking the time and actual effort to produce a superb article… but what can I say… I procrastinate a whole lot and don’t seem to get anything done.

  16. Right here is the right webpage for everyone who hopes to understand this topic. You know so much its almost tough to argue with you (not that I actually will need to…HaHa). You certainly put a fresh spin on a subject that’s been written about for decades. Wonderful stuff, just excellent.

  17. You’re so interesting! I don’t think I’ve read through something like this before. So wonderful to find another person with unique thoughts on this topic. Really.. thanks for starting this up. This web site is something that’s needed on the web, someone with some originality.

  18. Prezzo Viagra 50 Mg Cialis Selbsthilfegruppe Levitra brand cialis online Acheter Cialis Quebec

  19. Hi there, I do believe your blog could possibly be having internet browser compatibility problems. When I take a look at your blog in Safari, it looks fine however, if opening in Internet Explorer, it has some overlapping issues. I simply wanted to provide you with a quick heads up! Apart from that, excellent blog!

  20. Pretty! This was an incredibly wonderful post. Thanks for supplying these details.

  21. I needed to thank you for this excellent read!! I certainly enjoyed every little bit of it. I have got you book marked to check out new stuff you post…

  22. I blog quite often and I genuinely thank you for your content. Your article has truly peaked my interest. I will bookmark your site and keep checking for new information about once a week. I subscribed to your Feed as well.

  23. Hello there, I do think your web site could be having internet browser compatibility issues. When I take a look at your site in Safari, it looks fine however, if opening in IE, it’s got some overlapping issues. I simply wanted to give you a quick heads up! Other than that, fantastic site.

Leave a Reply

(required)

(required)

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

© 2017 Toby's Epril Suffusion theme by Sayontan Sinha