안전하지 않음 漢字도메인.안돼/좀더

한자漢字 도메인, 안 돼! 좀 더 기술적인 이야기들

네, 압니다. 이 웹사이트의 첫 문서는 도메인이 무엇인지도 모를 수 있는 보통 사람들을 위해 간단하게 썼기 때문에 정보 기술에 익숙하신 분들에게는 불편할 수 있다는 걸요. 이 문서에서는 그런 분들을 위해 좀 더 기술적이고 전문적인 이야기를 하겠습니다. 일정 수준의 컴퓨터 및 인터넷 지식, 그리고 끈기가 필요할 수 있습니다. (미안합니다. 꽤 많이 길어요.)

그래서 이 문제가 뭐라고요?

이 웹사이트는 한국 문자 루트 존 라벨 생성 규칙의 제안Proposal for Korean Root Zone Label Generation Rules이라는 제목의 문서를 공개적으로 비판하려 만들어졌습니다. 우리는 이 제안이 실용적으로나 기술적으로나 큰 결함을 가지고 있어서 막아야만 한다고 생각합니다.

제목이 무시무시하다는 거 알고 있습니다. 여기에서는 각각이 무슨 뜻인지 차근차근 살펴 보겠습니다. 구체적으로는 이런 순서로 살펴 봅니다.

도메인, 특히 국제화 도메인

도메인이 정확히 뭡니까?

도메인, 정확히는 도메인 이름domain name은 인터넷 주소, 즉 URL의 첫 머리를 이루는 이름입니다.

보통 인터넷에서 한 컴퓨터에서 (여러 다른 컴퓨터나 장치를 거쳐) 다른 컴퓨터로 연결하는 데는 인터넷 프로토콜IP (Internet Protocol)이라는 것이 쓰이고, 이 프로토콜에서 쓰는 컴퓨터의 주소를 아이피 주소IP address라 합니다. 그런데 아이피 주소는 192.168.7.89같이 외우기도 어렵고 웹사이트를 대표할 수도 없으므로, 이름을 넘겨 주면 아이피 주소를 확인resolve해 주는 도메인 이름 시스템DNS (Domain Name System)을 두고, 거추장스러운 아이피 주소 대신 이름을 쓰게 되는데, 바로 이 이름이 도메인 이름인 것입니다.

도메인 이름은 kr.이나 example.com.같이 글자들과 점 하나로 이루어진 라벨label들로 이루어져 있습니다. 다들 알듯이 마지막 라벨의 점은 보통 생략합니다. 도메인 이름 시스템은 계층적으로 구성되어 있어서, 이를테면 com.이 XXX.com. 꼴의 모든 도메인을 확인할 권한을 가지고 있고, example.com.이 XXX.example.com. 꼴의 모든 도메인을 확인할 권한을 가지고 있습니다. 이 때문에 라벨 하나만으로 이루어진 도메인 이름을 최상위 도메인TLD (top-level domain)이라 하여 따로 관리하고, 이러한 도메인들의 목록을 루트 존root zone이라 부릅니다.

도메인에 한글이나 한자가 들어갈 수 있습니까?

원래는 아니었습니다. 도메인은 본래 영문자(대소문자 구별 없음), 숫자, 하이픈만으로 이루어질 수 있었습니다. (길이 제한도 있습니다.)

2003년 즈음부터 국제화 도메인internationalized domain name이라 하여 도메인에 영문자 이외의 다른 문자를 넣는 것이 가능하게 되었습니다. 다만 기존의 도메인 이름 시스템을 바꿀 수는 없었기 때문에, 이런 문자가 들어 있는 도메인을 특정한 방법으로 영문자, 숫자, 하이픈만으로 이루어진 이름으로 바꾸는 편법을 씁니다. 이를테면 한글.은 xn--bj0bj06e.이 됩니다. 이런 변환은 오로지 사용자가 도메인을 입력하거나 사용자에게 도메인을 표시해 줄 때에만 일어납니다.

그럼 도메인에 아무 글자나 들어갈 수 있습니까?

아닙니다. 도메인에 아무 글자나 들어갈 수 있다면 엄청난 문제가 일어날 것입니다. 이 분야에서 이르길 동형이의자 공격IDN homograph attack이라고 하는 유명한 문제가 있습니다.

