리팩토링 우선순위 결정: ROI 기반 전략

 "어디부터 리팩토링해야 할까요?"

기술 부채 백로그에 50개가 넘는 항목이 쌓여있습니다. 팀은 모두 리팩토링이 필요하다고 동의하지만, 어디부터 시작해야 할지 모릅니다.

"이것도 중요하고, 저것도 중요해 보이는데..."

PM은 한정된 리소스를 어디에 투자해야 할지 고민합니다. 모든 것을 한 번에 할 수는 없고, 우선순위를 정해야 하는데 기준이 없습니다.

리팩토링 우선순위는 직관이 아닌 데이터로 결정해야 합니다. 제가 직접 경험한 프로젝트에서 복잡한 코드를 2주나 리팩토링했는데, 실제로는 거의 사용되지 않는 코드였습니다. 반면 매일 사용되는 핵심 기능은 간단한 코드였는데 그대로 두었죠. 결과는 시간 낭비였고, 효과는 없었습니다.

하지만 ROI 기반 우선순위 결정은 이 문제를 해결합니다. RICE 스코어링 방법을 활용하면, 데이터 기반으로 가장 효과적인 리팩토링을 선택할 수 있습니다. 오늘은 현장에서 검증된 실전 방법들을 공유해드리겠습니다.

리팩토링 우선순위의 딜레마: "어디부터 시작할까?"

전통적 방식의 함정

많은 팀들이 직관에 의존합니다. "이게 중요해 보이네요"라고 하거나, 위에서 "이거부터 하세요"라고 지시하거나, 최신 것부터 하거나, 어려운 것부터 정리하려고 합니다.

하지만 이런 접근 방식의 문제는 효과가 불확실하고, 리소스 낭비가 발생하며, 비즈니스 가치와 무관할 수 있고, 팀 동의를 얻기 어렵다는 것입니다.

제가 직접 경험한 사례가 있습니다. 한 팀이 복잡한 코드를 2주나 리팩토링했는데, 실제로는 거의 사용되지 않는 코드였습니다. 반면 매일 사용되는 핵심 기능은 간단한 코드였는데 그대로 두었죠. 결과는 시간 낭비였고, 효과는 없었습니다.

RICE 스코어링: 데이터 기반 우선순위 결정

RICE는 Intercom에서 개발한 우선순위 결정 프레임워크입니다. 리팩토링에도 동일하게 적용할 수 있습니다.

RICE는 4가지 요소로 구성됩니다:

1. Reach (도달 범위): 얼마나 많은 코드나 기능에 영향을 미치는가?
2. Impact (영향도): 개선 시 얼마나 큰 효과가 있는가?
3. Confidence (확신도): 이 개선이 정말 효과가 있을 확률은?
4. Effort (노력): 리팩토링에 얼마나 시간이 걸리는가?

계산 공식은 간단합니다. (Reach × Impact × Confidence)를 Effort로 나누면 됩니다. 점수가 높을수록 우선순위가 높습니다.

RICE 점수 계산 방법: 실전 가이드

1. Reach (도달 범위): "얼마나 많은 곳에서 사용되는가?"

해당 코드가 사용되는 기능 수, 일일 호출 횟수, 영향받는 사용자 수, 의존하는 다른 모듈 수를 확인하면 됩니다.

제 경험상, 거의 사용 안 되는 코드(1개 기능)는 0.5점, 가끔 사용되는 코드(2-3개 기능)는 1점, 자주 사용되는 코드(5-10개 기능)는 2점, 매우 자주 사용되는 코드(10개 이상 기능)는 5점, 핵심 기능(전체 시스템에 영향)은 10점을 주면 됩니다.

실제로 사용자 인증 모듈은 모든 기능에서 사용되므로 Reach가 10이고, 리포트 생성 모듈은 관리자만 사용하므로 2점, 테스트 유틸리티는 개발 환경에서만 사용되므로 0.5점이 적절합니다.

2. Impact (영향도): "개선 효과가 얼마나 큰가?"

리팩토링 후 예상 효과, 속도 개선 정도, 버그 감소 정도, 유지보수성 향상 정도를 고려하면 됩니다.

미미한 개선은 0.25점, 작은 개선은 0.5점, 보통 개선은 1점, 큰 개선은 2점, 매우 큰 개선은 3점을 주면 됩니다.

