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

며칠전 SoC(Seperation of Concerns)가 가져오는 복잡성을 극복하는 법이라는 글을 읽었다. 이 글을 쓴 사람이 SoC의 개념에 대해서 제대로 이해하고 있는지는 일단 제껴두고(이부분에 대해서는 어제 이 글을 읽고 해도 너무 한다며 흥분했던 영회가 비평 해주기로 했다), 내가 궁금한 것은 과연 어떤 것을 근거로 해서 "복잡함"을 생각했는가이다.

요즘은 여기 저기서 "xx기술은 복잡해", "xx는 복잡해져가"라는 이야기를 많이 듣는다. 이전에 한번 이야기 한 것처럼 자신이 기존에 알고 있는 지식이 아니거나 익숙한 것이 아니면 일단 복잡하다고 생각하는 사람들이 있다. 전에 케누형의 코멘트에 답을 단 것처럼 버튼이 백개가 넘는 만능리모콘에 익숙한 사람이 스크롤휠과 버튼 하나 달랑 달린 ipod을 보고는 "이거 왜 이리 복잡해"라고 말하는 것과 비슷할지도 모르겠다. 자신의 무지나 학습에 대한 부담을 복잡하다는 핑계로 회피하려는 치사한 태도에 대해서는 더 언급할 가치도 없다.

내가 궁금한 것은 정말로 SoC가 가져오는 분리라는 작업이 복잡함을 증가시키냐는 것이다. 소프트웨어개발에서 SoC는 일반적으로 관심사가 얽힌 코드나 모듈을 독립적으로 분해하고 분리하는 방법으로 처리한다. 메소드를 따로 뽑아내기도 하고, 책임이 다른 코드를 별도의 클래스로 구분하기도 한다. 여러 모듈에 걸쳐서 나타나는 공통의 관심은 추상화를 통해 분리하기도 한다. 결과적으로 코드의 양이 일시적이지만 늘어나고, 관리해야 하는 파일이나 모듈의 수가 증가하기도 한다. 아마도 그렇게 늘어난 작업대상의 갯수에 대해서 "복잡하다"는 평가를 내리는 것이 아닌가 싶다.

위 글을 읽어보면…

Seperation of Concerns (걱정거리들의 분리)   줄여서, SoC 라는 용어를 들어 보셨나요?  … 각 모듈마다 특정 문제에만 집중해서, 해결할 수 있게 나누어서 생각하자는 것입니다

…

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

…

모든 Parameter를 통합해 놓은 DTO 객체, Business Logic, Data Access Logic, 그리고 어떤 상황에 따라서는 분산객체나 Networked 기반의 접근 모듈로 구성되기도 합니다.

즉 하나의 시나리오를 구하기 위해 이 모든 객체를 다 생성하고 구현하는 노가다를 할 경우가 종종 있습니다

SoC는 결국 고통을 가져다 주며, 노가다를 만드는 원흉이 되어버렸다. 이러다가는 아들이 커서 "아빠는 개발자라면서 노가다SoC해?" 이런 말을 들을지도 모르겠다. 아무튼 이 글에서도 작업의 양이 늘어나는 것은 복잡하다는 식으로 설명되어있다. 마치 TDD하면 개발시간이 훨씬 증가한다는 주장처럼 SoC가 전체적으로 작업의 양을 증가시킨다는 주장에 대해서도 동의할 수 없지만, 단지 작업의 양이 늘어난다고 복잡하다고 평가하는 것에 대해서는 더욱 반대한다.

그 이유는 복잡하다는 것은 단지 할 일의 양이 많아졌다는 뜻이 아니기 때문이다.

사전에서 복잡하다는 말의 정의를 찾아보면 이렇다.

복잡하다 
-  일이나 감정 따위가 갈피를 잡기 어려울 만큼 여러 가지가 얽혀 있다.

Complexity

- Complexity is the state of having many different parts connected or related to each other in a complicated way.

단지 양이 많다는 것을 가지고 복잡하다고 설명하지 않는다. 정의대로라면 복잡하다는 것은 "이해하기 힘든(complicated), 갈피를 잡기 힘든” 것인데 그 이유는 "여러가지가 얽혀있기, connected or related to each other in a complicated way ” 때문이다.

결국 복잡하다는 것은 SoC의 정반대의 개념이라고 불 수 있다. 여러 관심사가 섞이고 얽혀 있어서 이해하고 파악하고 다루기 힘든 상황이 바로 "복잡하다"는 것이다. 그 섞이고 얽혀있는 정도에 따라 복잡도가 증가되는 것이다. 비즈니스로직이, 데이터로직이, 분산처리를 위한 기능과 전송할정보(DTO) 등과 한 곳에 혼재되어 얽혀있고 시간이 갈 수록 이해하기 힘들어지는 것이 복잡한 것이지, 그것이 분리되어서 개별적으로 이해하기 쉽고 손쉽게 다룰 수 있고 필요한 부분만 연결되고 그 외에는 깔끔하게 분리되어있는 것이 복잡한게 아니다.

결국 SoC가 복잡성을 증가시킨다는 주장은 "복잡"하다는 개념을 잘못 이해하는데서 나온 것이라고 생각된다.

물론 초기에 나타나는 단순하고 반복적인 작업에 대한 부담에 대해서 부담을 가지는 것은 이해한다. 그것은 목적과 수준에 맞는 적절한 아키텍처로 변경하거나, 기술적인 발전을 통해서 노가다성 작업을 제거하는 것으로 충분히 대응할 수 있다. 또는 위 글에서 말한 초기 템플릿 코드를 생성하는 툴의 지원도 조금은 도움이 될 수 있다. 근본적으로 노가다라고 느끼는 반복되는 작업은 기술의 발전을 통해서 해결하는 것이 더 낫다.  잘 설계된 프레임워크는 지저분한 작업을 프레임워크로 제거하고, 깔끔하고 꼭 필요한 작업만으로 개발이 가능하도록 지원해주기도 한다. 흠.. 그런데 프레임워크가 새롭게 등장하면 자신이 모르는, 학습할게 또 생겼으니 "복잡해"라고 비명을 지를지도 모르겠다.