결정 01
번역 키는 화면이 아니라 도메인 기준으로 나눈다
- 문제
- 처음에는 페이지별로 메시지 파일을 나눴는데, 같은 문구가 여러 페이지에 등장하면서 번역이 갈라졌습니다. 한쪽만 고치면 다른 쪽이 그대로 남습니다.
- 선택
- 공통 용어를 도메인 단위 네임스페이스로 묶고, 페이지 전용 문구만 페이지 파일에 남겼습니다.
- 결과
- 같은 개념은 항상 같은 단어로 번역됩니다. 번역 담당자에게 넘길 파일 구조도 더 설명하기 쉬워졌습니다.
처음 해 본 국제화, 그리고 끝내지 못한 프로젝트


워드프레스로 만들어진 기업 사이트를 Next.js로 리뉴얼하면서 다국어를 지원해야 했습니다. 국제화 작업은 처음이었고, 참고할 사내 선례도 없었습니다.
공식 문서와 해외 영상 자료를 보며 next-intl을 단기간에 익혀 적용했습니다. 라우트에 로케일을 넣고, 메시지 파일을 분리하고, 서버 컴포넌트에서 번역을 읽는 구조까지 세웠습니다.
다만 개발 도중 다른 프로젝트에 투입되면서 배포까지 마치지 못했습니다. 이후 회사의 경영 사정으로 퇴사하게 되어 끝내 마무리하지 못한 작업이 됐습니다. 결과물로 자랑할 수 있는 프로젝트는 아니지만, 국제화의 구조를 처음부터 세워 본 경험은 이후 작업에 계속 남았습니다.
문제가 무엇이었고, 무엇을 골랐고, 그래서 어떻게 됐는지.
결정 01
결정 02
로케일을 경로에 두고 언어별 URL과 hreflang을 제공.
공통 용어와 페이지 전용 문구를 분리해 번역 일관성을 유지.
기존 페이지 구조를 정리해 Next.js 라우트로 재구성.
Desktop
Mobile · 반응형

01

02

03

04

05
완성하지 못한 프로젝트를 기록에 남기는 것이 맞는지 고민했지만, 남기기로 했습니다. 실제 일에서는 끝까지 가지 못하는 작업도 있고, 거기서 배운 것도 남습니다.
국제화는 라이브러리 사용법의 문제가 아니라 정보 구조의 문제였습니다. 번역 키를 어떻게 나누느냐가 나중에 번역 품질을 결정한다는 걸, 한 번 잘못 나눠 보고 나서야 알았습니다.
짧은 기간에 낯선 도구를 익혀 적용해야 하는 상황이 실무에서는 자주 옵니다. 공식 문서를 먼저 끝까지 읽는 습관은 이때 생겼습니다.