제가 본 프로젝트에서 복잡도를 25에서 10으로 줄인 경우는 매우 큰 개선이어서 Impact가 3이었고, 중복 코드를 제거한 경우는 보통 개선이어서 1점, 변수명만 개선한 경우는 작은 개선이어서 0.5점이 적절했습니다.

3. Confidence (확신도): "이 개선이 정말 효과가 있을 확률은?"

데이터 기반 확신도, 과거 경험 기반, 전문가 의견을 종합해서 평가하면 됩니다.

낮은 확신(추측)은 50%, 보통 확신(일부 데이터)은 80%, 높은 확신(충분한 데이터)은 100%를 주면 됩니다.

SonarQube 데이터로 복잡도를 확인한 경우는 Confidence가 100%이고, 팀 경험 기반 추정은 80%, 직관적 추정은 50%가 적절합니다.

4. Effort (노력): "리팩토링에 얼마나 시간이 걸리는가?"

예상 작업 시간(인-일 또는 인-주), 복잡도 기반 추정, 과거 유사 작업을 참고하면 됩니다. Plexo의 AI Task Breakdown 기능을 활용하면, 리팩토링 범위를 설명하는 것만으로 AI가 세부 작업과 예상 시간을 자동 산정해주어 Effort 추정의 정확도를 높일 수 있습니다.

매우 작은 노력(1일 이하)은 0.5점, 작은 노력(2-3일)은 1점, 보통 노력(1주)은 2점, 큰 노력(2주)은 4점, 매우 큰 노력(1개월 이상)은 8점을 주면 됩니다.

변수명 변경은 1일이면 되므로 0.5점, 함수 분리는 2-3일이면 되므로 1점, 모듈 재구성은 2주가 걸리므로 4점, 아키텍처 변경은 1개월 이상이 걸리므로 8점이 적절합니다.

실제 계산 예시: 두 가지 케이스 비교

예시 1: 사용자 인증 모듈 리팩토링

복잡도가 25로 매우 높고, 모든 기능에서 사용되며, 버그가 자주 발생하는 상황입니다.

RICE 계산을 해보면:

• Reach: 10 (모든 기능에서 사용)
• Impact: 3 (복잡도 25에서 10으로 개선하면 매우 큰 개선)
• Confidence: 100% (SonarQube 데이터로 확인)
• Effort: 4 (2주 예상)

RICE 점수는 (10 × 3 × 1.0) / 4 = 7.5점입니다.

예시 2: 리포트 생성 모듈 리팩토링

중복 코드가 많고, 관리자만 사용하며, 가끔 버그가 발생하는 상황입니다.

RICE 계산을 해보면:

• Reach: 2 (관리자 기능만 사용)
• Impact: 1 (중복 제거는 보통 개선)
• Confidence: 80% (팀 경험 기반)
• Effort: 2 (1주 예상)

RICE 점수는 (2 × 1 × 0.8) / 2 = 0.8점입니다.

우선순위 결정

사용자 인증 모듈이 7.5점으로 최우선이고, 리포트 생성 모듈은 0.8점으로 나중에 해도 됩니다. 결론은 사용자 인증 모듈부터 리팩토링하는 것이 훨씬 효과적이라는 것입니다.

RICE 스코어링 구현: 자동화로 효율성 높이기

RICE 점수 계산을 자동화하면 훨씬 효율적입니다. 코드 사용 빈도를 분석해서 Reach를 측정하고, 복잡도 개선 정도로 Impact를 계산하며, 데이터 기반으로 Confidence를 평가하고, 복잡도와 코드 라인 수를 기반으로 Effort를 추정하면 됩니다.

코드 사용 빈도가 100회 이상이면 Reach는 10점, 50회 이상이면 5점, 10회 이상이면 2점, 1회 이상이면 1점, 0회면 0.5점을 주면 됩니다.

복잡도 개선 비율이 3배 이상이면 Impact는 3점, 2배 이상이면 2점, 1.5배 이상이면 1점, 그 이하면 0.5점을 주면 됩니다.

SonarQube 데이터가 있으면 Confidence는 100%, 팀 경험만 있으면 80%, 둘 다 없으면 50%를 주면 됩니다.

