[코드 냄새 #6] 기술 부채, 커닝햄이 말한 원래 뜻

핵심 답: 기술 부채는 1992년 워드 커닝햄이 만든 말이고, 원래 뜻은 지저분한 코드가 아니라 코드와 현재 이해 사이의 격차였습니다.

커닝햄은 부채 전략이 통하려면 오히려 코드가 깔끔해야 한다고 강조했습니다.

개발자가 비개발자에게 리팩터링을 설명해야 할 때 꺼내는 단어가 있습니다. 기술 부채.

이전 글 코드 냄새 #5에서 이어지는 내용입니다.

지금 빨리 만드느라 빚을 졌고, 이자가 붙고 있으니 갚을 시간을 달라는 이야기죠.

그런데 이 말을 처음 만든 사람은 자신의 비유가 잘못 쓰이고 있다고 여러 차례 밝혔습니다. 지저분한 코드를 부채라고 부르는 것이 특히 그렇다고요.

1992년, 워드 커닝햄

기술 부채라는 표현은 워드 커닝햄이 1992년에 처음 씁니다. OOPSLA(Object-Oriented Programming, Systems, Languages & Applications, 객체지향 프로그래밍 학회) 경험 보고서에서였습니다(논문).

위키를 발명한 사람이자 익스트림 프로그래밍의 초기 인물로 더 알려진 그 커닝햄입니다.

당시 그는 금융 소프트웨어를 만들고 있었습니다. 어려운 건 도메인이었습니다.

금융 상품의 구조를 처음부터 정확히 이해하고 시작할 수는 없으니까요. 그래서 지금 이해한 만큼으로 만들어 내보내고, 쓰면서 배운 것을 코드에 계속 반영하는 방식을 택합니다.

그가 말한 부채는 이 지점에서 생깁니다. 현재 코드가 담고 있는 이해와 지금 팀이 실제로 갖게 된 이해 사이의 차이.

처음 짤 때는 옳았던 구조가, 도메인을 더 알게 된 지금 보면 맞지 않는 상태. 그게 부채고, 코드를 새 이해에 맞게 고치는 것이 상환입니다.

2009년 그는 이 비유를 다시 설명하는 짧은 영상을 남기며 오해를 정정합니다. 요지는 이렇습니다(Debt Metaphor).

부채를 지는 것은 빨리 배우기 위한 전략이지, 형편없는 코드를 써도 된다는 허가가 아니다. 오히려 부채 전략이 작동하려면 코드가 깔끔해야 한다.

지저분하면 배운 것을 반영하는 일 자체가 불가능해지니까요.

여기가 핵심입니다. 원래 개념에서 부채는 잘 짜인 코드에서도 생깁니다.

시간이 지나 세상을 이해하는 방식이 바뀌면 자동으로 발생하니까요.

반면 오늘날 기술 부채라 불리는 것의 상당수는 그냥 대충 짠 코드입니다. 커닝햄의 논지대로라면 그건 빚이라기보다 그냥 엉망인 상태고요.

파울러의 사분면

그렇다고 “진짜 부채만 부채”라고 선을 그으면 실무에서 쓰기 어렵습니다. 마틴 파울러가 2009년에 정리한 사분면이 이 간극을 잘 메웁니다(Technical Debt Quadrant).

두 축을 씁니다. 의도적인가 우발적인가, 그리고 무모한가 신중한가.

	무모함(Reckless)	신중함(Prudent)
의도적	“설계할 시간 없어”	“지금 출시하고 대가는 감수한다”
우발적	“계층 분리가 뭔가요”	“이제야 어떻게 했어야 하는지 알겠다”

네 칸의 성격이 전부 다릅니다.

의도적·신중함은 경영 판단입니다. 마감이 있고, 늦으면 기회를 놓치고, 대신 나중에 비용을 치른다는 걸 알고 선택합니다.

이게 부채라는 은유가 가장 정확히 들어맞는 칸입니다.

조건이 하나 붙습니다. 대가를 안다는 것.

우발적·신중함이 커닝햄이 말한 원래 부채입니다. 최선을 다해 잘 만들었고, 6개월 뒤 도메인을 더 이해하고 나니 더 나은 구조가 보이는 상태.

잘못한 게 없는데도 발생합니다. 이 칸은 피할 수 있는 게 아니라서 상환 주기를 만들어 두는 것 말고 대책이 없습니다.

의도적·무모함은 알면서 대충 하는 쪽입니다. 흔히 부채라 불리지만 상환 계획이 없다는 점에서 부채보다 손실에 가깝습니다.

우발적·무모함은 몰라서 그렇게 된 경우입니다. 여기의 해법은 리팩터링 일정이 아니라 학습입니다.

같은 지저분한 코드라도 어느 칸인지에 따라 대응이 달라집니다. 팀이 부채 이야기를 할 때 자주 어긋나는 이유가 서로 다른 칸을 떠올리고 있어서인 경우가 많습니다.

이자는 무엇으로 내나

금융 부채의 이자는 돈이고, 기술 부채의 이자는 앞으로의 변경 비용입니다. 같은 기능을 추가하는 데 부채가 없으면 하루, 있으면 사흘이 걸린다면 이틀이 이자입니다.

정의를 이렇게 잡으면 결론이 하나 따라 나옵니다. 건드리지 않는 코드의 부채는 이자가 0입니다.

5년째 아무도 안 고치는 모듈이 아무리 지저분해도, 앞으로도 안 고친다면 갚을 이유가 없습니다. 반대로 매주 손대는 화면에 있는 작은 부채는 이자가 계속 나갑니다.

부채 목록을 만들 때 “얼마나 나쁜가”로 정렬하는 팀이 많은데, 실제 기준은 “얼마나 자주 손대는가”여야 합니다.

앞 편에서 쓴 Git 변경 빈도 조회가 여기서도 쓸모 있습니다. 자주 바뀌는 파일과 품질이 나쁜 파일이 겹치는 지점, 거기가 이자율이 가장 높은 곳입니다.

아담 톤힐은 이 교집합을 찾아 우선순위를 매기는 접근을 행동 기반 코드 분석이라고 부릅니다.

이 은유의 한계

기술 부채라는 말은 편해서 문제입니다. 무엇이든 여기에 담을 수 있습니다.

버그도, 오래된 라이브러리도, 마음에 안 드는 설계도, 내가 안 짠 코드도 전부 부채라고 불립니다. 그러면 이 단어는 “고치고 싶은 것”의 동의어가 되고 원래의 설명력을 잃습니다.

두 가지 질문을 통과할 때만 부채라 부르는 게 실용적입니다.

1. 무엇을 얻으려고 졌는가. 시간을 벌었는지, 학습을 얻었는지 말할 수 있어야 합니다. 아무것도 얻은 게 없으면 그건 부채가 아니라 실수입니다.
2. 어떻게 갚을 것인가. 갚을 계획이 없는 빚은 은유가 성립하지 않습니다.

은유 자체를 반대하는 시각도 있습니다. 부채라는 말이 “언젠가 갚으면 된다”는 인상을 줘서 실제로는 복리로 불어나 상환이 불가능해지는 상황을 가리기 때문입니다.

어떤 이들은 차라리 오염이나 위생 문제로 부르자고 제안합니다. 갚는 게 아니라 계속 치워야 하는 것에 가깝다는 이유로요.

다만 부채라는 단어가 오래 살아남은 데는 이유가 있습니다. 개발 외부와 대화가 되는 몇 안 되는 은유입니다.

커닝햄이 처음 이 비유를 꺼낸 자리도 상사에게 재작업의 필요를 설명하는 맥락이었습니다. 정밀한 용어가 아니라 번역 도구로 보면 여전히 값을 합니다.

실무에서 관리하는 법

목록으로 만들되 이슈 트래커에 묻지 않습니다. 부채 티켓만 모아 둔 백로그는 대개 아무도 안 봅니다.

대신 코드 근처에 남기는 방법이 있습니다. 해당 파일에 왜 이렇게 됐고 무엇이 필요한지 짧게 적어 두면, 다음에 그 파일을 여는 사람이 반드시 봅니다.

손대는 김에 갚습니다. 그 파일을 어차피 고칠 때가 이자가 발생하는 시점이고 문맥이 머리에 있는 시점입니다.

보이스카웃 규칙, 그러니까 “왔을 때보다 깨끗하게 두고 간다”가 부채 관리 방법으로 실제로 유효한 이유입니다.

갚지 않기로 결정하는 것도 관리입니다. 부채 목록의 절반은 상환 대상이 아니라 기록 대상입니다.

안 갚기로 명시적으로 정한 항목은 다음에 같은 논의를 반복하지 않게 해 줍니다.

의도적으로 질 때는 조건을 함께 적습니다. “출시 뒤 2주 안에”, “사용자 1만 명을 넘기 전에”처럼요.

시점 없이 진 빚은 갚는 시점도 없습니다.

정리하면

• 기술 부채는 1992년 워드 커닝햄이 만든 말이고, 원래 뜻은 지저분한 코드가 아니라 코드와 현재 이해 사이의 격차였습니다.
• 커닝햄은 부채 전략이 통하려면 오히려 코드가 깔끔해야 한다고 강조했습니다.
• 파울러의 사분면은 의도성과 신중함으로 네 칸을 나눕니다. 칸마다 대응이 다릅니다.
• 이자는 앞으로의 변경 비용입니다. 안 건드리는 코드의 부채는 이자가 0이라 갚을 이유가 없습니다.
• 무엇을 얻었고 어떻게 갚을지 말할 수 없다면 그건 부채가 아니라 그냥 문제입니다.

다음 편은 부채가 감당하기 어려울 만큼 쌓였을 때의 선택지를 다룹니다. 고쳐 쓸 것인가 새로 쓸 것인가.

소프트웨어 업계에서 가장 비싼 오답이 나온 자리이기도 합니다.

출처 및 확인 기준

• The WyCash Portfolio Management System — Ward Cunningham · 논문 원문 · 확인 2026-08-17 · 근거: 1992년 기술 부채 은유의 원래 설명
• Debt Metaphor — Ward Cunningham · 저자 원문 · 확인 2026-08-17 · 근거: 2009년 Ward Cunningham의 기술 부채 은유 해설
• Technical Debt Quadrant — Martin Fowler · 저자 원문 · 확인 2026-08-17 · 근거: 신중함·무모함과 의도성으로 구분한 기술 부채 사분면

이어서 읽기

코드 냄새 시리즈

• 이전 편: [코드 냄새 #5] 산탄총 수술 vs 발산적 변경
• 이전 편: [코드 냄새 #4] 갓 오브젝트(God Object) 완벽 정리
• 이전 편: [코드 냄새 #3] 라비올리 코드, 흐름을 아무도 모르는 코드