소프트웨어 국제화는 나중에 적용하면 늦는다 (24)

 잠시 중단했던 소프트웨어 국제화 칼럼을 재개한다.

당장의 소프트웨어 출시가 급하다고 국제화를 고려하지 않고 일단 개발하고 출시를 했다가 나중에 필요 시에 국제화를 적용하려고 하면 안된다. 비용이 너무 많이 들거나 너무 복잡해져서 제품 자체가 망가지기도 한다.

실제로 많은 회사들이 소프트웨어 국제화에 실패해서 비지니스에서도 실패하는 경우가 많다.

처음에는 국내에서만 팔다가 나중에 해외 진출을 하면서 뒤늦게 국제화를 적용하다가 낭패를 본다.

국제화를 적용하려고 했더니 데이터 베이스의 인코딩 등 설정을 바꿀 수 없기도 하고, 기능이나 UI를 대거 바꾸지 않으면 안되기도 한다. 초기부터 국제화를 적용했을 때의 국제화 비용보다 수십배 또는 수백배가 들기도 한다. 또한 수많은 버그를 만들어내곤 한다.

국제화를 적용하기에는 너무 늦어져 국제화 버전을 따로 개발해서 똑같은 소프트웨어가 여러벌이 되기도 하는데, 이는 더 큰 문제가 된다. 돌아올 수 없는 강을 건넌 것과 같다.

우리가 개발할 소프트웨어가 영원히 한국에서만 팔릴 소프트웨어라면 국제화를 적용할 필요가 없다.

한국에서만 팔리는 소프트웨어라도 한국내의 외국인을 위해서 여러 언어를 지원해야 한다면 국제화가 필요하다.

당장은 한국에서만 판매를 하지만 추후 해외에서도 판매할 계획을 1%라도 가지고 있다면 초기부터 국제화를 적용해야 한다.

당장 국제화 기능이 필요한 것은 아니고 추후 필요한 경우라면 국제화 아키텍처만 적용하여 나중에 국제화가 필요할 때 언제든지 적은 비용으로 빠르게 국제화를 적용할 수 있도록 할 수 있다.

간단한 예를 들어보자.

소프트웨어 내에는 날짜, 시간을 처리하는 수많은 모듈들이 있다. 이것을 국제화를 고려하지 않고 개발자들이 알아서 한국어에만 알맞게 개발을 한다면 어떻게 될까?

한국에서는 잘 동작할 것이다. 하지만 영어, 프랑스어 등 외국어를 지원해야 하는 국제화가 필요할 때는 큰 문제가 된다. 날짜를 처리하는 수많은 코드를 찾아다니면서 모두다 고쳐야 한다.

개발자들이 적절히 날짜 함수에 국제화 코드를 적용했다고 하더라도 문제가 된다. 각각 따로 적용한 국제화 코드는 일관성이 떨어져서 날짜를 표시하는 위치마다 다른 형태의 날짜가 표시될 수 있다.

그럼 당장 국제화가 필요하지 않지만 미래를 위해서 국제화 코드를 미리 적용해 놓으려면 어떻게 해야 할까?

날짜, 시간를 처리(입력, 출력)하는 모든 기능을 별도의 국제화 함수(클래스)로 분리를 하는 것이다. 그리고 모든 개발자는 날짜, 시간을 다룰 때는 꼭 이 국제화 함수를 사용하도록 하는 것이다. 이 국제화 날짜, 시간 함수는 현재는 한국어만 지원하지만 추후 필요할 때 언제든지 다양한 언어를 쉽게 지원할 수 있다.

날짜, 시간 처리 함수는 필요한만큼 다양하게 준비해야 한다. 소프트웨어 UI상 필요한 모든 조합을 함수로 만들어 놓아야 한다.

년월일시분초

년월일

시분초

날짜, 시간 함수 관련 추가 내용은 아래 글을 참조한다.

https://www.allofsoftware.net/2015/06/010203-12.html

제공된 국제화 함수 외에 다른 형식의 날짜 출력 함수가 필요하면 개별 개발자는 스스로 함수를 만들어서 사용하면 안된다. 국제화 담당 개발자에게 필요한 날짜 출력 함수를 만들어 달라고 요청한 한 후에 그 함수를 써야 한다. 1인 개발이라면 한명의 개발자가 양쪽 역할을 다하면 된다.