예상 일수가 1일 이하면 Effort는 0.5점, 3일 이하면 1점, 1주 이하면 2점, 2주 이하면 4점, 그 이상이면 8점을 주면 됩니다.

이런 로직을 자동화 스크립트나 프로젝트 관리 도구에 통합하면 RICE 점수를 자동으로 계산할 수 있습니다.

우선순위 결정 전략

1. RICE 점수 기반 정렬

기본 원칙:

• RICE 점수가 높은 순으로 정렬
• 상위 20%에 집중 (파레토 법칙)

실제 적용:

• 50개 리팩토링 항목 중 상위 10개 선택
• 나머지는 다음 스프린트로

2. 예외 규칙: "긴급한 것은 RICE와 무관하게 최우선"

보안 취약점, 성능 병목, 프로덕션 버그는 RICE 점수와 무관하게 최우선으로 처리해야 합니다. 보안 취약점은 즉시 수정이 필요하고, 성능 병목은 사용자 경험에 직접 영향을 미치며, 프로덕션 버그는 비즈니스 손실로 이어질 수 있기 때문입니다.

실제로는 긴급 항목을 먼저 분리하고, 나머지 항목에 대해 RICE 점수를 계산한 다음, 긴급 항목과 상위 10개를 합쳐서 최종 우선순위를 결정하면 됩니다.

3. 버그율 기반 가중치: "같은 점수라면 버그가 많은 것부터"

같은 RICE 점수라면 버그율이 높은 것부터 처리하는 것이 좋습니다. 버그율 가중치를 적용하면 됩니다.

버그율이 10%면 가중치가 2.0이 되고, 버그율이 5%면 가중치가 1.5가 됩니다. 이렇게 하면 버그가 많은 영역이 우선순위가 올라갑니다.

실전 적용 가이드

1주차: 리팩토링 항목 수집

먼저 리팩토링이 필요한 항목들을 수집해야 합니다. SonarQube 리포트를 분석하고, 코드 리뷰에서 발견된 문제를 정리하고, 팀 회고에서 나온 개선 사항을 모으고, 개발자 설문을 통해 수집하면 됩니다.

각 항목에 대해 파일 경로, 현재 복잡도, 사용 빈도, 버그 이력, 의존 관계를 기록해두면 나중에 RICE 점수 계산할 때 유용합니다.

2주차: RICE 점수 계산

자동화 스크립트를 사용하거나, Excel 템플릿을 활용하거나, 프로젝트 관리 도구에 통합하면 됩니다.

각 항목별로 Reach를 측정하고, Impact를 추정하고, Confidence를 평가하고, Effort를 추정한 다음, RICE 점수를 계산하면 됩니다.

3주차: 우선순위 결정

RICE 점수로 정렬하고, 긴급 항목을 확인하고, 상위 20%를 선택한 다음, 팀 리뷰를 통해 합의하면 됩니다.

4주차 이후: 실행 및 모니터링

스프린트에 리팩토링 작업을 포함하고, 진행 상황을 추적하고, 효과를 측정해야 합니다.

리팩토링 전후를 비교하고, RICE 점수를 재계산하고, 우선순위를 재조정하면 됩니다.

RICE 스코어링의 장단점: 현실적인 평가

장점

데이터 기반으로 결정할 수 있어서 직관이 아닌 객관적 우선순위를 정할 수 있습니다. 모든 기준이 명확해서 팀 합의를 얻기 쉽고, 제한된 리소스로 최대 효과를 얻을 수 있어서 ROI를 최적화할 수 있습니다.

단점

Reach와 Impact를 측정하는 데 시간이 걸리고, 초기 설정이 필요합니다. Impact와 Effort는 추정이기 때문에 불확실성이 존재하고, 예외 상황을 처리하기 어렵고, 비즈니스 맥락을 무시할 수 있습니다.

하지만 이런 단점에도 불구하고, RICE 스코어링은 여전히 가장 효과적인 우선순위 결정 방법 중 하나입니다. 제가 여러 팀에서 적용해본 결과, 직관에 의존하는 것보다 훨씬 좋은 결과를 얻을 수 있었습니다.

실전 체크리스트

리팩토링 우선순위 결정 전:

