레이블이 프로젝트/국제화인 게시물을 표시합니다. 모든 게시물 표시
레이블이 프로젝트/국제화인 게시물을 표시합니다. 모든 게시물 표시

2012년 8월 9일 목요일

해외 진출하는 족족 실패하는 이유

대한민국 이름을 걸고 해외에서 크게 성공한 Software가 없는 것은 안타까운 일이 아닐 수 없다. 내가 아는 한 그런 Software가 없다. 그런 Software가 있다면 알려주기 바란다.
게임 등 일부 분야에서는 성공 사례가 있지만 일부 특수 분야의 일이다.

그렇게 실패하는 이유는 여러가지가 있겠지만 내가 보는 가장 큰 이유는 소프트웨어를 개발하는 기초 역량이 부족해서이다.

누구는 해외 문화를 이해하지 못했다고 하기도 하고, 영업을 잘 못했다고도 하지만 가장 큰 이유는 개발 역량의 차이이다.

국내에서 개발했던 주먹구구의 방식이 해외에서도 그대로 먹힐 것이라고 생각하는 것은 큰 착각이다.

국내에서 성공했던 대부분의 회사들의 성공요인은 국내에서만 먹히는 서비스 전략 때문이었다. 대충 만들어 놓고 고객이 불만을 표시하면 무한 감동 서비스를 제공하는 것이 그것이다. 많은 회사들이 이 전략을 사용해서 국내에서는 성공을 했다.

작은 땅덩어리에서는 고객이 부르면 언제든지 달려갈 수 있지만, 시장이 세계로 넓어지면 그런 고객 감동 서비스는 꿈도 꿀 수 없는 일이 된다. 고객이 부르면 비행기 타고 날아가고 호텔에서 숙박을 해야 하기 때문에 비용과 시간이 너무 많이 들어간다.

해외에서 성공하려면 진짜로 제대로 개발을 해야 한다. 고객이 해달라는대로 개발하는 것이 아니고 제대로 전략을 세워서 제품 기획을 하고 분석/설계를 해서 개발을 해야 한다. 또, i18n Technology(국제화 기술)도 제대로 적용해야 하는데 99%의 회사는 나름대로 방식으로 또 엉터리를 만들어서 적용하기 때문에 해외에서 대패를 하게 된다.

이런 것을 모두 갖추어야 비로소 비슷한 출발선상에서 경쟁을 시작하는 것인데, 국내에서 하던 방법대로 해외서 성공하려고 하는 것은 100m 달리기에서 20~30m 뒤에서 출발하는 것과 다를 바가 없다.

근본적인 역량을 되돌아볼 때이다.

2010년 12월 14일 화요일

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

연초에 소프트웨어의 국제화와 지역화를 언급하면서 조만간 이에 대한 글을 올리겠다고 했는데, 벌써 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 프로그램만 작성을 하다가 유니코드 프로그램을 작성하는 것이 낯설고 어려울 수 있지만 이 또한 적응이 되고 나면 그렇게 어려운 일도 아닙니다.

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

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

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

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

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

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

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

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

2010년 7월 7일 수요일

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

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

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

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


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

2010년 2월 11일 목요일

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

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

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



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

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

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

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

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

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

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

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