다언어 라우팅으로 SEO와 광고 수익 동시 최적화

8개 언어 지원, [lang] 라우트, hreflang, AdSense 연동까지 한 번에 처리한 i18n 대작업을 마무리했다. 단순히 번역 텍스트 몇 개 추가하는 수준이 아니라, 검색 엔진 최적화부터 광고 수익까지 고려한 풀스택 국제화 구현이었다.

왜 지금, 왜 8개 언어인가

우리 서비스가 특정 지역/커뮤니티 중심에서 벗어나 글로벌하게 확장되려면 단순한 번역만으로는 부족하다는 판단이 있었다. 다만 모든 언어를 동시에 지원하는 건 비현실적이니까, 대사용자 기반과 광고 수익성을 함께 고려해서 8개 언어로 우선순위를 정했다.

이 결정 자체가 제품 전략과 직결되어 있다. 우리 팀에서는 "어느 언어부터 시작할 것인가"를 단순히 "많이 쓰는 언어" 기준으로만 잡지 않았다. AdSense (pub-1135) 광고 네트워크의 지역별 수익성, 이미 사용 중인 사용자층의 분포, 그리고 향후 성장 가능성까지 맵핑했다. 결과적으로 8개는 "지금 우리가 관리 가능한 최대치"와 "기대 효과"의 균형점이었다.

i18n 구현 전략 — 라우트, SEO, 광고

이번 작업의 핵심은 단순히 UI 텍스트를 바꾸는 것이 아니라, 라우트 구조부터 검색 엔진 신호까지 일관되게 설계하는 것이었다.

[lang] 라우트 패턴을 택한 이유는 여럿이다. Astro는 정적 생성 기반이므로 언어별로 별도 페이지를 빌드하는 게 자연스럽다. 또한 /en/, /ja/ 같은 URL 패턴은:
- SEO 크롤러가 명확하게 언어를 인식
- 캐시 레이어(CDN)에서도 언어별로 분리 가능
- 나중에 지역화 마케팅 할 때 쿼리 로그도 깔끔

hreflang 태그는 흔히 간과되는데, 검색 엔진이 중복 콘텐츠로 의심하는 상황을 명시적으로 해결해준다. 예를 들어:

<!-- /en/agencies 페이지에 -->
<link rel="alternate" hreflang="en" href="https://example.com/en/agencies" />
<link rel="alternate" hreflang="ja" href="https://example.com/ja/agencies" />
<link rel="alternate" hreflang="ko" href="https://example.com/ko/agencies" />
<!-- ... 다른 8개 언어 ... -->

이렇게 하면 Google 검색 결과에서 사용자 언어에 맞는 버전을 자동으로 보여준다. 단순 기술이지만, 효과는 크다. 우리가 전 지역에서 균등한 검색 트래픽을 받으려면 필수다.

AdSense 연동은 수익 최적화 측면의 핵심이다. 각 언어권(지역)마다 광고 수익이 다르니까, 로더에서 언어/지역을 감지한 뒤 알맞은 pub-1135 슬롯을 활성화한다. TalentCard 같은 반복 컴포넌트에서도 광고 노출 빈도를 언어별로 다르게 설정할 여지가 생긴다.

팀 리딩 관점 — 트레이드오프와 우선순위

이 작업을 진행하면서 팀과 함께 고민한 포인트들:

1. 빌드 타임 vs 유지보수성
   8개 언어 × 6개 핵심 페이지 = 48개 정적 페이지 생성. Astro는 병렬 빌드를 잘 지원하지만, 모든 조합을 미리 생성하는 것 자체가 "배포 시간 2-3배 증가"를 의미했다. 대신 번역 데이터가 JSON이나 YAML로 일관되게 관리되므로, 나중에 9번째 언어를 추가할 때 컴포넌트 로직은 안 건드려도 된다.

2. 번역 품질 관리
   자동 번역 vs 인간 번역. 우리는 UI 필수 텍스트는 인간이, 설명/마케팅 텍스트는 자동으로 시작해서, 사용자 피드백에 따라 점진적으로 보완하기로 했다.

3. 지역별 광고 정책
   AdSense는 지역에 따라 광고 정책이 다르다. pub-1135 로더에서 각 지역의 정책을 반영해야 하는데, 예를 들어 A 지역은 특정 카테고리 광고를 제한할 수 있다. 이건 기술 구현이 아니라 비즈니스 룰이므로, 운영팀과의 협업이 필수였다.

코드 리뷰 시 뭘 봤나

변경 파일들(HomeBody, AgenciesBody, ScheduleBody 등)을 검토하면서:

• 컴포넌트가 i18n 의존성을 깔끔하게 받았는가? — Props로 언어 정보가 명시적으로 들어오는지, 전역 Context가 남용되지는 않는지.
• 반복적인 패턴이 있는가? — 각 Body 컴포넌트가 hreflang을 개별로 세팅하지 않았나, 아니면 레이아웃 컴포넌트에서 한 번에 처리하나?
• 테스트 커버리지 — 특정 언어에서만 렌더링 깨지는 버그를 어떻게 잡을 건가?

특히 TalentCard는 반복 컴포넌트라서, 번역 데이터 로딩 실패 시 fallback을 명확히 두는 게 중요했다.

다음 — 점진적 최적화

이번 구현으로 기초는 다졌지만, 더 할 게 남았다:

• 언어별 콘텐츠 제공 (번역이 아닌 현지화된 콘텐츠)
• 각 지역 검색 엔진(Yandex, Baidu 등)별 사이트맵 최적화
• 비동기 광고 로더의 성능 모니터링
• 사용자 피드백 기반 번역 품질 개선

i18n은 한 번에 완성되는 작업이 아니다. 이제 사용자들이 실제로 어떤 언어에서, 어디서, 얼마나 많이 사용하는지 데이터를 수집하고, 그에 맞춰 다시 투자할 지점을 결정해야 한다. 이런 관점에서 이번 작업은 "글로벌 기반 마련"이고, 진짜 최적화는 지금부터다.

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

• 노트북 쿠팡에서 보기 →
• 모니터 쿠팡에서 보기 →
• 도킹스테이션 쿠팡에서 보기 →

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