기술 부채 계산: 속도 기반 vs. 이슈 기반 vs. 품질 기반 측정 설명

금리가 157% 인상되었습니다!

아니요, 저는 연준의 최근 결정이 아니라 Fictional Inc.가 플랫폼 버전 3.0을 출시한 후 직면한 둔화에 대해 이야기하고 있습니다.

다행스럽게도 제품 출시는 믿을 수 없을 정도로 성공적이었고 수익 성장이 빠르게 증가하기 시작했지만 이제 출시의 일부로 도입한 기술 부채를 어떻게 처리할 것인지 생각해야 합니다.

새 릴리스의 일부로 도입된 새로운 기술 부채는 이자율을 높이고 향후 팀이 직면하게 될 침체를 증가시키는 것으로 생각할 수 있습니다.

(여기서 기술 부채 개념에 대해 꽤 잘 알고 있다고 가정하겠습니다. 하지만 속도를 높이기 위해 다시 한 번 복습이 필요한 경우 여기에서 빠르게 뇌관 )

좋아, 아마도 엔지니어링 관리자가 기술 부채에 대해 이렇게 말하는 것을 듣지 못할 것입니다.

그런데 왜 안되죠?

지속적인 영향을 측정하고 정량화할 수 있습니다. 기술 부채는 매우 중요합니다 이를 해결하기 위해 실행 가능한 계획을 세우고 싶다면.

기술 부채에 대해 생각할 때, 이자는 기존 기술 부채 수준에 대한 현재 및 미래 개발에 손실된 시간의 양입니다.

이는 원금을 상환하기 위한 향후 결정( 부채 를 담당하는 코드 재작성, 리팩토링 또는 수정 비용)을 고려할 때 고려해야 할 부채의 중요한 부분이라는 것을 의미합니다. 충분히 높습니다.

기술 부채의 건강한 수준은 무엇입니까?

기술 부채로 인해 분명히 새로운 개발 속도가 느려지지만, 그렇다고 해서 모든 곳에서 기술 부채를 해결해야 한다는 의미는 아닙니다. 기존 코드를 다시 작성하거나 리팩토링하는 데는 상당한 비용이 들 수 있습니다. 따라서 우리는 이자(앞으로의 진행 속도를 늦추는 금액)가 원금을 초과하는 경우에만 기술 부채 원금을 갚고 싶습니다.

한 가지 명백한 문제가 즉시 발생합니다. 원금은 고정된 시간 단위(수정/다시 작성하는 데 소요되는 시간)이지만 이자는 시간당 손실된 시간 비율입니다. 이를 설명하기 위해 우리는 영향 간격 , 즉 기술 부채로 인한 향후 둔화가 재작성 비용을 초과하는지 여부를 고려하는 시간이라는 개념을 도입해야 합니다. 귀하가 중요하게 생각하는 영향 간격은 귀하의 회사, 일반적인 계획 프로세스, 단계 또는 코드베이스의 수명 주기에 따라 크게 달라집니다. 하지만 저는 개인적으로 일반적으로 영향 간격을 3개월로 봅니다. 회사 초기 단계에서는 1년 이상의 기간을 기준으로 모든 것을 살펴보는 것이 너무 광범위하지만 나중에 살펴보겠지만 2~3개월보다 짧은 기간은 기술 부채의 영향을 크게 과소평가하게 됩니다.

이는 다음과 같은 경우 기술 부채 수준을 해결할 가치가 없음을 의미합니다.

예를 들어, 소규모 프로젝트에 기술 부채가 있어 주당 2시간씩 속도가 느려지는 경우 해당 부채를 리팩터링하는 데 4일이 걸리고 3개월의 영향 간격을 고려하면 그렇게 하지 않습니다. 아직 그 빚을 갚을 시간을 보내세요.

이제 이것은 실제로 기술 부채의 건전한 수준에 대한 답이 아닙니다. 왜냐하면 팀의 엄청난 둔화에 직면하는 것이 건전하지 않다는 데 우리 모두가 동의할 수 있기 때문입니다. 대신 이제 우리는 재작성 및 리팩토링에 집중해야 할 때와 하지 말아야 할 때를 빠르게 결정할 수 있는 방법을 갖게 되었습니다. 우리는 이 기사의 뒷부분에서 실제로 건강한 부채 수준이 무엇인지 살펴보겠습니다.

기술 부채를 어떻게 측정합니까?

