테크 부채 triage 프레임워크 만들기(Build a technical debt triage framework)

테크 부채에는 이자율이 있다, 대출처럼 다뤄라

"Tech debt sprint"라는 프레임은 대개 지는 프레임입니다. 허락을 구하는 구조이기 때문에, 분기마다 계속 거절당합니다. Atlassian의 agile estimation 글과 The Pragmatic Engineer의 연구는 모두 테크 부채를 금융 부채처럼 다뤄야 한다고 말합니다. 모든 부채에는 이자율(그 영역의 미래 shipping을 얼마나 느리게 만드는가)과 원금(지금 고치는 데 드는 일회성 비용)이 있습니다. 특히 분기마다 이자율이 커지는 compounding debt가 가장 위험합니다.

이 프롬프트의 작동 방식

이 프롬프트는 interest rate, frequency, compounding 여부가 포함된 debt inventory를 만든 뒤, 항목별 분기 비용을 계산해 팀이 "느낌"이 아니라 ROI로 상환 우선순위를 주장할 수 있게 합니다. 상시 20% allocation rule은 실패하기 쉬운 "debt sprint" 패턴을 대체하고, 고이자 항목에 한해 30%까지 올리는 예외 규칙은 분기마다 허락을 다시 구하지 않고도 유연하게 대응할 수 있게 합니다.

언제 사용할까

• 코드베이스의 특정 영역에서 feature velocity가 감소하고 있을 때
• 시스템 복잡도는 크게 늘지 않았는데 on-call 시간이 계속 커질 때
• "debt sprint" 제안이 리더십 리뷰에 막혀 있을 때
• 플랫폼 리라이트 여부를 논쟁 중이고, 부채 수치가 판단에 도움이 될 때
• 신규 엔지니어가 생산성을 내기까지 3주 이상 걸릴 때

흔한 함정

• debt sprint 허락을 구하는 것. 허락은 거절됩니다. 상환을 상시 allocation 안에 녹이세요.
• 이자가 낮은 부채부터 갚는 것. 이런 부채는 정리할 때 기분은 좋지만 delivery velocity를 바꾸지 못합니다.
• 모든 부채를 똑같이 취급하는 것. Compounding debt는 평평한 debt보다 범주적으로 더 나쁩니다. 그 차이를 반영해 우선순위를 매기세요.

참고 자료

• Agile Estimation — Atlassian
• The Pragmatic Engineer — Gergely Orosz
• The Pragmatic Engineer Newsletter — Gergely Orosz
• Embracing Agile — Harvard Business Review