정의

현 시점에서 더 오래 소요될 수 있는 더 나은 접근방식을 사용하는 대신 쉬운(제한된) 솔루션을 채택함으로써 발생되는 추가적인 재작업의 비용을 반영하는 소프트웨어 개발의 한 관점이다.

• 긴급하게 스펙 및 요구사항 변경을 위해 임시로 넣은 코드
• 반복되는 일(배포/빌드 등)을 자동화하지 않음
• 더 이상 사용되지 않는 DB의 항목을 지우지 않음
• 더 좋은 해결책을 찾지 못한 개발 코드
• 사용 기술의 업데이트 되면서 레거시가 되어 버린 코드
• 등등...

---

기술 부채가 주는 악영향

• 기술 부채의 잘못된 결정들은 여전히 관리되어야 하고 기술 부채가 해결되지 않으면 더 이상 진전 할수 없는 경우가 존재한다.
• 기술 부채를 해결하는것이 더 혁신적인 피처에 집중할 수 있도록 미래에 할 재작업을 덜어 줄수 있다.
• 기술 부채는 전이되며 팀 전체에 악영향을 미친다.(내가 빚 졌지만 옆에 팀원이 갚는경우도 있다.)
• 기술 부채는 이자가 붙는다. 즉 시간이 지날수록 기술부채 해결에 더 많은 노력과 시간을 쏟아야 한다.

---

기술 부채가 무조건 나쁜것인가?

꼭 나쁜 것만은 아니다. 우리에게 돈을 빌려야 하는 이유가 있는 것처럼 기술 부채를 쌓으며 전진을 해야 하는 경우가 있다.
제 시간 내에 결과물을 전달해야 하는 경우 우리는 기술 부채를 활용하여 데드라인을 지키는게 좋을수도 있다. 스타트업에게 데드라인은 훨씬 더 가혹 한 경우가 많다.
기술 부채를 해결하기 위해 추가로 사용하는 일주일에 사업 기회가 사라져 버릴 수도 있고, 경쟁자가 같은 시도를 먼저 할 지도 모른다.

---

결론

기술 부채를 아예 없앨수는 없음을 인정하고 기술 부채를 이용할때는 이 부채로 인한 영향도를 생각하며 이용해야 한다.
결국 릴리즈 후에는 빠름은 사라지고 부채만 남는다. 라는 말처럼 기술 부채로 인한 릴리즈 후에는 갚아야 할 빚만이 남는다.

결론적으로 계획적으로 부채 상환의 기간을 일정을 계획한 다음에 기술부채를 이용하여야 한다.