프로덕션 깜짝 상황 없는 Vue 3 i18n 워크플로우 (500+ 키)

500개가 넘는 i18n 키에서 무엇이 잘못되는가

앱에 수백 개의 문자열이 넘어가면 처음에 깨지는 것은 보통 Vue I18n 자체가 아닙니다. 일관성이 깨집니다. 사람들이 서로 다른 스타일로 키를 추가하고, 같은 의미를 중복해서 다른 이름으로 만들고, 어떤 메시지를 삭제해도 되는지 아무도 확신하지 못하게 됩니다.

번역 누락도 드물지 않게 됩니다. 설정, 오류 상태, 빈 상태, 알림처럼 잘 사용되지 않는 화면에서 일반 사용자 경로에 나타납니다.

번역이 없을 때 사용자가 보게 되는 실패는 보통 세 가지입니다: 빈 UI(레이블 없는 버튼), 원시 키(예: checkout.pay_now), 또는 페이지 일부가 다른 언어로 바뀌는 이상한 폴백. 어느 쪽도 작은 버그처럼 보이지 않습니다. 앱이 깨진 것처럼 보이게 합니다.

그래서 특정 라이브러리보다 Vue 3 i18n 워크플로우가 더 중요합니다. 라이브러리는 요청한 대로 동작합니다. 규모가 커지면 팀들이 "완료"의 기준에 합의하지 못하는 경우가 많습니다.

흔한 예: 개발자가 40개의 새 문자열을 포함한 "동료 초대" 흐름을 배포합니다. 영어 파일만 업데이트되고 프랑스어 파일은 업데이트되지 않습니다. 스테이징에서는 테스터가 영어를 쓰기 때문에 모두 정상으로 보입니다. 프로덕션에서는 프랑스어 사용자가 번역된 UI와 번역되지 않은 UI가 섞인 화면을 보게 되고, 지원팀에는 원시 키 스크린샷이 올라옵니다.

해결책은 번역된 UI에 대해 "완료"가 무엇인지 정의하는 것입니다. 단순히 "문자열이 추가되었다"만으로는 충분하지 않습니다. 현실적인 완료 정의에는 보통 다음이 포함됩니다: 키가 네이밍 규칙을 따르고 로케일 빌드에서 missing-key 경고가 없고, 복수형과 변수들이 실제 데이터로 올바르게 렌더링되며, 최소 하나 이상의 비기본 로케일이 체크되고, 카피 변경이 추적되어 오래된 키가 남지 않도록 하는 것.

500개가 넘으면 로컬라이제이션을 막바지 파일 편집이 아니라 릴리스 프로세스로 다루는 쪽이 이깁니다.

문자열을 더 추가하기 전에 몇 가지 규칙을 정하라

수백 개의 문자열이 넘어가면 번역 작업 자체는 큰 문제가 아닙니다. 일관성이 문제입니다. 소규모 규칙 세트는 여러 사람이 매주 카피를 건드려도 Vue 3 i18n 워크플로우를 예측 가능하게 만듭니다.

먼저 “개념”이 무엇인지 정의하고 그 개념에 대해 하나의 진실 소스(source of truth)를 유지하세요. 같은 UI 아이디어가 다섯 곳에 나온다면(예: “변경 사항 저장”) 하나의 키를 원합니다. save, saveChanges, save_update, saveBtn 같은 다섯 가지 변형이 아닌 하나의 키를 사용하세요. 중복 키는 시간이 지나며 의미가 흐려지고 사용자 경험에서 일관성이 사라집니다.

다음으로 포맷팅의 위치를 결정하세요. 팀은 실수로 이를 나누는 경우가 많습니다: 어떤 메시지는 문장 부호와 대소문자까지 포함하고, 다른 메시지는 코드가 추가합니다. 한 가지 접근을 선택하고 지키세요.

실용적인 기본 규칙:

