4.5 기술 부채 측정

개요 및 동기

Ward Cunningham이 만든 은유인 기술 부채는 과거 지름길의 축적된 비용, 즉 무언가를 더 빨리 출시했지만 그 이후 코드베이스를 변경하기 더 어렵게 만든 편의적인 결정을 서술하며, 이는 금융 부채가 나중의 이자 비용으로 지금 지출할 수 있게 해 주는 것과 같은 방식이다. 모든 코드베이스는 어느 정도의 기술 부채를 지니며, 그것이 자동으로 실패인 것은 아니다. 그 은유의 진짜 가치는 부채를 부끄러운 비밀이나 피할 수 없는 영구적인 부담이 아니라 관리 가능한 트레이드오프로 프레이밍한다는 것이다. 이 주제는 그것을 모든 엔지니어가 감지하지만 아무도 증거로 행동할 수 없는, 막연하고 영원히 우선순위가 낮은 걱정으로 남겨 두는 대신 측정을 통해 그 트레이드오프를 눈에 보이고 관리 가능하게 만드는 것을 다룬다.

이 주제에 앞선 주제들, 즉 복잡도(4.1), 커버리지(4.2), 처닝과 핫스팟(4.3), 정적 분석(4.4)은 각각 기술 부채의 한 면을 드러낸다. 이 주제의 역할은 종합이다: 그러한 개별 신호들을, 어떤 자동화된 스캔에도 결코 나타나지 않는 항목들(문서화되지 않은 아키텍처 지름길, 의도적으로 연기된 마이그레이션)과 함께, 단지 그것에 어떤 메트릭도 붙어 있지 않고 계획 회의에서 아무런 옹호자도 없다는 이유만으로 기본값으로 경쟁에서 지는 대신 기능 작업에 맞서 공정하게 투자를 두고 경쟁하는 단일하고 우선순위가 매겨지고 눈에 보이는 백로그로 바꾸는 것이다.

대규모 팀에게 관리되지 않는 기술 부채는 진정으로 위험하고 과소평가하기 쉬운 방식으로 복합된다: 모든 새로운 지름길은 다음 변경을 약간 더 어렵게 만들며, 이는 더 많은 지름길에 대한 압박을 만들고, 그것은 더욱 복합된다. 여러 해에 걸쳐 시스템을 유지하는 엔터프라이즈와 정부 조직은 이 복합 효과에 특히 노출되어 있으며, 이 주제의 핵심 권장 사항인 눈에 보이고, 정량화되고, 우선순위가 매겨진 부채 백로그는 조직이 위기로 표류하는 대신 실제로 그 트레이드오프를 의도적으로 관리할 수 있게 하는 메커니즘이다.

핵심 원칙

기술 부채는 관리 가능한 트레이드오프를 위한 의도적인 은유이지, 부끄러운 비밀이 아니다. 알면서 떠맡은 일부 부채는 합리적인 비즈니스 결정이다.
측정되지 않은 부채는 기본값으로 기능 작업에 맞선 우선순위 지정 경쟁에서 진다, 그것이 덜 중요해서가 아니라 눈에 보이는 옹호자가 없기 때문이다.
의사 결정자가 저울질할 수 있는 용어로 부채를 정량화하라: 고치는 비용 대 그것을 보유하는 비용. 막연한 “코드가 지저분하다”는 주장은 좀처럼 구체적인 기능 요청에 맞서 잘 경쟁하지 못한다.
부채는 복합된다. 모든 새로운 지름길은 미래의 변경을 조금씩 더 어렵게 만들며, 그 효과는 관리되지 않으면 가속화된다.
모든 부채를 갚아야 하는 것은 아니다. 일부는 그것을 고치는 비용이 그것과 함께 사는 비용을 초과한다면 무기한으로 보유할 가치가 있다.

권장 사항

눈에 보이는 단일한 기술 부채 백로그를 구축하라

이 부의 앞선 주제들로부터의 신호, 즉 복잡도 이상치, 낮은 뮤턴트 제거율 영역, 핫스팟, 미해결 정적 분석 발견 사항을, 오직 사람만이 식별할 수 있는 부채 항목(아키텍처 지름길, 연기된 의존성 업그레이드, 문서화되지 않은 임시방편)과 함께, 당신의 기능 백로그와 동일한 엄격함과 가시성으로 추적되는 하나의 눈에 보이는 백로그로 통합하라. 개별 엔지니어의 기억이나 흩어진 코드 코멘트에만 존재하는 부채는 우선순위 지정 목적상 사실상 존재하지 않는다.

