WardCunningham이 WyCash Portfolio Management System을 만들면서 고안한 용어.
Ward Explains Debt Metaphor
https://wiki.c2.com/?WardExplainsDebtMetaphor 에 그 원래의 의도가 설명되어 있다.
아래는 위 페이지의 번역.
은유
조지 레이코프와 마크 존슨의 MetaphorWeLiveBy를 읽은 후, 은유가 우리의 사고 방식을 어떻게 영향을 미치는지에 관심을 가지게 되었습니다. 중요한 아이디어는 우리가 언어에 들어온 은유로 비유를 통해 추론한다는 것입니다.
부채
WyCash 제품의 리팩토링을 설명하기 위해 부채 은유를 만들었습니다. 이 제품은 Digitalk Smalltalk로 개발된 초기 제품이었으며, 시간이 지남에 따라 애플리케이션에 대한 학습을 축적하기 위해 프로그램을 수정하여 마치 처음부터 제대로 알고 있었던 것처럼, 그리고 Smalltalk에서 쉽게 할 수 있었던 것처럼 보이게 하는 것이 중요했습니다. 제가 상사에게 한 설명은 재무 소프트웨어에 대한 재무적 비유인 "부채 은유"였습니다. 이는 우리가 재무 객체에 대해 이해하는 바에 맞게 프로그램을 정렬하지 못한다면, 우리는 끊임없이 그 불일치에 걸려 넘어질 것이고 이는 마치 대출의 이자를 지불하는 것과 같다는 의미였습니다.
속도
빌린 돈으로 본래보다 더 빨리 일을 진행할 수 있지만, 그 돈을 갚기 전까지는 이자를 지불해야 합니다. 저는 돈을 빌리는 것이 좋은 생각이라고 생각했고, 소프트웨어를 재빨리 출시하여 경험을 쌓는 것도 좋은 아이디어라고 생각했습니다. 하지만 또한, 결국 소프트웨어에 대해 배우면서 그 대출을 상환하기 위해 프로그램을 리팩토링할 것이라는 점도 알고 있었습니다.
부담
사람들이 소프트웨어를 서둘러(rush) 출시하고 배움들을 얻지만, 그렇게 배운 부분 들을 프로그램에 다시 반영하지 않는 사례가 많았던 것 같습니다. 이는 부채를 빌리고 갚을 필요가 없다고 생각하는 것과 유사합니다. 물론, 만약 당신이 그렇다면, 예를 들어 신용카드를 사용하게 되면 결국 모든 소득이 이자로 가고 구매력은 제로가 됩니다. 마찬가지로, 오랜 시간 동안 기능만 추가하며 프로그램을 개발하고, 그 기능에 대한 이해를 반영하여 재조직(reorganizing)하지 않는다면, 결국 그 프로그램은 아무런 이해를 담고 있지 않게 되어 모든 작업 노력들이 점점 더 오래 걸리게 됩니다. 즉, 이자는 총체적입니다 -- 당신은 전혀 진전을 이루지 못할 것입니다.
민첩성
많은 블로거들이 부채 은유를 설명하면서 그것을 나중에 잘하기 위한 의도로 코드를 잘못 작성하는 것과 혼동한다고 생각합니다. 저는 결코 코드를 잘못 쓰는 것에 찬성하지 않지만, 현재 문제에 대한 이해를 반영하는 코드를 작성하는 것에는 찬성합니다. 비록 그 이해가 부분적이라도 말이죠.
소프트웨어를 완전히 이해하지 못하는 상태에서 그렇게 부채를 지고 싶다면, 그 소프트웨어가 당신의 이해를 최대한 반영하도록 만드는 것이 현명합니다. 그렇게 하면 리팩토링할 때, 당신이 썼던 코드를 이해하기 쉽고 현재의 생각으로 리팩토링하기가 수월해집니다.
즉, 전체 부채 은유, 즉 부채를 갚을수 있는 능력, 그리고 부채 은유를 당신의 유리한 방향으로 작용하게 만들기 위해서는 문제를 이해하게 되면서 언제든지 리팩토링할 수 있도록 충분히 깔끔한 코드를 작성하는 것에 달려 있습니다.
이것이 좋은 방법론이라고 생각합니다. 이는 ExtremeProgramming의 핵심입니다. 부채 은유는 ExtremeProgramming이 작동하는 이유를 설명하는 여러 가지 설명 중 하나입니다.