마케팅과 같은 비기술분야 사람들은 여러 나라를 지원하는 기능을 "소프트웨어 글로벌화"라는 추상적인 용어를 사용하지만 그건 비전문가들이 알아듣기 쉬우라고 사용하는 용어이고 이 분야의 기술적인 용어로는 정확하게는
Internationalization(국제화)와
Localization(지역화)라는 고유명사를 사용한다..
Internationalization을 약자로 I18n이라고 하고
Localization을 L10n이라고 한다.
필자가 소프트웨어 국제화/지역화에 몸을 담게 된 계기는 1990년 초에 Sun Microsystems(지금은 Oracle)의 국제화 부서에서 일하면서였다. Sun의 Unix OS인 Solaris 전체를 국제화한 부서였다. 세밀하게는 국제화와 지역화의 두 단계로 나누어져 있는데 난이도로 말하면 국제화가 지역화의 100배쯤 어렵다. 국제화를 제대로 한다는 것은 전 세계의 언어뿐 아니라 문화까지도 알고 있어야 가능하기 때문이다. 썬마이크로시스템즈, 마이크로소프트, 애플과 같은 미국 회사의 국제화는 항상 미국본사에서 수행하고 각 나라의 지역화 업무는 각 나라의 지사에서 국제화의 결과로 정해진 규칙에 따라 시키는 대로 수행하는 것이다. 즉 한글화를 했다고 해도 국제화를 이해한 것은 아니다. 사실은 국제화를 해 본 적도 없다는 것이 정확한 표현이다. 설계도에 따라 건물을 시공했다고 해서 설계를 이해하는 것은 아닌 것과 같다.
필자가 소프트웨어 국제화/지역화에 몸을 담게 된 계기는 1990년 초에 Sun Microsystems(지금은 Oracle)의 국제화 부서에서 일하면서였다. Sun의 Unix OS인 Solaris 전체를 국제화한 부서였다. 세밀하게는 국제화와 지역화의 두 단계로 나누어져 있는데 난이도로 말하면 국제화가 지역화의 100배쯤 어렵다. 국제화를 제대로 한다는 것은 전 세계의 언어뿐 아니라 문화까지도 알고 있어야 가능하기 때문이다. 썬마이크로시스템즈, 마이크로소프트, 애플과 같은 미국 회사의 국제화는 항상 미국본사에서 수행하고 각 나라의 지역화 업무는 각 나라의 지사에서 국제화의 결과로 정해진 규칙에 따라 시키는 대로 수행하는 것이다. 즉 한글화를 했다고 해도 국제화를 이해한 것은 아니다. 사실은 국제화를 해 본 적도 없다는 것이 정확한 표현이다. 설계도에 따라 건물을 시공했다고 해서 설계를 이해하는 것은 아닌 것과 같다.
국제화 자체가 방대한 주제인 만큼 국제화의
모든 기술을 설명한다는 것 자체가 많은 시간이 걸리는 일이다. 국제화에 수십 년의 경험을 가진 전문가들이 존재한다. Sun에서 일할 때 같이
Consortium으로 일했던 여러 회사의 동료들이 아직도 Unicode를 포함한
국제화 분야에서 일하고 있기도 하다.
국제화를 하기 위해서는 알아야 하는 다른
나라의 문화들 중 몇 개만 예로 들어 보자.
•
일본어와 중국어 문장에는 빈칸도 없고 마침표 “.” 를 사용하지 않는다
•
“01/02/03” 이 몇 년 몇 월 몇 일을 의미하는가? 나라에 따라 다르다.
•
독일에서 숫자 “12.456,789” 는 무엇인가?
•
프랑스에서 노트북 가격이 “1 199,01 EUR” 라고 적혀 있는데 저렴한 것처럼 보이니 사야 하나?
•
다음과 같은 사람 이름이 있다. 누구인지는 웹에서 검색해 보면 나온다. 성과 이름이 무엇인가?
•
Sheikha Manal bint Mohammed bin Rashid Al Maktoum
•
Victoria Mary Augusta Louise Olga Pauline Claudine Agnes
•
여권에 적힌 이름이 한 단어밖에 없다. “Pal” 이라는 인도 사람인데 성인가 이름인가?
이 예는 다른 나라 문화의 극히 일부분을
보여 주는 것이고 이런 분류체계만 수 백 개의 카테고리가 있다.
국제화를 제대로 한다는 것은 이런 모든 경우들을
나라별, 언어별, 지역별로 제대로 표현되도록 해야 하는 것이다. 국제화를 제대로 하기는 거의 불가능할 만큼 어렵다.
지금 사용하는 언어 코드체계인 Unicode도 전세계 모든 나라의 언어를 포함하는 합집합으로 만들어 놓은
것이다. Microsoft, Sun, Apple등이 회원이었던 Unicode
Consortium에서 모든 나라의 언어들을 모아서 최초로 정리하는데도 많은 시간이 걸렸고 몇 십 년이 지난 지금도 계속
진화하고 있을 정도로 국제화는 변화한다.
국제화에 필요한 수 백 개의 분류 항목 중
오래 전에 POSIX와 X/OPEN의 표준이라고 정해 놓은 6개가 있다. 문자타입,
시간형식, 숫자형식, 정열방법,
화폐단위, 메세징 이다. 이
6개가 가장 기본적인 것이긴 하지만 그 외에도 많은 중요한 비표준인 분류가 있고 또 새로 생겨나기도 했다.
결국 국제화를 제대로 하기 위해서는 이런 모든 분류항목을 고려해 보고 어떻게 할 것인지를 결정해야 한다.
눈에 보이는 화면이나 번역했다고 국제화를
한 것이 아니다. 그렇더라도 역시 가장 중요하고 사용자가
즉시 부딪치는 것이 화면에 보이는 것이다. 이를 메세징(Messaging)이라고 한다. 이번 포스트는
국제화에 대한 소개 단계이기 때문에 모든 사람들이 쉽게 이해하는 메세징에 대해 간단한 소개만 한다.
메세징에는 각 나라 언어에 따른 번역이 따른다. 즉 "Open" 이라는 버튼이 있으면 한국에서는 "열기" 로 번역을 해야 한다. 다섯 언어를 제공해야 한다면 다섯 언어로 번역을 해야 한다. 당연히 "Open"이라는 영어 원문과 "열기" 라는 한글
번역본이 어딘가에 존재하게 된다. 통상적으로 각 나라의 "언어팩"
이라고 불리는 패키지에 그 나라 번역결과가 포함되어 있다. 리눅스나 마이크로소프트의
윈도즈를 설치하다 보면 각 나라의 언어팩을 원하는 대로 언제든지 추가 설치할 수 있다는 것을 알 수 있다.
메세징에서 개발자들의 가장 원초적인 생각은
번역 결과물을 소스코드에서 분리하여 관리하겠다는 것이다. 옳은 생각이긴 하나 이런 분리 방식은 50년 이전부터 여러 언어를 지원하기 시작한 최초의 시점부터
실행되어온 방법으로 너무 당연하다. catgets 와 같은 표준 방식이 그들 중 하나이다.
어떤 방법을 사용하든 결국은 "메세지 아이디"(msgid)와 "메세지 번역결과"(msgstr)의 쌍을 포함하는 "메세지 카탈로그"라는 목록을 언어별로 관리해야 한다. 이를 위해서는 순진한 개발자들의 머리에서 고안된 수 많은
방법이 있다. 가장 간단한 세가지 예를 들면 msgid가 영어 원문,
심볼이름, 숫자로 된 경우이다.
·
open=열기
·
1=열기
·
ID_OPEN=열기
여기에 예로 나열한 방법들을 사용하여 메세지를
번역하고 소프트웨어가 제대로 구동되면 국제화가 되었다고 생각할 수 있으나 이는 시작에 불과하다. 이제부터 메세징의 진정한 문제가 시작된다. 특히 소프트웨어가 규모가 커지고 여러 나라를 지원해야 할 필요가 있으면 문제는 기하급수적으로 커진다. 즉 제품이 잘 팔리기 시작하면 문제가 나타나기 시작한다. 소스코드의 변경에 따른 필연적인
msgid의 변경으로 이어져 과거에 번역해 놓은 결과가 수정, 삭제,
추가 되는 과정에서 100개의 언어를 지원해야 한다만 악몽이 시작된다.
아직 이런 악몽을 겪지 않았다면 아직은 소규모의 소프트웨어이다. 글로벌 소프트웨어가
되기 위한 첫 단계에 신고식처럼 큰 장애물이 있는 것이다. 국내에서만 팔겠다면 국제화는 걱정할 필요가 없다.
하지만 아무리 제품전략이 좋고 훌륭한 개발자가 있어도 이 국제화 기술 하나가 잘못 채택되면 글로벌 소프트웨어를 만들 수
없다. 필자의 20년 국내 경험상 국제화 메세징 기술은 국내 소프트웨어
회사가 글로벌 회사에 비해 적어도 20년 이상 뒤떨어진 분야이다. 국제화
교육이 있기도 하지만 그것은 입문자를 위한 소개 코스에 불과하다.
국제화는 구현의 문제가 아니고 구조적인 아키텍처의
문제이다. 적어도 글로벌 소프트웨어가 목표라면 누구나
생각할 수 있는 단순한 방법으로 과연 글로벌 소프트웨어를 만들 수 있을까 하는 의심을 해 보는 것이 좋다. 구체적으로 소프트웨어의 생존주기에 벌어지는 일을 고려하고, 소프트웨어 규모가 커지고,
지원해야 할 언어가 100개로 증가하면 어떻게 할까 하는 전략을 생각해 봐야 한다.
한 번 잘못 시작된 국제화 아키텍처는 제대로 만들기가 어렵다. 거의 모든 소스코드에
영향을 미치는 대규모 수정이기 때문에 시간과 비용이 들 뿐 아니라 현재 진행되던 개발에 영향을 미치는 "브랜치와 머지" 문제가 발생하기 때문에 쉽게 할 수도 없다. 현실적으로 이미 잘못된 메세징 방식은 변경하기가 어렵다. 새로운 버전을 개발할 때 제대로 하는
것이 현실적인 권장 사항이다. 이런 문제를 시행착오 경험으로 배우려면 회사가 잘 되어야 한다.
그런데 그 때 알게 되면 늦는다는 딜레마가 있다. 처음부터 전문가의 조언을 받는
것이 좋다.
국제화 분야의 하나인 메세징도 겉으로는 모든
개발자가 할 수 있을 것처럼 쉬워 보이지만 극히 고도의 전략과 기술이 필요한 전문 분야이다. 처음에 잘못하면 미래의 발전을 꽉 막아버리는 중요한 기술이다.
앞에서 언급했듯이 글로벌 회사의 한국지사에서 수행하는 소프트웨어 지역화는 매우 단순한 개발이나 번역작업이기 때문에 이는
고도의 전문성이 필요한 국제화와는 다르다.
메세징만 해도 깊고 방대한 주제이기 때문에
여기서는 이 정도로 소개하고 글로벌 회사들이 사용하는 방법에 대해 깊이 있게 서서히 소개하기로 한다.