기술 부채 관리

🔄 이전 레슨에서 AI 리뷰 도구를 PR과 CI/CD에 통합했습니다. 지금 당장의 코드 품질은 관리되고 있습니다. 하지만 코드베이스에는 이미 쌓여 있는 문제가 있습니다 — 기술 부채.

기술 부채는 “나중에 고치자"의 총합입니다. 문제는 “나중"이 오지 않으면 이자가 복리로 불어난다는 것.

배울 내용

이 레슨을 마치면 기술 부채를 측정하는 프레임워크를 알고, AI로 핫스팟을 찾으며, 우선순위를 정해서 체계적으로 갚는 전략을 갖추게 됩니다.

기술 부채의 이자 메타포

Ward Cunningham이 만든 이 메타포가 비개발자(PM, 경영진)에게 설명할 때 가장 효과적입니다:

의도적 부채 vs 비의도적 부채

모든 기술 부채가 나쁜 건 아닙니다:

의도적 부채 (Strategic debt):
  "데드라인까지 3일. 이 설계로 가고, 다음 스프린트에 리팩토링하자."
  → 비즈니스 결정. 기록하고 계획적으로 갚으면 OK.

비의도적 부채 (Accidental debt):
  "이렇게 하면 되겠지... (3개월 후) 왜 이렇게 짰지?"
  → 경험 부족이나 시간 압박으로 무의식적으로 쌓임.

의도적 부채는 관리 가능합니다. 비의도적 부채가 진짜 위험합니다 — 얼마나 쌓여 있는지조차 모르니까요.

AI로 핫스팟 찾기

핫스팟이란?

핫스팟 = 변경 빈도가 높으면서 복잡도도 높은 파일.

CodeScene 분석에 따르면 전체 결함의 25~70%가 핫스팟에서 발생합니다. 전체 코드베이스를 리팩토링할 필요 없이, 핫스팟만 개선해도 큰 효과를 봅니다.

# Git 로그에서 변경 빈도가 높은 파일 찾기
git log --format=format: --name-only --since="6 months ago" \
  | sort | uniq -c | sort -rn | head -20

이 명령어로 최근 6개월 동안 가장 많이 수정된 파일 20개를 뽑을 수 있습니다. 여기에 복잡도를 곱하면 핫스팟이 됩니다.

AI에게 핫스팟 분석 요청

다음 파일들의 기술 부채를 분석해주세요.

각 파일에 대해:
1. 순환 복잡도 (Cyclomatic Complexity) 추정
2. 코드 스멜 목록 (이전 레슨의 5대 카테고리)
3. 리팩토링 난이도 (🟢 쉬움 / 🟡 보통 / 🔴 어려움)
4. 예상 효과 (버그 감소, 개발 속도 개선)

우선순위를 정해주세요:
- 높은 효과 + 쉬운 난이도 = 먼저
- 높은 효과 + 어려운 난이도 = 계획적으로
- 낮은 효과 = 나중에 또는 보류

✅ Quick Check: 복잡도가 매우 높지만 2년간 한 번도 수정되지 않은 파일이 있습니다. 핫스팟인가요? (아닙니다. 변경 빈도가 0이면 핫스팟이 아닙니다. 복잡하지만 안정적인 코드는 건드리지 않는 게 최선일 수 있습니다. “If it ain’t broke, don’t fix it.” 리팩토링 리스크 대비 이득이 없습니다.)

기술 부채 갚기 전략

20% 규칙

매 스프린트의 20%를 기술 부채 갚기에 할당합니다:

• 2주 스프린트 = 2일을 부채에 투자
• 100%를 기능 개발에 쓰면 단기적으로 빠르지만, 6개월 후엔 모든 것이 느려집니다

우선순위 매트릭스

SQALE 프레임워크

기술 부채를 시간으로 환산합니다:

기술 부채 = 문제를 고치는 데 필요한 총 시간

예시:
  - 중복 코드 제거: 4시간
  - 테스트 커버리지 추가: 8시간
  - API 설계 개선: 16시간
  ─────────────────────
  총 기술 부채: 28시간 (3.5 인일)

시간으로 환산하면 비개발자에게 설명이 됩니다: “이 부채를 안 갚으면 매주 2시간씩 추가 비용이 발생합니다.”

✅ Quick Check: PM이 “기술 부채 갚는 건 기능 개발이 아니니까 우선순위가 낮다"고 합니다. 어떻게 설득하나요? (이자 메타포를 쓰세요. “지금 8시간 투자하면 앞으로 매주 2시간을 절약합니다. 4주면 본전이고 그 이후는 순이익입니다.” 기술 부채를 시간과 비용으로 환산하면 비즈니스 언어로 대화할 수 있습니다.)

핵심 정리

• 기술 부채는 복리 이자가 붙습니다 — 빨리 갚을수록 비용이 적습니다
• 핫스팟(변경 빈도 × 복잡도)에 집중하면 전체를 리팩토링하지 않아도 큰 효과를 봅니다
• 매 스프린트 20%를 부채 갚기에 할당하는 것이 지속 가능한 비율
• SQALE로 부채를 시간으로 환산하면 PM과 경영진에게 설명할 수 있습니다
• 복잡하지만 안 건드리는 코드는 핫스팟이 아닙니다 — 리팩토링 리스크 대비 이득을 따지세요

다음 레슨

개인의 리뷰 역량과 기술 부채 관리를 다뤘습니다. 다음 레슨에서는 팀 차원 — 리뷰 문화를 구축하고, 표준을 정하고, 코드 리뷰를 성장의 도구로 만드는 방법을 배웁니다.