•  리팩토링 항목 수집 완료
•  Reach 측정 방법 정의
•  Impact 평가 기준 설정
•  Confidence 평가 기준 설정
•  Effort 추정 방법 정의
•  RICE 점수 계산 자동화
•  예외 규칙 정의
•  팀 합의 프로세스 수립

글을 마치며: 데이터로 결정하는 리팩토링 우선순위

리팩토링 우선순위는 직관이 아닌 데이터로 결정해야 합니다.

핵심 원칙을 다시 정리하면:

• RICE 스코어링으로 객관적 평가
• 긴급 항목은 예외 처리 (보안, 성능, 프로덕션 버그)
• 상위 20%에 집중 (파레토 법칙)
• 지속적 모니터링 및 재조정

이 원칙을 따르면, 제한된 리소스로 최대의 효과를 얻을 수 있습니다.

오늘부터 RICE 스코어링으로 리팩토링 우선순위를 결정해보세요. 작은 변화가 큰 차이를 만듭니다.

---

AI 기반 작업 분해와 리팩토링 우선순위를 체계적으로 관리하는 가장 스마트한 방법, Plexo를 통해 우리 팀의 기술 부채를 점검해 보세요.

AI Task Breakdown으로 리팩토링 작업의 Effort를 자동 산정하고, RICE 점수 계산과 우선순위 결정을 자동화할 수 있는 도구가 있다면, 리팩토링 우선순위를 미리 결정하고 관리하는 것이 훨씬 쉬워집니다.

기술 부채 측정과 추적: 정량적 모델링

"이 기능 추가하는데 왜 이렇게 오래 걸리죠?"

3개월 전에는 3일이면 되던 작업이, 지금은 2주가 걸립니다. 코드는 더 복잡해졌고, 버그는 더 자주 발생하고, 새로운 팀원은 코드베이스를 이해하는데 한 달이 걸립니다.

"기술 부채 때문이에요."

이 말을 들을 때마다 PM은 한숨을 쉽니다. 기술 부채가 얼마나 되는지, 언제 갚아야 하는지, 얼마나 비용이 드는지 알 수 없기 때문입니다.

30년 넘게 개발자로 일하면서, 그리고 수많은 프로젝트를 지켜보며 느낀 점은, 기술 부채는 금융 부채와 같다는 것입니다. 시간이 지날수록 복리처럼 증가하는 실제 비용이죠. 처음엔 작아 보였던 기술 부채가, 1년 후에는 프로젝트 속도를 절반 이하로 떨어뜨립니다.

제가 직접 경험한 프로젝트가 있습니다. 1개월차에 10%였던 기술 부채가 12개월차에는 35%로 증가했고, 결국 프로젝트 속도가 절반 이하로 떨어졌습니다. 하지만 그때는 기술 부채를 측정할 방법을 몰랐죠.

하지만 기술 부채는 측정할 수 있고, 추적할 수 있으며, 관리할 수 있습니다. 오늘은 현장에서 검증된 실전 방법들을 공유해드리겠습니다.

기술 부채의 숨겨진 비용: 복리처럼 증가하는 실제 비용

기술 부채는 단순히 "나쁜 코드"가 아닙니다. 시간이 지날수록 복리처럼 증가하는 실제 비용입니다.

제가 여러 프로젝트에서 목격한 기술 부채의 4가지 비용은 다음과 같습니다:

속도 저하: 기능 추가 시간이 점점 늘어납니다. 처음엔 3일이면 되던 작업이 2주가 걸리게 되죠.

버그 증가: 수정할 때마다 새로운 버그가 발생합니다. 한 곳을 고치면 다른 곳이 깨지는 악순환이 반복됩니다.

온보딩 비용: 신입 개발자가 코드를 이해하는 시간이 기하급수적으로 증가합니다. 처음엔 1주일이면 되던 것이 한 달이 걸리기도 합니다.

개발자 이탈: 복잡한 코드에 지친 개발자들이 퇴사를 선택합니다. 이건 가장 치명적인 비용이죠.

복리 효과는 무서운 것입니다. 1개월차에 10%였던 기술 부채가 3개월차에는 15%, 6개월차에는 23%, 12개월차에는 35%로 증가합니다. 처음엔 작아 보였던 기술 부채가, 1년 후에는 프로젝트 속도를 절반 이하로 떨어뜨립니다.

기술 부채를 측정하는 4가지 핵심 지표

