결합의 정의와 종류
결합이 무엇이냐고 묻는다면, 가장 간단하게는 영향력이라고 볼 수 있습니다.
Coupling은 단순히 두 요소가 연결되어 있다는 뜻이 아닙니다.
한 요소가 다른 요소에 영향을 주고받는 현상까지 포함합니다.
그래서 결합도는 어떤 구조로 연결되어 있고, 그 영향의 강도가 어느 정도인지를 함께 봐야 합니다.
한 요소가 수정되거나 실행될 때 다른 요소에 영향을 준다면 두 요소 사이에는 결합이 있습니다. 반대로 의존 관계가 존재하더라도 실질적인 영향이 없다면 결합이라고 보기 어렵습니다.
예를 들어 어떤 코드가 sin 함수에 강하게 의존하고 있다고 해봅시다.
라디안 값을 넣으면 사인 값을 반환하는 함수입니다.
코드 구조상으로는 분명 의존하고 있지만 이 함수의 동작이 사실상 바뀌지 않는다면, 우리 코드가 그 변화 때문에 영향을 받을 가능성도 거의 없습니다.
즉, Dependency가 있다고 해서 반드시 강한 Coupling이 생기는 것은 아닙니다.
의존 대상이 영구적인 const처럼 거의 변하지 않는다면 영향력도 거의 없습니다.
반대로 전쟁이 나야 바뀔 정도로 드물게 변경되는 값이라면 영향력은 매우 낮다고 볼 수 있습니다.
하지만 개발자가 기분 내킬 때마다 코드를 바꾸는 요소라면 이야기가 달라집니다.
그 요소에 의존하는 코드는 매우 큰 영향을 받게 됩니다.
결합을 이해할 때는 결국 어떤 영향력이 존재하고, 그 영향이 어디까지 퍼지는지를 파악해야 합니다.
소프트웨어에서 한 요소가 다른 요소에 영향을 주는 이유는 많지만, 크게 세 가지 정도로 나눠볼 수 있습니다.
하나는 추종 관계입니다.
단방향 의존성에서 자주 나타납니다.
어떤 핵심 도메인을 기준으로 다른 요소들이 동작하도록 만들어져 있다면, 그 도메인이 바뀌는 순간 관련된 코드가 한꺼번에 변경될 수 있습니다.
예를 들어 회사 이름이나 회사의 코어 시스템은 바뀌지 않을 것이라고 생각하고 여러 시스템이 여기에 의존하도록 만들었다고 해봅시다.
그런데 회사가 M&A를 당하고 네이버에 인수되어 네이버의 코어 시스템으로 전환해야 한다면 어떻게 될까요?
기존 시스템이 그 핵심 요소를 추종하고 있었다면 관련된 코드 역시 대규모로 변경해야 합니다.
이런 관계가 추종에 따른 결합입니다.
두 번째는 달성하려는 목적이 공유되는 경우입니다.
이 경우가 더 까다로운 이유는 코드 자체가 아니라 Context 때문에 발생하는 경우가 많기 때문입니다.
컴파일러에서도 잡히지 않고 런타임 에러가 발생하지 않을 수도 있습니다.
예를 들어 MSA 환경에서 기존에는 어떤 이벤트를 멤버 이벤트라고 정의해서 사용하고 있었다고 해봅시다.
그런데 어느 날 비즈니스 관점이 바뀌면서 같은 이벤트를 멤버 그룹 이벤트로 해석하기로 했습니다.
API는 하나도 바뀌지 않았습니다.
컴파일도 정상적으로 됩니다.
하지만 기존 API를 멤버라는 의미로 사용하던 서비스들은 더 이상 올바르게 동작한다고 볼 수 없습니다.
이제는 멤버 그룹이라는 새로운 Context를 기준으로 처리해야 하기 때문입니다.
이처럼 같은 목적이나 의미를 공유하는 요소들도 서로 영향을 받습니다.
세 번째는 자원 공유입니다.
같은 데이터베이스를 사용하거나 같은 프린터를 사용하는 것처럼 여러 요소가 동일한 자원을 사용하는 경우입니다.
모바일에서는 이런 자원 공유와 경합이 굉장히 자주 발생합니다.
대표적인 자원이 화면입니다.
애플리케이션이 스마트폰 화면을 완전히 지배할 수 있을까요?
그럴 수 없습니다.
아무리 중요한 제어 시스템 애플리케이션이라고 하더라도 전화가 오면 OS가 화면과 제어권을 가져갑니다.
모바일 OS는 더 중요한 상황이 발생했을 때 애플리케이션이 사용하던 자원과 실행 제어권을 회수할 수 있도록 설계되어 있습니다.
Apple의 macOS도 비슷한 형태의 제어가 가능하고, Windows Store 애플리케이션 역시 실행 도중 OS가 애플리케이션의 동작을 중단하거나 자원을 회수할 수 있는 구조를 가지고 있습니다.
Android와 iPhone도 마찬가지입니다.
아무리 애플리케이션 코드를 잘 작성해놨더라도 전화가 오면 필요한 자원을 해제하고 전화 기능이 우선 동작합니다.
결국 자원을 공유하면 서로 영향을 받을 수밖에 없습니다.
왜 영향력을 관리해야 하는가
결합을 관리해야 하는 가장 큰 이유는 영향력을 관리하지 않으면 시스템의 동작을 이해하기 어려워지기 때문입니다.
어떤 객체가 이상한 동작을 했다고 해봅시다.
처음에는 그 객체 자체의 문제처럼 보였는데, 알고 보니 다른 객체의 상태나 요청 때문에 그런 동작을 했을 수도 있습니다.
영향 관계를 알지 못하면 왜 그런 동작이 발생했는지 설명하기 어렵습니다.
소프트웨어의 동작을 이해하는 일은 생각보다 쉽지 않습니다.
하나의 결과가 여러 요소의 상호작용으로 만들어지는 경우가 많기 때문입니다.
기계식 시계를 생각해보면 이해하기 쉽습니다.
대략적으로는 기어비를 이용해서 진동자의 움직임을 초, 분, 시간으로 변환한다고 이해할 수 있습니다.
하지만 실제 기계식 시계 내부에서는 수많은 기어와 부품이 정교한 비율로 연결되어 동작합니다.
시계를 정확하게 수리하려면 단순히 "기어가 돌아간다"는 정도가 아니라 각각의 요소가 어떻게 영향을 주고받는지 이해해야 합니다.
소프트웨어도 같습니다.
영향력을 관리하지 못하면 동작을 제대로 이해할 수 없고, 동작을 이해하지 못하면 시스템을 안전하게 활용하거나 수정하기도 어렵습니다.
특히 유지보수에서 문제가 커집니다.
어떤 코드를 수정했을 때 그 여파가 어디까지 퍼질지 예측할 수 없다면 쉽게 코드를 고칠 수 없습니다.
수정 직후에는 정상적으로 동작하고 QA도 통과했는데, 실제 트래픽이 100명 이상 들어오는 순간 DB 연결이 끊어질 수도 있습니다.
이런 문제는 일반적인 QA 과정에서 바로 드러나지 않을 수도 있습니다.
문제는 확신입니다.
내가 코드를 수정했을 때 아무리 트래픽이 늘어나더라도 이 수정 때문에 서버가 다운되지는 않는다고 확신하려면, 수정한 코드의 영향력이 어디까지 전달되는지를 판단할 수 있어야 합니다.
이를 가능하게 하는 것이 소프트웨어 구조입니다.
서버가 다운되더라도 최소한 "이 수정 때문에 발생한 문제는 아니다"라고 판단할 수 있을 정도로 영향 범위를 통제할 수 있어야 합니다.
결합을 관리하지 못하면 결국 부분적인 개선도 어렵고 코드 재활용도 어려워집니다.
이것이 우리가 결합도, 즉 소프트웨어의 영향력을 관리하는 이유입니다.
Lifecycle 결합
소프트웨어에서 대표적으로 살펴볼 결합 중 하나가 Lifecycle입니다.
Lifecycle은 결국 변화율과 관련이 있습니다.
코드의 생명주기는 코드가 만들어지고, 수정되고, 기능이 추가되고, 일부가 제거되다가 결국 버려지는 과정입니다.
산업용 소프트웨어가 존재하는 이유는 대부분 도메인에 있습니다.
그리고 도메인은 기술적인 논리와 상관없이 여러 비즈니스 사정 때문에 계속 변합니다.
도메인은 개발자가 통제할 수 있는 대상이 아닙니다.
우리가 확실하게 알 수 있는 것은 하나입니다.
도메인은 계속 변합니다.
산업용 코드가 존재하는 이유 자체가 도메인을 지원하기 위한 것이므로, 도메인이 변한다는 사실은 코드 역시 계속 변한다는 뜻입니다.
취미로 작성하는 코드는 그렇지 않을 수도 있지만 산업용 소프트웨어에서는 대부분 피할 수 없는 문제입니다.
도메인의 일부가 변경되면 그 도메인을 지원하는 코드도 함께 수정됩니다.
이 과정이 해당 코드의 Lifecycle을 만들어냅니다.
문제는 서로 다른 도메인의 코드가 하나의 Lifecycle에 묶일 때 발생합니다.
이것을 공유된 수명주기라고 부릅니다.
예를 들어 A라는 도메인을 지원하는 코드와 B라는 도메인을 지원하는 코드가 하나의 파일에 같이 들어 있다고 해봅시다.
A와 B는 서로 다른 도메인이므로 변경 시점도 다를 수 있습니다.
하지만 코드가 하나로 묶여 있기 때문에 실제 코드의 Lifecycle은 공유됩니다.
그러면 A 도메인 때문에 코드를 수정할 때마다 B 도메인에 문제가 생기지 않을지 걱정해야 합니다.
반대도 마찬가지입니다.
B 도메인만 변경되었는데 A 도메인까지 망가질까 봐 조심하면서 코드를 수정해야 합니다.
도메인의 Lifecycle은 분리되어 있는데 코드의 Lifecycle을 하나로 묶어버렸기 때문입니다.
이것이 Lifecycle 결합입니다.
Implementation Knowledge
두 번째로 살펴볼 결합은 구체 지식, 또는 구현 지식입니다.
번역서에 따라 Implementation을 구현이라고 번역하기도 하고 구체라고 표현하기도 합니다. abstraction의 반대 개념으로 concrete가 사용되기도 하고, 같은 맥락에서 implementation이 사용되기도 합니다.
핵심은 내부 구현에 대한 구체적인 지식이 외부로 노출되는가입니다.
좋은 구조라면 외부에서는 내부 구현을 알 필요 없이 정해진 Protocol에 맞춰 요청하고 결과만 받으면 됩니다.
일종의 Sandbox처럼 동작해야 합니다.
하지만 외부 개발자가 API를 보고
"이 라이브러리와 저 라이브러리를 이런 식으로 조합해서 만들었구나."
라고 내부 구조를 추측할 수 있다면 구현 지식이 노출된 것입니다.
이런 상태를 Implementation Knowledge가 노출되었다고 표현합니다.
인터페이스를 사용한다고 해서 자동으로 해결되는 문제도 아닙니다.
인터페이스에는 구현 코드가 없으니 안전해 보일 수 있습니다. 하지만 메서드의 인자나 반환값만 보고도 내부 구현을 예상할 수 있다면 여전히 Implementation Knowledge가 노출된 상태입니다.
여기서 중요한 개념이 Encapsulation, 즉 캡슐화입니다.
Data Hiding과 Encapsulation은 비슷해 보이지만 완전히 같은 개념은 아닙니다.
Data Hiding은 내부 데이터를 외부에 직접 보여주지 않는 것에 가깝습니다.
반면 캡슐화의 핵심은 외부에서 내부 구조를 예상할 수 없도록 추상화하는 것입니다.
단순히 추상화를 했다고 끝나는 것이 아닙니다.
내부 구현을 추측할 수 없도록 만들어야 제대로 캡슐화했다고 볼 수 있습니다.
예를 들어 번역 API가 있다고 해봅시다.
출발 언어, 도착 언어, 번역할 본문을 전달하면 번역 결과를 반환합니다.
겉으로 보면 특별히 내부 구현을 노출하지 않습니다.
그런데 출발 언어나 도착 언어에 자동이라는 옵션을 제공한다고 생각해봅시다.
사용자가 어떤 텍스트를 넣고 출발 언어를 자동, 도착 언어를 한국어로 설정해서 번역을 요청할 수 있습니다.
그 순간 이 API는 번역 외의 용도로도 사용할 수 있게 됩니다.
사용자가 가진 텍스트가 러시아어인지 아랍어인지 구분하기 어려울 때 번역 API의 자동 감지 기능을 이용해서 언어를 판별할 수 있기 때문입니다.
이 인터페이스는 사실상 한 가지 내부 정보를 노출한 셈입니다.
"이 번역 시스템 내부에는 언어 판별기가 존재한다."
라는 지식입니다.
캡슐화가 깨진 것입니다.
캡슐화가 깨지는 순간 API는 원래 의도하지 않았던 방식으로 사용될 수 있습니다.
개발자들이 번역 API를 번역 용도로만 사용하지 않고 언어 판별기로 쓰기 시작하는 식입니다.
문제는 그다음입니다.
번역 API의 내부 구현을 변경했더니 갑자기 여러 개발자에게 연락이 옵니다.
"API 바꾸고 나서 언어 인식이 안 되는데요?"
API 개발자 입장에서는 황당합니다.
언어 인식 API를 제공한 적이 없기 때문입니다.
그런데 알고 보니 여러 서비스가 번역 API를 언어 판별기로 사용하고 있었습니다.
추상화는 되어 있었지만 인터페이스가 내부 구현을 암시했고, 그 결과 캡슐화가 깨졌기 때문입니다.
이렇게 예상하지 못한 우회적인 의존성이 생기면 영향 범위를 관리하기 어려워집니다.
Implementation Knowledge가 노출되는 방식은 매우 다양합니다.
단순히 인터페이스를 만들었다고 끝나는 문제가 아닙니다. 캡슐화를 제대로 하지 않으면 내부 구현에 대한 정보가 얼마든지 외부로 새어 나갈 수 있습니다.
상호작용성과 정보 누출의 균형
캡슐화를 강하게 할수록 항상 좋은 것도 아닙니다.
상호작용성과 정보 누출 사이에는 균형이 필요합니다.
앞에서 본 번역 API를 다시 생각해봅시다.
출발 언어를 사용자가 반드시 지정하게 하는 것보다 자동 감지 기능을 제공하면 사용하기는 훨씬 편합니다.
상호작용성이 좋아진 것입니다.
하지만 동시에 내부에 언어 판별 기능이 존재한다는 정보가 외부로 노출됩니다.
편의성을 높이면 Implementation Knowledge가 더 많이 노출될 가능성이 있습니다.
결국 둘 사이의 균형을 맞춰야 합니다.
정답이 하나로 정해져 있는 문제는 아닙니다.
생명주기와 구체 지식이 만드는 여파
결합의 종류로 Lifecycle 결합과 Implementation Knowledge 결합을 살펴봤다면, 각각이 어떤 문제를 만드는지도 봐야 합니다.
구조만 파악해서는 부족합니다.
그 결합이 실제로 어떤 여파를 만드는지까지 이해해야 합니다.
Lifecycle 결합은 주로 도메인 변화에 기민하게 대응하기 어렵게 만듭니다.
A 도메인을 수정해야 하는데 같은 Lifecycle에 묶여 있는 B 도메인이 깨질 것 같다면 쉽게 수정하지 못합니다.
코드를 변경하는 것이 두려워집니다.
그 결과 서비스 전체의 변화 속도가 느려집니다.
반면 Implementation Knowledge 결합은 개선과 오류 수정을 어렵게 만듭니다.
내부 구현을 변경했을 때 어떤 시스템까지 영향을 받을지 알기 어렵기 때문입니다.
외부 시스템들이 우리가 노출한 구체 지식에 의존하면서 예상하지 못한 간접 의존성을 만들었을 수 있습니다.
이런 상태에서는 기능 개선도 어렵고 버그 수정도 쉽게 하지 못합니다.
결합도는 0이 될 수 없다
그렇다고 결합도를 무조건 0으로 만드는 것이 목표는 아닙니다.
결합도가 0이라면 요소 간 상호작용 자체가 불가능합니다.
중요한 것은 결합을 없애는 것이 아니라 통제 가능한 수준으로 관리하는 것입니다.
Lifecycle도 어느 정도는 공유될 수밖에 없습니다.
Implementation Knowledge도 현실적으로 일부 노출될 수밖에 없습니다.
문제는 얼마나 허용할 것인지입니다.
예를 들어 코드를 지나치게 잘게 쪼개면 각 요소의 Lifecycle을 독립적으로 관리할 수 있습니다.
변경 가능성은 높아집니다.
하지만 구조가 지나치게 복잡해지고 사용하기 어려워질 수 있습니다.
그렇다면 어느 정도 Lifecycle이 비슷한 요소는 하나로 묶는 편이 낫습니다.
그만큼 기민성은 조금 떨어지겠지만 전체 구조는 단순해집니다.
Implementation Knowledge도 마찬가지입니다.
내부 구현을 전혀 노출하지 않으려고 지나치게 강하게 캡슐화하면 사용자가 간단한 작업을 위해 API를 20개씩 호출해야 하는 상황이 생길 수도 있습니다.
그렇다면 어느 정도의 Implementation Knowledge는 노출하는 편이 더 현실적일 수 있습니다.
물론 그만큼 간접 의존성이 생길 가능성도 커집니다.
핵심은 이런 선택을 했을 때 어떤 여파가 생기는지 알고 결정하는 것입니다.
설계는 트레이드오프다
그래서 소프트웨어 설계에서 자주 하는 말이 있습니다.
설계는 트레이드오프다.
무엇과 무엇의 트레이드오프일까요?
수정 가능성과 편의성 사이의 트레이드오프입니다.
설계를 구체적인 행위로 보면 결국 코드의 재배치라고 볼 수 있습니다.
설계라는 말을 지나치게 어렵게 생각할 필요는 없습니다.
실제로 개발자가 할 수 있는 일은 이미 존재하는 코드를 적절한 위치로 옮기는 것입니다.
코드를 함수에 담아서 다른 패키지로 옮길 수도 있고, 클래스로 만들어 다른 모듈로 보낼 수도 있습니다.
실제로 실행되는 코드 자체가 사라지는 것은 아닙니다.
위치와 경계를 다시 정하는 것입니다.
왜 코드를 재배치할까요?
Lifecycle과 Implementation Knowledge의 노출 범위를 고려해서 서로 격리해야 할 코드를 적절한 위치에 배치하기 위해서입니다.
이것이 설계에서 우리가 실제로 하는 일의 핵심입니다.
하지만 격리만 생각해서 코드를 지나치게 분리하면 수정 가능성은 높아질 수 있어도 사용성이 나빠지고 구조적인 복잡성이 커집니다.
반대로 관련 없는 코드를 전부 한곳에 몰아넣으면 당장은 편해 보이지만 나중에는 수정하기 어려워지고 역시 복잡성이 증가합니다.
결국 양쪽 모두 복잡성이 커질 수 있습니다.
그래서 두 극단 사이에서 복잡성이 가장 낮아지는 지점을 찾아 적당히 코드를 분산하고 격리해야 합니다.
이런 이야기를 하면 결국 경험 많은 개발자가 설계를 잘하는 것처럼 보일 수 있습니다.
하지만 경력이 많다고 해서 항상 설계를 잘하는 것은 아닙니다.
중요한 것은 자신이 어떤 트레이드오프를 선택하고 있는지 명확한 언어로 설명할 수 있는가입니다.
Lifecycle을 묶으면 이 영역에서는 도메인 변화에 빠르게 대응하기 어려워질 수 있습니다.
그럼에도 이 정도의 기민성은 포기하고 비슷한 Lifecycle을 가진 코드를 묶는 것이 더 낫다고 판단할 수 있습니다.
반대로 Implementation Knowledge를 너무 감추고 캡슐화를 지나치게 강하게 적용하면 API를 사용하는 쪽이 너무 불편해질 수도 있습니다.
그렇다면 내부 구현이 어느 정도 노출되고 그로 인해 영향 범위가 커질 가능성을 감수하더라도 이 정도까지는 공개하겠다고 결정할 수 있습니다.
이렇게 어떤 결합을 만들고 있는지, 그 결합이 어떤 영향을 만드는지, 무엇을 얻고 무엇을 포기하는지를 이해한 상태에서 코드를 배치하는 것이 설계입니다.
설계 감각을 반드시 긴 경력으로만 획득해야 하는 것은 아닙니다.
Lifecycle, Implementation Knowledge, Encapsulation, 영향력, 수정 가능성, 편의성 같은 개념을 명확한 언어로 이해하면 설계 판단을 더 의식적으로 통제할 수 있습니다.
