이번 연재를 통해 하고자 하는 이야기는 국제화 시대의 프로그래머가 되기 위해 필요한 이야기입니다. 근사한 다국어 버전 프로그램을 작성하는 것이 혹시 여러분의 오랜 소망은 아닌가요? 다국어 프로그래밍에 대한 이야기를 본격적으로 하기 전에 우선 간단한 용어 정리로 가볍게 몸을 풀어 봅시다.
다국어 프로그램의 단계
i18N
이것이 무슨 해괴한 글씨인지 궁금하지 않나요? 이 단어는 internationalization을 줄여 쓴 말이랍니다. 첫 글자인 i와 n 사이에 18개의 알파벳이 있다는 뜻에서 붙여진 이름이랍니다. 이제 이 단어의 뜻을 살펴볼까요? 이 단어를 직역을 한다면 프로그램의 국제화라고 해야겠지요. 즉, 이미 만들어진 프로그램을 다른 언어를 사용하는 사용자가 사용할 수 있도록 변경하는 과정을 말합니다. 다국어 프로그램이 가져야 할 최소요건을 이렇게 정의해 볼 수 있습니다(www.debian.org/doc/manuals/intro-i18n 참고). 편의상 사용자가 시스템에서 기본적으로 사용하는 언어를 기본어로 줄여서 말하겠습니다.
◆ 기본어의 문자를 정상적으로 입력할 수 있어야 한다
◆ 기본어에 가장 일반적으로 사용되는 인코딩 방식으로 작성된 파일을 다룰 수 있어야 한다
◆ 파일 이름과 다른 항목에 기본어의 문자를 사용할 수 있어야 한다
◆ 기본어의 문자를 인쇄할 수 있어야 한다
간단히 줄여 다시 말하면 기본어의 문자들을 자유롭게 사용할 수 있다는 말입니다. 이 경우 프로그램의 메뉴와 같은 UI가 반드시 기본어의 문자로 되어 있어야 하는 것은 아닙니다. 예를 들어 생각해 볼까요? 비주얼 스투디오의 영어 버전을 한국어 OS에 설치할 경우 위의 조건들에 모두 합당하다는 것을 알 수 있을 것입니다.
프로그램의 번역
이 과정은 단순히 국제화시킨 프로그램의 메뉴나 눈에 보이는 부분을 기본어로 번역하는 것을 말합니다. 이 과정 위에 대체 무슨 과정이 있을 것인지 궁금해 하는 독자라면 다음 과정을 유심히 살펴보세요.
L10n(Localization)
대문자 I와 소문자 l이 잘 구분되지 않는다는 이유로 이와 같이 표시한답니다. 이 단어는 현지화라고 번역을 하면 어떨까 싶네요. 단순한 메시지나 메뉴의 상투적인 번역이 아니라는 점을 강조하는 용어랍니다. 현지화를 제대로 해내려면 원래 언어와 번역된 언어 모두에 통달해야 하며 그 지방의 문화나 관습에 대해서도 잘 알고 있어야 합니다. 화폐, 시간, 날짜 등의 표시 방법, 기본 측량 단위 등의 사항을 고려해야 함은 물론이고, 각 지역에서 즐겨 사용하거나 싫어하는 이미지나 형상 등에 대한 고려도 필요한 것이지요.
언젠가 이와 관련된 이야기를 들은 적이 있습니다. 컴퓨터 서적 중에 ‘빨간 책’으로 유명한 녹스(Wrox)가 초반기에 유독 일본에서 고전했던 이유가 바로 그 트레이드 마크인 ‘빨간 색 표지’ 때문이었다고 합니다. 녹스 본사는 빨간 색을 포기할 수 없다고 하고, 일본 독자들은 빨간 책표지를 극도로 싫어했다나요? 이처럼 아무것도 아닌 것 같은 많은 사항들이 고려화된 상태의 프로그램을 우리는 현지화된 프로그램이라고 부를 수 있을 것입니다.
M17N(multilingualization)
다국어화를 지칭하는 이 용어는 사실 개별적으로 다루어져야 할지도 모르겠습니다. 일반적으로 다국어 버전의 프로그램이라면 단순한 메시지의 번역이나 최소한의 기본적인 사항들을 지키는 프로그램을 의미한답니다. 각 언어별로 제대로 현지화된 버전의 프로그램을 제공하는 것은 어지간한 개발자들에겐 힘에 부치는 일이 아닐까 싶습니다.
간단한 용어정리부터!
전문가가 된다는 것은 전문용어를 많이 안다는 것이라는 말이 있지요. 우리도 우선 간단한 용어들부터 정리하고 본격적인 이야기에 들어가 보기로 합시다.
문자 집합
각 나라의 언어들은 그 말을 표현하기 위한 문자들을 가지고 있습니다. 이를 컴퓨터 상에서 나타내기 위해 필요한 것이 바로 문자 집합(character set)입니다. 예를 들자면 한글을 표현하기 위해서는 KSC-5601 완성형을 사용할 수도 있으며, 조합형을 사용할 수도 있습니다. 이와 같이 하나의 언어에도 여러 가지의 문자 집합이 존재할 수 있습니다.
코드 페이지
코드 페이지(code page)는 쉽게 말하면 문자나 특수 문자를 숫자로 표현한 대조표 같은 것이라고 해야겠습니다. 1 바이트 코드 페이지는 8비트를 사용하여 기본적으로 256개의 문자를 가지고 있습니다(본 연재의 내용이 기본적으로 윈도우 환경을 다루고 있으므로 그 기준에 맞춰 설명하겠습니다). 첫 128개는 표준 ASCII 문자들로 구성되어 있으며 이 속에 기본적인 영어의 알파벳 문자들이 들어 있습니다. 나머지 128개의 공간에는 각 언어별로 특별히 사용되는 문자들이 들어 있습니다. 독일어의 ß, 프랑스어의 c 같은 문자들이 이에 해당됩니다. 물론 우리나라나 중국, 일본, 대만 등의 2바이트 코드 페이지를 사용하는 국가는 이런 1바이트 코드 페이지로는 표현할 수 없는 문자들이 너무 많습니다.
유니코드
코드 페이지 간의 여러 문제점을 해결하기 위해 유니코드(unicode)라는 새로운 아이디어가 등장하게 된 것은 그리 오래된 일은 아닙니다. 유니코드에 대한 기본적인 설명은 유니코드 공식 웹 페이지(www.unicode.org)를 참조하는 것이 좋겠습니다. 여기서 그 내용을 간략히 살펴보겠습니다(www.unicode.org/standard/translations/korean.html).
컴퓨터는 기본적으로 숫자만 처리합니다. 글자나 다른 문자에도 숫자를 지정하여 저장합니다. 유니코드가 개발되기 전에는 이러한 숫자를 지정하기 위해 수백 가지의 다른 기호화 시스템을 사용했습니다. 단일 기호화 방법으로는 모든 문자를 포함할 수 없었습니다. 예를 들어 유럽 연합에서만 보더라도 모든 각 나라별 언어를 처리하려면 여러 개의 다른 기호화 방법이 필요합니다. 영어와 같은 단일 언어의 경우도 공통적으로 사용되는 모든 글자, 문장 부호 및 테크니컬 기호에 맞는 단일 기호화 방법을 갖고 있지 못했습니다.
이러한 기호화 시스템은 또한 다른 기호화 시스템과 충돌합니다. 즉 두 가지 기호화 방법이 두 개의 다른 문자에 대해 같은 번호를 사용하거나 같은 문자에 대해 다른 번호를 사용할 수 있습니다. 주어진 모든 컴퓨터(특히 서버)는 서로 다른 여러 가지 기호화 방법을 지원해야 합니다. 그러나, 데이터를 서로 다른 기호화 방법이나 플랫폼 간에 전달할 때마다 그 데이터는 항상 손상의 위험을 겪게 됩니다.
유니코드는 사용 중인 플랫폼, 프로그램, 언어에 관계없이 문자마다 고유한 숫자를 제공합니다. 유니코드 표준은 Apple, HP, IBM, JustSystem, Microsoft, Oracle, SAP, Sun, Sybase, Unisys 및 기타 여러 회사와 같은 업계 선두주자에 의해 채택되었습니다. 유니코드는 XML, Java, ECMAScript(JavaScript), LDAP, CORBA 3.0, WML 등과 같이 현재 널리 사용되는 표준에서 필요하며 이는 ISO/IEC 10646을 구현하는 공식적인 방법입니다. 이는 많은 운영 체제, 요즘 사용되는 모든 브라우저 및 기타 많은 제품에서 지원됩니다. 유니코드 표준의 부상과 이를 지원하는 도구의 가용성은 최근 전 세계에 불고 있는 기술 경향에서 가장 중요한 부분을 차지하고 있습니다.
유니코드를 클라이언트-서버 또는 다중-연결 응용 프로그램과 웹 사이트에 통합하면 레거시 문자 셋트 사용에 있어서 상당한 비용 절감 효과가 나타납니다. 유니코드를 통해 리엔지니어링 없이 다중 플랫폼, 언어 및 국가 간에 단일 소프트웨어 플랫폼 또는 단일 웹 사이트를 목표로 삼을 수 있습니다. 이를 사용하면 데이터를 손상 없이 여러 시스템을 통해 전송할 수 있습니다.
유니코드 컨소시엄은 비영리 조직으로서 현대 소프트웨어 제품과 표준에서 텍스트의 표현을 지정하는 유니코드 표준의 사용을 개발하고 확장하며 장려하기 위해 세워졌습니다. 컨소시엄 멤버십은 컴퓨터와 정보 처리 산업에 종사하고 있는 광범위한 회사 및 조직의 범위를 나타냅니다. 컨소시엄의 재정은 전적으로 회비에 의해 충당됩니다. 유니코드 컨소시엄에서의 멤버십은 전 세계 어느 곳에서나 유니코드 표준을 지원하고 그 확장과 구현을 지원하고자 하는 조직과 개인에게 개방되어 있습니다.
이 내용을 다시 한번 정리하면 유니코드는 플랫폼, 프로그램, 언어에 상관없이 모든 문자에 대해 고유 번호를 제공한다는 개념입니다. 현재 유니코드는 4.0까지 그 표준이 정의되어 있는 상태이며, 유니코드에 대한 내용은 추후 다시 자세히 다뤄보기로 하겠습니다.
다국어 프로그램으로 가기 위해 고려해야 할 사항들
왜 다국어 프로그램과 관련된 부분의 코드를 따로 관리해야 하는가?
너무나 당연한 이야기이겠지만 한 번 짚어보고 넘어가야 할 사항이 바로 이 문제입니다. 가장 쉽게 다국어 프로그램을 만드는 방법은 일단 프로그램을 모두 작성한 후에 이를 해당 언어의 프로그래머에게 넘겨 그 언어 버전으로 번역하고 변경하게 하는 방법이겠지요. 이런 접근 방식에는 다음과 같은 여러 문제점이 있을 수 있습니다.
◆ 언어가 많아지면 많아질수록 각 언어를 담당하는 개발자 또한 늘어나야 하므로 회사 입장에서는 자금이 더 필요하게 됩니다.
◆ 각 언어에 한정된 코드가 포함되어 코드 읽기와 수정이 불편해집니다. 코드 곳곳에 조건문이나 분기문을 사용해서 각 언어에 따른 코드가 생기게 되면 코드의 가독성이 떨어질 것은 자명한 일입니다.
이러한 문제를 사전에 방지하려면 ‘반드시’ 다국어 프로그램에 관련된 부분은 따로 관리하는 것이 옳겠지요? 즉, 개별적인 데이터베이스나 텍스트 파일, 리소스 파일 등을 이용해 이와 관련된 부분을 분리해내야 합니다.
개발시 고려해야 할 부분은 과연 어떤 것들인가?
Locale이란?
사용자의 언어 사용 환경을 말할 때 흔히 사용되는 로케일이란 단어에는 단순한 언어(language) 이상의 의미가 담겨 있습니다. 즉, 현지화에 필요한 모든 정보들을 포함한 환경이 바로 로케일이라고 말할 수 있습니다.
숫자, 날짜, 화폐 형식, 측량 단위
숫자
숫자의 경우 주로 자릿수를 나누는 부호가 문제가 됩니다. 우리나라에서는 4,124.1과 같이 자릿수를 나누는 데는 쉼표를 소수를 표현하는 데는 점을 사용하지만, 이 두 부호를 바꿔 사용하는 나라들도 있습니다.
화폐
화폐의 단위도 숫자와 마찬가지 경우로 다양한 방식이 존재합니다. 간단한 사실만 비교해 보아도 우리나라의 경우 ￦1,000이나 1,000원으로 표기하지만 미국의 경우 1$처럼 단위를 표시하는 문자의 위치가 우리와 다른 곳에 위치합니다.
날짜와 시간
날짜의 경우 년도, 월, 일 순으로 표기하는 국가, 월, 일, 년도로 표기하는 국가, 일, 월, 년도의 순으로 표기하는 국가 등 여러 가지 변형이 있으며, 시간의 경우도 오전 오후 12시간 단위로 사용하는 나라도 있고, 24시간 단위로 사용하는 나라도 있습니다.
사용자 인터페이스와 관련된 문제들
폰트
폰트는 그 사용과 배포에 있어 여러 가지 권한을 가질 수 있습니다.
◆ Restricted licence embedding : 문서 내에 폰트가 포함될 수 없습니다.
◆ Print & Preview embedding allowed : 문서 내에 폰트가 포함될 수 있지만 반드시 임시적으로만 설치돼야 합니다. 문서는 읽기전용으로만 읽을 수 있습니다.
◆ Editable embedding allowed : 문서 내에 폰트가 포함될 수 있지만 반드시 임시적으로만 설치돼야 합니다.
◆ Installable embedding allowed : 문서 내에 폰트가 포함될 수 있으며, 폰트를 영구적으로 설치하는 것이 가능합니다.
이러한 폰트의 특징을 이해하고 각 언어 로케일마다 적절한 폰트를 정의해야 합니다. 일반적으로는 각 언어의 시스템에서 사용하고 있는 기본 폰트를 따르는 것이 좋으므로 자동으로 시스템의 로케일과 기본 폰트를 사용할 수 있도록 코드를 작성해야 합니다.
공간
영어 로케일의 시스템인 경우 폰트의 기본 크기는 8pt가 됩니다. 하지만 2바이트 문자인 우리나라, 일본, 중국의 기본 폰트 크기는 9로 지정되어 있습니다. 이런 경우 영어 프로그램에 맞춰 컨트롤의 크기를 정해 둘 경우 메시지가 잘려 보이는 수가 많습니다. 또한, 각 언어마다 똑같은 의미를 전달하더라도 메시지의 길이는 제각각일 수도 있겠지요? 이런 경우 컨트롤의 내용을 모두 보여주는 데 필요한 크기의 길이를 자동적으로 계산해서 컨트롤의 크기를 적절히 조정해 주는 함수를 작성하는 것이 도움이 됩니다.
데이터의 정렬 순서
데이터의 정렬 문제는 자칫 빼먹고 지나쳐 버릴 수 있는 문제입니다. 예를 들어 유럽 언어의 경우에는 기본적인 영어 알파벳 순서 군데군데에 문자들이 추가되는 경향이 있습니다. 체코어 같은 경우는 ch가 하나의 문자로 인식되어 영어 알파벳 h 바로 뒤에 나타나야 하며, 대부분의 로케일에서 a 뒤에 나타나는 a의 경우 노르웨이어에서는 z 뒤에 정렬돼야 하는 등의 문제가 있습니다.
또한, 중국, 한국, 일본의 경우는 그 문제가 더욱 심각합니다. 우리나라의 경우는 기본 정렬 순서가 KSC 순서라고 알려진 방식이며, 이 방식으로 정렬할 경우 한글과 한자 문자들이 섞일 수 있습니다. 일본어가 포함된 경우는 유니코드의 순서를 따르기도 합니다.
입력 방식
간단히 영어와 한글의 경우만을 비교해 봐도 영어의 경우는 키보드를 한 번 누를 때 하나의 문자가 입력되지만, 한글의 경우 키보드를 두 번 이상 눌러야 하나의 글자가 구성됩니다. 또한, 입력 방식도 2벌식 3벌식으로 나눌 수 있어 하나의 언어를 입력하는 방식도 하나 이상 존재할 수 있습니다.
그 외에 고려해야 할 부분은 과연 어떤 것들인가?
다음의 각 사항에 대한 자세한 이야기는 연재를 계속해가며 다뤄보기로 합시다.
◆ 웹 애플리케이션
◆ 국제화된 소프트웨어 테스트하기
◆ 문서 작업
기초를 확실히
이번 연재에서는 실제적으로 코드를 통해 다국어 프로그램을 작성하기 이전에 갖춰야 할 지식에 대해 알아보았습니다. 다국어 프로그램을 이야기할 때 흔히 등장하는 용어들에 대해 알아보고, 프로그램 작성시 미리 고려해 두어야 할 사항들이 무엇인지에 대한 이야기도 나누었습니다. 다음 시간에는 비주얼 베이직을 이용해 다국어 버전 프로그램에 실제로 도전해 보기로 하겠습니다.@
* 이 기사는 ZDNet Korea의 자매지인 마이크로소프트웨어에 게재된 내용입니다.
지금 뜨는 기사
이시각 헤드라인
ZDNet Power Center
