콘텐츠 요청 위젯이 사용자 언어를 알게 되다

콘텐츠 요청 위젯을 locale-aware 하게 리팩토링했다. 8개 로케일을 지원하면서 ContentRequestWidget.astro와 Base.astro 레이아웃을 연동시킨 작업이다.

다국어 사용자, 언어 장벽 없이 요청하도록

처음엔 콘텐츠 요청 위젯이 고정 언어(아마 기본값)로만 렌더링됐을 거다. 전 세계 사용자가 늘면서 영어, 한국어, 일본어 등 다양한 언어권 사용자들이 모국어로 요청을 남기고 싶어 하는 니즈가 생겼고, 이게 곧 지원 팀의 수요로까지 이어진다. "사용자가 일본어로 요청 남겼는데 폼 레이블이 영어네요" 이런 식의 케이스들.

이런 상황에서 팀과 얘기해보면 대부분 두 가지 선택이 있다:
1. 점 수정 — 각 언어 사용자마다 별도 요청 폼 페이지 만들기 (유지보수 재앙)
2. 구조적 개선 — 위젯 자체를 로케일 인식형으로 만들기 (한 번의 투자, 장기 득)

여기선 2번을 택했다. 8개 로케일 지원이라는 규모도 충분히 커서 그 가치가 명확했다.

기술: 레이아웃에서 로케일을 전달받다

Astro 컴포넌트 구조에서 이건 꽤 흔한 패턴이다:

Base.astro (루트 레이아웃)
  ├─ 로케일 감지 (URL 경로 / HTTP 헤더 / 브라우저 설정)
  └─ props로 locale 전달
       │
       └─ ContentRequestWidget.astro
            └─ locale에 맞춘 텍스트 렌더링

Base.astro 에서 현재 로케일을 파악하고 그걸 자식 컴포넌트인 ContentRequestWidget.astro 로 넘겨주는 식이다. 그럼 위젯이:
- 로케일별 메시지 데이터 (보통 i18n 객체나 JSON 파일) 로드
- 폼 레이블, 플레이스홀더, 버튼 텍스트를 현 로케일로 렌더링
- 요청 전송 시 로케일 정보도 함께 기록 (백엔드가 어느 언어로 요청 온지 추적 가능)

일단 한 컴포넌트에서 처리하니까 수정도 한 곳만 하면 되고, 레이아웃은 다른 자식들에게도 로케일을 뿌려줄 수 있으니 확장성도 좋다.

8개 로케일, 관리는 어떻게

이 규모면 고민해야 할 게 몇 가지다:

8개는 손으로 일일이 관리 가능하지만, 점점 늘어날 땐 자동화를 생각해야 한다. 번역 서비스(Crowdin, Lokalise) 연동이라든지, CI 에서 누락된 키를 검출하는 식으로.

왜 이 타이밍에, 팀장 관점에서

이 변경이 작지만 중요한 건 사용자 접근성과 운영 비용 두 축을 동시에 개선한다는 거다.

• 사용자 경험: 영어권 아닌 사용자들이 모국어로 문의를 남길 수 있으니 작성 심리 장벽이 낮아진다. 대충 요청하는 게 줄고 구체적인 피드백이 늘 가능성이 높다.
• 지원팀 효율: 다국어 요청을 각각 따로 폼으로 처리할 필요 없이, 한 시스템에서 모두 수집. 로케일 정보가 담기니까 답변할 때도 사용자 언어 맥락을 쉽게 파악 가능.

물론 번역 품질, 로케일 누락 케이스, 새 언어 추가 요청 같은 운영 포인트는 남는다. 하지만 구조를 한 번 잘 다져놓으면, 다음 언어 추가는 이제 텍스트만 하나 더 들이면 된다. 기술 빚이 안 쌓인다.

이런 작은 리팩토링들이 모여서 나중에 "아, 우리 시스템 국제화 지원 잘 되어 있네" 하는 평판이 생긴다. 개별 커밋 하나하나의 가치는 작아 보여도, 누적하면 대단한 변화다.

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

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

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