brunch

You can make anything
by writing

C.S.Lewis

by 박동윤 Nov 08. 2021

[10] 다국어 지원

디자이너가 된 엔지니어 - 10

디자이너이자 크리에이티브 테크놀러지스트이며 저자인 박동윤(Yoon Park)은 현재 미국 시애틀 마이크로소프트 본사의 Mixed Reality Design & UX Research 팀에서 Principal UX Designer로서 홀로렌즈 및 혼합현실 서비스와 관련된 디자인을 담당하고 있다. 전자공학을 전공하고 반도체 설계 및 모바일 소프트웨어 연구원으로 일하다 그래픽 디자인이 너무 좋아 시각 디자인을 다시 공부하여 디자이너로서의 커리어를 새롭게 시작했다. 타이포그래피에 대한 관심을 바탕으로 2011년 Typography Insight앱을 출시했으며, 현실 공간에서 타입 레이아웃을 가능하게 하는 Type In Space라는 홀로렌즈용 앱을 만들기도 했다. 
홈페이지 - http://dongyoonpark.com 
링크드인 - https://www.linkedin.com/in/cre8ivepark/

전자공학을 전공하고 소프트웨어 엔지니어로 일하던 저자가 직장을 그만두고 시각디자인을 다시 공부하여 미국 마이크로소프트에서 10여 년간 UX 디자이너로 일해온 경험을 공유합니다


Internationalization & Localization

앱이 윈도우즈에 기본 탑재되기로 결정된 후에 한 가지 중요한 문제가 생겼는데, 바로 다국어 지원이었다. 윈도우즈 팀에서 공유한 방대한 로케일 및 언어 테이블을 보니 전 세계 수백 수천만이 사용하는 운영체제라는 사실 실감이 되었다. 여러 국가의 언어로 우리의 앱 들이 어떻게 표현될지 미리 가늠해 볼 수 있도록 개발팀에서 우리의 앱에서 의사(擬似) 로컬라이제이션 (pseudo-localization)이라는 기능을 지원하도록 업데이트해 주었다. 이 기능을 사용해 전 세계 다양한 언어의 특성들을 시뮬레이션 테스트해 볼 수 있었다. 가장 대표적인 특징은 텍스트의 길이였는데, 영어 라틴문자를 기반으로 디자인한 작업들이 다양한 언어들로 번역이 되었을 때 길이가 훨씬 길어지거나, 축약어의 경우 특정 국가/언어에 해당되는 축약어가 없어 길게 풀어 설명이 되는 경우가 있었다. 그리고 각 언어에 대해 사용되는 서체의 특성이 다르기에 어떻게 콘텐츠가 표시될지 걱정이 되기 시작했다. 


의사 로컬라이제이션 기능을 켜자 영어를 기반으로 작업한 우리의 앱의 많은 부분의 레이아웃이 처참하게 박살이 나는 것을 볼 수 있었다. 특히 데이터 타일들이 많은 문제가 있었는데, 일부의 경우 디자인 자체의 변경을 고려해야 하기도 했다. RTL(Right to Left, 우측에서 좌측으로 읽어나가는 언어 — 아랍어, 히브리어 등) 언어들에 대한 UI 디자인도 중요한 부분이었는데, 콘텐츠 전체를 단순히 좌우를 대칭한다고 해결되는 문제가 아니기에 보다 꼼꼼한 점검이 필요했다. 

Pseudo Localization을 통한 다국어 지원 테스트. 레이아웃이 많이 깨지는 것을 볼 수 있다.


우리는 각자 담당한 앱들을 점검하며 문제가 되는 부분들을 정리하기 시작했고, 해당 요소들에 대한 해결 방법을 찾기 시작했다. 간단한 것들은 단순히 텍스트 레이블의 프레임을 좀 더 여유 있게 늘린다던가 좌우/상하의 여백을 넉넉히 확보하는 수준으로 해결 가능했지만, 좁은 공간에 많은 텍스트와 데이터가 모아져 있는 부분에서는 좀 더 다른 솔루션에 대한 생각을 필요로 했다. 특히 아시아의 2-byte 문자권 (한글, 한자, 히라가나 등)이 차지하는 공간의 크기나 해당 언어의 폰트가 가지는 특성들이 많은 문제를 야기했는데, 보다 근본적인 원인과 솔루션을 찾기 위해 디자인 팀원 중 한국어와 일본어를 할 줄 아는 내가 나서서 이에 대해 깊게 조사하기로 마음을 먹었다. 


