요약

소스 수정이 필요한 경우 빠르게 대충 땜빵 코드 넣을 건가 ? 아니면 프레임웍 자체를 바꿀건가 ? 위 2가지 선택에서 발생하는 비용계산.

내용

우리에게 시스템에 추가해야 하는 기능이 있다고 치자. 이 일을 하는 데에는 두 가지 방법이 있다. 하나는 (물론 나중에 잘 가다듬을 생각을 하며) 좀 지저분하지만 빠르게 처리하는 방법이다. 다른 하나는 설계가 더 깔끔하지만, 준비 시간이 더 걸리는 방법이다.

기술 부채(Technical Debt)는 이 문제를 잘 이해하도록 워드 커닝햄(Ward Cunningham)에 의해 고안된 멋진 은유다. 이 은유에 의하면, 빠르지만 지저분한 방식으로 일하면, 회계에서 말하는 부채와 유사한 기술 부채로 압박받게 된다. 회계 부채와 같이, 기술 부채는 지저분하면서 빠른 방법을 사용했기 때문에 추가 개발 노력을 기울임으로써 이자를 내야 한다. 우리는 이 이자를 계속 내기로 선택할 수도 있고, 지저분하고 빠른 방식의 설계를 리팩토링으로 개선하여 원금을 갚을 수도 있다. 원금을 갚으려면 비용이 들지만, 앞으로 치를 이자가 줄어드는 이점이 있다.

출처

https://brunch.co.kr/@pubjinson/23