The Art of Software Development

며칠전 Separation of Concerns (SoC)가 복잡도를 증가시킨다는 좀 황당한 블로그 포스트를 읽고 몇자 적어본다.
"아키텍트로 가는 길"이라며 "Load to Architect" 라고해서 아키텍트의 짐 (Load)인지 아니면 길 (Road)를 짐 (Load)로 오기한건지는 모르겠어서 Load 에 "길"이라는 뜻도 있는지 사전까지 찾아보게 만든. 이상하다고 여기면서도 다른 뜻이 있겠지라고 생각했던 블로그인데 저런 내용을 보고나니 다른 뜻이 있어 그렇게 표기했는지가 의심이 된다.

그 글을 보자마자 댓글이라도 달아서 무슨 뜻으로 복잡도를 증가시킨다는 생각을 하는지 물어보고 싶었지만 그러려니 하고 있었는데 RSS로 블로그를 구독하는 영회님과 토비님이 한마디 하신 것 같다. 그런데 아쉽게도 영회님의 포스트는 무슨 이유에서인지 삭제가 된듯 하다. 일단 토비님이 지적하신 것에 대해서는 본인이 표현상의 문제가 있었다는 해명을 했지만 여전히 다른 복잡성(Complexity)을 발생시킨다는 부분에 대해서도 이해하기 힘들다.

언급된 포스트에서

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

라고 말하고 있다. 만약 위와 같은 현상이 발생한다면 SoC 때문에 고통이 발생한 것이 아니라 SoC를 잘 구현하지 못했기 때문에 고통이 왔다고 보여진다. 객체 하나의 수정이 여러개의 다른 객체 수정으로 이어진다면 문제를 분리했다기 보다는 오히려 객체들의 종속성 (Dependency)이 늘어났다는 얘기다. 문제가 분리된것이 아니라 반대로 문제가 더 커진것이다. 논리적 관점에서의 SoC가 아닌 단순한 코드의 분리로 구현했을 경우 이런 현상이 발생할 확률이 높다.

새로운 기능을 추가할 경우는 당연히 디자인에 반영되지 않은 부분이므로 여기 저기 손볼 곳이 많아진다. 하지만 이를 놓고 SoC 때문에 클래스가 잘게 쪼개져서 여러개의 객체를 수정해야 된다고 하는 것은 패턴을 모르는 사람이 패턴으로 구현된 코드를 보고 "클래스가 많아서" 쓸데 없이 복잡하게 코딩한다고 불평하는 것과 다를게 없다.

어떤 다른 뜻이 있었는데 표현을 적절하게 하지 못한 것인지 아니면 정말 SoC 때문에 그러한 고통이 온다고 생각했는지는 모르겠지만 위의 포스트를 읽고 SoC를 단순히 코드의 분리로 이해해서 SoC 때문에 클래스가 조각난다는 생각을 갖는 사람들이 없기를 바란다.