메아리 저널

그러니까, 두 달 전에 유니코드 6.0이 나왔는데 이제서야 글을 쓰는 것은 내가 이 얘기를 랑데브 채널에서 마구 떠들다가 바빠서 잊고 있다가 들어 갔다는 걸 이제야 알았기 때문이다. (내가 맨날 유니코드 파이프라인 페이지를 지켜 보고 있는 것도 아니고…) 다른 나라 문자와 언어에 관심 없는 우리 같은 사람한테 유니코드 6.0의 주된 변경점은 물론 인도 루피 기호(U+20B9)가 새로 들어 갔다¹는 것도 있지만 사실 더 큰 건은 에모지가 아닌가… 싶다. 그리하여 코스웍이 거의 정리된 이 시점에서 망한 저널을 되살리기 위하여 이 쪽 얘기를 정리하도록 하겠다.

배경

이 문제를 설명하려면 일단 일본의 이동통신사 현황에 대한 이해가 필요한데, 한국에서 SKT, KTF, LGT 삼개 통신사가 시장을 거의 점유하는 것과 비슷하게 일본도 NTT 도코모, 소프트뱅크, au 삼개 통신사가 시장을 거의 점유하고 있다. 물론 한국이랑 마찬가지로 일본에서도 삼사의 경쟁은 치열했고, 그 결과로 별의별 호환되지 않는 기능들이 생겨나기에 이르는데 그 중 하나가 에모지(絵文字), 그러니까 그림 문자 기능이었다. 이 기능은 (내 기억이 맞다면) 본래 NTT 도코모 쪽에서 처음 만든 것으로 나중에는 삼사가 모두 지원하게 되었는데, 지원하는 건 좋지만 각 회사 별로 사용할 수 있는 에모지가 달랐다라는 것이 굉장한 문제였다. 일본은 한국과는 달리 문자 메시지(SMS)는 같은 통신사 안에서만 받고 보낼 수 있으며 다른 통신사들끼리 메시지를 주고 받으려면 이메일을 써야 하는데, 에모지의 인코딩 방법과 사용 가능한 에모지 목록이 서로 다른지라(…) 한 쪽에서 보낸 게 다른 쪽에서는 깨져 보인다거나 하는 문제가 생기고 만다. 무슨 Shift_JIS랑 ISO-2022-JP처럼 인코딩만 바꾸면 되는 문제라면 모르겠지만 에모지는 모두 자체적으로 만들어진 확장 구역을 사용하기 때문에² 표준화된 인코딩이라고 할 만한 것도 존재하지 않았다.

더군다나 그 이유는 단문 메시지를 쓰기 어렵게 한 통신사들의 횡포에 가깝긴 하지만 (자기네들끼리 쓴다면 뭐 신경을 쓸 이유가 없다), 결과적으로는 이 빌어먹을 에모지들이 휴대전화가 아닌 외부의 이메일에서도 노출되어 버려서 구글이나 야후 같은 회사들이 어쩔 수 없이 에모지를 지원하게 만드는 빌미를 제공하고야 만다. 비슷한 이유로 아이폰도 에모지 입력기가 내장되어 있고 일본 바깥에서는 비활성화되어 있긴 하지만 에모지 자체를 볼 수는 있는 걸로 안다. 이 정도로 상황이 복잡해지자 미적미적거리던 통신사들을 제치고 2009년에 구글과 애플 직원들이 공식(N3582)으로 유니코드에 에모지 호환을 위한 문자들을 추가할 것을 제안하기에 이르고, 수많은 수정을 거쳐서 유니코드 6.0에 대부분의 에모지 문자들이 추가되기에 이른다. 여기까지가 이 “사태”의 근원이다.

내가 에모지의 추가를 “사태”라 부르는 이유는, 이번에 추가된 문자들이 애초에 그림 문자이던 것을 상호운용성을 위해 유니코드에 끼워 넣은 것이기 때문에 다른 이유라면 인코딩에 그다지 적절하지 않은 문자들이 마구 추가되었다는 것 때문이다. 어쩔 수 없는 상황이긴 하지만 영 미덥지 않다고 해야 할까.

구성

에모지의 구성을 논하기 전에 유니코드의 기본적인 철학을 짚고 넘어 가기로 하자.

유니코드는 문자 글리프가 아닌 문자의 의미를 인코딩한다.

이전에 한중일 한자 통합 과정에서도 많이 논란이 되긴 했지만, 유니코드는 기본적으로 꼭 필요한 경우가 아니라면(이를테면 KS X 1001의 중복 한자) 글리프 모양만으로 다른 코드 포인트를 할당하는 경우는 별로 없다. 에모지의 경우에도 비슷한 논리가 적용되는데, 결과적으로는 굉장히 일반적인 문자들이 할당되었다. 예를 들자면 au 에모지 은 물고기 모양이지만, 그 이름은 “물고기 자리”로 되어 있기 때문에 일차 매핑은 ♓(U+2653 PISCES)로 되어 있다. 또한 대부분의 얼굴 모양 그림 문자들은 일반적인 의미에 따라 매핑이 되었는데, 이를테면 NTT 도코모 , au , 소프트뱅크 은 웃는 얼굴이긴 해도 다소간의 차이가 있지만 여기에 대응하는 유니코드 문자는 U+1F601 GRINNING FACE WITH SMILING EYES가 되었고, 레퍼런스 글리프도 아무 효과 없는 맹맹한 모양이 되었다(직접 그 위용을 보시라). 예외적으로 색깔(…)만 다른 글리프들은 가능하면 WHITE/BLACK으로 매핑했지만 안 되면 U+1F499..1F49C처럼 색깔을 그냥 이름의 일부로 포함시키고야 말았다. 이를 두고 모 채널에서 나온 얘기가 압권.