세상의 많은 문자들은 서로를 모르고 발전한 경우가 많아서, 지금 와서 보니 서로 비슷한 문자가 꽤 많이 있습니다. 영문자 A와 키릴 문자 А같이 그 뿌리가 같아서 비슷한 경우도 있고, 한글 숲과 한자 金같이 어쩌다 보니 비슷해진 경우도 있습니다. 이러한 것들을 동형이의자라 합니다.

도메인 이름은 직접 입력하기도 하지만 보통 읽는 쪽이 많습니다. 하지만 이런 동형이의자가 들어간 도메인 이름은 눈으로 구분을 거의 할 수 없지만 서로 다르게 취급하기 때문에, 유명한 도메인과 비슷하게 생긴 다른 도메인을 등록해서 그 사이트인 양 행세spoofing할 수 있다는 문제가 있습니다.

꼭 도메인 이름을 속이지 않아도 다른 사이트인 양 행세하는 방법은 여럿 있기 때문에 다양한 해결책들이 이미 나와 있습니다. 예를 들어서 아주 유명하거나 은행같이 중요한 사이트라면, 돈을 들여서 확장 검증 인증서EV (extended validation) certificate를 발급받으면 주소 창에 추가 정보를 표시할 수 있습니다. (다만 꼭 그런 것만도 아닌 것 같습니다.) 그러나 이런 접근은 애초에 도메인만으로 사용자가 아무 것도 모르는 사이트에 접속할 수 있고 그래야만 하는 인터넷 환경에서는 많이 부족합니다.

그럼 어떻게 막나요?

크게 두 종류의 해결책이 있습니다.

  1. 특정한 최상위 도메인에서는 특정한 문자들만 허용합니다. .kr에서 아랍 문자를 사용하려고 하는 사람은 거의 없겠지요. 하지만 .com같이 전 세계 사람들이 쓰는 최상위 도메인에서는 적용하기 어렵습니다.
  2. 동형이의자의 목록을 뽑아서, 동형이의자끼리만 다른 도메인은 등록을 거절합니다. 좀 더 확실한 방법이지만, 동형이의자가 한 둘도 아니라 놓치는 글자 쌍이 생길 수 있습니다.

어느 한 쪽도 완벽하지는 않기 때문에 실제로는 두 방법이 함께 병행됩니다. 이를테면 현재 한국어 도메인에서 추가적으로 쓸 수 있는 문자는 현대 한글 11,172자(가~힣)뿐입니다.

어라, 하지만 영문자 소문자 l과 대문자 I도 비슷할 텐데요.

맞습니다. 한 문자 체계 안에서의 혼동same-script confusion은 국제화 도메인이 나오기 한참 전부터 유행하던 것이었습니다. 대표적으로 페이팔Paypal의 도메인을 paypaI.com이라고 속이는 경우가 있었죠. (무슨 글자가 다른지 보이시나요?)

이러한 기존의 공격은 다행히도 가능한 문자 쌍이 많지는 않고, 이미 등록된 도메인도 많은 데다(앞선 paypaI.com은 이미 십수 년 전에 등록되었다고 합니다), 설령 고칠 수 있다 하더라도 기존의 인터넷 체계를 크게 깨뜨릴 수 있어서 방치되어 있습니다. 하지만 국제화 도메인에서는 가능한 문자 쌍이 훨씬 많기 때문에 미리 막게 된 것입니다.

왜 비슷하게 생긴 문자들이 서로 다르게 취급되는 거죠? 처음부터 똑같이 취급했으면 문제가 없지 않았을까요?

어쩔 수 없습니다. 인간들이 만든 문자들이 원래 그렇게 생겼는걸요.

오늘날 세계의 문자들을 컴퓨터에서 다루는 표준은 유니코드Unicode로 통일되어 있습니다. 유니코드는 단순히 문자를 모아 놓은 것뿐만 아니라, 어떤 문자가 어떤 문자의 대소문자인지, 어떤 문자는 다른 문자가 같이 있을 때 어떻게 보이고 어떻게 상호작용하는지 등을 모두 기술하는 매우 복잡한 표준입니다. 당연히 비슷하게 생긴 문자라도 그 성질은 천차만별일 수 있기 때문에, 유니코드에서는 좋든 싫든 나눌 수밖에 없습니다.

