코드가 일정 기간 동안 얼마나 많이 바뀌었는지(추가·수정·삭제)를 측정하는 지표입니다. 흔히 “rework(재작업)”이라고도 부릅니다. (Jellyfish)
왜 중요해요?
- churn이 높으면 프로젝트 불안정 신호일 수 있어요. 초반엔 높다가 릴리스가 가까워질수록 낮아지는 게 보통입니다. (Microsoft Learn)
- 연구에선 높은 churn이 결함(버그) 밀도와 상관이 있음을 보고하기도 했습니다(Windows Server 2003 사례). 다만 단독으로는 불완전한 지표예요. (ACM Digital Library)
어떻게 계산해요? (대표적인 방식)
- 기간 내 추가+수정+삭제된 LOC(라인 수) 를 합산 → 이를 전체 변경 대비 비율로 보거나, 파일/모듈 단위로 추적합니다. 예: 지난 14일에 쓴 100라인 중 40라인을 고쳤다면 churn 40%. (Swimm)
빠르게 보는 Git 예시
# 지난 14일간 전체 변경 요약(추가/삭제 라인 합계)
git log --since="14 days ago" --shortstat --pretty=tformat: | \
awk '/files? changed/{a+=$4; b+=$6} END{print "added:",a,"deleted:",b}'
# 파일별 변경량 상위(핫스팟) 찾기
git log --since="30 days ago" --numstat --pretty="%H" | \
awk 'NF==3{add+=$1;del+=$2;file=$3;f[file]+=($1+$2)} END{for (i in f) print f[i], i}' | \
sort -nr | head
원리는 “추가/삭제 라인 합”을 기간으로 묶어 합산·비교하는 겁니다. (TFS/Azure DevOps 등도 같은 개념으로 리포트를 제공합니다.) (Microsoft Learn)
해석 팁
- 초반 스파이크: 요구사항 변화·대규모 리팩터링이면 자연스러움.
- 릴리스 직전 고 churn: 위험 신호(안정화 부족)일 수 있음. (Microsoft Learn)
- 지속적으로 많이 바뀌는 파일: 구조적 문제(응집도/결합도)나 명확하지 않은 책임의 단서.
- 경험칙: 일부 엔지니어링 블로그는 **재작업 20%**를 경계선으로 보기도 하지만, 조직/코드베이스마다 다릅니다(참고용). (LinearB)
주의할 점(함정)
- 포매터 적용/대규모 자동 리팩터링은 churn을 인위적으로 키움 → 제외 필터(경로/파일) 설정 권장.
- churn만 보면 복잡도를 반영 못 함 → 복잡도 지표(예: 순환복잡도), 결함 데이터와 함께 보세요. 최신 연구도 churn 단독 한계를 지적합니다. (Nature)
툴
- Azure DevOps(Code Churn Report), 다양한 엔지니어링 인텔리전스 툴(예: Jellyfish, LinearB 등)에서 지표/대시보드로 제공됩니다. (Microsoft Learn)
TL;DR: code churn = 일정 기간 코드 변경량(추가·수정·삭제). 초반엔 높을 수 있지만, 릴리스가 가까울수록 내려가야 안정적이고, 버그 위험의 단서가 되기도 합니다. 단, 복잡도·품질 지표와 함께 보세요. (Microsoft Learn)
답글 남기기