응집도

코드를 어느 파일에 둘지 정하는 기준이 사람마다 다르던 시절이 있었습니다. 새 함수를 하나 만들면 마땅한 자리가 안 보여서 utils 라는 이름의 파일에 넣었고, 다음 사람도 같은 이유로 거기에 넣었습니다. 반년이 지나면 그 파일 안에 날짜 표시 함수와 비밀번호 암호화 함수와 엑셀 내보내기 함수가 나란히 앉아 있었습니다.

문제는 고칠 일이 생겼을 때 드러났습니다. "결제 실패했을 때 안내 문구를 바꿔 주세요" 라는 요청 하나에 개발자가 파일 일곱 개를 열어야 했습니다. 결제 금액을 계산하는 코드는 여기, 실패를 판정하는 코드는 저기, 문구는 또 다른 곳에 있었기 때문입니다. 하나를 빠뜨리면 화면마다 다른 문구가 뜨는 버그가 났고, 그 버그는 대체로 고객이 먼저 발견했습니다.

응집도는 이 상황에 이름을 붙여 눈금으로 만든 말입니다. 덩어리를 몇 개로 나눴는지가 아니라 한 덩어리 안에 들어간 것들이 서로 관계가 있는지를 묻습니다. 취향으로 갈리던 "이 코드는 여기 있을 게 아닌데요" 라는 지적이 이 말을 얻고 나서 근거를 댈 수 있는 이야기가 됐습니다.

한 덩어리를 열어 놓고 그 안의 코드들이 같은 이유로 바뀌는지를 봅니다. 결제 규칙이 바뀔 때 이 파일 안의 모든 함수가 함께 손봐야 할 대상이면 응집도가 높고, 절반은 결제와 아무 상관이 없어 그대로 남는다면 낮습니다.

같은 덩어리에 묶인 이유를 따져 보면 단계가 나뉩니다. 아래로 갈수록 높은 응집도입니다.

1. 그냥 둘 데가 없어서 — 앞서 나온 utils 파일입니다. 묶인 이유가 아예 없어서 가장 낮습니다.
2. 비슷해 보여서 — 이메일 형식 검사와 결제 카드번호 검사를 "검증" 이라는 한 덩어리에 넣는 경우입니다. 이름은 그럴듯하지만 이메일 규칙이 바뀔 때 카드 쪽은 열어 볼 이유가 없습니다.
3. 같은 때에 실행돼서 — 앱이 켜질 때 해야 하는 일들을 "초기화" 에 몰아 둔 경우입니다. 실행 시점만 같을 뿐 서로 남남이라, 한 줄을 지웠을 때 무엇이 망가지는지 아무도 예측하지 못합니다.
4. 한 가지 일을 함께 이뤄서 — 할인 계산과 결제 요청과 영수증 발행이 결제 덩어리에 함께 있는 경우입니다. 셋 중 하나만 바뀌는 일이 드물기 때문에 열어야 할 파일이 하나로 줄어듭니다.

페이지덱의 문서 공유 기능을 예로 들면, 링크를 만들고 권한을 확인하고 만료 시각을 계산하는 코드가 한 덩어리에 있으면 4번입니다. 여기에 공유했다는 알림 메일을 보내는 코드까지 들어가면 2번으로 내려갑니다. 메일 문구를 바꾸려고 공유 기능을 여는 상황이 생기고, 그러다 권한 확인 코드를 건드릴 위험이 따라옵니다.

측정하는 계산식은 따로 없습니다. 대신 실무에서는 한 가지 요청을 처리할 때 몇 개의 파일을 열었는지를 기록해 두고 씁니다. 같은 성격의 요청에 매번 다섯 개 이상을 열고 있다면 그 기능은 흩어져 있습니다.

