결합도

프로그램이 커지면 어느 순간부터 고치는 일이 무서워집니다. 알림 문구 한 줄을 바꿨는데 결제 화면이 깨지고, 열어 보기 전에는 왜 깨졌는지 아무도 모릅니다. 페이지덱에서도 태오가 문서 저장 쪽 코드를 정리한 날 알림이 통째로 멈춘 적이 있습니다. 두 기능은 화면상으로 아무 관련이 없었고, 알림 코드가 문서 저장이 쓰는 데이터베이스 표를 직접 읽고 있었기 때문이었습니다.

이런 일이 반복되면 팀은 방어적으로 움직입니다. 고칠 수 있는데도 고치지 않고, 새 기능을 기존 코드 옆에 하나 더 붙이는 쪽을 고릅니다. 그러면 얽힘은 더 늘어납니다. 문제를 이야기하고 싶어도 "이 코드는 뭔가 복잡해요" 말고는 할 말이 없어서, 일정 회의에서 일주일을 더 달라고 설득할 근거가 되지 못했습니다.

결합도는 그 "뭔가 복잡해요" 에 눈금을 붙이려고 생긴 말입니다. 코드의 양이나 난이도가 아니라 덩어리 사이의 연결만 따로 떼어 보는 개념이고, 덕분에 설계 이야기가 취향 싸움에서 빠져나옵니다. 어느 쪽 구조가 더 예쁜지를 다투는 대신, 이 기능 하나를 고칠 때 몇 군데를 함께 열어야 하는지를 세면 됩니다.

결합도는 두 덩어리 사이에 오가는 정보가 얼마나 구체적인지로 정해집니다. 상대의 속사정을 많이 알수록 높고, 정해진 창구로 정해진 값만 주고받을수록 낮습니다.

같은 두 기능도 잇는 방식에 따라 결합도가 달라집니다. 느슨한 쪽부터 단단한 쪽으로 늘어놓으면 대략 이렇습니다.

1. 사건만 던지기 — 문서 모듈이 "문서가 저장됐다" 는 사실만 알리고 누가 받아 가는지는 모릅니다. 이벤트 기반 아키텍처가 이 방식입니다. 알림이 멈춰도 저장은 끝납니다.
2. 정해진 창구로 부르기 — 문서 모듈이 열어 둔 API, 곧 프로그램끼리 주고받기로 약속한 창구를 통해서만 부릅니다. 창구 모양이 그대로면 안쪽은 마음대로 바꿀 수 있습니다.
3. 상대 내부 함수 직접 부르기 — 약속되지 않은 안쪽 함수를 부릅니다. 그 함수의 이름이나 인자가 바뀌면 부르는 쪽이 같이 깨집니다.
4. 상대 데이터 직접 읽기 — 알림 코드가 문서 표를 직접 조회합니다. 표에서 열 이름 하나만 바꿔도 알림이 멈추고, 문서 담당자는 알림이 자기 표를 보고 있다는 사실조차 모릅니다.
5. 같은 전역 상태 공유 — 두 덩어리가 같은 변수를 읽고 씁니다. 값이 언제 누구 때문에 바뀌었는지 추적할 길이 사라집니다.

가전제품과 콘센트를 떠올리면 편합니다. 규격이 맞으면 벽 안에 전선이 어떻게 깔려 있는지 몰라도 청소기를 꽂아 쓸 수 있고, 벽 공사를 해도 청소기는 그대로 씁니다. 청소기 선을 벽 안 전선에 직접 납땜해 두면 당장은 잘 돌아가지만, 둘 중 하나만 바꾸려 해도 벽을 뜯어야 합니다.

설계와 일상 작업 양쪽에서 판단 재료로 쓰입니다.

