역시 속력이 아닌 방향일까

리팩토링은 단순히 ‘코드를 예쁘게 정리하는 일’이 아니다. 

처음에는 쓸모없어 보일 수도 있다. 이미 돌아가는 기능을 굳이 손대는 건 낭비처럼 느껴질 수도 있다. 하지만 시간이 지날수록 상황은 달라진다. 코드가 엉켜갈수록 새로운 기능 하나 추가하는 데도 시간이 두 배, 세 배로 늘어난다. 우리가 지금 손보지 않으면, 미래의 우리는 그 코드와 씨름하느라 속도를 잃는다.

Martin Fowler의 Design Stamina Hypothesis(디자인-스테미너 가설)에 따르면, 초반에는 차이를 느끼기 어렵지만, 시간이 지나면 좋은 설계를 가진 팀과 그렇지 않은 팀의 개발 속도는 극명하게 갈린다고. 결국 리팩토링은 좋은 설계로 나아가기 위한 실질적인 도구다. 더 빠르게, 더 안정적으로 기능을 쌓아올릴 수 있게 만드는 가장 경제적인 선택이다.

물론 ‘클린 코드가 멋있어서’, ‘전문가니까’라는 이유도 있을 수 있다. 

하지만 진짜 이유는 속도다. 경제성이다.
코드를 깔끔하게 정리하는 것이 결국 더 많은 일을, 더 빠르게 할 수 있는 길이기 때문이다. 리팩토링의 여부는 결국 개발자의 선택이다. 

폴싯(Forsit)에서 누군가는 ‘지금은 바빠서 나중에 하자’고 말할 수도 있다. 하지만 우리가 쓰는 이 한 줄, 한 줄이 미래의 개발 속도를 결정한다. 여기서도 적용되는 이야기다. 중요한건 속력이 아닌 방향이다.