[바라봄 개발log] 바라봄 현지화 적용 후기

잡담

바라봄에 다국어 지원을 적용했다.

처음에는 단순히 한국어 문구를 영어와 일본어로 번역하면 되는 작업이라고 생각했는데, 생각보다 고민할 지점이 많았다.

바라봄이라는 이름을 그대로 가져가도 되는지, 건강수첩이라는 표현은 다른 나라에서도 자연스러운지, 반려동물 기록 앱을 설명할 때 어느 정도까지 건강을 말해도 되는지 같은 문제들이 계속 나왔다.

결국 이번 작업은 단순한 번역이 아니라, 바라봄을 다른 언어권 사용자에게 어떻게 소개할 것인지 정리하는 작업에 가까웠다.

번역보다 먼저 필요했던 브랜딩 정리

바라봄은 한국어로 보면 꽤 마음에 드는 이름이다.

바라보다, 돌봄, 봄 같은 이미지가 자연스럽게 이어지고, 반려동물을 지켜보고 챙기는 서비스의 느낌도 어느 정도 담긴다.

하지만 이 감각이 다른 언어에서도 그대로 전달되지는 않는다.

영어권 사용자에게 Barabom은 그냥 고유명사에 가깝고, 일본 사용자에게 バラボム은 바라봄이 가진 부드러운 느낌보다 낯선 소리로 먼저 다가갈 수 있다고 판단했다.

그래서 현지화를 시작하기 전에 먼저 바라봄의 핵심을 문장으로 정리했다.

바라봄은 반려동물의 하루를 쉽고 세심하게 기록하고, 필요할 때 다시 보기 좋게 모아주는 똑똑한 반려동물 건강수첩이다.

이 문장을 기준으로 스토어 문구, 앱 이름, 기능 설명의 방향을 맞췄다.

기준은 기록, 정리, 다시 보기, 공유 키워드에 집중했다.

일본에서는 이름을 바꿨다

가장 큰 결정은 일본 앱 이름이었다.

한국과 미국에서는 바라봄 브랜드명을 유지했다.

• 한국: 바라봄 - 똑똑한 반려동물 건강수첩
• 미국: Barabom - Smart Pet Health Notebook

하지만 일본에서는 ほほみる - スマートなペット健康手帳으로 이름을 바꿨다.

처음에는 브랜드 통일성을 생각해서 일본에서도 Barabom 또는 バラボム을 쓰는 편이 좋지 않을까 고민했다.

그런데 이름만 놓고 보면 일본 사용자에게 바라봄의 의미가 거의 전달되지 않는다.

또 バラボム은 소리만 봤을 때 부드러운 돌봄 서비스보다는 조금 딱딱하거나 낯선 느낌이 있었다.

그래서 일본에서는 의미를 다시 만드는 쪽을 선택했다.

ほほみる는 호호미루(Hohomiru)로 읽는다.

ほほ는 뺨, 온화한 미소, ほほえみ를 떠올리게 하고, みる는 보다, 살피다, 상태를 확인한다는 뜻을 가진다.

두 단어를 합치면 가족이 반려동물을 따뜻하게 지켜보고 살피는 기록 앱이라는 느낌을 줄 수 있다고 판단했다.

물론 이 결정이 정답인지는 아직 모른다.

브랜드 이름을 국가마다 다르게 가져가는 것은 관리 비용이 생긴다.

검색 키워드도 나뉘고, 소개 문구도 따로 관리해야 하고, 장기적으로 브랜드 자산이 분산될 수도 있다.

하지만 지금 바라봄의 단계에서는 글로벌 브랜드 인지도보다 첫인상이 더 중요하다고 봤다.

처음 보는 사용자에게 “이 앱이 무엇을 하는 앱인지”, “나에게 낯설지 않은 앱인지”가 먼저 전달되어야 한다.

그래서 일본 시장에서는 Barabom을 억지로 설명하기보다, ほほみる라는 이름으로 다시 시작하는 쪽을 선택했다.

i18n 적용

기술적으로는 i18next, react-i18next, expo-localization 조합을 사용했다.

지원 언어는 우선 한국어, 영어, 일본어 세 가지로 잡았다.

문자열 key 대신 함수형 t를 쓴 이유

이번 i18n 작업에서 가장 마음에 들었던 부분은 t를 문자열 key 방식이 아니라 함수형 selector 방식으로 사용한 것이다.

일반적으로는 이런 식으로 많이 쓴다.

t('feedList.searchLabel')

하지만 바라봄에서는 이런 식으로 사용했다.

t($ => $.feedList.searchLabel)

일반 문자열 방식은 타입 체크가 불가능했다.

feedList.searchLable처럼 오타가 나도 그냥 문자열이라서 놓치기 쉽고, 리소스 구조를 바꿀 때 어디가 깨지는지 찾기도 어렵다.

하지만 selector 방식은 TypeScript 자동완성이 된다.

존재하지 않는 key를 쓰면 타입 단계에서 잡을 수 있고, 리소스 구조를 따라가며 문구를 찾기도 쉽다.

AI가 번역 파일을 만들거나 컴포넌트 문구를 바꿀 때도 타입이 가드 역할을 해준다.

문자열 key는 겉으로 보기엔 간단하지만, 규모가 커질수록 사람이 기억해야 하는 규칙이 많아진다.

함수형 t는 조금 장황해 보이지만, IDE와 타입 시스템이 같이 봐주기 때문에 장기적으로는 더 안전하다고 느꼈다.

그래서 i18next 설정에도 enableSelector와 strictKeyChecks를 켰다.

interface CustomTypeOptions {
  enableSelector: true;
  strictKeyChecks: true;
}

덕분에 문구 작업을 하면서 “이 key가 진짜 있나?”를 계속 눈으로 확인하는 시간이 줄었다.

현지화하면서 느낀 것

이번 작업을 하면서 현지화는 번역이 아니라 제품을 다시 설명하는 일에 가깝다는 생각이 들었다.

한국어에서 자연스러운 표현이 영어와 일본어에서도 자연스러운 것은 아니었다.

특히 바라봄처럼 감정과 돌봄의 뉘앙스가 중요한 서비스는 더 그랬다.

공동육아라는 말도 한국어에서는 꽤 직관적이지만, 그대로 옮기면 어색해질 수 있다.

그래서 영어에서는 shared records, care routine처럼 기록과 루틴에 집중했고, 일본어에서는 家族で共有, 一緒に見守る, すこやかな毎日처럼 부드럽고 일상적인 표현을 중심으로 잡았다.

기능은 같아도 사용자가 받아들이는 첫인상은 언어마다 달랐다.

결국 현지화는 “같은 말을 다른 언어로 바꾸는 것”이 아니라 “같은 가치를 다른 문화권에서 이해되는 방식으로 다시 말하는 것”에 가까웠다.

마무리

아직 바라봄의 다국어 지원은 시작 단계다.

문구도 더 다듬어야 하고, 실제 일본어/영어 사용자 피드백도 받아봐야 한다.

스토어 키워드, 스크린샷, 온보딩 문구까지 생각하면 해야 할 일도 많다.

그래도 이번 작업을 통해 바라봄이 어떤 앱인지 다시 정리할 수 있었다.

단순히 기능이 많은 앱이 아니라, 반려동물의 하루를 꾸준히 남기고 가족과 함께 다시 볼 수 있게 돕는 앱.

이 기준을 잡고 나니 한국어 문구도 오히려 더 선명해졌다.

현지화 작업을 시작했는데, 결국 바라봄의 정체성을 다시 정리한 셈이다.

이제 진짜 해외 사용자도 써줄지는... 😅