태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

외국에 출시한 소프트웨어가 날짜 때문에 낭패 본 사연 (4)

2015.05.26 14:10 by 전규현


잠시 후 Google blogger로 이동됩니다.





10년차 개발자인 김과장(가상의 인물)은 최근에 소프트웨어를 영어를 지원하도록 만들었다. 어플리케이션에서 표시되는 모든 메시지(메뉴, 버튼, 다이얼로그 등)를 영어로 번역했다. 그렇게 해서 영어버전을 출시했는데 얼마 안 가서 버그가 보고 되었다.


날짜를 2015/05/15 이렇게 표시를 했는데 미국에서는 05/15/2015로 표기해 달라는 것이다.


김과장은 소스코드를 다음과 같이 수정해서 버그를 해결했다.


if (locale == “en_US”)

     date_format = “mm/dd/yyyy”;

else

     date_format = “yyyy/mm/dd”;


물론 의사코드(pseudocode)이므로 정확한 소스코드는 아니다. 예를 든 것뿐이다. 


그런데 얼마 안 있어서 호주에서는 15/05/2015로 표기를 해달라고 하는 것이다. 기존의 표기는 헷갈린다고 한다. 이렇게 하나씩 고치다 보니 날짜뿐만 아니라 여러 가지 분야에서 끝도 없는 수정이 계속 되었다. 문제는 이렇게 고쳐달라고 요청하는 사용자보다 틀린 것을 참고 쓰거나 아예 포기를 해버리는 사용도 많을 텐데 파악이 안 된다는 것이다.


김과장은 로케일만 알았지 로케일이 시스템에 무엇을 바꾸는지는 잘 몰랐던 것이다. 김과장은 로케일을 제대로 이해하고 있었다면 이렇게 김과장이 직접 로케일의 변화에 따른 프로그래밍을 직접 할 필요가 없었다. 그냥 시스템에서 제공하는 함수를 쓰면 되는 것이었다. 물론 OS나 개발 라이브러리에 따라서 사용법은 조금씩 다르다.




로케일은 시스템의 무엇을 바꿀 수 있을까? 이렇게 로케일이 시스템에 미치는 영향을 6가지로 구분하여서 이를 로케일 카테고리라고 한다.


로케일 카테고리의 약자인 “LC”를 앞에 붙여서 LC_TIME, LC_NUMERIC, LC_MONETARY, LC_COLLATE, LC_CTYPE, LC_MESSAGES 이렇게 6가지가 정의되어 있다. 대부분의 OS와 개발 라이브러리에서 이를 지원하고 있다.


사용법은 setlocale(로케일 카테고리, 로케일) 이다. 즉, setlocale(LC_TIME, “de_DE”) 이렇게 하면 날짜와 시간을 독일 식으로 표현하라는 얘기다. 이렇게 6개를 모두 설정하려면 귀찮기 때문에 LC_ALL이라는 것을 둬서 setlocale(LC_ALL, “de_DE”)이라고 하면 한번에 6개의 카테고리가 모두 독일식으로 설정된다. 


그럼 하나씩 알아보자.


LC_TIME 시간과 날짜의 표현에 대한 설정이다. 김과장이 이 카테고리만 설정하고 이와 관련된 함수만 사용했어도 위에서와 같은 고생은 안 해도 됐다. LC_TIME이 영향을 미치는 함수는 개발 라이브러리에 따라서 다르다. GNU C 라이브러리인 경우에는 strftime(), strptime()이다. PHP나 Python도 strftime()을 지원한다. LC_TIME를 세팅하면 로케일 별로 다른 시간과 날짜가 표시된다.


LC_NUMERIC 숫자 표현을 위한 설정이다. 나라마다 숫자 표현이 크게 다르다는 것을 모르는 개발자도 상당히 많다. 우리는 소수점으로 점(.)을 쓰는 것을 당연하게 생각하지만 그렇지 않은 나라도 매우 많다. 우리가 이렇게 로케일별로 다른 표현을 다 연구할 필요는 없다. LC_NUMERIC이 영향을 미치는 함수를 쓰기만 하면 된다. strtod(), atof()가 그 예이고 sprintf(), printf() 함수도 영향을 받는다. 자세한 것은 나중에 다루겠다.


LC_MONETARY 화폐, 금액을 다루기 위한 설정이다. 영향을 받는 함수는 strfmon()이 있다. 최근에는 유로화를 지원하기 시작하면서 좀 복잡해졌다. 라이브러리 별로 지원하는 것이 조금씩 다르기도 하다.




LC_COLLATE 정렬에 관한 것인데 조금 복잡하다. 정확하게 이해하려면 사전에 어떠한 순서로 정렬이 되는 것이 자연스러운지 생각해보면 된다. 영어에는 대소문자에 대한 정렬 방법이 일반 ASCII 정렬방법과는 약간 다르고 한국어에도 ‘ㄱ’이 어느 위치에 정렬되어야 하는지는 EUC-KR 코드의 순서와는 약간 다르다. ASCII 순서에 따르면A, B, a, b 이렇게 되지만 사전에서는 a, A, b, B이기 때문이다. 물론로케일별로 다르다. Collation이라는 용어는 나중에 Database 설정에도 나오기 때문에 잘 알아두는 것이 좋다. LC_COLLATE가 영향을 미치는 함수는 strcoll(), wcscoll() 등이 있다. 즉, 이런 함수를 이용해서 정렬 함수를 만들어야 각 로케일에 맞는 정렬이 된다.


LC_CTYPE 문자의 종류를 다루기 위한 설정이다. 문자인가 숫자인가, 대소문자 구분을 다룬다. strlen(), stricmp(), strlwr(), strupr() 등의 함수가 영향을 받는다.


LC_MESSAGES 로케일 별로 번역된 메시지를 표현하기 위한 설정이다. catopen(), gettext() 등이 영향을 받는데, 메시징은 국제화에서 별도로 다뤄야 할 만큼 중요하기 때문에 추후 여러 회에 걸쳐서 다뤄질 것이다.


이렇게 거의 모든 OS와 개발라이브러리에서 다루는 6가지 로케일 카테고리 외에도 LC_ADDRESS, LC_NAME, LC_PAPER, LC_TELEPHONE 등을 사용하는 곳도 있다.


우리는 로케일을 지정함으로써 로케일별로 다른 표현 및 기능이 자동으로 바뀌도록 개발을 해야 한다. 소스코드에 if (locale == "de_DE") 등과 같은 표현이 절대로 있어서는 안된다. if (lang == "english")는 더더욱 안된다.


이미지 by Kolmisoft

저작자 표시 비영리 변경 금지
신고

전규현 프로젝트/국제화 i18n, L10n, 국제화

독일어 버전 소프트웨어란 말이 잘못된 이유 (3)

2015.05.19 01:00 by 전규현


잠시 후 Google blogger로 이동됩니다.





본 시리즈는 차례대로 읽으면 소프트웨어 국제화가 전체적으로 이해가 되어서 소프트웨어 개발자에게 도움이 되는 방향으로 진행하려고 하고 있다. 개발자마다 지식과 경험이 천차만별이라서 초급 개발자를 기준으로 작성하고 있다.


경영자가 개발자에게 독일어 버전을 만들라고 하면 어떨까? 대부분은 콩떡 같이 말하면 찰떡같이 알아듣겠지만 엄밀히 말하면 틀린 얘기다. 정확한 표현이 아니라고 하는 것이 낫겠다.


우리는 우연히 한 국가에서 하나의 언어만 쓰고 있다. 공식 언어가 존재한다. 하지만 미국만 하더라도 공식 언어가 존재하지 않는다. 누구나 미국의 공식 언어는 영어라고 생각하지만 관습 헌법 같은 것일 뿐이다. 그나마 미국은 영어가 대표적인 언어다. 하지만 바로 위의 캐나다로 가면 영어와 프랑스어를 쓰고 있으며 어느 한 언어를 무시할 수 없다.


