4.3 코드 처닝과 핫스팟 분석

개요 및 동기

코드 처닝은 파일이나 모듈이 시간에 따라 얼마나 자주 변경되는지, 즉 연속된 커밋에 걸쳐 추가되고, 수정되고, 삭제된 줄을 측정한다. 그 자체로는 처닝은 상당히 약한 신호다: 일부 파일은 활발하고 건강한 개발 아래 있기 때문에 자주 변경되며, 일부는 방치되어서가 아니라 안정적이고 올바르기 때문에 거의 변경되지 않는다. 이 주제의 접근법이 가진 진정한 진단력은 처닝을 복잡도(주제 4.1)와 결합하는 데서 온다: 자주 변경되면서 동시에 매우 복잡한 파일, 즉 핫스팟은 불균형하게 결함의 원천이자 팀 속도에 대한 걸림돌이 될 가능성이 높으며, 실증 연구는 많은 코드베이스와 조직에 걸쳐 이를 일관되게 뒷받침한다.

Adam Tornhill의 소프트웨어 분석 작업으로 대중화된 핫스팟 분석은 그 목표를 찾는 데 어떤 수동 조사나 주관적 판단도 필요하지 않다는 점에서 특별히 가치가 있다. 버전 관리 이력은 이미 코드베이스의 모든 파일에 대해 자동으로 처닝과, 정적 분석 도구와 결합된, 복잡도 둘 다를 계산하는 데 필요한 모든 것을 담고 있다. 이는 팀이나 조직이 일화나 회고에서 가장 큰 목소리의 불만이 아니라 실제 증거로, 코드베이스의 정확히 어느 작은 부분이 먼저 리팩토링 관심을 받을 자격이 있는지 식별할 수 있게 한다.

대규모 팀에게 핫스팟 분석은 진정한 배분 문제를 해결한다: 수십만 줄의 코드베이스는 어떤 팀도 포괄적으로 리팩토링할 여유가 없을 만큼 훨씬 더 많은 코드를 가지고 있으며, 최악의 문제가 어디에 사는지에 대한 직관은 흔히 틀리고, 가장 최근에 불평한 사람이나 고참 엔지니어가 우연히 싫어하는 파일에 의해 치우쳐 있다. 크고 장수명인 코드베이스를 관리하는 엔터프라이즈와 정부 조직은 진정으로 희소한 리팩토링 예산을 가장 큰 수익을 만들어 낼 코드로 이끌기 위해 이 데이터 주도 우선순위 지정에 의존한다.

핵심 원칙

처닝 홀로는 약한 신호다. 복잡도와 결합된 처닝은 강하다. 어느 메트릭 홀로가 아니라 그 조합이야말로 진정한 핫스팟을 식별하는 것이다.
핫스팟 분석은 어떤 수동 조사도 필요하지 않다. 버전 관리 이력은 이미 그것을 자동으로 계산하는 데 필요한 모든 것을 담고 있다.
핫스팟은 우선순위 지정 신호이지 자동 평결이 아니다. 특정 핫스팟이 어떤 행동을 요구하는지 결정하는 데는 여전히 사람의 판단이 필요하다.
빈번한 변경이 본질적으로 나쁜 것은 아니다. 일부 처닝은 품질 문제가 아니라 건강하고 활발한 개발을 반영한다.
이 분석은 정확히 직관이 실패하는 곳에서 확장된다: 어느 개인도 느낌만으로 조사하고 우선순위를 정하기에는 너무 큰 대규모 코드베이스에서.

권장 사항

처닝과 복잡도를 함께 계산하고 그 조합으로 순위를 매기라

의미 있는 창, 전형적으로 6개월에서 1년에 걸쳐 버전 관리 이력으로부터 파일별 변경 빈도를 추출하고, 같은 파일에 대한 복잡도 측정치(주제 4.1)와 짝지어라. 어느 메트릭 홀로가 아니라 조합, 흔히 처닝과 복잡도의 곱으로 파일 순위를 매겨라. 이 조합이야말로 근본적인 연구가 일관되게 상승된 결함률과 유지보수 비용과 연관짓는 것이기 때문이다.