1. 순환 복잡도: "이 함수가 얼마나 복잡한가?"

코드의 분기 수를 측정하는 지표입니다. 함수당 분기 수를 계산하면 됩니다.

제 경험상, 복잡도가 1-10이면 단순하고 이해하기 쉽습니다. 11-20이면 복잡하고 주의가 필요하고, 21 이상이면 매우 복잡해서 리팩토링이 필수입니다.

실제로 복잡도 3인 함수는 이해하기 쉬워서 버그도 적고, 수정도 빠릅니다. 하지만 복잡도 25인 함수는 이해하기 어려워서 버그 위험이 높고, 수정할 때마다 새로운 문제가 생기기 쉽습니다.

2. 코드 중복률: "같은 코드가 얼마나 반복되는가?"

같은 코드가 반복되는 비율을 측정합니다. 전체 코드 중 중복 코드 비율을 확인하면 됩니다.

0-5%면 양호하고, 5-10%면 주의가 필요하며, 10% 이상이면 리팩토링이 필요합니다.

제가 본 프로젝트에서 중복 코드가 10%였을 때, 버그 수정 시간이 20%나 증가했습니다. 한 곳을 수정하면 다른 곳도 수정해야 하는 악순환이 반복되었죠. 결국 공통 함수로 추출하는 리팩토링을 진행했고, 그 후 버그 수정 시간이 크게 줄었습니다.

3. 테스트 커버리지: "코드가 얼마나 안전한가?"

코드가 테스트로 얼마나 커버되는지 측정합니다. 전체 코드 중 테스트된 코드 비율을 확인하면 됩니다.

80% 이상이면 양호하고, 60-80%면 보통이며, 60% 미만이면 위험합니다.

제가 경험한 프로젝트에서 테스트 커버리지가 50%였을 때, 버그 발견 시간이 2배나 증가했습니다. 리팩토링할 때도 회귀 버그 위험이 높아서 신중하게 진행해야 했죠. 커버리지를 80% 이상으로 올린 후에는 리팩토링도 자신 있게 할 수 있게 되었습니다.

4. 기술 부채 비율: "전체 개발 시간 중 기술 부채가 차지하는 비율"

SonarQube에서 제공하는 종합 지표입니다. 기술 부채 수정 시간을 개발 시간으로 나눈 뒤 100을 곱하면 됩니다.

0-5%면 양호하고, 5-10%면 주의가 필요하며, 10% 이상이면 위험합니다. 이 비율이 높을수록 신규 기능 개발보다 기술 부채 정리에 더 많은 시간을 써야 합니다.

기술 부채를 추적하는 실전 도구들

1. SonarQube: 가장 널리 쓰이는 종합 분석 도구

코드 품질 분석부터 기술 부채 비율 계산, 취약점 및 버그 탐지, 코드 냄새 감지까지 한 번에 할 수 있습니다.

순환 복잡도, 코드 중복률, 테스트 커버리지, 보안 취약점, 유지보수성 지수까지 측정할 수 있어서 제가 가장 많이 사용하는 도구입니다. 특히 기술 부채 비율을 자동으로 계산해주는 것이 큰 도움이 됩니다.

2. CodeClimate: 실시간 모니터링에 특화

실시간 코드 품질 모니터링과 PR별 기술 부채 추적이 가능합니다. 팀별 메트릭 대시보드도 제공해서 팀 전체의 기술 부채 현황을 한눈에 볼 수 있습니다.

GitHub와 통합되어 있어서 PR을 올릴 때마다 자동으로 코드 리뷰를 해주고, 기술 부채 트렌드를 추적할 수 있습니다. 작은 팀이나 스타트업에서 사용하기 좋은 도구입니다.

3. 자체 측정: 간단하게 시작하는 방법

도구를 도입하기 전에 간단하게 시작할 수도 있습니다. 기술 부채 비용을 계산할 때는 속도 저하(약 15%), 버그 증가(약 20%), 온보딩 비용 증가(약 30%), 이탈 비용(약 10%)을 고려하고, 복리 효과(월 1.15배)를 적용하면 됩니다.

하지만 시간이 지나면서 자동화된 도구를 사용하는 것이 훨씬 효율적입니다. 수동으로 측정하는 것은 시간이 많이 걸리고, 놓치는 부분이 생기기 쉽습니다.