각 부채 항목의 비용과 보유 비용을 정량화하라

각 항목에 대해 두 가지 수치를 추정하라: 그것을 고치는 비용(엔지니어링 시간, 수정 자체의 위험)과 그것을 고치지 않고 보유하는 비용(관련 작업이 얼마나 더 느려지는지, 얼마나 많은 추가적인 결함 위험을 지니는지, 얼마나 많은 다른 작업을 막는지). 금융 부채 은유 자체의 논리에서 직접 빌려온 이 프레이밍은 의사 결정자에게 추상적이고 정량화되지 않은 불만이 아니라 기능 작업의 비용과 기대 가치에 맞선 실제 비교 근거를 준다.

나이나 가장 목소리 큰 옹호자가 아니라 영향으로 우선순위를 정하라

보유 비용과 영향을 받은 코드가 얼마나 자주 건드려지는지(주제 4.3의 처닝 데이터가 여기서 직접 유용하다)의 조합으로 부채 항목의 순위를 매겨라: 코드베이스에서 드물게 수정되는 구석에 있는 항목은, 아무리 불쾌하더라도, 당신의 가장 활발한 개발의 경로에 직접 자리한 것보다 훨씬 덜 중요하다. 어느 항목이 백로그에 가장 오래 있었는지나 어느 엔지니어가 가장 끈질기게 옹호하는지에 근거해 우선순위를 정하고 싶은 유혹을 물리쳐라. 둘 다 실제 비즈니스 영향과 신뢰성 있게 상관관계가 없다.

부채 개선을 위해 전용의 보호된 역량을 배분하라

모든 계획 주기에서 들어오는 모든 기능 요청에 맞서 항목별로 경쟁해야 하는 부채 백로그는 일관되게 지는 경향이 있는데, 기능 작업은 보통 더 명확하고 더 즉각적인 비즈니스 옹호자를 가지기 때문이다. 부채 개선을 위해 특별히 보호된 엔지니어링 역량의 비율을 배분하라, 흔한 패턴은 10%에서 20% 사이다. 매 스프린트마다 새로 협상하는 것이 아니라 미리 결정하여, 부채 갚기가 위기의 여파 속에서만이 아니라 당연한 일로 일어나게 하라.

일부 부채를 영구적인 것으로 받아들이고 명시적으로 그렇게 말하라

모든 항목이 능동적인 개선 계획에 속하는 것은 아니다. 특히 안정적이고, 드물게 건드려지며, 곧 은퇴할 시스템의 코드에서, 고치는 비용이 무기한으로 항목을 보유하는 비용을 진정으로 초과하는 곳에서는, 그 결정을 명시적으로 문서화하고 그 지속적인 존재가 실제로 결코 일어나지 않을 작업을 조용히 암시하는 능동적인 백로그에 무기한으로 앉아 있게 두는 대신 그 항목을 의도적으로 우선순위가 낮은 범주로 옮겨라.

트레이드오프: 장단점

접근법	장점	단점
공식적인 부채 추적 없음	오버헤드 없음	부채가 기본값으로 우선순위 지정 경쟁에서 짐; 보이지 않게 복합됨
비공식적이고 즉흥적인 부채 인식	낮은 오버헤드, 어느 정도의 가시성	일관성 없음; 개인의 기억과 옹호에 의존함
공식적이고 정량화된 부채 백로그	투자를 위해 공정하게 경쟁함; 정보에 입각한 트레이드오프를 가능하게 함	지속적인 유지 보수와 정량화 규율이 필요함
보호되고 전용된 개선 역량	갚기가 반응적으로만이 아니라 일관되게 일어나도록 보장함	단기적으로 기능 작업에 이용 가능한 역량을 줄임

