레거시 템플릿 설정값 완전 제거

얼마 전 뭔가 큰 마이그레이션이 있었던 것 같은데, 거기서 남겨진 레거시 설정들을 정리했다. ssul 템플릿 관련 코드가 여기저기 흩어져 있던 게 눈에 띄었고, 특히 metric 시스템의 SITE_ID 값과 content config 카테고리 부분에 아직도 낡은 설정이 남아 있던 상황이었다.

마이그레이션의 마지막 정리 단계

대규모 시스템 리팩토링을 할 때 가장 까다로운 부분이 이거다. 새로운 구조로 주요 로직을 옮기고 나면, 옛날 설정값이나 상수들이 여기저기 남겨진다. 명시적으로 제거되지 않고 조용히 놓여 있는 거 말이다. 특히 여러 레이어에 걸쳐 있으면 더 그렇다.

이 경우가 그랬다. 어떤 이유로든 ssul 이라는 템플릿 엔진에서 벗어나는 작업이 있었는데, content config와 metric API 두 곳 모두에 그 흔적이 남아 있었다. content.config.ts에는 옛 카테고리 정의들이, metric API에는 특정 SITE_ID 값(43으로 나타난 듯)에 종속된 로직이 있었던 것 같다.

정리해야 했던 이유들

이런 남겨진 설정들이 문제가 되는 이유는 몇 가지다.

첫째, 인지 부하다. 새로운 개발자가 와서 코드를 볼 때, 이게 여전히 활성화된 코드인지, 아니면 "언젠가는 지울 거"라는 의도로 남겨진 코드인지 불명확하다. 결국 그게 누군가의 머릿속에만 있으면 팀의 효율성이 떨어진다.

둘째, 유지보수 비용이다. metric 시스템에서 SITE_ID를 다룰 때마다 "왜 43인데?" 하고 물어봐야 하고, 만약 이 값이 언젠가 변경되어야 한다면 이런 레거시 의존성 때문에 변경 영역을 전부 파악하기 어렵다.

셋째, 마이그레이션 완성도다. 처음부터 끝까지 깔끔하게 제거되지 않은 것처럼 보이면, 사람들이 그 마이그레이션을 얼마나 신뢰할 수 있을까? "아, 저게 완전히 끝난 작업이 아니네" 하면서 다른 곳에도 문제가 있을 거라고 의심하게 된다.

정리의 구체적 내용

변경 파일 두 개가 다 건드려진 이유는, 이 레거시 설정들이 구성 레이어(config)에서 시작된 후 API 로직까지 흘러들어갔기 때문이다. 둘 다 정리해야 선순환 구조가 된다.

팀 입장에서의 회고

이런 일이 자주 반복되면 리팩토링 프로세스 자체를 개선해야 한다는 신호다.

• 마이그레이션 체크리스트: 새 시스템으로 옮기기 전에, "이 설정값이 코드베이스에 어디에 쓰이고 있는지" 철저히 파악하고, 마이그레이션 후 "모두 제거되었는지" 명시적으로 확인하는 단계를 넣기.
• 코드 리뷰 시 레거시 감지: PR 리뷰할 때 deprecated나 레거시 코드 섹션을 보면, 함께 제거할 날짜나 조건을 명기하도록 리뷰어 관점에서 지적하기.
• 문서화: 왜 이 값이 43으로 고정되어 있는지, 언제쯤 제거 예정인지 코멘트로 남기기. 그래야 3개월 뒤에도 누가 봐도 "아, 이건 의도된 임시 값이구나" 알 수 있다.

이번 정리는 사실 그런 의도된 정리 단계 중 하나다. 큰 작업을 끝낸 후 "마지막 먼지를 터는" 과정이다. 이게 체계적으로 이루어지면 팀의 코드 웰빙이 한층 높아진다.

🛒 이 글과 어울리는 추천 상품

• 사무의자 쿠팡에서 보기 →
• 모니터 쿠팡에서 보기 →
• 커피머신 쿠팡에서 보기 →

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.