국제화 시 고려해야 할 49가지

소프트웨어를 국제화해야 하기 위해서는 고려해야 할 것이 한두가지가 아니다. 그런데 많은 회사들은 메시지나 번역하면 되는 것으로 안다. 그렇게 쉽게 접근하다가는 해외 진출을 하면할 수록 문제가 커지고 비용이 늘어서 점점 어려워진다.

실제 만나본 거의 대부분의 회사가 국제화를 제대로 적용하지 못해서 낭패를 보고나 해외에서 크게 실패를 하였다. 비효율성이 높고 문제가 많아도 제품의 크기가 작거나 고객수가 적다면 그럭저럭 버티지만 큰 제품이나 대규모 서비스는 타격이 엄청나다. 심지어는 회사가 휘청할 정도의 문제를 야기 시키기도 한다.

국제화 기술은 알아야 할 지식도 많고 경험도 많이 필요하다. 

기본적으로 국제화(i18n)과 지역화(L10N)으로 나뉜다. 국제화(i18n)은 소프트웨어가 여러 Locale을 지원할 수 있는 기본 기술이고 지역화(L10N)은 각 Locale을 지원하는 것이다.

이 과정에서 고려해야 할 것은 수백가지가 넘는다. 그 중에서 49가지만 알아보자. 만약에 국제화된 소프트웨어를 개발하고 있는 개발자라면 이중에서 몇가지나 알고 있는지 세어보자. 어떤 항목은 그 하나가 엄청나게 큰 것도 있다. 특별하게 순서를 가지고 정리한 것은 아니지만 하나씩 살펴보자. 