구조를 고를 때가 첫째입니다. 모놀리스처럼 전부를 한 덩어리에 담으면 내부끼리 함수를 바로 부를 수 있어 빠르지만 결합도가 쉽게 올라갑니다. 마이크로서비스로 잘라 따로 배포하면 강제로 낮아지는 대신 배포와 감시가 서비스 수만큼 늘어납니다. 모듈러 모놀리스는 한 덩어리로 올리되 모듈끼리 정해진 창구로만 부르게 막아 중간을 노립니다.

코드 리뷰에서도 자주 나옵니다. 어떤 변경이 파일 열두 개를 건드린다면 대개 그 자리에 얽힘이 있습니다. 리팩터링, 곧 동작은 그대로 두고 구조만 손보는 작업의 우선순위도 이 기준으로 정합니다. 자주 고치는 곳 가운데 결합도가 높은 순서로 풉니다. 미뤄 둔 정리가 쌓여 속도를 깎는 상태를 기술 부채라고 부르는데, 그 이자가 가장 비싸게 붙는 자리가 대개 여기입니다.

테스트가 조용한 신호를 줍니다. 단위 테스트를 쓰려는데 그 함수 하나를 돌리려고 데이터베이스와 결제 대행사까지 띄워야 한다면, 그 함수는 이미 그만큼 많은 것에 얽혀 있는 것입니다. 테스트를 짜기 어렵다는 느낌이 대개 결합도 문제를 가장 먼저 알려 줍니다.

"여기 결합도가 높아서 이 부분만 떼어 고치기는 어려워요."

작업 범위가 예상보다 넓다는 신고이고, 대개 일정을 다시 잡자는 뜻입니다.

"알림에서 문서 테이블을 직접 읽고 있네요. 이벤트로 빼죠."

4번 방식을 1번 방식으로 바꾸자는 구체적인 제안입니다.

"지금 구조로는 결제만 따로 배포할 수 없습니다."

결합도가 배포 단위를 묶어 버렸다는 뜻이고, 이 상태에서는 작은 수정도 전체 배포를 거쳐야 합니다.

페이지덱에서는 이 말이 일정 이야기와 붙어 나옵니다. 지현이 알림 문구를 손보는 데 사흘을 잡아 두면 태오가 실제로는 문서 저장 쪽까지 열어야 한다고 답하고, 그 차이가 어디서 오는지를 설명하는 자리에 결합도가 등장합니다. 숫자로 재는 지표가 아니라 작업 범위를 설명하는 말에 가깝습니다. 사흘과 열흘의 차이가 게으름이 아니라 구조에서 온다는 것을 보이는 자리입니다.

그래서 이 단어는 기능 요청을 거절하는 데 쓰이지 않습니다. "지금 구조로는 이만큼 걸리고, 여기를 한 번 풀어 두면 다음부터는 하루면 됩니다" 처럼 선택지를 만드는 데 씁니다.

낮을수록 무조건 좋다고 읽는 경우가 많습니다. 높으면 문제가 생긴다고 배우니 자연스러운 생각입니다. 하지만 결합도를 끝까지 낮추려면 덩어리 사이마다 중간 계층과 약속을 두어야 하고, 그만큼 코드가 늘고 흐름을 따라가기 어려워집니다. 두 화면짜리 제품에 서비스를 여섯 개로 쪼개 두면 기능 하나를 따라가는 데 파일 스무 개를 열게 됩니다. 목표는 0이 아니라 함께 바뀌는 것끼리 붙여 두고 따로 바뀌는 것끼리 떼어 두는 쪽입니다.

덩어리로 나누기만 하면 결합도가 내려간다고 믿는 것도 흔합니다. 서비스를 다섯 개로 갈랐는데 다섯 모두가 같은 데이터베이스 표를 읽고 쓰면, 표 하나를 바꿀 때 다섯 팀이 동시에 배포해야 합니다. 배포 단위만 늘고 얽힘은 그대로라서 분산된 모놀리스라고 부릅니다. 이 상태는 원래 모놀리스보다 나쁩니다. 함수 하나를 부르던 자리가 네트워크 호출로 바뀌어 장애 지점이 늘었는데 얻은 것은 없기 때문입니다.