코로나 이후, 한국에 오는 외국인 관광객/유학생들이 늘어나면서 앱/웹에 외국어 지원 기능을 넣으려는 곳들이 많아지고 있다.
내가 맡았던 테이블 오더는 일종의 메뉴판 역할을 하는 서비스라는 점에서, 명동/홍대 같은 외국인 관광객이 많이 오는 곳이나 외국인 유학생이 많은 대학가 등지에서 외국어 지원 기능이 필요하다는 니즈가 많았다. 해당 지역 매장의 타기팅을 위해 빠른 우선순위로 외국어 지원 기능을 기획했었다.
기능 기획을 해나가며, 그리고 기능 기획 이후에 운영과정에서 느꼈던 지점들이 꽤 있었다.
외국어 지원 기능이라는 것은 도메인 상관없이 여러 앱에서 보편적으로 적용될 수 있는 기능이기에 내가 겪은 경험들이 해당 기능 기획을 고민하고 있는 사람들의 시행착오를 조금이나마 줄이는 데 도움이 되지 않을까 해서 글을 적게 되었다.
1. 번역을 어떻게 해야할까?
1) 역시 가장 좋은 방법은 회사 내부
가장 좋은 방법은 회사 내부에서 해당 번역을 해줄 사람을 찾는 것이라고 생각한다. 결국 회사 서비스에 대한 맥락을 알고 번역하는 게 제일 좋을 수밖에 없다. 그렇기 때문에 회사 내에 번역을 해줄 수 있는 사람이 있다면 그분께 번역을 부탁드리는 게 번역 Quality 측면에서 가장 좋을 것이라고 생각한다.
2) 그게 어렵다면..
그게 어려운 상황에서 할 수 있는 방법은 크몽 등의 플랫폼에 있는 번역 업체들에 맡기는 방법이 있다. 한번 이용해 본 개인적인 입장에서 해당 업체의 퀄리티는 약간의 랜덤성이 있다고 생각한다.
내 시간을 아낄 수 있다는 차원의 장점은 있지만, 회사 서비스에 대한 맥락을 잘 모르기 때문에 General 한 번역값이 나올 가능성이 있다. 일반적으론 맞는 번역값이지만, 해당 서비스의 맥락엔 적합하지 않은 번역값 말이다.
또 앱 내에서 여러 언어(ex. 영어/일본어/중국어 등)를 번역해야 하는 상황이라면 더 고민이 필요하다. 크몽등에 있는 업체들은 보통 한 언어만 취급하는 업체가 많지, 여러 언어를 한 번에 하는 곳은 드물다. 따라서 이렇게 여러 업체에게 맡겼을 경우 언어의 어투(?) 측면의 통일성은 약간 아쉬울 순 있다는 점도 고려해야 한다.
그리고 마지막이 가장 중요한 부분인데, 막상 번역된 값을 받아봐도 구글 번역기나 파파고로 번역한 것과 퀄리티 차이가 크게 없다고 느낄 수도 있다.
그래서 개인적인 의견으로는
시간이 많이 없고, 번역해야 할 사항이 많다 -> 크몽 등에 있는 업체에게 번역 부탁
번역해야할 사항이 그리 많지 않고, 그 정도 양의 번역에 투자할 시간은 있다. 번역 퀄리티 보단 일단 번역이 되는 게 중요하다 -> 그냥 직접 구글 번역기 돌리기
위처럼 본인의 상황에 맞게 선택하는 게 좋다고 생각한다.
2. 기능 기획 과정에서 고려할 것은?
1) 언어/서비스가 늘어날 수 있다는 것을 고려하라
외국어 기능 기획 시 가장 보편적으로 생각해야 하는 부분은 서비스에 지원 언어가 늘어날 수도 있다는 것이다.
지금은 특정 언어까지만 지원하더라도, 언제 어떤 언어가 추가될지는 모르는 일이다. 갑자기 프랑스 관광객이 대거 한국에 옴에 따라, 프랑스어를 추가해야 할 수도 있을 것이고, 베트남 유학생이 많은 매장을 계약하기 위해선 베트남어를 추가해야 하는 상황이 발생할 수도 있다. 이렇게 여러 가지 비즈니스적 이유로 인해 지원언어를 늘려야 하는 상황이 있을 수 있다.
또, 지금은 특정 앱에서 외국어 지원 기능을 이용하더라도 추후엔 회사 내의 다른 앱에도 외국어 지원 기능을 만들어야 할 수도 있다. 초반 백엔드 설계 시 해당 확장성을 고려하고 설계하는 것과 아닌 것은 추후 해당 확장 시 들어가는 공수 측면에서 꽤나 큰 차이가 있을 수밖에 없다.
그렇기 때문에 초반 설계 때, 과연 우리 서비스가 언어가 더 늘어날 가능성이 있는지, 외국어를 지원하는 앱이 더 늘어날 가능성이 있는지에 대한 고민이 필요하다고 볼 수 있다.
2) 자동 번역 해줄 것과 아닌 것을 정의하기
이 2번째 부분은 테이블 오더라는 서비스의 특수성이라고 보면 된다.
초반 기능 기획 시 "앱에서 자동적으로 번역을 해줄 값"과, "사장님이 시스템 상에 수동 번역값을 등록해 놓아야 하는 값"을 구분하고 정의하는 과정이 필요했다.
예를 들어 식당의 [음식 명칭]을 생각해 보자.
각 식당마다 음식들 명칭도 다르다. 또 같은 명칭이더라도 사장님마다 다르게 표현하고 싶을 수 있다.
(Ex. 어떤 사장님은 삼겹살을 "Samgyeobsal"로 발음 그대로 표현하고 싶고, 다른 사장님은 "Korean bbq"로 의미를 전달하고 싶을 수 있다.)
따라서 회사의 개발 인풋 차원에서도 해당 부분은 자동번역을 지원하지 않는 게 맞지만, 유저(사장님)의 "원함"측면에서도 [음식 명칭]과 같은 부분은 유저(사장님)가 직접 워딩을 어딘가의 백오피스에 입력/저장할 수 있게 하고, 그 입력해 놓은 값이 앱에 나올 수 있게 하는 게 좋다.
반면에, [주문하기] 버튼이나, [9000 원]에서의 [원] 같이, 앱 내에서 공통적으로 쓰일 수 있는 워딩은, 사장님이 번역값을 백오피스에 입력해 놓는 것이 아닌 앱에서 자동으로 번역을 해줘서 내려주는 것이 훨씬 낫다.
대부분의 일반 유저만 고려하면 되는 1-side 앱은 모든 언어를 다 번역해서 내려주면 되겠지만
테이블 오더를 "관리하는 이용자"인 사장님과, 테이블 오더를 "사용하는 이용자"인 식당 고객이라는 2-side가 있는 입장에선, 사장님이 수동으로 입력/저장해야만 하는 항목과 우리 앱에서 자동적으로 번역해 줄 항목을 잘 구분하고 그에 따라 기획하는 과정이 초반의 핵심이었다.
3) 어느 타이밍에 다시 한국어로 돌아올 것인가?
"앱을 사용하는 사용자가 어떤 액션을 했을 때 다시 한국어로 돌아오게 할 것인가?" 도 중요하게 고민해야 하는 포인트였다.
만약 유저 1명이 사용하는 1-side 앱(ex. 은행 앱)이라면, 그 유저가 설정해 둔 언어를 계속 보여주면 될 것이다.
(Ex. 미국인 Mike 씨는 계속 영어로 보고 싶을 것이다. 따라서 Mike 씨가 앱에서 영어로 언어 선택을 하면 Mike 씨가 직접 설정값을 변경하지 않는 한 계속 영어 상태값을 유지하는 게 맞을 것이다.)
하지만 테이블 오더의 경우 위의 은행앱과 달리 그 태블릿/앱을 쓰는 사용자가 계속 바뀐다.
저녁 6시에는 해당 자리에 미국인 Mike 씨가 앉았다가, 7시에는 일본인 기무라 씨, 8시에는 한국인 철수 씨가 앉을 수 있다.
그런 차원에서 앱에서 유저가 "어떤 액션을 했을 때" 다시 기본값인 한국어로 앱 모드를 변환시킬지에 대한 고민이 기획과정에서 필요했다. (ex. 대기화면으로 돌아왔을 때, 유저가 결제를 했을 때, 기타 등등)
기존에 그 자리에 앉은 사람이 아직 자리를 떠나지 않았다면 설정해 둔 언어로 계속 보여주는 게 사용성 측면에서 좋고, 자리를 떠났다면 그다음에 올 손님 중 가장 비중이 높을 수밖에 없는 한국어를 표출시켜 주는 게 더 좋기 때문이다.
3. 기획/개발 시 참고할만한 추가 Tip들
위에서 적은 내용 외에도 추가적으로 기획 시 참고할만한 tip들을 좀 더 적어보겠다.
1) 화면 단위로 언어를 정리하기
결국 앱 서비스 번역 기능에 있어서의 핵심은 [1. 빠진 화면/워딩없이 2. 번역을 정확히 하는 것]이라고 생각한다.
빠진 워딩이 없게 하기 위해, 내가 선택했던 방식은 IA(화면구조) 단위로 앱의 모든 워딩들을 엑셀 시트에 저장했던 것이다.
주요 화면 별로 구성되어 있는 1,2,3 depth를 파악하고 각 화면에서 나오는 "문구"들에 대해 영어/중국어/일본어 번역값 한 곳의 시트에 저장했다.
실제 개발 과정에선 이런 화면단위 구분보다는 번역이 필요한 언어를 중복되지 않게 프런트엔드 개발자에게 전달하는 게 더 필요했었다. 하지만 번역값들에 대한 아카이빙/지속적 업데이트 및 관리 측면 에선 이런 IA(화면구조) 식으로 해당 서비스의 모든 번역값들을 한 곳에 정리하는 게 꽤 유용했던 것 같다.
2) 빠트리기 쉬운 오류메시지
화면단위로 빠짐없이 번역을 해놓으려 해도 놓쳤던 부분이 뭐라고 물어본다면 앱 내의 여러 "오류 메시지"라고 말하고 싶다. 실제로 웬만한 화면들은 디자인 파일로 회사 내부에 다 정리가 되어있기도 하고, 실제 앱을 이용해 보면서 접할 수가 있다. 하지만 특정 "오류 메시지"의 경우엔 디자인 파일로까진 정리가 안되어있는 경우도 있고, 해당 오류메시지를 회사 내부가 아니라 외부 서버에서 내려주는 경우도 있기 때문에 더 파악하기 쉽지 않은 경우가 있다. 또 평소에는 잘 등장하지 않는 오류 상황인 경우도 있고 말이다.
그렇기 때문에 이런 부분들의 경우 초반 번역과정/개발과정에서 조금 놓쳤었었고, 이 부분들은 추후 QA(테스트) 과정에서 발견해서 추가하는 식으로 진행했었다.
3) 더 짧은 번역이 필요한 영어/일본어
언어 특성상, 번역시 영어와 일본어는 같은 말이더라도 중국어에 비해 조금 더 텍스트가 길어지는 경우가 있다.
중국어는 한자 몇 개로 이뤄져 있지만, 영어는 띄어쓰기도 필요하고 일본어는 각종 조사도 많이 붙기 때문인 것 같다.
모바일 앱의 특성상, 결국 화면 크기나, 팝업 창 크기에 제약이 있을 수밖에 없다. 따라서 너무 번역값이 길어질 경우 UI가 깨지거나 폰트가 화면을 넘어가는 상황이 생길 수 있다. 이 경우 해당화면만 Enter 처리를 프런트엔드 개발자가 일일이 추가로 해야 하고, 그에 따른 디자인도 추가 작업이 필요할 수 있다.
이런 메이커 분들의 불필요한 공수를 최대한 줄이기 위해 너무 긴 워딩으로 번역됐다면 좀 더 짧은 대체 워딩으로 번역값을 바꿔주는 게 필요하다.
실제로 이런 부분들이 시행착오를 겪었던 부분 중에 하나였고, 맨 처음 기획할 때부터 이 지점을 알았다면 공수를 훨씬 아낄 수 있지 않았을까 싶다.
4) 번역값은 형식에 맞춰 전달하기
프런트 엔드 개발자가 컴퓨터 코드에 해당 번역값을 넣기 위해선 필요한 형식이 있을 수 있다. (ex. json 형식, csv 형식 등등) 개발자와 소통을 통해 원하는 형식을 물어본 후 해당 형식에 맡게 넣어서 전달해 준다면 귀한 개발자 분의 시간을 최대한 줄일 수 있다.
예를 들어 코드 상 워딩들에 대한 한국어(기본) 값이 다음과 같은 양식으로 저장되어있다면,
{
"order": "주문하기",
"won": "원"
}
번역해야 하는 값의 엑셀/텍스트 파일을 아무 형식으로 통째로 던져 주는 것이 아닌,
아래와 같이 번역해야 하는 값을 기존 형식에 맞춰 삽입해서 전달해 주는 식이다.
{
"order": "Place an order",
"won": "won"
}
이렇게 해서 전달 시 확실히 프런트엔드 개발자 분의 막일(?) 리소스를 줄일 수 있고, 이런 부분을 기획자가 해서 넘겨드려야 개발자 분이 리소스를 다른 곳에 더 잘 활용할 수 있기 때문에 이런 방식을 추천한다.
5) 더 세심해져야 개발자 분들이 덜 고생한다
변숫값 영역이나, 하이라이트 폰트 영역까지 고려할 수 있다면 프런트엔드 개발자 분 입장에서 훨씬 편해질 것이다.
예를 들어서, [9000 원]에서 [9000]이라는 부분은 상품의 가격에 따라서 값이 달라지는 변수이다. 소위 말해 "{n} 원" 이런 식으로 코드 상 저장이 되어있고 금액에 따라 "n"의 값이 달라질 것이다.
영어/중국어/일본어로 번역을 하다 보면, 해당 언어의 어순 상 "n"의 위치가 한국어와는 달라질 경우가 생길 수도 있다. 예를 들면 한국어에선 어순의 맨뒤에 있었는데, 영어에선 맨 앞으로 오는 경우도 생긴다.
따라서 번역값을 전달해 줄 때 해당 "{n}"의 위치에 대한 고려까지 해서 전달한다면, 조금 더 세심해질 수 있다.
마찬가지로 앱 내 텍스트 중에 하이라이트 폰트가 적용된 부분이 있을 수 있다.
예를 들어서 [n초 후 앱 꺼짐]이라는 텍스트 중에 "n초 후"라는 부분만 주황색 글씨(하이라이트 폰트)고, 나머지 "앱 꺼짐"은 검은 글씨(일반 폰트)라고 하자.
영어/일본어/중국어 등 타 언어로 번역했을 때는 언어의 어순 상 해당 "n초 후" 부분이 어순의 맨 앞이 아닌 맨 뒤로 갈 수도 있다. 이런 부분들에 대한 고려까지 진행해서 개발자 분과 같이 논의를 한다면 조금 더 시행착오를 줄일 수 있다.
4. 개발 완료 후에 신경 쓸 것
1) 앞으로의 모든 기능에 외국어를 고려해야 한다
한번 서비스에 외국어 기능을 넣기 시작하면, 그 뒤 모든 추가 기능을 기획/개발할 때마다 외국어에 대한 고려가 필요하다.
특정 기능이 추가된다면 해당 기능을 구성하고 있는 UI에 텍스트가 포함되어 있는 경우가 대부분이다. 결국은 추가된 UI/텍스트에도 번역값을 파악해서 외국어 대응 작업을 해야 하는 경우가 생긴다.
결국 이는 외국어 기능을 지원하기 시작한 순간 기획/디자인/개발에 있어서 계속 추가적으로 신경 써야 할 것이 생긴다는 의미이고, 추가적인 작업이 생길 수 있다는 뜻이다. 또, 기능 QA(테스트) 시에도 일반 한국어 화면뿐만 아니라 각 언어별 화면에 대해서 QA를 해봐야 한다는 점에서 QA 량이 이전보다 많아질 수 있다.
이는 기능은 다르지만 "큰 글씨 모드"를 넣었을 때도 유사하다. 앱의 워딩/사진 등을 큰 폰트/배율로 볼 수 있게 해주는 큰글씨 모드를 지원하게 됐을때도, 신규 기능을 제작할 때마다 이 기능에 대한 큰 글씨 모드는 어떻게 할지에 대한 고려가 필요하다.
실제로 테이블 오더 서비스에도 추후에 "큰글씨 모드"를 넣었었고, 추가 기능 기획/테스트 시 외국어, 큰 글씨, 그리고 이의 조합으로 인해 생기는 이슈들에 대한 모든 고려가 필요해졌다.
이처럼 외국어 지원 기능 삽입시 앞으로 신규 기능 개발시마다 신경 써야 할 부분들이 지속적으로 생긴다는 의미이므로, 이 기능의 개발 "시점"에 대한 고민도 필요하다고 생각한다.
2) 번역값들에 대한 아카이빙
기획자로서 신경 썼었던 것 중 하나가, 번역된 값에 대한 아카이빙이었던 것 같다. 지속적으로 신규 기능이 추가될 때마다 추가적인 번역값들이 생길 수밖에 없으므로 이에 대한 지속적인 업데이트 및 관리를 신경 썼다.
특히 일반적인 기능이라면 디자인 파일을 다 아카이빙 해놓으면 좋지만, 번역값의 경우 해당 부분을 다 아카이빙 해놓으려면 기존 디자인을 3~4벌씩 추가적으로 만들어야 하기 때문에 조금은 비효율적인 인풋이 생길 수 있다.
그러한 차원에서 초반에 IA(화면구조) 단위로 만들어놨던 엑셀 시트를 계속 잘 활용했었다.
외국어 지원 기능은 회사에 들어가서 초반에 맡았던 기능 중 꽤나 고려해야 할 게 많았던 기능 중 하나였었다. 외부 번역업체에 대한 컨택, 타 서비스를 다루는 PO, 개발자 분들과의 소통과 협업, 번역값을 개발자 분께 알맞게 전달하는 방식 등에 대한 고민, 추후 기능 기획에서의 고려까지. 지금 생각해 보면 고민할 사항이 많았기에, 배울 수 있던 요소도 더 많았다고 생각한다.
이 기능에 대한 경험이 앞으로 어떤 식으로 나에게 도움 될지는 모르겠지만, 여러 앱에서 공통적으로 쓰일 수 있는 기능이라는 점에서 좋은 경험을 했다고 생각한다.
앞으로도 이번 외국어 기능 기획 때 배웠던 것처럼, 다양한 일/경험들을 하면서 배웠던 내용들을 지속적으로 적어보려 한다.
Profile:
'대학생! 핀테크 스타트업 PO가 되다' 카테고리의 다른 글
| 13. 하드웨어를 맡게된 PO - 자체 태블릿 제작기 ② (진행 업무) (2) | 2023.11.29 |
|---|---|
| 12. 하드웨어를 맡게된 PO - 자체 태블릿 제작기 ① (제작 배경) (2) | 2023.11.28 |
| 10. 기획 과정에서 배운 것들 ① (feat. 안정화 기능) (2) | 2023.10.30 |
| 09. 하루에 몇 십개의 일을 처리하기 (feat. PO의 숙명) (0) | 2023.10.16 |
| 08. 대학생 PO가 직원들의 신뢰를 얻기까지 下 - 새벽 1시에 식당 사장님 전화를 받다. (4) | 2023.10.04 |