<lifthrasiir> http://www.fileformat.info/info/unicode/char/1f499/index.htm Unicode is not for color blinds either. (also see U+1F49A..1F49C)
<fizzle> There’s also green book/blue book/orange book (1f47[d-f]).
<fizzle> Sorry, 1f4d[7-9] instead.
<fizzle> I apparently have early-onset dysxelia.
<fizzle> The whole block is so random. Silhouette of Japan? Orange/blue diamonds, but red/blue circles and red triangles?

(당연한 얘기지만 마지막 물음에 대한 답변은 “에모지에 할당된 그림들이 원래 랜덤하므로”이다…)

물론 비슷해 보이는 문자를 하나로 통합하는 과정이 순탄할 수만은 없다. 통신사들에서도 일부 통합된 문자를 서로 갈라야 한다는 지적을 몇 번 하기도 했고, 유니코드에서의 에모지 논의보다 한참 전에 소프트뱅크가 고화질 에모지를 지원하기 시작했을 때도 에모지의 글리프가 유지되지 않는 것은 옳지 않다는 지적도 있었다. 게다가 유니코드 에모지 FAQ에서도 언급하고 있지만, 에모지와 비슷한 성격을 가지고 있는 딩뱃 문자들의 경우 서로 다른 글리프인 ❶(U+2776 DINGBAT NEGATIVE CIRCLED DIGIT ONE)과 ➊(U+278A DINGBAT NEGATIVE CIRCLED SANS-SERIF DIGIT ONE)을 구분하고 있단 말이다. (물론 딩뱃 문자들은 글리프가 매우 표준화되어 있는 반면 에모지는 별로 그렇진 않다는 게 다르긴 하다.) 그러나 결과적으로 유니코드에 들어간 에모지들은 기본적으로는 글리프를 유지하지 않은 채로 의미만 가지고 할당이 되었다. 개인적으로는 한중일 한자 통합 과정에서 최종적으로 들어 간 솔루션인 Ideographic Variation Sequence가 일반적인 글리프를 위하여 확장되는 게 이런 상황을 위해서는 낫지 않나 싶긴 한데, 어쩌면 나쁜 선례가 될 수도 있을 것 같아서 섣부른 판단을 내리긴 어렵다.

문자 선정 과정에서 웃지 못 할 일이 하나 있었는데, 에모지 중에는 국기 그림이 열 개 포함되어 있다(중국, 독일, 에스파냐, 프랑스, 영국, 이탈리아, 일본, 한국, 러시아, 미국). 논의 초기에는 별도의 글리프 없이(코드 차트에서는 점선으로 그린 사각형으로 나오는 그것) 열 개의 문자를 그대로 할당했었는데, 이것이 다른 국가들에 대한 차별이라는 게 지적된 덕택에 상당한 논의가 있었다. 이를 처음으로 지적한 N3607을 인용하면:

Germany (one of the 10 countries “lucky” enough to be included in emoji glyph sets) concurs with Ireland (one of the 193 countries “unlucky” enough not to be included in emoji glyph sets) that this is an inappropriate use of the UCS. Politically, the proposal made in N3583 is both naïve (no one is fooled) and untenable (being prejudicial against 95% of the world’s sovereign states).

N3607에서 제시한 방법은 그냥 아예 26² = 676개의 “두 글자 코드 문자”를 한 번에 할당해서, 이것을 ISO 639-1 언어 코드나 ISO 3166-1 alpha 2 국가 코드 같은 두 글자 코드를 위한 일반적인 목적으로 쓰자는 제안이었다. 그러나 뒤따르는 임시 회의(N3636)에서는 아예 이들 문자를 인코딩하지 말자는 쪽이 우세했고, 결국 N3727에서 제안한 대안, 즉 U+1F1E6..1F1FF까지 Regional indicator라 불리는 글자들을 추가하여 두 글자를 연속으로 쓰면 해당하는 국기가 나오게 하자는 방법으로 결정되었다. 이와 비슷한 이유로, 에모지 문자들 중에는 조커 카드가 있는데 마찬가지로 N3607에서 이 문자를 별도의 블록으로 빼 내고 일반적인 카드를 모두 추가해 버리자는 제안이 채택되어(…) U+1F0A0..1F0FF 영역에 새로이 카드 문자가 추가되었다. 이건 뭐라 말할 수도 없고…

결론

이런 저런 과정을 거쳐서 유니코드 6.0의 가장 큰 쟁점(?)이라 할 수 있는 에모지가 거의 대부분 추가되기에 이른다. (아주 일부, 기업 관련 기호라거나 서비스를 나타내는 기호 등은 추가되지 않는다. 하지만 누가 그런 쓸모 없는 문자를 쓰겠는가?) 개인적으로는 이 사태가 유니코드 표준 위원회가 동작하는 방식을 잘 보여 주는 것 같은데, 특히 국기 기호에 대한 독일과 아일랜드 대표(N3607을 같이 썼다)의 반응이 볼만했다.

유니코드 6.0에는 에모지나 루피 기호 말고도 헨타이가나 일부가 추가³되었다거나 하는 변경점이 있지만… 귀찮으므로 여기까지.