다국어 뉴스 자동 번역 인프라 완성

이번에 뉴스 서비스의 다국어 지원을 위해 110건의 뉴스를 7개 언어로 번역하고, 그 데이터를 범용 i18n 헬퍼/컴포넌트와 연결했다. 이 작업은 단순한 "데이터 채우기"가 아니라, 글로벌 확장을 대비한 인프라 정비의 첫 단계였다.

왜 다국어 뉴스가 필요했는가

서비스가 다른 국가로 확장되면서 사용자들이 자신의 언어로 뉴스를 읽고 싶어 하기 시작했다. 특히 뉴스는 단순 UI 문구가 아니라 콘텐츠의 본질이다. 사용자가 한국어 뉴스만 본다면 서비스의 글로벌 가치가 반감된다.

하지만 실시간으로 모든 뉴스를 다국어로 번역하기는 비용이 많이 든다. 그래서 전략을 세웠다:
- 핵심 뉴스 110건을 엄선해서 인간 검수와 함께 정확하게 번역
- 그 데이터를 일관된 구조로 저장
- 범용 i18n 시스템을 통해 렌더링

이렇게 하면 나중에 뉴스가 늘어나도, 상품 설명이나 공지사항 같은 다른 콘텐츠에도 같은 i18n 구조를 재사용할 수 있다.

배치 파일로 데이터를 나눈 이유

6개의 JSON 파일(news_batch_01.json ~ news_batch_06.json)로 나눈 것은 단순한 편의가 아니다. 한 파일에 110건을 모두 넣으면:

이렇게 나누면 팀원들이 각자 다른 배치를 건드릴 때 Git 충돌이 줄어들고, 번역 검수도 한 번에 30~20건 정도씩 집중해서 할 수 있다.

범용 i18n 헬퍼/컴포넌트의 의미

이 커밋에서 단순히 JSON 데이터만 추가한 게 아니라, 헬퍼와 컴포넌트를 연결했다는 게 핵심이다. 예를 들어:

// i18n 헬퍼 예시
export const getLocalizedNews = (newsId, locale = 'ko') => {
  return newsData[locale]?.[newsId] || fallbackToEnglish(newsId);
};

// React 컴포넌트 예시
function NewsCard({ newsId, locale }) {
  const news = getLocalizedNews(newsId, locale);
  return (
    <article>
      <h2>{news.title}</h2>
      <p>{news.description}</p>
    </article>
  );
}

이렇게 추상화하면:
- 뷰 로직이 i18n 구조에 의존하지 않음 — 뉴스 데이터가 어디서 오든 같은 인터페이스 사용
- 언어 추가가 쉬움 — 새로운 배치 파일만 추가하고 헬퍼에 등록
- 테스트 가능 — 헬퍼를 단독으로 검증

이 작업에서 배운 것들

1. 대량 데이터 관리는 구조부터

초반에 "110건 정도 하나 JSON으로 해도 되지 않나?" 하고 생각했다. 하지만 실제로 작업해보니:
- 컨플루언스에서 번역 지시를 나눠서 쓸 때도 배치 기준으로
- QA 팀이 검수할 때도 배치별로 태그 붙여서 관리
- 배포 전 데이터 무결성 체크할 때도 배치별 체크섬 검증

작은 구조 결정이 전체 워크플로우를 얼마나 좌우하는지 실감했다.

2. i18n은 초기 설계가 80%

이번에 헬퍼와 컴포넌트를 잘 만들어두니, 다음번에 상품명 다국어화가 필요했을 때 거의 그대로 재사용했다. 초기에 "뉴스 전용으로 만들어도 되지"라고 생각했다면, 나중에 3배의 비용이 들었을 것이다.

i18n 설계는 "지금 필요한 것만 하기"와 "다음 것을 준비하기" 사이의 균형이 중요하다.

3. 검수와 QA의 범위가 확 늘어난다

번역 데이터가 추가되면서 "정말 정확한가?" "특수문자는 제대로 인코딩되었나?" "각 언어별 UI 길이 맞는가?" 같은 체크포인트가 생겼다. 단순 코드 리뷰가 아니라 언어별 실제 렌더링까지 확인해야 한다. 이 점을 팀에 미리 알렸어야 검수 일정을 더 잘 잡을 수 있었다.

4. 비슷한 도메인이 많다

뉴스 다음으로 FAQ, 공지사항, 도움말 같은 콘텐츠들도 다국어 지원이 필요해졌다. 이번 i18n 인프라가 없었다면 각각 다르게 만들었을 텐데, 이제는 배치 파일만 추가하고 같은 헬퍼를 쓰면 된다. 초기 투자가 후속 작업의 속도를 크게 높였다.

이 작업을 통해 "글로벌 서비스의 다국어 지원"이 얼마나 깊이 있는 문제인지 알게 됐다. 단순히 번역문을 붙이는 게 아니라, 데이터 구조, 캐싱, 검수 프로세스, 컴포넌트 설계까지 모두 함께 고려해야 한다. 그리고 초기에 잘 설계한 구조가 나중에 얼마나 큰 자산이 되는지도.

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

• 외장SSD 쿠팡에서 보기 →
• 모니터 쿠팡에서 보기 →
• 사무의자 쿠팡에서 보기 →

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