1997년 쯤에 학교 수업의 리포트로 작성했던 소프트웨어 메시지의 "국제화"와 "지역화"에 대한 리포트입니다. 유니코드가 제안되고 얼마 지나지 않은 시기에 작성된 내용이라서 잘못된 부분이 많을 수 있으니 주의하시기 바랍니다.
국제화와 지역화(현지화)의 문제는 인터넷을 매개로 하는 웹 세계의 가장 근원적인 목표이다. 비단 웹에서만의 문제는 아니지만, 인터넷은 엔드-유저(end-user)에게도 쉽게 접근할 수 있는 대상으로 다가왔기 때문에, 웹에서의 국제화/현지화의 문제는 다른 분야(e-mail전송,X window 프로그램개발)에서보다 더 두드러지게 중요한 이슈로 떠오르고 있다. 이에 이 문서에서는 일반 사용자에게는 물론이고, 프로그램 개발자나 웹 디자이너, 시스템 관리자에게조차 생소하고 요원해 보이는 국제화 세계화 문제에 대해서 가벼운(기술적이지 않은) 접근을 해보고 그 문제점과 해결방안에 대해서 그리고 마지막으로 한글화에 대해서 살펴보기로 하겠다.
인터넷이란 말 그대로 전세계에 걸쳐있는 네트웍들이 모여 있는 것인데, 전세계의 사람들이 인터넷을 사용하기 때문에 각 민족의, 각 국가의 언어들이 표현되어야 하는 문제점이 대두된다. 여기에서 파생하는 문제점들에 대해서 알아보고 왜 표준이 필요한가의 이유도 알아보자.
다른 글자를 encoding하기 위한 표준을 정해야 하는 문제점이 있다. 예를 들면, A나라의 B시스템에 있는 홈페이지를 C나라의 D시스템을 사용하는 어떤 사용자가 보려고 한다면 B가 보내주는 A나라언어가 encoding된 자료를 전송할 것이다. 그러면 C나라의 사용자는 A나라언어가 encoding되는 방식에 대해서 훤히 알고 있어야 할 것이다. 아니면 D시스템이 A encoding기법을 알아서 변환해주어야 할 것이다. 이러면 각 나라의 수를 n이라 할 때, n^2의 complexity가 발생한다. 이러한 문제를 해결하기 위해 공통의 표준이 필요해지는 것이다.
다른 나라의 글자는 encoding뿐만 아니라 glyph(모양)에 대해서도 알아야 하기 때문에, 실제로 텍스트만 주고 받아야 하는 게 아니라 font도 필요하다. 그런데, font는 크기가 크기 때문에 네트웍으로 주고받는 것에는 문제가 있다. 그러면 web browser가 각 국의 언어 font를 가지고 있어야 한다. 그러나 n^2의 문제가 여전히 남는다. 하드디스크가 모자라는 상황에 닥치게 되는 것이다.
URL을 표시하기 위해서는 ASCII코드 범위내에서만 가능하다. 그런데 각 나라 언어로도 URL을 표현해야 하는 경우가 생긴다. "index.html"과 같이 영어로 된 파일의 경우 별 문제가 없지만, "보고서.html"이라는 이름의 파일은 URL로 나타내기 좀 까다롭다.
character set과 encoding의 문제점은 Unicode라는 전세계적인 일반성을 보유한 코드셋으로 종합되어져서 해결이 된다고 한다. 그래서 W3C는 Unicode를 web을 표현하기 위한 수단인 HTML과 XHL, CSS등에 포함되도록 표준화했다.
최소기반을 Unicode로 하여, 각 언어의 encoding을 표현할 수 있도록 확장하였다. 만약 encoding중에서 표현할 수 있는 코드가 아니라면 Unicode로 표현할 수 있도록 한다. encoding뿐만 아니라 그 encoding을 다루는 알고리즘을 포함하는 것이다. 현재는 여러 언어를 혼합된 Hyper-text를 만들 수 있으며, 혼합된 쓰기 방향(오른쪽에서 왼쪽으로 쓰는 것도 가능함)이 지원된다.
XML은 HTML과 같은 text를 구성하는 markup language이며,Unicode를 기반으로 하여 혼합된 encoding을 사용하 수 있다.
영어가 아닌 글자로 쓰여진 Cascading Style Sheet는 backslash를 이용한 reference를 지정하여 Unicode로 표현할 수 있다. CSS2에서는 사용자가 직접 자신의 Unicode범위를 지정할 수 있다.
HTTP가 1.1이 되면서 1.0에서는 권장사항 이었던 Content-type의 header를 필수적으로 따르도록 규정했다. charset(character set) parameter에 따라 browser가 encoding방식을 결정하게 된다. 브라우저가 서버에게 자신이 처리할 수 있는 언어에 대해서 알려주게 되면 서버는 그에 알맞는 언어를 골라서 헤더에 정보를 실어서 보내게 된다. 그러면 브라우저는 처리가능한 언어로 문서를 받을 수 있는 것이다.
W3C에서는 자신들이 해결할 과제를 다음과 같이 밝히고 있다.
Unicode는 ISO-10646 UCS라는 이름의 표준이며 1바이트를 1글자로 보았던, ISO-2022 와는 달리 character set을 4바이트범위에서 정의하게 되므로 보다 유연한 code set을 제공하게 된다. 이전의 코드는 영어 및 서유럽어만을 지원(ISO-2022)했었으나 이제는 각국의 언어가 모두 하나의 character set안에서 표현이 된다는 점이 Unicode의 장점이 되었다.
프로그램의 개발이나 배포, 사용 등에 있어서 효율적이고 용이하다는 점은 높이 살만 하지만, 한국, 중국, 일본의 언어에 대한 진지한 배려가 약간은 부족했고 (특히나 charater의 순서가 임의적이라서 자료정렬에 추가적인 노력이 필요할 것으로 본다. 특히나 한자어의 경우에는 이러한 문제가 심각할 것으로 본다.) 미국 컴퓨터 업체들(Apple, Metaphor, RLG, Sun,Xerox)이 모여서 만든 업계 표준이라서 미국이 주도하고 강권하는 표준이라는 점에서는 아직 부족한 점이 있다.
미국 업체들의 주도로 만들어졌다는 건 Unicode를 통해 프로그램의 다국어 버전을 만들어서 세계시장에 판매를 하려는 의도가 엿보이는 점이다. 이 문제야 어쩔 수 없는 점이라 쳐도, 한글이 초성, 중성, 종성으로 이루어졌는데도 자음과 모음이라는 단순한 구분으로 한글을 사용하도록 정해졌다는 점은 향후 웹에서의 한글 운용에 제약이 가해질 것을 예상할 수 있다.
I18N이 제대로 갖추어진다고 해도 실제의 프로그램이나 웹 페이지가 사용되는데에는 반대의 측면인 L10N이 뒷받침되어야 한다. I18N에 따라서 제작된 문서나 resource를 번역하여 한국어 locale에 추가하는 일은 L10N에 속하는 일이 될 것이다.
한국에서는 이러한 작업들이 소수의 관심있는 사람들(특히나 technician)들을 중심으로 이루어져 왔는데, 인원도 적을 뿐만 아니라 표준 (최우형씨의 권고안인 RFC 1557이 지켜지고 있는 것이 드물거나, 제대로 지켜지지 않고 있다.)에 따라서 행해지고 있는 것이 아니라서 이런 문제에 대해서 뒤늦게 뛰어든 업체들이나 MS같은 다국적 기업들이 중심이 되는 협의안에 의해 무시당하는 경우가 발생할 가능성이 있다. (참고로, 이러한 협의회에서는 업체의 이익을 대표하는 비전문가들이 중심이 되어 업체의 표준을 제시할 뿐이고, 학교나 비영리단체에 대한 배려가 없다.)
뉴스그룹 han.comp.hangul에서 한글화와 그 관련 프로그램과 규약에 대한 논의가 진행되고 있으나 이러한 논의들이 국가 표준이나 업체 표준에 반영될 지는 미지수이다. 조그만 활동들이 큰 변화의 물결 속에서 의미를 잃어버리지 않도록 L10N에 관련된 작업들이 하나의 커다란 목표 아래서 재정비되어야 할 것이라고 본다.
개인적으로는 internationalized되어 있는 X window 프로그램의 localization에 관심이 있는데, 이러한 것들에서도 표준이 제대로 제시되어 있지 않아서(RFC 1557도 계속 수정되고 있는 것으로 알고 있다.) 비슷한 형태의 작업에 상당히 많은 시간을 낭비하게 된다.
사실 글자 집합과 인코딩은 모호한 개념이고 표준이라 불리우는 것도 도대체 어느 것을 지칭하는지 구분짓기 어렵다. 문자셋과 인코딩에 관한 구분은 신정식씨의 커멘트에 기반하여 정리해 보았다.
한글 코드 또는 한글 character set이라고 부르는 글자 집합은 KSC-5601, KSC-5657, KSC-5700이라는 표준에 의해 정의되었다. 글자 집합이란 테이블 내의 어떤 위치가 어떤 글자를 가리키는가에 대한 정의가 만들어져 있는 것을 의미하며, 한글 코드는 계속 새로운 글자들이 추가되는 쪽으로 개선되어 왔다. 이밖에도 MS에서 사용된 통합완성형 한글과 동국대와 부산대에서 제안한 첫가끝코드(정음형코드)같은 것도 있으나 국가 표준(KSC-xxxx)가 아니므로 여기서는 생각하지 않는다.
인코딩은 글자 집합 내의 특정한 자소를 가리키는 위치를 나타내는 bit stream을 어떻게 만들 것인가에 관한 규칙인데, 여기에는 EUC-KR, ISO-2022-KR, ISO-2022-Int등이 있다. 이처럼 인코딩과 글자 집합에 관한 표준은 서로 독립적으로 존재하는데 이러한 독립적인 성격 때문에 인코딩에 여러 가지 방식이 존재하게 되고 이러한 방식을 모두 지원하기 위해서 한글을 다루는 프로그램들은 복잡한 기능을 탑재하거나 한글처리를 전문적으로 해주는 필터를 장착해야한다.
인코딩방식이 크게 세가지로 사용되는데에는 근원적인 이유가 존재하는데, 그것은 EUK-KR은 자료 저장에 사용되고, ISO-2202-KR은 메일 전송에 사용되며, ISO-2202-Int는 Mule(Multi-language Emacs)에서 사용되고 있는 식으로 쓰이는 곳이 다르기 때문이다. 8비트 메일 전송이 거의 표준처럼 사용되고 있는 현실이기는 하지만, 과거 7비트로 처리하던 시스템과의 호환문제나 외국과의 메일 교환에 따르는 문제점들이 계속 남게 되므로 쉽게 해결될 조짐이 보이지 않고 있다.
개인적으로는 아마 charset으로는 8bit인 EUC-KR이 표준이 되고 QP/Base 64 MIME encoding이 전송Encoding으로 사용될 것 같다. 그러나 근원적인 해결은 ISO-2022가 개선되는 것이다. 7bit만을 전송할 수 있도록 규정해놓은 영어문화권 국가들 중심의 표준이 국내 문제에서도 한계를 지어놓은 좋은 예이다. 표준이란 모두의 편의를 위해서 존재해야 하는 것이므로 특정 언어에만 편의를 제공하는 표준은 개선되어야 할 것이다.
95년에 채택된 한글코드의 표준인 KSC-5700은 Unicode와 궤를 같이 하고 있다. 그러나 아직은 그 코드를 어떻게 구현할 것인가의 문제가 해결되지 않았다고 봐야 한다. 대부분의 업체들은 구현하기 쉬운 완성형을 택할 것으로 보는데, 이런 식으로 방치하게 되면 아마 완성형이 암묵적인 표준이 될 것으로 본다.(현재 조합형이 쓰이고 있는 것은 몇몇개의 한글 전문 프로그램에 국한되고 있다.) 한글 창제 원리나 다양한 표현 가능성을 염두에 두면 한글코드의 표준도 아직은 문제점에서 벗어났다고 볼 수는 없다. 이제는 더이상 87년의 과오(KS완성형만을 표준으로 삼았던 KSC-5601과 같은 정부 주도의 표준)를 되풀이 해서는 안 될 것이다.