1년 전엔 기능 하나를 이틀이면 만들었는데, 지금은 일주일이 걸립니다. 개발자들은 "코드가 너무 얽혀서 한 곳을 바꾸면 엉뚱한 데가 깨져요"라고 합니다. 하지만 경영진엔 "그냥 개발이 느려졌다"로만 보입니다. 한편 인프라팀은 5년 된 라이브러리·미적용 보안 패치·매주 반복하는 수동 작업에 짓눌려 있는데, 이 '보이지 않는 비용'은 로드맵 어디에도 없습니다. 기술 부채는 회계장부에 없지만 분명히 존재하는 빚입니다. PM이 이걸 '비용'으로 이해하고 가시화하지 못하면, 조직은 서서히 느려지다 멈춥니다.
- 1기술 부채가 "이자 붙는 빚"처럼 변경 비용을 키움을 설명할 수 있다
- 2리팩터링이 "동작은 그대로, 구조 개선"임을 구분할 수 있다
- 3부채 상환에 일정 비율을 고정 배정하는 이유를 설명할 수 있다
- 4코드·운영 부채를 백로그 이슈로 가시화할 수 있다
기술 부채 — 이자 붙는 빚
지금의 속도를 미래에서 빌려온다
기술 부채는 당장 빠르게 가려고 미룬 것(임시방편·미흡한 설계·빠진 테스트·낡은 의존성)이 쌓여 미래의 변경을 느리고 위험하게 만드는 것입니다.
확대
핵심: 부채 자체가 악은 아닙니다. 관리되는 부채(언제 왜 졌고 언제 갚을지 기록)는 전략입니다. 문제는 보이지 않게 방치되는 것 — PM이 이걸 '비용'으로 인식하지 못하면 기능만 쌓이다 어느 날 "작은 변경도 며칠"이 됩니다.
확대
위 그림처럼 부채를 방치하면 변경 비용이 복리로 가파르게 증가하고, 꾸준히 상환하면 완만하게 유지됩니다.
리팩터링 — 동작은 그대로, 구조를 개선
기능 추가가 아니라 '갚는' 작업
리팩터링은 외부 동작(기능)은 바꾸지 않고 내부 구조를 개선하는 작업입니다.
리팩터링 전후: 사용자가 보는 동작 = 동일
내부: 얽힌 코드 → 정리된 코드 (이후 변경이 쉬워짐)
안전장치: 리팩터링 전후 테스트 결과가 같아야 함([[test-strategy]])
→ 테스트가 없으면 리팩터링이 위험(뭐가 깨졌는지 모름)
→ 그래서 "리팩터링하려면 먼저 테스트부터"
PM이 알아야 할 점: 리팩터링은 사용자에게 안 보입니다. 그래서 "왜 기능도 안 늘었는데 시간을 썼냐"는 오해가 생깁니다. 하지만 리팩터링은 미래의 기능 개발 속도를 회복하는 투자입니다. "이 리팩터링으로 앞으로 결제 관련 변경이 절반 시간에 가능해진다" 같은 속도 회복으로 가치를 설명해야 합니다.
확대
위 그림처럼 리팩터링 전은 모든 로직이 뒤섞인 스파게티 구조이고, 후는 책임이 명확히 분리돼 테스트 작성이 가능해집니다.
확대
위 그림처럼 부채 배정 0%는 단기에 빠르지만 속도가 급락하고, 20% 고정이 장기적으로 가장 안정적인 속도를 유지합니다.
부채를 가시화하기 — 직접 점검
부채는 보이지 않으면 갚히지 않습니다. PM·인프라는 부채를 이슈로 만들어 영향과 함께 가시화합니다(로드맵과 이슈 트래킹).
부채 이슈화(예):
항목 영향(이자) 우선순위
결제 모듈 얽힌 구조 결제 변경마다 +3일, 회귀 빈발 높음
라이브러리 5년 미업데이트 보안 취약점 노출, MAJOR 점프 위험 높음([[semantic-versioning]])
인증서 수동 갱신(toil) 분기 14회 수작업·갱신 누락 장애 높음([[roadmap-issue-tracking]])
미정리 기능 플래그 30개 코드 분기 복잡·실수 유발 중간([[release-strategy]])
모니터링 사각(배치 작업) 장애 늦게 발견, MTTR 증가 중간
→ 매 스프린트 20%를 상위 부채 상환에 고정 배정
부채 대시보드 효과:
Before: "개발이 그냥 느려요"(설명 불가) → 상환 우선순위 0
After: "결제 모듈 부채로 변경당 +3일" → 정량화 → 리팩터링 정당화
→ 보이지 않던 비용이 의사결정 테이블에 올라옴
echo '부채 항목 → 영향·이자 → 상환 우선순위'- 부채 항목마다 "이자(영향)"를 정량화한다 — "변경당 +3일", "분기 14회 수작업"처럼. 숫자가 있어야 기능과 우선순위 경쟁에서 밀리지 않는다
- 운영 부채(낡은 의존성·미적용 패치)는 보안 리스크와 직결 → 시맨틱 버저닝의 MAJOR 점프 위험과 함께 상환 우선순위를 높인다
- reactive(터지면 대응)만 반복되면 부채가 누적 중인 신호 — 매 스프린트 고정 비율(예: 20%)이 0으로 수렴하지 않는지 점검
- 리팩터링 PR이 테스트 없이 올라오면 위험(테스트 전략) — "리팩터링 전 테스트 먼저"가 안전장치. 테스트 없는 코드의 리팩터링은 부채를 또 만들 수 있다
상황: 매 분기 "이번엔 기능이 급하니 리팩터링은 다음에"가 반복됩니다. 2년 뒤, 작은 버튼 하나 바꾸는 데도 며칠이 걸리고, 변경마다 예상 못 한 곳이 깨지며, 신규 입사자는 코드를 이해하지 못합니다.
원인: 부채 상환을 항상 후순위로 밀어 0%가 됐습니다. 기능의 단기 가치는 보이고 부채의 비용은 안 보여서, 매번 기능이 이깁니다. 그 결과 부채가 복리로 쌓여 변경 속도가 붕괴했습니다(추정과 우선순위에서 본 '운영비 누락'의 장기 버전).
진단:
□ 최근 N스프린트에 부채/리팩터링 항목이 실제로 완료됐나? (0이면 위험)
□ 같은 영역의 버그·회귀가 반복되나? (부채의 증상)
□ 기능 추정이 점점 커지나? (예전 2일 → 지금 1주)
해결: (1) 매 스프린트 고정 비율(예: 20%) 을 부채 상환·리팩터링·테스트 보강에 배정하고, 이를 '협상 불가' 항목으로 보호. (2) 부채를 로드맵과 이슈 트래킹 이슈로 가시화하고 '이자(영향)'를 정량화해 기능과 동등하게 우선순위 경쟁. (3) "보이스카우트 룰" — 코드를 만질 때마다 조금씩 정리. 부채는 없앨 수 없지만, 꾸준히 갚으면 통제 가능합니다. PM이 부채를 '비용'으로 다루는 것이 장기 개발 속도의 핵심입니다.
심화 — 상환률을 채워도 빨라지지 않는 이유
심화: 부채 지표가 목표가 되는 순간 — 점수 게임과 핫스팟
부채를 가시화하고 20%를 배정했는데도 개발 속도가 회복되지 않는 팀이 있습니다. 다음 질문은 '얼마나 갚는가'가 아니라 '무엇을 갚는가', 그리고 부채 지표 자체가 왜곡되는 경로입니다.
- 정적 분석 점수를 KPI로 삼으면 점수 게임이 시작됩니다: 분석 도구의 등급·경고 수를 목표로 걸면, 고치기 쉬운 경고(미사용 import·네이밍·중복 상수) 수천 건을 소탕해 점수는 오르지만, 정작 이자가 큰 구조 부채(얽힌 모듈·순환 의존·테스트 부재)는 그대로 남습니다. 커버리지 80% 함정(테스트 전략)과 같은 왜곡이 부채 영역에서 반복되는 것입니다.
- 갚을 곳은 핫스팟이 정합니다: 이자는 '변경 빈도 × 복잡도'에서 나옵니다. Git 이력에서 자주 바뀌는 파일과 복잡도 높은 파일의 교집합(핫스팟)을 뽑으면 상환 우선순위가 데이터로 나옵니다 — 거의 안 바뀌는 코드의 부채는 등급이 나빠도 이자가 0에 가깝습니다.
- 조직 단계에 따라 부채는 전략입니다: 제품·시장 적합성을 찾는 초기 단계에서 과도한 구조화는 오히려 '검증 안 된 코드에 선투자'하는 낭비입니다. 이때의 원칙은 '부채를 지지 마라'가 아니라 '지는 부채를 기록하라' — 살아남은 기능에만 구조를 투자하는 게 맞습니다. 반대로 트래픽·팀이 커진 뒤에도 초기 습관으로 달리면 이자가 조직 전체 속도를 잠식합니다.
- strangler fig에도 함정이 있습니다: 점진 교체는 옳지만, 전환 기간엔 옛 시스템과 새 시스템을 병행 운영하는 이중 비용이 듭니다. '전환 완료 기준과 기한'을 정하지 않으면 병행이 영구화돼, 부채 하나를 갚으려다 시스템 두 벌 유지라는 더 큰 부채를 떠안게 됩니다.
그래서 성숙한 팀은 상환의 성과를 점수가 아니라 결과로 잽니다 — 상환한 영역의 변경 리드타임과 회귀 버그율이 실제로 줄었는가.
상황: 부채 상환 20% 룰을 도입하며 정적 분석 등급을 분기 KPI로 걸었습니다. 6개월간 경고 4,200건이 800건으로 줄고 등급도 C에서 A가 됐습니다. 그런데 기능 하나의 평균 리드타임은 여전히 8일이고, 결제·정산 영역의 회귀 버그도 줄지 않았습니다.
원인: 지표를 목표로 삼자 상환이 쉬운 쪽으로 쏠렸습니다. 20%의 시간이 '경고로 잘 잡히는' 미사용 코드·네이밍 정리에 쓰였고, 도구가 잘 못 잡는 진짜 이자 — 결제 모듈의 얽힌 의존, 테스트 없는 정산 로직 — 는 손대지 않았습니다. 점수는 부채의 총량이 아니라 '도구가 셀 수 있는 부채'만 셉니다.
진단: 상환된 파일 목록과 Git 변경 빈도를 교차해 봅니다. 6개월간 고친 파일의 대부분이 최근 반년간 변경이 거의 없던 코드라면, 이자가 없는 부채만 갚은 것입니다. 반대로 변경이 가장 잦은 상위 파일들의 복잡도·테스트 유무를 보면 진짜 핫스팟이 드러납니다.
해결: (1) 정적 분석 점수를 KPI에서 참고 지표로 강등하고, 상환 대상을 핫스팟(변경 빈도 × 복잡도) 순으로 선정합니다. (2) 상환 효과를 점수가 아니라 해당 영역의 변경 리드타임·회귀율로 측정해 로드맵과 이슈 트래킹 이슈에 전후 수치를 남깁니다. (3) 20% 시간의 사용처를 스프린트 리뷰에서 공개해 '만만한 부채'로의 쏠림을 팀이 스스로 감시합니다. 부채 상환도 투자입니다 — 수익률(이자 감소)이 없는 상환은 그냥 비용입니다.
인프라/SRE로서 '운영 부채'는 당신의 일상과 직결됩니다 — 낡은 의존성(보안), 미적용 패치, 반복 수작업(toil), 모니터링 사각, 쌓인 기능 플래그가 장애와 야근을 만듭니다. 이를 로드맵과 이슈 트래킹에서 본 것처럼 이슈로 집계해 "인증서 수동 갱신 분기 14회 → 자동화 시 14건 toil 제거" 같은 정량 근거로 상환을 정당화합니다. PM은 기술 부채를 '개발팀의 게으름'이 아니라 '관리해야 할 비용'으로 이해하고, 매 스프린트 상환 비율을 보호하며, 리팩터링의 가치를 '미래 속도 회복'으로 이해관계자에게 번역합니다. 부채를 외면하는 조직은 빠른 게 아니라 빚으로 달리는 것입니다.
이것으로 품질·부채를 다뤘습니다. 다음 모듈에서는 운영의 신뢰성을 지표로 관리하는 SLO·에러버짓과 장애 대응 문화를 다룹니다.
실전 랩으로 손에 익히기: 기술부채·리팩터링 실습 — 기술부채를 식별·우선순위화하고 리팩터링 전략을 세웁니다.