• 문법, 문장부호, 사용자에게 보이는 포맷(예: “(선택 사항)”)은 메시지에 넣으세요.
• 순수한 데이터 포맷(날짜, 통화, 단위)은 코드에서 처리한 다음 그 결과를 i18n에 전달하세요.
• 이름과 수량 같은 가변 부분은 문자열 결합이 아니라 플레이스홀더를 사용하세요.
• 메시지에 HTML을 넣는 것은 특수 사례로 명확한 규칙(허용 여부)을 정하세요.

그다음 소유권을 정의하세요. 누가 새 키를 추가할 수 있는지, 누가 기본 언어 카피를 검토하는지, 누가 다른 로케일을 승인하는지 결정하세요. 이것이 없으면 문자열이 급하게 추가되고 검토되지 않습니다.

마지막으로 폴백 전략을 선택하고 문서화하세요. 키가 없을 때 사용자가 무엇을 보아야 할까요: 키 이름, 기본 로케일 텍스트, 아니면 안전한 일반 메시지? 프로덕션에서는 많은 팀이 기본 로케일로 폴백하고 로깅을 추가하는 방식을 선호합니다. 사용자가 차단되지 않고 문제를 알 수 있는 신호를 받을 수 있기 때문입니다.

AppMaster 같은 제너레이터(AppMaster (appmaster.io))로 Vue 3 앱을 만든다면 이 규칙들은 여전히 적용됩니다. 번역을 "그냥 개발 텍스트"로 보지 말고 제품 콘텐츠로 다루면 대부분의 늦은 깜짝 문제를 피할 수 있습니다.

읽기 쉬운 키 네이밍 규칙

수백 개 이상의 문자열에서는 일관성이 가장 큰 영향을 미칩니다. 한 가지 키 스타일을 선택하세요(대부분 팀은 billing.invoice.title 같은 점(dot) 경로를 사용합니다) 그리고 이를 규칙으로 만드세요. 점, 슬래시, snake_case, 임의의 캐싱을 혼합하면 검색과 리뷰가 느려집니다.

카피 변경을 견딜 수 있는 안정적인 키를 사용하세요. "Please enter your email" 같은 키는 마케팅이 문장을 조금 바꾸는 순간 깨집니다. auth.email.required나 auth.email.invalid처럼 의도를 기반으로 한 이름을 선호하세요.

먼저 제품 영역이나 UI 표면으로 키를 그룹화하고 그다음 목적별로 나누세요. 이미 앱이 가진 카테고리로 생각하세요: auth, billing, settings, support, dashboard. 이렇게 하면 로케일 파일을 스캔하기 쉬워지고, 두 화면에서 같은 아이디어가 필요할 때 중복을 줄일 수 있습니다.

각 영역 내에서 공통 UI 요소에 대해 작은 패턴 집합을 유지하세요:

• 버튼: *.actions.save, *.actions.cancel
• 레이블: *.fields.email.label, *.fields.password.label
• 힌트/도움말 텍스트: *.fields.email.hint
• 에러/검증: *.errors.required, *.errors.invalidFormat
• 알림/토스트: *.notices.saved, *.notices.failed

동적 메시지는 무엇이 바뀌는지를 말해야지 어떻게 바뀌는지를 말하면 안 됩니다. 변수 부분은 파라미터로 처리하고 메시지 이름은 의도로 명명하세요. 예: billing.invoice.dueInDays에 {days}를 쓰는 것이 billing.invoice.dueIn3Days보다 명확합니다.

예시(이 방식은 Vue 3 i18n 워크플로우에 잘 맞습니다): orders.summary.itemsCount에 {count}로 수량을, orders.summary.total에 {amount}로 금액을 넣습니다. 코드에서 키를 보면 해당 키가 어디에 속하는지, 왜 존재하는지 알 수 있어야 합니다. 최종 문구가 바뀌더라도 의미가 유지되어야 합니다.

예기치 않은 복수형 규칙과 메시지 포맷팅 방지

