정책 페이지 4종이 이제 다국어를 지원합니다

네 개의 정책 페이지에 다국어 라우팅을 추가했다. 쿠키 정책, 연락처, 정정 요청, 소스 정책이 사용자의 언어 설정에 맞게 로드되도록 한 것인데, 생각보다 반성할 점이 많은 작업이었다.

우리가 놓친 부분

처음엔 서비스의 핵심 페이지들부터 다국어 지원을 시작했다. 랜딩, 대시보드, 주요 기능 영역 같은 곳들이 먼저 [lang] 동적 세그먼트를 갖게 됐다. 그런데 며칠이 지나면서 점점 많은 페이지들이 "아, 우리 이거 아직 영어만 지원하네?" 하는 식으로 발견되기 시작했다. 정책 페이지들이 그중 하나였다.

특히 쿠키 정책(cookies), 개인정보 관련 정정 요청(correction-request), 소스 정책(source-policy)처럼 법적 성격이 강한 페이지일수록 다국어 대응의 우선순위가 높아야 한다. 사용자가 자신의 모국어로 법적 문서를 읽을 권리가 있기 때문이다. 연락처(contact) 페이지도 한국어 사용자가 한국어로 문의를 보내고 싶은데 정책 링크가 영어로만 있으면 어색한 경험이 된다.

커밋 메시지에 "fix"라고 표기한 이유가 여기 있다. 엄밀히 말하면 "새 기능 추가"이지만, 사실은 설계 단계에서 완벽하게 다국어를 구성하지 못한 부분을 사후에 채우는 것이기에 "수정(fix)"으로 봤다.

구조와 패턴

Astro의 파일 기반 라우팅에서 [lang] 동적 세그먼트를 활용하는 패턴은 이미 프로젝트에 정립돼 있었다. /[lang]/about, /[lang]/features 같은 페이지들이 이미 작동하고 있었으니, 이번 작업은 그 패턴을 정책 페이지 4종에 일관되게 적용하는 것이었다.

각 페이지가 src/pages/[lang]/ 폴더 아래 배치되면서, 사용자가 언어 설정을 바꾸거나 특정 언어 경로로 접근할 때 올바른 버전을 제공받을 수 있게 됐다.

배운 점과 앞으로의 과제

이런 식의 누락 발견은 프로젝트가 성장할 때마다 반복된다. 처음엔 "이 정도면 충분하겠지"로 시작한 기능이 나중에 "왜 이것도 안 되는데?"로 변한다.

팀 입장에서는 두 가지 교훈이 있다:

1. 초기 설계 체크리스트: 새로운 페이지를 추가할 때 "다국어 지원 필요한가?"를 명시적으로 물어봐야 한다. 정책 페이지는 처음부터 다국어 체크리스트에 들어가야 한다.

2. 문서화와 자동화: [lang] 라우팅 패턴이 매뉴얼 작업이라면, 시간이 지날수록 일관성이 깨질 수 있다. 새로운 페이지가 추가될 때마다 개발자가 "아, [lang] 폴더를 써야 한다"고 기억해야 한다는 뜻이다.

이번 작업 자체는 간단한 라우트 추가였지만, 이렇게 쌓이는 작은 누락들을 어떻게 시스템적으로 방지할 것인가 하는 고민은 계속된다. 다음 번엔 온보딩 문서에 명확한 체크리스트를 추가하고, 가능하면 스캐폴딩 도구나 린트 규칙으로 자동 감지할 수 있도록 할 생각이다.

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

• 모니터 쿠팡에서 보기 →
• 기계식키보드 쿠팡에서 보기 →
• 사무의자 쿠팡에서 보기 →

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