2026-03 Testing Metrics 사전 준비 없이 Ad Hoc으로 뽑아보기

최초 업로드 2026-03-17 / 마지막 수정 2026-03-17

개발 조직의 성과가 비즈니스 성과로 지표적으로 수치로 이어지는 것을 대표님들 + 전사 동료분들에게 보여드리는 것이 올해 목표 중 하나이다.

사업적인 지표로 전환하려면 먼저 개발 지표에 다른 개념을 곱셈하는게 가장 쉽다. (예 - 버그 발생률 20% 감소 x 버그 당 평균 개발자 투입 시간 = 돈)

이번에는 테스팅 메트릭을 보고 있다. 테스트가 전무하던 환경에 Jest 세팅부터 시작해서, 4개 레포에 400개 이상의 테스트 파일을 작성하고, Testcontainers 기반 통합 테스트 인프라를 구축하고, 팀원들이 같은 패턴으로 테스트를 쓰기 시작하는 것까지 만들어냈다. 이걸 지표적으로 지난 2년간 트래킹을 안했었는데, 지금 adhoc으로 측정해서 확인할 수가 있을까?

git 히스토리에서 가능한 모든 방법을 시도해보았다. 결론부터 말하면, git 데이터만으로 테스팅 효과를 정량화하는 것은 많이 어렵다.

DORA 4대 지표로 시도

소프트웨어 딜리버리 성능의 업계 표준인 DORA 지표를 전부 계산해보았다. main 머지가 곧 프로덕션 배포(CI/CD 자동)인 환경이라, main 머지를 배포 단위로 사용했다.

Deployment Frequency: 전 기간 Elite (일 평균 2.3회, 최근 5~7회). 하지만 이건 팀 전체의 배포 문화이지 테스팅 효과가 아니다.

# main 머지 횟수 = 배포 횟수 (main 머지 시 CI/CD 자동 배포)
git log main --merges --format='%ad' --date=format:'%Y-%m' | sort | uniq -c

Lead Time for Changes: 전체 중앙값은 9분이지만, 이건 49%를 차지하는 1-커밋 PR(핫픽스/설정 변경)이 끌어내린 수치다. PR 규모별로 보면 실체가 다르다:

단일 대표값(중앙값이든 평균이든)으로는 이 분포를 설명할 수 없다. 중앙값 9분은 "빠르다"고 말하기엔 오해가 크고, 평균 30시간은 대규모 PR 아웃라이어에 끌려간 수치다. 결국 이것도 테스팅 효과와는 관련 없이, PR을 잘게 쪼개서 자주 머지하는 워크플로우의 반영이다.

# 각 머지 커밋에 대해: 브랜치 첫 커밋 시각 ~ 머지 시각의 차이
# 머지 커밋 해시와 시각 조회
git log main --merges --format='%H|%ad' --date=iso

# 특정 머지의 브랜치 첫 커밋 시각 (hash = 머지 커밋 해시)
git log --format='%ad' --date=iso --reverse ${hash}^1..${hash}^2 | head -1

Change Failure Rate: 정의에 따라 결과가 완전히 달라진다. fix 브랜치 기준으로 보면 테스트 도입 과도기에 오히려 악화(8% → 27%)되었다가 성숙기에 회복(11%). hotfix 기준, revert 기준 모두 깔끔한 추세를 만들지 못했다.

# fix 머지 비율 (머지 커밋 메시지에서 fix 브랜치 판별)
git log main --merges --format='%s' | grep -c 'fix/'  # fix 브랜치 머지 수
git log main --merges --oneline | wc -l                 # 전체 머지 수

MTTR: 유일하게 일관된 개선 추세를 보였다 (중앙값 14.1h → 1.6h). 하지만 이것도 테스팅만의 효과로 귀인할 수 없었다.

# MTTR: 직전 비-fix 배포 시각 → fix 배포 시각의 차이
# 머지 커밋들의 시각과 fix 여부를 시계열로 뽑은 뒤 python으로 계산
git log main --merges --format='%ad|%s' --date=iso | head -500

왜 DORA가 안 먹히는가

DORA는 "소프트웨어 딜리버리 성능"을 측정하는 팀/조직 레벨 지표이지, 테스팅 전용 지표가 아니다. 테스팅은 DORA에 영향을 주는 수많은 요인 중 하나일 뿐이고, 팀 성숙도, 아키텍처 개선, 인프라 안정화 등의 교란 변수를 통제할 수 없다.

