리팩토링이란, 소프트웨어의 기능은 그대로 유지하면서 코드의 구조를 개선하는 작업이다. 코드의 입력값이나 출력값은 변하지 않는 상태에서 내부의 동작 방식을 변경하거나 더 읽기 쉽고 유지보수하기 쉬운 상태로 코드를 개선하는 작업이다.
코드의 가독성을 올리고 유지보수 비용을 절감하기 위해서 또 버그를 예방하고 개발 생산성까지 향상된다.
간단히 말하면 개발의 효율성을 올리는 작업이다.
이렇게 좋다고 생각하는 리팩토링에 대해 개발자로 일하다보면 그게 돈이 되냐는 말을 꽤나 자주 듣게된다. 실제로 많은 회사에서 리팩토링이나 테스트코드를 작성하는데 시간을 할애하지 않는다. 이유는 돈이 되지 않기 때문이다.
정말 리팩토링이라는 것은 돈이 안될까?
리팩토링이라는 것은 시간이 필요하다. 그리고 앞에서 설명한것과 같이 요청값과 응답값이 변하지 않는다. 즉 개발팀 외부에서는 뭐가 바뀐건지 알기 어렵다. 그 말은 리팩토링이라는것은 당장 가시적인 성과를 보이지 않을 수 있다는 의미이다. 그런 의미에서 리팩토링과 테스트코드 작성은 개발팀 외부에서는 돈이 되지 않는 시간만 드는 작업이라고 판단할 수 있다.
리팩토링과 테스트 코드 작성이 돈이 안 된다고 판단되는 또 다른 이유는 직접적인 비즈니스 가치 창출과 거리가 멀어 보이기 때문이다.
많은 비즈니스에서는 고객을 위해서라면 내부적인 코드구조 개선 보다는 새로운 기능 추가가 더 직접적인 가치를 제공하는것이라고 생각한다. 하지만 리팩토링이라는 것은 새로운 기능을 제공하지 않기 때문에 새로운 변화나 가치를 느낄 수 없다. 이는 곧 비용 대비 성과있는 작업이라고 생각하지 않게 된다.
또 중요한 이유로는 자칫 리팩토링을 잘못 진행하면 예상치 못한 버그가 발생하거나 기존 기능이 손상될 수 있다. 이를 막기위해 최대한 테스트케이스를 작성하긴 하지만, 이로 인해 리팩토링이 더 많은 추가 작업을 유발할 수 있으며, 이는 프로젝트 일정에 차질을 주거나 이미 잘 동작하고있던 코드에 오류가 발생하는 등 외부에서 부정적으로 평가될 가능성이 높다.
이러한 이유들 때문에, 많은 비즈니스에서는 리팩토링이나 테스트 코드 작성이 돈이 안 되는 작업으로 느껴질 수 있다.
앞에서 리팩토링이 돈이 안되는 이유들에 대해 설명했다. 그럼 반대로 리팩토링이 돈이 되는 이유에 대해서도 살펴보자.
우선 코드의 유지보수 비용을 절감시킬 수 있다. 기능이 추가되면서 덕지덕지 추가된 복잡한 개발코드는 장기적으로 유지보수의 문제가 발생한다.
복잡하고 읽기 어려운 코드는 새로운 기능을 추가하거나 유지보수할 때마다 시간과 비용이 많이 소모된다. 특히 시간이 지남에 따라 코드의 복잡성이 커지면서 코드의 일부를 수정할 때 의도치 않게 다른 부분에 영향을 미쳐 기존 기능에 버그를 발생시키는 위험 또한 높아진다. 이런 상황이 자주 발생하면 유지보수 비용이 기하급수적으로 증가하게 된다.
리팩토링은 이러한 문제를 해결하기 위한 예방적인 조치이다. 코드가 간결하고 읽기 쉬운 구조일수록 개발자는 문제를 더 쉽게 파악하고 수정할 수 있다. 또한, 코드 구조가 개선되면 개발자는 기존 코드를 재사용하기 쉬워지고, 중복된 코드나 불필요한 복잡성을 제거하여 전반적인 유지보수 비용을 줄일 수 있다. 이러한 리팩토링 작업을 통해 장기적으로 봤을 때 오히려 비용이 절감되는 효과를 경험할 수 있다.
복잡한 코드 구조는 잠재적인 오류와 버그를 발생시키는 원인이 될 수 있다. 명확하지 않은 변수명이나 복잡한 논리 구조 그리고 중복된 코드들은 많은 버그를 발생시킨다. 리팩토링은 이러한 요소들을 제거하고, 코드의 명확성을 높이는 데 초점을 둔다. 코드가 명확하면, 의도한 대로 작동하지 않거나, 잘못된 데이터를 처리할 가능성이 줄어든다.
그래서 테스트 주도 개발(TDD) 방식과 함께 리팩토링을 진행하면 코드의 품질을 더욱 보장할 수 있다. 코드 리팩토링 후에는 변경 사항이 전체 시스템에 영향을 미치지 않도록 테스트를 통해 확인해야 하는데 이는 의도하지 않은 부작용을 방지하는 데 중요한 역할을 한다.
그래서 리팩토링을 하기전에 반드시 모든 케이스에 대해 테스트코드를 작성하고 리팩토링 후에 모든 테스트코드가 올바르게 동작하는지 확인하는 과정은 반드시 필요하다. 이러한 리팩토링을 통해 버그가 적게 발생하면, 문제 해결에 소요되는 시간과 비용도 줄어들어 개발팀의 효율성이 향상될 수 있다.
기술 부채는 개발 과정에서 빠르게 개발하기 위해 비효율적인 코드를 작성하거나 즉시 배포를 위해 임시적인 해결책을 사용하는 경우에 대부분 발생한다. 처음에는 더 빨리 기능을 완성하는 데 도움이 되지만, 시간이 지남에 따라 이러한 임시 해결책이 쌓이면서 유지보수와 확장성에 문제가 발생한다. 이러한 기술 부채가 쌓이면 프로젝트는 점점 더 복잡해지고, 수정이 어려워지며, 새로운 기능을 추가할 때 예상치 못한 문제들이 발생하게 된다.
리팩토링은 이러한 기술 부채를 줄이는 데 중요한 역할을 한다. 기존의 비효율적인 코드 구조를 더 효율적이고 유지보수하기 쉽게 정리하면, 코드가 복잡해지더라도 그 복잡성이 관리 가능한 수준에서 관리할 수 있다.
기술 부채가 줄어들면, 유지보수와 수정 작업에서 예상치 못한 문제나 버그가 발생하는 빈도가 줄어들고, 새로운 기능을 더 빨리 개발할 수 있게 된다. 또 장기적으로는 기술 부채가 줄어들면 프로젝트의 안정성이 증가한다. 따라서 기술 부채를 줄이는 작업은 단순한 코드 정리가 아닌 비용 절감과 비즈니스의 안정성을 위해서라면 반드시 해야하는 필수적인 작업이다.
앞에서 리팩토링이 돈이 되지 않는 이유와 돈이 되는 이유들에 대해 살펴봤다. 결론적으로, 리팩토링은 단기적으로 눈에 보이는 ‘돈’이 되지는 않지만, 장기적인 관점에서 보면 비즈니스와 개발팀 모두에게 필수적인 투자이다. 이는 기술 부채를 줄이고, 개발 속도와 효율성을 향상시키며, 유지보수 비용을 절감하는 데 중요한 역할을 한다.
즉, 리팩토링은 비즈니스의 장기적인 성장을 뒷받침하는 숨은 자산이며, 이를 통해 더 나은 품질의 소프트웨어를 제공할 수 있고 새로운 기능 추가에 대해 더욱 유연하게 대응할 수 있다.