이 정도면 국제화 도메인을 만들지 않는 게 나았을지도 모르겠습니다.

그렇게 생각하는 사람들도 제법 있습니다. 그러나 그동안 세계 곳곳에서 국제화 도메인과 비슷하지만 훨씬 문제가 많은 시스템을 만들려는 시도는 많이 있었습니다. 당장 한국의 경우에도 넷피아라는 업체가 비슷한 사업을 벌이며 사용자가 쉽게 삭제하기 어려운 프로그램을 배포해 큰 논란이 된 바 있습니다. 이런 비표준들이 난무하는 상황보다는, 하나의 그나마 제대로 만든 표준이 더 낫겠지요.

국제화 도메인 정책

국제화 도메인 정책이 왜 필요합니까?

앞에서 설명했듯, 국제화 도메인을 무제한으로 허용하면 큰 보안 문제가 생깁니다. 하지만 국제화 도메인 자체를 금지하기에는 수요가 많습니다. 이 때문에 국제화 도메인을 허용하되, 적절한 언어 제한을 두고, 각 언어 별로 무슨 문자들만 허용되는지 규칙을 정하게 되었습니다.

국제화 도메인 정책은 누가 결정합니까?

기본적인 정책, 즉 국제화 도메인을 만드는 방법 자체는 국제 인터넷 표준화 기구IETF (Internet Engineering Task Force)의 담당입니다. 하지만 개별 최상위 도메인이나 언어에 대한 정책은 국제 인터넷 주소 관리 기구ICANN (Internet Corporation for Assigned Names and Numbers)가 담당합니다. ICANN의 결정은 다시 각 국가 별 대표와 주요 국제 기술 기구들의 총의로 이루어집니다.

엄밀히 말해서, ICANN이 결정하는 정책은 최상위 국제화 도메인으로 제한됩니다. 즉 한국., рф. 같은 도메인에 어떤 문자가 들어갈 수 있는지를 결정하는 거지, 한국. 안에 тэханмингук.한국.이 등록될 수 있는지를 결정할 권한은 없습니다. 그러나 뒤에 설명하겠지만 이러한 구분은 이 논의에서는 큰 의미가 없습니다.

라벨 생성 규칙LGR (label generation rule)은 그럼 무엇입니까?

각 언어 별로 도메인을 이루는 라벨label 중 어떤 것을 허용할 것인지를 설명하는 규칙입니다. 이 규칙은 크게 두 부분으로 나눌 수 있습니다.

여기에서 볼 수 있듯, A라는 라벨이 이미 있을 때 B라는 라벨을 등록할 수 없을지라도 반대로는 가능할 수 있습니다. 그러나 이는 기술적인 구분이고 이 논의에서는 해당하는 상황은 없으므로 다루지 않습니다. 기술적인 내용을 원하신다면 RFC 7940과 RFC 8228을 참고하세요.

루트 존에서의 라벨 생성 규칙은 비교적 최근에 등장한 것으로, 최상위 도메인에 들어갈 수 있는 문자를 기계가 처리할 수 있는 공통 포맷으로 설명하려는 작업입니다. 2018년 2월 현재 한국어를 포함해 각 언어 사용자들을 대표하는 기구들이 라벨 생성 규칙을 제출하고 있는 상황입니다.

한국어 국제화 도메인 정책은 어땠습니까?

한국어 국제화 도메인 정책은 한국 인터넷 진흥원KISA (Korea Internet & Security Agency)과 하위 조직인 한국 인터넷 정보 센터KRNIC (Korea Network Information Center)가 담당하고 있습니다. KISA는 현재 kr., 한국. 등의 최상위 도메인을 관리하고 있습니다.

각 최상위 도메인 별로 한국어를 어떻게 취급하는지는 국제화 도메인 테이블에서 살펴 볼 수 있습니다. 2018년 2월 현재 한국어를 지원하는 모든 최상위 도메인은 다음 중 한 경우에 속합니다.

어느 쪽도 한자를 지원하진 않습니다. 이들 국제화 도메인 정책은 대부분 KISA의 조언을 받은 것으로 보입니다.

