팀과 코드베이스의 기술적 건강을 어떻게 측정하고 개선합니까?

Question

Accepted Answer

**기술적 건강**은 팀이 얼마나 지속 가능하게 전달할 수 있는가입니다, 코드 품질, 시스템 신뢰성, 딜리버리 velocity가 함께입니다. 측정하지 않는 것은 개선할 수 없지만, 목표는 *개선을 이끄는 통찰*이지 달성할 숫자가 절대 아닙니다. metric은 손전등이지 점수판이 아닙니다.

## 무엇을 측정할 것인가

```text
DELIVERY(DORA metric — 잘 연구되고 균형 잡힌):
  - Deployment frequency        - Lead time for changes
  - Change failure rate         - Time to restore service

QUALITY / RELIABILITY:
  - Production 인시던트 비율 & 심각도
  - Test coverage 추세(허영 %가 아니라 방향)
  - Escaped-bug 비율

TEAM / FLOW:
  - Cycle time, time-in-review(느린 리뷰 = 숨은 bottleneck)
  - 반복되는 고통점(팀을 survey하라 — 그들이 안다)
```

## DORA를 균형 있게 써라

네 가지 DORA metric은 속도와 안정성을 *균형* 잡기에 가치가 있습니다, 다른 것을 해치지 않고는 하나를 게임할 수 없습니다. 높은 deploy 빈도에 높은 failure rate는 승리가 아니라 위험 신호입니다. 단일 숫자가 아니라 세트를 추적하십시오.

## 구체적인 예시

lead time for changes가 슬금슬금 올라갑니다. 파고들어 PR이 며칠씩 리뷰에 머문다는 것을 발견합니다. metric이 직감으로는 결코 발견 못 했을 진짜 bottleneck, 즉 리뷰 프로세스 문제를 가리켰습니다. 프로세스를 고치면 metric은 *부수 효과*로 개선됩니다.

## 큰 함정: 게임하기

metric이 목표가 되는 순간, 사람들은 결과가 아니라 숫자를 최적화합니다(Goodhart's Law). coverage 목표는 쓸모없는 test를 낳고, velocity 목표는 부풀려진 추정을 낳습니다. metric을 문제를 *찾는* 데 쓴 다음 사람과 대화하십시오, 결코 순위를 매기거나 처벌하는 데 쓰지 마십시오.

## 왜 중요한가

신호가 없으면 기술적 건강은 보이지 않게 악화되어, 팀이 알 수 없이 느려지고 아무도 이유를 말하지 못할 때까지 갑니다.

좋은 측정은 보이지 않는 것을 보이게 만들어, 가치 있는 곳에 투자하고, 그렇게 할 때 영향을 입증하게 합니다.