프로젝트 전체에서 사용되는 패키지, 어떻게 마이그레이션 할까?

TUBA는 공통 코드 수정 때 22개 서비스를 모두 빌드해야 해 빌드가 느려지고 메모리 문제까지 겪었습니다. 내부 서비스에서 SSR의 이점이 작고 Next 기능을 거의 쓰지 않는다고 판단해, 기존 인터페이스를 구현한 next-polyfill을 만들고 webpack으로 점진적으로 옮겨 빌드 시간을 약 86% 줄였습니다. 지원이 불안정해진 Recoil은 유지보수와 코드 변경 범위를 고려해 Jotai로 전환하기로 했고, ts-morph로 함수 호출을 AST 기반으로 찾아 자동 변경했습니다. 자동화 후 타입 오류를 보완하며 900여 개 파일의 마이그레이션을 진행한 경험은 대규모 패키지 교체에서 호환 계층과 반복 가능한 변환 스크립트가 유용하다는 점을 보여줍니다.

• 공통 패키지 변경이 여러 서비스의 전체 빌드로 이어진다면, 의존성과 빌드 구조를 함께 점검하세요.
• 프레임워크를 제거할 때는 기존 인터페이스를 흉내 내는 호환 패키지를 두면 코드 수정 범위를 줄이며 점진적으로 전환할 수 있습니다.
• 상태 관리 라이브러리처럼 사용처가 많은 패키지는 활발한 유지보수 여부와 기존 코드와의 유사성을 기준으로 대안을 고르세요.
• ts-morph로 TypeScript AST를 분석하면 반복적인 함수명·import 변경을 자동화할 수 있지만, 변환 스크립트가 놓친 타입 오류는 별도로 확인해야 합니다.