Technical Debt

Technical Debt

 

Technical Debt는 직역하자면 "기술적인 빚"이다. 은유적인 표현으로 개발단계에서 제대로 개발을 해놓지 않게 되면 그게 빚이 되고 나중에 이자가 붙어서 더 많은 일을 해야 한다는 것이다.

쉽게 예를 들어서, 개발 단계에서 문서화를 제대로 해놓지 않은 경우, 개발이 끝난 후, 기능 개선이나 기타 수정을 하려고 했을 때 문서가 없기 때문에 코드를 분석하고 구조를 다시 분석하는 작업을 한 후에 다시 개발을 해야 함으로, 더 많은 노력이 든다. 즉 문서화를 해놓지 않은 것이 "빚" 이 되는 것이다.

Technical Debt가 생기는 원인은 여러 가지를 들 수 있는데, 주요한 원인은 다음과 같다.

 

①   비지니스 조직으로 부터의 무리한 압박 : 시장 출시를 맞추기 위해서 무리한 일정이나 무리하게 적은 예산으로 진행한 경우, 소프트웨어의 품질에 문제가 생기고, 결국 나중에 이 부분을 다시 보강해야 한다.

②   부정확한 요구 사항이나 잦은 변경 : 요구 사항이 정확하지 않게 정의 되면 시스템의 기능이 제대로 개발되지 않고 프로젝트 후반에 집중되는 경향이 있으며, 이는 심각한 일정과 품질 문제로 연결 된다.

③   잘못된 의사 결정 프로세스 : 비지니스 쪽에서 일정 변경이나 요구 사항 변경에 대한 implication (영향도)를 인지하지 못하고, 일정이나 비용등에 없이 변경을 하면 결국 문제가 발생하고 Technical debt의 원인이 된다. 이는 잘못된 의사 결정 프로세스에서 기인 한다.

④   부족한 협업 : 팀간의 협업 부족으로 서로 정보가 공유되지 않거나 정보가 오역되는 경우

⑤   부족한 테스팅 : 테스팅의 부족으로 인하여 소프트웨어의 품질이 심각하게 저하되는 경우

⑥   부족한 문서화 : 문서화의 부족으로 향후 참고할 자료가 없는 경우

⑦   Refactoring 지연 : Refactoring을 미루다가, 소프트웨어 품질이 저하된 경우

⑧   낮은 수준의 아키텍쳐 설계 : 아키텍쳐 설계가 유연하지 않아서 향후 요구 사항에 대한 반영이 어려운 경우. 또는 용량이나 성능에 대한 부분이 충분히 고려되지 않아서 향후 용량 초과시 문제가 되는 경우

 

요약하자면, 개발단계에서 제대로 개발을 하지 않으면, 그 부분은 빚이 되고, 그 빚은 빠른 시일내에 처리하지 않으면 이자가 붙어서 나중에 그 빚을 갚아야할 시기에 더 많은 노력을 들이게 된다.

Technical debt에 대해서 오해하지 말아야 하는 점은 Technical debt가 없는 것이 좋은 프로젝트가 아니다. 실제 사업에서도 그렇듯이 적정 비율을 부채를 유지하면서 그 비용을 다른 곳에 투자 하는 것이 오히려 많은 이익을 낼 수 있다. 소프트웨어 개발에서도 Technical debt를 발생시키면서 남는 잉여 리소스를 다른 곳에 투자함으로써 좋은 효과를 낼 수 있는다. 중요한 것은 이 Technical debt의 비율을 어느 정도로 유지할 것이냐 이다.

이러한 Technical debt는 금융 부채와는 다른게 수치화가 어려운데, 근래에 이를 수치화 하는 노력들이 이루어 지고 있다. 자세한 정보들은 http://www.ontechnicaldebt.com/ 를 참고해보기 바란다.

 

참고 : http://en.wikipedia.org/wiki/Technical_debt

빚이 있으면 반대로 투자도 있다. 투자는 아키텍쳐이다. 아키텍쳐는 소프트웨어의 기능적인 요건을 구성하기 보다는 주로 비 기능적인 요소를 충족하기 위해서 디자인 된다.

고가용 아키텍쳐, 분산 아키텍쳐, 대용량 아키텍쳐, 서비스 지향 아키텍쳐 등 모든 아키텍쳐 사상은 어떤 기능을 구현하기 위해서 보다는 대부분 비기능적인 용량이나 재 사용성등을 위해서 설계 된다.

투자 역시 자원을 사용하는 행위이다. 즉 자원을 과 사용하면 다른 곳에 쓸 자원이 없어진다.

아키텍쳐와 Technical debt 모두 밸런스가 중요하다.

 

Technical debt에 대해서 공부하던 중에 재미있는 그림을 하나 찾았는데,

http://www.andrejkoelewijn.com/blog/2010/11/25/lac2010-technical-debt/

Technical debt와, Architecture 그리고 Feature와 Bug에 대한 관계를 설명해놓은 그림이다.

Positive한 value가 구현화 되서 시각화 되는 것이 Feature, Negative한 value구 구체화 되서 시각화 되는 것이 Bug이다 이 둘은 쉽게 인식이 가능하다.

Technical debt와 Architecture도 각각 Negative한 value와 Positive한 value에서 기인하지만, 둘다 시각화나 수치화하기가 어렵다.

그나마 Architecture의 경우에 비기능 요구 사항이라는 이름으로 관리되고, 문제가 있을 경우, 시스템 운영에 영향을 주기 때문에 어느정도 관리가 되지만, Technical debt는 품질에 영향을 주기는 하지만, (스파게티 코드등), 시스템의 작동에 직접적인 문제를 주지 않기 때문에 그간 관리가 잘 되지 않았다. (보통 개발자만 밤세면 된다.) 하지만 소프트웨어의 복잡도가 올라가고 대규모 협업이 필요해지면서, 소프트웨어 품질 문제가 발생하게 되었고, 이에 대한 문제가 Feature,Architecture, Bug 들로 설명이 되지 않고 다른 요인에 있다고 해서 새로운 정의가 필요하였고, 그것이 Technical debt로 표현되었다.

 

참고 : http://en.wikipedia.org/wiki/Technical_debt

재미있는 그림 하나 발견 http://www.andrejkoelewijn.com/blog/2010/11/25/lac2010-technical-debt/