스위스로 가면 독일어, 프랑스어, 이탈리아어, 로만슈어의 네 가지 언어가 공용 언어다.  이렇게 한 나라에서 여러 가지 언어를 쓰는 경우는 매우 많다. 오히려 한 가지 언어만 쓰는 나라가 더 적다.


반대로 언어의 관점으로 보면 하나의 언어가 매우 많은 나라에서 쓰인다. 독일에서 쓰는 표준 독일어와 스위스에서 쓰는 독일어는 조금 다르다. 독일 사람들은 스위스 사람들이 말하는 독일어를 이해하지 못하곤 한다. 스페인어도 매우 많은 나라에서 쓰인다. 스페인을 비롯해서, 멕시코, 칠레, 미국 등 국가에서 사용된다. 


그럼 독일어 버전을 만들라고 하면 표준 독일어를 말하는 것일까? 오스트리아, 스위스, 룩셈부르크 어느 나라의 독일어를 지원하라는 얘기일까? 대충 다 알아보지 않을까?라고 생각하는 것은 안일한 생각이다. 각 나라 별로 같은 언어라고 하더라도 쓰는 방법이 다 다르다.


그래서 소프트웨어 국제화에서는 언어와 국가, 정확하게 말하면 지역을 조합해서 부른다. 이것을 로케일(Locale)이라고 한다. 그래서 앞으로 소프트웨어 국제화를 얘기할 때는 언어나 국가로 얘기하지 않고 로케일을 기준으로 얘기를 해야 한다.


로케일의 컨셉은 거의 모든 OS와 개발 언어에 포함되어 있다. 


로케일의 표기 방법은 다음과 같다. 


[language[_territory][.codeset]]


language는 언어를 나타내며 알파벳 소문자 두 글자로 이루어져 있다. 한국어는 “ko”, 일본어는 “ja”, 영어는 “en”, 독일어는 “de”라고 표기한다. ISO639에 표준이 정의 되어 있다.


territory는 지역을 의미하며 알파벳 대문자 두 글자를 사용하며 생략하기도 한다. 한국은 “KR”, 일본은 “JP”, 미국은 “US”, 독일은 “DE”를 사용한다. ISO3166에 표준이 정의 되어 있다.


codeset은 어떠한 코드셋을 사용했는지 나타내는 것으로 생략할 수 있다. 한국어인 경우 “UTF-8” 또는 “euc-kr”을 사용한다.


그래서 한국어는 ko_KR이라는 로케일을 사용하게 된다.


독일어 하나만 해도 de_DE(독일), de_AT(오스트리아), de_LU(룩셈부르크), de_CH (스위스) 이렇게 여러 가지 로케일로 표한 할 수 있다. 


이렇게 해서 탄생할 수 있는 로케일의 개수는 수백 개가 넘지만 개발 언어의 라이브러리 별로 지원하는 범위가 조금씩 다르다. 하지만 우리가 흔히 지원하려고 하는 로케일은 거의 포함이 되어 있으므로 걱정할 필요는 없다.


이외에 “C” 로케일이라는 것이 있다. 이것은 GNU C에서 사용되는 것으로서 로케일을 지정하지 않으면 지정되는 디폴트 로케일로서 “POSIX”로케일이라고도 한다.


어플리케이션에서 로케일을 지정하는 방법은 setlocale() 이라는 함수를 쓰거나 환경 변수를 바꾸는 함수를 사용하는 것이다. OS나 개발 언어에 따라서 조금씩 다르다. 


로케일이 바뀌면 무엇이 바뀌는지는 다음 연재글에서 알아보자.


저작자 표시 비영리 변경 금지
신고

전규현 프로젝트/국제화 i18n, L10n, locale, 국제화

소프트웨어를 외국에 출시 하면서 흔히 빠지는 함정 (2)

2015.05.12 01:00 by 전규현


잠시 후 Google blogger로 이동됩니다.





우리나라 소프트웨어 중에서 외국에서 크게 성공했다고 하는 소프트웨어가 있는가? 온라인 게임을 제외하고는 거의 없다. 사실 게임은 국제화, 지역화를 잘 못하더라도 큰 흉이 안 된다. 하지만 그 외의 많은 소프트웨어들은 제품이든 서비스든 국제화, 지역화에 실패하여 해외 시장에서 실패하는 경우가 매우 많다. 그럼 소프트웨어 회사들, 개발자들이 흔히 하는 실수에는 어떤 것이 있는지 알아보자. 실수를 알아보는 것은 같은 실수를 하지 않도록 교훈을 준다.


먼저 소프트웨어 국제화, 지역화를 하는데 있어서 기술적인 목표를 알아보자. 비즈니스적인 목표는 개발자들이 크게 상관할 바는 아니지만 기술적인 목표는 잘 알아야 흔들림 없이 개발을 할 수 있다.


첫 번째 목표는 국제화, 지역화 품질이다. 해당 지역, 국가에서 받아들여 질만해야 한다. 어색한 번역 외에도 날짜, 숫자, 화폐, 단수/복수, 어순, 쓰기 방향, 키보드배치, 폰트, 띄어쓰기 여부, 쉼표, 온도, 문장정렬, 이름, 주소, 색깔의 의미, 섬머타임, 종이 크기 등 지역, 언어별로 신경을 써야 한다. 소프트웨어마다 신경을 써야 하는 범위가 다르고 나라마다 받아들이는 정도도 다르다. 첫술에 이 모든 것을 다 처리하기는 어렵고 앞으로 중요한 순서대로 자세히 알아보려고 한다.


두 번째 목표는 생산성이다. 국제화, 지역화를 위해서 너무 많은 시간과 비용이 들어간다거나 이를 유지하기 위해서 많은 부담이 되면 실패다. 특히, 번역은 소프트웨어가 업그레이드 될 때마다 계속 변하는데 번거로운 수동 프로세스로 진행을 하면 비용도 많이 들뿐더러 실수로 인한 버그가 발생하게 된다. 또한 국제화, 지역화 아키텍처를 잘못 만들면 돌이킬 수 없는 비효율의 구렁텅이로 빠지게 된다. 아키텍처와 프로세스에 대해서도 앞으로 다루겠다.


그럼 많은 소프트웨어 회사들이 흔히 빠지는 실수는 어떤 것이 있나 알아보자. 우리는 이런 함정을 피해 다녀야 한다.


첫째, 일단 한국어 버전을 먼저 만들고 나중에 국제화, 지역화를 적용한다.


의도했던 의도하지 않았던 이런 회사는 매우 많다. 혼자서 만드는 아주 작은 소프트웨어라면 어떻게 해도 다 되지만 중간 규모 이상의 소프트웨어를 나중에 국제화하는 것은 다 지어서 아파트에 주민들이 살고 있는 상황에서 리모델링을 하는 격이다. 제대로 국제화가 되지도 않고 비용도 10배 이상 많이 들어간다.


둘째, 번역이 전부인줄 알고 번역만 한다.


경영자들은 아주 쉽게 개발자에게 “영어 버전 만들어”, “독일어 버전 만들어” 이렇게 얘기를 한다. 물론 이 말은 정확한 표현도 아니다. 이 시리즈를 계속 읽다 보면 왜 이렇게 말하면 안 되는지 알게 된다. 번역은 소프트웨어 국제화 시 고려해야 할 200가지 중에서 한가지일 뿐이다. 200가지 전부를 완벽하게 지원하는 것은 어떠한 소프트웨어라도 불가능하지만 그중 몇 가지는 꼭 신경을 써야 한다.


셋째, 해외 버전을 별도로 만드는 것이다.