국제화 외부 라이브러리가 모든 것을 해결해주지는 않는다. 외부 라이브러리를 이용하더라도, 현재 프로젝트에 맞게 다 커스트마이징해서 일관된 국제화 함수들을 만들어 줘야 한다. 개발자들에게 각자 알아서 국제화 함수를 사용하라고 하면 일관성이 없고 중구난방이 된다.

국제화 함수 인터페이스는 나중에 바뀌지 않도록 잘 정해야 하므로 경험이 많은 고참 개발자가 정하는 것이 좋다.

날짜 외에도 고려해야 할 것은 많다. 아래 그 예를 보자.

번역이 필요한 메시지, 문자 인코딩(Database, File, 통신), 키보드 글자 배치, 폰트 종류, 글자 크기, 숫자 표기, 띄어쓰기, 쉼표, 마침표, 날짜/시간 표기, 썸머타임, 대소문자, 정렬 방법, 화폐, 무게, 부피, 길이, 종이크기, 온도, 주소, 이름, 제도 관련, 문화 관련 색깔/아이콘 등, 소리, 텍스트를 포함한 아이콘, O/X 기호, 문자 입력 방향

국제화 이슈가 있는 것은 개별 개발자가 마음대로 개발하면 안되고, 국제화 라이브러리에 추가한 후에 사용해야 한다. 모든 소프트웨어가 이 모든 항목을 고려해야 하는 것이 아니므로 국제화 이슈가 있을 것 같은 항목을 만나면, 또는 이미 구현을 했어도 나중에 발견하면 국제화 라이브러리로 옮겨야 한다.

소프트웨어의 어떤 부분이 국제화의 영향을 받을지 찾아내는 것도 중요하다. 그래서 국제화 경험이 많은 개발자가 필요하다. 

개발 초기에 소프트웨어 국제화 전문가에게 컨설팅을 받는 것도 좋다. 대충 개발하고 나중에 국제화가 문제 되어서 큰 비용을 지불하는 것보다 훨씬 경제적이다.

국제화 아키텍처를 어떻게 구성해야 하는지는 아래 글을 참조한다. 실제는 이보다 훨씬 복잡하지만 간단한 참조는 될 것이다.

https://www.allofsoftware.net/2015/06/5.html

소프트웨어 국제화는 쉽게 생각했다가는 큰코다칠 수 있지만, 초기부터 제대로 적용하면 큰 무기가 될 것이다.

왜 소프트웨어 번역의 기준은 영어가 되어야 하는가? (20)

이전 글에서 소프트웨어 번역 프로세스의 제 1원칙은 메시지 키는 영어 자체여야 한다고 했다. 즉, 번역의 기준은 영어여야 한다는 것이다. 
 

 현재 시중에 나와 있는 수많은 번역 함수들은 이 제 1원칙에 어긋나있다. 개발자들도 제 1원칙에 어긋난 수많은 방법을 이용해서 소프트웨어 번역을 하면서 수많은 문제가 봉착하고 있다. 

대규모 프로젝트들이 MS개발툴, Java 등 널리 쓰이는 개발툴에서 제공하는 번역 함수들을 그대로 이용해서 번역을 하고 있다고 착각하고 있는 개발자들이 매우 많다. RC파일을 이용해서 메시지가 10,000개,지원하는 언어(로케일)가 30개인 프로젝트를 수행해 낼 수 있다고 착각한다. 할 수도 있겠지만 너무 비효율적이고 거의 불가능하다. 대부분의 대규모 프로젝트에서는 오픈소스 또는 내부에서 개발한 번역 함수와 자동화된 번역 프로세스를 통해서 해결하고 있다. 이를 위해서 매우 전문적인 소프트웨어 국제화 담당자들이 활약하고 있다.

우리나라에서도 대규모 프로젝트에서는 스스로 개발한 번역 함수와 번역 프로세스를 사용하곤 하지만 원칙에 어긋나거나 완전 자동화에 실패를 해서 빠져 나오기 어려운 문제에 봉착하곤 한다. 

그럼 번역의 기준이 되는 메시지의 키는 어떤 것들이 있으며 영어가 아니면 왜 문제가 되는 것일까? 번역 함수에 “메시지 키”를 넘겨주면 “번역된 메시지”가 넘어 온다.
 번역된 메시지 = 번역함수(메시지 키)