행동하기 전에 사람의 판단으로 상위 핫스팟을 조사하라

순위가 매겨진 핫스팟 목록은 자동 행동 목록이 아니라 관심을 받을 후보를 식별한다. 당신의 상위 핫스팟 각각에 대해, 사람의 눈으로 조사하라: 이것은 리팩토링이 필요한 진정으로 잘못 설계된 코드인가, 아니면 활발하고 진화하는 비즈니스 논리의 중심에 자리하기 때문에 정당하게 빈번한 변경이 필요한 파일인가. 후자의 경우 우선순위는 구조적 재작성이 아니라 더 나은 테스트나 더 명확한 문서화일 수 있다. 이것은 결합된 처닝-복잡도 신호에 적용된 주제 4.1의 본질적 대 우발적 복잡도 구분을 반영한다.

핫스팟을 인시던트와 결함 데이터에 비추어 교차 참조하라

이용 가능한 곳에서는, 식별된 핫스팟이 실제 프로덕션 인시던트(주제 6.2)나 결함 누락 데이터(주제 5.1)와 상관관계가 있는지 확인하라. 강한 상관관계는 핫스팟 분석이 당신의 특정 코드베이스에 진정으로 예측적이라는 것을 검증하고 그것에 행동하는 것에 대한 비즈니스 사례를 강화한다. 약하거나 부재한 상관관계는 데이터 품질 문제이거나, 당신의 특정 맥락에서 처닝과 복잡도가 우선순위를 정할 올바른 신호 조합이 아니라는 것을 시사한다.

단일 스냅샷뿐 아니라 연속된 분석에 걸친 핫스팟 추세를 추적하라

주기적으로(분기별이 흔하다) 핫스팟 분석을 다시 실행하고 이전에 식별된 핫스팟이 개선되고 있는지, 악화되고 있는지, 해결되었는지, 그리고 새로운 것이 나타나고 있는지 추적하라. 반복적으로 표시되었음에도 여러 분석 주기에 걸쳐 지속되는 핫스팟은 개선 노력이 실제로 적용되지 않았거나 이전의 개선 시도가 실제 근본 문제를 다루지 못했다는 것을 나타낸다.

핫스팟 데이터를 사용해 팀 수준 우선순위 지정 대화를 대체하지 말고 알려라

핫스팟 분석을 지금 가장 중요한 것에 대한 팀 자체의 맥락적 판단을 무시하는 자동 명령이 아니라 우선순위 지정 논의에서의 증거로 제시하라. 팀은 알려진 핫스팟의 우선순위를 일시적으로 낮출 좋고 정당한 이유를 가질 수 있다. 예를 들어 다가오는 계획된 재작성이 점진적인 리팩토링을 낭비되는 노력으로 만든다면, 그리고 그 분석은 그 대화를 대체하는 것이 아니라 알려줘야 한다.

트레이드오프: 장단점

접근법	장점	단점
직관 기반 우선순위 지정	빠르고, 도구가 필요 없으며, 팀의 맥락적 지식을 활용함	최신성, 개인적 선호, 가장 크게 불평하는 사람에 의해 치우침
처닝 홀로	계산하기 단순함	그 자체로는 약한 신호; 빈번한 변경이 본질적으로 나쁜 것은 아님
복잡도와 결합된 처닝 (핫스팟 분석)	강하고, 증거에 기반하며, 기존 데이터로부터 자동임	두 데이터 출처를 결합하고 판단으로 결과를 해석해야 함
인시던트 데이터와 교차 참조된 핫스팟 분석	검증되었고, 우선순위 지정에 대한 가장 강한 증거	모든 조직이 가지고 있지는 않은 신뢰할 수 있는 인시던트-코드 연결이 필요함

