#Frontend
모노레포 환경에서 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
Continue reading · same source
More from 무신사
View all posts from 무신사
AI Native 조직은 도메인 지식을 어떻게 공유하는가
LLMAI AgentDomain Modeling5일 전코딩만 빨라졌다고요? 아뇨, 일하는 방식이 다 뜯어고쳐졌습니다.
AIGenerative AISDLC6일 전MATCH란 무엇인가
CDPMachine LearningAudience Targeting1개월 전의심했던 범인은 알리바이가 있었다.
Java Flight RecorderSpring BatchAurora MySQL1개월 전
LLM 비용 64% 절감, 캐시 히트율 98% 달성기
AWS BedrockPrompt CachingLangChain4j1개월 전