"번역함수"에는 여러가지고 있고 물론 자동으로 번역을 해주는 함수가 아니고 번역가가 번역한 메시지를 소프트웨어서 보관하고 있다가 사용자가 사용하는 언어로 변경 해주는 함수를 말하는 것이다.

개발자들이 번역을 위해서 사용하는 메시지의 키는 대략 4가지 정도가 있다.
1. 숫자
2. 심볼
3. 한국어
4. 영어
 

첫 번째 숫자부터 알아보자. 번역의 기준을 숫자로 사용하는 방법은 매우 오래된 방법이다.
번역함수(1) => 사과
번역함수(2) => 딸기
이렇게 사용하는 방법이다. 이 방법의 문제점은 숫자를 잘 관리해야 한다는 점이다. 번역이 필요한 메시지를 새로 추가할 때 기존의 숫자들과 중복되지 않는 숫자를 찾아야 하고 삭제할 경우에는 해당 메시지가 더 이상 정말로 사용되지 않는지 면밀히 검토를 해야 한다. 이런 번거로운 절차를 자동화하는 툴들도 있지만 잘 동작하지 않는 경우가 많았다. 또한 숫자를 보고 바로 번역할 수 없으므로 영어 메시지를 전달해야 하고 영어 번역이 바뀌면 다른 언어도 번역을 변경해야 하는데 이를 관리하는 것이 너무 어렵다. 숫자를 기준으로 번역하는 것은 함수는 간단해 보이지만 관리가 너무 어려워서 이제는 거의 쓰이지 않는다.

두 번째 심볼을 쓰는 방법은 가장 널리 사용되고 있다.
번역함수(MSG_CLOSE) => 닫기
번역함수(BUTTON_OPEN) => 열기
이렇게 사용하는 방법이다. 이 방법은 숫자에 비하여 심볼을 보면 대충 무슨 의미인지 알 수 있어서 개발자들이 메시지 파일을 뒤지지 않고도 심볼을 기억해서 사용할 수도 있고 엉뚱한 메시지를 사용할 위험성이 줄어든다. 하지만 이 방법에도 치명적인 몇 가지 문제가 있다. 먼저 매번 새로운 메시지가 추가될 때마다 심볼을 정해야 한다. 이때 다른 동료와 동시에 같은 심볼을 정해서 충돌이 날 수도 있고, 기존에 사용된 심볼을 없는 줄 알고 다시 쓰는 문제도 발생할 수 있다. 이 또한 삭제할 메시지를 정하는 것이 매우 어렵다. 실수로 삭제하는 위험성 때문에 삭제는 영원히 안하는 회사도 있다. 그러면 새로 지원하는 언어가 늘어 날 때마다 사용도 안하는 메시지를 번역하는 일도 생긴다.
 

번역가에게는 영문 메시지파일을 전달해서 여러 언어로 번역을 요청하지만 나중에 영어가 바뀌면 바뀐 메시지만 다시 각 언어별로 번역을 요청하는 것이 너무 어렵다. 바뀐 영어 메시지를 찾고 관리하는 것도 어렵지만 번역가에게 몇 개의 메시지만 번역을 변경해달라고 요청하기도 힘들다.
어떤 소프트웨어가 v1.0에서 3,000개의 메시지를 번역했다고 하자. 그런데 v1.1에서 500개의 메시지가 삭제되고 500개는 영어 메시지가 수정되었고, 1,000개의 메시지가 추가되어서 최종 3,500개의 메시지가 되었다고 하자. 그럼 번역가에게는 1,000개는 새로 번역을 요청하고 500개는 번역 수정을 요청해야 한다.
어떤 메시지가 수정할 메시지이고, 삭제될 메시지, 추가된 메시지를 버전 별로 관리하고, 번역가에게 보내고, 번역된 메시지를 메시지 파일과 통합하는 일련의 프로세스가 얼마나 복잡한지 대규모 프로젝트의 번역 프로세스를 담당해본 개발자라면 잘 알 것이다
이런 과정에서 문제가 없이 번역 프로세스를 처리하는 것은 거의 불가능하며 수많은 버그를 포함하게 된다. 번역이 누락된 경우 “MSG_CLOSE”와 같은 심볼이 출력되기도 한다.
메시지 키에 심볼을 사용하는 이상 이런 복잡한 프로세스를 피해가기 어렵다.