핵심 긴장은 즉각적인 전달 압박 대 장기적인 유지보수성이다. 기능 작업은 거의 항상 부채 개선보다 더 명확하고 더 즉각적인 비즈니스 옹호자를 가지며, 이는 그 누적 비용이 높을 때조차 부채가 모든 개별 우선순위 지정 결정에서 지는 구조적 압박을 만든다. 보호되고 사전 배분된 역량을 통해 부채 개선을 항목별 경쟁에서 완전히 제거하여, 그 트레이드오프가 모든 단일 계획 주기에서 재검토되고 보통 지는 것이 아니라 의도적으로 그리고 사전에 결정되게 함으로써 이 긴장을 해결하라.

팀과 논의할 질문

우리는 단일하고 눈에 보이는 기술 부채 백로그를 가지고 있는가, 아니면 부채 인식이 대체로 개별 엔지니어의 머릿속에 사는가? 정직한 답이 후자라면, 그것이 이 주제가 가장 먼저 메우라고 권장하는 단일한 가장 큰 간극이다.
우리의 상위 부채 항목에 대해, 우리는 그 고치는 비용과 보유 비용을 기능 요청에 맞서 공정하게 비교할 만큼 충분히 구체적인 용어로 서술할 수 있을까? 그럴 수 없다면, 실제 현재 항목을 사용해 그룹 연습으로 이 정량화를 연습하라.
우리의 엔지니어링 역량 중 실제로 몇 퍼센트가 부채 개선으로 가고 있으며, 그 퍼센트는 의도적으로 결정되었는가, 아니면 단지 기능 작업이 배분된 후 남는 것인가? 당신의 실제 최근 스프린트를 보고 인상에 의존하는 대신 실제 수치를 계산하라.
우리의 부채 백로그는 진정한 비즈니스 영향으로 우선순위가 매겨지는가, 아니면 가장 끈질기게 제기되거나 가장 오래 앉아 있는 항목으로 우선순위가 매겨지는가? 당신의 현재 우선순위 지정을 처닝 데이터(주제 4.3)에 비추어 교차 참조하고 둘이 일치하는지 확인하라.
능동적인 백로그에 무기한으로 모호하게 앉아 있게 두는 대신 영구적인 것으로 명시적으로 받아들여야 할 부채 항목은 무엇인가? 고치는 비용이 진정으로 보유 비용을 초과하는 적어도 하나의 실제 항목을 식별하고, 그것을 명시적으로 우선순위가 낮은 상태로 옮기는 것을 논의하라.
우리의 부채 백로그는 지난 1년 동안 어떻게 바뀌었는가, 자랐는가, 줄었는가, 아니면 평평하게 유지되었는가, 그리고 그 추세는 우리의 직관과 일치하는가? 단일 스냅샷만 보는 대신 시간에 따라 이것을 추적하라. 그 추세는 흔히 어느 주어진 순간의 절대적인 크기보다 더 많은 정보를 준다.

분야별 관점

스타트업. 의도적이고 정보에 입각한 부채는 흔히 이 단계에서 합리적인 전략이다: 가설을 검증하기 위해 빠르게 출시하면서, 제품이 입증되면 특정 지름길을 다시 살펴보겠다는 명확한 계획을 가지는 것은 실패가 아니라 정당한 거래다. 위험은 코드베이스가 성장함에 따라 어떤 지름길이 의도적이고 되돌릴 수 있는 것이었는지와 어느 것이 조용히 영구적이고 검토되지 않은 부채가 되었는지를 놓치는 것이다.

중소기업. 당신의 알려진 지름길과 그 대략적인 고치는 비용을 이름 붙인, 비공식적일지라도, 단순하고 공유된 목록이 보통 이 규모에서 충분하다. 채택할 가치가 있는 주된 규율은 그것이 조용히 축적되고 친숙함을 통해 보이지 않게 되도록 두는 대신 그 목록을 주기적으로 다시 살펴보는 것이다.

엔터프라이즈. 보호되고 사전 배분된 개선 역량은 여기서 가장 중요한데, 부채와 기능 작업 사이의 개별 우선순위 지정 경쟁은 구조적 균형추 없이는 수십 개 팀에 걸쳐 동시에 신뢰성 있게 기능을 선호하기 때문이다. 포트폴리오 수준의 투자 결정을 위해 팀 간에 부채 항목을 공정하게 비교할 수 있도록 조직 전체에서 부채 정량화 관행을 표준화하라.

