1년 전엔 기능 하나를 이틀이면 만들었는데, 지금은 일주일이 걸립니다. 개발자들은 "코드가 너무 얽혀서 한 곳을 바꾸면 엉뚱한 데가 깨져요"라고 합니다. 하지만 경영진엔 "그냥 개발이 느려졌다"로만 보입니다. 한편 인프라팀은 5년 된 라이브러리·미적용 보안 패치·매주 반복하는 수동 작업에 짓눌려 있는데, 이 '보이지 않는 비용'은 로드맵 어디에도 없습니다. 기술 부채는 회계장부에 없지만 분명히 존재하는 빚입니다. PM이 이걸 '비용'으로 이해하고 가시화하지 못하면, 조직은 서서히 느려지다 멈춥니다.
- 1기술 부채가 "이자 붙는 빚"처럼 변경 비용을 키움을 설명할 수 있다
- 2리팩터링이 "동작은 그대로, 구조 개선"임을 구분할 수 있다
- 3부채 상환에 일정 비율을 고정 배정하는 이유를 설명할 수 있다
- 4코드·운영 부채를 백로그 이슈로 가시화할 수 있다
기술 부채 — 이자 붙는 빚
지금의 속도를 미래에서 빌려온다
기술 부채는 당장 빠르게 가려고 미룬 것(임시방편·미흡한 설계·빠진 테스트·낡은 의존성)이 쌓여 미래의 변경을 느리고 위험하게 만드는 것입니다.
부채 없는 코드: 기능 추가 ──▶ 이틀
부채 쌓인 코드: 기능 추가 ──▶ 일주일 (얽힌 코드 파악 + 깨지는 곳 수습)
└ '이자' = 매 변경마다 더 드는 비용
부채의 종류:
의도적·전략적: "마감 위해 지금은 임시로, 다음 스프린트에 정리" (관리되면 OK)
방치된 부채: "바빠서 못 갚음"이 누적 → 복리로 증가 (위험)
운영 부채: 낡은 의존성·미적용 패치·반복 수작업(toil)·모니터링 사각
핵심: 부채 자체가 악은 아닙니다. 관리되는 부채(언제 왜 졌고 언제 갚을지 기록)는 전략입니다. 문제는 보이지 않게 방치되는 것 — PM이 이걸 '비용'으로 인식하지 못하면 기능만 쌓이다 어느 날 "작은 변경도 며칠"이 됩니다.
리팩터링 — 동작은 그대로, 구조를 개선
기능 추가가 아니라 '갚는' 작업
리팩터링은 외부 동작(기능)은 바꾸지 않고 내부 구조를 개선하는 작업입니다.
리팩터링 전후: 사용자가 보는 동작 = 동일
내부: 얽힌 코드 → 정리된 코드 (이후 변경이 쉬워짐)
안전장치: 리팩터링 전후 테스트 결과가 같아야 함([[test-strategy]])
→ 테스트가 없으면 리팩터링이 위험(뭐가 깨졌는지 모름)
→ 그래서 "리팩터링하려면 먼저 테스트부터"
PM이 알아야 할 점: 리팩터링은 사용자에게 안 보입니다. 그래서 "왜 기능도 안 늘었는데 시간을 썼냐"는 오해가 생깁니다. 하지만 리팩터링은 미래의 기능 개발 속도를 회복하는 투자입니다. "이 리팩터링으로 앞으로 결제 관련 변경이 절반 시간에 가능해진다" 같은 속도 회복으로 가치를 설명해야 합니다.
부채를 가시화하기 — 직접 점검
부채는 보이지 않으면 갚히지 않습니다. PM·인프라는 부채를 이슈로 만들어 영향과 함께 가시화합니다([[roadmap-issue-tracking]]).
부채 이슈화(예):
항목 영향(이자) 우선순위
결제 모듈 얽힌 구조 결제 변경마다 +3일, 회귀 빈발 높음
라이브러리 5년 미업데이트 보안 취약점 노출, MAJOR 점프 위험 높음([[semantic-versioning]])
인증서 수동 갱신(toil) 분기 14회 수작업·갱신 누락 장애 높음([[roadmap-issue-tracking]])
미정리 기능 플래그 30개 코드 분기 복잡·실수 유발 중간([[release-strategy]])
모니터링 사각(배치 작업) 장애 늦게 발견, MTTR 증가 중간
→ 매 스프린트 20%를 상위 부채 상환에 고정 배정
부채 대시보드 효과:
Before: "개발이 그냥 느려요"(설명 불가) → 상환 우선순위 0
After: "결제 모듈 부채로 변경당 +3일" → 정량화 → 리팩터링 정당화
→ 보이지 않던 비용이 의사결정 테이블에 올라옴
echo '부채 항목 → 영향·이자 → 상환 우선순위'- 부채 항목마다 "이자(영향)"를 정량화한다 — "변경당 +3일", "분기 14회 수작업"처럼. 숫자가 있어야 기능과 우선순위 경쟁에서 밀리지 않는다
- 운영 부채(낡은 의존성·미적용 패치)는 보안 리스크와 직결 → [[semantic-versioning]]의 MAJOR 점프 위험과 함께 상환 우선순위를 높인다
- reactive(터지면 대응)만 반복되면 부채가 누적 중인 신호 — 매 스프린트 고정 비율(예: 20%)이 0으로 수렴하지 않는지 점검
- 리팩터링 PR이 테스트 없이 올라오면 위험([[test-strategy]]) — "리팩터링 전 테스트 먼저"가 안전장치. 테스트 없는 코드의 리팩터링은 부채를 또 만들 수 있다
상황: 매 분기 "이번엔 기능이 급하니 리팩터링은 다음에"가 반복됩니다. 2년 뒤, 작은 버튼 하나 바꾸는 데도 며칠이 걸리고, 변경마다 예상 못 한 곳이 깨지며, 신규 입사자는 코드를 이해하지 못합니다.
원인: 부채 상환을 항상 후순위로 밀어 0%가 됐습니다. 기능의 단기 가치는 보이고 부채의 비용은 안 보여서, 매번 기능이 이깁니다. 그 결과 부채가 복리로 쌓여 변경 속도가 붕괴했습니다([[estimation-prioritization]]에서 본 '운영비 누락'의 장기 버전).
진단:
□ 최근 N스프린트에 부채/리팩터링 항목이 실제로 완료됐나? (0이면 위험)
□ 같은 영역의 버그·회귀가 반복되나? (부채의 증상)
□ 기능 추정이 점점 커지나? (예전 2일 → 지금 1주)
해결: (1) 매 스프린트 고정 비율(예: 20%) 을 부채 상환·리팩터링·테스트 보강에 배정하고, 이를 '협상 불가' 항목으로 보호. (2) 부채를 [[roadmap-issue-tracking]] 이슈로 가시화하고 '이자(영향)'를 정량화해 기능과 동등하게 우선순위 경쟁. (3) "보이스카우트 룰" — 코드를 만질 때마다 조금씩 정리. 부채는 없앨 수 없지만, 꾸준히 갚으면 통제 가능합니다. PM이 부채를 '비용'으로 다루는 것이 장기 개발 속도의 핵심입니다.
인프라/SRE로서 '운영 부채'는 당신의 일상과 직결됩니다 — 낡은 의존성(보안), 미적용 패치, 반복 수작업(toil), 모니터링 사각, 쌓인 기능 플래그가 장애와 야근을 만듭니다. 이를 [[roadmap-issue-tracking]]에서 본 것처럼 이슈로 집계해 "인증서 수동 갱신 분기 14회 → 자동화 시 14건 toil 제거" 같은 정량 근거로 상환을 정당화합니다. PM은 기술 부채를 '개발팀의 게으름'이 아니라 '관리해야 할 비용'으로 이해하고, 매 스프린트 상환 비율을 보호하며, 리팩터링의 가치를 '미래 속도 회복'으로 이해관계자에게 번역합니다. 부채를 외면하는 조직은 빠른 게 아니라 빚으로 달리는 것입니다.
이것으로 품질·부채를 다뤘습니다. 다음 마지막 모듈에서는 운영의 신뢰성을 지표로 관리하는 SLO·에러버짓과 장애 대응 문화를 다룹니다.