01/02/03은 몇년 몇월 며칠일까?
우리나라 사람들은 2001년 2월 3일로 읽지만 미국사람들은 2003년 1월 2일로 읽는다. 이것이 다 일까? 호주사람들은 2003년 2월 1일로 읽는다. 이렇듯 나라마다 날짜를 쓰는 방식이 다를 뿐만 아니라 번역, 날짜, 숫자, 화폐, 단수/복수, 어순, 쓰기 방향, 키보드배치, 폰트, 띄어쓰기 여부, 쉼표, 온도, 문장정렬, 이름, 주소, 색깔의 의미, 섬머타임, 종이 크기 등 지역, 언어별로 다른 것들은 수천가지에 이른다.
이렇게 나라마다 언어마다 다른 특성을 소프트웨어도 각각 다르게 지원해야 한다. 이를 소프트웨어 국제화와 지역화라고 부른다. 하지만 많은 우리나라 소프트웨어는 제대로 된 국제화 전략 없이 개발돼 해외에서 외면받는 일이 많다.
그 중에는 적당히 넘어갈 수 있는 것도 있지만 많은 항목들이 버그로 보고 된다. 어설프게 개발된 소프트웨어는 고쳐도 고쳐도 끝이 없다. 일단 국제화에 대한 이해를 돕기 위해서 꼭 알아야 할 용어를 알아보자.
첫 번째는 국제화(Internationalization)다. 영어 줄임말로 i18n이라고 한다. ‘i’와 ‘n’사이에 18글자의 알파벳이 있다. 단어가 워낙 길어 이렇게 짧게 줄여서 얘기한다. 소프트웨어를 여러 나라 언어를 지원하기 쉬운 구조로 만드는 것이다. 국제화가 잘된 소프트웨어는 쉽게 여러 나라 언어를 지원할 수 있다.
두 번째는 지역화(Localization)다. 줄여서 L10n이라고 한다. 소프트웨어를 특정 지역의 언어를 지원하도록 만드는 것이다. 예를 들면 중국어나 일본어를 지원하는 것이다.
소프트웨어 국제화라고 하면 누구나 알 것 같은 용어지만 기술적으로 자세히 들어가면 그렇게 간단하지는 않다. 많은 회사들이 소프트웨어 국제화에 대한 정교한 전략 없이 일단 소프트웨어를 개발해 놓고 국내에서 반응이 좋으면 번역을 해서 해외에 팔면 된다고 생각한다. 국제화를 미리 대비한다고 해도 국제화에 대한 부족한 지식과 경험으로 실제 해외 판매 시 많은 문제를 겪는다.
소프트웨어를 개발해서 많은 나라에 팔기 위한 전략과 기술은 수십 년간 발전해 왔는데, 많은 개발자나 경영자들은 단순히 메뉴 정도만 번역하면 되는 정도로 이해를 하고 국제화에는 별로 투자를 하지 않는다. 우리나라에 소프트웨어 국제화 전문가가 턱없이 부족한 것도 큰 문제다.
개발자가 수천명인 대기업부터 1인 스타트업까지 우리나라 소프트웨어 회사 중에서 국제화를 제대로 알고 적용하고 있는 회사는 거의 없다고 보면 된다. 문제는 대부분 국제화가 그렇게 어려운 지, 무엇을 해야 하는지 잘 모른다는 것이다.
의욕만 가지고 되는 것은 아니다. 방대한 지식과 경험이 필요하다. 비주얼스튜디오나 엑스코드(XCode) 등 각 개발 툴에서 제공하는 기본적인 국제화 방법은 그야말로 기초 중에 기초이며 이것만 이용해서 대규모 상업용 소프트웨어의 국제화를 완성할 수는 없다. 그런 것들은 마트의 시식코너 같은 것인데 이것이 전부인줄 알면 오산이다.
우리가 흔히 알고 있는 글로벌 소프트웨어들은 국제화가 매우 잘 되어 있고 지역화를 통해서 수십, 수백개의 언어를 지원한다. 기술적으로는 지역과 언어를 합친 로케일(locale)을 지원한다고 한다.
소프트웨어를 처음 개발할 때부터 국제화를 제대로 적용하면 개발비용이 5%만 더 들어간다. 추후 지역화 비용은 각 언어별로 1~2%정도만 더 쓰면 된다.
제품마다 비율은 다르지만 대충 이해를 돕기 위해서 설명하면 그 정도다. 여러 언어를 지원하더라도 개발자들이 특별히 해줘야 할 것은 거의 없고 대부분의 프로세스는 자동화된다. 국제화가 잘 된 소프트웨어는 추가로 몇 개의 언어를 지원하더라도 큰 비용과 시간이 들지 않는다.
하지만 급하다고 또는 무지 때문에 국제화에 대한 전략 없이 그냥 소프트웨어를 개발하면 처음에는 5% 절약은 되겠지만 나중에 여러 언어를 지원하려고 할 때 수십 ~수백배 비용이 더 들어가게 된다. 시간이 흐를수록 비용도 점점 늘어난다.
물론 나라별 고객의 요구를 무시하면 되지만 그러면 제품 품질은 형편없이 떨어지게 된다. 사례에 따라서 비용 부담의 편차는 다르지만 허술한 국제화에 대한 전략이 미치는 폐해는 엄청나다. 많은 회사들이 어설프게 여러 언어를 지원하다가 포기하거나 결국 실패한 사례는 셀 수 없이 많다.
그렇지만 소프트웨어 국제화를 처음부터 제대로 적용하기는 쉽지 않다. 소프트웨어 국제화 시 고려해야 할 것이 수백 가지인데 일반 개발자들은 대부분은 들어본 적도 없는 것들이며 들어 봤어도 어떻게 해야 할지 막막한 것들이다.
소프트웨어 국제화는 관습, 문화적인 것도 이해를 해야 하지만 기술적인 것도 매우 중요하다. 국제화를 위한 수많은 기술이 수십 년간 연구되어 왔는데 이를 다 이해하는 것만도 전문가가 아닌 사람들에게는 벅찬 일이다. 그래서 소프트웨어 국제화 전문가가 필요한 것이다.
그럼 우리나라 회사들은 어떻게 국제화에 실패했는지 실제 사례를 알아보자.
E사는 초기에 한국어만 지원하도록 소프트웨어를 개발했다. 그런데 일본어 버전이 필요할 때 한국어 버전을 복사해서 번역을 할 경우 한 달이면 일본어 버전을 만들 수 있고 나름대로 국제화를 적용하려면 두 달이 걸린다는 개발자들의 의견에 경영진은 빠른 개발을 선택했다.
한국어와 일본어 버전은 소스코드가 갈라졌고, 매번 개발 시마다 양쪽 소스코드에 각각 기능을 적용했다. 두 소스코드는 점점 달라졌다. 이제는 너무 달라져서 두 소스코드를 다시 합치는 것이 불가능하며 그런 식으로 중국어 버전까지 나오다보니 비효율적인 개발에 따른 고통을 겪고 있다.
S사는 웹서비스 회사다. 처음에는 국내 사용자만을 대상으로 하는 서비스였는데 몇 년전 해외에도 서비스를 오픈 하려고 했다. 하지만 처음에 서비스를 시작할 때 별 계획 없이 데이터베이스에 자료를 한국어(EUC-KR)로 입력해 놓았다.
전세계 모든 언어를 지원하려면 유니코드로 저장해야 한다. 글로벌 서비스를 위해서 데이터를 유니코드로 변환하려고 했는데 데이터베이스만 변환한다고 될 일은 아니었다. 얽혀 있는 것이 너무 많고 소스코드를 너무 많이 바꿔야 했다. 엄두가 나지 않아 결국 데이터베이스 변환 계획은 포기했다.
C사는 국내 서비스를 해외 서비스로 확장하기 위해서 해외 버전을 별도로 개발했다. S사와 마찬가지로 별도 개발하는 것이 더 빨리 개발할 수 있는 상황이었다.
문제는 해외 서비스 오픈 후에 발생했다. 이중으로 작업을 하다가 팀을 나눠서 각각의 서비스를 따로 개발하기 시작했다. 개발은 점점 비효율적으로 변해갔다. 그러느라고 해외 서비스는 제대로 개발도 못하는 상황이 벌어졌다.
A사는 나름대로 연구를 해서 국제화 기능을 구현했다. 각 언어의 메시지를 데이터베이스에 넣어 관리를 하는 방식으로 구현했다. 개발자는 코딩을 하다가 메뉴 등 메시지를 하나 추가하려면 많은 일을 해야해서 부담스럽다.
메시지를 추가하려면 먼저 엑셀에 해당 메시지를 추가해야 하는데 다른 개발자가 동시 수정하면 충돌이 일어나는 일이 자주 발생했다. 그래서 메시지 관리 담당자를 따로 정해서 관리했다. 그러다보니 관리부담만 늘고 개발자들은 매번 담당자에게 요청하느라 매우 불편해졌다.
국가별 날짜포맷도 연구해서 직접 개발을 했다. 국제화에 많은 노력을 투자했음에도 A사는 해외 고객들로부터 계속 수많은 국제화 관련 버그를 보고 받고 있다.
I사도 국제화에 많은 노력을 기울였다. E사 제품은 한국어의 특징을 살려서 제품 유저인터페이스(UI)가 상당히 조밀하다. 한국어는 단어 길이가 짧은 것들이 많다보니 메뉴, 옵션 화면 등을 상당히 빽빽하게 구성됐다.
이런 화면을 영어, 독일어로 변환하다 보니 언어별로 메시지 길이가 천차만별이라서 화면 구성에 애를 먹었다. 결국에 화면을 언어별로 다르게 디자인했는데 그렇게 개발한 후로 개발할 때마다 언어별 화면을 튜닝 하느라고 많은 비용이 들어가고 있다.
N사는 언어별로 번역을 해서 소프트웨어를 여러 나라에 팔고 있다. 그런데 번역이 잘못되었다는 버그를 많이 보고 받았다. “A의 B”를 변역 해야 했고 A와 B는 다른 단어로 대체 가능한 문장이었다.
그런데 영어로 번역을 하니 “A of B”처럼 어순이 뒤바뀌어 의미가 달라져 버렸다. 그리고 “사과 2개”를 영어로 번역을 하니 “2 apple”과 같이 복수 처리가 안되었다. 복수 지원을 위해서 복수 메시지 함수를 만들었는데 언어마다 단수, 복수 체계가 다르다는 것을 몰랐다. 지금도 구조적인 번역 오류에 대한 보고는 계속 되고 있다.
이렇게 여러 실패 사례를 알아 봤는데, 안타까운 것은 지금도 소프트웨어 국제화의 필요성을 인식 못하고 이와 같은 일들이 계속 벌어지고 있다. 해외에 소프트웨어를 팔 계획을 가지고 있고 영원히 영어만 지원하는 소프트웨어를 만들 것이 아니라면 국제화 전문가의 도움을 받아야 한다.
회사 내부에서 1, 2년만에 전문가를 키우기도 쉽지 않다. 소프트웨어마다 필요한 국제화 수준이 다르기는 하지만 지금처럼 소프트웨어 국제화를 쉽게 생각하다가는 좋은 소프트웨어가 국경과 문화의 장벽에 막혀서 실패하는 일은 계속 될 것이다.
글로벌 소프트웨어를 개발하는 있어서 소프트웨어 국제화는 선택이 아닌 필수요소임을 알아야 한다.
이글은 ZDNet Korea에 기고한 칼럼입니다.