현재 한국어버전 소프트웨어 밖에 없는 경영자가 어느 날 갑자기 “한달 안에 일본어 버전을 만들어”라고 강요를 하면 개발자들이 흔히 하는 선택은 소스코드를 그대로 복사해서 소스코드의 한국어 부분을 전부 일본어로 바꾸는 것이다. 이 방법은 가장 빠른 방법이지만 가장 느리다. 첫 버전은 가장 빠르지만 점점 느려진다. 소스코드를 수정할 때마다 두 소스코드를 모두 고쳐야 한다. 이 와중에 “독일어 버전도 만들어”라고 하면 개발자는 앞이 캄캄해진다. 첫번째 소스코드가 복사된 순간 “지옥문”을 연 것이다. 무식한 경영진을 탓해야 하지만 그렇다고 소스코드를 복사한 개발자도 똑 같은 책임이 있다.


이런 실수는 거대기업을 무너뜨리는 결과를 낳기도 한다.


넷째, 국제화, 지역화 기능을 모두 직접 구현하는 것이다.


이는 자동차를 만들라고 했더니 타이어도 직접 제작하고 유리를 녹여서 유리창도 만들고 에어백도 직접 생산하는 꼴이다. 자동차를 제대로 만드는 방법은 설계를 잘하고 핵심 부품만 우리가 만들고 수많은 부품은 사다가 조립하고 것이다. 그런데 많은 개발자들은 그런 부품이 시장에 있는지도 모르고 직접 만들곤 한다. 물론 엉터리다. 수십 년간 진화해온 전문 부품을 개발자가 며칠 동안 흉내 낼 수 있겠는가? 특히 메시지 번역관련 라이브러리는 많이들 직접 만들어 쓰는데 필자가 수십 가지 사례를 봐왔지만 제대로 만들어서 쓰고 있는 사례는 0 건이었다. 그 외에도 날짜함수, 숫자함수를 직접 만들어서 낑낑대며 고생하는 개발자들도 많이 봐왔다. 국제화, 지역화 기능은 표준이 있으며 직접 구현해야 하는 것도 있지만 상당수는 라이브러리를 이용하거나 OS에 이미 포함된 기능을 써야 한다.


다섯째, 한국어 코드체계를 기반으로 개발을 한다.


한국어 버전을 먼저 만든 경우 흔히 저지르는 실수인데 한국어 인코딩인 “EUC-KR”로 DB나 파일을 저장할 경우 중국어, 일본어나 다른 언어를 저장하려고 할 경우 글자들이 깨지게 된다. 영어까지는 저장하는데 문제가 없어서 무신경하게 지나가곤 한다. “EUC-KR”은 전세계 모든 글자를 담을 수가 없다. 제품이든 서비스든 일단 “EUC-KR”기반으로 소프트웨어를 개발하면 나중에 유니코드 기반으로 소프트웨어를 변경하기는 매우 어렵다. 데이터를 변환해야 하며 모든 기능을 다시 다 테스트 해야 한다. 엄두가 나지 않는 일인 경우가 많다.


여섯째, 우리의 기준으로 외국을 이해하는 것이다.


우리나라가 이러하니 다른 나라도 이럴 것이다라고 착각을 하는 경우다. 우리가 “.”을 소수점으로 사용하니 다른 나라도 그럴 것이다. 단어 사이에는 띄어쓰기를 할 것이다. 종이는 다 A4용지를 사용할 것이다. 하지만 전세계에는 수많은 다른 문화가 있다. 물론 완벽하게 이 모든 문화를 지원할 수는 없지만 일단 다르다는 의심을 가지고 시작해야 한다. 그 중에서 중요한 것들은 지원을 해야 한다.





그럼 어떻게 해야 할까? 반대로 하면 된다. 처음부터 국제화, 지역화 전략을 가지고 아키텍처를 구성해야 하며 하나의 소스코드를 유지해야 하고 잘 개발된 표준과 라이브러리를 이용해서 유니코드를 기반으로 만들어야 한다. 


혹시 경영자가 당장 외국 버전을 턱도 없이 짧은 시간 내에 만들어 내라고 한다면 “그 시간 안에는 안됩니다. 아키텍처를 제대로 구성해서 제대로 만들려면 시간이 더 필요합니다.”라고 주장할 용기가 있어야한다. 이런 것이 씨도 안 먹히는 조직문화를 가진 회사도 많지만 이는 경영자가 시켰다고 6개월 후면 무너질 것을 알면서도 다리를 만드는 것도 같다. 누구의 책임이 더 클까? 생각해볼 문제다. 모든 것을 경영자 등 외부의 탓으로 돌리는 것은 경계해야 할 자세다.


필자는 수십개의 회사를 직접적으로 또 간접적으로는 더 많은 회사의 상황을 직접 봐왔고 이런 어설픈 국제화 적용으로 망해가는 회사를 봐왔기 때문에 이 시리즈를 시작하게 된 것이다. 나는 지식과 정보, 경험, 노하우을 전하겠지만 이것이 얼마나 도움이 될지는 독자의 몫이다.


이 글은 네이버포스트에 게재한 글입니다.


저작자 표시 비영리 변경 금지
신고

전규현 프로젝트/국제화 i18n, L10n, 국제화

외국에서 팔리는 소프트웨어 만들기 위한 소프트웨어 국제화 (1)

2015.05.05 01:00 by 전규현


잠시 후 Google blogger로 이동됩니다.





가장 먼저 소프트웨어 국제화에 대한 이야기로 글을 시작하려고 한다.


오래 전부터 소프트웨어 세계에는 국경이 없었다. 거의 모든 사람들은 수십 나라에서 개발된 다국적 소프트웨어를 사용하고 있다. 앱을 하나 개발해서 앱스토어에 올리면 바로 다음날부터 전세계 수십, 수백 나라에서 즉시 사용된다.


이제 소프트웨어 국제화는 소프트웨어 개발자라면 필수적으로 알아야 할 지식이다. 소프트웨어 국제화 전문가가 되기 위해서는 십 수년의 공부와 경험이 필요하지만 최소한의 기본 지식은 갖추도록 하자.


기본적으로 영어권 개발자들이 만든 소프트웨어는 국제화에 대해서 별로 신경을 안 써도 큰 문제 없이 전세계에서 사용되는 경우가 많다. 우리도 영어만 지원하는 소프트웨어를 얼마나 많이 써왔던가? 비단 메시지만 영어로 나오는 것뿐만 아니라 날짜 표기, 이름 표기 등도 우리 문화와는 다르지만 소프트웨어를 사용하는 데는 큰 문제가 없다. 물론 한국어 폰트가 깨지는 등 문제가 있는 경우도 많지만 개발자들은 이런 것은 신경도 안 쓰는 경우가 많다. 우리는 소수 사용자이기 때문이다.


하지만 비 영어권 개발자들이 만든 소프트웨어는 상황이 전혀 다르다. 기본적으로 우리 문화에 맞춰서 개발한 소프트웨어는 영어권뿐만 아니라 우리나라를 제외한 대부분의 나라에서 거부감을 갖게 된다. 그만큼 우리나라 개발자들이 만든 소프트웨어가 전세계로 확산되기는 쉽지 않다. 그러다 보면 전세계 1% 시장이라는 우리나라 소프트웨어 시장만을 대상으로 소프트웨어를 만들게 된다.


100배 큰 시장으로 나가기 위해서는 소프트웨어 국제화를 잘 알아야 한다.


일단 용어부터 알아보자.


첫 번째 용어는 국제화, 영어로는 Internationalization이다. 이 용어는 1985년에 Apple에서 사용하기 시작하였다. 오랫동안 이렇게 긴 영어 단어로 사용되다가 유니코드 컨소시엄에서 i18n이라는 줄임말을 사용하기 시작했다. 사실 정확하게 누가 먼저 사용했는지는 알기 어렵다. "인터네셔널라이제이션"이라는 긴 단어를 발음하다보면 혀가 꼬이기 일쑤다. 그래서 i와 n 사이에 18글자의 알파벳이 있다는 의미로 i18n을 사용하기 시작했다.


