소프트웨어 개발자 냇 베넷(Nat Bennett)은 지난 8월 14일 자신의 블로그 심플러 머신스(Simpler Machines)에 "기술 부채라 부르지 말고 그냥 엉망이라 부르자"는 글을 올렸다. 몇 달 전 부채 처리법을 다룬 글을 쓰다가 "사실 이 비유가 마음에 안 든다"는 대목을 통째로 들어냈던 경험이 이번 글의 출발점이다. 개발자끼리는 습관적으로 "기술 부채"라고 말하지만, 그 말을 들은 비개발자 동료는 대개 "일을 대충 했거나 이전 팀 방식이 마음에 안 든다는 뜻이겠거니" 하고 받아들인다고 그는 적었다.
베넷이 문제 삼는 지점은 "부채"라는 말이 실제 금융 부채의 성질을 함부로 빌려 온다는 데 있다. 기업에는 "적정 수준의 부채"라는 개념이 있고, 부채가 너무 적으면 오히려 더 비싼 자본에 의존하거나 성장 속도를 놓친다. 반면 금융 부채는 예측 가능하다. 얼마를 빌렸고 어떤 조건으로 언제 갚아야 하는지 계약서 한 장에 다 적혀 있다. 소프트웨어에서 "기술 부채"라고 불리는 것 대부분은 이 조건을 갖추지 못한다.
진짜 부채라고 부를 수 있는 경우는 무엇인가
베넷은 자신이 만든 서비스 스토리타임(StoryTime)의 SQL 쿼리를 예로 든다. 처음 쿼리를 짤 때는 성능보다 가독성을 우선해서, 화면 하나에 필요한 데이터를 쿼리 하나씩 따로 매핑했다. 이용자와 쿼리 수가 늘어나면 언젠가 이 호출들을 하나로 합쳐 페이지 로딩 성능을 개선해야 한다는 사실을 그는 그 순간부터 알고 있었다. 나중에 갚아야 할 비용을 미리 알고 지금의 편의를 산 선택이었다는 점에서, 이 사례는 그가 인정하는 몇 안 되는 "진짜 부채"에 해당한다.
반대로 그가 "엉망"이라 부르는 문제 대부분은 이 조건, 즉 선택 당시 비용을 알고 있었는지를 통과하지 못한다. 베넷은 셋으로 나눠 설명한다. 첫째는 미숙하거나 거친 작업이다. 느리고 불안정한 테스트가 대표 사례로, 테스트를 잘 짤 줄 알면 애초에 테스트 있는 코드가 없는 코드보다 어렵지 않고 속도 이득도 바로 나타난다. 몰라서 그렇게 만든 것을 "빚"이라 부르는 것은 맞지 않는다는 것이다. 둘째는 취향 차이다. 그는 한 팀이 컨테이너 이미지를 여러 개 쓰는 것을 "부채"로 규정하고 몇 주를 들여 하나로 합쳤다가, 1년 뒤 새 인원이 합류하자 이번엔 하나로 뭉친 이미지가 "부채"라며 다시 여러 개로 쪼갠 사례를 든다. 두 결정 다 틀린 건 아니지만, "이 방식이 내 취향과 다른 트레이드오프를 가졌다"는 말을 "빚"으로 바꿔 부를 이유는 없다.
세 번째 갈래, 이벤트 기반 아키텍처는 왜 "폭발"하나
베넷이 가장 힘주어 말하는 셋째 유형은 결정 당시에는 비용을 전혀 예측하지 못했던 경우다. 그는 컨설팅 현장에서 반복해서 본 사례로 AWS 람다(Lambda) 기반 이벤트 주도 시스템을 든다. 팀은 대개 요청 기반 모놀리식 구조에서 스케일링 문제로 고생한 경험이 있고, 이벤트 기반이 훨씬 낫다는 글을 읽은 뒤 다음 기회에 전면적으로 이벤트 기반을 택한다. 문제는 그 다음이다. 특정 고객 행동이 시스템 어느 지점에서 실패하는지 추적하기가 매우 어렵고, 이런 구조를 처음 만들어 본 팀이라 애초에 제대로 계측하는 법도 몰랐다. 베넷이 투입될 즈음이면 아무도 시스템 작동 방식을 이해하지 못하는 상태이고, 게다가 이 시스템이 처리하는 이벤트는 초당 0.5건 수준에 그친다.
베넷은 이 상황을 "재무 자문가의 추천으로 사모 신용에 투자했다가 30년 동안 돈을 못 빼낸다는 걸 나중에야 알게 된 것"에 비유한다. 결정 시점에 비용을 알 수 있어야 한다는 조건이 부채의 핵심인데, 그가 본 기술적 결정 대부분은 이 조건을 만족하지 못했다는 것이다. 결정 당시엔 사소한 효율화, 심지어 "제대로 하는 방법"처럼 보였던 선택이 나중에야 폭발적인 비용으로 드러난다.
"부채"와 "엉망"을 가르는 기준은 결국 하나다
베넷의 논지를 관통하는 기준은 단순하다. 결정을 내리는 시점에 그 선택의 비용을 알고 있었는가다. 알고 있었다면 그것은 부채이고, 갚을 계획도 함께 있어야 정상이다. 몰랐다면, 혹은 애초에 알 수 없는 종류의 문제였다면 그것은 부채가 아니라 그냥 엉망이다. 그는 "기술 부채"라는 말을 이런 상황에 잘못 쓰면 "계약서도 안 읽고 빚을 낸 사람"처럼 보인다고 지적한다. 소프트웨어 개발자는 자기 경험의 한계 바로 앞에서 일하기 때문에, 결과에 놀라는 일 자체는 오히려 정상이라고 그는 말한다.
베넷이 제안하는 대안은 "집이나 작업공간을 관리한다"는 비유다. 소프트웨어 프로젝트도 하나의 작업공간이고, 시간이 지나면서 정리·정돈·재배치가 필요해진다. 도구를 기능별로 정리했다가 크기별로 바꾸는 편이 낫다는 걸 나중에 깨닫기도 하고, 필요 없어진 물건을 못 버려 어수선해지기도 하며, 전 주인이 쓰던 집을 넘겨받아 대대적인 손질이 필요한데 그 사이에도 그 집에서 계속 살아야 하는 경우도 있다. "빚을 갚는다"는 말보다 "정리한다"는 말이 지금 자신이 하는 일을 훨씬 정확히 설명한다고 그는 마무리한다.
출처: Nat Bennett, Simpler Machines, "Let's not call it 'tech debt,' it's just 'mess'" (2026-08-15 확인)