특히 개인 단위로 쪼개보면 상황이 더 안 좋아진다. 내 CFR이 팀원 대비 3배 높게 나왔다 (27% vs 8.4%). 가장 복잡한 도메인(gov-grant, ES, company)을 담당하면서 남의 버그도 고쳐주는 사람이니까 fix 브랜치가 많을 수밖에 없는데, 맥락 없이 숫자만 보면 "이 사람 코드 버그가 많네?"로 읽힌다.

그리고 근본적으로, 우리가 측정한 방식은 표준 DORA 측정 방식과 상당히 다르다.

DF와 LT는 main 머지가 곧 배포인 우리 환경에서 꽤 정확하다. 하지만 CFR과 MTTR은 근본적으로 다르다. fix: 커밋은 프로덕션 장애가 아니라 개발 중 발견한 버그, 사소한 수정, 남의 코드 수정이 전부 섞여 있다. 표준 MTTR은 장애 감지 시점이 시작점인데, 우리에겐 그 데이터 자체가 없다. 결국 git 히스토리만으로는 CFR과 MTTR을 표준에 가깝게 측정하는 것 자체가 불가능하다.

DORA 외 접근들

DORA가 안 되니까 다른 방법을 시도했다.

모듈별 테스트 도입 전/후 fix 비율 비교: v2 모듈 18개 중 13개가 모듈 생성과 동시에 테스트가 들어가서 "전" 데이터가 없었다. 비교 가능한 5개 모듈은 2개 개선, 3개 악화로 방향성 없음.

Rework Rate (7일 이내 동일 파일 재수정 비율): 기간별로는 60.6% → 42%로 개선 추세가 보였지만, 테스트 있는 파일 vs 없는 파일로 나누면 오히려 테스트 있는 파일의 rework이 더 높았다 (49.8% vs 34.7%).

테스트 포함 PR vs 미포함 PR의 후속 fix 비율: 사실상 차이 없음 (48.2% vs 47.2%).

5일 윈도우 DER (Defect Escape Rate): 배포 빈도가 일 23회라 5일 윈도우 안에 어떤 fix든 걸려서 7891%라는 비현실적 수치가 나왔다. 그리고 애초에 테스팅이랑 개발을 같이하는 경우가 많아서 측정이 어렵다.

모든 접근에서 부딪힌 공통 벽

선택 편향: 테스트를 작성하는 대상 = 가장 복잡하고 자주 변하는 핵심 코드. 당연히 fix도 많고 rework도 많다. git 데이터만으로는 이 편향을 통제할 수 없다.

반사실적 질문: "테스트가 없었으면 어땠을까?"는 원천적으로 관측 불가. 테스트가 잡은 버그는 코드에 기록이 안 남는다 (개발 중에 그냥 고치니까).

교란 변수: 시간이 지나면 팀이 성숙하고, 아키텍처가 안정되고, 경험이 쌓인다. 테스팅 효과만 분리하는 건 단일 팀의 git 히스토리로는 불가능하다.

구간 자의성: "테스트 도입 전/후"의 경계를 어디에 긋느냐에 따라 결과가 달라진다. 이 자의성 자체가 통계적 약점.

그래서 테스팅 고수들은 어떻게 하는가

테스팅 효과를 정량화할 수 있는 사람들은 대부분 환경이 다르다:

• QA/SDET 전문 직군: Jira 같은 버그 트래커에서 "Bug" 라벨 티켓 수를 관리하는 프로세스가 갖춰져 있음
• 대기업 플랫폼 엔지니어: "CI 실행 시간 45분 → 12분", "flaky test 15% → 2%" 같은 테스트 인프라 성능 지표
• 코드 커버리지: "30% → 80%"처럼 쓰지만, 이건 이미 업계에서 의미 없는 지표로 인식되고 있음

정량화할 수 있는 조직들은 대부분 환경이 다르다. 버그 트래커에서 티켓 수를 세거나, CI 실행 시간이나 flaky test 비율 같은 테스트 인프라 성능 지표를 쓴다. 측정할 수 있는 인프라가 이미 갖춰져 있는 것이다.

현재: 불완전하지만 측정한다

지금 우리 팀에는 버그 트래커도 없고, QA 프로세스도 없고, 테스트도 내가 도입하기 전까지 전무했다. 완벽한 측정 환경이 갖춰질 때까지 기다렸으면 아무것도 하지 못했을 것이다.

그래서 현재는 git에서 뽑을 수 있는 수준의 숫자를 쓰고 있다. 리팩토링 커밋 비율 증가, fix 커밋 비율 감소 같은 것들.