우선 여러 국가별로 마이크로소프트에서 기본으로 사용하는 폰트를 리스팅 한 자료를 찾아 해당 폰트 별 x-height 및 행간 등에 대해 이해하고, 문제가 일어나는 부분들에 대해 중점적으로 조사를 했는데, 이미 우리가 개발 중인 앱의 코드를 가지고 있었기에, 다양한 프런트엔드 부분의 폰트 관련 파일들의 변경 및 테스트들을 통해 어느 정도 해결책을 도출해 낼 수 있었다. 


언어별로 다른 폰트의 특성과 행간의 차이에 대한 조사
앱에서 스타일링이 어떻게 이루어지는가를 팀 멤버들에게 설명하기 위한 그래픽


다양한 국가의 언어로 바꿔가며 디자인을 점검해 보던 중 발견한 또 한 가지 사실은, 특정 국가의 폰트에는 숫자(numeric text)를 표시할 때 라틴문자권의 폰트와는 다르게 Segoe UI 폰트가 아닌 다른 폰트가 사용되는 경우가 있어 디자인의 일관성을 해치고 있었다. 예를 들면 일본어의 기본 폰트인 Meiryo UI의 경우 Segoe UI가 아닌 Verdana를 숫자로 표시하는 데 사용하고 있어 다른 언어권의 디자인과의 거리감이 컸고, 라틴문자를 표시하는 Segoe UI와는 어울리지 않았다. 


이를 해결하기 위하여 고민을 하던 중 앱의 스타일링의 근간이 되는 CSS의 폰트 순서 및 fall-back 폰트 특성을 활용한 솔루션을 고안해 냈고, 적용 결과 효과적으로 해당 문제가 해결이 되는 것을 볼 수 있었다. 아이디어는 바로 Segoe UI를 언어에 관계없이 폰트 우선순위의 첫 번째로 배치하는 것인데, 이를 통해 모든 숫자는 Segoe UI 폰트로 표시가 된 후, 해당 언어(일본어, 중국어, 태국어, 등)의 글립(glyph)은 Segoe UI 폰트가 표시할 수 없기에 다음 순서의 폰트로 넘어가 올바르게 언어에 맞는 폰트로 표시가 되는 방식이다. 

국가별 올바르지 않은 폰트가 적용되는 사례(왼쪽) 와 올바르게 수정된 솔루션 적용 예 (오른쪽)

나는 다양한 국가의 언어로 이 솔루션을 테스트한 후 디자인 팀 멤버들에게 프레젠테이션 하였고, 이후 엔지니어링 팀에 프레젠테이션을 하여 실제 빌드에 적용 및 테스트를 하였다. QA 팀에서도 여러 테스트를 거친 결과 해당 솔루션이 잘 동작함을 확인하고 소식을 내게 전해주었는데, 간단하면서도 효과적인 방법으로 디자인 일관성과 퀄리티를 달성할 수 있었다는 점에서 많이 뿌듯함을 느끼게 된 순간이었다. 그리고 나만이 가지고 있던 장점 들 — 엔지니어로서의 경험을 바탕으로 프런트엔드 조작을 통해 솔루션을 직접 프로토타이핑해보고 도출해 낸 점, 한국어, 일본어 등의 아시아권 언어의 타이포그래피에 대한 경험으로 중요 요소들을 캐치해 내고 문제점을 발견해 낸 점 등— 을 잘 활용할 수 있었던 기회로 더 보람을 느낄 수 있었다.


로컬라이제이션 작업 중에 한 가지 재미있었던 부분은, 주식시장의 상승과 하락을 나타내는 색상이었는데, 한국을 비롯한 여러 아시아권 국가들은 빨간색이 주식의 상승을 나타내고, 초록색은 하락을 나타내지만 미국은 정 반대였다. 이 부분에 대한 차이점을 처음 알게 된 미국 팀 멤버들은 왜 빨간색이 상승장을 나타내는지 신기해하기도 했다. 


디자이너가 된 엔지니어 시리즈 


브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari