David.Cheon
UIpac
David.Cheon
  • UIpac (647) N
    • Planning · PM (227)
      • 프로젝트 · PM (58)
      • UX · Product (49)
      • 서비스 기획 (40)
      • Business · Growth (60)
      • 일하는 방법 (20)
    • AI (64) N
      • AI Product (13)
      • AI 활용 · 자동화 (7)
      • AI Technology (11)
      • AI Trend (33) N
    • Projects · Tech (2)
      • Toy Project (1)
      • Web · IT (1)
      • Tools (0)
    • Archive (352) N
      • Weekly Curation (251)
      • Performing Arts (17) N
      • Collection (6)
      • Books (0)
      • Life (78) N

인기 글

Tags

  • 인공지능
  • 디자인
  • 2015
  • UX
  • Mreport
  • Gartner
  • 유니티
  • trend
  • Curation
  • 가트너
  • 디자인참고
  • 세계 게임시장 규모
  • 다음카카오
  • 분석
  • 애플리케이션
  • 동향
  • 2014
  • 모바일
  • 큐레이션
  • 반응형웹
  • 사이트
  • 웨어러블
  • 벤치마킹
  • daumkakao
  • 트랜드
  • UI
  • 사물인터넷
  • 트렌드
  • 기획참고
  • 기획

최근 댓글

방명록

전체 방문자
오늘
어제
hELLO · Designed By 정상우.
David.Cheon

UIpac

Planning · PM/서비스 기획

글로벌 서비스 기획 시 고려사항

2020. 6. 13. 13:34

 

국내에서 잘 돌아가는 서비스를 해외에도 내보내자는 이야기는 기획 회의에서 한 번쯤 나옵니다.
처음에는 "언어만 바꾸면 되는 거 아닐까" 하고 생각하기 쉬워요.
그런데 막상 체크리스트를 만들어 보면 번역은 전체의 일부일 뿐이더라고요.
오늘은 글로벌 서비스를 기획할 때 제가 확인하는 항목을 주제별로 정리해 봤습니다.
현업에서 겪으며 계속 고쳐 가는 내용이라, 지금 시점의 정리라고 봐 주세요.

 

번역은 문장을 다른 언어로 옮기는 일이고, 현지화는 그 나라 사용자가 자연스럽게 쓰도록 서비스를 맞추는 일입니다.
화면에 보이는 글자보다 입력 방식에서 먼저 문제가 터지는 경우가 많았어요.

예를 들어 가입 화면에 "성명" 입력 칸이 하나만 있다고 가정해 볼게요.
이름과 성을 나눠 쓰는 나라에서는 어느 쪽을 먼저 적어야 할지 헷갈립니다.
주소 입력도 마찬가지입니다.
국내 우편번호 검색에만 맞춰 둔 입력 폼은 다른 나라 주소 체계에는 아예 들어맞지 않을 수 있습니다.
전화번호 형식, 날짜 표기, 통화 기호, 단위도 같은 계열의 문제입니다.

문장 길이도 변수입니다.
같은 의미라도 언어에 따라 글자 수가 크게 달라져서, 한국어에 맞춰 만든 버튼이 다른 언어에서는 깨질 수 있어요.
오른쪽에서 왼쪽으로 읽는 언어를 지원한다면 화면 배치 자체를 뒤집어야 합니다.
그래서 문구를 코드에 박아 넣지 않고 따로 관리하는 구조를 처음부터 기획서에 적어 두는 편이 좋습니다.

개발 쪽에서는 문구 분리 말고도 현지 시간대 처리와 문자 인코딩 같은 기본 사항을 점검해야 합니다.
이런 항목은 기획서 한쪽에 "다국어 대응 체크"로 모아 두면 빠뜨리지 않아요.

 

결제 수단은 나라마다 선호가 꽤 다르다고 알려져 있습니다.
카드가 중심인 곳도 있고, 계좌이체나 간편결제, 현금 결제를 선호하는 곳도 있습니다.
국내에서 쓰던 결제 흐름을 그대로 가져가면 결제 단계에서 이탈이 생길 수 있어요.

가정해 보면 이런 상황입니다.
국내에서는 간편결제 한 번이면 끝나는 구조인데, 새로 나가는 나라에서는 그 수단을 쓰는 사람이 거의 없다고 해 보죠.
이때는 결제 대행사를 여러 곳 붙일지, 처음에는 카드 하나로 시작할지를 정해야 합니다.
통화 표시와 환율 적용 시점, 정산 주기, 영수증 형식까지 같이 정리해야 하고요.
이런 부분은 실제 도입 전에 결제 대행사나 해당 지역 담당자에게 확인해야 합니다.

 