번호	항목	설명
1	언어 구분	한 국가에도 언어가 여러가지이기도 하고 하나의 언어가 여러 나라에서 서로 다르게 쓰이기도 한다.
2	지역 구분	지역과 국가가 완전히 일치하지는 않는다. 언어와 지역 정보가 합쳐져서 Locale이 된다. 소프트웨어는 Locale 단위로 지역화(L10N)를 한다.
3	소프트웨어의 인코딩 전략	소프트웨어가 지원해야 할 인코딩은 매우 복잡하다. Multibyte를 지원하냐 Unicode를 지원하냐에 따라서 인코딩이 다르고 Software, File, Database, Network 별로 다른 인코딩 전략을 사용해야 한다.
4	현지 로케일의 인코딩으로 Export	지역에 따라서 특정 인코딩을 선호하기도 하고 Software의 인코딩과 다른 인코딩으로 Export를 하기도 한다.
5	시스템에 따른 인코딩 차이	거의 대부분의 OS는 Unicode를 지원하지만 OS에 따라서 Unicode이 인코딩이 다르다. UTF-16(UCS2) 또는 UTF-32이 그 예이다.
6	로칼 요구사항의 차이	지역화(L10N)시 현재의 요구사항을 반영한다. 하나의 소스코드와 하나의 팩키지로 지역 요구사항을 반영할 수 있도록 한다.
7	메시지 번역	Locale별로 번역을 한다.
8	메시지 번역 프로세스	소스코드에서 메시지를 추출하고 번역하고 제품에 반영한다. 소스코드가 수정되면 수정된 메시지를 쉽게 반영할 수 있는 프로세스가 필요하다. 번역을 제외한 모든 부분은 자동화가 되어야 한다.
9	메시징 기술	메시징 기술은 수도 없이 많지만 여기서 언급한 모든 것을 지원하는 메시징 기술은 별로 없다. 거의 대부분의 회사는 개발툴에서 번들로 제공하는 간단한 메시징 기술을 사용하는데 이 정도로는 아주 간단한 소프트웨어 밖에 제대로 지원하지 못한다.
10	문자 인코딩 변환	소프트웨에서는 여러가지 인코딩을 사용하기 때문에 수시로 변환을 해야 한다.
11	번역에 따른 문자열 길이 변화	메시지를 번역하면 메시지의 길이가 변한다.
12	국제화를 고려한 UI 디자인	메시지의 길이는 지역에 따라서 바뀌기 때문에 이를 고려하여 UI를 디자인 해야 한다.
13	단수, 복수 표현의 차이	단수, 복수가 없는 언어도 있고 영어보다 훨씬 복잡한 단수, 복수를 사용하는 언어도 있다. 대표적인 것이 폴란드어이다. 메시징 기술은 이것을 지원해야 한다.
14	쓰기 방향의 차이 (오른쪽, 왼쪽)	언어 별로 쓰는 방향이 다르다.
15	커서의 이동 방향  (오른쪽, 왼쪽)	오른쪽 화살표를 눌러도 커서가 왼쪽으로 이동하는 언어도 있다.
16	키보드 글자 배치	언어별로 키보드의 글자배치가 다르다.
17	키보드의 단축키 차이	키보드에 따라서 단축키가 서로 다르다.
18	문자입력기(IME)차이	언어별로 문자입력기가 다르다.
19	폰트의 차이	언어별로 사용하는 폰트가 다르다. 서로 다른 폰트를 고려해야 한다.
20	글자의 크기 차이	언어별로 기본 글자의 크기가 다르다. 특히 중국어는 영어보다 크기가 크다.
21	숫자 표기 방법	나라별로 숫자의 표기가 다르다. 콤마(,)와 점(.)를 표시하는 방법이 다르다. 심지어는 콤마(,)대신 공백을 사용하는 나라도 있다.
22	띄어쓰기 사용의 차이	영어와 한글에 띄어쓰기가 있기 때문에 모든 언어에 띄어쓰기가 있을 것 같지만, 띄어쓰기가 아예 없는 언어도 많아서 띄어쓰기를 기준으로 단어를 분리하면 안된다.
23	쉼표, 마침표 사용의 차이	쉼표와 마침표의 사용도 언어마다 다르다.
24	날짜 표기법의 차이	01/02/03을 읽는 방법은 나라마다 다르다. 미국, 한국, 호주가 각각 다르다.
25	타임존 고려	국제화된 소프트웨어를 만들려면 타임존을 고려해야 한다.
26	썸머타임 고려	썸머타임을 고려해야 하는 나라가 있다.
27	대소문자 구분의 차이	언어마다 대소문자가 다르다. 대소문자가 없는 언어도 있다.
28	관사 사용법 차이	언어마다 관사가 다르다. 관사가 없는 나라도 있다.
29	맞춤법 검사 모듈	맞춤법 검사 기능이 있다면 국제화를 고려해야 한다.
30	사전 제공	사전을 제공한다면 국제화를 고려해야 한다.
31	정렬 방법의 차이	문자열의 순서가 언어마다 다르다. 대부분의 소프트웨어는 목록을 정렬해야 한다. 이때 국제화 기술을 적용해야 한다.
32	화폐 단위의 차이	지역별로 화폐의 단위 및 그 표기법이 다르다.
33	길이, 무게, 부피 단위 차이	지역별로 측정 단위가 다르다.
34	종이 크기의 차이	지역별로 인쇄에서 사용하는 용지의 명칭이 다르다.
35	온도 단위 차이	지역별로 사용하는 온도의 단위가 다르다.
36	주소 형식의 차이	지역별로 주소 표시 형식이 다르다.
37	전화번호 등의 현지화	소프트웨어에서 전화번호를 사용한다면 지역별로 다른 형식을 지원해야 한다.
38	이름 표기법의 차이	지역별로 이름 표기법이 다르다. 이름의 구성, 순서가 다르다.
39	현지 법률 및 제도 적용	현지 법률이나 제도와 표준을 지원해야 한다.
40	문화에 따른 아이콘의 차이	동일한 아이콘이라고 하더라도 문화에 따라서 완전히 다르게 인식할 수 있고 금기시 되는 이미지들도 있다.
41	알파벳을 형상화한 아이콘	아이콘 중에는 알파벳을 형상화 한 것들이 있는데 이는 언어에 따라서 바뀌어야 한다. 대표적인 것이 Bold 아이콘인 "B"이다. 언어에 따라서 Bold가 "B"로 시작하지 않는다.
42	텍스트를 포함한 아이콘	아이콘에 텍스트가 포함된 경우가 있다. 이때 텍스트의 길이 폰트의 크기 등을 고려해야 한다.
43	이모티콘 차이	나라별로 이모티콘이 다르고 지역화된 이모티콘도 있다.
44	색상의 의미 차이	나라별로 색상의 의미가 완전히 다르다. 선호 색상도 다르다.
45	O, X 등 기호의 차이	언어별로 기호의 의미는 천차만별이다. 우리에게 X는 틀렸다는 의미지만 영어에서는 Check라는 의미가 있다.
46	유니코드 처리	국제화된 소프트웨어를 개발하려면 유니코드는 기본이다. 누구나 다 아는 것도 유니코드이지만 유니코드를 제대로 알려면 1,2년 가지고는 모자르다.
47	외부 라이브러리의 유니코드 지원 고려	외부라이브러리들이 유니코드를 지원하지 않는 경우가 있다. 이를 고려해야 한다.
48	파일 시스템의 지원 인코딩	OS별로 파일 시스템의 인코딩이 서로 다르다. 이를 고려해야 한다.
49	멀티 Lingual 고려	하나의 소프트웨어로 수많은 언어를 동시에 지원하고 바꿀 수 있어야 한다.

