---
title: 기술 부채는 갚는 게 아니라 관리하는 것이다
description: "기술 부채를 0으로 만들겠다는 목표는 처음부터 틀렸다. 쓰이는 소프트웨어는 그대로 둬도 복잡도가 늘어나는 시스템이라, 부채는 제거할 결함이 아니라 이자율로 다루는 포트폴리오다. 커닝햄의 원래 비유와 파울러의 사분면으로 좋은 빚과 나쁜 빚을 가르고 우선순위를 매기는 법을 정리했다."
createdAt: 2026-06-23
author: 이든
category: tech
jobCategory: dev
tags: [기술 부채, 리팩터링, 소프트웨어 아키텍처, 코드 품질, 엔지니어링 문화]
featured: false
canonical: "https://blog.careernote.io/article/technical-debt-is-managed-not-repaid"
source: CareerNote Blog
language: ko
---
리팩터링 일정을 잡을 때마다 같은 질문을 받습니다. 기술 부채를 언제쯤 다 갚을 수 있냐고요. 결론부터 말씀드리겠습니다. 기술 부채는 다 갚을 수 없고, 다 갚는 것을 목표로 삼아서도 안 됩니다. 부채는 언젠가 제거할 결함이 아니라, 이자율을 보고 다루는 포트폴리오에 가깝습니다. 그러니 진짜 질문은 "언제 다 갚는가"가 아니라 "어떤 부채를 의도적으로 지고, 어떤 부채를 먼저 갚을 것인가"입니다. AI가 코드를 쏟아내며 [부채가 쌓이는 속도가 빨라진 지금](/article/ai-writes-half-the-code), 이 구분은 그 어느 때보다 실무에 직접 영향을 줍니다.

## "다 갚는다"는 목표가 처음부터 틀렸다

기술 부채를 0으로 만든다는 건 도달할 수 없는 상태입니다. 소프트웨어가 멈춰 있다면 모를까, 쓰이는 한 부채는 계속 생기기 때문입니다.

근거는 50년 묵은 관찰에 있습니다. 마이어 레만은 IBM의 OS/360 같은 대형 시스템의 변경 이력을 실증적으로 분석해 소프트웨어 진화의 법칙을 정리했습니다(Lehman, 1980). 

- **제1법칙, 계속적 변화**: 쓰이는 소프트웨어는 끊임없이 바뀌지 않으면 점점 쓸모없어집니다.
- **제2법칙, 복잡도 증가**: 시스템이 진화하면 복잡도는 올라갑니다. 복잡도를 줄이는 일을 의도적으로 하지 않는 한, 이건 열역학 제2법칙과 같은 구조입니다.

리팩터링은 엔트로피에 역행하는 작업이지, 엔트로피를 0으로 만드는 작업이 아닙니다. 그러니 "부채 제로"는 변경이 멈춘 죽은 코드에서만 성립합니다. 살아 있는 제품에서는 부채가 계속 발생하고, 우리가 할 수 있는 건 제거가 아니라 관리입니다. 게다가 부채는 이미 모두의 장부에 잡혀 있습니다. 보이지 않을 뿐이죠.

| 출처 | 측정 대상 | 수치 |
|------|----------|------|
| 맥킨지 (2020) | 기술 자산 가치 대비 부채 | 20~40% |
| 맥킨지 (2020) | 신규 제품 예산 중 부채 처리로 전용 | 10~20% |
| 스트라이프 (2018) | 개발자 주당 부채 대응 시간 | 약 13.5시간 (업무의 3분의 1) |
| CISQ (2022) | 미국 누적 기술 부채 원금 | 약 1.52조 달러 |

맥킨지가 대기업 CIO 50명을 조사해보니 기술 부채가 전체 기술 자산 가치의 20~40%에 달했고, 응답자의 60%는 지난 3년간 부채가 눈에 띄게 늘었다고 답했습니다. 스트라이프 조사에서는 개발자가 주당 업무의 3분의 1가량을 부채 대응에 씁니다. 부채는 안 보이는 게 아니라, 이자만 조용히 빠져나가고 있을 뿐입니다.

## 커닝햄이 말한 부채는 '나쁜 코드'가 아니었다

여기서 비유의 원점을 짚어야 합니다. 기술 부채라는 말은 1992년 워드 커닝햄이 WyCash라는 금융 포트폴리오 시스템을 만들며 OOPSLA에서 처음 꺼냈습니다(Cunningham, 1992). 원문은 이렇습니다. "처음 짠 코드를 출시하는 것은 빚을 지는 것과 같다. 약간의 빚은 개발을 빠르게 한다, 다시 짜서 곧바로 갚는 한." 그리고 한 줄을 덧붙입니다. 어설픈 코드에 쓰는 1분 1분이 그 빚의 이자라고.

