[ Home | Freetime works | FreeBSD | KFUG ]
프로그램세계 1999년 11월호이러한 것은 운영체제의 면과, 어플리케이션의 면으로 나누어 볼 수 있는데, 대체적으로 운영체제의 핵심 부분(커널과 C라이브러리)의 개발자들은 국제화에 대한 관심을 갖기 보다는 시스템의 성능 향상이나 다기능에 더욱 초점을 맞추며, 이러한 쪽의 사람도 부족한 것이 현실이다. 또한 현존하는 프로그램을 당장 지역화하는데 시간을 쓰는 것이 현명한 일인지, 또는 국제화의 표준에 맞추도록 하는 것이 중요한지도 생각해야 하는 문제이다. 이러한 문제들에 대해 생각해 보자.
지역화 경향은 해당 지역의 사용자들에게 당장 사용할 수 있는 방법을 제공한다는데 의의가 있지만 패치의 난립에 따른 시스템의 분열과, 표준과의 상충이라는 두가지 문제를 안고 있다. 하지만 지역화가 필수적이어야만 하는 경우가 있는데, 국제화 표준에 속하지 않는 대상의 언어, 문화권, 문자셋이나, 독립적으로 사용할 수 있는 프로그램이 그런 부류에 속한다. 유닉스 상의 로케일 시스템이라고 해도 시스템마다 그 구현의 정도나 방식, 지원 범위가 천차 만별이므로, 아직은 한가지의 로케일 시스템에 의존한 프로그램 개발은 거의 불가능하다고 보아도 된다. hanterm이나 hanemacs등이 기존 시스템과 독립적으로 한글 구현이 가능한 예인데, 이러한 일을 위해 입출력을 위한 함수들을 내장하고 있는 것이 특징이다. 한국어의 경우 이러한 입출력 방법이 비교적(!) 간소하여 내장에 큰 무리가 없지만, 일본어 등은 그렇게 쉽지 않다.
그럼에도 불구하고 지역화의 존재는 피할 수 없다. 현재의 로케일 모델은
한국어에 대한 내용을 거의 모든 경우에 포함하고 있으므로 우리나라의
경우 걱정할 것은 별로 없지만 그렇지 않은 언어 등도 많기 때문이다.
그리고 국제화 모델에서 제공하지 않는 여러가지 면(프린터 출력 등)에
대해서는 독자적으로 해결해 나갈 수 밖에는 없다.
glibc 2.0.x의 경우 libwcsmbs라는
일본에서 개발된 libc 확장을 사용하면 유니코드 기반의 멀티바이트 변환
시스템을 얻을 수 있다. 앞으로 발표되는 glibc 2.2에서는 멀티바이트에
대한 완전한 유니코드 기반 지원이 계획되고 있으며, 2.1에도 어느 정도
포함되어 있다.
FreeBSD는 XPG4에 기반한 로케일 시스템을 갖고 있으며, 이는 원래 4.4BSD
의 libc 소스에 기반한 것이다. 하지만 그 구현은 glibc의 그것과 완전히
다르며, 멀티바이트의 경우에는 EUC코드만을 지원하고 있다. 동종의 BSD
시스템(OpenBSD, NetBSD등)도 마찬가지 경우인데, 부가적으로 중국의
Big5인코딩이나 일본의 SJIS와 같은 로케일 지원이 추가되어 있는 경우도
있다.
솔라리스나 Tru64 유닉스 등에서도 독자적인 로케일 시스템을 갖고 있다.
이러한 시스템의 큰 차이는 바로 한국어 등의 설정에서 LANG, LC_ALL,
LC_CTYPE등의 환경 변수를 어떻게 지정하는지부터가 달라지게 되는데,
시스템마다 한국어 로케일을 지정하기 위해서는 다음과 같이 해야 한다.
이들은 모두 기본적으로 EUC-KR 인코딩 시스템의 한국어 로케일 시스템을
가리킨다.
로케일
POSIX 또는 XPG4의 로케일 시스템은, 일반적으로 시스템마다 모두 다르다.
리눅스에서도 libc5까지는 주로 1바이트 언어권만을 지원하고 있었으며,
메시지 시스템도 catopen()시스템을 사용하였지만 glibc에 넘어오고
별도로 GNU gettext가 개발되면서 이런 점은 바뀌기 시작하였다. glibc는
현재 1바이트 언어권을 충실히 지원하고 있고, 2바이트 언어에 대한 지원도
일부 포함되어 있지만 온전하지는 않은 실정이다.
Linux glibc2
ko_KR.eucKR, ko
FreeBSD
ko_KR.EUC
Solaris 2
ko, korean
LANG 환경변수: 유닉스의 환경변수는 프로세스 실행 환경의 일부이므로, 쉘 등에 관계없이 현재 실행 환경의 여러가지 면을 조정하기 위해 사용된다. 로케일 시스템에서 LANG환경변수는 기본적인 시스템 로케일을 지정하기 위해 사용되는데, 구체적으로는 LC_xxx 식의 카테고리를 모두 한꺼번에 지정하는 것과 같은 효과를 얻는다. 가령 인코딩은 한국어, 시간 표시는 미국식으로 유지하고 싶을 때가 있다. 특정 카테고리에 대한 로케일을 지정하기 위해서는 xxx에 카테고리를 지정하면 된다. 카테고리에는 ALL(전체, LANG와 동일한 효과), CTYPE(문자 인코딩), MONETARY(통화표시), TIME(시간 표시 형식), MESSAGES(메시지 표시) 등이 있다.
최근에는 유니코드가 널리 통용되면서, 로케일 시스템도 유니코드를 지원하는 것이 있다. 또한 이전의 ISO-2022를 지원하는 시스템 등에서는 한국어가 반드시 EUC-KR인코딩이라는 보장이 없으므로, ko, ko_KR등이라고 쓰는 경우에는 실제로 어떤 인코딩을 가리키는지에 주의하는 것이 좋지만, 실제로는 거의 모두가 EUC-KR을 가리키고 있다.
X 윈도우 시스템
X윈도우 시스템은 2바이트 글꼴 처리 등을 위한 함수들을 X11R5이후부터
내장하고 있으며, 이들은 유닉스의 로케일 시스템에 의해 사용 여부가
결정될 수 있다. X윈도우 시스템의 구현 중 하나인 XFree86은
공개 유닉스의 표준 윈도우 시스템으로 사용할 수 있지만 모든
시스템에서 동일한 로케일 시스템을 지원하지 않으므로, 선택에 따라
내장된 X윈도우 로케일 시스템을 사용할 수도 있고 시스템의 로케일을
사용할 수도 있다. 이전에 X_LOCALE이라고 불리던 것은 바로 한국어
로케일이 제대로 지원되지 않던 리눅스의 libc5나 FreeBSD 2.1등의 시스템
에서 한국어 로케일로 초기화될 수 있는 X윈도우 위젯 등을 사용하기 위해
사용하는 방법이었다. X시스템의 설치를 위한 설정이나 프로그램을 컴파일
할 때 X_LOCALE을 C의 #define으로 정의해 두면 X는 독자적인 로케일
시스템을 사용한다. 현재로서는 완벽하지는 않지만 로케일의 정의가
가능하므로 거의 사용하지 않게 되었지만, 사실 이 완벽하지 않다는 점
때문에 넷스케이프에서의 한글 입력 등에서 여러가지 문제를 발생하게
되었다(물론 그 문제는 여러가지 원인이 복합적으로 작용한다).
최근 gtk+등 X툴킷에 기반하지 않는 GUI위젯 시스템은 이러한 X윈도우의
로케일 모델에 직접적으로 의존하지 않고, 시스템의 로케일 지원에
의존한다. 따라서 이러한 시스템의 경우라면 X_LOCALE의 정의 여부가
큰 의미를 갖지 않지만, 적어도 X윈도우 시스템은 반드시 해당 언어의
지원을 포함하도록 컴파일되어야 한다.
앞서 말한 것과 같이 유닉스의 경우 로케일 시스템에 기반을 둔 국제화 경향은 현재는 거의 일반적이 되었다. 그러나 국제화에서 다룰 수 있는 방식에는 한계가 있어서, 현재로서는 다음과 같은 것이다.
대부분의 어플리케이션은 위의 범주 내에서 어플리케이션 작성이 가능하므로 그리 걱정할 필요는 없다. 하지만 이의 범주 이외에 속하는 프로그램을 작성하는 데에는 국제화 모델은 별 쓸모가 없는 것이 되어 버린다. 따라서 이러한 시스템의 경우 독자적인 구현이 필요한 경우가 많다.
유닉스에서 화면 출력방식과 달리 프린터 출력은 모두 해당 시스템의 구현에 맡기고 있다. 이는 곧바로 어플리케이션 프로그래머의 부담으로 이어지는데, 따라서 일반적인 유닉스 어플리케이션의 출력은 화면 출력이 가능할지라도 프린터 출력이 불가능한 경우가 많다. 주도적인 프린터 공급업체의 경우 이러한 문제를 해결하기 위한 몇가지 방안을 내놓고 있지만, 아직 널리 받아들였다고 보기에는 어려운 점이 많다.
hcode나 hmconv와 같은 유틸리티는 국제화 모델에서 제공하지 않는 여러가지 인코딩(3바이트나 상용 조합 이외의 인코딩 등)을 지원하고 있다. 국제화 인코딩 지원 프로그램은 현재 GNU 자유 번역 프로젝트를 이끌고 있는 Francois Pinard의 GNU recode가 있지만, recode는 현재 유럽 언어 등에 대해서는 잘 지원하지만 동아시아권의 멀티바이트 인코딩에 대해서는 지원이 부족하다. 물론 recode도 로케일 모델에 존재하는 프로그램은 아니지만 다국어 지원에 신경쓰는 점이 많으므로, 도와주는 사람만 있다면 한국어 인코딩 등도 포함될 수 있을 것이다.
사실 커널 프로그래밍이나 네트워크 프로그래밍 등의 분야는 국제화나 지역화의 여부가 중요하지 않은 경우이고, 국제화나 지역화는 직접 사용자와 접촉하는 경우에만 중요한 경우가 대부분이다. 따라서 이러한 시스템 프로그래밍이라면 국제화 문제 등에 신경쓸 필요가 거의 없을 것이다. 하지만 커널에 관심 있는 독자라면 콘솔에서의 한국어 처리 등에 관심을 가지고 지켜보는 것이 좋을 것이다. 리눅스 커널 2.2에서는 프레임버퍼 콘솔을 사용하여 임의의 문자를 비교적 자유롭게 그릴 수 있는 환경이 마련되었고, FreeBSD의 경우에도 기본 콘솔 시스템인 syscons에서의 국제화 방식에 대해 논의가 있었다.
MiziOS는 미지리서치의 개인용 리눅스 배포본이다. 이 OS에 의의를 두는 이유는 바로 최초로 흩어져 있던 국내 개발자들이 가장 많이 모여서 개발하고 있는 리눅스 배포본이라는 것이다. 한국어 사용에 불편함이 없도록 개발하고 있는 리눅스 배포본들은 여러가지가 있지만, 가장 공개적으로 운영되고 있는 것은 MiziOS가 좋은 예를 보여주고 있다. 이러한 방식의 개발이 국내에서도 가능하였다는 것은 현재 국내의 리눅스 개발자도 상당히 늘어났다는 점을 증명하는 것이 아닌가 한다. 물론 앞으로의 발전 과정도 계속 그러한 방식으로 진행될 것인지는 조금 더 두고 보아야 할 것이다. rpm기반의 시스템 개발에 관심있는 사람들은 개발자 메일링 리스트에 가입해 보자.
http://linux.mizi.co.krMiziOS의 개발과 함께 이루어진 반가운 소식 중의 하나는, 자유롭게 사용 할 수 있는 한글 글꼴들이 대거 공개되었다는 것이다. (주) 우더아트의 백묵 글꼴 4종이 그것인데, 이는 윈도우나 솔라리스, IRIX등의 상용 운영체제에서 대부분 제공하고 있는 굴림, 바탕, 돋움, 궁서체 등에 대한 대안을 제공하고 있다. 백묵글꼴은 트루타입의 형태로 개발되어 있고, 이를 X 비트맵 글꼴로 변환한 것이 있는데, 다음 장소에서 다운로드받을 수 있다.
ftp://ftp.mizi.co.kr/pub/baekmuk위 사이트에서는 rpm형태의 글꼴 패키지를 다운로드받을 수 있으며, 현재 Debian-kr이나 FreeBSD에서는 패키지의 형태로 백묵글꼴 패키지를 다운로드받을 수 있다. 백묵 글꼴의 장점이라고 한다면 먼저 공개된 글꼴 이라는 점이지만, 그것만으로는 충분하지 않다. 실제로 공개되어 있는 글꼴은 여러가지가 있지만, 상용 글꼴의 좋은 점은 미려한 화면 표시를 위해 약 9-14포인트 이내의 화면용 비트맵 글꼴이 일일이 수작업을 통한 힌팅 처리가 되어 있다는 것이다. 백묵 글꼴도 예외는 아니어서 현재 수작업으로 해결해야 하는 힌팅 문제가 남아 있으며, 언제라도 이 작업에 참여할 수 있다. 관심있는 사람들은 미지리서치의 홈페이지를 참조하도록 하자. 단점이라면 비트맵 글꼴 문제와 더불어 유니코드 2.0상당의 모든 한글과 한자 글꼴을 얻었으면 하는 바램이지만, 첫술에 배부를 수 없다고 이런 문제는 앞으로 점점 해결될 것이라고 생각해 보자. 백묵 굴림체 12포인트 비트맵은 한글 부분이 힌팅된 버전이 공개되어 있으니 많이 사용하고 보정 작업에도 참여하도록 하자.
MiziOS 개발자 메일링 리스트에서 오고가던 사항 중 특정 운영체제와 관련 없는, 그리고 흩어져 있던 각 한글화 리눅스 배포본에서 적용되고 있던 패치를 모으고 이를 원 저자에게 돌려주는 과정에서 제기가 되어 생겨난 것이 바로 hangul-patch 메일링 리스트이다. 이는 각 리눅스 배포본의 한글 패치를 모으고 정리하려던 김현철 <mindgame@kldp.org>님의 웹페이지에서 시작하여, 메일링 리스트가 개설되고 홈페이지를 KLDP로 이전하게 되었다. hangul-patch 메일링 리스트는 각 리눅스 배포본이나 FreeBSD 등의 공개 프로젝트에서 패키지로 제공되는 각 어플리케이션에 포함되는 간단한 수준에서부터 국제화 패치까지를 모으고, 이에 대한 사항을 논의하고 되도록이면 별도의 패치로 존재하지 않도록 원 저자에게 돌려주는 것을 목적으로 하고 있다. 관심있는 사람들은 김현철님의 한글패치 홈페이지에 방문하기 바란다.
http://kldp.org/~mindgame/unix/hangulhangul-patch메일링 리스트는 Korea FreeBSD Users Group에서 제공하고 있다.
hangul-patch@kr.FreeBSD.org가입하고 싶은 경우 홈페이지의 내용을 참조해서 가입하기 바란다.
최근에 hangul-patch 메일링 리스트의 가장 큰 주제 중의 하나는, 리눅스 (또는 그 외의 유닉스 시스템)에서 올바른 로케일 시스템의 사용법과 glibc의 경우 로케일명 등에 대한 논의였다. 이는 로케일 초기화의 표준적인 방법인 setlocale()의 사용을 하지 않고 getenv("LANG")등을 사용하는 비표준적인 어플리케이션에 대한 논의에서부터 시작한 것이었는데, 여러가지 논의 끝에(물론 끝난 것은 아니고 계속되고 있다) 일정하게 정리된 안을 내기로 하였다. 아래 문서는 그것의 결과인데, 어떤 영향력이 있다기 보다는 프로그래머나 패키징하는 사람이 생각할 수 있는 일종의 권장안이라고 생각하는 것이 좋겠다. 한글패치 홈페이지에서는 이러한 권장안들을 몇가지 더(패치하는 방법 등) 찾을 수 있다.
* linux에서 locale설정에 관한 제안 URL ( http://kldp.org/~mindgame/unix/hangul/linux_locale.txt ) 마지막 수정: 1999년 10월 09일 초안 작성일: 1999년 9월 30일 가) 환경변수 LANG을 ko_KR.eucKR로 설정하거나, 그렇지 않은 경우(i.e. ko)는 locale.alias(/usr/share/locale/, /usr/X11R6/lib/X11/locale/)을 다음 예와 같이 편집하여 호환성을 유지 ko ko_KR.eucKR * 참고: locale값 ko_KR.eucKR는 "언어[_국가].[코딩(charset)]" 형식임 나) message의 locale관련 부분(i.e. gnome에서의 xxx.desktop, kde에서의 xxx.kdelnk, rpm spec files)은 관례를 따라 ko로 표기 다) 현재 charset(eucKR)에 의존적인 locale관련 resource들은 ko_KR.eucKR/ 디렉토리 밑에 설치하고, 확장자가 .mo인 한글 메시지 파일들은 원칙적으로 charset 의존성이 없으므로 ko/LC_MESSAGES/ 디렉토리밑에 설치 라) 프로그램 내부에서 locale값의 확인이 필요할 때는 가능하다면 getenv() 함수 대신 setlocale() 함수를 사용 * 참고: setlocale(LC_xxx, "")로 쓴 경우 환경변수로부터 LC_ALL -> LC_xxx -> LANG 순서로 locale값을 찾아서 locale.alias(/usr/share/locale/)를 참조한 후 locale값을 설정, 리턴. locale값을 참조할 때는 setlocale(LC_xxx, NULL)의 리턴값을 이용. LANGUAGE 환경변수는 locale다중 설정을 위해 gettext에서 사용되는 GNU extension으로 LC_ALL보다 우선언뜻 보기에는 이해하기 어려울 지 모르지만, 결국 어느곳에서 일반적으로 받아들여지는 ko라는 로케일명을 사용할 것인지 또는 구체적인 인코딩을 나타내는 ko_KR.eucKR이라는 로케일명을 사용할 것인지에 대한 내용이다. 지금까지 리눅스에서는 ko라는 로케일 명을 대부분 사용해 왔고, GNU gettext를 사용하는 경우에도 마찬가지로(이전 회 참조) ko정도로만 지정하는 것으로 충분하였기 때문이다. 이는 로케일명이 얼마나 명확해야 하는지 등의 기준에 대한 문제를 일으키는데, 대략 현재 GNU gettext 시스템은 두자로 된 언어명(물론 예외도 존재한다)만으로 충분하고, 그 이외의 경우라면 ko_KR.eucKR과 같은 식으로 되도록이면 전체 표기를 하며, 항상 locale.alias파일을 통해 두 로케일을 동등하게 사용할 수 있도록 하고 있다는 점에 주의하도록 하자. FreeBSD와 같이 기본적으로 ko_KR.EUC만을 허용하는 시스템이라도 GNU gettext를 사용하는 경우에서는 ko만을 사용할 수도 있다.
GNU gettext는 언어를 결정하기 위해 LANGUAGE변수도 사용하는데,
두 경우 모두 setlocale()을 사용하지 않으므로 로케일이 setlocale()을
통해 초기화될 수 있는지의 여부는 중요하지 않다는 점에 주의하자.
심지어는 한국어 로케일 자체가 없는 시스템에서도 GNU gettext를 통한
한국어 메시지 출력은 가능하다.
ko_KR.eucKR과 ko_KR.EUC: EUC는 특정 언어의 문자셋을 나타내는 방식이
아니라 ISO-2022와 같이 인코딩 방식을 나타내고 있다. 실제로 EUC를 따르는
언어는 주로 EUC-JP(일본어), EUC-KR(한국어) 등이 있는데(중국에서는
EUC를 많이 사용하지 않는다), EUC-JP와 EUC-KR은 비슷해 보이지만 실제로
완전히 다른 문자셋이므로, 구분해서 사용하는 것이 좋다는 관점에서 본다면
FreeBSD의 ko_KR.EUC와 같은 이름은 문제가 생길 수 있다. 게다가 LANG
환경변수의 마지막 필드는 인코딩이 아니라 문자셋이 오는 자리이기
때문이다.
현재의 한글 패치라고 한다면 대략 다음과 같이 나누어 볼 수 있다. (김현철님의 구분 방식에 따라)
emacs 편집기가 국제화되면서 hanemacs의 도움 없이도(물론 incremental search등의 기능에서는 hanemacs가 뛰어나다) mule의 통합으로 인해 국제화 방식의 지원으로 인한 다국어 처리가 가능해졌다. emacs 20부터 다가온 이 중대한 변화는 또한 여러가지 문제를 일으키게 되었는데, emacs-kr리스트는 국내의 emacs사용자들이 한글 처리 문제 등을 논의하고 버그 패치등을 만들어 원 emacs배포본에 적용될 수 있도록 하는 노력의 결과이다. emacs를 사용하고 있고, emacs의 한글 사용에 관심이 있다면 아래 홈페이지와 메일링 리스트는 참조하도록 하자.
http://pluie.kaist.ac.kr/emacs-kr/ (홈페이지)
emacs-kr@debian-kr.org (메일링 리스트)
최근의 중요한 작업은 emacs의 통합 메시지 시스템인 GNUS에서의 한국어
처리에 대한 문제였다. 그동안 GNUS는 기본적인 사용에는 큰 불편함이
없었지만 답장시의 메시지 제목 등에서 한국어 표시가 제대로 되지 않는
문제 등이 있었는데, 최근에 이러한 문제가 몇가지 해결되었다.
http://www.li18nux.org
http://www.linuxi18n.org
일본의 리눅스연구회(LRS)의 NLS부서에는 glibc 2에 완전한 멀티바이트 처리가 포함되도록 하기 위해 개발 노력을 하고 있다. 반드시 일본어만을 위한 것은 아니고, 지금도 여러 나라 사람들의 참여를 기다리고 있고, 최근에 몇가지 패치들이 나와 있기도 하다. 관심 있는 사람은 다음 주소에 연락해 보기 바란다.
nls-request@linet.gr.jp (영어) pod-request@linet.gr.jp (일본어)
help
이러한 분야에서의 발전은 관심있는 면을 열심히 연구하고 실제로 해 보고 발표하고 피드백을 모으는 과정에서 발전하며, 이 과정에서 많은 사람들이 조금씩 아는 내용들도 큰 도움이 될 수 있다. 여러분도 남들이 해 주는 것만을 받아들이지 말고 이러한 분야에 조금씩 도움이 될 수 있다면, 공개 유닉스에서 원활한 한국어 처리가 되는 것을 보는 날도 그리 멀지는 않을 것이다.
$Id: index.shtml,v 1.1.1.1 2001/05/23 03:11:31 cjh Exp $
[ Home | Freetime works | FreeBSD | KFUG ]