세 번째는 한국어를 메시지 키로 사용하는 방법이다.
번역함수(닫기) => Close
번역함수(열기) => Open
이 방법은 먼저 영어로 번역을 한 후에 다른 언어로 번역을 해야 하기 때문에 번역 프로세스가 더 오래 걸린다. 그렇게 널리 쓰이는 방법은 아니다.

이 방법이 좋다고 생각하는 경우 한국어에서 영어, 한국어에서 일본어와 같이 우리와 친숙한 언어들을 위주로 지원하고 한국어를 잘아는 번역가를 활용을 하기 때문이다. 이렇게 한국어를 기준으로 변역해도 별 문제가 없는 경우도 있지만 대부분의 번역가는 영어와 해당언어의 전문가들이다. 한국어는 그 중에 하나의 언어인 경우가 많다.

이 방법은 지구가 우주의 중심이라고 생각하는 것과 같다. 그렇다고 영어가 우주의 중심이라는 사대주의적인 얘기는 아니다. 전세계 번역가를 충분히 활용하려면 그 중심은 영어라는 얘기다.

마지막으로 메시지 키로 영어를 쓰는 방법이다.
번역함수(Close) => 닫기
번역함수(Open) => 열기
이와 같이 개발자는 소스코드에 번역할 영어 메시지를 그대로 사용하는 것이다. 이 방법의 장점은 개발자가 소스코드에 영어 메시지를 적는 것 외에 아무 것도 할 것이 없다는 것이다. 심볼 이름을 정하려고 고민할 필요가 없고 심볼 이름이 중복될 까봐 고민할 필요도 없다. 다른 개발자가 동시에 Open이라는 메시지를 번역하려고 소스코드에 추가를 해도 충돌이 나지는 않는다. 삭제된 메시지를 개발자가 수동으로 찾아서 삭제를 할 필요도 없다. 이를 자동으로 찾아주는 툴이 있기 때문이다. 그리고 번역이 누락되면 화면에 영어로 출력된다. 숫자나 심볼로 출력된 것보다는 소프트웨어를 사용 할만 하게 된다. 이 방법의 가장 큰 특징은 번역을 제외한 전 과정이 완전 자동화가 가능하다는 것이다.
이 방법의 유일한 단점이 우리나라 개발자들이 영어 메시지를 제대로 만들어 내지 못한다는 것이다. 개발자가 영어를 너무 못하고 영어에 거부감이 커서 한국어를 키로 사용한다면 장기적으로는 여러 문제에 봉착한다. 그보다는 이를 해결하기 위해서 별도의 프로세스가 추가해서라도 영어를 키로 쓰는 것이 장기적으로는 낫다.

이 글에 의심을 품고 이의를 제기할 개발자가 많다는 것을 잘 알고 있다. 흔히 RC 파일 등에서 자주 쓰이는 심볼 방식이 무엇이 문제인지, 지금까지 문제 없이 잘 쓰고 있다고 주장하는 사람도 많다. 전에도 얘기를 했지만 아주 작은 소프트웨어, 적은 지원 언어를 처리하는 상황이라면 무슨 방법을 써도 문제가 안 된다. 또한 기존 방법의 수동 프로세스를 당연하게 생각하고 있다면 어떠한 조언도 귀에 들어오지 않을 수 있다. 필자는 20년 넘게 소프트웨어를 개발하면서 대부분의 독자들이 경험한 국제화 방법을 거의 경험해 봤고 문제를 다 겪어봤다. 
 
필자는 분명히 말할 수 있다. 나중에 대규모 프로젝트에서 소프트웨어 국제화를 적용할 때 이 원칙을 무시하면 소프트웨어 국제화 때문에 프로젝트에 실패하는 일이 발생할 수 있다. 지금 마음을 열고 소프트웨어 국제화의 원칙을 이해하려고 노력해야 한다. 대규모 프로젝트를 수행하게 될 기회는 개발자에게 언제든지 올 수 있다. 그때를 위해서 몸에 익혀놔야 한다.
 
작은 프로젝트라고 하더라도 원칙을 지키고 번역 프로세스를 완전 자동화하는 것이 훨씬 효율적이다. 그런 과정을 통해서 제 1원칙의 원리를 몸에 익히는 것이 필요하다.

123.456이 무엇으로 보이는가? (10)