여기에 모든 것을 다 나열한 것은 아니다. 하지만 이중에서 필요한 일부를 고려하지 않고 소프트웨어를 개발한다면 이것은 버그가 될 것이고 또는 해당 국가에서 보면 어색하고 기분 나뿐 소프트웨어가 될 수도 있다. 물론 소프트웨어의 종류에 따라서 국제화시 고려해야 하는 항목이 다르다. 따라서 위의 모든 것을 모든 프로젝트에서 고려해야 하는 것은 아니다. 한번씩은 생각해봐야 할 항목들이다.

좋은 소프트웨어를 가지고 비즈니스를 아무리 잘해도 국제화가 잘 안된 소프트웨어는 현지에서 성공하기 어렵다.

1~49번까지의 항목들이 제목만 본다고 쉽게 해결할 수 있는 것은 아니다. 하나의 항목을 가지고 10년 넘게 연구하고 개발하고 있는 것도 있을 정도로 크고 복잡한 것도 있다. 제대로 국제화를 적용하고 싶다면 국제화 전문가의 도움을 받는 것도 한 방법이다. 이것을 처음부터 제대로 하지 않고 시행착오를 거쳐서 고객이 버그를 찾을 때마다 하나씩 고쳐주는 것은 끝도 없고 제품의 이미지는 처음부터 추락할 것이다. 

확실한 것은 국제화를 스스로 생각해서 직접 개발하면 잘못될 가능성이 99%이다. 대부분은 이미 국제 표준이나 기술이 있으므로 직접 개발하기보다는 제대로 완성된 기술을 이용해야 한다.

국제화 기술이 소프트웨어 해외 진출 필수임을 잊지 말자.

Agile이 우리 회사 문제를 해결해 줄 수 있을까?

소프트웨어 공학이라는 용어는 사용하기가 상당히 꺼려진다. 소프트웨어 공학이라는 용어를 듣는 사람들이 많은 오해를 하기 때문이다. 일단 듣는 순간 거부감을 가지는 사람들도 상당히 많다.

소프트웨어 공학이 무엇인지 사람마다 서로 다르게 생각하고 있다. 그럼 스스로 소프트웨어 공학을 어떻게 생각하고 있는지 골라보자. 소프트웨어 공학이란?

1. 소프트웨어를 체계적으로 개발하기 위한 방법이다.

2. 고객이 만족하는 소프트웨어를 개발하는 방법이다.

3. 소프트웨어를 여러 사람이 효과적으로 개발하기 위한 방법이다.

4. 유지보수가 용이한 소프트웨어를 개발하기 위한 방법이다.

5. 프로세스를 따라서 소프트웨어를 개발하기 위한 방법이다.

6. 품질이 좋은 소프트웨어를 개발하기 위한 방법이다.

7. 성능이 좋은 소프트웨어를 개발하기 위한 방법이다.

