프론트엔드 개발자 엄성준 블로그

기존에 작성했던 React i18n 다국어 처리 빌드 크기 최적화 1 글에 이어지는 내용입니다. 이전 글에서는 프로젝트 내 src 하위에서 관리하던 다국어 파일을 public 디렉터리로 분리하고, i18next-http-backend를 활용해 런타임 시 필요한 언어만 로드하도록 개선하면서 JS 번들 크기와 초기 로딩 성능을 개선한 경험을 공유했습니다. 이번 글에서는 그 다음 단계로, Google Sheet로 관리하던 다국어 데이터를 페이지 단위로 분리해 각 페이지에서 정말 필요한 다국어만 로드하도록 최적화한 과정을 정리해보려고 합니다.key 설계 배경: namespace.key 구조를 미리 선택한 이유이번 최적화는 갑자기 구조를 바꿔서 진행한 작업은 아니었습니다. 실제로 다국어를 처음 설계할 당시부터, ..

프로젝트 내 다국어(i18n)를 관리하다 보면, 기능이 변경되거나 삭제될 때마다 사용하지 않는 번역 키가 남게 됩니다.이번에는 WiniLogis 프로젝트에서 점점 쌓여가던 불필요한 다국어 키를 정리한 과정을 공유하려고 합니다.❗️ 문제 상황WiniLogis에서는 Google Cloud Sheet를 기반으로 다국어를 관리하고 있습니다. 개발 환경에서는 스크립트를 통해 Sheet에 작성된 다국어 데이터를 public/locales/{언어}/translation.json 형태로 변환하여 저장합니다.public/ └─ locales/ ├─ en/translation.json ├─ es/translation.json └─ ru/translation.json 그러나 프로젝트가 커지고 여러 기능..

🌍 React i18n 다국어 처리 최적화, 실제 적용기Autowini 서비스를 개발하면서 다국어(i18n) 지원을 위해 react-i18next를 도입해 사용하고 있었습니다.처음에는 번역 JSON 파일을 import해서 사용하는 방식으로 구축했지만, 프로젝트가 커질수록 청크 파일 크기 증가와 초기 로딩 성능 저하 문제를 겪게 됐습니다. 그래서 언어 처리 방식을 아예 바꾸고 i18n 번들 최적화를 적용했습니다. 그 과정을 공유해 보려고 합니다.📌 기존 방식: import로 언어 번들 포함처음에는 아래와 같이 다국어 JSON을 import해서 resources에 직접 넣는 방식이었습니다.import ko from './locales/ko/translation.json';import en from '...