technical debt를 어떻게 식별하고, 우선순위를 정하며, 상환합니까?

Question

Accepted Answer

**technical debt**는 코드의 현재 상태와 마땅히 그래야 할 상태 사이의 간극으로, 더 빨리 나아가기 위해(의도적이든 아니든) 떠안은 것입니다. 일부 부채는 괜찮습니다. 일은 그것을 제거하는 것이 아니라 관리하는 것입니다. 핵심은 실제로 *아픈* 부채에 우선순위를 두는 것입니다.

## 짜증이 아니라 영향으로 우선순위를 정하라

```text
각 부채에 대해 물어라:
  - 얼마나 자주 우리를 느리게 하거나 버그를 일으키는가?(빈도)
  - 터질 때 얼마나 나쁜가?(심각도)
  - 고치는 것이 얼마나 위험하고 비싼가?(비용)

높은 빈도 + 높은 심각도 + 낮은 비용 → 지금 고친다
낮은 빈도 + 낮은 심각도 → 그냥 둔다, 문서화한다
```

## 구체적인 예시

릴리스마다 깨지고 매주 팀을 막는 취약한 모듈은 고칠 가치가 있습니다. 보기 흉하지만 안정적이고 아무도 건드리지 않는 유틸리티는 *그렇지 않습니다*, 당신을 거슬리게 하더라도요. 그것을 refactoring하는 것은 가치가 아니라 허영입니다.

## 작업 자금을 마련하는 법

순수한 "부채 스프린트"는 좀처럼 승인되지 않습니다. 더 나은 전술:

```text
✓ 각 스프린트의 약 10-20%를 부채에 지속적으로 배정
✓ 관련 기능 작업 안에서 부채를 상환("boy scout rule")
✓ 부채를 비즈니스 고통과 연결: "기능 X가 3주 걸린 이유가 이것"
```

## 왜 중요한가

관리되지 않은 부채는 복리로 쌓입니다. 팀이 거의 출시할 수 없을 때까지 velocity가 조용히 떨어집니다.

그러나 모든 불완전함을 쫓는 것은 중요하지 않은 부채에 시간을 낭비합니다.

TL의 가치는 그 차이를 알고, 엔지니어링 용어가 아니라 *비즈니스* 용어로 리더십에 설득하는 것입니다.