핵심 긴장은 증거 대 맥락이다. 핫스팟 분석은 직관 기반 우선순위 지정이 크고, 낯설거나, 장수명인 코드베이스의 규모에서 맞먹을 수 없는 객관적이고 확장 가능한 증거를 제공하지만, 특정 핫스팟이 지금 왜 중요한지, 혹은 중요하지 않은지에 대해 팀이 가진 맥락적 판단은 부족하다. 핫스팟 분석을 타이밍과 트레이드오프에 대한 팀 자체의 맥락적 판단을 대체하는 것이 아니라 그것과 결합된, 우선순위 지정 대화를 위한 증거 기반으로 취급함으로써 이 긴장을 해결하라.

팀과 논의할 질문

처닝과 복잡도를 결합하여 순위를 매긴 우리의 상위 다섯 핫스팟은 무엇이며, 그 순위는 우리의 최악의 문제가 어디에 사는지에 대한 우리 팀의 직관과 일치할까? 분석을 실행하고 그 결과를 데이터를 보기 전에 당신의 팀이 추측했을 것과 비교하라. 불일치는 흔히 가장 가치 있는 발견이다.
우리가 식별한 핫스팟은 실제 프로덕션 인시던트나 결함 누락 데이터와 상관관계가 있는가? 이것을 확인할 데이터가 있다면 직접 그렇게 하라. 없다면, 그 간극 자체가 쌓아 올릴 가치가 있는 것으로 이름 붙일 가치가 있다.
지금 우리의 상위 핫스팟에 대해, 근본적인 문제는 정당하게 빈번한 변경을 요구하는 본질적 복잡도인가, 아니면 리팩토링이 진정으로 고칠 수 있는 우발적 복잡도인가? 그 파일을 함께 살펴보고 어느 쪽 답도 가정하지 않고 이 판단을 명시적으로 내려라.
이전에 식별된 핫스팟이 표시되었음에도 여러 분석 주기에 걸쳐 지속된 적이 있는가? 만약 그렇다면, 왜인지 정직하게 조사하라: 개선이 실제로 시도된 적이 없었는가, 아니면 이전 시도가 실제 근본 원인을 다루지 못했는가.
우리는 현재 증거에 근거해 리팩토링 작업의 우선순위를 정하는가, 아니면 가장 최근에 혹은 가장 크게 불평한 사람에 근거해 정하는가? 당신 팀의 실제 현재 우선순위 지정 절차와 그것이 증거 기반 핫스팟 분석이 시사할 것과 어떻게 비교되는지에 대해 정직해져라.
우리의 현재 상위 핫스팟을 또 다른 1년 동안 다루지 않고 남겨 둔다면 결함률이나 전달 둔화에서 우리에게 어떤 비용이 들까? 이 질문은 핫스팟을 추상적이고 쉽게 우선순위가 낮아지는 관심사로 남겨 두는 대신 우선순위 지정 결정에 닻을 내릴 수 있는 구체적인 비용 추정을 강제한다.

분야별 관점

스타트업. 공식적인 핫스팟 분석은 전체 팀이 여전히 집단적으로 머릿속에 담고 있는 작고 젊은 코드베이스에서는 보통 불필요하다. 이 기법은 특별히 코드베이스가 어느 개인이든 기억만으로 신뢰성 있게 최악의 영역을 식별할 수 있는 규모를 넘어 성장한 후, 흔히 지속적인 성장의 첫 1~2년 어딘가에서 가치 있어진다.

중소기업. 무료나 저렴한 도구는 최소한의 설정으로 당신의 기존 버전 관리 이력으로부터 직접 처닝 데이터를 추출할 수 있다. 이 규모에서 전용 상용 핫스팟 분석 소프트웨어에 투자하는 대신 그것을 당신의 기존 린터나 정적 분석 도구가 이미 보고하는 복잡도 데이터와 결합하라.

엔터프라이즈. 핫스팟 분석은 증거 기반 우선순위 지정이 가장 큰 수익을 얻는 곳인데, 수백 개의 서비스와 수천 개의 파일에 걸친 코드베이스의 규모에서는 직관이 진정으로 실패하기 때문이다. 전체 코드베이스에 걸쳐 정기적으로 이 분석을 실행하고 인시던트 데이터에 비추어 교차 참조하여 리팩토링 투자에 대한 검증되고 방어 가능한 사례를 구축하는 데 투자하라.