기술 부채를 관리하는 3가지 실전 전략

1. 기술 부채 백로그 운영: "우선순위를 명확히 하라"

기술 부채 백로그를 별도로 관리하고, 우선순위를 명확히 해야 합니다. 영향도, 수정 비용, 비즈니스 영향을 고려해서 높음/중간/낮음으로 분류하면 됩니다.

제가 여러 팀에서 적용해본 결과, 매 스프린트마다 기술 부채 작업을 20% 할당하는 것이 가장 효과적입니다. 신규 기능 개발에만 집중하면 기술 부채가 쌓이기만 하고, 기술 부채 정리에만 집중하면 비즈니스 가치를 만들 수 없으니까요.

정기적으로 리뷰하고 우선순위를 조정하는 것도 중요합니다. 한 달 전에는 낮았던 우선순위가 지금은 높을 수 있으니까요.

2. 기술 부채 예산 설정: "20%의 법칙"

신규 기능에 80%, 기술 부채에 20%를 할당하는 것이 좋습니다. 이 비율을 지키면 기술 부채가 쌓이지 않으면서도 신규 기능 개발을 계속할 수 있습니다.

하지만 기술 부채가 20%를 넘으면 신규 기능 개발을 중단하고 기술 부채 정리에 집중해야 합니다. 그렇지 않으면 기술 부채가 복리처럼 증가해서 결국 프로젝트가 멈추게 됩니다.

3. 기술 부채 대시보드: "데이터로 보는 팀의 건강 상태"

기술 부채 비율 추이, 순환 복잡도 분포, 테스트 커버리지 추이, 코드 중복률 추이를 한눈에 볼 수 있는 대시보드를 만들면 좋습니다.

주간으로는 팀 리뷰를 하고, 월간으로는 경영진에게 보고하며, 분기별로는 전략을 조정하면 됩니다. 데이터가 있으면 감이 아닌 사실로 의사결정을 할 수 있습니다.

💡 Plexo의 AI Task Breakdown 기능을 활용하면 새 기능 추가 시 AI가 작업별 예상 시간을 자동 산정합니다. 이 AI 추정치와 실제 소요 시간을 비교하면, 기술 부채로 인한 속도 저하를 정량적으로 측정할 수 있어 기술 부채의 실제 비용을 더 명확하게 파악할 수 있습니다.

실전 체크리스트

매일 확인할 것들

• 코드 리뷰 시 복잡도 체크
• 중복 코드 발견 시 리팩토링 제안
• 테스트 커버리지 확인

매주 확인할 것들

• SonarQube 리포트 확인
• 기술 부채 백로그 우선순위 조정
• 팀 회의에서 기술 부채 논의

매월 확인할 것들

• 기술 부채 비율 추이 분석
• 기술 부채 예산 사용 현황 확인
• 경영진 보고서 작성

글을 마치며: 측정할 수 있으면 관리할 수 있습니다

기술 부채는 측정할 수 있습니다. 그리고 측정할 수 있으면 관리할 수 있습니다.

기술 부채를 무시하면, 시간이 지날수록 개발 속도는 느려지고, 버그는 늘어나고, 팀의 사기는 떨어집니다. 제가 직접 경험한 프로젝트에서 이런 일이 반복되었습니다.

하지만 정량적으로 측정하고 추적하면, 언제 갚아야 할지, 얼마나 투자해야 할지 명확해집니다. 순환 복잡도, 코드 중복률, 테스트 커버리지, 기술 부채 비율을 측정하고, SonarQube나 CodeClimate 같은 도구로 추적하며, 매 스프린트마다 기술 부채 작업 20%를 할당하면 기술 부채를 관리할 수 있습니다.

오늘부터 기술 부채를 측정하기 시작하세요. 작은 노력이 큰 차이를 만듭니다.

---

AI 기반 프로젝트 관리로 기술 부채를 추적하고 관리하는 가장 스마트한 방법, Plexo를 통해 우리 팀의 코드 품질을 점검해 보세요.

AI Task Breakdown으로 기능별 예상 시간을 자동 산정하고, 기술 부채 비율과 코드 품질 지표를 한눈에 파악할 수 있는 도구가 있다면, 기술 부채를 미리 감지하고 예방하는 것이 훨씬 쉬워집니다.