(이 글을 준비하는 과정에서 co.의 테이블이 잘못되어 있음을 발견했습니다. 설명에는 한글 2,350자를 지원한다고 쓰여 있으나 엉뚱하게도 일본어 테이블이 들어 있는 것입니다. 각 최상위 도메인 별로 얼마나 큰 자율권을 가지는지를 보여 주는 사례라 할 수 있습니다.)

라벨 생성 규칙이 "나쁠" 수도 있습니까?

안타깝게도 그렇습니다. 국제화 도메인의 취지와 주요 문제들을 생각하면, 아래 문제들을 가지고 있는 라벨 생성 규칙은 사용자에게 나쁘다고 볼 수 있습니다.

아래 규칙은 사용자에게 그렇게 나쁘진 않지만 다른 규칙이나 구현에 영향을 미칠 수 있어서 가능한 한 피하는 게 좋겠습니다.

우리는 제안된 라벨 생성 규칙이 위 조건을 상당수 만족한다고 보고 있습니다.

라벨 생성 규칙에 문제가 있다면 나중에 바뀔 수도 있습니까?

이론적으로 그렇습니다. 현실적으로는 상당한 부담이 될 것입니다.

한 때 허용되었던 도메인이 더 이상 등록 불가능해지는 경우는 종종 있습니다. 대표적으로 오늘날 대다수 최상위 도메인에서 한 글자 도메인은 등록할 수 없으나, x.org.같이 인터넷의 초창기에 등록된 도메인은 여전히 유지되고 있습니다. 마찬가지로 이전에 등록되었던 도메인은 이후에 규칙이 바뀌어도 유지되게 할 수 있습니다.

현실적으로는, 라벨 생성 규칙은 하나의 최상위 도메인뿐만 아니라 한국어를 허용하는 수많은 최상위 도메인에 퍼져 나갈 수 있습니다. 최상위 도메인은 상당한 자율권을 가지고 있기 때문에 등록 가능하고 불가능한 도메인에 대해 나름의 정책을 가지고 있고, 규칙 변경이 이 모든 정책과 상충되지 않는다는 보장은 없습니다.

확신이 가지 않는 규칙이 있다면 선제적으로 넣는 것보다는 나중에 상황을 보고 추가하는 것이 전체 인터넷 공동체에 더 유익한 일일 것입니다.

라벨 생성 규칙을 만들고 쓰지 않는 것도 가능합니까?

이번에 문제가 되고 있는 라벨 생성 규칙은 루트 존에 적용되고, 루트 존에 새 도메인 이름을 추가하는 데는 특별한 규칙이 적용되므로 한국 측에서 마음만 먹으면 쓰지 않을 수 있습니다.

하지만 좀 더 일반적으로, 이렇게 정의된 라벨 생성 규칙은 최상위 도메인이 아니라 차상위 도메인에서도 쓰일 가능성이 높습니다. 이미 각 최상위 도메인에서 한국어 국제화 도메인의 규칙은 (강제는 아니지만) KISA의 영향을 받고 있으므로, KISA가 새 규칙을 제시했다는 이유로 옮겨가는 주체가 생길 수도 있습니다.

이 점과 ICANN에서 라벨 생성 규칙을 적극적으로 권장하고 있음을 생각하면, 라벨 생성 규칙을 아예 안 만들거나 무시하는 선택지는 없다고 결론내릴 수 있습니다.

한자 도메인, 필요한가?

한자 도메인이 정확히 어떤 것을 가리킵니까?

편의상 한자 도메인이라는 말을 쓰고 있으나, 좀 더 정확히는 다음과 같이 나눌 수 있습니다.

우리는 한자 혼용 도메인은 금지되어야 하며, 한자 전용 도메인도 최대한 지양해야 한다고 생각합니다.

한국어에서 한자가 쓰인다면 한자 도메인이 왜 지양되어야 합니까?

한국어에서 한자와 한자어의 쓰임새는 서로 생각하는 바가 다를 것입니다. 불필요한 논의를 피하기 위해 이렇게 정리하고 싶습니다.

위 내용은 "현재의 사용"에 대한 것입니다. 한자가 한때 널리 쓰였음을 부정하지도 않으며, 한자 교육이나 컴퓨터에서의 한자 지원 등에 대해 어떤 판단도 하지 않습니다. 그러나 한국어에서, 특히 2000년대 이후에 한자의 사용이 한글과 비교할 수 없을 정도로 줄었다는 것을 부정할 수는 없습니다. 이러한 문자를 도메인에 쓸 수 있게 하려면 충분한 준비와 근거가 필요하다는 것이 저희의 굳은 생각입니다.

