리팩토링 우선순위 결정: 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 점수 계산과 우선순위 결정을 자동화할 수 있는 도구가 있다면, 리팩토링 우선순위를 미리 결정하고 관리하는 것이 훨씬 쉬워집니다.