기술 부채란?

기술 부채는 Ward Cunningham이 1992년도에 만든 표현이다. 오늘날 기술 부채 및 코드 부채는 개발 팀이 애플리케이션을 개발 시 빠른 코드를 작성하는 것을 선택할 때 발생한다. (일정에 쫓겨서 개발) 신속한 코드 전달은 프로젝트 완료일을 맞추는데 도움이 되고 이에 대한 기술 부채를 감내한다고 했을 때, 비지니스 관점에서는 문제가 없어 보일 순 있지만, 향후 부정적인 결과를 초래할 수 도 있다. 기술 부채를 발생시키기로 결정했다면 부정적인 결과가 생기는걸 고려해야 한다.

기술 부채는 처리하기가 복잡하고 특정 지표와 연결되어 있지 않다. 기술 부채를 해결하는데 필요한 정확한 자원을 추정하는 것도 쉬운 일은 아니다. 기술 부채는 어떤 영향을 미칠까?

개발자

개발자의 생산성에 영향을 미치고 개발 수명 주기에 대해 방해하는 기술적 요인을 가장 먼저 느끼게 된다. 기존 코드의 문제를 수정하는 것이 어렵고 기술 부채를 해결하는데 많은 시간을 쏟을 수 도 없는 실정이다. 결과적으로 개발자는 더 깨끗한 코드를 지니고 있는 조직에 합류하기를 원하고 너무 많은 기술 부채로 인해 사람들이 떠나갈 수 도 있다.

조직

기술 부채는 회사 전체에 영향을 미치기 시작한다. 신규 프로젝트와 기존 프로젝트를 수정하는 것이 악몽이 된다. 점점 시간이 지날 수록 기술 부채를 제거하는 것이 어렵게 된다.

기술 부채는 나쁜가?

금융 부채와 마찬가지로 기술 부채도 좋은 방법과 나쁜 방법으로 활용될 수 있다. 상황에 따라 기술 부채는 서비스 출시일을 충족하기위한 계산된 결과일 수 있다. 반면 애플리케이션을 업데이트할때 피할 수 없는 실수의 결과이기도 하다.

기술 부채의 원인은?

기술 부채에는 4가지 원인이 있다. 이를 기술 부채 사분면이라고 한다. 마틴파울러가 만든 4가지 기술 부채 사분면에는 무모함, 신중함, 부주의함이 포함되어 있다. 아래의 사분면에 기술 부채를 할당하면 문제에 대한 의도와 배경을 측정하는데 도움이 된다.

• Prudent and deliberate - 신속하게 개발하고 나중에 결과를 처리하기로 결정하면 신중하고 고의적인 부채가 발생한다. 이 유형의 부채는 제품의 지분이 상대적으로 낮고 빠른 개발의 이점이 위험보다 클 때 가장 일반적으로 사용된다.
• Reckless and deliberate - 최고의 코드를 생성하는 방법을 알고 있지만 그보다 빠른 개발을 우선시하는 것이 무모하고 고의적인 부채의 원인이다.
• rudent and inadvertent - 신중하고 부주의한 부채는 최상의 코드를 생성하려는 욕구가 있지만, 구현 후에 더 나은 솔루션을 찾을 때 발생한다.
• Reckless and inadvertent - 무모하고 부주의한 부채는 팀이 필요한 지식 없이 최고의 코드를 생성하려고 할 때 발생한다. 그리고 자신들이 저지르는 실수를 인지하지 못한다.

기술 부채의 유형

기술 부채는 두 가지 유형이 있다고 한다.

• 고의적 기술 부채
• 의도하지 않은 기술 부채

고의적 기술 부채

고의적 기술 부채는 조직이 미래보다는 현재를 위해 결정을 내릴 때 발생한다. 이 부채는 단기와 장기로 나뉜다. 예를 들어서 이전 부채를 상환하기 위해 발생한 것은 단기 부채이고, 더 큰 미래 부채를 방지하기 위해 발생한 것은 장기 부채이다.

• 단기 부채 - 기존 자원을 사용하는 등의 전략적 이유로 소극적으로 발생한다.
• 장기 부채 - 납기일 등의 전략적 이유로 선제적으로 발생한다.

발생한 유형에 따라 부채를 상환하는데 걸리는 시간은 달라지게 된다.

의도하지 않은 기술 부채

의도하지 않은 기술 부채는 이해 부족, 우발적 실수 또는 경우에 따라 잘못 작성된 코드로 인해 발생한다. 이런 상황이 발생하는 이유는 오류가 발생하기 쉬운 설계에 있다. 이는 피할 수 없는 실수를 저지른 비전략적 결과이다. 의도하지 않은 기술적 부채는 팀에서 고의로 발생시키지 않았기에 우발적인 것으로 간주할 수 있다. 대부분 프로젝트를 완료한 후에 실수를 깨닫게 된다.

기술 부채를 관리하는 방법

대출 받은 금융 부채를 점진적으로 상환하는 접근 방식을 기술 부채에도 적용할 수 있다. 개발팀의 꾸준한 노력이 필요하지만 전체적인 비용 절감에 유리하다. 애플리케이션 리팩토링을 미리 계획해야 한다. 이 접근 방식은 몇 년 동안 축적된 기술 부채를 줄이는데 도움이 된다. 팀 리더는 정기적으로 기술 부채를 해결하기 위해 시간을 할애해야 한다. 애플리케이션에 영향을 주지 않고 자주 변경되는 요구 사항을 수용하는데 도움이 된다.

결론

애플리케이션을 개발할 때 항상 부채를 피할 수 있는 것은 아니다. 의사 결정에서 코드 실수에 이르기까지 발생한 기술 부채가 향후 어떤 영향을 미치는지는 대부분 알고 있을 것이다. 기술 부채는 결국 비즈니스에 영향을 줄 수 있다. 따라서 기술 부채가 어떻게 축적되는지 파악하고 이를 통제하기 위한 것을 고려해야 한다.

References:

• https://dzone.com/articles/types-of-technical-debt-and-how-to-manage-them
• https://asana.com/resources/technical-debt?utm_campaign=NB–KO–EN–Catch-All–All-Device&utm_source=google&utm_medium=pd_cpc_nb&gclid=CjwKCAjw6MKXBhA5EiwANWLODINX1qI3BXoFZ9pqhgr2eJlZhEmh0PyxJxZ9LI-uMvHLBURFqs8ZsBoCxzgQAvD_BwE&gclsrc=aw.ds