i18n은 소프트웨어를 여러 나라 언어와 문화를 지원하기 쉬운 구조로 만드는 것이다. 국제화가 잘된 소프트웨어는 쉽게 여러 나라 언어를 지원할 수 있다. i를 소문자로 쓰는 이유는 대문자로 쓸 경우 L의 소문자와 헷갈리기 때문이다.

 

두 번째 용어는 지역화, 영어로는 Localization이다. 이 또한 줄여서 L10n이라고 한다. L를 흔히 대문자로 쓰는 이유도 역시 헷갈리지 않게 하기 위함이다. 


L10n은 소프트웨어를 특정 지역의 언어와 문화를 지원하도록 만드는 것이다. 예를 들면 중국어나 일본어를 지원하는 것이다.




전세계 개발자와 회사들은 1980년대부터 본격적으로 소프트웨어 국제화와 지역화에 대해서 연구를 해왔고 그 결과 1991년 유니코드가 탄생을 하였고 수많은 표준이 제정되었다. 그 지식과 정보는 너무나 방대해서 어느 개발자도 모두 알기는 어렵다. 따라서 앞으로 이 중에서 소프트웨어 개발자가 알아야 할 필수적인 내용을 연재하겠다.


이 글인 네이버포스트에 게재한 글입니다.

저작자 표시 비영리 변경 금지
신고

전규현 프로젝트/국제화 i18n, L10n, 소프트웨어국제화

한국 SW가 해외에서 힘 못쓰는 이유

2014.02.18 23:16 by 전규현


잠시 후 Google blogger로 이동됩니다.





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에 기고한 칼럼입니다.

저작자 표시 비영리 변경 금지
신고

전규현 소프트웨어이야기 i18n, L10n, 국제화, 지역화

  1. Blog Icon

    비밀댓글입니다

해외에 소프트웨어를 팔려면 이것이 꼭 필요하다.

2010.12.14 18:42 by 전규현


잠시 후 Google blogger로 이동됩니다.





연초에 소프트웨어의 국제화와 지역화를 언급하면서 조만간 이에 대한 글을 올리겠다고 했는데, 벌써 10개월이 지났네요.
2010/02/11 - [소프트웨어이야기] - 애플은 한국어와 한글을 구분하지 못한다?

그래서 간단하게 정리를 해보려고 합니다.

일단 다음의 기본 용어는 알아두는 것이 좋습니다.
 i18n(internationalization) - 국제화를 말하며 i와 n사이에 18개의 알파벳이 있어서 i18n으로 줄여말합니다. 소프트웨어가 여러 언어(locale)를 지원하기 용이한 형태로 만드는 것을 말합니다. i가 소문자인 이유는 알파벳엘(l) 또는 숫자일(1)과 혼동되기 때문입니다.

 L10n(localization) - 지역화를 말하며 l과 n사이에 10개의 알파벳이 있어서 L10n으로 줄여말합니다. 소프트웨어를 해당 지역에서 사용할 수 있도록 메시지나 기능을 해당지역에 맞춰주는 것을 말합니다.

Locale - 지역화의 단위입니다. 한국어를 공식적으로 쓰는 나라는 우리나라밖에 없어서 (북한예외) Locale과 나라를 동일시하기도 하는데 영어만 아더라도 여러나라에서 쓰고 캐나다에서는 영어와 프랑스어를 모두 쓰게 됩니다. 따라서 Locale에는 언어 정보와 지역정보가 같이 포함되어 있습니다. 제 글에서는 국가와 혼영해서 사용했으니 알아서 이해하세요.

최근의 소프트웨어들을 보면 국경은 의미가 없어진지 오래입니다. 특히 스마트폰이 폭발적으로 보급되면서 개발자들과 세계 각국의 사용자들은 더욱 가까워졌습니다.

그래서 지역화된 소프트웨어가 더욱 절실해졌습니다. 그런데 우리나라 상황을 보면 아직도 많은 소프트웨어들이 국제화와 지역화에 관심을 기울이지 않고 있습니다. 그러다보니 국내에서 성공한 제품들을 들고 해외에 진출을 하다가 국제화와 지역화의 어려움에 막혀서 좌절하곤 합니다.

 국제화, 지역화 방법은 표준을 따라야 합니다.

국제화와 지역화에대한 소프트웨어 개발의 표준(De facto)이 정립된지는 매우 오래되었지만, 국내에서는 별로 관심을 받지 못하는 것이 사실입니다. 그렇게 어렵지 않은 기술임에도 관심들이 별로 없고 관심이 있다고 하더라도 흩어져 있는 정보를 모두 모아서 하나의 그림으로 보기 어려운 상황입니다. 어렵지는 않다고 했지만 매우 복잡하기 때문에 처음에 이해하기란 쉽지 않습니다.

대부분의 소프트웨어 회사들은 국제화와 지역화 과정에서 표준적인 방법을 따르지 않고 스스로 연구한 방법을 사용하다가 큰 낭패를 보게 됩니다. 왜냐하면 국제화와 지역화에 대한 방대한 지식을 소수의 개발자가 연구해서 체계화 하기란 불가능합니다. 전세계 수백명의 개발자들이 십수년간 모여서 완성한 것을 우습게 보면 안됩니다.

그래서 스스로의 방법은 대부분 실패하게 됩니다. 

 초기부터 국제화와 지역화를 고려해야 합니다.

소프트웨어 개발 초기부터 국제화와 지역화를 신경쓰지 않다가 제품을 다 완성한 후에 나중에 반영을 하게 되면 또 엄청난 비용이 들고 그 방법이 잘못되었다면 비용을 많이 들이고도 또 실패합니다.

소프트웨어가 다른 언어를 지원해야 할 가능성이 단 1%라도 있다면 저는 국제화와 지역화를 적용하여 소프트웨어를 개발합니다. 초기부터 적용하는 것은 비용이 추가로 거의 들지 않기 때문입니다.

 소프트웨어는 하나로 만들어야 합니다.

여러개로 지역화된 소프트웨어 별로 Master가 별도로 존재한다면 이를 관리하는데 또 엄청난 비용을 지불해야 합니다. 표준적인 방법들은 대부분은 하나의 소프트웨어에서 여러개의 언어(locale)을 지원할 수 있도록 미리 준비되어 있습니다.

Locale별로 여러벌의 소프트웨어가 존재한다면 이를 관리하는 비용은 기하급수로 증가하여 혼돈의 상태를 경험하게 됩니다. 이 과정에서 수많은 오류가 발생하고 해외 진출 실패의 주요 원인이 되곤 합니다.

 메시지 번역이 지역화의 전부가 아닙니다.

흔히들 우리나라에서 성공한 제품을 가지고 해외에 진출한다고 영어버전을 만들고 일본어, 중국어 버전을 만들곤 합니다. 이때 그냥 메시지만 번역을 해서 지역화된 제품이라고 생각하곤 합니다. 하지만 이런 제품을 해외에 가지고 나갔다가는 낭패를 보기 일쑤입니다. 외국과 우리나라가 그렇게 비슷하다고 생각하면 착각입니다.

숫자만하더라도 우리나라에서는 1,234.56이라고 쓰는 것을 독일에서는 1.234,56이라고 씁니다. 즉 콤마와 소숫점을 반대로 사용합니다. 

이런식으로 언어(locale)이 고려해야 할 것은 메시지외에도 Collate, Ctype, Monetary, Numeric, Time이 있습니다. 이것들은 표준적으로 정해 놓은 것이고 비표준적인 요소는 이보다 훨씬 많습니다. 비표준적인 요소들은 제품마다 별도로 분석해야 합니다.

 메시지도 단순히 번역하는 것이 다가 아닙니다.

간단한 예로 나라마다 어순이 다르고 단수, 복수의 표현이 다릅니다.

우리나라에는 단수, 복수에 따른 차이가 거의 없지만, 영어에는 복수가 있지요. 하지만 폴란드어는 1개일때 2~4개일때, 5개 이상일 때 서로 표현이 다릅니다. 게다가 12~14개로 넘어가면 또 반복이 됩니다.