123.456 숫자를 보면 우리나라 사람들은 대부분은 123에 소수점을 찍은 후 0.456이 추가된 것으로 생각을 할 것이다. 하지만 독일사람에게 123.456을 보여주면 뭐라고 생각할까? 독일에서 ‘.’은 천단위 구분자다. 그래서 123.456은 123456과 같은 숫자다. 만약에 123.456톤 원자재를 주문하면 어떻게 될까? 원래 의도보다 1000배많은 물량을 주문한 결과가 된다. 이런 것이 처리가 안된 소프트웨어를 과연 독일에 팔 수 있을까?

그럼 독일이 이런 것을 알았으니 독일에 맞춰서 소프트웨어를 개발한다고 하면 매번 새로운 나라가 나올 때마다 조사하고 연구해서 지원을 해줘야 한다. 그런 식으로는 끝이 없다. 나라별로 소숫점과 천단위 구분자는 천차만별이다. 게다가 아랍은 아라비아 숫자가 아닌 별도의 숫자를 사용하고 있고, 중국과 일본은 과거 천이 아닌 만단위 구분자를 사용했었다. 

Application 개발자가 매번 숫자를 출력할 때마다 이런 고민을 할 수는 없다. 국제화 라이브러리를 만드는 개발자가 이를 고민해야 하고 Application 개발자는 숫자를 출력하기 위해서 마음대로 개발을 하면 안되고 꼭 국제화 라이브러리를 사용해야 한다. 국제화 라이브러리 개발자는 내용은 나중에 채우더라도 Application 개발자가 쓸 수 있는 함수 정의를 먼저 제공해야 한다. 처음에는 한국의 숫자 형식으로 출력이 되겠지만 국제화 라이브러리 개발자가 로케일별 숫자 형식을 지원하는 라이브러리를 완성하면 숫자가 로케일별로 다른 형식으로 출력되게 된다. 

(소수점 사용 지도)

그럼 나라별로 어떤 형식의 숫자를 사용하는지 먼저 좀 알아야 한다. 또한 자신이 개발하고 있는 OS와 사용하고 있는 개발툴, 프레임워크가 어떤 국제화 함수들을 지원하는지도 잘 알아야 한다. 먼저 나라별 숫자 형식을 살펴보자.

1,234,567.89와 같은 숫자를 쓰는 나라는 한국, 미국, 캐나다, 중국, 일본, 영국, 호주 등이 있다. 물론 소프트웨어 내에서는 국가가 아니고 로케일로 지정을 해야 한다.

이와 반대로 1.234.567,89 형식의 숫자를 쓰는 나라는 독일, 그리스, 덴마크, 이탈리아, 인도네시아, 러시아 등이 있다. 네덜란드는 통화표시 때는 이 형식을 사용한다. 인도네시아는 과거 네덜란드의 식민지여서 이 숫자 형식을 쓰게 된 것으로 보인다. 아시아 나라들의 국제화 표준은 식민지 역사와 관련이 있는 것이 씁쓸하다.

특이하게 스위스에서는 1'234'567.89 형식으로 숫자를 사용한다. 

1 234 567,89와 같이 천단위 구분자로 띄어쓰기를 하고 소수점으로 콤마를 쓰는 나라로는 벨기에, 프랑스, 네덜란드(비 통화표시) 등이 있다.

사우디아라비아에서는 ١٬٢٣٤٬٥٦٧٫٨٩와 같이 표기한다. 천단위 구분자도 다르고 소수점도 다르다. 아리비아숫자도 쓰지만 아랍어의 숫자도 쓴다. 아랍권도 로케일마다 숫자표기가 다르다. 천단위 구분자는 뒤집힌 콤마인데 폰트 때문인지 제대로 안나온다. 특이한 점은 아랍어는 오른쪽에서 왼쪽으로 쓰지만 숫자는 왼쪽에서 오른쪽으로 쓴다는 점이다.

아라비아숫자는 최초에 인도에서 만들어졌다는데 대다수 역사가들이 동의를 하다. 하지만 인도숫자가 아니고 아라비아숫자라는 명칭을 얻게 된 이유는 인도에서 만들어졌지만 이슬람세계를 거쳐 점점 변형이 되면서 유럽으로 전파가 되었기 때문에 유럽 사람들은 아랍에서 온 숫자로생각했다. 

