技術的負債とリリース速度 — 利息を測り返すときを決める

한 줄 요약

기술 부채는 나쁜 것이 아니라 이자가 붙는 대출이다. 초기 제품은 빨리 배우려고 일부러 빌린다. 문제는 이자를 재지 않는 것이다. 배포 기록과 작업 기록에서 이자(계획 밖으로 새는 시간)와 배포 안정성을 재고, 갚는 비용·회수 기간·미뤄지는 기능의 가치를 한 줄에 놓으면 "지금 갚을까" 가 의견이 아니라 계산이 된다.

왜 이게 필요했나

작은 팀은 두 목소리 사이에서 흔들린다. "지금 고치지 않으면 영원히 못 고친다" 와 "고객이 원하는 기능부터 내야 산다". 둘 다 맞는 말이라 회의가 끝나지 않는다. 결론은 대개 목소리가 큰 쪽이 정한다.

마틴 파울러는 기술 부채 글에서 이 은유를 워드 커닝햄이 1992년 OOPSLA 경험 보고에서 만들었다고 적고, 코드의 결함 때문에 기능을 더할 때마다 추가로 드는 노력을 이자, 그 결함을 걷어 내는 노력을 원금으로 설명한다. 그 틀을 그대로 쓰면 된다. 이자가 크고 늘고 있는데 원금이 작다면 갚는 편이 빠르고, 이자가 작다면 그 시간에 기능을 내는 편이 낫다.

어떻게 동작하나

배포 안정성 — DORA 지표. dora.dev 의 지표 안내는 처리량 지표로 변경 리드 타임(버전 관리에 커밋된 변경이 운영에 배포되기까지의 시간)·배포 빈도·실패 배포 복구 시간을, 불안정성 지표로 변경 실패율(배포 직후 즉시 개입이 필요했던 배포의 비율)과 배포 재작업률(운영 사고 때문에 한 계획 밖 배포의 비율)을 든다. 부채가 쌓인 모듈은 흔히 배포가 뜸하고, 실패가 잦고, 복구가 길고, 사고 대응 배포가 많다.

평균보다 중앙값. 리드 타임에는 며칠씩 묵힌 변경 몇 건이 섞인다. 평균은 그 몇 건에 끌려가 전형적인 변경이 얼마나 걸리는지를 가린다. 이 실습은 중앙값과 평균을 나란히 적어 차이를 보게 한다.

이자 재기. 주마다 모듈별로 기록한 '계획 밖 작업 시간'(버그·장애 대응)이 이자다. 평균만 보지 말고 추세를 본다 — 첫 4주와 마지막 4주를 비교해 늘고 있다면, 갚는 결정의 기준은 지난 평균이 아니라 최근 이자여야 한다.

갚을지 판단하기. 이 실습은 다음 순서로 계산한다(모든 값과 규칙은 예시다).

값	계산
절감(시간/주)	최근 이자 × 리팩터링이 줄이는 비율
회수 기간(주)	리팩터링 비용(시간) ÷ 절감
기간 순절감(원)	(절감 × 판단 기간 − 비용) × 시간당 비용
지연 비용(원)	(비용 ÷ 팀 주간 용량) × 기능의 주간 가치

리팩터링하는 동안 팀이 기능을 못 만든다면, 그만큼 기능이 늦어지고 그 기능이 매주 벌었을 가치가 사라진다 — 이것이 지연 비용(cost of delay)이다. 회수 기간이 가장 짧은 후보의 기간 순절감이 지연 비용보다 크면 먼저 갚고, 아니면 기능을 먼저 낸다. '리팩터링이 이자를 70% 줄인다' 같은 추정은 틀릴 수 있으므로, 추정치를 적어 두고 갚은 뒤 실제 이자와 비교하는 것까지가 한 바퀴다.

부채를 어디에 기록하나. 이자를 재려면 계획 밖 작업을 모듈별로 기록해야 한다. 거창한 도구가 필요하지 않다 — 이슈 트래커에 '계획 밖' 표식과 모듈 이름, 쓴 시간만 남기면 주간 합계가 나온다. 기록이 없으면 이자는 '다들 바쁘다' 라는 느낌으로만 존재하고, 느낌은 기능 요청의 숫자를 이기지 못한다.

모든 부채를 갚을 필요는 없다. 곧 버릴 실험 코드, 거의 바뀌지 않는 모듈의 부채는 이자가 0 에 가깝다. 파울러가 말한 대로 이자는 그 코드를 바꿀 때 붙는다. 그래서 갚을 후보는 '지저분한 코드' 가 아니라 '자주 바뀌면서 계획 밖 작업을 만드는 코드' 에서 고른다. 변경 빈도와 계획 밖 작업이 함께 높은 모듈이 첫 후보다.

현장에서 만나는 모습

• 결제 모듈만 건드리면 배포가 실패하고, 복구에 반나절이 걸리고, 매주 금요일이 장애 대응으로 끝난다. 이자는 기록되지 않아 아무도 크기를 모른다.
• "리팩터링하면 빨라진다" 는 말만 있고 얼마나, 언제부터인지 숫자가 없어 매번 기능에 밀린다.
• 반대로, 이자가 거의 없는 오래된 코드를 '보기 싫어서' 고치느라 출시를 한 달 미룬다.

틀렸을 때 알아채는 법

• 리드 타임의 평균과 중앙값이 크게 다르면 긴 꼬리가 있다는 뜻이다. 그 꼬리의 변경들을 따로 열어 원인을 본다 — 리뷰 대기인지, 배포 창을 기다린 것인지.
• 변경 실패율의 분모가 배포 수인지 확인한다. 사고 수나 일수로 나누면 배포가 잦은 팀이 불리해진다.
• 이자 추정에 12주 평균을 썼다면 추세를 함께 본다. 늘고 있는 이자를 평균으로 판단하면 갚을 때를 놓친다.
• 결정 뒤 몇 주가 지나면 계획 밖 작업을 다시 재어 추정과 비교한다. 비교하지 않은 추정은 다음 결정에서도 같은 크기로 틀린다.

다음 실습에서 할 것

12주의 배포·작업 기록으로 서비스별 DORA 지표를 계산하고, 리드 타임의 중앙값과 평균이 왜 다른지 본다. 모듈별 이자와 그 추세를 재고, 리팩터링 후보 두 개의 회수 기간·순절감·지연 비용을 계산해 규칙대로 결정한다. 채점기는 여러분의 함수를 흔든 기록에도 다시 돌린다.