이렇듯 거의 모든 요소에서 다른 나라에서는 과연 이대로 쓰는지 의심을 해봐야 합니다. 경험도 많이 필요합니다. 그러면서 자연스럽게 문장의 표현 방법도 글로벌하게 문제가 없는 방법을 사용하게 됩니다.

또한, 번역을 했을 때 문장의 길이가 천차만별이기 때문에 UI 디자인시 문장의 길이를 충분히 길다고 생각하고 디자인을 해야 합니다.

이러한 모든 것이 습관이 되어 있다면 간단한 일이지만 초기에는 매우 귀찮은 일이 됩니다.

 유니코드는 기본입니다.

지역화된 소프트웨어를 개발하다보면 항상 부딪히는 것이 문자코드의 충돌입니다.
유니코드를 사용하지 않아도 지역화된 소프트웨어를 개발할 수 없는 것은 아니지만, 여러 군데에서 매우 귀찮은 일이 발생하게 됩니다.
따라서 유니코드를 기본으로 생각하면 복잡한 문제들이 대부분 해소가 됩니다.
기존에 ANSI 프로그램만 작성을 하다가 유니코드 프로그램을 작성하는 것이 낯설고 어려울 수 있지만 이 또한 적응이 되고 나면 그렇게 어려운 일도 아닙니다.

단, 유니코드 및 문자셋, 코드셋, 인코딩 등 복잡한 컨셉을 모두 제대로 이해하는 것은 보통 어려운 일이 아닙니다. 그렇지 않다면 개발을 하다가도 "어찌어찌 하니 우연히 되더라"하는 식의 개발이 되기도 합니다.

유니코드가 적용된 지역화된 소프트웨어를 개발하려면 갖춰야할 기본 지식이 매우 많습니다.

 꾸준히 유지보수 할 수 있는 프로세스를 만들어야 합니다.

지역화된 소프트웨어를 만들때 흔히 발생하는 문제점이 처음에 한번 개발은 어떻게든 해 냈는데, 유지보수 단계에서 상당히 곤란한 상황에 처한다는 겁니다. 한국어를 포함해서 영어, 중국어, 일본어 그러고 여러 언어를 지원하다보면 패치를 만들어가 업그레이드를 할 때 매번 새로 추가된 메시지와 삭제, 변경된 메시지를 추려서 각각의 언어로 번역을 하고 제품에 반영해서 또 테스트를 해야 하는데 그게 잘 안되고 뒤죽박죽되기 일쑤입니다. 툭하면 어떤 언어에서는 메시지가 제대로 안나오곤 합니다.
지역화 프로세스는 번역과정을 빼고는 모두 자동화를 해서 추가로 비용이 들지 않아야 합니다.

각 개발자나 회사에서 스스로 만든 지역화 방법을 사용하면 좋지 않은 결정적인 이유가 유지보수 입니다. 대부분의 개인들이 만든 지역화 방법은 유지보수까지 완벽하게 반영하지 못한 것이 대부분이기 때문입니다.

 결론

필자는 무슨 소프트웨어를 만들지간에 국제화는 무조건 생각합니다. 이미 알고 있는 마당에서 비용이 추가로 들것도 별로 없습니다.
하지만, 초기에 국제화를 생각하지 않고 나중에 영업이 잘되서 해외 진출을 한번 해보려고 하면 국제화와 지역화는 큰 걸림돌이 될 겁니다. 
이 또한 알면 무지 쉬운데 모르면 한없이 어려운 분야 중 하나입니다.
"유비무환". 미리미리 준비해서 언제든지 글로벌 소프트웨어 회사들과 경쟁할 준비를 해놓읍시다.

이번 글에는 소프트에어의 국제화와 지역화의 필요성과 개념만 정리를 했는데, 그 구체적인 방법은 너무 광범위 해서 블로그 글로 모두 적기는 어려울 것 같습니다. 하지만 기회가 되면 한가지씩 올려 볼 수는 있을 것 같습니다.

혹시 소프트웨어의 국제화와 지역화가 필요하기는 한데 어려움을 겪고 있거나 이미 스스로 방법을 만들어서 쓴맛을 본 분들이 있으면 연락해주세요. 도움이 되어 드리면 좋겠습니다. :)

 * 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
image by chrys
저작자 표시 비영리 변경 금지
신고

전규현 프로젝트/국제화 i18n, L10n, 국제화, 지역화

  1. Blog Icon
    정도유

    더 중요한 것은 timezone 설정입니다.

  2. 안녕하세요. 정도유님
    Time zone은 이미 OS에서 설정이 되고 있고 이를 이용할 수 있습니다.
    제품에서 별도의 time zone을 설정할 필요가 있다면 기능이 필요하곘네요. 또한 섬머타임도 고려를 해야 하고요.
    그리고 소프트웨어의 성격에 따라서 시간의 저장은 Local time이 아닌 절대 시간으로 기록을 하고 필요에 따라서 Local time의 변환해서 보여기도 합니다.

  3. Blog Icon
    김영규

    UI도 중요한 부분이라고 생각됩니다.
    UI에 표시되는 텍스트만 보더라도 각 언어마다 텍스트 길이나 배치가 달라져 제대로 확인하지 않으면 UI가 제대로 표시되지 않으니깐요.

  4. 김영규님 안녕하세요.
    동감합니다. 게다가 각 나라마다 선호하는 UI방식이 다른 것은 정말 골치 아프거든요. 그런 경우는 UI를 Flexible하게 바꿀 수 있게 하기도 하는데 점점 복잡해집니다. - -;

  5. Blog Icon
    김정민

    안녕하세요.
    위에 국제화와 지역화에대한 소프트웨어 개발의 표준(De facto)이 정립된지는 매우 오래되었지만 이라고 하셨는데요. 이 표준이 어떤건지 알려주실수 있는지요?

  6. 안녕하세요. 김정민님
    가장 널리 쓰이는 업계 표준은 gettext를 비롯화여 이와 관련된 여러가지를 말하는 겁니다.
    유니코드포럼에서 표준을 정립한 PO파일과 MO파일 그리고 이를 썬마이크로시스템즈에서 gettext로 구현을 해 놓았고, xgettext나 po에디터등 이와 관련된 여러가지 툴이 있고, 프로세스도 상당히 표준화 되어 있습니다.
    gettext는 현재 광범위하게 여러 플랫폼과 개발언어에 포팅이 되어 있어서 왠만한 개발에 거의 모두 사용할 수 있습니다.
    gettext를 제대로 사용하려면 국제화, 지역화에 대한 일반 지식을 모두 잘 알아야 합니다. 또한 관련된 툴의 사용법과 다국어 프로세스 또한 잘 알아야 합니다. 그렇지 않으면 반쪽짜리가 되어서 어디에선가 구멍이 생기게 됩니다.
    모든 케이스를 염두해 두고 방안을 마련해야 합니다.

  7. 아.. 몇번 해외 오픈소스 번역을 해보다 느낀 점들이 잘 정리 되어있네요.

    UFO:AI 라는 오픈소스 게임과 VtigerCRM 번역을 진행해보았는데
    확실히 영어권에서 만들다 보니 어순이 다른 한글에서는 번역에 어려움이 많아지더라구요
    UFO:AI는 리눅스 기반으로 gettext - poedit 이라는 것을 사용해서 조금은 편했지만
    VtigerCRM은 php 라서 그냥 단순 텍스트 파일을 번역을 해야 하는데 언어구성을 잘못해놔서
    모듈별로 중복되는 메시지들도 많다보니 번역도 짜증나고 그리 속도가 안나더군요

    물론 개발자측에서 추가적으로 개발해야할 내용이겠지만
    번역을 감안해서 프린트 할 내용의 순서역시 변경가능하도록 하면 좋지 않을까 생각이 들더라구요
    예를 들어서 "%n of %n" 이런 문장은 한글로 번역 하자면 "%n개 (총 %n개)" 이런식으로 번역하는데
    한글어순에 맞추려면 "%1n of %2n"은 "%2n 중에 %1n개" 이런식으로 되어야 하니 말이죠.

    이런 것들에 대한 프레임워크가 이미 나와있는지는 모르겠지만 gettext는 이런건 지원하지 못하니 아쉬운 감이 있습니다.

  8. 안녕하세요. 구차니님
    gettext에서도 말씀하신 모든 것이 지원이 됩니다.
    이러한 예가 broken sentence의 한 종류입니다. 비슷한 경우는 수많은 케이스가 있습니다. gettext를 제대로 쓰르면 "%1$d of %2$d"와 같이 처음부터 그렇게 코드를 작성해야 나중에 번역만 하면 됩니다.
    gettext와 관련된 툴들도 계속 업그레이드가 되고 있어서 새로운 기능이 계속 추가 되고 있습니다.

  9. 이 글을 읽다 보니 이런 궁금한 점이 생겼습니다.

    MSDN 같은 개발 참고 문서들은 어떻게 국제화를 하는 것일까요?

    언어를 한 개만 지원한다면 그냥 Doxygen으로 만들어 버리면 되겠지만,

    언어가 2개 이상이 된다면 이것도 마냥 쉬운 일은 아닐 것 같은데요.

    HTML 보고 번역하는 것일까요?

  10. 주의사신님 안녕하세요.
    저도 이러한 경험은 없네요. ^^
    보통 Doxygen은 회사 내부에서 사용하기 위한 것이라서 어떻게 번역이 이루어지는지 저도 궁금하네요.
    보통 번역의 가장 어려운 점은 처음에 번역하는 것이 아니고 수정될 때 입니다.
    단순히 번역만 하는 것 가지고는 어려움이 있을 것 같습니다.
    표준적이 방법이 있는지는 저도 좀 알아봐야 할 것 같습니다.
    감사합니다.

  11. 글 잘 보았습니다.
    좋은 하루 되십시오.

  12. 이장석님 감사합니다.