이외에도 여러가지 숫자 표기 형식이 더 있다. 하지만 개발자가 이 모든 것을 다 알 필요는 없다.  이렇게 다양하다는 것 정도와 나중에 버그가 보고 될 때 버그를 고치기 위해서 필요한 정도만 알면 된다.

우리나라 및 한자권의 나라들은 숫자가 만 단위로 되어 있어서 만단위구분자를 찍는것이 읽기는 더 편하다. 하지만 숫자표기 표준화에 따라서 우리나라에서도 천단위 구분자를 사용하는데 불편하다. 또한 관습적으로 백단위와 천단위 구분자를 섞어서 쓰는 나라도 있지만 지금은 거의 천단위 구분자를 사용하는 것으로 통일되고 있다.

숫자를 위한 국제화 라이브러리를 설계할 때는 다음 순서를 따르면 된다.

첫째, 지원 범위를 결정한다.

얼마나 많은 로케일을 지원해야 하나? 현재는? 미래에는?

지원할 숫자의 종류는? 정수? 실수? 숫자의 길이는?

천단위 구분자를 지원할 것인가?

출력만 지원할 것인가? 입력, 출력 모두를 지원할 것인가? 입출력별 지원할 숫자 형식은?

Application 종류마다 지원 범위가 다르므로 미래 요구사항까지 고려하여 스펙을 정해야 한다.

둘째, 함수 프로토타입을 정의한다.

함수가 정의되어야 국제화 라이브러리가 완성되지 않아도 Application 개발자가 사용할 수 있으므로 프로젝트 초기에 정해야 하며 나중에 바뀌지 않도록 신중하게 결정해야 한다.

보통 정수를 문자열로, 문자열을 정수로 바꿔주는 함수와 실수를 문자열로, 문자열을 실수로 변환하는 함수를 정의한다. 천단위 구분자를 옵션으로 주기도 하고 로케일에 영향을 받지 않는 옵션을 제공하기도 한다.

셋째, 함수 내부를 구현한다.

숫자 함수는 보통 L10n 라이브러리를 로케일별로 각각 개발하지 않고 시스템에서 제공하는 국제화 함수들을 사용한다. 그만큼 숫자는 일반적인 국제화 항목이라서 대부분의 시스템에서 제공한다. C언어를 사용한다면 atof(), atoi(), atoll(), strtod(), strtol(), printf(), sprintf() 등의 함수가 로케일을 바꿔주면 로케일에 따라서 다르게 동작한다. 물론 각 함수들은 와이드캐릭터(wchar_t) 버전이 따로 있으니 사용하는 문자의 데이터형에 따라서 알맞은 함수를 사용해야 한다. printf() 함수의 국제화 버전을 사용하려면 libintl라이브러리를 포함해야 한다.위 함수들이 로케일에 따라 다르게 동작하게 하려면 setlocale(LC_NUMERIC, "ko_KR")과 같이 숫자형식의 로케일을 바꿔줘야 한다. LC_ALL을 이용해서 모든 카테고리를 다 바꿔도 동작한다.

그 외에 어떤 개발언어, 라이브러리, 프레임워크를 사용하냐에 따라서 숫자함수들의 사용법이 다르니 환경에 알맞게 구현을 해야 한다. 

자세한 시스템 국제화 숫자 관련 함수의 사용법은 환경에 따라서 매우 다양하여 이 글에서 다 소개하기는 어렵다. 추가로 궁금한 것은 스스로 조사를 하던가 필자에게 직접 문의를 하는 것이 좋겠다. 

입력함수는 출력함수와는 다르게 엄격하지 않게 구현하는 것이 일반적이다. 천단위 구분자를 포함해서 입력하는 함수라도 천단위 구분자가 입력되지 않은 경우에도 처리를 하는 등 유연성을 발휘하는 것이다.

추가로 35%, 10mm 등 뒤에 단위가 붙은 숫자들도 국제화 함수로 미리 정의를 해 놓는 것이 좋다. 이또한 나라별로 국가별로 어떤 표기법으로 바꿔야 할지 알 수 없기 때문이다.

이렇게 숫자를 나라별, 로케일별로 제대로 표현하는 것은 소프트웨어 국제화의 시작이다.

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

국제화 시 고려해야 할 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%이다. 대부분은 이미 국제 표준이나 기술이 있으므로 직접 개발하기보다는 제대로 완성된 기술을 이용해야 한다.

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