기술 부채 갚자고 설득하는 법

"리팩토링 할 시간 주세요"의 결말

이 말을 PM에게 하면 돌아오는 대답은 99% 같다. "지금 일정이 빠듯해서요." 틀린 말은 아니다. 일정이 안 빠듯한 적이 언제 있었던가.

나는 5번 거절당했다. 매번 "코드가 더러워서 개선하고 싶다", "기술 부채가 쌓이면 나중에 큰일 난다" 같은 말을 했다. 근데 이게 비개발자 입장에서는 설득력이 없다.

코드가 더러운 건 개발자만 불편한 거고, "나중에 큰일 난다"는 예언은 당장 매출에 영향을 안 주니까.

실패한 설득법들

"코드 품질이 중요합니다" - PM 반응: "네, 그런데 이번 스프린트에 기능 3개 빠지는데요?"

"다른 회사들도 리팩토링 시간을 따로 잡습니다" - PM 반응: "다른 회사 사정은 우리랑 다릅니다."

"이러다 개발자들 퇴사합니다" - PM 반응: 잠깐 심각한 표정을 짓다가 그래도 일정 변경은 없었다.

(다섯 번째 거절당했을 때 좀 회의감이 들었다.)

6번째에 바꾼 전략

숫자로 말했다. "현재 주문 관련 기능을 수정하는 데 평균 3.2일이 걸립니다. 비슷한 규모의 수정이 다른 모듈에서는 1일이면 됩니다. 리팩토링하면 주문 모듈도 1.5일로 줄일 수 있습니다."

그리고 비즈니스 영향을 연결했다. "다음 분기에 주문 관련 기능 요청이 4건 예정돼 있으니까, 리팩토링에 5일 투자하면 다음 분기에 6.8일을 아낍니다."

PM이 처음으로 "그러면 이번 스프린트 마지막 주에 해볼까요?"라고 했다.

실제로 리팩토링한 결과

5일 동안 주문 모듈을 리팩토링했다. 솔직히 5일로는 부족해서 기본적인 구조 개선만 했다. 완벽하지 않았다. 근데 수정 시간이 3.2일에서 2.1일로 줄었다. 예상한 1.5일보다는 느렸지만 개선은 됐다.

이 결과를 다시 PM에게 공유했다. 그 다음부터 리팩토링 시간 요청이 조금 더 수월해졌다. 숫자로 보여주니까 신뢰가 쌓인 거다.

내가 깨달은 것

개발자끼리는 "코드가 지저분하다"가 충분한 이유가 된다. 근데 비개발자에게는 그게 비용과 시간으로 번역돼야 한다. "코드가 더러워서"가 아니라 "이 코드 때문에 기능 하나 만드는 데 3일이 더 걸린다"로 바꿔야 한다.

그리고 한 번에 큰 리팩토링을 요구하면 안 된다. 작은 단위로 쪼개서, 각각의 효과를 측정하고, 그 결과로 다음 리팩토링을 정당화하는 사이클을 만들어야 한다.

사실 제일 어려운 건

리팩토링 시간을 받아도 우선순위를 정하는 게 어렵다. 고치고 싶은 곳이 12군데인데 5일밖에 없으면 어디부터 해야 하나. 제일 비즈니스 임팩트가 큰 곳부터 하라는데, 그걸 판단하는 것 자체가 주관적이라서 확신이 안 선다.

아직도 기술 부채는 쌓이고 있고, 다 갚을 수 있을 거라는 환상은 버렸다. 그냥 관리하는 거다.