기술 부채와 리팩터링 — 보이지 않는 비용 다루기 — 실습 Lab

INCIDENT RESPONSE

0 / 5 단계 완료

📚 PREREQUISITES

Theorysw-engineering/tech-debt-refactoring

TRACK

SW-ENGINEERING

SLA

50분

LEVEL

중급

PHASES

3단계

ENV

local

INCOMING TICKET

“팀장: "요즘 기능 하나 추가하는 데 반년 전보다 두 배는 걸려요. 다들 결제 쪽 코드가 썩었다고 하는데, 정작 뭐가 얼마나 문제인지 숫자로 대는 사람이 없어요. 기술 부채를 눈에 보이게 정리하고, 뭘 먼저 갚을지, 리팩터링 스프린트 잡자 말고 실제로 어떻게 갚을지 계획을 만들어 주세요."”

YOUR ROLE

기술 부채를 가시화하고 상환 계획을 세우는 테크리드/PM

안 하면 나중에

부채를 감으로만 두면 우선순위 경쟁에서 늘 기능에 밀려 영영 안 갚히고, 어느 순간 작은 변경도 며칠씩 걸리는 상태로 복리처럼 커진다.

📋상황 브리핑

팀장이 말합니다.

"기능 하나 추가하는 데 반년 전보다 두 배는 걸려요. 다들 결제 쪽 코드가 썩었다고 하는데, 정작 뭐가 얼마나 문제인지 숫자로 대는 사람이 없어요. 그러니 스프린트마다 기능에 밀려서 정리는 늘 다음으로 미뤄지고요. 기술 부채를 눈에 보이게 정리하고, 뭘 먼저 갚아야 하는지, 그리고 리팩터링 스프린트 잡자 말고 실제로 어떻게 갚을지 계획을 만들어 주세요."

기술 부채는 "코드가 못생겼다"의 문제가 아니라 "미룬 일이 이자를 붙여 미래의 변경을 느리고 위험하게 만든다"의 문제다. 이 Lab은 부채를 식별·분류해 가시화하고, 영향과 변경 빈도로 상환 우선순위를 세운 뒤, 양극단(전용 스프린트 vs 방치)을 피한 지속적 상환 전략까지 확정한다.

⏱ 50분📊 중급🔧 3단계#tech-debt#refactoring#maintenance#prioritization

MISSION

부채 식별·분류 — "썩었다"를 목록과 숫자로 바꾸기

느낌으로 떠도는 부채를 원인(의도적/우발적)과 형태(코드·설계·문서·테스트)로 분류해, 백로그 이슈로 가시화한다.

상환 우선순위 — 부채의 "이자"는 변경 빈도가 결정한다

영향(고치면 얼마나 이득)과 변경 빈도(얼마나 자주 건드리나)로 부채를 사분면에 배치해, 무엇을 먼저 갚고 무엇을 의도적으로 남길지 정한다.

실행 전략 — "전용 스프린트"도 "절대 안 함"도 아닌 길

보이스카웃 규칙·스트랭글러 패턴·기능 개발에 끼워넣기로 부채를 지속적으로 갚는 계획을 세우고, PM을 설득할 언어(비용·이자)로 정리한다.

📌 선수 지식

• [이론] sw-engineering/tech-debt-refactoring

ℹ️ 실습 환경

환경: local

🔒

실습 실행은 Pro 플랜 전용입니다

인시던트 브리프와 학습 자료는 지금 바로 확인할 수 있습니다. 실제 실습 진행 및 터미널 사용은 Pro 플랜에서 가능합니다.

Pro로 업그레이드 →

>_ LAB TERMINAL↔ 너비 조절

NOTES