경영진은 "tech debt"에 예산을 주지 않습니다 — 그들은 **결과(outcomes)**에 예산을 줍니다. 당신의 일은 내부 엔지니어링의 고통을 그들이 이미 신경 쓰는 언어로 번역하는 것입니다: 리스크, 속도, 비용, 장애. 내부가 아니라 결과를 말하세요.
| 엔지니어링 현실 | 비즈니스 프레이밍 |
|---|
| 잘 깨지는 legacy 모듈 | 장애 리스크, outage 노출 |
| 느린 build/deploy | 속도 손실, 느린 time-to-market |
| test coverage 없음 | 높은 결함률, 고객 이탈 |
| 수동 운영 잡일 | 낭비되는 인력, 확장 한계 |
모호한 불평은 지고, 숫자는 이깁니다. "이 영역이 우리 장애의 약 30%를 일으키고 모든 feature에 이틀을 더한다"는 예산을 따낼 수 있습니다. 경영진이 이미 가진 목표에 연결하세요 — 신뢰성 목표, 출시 마감, 비용 한도.
비즈니스 논리를 만들지 못하는 엔지니어는 부채가 위기를 촉발할 때까지 복리로 불어나는 것을 지켜볼 뿐입니다 — 그리고 수정은 압박 속에서, 가능한 최악의 조건에서 이뤄집니다. 투자를 결과로 프레이밍하는 tech lead는 문제가 터지기 전에 고칠 수 있는 신뢰와 예산을 얻습니다. 이것이 항상 불을 끄는 팀과 꾸준히 빨라지는 팀의 차이입니다.