핵심은 커닝햄이 말한 부채가 지저분한 코드가 아니라는 점입니다. 그가 가리킨 건, 도메인을 아직 다 이해하지 못한 상태에서 일단 내보내 배우고, 배운 것을 코드에 반영하는 의도적 레버리지였습니다. 그가 지목한 진짜 위험도 코드가 더럽다는 게 아니라 통합(consolidate)에 실패하는 것, 즉 빚을 갚지 않는 것이었습니다.

많은 팀이 부채를 실수나 게으름의 동의어로 씁니다. 하지만 원래 비유에서 부채는 속도를 빌리는 전략적 선택이었습니다. (솔직히 저도 한동안 부채를 그냥 치워야 할 쓰레기로만 봤습니다.) 이 구분이 관리의 출발점입니다. 부채에는 좋은 빚과 나쁜 빚이 있고, 둘을 같은 잣대로 다루면 멀쩡한 코드를 헤집거나 위험한 코드를 방치하게 됩니다. 감당할 준비 없이 [마이크로서비스로 시스템을 쪼개는 선택](/article/microservices-vs-monolith-architecture) 역시, 미래에 비싼 이자를 부르는 무모하고 우발적인 아키텍처 부채가 되기 쉽습니다.

## 모든 부채가 같지 않다

좋은 빚과 나쁜 빚을 가르는 도구로 마틴 파울러의 사분면만 한 게 없습니다(Fowler, 2009). 부채를 의도적인가 우발적인가, 그리고 신중한가 무모한가의 두 축으로 나눕니다.

| | 신중 (Prudent) | 무모 (Reckless) |
|---|---|---|
| **의도적** | "지금 출시하고 대가를 감수한다" | "설계할 시간 없어" |
| **우발적** | "이제야 어떻게 했어야 하는지 알겠다" | "계층 분리가 뭐죠?" |

신중하고 의도적인 부채는 정당한 전략입니다. 마감을 위해 갚을 계획과 함께 지는 빚이죠. 우발적이지만 신중한 부채는 뛰어난 팀에게도 불가피합니다. 다 만들고 나서야 더 나은 설계를 깨닫는 경우니까요. 문제는 아래쪽, 특히 무모하고 우발적인 부채입니다. 모르고 짜서 생기고, 무엇이 쌓이는지조차 모르는 상태죠.

그렇다면 무모한 부채는 왜 그렇게 잘 쌓일까요. 의지가 약해서가 아니라 인간의 기본 편향 때문입니다. 행동경제학의 현재 편향, 쌍곡 할인이 여기 정확히 들어맞습니다. 사람은 가까운 비용과 이익에 과한 가중치를 두고 먼 미래는 과소평가합니다(Laibson, 1997). 부채의 이자는 미래에 청구되고, 빨리 친 코드의 이득은 지금 손에 잡힙니다. 그래서 "나중에 갚지"가 구조적으로 반복됩니다. 무모한 부채는 개인의 나태가 아니라 예측 가능한 편향이고, 그래서 개인 의지가 아니라 시스템으로 막아야 합니다.

방치하면 복리로 분다는 것도 비유가 아닙니다. 헌트와 토머스는 『실용주의 프로그래머』에서 깨진 유리창 이론을 코드에 적용했습니다(Hunt & Thomas, 1999). 방치된 나쁜 코드 하나가 "여기선 이래도 되는구나"라는 신호가 되어 부패를 가속한다는 거죠. 첫 번째 무모한 부채가 두 번째를 부르고, 그렇게 이자가 이자를 낳습니다.

## 부채를 포트폴리오처럼 관리한다

정리하면, 부채는 제거할 대상이 아니라 운용할 대상입니다. 포트폴리오 운용에 네 가지 원칙을 씁니다.

**이자가 보이게 만듭니다.** 안 보이는 빚은 갚히지 않습니다. 부채를 백로그 티켓, 코드 주석, 아키텍처 결정 기록으로 장부에 올립니다. 현재 편향을 이기는 유일한 방법은 미래의 비용을 지금 눈앞으로 끌어오는 것입니다.

**이자율로 우선순위를 매깁니다.** 전부 갚을 수 없으니 비싼 빚부터. 이자율은 대략 변경 빈도 곱하기 복잡도입니다. 1년에 한 번 건드리는 모듈의 더러운 코드는 이자가 거의 0이라 갚을 필요가 없습니다. 매일 손대는 핵심 경로의 부채가 진짜 비쌉니다. (이 트리아지 없이 '코드 정리 스프린트'를 잡으면, 아무도 안 보는 코드를 예쁘게 다듬으며 시간을 태우기 쉽습니다.)

몇 년 전 한 화면의 필터 기능을 맡았을 때가 그랬습니다. 옵션 목록과 라벨, URL 쿼리 파라미터, UI 상태가 제각기 다른 곳에서 관리되고 있었죠. 필터를 하나 추가할 때마다 네 군데를 손봐야 했고, 한 곳을 빼먹으면 조용히 버그가 났습니다. 변경 빈도는 높은데 구조가 분산된, 전형적인 고이자 부채였습니다. 그래서 단일 설정 모델(SSOT)을 기준으로 라벨 매핑과 렌더링, 쿼리 변환이 같은 데이터를 참조하도록 통합했습니다. 새 필터를 추가하는 비용이 네 곳에서 한 곳으로 줄었습니다. 의도적으로, 그러나 신중하게 진 부채를 제때 갚은 셈입니다.