정부. 장수명 시스템은 위기가 그 문제를 강제할 때까지 아무런 공식적인 부채 추적도 없이 수년이나 수십 년에 걸친 점진적이고 개별적으로 합리적인 요구 사항 변경을 통해 부채를 축적한다. 정량화되고 눈에 보이는 부채 백로그는 막연한 “시스템이 오래되었다”는 주장을 투자에 대한 구체적이고 비용이 매겨진 사례로 바꾸기 때문에 감독 기구에 현대화 예산을 정당화하기 위한 진정으로 설득력 있는 도구다.

사례

엔터프라이즈. 한 통신 회사의 청구 플랫폼은 엔지니어들이 회고에서 아무런 후속 조치 없이 일상적으로 “청구 엔진은 엉망이다”고 언급하면서, 10년 넘게 비공식적으로 인정되었지만 결코 공식적으로 추적되지 않은 기술 부채를 축적해 왔다. 새로운 엔지니어링 이사는 모든 팀에 각 항목에 대한 수정 비용과 보유 비용을 추정하는 정량화된 부채 백로그를 구축하도록 요구했고, 향후 부채 개선을 위해 고정된 15%의 엔지니어링 역량을 배분했다. 1년 안에, 개수로는 전체 백로그의 작은 부분을 나타내는 가장 높은 보유 비용의 상위 다섯 항목이 해결되었고, 청구 관련 배포에 대한 변경 실패율(주제 2.10)이 측정 가능하게 개선되었으며, 이는 임의의 순서로 백로그를 거쳐 가는 대신 가장 높은 보유 비용 항목을 먼저 목표로 삼는 것의 불균형한 영향을 입증했다.

정부. 20년도 더 전에 원래 구축된 한 국가 통계 기관의 핵심 데이터 처리 시스템은 상당 부분이 취약하고 잘 이해되지 않는다는 직원들 사이의 광범위한 비공식적인 인정에도 불구하고 결코 공식적인 부채 평가를 받은 적이 없었다. 정적 분석 발견 사항, 핫스팟 데이터, 가장 오래된 구성 요소를 이해하는 몇 안 되는 남은 엔지니어와의 인터뷰를 결합한 구조화된 부채 평가는 다년간의 현대화 예산 요청을 직접 뒷받침하는 정량화되고 우선순위가 매겨진 백로그를 만들어 냈다. 결정적으로, 그 평가는 또한 여러 안정적이고 드물게 건드려지는 레거시 구성 요소를 변경하지 않고 두는 것이 합리적이라고 명시적으로 식별하여, 불필요하게 광범위하고 비싼 전체 시스템 재작성을 피하고 대신 데이터가 가장 높은 지속적인 비용을 지닌다고 보여 준 특정 영역에 목표를 겨냥한 투자를 선호했다.

비즈니스 사례: 동기, ROI, TCO

기술 부채를 의도적으로 관리하는 것의 수익은 예방된 복합 비용이다: 다뤄지지 않은 모든 지름길은 미래의 변경을 조금씩 더 어렵게 만들며, 그 효과는 개입 없이는 가속화되어, 결국 단순한 변경조차 느리고 위험해지는 매우 취약한 코드베이스를 만들어 낸다. 위의 통신 사례는 그 수익을 구체적으로 보여 준다: 가장 높은 보유 비용 항목 소수에 목표를 겨냥한 것은 그 항목들이 나타낸 전체 백로그의 적당한 부분에 불균형한 측정 가능한 전달 및 품질 개선을 만들어 냈다.

총 소유 비용은 개선에 배분된 보호된 역량이며, 전형적으로 엔지니어링 시간의 10%에서 20%이고, 이는 단기적으로 기능 속도와 경쟁하는 실재하고 눈에 보이는 비용이다. 그 비용은 치를 가치가 있는데, 대안, 즉 관리되지 않고 복합되는 부채는 결국 다뤄지지 않은 특정 항목뿐 아니라 전체 코드베이스에 걸쳐 느려진 전달과 상승된 결함률에서 훨씬 더 많은 비용이 들기 때문이다.

안티패턴과 함정

