[tl;dr] 소프트웨어 설계에서 결합의 균형 잡기

같은 저자의 Domain-Driven Design 책을 읽고, 모듈식 설계를 다루는 데 적용한 역사적 관점이 흥미로워 이 주제에 관심이 생겼다. 이번 신간은 그 논의를 확장할 것처럼 들렸고, 기대를 저버리지 않았다. Parnas, Myers, Brooks, Conway, Ousterhout의 아이디어를 토대로 새롭고 유용한 내용을 촘촘히 연구해 담아냈다. Vlad Khononov는 내가 소프트웨어 설계 논의에서 근본적이라고 보는 것—즉, 감에 의존하지 않고 의사결정을 내릴 수 있도록 원칙에 기반한 정의를 제공하는 일—을 해낸다. 다만 통찰은 깊지만 꽤 전문적인 책이기도 하다. 나는 소프트웨어 설계 덕후들에게는 추천하지만 모든 프로그래머에게까지 권하진 않는다(예컨대 _A Philosophy of Software Design_은 널리 추천한다). 다만 앞으로 이 책의 휴리스틱을 자주 써서 성과를 거둔다면 이 평가는 바뀔 수 있다.

이 책의 논지: 평판과 달리 결합은 근본적으로 제거해야 할 나쁜 것이 아니라 전략적으로 관리해야 할 속성이다. 본질적 복잡성과 마찬가지로, 유용한 소프트웨어 시스템은 구성 요소들 간의 어떤 형태의 결합 없이는 존재할 수 없다. 이 생각을 내면화하는 쉬운 방법은, 때때로 응집(cohesion)을 ‘좋은 결합’으로 정의한다는 사실을 떠올리는 것이다.

소프트웨어는 프랙탈적이다. 시스템, 서비스, 네임스페이스, 클래스, 함수 수준에서 모듈성을 논할 수 있다. 각 수준마다 인터페이스와 구현, 모듈의 깊이와 복잡도가 있다. 복잡성은 이원적이다: 로컬과 글로벌. 그리고 소프트웨어가 프랙탈이기 때문에, 한 수준의 글로벌 복잡성은 더 높은 수준에서 로컬 복잡성으로 바뀐다. 단순히 모듈을 더 작은 단위로 쪼개는 일은 로컬 복잡성을 위로 밀어 올려 전체 시스템을 더 복잡하게 만들 뿐이다. 우리의 일은 로컬 최소값을 쫓는 것이 아니라 균형을 찾는 것—총 유지보수 비용을 줄이는 충분히 괜찮은 절충안을 찾는 것이다.

책의 3분의 2는 정의에 할애한다. 익숙한 개념들(복잡성, 모듈성, 결합), 역사적으로 중요한 개념들(구조적 설계의 모듈 결합, 코나선스(connasence)), 그리고 저자가 새로 소개하는 몇 가지 개념(통합 강도, 거리, 변동성)이 있다. 이들을 조합해 시스템 내 구성 요소의 모듈성과 ‘균형’을 평가하고, 문제를 감지하고, 가능한 해법을 암시하는 휴리스틱(수식으로 표현됨)을 만든다. 저자는 이 활동을 결합을 균형화(그리고 재균형화)한다고 부른다. 마지막 장들은 일련의 사례 연구에 이 휴리스틱을 구체적으로 적용해 보인다.

크게 요약하면 이렇다. 모듈이 강하게 통합되어 있다(서로 많은 지식을 공유한다)면 거리를 줄이고, 약하게 통합되어 있다(서로 공유하는 지식이 적다)면 거리를 늘려라. 이는 더 작고 더 널리 흩어진 컴포넌트가 반드시 더 단순한 시스템을 만든다는 생각(마이크로서비스 지옥과 left-pad로 이어지는 생각)과 다르다.