**의도적 부채는 만기를 적습니다.** 신중하고 의도적인 빚을 질 때는 커닝햄처럼 갚을 계획을 함께 남깁니다. 코드로 보겠습니다.

```python
# DEBT(만기: 2026-Q3, 조건: 결제 v2 API 출시 시 제거)
# v1 게이트웨이가 멱등키를 지원하지 않아, 임시로 주문ID로 중복 청구를 막는다.
# 이자율: 결제 경로 = 변경 빈도 높음 → 우선 상환 대상.
def charge_once(order_id, amount):
    if payments.exists(order_id):
        return payments.get(order_id)
    return gateway.charge(order_id, amount)
```

만기와 조건, 이자율을 한 줄로 적어두면, 이 부채는 무모한 부채로 변질되지 않습니다. 만기 없는 의도적 부채는 시간이 지나면 그냥 우발적 부채와 구분되지 않습니다.

**상시 상환은 보이스카우트 규칙에 맡깁니다.** 마틴이 말한 "왔을 때보다 깨끗하게 두고 떠나라"입니다. 리팩터링은 집 청소와 같습니다. 매일 조금씩 하면 대청소가 필요 없습니다. 측정이 먼저라는 점만 잊지 않으면 됩니다. 예전에 중첩 배열을 순회하던 코드를 맡았을 때, 읽기 어렵다는 이유만으로는 건드리지 않았습니다. 프로파일링을 해보니 그 순회가 화면 로딩의 병목이었고 소비 지점도 많아 이자율이 확실히 높았습니다. 그제서야 데이터를 키 기반 맵으로 재구조화해 접근을 한 단계로 줄였습니다. 거꾸로 했다면 느낌만으로 멀쩡한 코드를 헤집었을 겁니다.

물론 트레이드오프가 있습니다. 부채를 장부에 올리고 만기를 관리하는 일 자체에 비용이 듭니다. 모든 부채를 추적하면 추적이 또 하나의 부채가 됩니다. 그래서 이자율 높은 상위 몇 개만 명시적으로 관리하고, 나머지는 보이스카우트 규칙에 맡기는 게 현실적입니다. 완벽한 장부 대신 80%짜리 장부를 택하는 거죠. 부채 관리에도 부채 관리가 필요하다는 건, 좀 웃기지만 사실입니다.

## 결론

기술 부채는 갚아 없앨 적이 아니라 속도를 빌리는 도구입니다. 레버리지가 늘 그렇듯, 문제는 빚을 졌다는 사실이 아니라 이자율을 모른 채 빚을 굴리는 것입니다. 살아 있는 소프트웨어에서 부채 제로는 환상이고(엔트로피는 0이 되지 않습니다), 부채 방치는 복리로 돌아옵니다. 그 복리 청구서는 종종 장애의 형태로 날아옵니다. 방치된 고이자 부채는 [장애 회고에서 단골로 등장하는 기여 요인](/article/incident-response-is-learning-not-recovery)이니까요. 그 사이에서 우리가 할 일은 어떤 빚을 의도적으로 지고, 어떤 빚을 먼저 갚을지 고르는 것뿐입니다.

다음에 "언제 부채를 다 갚죠?"라는 질문을 받으면, 질문을 바꿔보시기 바랍니다. "지금 우리가 가장 비싼 이자를 내고 있는 코드는 어디인가." 좋은 코드를 만드는 일이 결국 [코드를 짜기 전의 판단](/article/what-senior-developers-do-before-coding)에서 시작하듯, 부채 관리도 갚는 기술이 아니라 고르는 판단에서 시작합니다. 그 한 줄이 부채를 막연한 공포에서 구체적인 의사결정으로 바꿉니다. 같은 이유로, [리뷰는 부채가 새어 들어오는 마지막 관문](/article/code-review-is-not-reading-code)이기도 합니다.

---

## 참고 자료

- Cunningham, W. (1992). The WyCash Portfolio Management System. OOPSLA Experience Report.
- Fowler, M. (2009). Technical Debt Quadrant. martinfowler.com.
- Lehman, M. M. (1980). Programs, Life Cycles, and Laws of Software Evolution. Proceedings of the IEEE. (계속적 변화·복잡도 증가의 법칙)
- Hunt, A. & Thomas, D. (1999). The Pragmatic Programmer. (소프트웨어 엔트로피와 깨진 유리창)
- Laibson, D. (1997). Golden Eggs and Hyperbolic Discounting. Quarterly Journal of Economics. (현재 편향·쌍곡 할인)
- McKinsey & Company (2020). Tech debt: Reclaiming tech equity.
- Krasner, H. / CISQ (2022). The Cost of Poor Software Quality in the US.
- Stripe & Harris Poll (2018). The Developer Coefficient.