2012년 1월 31일 수정: 유니코드 6.1이 발표됨에 따라 유니코드 6.1 관련 내용을 예정에서 확정으로 바꿈

유니코드에는 canonical equivalence라는 것이 존재한다. canonical equivalence란, 한 가지의 추상적인(abstract) 문자를 나타내는 문자나 문자열 사이의 기본적인 동등함(fundamental equivalency)을 말하며, 올바르게 표시되었을 때는 똑같이 표현되고 동작해야 한다. 한 문자에 대해 여러 가지 canonical equivalence가 존재하는 것도 가능하다.
예를 들어 문자 Ç(U+00C7)와 문자열 C(U+0043) + ◌̧(U+0327)는 서로 같은 추상적인 문자를 나타내므로 canonical equivalence이고, 문자 Ω(U+03A9)와 문자 Ω(U+2126)은 서로 똑같은 추상적인 문자를 나타내므로 canonical equivalence이다.

이 canonical equivalence를 정의한 매핑을 canonical mapping이라고 한다. 예를 들어 문자 Ç에는 canonical mapping으로 C + ◌̧이 정의돼 있으며, Ω(U+2126)에는 canonical mapping으로 Ω(U+03A9)이 정의돼 있다. 유니코드 4.1부터는 유니코드의 안정성(stability)을 위해 한 번 정해진 canonical mapping을 변경하지 않기로 결정했다.

이 canonical equivalence와 canonical mapping은 유니코드 정규화(Unicode normalization) 처리에 중요한 역할을 한다. 유니코드 정규화는 한 가지의 추상적인 문자를 표현하는 데 쓰인 여러 가지의 canonical equivalence들을 정리해, 모두 같은 형태로 변환한다. 예를 들어, Ç와 C + ◌̧가 같이 포함된 문자열에 유니코드 정규화 처리를 하면, 정규화 알고리듬에 따라 Ç와 C + ◌̧가 모두 Ç 또는 C + ◌̧ 둘 중 한 가지 형태로만 변환된다. (유니코드 정규화 알고리듬에는 여러 가지가 있는데, 설명하기 복잡하므로 여기에 대해서는 이 글에서 다루지 않겠다.)
두 문자 이상으로 이루어진 문자열(예: C + ◌̧)이 아니라 한 문자(singleton)로만 이루어졌을 경우는 정규화 알고리듬의 종류에 상관없이 모두 같은 문자로 변환된다. 예를 들어 Ω(U+2126)과 Ω(U+03A9)가 같이 포함된 문자열에 유니코드 정규화 처리를 하면 모두 Ω(U+03A9)로 변환된다.

이제 郎(U+F92C) 얘기로 돌아가자.
郎(U+F92C)는 호환용 한자이고, 호환용 한자는 기존하던 문자 집합(KS C 5601, Big5 등)과 유니코드 사이의 왕복 변환을 위해 유니코드에서 중복 배당한 한자들이다. 한국의 KS C 5601(KS X 1001)에서는 독음이 여러 개인 한자는 그 독음 수만큼 중복 배당했는데, 유니코드는 KS C 5601과 호환성을 유지하기 위해 KS C 5601의 중복 한자를 U+F900부터 U+FA0B에 배당했다.

따라서 호환용 한자에는 기본적으로 정규 한자가 canonical mapping으로 배당되어 있다. 예를 들어 樂(U+F914), 樂(U+F95C), 樂(U+F9BF)에는 모두 樂(U+6A02)이 canonical mapping으로 배당되어 있고, 따라서 유니코드 정규화 처리 후에는 樂(U+F914), 樂(U+F95C), 樂(U+F9BF)는 모두 樂(U+6A02)으로 변환된다.

郎(U+F92C)은 郞(U+90DE)의 중복자이므로, 郎(U+F92C)에 대한 canonical mapping은 郞(U+90DE)이어야 할 것이다. 하지만 실제로는 郎(U+F92C)는 엉뚱하게도 郎(U+90CE)에 매핑되어 있다. 이 잘못된 매핑은 유니코드 1.1부터 쭉 유지되었고, 유니코드 6.0까지 나온 현 시점에서 매핑을 변경하기에는 이미 늦었다.
문제는 이 郎(U+90CE)가 KS C 5601에 없다는 것이다. 따라서 유니코드 정규화 처리를 하게 되면 KS C 5601에 있는 郎(U+F92C)은 KS C 5601에 없는 郎(U+90CE)로 변환되고, KS C 5601로 처리할 수 있었던 정규화 처리 전의 데이터가 정규화 처리 후에는 KS C 5601로 처리할 수 없게 돼 버린다.

이 문제를 해결하기 위해 한국 측에서는 canonical mapping으로 郞(U+90DE)가 배당된, 郞(U+90DE)의 중복자를 U+FA2E에 배당하기를 제안했고, 이 제안은 받아들여져서 유니코드 6.1에 U+FA2E가 배당되었다. 즉 郎(U+F92C)을 되도록 쓰지 않도록 하고(depreciated), U+FA2E를 쓰도록 하려는 것이다.
(개인적으로는, 이미 오랫동안 郎(U+F92C)를 써 왔는데 U+FA2E에 새로운 문자를 배당해 쓰면 더 문제가 복잡해지지 않나 싶다. -_-)

그렇다면 왜 郎(U+F92C)는 郞(U+90DE)가 아니라 郎(U+90CE)로 잘못 매핑된 것일까?
이 이유는 마이크로소프트 윈도에서 기본 지원하는 한국어 글꼴 굴림, 돋움, 바탕, 궁서에 있는 것 같다. 실제로 굴림, 돋움, 바탕, 궁서 글꼴에는 郎(U+F92C)의 자형이 郎(U+90CE)와 똑같이 그려져 있고, 郞(U+90DE)와는 분명 차이가 있다. 郎(U+F92C)의 자형이 왜 저렇게 그려져 있는지는 모르겠다.

유니코드와 ISO/IEC 10646에 등록된 郎(U+F92C)의 대표 자형도 郎(U+90CE)와 같다. 즉 한국 측에서 PDF 차트를 제작할 시 위 네 가지 글꼴 중 하나를 사용해 제작해서 잘못된 자형이 유니코드에 대표 글리프로 등록됐고, 따라서 canonical mapping 또한 잘못된 것이다.

그림 1: 굴림·돋움, 바탕·궁서 글꼴로 표현한 郎(U+F92C)와 郞(U+90DE) – 郎(U+90CE)에는 자형 없음


그림 2: 유니코드와 ISO/IEC 10646에 등록된 郎(U+F92C), 郎(U+90CE), 郞(U+90DE)의 자형


덧붙임: canonical mapping이 잘못된 KS C 5601 호환용 한자는 郎(U+F92C) 말고 하나 더 있다. 잘 찾아보시라.


신고
Posted by Jōhō Tōgō Shinentai