하지만 균형 맞추기는 단순히 “이것저것 옮겨 담는” 데 그치지 않는다. 소프트웨어 시스템이 프랙탈 네트워크라는 점을 감안하면, 구조적 한계—그리고 이를 유지보수하는 이들이 감당할 수 있는 인지 부하—를 넘어 성장하도록 새로운 추상화 수준을 도입할 수 있다. 이 책 이론의 강점 중 하나는 동일한 원칙이 시스템의 모든 수준에 적용된다는 점이다. 소프트웨어 설계와 아키텍처 사이에—심지어 소프트웨어 시스템과 그들이 통합되는 인간 시스템 사이에도—딱 잘라 구분되는 경계가 없다. 단지 규모와 의미 수준, 관점만 다를 뿐이다.

요약

• 시스템은 구성 요소와 목적을 가진다. 구성 요소 간의 상호작용(결합)은 시스템의 목적을 이루기 위해 필수적이다. 더 작은 스케일에서, 구성 요소는 거의 언제나 그 자체로 하위 시스템이다.

• 결합은 구성 요소가 지식이나 생명주기(라이프사이클), 혹은 둘 다를 공유해야 하는 데서 비롯된다.

  • 결합은 구성 요소 간에 어떤 지식이 흐를 수 있는지를 정의할 뿐 아니라, 어떤 지식은 경계를 절대 떠나면 안 되는지도 정의한다. 이 때문에 결합은 모듈식 소프트웨어 시스템을 설계하는 핵심 도구가 된다.
  • 결합의 크기가 클수록, 결합된 구성 요소들이 함께 변경되어야 할 가능성이 커진다.

• 복잡성은 사람이 시스템과 상호작용할 때 경험하는 인지 부하를 반영한다. 인지 부하가 클수록 시스템의 동작을 이해·통제·예측·변경하기가 더 어려워진다.

  • 로컬 복잡성은 단일 구성 요소의 복잡성—그 안에서 일어나는 상호작용의 복잡성이다.
  • 글로벌 복잡성은 시스템의 구성 요소들 사이에서 벌어지는 상호작용의 복잡성이다.
  • 이 구분은 관점에 따라 주관적이다. 더 높은 추상화 수준에서 시스템을 관찰하면 글로벌 복잡성은 로컬 복잡성으로 바뀐다.

• 모듈은 시스템의 유연성을 높여 미래의 목표를 지원하도록 진화시킬 수 있게 설계된 구성 요소의 한 형태다.

  • 소프트웨어 모듈은 잘 정의된 기능에 경계를 치고, 공용 인터페이스를 통해 다른 구성 요소에 이를 공개한다. 소프트웨어 시스템의 모든 논리적·물리적 경계—서비스, 네임스페이스, 객체, 함수 등—는 모듈로 설계될 수 있다.
  • 효과적인 모듈은 ‘결정’을 숨긴다. 어떤 결정을 다시 검토해야 할 때, 변경의 영향은 그 결정을 “숨기는” 하나의 모듈로 한정되어야 한다.
  • 효과적인 모듈은 자신이 캡슐화하는 지식을 최대화하면서, 다른 구성 요소가 자신과 협력하는 데 필요한 최소한만 공유한다.

• 시스템 설계는 개별 모듈을 고립적으로 평가하는 것이 아니라, 모듈들 간의 관계—어떻게 결합되어 있는가—를 통해 평가해야 한다. 구성 요소를 결합하는 방식에 따라 공유되는 지식의 유형과 양이 달라진다. 어떤 방식은 복잡성을 키우고, 다른 방식은 모듈성에 기여한다.

  • 결합은 세 차원—통합 강도, 거리, 변동성—에 걸쳐 나타난다.
  • 통합 강도가 높을수록(경계 너머로 공유되는 지식이 많을수록) 모듈들이 발맞춰 변경되어야 할 가능성이 커진다. 이런 연쇄적 변경이 필요할 때, 거리는 그것을 구현하는 데 드는 조정 노력의 크기를 뜻한다. 변동성은 이러한 변경이 얼마나 자주 일어날 것으로 예상되는지를 나타낸다.
  • 교차 컴포넌트 상호작용을 설계할 때 우리의 목표는 결합 강도를 최소화하는 것이 아니다. 목표는 구현·진화·유지보수가 쉬운 모듈식 시스템이다. 이를 달성하려면 결합의 세 차원을 모두 고려해야 한다.

