casaubon

Apple Peel
Unicode: Sick of This Push and Pull

6-21-02 Pierre Igot

불어를 하는 사람이자, 인터넷을 5 년 이상 써온 사람으로서, 2002년 바로 오늘날, 생각없는 소프트웨어 제작자와 불완전한 시스템 관리자, 무식한 엔드 유저들이 메일을 알아볼 수 없을 정도로 이상하게 렌더링을 걸어버리는 통에 필자는 매우 실망스럽다. 이들은 편지를 알아볼 수 없게 보내버린다.

The Problem

능숙한 맥 사용자라면 이 문제를 잘 알고 있을 테지만, 정작, 이를 시정해야할 사람들이 주의를 기울이지 않아서 피해를 보고 있다.

0~9와 A~Z, 그 외 주로 쓰이는 기호(!, ?, & 등) 외의 문자와 이를 해석하는 전자부호 때문에 어떠한 규칙[http://tronweb.super-nova.co.jp/characcodehist.html]이 없이는 통신이 힘들게 되버렸다.

이를테면, 악상떼귀(L'accent aigu)가 붙은 e는 불어에서 매우 흔하며, 영어 단어에도 프로떼제나 레주메, 네글리제같은 단어에 쓰이고, 맥 오에스 9를 돌리는 매킨토시 상에서는 142 번(16진법으로는 %82)의 캐릭터 코드를 갖고 있다(맥로만[http://www.hclrss.demon.co.uk/demos/macroman.html] 문자 셋). 하지만 윈도우즈 98을 돌리는 컴퓨터(윈라틴1[http://www.hclrss.demon.co.uk/demos/ansi.html] 문자 셋, 즉 ANSI이다)에서는 233 번의 캐릭터 코드(%E9)를 갖고 있다.

즉, 악상떼귀 "e"가 붙은 메시지를 보내려면 공통의 코드에 기반하는 텍스트로 인코딩해야한다. 그래야 역시 공통의 코드를 이용하여 여러분이 보낸 메시지를 디코딩해서 올바르게 볼 수 있기 때문이다. 당연히 이부분은 소프트웨어가 처리해야하며, 이런 작업을 사용자가 수동적으로 하도록 요구하지는 않는다. 과연 그럴까?

사실 문제는 두 가지로 볼 수 있다. (1) 보내는 이와 받는 이가 사용하는 모든 소프트웨어, 그리고 그들 사이의 모든 컴퓨터 서버가 문자 정보를 보존하는 공통의 인코딩/디코딩 규칙을 받아들여야한다. (2) 이 규칙은 모두가 받아들여야 한다. 이 두 가지 문제가 잘 지켜지지 않기 때문에 이메일 문제는 여전하다.

The Universal Code

인간사의 다른 일들처럼, 공통 코드를 제정하는 데에도 오래고 고된 시간이 걸렸다. 이유는 분명하다. 세계에는 언어가 절대적으로 다양하지만, 그 외에 다수의 사람들이 사용하는 오퍼레이팅 시스템과 소프트웨어는 상대적으로 다양하고, 앞으로 미래의 개발을 위해 컴퓨터 기술을 응용해야할 필요가 생긴 것이다. 정치적인 이유도 있다. 공통 코드에 대한 결정은 전세계 공동체와 사업체, 나라의 다양한 이해 관계를 대표하는 제한된 대표자들이 내려야했다.

긴 이야기를 짧게 하기 위해, 문자 인코딩의 "대합의" 역사를 두 가지 단계로 설명하겠다.

첫 번째 단계는 ISO-Latin1 문자셋의 채택이었다. "ISO8859[http://czyborra.com/charsets/iso8859.html]"로 알려진 문자 셋을 확장시킨 ISO-Latin1은 맥 오에스 9를 돌리는 매킨토시 컴퓨터와 윈도우즈 95 이후 버전을 돌리는 윈도우즈 컴퓨터가 적어도 서구 세계에서는 별 문제없이 소통할 수 있도록 하였다.

앞서 언급했듯이, 맥로만 문자 셋으로 작성된 텍스트를 ISO-Latin1 문자셋을 이용하여 인코딩한 다음에, 수신자에게 인코딩한 파일을 보낸다. 문제없이 전송됐다면, 수신자는 이를 ISO-Latin1 텍스트를 디코딩하는 소프트웨어를 돌려서 송신자가 보낸 문자를 어려움없이 볼 수 있게 하는 식이었다.

HTML로 인코딩하는 웹의 경우, ISO-Latin1 코드는 매우 중요한 역할을 하였다. 웹은 어떤 컴퓨터에서 어느 나라 사람이 보더라도 동일하게 보여야하기 때문이었다.

Implementing ISO-Latin1

ISO 5889가 1980년대에 제정됐지만 일반화되기까지는 오랜 기간이 흘렀다. 엔드 유저들 사이에서 문제가 생길 때마다 변화를 시켜줘야했기 때문이다.

여기에서 마이크로소프트의 독점이 다시 한 번 주요한 이유가 되었다. 만약 윈텔 머신을 사용해서 이메일을 윈텔을 사용하는 다른 이에게 보내는 것은 문제가 없다. 설사 컴퓨터를 잘못 설정했다 하더라도 어떠한 특수 부호를 넣건 어떤 악센트를 집어넣건 그대로 보인다. 마찬가지로 매킨토시 사용자가 또다른 매킨토시 사용자에게 메일을 보내도 문제는 없다. 다만, 맥 사용자가 윈텔 사용자에게, 혹은 그 반대의 경우 문제가 발생한다.

이 문제는 컴퓨터의 설정과는 관계 없다. 이메일은 다양한 소프트웨어를 돌리는 모든 종류의 서버를 통과해야하며, 이경우 각 서버들을 올바르게 설정해둬야한다.

인코딩 문제에 있어서도 제일 큰 피해자는 소수, 즉 맥 사용자들이다. 이들은 소수이기 때문에 불만을 토로하더라도 다른 이들보다 열 배는 더 크게 말해야한다. 소프트웨어 설정을 올바르게 하라고 시스템 관리자들에게 불만을 제기한 적은 수도 없다.

이를테면, 필자는 수 년동안 프랑스 국내 신문인 르몽드의 구독자다. 심지어는 오늘도 르몽드 메일링 리스트 관리자에게 대여섯 번의 불만 사항을 전달했을 정도이다. 문제가 여전한 것이다. 최신 "르몽드-신기술" 뉴스레터를 보면 다음과 같다.



불어를 조금이라도 안다면, 모든 악상이 잘못됐음을 알 수 있다. 필자도 매우 힘들게 읽어야했다. 이 현상은 당연히 맥을 사용하는 독자들에게만 해당하는 문제이다. 말했듯이, 르몽드에 필자는 몇 번이고 불만을 제기하였고, 그들의 뉴스레터, 이메일 헤더가 모든 정보를 올바르게 담고 있지(분명히 헤더에는 ?ontent-Type: text/plain; charset="iso-8859-1"횃箚 적혀 있었다.) 않다고 누차 말했었다. 르몽드는 필자의 불만을 인정하고 그사실을 책임자에게 말해줬다고 통보해왔으나 고쳐진 점은 없었다. 뉴스는 여전히 읽기 어려웠으며, 필자는 거의 포기해버렸다.

르몽드는 전세계 불어 사용 인구를 위한 프랑스 신문이다. 당연히 모든 불어 사용 독자들은 르몽드를 올바르게 읽을 것으로 예상할테지만, 그 불어 사용 독자들은 윈텔 사용자들 뿐이다. 소수의 불만이 와닿지 않는 이상 고쳐지는 것은 없게 마련이다.

이들에게 어떻게 애플의 "스위치" 광고 캠페인을 말해줄 수 있겠는가? 애플이 이 광고로 얼마나 많은 윈텔 사용자들을 애플로 끌어들이는 것과 상관 없이, 매일매일 맥 사용자들은 자신들의 불만을 인정시키고, 알리려고 고된 노력을 펼치고 있으며, 그것이 바로 현실이다.

Step 2: Unicode

르몽드의 사례를 이야기하였는데, ISO 8859 자체의 구현은 발전이랄 수 있다(물론 매우 느린 발전이다.). 여기에 또다른 단계, 유니코드가 나왔다.

짧게 설명하자면, ISO 8859는 1-바이트 인코딩의 제한(한 문자는 1 바이트이다.) 때문에 256 문자(%00에서 %FF, 혹은 0~255)만을 포함시킬 수 있다.

유니코드는 2-바이트 인코딩도 포함시키는 개가를 이루었다. 즉, %0000에서 %FFFF, 혹은 0~65535까지의 2 바이트 코드를 사용하여 인코딩하는 문자들을 포함시켰다는 얘기이다. 잠재적으로 65536 개의 문자를 포함하는 유니코드는 전세계 대부분의 언어를 감당할 수 있을 정도이다.

하지만 1-바이트에서 2-바이트로의 메시지 때문에 모든 소프트웨어에 업데이트가 필요하다는 문제가 있다. 또한 윈도우즈와 매킨토시를 지원하는 다수의 소프트웨어는 아직 유니코드 문자 인코딩을 올바르게 처리하지 못하고 있다.

윈도우즈 XP와 맥 오에스 텐 모두 유니코드를 기본으로 지원하고 있지만 유명 애플리케이션들은 아직이다. 그러나 몇 달 전에 필자는 새로운 차원의 이메일을 발견했다. 다음 메시지를 한 번 보기 바란다. (익명성을 위해 개인 정보에 "***"를 사용했다.)

X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
MIME-Version: 1.0
Subject: =?utf-8?Q?FW=3A_R=C3=A9vision?=
Date: Wed, 12 Jun 2002 13:37:37 -0400
Thread-Topic: =?utf-8?Q?R=C3=A9vision?=
Thread-Index: AcISIh/GWBilsjKYQVeKWVm+Ue3opAABZcGsAAE6AyAAAhsvgAAAB0NwA ABju3A=
From: "Paul ***"
To: "**** List" <***@***.ca>

Le Conseil des ministres de l'?ducation (Canada), aka le CMEC, recherche une personne qui aurait les comp챕tences voulues pour faire de la lecture d'챕preuve?n fran챌ais (v챕rification finale de traductions vers le fran챌ais). Il s'agit d'un poste temporaire, du2 au 26 juillet prochain.

Pour plus de d챕tails, s'adresser directement ? ***, directeur adjoint, Administration et Communications, CMEC. mailto::***@***.ca.

Paul

르몽드의 사례와 비교해보면 알 테지만 또다시 불어 텍스트가 말썽이었다. 달라진 점은 악상이 있던 알파벳이 모두 두 개의 문자로 대치됐다. 이를테면, 악상떼귀 "e"는 메시지 상에서 惇⒤로 바뀌어졌다.

"제목"에서도 마찬가지였다. 단 하나의 "é" 때문에, 'Révision'이 =?utf-8?Q?R=C3=A9vision?=獺 바뀌어져버렸다. 독자들이여, 마이크로소프트 독점 문제는 유니코드에서도 여전하다.

The Microsoft Problem

왜 마이크로소프트에 계속 딴죽을 거는가 알아보도록 하자.

우선, 일반적으로 아직까지 유니코드는 전세계가 유니코드를 완전히 지원하는 디바이스를 사용하여 별 어려움 없이 모두 통신할 수 있는 상태를 가정하는 하나의 이론일 뿐이다.

다만 현실은 그런 가정이 아직 너무나, 너무나 멀다는 걸 보여줄 뿐이다. 단순한 사례를 들면, 마이크로소프트의 맥 오에스 텐용 인터넷 익스플로러는 유니코드 인코딩 HTML 페이지를 올바르게 렌더링 못한다. 필자가 만약 BBEdit 6.5(유니코드를 지원한다.)를 이용하여 다음의 웹을 만들었다고 가정해보자.




이 HTML 파일을 인터넷 익스플로러로 보면 다음과 같다.




Unicode page in Explorer

하지만, BBEdit 옵션에서, "Byte-Order Mark"를 HTML 파일로부터 제거하고 유니코드 파일로 저장을 하면, 익스플로러는 악상을 올바르게 표현한다.




Unicode page with no Byte-Order Mark

하지만 편집을 더 하기 위해 똑같은 HTML 파일을 BBEDIT으로 열면 다음과 같이 나온다.


"http://www.w3.org/TR/1999/REC-html401-19991224/loose.dtd">

****** lang="fr">



****** http-equiv="content-type" content="text/html; charset=utf-8">



****** name="generator" content="BBEdit 6.5.2">



******>


R챕vision


*******>

*******>

유니코드 인코딩을 올바르게 나타나게 하기 위해서는 Byte-Order Mark가 필수적이기 때문에, 필자로서는 어쩔 도리가 없는 셈이다.
앞서 문제의 이메일로 돌아가보자. 헤더에 다음과 같은 메시지를 볼 수 있다. 심상치 않은 글이다.

X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0

좀더 알아보면 메시지의 "raw" 형태(수신자를 위해 렌더링하지 않는 부분)에 다음과 같은 글이 있다.

X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: =?utf-8?Q?FW=3A_R=C3=A9vision?=






******>

****** HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=utf-8">



****** content="MSHTML 5.50.4916.2300" name=GENERATOR>

****** dir=ltr>



분명히 이 정보는 마이크로소프트 소프트웨어를 사용하여 만든 다음에 유니코드("UTF-8")를 이용하여 인코딩하였다. 이런 현상은 비교적 새로웠기 때문에 필자로서는 마이크로소프트의 윈도우즈 XP와 오피스 XP의 인코딩 방식을 의심하지 않을 수 없었다.

또한 이 메시지의 저자가 자신의 메시지를 유니코드로 "일부러" 인코딩시켰는 지도 의심스러웠다. 대부분의 인터넷 사용자들처럼, 그는 유니코드가 무엇인 지조차 모를 것이다. 문제는 그의 윈도우즈 소프트웨어가 기본적으로 유니코드를 설정하여 그도 모르게 인코딩을 유니코드로 시켰다는 점이다.

몇 년 전에 마이크로소프트가 아웃룩과 아웃룩 익스프레스로 보내는 기본 이메일 포맷으로 무조건 HTML로 하기로 한 결정과 비슷한 구석이 있다. 갑자기 전세계에 HTML 포맷이 된 이메일이 넘치게 된 이유는 사용자들이 이를 요구했기 때문이 아니라 마이크로소프트가 HTML을 기본 포맷으로 선택했기 때문이다. 다시 말하건데, 대부분의 사용자들은 모르고 있으며 자신의 메시지가 HTML로 인코딩된다는 사실도 모른다. 바로 이런 무지함이 모든 종류의 문제를 일으킨다.

하지만 이렇게 말할 수도 있을 것이다. "마이크로소프트가 자기 제품에 유니코드를 사용하는 것이 무엇이 잘못되었는가? 유니코드의 가정을 이루기 위해 오히려 마이크로소프트의 움직임을 반겨야하지 않는가?" 물론 HTML 포맷의 이메일과는 달리, 유니코드는 비영리 조직이 될 수 있는 한 빨리 실현시키려고 제정한 좋은 아이디어이다.

문제는, 마이크로소프트가 유니코드 인코딩 메시지를 기본 옵션으로 만들어버렸기 때문에 지구상의 모든 컴퓨터 사용자들이 갑자기 유니코드로 이메일을 날리면서, 모두가 갑자기 행복해하는 것이 아니라는 데에 있다.

우선, 마이크로소프트 XP 소프트웨어 최신 버전으로 업그레이드하지 않은 사람들, 두 번째로 유니코드를 올바르게 지원하지 않는(필자의 경우는 오에스 텐용 유도라가 그러했다.) 소프트웨어를 사용하는 사람들이 아직 많다. 세 번째로, 최신 버전의 마이크로소프트 오피스와 오에스 텐용 인터넷 익스플로러조차 유니코드를 올바르게 지원하지 않는다. 즉, 마이크로소프트 최신 제품 절반이 아직 지원하지 않는다는 의미이다.

Implementing Unicode

분명한 점은, 유니코드의 구현 역시 오랜 기간이 필요하다는 데에 있다.

언제인가는 모든 소프트웨어와 서버, 웹 페이지들이 유니코드를 올바르게 지원해서 유니코드의 존재에 대한 걱정을 말끔히 해결해줄 때가 올 것이다.

하지만 그러기에는 아직 수 년이 더 필요하다. 그러는 동안에는 주의해야할 점이 많다. 하위-호환성도 그중 하나이다. 모든 사용자들이 100% 유니코드-호환 소프트웨어를 사용한다고 완전히 확신하지 못하는 한, 유니코드를 멋대로 사용하는 것은 여러분의 명성만 떨어뜨리는 꼴이다. 즉, 여러분이 자신이 사용하는 것도 어떻게 다루는 지 제대로 모른다는 인상을 주기 때문이다.

불행히도, 마이크로소프트와 같은 회사들이 무엇을 왜 사용하는 지에 대해 무지한 사용자들을 농락시키고 좌절시키는 역사가 되풀이하고 있다. 더 좋기 때문에 소프트웨어를 업그레이드하는 이들은 별 설정 없이 기본 설정 그대로 프로그램을 사용하는 경향이 있다. 물론 소프트웨어 설정 자체가 버겁기도 한 이유도 있다.

그러나 그 결과는 생산성/시간의 낭비와 더불어 컴퓨터를 이해하지 못할 에러와 복잡하기만 한 걸로 가득찬 존재로 인식하게 만들 뿐이다. 사람들이 정말로 이런 인식에서 "스위치"할 수 있게 하려면, 깔끔한 광고 캠페인이나 소수의 잘 만들어진 소프트웨어로는, 미안하지만 아직 어렵기만 하다.

- Pierre Igot

2000-2001 Applelust.com. All rights reserved. No part of this publication may be reproduced in any way without prior, expressed permission from the Publisher. It is the sole property of Applelust.com and its writers, who retain copyright to their own works. If you wish to link to us, please see our Privacy Statement for conditions. Apple, Macintosh, and Mac are trademarks of Apple Computer, Inc, with whom we are in no way affiliated or endorsed.

http://www.applelust.com/alust/oped/.../peel_33.shtml

perky

긴 글 번역해 주셔서 읽을 기회를 주시는 것에 대해 늘 감사드리고 있습니다.
그런데, 이 글의 후반부에서 지적한 부분은 필자가 잘못 생각하고
쓴 듯합니다. 원래 RFC821과 822는 7비트 문자만 허용하지만
그 이후에 sendmail의 확장으로 8비트를 모두 커버에서 사실상 캐릭터셋
을 무시하고 그냥 마구 보냈던 문제로 각각의 메일 클라이언트에서
자기 언어가 아니면 제대로 안보였습니다. 이 부분에서는 Content-type
헤더가 캐릭터셋을 헤더의 캐릭터셋을 지정하는 목적이 아니기때문에
(RFC822참조) 헤더에는 사실 캐릭터셋을 지정하는 것이 불가능해서
제대로 국제화가 되려면 헤더에는 7비트 US-ASCII외에는 사용하지
않는 것이 좋습니다. 그 때문에 RFC2047에서 =?로 시작하는 인코딩을
제정하게 되고 그 이후로 헤더에 US-ASCII 가 아닌 글자를 표현하려면
RFC2047 인코딩을 쓰는 것이 대부분의 클라이언트에게 받아들여졌습니다.
이미 더 좋은 해결책이 있는데 굳이 표준을 어겨가면서 제대로 보이지도
않는 8비트 문자를 헤더에 쓰지는 말자는 공감대가 이루어졌기 때문이겠지요..
그래서, 이 글의 후반부에서 제시하고 있는 RFC2047 인코딩 문제는
필자가 표준규약을 미처 자세히 보지 못하고 쓴 듯 합니다.

또한, 2바이트유니코드 (UCS2)이 사실상 대부분의 문자를 표현하고
있다는 것은 서구인들의 관점이고, 멀티바이트 수요자의 사실상 대다수를
차지하고 있는 극동지역에서는 우리나라를 제외한 대부분의 나라가
UCS16에 일상생활의 글자를 포함하지 못하고 있습니다. 중국은 중학교
교과서에 나오는 글자도 간혹 빠진 게 있을 정도라고 합니다.
한글은 다행히 유니코드에서 가장 축복받은 글자이긴 한데,
중국어권 국가들(중국, 대만, 싱가폴 등..)과 일본에서 UCS2에 반대하고
차라리 UCS4를 쓰겠다는 입장을 보이고 있어서, 생각보다 유니코드가 빨리
정착되긴 힘들 것 같습니다.

__________________
Hye-Shik Chang &lt;perky@FreeBSD.org&gt;