Managing Technical Debt in Indie Dev: Which Debt to Keep, Which to Pay
개요
인디 개발에서 기술 부채를 관리하는 것은 모든 부채를 제거하려는 시도 대신, 전략적 관리를 통해 생산성을 유지하는 것을 목표로 합니다.
주요 내용
* 기술 부채 분류:
* 전략적 부채 (유지 가능): MVP 검증 전의 플레이스홀더 코드, 추후 리팩터링 가능한 격리된 모듈, 낮은 사용자 수에서 허용 가능한 성능 트레이드오프.
* 차단 부채 (반드시 상환): 테스트가 불가능한 강하게 결합된 코드, 반복적인 버그를 유발하는 구조, 인지 부하를 높이는 코드 (미래의 자신 포함).
* 부채 가시화:
* TODO / FIXME 주석에 명시적인 타임라인을 추가하여 기술 부채를 표시합니다.
* CI에서 부채를 정량화하여 TODO 및 FIXME 개수를 추적합니다.
* 리팩터링 우선순위 지정:
* 높은 우선순위: 반복적인 버그가 발생하는 영역 (오픈 이슈), 이해하기 어려운 고변동 코드, 새로운 기능 구현을 항상 차단하는 구조.
* 낮은 우선순위: 변경되지 않는 안정적인 코드, 통과하는 테스트로 커버되는 작동하는 코드, 외부에서 보이지 않는 내부 세부 사항.
* 점진적 리팩터링 (Strangler Fig Pattern): 대규모 모듈을 한 번에 재작성하지 않고, 기존 코드와 새 코드를 병렬로 실행한 후 점진적으로 전환합니다.
* 20% 규칙: 매주 작업 시간의 20%를 기술 부채 상환에 할당하여 생산성을 높게 유지하면서 부채 증가를 방지합니다.
* 자동화된 주간 알림: GitHub Actions (GHA)를 사용하여 기술 부채 관련 작업 항목에 대한 주간 알림을 설정합니다.
시사점
기술 부채를 관리된 차입처럼 취급하고, 모든 부채를 없애는 것이 아닌 지속 가능한 수준으로 관리하는 것이 인디 개발에서의 효율적인 코드베이스 유지와 신속한 기능 출시를 가능하게 합니다.
댓글
GitHub Discussions