• **통합 강도(Integration strength)**는 결합된 구성 요소들이 공유하는 지식의 유형과 범위를 모델링한다. 결합 강도에는 네 가지 수준이 있다.

  • 침투적 결합: 상류(upstream) 컴포넌트의 비공개 인터페이스나 기타 구현 상세를 통해 통합한다. 이 방식은 하류(downstream) 컴포넌트를 상류 컴포넌트의 모든 미래 변경에 민감하게 만든다.
  • 기능적 결합: 컴포넌트들이 긴밀히 연관된 비즈니스 기능을 구현한다. 비즈니스 요구사항의 변경은 결합된 모든 컴포넌트에 영향을 줄 가능성이 높다.
  • 모델 결합: 비즈니스 도메인의 공유 모델을 사용하는 컴포넌트들. 모델의 진화는 결합된 모든 모듈에 변경을 요구한다.
  • 계약 결합: 통합 전용의 공유 모델—즉 계약(contract)—을 사용하는 컴포넌트들. 통합 계약은 상류 컴포넌트 내부에서 사용하는 모델의 세부를 추상화한다.

• **거리(Distance)**는 결합된 구성 요소들 사이로 지식이 “이동”하는 공간을 뜻한다. 이는 결합된 구성 요소에 영향을 미치는 변경을 구현하기 위해 필요한 조정·소통의 노력을 좌우한다. 거리는 여러 요인의 영향을 받는다.

  • 코드의 물리적 위치: 예를 들어, 같은 클래스의 결합된 메서드를 바꾸는 것이 분산 시스템 간의 결합된 메서드를 바꾸는 것보다 쉽다. 반면 서로 관련 없는 기능을 한 데 모아두면 라이프사이클이 결합되어, 분리되어 있었다면 필요하지 않았을 부수적 변경을 초래한다.
  • 조직 구조: _소유권(ownership)_의 거리가 클수록(동일인/동일팀/부서/조직이 관리하느냐에 따라) 조정 비용이 커진다.

• **변동성(Volatility)**은 구성 요소의 예상 변경 빈도다.

  • 변동성을 모델링하는 한 가지 방법은 도메인 주도 설계(DDD)의 서브도메인 유형을 이용하는 것이다. 코어 서브도메인은 서포팅·제너릭 서브도메인보다 더 자주 변할 것으로 예상된다.
  • 자주 변하지 않을 것으로 예상되는 구성 요소에 모듈화를 투자하는 것은 그만큼 이득이 크지 않다.

• **균형(Balance)**은 결합의 세 차원이 최적 상태에 있어, 설계가 시스템의 변동성이 큰 구성 요소들의 모듈성을 높여 주는 상태를 말한다. 이 차원들의 불균형한 조합은 인지 부하 증가로 이어지고, 결과적으로 복잡성을 높인다.

-- 상당한 양의 지식이
-- 먼 거리를 이동할 때 글로벌 복잡성이 생긴다
global_complexity := strength() AND distance()

-- 서로 관련 없는 컴포넌트가
-- 한자리에 함께 있을 때 로컬 복잡성이 생긴다
local_complexity := NOT strength() AND NOT distance()

-- 모듈성은 로컬/글로벌 복잡성의 부재다
complexity := local_complexity OR global_complexity
            = NOT (strength() XOR distance())
modularity := NOT complexity
            = strength() XOR distance()

-- 변동성이 큰 컴포넌트가 모듈식이고
-- 복잡한 컴포넌트가 변하지 않을 때 균형이다
balance := modularity OR NOT volatility()
         = (strength() XOR distance()) OR NOT volatility()