기술 부채 이자율을 결정하려면 우리가 내린 다양한 결정으로 인해 속도가 얼마나 느려지는지 파악해야 합니다. 불행하게도 개발 속도가 얼마나 느려지는지 추적할 수 있는 명확하거나 간단한 방법은 없습니다. 하지만 좋은 근사값을 얻기 위해 취할 수 있는 세 가지 접근 방식이 있습니다.

속도 기반 측정

속도 저하를 코드베이스의 여러 섹션에 연결하는 가장 직접적인 방법은 프로젝트의 여러 섹션에서 시간이 지남에 따라 속도가 어떻게 변하는지 살펴보는 것입니다. 코드베이스의 여러 영역을 살펴보면 다양한 섹션에서 변형을 식별하기 시작할 수 있습니다(예: 이 분석 섹션을 다루는 개발은 다른 것보다 3배의 시간이 걸립니다). 시간이 지남에 따라 지역의 변화를 살펴보면 새로운 개발이 향후 개발 속도에 어떤 영향을 미치는지 어느 정도 알 수 있으며 팀이 다루고 있는 관심 수준을 알 수 있습니다.

예를 들어, 우리가 작업할 4개의 서로 다른 영역이 있는 상대적으로 간단한 프로젝트가 있는 경우 시간이 지남에 따라 속도가 어떻게 변하는지 확인할 수 있습니다(여기서는 스토리 포인트/개발자 월 단위로 속도를 추적합니다).

기술 부채 영향의 속도 기반 측정

여기에서 우리는 D가 유사하게 복잡한 작업을 수행하는 데 다른 영역보다 작업하는 데 항상 최대 3배의 시간이 걸렸다는 것을 알 수 있습니다. 이는 코드베이스의 다른 모든 섹션보다 관심도가 3배나 높다는 것을 의미합니다. B는 A & C와 상대적으로 동등했지만 4개월차부터 갑자기 2배의 시간이 소요되는 속도로 뛰어올랐습니다. 이는 우리가 B의 이전 금리에 비해 이자율을 두 배로 늘리는 부채를 도입했음을 의미합니다.

한 가지 강조해야 할 점은 전체 코드베이스에 대한 이자율이 아니라 개별 구성 요소/영역에 대한 이자율에 대해 이야기하고 있다는 것입니다. 이는 기술 부채의 증가로 인한 둔화는 일반적으로 문제가 되지 않기 때문입니다. 우리가 하는 모든 일에 영향을 미치는 대신 코드베이스의 한 부분으로 현지화됩니다.

속도 기반 측정과 관련하여 고려해야 할 몇 가지 중요한 주의 사항이 있습니다.

• 속도는 변동이 심할 수 있으며 새로운(또는 기존) 버그, 잘못 정렬된 추정, 기술적 장애물 또는 외부 프로젝트 지연과 같은 기술적 부채와 무관한 요인에 따라 달라질 수 있습니다.

• 추정에는 내재된 불확실성이 어느 정도 존재하며 처음부터 부정확한 척도가 될 수 있습니다.

• 이 데이터를 수집하고 분석하는 것은 까다롭고 시간이 많이 걸릴 수 있습니다.

  
  

속도 기반 측정을 위한 한 가지 빠른 프록시는 엔지니어링 팀에 코드베이스의 각 주요 영역에서 프로젝트/작업을 완료하는 데 걸리는 시간을 상대적으로 추정하도록 요청하는 것입니다. 잘 이해되고 자주 사용되는 영역에 대해 확립된 기준선에 동의한 다음 모든 사람이 서로의 영역을 해당 기준선의 백분율 또는 배수로 추정하도록 합니다. 전체 속도 기반 측정 접근 방식만큼 엄격하지는 않지만 팀의 통찰력과 직관을 기반으로 상대적인 기술 부채 관심도에 대한 빠른 아이디어를 제공할 수 있습니다.

이슈 기반 측정

다른 접근 방식은 프로젝트 내에서 특정 기술 부채 사례를 식별하고 각각의 속도가 얼마나 느려질 수 있는지 추정하는 것입니다. 이 중 일부는 정적 분석 도구와 같은 자동화된 도구를 사용하여 프로젝트의 가독성, 확장성 또는 유지 관리 가능성에 영향을 미칠 수 있는 코드 품질과 관련된 일반적인 문제를 찾는 방식으로 수행될 수 있습니다. 각 문제 유형에 대해 팀이 이러한 유형의 문제를 처리한 경험을 바탕으로 이자 비용(예: 주당 5분 또는 1%)을 할당할 수 있습니다.

