10년 된 레거시 코드, 3개월 갈아엎은 이야기
입사하자마자 배치된 프로젝트가 '아무도 안 건드리는 서비스'였음. 커밋 로그 마지막이 3년 전이었고, 담당자도 퇴사한 지 오래.
처음 2주는 구조를 파악하는 데 다 썼고, 그다음 2주는 이게 왜 이렇게 짜였는지 추측하는 데 썼음. 결론은 '그때 급했으니까'였음. 문서가 없는 게 아니라 애초에 '이렇게 하면 일단 돌아간다'만 기록되어 있었음.
그다음부턴 순서를 정해서 갔음. 첫째, 테스트를 먼저 깖. 이게 진짜 반은 먹고 들어감. 기존 동작을 고정해두니까 겁 없이 뜯을 수 있었음. 둘째, 한 번에 하나만 바꿈. 리팩토링이랑 기능 추가를 같이 하면 반드시 사고 남. 셋째, 바꿀 때마다 팀에 공유. 혼자 알고 있으면 나중에 다 뒤집어씀.
결과적으로 코드 줄 수는 40% 줄었고, 배포는 수동 스크립트에서 CI로 바뀌었음. 솔직히 기술적으로 어려운 건 하나도 없었음. 어려운 건 '이걸 해도 되는가'에 대한 합의였음.
회사에서 레거시 만나면 일단 겁먹지 마시고 테스트부터 까시길. 그게 제일 빨라요.
5 개의 답변
'이걸 해도 되는가에 대한 합의' 이 부분이 핵심인 듯. 기술은 결국 사람 설득이 반이야.
테스트 먼저 까는 거 진짜 ㅇㅈ. 레거시 손댈 때 제일 무서운 게 '이거 왜 이렇게 짜놨지'인데 그거 파악하느라 시간 다 날리잖아요.
3개월에 40% 감소면 사실상 재작성 아님? 솔직히 궁금한 게 리팩토링 중에 장애 난 적은 없음? 글에서는 '한 번에 하나만' 강조했는데 그 3개월 동안 운영 이슈는 어떻게 처리했는지 빠져 있어서 좀 아쉽네. 우리 팀은 비슷한 규모로 진행하다가 배포 직후 롤백 두 번 하고 접었거든. 테스트 커버리지가 어느 정도였는지도 알려주면 좋겠다.