결합도와 응집도

소프트웨어 비용의 정체가 뭔지 하나만 꼽으라면, 결합도야. 한 곳을 바꿀 때 다른 곳도 바꿔야 하는 정도. 이게 높으면 변경 비용이 높아지지.

**결합도(Coupling)**는 여러 형태로 나타나. 한 함수가 다른 함수의 내부 구현에 의존하거나, 여러 모듈이 같은 전역 데이터를 참조하거나, 변경이 연쇄적으로 퍼져나가는 구조. 결합도 자체가 나쁜 건 아니야. 소프트웨어는 어쩔 수 없이 결합이 있거든. 문제는 불필요한 결합이야. 함께 바뀔 이유가 없는 것들이 결합되어 있으면, 그게 변경 비용을 높이는 주범이지. 코드 정리의 상당수는 결국 불필요한 결합도를 줄이는 일이야.

래리 콘스탄틴(Larry Constantine)이 발견한 등가성이 있어. 소프트웨어 비용 ≈ 변경 비용 ≈ 큰 변경의 비용 ≈ 결합도. 풀어서 말하면 이래. 소프트웨어의 전체 비용에서 가장 큰 부분은 유지보수, 즉 변경 비용이야. 변경 비용에서 가장 큰 부분은 크고 어려운 변경이고. 크고 어려운 변경의 원인은 높은 결합도지. 그러니까 소프트웨어 비용을 줄이려면 결합도를 줄여야 해. 이게 코드 정리의 경제적 근거야. 보호 구문, 도우미 추출, 명시적 매개변수 — Part 1의 모든 기법이 결국 결합도를 낮추거나, 그걸 위한 준비 작업이었거든. 콘스탄틴의 등가성은 1960년대에 발견됐는데, 여전히 소프트웨어 설계의 가장 중요한 통찰 중 하나야.

결합도를 줄이는 방법은 크게 두 가지야. 첫째, 결합된 요소를 함께 둬. 어차피 함께 바뀌어야 한다면 같은 곳에 모으는 거지. 응집도를 높이는 배치가 이 방법이야. 결합 자체를 없앤 건 아니지만, 함께 있으니 변경이 쉬워져. 둘째, 요소 사이에 인터페이스를 둬. 안정된 경계를 만들어서, 한쪽이 바뀌어도 다른 쪽에 영향이 퍼지지 않게 하는 거야. 어떤 방법을 쓸지는 상황에 따라 다른데, 같은 팀이나 서비스 안에 있으면 함께 모으는 게 낫고, 다른 팀이나 서비스에 걸쳐 있으면 인터페이스로 분리하는 게 낫지. 결합도를 제거하는 데도 비용이 들어. 무조건 줄이라는 게 아니라, 이득이 클 때 줄여야 해.

결합도의 쌍둥이 개념이 **응집도(Cohesion)**야. 함께 바뀌어야 하는 코드가 실제로 함께 있는 정도를 말하지. 결합도가 "떨어져 있는데 함께 바뀌어야 하는 것"의 문제라면, 응집도는 "함께 있는 것이 실제로 함께 바뀌는가"의 문제야. 응집도가 낮으면 하나의 기능을 수정하는데 여러 파일을 돌아다녀야 하고, 수정해야 할 곳을 빠뜨리기 쉽지. 응집도가 높으면 관련된 코드가 한곳에 모여 있어서 변경이 국지적이야. 한 파일, 한 함수만 고치면 돼. 결합도를 낮추고 응집도를 높여라 — 이건 소프트웨어 설계의 가장 오래되고 가장 유효한 원칙이야.

그래서 이 책 전체를 한마디로 요약하면? "코드 정리를 먼저 하라. 단, 작게." Part 1에서 15가지 정리 기법을 배웠고, Part 2에서 정리의 관리 방법을 배웠고, Part 3에서 왜 정리하는지를 배웠지. 소프트웨어 비용은 결합도에 비례하고, 코드 정리는 결합도를 낮추고 응집도를 높이는 일이야. 경제적으로도 합리적인 투자고. 켄트 벡은 이 책이 시리즈의 첫 번째라고 말해. "Tidy First?"는 가장 작고 안전한 단계 — 개인이 자기 코드를 정리하는 것 — 에 집중했거든. 소프트웨어 설계는 인간적인 활동이야. 코드를 정리하는 건, 다음에 이 코드를 읽을 사람(미래의 나 포함)에 대한 배려지. 거기서 시작하면 돼.

---

정리

5장 읽고 기억할 거 세 가지:

1. 소프트웨어 비용 ≈ 결합도야. 콘스탄틴의 등가성이 말해주지. 결합도를 줄이면 변경 비용이 줄어
2. 결합도를 줄이는 방법은 함께 모으거나, 인터페이스로 분리하거나 두 가지야. 응집도를 높이는 건 결합도를 낮추는 것과 동전의 양면이고
3. "코드 정리를 먼저 하라. 단, 작게." 이게 이 책의 전부야. 작은 것부터 시작해서, 다음에 이 코드를 읽을 사람을 배려하는 거지