# 월별 커밋 타입 분포 (본인 커밋만)
git log main --author='seho\|Seho' --format='%ad|%s' --date=format:'%Y-%m' \
  | awk -F'|' '{
      month=$1; msg=tolower($2);
      total[month]++;
      if (msg ~ /^refactor/) ref[month]++;
      if (msg ~ /^fix/) fix[month]++;
      if (msg ~ /^feat/) feat[month]++;
    } END {
      for (m in total) printf "%s total=%d ref=%d(%.0f%%) fix=%d(%.0f%%) feat=%d\n",
        m, total[m], ref[m], ref[m]/total[m]*100, fix[m], fix[m]/total[m]*100, feat[m]
    }' | sort

# 테스트 파일 추가 이력 (누적 추적용)
git log main --author='seho\|Seho' --diff-filter=A --format='%ad' --date=format:'%Y-%m' \
  -- '*.spec.ts' '*.test.ts' | sort | uniq -c

# 전후 6개월 비교: 도입 직전(2024-11~2025-04) vs 직후(2025-05~2025-10)
# 위 커맨드 결과에서 해당 월만 합산

위에서 장황하게 썼듯이 이 숫자들이 엄밀하지 않다는 건 안다. 선택 편향이 있고, 교란 변수를 통제하지 못하고, 구간을 어떻게 잡느냐에 따라 결과가 달라진다.

그래도 측정 방법과 한계를 같이 기록하면서 쓴다. 숫자만 놓지 않고, "이 테스트 인프라 덕분에 v1→v2 아키텍처 전환을 안전하게 했다", "주 단위 기획 변경에도 기존 기능이 깨지지 않았다" 같은 맥락을 붙인다. 불완전한 숫자 + 맥락이, 아무것도 측정하지 않는 것보다는 낫다.

앞으로: 제대로 측정하기 위한 환경 만들기

git 히스토리만으로는 한계가 명확하다. 테스팅 효과를 제대로 트래킹하려면 측정 인프라 자체를 만들어야 한다.

1. 버그 트래킹 체계 도입

리니어에 "Bug" 라벨을 운영하고, 버그 발견 시점(개발 중 / QA / 프로덕션)을 태깅한다. 이것만 있어도 "테스트가 잡은 버그 vs 프로덕션까지 나간 버그" 비율을 정확하게 산출할 수 있다. 가장 직관적이고 대표들에게 설명하기도 쉬운 지표가 된다. => 이것도 만약 테케 만들면서 개발하거나 TDD를 쓰면 애매해져서 좀 어려움. 실무에서 솔직히 도입하기는 어려워보임.

2. CI 파이프라인에 자동 리포트 붙이기

배포마다 테스트 실행 결과를 자동 기록한다. 테스트 수, 통과율, 실행 시간, 실패 원인 분류를 시계열로 쌓으면 "테스트가 배포 전에 잡아낸 결함 수"를 정확하게 보여줄 수 있다. flaky test 비율 추이도 테스트 인프라 건강도의 좋은 지표가 된다. => 이건 확실히 좋다. 지금 git push husky에 test 달아두었다가 없앴었고 지금은 CI에 아예 안붙어있는데, 예에에에전부터 염원했던 actions 같은곳에 붙이면 제일 좋을 것 같긴하다.

3. 배포 후 인시던트 연결

프로덕션 이슈가 발생했을 때 해당 배포와 연결하고, "테스트가 있었던 모듈인가 / 없었던 모듈인가"를 기록한다. 이 데이터가 몇 달만 쌓이면 테스트 커버리지와 프로덕션 장애 간의 상관관계를 볼 수 있다. => 이런건 뭐 llm 같은걸로도 할 수 있어보인다. 이거 말고 더 복잡한 것도 요즘은 llm-as-a-judge로 해결 가능하긴할듯하다.

4. 비즈니스 임팩트 연결

"프로덕션 버그로 인한 고객 이탈 / CS 건수 / 다운타임"을 추적하고, 이를 테스트 도입 전후로 비교한다. 개발 지표가 아닌 비즈니스 지표로 전환해야 대표님이나 동료분들에게 와닿는다.

결국 "테스팅이 비즈니스에 도움이 되는가?"라는 질문에 답하려면, 측정할 수 있는 구조를 먼저 만들어야 한다. 지금까지의 삽질은 그 구조 없이 사후적으로 증명하려고 해서 실패한 것이다. 다음 단계는 코드를 짜는 게 아니라, 측정 파이프라인을 짜는 것이다. 2Q에는 지표 트래킹을 위한 발판 마련에 많은 공을 들여야할 것 같다.