8. 야근을 하지 않고 소프트웨어를 개발하기 위한 방법이다.

9. 소프트웨어를 빠르게 개발하기 위한 방법이다.

소프트웨어 공학을 정확하게 이해하고 있지 못하다면 이중에서 하나를 고르는 것은 여간 헷갈리는 것이 아니다. 정답은 9번이다. 

소프트웨어 공학은 소프트웨어를 가장 적은 비용으로 가장 빠르게 개발하기 위한 방법을 모아 놓은 것이다. 

어디서 많이 듣던 얘기다. 소프트웨어를 빠르게 개발하자고 하는 것은 Agile이 아닌가?

옛날에는 소프트웨어를 늦게 개발했는데 Agile이라는 것이 나와서 그때부터 빨리 개발해야 하겠구나 해서 빨리 개발하기 시작한 것이 아니다. Agile 이전 몇십년 전부터 소프트웨어를 빨리 개발하는 방법에 집중 되어 왔었다. 즉 Agile이라는 용어가 나오기 전부터 Agile하게 개발을 해왔는데 용어를 만들고 그럴듯하게 포장을 하고 상품화를 한 측면이 있다. Agile에서 사용하는 수많은 기법들도 대부분 그 훨씬 이전부터 해오던 것이다. 

유사한 것 중에 UML이 있다. UML 탄생 이전에도 UML의 내용은 거의 다 있었지만 UML은 이들을 모으고 종합해서 상품화를 한 것이다. UML이 기여한 것은 툴을 제공하고 기법의 표준을 정리했지만, 많은 개발자들이 설계는 UML로 하는 것이라는 착각을 일으키게 해서 오히려 소프트웨어 업계를 혼란에 빠뜨린 경향이 있다.

소프트웨어 공학에서는 특정 기법이나 방법론을 써야 한다고 강요하고 있지 않다. 기법은 회사나 프로젝트의 성격에 알맞은 것을 취사선택 하면 된다.

가끔은 Waterfall과 비교를 하면서 Waterfall의 비효율성을 강조하는데 실제 Waterfall을 적용하여 개발하는 곳은 하나의 없다. 개발할 수도 없는데 비교를 하는 것이다. Waterfall은 99.9% 기업에서 적용은 못하지만 여러 방법론 또는 라이프사이클의 모델이 되는 것이다. 비교 대상이 아니다. 전세계적으로도 Waterfall대로 개발하는 프로젝트는 0.001%도 되지 않고 그렇게 할 필요도 없고 그럴 역량도 대부분 없다.

소프트웨어 개발을 잘하기 위해서 즉, 빠르게 개발하기 위해서 방법론만 적용한다고 되는 것은 아니다. 방법론은 소프트웨어 공학의 일부분일 뿐이다. 소프트웨어를 빨리 개발하기 위한 소프트웨어 공학에서 다루는 분야는 방법론 이외에도 분석, 설계, 구현, 테스트, 유지보수, 형상관리, 프로세스, 툴, 품질 등 많다.

특히 분석 즉, “스펙 작성”은 기법 좀 배워서 잘 할 수 있을 것으로 생각하면 오산이다. 수많은 소프트웨어 전문가가 스펙이 소프트웨어 개발에서 가장 어렵고 중요하다고 하는데 괜히 하는 소리가 아니다.

소프트웨어 개발에 문제를 깨닫고 Agile 등 새로운 것에 희망을 걸고 시도를 해본 많은 사람들이 있을 것이다. 그 성과는 어땠는가? Agile 등의 세미나를 많이 쫓아 다니면서 들어서 정말 회사에서 소프트웨어 개발 문제가 사라졌고 소프트웨어가 빨리 개발되고 있는지 스스로에게 물어보자. 그렇지 않다면 그 동안 Silver bullet을 쫓아다닌 것이다.

Silver bullet이란 늑대인간을 한번에 확실하게 죽일 수 있는 전설로 내려오는 탄환이다. 소프트웨어도 많은 사람들이 한방에 모든 문제를 해결해 줄 수 있는 전설의 탄환이 있을 것으로 생각해왔다.