한자 혼용 도메인은 왜 금지되어야 합니까?

한자 혼용 도메인은 그 비용에 비해 쓰임새가 극히 제한됩니다. 앞서 말했듯 설령 한자 혼용 도메인을 허용해도, 그 주된 쓰임새는 고유 명사나 일반 명사를 한자로 쓰는 것이 아니라 한자를 꾸밈 용도로 쓰는 수준에 그칠 것입니다. 그러나 이런 사소한 장점을 취하기엔 단점이 너무 많습니다.

한자 혼용 도메인은 예측하기 어렵습니다. 대전도시공사.한국.의 한자 혼용 도메인은 大田都市公社.韓國.일 수도 있지만 大田도시공사.韓國.일 수도, 대전都市公社.한국.일 수도 있습니다. 일반적으로 한자로 표기할 수 있는 낱말이 n개라면 각 낱말을 한글 또는 한자로 표현할 수 있으므로 한자가 포함된 도메인은 2n-1개 있을 수 있습니다. 웹사이트 운영자는 모든 가능한 도메인을 구입하거나, 자주 쓰일 법한 도메인만 구입하고 다른 문제가 생기지 않길 기도하는 수밖에 없습니다.

한자 혼용 도메인은 한국어나 한글을 모르는 외국인이 입력할 수 없습니다. 한국어를 모르거나, 한글을 입력할 수 없는 사람이 한국의 도메인을 입력하는 상황은 한자 도메인의 쓰임새로 종종 등장합니다. 이런 상황이 존재한다고 가정하여도, 한자 혼용 도메인은 전혀 도움이 되지 않습니다. 마치 "서울驛"이라고 써 놓고 "서울"을 일본인이나 중국인이 이해하길 바라는 것과 비슷합니다. "首尔站", "ソウル駅"같이 각 나라에서 이해할 수 있는 도메인이 대신 필요할 것입니다.

한자 혼용 도메인은 동형이의자 공격에 취약합니다. 한글과 혼동되는 한자는 상당히 많습니다. 얼마나 많으면 인터넷에서는 야민정음이라고 하여 한글을 다른 비슷한 한글이나 한자와 바꿔 쓰는 방법이 체계적으로 정리되어 있을 정도입니다. 사람들은 이런 데서는 유독 창의적이기 때문에 알려진 것만 막는 데도 한계가 있습니다. 차라리 한글과 한자를 처음부터 섞어 쓰지 않는 게 훨씬 안전합니다.

한자 전용 도메인은 왜 지양되어야 합니까?

한자 전용 도메인은 한자 혼용 도메인에 비하면 최소한의 사용을 기대할 수 있습니다. 그러나 여기에는 몇 가지 난점이 있습니다.

한자를 필요하면 입력할 수 있는 한국어 환경의 비율은 줄고 있습니다. 현재 주요 스마트폰 운영 체제에서, 한국어 환경으로 한자를 바로 입력할 수 있는 경우는 없습니다. 별도 앱을 설치하거나, 중국어 또는 일본어 입력기를 빌려야 합니다. 읽기도 많이 하지만 직접 입력하기도 하는 도메인의 특성을 생각하면 좋은 상황이 아니지요.

외국인이 입력하는 한자는 한국식이 아닙니다. 비록 유니코드가 한중일 통합 한자CJK unified ideograph라고 (잘못) 부르는 한자 대통합을 잡음 끝에 이루어 내긴 했지만, 한 국가나 지역의 문자 코드에서 둘로 나뉜 문자는 유니코드에서도 나뉘어 있기 때문에(예: 靑-青) 실제로는 제법 차이가 있습니다. 한국식 한자를 지원하는 것만으로는 이런 용례를 다룰 수 없습니다.

따라서 한자 전용 도메인을 굳이 지원하고자 한다면, 한국식 한자를 지원하는 것보다는 중국식 및 일본식 한자를 (그들의 기준에 맞춰서) 지원하는 것이 더 쓸모가 있을 것입니다.

