Technical Debt (기술부채)

어디까지 네모난 바퀴로 갈까?

• 유닛 테스트를 작성하지 않는다.
• 더 이상 사용되지 않는 DB의 항목을 지우지 않는다.
• 반복되는 일(배포/빌드 등)을 자동화하지 않는다.
• 긴급하게 스펙을 변경한다.

• 빚을 지고 있으면 마음이 불편하다. 특히 빚을 질 때 제일 불편하다. 하지만 그 상황이 지속되면 빚을 지고 있는 상황에 익숙해진다.
• 빌리는 것은 상대적으로 쉽지만 갚는 것은 어렵다. 게다가 한 번에 갚는 것은 불가능에 가깝다. 지금 당장 문서를 쓰지 않고, 테스트를 작성하지 않는 것은 쉽지만 나중에 그것을 회복하기는 어렵다.
• 이자가 붙는다. 지금 배포 자동화를 해두지 않으면 배포를 할 때마다 시간을 쓰게 된다. 그 시간이 이자다.
• 부도가 나는 경우도 있다. 더 이상 복구 불가능한 상태가 되어 프로젝트가 폐기되거나 아예 처음부터 다시 만들게 된다.

• 빚을 지는 사람과 갚아야 할 사람이 다를 수도 있다. 어떤 사람이 코드를 리팩터링 하지 않은 상태로 두면 그 부채는 다른 팀원이 갚을 수도 있고, 나의 후임이 갚아야 할 수도 있다.
• 갚아야 할 양이 정확히 예측되지 않는다. 돈을 빌리면 내가 어느 시점에 얼마를 갚아야 하는지 정확히 알 수 있지만 기술 부채는 끝까지 해결하지 않아도 별다른 문제가 되지 않을 수도 있고, 폭탄이 되어 프로젝트를 망칠 수도 있다.

• 기술 부채를 해결하는데 얼마나 노력이 드는가?
• 기술 부채의 해결로 얻어지는 가치는 무엇인가?
• 기술 부채를 쌓고, 비즈니스 문제를 풀었을 때 얻어지는 가치는 무엇인가? (보통 이 질문으로 바꾸는 것이 더 쉽다. 비즈니스 문제의 해결을 미뤘을 때 어떤 문제가 생기는가?)