"기술 부채"라고 부르지 말고, 그냥 "엉망진창"이라고 부르자.

출처: Simpler Machines (Nat Bennett)
원문: https://www.simplermachines.com/lets-not-call-it-tech-debt-its-just-mess/
원문 발행일: 2026-08-13
작성자: 팔복소프트-김팔복

한눈에 보기

• 개발자 Nat Bennett이 "기술 부채(technical debt)"라는 용어가 실제 상황과 잘 맞지 않는다며, 대신 "mess(어질러짐, 정리 안 된 상태)"라는 표현을 제안했다.
• 금융 부채는 계약 시점에 규모와 비용이 정해지지만, 개발 현장에서 부채라 부르는 대부분은 결정 당시 비용을 알 수 없었던 것이다.
• 개발자들이 부채라고 부르는 것 중 상당수는 실제로는 미숙한 작업, 취향 차이, 예상 못 한 설계 부작용이다.
• 비개발자는 "기술 부채"를 "일을 대충 했다"는 뜻으로 알아듣기 쉬워, 개발팀의 신뢰를 깎는 부작용이 있다.
• 필자는 소프트웨어를 '계속 청소하고 재배치해야 하는 작업 공간'에 비유하는 쪽이 더 정직하다고 본다.

배경

"기술 부채"는 1992년 Ward Cunningham이 만든 비유다. 당장 빨리 출시하기 위해 완벽하지 않은 코드를 의도적으로 선택하면, 나중에 이자(추가 유지보수 비용)를 갚아야 한다는 뜻이다. 이후 이 말은 개발자 사이에서 "손봐야 하는 코드" 전반을 가리키는 관용어로 굳어졌고, 국내에서도 리팩토링 일정을 요청할 때 흔히 쓰인다. 이번 글은 그 관용적 용법이 오히려 문제를 만든다는 문제 제기다.

주요 내용

부채 비유가 성립하려면

필자는 금융 부채의 특징을 두 가지로 요약한다. 첫째, 의도적으로 진다. 둘째, 얼마를 빌렸고 얼마를 갚아야 하는지 처음부터 문서로 정해져 있다. 그래서 기업 입장에서 부채는 나쁜 것이 아니라 적정 수준을 유지해야 하는 자원이다. 너무 적으면 성장 기회를 놓치고, 너무 많으면 위험해진다.

이 기준을 만족하는 기술 부채도 있다. 필자가 자신의 프로젝트에서 SQL 쿼리를 읽기 쉬운 단위로 쪼개 작성하고, 사용자가 늘면 나중에 합쳐 DB 호출 수를 줄이기로 미룬 것이 그 예다. 나중 비용을 알고, 지금 개발 편의를 얻은 거래다.

그런데 대부분은 부채가 아니다

문제는 현장에서 "부채"라고 부르는 것 대부분이 위 조건에 맞지 않는다는 점이다. 필자가 든 유형을 정리하면 다음과 같다.

특히 마지막 유형이 필자의 핵심 논지다. 이벤트 기반 시스템 컨설팅 경험을 예로 들며, 모놀리식에서 확장 문제로 고생한 팀이 두 번째 기회에 AWS Lambda 기반 이벤트 아키텍처로 전면 전환했다가, 특정 사용자 동작이 어디서 실패하는지 추적할 수 없게 된 상황을 설명한다. 이런 시스템을 처음 만들어 보니 계측(instrumentation)을 어떻게 해야 하는지도 몰랐고, 정작 처리량은 초당 0.5건 수준이었다고 한다.

이런 상황을 부채라고 부르면 오히려 개발팀이 무책임해 보인다는 것이 필자의 지적이다.

"기술 부채"를 "결정할 때는 몰랐던 문제"라는 뜻으로 쓰면, 계약 조건도 읽지 않고 대출을 받는 사람처럼 보이게 된다. — Nat Bennett

필자는 개발자가 대부분 자기 경험의 가장자리에서 일하기 때문에 결과에 놀라는 것이 정상이라고 덧붙인다. 잘못은 놀란 것이 아니라, 그것을 "계산된 부채"인 양 포장하는 언어에 있다.

대안: 작업 공간 정리

필자가 제안하는 비유는 집이나 작업장 관리다. 도구를 기능별로 놓았다가 크기별이 더 낫다는 걸 깨닫기도 하고, 버리지 못한 물건이 쌓이기도 하고, 전 주인에게서 넘겨받은 집을 살면서 고쳐야 할 때도 있다. 소프트웨어도 같은 종류의 지속적인 정리 작업이 필요한 공간이라는 관점이다.

팔복소프트 관점

• 국내 개발 조직, 특히 SI·외주 구조에서는 이 지적이 더 아프게 들린다. 인수받은 코드를 "레거시" 또는 "기술 부채"라고 부르는 순간, 발주처는 "전 업체 탓을 한다"로 받아들이고, 개선 예산 협상은 시작도 전에 감정 싸움이 된다. 필자가 말한 "비개발자는 mess로 듣는다"는 현상이 국내에서는 더 강하게 나타난다.
• 실무적으로 유용한 것은 용어 교체보다 분류다. 위 표처럼 "의도적으로 미룬 것", "지금 팀이 못 하는 것", "취향 차이", "몰랐던 부작용"을 나눠 보면 대응이 달라진다. 첫째는 일정, 둘째는 학습·교육, 셋째는 합의, 넷째는 관측성 투자로 풀어야 한다. 전부 "부채 상환 스프린트"에 몰아넣으면 아무것도 제대로 안 된다.
• 다만 "mess"라는 표현이 경영진 설득에 반드시 유리하지는 않다. 부채 비유의 장점은 이자, 원금, 상환 계획처럼 예산 언어로 번역된다는 점이다. 정리 비유는 정직하지만 "얼마가 드나"에 답하기 어렵다. 우리는 내부 회고에서는 정리 비유를, 예산 요청서에서는 비용 추정을 붙인 부채 언어를 쓰는 식으로 상황에 따라 나눠 쓰는 편이 현실적이라고 본다.
• Lambda 이벤트 아키텍처 사례는 국내에서도 그대로 재현된다. MSA나 Kafka 기반 이벤트 구조를 트래픽 규모와 무관하게 도입한 뒤 분산 추적(OpenTelemetry, X-Ray 등) 없이 운영하다 막히는 경우다. 이 글이 주는 실질적 교훈은 "새 아키텍처를 처음 쓸 때는 관측성부터 예산에 넣어라"에 가깝다.

정리

기술 부채라는 말은 "알고 진 빚"에만 써야 설득력이 있다. 나머지는 실력, 취향, 무지의 문제이며 각각 처방이 다르다. 이번 주 백로그에서 "기술 부채"라고 적힌 항목을 열어 보고, 정말 부채인지 아니면 그냥 치워야 할 어질러짐인지 한 번 나눠 보길 권한다. 그것만으로도 이해관계자와의 대화가 달라진다.

• 기술부채
• 리팩토링
• 소프트웨어 유지보수
• 개발 문화
• 아키텍처