기술 부채 측정: SonarQube를 넘어

Source: Dev.to

SonarQube의 한계

SonarQube는 코드 냄새에 대해 알려 주지만, 청구 서비스가 인증 서비스와 데이터베이스 테이블을 공유하는 것처럼 문서화되지 않은 결합 관계—곧 퇴사할 한 명의 엔지니어만 알고 있는 관계—를 드러내지는 못합니다.
이러한 종류의 기술 부채가 실제로 문제를 일으킵니다.

전통적인 코드 품질 도구가 측정하는 것

• 순환 복잡도(함수 수준)
• 코드 중복
• 테스트 커버리지 비율
• 스타일 위반
• 알려진 취약점 패턴

이 메트릭들은 유용하지만 피상적입니다. 코드베이스가 SonarQube에서 A+를 받더라도 실제 부채가 구조적이고 구문적인 것이 아니라면 운영상의 악몽이 될 수 있습니다.

구조적 부채

전형적인 증상

• 서비스 간 원하지 않는 결합
• 독립적이어야 할 서비스들 간에 공유되는 데이터베이스 테이블
• 정리되지 않은 채 남아 여러 코드 경로를 제어하는 기능 플래그

구조적 부채 측정 방법

• 크로스‑기능 의존성 수 – 독립적이어야 할 기능들을 연결하는 엣지 수
• 결합 비율 – 기능당 내부 의존성 / 외부 의존성
• 순환 의존성 탐지 – 서로를 의존하는 서비스들 (A → B → A)

지식 부채

증상

• 문서화되지 않은 트라이벌 지식(예: “Mike에게 물어봐”)
• 한 사람만 이해하는 코드 영역

지식 부채 측정 방법

• 기능별 버스 팩터 – 지난 6개월 동안 각 기능에 커밋한 사람 수
• 지식 집중도 – 기능당 상위 기여자가 작성한 코드 비율
• 리뷰 커버리지 – 해당 영역의 PR 중 작성자 외 다른 사람이 리뷰한 비율

아키텍처 부채

증상

• 분해되어야 할 모놀리식
• 잘못 배치된 서비스 경계
• 감싸는 코드보다 이해하기 어려운 과도하게 패치된 추상화

아키텍처 부채 측정 방법

• 변경 결합 – 항상 함께 변경되지만 서로 다른 기능에 속하는 파일(누락된 추상화 시사)
• 기능별 churn 비율 – 아키텍처가 감당하기에 버거운 고 churn 기능
• PR 크기 분포 – 특정 기능에서 지속적으로 큰 PR이 나타나는 경우 경계가 잘못 잡혔을 가능성

보다 실행 가능한 대시보드

단일 SonarQube 등급 대신, 다음과 같은 정보를 보여주는 대시보드를 상상해 보세요:

• 기능 건강 그리드 – 각 기능을 복잡도, 결합, 지식 집중도, churn 기준으로 점수화
• 위험 핫스팟 – (churn × coupling × single‑author %) 기준 상위 10개 파일, 운영 사고 가능성 순으로 정렬
• 지식 위험 – 최근 커밋의 80 % 이상이 한 사람에게서 나온 기능
• 의존성 이상 – 지난 분기 동안 증가한 크로스‑기능 의존성
• 진화 압력 – churn은 높지만 테스트 커버리지는 낮은 기능 – 미래 사고의 가장 가능성 높은 원천

이러한 인사이트는 Glue의 team insights와 code health 기능이 제공하는 것으로, 구문 수준 메트릭이 아니라 실제 위험에 대한 시스템‑레벨 인텔리전스입니다.

메트릭을 의사결정으로 연결하기

• 청구 서비스에 지식 위험이 높음? → 해당 단독 기여자와 페어링 세션을 일정에 잡아 휴가 전에 공유하도록 합니다.
• 크로스‑기능 결합이 증가하고 있나요? → 경계 정리를 위한 리팩터링 스프린트를 우선순위에 둡니다.
• 인증 서비스에 churn은 높고 커버리지는 낮음? → 다음 기능 배포 전 통합 테스트를 추가합니다.

“우리는 기술 부채가 있다”(모두가 알고 있음)와 “우리는 3개의 지식 집중 기능, 2개의 결합 이상, 테스트 커버리지가 0인 고 churn 영역을 가지고 있다”(실행 가능한 인텔리전스) 사이의 차이가 불평과 해결의 차이입니다.