완성형/중복 한자
1. 개요
KS X 1001 완성형(이하 KS 코드)은 독음이 여러 개인 일부 한자를 그 독음 수만큼 중복 배당하는 정신 나간 짓을 저질렀다. 예를 들어 樂의 경우 '락', '악', '요' 셋에다가 두음 법칙을 적용한 '낙'까지 해서 총 4개의 코드에 중복 배당돼 있다. 졸지에 닮은꼴 문자가 생겨난 셈.
일본이나 중국, 대만, 심지어 북한조차도 이런 식으로 한자를 중복 배당하지 않았다. 일본어의 한자 독음은 한국어보다 다양하므로[1] 만약 일본이 JIS 코드에 KS 코드와 같은 식으로 한자를 독음 수만큼 중복 배당했다면 JIS 코드와 유니코드에 生의 호환용 한자가 수십 개나 존재했을 것이다.[2]
2. 문제점 및 결점
이와 같이 발음이 다르다고 같은 문자를 일부러 중복 배당하는 것은 영어에서 f'''a'''ther, th'''a'''t, '''a'''bout 등의 a의 발음이 모두 [ɑ(ː)], [æ], [ə]로 다르니 a를 여러 번 중복 배당하는 것[3]과 한국어에서 '물'''고'''기'의 '고([꼬])'와 '불'''고'''기'의 '고([고])'의 발음이 다르니 '고'를 두 번 중복 배당하는 것과 다를 바가 없다. 그 어떤 문자 코드도 발음이 다르다고 문자를 중복 배당하지는 않았는데, 왜 KS 코드는 한자에 대해서만 그렇게 했는지는 상식적으로 이해할 수 없다. 즉 발음이 다르다고 같은 문자를 일부러 중복 배당하는 것은 정말로 생각이 없는 짓이었다고 할 수 있다.
이로 인해 생기는 문제점 및 결점은 다음과 같다.
첫째, 똑같아 보이는 문자가 내부 코드상으로는 다르게 처리되다 보니 문자열 검색이나 비교 등에서 오히려 불편을 초래한다. 실제로 이 정신 나간 짓의 결과로 이런 일이 생기기도 하며, 이 글에서 언급하는 바와 같이 온라인 서점에서 한자가 들어간 책 제목을 검색할 때도 문제가 될 수 있다.[4]
또한 같은 한자가 여러 개의 코드 값을 가진다는 것을 모르는 사람이 대부분이라는 것이다. 예를 들어, 年金(연금)이라는 단어를 입력할 때 누군가는 '연금'으로 변환해서 입력할 수도 있고 누군가는 年의 본 음가인 '년금'으로 변환해서 입력할 수도 있다(그리고 이 중복 한자 문제를 아는 사람은 '년김'으로 변환해서 입력할 수도 있다). 즉 작업자가 누구냐에 따라 똑같은 한자 단어를 다른 코드로 입력하게 되고 만다.
둘째, 이 중복 배당이 모든 독음을 커버하는 것도 아니다. 예를 들어 初八日(초'''파'''일), 六月('''유'''월), 十月('''시'''월), 木瓜('''모'''과), 困難(곤'''란'''), 娑婆(사'''바'''), 邯鄲之夢('''한'''단지몽), 唵川面('''옴'''천면), 紙杻驛(지'''축'''역) 등의 '파', '유', '시', '모', '란', '바', '한', '옴', '축' 등에는 별개의 코드가 주어지지 않았으며, 亘(긍, 선)은 '긍'만 고려되었고 射(사, 석, 야, 역)는 '사'만 고려되었고 敦(단, 대, 돈, 조, 퇴)은 '돈'만 고려되었다. 그리고 사이시옷을 넣는 6개 한자어 庫間('''곳'''간), 貰房('''셋'''방), 數字('''숫'''자), 車間('''찻'''간), 退間('''툇'''간), 回數('''횟'''수)에서 등장하는 사이시옷이 추가된 한자음 '곳', '셋', '숫', '찻', '툇', '횟'에도 별개의 코드가 주어지지 않았다.
게다가 일관성조차 없다. 똑같은 독음을 가진 한자인데 어떤 것은 두음 법칙을 적용해서 중복 배당하고 어떤 것은 두음 법칙도 적용하지 않고 중복 배당하지도 않았다. 예를 들어 KS 코드에서 '력'이라는 독음을 가진 한자는 力, 曆, 歷, 瀝, 礫, 轢, 靂이 존재하는데, 이 중에서 力, 曆, 歷, 轢은 '력'뿐만 아니라 두음 법칙을 적용한 '역'이라는 독음으로도 중복 배당돼 있지만, 瀝, 礫, 靂은 오로지 '력'으로만 존재하고 '역'으로는 존재하지 않는다. 그래서 力學(역학)의 力은 '역'으로 변환해서 '역' 전용 (호환용) 한자를 입력할 수 있지만, 礫巖(역암)의 礫은 '력'으로만 변환·입력해야 한다. 즉 독음에 따라 같은 한자를 중복 배당한 게 실질적으로 별 도움이 되지 않는다.
한자 중복 배당에 대한 그나마 말이 되는 이유를 굳이 생각해 보자면 아마도 '한글→한자' 변환뿐 아니라 '한자→한글' 변환까지 억지로 고려하다 보니 이렇게 되어 버린 게 아닌가 싶다.[5] 가령 한자 '李'가 '리'에만 등록되어 있다면 한자명 '李哲秀'를 도로 한글로 변환했을 때 '리철수'가 된다. 대한민국 맞춤법에서는 두음 법칙을 인정하고 있으므로 '이철수'로의 변환을 보장하기 위해 '리'에 해당되는 '李'와는 별도로 '이'에 해당되는 '李'를 만들어 배당해 두고, '한글→한자' 변환 시에는 '이'→'李('이' 전용)', '한자→한글' 변환 시에는 '李('이' 전용)'→'이'의 과정을 따르게끔 의도한 게 아닌가 싶다. 물론 자세한 의도는 알 수 없다. 하지만 그렇다 하더라도 결과가 너무 어설펐으며, 결국 독음만 다른 같은 글자에 대해 전혀 다른 코드 매핑이 이루어져 갖은 불편 사항만 생겼으므로 정신 나간 짓임은 분명하다. 차라리 문자 코드상으로는 한자를 중복 배당하지 않고, 한자 '李'를 한글로 변환할 때에는 '리'나 '이'라는 후보가 뜨게끔 했다면 훨씬 나았을 것이다.
그러나 어차피 '한자→한글' 변환은 상술한 '十月'→'시월', '邯鄲之夢'→'한단지몽', '數字'→'숫자' 같은 경우 때문에 별도의 단어 사전이 필요하다. 또한 '한자어+고유어' 구조의 합성어에서 한글 철자에 추가되는 사이시옷을 제대로 처리하려면 단어 사전에 한자와 한글이 섞인 단어도 집어넣어야 한다(예: '齒솔'→'칫솔', '空器밥→'공깃밥', '問題거리'→'문젯거리' 등). 형태소로만 따지면 '칫솔'과 같은 경우 '齒+ㅅ+솔'이므로, '齒ㅅ솔'과 같은 형태를 기준으로 하면 문제가 없겠으나, 현대 맞춤법에서는 음절별로 모아 쓰게 되어 있으므로 음절 말 자음, 즉 종성이 없는 한자의 받침에 사이시옷이 들어가는 경우까지 고려해야 한다. 결국 이러나 저러나 '한자→한글' 변환은 별도의 단어 사전으로 해결해야 한다는 말이다. 그리고 '한자→한글' 변환 시 두음 법칙이 적용된 음은 한자의 본음으로부터 기계적으로 생성해 낼 수 있기 때문에 두음 법칙은 굳이 중복 배당이 필요한 사항도 아니다.
그리고 '한글→한자' 변환 시, 문자 코드상으로 '李'가 하나만 있더라도 '이'를 변환할 때 나오는 후보에 '李'를 추가해 놓으면 그만이다. 실제로 중국어 입력기와 일본어 입력기는 이렇게 한다.
- 중국어 입력기는 快乐(kuàilè)에도 音乐(yīnyuè)에도 코드까지 정확히 똑같은 글자(유니코드: U+4E50, GB 2312-80: 32-54 (EUC-CN/CP936: 0xC0D6))를 사용한다. 乐는 중국의 기본 문자 코드 GB 2312-80에서는 le 위치에만 있고 유니코드에서는 U+4E50에만 있으나, 乐의 독음이 lè(한국 한자음 '락'에 해당됨)일 때도 yuè(한국 한자음 '악'에 해당됨)일 때도 똑같은 코드의 똑같은 글자 乐가 전혀 문제없이 사용된다.
- 일본어 입력기는 生きる(いきる), 生む(うむ), 生地(きじ), 生じる(しょうじる), 誕生(たんじょう), 生物(せいぶつ), 生意気(なまいき), 生える(はえる), 芽生える(めばえる), 芝生(しばふ) 등에 코드까지 정확히 똑같은 글자(유니코드: U+751F, JIS X 0208: 32-24 (Shift_JIS: 0x90B6, EUC-JP: 0xC0B8))을 사용한다. 生는 일본의 기본 문자 코드 JIS X 0208에서는 せい 위치에만 있고 유니코드에서는 U+751F에만 있으나, 生의 독음이 무엇이건 간에 똑같은 코드의 똑같은 글자 生가 전혀 문제없이 사용된다.
3. 유니코드에서의 처리
유니코드는 한자 하나당 한 코드를 부여하는 것이 원칙이나, KS 코드와의 호환을 위해 KS 코드의 중복 한자들 중 하나만을 통합 한자 영역(U+4E00~U+9FFF)에 넣고 나머지는 호환용 한자 영역(U+F900~U+FAFF)에 넣었다. 樂의 경우 '악'에 해당되는 것만 통합 한자에 들어갔고 나머지 셋은 호환용 한자에 들어갔다.
유니코드는 기존 문자 집합과의 왕복 변환(round trip)을 위해서만 호환용 한자의 사용을 허용하고 있고, 다른 용도로 사용하는 것은 권장하지 않고 있다. 따라서 나무위키에서 한자 문서를 작성할 때는 통합 한자만을 사용하는 것을 원칙으로 하고 있다. 즉 樂의 경우 樂(악, U+6A02)만을 사용하고 樂(낙, U+F914), 樂(락, U+F95C), 樂(요, U+F9BF)는 사용하지 않는다. 호환용 한자를 사용하면 괜히 불편만 초래하니, 웬만하면 통합 한자만을 쓰도록 하자. 참고로 Chrome이나 Safari, 미디어위키에서는 호환용 한자를 입력하면 아예 통합 한자로 자동으로 바뀌며, 호환용 한자를 그대로 입력할 수 없다. 이 문서를 크롬이나 사파리로 편집하거나, 이 문서의 내용을 복사해 미디어위키에 붙여 넣으면 호환용 한자가 모두 통합 한자로 자동으로 바뀌게 된다.
미디어위키에다가 호환용 한자를 집어넣고 미리 보기를 실행하면 자동으로 통합 한자로 바뀌므로, 호환용 한자 → 통합 한자 자동 변환을 원하는 사람들은 미디어위키에 변환할 문자열을 넣고 미리 보기를 한 뒤 그 결과물을 복사해서 쓰는 방법도 있다.
만약 한국어 입력기로 일본어나 중국어를 입력할 경우(물론 일본어나 중국어를 한국어 입력기로 입력하는 것 자체가 권장되지는 않는다), 호환용 한자를 쓰면 제대로 인식·출력되지 않을 수도 있으므로 통합 한자만을 사용하는 것이 바람직하다. 아래 리스트에서 '통합 한자' 줄에 있는 음가로 변환해야 한다(예: 樂의 경우 '악'으로만 변환해야 하며, 年金의 경우 '년김'으로만 변환해야 함).
나무위키에서 호환용 한자를 검색했을 때 검색 결과에 이 문서와 의도적으로 호환용 한자를 쓴 문서 유니코드/F000~FFFF, 한자/KS X 1001, 한자/BMP, 알맞은 리다이렉트밖에 나오지 않는 것이 가장 이상적이다. 참고로 이 문서에서도 위에서 李와 樂을 언급하는 부분, 아래에서 林과 劉와 柳를 언급하는 부분, 아래의 중복 한자 목록 그 자체를 제외하고는 호환용 한자가 사용되지 않았다.
데이터 처리 시에 또한 OS나 에디터의 차이로 호환용 한자가 입력된 경우 다른 글자로 처리되는 문제가 있는데, 이를 해결하기 위해 많은 프로그래밍 라이브러리나 프레임워크 수준에서 지원을 해 주고 있다. 예를 들어 C#의 경우 Char나 String 타입에 정규화(Normalize)라는 함수를 통해 하나의 대표 코드를 알아내는 게 가능하다.
참고로 리그베다 위키 시절에는 호환용 한자를 문서 제목에 쓸 수 있었으나, 나무위키에서는 호환용 한자를 문서 제목에 사용할 수 없다. 문서 제목에 포함된 호환용 한자는 문서 편집 시에 저절로 통합 한자로 바뀐다. 다만 문서 내용에 포함된 호환용 한자는 (크롬이나 사파리 등 자체적으로 정규화를 실시하는 웹 브라우저를 사용하는 경우를 제외하고는) 그대로 유지된다.
그리고 중복 한자의 모습은 글꼴에 따라 완전히 같을 수도 있고 약간 다를 수도 있다. Source Han Sans는 완전히 같은 모습을 보이고,[6] Microsoft Windows의 기본 한국어 글꼴 '돋움'은 약간 다른 모습을 보인다(참고).[7]
4. 다른 언어 문자 코드와의 호환 문제
다른 언어 문자 코드에는 기본적으로 KS 코드 유래의 호환용 한자가 존재하지 않으므로, 일본어·중국어 웹사이트에서 KS 코드 유래의 호환용 한자를 입력하면 인식이 안 되는 경우가 있다. 실제로 한국인이 일본어·중국어 웹사이트에서 자신의 한자 이름을 한국어 입력기로 입력하면 간혹 호환용 한자 때문에 인식이 안 되는 문제가 생긴다.
사례 1은 林(림, U+6797)이 아니라 林(임, U+F9F4)으로 입력했기 때문이고, 사례 2는 劉(류, U+5289) 또는 柳(류, U+67F3) 대신 劉(유, U+F9C7) 또는 柳(유, U+F9C9)로 입력했기 때문이다. 실제로는 통합 한자 林(U+6797), 劉(U+5289), 柳(U+67F3)는 모두 기본 일본어 문자 코드(JIS X 0208)에 있기 때문에 일본어 환경에서 문제없이 처리된다.
그러므로 일본어·중국어 웹사이트에서 자신의 한자 이름을 입력해야 하는 상황이라면 호환용 한자가 입력되지 않았는지 확인하거나, 호환용 한자 입력 여부를 확인하기 어렵다면 Chrome, Safari, 미디어위키 등 호환용 한자를 통합 한자로 자동으로 바꿔 주는 환경을 이용하거나 아니면 아예 처음부터 자신의 한자 이름을 일본어 입력기나 중국어 입력기로 입력하는 게 좋다.
KS 코드 제정 당시의 정신 나간 결정 때문에 사용자 입장에서 불필요하게 신경 써야 할 것만 하나 늘어난 셈이다.
5. 중복 한자 목록
모두 268자로, '두음'이 203자(75.7%), '일반'이 65자(24.3%)이다.
5.1. 두 번 중복(일반)
한국어 독음이 원래 두 개인 한자들이다. 두음 법칙에 의한 중복과는 달리 일정한 규칙이 없기 때문에 통합 한자로 입력하려면 그냥 외우는 수밖에 없다. 串, 金, 不의 경우 흔히 본음으로 알고 있는 관, 금, 불과 달리 곶, 김, 부로 입력해야 통합 한자가 나온다.
왠지는 알 수 없지만, 한컴오피스 한글의 경우 2007까지만 해도 串, 金, 復, 不의 매핑이 반대로 되어 있었다.[8] 유니코드 표준 매핑은 아래 표에 나온 그대로이다.
5.2. 두 번 중복(두음)
두음 법칙으로 인해 중복된 한자들이다. 이 경우 통합 한자로 입력하려면 두음 법칙이 적용되지 않은 본래의 독음으로 변환하면 된다. 예외로는 涅(개흙 녈)이 있는데, 이 글자는 중복 한자가 아니다(원래 음인 '녈'로는 아예 한자 변환이 되지 않으며, '열'로 변환하면 통합 한자가 나온다).
중복 한자 중 拏(붙잡을 나), 諾(허락할 낙), 怒(성낼 노), 異(다를 이)는 두음 법칙이 아닌 활음조 현상에 의한 중복 한자이므로 주의. 바로 위 문단에 있다. 이들은 원래 음이 '나', '낙', '노', '이'이며, '라', '락', '로', '리' 쪽이 바뀐 음이기 때문에 '나', '낙', '노', '이'로 변환해야 통합 한자가 나온다. 아래 '세 번 중복' 문단에 있는 寧(편안할 녕)도 원래 음은 '령'이 아닌 '녕'이므로 통합 한자 입력을 원한다면 주의할 것.
5.3. 세 번 중복
5.4. 네 번 중복
6. 관련 문서
- 한자/BMP
- 한자/KS X 1001
- 유니코드/F000~FFFF
- °(...) - 한자가 아니지만 한자키 조합 입력법에 뜬금없이 코드 페이지가 비슷한 0xA3C6인 F가 두번 들어가 있다.
[1] 일단 음독 외에 훈독이 존재하고, 음독과 훈독도 여러 종류가 있다.[2] 훈독이 많기로 악명 높은 한자이다.[3] 유니코드의 A(U+0041, 라틴 문자 대문자 에이), Α(U+0391, 그리스 문자 대문자 알파), А(U+0410, 키릴 문자 대문자 아)와 같은 경우는 속하는 문자 체계가 다르고 개별 문자 자체가 다른 문자이기 때문에 별도의 글자로 배당된 것이고(가짜동족어와 비슷하다고 보면 된다), 같은 문자 체계의 같은 문자가 중복 배당된 것이 아니다. 한글 자모 ㅁ(미음)과 한자 口(입 구)가 다른 문자이고 둘에 별도의 코드가 주어진 것과 같다.[4] 검색 엔진이나 소프트웨어, 시스템에 따라 이 중복 한자들을 똑같은 글자로 취급해 주기도 하고, 그냥 다른 글자들로 취급하기도 한다. 물론 똑같은 글자로 취급하도록 만들려면 검색 엔진이나 소프트웨어, 시스템 차원에서 별도의 처리가 필요하다.[5] 한컴오피스 한글이나 Microsoft Word와 같은 워드프로세서 등에서는 '한글→한자' 변환은 물론 '한자→한글' 변환도 가능하다.[6] Source Han Sans는 자형(glyph)은 하나만 마련해 놓고 그 자형 하나가 여러 유니코드 코드 포인트에 사용되도록 만들었다. 그러니 모습이 같을 수밖에 없다.[7] MS의 기본 한국어 글꼴들은 중복 한자를 하나하나 다 그렸기 때문으로 보인다.[8] 한/글 2010에서는 저 네 글자의 매핑이 유니코드 표준 매핑대로 고쳐졌다. 그래서 한/글 2010부터는 저 네 글자를 한글로 바꾸고자 할 경우 어떻게 바꿀지를 묻는다. 한/글 2007 이하 버전으로 작성된 글과의 호환성 또는 한/글 외의 환경에서 작성된 글과의 호환성을 위해서인 듯하다.[9] 유니코드에는 이 U+F92C 郎의 매핑이 올바른 U+90DE 郞가 아니라 U+90CE 郎로 잘못되어 있다. 이 매핑은 고칠 수 없기 때문에, U+FA2E 郞에 이 글자가 올바른 매핑(U+90DE 郞)으로 다시 배당되었다.[10] 유니코드에는 이 U+F9B8 隸의 매핑이 올바른 U+96B7 隷이 아니라 U+96B8 隸로 잘못되어 있다. 이 매핑은 고칠 수 없기 때문에, U+FA2F 隷에 이 글자가 올바른 매핑(U+96B7 隷)으로 다시 배당되었다.[11] 신자체를 위한 説(U+8AAC)이 따로 배당되어 있는데, 稅(U+7A05)도 마찬가지로 신자체를 위한 税(U+7A0E)가 따로 배당되어 있다. 그런데 사실 같은 글자들이다. 이보다 훨씬 더 엉망(?)인 益, 溢이 하나의 코드를 쓰는데도 말이다. 특히 益은 이들과 거꾸로 되어 있다. 통합 한자인 益(U+76CA)이 신자체로 활용되는 반면 호환용 한자에 있는 益(U+FA17)은 구자체로 되어 있다.