그러나 이는 문제를 일으키는 기술 부채의 하위 집합만 포착합니다. 다른 것들은 코드베이스에 더 미묘하거나 맞춤화되며 팀이 코드의 해당 영역에서 적극적으로 작업하는 동안에만 관찰됩니다. 이 경우 특정 문제(코드베이스 영역과 관련)를 기록하고 해당 문제가 개발 속도를 늦추는 데 미치는 예상 영향을 기록하고 싶을 것입니다. 이러한 문제를 추적하려면 GitHub, Jira 등의 문제 백로그에 있거나 특수 목적으로 구축된 기술 부채 문제 추적기를 사용하여 일종의 문제 추적기를 사용하는 것이 좋습니다. 단계 크기 .

이 접근 방식의 몇 가지 단점은 다음과 같습니다.

• 특정 문제와 관련된 예상 시간은 부정확할 수 있습니다.
• 일부 문제는 오랜 기간 동안 쉽게 감지되지 않을 수 있습니다.

품질 기반 측정

코드베이스의 상태를 전반적으로 파악하고, 현재 각 영역의 향후 개발에 영향을 미치는 기술 부채의 양을 추정하는 데 사용할 수 있는 다양한 코드 품질 지표가 있습니다. Sourcery에서는 다음을 살펴보는 경향이 있습니다. 복잡성 , 작업기억 , 메소드 길이는 함수나 클래스 내에서 볼 때 중요한 지표입니다. 하지만 유지 관리 가능성 지수, 문서 및 테스트 적용 범위, 복제율 등과 같은 항목도 볼 수 있습니다.

문제 기반 접근 방식과 유사하게 기술 부채로 인한 현재 진행 중인 개발 둔화 및 향후 개발 둔화에 다양한 점수(또는 전체 품질 또는 상태 점수)의 상대적 영향을 할당할 수 있습니다. 연구에 따르면 복잡성 및 속도뿐만 아니라 코드 품질, 버그 위험, 유지 관리 부하 등과도 강한 음의 상관관계가 있는 것으로 나타났습니다.

예를 살펴보겠습니다. 속도 기반 측정 섹션에서 살펴본 간단한 4부분 코드베이스를 다시 살펴보겠습니다.

표(빨간색으로 강조 표시)에서 이 프로젝트의 문제 섹션을 쉽게 볼 수 있으며 관심 추정치를 계산하는 것은 상대적으로 간단합니다. 다양한 구성 요소의 관심 영향을 간단히 요약하면 됩니다.

이 접근 방식의 몇 가지 단점은 다음과 같습니다.

• 다양한 품질 지표에 대한 관심도 영향 추정치를 정의해야 합니다(일부 기준을 기준으로 삼고 싶지만 코드베이스에 따라 상당히 달라질 수 있습니다). 이를 위해 속도 기반 측정을 살펴보고 이를 품질과 연결하는 것이 좋습니다.
• 품질 지표 자체는 불완전하며 언어마다 크게 다릅니다 .

이 품질 기반 측정 접근 방식은 우리가 살펴본 세 가지 접근 방식 중 정확도가 가장 낮지만 시간이 지남에 따라 프로젝트의 다양한 영역을 전체적으로 살펴보는 데 매우 효과적입니다. 이 접근 방식을 방금 논의한 문제 기반 접근 방식과 결합하여 프로젝트의 각 섹션에서 일반적인 품질 및 상태 문제를 추적하는 동시에 특정 문제 추적의 균형을 맞출 수 있습니다.

코드베이스 상호작용 빈도 살펴보기

이러한 세 가지 접근 방식 모두에 대해 우리는 코드베이스의 해당 섹션을 실제로 접촉하는 빈도에 대해 코드베이스의 여러 섹션에 미치는 영향을 매핑하는 방법이 필요합니다. 우리 프로젝트에서 처리하기 힘든 부분이 있지만 더 이상 아무도 건드리지 않는 부분이 있다면 그것은 실제로 진행 중인 기술 부채에 큰 영향을 미치지 않습니다. 반대로, 매일 기여하는 코드베이스 섹션의 작지만 지속적인 속도 저하로 인해 매우 빠르게 엄청난 시간 손실이 발생할 수 있습니다.

이를 설명하려면 프로젝트의 각 영역이 얼마나 자주 기여되는지 살펴봐야 합니다. 여기에서 취할 수 있는 몇 가지 접근 방식이 있습니다. Git 기록을 살펴보고 다음과 같은 보다 집중적인 도구를 사용하여 가장 자주 접촉되는 영역을 파악합니다. 코드씬 더 이해하기 쉬운 역사적 기여 데이터를 얻거나 향후 계획과 우선 순위를 살펴보고 앞으로 몇 달 동안 우리 팀이 대부분의 시간을 보낼 곳을 이해함으로써 미래 지향적인 접근 방식을 사용합니다.