한자 도메인은 시각 장애인들의 접근성을 침해합니다. 시각 장애인들은 스크린 리더나 점자에 의존할 수밖에 없는데, 스크린 리더나 점자로는 한자를 표현할 수 없거나, 한자를 표현하는 데에 한계가 있습니다. 단순히 한자의 음만 알려준다면 원래 한자로 적혀 있는지 한글로 적혀 있는지 알 수가 없으며, 훈과 음을 알 수 있다 해도 어떤 한자인지 정확히 알 수 없는 경우가 있습니다(예: '클 석'은 奭일 수도 있고 碩일 수도 있음).

한자 전용/혼용 도메인이 비한국어 한자 도메인에 영향을 줄 수도 있습니까?

그렇습니다. 라벨 생성 규칙은 다른 라벨 생성 규칙에 악영향을 주면 안 되는데, 여기서 말하는 악영향에는 한 규칙에서 정당한 이유로 불허된 라벨이 다른 규칙에서 허용되면 안 된다는 것도 포함됩니다.

이를테면, 한글처럼 생긴 한자가 들어 있는 중국어 또는 일본어 도메인을 한자 혼용 도메인으로 속일 수 있습니다. 중국어 또는 일본어 규칙에는 한글에 대한 내용이 없음에도 불구하고 한국어 규칙의 문제로 해당 국가의 사용자가 피해를 보게 된 것입니다. 라벨 생성 규칙에는 이런 경우를 대비하기 위해 해당 언어에서 쓰이지 않는 문자에 대해서도 규칙을 지정할 수 있게 되어 있습니다.

제안과 그 비판

여기에서 다루는 제안 문서는 PDF 파일로 받을 수 있습니다.

이 제안은 누가 썼습니까?

이 제안은 루트 존 LGR 프로젝트의 한국어 패널KGP (Korean Generation Panels)이라는 단체에서 제출한 것입니다. KGP는 앞서 언급한 KISA뿐만 아니라 여러 학자, 변호사, 컨설턴트 등이 참여하는 민관 협의체입니다.

이 제안은 언제부터 논의된 것입니까?

제안서 4.6장에서는 2013년 12월부터 논의가 시작되어 2016년 2월에 공식 발족, 2017년 12월에 제출되었다고 쓰여 있습니다. 다자간 인터넷 거버넌스 협의회KIGA (Korea Internet Governance Alliance)라는 단체의 제15차 주소인프라분과 회의록 맨 마지막 장을 보면 KIGA의 구성원들이 한글 gTLD 검토 패널, 즉 KGP에 참여하는 것으로 결정했습니다. KIGA의 구성원들이 주축이 되어 KGP가 결성되었으나, 이 두 단체는 서로 다른 목적을 가지고 있으며 운영 또한 별개입니다. 해당 단체 공개 논의로부터 이 라벨 생성 규칙 자체가 한중일 간의 협의에서 나왔음을 확인할 수 있습니다.

이 제안은 일단은 공개적으로 논의된 바가 여러 차례 있습니다. KIGA에서 진행하는 한국 인터넷 거버넌스 포럼KrIGF (Korea Internet Governance Forum)이라는 행사의 워크숍에서 2015년, 2016년에 공개적으로 다뤄졌었고, ICANN에도 관련 회의가 있을때마다 회의록이 올라왔었습니다.

그런데 이게 왜 이제서야 문제가 되는 것이지요?

대부분의 논의들이 홍보 없이 이뤄졌기 때문입니다.

한글 도메인의 경우 대중의 관심이 상당했고, 문제가 많았지만 유사한 시스템이 상용화되어 있어 문제가 있었을 때 바로 잡을 기회가 많았습니다. 그러나 이 논의는 업계에서도 국제화 도메인 정책에 관심이 있는 극히 소수만이 인지하고 있었으며, 일반인에게는 사실상 노출되지 않았습니다. 이런 논의는 "투명"하다고 할 수는 있으나 문제가 없다고 할 수는 없습니다.

제안에서는 어떤 이유로 한자를 넣어야 한다고 주장하고 있습니까?