애플이 아이폰4에서 한글을 바꾼 이유는...

2010.07.07 11:47 by 전규현


잠시 후 Google blogger로 이동됩니다.





얼마전 아래와 같은 아이폰의 Localization에 대한 글을 올린적이 있습니다.

심각한 내용은 아니었고, 아이폰의 다국어 설정 화면에서 우리말을 선택하는 항목이 "한국어"라고 적혀 있어야 하는데 "한글"이라고 적인 것에 대한 포스트였습니다. 그뒤로 'Localization(L10n)과 Internationalization(i18n)에 대한 글을 한번 작성해야 지'하고 마음만 먹고 있었는데 너무 바빠서 블로그에 글 자체를 자주 못올리고 있습니다.

그런차에 아이폰을 iOS4.0으로 업그레이하니 제 블로그의 글 때문은 절대로 아니겠지만(^^), 아이폰의 다국어 설정 화면에서 "우리말"을 지칭한 항목이 "한국어"로 바뀌었더군요.


iOS3



iOS4

사소한 변화이기는 하지만 애플이 우리말을 조금 더 잘 이해하게 된 것 같습니다. 아니면 한국어 담당 개발자를 더 뽑았을 수도 있고요. 아무튼 좋은 변화입니다.

* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
저작자 표시 비영리 변경 금지
신고

전규현 프로젝트/국제화 i18n, L10n, 다국어, 아이폰, 한국어, 한글

  1. 구글 서비스에선 한국어를 뜻하는 Korean이 '한국의'로 오역되어 있기도 하더라구요.
    구글 코리아에서 이런 부분은 본사에 적극 어필해주면 좋을텐데요. ^^

  2. 안녕하세요. 편집장님
    "한국인"이라고 표기될 수도 있겠네요. ^^

  3. Blog Icon
    애매한

    북한이 있기 때문에 한국어라고 쓰기도 사실 좀 애매합니다.
    북한에서는 조선말 이라고 쓰니까요.

    서방국가 시각에서 보면 한국어 라고 쓰는게 자연스럽기도 하지만 일본이나 중국에서 일하면서
    뉴스 같은 걸 보면 남북 양쪽의 눈치를 같이 보는 경우가 많더군요.

    현지인이 그렇게 이야기 하더군요... 한국어 라고 표현하기도 좀 애매하다고...
    애플이 거기까지 생각하고 일부러 한글이라고 했을리는 없을 것 같습니다만...

  4. 안녕하세요.
    Localization에서 정확한 표기를 하려면 Locale을 사용해야 합니다.
    Locale에는 문자체계와 사용하는 지역으로 표기가 됩니다.
    즉, 영어_영국, 영어_미국, 한글_대한민국, 한글_북한, 한글_중국(조선족) 이와 같은 식이죠.
    따라서 en_UK, en_US, ko_KR, ko_PK, ko_CN 이렇게 표기합니다.
    하지만 이렇게 표기하면 일반인들이 알아보기 힘듭니다.
    따라서 영국영어, 미국영어, 한국어, 조선어, 중국조선어 등으로 표기할 수 있습니다. 여기에는 딱히 표준이 없는것 같습니다.

    하지만 한국어의 주요 소비국은 대한민국이라서 대부분의 외국제품은 대한민국만을 기준으로 Localization을 하고 있습니다.

  5. 음.. 그냥 훈민정음이라고 표기하면 북한 남한 눈치 안봐도 되려나요 ^^;

  6. 구차니님 안녕하세요.
    ㅎㅎ 그래서 애플이 한글이라고 표기를 했었나보군요.

  7. 아이폰 4이지 아이폰4G 가아닙니다^^...

  8. 맞습니다. ^^

  9. Blog Icon

    비밀댓글입니다

애플은 한국어와 한글을 구분하지 못한다?

2010.02.11 15:44 by 전규현


잠시 후 Google blogger로 이동됩니다.





아이폰을 사용하기 시작한지 오늘로 꼭 2달이 되었습니다. 
2달동안 아이폰을 사용하는 재미, 아이폰 앱 개발 관련 공부하는 재미에 빠져있었습니다. 그런데, 아이폰 다국어 설정에서 이상한 것을 발견했습니다.

언어어 설정에 떡하니 "한글"이라고 나와 있는 겁니다. 대부분의 사람들은 그냥 지나쳤겠지만, 저야 소프트웨어 전문가이고 Localization의 중요성을 알고 있는터라서 눈에 확 거슬리더군요. 
아시는 분들도 많겠지만, 여기에는 "한글"이 아니고 "한국어"라고 나와야 맞습니다.


그럼 "한글"과 "한국어"가 다른지 알아보겠습니다. 

"한국어"는 몇 천년전부터 조상 대대로 사용해 오던 우리 말입니다. 
"한글"은 1443년 세종대왕께서 만드신 자랑스러운 우리 고유의 문자체계입니다. 한글이라는 이름도 1910년 주시경선생이 붙인 것이고요.

"영어", "English"는 말이고 "알파벳"은 문자체계죠.
"일본어"는 말이고 "히라가나"는 문자체계죠.

영어로 얘기해도 엄연히 다름니다. 
"한국어"는 "Korean" 이지만 "한글"은 "Korean Alphabet" 또는 "Hangul"입니다.

물론 한글은 자랑스러운 우리의 글자체계입니다. 전세계적으로 고유의 문자체계를 가지고 있는 나라는 몇 안되고, 알파벳이나 한자의 영향을 거의 받지 않고 완전히 독립적인 문제체계를 가진 나라는 그렇게 많지는 않습니다.. 게다가 한글은 매우 과학적이고 배우기 쉬워서 "언어"는 있는데 "표기방법"을 가지고 있지 않는 나라들에게 "한글"을 보급하기 위한 활동도 진행중입니다. 세종대왕께서도 한글(훈민정음)은 슬기로운 사람은 아침 나절이 되기 전에 익힐 수 있고, 어리석은 사람도 열흘 안에 배울 수 있다고 했죠. 