데이터를 얻는 방법에 관계없이 코드베이스의 각 섹션과 상호 작용하는 데 소요되는 시간의 비율을 분석할 수 있습니다. 이것을 이미 결정한 Interest 기여와 결합하면 앞으로 코드베이스의 각 섹션을 처리할 때 속도가 얼마나 느려질 것으로 예상되는지 정확히 알 수 있습니다.

앞선 예를 계속해서 설명하면, 앞으로 3개월 동안 작업할 모든 프로젝트를 미래 지향적으로 보고 이를 코드베이스의 각 영역에서 소비한 시간이라고 자신있게 추정할 수 있다면( 이것은 매우 간단한 프로젝트라는 것을 기억하십시오):

이제 이를 속도 기반 접근 방식과 품질 측정 기준 기반 접근 방식에서 얻은 관심도 추정치에 다시 연결하여 속도가 가장 많이 느려지는 위치를 파악할 수 있습니다.

여기서 우리는 이전에 속도 기반 측정을 살펴볼 때 섹션 B 및 C 작업에서 확인한 속도 저하를 사용하고 이를 사용하여 향후 3개월 동안 기술 부채로 인해 예상되는 시간 손실을 계산합니다. 전반적으로 우리는 빚을 갚기 위해 개발자에게 28개월 이상의 추가 노력을 기울일 것으로 예상합니다. 이 접근 방식에서 고려해야 할 중요한 점은 이 모든 것이 상대 속도를 고려한다는 것입니다. 따라서 기본 프로젝트는 사실상 부채가 없는 것으로 간주되며 이는 일반적으로 정확하지 않습니다. 이 접근 방식의 또 다른 문제는 발생할 가능성이 있는 미래 부채 수준의 변동을 고려하지 않는다는 것입니다. 하지만 예측하기 어렵기 때문에 무시하기가 더 쉽습니다.

여기에서는 각 섹션의 코드 품질을 기준으로 일반적인 예상 지연 시간을 파악하고 이를 향후 3개월에 걸쳐 예상했습니다. 전반적으로 우리는 속도법을 사용할 때보다 부채 영향 예측이 훨씬 더 낮다는 것을 알 수 있습니다. 이는 기술 부채를 기반으로 한 둔화 추정치가 속도 사례에서 본 것보다 낮기 때문입니다. 이 경우에는 좀 더 조정이 필요할 수 있습니다! 속도 기반 지표와 마찬가지로 이는 기술 부채의 향후 변화를 고려하지 않습니다. 하지만 두 추정치는 프로젝트의 다양한 섹션을 다시 작성하고 리팩터링하는 우선순위를 결정하는 데 도움이 될 수 있습니다.

이자 및 부채 관리

우리는 기술 부채가 지속적으로 우리에게 얼마나 많은 영향을 미치는지 설명하기 위해 몇 가지 다른 방법을 살펴봤지만 건전한 기술 부채 수준이 무엇인지에 대한 질문에 완전히 답하지 못했습니다.

안타깝게도 정확한 숫자는 없습니다. 단기적으로는 일부 부채를 수락하는 것이 실용적일 수 있습니다. 그러나 장기적으로 우리는 부채를 0에 가깝게 유지하는 것을 목표로 할 것입니다. 지속적인 관심은 매우 큰 비용이 들고 기술 부채는 계속 쌓이기 때문입니다. 그러나 우리는 단지 미미한 이득만 주는 문제를 리팩토링하고 다시 작성하는 데 모든 시간을 소비하고 싶지 않습니다.

앞서 논의한 것처럼 우리는 일반적으로 다음과 같은 코드베이스 영역을 다루는 데 시간을 낭비하고 싶지 않습니다.

그러나 극단적인 경우에는 고칠 비용이 극도로 높은 높은 수준의 부채로 인해 우리의 속도가 크게 느려지는 경우가 발생할 수 있습니다. 이 역시 좋은 상황은 아닙니다.

가장 좋은 접근 방식은 중간에 위치하는 것입니다. 기술 부채 문제를 해결하고 기존 코드를 리팩터링하기 위해 진행 중인 계획에 시간을 할애하세요. 현재 가장 비용이 많이 드는 항목부터 우선순위를 정하세요. 그리고 부채 감소로 인한 수익이 크게 감소할 때까지 이를 계속 추진하십시오.