•
워드 커닝햄이 처음 사용한 용어로 소프트웨어의 수준에 따라 운영 단계에서 쏟아야 하는 노력이 달라진다는 의미
◦
개발자가 코딩 규칙을 지키지 않고 자신만의 방식으로 개발을 해도 작동은 함
◦
하지만 이런 경우 운영과정에서 유지보수에 더 큰 비용이 발생하는데 정상적인 소프트웨어라면 들지 않았을 비용이 추가로 발생하는 셈으로 금융 부채가 있으면 이자를 내야 하듯, 소프트웨어에 문제가 있으면 추가로 노력이 든다는 것을 은유한 개념
마틴 파울러의 기술 부채 사분면
•
소프트웨어는 대부분 기술 부채를 갖고 있다. 대부분의 기업과 조직의 소프트웨어 에산은 개발보다 유지보수 분야가 더 큼
•
기술 부채는 활용하기에 따라 애자일 소프트웨어 개발의 촉매 역할을 하기도 하지만 관리하지 않고 방치한다면 다음과 같은 문제들이 발생
1.
유지보수 시간이 오래 걸린다. ⇒ 오랜 기간 변경으로 인해 스파게티 코드가 되어 비즈니스 요구사항 반영이 어려워짐
2.
유지보수 비용이 증가한다. ⇒ 오랫동안 시스템을 담당하고 있는 사람 또는 조직이 아니면 다룰 수 없어짐
3.
비즈니스 경쟁력을 해친다. ⇒ 거대한 블랙박스를 다루고 있다는 생각에 새로운 시도를 할 엄두를 내지 못함
4.
기업 파산으로 이어질 수 있다. ⇒ 기술 부채 규모가 일정 수준을 넘어서면 더 이상 기술 부채를 해결할 수 없는 수준이 됨
애자일과 기술 부채
•
디지털 시대는 개념의 빠른 형상화를 필요로 함, 비즈니스 요구사항을 확정하고 소프트웨어를 개발하는 것이 아닌, 소프트웨어가 모습을 갖추며 비즈니스 방식도 결정되는 것
•
빠르고 빈번한 소프트웨어의 출시가 당연한 것으로 받아들여지고 있는 이유로 소프트웨어를 빠르게 출시한다는 것은 Time to Opportunity를 줄일 수 있다는 효과가 있음
•
빠른 개발의 효과는 오래가지 않음, 몇 일이 지나면 소프트웨어의 품질 수준이 중요하게 되는데, 낮은 품질의 소프트웨어와 높은 품질의 소프트웨어와의 활용 효과와 도입 비용 차이는 점차 벌어지게 됨
•
빠른 출시를 위해 품질을 희생한다면 이후엔 그 비용을 지불해야한다. 통상 소프트웨어 운영 기간은 개발 기간의 열 배 이상이고 이 기간동안 희생된 품질로 인한 높은 유지보수 비용을 감당해야 함
•
애자일 개발을 위해 ‘지저분한 코드’를 허용하는 것은 필요하지만 애자일 개발 이후에는 리팩토링을 통한 코드 클리닝을 해야 함