개발 경력이 몇 년 안된 개발자는 잘 모르겠지만 경력이 20년이 넘은 개발자들은 Silver bullet의 역사를 잘 알 것이다. 20여 년 전에는 OOP가 소프트웨어 문제를 모두 해결해 줄 수 있을 줄 알았는데 그렇지 못했다. 그 뒤 CBD, XP가 지금은 Agile이 우리를 유혹하고 있다. 

확실한 것은 이 모두가 전혀 잘못된 방법이 아니라는 것이다. 단지 너무 맹목적으로 믿을 경우 문제가 되는 것이다.

과거에 ZDNet Korea에 기고한 "소프트웨어 개발방법론의 함정"이란 글도 참고하기 바란다.

우리나라에서는 특히나 Silver bullet 열풍이 더 거셌다. 이미 소프트웨어 공학과 개발문화가 정착된 소프트웨어 선진국에서는 필요한 것들을 쉽게 적당히 접목했는데 항상 목마른 우리나라 개발자들은 새로운 것이 나오면 그냥 다 해결 해 줄 것 같이 매달려오기를 벌써 20년이 넘었다.

앞으로 10년 후에도 또 새로운 방법론이나 기법을 가지고 이러고 있어서는 안된다. 기법이나 방법론이 잘못된 것은 하나도 없다. 적용하는 우리의 자세가 중요하다.

소프트웨어 공학은 배울 수가 없다. 경험으로 익히는 것이다. 그런데 방법론 전문가에게 배울 수 있을까? 배우는 것이 의미는 있다. 하지만 얻는 것은 크지 않다. 1%을 배운다면 실제 프로젝트에 적용해서 오랜 경험과 합쳐져야 100%가 된다. 방법론 전문가는 1%는 가르쳐 줄 수 있지만 100%는 본인은 실전 경험이 없거나 적기 때문에 알지도 못한다. 물론 그 1%가 없으면 방향을 못잡고 100%에 영원히 이르지 못할 수가 있다.

방법론이나 기법 전문가가 소프트웨어 전문가가 아니고 우리 개발자가 소프트웨어 전문가이다. 방법론 전문가는 결코 소프트웨어 전문가가 될 수 없다. 대부분은 실전 경험이 부족하기도 하고 실전 프로젝트를 할 시간도 없기 때문이다. 피아노는 치는 것은 초보인데 이론과 방법은 전문가인 사람이 피아니스트를 교육 시키거나 세미나에서 가르치는 격이다. 모르던 이론과 방법을 한번 듣는 정도의 의미가 있지 그 이상을 가르쳐줄 수 있다고 생각하면 착각이다. 또한 배운 그대로 따라 해야 하는 것도 아니다. 원리를 깨닫고 스스로 알맞게 적용해야 한다. 방법론 전문가는 방향과 기법을 알려주는 역할만 할 수 있을 뿐이다.

여러분들보다 소프트웨어 개발에 대해서 잘 모르는 방법론 전문가에게 해답을 구하다가는 "주화입마"를 입을 수 있다. 원리보다 이론이나 기법을 쫓다가 마를 입을 수 있다.

그럼 어떻게 해야 할까?

Silver bullet을 쫓지 말고 근본 원리를 깨닫기 위해서 노력해야 한다. 기법은 익히되 기법이 해결해 줄 것으로 너무 큰 기대를 하지 말아야 한다. 인식을 바꾸고 개발 문화를 정착 시키는데 더 큰 노력을 기울여야 한다. 방법론 전문가에게는 그런 관점으로 방법론을 배우고 소프트웨어 개발은 소프트웨어 전문가에게 배우는 것이다. 보통은 선배 개발자들이 소프트웨어 전문가이다. 하지만 우리나라에서는 회사 내부에 소프트웨어 전문가가 부족하니 외부에서 자꾸 찾으려는 경향이 있는데 방법론 전문가를 소프트웨어 전문가로 착각해서 너무 큰 것을 기대해서는 안 되는 것이다. 진짜 소프트웨어 전문가를 찾던지, 소프트웨어 전문가가 많은 회사로 옮기던지, 스스로 해나가는 수 밖에 없다.