소프트웨어 개발팀에서 '기술 부채(technical debt)'라고 부르는 문제의 대부분은 사실 미래 비용을 알고 의도적으로 선택한 부채가 아니라, 미숙한 작업, 취향 차이, 또는 예상하지 못한 복잡성이 뒤섞인 '엉망인 상태(mess)'에 가깝다는 주장이 나왔습니다. 금융 부채와 달리 기술적 결정의 비용은 대개 나중에 드러나므로, 부채라는 은유가 전제하는 비용 예측 가능성과 맞지 않는다는 것입니다.
이 주장의 핵심은 금융 부채가 계약 시점에 규모, 비용, 조건을 명확히 알 수 있는 것과 달리, 기술적 결정은 그 비용과 상환 작업을 처음부터 이해하기 어렵다는 점입니다. 예를 들어, 성능 개선을 나중에 할 계획으로 단순한 SQL 구조를 택하는 것은 의도적인 부채일 수 있지만, 느리고 불안정한 테스트처럼 개발 속도조차 높이지 못하는 문제는 기술 부족이나 부주의에 해당합니다. 또한, AWS 람다(Lambda) 기반 이벤트 주도 시스템처럼 확장성을 기대한 선택이 추적과 계측의 어려움으로 돌아오는 경우는 비용을 알고 진 빚이 아니라, 경험의 경계에서 발생한 예상 밖의 결과로 봐야 한다고 설명합니다.
이러한 관점은 '기술 부채'라는 용어가 비개발 직군과의 소통에서 오해를 불러일으킬 수 있다는 점을 강조합니다. 비개발자는 이를 개발자가 일을 제대로 하지 못했거나 이전 팀의 방식을 마음에 들어 하지 않을 때 쓰는 말로 받아들일 수 있기 때문입니다. 미리 알지 못했던 문제까지 기술 부채라고 부르면, 조건을 읽지 않고 빚을 낸 사람처럼 보여 진지하지 않은 인상을 줄 수 있습니다. 소프트웨어를 집이나 작업 공간처럼 지속적으로 청소, 정리, 재구성해야 하는 대상으로 본다면, 문제를 무책임한 차입으로 오해하지 않고 현재 필요한 유지보수로 다룰 수 있다는 제안입니다.
결국, 이 논의는 소프트웨어 개발의 본질을 '예측 불가능한 탐색'으로 이해하고, 그 과정에서 발생하는 문제들을 '예측 가능한 금융 부채'의 관점으로만 보지 않아야 한다는 메시지를 던집니다. 이는 개발팀 내부적으로 문제를 더 정확하게 진단하고, 비개발 직군과의 소통에서 불필요한 오해를 줄이며, 궁극적으로는 소프트웨어 프로젝트의 지속적인 유지보수와 개선에 대한 인식을 전환하는 데 중요한 의미를 가집니다.