한글이 그렇게 우수하다고 하더라도 말과 글을 혼동해서 쓰는 것은 안되겠죠. 일반인들은 흔히 한글과 한국어를 혼동해서 얘기를 하고 별 문제될 것도 없지만, 수천만명이 쓰는 디바이스에 잘못된 오류가 있는 것은 고쳐야 할 것 같습니다.

아이폰의 Internationalization(i18n) Localization(L10n)을 진행한 사람들이 전문가들일텐데, 단순 실수라고 믿고 싶습니다.

i18n과 L10n 얘기가 나온차에 조만간에 이에 관련된 글을 올려보도록 하겠습니다. 잠깐 미리 조금 얘기를 드리자면 흔히들 소프트웨어를 개발해서 해외에 진출하기 위해서 영어로 번역을 한다, 일본어, 중국어를 지원한다라고 하지만, 단순히 메시지 좀 번역하는 것이 Localization이 아닙니다. 또한 대충 해 놓았을 경우 발생하는 유지보수 비용은 만만치가 않습니다. 그래서 Localization은 스펙작성시부터 고려가 되며, 아키텍쳐에 반영이 되며 단순히 메시지 뿐만 아니라 많은 부분을 고려해야 하고, 개발 및 유지보수를 위한 프로세스와 툴들이 필요합니다. 자세한 내용은 다음에 올리도록 하겠습니다.

* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
image by laura padgett
저작자 표시 비영리 변경 금지
신고

전규현 프로젝트/국제화 i18n, L10n, 다국어, 일본어, 한국어, 한글

  1. 음.. 번역은 어짜피 외주주지 않을까요?
    저도 UFO:AI 라는 opensource 게임의 한글화를 부분적으로 자발적으로 지원하는 중이지만, 번역이 쉽지는 않더라구요. 아무튼 메시지ID 기반으로 하는 번역 시스템의 한계도 있고, 이래저래 번역도 쉬운일은 아니더라구요.

    그러고 보니, 문자체계와 언어는 구분을 해야겠군요. 좋은 내용 감사합니다.
    저도 번역 작업에 주의를 더 기울여야겠습니다.

  2. 구차니님 안녕하세요.
    번역이 다국어 지원의 전부는 아니죠 ^^ 메시지ID기반의 다국어 작업은 전통적으로 MS가 좋아하는 방식이지만, 실제 적용해보면 많은 문제들이 있습니다. 구체적으로는 다음에 블로그 글로 올려보도록 하겠습니다. 감사합니다.

  3. 이 부분은 좀 다른 사정이 있을겁니다. '조선어(북한)'와 '한국어(대한민국)' 양쪽으로 두 번 로컬라이징 하는 번거로움을 덜기 위해, 외국 회사에서 제작한 프로그램이 언어 선택 옵션에 '한글'을 제시하는 것은 매우 흔한 일입니다. 물론 아이폰이 북한에 출시될 가능성은 희박합니다만, 일종의 관행적인 일이라고 보아도 될 것 같습니다.

  4. 안녕하세요. Chatmate님
    물론 이유는 있을 것 같네요. 말쓴 하신 이유도 그럴듯합니다. 북한말과 우리말을 소프트웨어를 개발할때 같은 언어로 봐야할지도 이슈네요. 상당부분 이해는 되지만, 다른 단어들어 너무 많아서요. 그래서 영어도 미국, 캐나다, 영어 다 Locale을 따로 가지고 있습니다. 그렇다면 외국의 소프트웨어 회사들에게 북한과 우리의 차이를 이해시켜야겠네요.

  5. 그리고 보니까 소프트웨어 관련 블로그를 가지고 계시네요. 바로 RSS Feed 등록했습니다. 감사합니다.

  6. 저도 chatmate님과 비슷한 의견을 가지고 있습니다.
    일본에서 한글(한국어) 교제에는 한글로 표기되고 있습니다.
    처음에는 한국어가 많았는데 조총련에서 딴지를 걸어서
    한글로 쓰고 있다는 말을 방송국에서 일할때 들었었습니다.

    Ray.전규현님의 언급처럼 언어와 문자체계로 나룰수도
    있겠지만 한국어와 조선어를 포괄하는 개념으로 한글을
    사용할 수도 있다고 생각되네요.

    어찌되었던 로컬라이징은 그 나라의 문화와 역사를 모르면
    가장 어려운 부분이 아닐까 싶군요 ^^

  7. Blog Icon
    Desac

    알파벳이나 한자의 영향을 거의 받지 않고 완전히 독립적인 문제체계를 가진 나라는 대한민국을 제외하고는 거의 없습니다.
    ------
    아랍어, 태국어 등등 여럿 있습니다.

  8. 안녕하세요. Desac님
    저도 몇개 있는 것으로 생각은 하고 있으나 그쪽 전문가는 아니라서 이런 표현을 했는데, 제가 생각한 것보다는 많나보네요. 몇개로 바꾸는 것이 나을 것 같습니다. 감사합니다.

  9. Blog Icon
    그런데

    실질적으로 언어인 말을 가지고 있는 나라는 많지만 글자를 가진 나라는 그리 많지 않습니다
    주로 영어로 많이 쓰죠

  10. 전세계에 6800개의 언어가 있고, 그중 절반이 사라질 위기에 있다는 군요. 그중 글자를 가진 언어는 100개 정도라네요.

  11. Blog Icon
    김종국

    좋은 지적입니다. 미쳐생각지도 못했는데..

  12. 김종국님 감사합니다. 가수는 아니시죠? ^^

  13. 애플만 그런게 아니라 솔까말 한국인들 대개가 그렇습니다. 예전에 컬투가 웃찾사에서

    "아름다운 우리말 누가 만들었나 세종대왕이지 어쩌고..."

    우리 말을 세종이 만들었댑니까. 글을 만들었지..

    국어국문학과 출신(현재 교직 시험보는) 아가씨가 글과 말을 헷갈리길래 함 지적했더니 답변이라고 하는게 어디서 줏어들은 풍월은 있어가지고...

    "말과 글은 떼어놓고 생각 할 수 없는 법이다"

    물론 그 말 자체만 놓고 치면 맞는 말입니다마는 지가 한글과 한국어를 헷갈린건 어디까지나 쪽팔릴 일이지 그딴 궤변으로 빠져나가려 드는 모습이 참 안쓰러웠습니다.


    그건 그렇고 locale에 대한 지적은 chatmate님 말씀이 거의 정확할겁니다.

  14. 지금 제 아이폰을 확인해보니, 설정->일반->다국어->언어에는 "한글"이라고 나와있지만, 언어 아래항목인 음성으로 조절하기에는 "한국어"라고 되어있네요.
    단순실수인지, 둘을 구분한 이유가 있는건지, 갑자기 저도 궁금해집니다.
    좋은 지적 잘 보고 갑니다. ^^

  15. 안녕하세요. 예문당님
    아마 애플에서도 나름대로 이유가 있을 것으로 추측은 하고 있습니다.

  16. Blog Icon
    오르페

    이래서 제가 개발자분들을 존경합니다. 잘 봤습니다.

  17. 존경씩이나 - -; 일반인이 섞어 쓰는 것은 별 문제 없다고 생각합니다. 누군가가 혼동한다고 굳이 지적할 내용은 아니라고 봅니다. 개발자로 사는 것은 피곤하죠?

  18. Blog Icon
    카일

    최근 한글을 표기언어로 채택한 짜이짜이족에 아이폰을 판다면 같은 한글을 쓰더라도 분명이 다른 언어로 표현되기 때문에 "짜이짜이어"라는 옵션이 들어갈 것입니다. 표기문자는 한글이지만 언어가 다르니까요. 만약 한글이라고 한다면 짜이짜이족이 햇갈리지요.

  19. 안녕하세요. 카일님
    짜이짜이족 이외에는 아직 한글이 보급된 민족이나 나라는 없나요? 한글 보금이 성과를 빨리 내기는 어려운 것 같군요.

  20. 좋은 글 잘읽고 갑니다. ^^ 우리 팀 동료들에게도 "한글"과 "한국어"의 차이에 대해 물어보니 누구도 쉽게 대답하지 못하더군요. 평상시에 놓치기 쉬운 부분이지만 꼭 구분되어야 하는 사항 같습니다.

  21. 안녕하세요. 검은왕자님
    소프트웨어 개발자라면 알아야 한다고 생각합니다.

  22. 좋은 글 잘 보고 갑니다. 말씀하신대로 한국어와 한글을 구별할 줄 알아야 하겠네요. 좀 다른 얘기지만, 유독 localization은 하찮은 잡무로 취급되는 경향이 없지 않나 생각됩니다. 그것도 자세히 들여다 보면 전문적으로 해야 할 일이 많고, 어려운 일들도 있는데 말이죠.

  23. 도모네님 안녕하세요.
    메시지 좀 번역하면 Localization인줄 알다가는 큰코 다칩니다. 그동안 해외에서 장사가 잘 안되서 큰 문제들이 없던 겁니다. 이걸 다행으로 알아야 하나...

  24. 애플만의 문제가 아닙니다. 대부분의 회사에서 나타나는 문제이지요. 심지어 윈도조차도 "한국어 윈도"가 아닌 "한글 윈도"라는 말하는데요. ㅡㅡ;
    심지어 한국 사람조차도 "한글화"라는 엉뚱한 말을 하는데, 외국 기업인 애플이야 더 말해 무엇하겠습니까?

  25. koc/SALM님 안녕하세요.
    그러고 보니까 한글/한국어 혼용이 광범위 하게 사용되고 있네요.

  26. Blog Icon

    비밀댓글입니다

  27. 감사합니다. 맞춤법은 최대한 맞게 쓰려고 하는데도 가끔 실수로 또는 몰라서도 틀리곤 합니다.

  28. Blog Icon
    푸른고래

    좋은글 잘 봤습니다.

  29. 푸른고래님 반갑습니다.

  30. Blog Icon
    김계승

    의미있는 문제제기 잘 봤습니다. 다만, 위에서 제시하신 화면은 아이폰에서 처리할 문자체계를 어떤걸로 할껀지 선택하는 대화상자라고 봤을때 "한글"이라고 표기하는게 문제되지 않아 보입니다. 영어 알파벳 글자를 제대로 표현하고 싶으면 "English"를, 히라가나든지 가타가나든지 일본 글자를 제대로 표현하고 싶으면 "일본어"를 선택하는 것이겠지요. 한국어든 짜이짜이어든 한글 글자를 제대로 표현하고 싶다면 "한글" 옵션을 선택하는게 어쩌면 당연해보이네요. 저의 짧은 생각~

  31. 김계승님 안녕하세요.
    Locale이라는 것이 개념이 좀 복잡하세요.
    언어의 속성은 말, 글, 지역, 시대가 있습니다.

    말 - 한국어, 영어, 중국어, 일본어
    글 - 한글, 알파벳, 간체, 번체, 히라가나
    지역 - 한국, 북한, 영국, 미국, 타이완, 중국본토, 홍콩
    시대 - 과거, 현재

    Locale은 지역과 말을 다루고 있고 글자체계는 따라옵니다.
    물론 언어를 한글로 표시한다고 해도 누구나 이해는 가능하지만, 엔지니어링 관점에서 정확한 표현을 쓰는것이 좋다는 것을 의미입니다.

  32. Blog Icon
    김계승

    오늘도 또 하나 배우고 갑니다. ^^
    트윗도 잘 보고 있답니다.

  33. 그 잉여로운(?) 백괴사전에도 들어가셨군요. http://uncyclopedia.kr/wiki/%ED%95%9C%EA%B8%80%EA%B3%BC_%ED%95%9C%EA%B5%AD%EC%96%B4%EC%9D%98_%EA%B5%AC%EB%B6%84#도보시오

  34. 이런 일이... 이런 사전도 있군요. - -;