제안에서 한자의 쓸모를 역설하는 부분은 3장에 집중되어 있습니다. 각 소제목을 뽑아 요약하면 다음과 같습니다. 아래 내용은 본래 영어인 것을 요약 번역한 것입니다.

  1. 3.1장 "한국 문자: 한글과 한자"에서는 한글 이전의 한자의 역사와, 그 이후의 한글의 쓰임을 서술하고, 한글이 주된 문자가 된 지 백 년이 채 안 되었다고 평합니다.
  2. 3.2장 "한국 문자의 주요 사용자 공동체"에서는 한자에 대한 이야기가 나오지 않습니다. 이 소제목에서는 한국어를 쓰는 주요 국가와 집단에 대해서만 다룹니다.
  3. 3.3장 "한국어와 한국 문자, 한글"에서는 첫 소제목의 내용을 되풀이합니다. 다른 내용은 사실상 한 문단뿐인데 후술하겠습니다.
  4. 3.4장 "요약: 한글과 한자 모두 한국어 라벨 생성 규칙K-LGR (Korean label generation rules)에 필요하다"에서는 한글이 한자보다 더 많이 쓰이면서도 K-LGR에서 한글 한자 혼용을 허용해야 한다고 주장하고 있습니다. 이 또한 후술합니다.

(2장에서도 언급되듯 보통 "Korean script"라 하면 한글을 가리키지만 이 제안에서는 한글과 한자를 모두 포함하고 있는데, 이는 한글의 역사를 설명하면서도 정작 해당 부분의 소제목에는 한글과 한자가 모두 포함되는 이상한 결과로 이어집니다.)

3.3장에서는 전체 제안에서 유일하게 한자가 한글과 어떻게 상호작용하는지를 서술하는데, 여기에서는 한글 뒤에 그 뜻을 밝히기 위해 한자를 괄호 안에 넣는 게 보통이고, 한자 낱말과 한글 토씨·접사를 붙이는 경우가 드물게 있다고 밝히고 있습니다.

3.4장에서 K-LGR을 굳이 지원해야 하는 이유는 다음과 같이 밝히고 있습니다.

또한 부록 H(와, 간접적으로 부록 A부터 E까지)에서 제시된 증거를 바탕으로 다음과 같이 주장하고 있습니다.

우리는 대부분의 논점이 한자 도메인과는 무관하거나, 앞서 설명한 이유로 큰 근거가 되지 못한다고 주장하는 바입니다. 게다가 위 목록 중에는 큰 오해를 불러일으킬 수 있는 잘못된 근거도 여럿 있는데, 아래에서 깊이 살펴 보겠습니다.

국어기본법이 있는데 교과서에서 한자를 병기하려는 건 모순되는 게 아닙니까?

그 자체로는 모순되지 않습니다. 국어기본법 제14조에서는 한글 전용의 대상이 "공문서"라고 명확히 밝히고 있으며, 대통령령으로 괄호 안에 한자 등을 병기할 수 있다고 쓰고 있습니다. 교과서는 공문서가 아니며, 만에 하나 공문서의 범위를 넓게 보더라도 빠져 나갈 구멍은 있습니다.

이 주장의 진짜 문제는 이 정책이 2018년 1월 9일에 폐기되었다는 점입니다. 네, 이 제안은 제안서가 공개되기 2주일 전에 폐기된 정책을 근거로 한자 병기도 아닌 한자 혼용을 주장하고 있는 셈입니다.

한자에 대한 증거가 있다고요?

그렇습니다. 이러한 증거는 이를테면 유니코드 같은 곳에서 어떤 문자가 필요하다고 제안을 넣을 때 사용하는 방식입니다.

안타깝게도, 아무래도 좋은 증거를 찾지 못한 모양인지, 제안서의 부록 A부터 E까지에 제시된 증거는 여느 한국인이 보아도 바로 비판이 가능할 정도로 상태가 좋지 못합니다. 예를 몇 가지 들어 보았습니다.

그래서, 어떤 한자들이 포함되었습니까?

KS X 1001의 한자 4,620자와 IICORE의 한국 측 문자 4,744자(제안에는 4,743자라고 잘못 쓰여 있습니다)의 합집합인 4,758자가 포함되었습니다.

보통 KS X 1001에는 한자 4,888자가 들어 있다고들 하지만, 사실 여기에는 음가가 여러 개인 한자가 중복되어 들어 있기 때문에 이들은 제외되었습니다.

