문서

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

김덕원 토스 · 토스 기술 블로그

AI 핵심 요약

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

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

소개

시간이 지날수록 그동안 잘 사용했던 기반 기술들이 더 이상 최선의 선택이 아닌 순간이 오는데요. 제품을 계속 안정적으로 운영하면서 마이그레이션 또한 쉽지 않습니다. 오늘은 토스의 TUBA 팀에서는 이런 문제를 어떻게 해결했는지 소개드릴게요.

비슷한 학습 자료

문서 박서진/이다용

es-toolkit: How a Small Internal Library Became a Global Project

문서 박서진/이다용

*This is the English version of a previously published article. Hello! We're Sojin Park, Head of Frontend Engineering at Toss, and Dayong Lee, Frontend Developer at Toss Bank. Today, we'd like to share the story of es-toolkit: how it started as a small utility function library inside Toss and grew i...

프론트엔드 프로그래밍 언어