랜딩페이지 다국어 전면 확장: 기능 추가가 아니라 유통 결정
다국어가 왜 안 되냐는 질문에서 출발해, 고장이 아니라 미구현임을 먼저 가려내고 6개 언어 전 페이지 확장까지 간 하루.
다국어 지원이 왜 안 되냐는 질문 하나로 하루가 시작됐다. 답을 내기 전에 먼저 가려야 할 게 있었다. 이건 고장인가 아니면 원래 안 만든 것인가. 그 구분이 오늘 작업 전체의 방향을 갈랐다.
세 줄 요약. 랜딩페이지 wildeconforce.com을 한국어 포함 6개 언어로 전 페이지 확장했다. 이게 중요한 이유는 다국어가 단순 번역 기능이 아니라 누구에게 닿을지를 정하는 유통 결정이기 때문이다. 빌더에게 주는 의미는 하나다. 화면에 새 버튼을 붙이기 전에 "이게 고장인가 미구현인가"부터 판별하면 엉뚱한 곳을 고치는 시간을 아낄 수 있다.
고장이 아니라 미구현이었다
첫 판단은 증상을 고장으로 성급하게 규정하지 않는 것이었다. "다국어가 왜 안 되냐"는 말은 보통 "되던 게 깨졌다"로 들린다. 그런데 실제로 눌러보니 언어 전환 장치 자체가 없었고, 다른 언어 주소로 들어가면 404가 떴다. 번역 파일도 없었다. 즉 어딘가 부서진 게 아니라 처음부터 만든 적이 없는 기능이었다.
이 구분이 왜 중요하냐면, 고장은 원인을 찾아 되돌리는 일이고 미구현은 설계부터 새로 하는 일이기 때문이다. 둘을 헷갈리면 있지도 않은 버그를 몇 시간씩 뒤지게 된다. 오늘은 진단을 먼저 끝냈기 때문에 곧장 "무엇을 새로 지을까"로 넘어갈 수 있었다.
언어를 기억할 것인가
두 번째 갈림길은 사용자 경험 쪽이었다. 방문자가 영어를 골랐을 때 그 선택을 기억할 것인가, 아니면 매번 접속할 때마다 브라우저 언어를 다시 감지할 것인가.
- 기억하는 쪽은 한 번 고르면 다음 방문에도 그 언어로 열린다.
- 매번 감지하는 쪽은 구현이 단순하지만 사용자가 원치 않는 언어로 계속 튕겨 나갈 위험이 있다.
기억하는 쪽을 택했다. 해외 방문자가 자기 언어로 편하게 머무르는 게 랜딩페이지의 목적에 더 맞다고 봤다. 자동 감지는 끄고 기본은 한국어로 두되, 선택은 사용자에게 넘겼다.
크롬과 본문을 나눈 사전 구조
세 번째는 구조 설계였다. 여기서 핵심 판단은 "화면 껍데기"와 "글 본문"을 분리한 것이다.
메뉴, 모바일 메뉴, 푸터처럼 모든 페이지에 공통으로 나오는 부분은 크롬 사전 하나로 묶어 6개 언어를 한 곳에서 관리했다. 반면 소개, 교육, 프로젝트, 도구 같은 페이지별 내용은 페이지마다 별도 사전을 뒀다. 이렇게 나누면 공통 문구를 고칠 때 아홉 군데를 따로 손대지 않아도 된다.
- 대상 언어는 영어, 일본어, 중국어 간체, 스페인어, 아랍어, 한국어 6개.
- 아랍어는 글자가 오른쪽에서 왼쪽으로 흐르기 때문에 화살표와 배지, 들여쓰기까지 방향을 뒤집어 대응했다.
- 브랜드명, 제품명, 날짜, 상태 표시 같은 고유 토큰은 일부러 번역하지 않고 원문을 유지했다. 이런 건 옮기면 오히려 뜻이 흐려진다.
작업은 서브에이전트 여러 대를 병렬로 돌려 페이지별 사전을 동시에 채운 뒤, 통합 검증에서 전 언어가 실제로 미리 렌더링되는지 빌드 산출물로 직접 확인했다. 영어 주소는 영어로, 아랍어 주소는 아랍어로 나오는지를 눈으로 보고 나서야 넘어갔다.
오늘 배운 것
관통하는 판단은 이거였다. 다국어는 기능 목록에 한 줄 추가하는 일이 아니라 "누구에게 닿을 것인가"를 정하는 유통 결정이다.
한국에서 만든 도구라도 해외에서 처음 보는 사람에게 자기 언어로 첫인상을 주지 못하면 곧바로 이탈한다. 영어 화면을 갖추는 건 번역 작업이 아니라 도달 범위를 넓히는 전략의 일부였다. 만드는 근육과 닿게 하는 근육은 다르고, 오늘 작업은 후자에 가까웠다. 화면에 무언가를 붙이기 전에 그게 고장 수리인지 미구현 신축인지부터 갈라놓으면, 고칠 곳과 새로 지을 곳을 혼동하지 않는다.