IICORE는 한중일에서 각 국가들이 널리 쓴다고 여기는 문자들만 뽑아서 "한중일 필수 한자"라는 명목으로 제안된 한자 집합입니다. 이 집합은 2004년에 유니코드의 옛 버전을 기준으로 만들어졌으며, 그 뒤로 한 번도 갱신된 적이 없는 데다 현 시점에서 IICORE를 쓰는 곳이 거의 없다는 점에서 역사적인 의미는 있을지언정 그 실용성이 불분명한 상황입니다. 심지어 IICORE에서 KS X 1001에 포함되어 있지 않은 한국 측 문자 상당수는 그 출전이 불분명한 상태로, 이러한 문자를 굳이 넣어야 하는지 의문이 듭니다.

물론, 제안에는 한국식 한자를 굳이 제안에 넣을 필요가 있는지에 대한 정당한 이유는 없습니다.

K-LGR의 이체자 그룹variant group은 어떻습니까?

이 또한 치명적인 수준으로, 제안의 전체적인 상태에 화룡점정을 찍는 내용입니다.

앞서 살펴 보았듯이 한글과 한자 사이에는 상당히 많은 동형이의자가 있습니다. 그럼에도 불구하고 이 제안에서는 한자들끼리의 동의이형자에만 신경 쓴 나머지, 사용자에게나 타국에게나 더 중요한 한글-한자 동형이의자를 거의 포함하고 있지 않습니다. 다음은 포함된 목록입니다.

나무위키의 야민정음 문서에서 제시된 예 중 대부분의 글꼴에서 혼동할 수 있는 문자 쌍은 이 밖에도 30여 개 정도 됩니다. 앞에서 언급한 숲↔金이 대표적이고, 그 밖에도 이를테면 이런 것들이 있습니다. 모두 혼동하기 쉽지만 K-LGR에 언급되지 않았습니다.

야민정음이 한국어 (데스크톱) 환경에서 그나마 쉽게 입력할 수 있는 문자가 대부분임을 감안하면, 실제로 가능한 문자 쌍은 수십 개에서 수백 개까지 늘어날 수 있습니다. 제안서는 이러한 위험에 대해서는 무심합니다.

헉, 근데 설마 이런 문제를 모르고 제출했을까요?

솔직히 우리도 알 수는 없습니다. 문제를 정말로 몰랐는지, 알고서도 시간에 쫓겨 그냥 제출한 것인지는 당사자들이 해명하기 전까지는 섣불리 추측할 수 없습니다. 다만 KGP와는 독립적으로 운영되기 때문에 직접적인 연관이 없지만, KGP와 상당수 인원 구성을 공유하는 KIGA의 주소자원분과 회의록에선 관련 내용을 찾아볼 수 있었습니다.

KIGA에서 저러한 과거 논의가 있었던 것을 생각하면, 제안이 어느 정도 무리가 있음은 KGP 측에서도 알고 있었지 않았을까 추정됩니다. 물론 허황된 시각이나 이상한 조사 결과도 보입니다.

회의록에서는 지금은 한자가 별로 안 쓰이지만 5~10년 안에 어떻게 될지 모르는 상황에서 확보를 안 해 두기는 어렵다는 취지의 발언이 여러 차례 나옵니다. 이 시각이 정당한지는 여러분이 판단하셔야겠습니다만, 하나 확실한 건 5~10년을 내다 본다는 제안은 5~10년 후에 봐도 논리가 탄탄해야 한다는 점입니다.

우리는 요구합니다

현재 진행되고 있는 K-LGR 제안은 실용적으로나 기술적으로나 잘못되었기에 그대로 통과되어서는 안 됩니다! 이는 한국어 사용자에게나 다른 언어 사용자에게나 큰 부담을 지울 것입니다.

한자 도메인을 정부 측에서 받아들이기 어려울 것이기에 조용히 처리하겠다는 발상을 버리십시오. 오차 범위도 제대로 안 나올 이상한 설문 조사로 정책을 정당화하지 말고, 좀 더 탄탄한 논리를 개발하여 정책 결정자가 아닌 국민들을 설득하는 것이 상식적인 발상일 것입니다.

무엇을 할 수 있을까요?

다음 방법으로 항의 의사를 보낼 수 있습니다.

글쓴이들

이 글과 웹사이트, 공개 서한을 작업한 사람들은 다음과 같습니다. (가나다순)

저희와 뜻을 같이 하시는 분께서는 글쓴이들에게 연락해 주세요.