[지디넷코리아]이번 연재를 통해 하고자 하는 이야기는 국제화 시대의 프로그래머가 되기 위해 필요한 이야기입니다. 근사한 다국어 버전 프로그램을 작성하는 것이 혹시 여러분의 오랜 소망은 아닌가요? 다국어 프로그래밍에 대한 이야기를 본격적으로 하기 전에 우선 간단한 용어 정리로 가볍게 몸을 풀어 봅시다.

다국어 프로그램의 단계
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까지 그 표준이 정의되어 있는 상태이며, 유니코드에 대한 내용은 추후 다시 자세히 다뤄보기로 하겠습니다.