Read Original
#Frontend

모노레포 환경에서 i18next 다국어 시스템 구축하기

모노레포 환경에서 i18next 다국어 시스템 구축하기
01

Summary

무신사 글로벌은 어떻게 30개 앱의 다국어 번들을 15%나 줄였을까?

pnpm 모노레포와 i18next를 활용한 고성능 국제화 시스템 최적화 전략

글로벌 서비스 확장 과정에서 발생하는 번들 크기 비대화와 성능 저하 문제를 해결하기 위한 무신사 프론트엔드 팀의 기술적 여정을 담았습니다. 단순한 라이브러리 도입을 넘어 모노레포 환경에 최적화된 빌드 전략과 자동화된 번역 워크플로우를 구축한 실전 노하우를 공유합니다.

  • 01Lokalise와 GitHub Actions를 활용한 무중단 번역 자동화 워크플로우 구축
  • 02동적 임포트의 한계를 극복하기 위해 VITE_LANG 기반 정적 빌드 전략 도입
  • 03불필요한 언어 리소스 제거를 통해 네트워크 로딩 시간 최대 800ms 단축
  • 04정적 분석 스크립트를 활용하여 빌드 단계에서 누락된 번역 키를 감지하는 시스템 구현

RECOMMENDATION

모노레포 환경에서 다국어 지원을 고민 중이거나, 대규모 서비스에서 i18n 번들 최적화가 필요한 프론트엔드 개발자에게 이 아티클의 빌드 타임 언어 결정 전략을 적극 추천합니다.

The Problem

무신사 글로벌은 30여 개의 pnpm 모노레포 환경에서 13개국 서비스를 지원하며, 초기에는 모든 번역 데이터를 한꺼번에 로드하여 번들 크기가 비대해지고 네트워크 성능이 저하되는 문제를 겪었습니다.

The Solution

Lokalise TMS와 GitHub Actions를 연동하여 번역 워크플로우를 자동화하고, 빌드 시점에 VITE_LANG 환경 변수를 활용한 정적 임포트 방식을 도입하여 언어별 번들 분리와 Tree-shaking을 적용했습니다.

The Result

9개 주요 앱 기준 총 741KB의 번들 크기를 절감하여 평균 약 15%의 용량을 감소시켰으며, 3G 네트워크 환경 기준 로딩 시간을 최대 800ms까지 단축하는 성과를 거두었습니다.

Trade-off

빌드 시점에 언어를 결정하는 방식을 채택함에 따라 언어별 별도 빌드가 필요하며, 런타임에 동적으로 여러 언어를 즉시 전환해야 하는 특수 상황에서는 추가적인 아키텍처 대응이 필요할 수 있습니다.

03

Key Concepts

Concept · 01

Lokalise

개발자와 번역가의 협업을 지원하는 클라우드 기반 번역 관리 시스템(TMS)입니다.

  • API와 CLI를 통해 GitHub 워크플로우와 연동하여 번역 파일 업데이트 자동화
  • 번역 키 수정 시 슬랙 알림 및 PR 생성 기능 제공
Concept · 02

Tree-shaking

빌드 과정에서 실제 사용되지 않는 코드를 제거하여 번들 크기를 최적화하는 기술입니다.

  • 동적 import 대신 정적 import와 조건부 빌드를 결합하여 불필요한 언어 리소스 제거
  • VITE_LANG 환경 변수를 통해 빌드 타임에 특정 언어 데이터만 포함하도록 설계
Concept · 03

saveMissing

i18next 라이브러리에서 제공하는 기능으로, 코드 내에서 정의되었으나 번역 파일에 없는 키를 감지하는 옵션입니다.

  • 개발 환경에서 누락된 번역 키를 콘솔에 노출하여 추적 가능하게 지원
  • 무신사는 이를 응용하여 빌드 단계에서 정적 분석으로 누락 키를 추출하는 스크립트 구현