기술 부채를 부정적 결과로만 보지 않고, 지식의 축적이 어떻게 부채를 발생시키는지, 그리고 그것을 투자 기회로 커뮤니케이션하고 우선순위를 정하는 관점에 대해 논한다.
이제 소프트웨어 업계에서 널리 쓰이는 기술 부채라는 용어는, 지식을 얻기 위해 소프트웨어를 빠르게 작성하는 의도적 과정을 설명하기 위해 만들어졌고, 그 후에 그렇게 얻은 지식을 사용해 소프트웨어를 개선해야 한다는 점을 내포한다.
사람들이 기술 부채를 오로지 부정적이거나 나쁜 결정의 결과로만 말할 때, 이 관점은 여전히 유용하다. 마틴 파울러의 기술 부채 4분면은 그런 오해에 대한 좋은 해독제다.
이 관점에서 보면, 지식을 얻게 되는 순간 기술 부채는 언제든지, 마치 갑자기 어디서든 나타날 수 있다.
더 나은 방법을 발견하면, 코드베이스에 박혀 있는 예전 방식은 이제 "부채"가 된다:
이 "더 나은 방법"은 다른 언어, 라이브러리, 도구, 패턴일 수 있다. 어떤 경우에는 그 더 나은 방법이 최근에야 발명되었을 수도 있다. 개인적인 발견일 수도, 업계 전반의 흐름일 수도 있다. 현재 프로젝트를 실제로 수행하는 과정에서 얻은 지식일 수도 있고(이것이 워드 커닝엄이 이 용어를 사용한 맥락이었다), 다른 경로에서 얻었을 수도 있다. 그러나 결론은 같다 — 이전보다 더 많이 알게 되었고, 이제 부채가 생겼다.
문제는 이것이 그럴듯하게 들리지 않는다는 점이다. 무언가를 배웠더니 예전엔 없던 문제가 생겼다. "부채를 발견했다"는 말을 좋게 포장하기가 어렵다.
하지만 다른 각도에서 보면, 이 관점은 다른 사람들과 소통하고 왜 기술 부채를 다뤄야 하는지 설명할 때 사용할 수 있는 다른 언어를 제공해 준다. "우리에겐 부채가 있다"고 말하기보다는, 우리가 얻은 지식을 "기회"로 구성할 수 있다. 그 기회를 잡지 못하는 것은 기회비용이 된다.
"기술 부채의 더미"는 본질적으로 지식의 더미다 — 지금 코드에서 나쁘다고 여기는 모든 것들은 소프트웨어를 더 잘 만드는 법에 관해 우리가 배운 것을 나타낸다. 현재와 이상 사이의 간극은 과거에 우리가 알던 것과 지금 우리가 아는 것 사이의 간극이다.
그리고 그 코드를 고치는 일은 "갚아야 할 빚"이 아니라, 수익을 거둘 투자 기회다. 원한다면 그 기회를 거부할 수 있겠지만, 그것은 피땀 흘려 얻은 지식을 비극적으로 낭비하는 일 — 곧 학습에 이미 들였던 투자까지 낭비하는 일 — 이고, 결국 돈을 잃고, 지식을 최대한 활용하는 경쟁자들에게 뒤처지게 될 것이다.
마지막으로, 이를 지식의 관점으로 표현하는 것이, 마음에 들지 않는 모든 것을 "기술 부채"라고 부르는 성급한 본능을 길들이는 데도 도움이 된다고 생각한다. 우리는 정말로 "이제 안다"고, 현재의 코드가 열등하다고 말할 수 있는가? 코드를 고치는 것이 정말 "내 지식에 투자하는" 일인가? 단지 직감이거나 개인적 취향, 혹은 최신 유행에 불과하다면, 불필요한 리라이트의 충동을 억누르면서 동시에 더 편안한 마음을 가질 수도 있을 것이다.
이곳은 개인 블로그이며, 여기의 의견이 내 고객/고용주나 교회의 견해를 반드시 반영하는 것은 아닙니다.
