정책 페이지를 7개국어로 지원하며 글로벌 진출 준비하기

정책 페이지 8종을 일괄로 국제화했다. About, Copyright, Privacy, Terms, Cookies, Contact, Source Policy, Correction Request 페이지를 7개국어로 동시에 제공하는 구조를 만들었다.

왜 정책 페이지인가

정책 페이지는 단순한 정보 공시가 아니다. 특히 글로벌 서비스일수록 각 지역의 규제를 준수하고 사용자의 신뢰를 얻는 법적·제도적 기초다. GDPR, 개인정보보호법 등 지역별 규정이 다르고, 영어나 기본 언어로만 제공하면 현지 사용자는 번역 앱에 의존해야 한다. 정책 문서가 오역되면 법적 책임까지 미칠 수 있으니까 더더욱 중요하다.

내 팀이 이 작업을 우선순위에 올린 이유는 "다음 분기 글로벌 마케팅" 때문이었다. 새로운 지역으로 수출할 때 현지 언어로 된 정책 페이지가 있으면 없으면의 신뢰도가 다르다. 법무팀과도 조율해서 각 정책의 정확성을 보장해야 했고, 이 과정에서 단순히 개발자가 번역 데이터를 넣는 수준이 아니라 컨텐츠 구조 자체를 다국어 관점으로 재설계해야 했다.

기술적 설계: Astro + i18n 조합

파일 구조는 깔끔하게 두 부분으로 나눴다.

이 구조가 중요한 이유는 "콘텐츠와 프레젠테이션의 분리"다. 정책 문구 자체는 policy.ts 에 순수 데이터로 관리하고, PolicyPage.astro 는 언어 파라미터에 따라 올바른 텍스트를 꺼내 렌더링하는 식으로 설계했다. 덕분에 나중에 새로운 언어가 추가돼도 컴포넌트 자체는 건드릴 필요 없다.

// 개념: src/i18n/policy.ts 구조
export const policiesContent = {
  privacy: {
    en: "Privacy Policy content...",
    ko: "개인정보 보호정책 내용...",
    ja: "プライバシーポリシー内容...",
    // ... 7개국어
  },
  terms: {
    en: "Terms of Service...",
    ko: "서비스 이용약관...",
    // ...
  },
  // about, copyright, cookies, contact, source-policy, correction-request ...
}

이런 식으로 정책별로 계층화하면 각 정책의 번역 완성도를 추적하기도 쉽다. "Terms는 6개국어인데 Cookies는 7개국어" 같은 불완전한 상태도 한눈에 보인다.

다국어 페이지에서 잘 빠지는 함정들

1. 길이 변동성
한국어는 짧지만 독일어나 영어는 길어진다. 특히 레이아웃이 고정 너비 박스라면 overflow 가 생긴다. 이번 작업에서도 "Correction Request" 같은 긴 영문을 현지화하면서 일부 언어는 3줄, 다른 언어는 1줄이 되는 경험을 했다. 초반에는 CSS min-height 대신 content-based height 를 썼다가 나중에 여유 있는 높이로 재조정했다.

2. 문자 인코딩과 특수 문자
각 언어마다 고유의 특수 문자나 이모지가 들어갈 수 있다. 아랍어는 우측 정렬, 중국어 간체/번체는 폰트 서포트가 다르다. Astro 정적 빌드에서 UTF-8 인코딩이 제대로 되지 않으면 빌드 단계에서 잡아야 한다.

3. 법적 정확성
IT 정책은 국가별로 다르다. 개인정보보호법(PIPA) vs GDPR 은 보호 수준 자체가 다르다. 번역만으로는 부족하고, 각 지역 법무팀(또는 외부 법무)과 검수가 필요했다. 개발자 입장에서는 "이건 번역이 아니라 지역화(localization)"라는 점을 인식해야 한다.

팀과의 협업 관점

이 작업은 개발자 혼자 끝내지 못한다. 우리 팀에서는:

• 마케팅팀: 어떤 지역으로 확대할 것인가 → 7개국어 언어 선택
• 법무팀: 각 정책의 로컬 규제 준수 검토
• 디자인팀: 번역된 콘텐츠가 UI 에 잘 맞는지 확인
• 개발팀: i18n 구조 설계 및 구현, 자동화 테스트 (모든 언어에서 렌더링 체크)

특히 법무팀 검수를 기다리는 시간이 길었다. 처음에는 마케팅이 준비한 번역본으로 PR을 올렸는데 법무에서 "이 표현은 한국 법령에 맞지 않음", "이건 약간 더 강한 표현이 필요" 같은 피드백이 나왔다. 그 결과 정책 페이지 하나가 여러 번 되돌려졌고, 개발 입장에서는 "번역은 번역인데 법적 검수는 별개"라는 걸 배웠다.

앞으로의 확장성

이 구조는 향후 확장에 유리하다. 만약 새 정책이 추가되거나 기존 정책이 업데이트되면 policy.ts 에 새 키와 7개국어 콘텐츠를 추가하기만 하면 된다. PolicyPage.astro 는 일반화된 로직만 가지고 있어서 건드릴 게 없다.

다만 관리해야 할 부분이 있다. 8종 × 7개국어 = 56개 문자열을 관리하는 것이 점점 복잡해질 수 있다. 그래서 나중에는:
- 번역 관리 도구(예: Crowdin, Lokalise) 도입을 고려 중
- 자동화된 번역 품질 체크 (누락된 번역 감지)
- 정책 업데이트 시 어느 언어들이 아직 갱신되지 않았는지 추적

이번 작업으로 "단순 i18n은 코드 수준에서 끝나는 게 아니라, 운영과 관리까지 포함된 프로세스"라는 걸 실감했다.

🛒 이 글과 어울리는 추천 상품

• 모니터 쿠팡에서 보기 →
• 기계식키보드 쿠팡에서 보기 →
• 외장SSD 쿠팡에서 보기 →

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.