해외에 소프트웨어를 팔려면 이것이 꼭 필요하다.
2010/12/14 18:42 by 전규현
All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다.
RSS Feed
연초에 소프트웨어의 국제화와 지역화를 언급하면서 조만간 이에 대한 글을 올리겠다고 했는데, 벌써 10개월이 지났네요.
최근의 소프트웨어들을 보면 국경은 의미가 없어진지 오래입니다. 특히 스마트폰이 폭발적으로 보급되면서 개발자들과 세계 각국의 사용자들은 더욱 가까워졌습니다.
국제화와 지역화에대한 소프트웨어 개발의 표준(De facto)이 정립된지는 매우 오래되었지만, 국내에서는 별로 관심을 받지 못하는 것이 사실입니다. 그렇게 어렵지 않은 기술임에도 관심들이 별로 없고 관심이 있다고 하더라도 흩어져 있는 정보를 모두 모아서 하나의 그림으로 보기 어려운 상황입니다. 어렵지는 않다고 했지만 매우 복잡하기 때문에 처음에 이해하기란 쉽지 않습니다.
흔히들 우리나라에서 성공한 제품을 가지고 해외에 진출한다고 영어버전을 만들고 일본어, 중국어 버전을 만들곤 합니다. 이때 그냥 메시지만 번역을 해서 지역화된 제품이라고 생각하곤 합니다. 하지만 이런 제품을 해외에 가지고 나갔다가는 낭패를 보기 일쑤입니다. 외국과 우리나라가 그렇게 비슷하다고 생각하면 착각입니다.
RSS Feed
연초에 소프트웨어의 국제화와 지역화를 언급하면서 조만간 이에 대한 글을 올리겠다고 했는데, 벌써 10개월이 지났네요.
| 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 프로그램만 작성을 하다가 유니코드 프로그램을 작성하는 것이 낯설고 어려울 수 있지만 이 또한 적응이 되고 나면 그렇게 어려운 일도 아닙니다.
단, 유니코드 및 문자셋, 코드셋, 인코딩 등 복잡한 컨셉을 모두 제대로 이해하는 것은 보통 어려운 일이 아닙니다. 그렇지 않다면 개발을 하다가도 "어찌어찌 하니 우연히 되더라"하는 식의 개발이 되기도 합니다.
유니코드가 적용된 지역화된 소프트웨어를 개발하려면 갖춰야할 기본 지식이 매우 많습니다.
이런식으로 언어(locale)이 고려해야 할 것은 메시지외에도 Collate, Ctype, Monetary, Numeric, Time이 있습니다. 이것들은 표준적으로 정해 놓은 것이고 비표준적인 요소는 이보다 훨씬 많습니다. 비표준적인 요소들은 제품마다 별도로 분석해야 합니다.
| 메시지도 단순히 번역하는 것이 다가 아닙니다. |
간단한 예로 나라마다 어순이 다르고 단수, 복수의 표현이 다릅니다.
우리나라에는 단수, 복수에 따른 차이가 거의 없지만, 영어에는 복수가 있지요. 하지만 폴란드어는 1개일때 2~4개일때, 5개 이상일 때 서로 표현이 다릅니다. 게다가 12~14개로 넘어가면 또 반복이 됩니다.
이렇듯 거의 모든 요소에서 다른 나라에서는 과연 이대로 쓰는지 의심을 해봐야 합니다. 경험도 많이 필요합니다. 그러면서 자연스럽게 문장의 표현 방법도 글로벌하게 문제가 없는 방법을 사용하게 됩니다.
또한, 번역을 했을 때 문장의 길이가 천차만별이기 때문에 UI 디자인시 문장의 길이를 충분히 길다고 생각하고 디자인을 해야 합니다.
이러한 모든 것이 습관이 되어 있다면 간단한 일이지만 초기에는 매우 귀찮은 일이 됩니다.
| 유니코드는 기본입니다. |
지역화된 소프트웨어를 개발하다보면 항상 부딪히는 것이 문자코드의 충돌입니다.
유니코드를 사용하지 않아도 지역화된 소프트웨어를 개발할 수 없는 것은 아니지만, 여러 군데에서 매우 귀찮은 일이 발생하게 됩니다.
따라서 유니코드를 기본으로 생각하면 복잡한 문제들이 대부분 해소가 됩니다.
기존에 ANSI 프로그램만 작성을 하다가 유니코드 프로그램을 작성하는 것이 낯설고 어려울 수 있지만 이 또한 적응이 되고 나면 그렇게 어려운 일도 아닙니다.
단, 유니코드 및 문자셋, 코드셋, 인코딩 등 복잡한 컨셉을 모두 제대로 이해하는 것은 보통 어려운 일이 아닙니다. 그렇지 않다면 개발을 하다가도 "어찌어찌 하니 우연히 되더라"하는 식의 개발이 되기도 합니다.
유니코드가 적용된 지역화된 소프트웨어를 개발하려면 갖춰야할 기본 지식이 매우 많습니다.
| 꾸준히 유지보수 할 수 있는 프로세스를 만들어야 합니다. |
지역화된 소프트웨어를 만들때 흔히 발생하는 문제점이 처음에 한번 개발은 어떻게든 해 냈는데, 유지보수 단계에서 상당히 곤란한 상황에 처한다는 겁니다. 한국어를 포함해서 영어, 중국어, 일본어 그러고 여러 언어를 지원하다보면 패치를 만들어가 업그레이드를 할 때 매번 새로 추가된 메시지와 삭제, 변경된 메시지를 추려서 각각의 언어로 번역을 하고 제품에 반영해서 또 테스트를 해야 하는데 그게 잘 안되고 뒤죽박죽되기 일쑤입니다. 툭하면 어떤 언어에서는 메시지가 제대로 안나오곤 합니다.
지역화 프로세스는 번역과정을 빼고는 모두 자동화를 해서 추가로 비용이 들지 않아야 합니다.
각 개발자나 회사에서 스스로 만든 지역화 방법을 사용하면 좋지 않은 결정적인 이유가 유지보수 입니다. 대부분의 개인들이 만든 지역화 방법은 유지보수까지 완벽하게 반영하지 못한 것이 대부분이기 때문입니다.
각 개발자나 회사에서 스스로 만든 지역화 방법을 사용하면 좋지 않은 결정적인 이유가 유지보수 입니다. 대부분의 개인들이 만든 지역화 방법은 유지보수까지 완벽하게 반영하지 못한 것이 대부분이기 때문입니다.
| 결론 |
필자는 무슨 소프트웨어를 만들지간에 국제화는 무조건 생각합니다. 이미 알고 있는 마당에서 비용이 추가로 들것도 별로 없습니다.
하지만, 초기에 국제화를 생각하지 않고 나중에 영업이 잘되서 해외 진출을 한번 해보려고 하면 국제화와 지역화는 큰 걸림돌이 될 겁니다.
이 또한 알면 무지 쉬운데 모르면 한없이 어려운 분야 중 하나입니다.
"유비무환". 미리미리 준비해서 언제든지 글로벌 소프트웨어 회사들과 경쟁할 준비를 해놓읍시다.
이번 글에는 소프트에어의 국제화와 지역화의 필요성과 개념만 정리를 했는데, 그 구체적인 방법은 너무 광범위 해서 블로그 글로 모두 적기는 어려울 것 같습니다. 하지만 기회가 되면 한가지씩 올려 볼 수는 있을 것 같습니다.
혹시 소프트웨어의 국제화와 지역화가 필요하기는 한데 어려움을 겪고 있거나 이미 스스로 방법을 만들어서 쓴맛을 본 분들이 있으면 연락해주세요. 도움이 되어 드리면 좋겠습니다. :)
* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
하지만, 초기에 국제화를 생각하지 않고 나중에 영업이 잘되서 해외 진출을 한번 해보려고 하면 국제화와 지역화는 큰 걸림돌이 될 겁니다.
이 또한 알면 무지 쉬운데 모르면 한없이 어려운 분야 중 하나입니다.
"유비무환". 미리미리 준비해서 언제든지 글로벌 소프트웨어 회사들과 경쟁할 준비를 해놓읍시다.
이번 글에는 소프트에어의 국제화와 지역화의 필요성과 개념만 정리를 했는데, 그 구체적인 방법은 너무 광범위 해서 블로그 글로 모두 적기는 어려울 것 같습니다. 하지만 기회가 되면 한가지씩 올려 볼 수는 있을 것 같습니다.
혹시 소프트웨어의 국제화와 지역화가 필요하기는 한데 어려움을 겪고 있거나 이미 스스로 방법을 만들어서 쓴맛을 본 분들이 있으면 연락해주세요. 도움이 되어 드리면 좋겠습니다. :)
* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
image by chrys
'개발문화' 카테고리의 다른 글
| 왜 나만의 방법이 실패하는지? (NIH 신드롬) (12) | 2011/01/09 |
|---|---|
| 매일 불난 호떡집 같은 회사 (중요한 일 vs. 시급한 일) (14) | 2011/01/03 |
| 해외에 소프트웨어를 팔려면 이것이 꼭 필요하다. (12) | 2010/12/14 |
| 문서화 딜레마 (20) | 2010/11/11 |
| 내가 지금 하고 있는 일의 가격 (6) | 2010/11/02 |
| 개발자를 잘못 채용하는 방법 (20) | 2010/04/19 |
Trackback Address: http://allofsoftware.net/trackback/202
-
2010/12/15 10:47Web 2.0과 세계화(Globalization) Tracked from 세상을 보는 또 다른 시선
-
2011/03/04 10:45국내 소프트웨어 업계의 미래는 밝다! Tracked from 클로인의 일상로그
더 중요한 것은 timezone 설정입니다.
안녕하세요. 정도유님
Time zone은 이미 OS에서 설정이 되고 있고 이를 이용할 수 있습니다.
제품에서 별도의 time zone을 설정할 필요가 있다면 기능이 필요하곘네요. 또한 섬머타임도 고려를 해야 하고요.
그리고 소프트웨어의 성격에 따라서 시간의 저장은 Local time이 아닌 절대 시간으로 기록을 하고 필요에 따라서 Local time의 변환해서 보여기도 합니다.
UI도 중요한 부분이라고 생각됩니다.
UI에 표시되는 텍스트만 보더라도 각 언어마다 텍스트 길이나 배치가 달라져 제대로 확인하지 않으면 UI가 제대로 표시되지 않으니깐요.
김영규님 안녕하세요.
동감합니다. 게다가 각 나라마다 선호하는 UI방식이 다른 것은 정말 골치 아프거든요. 그런 경우는 UI를 Flexible하게 바꿀 수 있게 하기도 하는데 점점 복잡해집니다. - -;
안녕하세요.
위에 국제화와 지역화에대한 소프트웨어 개발의 표준(De facto)이 정립된지는 매우 오래되었지만 이라고 하셨는데요. 이 표준이 어떤건지 알려주실수 있는지요?
안녕하세요. 김정민님
가장 널리 쓰이는 업계 표준은 gettext를 비롯화여 이와 관련된 여러가지를 말하는 겁니다.
유니코드포럼에서 표준을 정립한 PO파일과 MO파일 그리고 이를 썬마이크로시스템즈에서 gettext로 구현을 해 놓았고, xgettext나 po에디터등 이와 관련된 여러가지 툴이 있고, 프로세스도 상당히 표준화 되어 있습니다.
gettext는 현재 광범위하게 여러 플랫폼과 개발언어에 포팅이 되어 있어서 왠만한 개발에 거의 모두 사용할 수 있습니다.
gettext를 제대로 사용하려면 국제화, 지역화에 대한 일반 지식을 모두 잘 알아야 합니다. 또한 관련된 툴의 사용법과 다국어 프로세스 또한 잘 알아야 합니다. 그렇지 않으면 반쪽짜리가 되어서 어디에선가 구멍이 생기게 됩니다.
모든 케이스를 염두해 두고 방안을 마련해야 합니다.
아.. 몇번 해외 오픈소스 번역을 해보다 느낀 점들이 잘 정리 되어있네요.
UFO:AI 라는 오픈소스 게임과 VtigerCRM 번역을 진행해보았는데
확실히 영어권에서 만들다 보니 어순이 다른 한글에서는 번역에 어려움이 많아지더라구요
UFO:AI는 리눅스 기반으로 gettext - poedit 이라는 것을 사용해서 조금은 편했지만
VtigerCRM은 php 라서 그냥 단순 텍스트 파일을 번역을 해야 하는데 언어구성을 잘못해놔서
모듈별로 중복되는 메시지들도 많다보니 번역도 짜증나고 그리 속도가 안나더군요
물론 개발자측에서 추가적으로 개발해야할 내용이겠지만
번역을 감안해서 프린트 할 내용의 순서역시 변경가능하도록 하면 좋지 않을까 생각이 들더라구요
예를 들어서 "%n of %n" 이런 문장은 한글로 번역 하자면 "%n개 (총 %n개)" 이런식으로 번역하는데
한글어순에 맞추려면 "%1n of %2n"은 "%2n 중에 %1n개" 이런식으로 되어야 하니 말이죠.
이런 것들에 대한 프레임워크가 이미 나와있는지는 모르겠지만 gettext는 이런건 지원하지 못하니 아쉬운 감이 있습니다.
안녕하세요. 구차니님
gettext에서도 말씀하신 모든 것이 지원이 됩니다.
이러한 예가 broken sentence의 한 종류입니다. 비슷한 경우는 수많은 케이스가 있습니다. gettext를 제대로 쓰르면 "%1$d of %2$d"와 같이 처음부터 그렇게 코드를 작성해야 나중에 번역만 하면 됩니다.
gettext와 관련된 툴들도 계속 업그레이드가 되고 있어서 새로운 기능이 계속 추가 되고 있습니다.
이 글을 읽다 보니 이런 궁금한 점이 생겼습니다.
MSDN 같은 개발 참고 문서들은 어떻게 국제화를 하는 것일까요?
언어를 한 개만 지원한다면 그냥 Doxygen으로 만들어 버리면 되겠지만,
언어가 2개 이상이 된다면 이것도 마냥 쉬운 일은 아닐 것 같은데요.
HTML 보고 번역하는 것일까요?
주의사신님 안녕하세요.
저도 이러한 경험은 없네요. ^^
보통 Doxygen은 회사 내부에서 사용하기 위한 것이라서 어떻게 번역이 이루어지는지 저도 궁금하네요.
보통 번역의 가장 어려운 점은 처음에 번역하는 것이 아니고 수정될 때 입니다.
단순히 번역만 하는 것 가지고는 어려움이 있을 것 같습니다.
표준적이 방법이 있는지는 저도 좀 알아봐야 할 것 같습니다.
감사합니다.
글 잘 보았습니다.
좋은 하루 되십시오.
이장석님 감사합니다.