PE Notes · SW
기술 부채 · 3R · 리팩토링
기술 부채의 원금·이자와 Fowler 사분면을 잡고, Reuse·Restructure·Rewrite 3R로 상환 규모를 가른 뒤 리팩토링·SQALE·보이스카우트 게이트를 정리합니다.
빨리 내기 위해 더 나은 구조를 미루면, 다음 변경마다 이자가 붙습니다. 는 그 미룬 선택의 미래 비용입니다. 원금은 지저분한 코드·얇은 시험이고, 이자는 같은 일을 하는 데 매일 더 드는 시간입니다. 갚는 기본 수단은 겉 동작을 두고 속만 다듬는 입니다. 재공학이 시스템을 현대화하는 큰 줄이라면, 리팩토링은 그 안의 일상 단위입니다.
은유와 사분면
정의는 1992년 Ward Cunningham이 금융에서 빌린 말입니다. 영향은 속도 하락, 결함 증가, 새 사람 온보딩 지연입니다. 이자는 복리처럼 쌓입니다. 자주 만지는 모듈일수록 이자 납부가 잦습니다.
Fowler 사분면은 의도×신중입니다. 신중·의도적은 출시·MVP를 위해 “지금은 이렇게, 곧 고친다”는 기록 있는 선택입니다. 무모·의도적은 설계를 알고도 건너뜁니다. 이 그 자리에서 납니다. 신중·비의도적은 나중에야 더 나은 길을 배운 성장입니다. 무모·비의도적은 나쁜지조차 모르는 역량 공백입니다.
영역은 코드(중복·복잡도·스멜), 아키텍처(결합·잘못된 경계, 대규모 재작업), 시험(커버리지 공백·깨지기 쉬운 시험, 변경 공포)입니다. 문서·인프라 부채도 같은 이자 구조를 갖습니다. 스멜 글이 처방을 기법에 매핑한다면, 이 글은 그 처방을 부채 원장과 상환 예산에 올립니다.
리팩토링은 Extract Method·Extract Class처럼 책임 단위를 나누는 일이 많고, 회귀 시험 없이 하면 원금을 이자로 바꿉니다.
3R로 규모를 가른다
갚는 방법은 부채 크기에 따라 셋입니다. 는 독립된 모듈·라이브러리를 그대로 씁니다. 부채가 작고 경계가 분명할 때입니다. 는 기능은 두고 내부 구조만 바꿉니다. 리팩토링과 점진적 분리(모노리스에서 서비스로)가 여기 들어갑니다. 는 코드를 버리고 다시 씁니다. 부채가 원금을 넘고 변경마다 장애가 날 때의 마지막 카드입니다.
측정과 상환 순서
보이는 숫자 없이 “나중에”는 영원히입니다. SonarQube 류는 이슈를 고치는 예상 시간으로 부채를 분·시간에 합칩니다. 은 그 합을 개발 비용 대비 비율로 바꿉니다. 은 수정 비용 ÷ 개발 비용이며, 흔히 5% 아래를 게이트로 둡니다.
전략은 세 갈래입니다. 은 맡은 코드를 체크아웃보다 조금 낫게 올립니다. 상환 스프린트는 용량의 20~30%를 구조 개선에 고정합니다. 부채 등록부는 항목을 비용·위험·영향으로 줄 세웁니다.
우선은 많이 의존되는 코드(파급), 자주 바뀌는 코드(이자 횟수), 핵심 업무(장애 비용)입니다. 안 만지는 모듈의 추한 코드는 이자가 작습니다. 바이브 코딩은 생성 속도를 올리지만, 스멜과 시험을 건너뛰면 무모한 의도적 부채가 됩니다.
예방과 거버넌스
유입을 막는 문화가 상환보다 쌉니다. 코딩 표준을 도구로 강제하고, 모든 변경에 리뷰를 걸며, TDD와 지속 리팩토링으로 스멜이 커지기 전에 자릅니다.
거버넌스는 로 “왜 지금 이 타협인가”를 남겨 신중한 부채를 명시합니다. 대시보드는 비기술 이해관계자에게 비율과 추이를 보여 줍니다. 임계를 넘기면 빌드를 실패시키는 품질 게이트가 통제입니다.
비즈니스 연결은 이자(느린 개발)와 위험(장애)을 손실로 바꿉니다. “기능이 20% 느리다”가 설득 문장입니다. 신기능과 상환의 비율은 제품 목표가 정하고, 그 결정은 기록합니다. 숨기면 무모가 됩니다.
답안은 원금·이자, 사분면 네 칸, 코드·구조·시험, SQALE 비율, 보이스카우트와 게이트를 한 장에 올립니다.