영어처럼 모든 언어를 취급하면 복수형 텍스트는 조용히 깨집니다. 언제 ICU 메시지 문법을 사용할지, 언제 단순 플레이스홀더로 충분할지 미리 결정하세요.

라벨이나 숫자에 따라 바뀌지 않는 짧은 UI 텍스트에는 단순 치환을 사용하세요(예: Welcome, {name}). 숫자에 따라 달라지는 것은 ICU 문법을 사용하세요. ICU는 모든 형태를 한 곳에 모아 규칙을 명확히 해줍니다.

{
  "notifications.count": "{count, plural, =0 {No notifications} one {# notification} other {# notifications}}"
}

번역하기 쉬운 방식으로 카운트 메시지를 작성하세요. 전체 문장을 선호하고 숫자 플레이스홀더(#)를 명사 근처에 두세요. "1 항목"과 "2 항목"을 같은 키로 재사용하는 식의 트릭을 피하세요. 번역자는 전체 메시지를 보고 번역해야지 어떻게 이어붙일지 추측하면 안 됩니다.

최소한 =0, one, other를 계획하고 0에 대해 팀이 어떤 스타일을 원하는지 문서화하세요. 어떤 제품은 "0 items"를 원하고 다른 제품은 "No items"를 원합니다. 하나의 스타일을 정하고 지켜서 UI의 일관성을 유지하세요.

또한 기대보다 더 많은 복수 카테고리를 가진 언어가 있다는 점을 주의하세요. 많은 언어가 단순히 "one vs many"를 따르지 않습니다. 나중에 새로운 로케일을 추가하면 one과 other만 있는 메시지는 문법적으로 틀릴 수 있습니다.

배포 전에 UI에서 실제 카운트로 복수를 테스트하세요. JSON만 보는 것이 아니라 화면에서 0, 1, 2, 5, 21 같이 검사하는 간단한 체크가 대부분의 문제를 잡아냅니다.

Vue3 웹 앱을 구축했다면(예: AppMaster 안에서) 이 테스트를 실제 텍스트가 표시되는 화면에서 하세요. 레이아웃 문제, 글자 잘림, 어색한 문장 구성이 그곳에서 먼저 드러납니다.

성장에 맞춘 로케일 파일 구성

수백 개의 문자열이 넘어가면 하나의 큰 en.json이 병목이 됩니다. 여러 사람이 같은 파일을 건드리면 머지 충돌이 늘고 카피가 어디에 있는지 추적하기 어려워집니다. 좋은 구조는 제품이 바뀌어도 Vue 3 i18n 워크플로우를 안정적으로 유지합니다.

권장 구조

2~5개 로케일에는 기능별 분리가 보통 충분합니다. 모든 로케일에서 동일한 파일 구조를 유지하여 키 추가가 예측 가능한 편집이 되게 하세요.

• locales/en/common.json, locales/en/auth.json, locales/en/billing.json
• locales/es/common.json, locales/es/auth.json, locales/es/billing.json
• locales/index.ts (메시지를 로드하고 병합)

20개 이상의 로케일에는 같은 아이디어를 확장하되 드리프트가 일어나기 어렵게 만드세요. 영어를 진실의 소스(source of truth)로 삼고 모든 로케일이 동일한 폴더와 파일 이름을 미러링하도록 강제하세요. 새로운 도메인(예: notifications)이 나타나면 모든 로케일에 그 파일이 있어야 합니다. 임시 텍스트라도 구조가 같아야 예측 가능성이 유지됩니다.

도메인별 분리는 두 사람이 서로 다른 파일에 문자열을 추가하면 충돌이 줄어듭니다. 도메인은 앱이 구성된 방식과 일치해야 합니다: common, navigation, errors, settings, reports, 그리고 큰 영역은 피처 폴더로 분리하세요.

키 일관성 유지

각 파일 내에서는 로케일 전반에 걸쳐 동일한 키 모양을 유지하세요: 같은 네스팅, 같은 키 이름, 다른 텍스트. 언어별로 창의적인 키를 사용하지 마세요. 영어에 billing.invoice.status.paid가 필요하면 모든 로케일에 동일한 키가 있어야 합니다.

진정으로 반복되는 것만 중앙화하세요: 버튼 라벨, 일반 검증 에러, 글로벌 내비게이션 같은 것들입니다. 기능별 카피는 해당 기능 도메인 가까이에 두세요. 예: "Save"는 common에, "Save payment method"는 billing에 둡니다.

장문의 콘텐츠

긴 도움말 텍스트, 온보딩 단계, 이메일 템플릿은 빨리 지저분해집니다. 몇 가지 규칙이 도움이 됩니다:

• 장문은 별도의 도메인(예: help 또는 onboarding)에 두고 깊은 네스팅을 피하세요.
• 번역자가 안전하게 작업할 수 있도록 긴 문단 하나보다는 짧은 문단을 선호하세요.
• 마케팅이나 지원팀이 자주 편집하는 텍스트는 전용 파일에 두어 다른 곳의 변경을 줄이세요.
• 이메일은 제목(subject)과 본문(body)을 분리해서 저장하고 플레이스홀더(이름, 날짜, 금액)를 일관되게 유지하세요.

이런 설정은 변경 검토, 번역 작업, 릴리스 직전의 깜짝 누락 방지에 도움이 됩니다.

문자열 추가 및 배포를 위한 단계별 워크플로우

안정적인 Vue 3 i18n 워크플로우는 도구보다 매번 같은 작은 단계를 반복하는 것에 가깝습니다. 새 UI 텍스트는 키, 기본 메시지, 명확한 번역 상태 없이 프로덕션에 도달해서는 안 됩니다.

먼저 기본 로케일(보통 en)에 키를 추가하세요. 기본 텍스트는 실제 카피처럼 작성하고 자리표시자처럼 두지 마세요. 이렇게 하면 프로덕트와 QA가 읽어서 검토할 수 있고 나중에 "미스터리 문자열"을 방지할 수 있습니다.

컴포넌트에서 키를 사용할 때는 처음부터 파라미터와 복수 로직을 포함해 번역자가 메시지의 전체 형태를 볼 수 있게 하세요.

// simple param
$t('billing.invoiceDue', { date: formattedDate })

// plural
$t('files.selected', count, { count })

번역이 준비되지 않았다면 키를 비워두지 마세요. 다른 로케일에 자리표시자 번역을 추가하거나 일관된 방식으로 미완료(TODO: 접두사 등)로 표시하세요. 중요한 것은 앱이 예측 가능하게 렌더링되고 리뷰어가 미완료 카피를 쉽게 식별할 수 있어야 한다는 점입니다.

머지 전에 빠른 자동화 검사들을 실행하세요. 이 검사들은 지루하고 엄격해야 합니다: 로케일 간 누락된 키, 사용되지 않는 키, 플레이스홀더 불일치(예: {count}나 {date} 누락 또는 잘못된 중괄호), 지원되는 언어에 맞지 않는 복수형, 우발적 오버라이드 등을 검사하세요.

마지막으로 최소 하나의 비기본 로케일에서 짧은 UI 검사를 하세요. 문자열이 긴 언어(종종 독일어 또는 프랑스어)를 선택해 오버플로우, 잘리는 버튼, 어색한 줄바꿈을 잡아내세요. Vue 3 UI가 제너레이터로 생성되거나 제품의 다른 부분과 함께 유지된다면(예: Vue3 웹 앱을 AppMaster로 만든 경우) 이 단계는 레이아웃이 기능 변화에 따라 바뀌기 때문에 여전히 중요합니다.

이 단계를 모든 텍스트 추가 기능의 완료 정의로 다루세요.

팀들이 반복하는 흔한 실수

로컬라이제이션을 고통스럽게 만드는 가장 빠른 방법은 i18n 키를 "그저 문자열"로 취급하는 것입니다. 수백 개의 키가 쌓이면 작은 습관들이 프로덕션 버그로 이어집니다.

의미가 흐려지거나 충돌하거나 거짓인 키들

오타와 대소문자 차이는 누락된 텍스트의 고전적 원인입니다: 어떤 곳에서는 checkout.title, 다른 곳에서는 Checkout.title. 코드 리뷰에서는 괜찮아 보이다가 폴백 언어가 조용히 배포됩니다.

또 다른 흔한 문제는 하나의 키를 다른 의미로 재사용하는 것입니다. "Open"이 지원 화면에서는 "티켓 열기"를 뜻하고 상점 페이지에서는 "지금 열기"를 뜻한다면 같은 키를 재사용하면 다른 언어에서 한 화면이 틀리게 됩니다. 번역자가 추측하게 되는 상황이 생깁니다.

간단한 규칙: 하나의 키는 하나의 의미입니다. 의미가 바뀌면 영어 텍스트가 같아도 새 키를 만드세요.

"문자열 모양" 가정에서 오는 레이아웃 버그

팀은 종종 번역에서 문장부호, 공백, HTML 일부를 하드코딩합니다. 언어에 따라 문장부호가 달라지거나 UI가 마크업을 다르게 이스케이프/렌더링하면 문제가 생깁니다. 마크업 결정은 템플릿에 두고 메시지는 텍스트에 집중하게 하세요.

모바일에서 문제가 숨겨지는 경우가 많습니다. 영어에 맞는 레이블이 독일어에서는 세 줄로 감기거나 태국어에서는 넘칠 수 있습니다. 한 화면 크기만 테스트하면 놓치게 됩니다.

반복적으로 문제를 일으키는 것들을 주시하세요: 변수(이름, 수량, 날짜)를 삽입할 때 영어 단어 순서를 가정하는 것, 메시지를 여러 조각으로 이어붙이는 것 대신 하나의 메시지를 사용하는 것, 긴 값(제품명, 주소, 오류 세부) 테스트를 잊는 것, 누락된 키가 "영어로 보여져서" 괜찮아 보이도록 조용히 폴백을 켜둔 상태로 배포하는 것, 영어 값만 편집하면서 키는 재사용하는 것 등.

500개 이상의 키를 안정적으로 유지하고 싶다면 키를 API의 일부로 취급하세요: 안정적이고 구체적이며 다른 것들처럼 테스트하세요.

번역 누락을 조기에 발견하는 QA 단계

번역 누락은 앱이 여전히 "동작"하기 때문에 발견하기 어렵습니다. 단지 키나 잘못된 로케일, 빈 문자열로 폴백할 뿐입니다. 번역 커버리지를 테스트처럼 다루어 배포 전에 빠른 피드백을 받으세요.

자동화 검사(모든 PR에서 실행)

빌드를 실패하게 만드는 검사부터 시작하세요. 경고만 출력하는 검사는 아무도 보지 않습니다.

• 코드베이스에서 $t('...')와 t('...') 사용을 스캔하고 사용된 모든 키가 기본 로케일에 존재하는지 확인하세요.
• 로케일 간 키 집합을 비교하고 어떤 로케일이라도 키가 누락되면 실패시키세요(예외 목록은 짧게 유지).
• 로케일 파일에 존재하지만 사용되지 않는 고아 키를 표시하세요.
• 메시지 문법(플레이스홀더, ICU/플럴 블록)을 검증하세요. 하나의 깨진 메시지가 런타임에서 페이지를 깨뜨릴 수 있습니다.
• 중복 키나 일관성 없는 대소문자는 에러로 처리하세요.

예외 목록은 짧고 팀이 소유하게 하세요. "CI를 통과하는 것"이 예외의 주인이 되지 않도록 합니다.

런타임 및 시각적 검사(스테이징)

CI가 있어도 실제 사용자 경로에서 트리거되는 문자열을 잡아내기 위해 스테이징에 안전망을 두어야 합니다.

스테이징에서 missing-translation 로깅을 활성화하고 빠르게 고칠 수 있도록 컨텍스트(로케일, 라우트, 컴포넌트 이름 등)를 포함하세요. 눈에 띄게 만드세요. 무시하기 쉬우면 무시됩니다.

의사-로케일(pseudo-locale)을 추가해 빠른 UI 점검을 하세요. 문자열을 변형해 길게 만들고 표시 마커를 넣으면 레이아웃 문제가 바로 눈에 띕니다(예: [!!! 𝗧𝗲𝘅𝘁 𝗲𝘅𝗽𝗮𝗻𝗱𝗲𝗱 !!!]). 잘림, 표 헤더 깨짐, 공백 문제를 사전에 잡아낼 수 있습니다.

마지막으로 사전 릴리스에서 핵심 흐름을 2~3개 로케일로 빠르게 확인하세요: 로그인, 결제/체크아웃, 핵심 설정, 그리고 이번에 출시하는 새 기능. 여기서 "번역은 되어 있으나 플레이스홀더가 잘못된" 버그를 잡습니다.

새로운 언어 추가와 지속적인 카피 변경 처리

새로운 언어를 추가하는 일을 "단순 카피 작업"이 아니라 소규모 제품 릴리스로 다루면 복잡함을 줄일 수 있습니다. 앱은 로케일이 불완전해도 빌드되게 하되, 사용자에게 보이기 전에 격차가 명확하게 드러나게 하세요.

새 로케일을 추가할 때는 번역부터 하지 말고 구조부터 생성하세요(보통 en의 파일 형태를 복사).

• 소스 로케일의 전체 키 집합을 복사해 새 로케일 폴더/파일을 만드세요.
• 값은 TODO 자리표시자로 표시해 QA에서 누락 문자열이 보이게 하세요.
• 기본 항목이 커버되기 전까지는 언어 선택기에 새 로케일을 추가하지 마세요.
• 화면별로 한 번씩 확인해 긴 단어, 줄바꿈 문제를 체크하세요.

번역은 늦게 오는 경우가 많으니 "부분적"이 제품에서 무엇을 의미하는지 미리 정하세요. 고객 대상 기능이면 기능 플래그를 사용해 기능과 문자열을 함께 배포하세요. 전체 번역 없이 배포해야 한다면 빈 레이블보다는 명확한 폴백(예: 영어)을 선호하되 스테이징에서는 크게 표시되도록 하세요.

카피 업데이트는 키를 망가뜨리는 지점입니다. 문구를 바꿀 때는 키를 안정적으로 유지하세요. 키는 정확한 문장을 설명하면 안 되고 의도를 설명해야 합니다. 의미가 바뀔 때만 키 이름을 바꾸고, 그때도 통제된 마이그레이션으로 진행하세요.

"좀비 문자열"을 피하려면 키를 의도적으로 사용 중단(deprecate)하세요: 대체 키와 함께 사용 중단 날짜를 표시하고 한 릴리스 주기 동안 유지한 뒤 참조가 0개인 것을 확인하고 제거하세요.

번역 노트는 키 가까이에 두세요. JSON 포맷이 주석을 허용하지 않으면 작은 보조 문서나 인접 메타데이터 파일에 노트를 저장하세요(예: "checkout success 화면에서 사용"). 여러 사람이 카피와 UI를 건드는 환경(예: AppMaster로 생성된 Vue 3 웹 앱)에서 특히 유용합니다.

예: 60개의 새 문자열이 포함된 기능 배포

한 스프린트에 팀이 동시에 세 가지를 배포합니다: 새 설정 페이지, 청구(Billing) 화면, 그리고 영수증/결제 실패/체험 종료 이메일 템플릿 세 개. 대략 60개의 새 문자열이고 여기서 보통 i18n 문제가 시작됩니다.

팀은 기능별로, 그다음 표면별로 키를 그룹화하기로 합의합니다. 각 기능에 새 파일을 만들고 어디서나 같은 패턴(feature.area.element)을 따릅니다.

// settings
"settings.profile.title": "Profile",
"settings.security.mfa.enable": "Enable two-factor authentication",

// billing
"billing.plan.current": "Current plan",
"billing.invoice.count": "{count} invoice | {count} invoices",

// email
"email.receipt.subject": "Your receipt",
"email.payment_failed.cta": "Update payment method"

번역 작업을 시작하기 전에 복수형 문자열은 실제 값으로 테스트합니다. billing.invoice.count의 경우 QA가 0, 1, 2, 5를 시드된 데이터나 간단한 개발 토글로 확인합니다. "0 invoice" 같은 어색한 경우를 조기에 잡습니다.

QA는 또한 누락된 키를 드러내기 쉬운 집중적인 흐름을 실행합니다: 설정과 Billing을 열어 탭을 한 번씩 클릭하고, 이메일 템플릿을 스테이징에서 테스트 계정으로 트리거하고, 비기본 로케일로 앱을 실행하며 로그에서 누락 번역 경고가 나타나면 빌드를 실패시키는 식입니다.

이 스프린트에서 QA는 Billing 화면의 한 레이블과 이메일 제목의 한 항목이 누락된 것을 발견했고 팀은 출시 전에 이를 고쳤습니다.

릴리스를 차단할지 폴백을 허용할지 결정할 때는 간단한 규칙을 사용합니다: 사용자 대상 화면과 트랜잭션 이메일은 릴리스를 차단한다; 위험이 낮은 관리자 전용 텍스트는 일시적으로 기본 언어로 폴백할 수 있으나 티켓과 명확한 데드라인이 있어야 합니다.

다음 단계와 간단한 릴리스 체크리스트

Vue 3 i18n 워크플로우는 번역을 코드처럼 다룰 때 안정적입니다: 매번 같은 방식으로 추가하고, 테스트하고, 점수를 매기세요.

릴리스 체크리스트(병합 5분 전)

• 키: 네이밍 패턴을 따르고 스코프가 명확한지(페이지, 기능, 컴포넌트) 확인하세요.
• 복수형: 최소 한 언어에서 여러 복수 규칙을 가진 케이스로 올바르게 렌더되는지 확인하세요.
• 플레이스홀더: 변수들이 모든 곳에서 존재하고 이름이 동일하며 실제 데이터로 확인했을 때 자연스러운지 검증하세요.
• 폴백: 누락 키 동작이 현재 정책과 일치하는지 확인하세요.
• 화면: 깨지기 쉬운 몇몇 화면(테이블, 토스트, 모달, 빈 상태)을 스팟 체크하세요.

측정할 항목 결정(문제 조기 발견용)

몇 가지 간단한 수치를 선택해 정기적으로 검토하세요: 테스트 실행에서의 누락 키 비율, 비기본 로케일의 번역되지 않은 문자열 수, 사용되지 않는 키 수(더 이상 어디에도 나타나지 않는 문자열). 릴리스별로 추적하면 일회성 실패보다 추세를 볼 수 있습니다.

문자열 추가, 번역 업데이트, 결과 확인의 정확한 단계를 적어두세요. 짧게 유지하고 키 이름과 복수형 사용 예시를 포함하세요. 새 기여자가 질문하지 않고 따라 할 수 있게 하세요.

내부 도구를 만든다면 AppMaster (appmaster.io)는 Vue3 웹 앱과 동반 모바일 앱 전반에서 UI 카피와 번역 키를 일관되게 관리하는 실용적인 방법일 수 있습니다. 모든 것이 한 곳에서 관리되기 때문입니다.

스프린트마다 작은 i18n 건강 작업을 하나씩 예약하세요: 죽은 키 삭제, 플레이스홀더 불일치 수정, 최근 누락된 항목 리뷰. 작은 정리가 프로덕션에서의 긴급 번역 수색보다 낫습니다.