요즘 진행하고 있는 리팩토링 작업 중, 우연히 10년 전 내가 작성한 코드를 다시 보게 되었다. 단순히 기능을 개선하는 과정이었지만, 그 코드들을 보며 자연스럽게 지난 시간들을 돌아보게 되었고, 이 글을 통해 짧은 회고를 남기고자 한다.
빠르게 만들고, 빠르게 고치던 시절
초기 몇 년간은 정말 정신없이 코드를 썼다. 사용자의 피드백을 빠르게 반영하고, 신규 기능을 추가하고, 기존 기능을 수정하며 “빠르게 만들고, 빠르게 고치는” 것이 가장 중요한 가치였다. 코드의 품질보다는 변화에 대응하는 속도가 더 중요했고, 실제로 그 방식은 제품이 성장하는 데 있어 꽤 유효했다.
하지만 시간이 지나며, 제품이 점차 안정화되고 시장도 변화하면서 우선순위가 조금씩 바뀌기 시작했다. 기능의 추가보다는 안정성과 유지보수가 중요해졌고, 점점 더 변화보다 ‘지속 가능성’이 중요한 가치로 떠올랐다.
기술 부채의 대가
이번 리팩토링 작업의 출발점은 단순한 신규 기능 추가였다. 그런데 막상 들어가 보니 너무 많은 이슈가 얽혀 있었다. 구형 안드로이드 버전, 더 이상 지원되지 않는 라이브러리들, 예상치 못한 CS 이슈들까지…
작은 기능 하나 추가하는 데 과하게 많은 시간과 에너지를 소모하게 된 이유는, 그동안 누적되어 온 기술 부채 때문이었다. 다행히 집중적으로 모듈을 최신화하고 레거시 라이브러리를 교체하며 정리해나갈 수 있었지만, 이번 경험을 통해 몇 가지 깊이 느낀 점이 있다.
소프트웨어도 ‘집’처럼 늙는다
처음엔 새롭고 반짝이던 코드도, 시간이 지나면 점점 낡고 손보지 않으면 안 되는 상태가 된다. 업데이트를 미루고, 문서를 생략하고, 테스트 없이 돌아가는 것만 확인한 채 배포했던 코드들은 결국 유지보수의 큰 장애물이 되었다.
‘잘 동작하니까 굳이 손대지 말자’는 마음이 쌓이면, 결국 어떤 기능 하나를 추가하기 위해서도 전체 구조를 다시 이해하고 하나하나 추적해야만 하는 상황이 된다. 문서화되지 않은 코드, 테스트 없이 돌아가는 함수, 구조화되지 않은 설계는 결국 지금의 나에게 많은 시간을 요구하게 된다.
유지보수 단계에 접어들며 깨달은 것들
이번 리팩토링 과정에서 가장 크게 깨달은 점은, 소프트웨어의 라이프사이클에는 리팩토링과 문서화, 테스트 코드, 자동화가 반드시 포함되어야 한다는 것이다.
초기에는 빠른 개발이 중요하다. 하지만 프로젝트가 어느 시점에 이르면 유지보수라는 또 다른 국면에 진입하게 된다. 이때부터는 다음과 같은 요소들이 핵심이 된다.
- 문서화: 코드의 흐름과 의도를 명확히 기록함으로써, 시간이 지나도 낯선 코드가 되지 않도록 한다.
- 테스트 코드: 시스템의 안정성을 담보하고, 리팩토링이나 기능 추가 시 문제를 조기에 감지할 수 있게 한다.
- 모듈화: 작은 단위로 기능을 책임지고, 다른 영역에 영향을 주지 않는 범위 내에서 유연하게 수정할 수 있도록 한다.
- 자동화: 반복되는 작업은 자동화하여, 시간 낭비를 줄이고 실수를 예방한다.
이런 기본적인 요소들이 갖춰져 있으면, 시간이 지나도 프로젝트는 여전히 유의미하게 진화해나갈 수 있다.
결론: 지속 가능한 개발을 위한 태도
소프트웨어는 그저 동작만 잘한다고 끝나는 게 아니다. 시간이 지나도 관리 가능한 시스템으로 남아야 진짜 살아있는 코드라고 할 수 있다.
빠르게 만들고 피드백을 반영하는 민첩함도 물론 중요하다. 하지만 그 과정 속에서도 최소한의 구조화, 문서화, 테스트가 병행되어야 한다. 그리고 어느 시점부터는 의도적으로 리팩토링과 정리를 우선순위에 두어야 한다.
이번 경험을 통해 나는 소프트웨어가 가지는 ‘시간의 무게’를 실감했고, 앞으로의 개발에서 이 점을 더 깊이 새기고 싶다. 그리고 지금도 내가 만들어가고 있는 코드들이 언젠가 다시 내게 돌아올 때, 조금 더 반가운 얼굴로 마주할 수 있기를 바란다.
