기술 부채(Technical Debt)를 관리하는 방법: 파산하지 않으려면
Culture
워드 커닝햄이 만든 "기술 부채"라는 메타포는 정말 적절합니다. 우리는 빠른 기능 출시(Time to Market)를 위해, 깔끔한 설계(원금) 대신 빨리 짤 수 있는 스파게티 코드(부채)를 선택하곤 합니다. 부채를 져서 사업을 빨리 시작하는 것은 좋은 전략입니다. 문제는 이자를 갚지 않을 때 발생합니다.
1. 기술 부채의 이자
코드가 더러워서 새로운 기능을 추가하는 데 시간이 점점 더 오래 걸립니다. 버그를 고쳤더니 다른 곳에서 버그가 터집니다. 개발자는 지치고 퇴사 욕구가 샘솟습니다. 이게 바로 우리가 치러야 할 이자입니다.
2. 부채의 종류
- 신중한 부채: "지금은 시간이 없으니 일단 하드코딩하고, 다음 스프린트에 리팩터링 하자." (알고 지는 빚)
- 무모한 부채: "설계? 몰라. 그냥 돌아가게만 만들어." (모르고 지는 빚. 사채에 가깝습니다.)
3. 부채 상환 전략
- 보이스카우트 규칙: "머물렀던 자리보다 떠날 때 더 깨끗하게 하라." 기능을 수정하러 들어간 김에, 그 주변 코드의 변수명 하나라도 고치고 나오는 습관을 들입니다.
- 부채 청산 주간: 분기에 한 번 정도는 기능 개발을 멈추고 리팩터링만 하는 기간을 가집니다.
- 부채 시각화: TODO 주석을 남기거나, 이슈 트래커에 "Refactoring" 태그를 달아 부채 규모를 파악해야 합니다.
기술 부채가 0인 프로젝트는 없습니다(망한 프로젝트 빼고). 중요한 건 부채를 "관리 가능한 수준"으로 유지하는 것입니다.