가장 자주 쓰이는 자리는 코드 리뷰입니다. "이 함수는 여기 있을 게 아니다" 라는 지적을 응집도라는 말로 하면 무엇을 어디로 옮기자는 이야기로 바뀝니다. 알림 전송 코드가 결제 모듈에 들어와 있으면 결제가 알림 문구 때문에 다시 배포되는 상황을 막기 위해 옮기자고 말할 수 있습니다.

덩어리의 경계를 새로 그을 때도 봅니다. 모놀리스는 전부를 한 덩어리에 담아 한 번에 올리는 방식인데, 여기서 마이크로서비스처럼 기능별로 잘라 따로 올리는 구조로 옮기려면 자를 선이 보여야 합니다. 응집도가 낮은 상태에서 자르면 결제 서비스를 떼어 냈는데 알림 코드가 딸려 오고, 알림을 고칠 때마다 결제 서비스를 다시 올려야 하는 상태가 그대로 옮겨 갑니다. 자르기 전에 한 덩어리 안에서 먼저 모으는 순서를 밟는 이유입니다.

경계를 어디에 그을지 자체를 다루는 방법도 있습니다. 도메인 주도 설계는 데이터베이스 표 모양이 아니라 업무에서 쓰는 말을 기준으로 선을 긋는 방식이고, 그 기준을 따르면 응집도가 자연히 올라갑니다. 업무에서 함께 바뀌는 것들이 대체로 같은 말로 불리기 때문입니다.

"이 모듈 응집도가 너무 낮아요. 알림 보내는 코드는 빼는 게 맞습니다."

한 덩어리 안에 성격이 다른 일이 섞여 있으니 옮기자는 제안입니다.

"문구 하나 바꾸는 데 파일 여섯 개를 열었어요."

숫자를 들어 응집도가 낮다고 말하는 방식입니다.

"지금 자르면 경계가 어중간해요. 응집도부터 올리고 나서 나눕시다."

구조를 바꾸기 전에 덩어리 안을 먼저 정리하자는 뜻입니다.

페이지덱에서 문서 내보내기 기능이 매번 말썽이던 시기가 있었습니다. PDF 로 내보내는 코드가 문서 편집 쪽에 있었고, 파일 이름을 만드는 코드는 공유 기능 쪽에, 내보내기 횟수를 세는 코드는 결제 쪽에 있었습니다. 요금제마다 횟수 제한이 달라 결제 쪽에 들어간 것이었습니다.

태오가 이 셋을 내보내기라는 한 덩어리로 모으자고 제안했고, 결제 쪽에는 이번 달 남은 횟수를 묻는 창구 하나만 남겼습니다. 그 뒤로 내보내기 관련 요청은 파일 한 곳에서 끝났습니다. 지현이 요금제별 제한을 바꿔 달라고 했을 때도 결제 쪽 숫자만 고치면 됐습니다.

파일을 잘게 쪼개면 응집도가 올라간다고 여기는 경우가 많습니다. 큰 파일이 문제라는 지적을 자주 듣다 보니 길이와 응집도를 같은 것으로 읽게 됩니다. 하지만 재는 대상은 크기가 아니라 관계입니다. 300줄짜리 파일 하나를 50줄짜리 여섯 개로 쪼개도 그 여섯이 여전히 서로 무관하면 응집도는 그대로이고, 오히려 흩어진 자리가 늘어 찾기만 어려워집니다. 반대로 한 가지 일을 하는 코드 500줄이 한 파일에 모여 있다면 그 파일은 응집도가 높습니다.

응집도를 올리려면 결합도를 포기해야 한다고 읽는 것도 흔한 오해입니다. 둘 다 좋게 가져갈 수는 없다는 말을 어디선가 듣고 오는 경우입니다. 실제로는 대개 같이 움직입니다. 관련 있는 것들이 한자리에 모이면 덩어리끼리 주고받을 일이 줄어들어 얽힘도 함께 줄기 때문입니다. 둘이 반대로 움직이는 것처럼 보인다면 경계를 잘못 그은 것이고, 그때 손볼 것은 둘 사이의 균형이 아니라 선의 위치입니다.