블로그 호스팅을 Google Blogger로 이전합니다.

최근에 블로그에 보안 문제가 발생하여 좀더 안정적으로 블로그를 운영하기 위해서 Google Blogger로 이전합니다. 기존에 http://allofsoftware.net 과 http://www.allofsoftware.net..

한국어(한글) 코드 이야기 (8)

유니코드에 대해서 좀더 알아보기 전에 한국어 코드(문자세트)와 인코딩에 대해서 좀더 알아보자. 1991년에 유니코드가 탄생한 후에 유니코드는 점점 많은 개발자들이 사용하기 시작해서 영역을 넓혀가고 있다. 물론 언젠가는 유니코..

유니코드 영토 전쟁의 승리자는? (7)

이번에는 유니코드의 코드 체계에 대해서 간단하게 알아보고자 한다. 소프트웨어 국제화를 필요로 하는 개발자라면 자주는 아니지만 유니코드 내부 코드 체계를 알아야 할 때가 있다. 다양한 플랫폼에서 개발을 할 때 폰트 등과 관련하..

유니코드는 어떻게 탄생했을까? (6)

소프트웨어 국제화를 이해하기 위해서는 유니코드에 대해서 필수적으로 잘 알아야 한다. 유니코드란 말을 들어보지 않은 개발자는 없지만 관련 용어가 매우 많아서 종종 헷갈린다. 게다가 유니코드가 탄생한지 20년도 더 넘었지만 아직..

직원을 잠재적인 도둑 취급하는 회사

필자는 몇 년 전 A그룹에 강연을 하러 갔다가 곤란한 일을 겪은 적이 있다. 한국 대부분의 대기업이 그렇듯이 보안이 매우 엄격한 회사였다. 나는 직원들의 안내대로 메모리, 외장하드를 모두 빼놓고 회사로 들어갔다. 하지만 강연..

외국에서 팔리는 소프트웨어의 아키텍처 디자인 원칙 (5)

김과장은 그 동안 한국어만 지원하는 소프트웨어 A를 개발해 왔는데 최근에 사장님이 A의 일본어 버전을 만들라고 했다. 그리고 개발 기간도 한달 밖에 주어지지 않았다. 그래서 기존 소스코드를 복사해서 한국어가 들어 있는 모든 ..

소프트웨어 개발자 성장에 꼭 필요한 리뷰

우리나라 개발자들은 프로그래밍은 잘 하는데 대접을 못 받는다는 얘기가 있다. 또, 머리는 좋은데 환경이 나쁘다는 얘기도 있다. 젊은 개발자들은 외국의 개발자들에 전혀 뒤지지 않는데 나이를 먹을수록 실력이 떨어진다는 얘기도 있..

외국에 출시한 소프트웨어가 날짜 때문에 낭패 본 사연 (4)

10년차 개발자인 김과장(가상의 인물)은 최근에 소프트웨어를 영어를 지원하도록 만들었다. 어플리케이션에서 표시되는 모든 메시지(메뉴, 버튼, 다이얼로그 등)를 영어로 번역했다. 그렇게 해서 영어버전을 출시했는데 얼마 안 가서..

독일어 버전 소프트웨어란 말이 잘못된 이유 (3)

본 시리즈는 차례대로 읽으면 소프트웨어 국제화가 전체적으로 이해가 되어서 소프트웨어 개발자에게 도움이 되는 방향으로 진행하려고 하고 있다. 개발자마다 지식과 경험이 천차만별이라서 초급 개발자를 기준으로 작성하고 있다. 경영자..

소프트웨어를 외국에 출시 하면서 흔히 빠지는 함정 (2)

우리나라 소프트웨어 중에서 외국에서 크게 성공했다고 하는 소프트웨어가 있는가? 온라인 게임을 제외하고는 거의 없다. 사실 게임은 국제화, 지역화를 잘 못하더라도 큰 흉이 안 된다. 하지만 그 외의 많은 소프트웨어들은 제품이든..

티스토리 툴바