제가 가장 조심하는 영역입니다.
개인정보 보호 규정, 아동 이용 연령 기준, 소비자 환불 규정, 세금 표기, 광고 표현 제한은 지역마다 다릅니다.
다만 저는 법률 전문가가 아니어서 여기서 무엇이 맞다고 단정할 수는 없어요.

기획자가 할 수 있는 일은 질문 목록을 만드는 것이라고 생각합니다.
사용자 데이터를 어느 나라 서버에 저장할 수 있는지, 동의를 받는 방식이 다른지, 환불 기간에 의무 조건이 있는지 같은 질문입니다.
이 목록을 들고 법무 담당자나 현지 전문가에게 가서 "확인 필요"로 표시된 항목을 하나씩 지워 가는 방식이 안전했습니다.
약관과 개인정보 처리방침도 번역본이 최신 상태인지 계속 확인해야 합니다.

 

색과 아이콘의 의미는 문화마다 다르게 읽힐 수 있습니다.
어떤 곳에서는 긍정의 표시가 다른 곳에서는 부정적인 느낌을 줄 수도 있어요.
손 모양 아이콘이나 동물 이미지처럼 별생각 없이 쓴 요소가 문제가 되는 경우도 있다고 들었습니다.

호칭과 말투도 중요합니다.
친구처럼 말을 거는 서비스 톤이 한국에서는 호감이지만, 다른 곳에서는 가볍게 느껴질 수 있습니다.
사용 시간대와 이용 습관도 달라서, 알림을 보내는 시각을 한국 기준으로 고정해 두면 현지에서는 한밤중에 울리는 알림이 될 수 있습니다.
이런 차이는 문서만 봐서는 알기 어려워서, 현지 사용자 몇 분께 화면을 보여 드리고 반응을 듣는 시간이 꼭 필요합니다.

표현에서 오해가 생기지 않도록, 번역한 문구는 가능하면 그 언어를 모국어로 쓰는 분께 한 번 읽어 달라고 부탁하는 것이 좋습니다.
기계 번역이 편해졌다고는 하지만 서비스의 톤까지 맞추기에는 사람의 확인이 아직 필요해 보여요.

 

출시하고 나면 문의가 들어옵니다.
어느 언어로, 몇 시부터 몇 시까지, 누가 답할지를 정하지 않으면 서비스 품질이 가장 먼저 흔들립니다.
자주 묻는 질문 문서를 먼저 만들고, 상담이 필요한 경우만 사람이 받는 구조를 고민해 볼 수 있어요.

가정 예시로 정리해 보겠습니다.
국내에서 운영 중인 예약 서비스를 한 나라에 시험 출시한다고 해 보죠.
국가는 시장 크기만 보지 않고 결제, 법규, 언어 대응이 가장 단순한 곳부터 고릅니다.
핵심 흐름인 검색, 예약, 결제만 먼저 현지화하고 나머지 기능은 뒤로 미룹니다.
시험 기간에는 가입 완료율, 결제 실패율, 문의 유형 같은 몇 가지 지표만 보고 다음 확장 여부를 정합니다.
이렇게 하면 한 번에 모든 것을 맞추려다 일정이 무너지는 일을 줄일 수 있습니다.

 

글로벌 기획은 기능을 더하는 일보다 가정을 하나씩 확인하는 일에 가깝다고 느낍니다.
우리 서비스의 당연함이 다른 나라에서는 당연하지 않을 수 있다는 점을 계속 의심해야 해요.
요즘은 비대면 서비스가 늘면서 해외 사용자를 만나는 문턱이 낮아졌다는 이야기가 많지만, 그만큼 확인할 항목도 같이 늘어나는 것 같습니다.

아직 정리하지 못한 질문도 남아 있습니다.


현지화에 어디까지 비용을 쓰고 어디서 멈출지, 그 기준은 어떻게 세울지 고민이 됩니다.
다음에는 시험 출시 단계에서 어떤 지표를 몇 주 동안 볼지를 더 구체적으로 적어 보려고 합니다.

저작자표시 비영리 변경금지 (새창열림)

'Planning · PM > 서비스 기획' 카테고리의 다른 글

테넌트 구조 예약 시스템, 기획을 시작하며 정리한 용어들  (0) 2023.02.28
챗봇 vs 콜센터, 고객 응대 채널 전환 기준  (0) 2020.08.09
글로벌 지도 서비스를 비교하는 관점  (0) 2018.07.21
오픈 지도 프로젝트를 서비스에 쓸 때 생각할 것  (0) 2018.05.11
일상을 포인트로 바꾸는 서비스, 왜 사람들은 모으나  (0) 2018.04.28

티스토리툴바