정부. 때로는 수십 년 된 장수명 시스템은 핫스팟 분석에 자연스럽게 적합한데, 축적된 버전 관리 이력이 시스템의 어느 부분이 시간이 지남에 따라 진정으로 문제가 있는 것으로 입증되었는지에 대한 풍부하고 장기적인 신호를 제공하기 때문이다. 이 증거 기반 접근법은 또한 자금을 승인하기 위해 엔지니어의 비공식적인 의견 이상의 것이 필요한 이해관계자에게 현대화 투자를 정당화하기 위한 설득력 있고 구체적인 도구다.

사례

엔터프라이즈. 수십 개의 서비스에 걸쳐 200만 줄이 넘는 코드로 이루어진 한 보험 회사의 보험금 청구 처리 플랫폼은 “보험금 청구 검증 모듈”이 문제가 있다는 몇 년에 걸친 비공식적인 불만을 축적해 왔지만, 그 불만으로부터 공식적인 우선순위 지정이 결코 뒤따른 적이 없었다. 6개월의 처닝 데이터를 복잡도 점수와 결합한 핫스팟 분석은 완전히 다른 파일, 즉 거의 논의되지 않는 의존성 깊숙이 묻혀 있는 공유 통화 변환 유틸리티를 실제 상위 핫스팟으로 식별했으며, 이는 어떤 회고 불만에서도 결코 나온 적이 없는 것이었다. 인시던트 데이터에 비추어 교차 참조한 것은 이 유틸리티가 지난해 동안 불균형한 몫의 재무 계산 결함에 연루되었다는 것을 확인시켜 주었고, 모두가 비공식적으로 탓해 왔던 모듈이 아니라 그 특정 유틸리티의 목표를 겨냥한 리팩토링은 다음 분기 안에 관련 인시던트의 측정 가능한 감소를 만들어 냈다.

정부. 한 주 차량국의 수십 년 된 면허 시스템은 현대화 비즈니스 사례의 일부로 핫스팟 분석을 받았다. 그 분석은 전체 코드베이스의 3% 미만을 나타내는 작은 파일 군집을 처닝과 복잡도 둘 다의 불균형한 몫을 책임지는 것으로 식별했고, 그 기관의 인시던트 로그에 비추어 교차 참조한 것은 같은 군집이 지난 3년 동안 보고된 모든 시스템 결함의 거의 40%를 차지한다는 것을 보여 주었다. “시스템이 오래되었고 현대화가 필요하다”는 일반적인 주장보다 훨씬 더 설득력 있는 이 구체적이고 증거 기반의 발견은, 훨씬 더 비싼 전체 시스템 교체 대신 그 군집에 특별히 초점을 맞춘 목표를 겨냥한 점진적인 현대화 노력에 대한 성공적인 예산 요청의 중심이 되었다.

비즈니스 사례: 동기, ROI, TCO

핫스팟 분석의 수익은 목표를 겨냥한, 증거 기반의 투자다: 위의 두 사례 모두 공식적인 분석이 비공식적인 불만이 집중했던 곳으로부터 벗어나 데이터가 실제로 문제가 산다고 보여 준 곳으로 리팩토링 관심을 재조정한 경우를 보여 주며, 이는 목표 없거나 직관에 이끌린 투자보다 측정 가능하게 더 나은 수익을 만들어 냈다.

총 소유 비용은 낮다. 처닝 데이터는 기존 버전 관리 이력에서 직접 오고 복잡도 데이터는 보통 이미 정적 분석 도구(주제 4.4)로부터 이용 가능하기 때문이다. 주된 투자는 주기적인 분석 노력과 결과를 해석하고 식별된 각 핫스팟이 어떤 행동을 요구하는지 결정하는 사람의 판단 시간이다.

안티패턴과 함정