눈에 보이고 추적되는 부채 백로그 없음: 부채가 기본값으로 우선순위 지정 경쟁에서 지고 보이지 않게 복합된다.
막연하고 정량화되지 않은 부채 주장: 계획에서 구체적이고 정량화된 기능 요청에 맞서 좀처럼 잘 경쟁하지 못한다.
영향이 아니라 나이나 옹호 물량으로 부채 우선순위 정하기: 제한된 개선 역량을 잘못 이끈다.
개선을 위한 보호된 역량 없음: 부채 갚기가 일상적이고 의도적인 관행으로서가 아니라 위기 이후에만 반응적으로 일어난다.
모든 부채를 똑같이 고칠 가치가 있는 것으로 취급하기: 높은 보유 비용의 항목이 다뤄지지 않은 채 남아 있는 동안 낮은 영향의 항목에 노력을 낭비한다.
그것이 영구적이라고 결코 결정하지 않은 채 능동적인 백로그에 부채가 무기한으로 앉아 있게 두기: 실제로 결코 일어나지 않을 미래의 작업을 암시하고 진정한 우선순위 지정을 어지럽힌다.

성숙도 모델

1단계, 시작: 기술 부채가 추적되는 백로그나 정량화 없이 비공식적으로 논의되며, 그것은 일관되게 기능 작업에 진다.
2단계, 개발: 일부 팀이 비공식적으로 부채를 추적하지만, 일관된 정량화, 팀 간 가시성, 혹은 보호된 개선 역량이 없다.
3단계, 표준화: 조직 전체에서 눈에 보이고 정량화된 부채 백로그가 존재하며, 보호된 개선 역량이 일관되게 배분된다.
4단계, 관리: 부채 항목이 측정된 영향(처닝과 결합된 보유 비용)으로 우선순위가 매겨지며, 영구적으로 받아들여진 부채는 모호하게 남겨지는 대신 명시적으로 문서화된다.
5단계, 조율: 조직은 목표를 겨냥한 부채 개선으로 거슬러 올라가는 구체적이고 측정 가능한 전달이나 품질 개선을 제시할 수 있으며, 부채 관리는 기능 작업과 나란히 엔지니어링 투자 결정에 대한 일상적이고 신뢰받는 입력이다.

논의를 위한 아이디어

지금 우리의 단 하나의 가장 높은 보유 비용 부채 항목은 무엇이며, 우리는 그것을 정량화할 수 있을까?
오늘날 우리의 역량 중 실제로 몇 퍼센트가 부채 개선으로 가는가?
백로그에 모호하게 남겨 두는 대신 영구적인 것으로 명시적으로 받아들여야 할 부채 항목은 무엇인가?
지난 1년 동안 우리의 부채 백로그는 자랐는가, 줄었는가, 아니면 평평하게 유지되었는가?
정량화된 부채 평가는 우리의 현재 비공식적인 인식이 놓치고 있는 무엇을 드러낼까?

핵심 요약

기술 부채는 관리 가능한 트레이드오프이지, 부끄러운 비밀이 아니다. 그것을 막연하고 영원히 우선순위가 낮은 관심사로 남겨 두는 대신 정량화하라.
각 항목이 기능 작업에 맞서 공정하게 경쟁할 수 있도록 고치는 비용 대 보유 비용을 정량화하라.
나이나 옹호 물량이 아니라 영향(처닝과 결합된 보유 비용)으로 우선순위를 정하라.
그렇지 않으면 부채가 기능 작업에 맞선 항목별 경쟁에서 신뢰성 있게 지기 때문에, 사전에 결정된 보호되고 전용된 개선 역량을 배분하라.
모호하게 능동적인 백로그에 남겨 두는 대신, 고치는 비용이 보유 비용을 초과하는 곳에서 일부 부채를 명시적으로 영구적인 것으로 받아들여라.

참고 문헌 및 추가 자료

Cunningham, Ward. “The WyCash Portfolio Management System.” OOPSLA experience report, 1992.
Kruchten, Philippe, Robert Nord, and Ipek Ozkaya. Managing Technical Debt: Reducing Friction in Software Development. Addison-Wesley, 2019.
Fowler, Martin. Refactoring: Improving the Design of Existing Code. Addison-Wesley, 1999.
Tornhill, Adam. Your Code as a Crime Scene. Pragmatic Bookshelf, 2015.