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

0

프로젝트가 커지고 시간이 지날수록 잘 사용했던 기반 기술이 최선의 선택이 아닌 순간이 옵니다. 이를 방치하면 개발 생산성 저하와 예측할 수 없는 문제들이 발생할 수 있습니다. 그러나 안정적인 운영과 기술 마이그레이션은 쉽지 않은 과제입니다. 이 글에서는 토스의 TUBA 팀에서 이런 문제를 어떻게 해결했는지 소개해드리겠습니다.

토스의 만능 어드민, TUBA

TUBA(Toss User Behavior Analyzer)는 토스 임직원용 데이터 솔루션으로, A/B 테스트, 메세지, 유저 세그먼트 등 22개의 하위 제품이 포함되어 있습니다. 다양한 직군의 임직원이 사용하는 이 제품은 오래된 프로젝트로, 여러 문제가 발생했다고 합니다.

첫 번째 시련: 너무 오래 걸리는 빌드

TUBA의 빌드 속도는 매우 느려졌습니다. yarn workspace를 사용해 frontend 하위 서비스와 공통 모듈을 관리했지만, 작은 수정에도 모든 서비스를 새로 빌드해야 했고, 빌드 타임은 2시간 15분으로 늘어났다고 합니다.

빌드 속도 문제의 원인은 next 12와 Module Federation, SSG 빌드 방식에 있었습니다. TUBA 팀은 next의 필요성을 재검토한 후, next에서 webpack으로 마이그레이션을 시작했습니다. 이를 위해 next-polyfill 패키지를 만들어 대체 기능을 구현했습니다. 이 과정에서 빌드 시간이 약 86% 감소했다고 합니다.

두 번째 시련: 지원이 종료된 패키지

Recoil 패키지가 지원 종료되면서, TUBA 팀은 활발히 관리되며 코드 영향이 적은 Jotai로 대체했습니다. ts-morph 패키지를 활용해 코드를 분석하고, Recoil 함수를 Jotai 함수로 자동 변경했습니다. 이로써 약 100초 만에 900개 파일을 마이그레이션할 수 있었다고 합니다.

결론

TUBA 팀의 마이그레이션 사례는 기술 리팩토링이나 deprecated 패키지 제거를 고려하는 프로젝트에 큰 도움이 될 것입니다. 이렇게 안정적이고 효율적인 운영을 위해서는 꾸준한 기술 점검과 업데이트가 필요합니다.

답글 남기기