복잡도 없이 처닝만 사용하기: 그 자체로는 건강하고 활발하게 개발되는 코드를 거짓 양성으로 표시할 수 있는 약한 신호.
핫스팟 순위를 사람의 판단 없는 자동 행동 목록으로 취급하기: 올바른 대응을 결정하는 본질적 대 우발적 구분을 놓친다.
증거가 아니라 가장 큰 목소리의 불만에 근거해 리팩토링 우선순위 정하기: 흔히 데이터가 실제로 문제가 산다고 보여 주는 곳으로부터 노력을 잘못 이끈다.
핫스팟을 인시던트나 결함 데이터에 비추어 결코 교차 참조하지 않기: 분석에 행동하는 것에 대한 사례를 강화하는 검증 단계를 놓친다.
분석을 한 번 실행하고 결코 반복하지 않기: 개선 노력이 시간이 지남에 따라 실제로 작동하고 있는지를 놓친다.
왜 개선이 자리 잡지 못했는지 조사하지 않고 지속적으로 표시되는 핫스팟을 무시하기: 반복된 분석의 진단적 가치를 낭비한다.

성숙도 모델

1단계, 시작: 리팩토링 우선순위가 처닝이나 복잡도 데이터가 결정을 알려주지 않은 채 직관이나 불만 물량에 의해 설정된다.
2단계, 개발: 일부 팀이 비공식적으로 처닝이나 복잡도 데이터를 확인하지만, 일관되고 조직 전체의 핫스팟 분석 관행이 없다.
3단계, 표준화: 처닝과 복잡도를 결합한 핫스팟 분석이 정기적이고 일관되게 실행되며 조직 전체에서 리팩토링 우선순위 지정을 알려준다.
4단계, 관리: 핫스팟이 분석을 검증하기 위해 인시던트와 결함 데이터에 비추어 교차 참조되며, 연속된 주기에 걸친 추세가 능동적으로 추적된다.
5단계, 조율: 조직은 핫스팟에 정보를 받은 리팩토링 투자로부터 나온 구체적이고 측정 가능한 결함률이나 전달 개선을 제시할 수 있으며, 그 분석은 엔지니어링 투자 결정에 대한 일상적이고 신뢰받는 입력이다.

논의를 위한 아이디어

오늘 이 분석을 실행한다면 우리의 상위 핫스팟 목록은 어떻게 보일까?
그 목록은 우리의 최악의 문제 영역에 대한 우리 팀의 현재 비공식적인 감각과 일치할까, 아니면 모순될까?
우리는 핫스팟을 실제 인시던트에 비추어 교차 참조할 데이터를 가지고 있는가?
알려진 문제 영역이 이전의 고치려는 시도에도 불구하고 지속된 적이 있는가, 왜인가?
우리의 현재 상위 핫스팟을 또 다른 1년 동안 다루지 않고 남겨 둔다면 우리에게 어떤 비용이 들까?

핵심 요약

복잡도와 결합된 처닝은 어느 메트릭 홀로보다 훨씬 더 신뢰성 있게 진정한 핫스팟을 식별한다.
핫스팟 분석은 어떤 수동 조사도 필요하지 않다. 그것은 기존 버전 관리와 정적 분석 데이터로부터 자동으로 계산 가능하다.
핫스팟 순위를 자동 평결이 아니라 우선순위 지정을 위한 증거로 취급하라. 사람의 판단이 여전히 필요하다.
분석을 검증하고 그것에 행동하는 것에 대한 사례를 강화하기 위해 핫스팟을 인시던트와 결함 데이터에 비추어 교차 참조하라.
개선이 실제로 작동하고 있는지 확인하기 위해 단일 스냅샷이 아니라 연속된 분석 주기에 걸쳐 핫스팟을 추적하라.

참고 문헌 및 추가 자료

Tornhill, Adam. Your Code as a Crime Scene. Pragmatic Bookshelf, 2015.
Tornhill, Adam. Software Design X-Rays. Pragmatic Bookshelf, 2018.
Nagappan, Nachiappan, and Thomas Ball. “Use of Relative Code Churn Measures to Predict System Defect Density.” ICSE, 2005.
Fowler, Martin. Refactoring: Improving the Design of Existing Code. Addison-Wesley, 1999.