E,AHRSS

완성형

last modified: 2015-04-08 08:21:20 Contributors


Contents

1. 개요
2. 장단점
2.1. 이야깃거리
3. 통합 완성형
4. 유니코드
5. 현재의 완성형
6. 완성형에서의 한자
7. 기타 완성형 코드
7.1. KS X 1002 (KS C 5657)
7.2. 북한의 완성형
7.3. 7비트 2바이트 완성형

1. 개요

한글 인코딩 방식 중 하나. 현재 산업 표준이기도 하며, 표준 번호는 KS X 1001(과거 KS C 5601)이다. 인코딩은 EUC-KR로 이루어진다. 이 항목에서는 이 KS X 1001 표준에 대해 주로 서술한다.
글자 코드 세트에 쓸 문자를 현대 한국어에서 빈도가 높은 한글만 추려내어, 가부터 힝[1]까지 죄다 배당한 후 문자를 기록하는 방식으로, 가령 '속'이라는 글자를 기록한다면 가, 각, 간, 갇, 갈, 갉, 갊…으로 쭉 찾아가다가 0xBCD3로 표현하는 방식이다.

2. 장단점

외국어나 특수문자와 같이 이용하는 것을 미리 가정하고 만들었기 때문에 조합형에 비해 국제 표준과 충돌이 적다는 장점이 있다. 하지만 이 방식의 가장 치명적인 문제는 미리 조합되어 있는 글자 외의 문자는 어떻게 해도 표시할 수 없다는 점이다. 더군다나 1987년에 최초로 만들어진 기본 완성형 코드의 한글 글자 수는 겨우 2350자뿐이라서 조합형 완성형 논쟁 당시 조합형을 지지하던 사람들은 이 방식을 대차게 까대고는 했다. 나름대로 빈도를 조사하기는 했지만 저 정도 수로는 아무래도 부족했다. 한글 자체가 원래 초성 + 중성 + 종성의 조합으로 이루어지는 조합형 문자인데 이걸 전부 한 글자 한 글자 만든다는 것도 비효율적이라는 이유로 완성형이 무시당하는 데 한몫 단단히 했다. 또, 그런 식으로 코드를 배당하다 보니 글자를 완성하는 과정이 개무시되었다. 가장 대표적인 경우가 바로 ""이다. 분명 KS X 1001 코드 안에는 쓩이라는 글자가 있긴 있으나 "쓔"가 없어서 ㅆㅠㅇ이라고 써진다. 이건 뭐 아버지를 아버지라 부르지 못하고 형을 형이라 부르지 못하는 홍길동도 아니고.

그리고 나름대로 빈도 조사를 했으나, 완성형 2350자만으로는 표준어조차 다 적을 수 없다. 하다(더 들어가지 못할 만큼 가득하다), fuxx('부엌'의 준말), 큼('냉큼'의 센말), 베르(프랑스 지명 Verdun), 하다('하얗다'의 과거형), 거('거칠다'의 명사형), 전니다('전화입니다'의 준말 전화는 없어요!), 되, 되다('되뇌어', '되뇌었다'의 준말. 되어 → 돼, 되었다 → 됐다와 같은 원리다), 섬(갑자기 소름이 끼치도록 무시무시하고 끔찍한 느낌이 드는 모양. 2014년 12월에 표준어가 됨), 모 쇠 만드는 기업의 계열사에서 지은 아파트 이름인 더 등도 적을 수 없다. 백괴사전KS X 1001 문서에 표준어인데도 표기할 수 없는 단어들의 예가 목록이 나와 있다. 이런 데엔 또 디테일한 백괴사전

또한 한국어의 발음 표기를 위한 글자가 많이 빠져 있다는 점도 문제다. 예를 들어 발음 교육을 위해 '갈등', '물엿'의 발음이 /갈뜽/, /물렫/임을 표시하고자 할 때 '뜽', '렫' 자가 없어서 '갈등', '물엿'의 발음을 표기할 수 없다.

완성형 한글 2350자의 목록은 완성형/한글 목록 참고. 특수 문자 목록은 완성형/특수 문자 참고.

2.1. 이야깃거리

2011년 네이트의 '오늘 운세'에서 마지막이 으?으?! 로 끝나서 점술가가 점 보다가 급사했다며 유머짤로 퍼져나가다가 결국 인터넷 유행어가 된 적이 있다.

으으.jpg
[JPG image (Unknown)]


바로 EUC-KR에 '쌰'가 없어서 생긴 참사.

3. 통합 완성형

그 후, 윈도우즈 95가 발매되면서 이 OS에 탑재된 UHC, 즉 통합 완성형(95 베타에서는 '확장 완성형'이라 하였음)이라는 코드가 다시 문제가 됐는데, 이 통합 완성형이라는 코드는 원래 완성형에서 표시 못 하던 2350자 외의 글자들을 별도의 영역에 추가로 붙여넣어서 만든 코드이다. 도스 및 윈도우즈 95 이전 버전의 프로그램과 충돌하는 문제도 자주 있었다. 때문에 일부 사람들은 윈도우즈 95를 사용하지 말자는 의견까지 내곤 했지만, 결과는 지금 보면 알 수 있듯이 MS의 승리(…).

예외적으로 윈도우즈용으로 나왔던 프로그램 중에서도 조합형 한글을 사용했던 프로그램이 있는데, 아래아 한글 3.0 윈도우판이 그것. 옛한글까지 지원하는 아래아 한글로서는 필연적인 선택이었을 것이다. 프로그램 내부에서는 조합형으로 모든 글자를 처리하고, 프린터 등으로 글자를 보낼 때에만 확장 완성형으로 컨버팅을 해서 날리는 방식을 사용했는데, 당연히 효율이 무지 떨어졌고 윈도우 안에 있는 폰트는 하나도 이용할 수 없다는 치명적인 단점 때문에 이후 버전에서는 내부 라이브러리를 완전히 교체하기도 하였다. 교체 이후에는 윈도우에 설치된 폰트도 사용 가능해졌고, 이 방식은 한글 97까지 계속 사용되었고, 워디안부터는 유니코드로 교체되었다. 끝까지 완성형을 사용 안 하고 유니코드 시대가 올 때까지 버틴 유일한 프로그램이다.

4. 유니코드

이후 나온 유니코드는 완성형과 조합형을 둘 다 가지고 있는 코드이다. 현대 한국어의 자모 조합으로 나타낼 수 있는 모든 완성형 한글 11172자와 조합형으로 쓰는 한글 초·중·종성을 모두 가지고 있다. 이것은 유니코드가 생길 때 완성형과 조합형이 모두 국가 표준이었기 때문이다. 당연히 여기서는 통합 완성형의 문제가 모두 해결되어 있다. 하지만 유니코드에서 조합형의 형태로 한글을 구현하는 경우는 완성형에 없는 옛한글을 표현할 때를 제외하고는 별로 없는 편이다. 또한 통합 완성형에서 유니코드로 넘어가면서 이런저런 문제가 많이 발생하고 있는 상태이다.

특히 웹 문서에서 문제가 자주 생기는데, 페이지 인코딩은 EUC-KR로 해 놓고는 정작 EUC-KR에 포함되지 않는 글자(즉 통합 완성형에 추가된 글자)를 넣어서 변환하면서 인식이 안 돼서 깨지기도 하고, EUC-KR 페이지에서 확장 한글을 표시해주는 방식이 웹 브라우저마다 달라서 IE에서는 '뷁'이었던 것이 파이어폭스에서는 'ㅤㅂㅞㄺ'[2]처럼 자모별로 흩어지기도 하는 등 온갖 에러가 발생하곤 한다(이것은 역시 확장 완성형과 완성형의 차이로, 파이어폭스가 확장 완성형을 지원하지 않았기 때문이다. 엄밀히 말하면 EUC-KR은 확장 완성형이 아닌 완성형이므로 파이어폭스 쪽이 맞게 표현하는 것). 그 최대 피해자 중 하나가 오위키 시절의 엔하위키(…). 이때 이를 해결하기 위해 많은 위키니트들이 열심히 노가다를 했다(모니위키로 이전한 뒤에는 UTF-8로 인코딩이 바뀌었으므로 더 이상 이런 문제가 없다). 2014년 현 시점에서는 이런 문제는 많이 사라졌는데, 웹 환경이 UTF-8로 대부분 바뀐데다 웹 브라우저의 한글 지원도 상당히 좋아졌기 때문이다. 거기다 OS도 유니코드를 기본으로 지원하고, 특히 윈도우는 Windows XP로 넘어오면서 아예 유니코드를 기본 언어 인코딩으로 채택했기 때문에 이런 문제는 거의 사라진 상태다. 고전 프로그램을 돌린다던지 공개적인 장소에서는 돌릴 수 없는 게임[3]을 즐긴다던지 하는 문제가 아니라면 이런 언어 코드 충돌은 보기 힘든 환경이 되었다.

5. 현재의 완성형

저 2350자 기본 완성형은 아직도 메모리 용량에 목숨 걸어야 하는 일부 분야에서 사용되고 있는데[4], 대표적인 분야가 피처폰. 그렇기 때문에 일부 제조사의 핸드폰에서는 문자 메시지에서 '뷁'을 사용할 수 없다(…). 뿐만 아니라 앞서 언급한 '쓩' 같은 글자는 여전히 홍길동 신세를 탈출하지 못하고 있으며 심지어는 '뛔'도 마찬가지이다(분명히 '뛔'는 있다. 하지만 핸드폰에서 뛔를 쓰려면 ㄷㄷㅜㅓㅣ의 순서로 써야 하기 때문에 중간에 '뚸'를 거쳐야 하지만 그 글자가 2350자 안에 없다. 천지인 자판(ㆍ, ㅡ, ㅣ)을 채택하는 핸드폰의 경우 ㄷ → ㅌ → ㄸ → 뜨 → 뚜 → 뜌 → 뚸 → 뛔 순으로 써야 되는데 '뚸' 바로 앞의 '뜌'도 없다).

그러나 이마저도 폰의 용량이 커지면서 서서히 사라지다가[5], 스마트폰 시대가 오면서 유니코드로 대체되었다. 스마트폰에서 가장 많이 쓰이는 OS인 안드로이드iOS는 글로벌 환경을 지원하기 때문에 유니코드를 쓴다.

책을 컴퓨터로 편집하는 데 쓰는 프로그램의 대다수가 EUC-KR 방식만을 지원하기 때문에 일본어 이름을 지니고 있는 몇몇 인물들이 생고생을 하기도 한다. 대표적인 예로 을 들 수 있다.
실제로 일본 영화 러브레터가 국내에 수입될 당시, 당시에는 이 영화를 제작한 이와이 슌지(岩井 俊二, いわい しゅんじ) 감독의 자를 제대로 표기할 수 없어 이와이 슈운지로 표기하는 경우가 왕왕 있었는데, 이렇게 하면 장음으로 오해하기 딱 좋다.[6] 그리고 외래어 표기법에 따르면 장음 표기는 따로 하지 않는다. 또한 미즈노 슌페이는 미즈노 페이로 개명당했다.

방송업계에서 쓰는 시스템도 완성형이라 특정한 단어들을 표현하는데 애를 먹기도 한다. 대표적인 예로 신화의 노래 '으쌰으쌰'는 를 표현할 수 없어 만 다른 프로그램을 이용해 다른 폰트를 사용하거나, 싸에 덧칠을 하는식으로 표현했다. 이 시기 노래방 책자나 불법 복제 테이프 등에서도 ㅆ 따로 ㅑ 따로 해서 '으ㅆㅑ으ㅆㅑ'라고 표기되어 있기도 했다. 심지어 1990년에 MBC에서 방영한 드라마 방각하자가 없어서 대본이나 편성표에는 '돔방각하'로 인쇄하는 경우도 있었다(기사).

이는 대한민국의 행정 전산망도 예외가 아니다. 대한민국의 행정 전산망 역시 아직도 완성형을 쓰고 있기 때문에 일부 이름을 표기하지 못한다. 실제로 설라는 사람의 경험담을 보면 전산 시스템 때문에 엄청 고생하는 것을 알 수 있다.[7]

또한 언리얼 엔진과 같은 외국산 엔진의 경우, 문자를 비트맵으로 불러들여 사용하기 때문에 알파벳이나 일본어처럼 문자의 수가 정해져 있다면 문제가 없겠지만 한글처럼 조합하여 표시하는 경우 문자를 표시하기 위한 비트맵 크기가 어마어마해진다.[8][9]

물론 단점만 있는 것은 아니다. 국제 표준과 잘 맞아서 통신에 이용하기 수월하며, 글자가 순서대로 저장되어 있으므로 쉽게 오름차순/내림차순 정리가 가능하다는 장점이 있다(통합 완성형은 해당 안 됨. 그리고 조합형도 정렬은 됨).

6. 완성형에서의 한자

한자의 경우, 독음이 여러 개인 한자를 그 독음 수만큼 중복 배당하는 병크[10]를 저질렀다. 이에 대한 자세한 정보와 중복 한자의 목록은 완성형/중복 한자 항목 참고. 한자 268자 중복하는 대신 한글이나 더 넣지

7. 기타 완성형 코드

7.1. KS X 1002 (KS C 5657)

KS X 1001을 보충하기 위해 1991년에 만든 문자 집합이었으나... 완전히 묻혔다. 정말 아무도 안 쓴다. 현대 한글 1930자, 옛한글 1675자, 한자 2856자 등을 포함하고 있다. 이 글도 참고.

다만 저 중에서 한자 2856자만은 살아남은 듯하다. Microsoft Windows의 기본 한국어 글꼴과 기본 한국어 IME는 저 2856자를 지원한다.

7.2. 북한의 완성형

북한에서도 완성형 코드를 사용하는데 남한의 KS X 1001과 비슷해 보이지만 전혀 다른 '국규 9566'(KPS 9566)이라는 완성형 코드를 쓴다. 한글은 2679자(후술할 '특수 문자' 한글 제외), 한자는 4653자 배당돼 있으며, 특징으로는 특수 문자 영역에 한글 6글자가 꼽사리 껴 있다. 그 6글자는 역시나 "김, 일, 성, 김, 정, 일". 그리고 저 글자들을 유니코드에도 추가 신청했다가 당연히 거절당했다.


그리고 2014년에는 김, 일, 성, 김, 정, 일 바로 뒤에 김, 정, 은추가된 것이 확인되었다! 링크한 스크린샷은 붉은별 3.0 서버용의 화면을 찍은 것이며, 출처는 이 글이다.

국규 9566의 한글 배열 순서를 보면 남한의 KS X 1001과는 매우 다르게 되어 있다. 남북 분단 후 북한이 아예 한글 정렬 순서를 새로 짜면서 그것이 그대로 반영된 건데, 한때 북한은 유니코드의 한글 영역이 남한의 한글 정렬 순서로 되어 있던 것이 싫어서 유니코드의 한글 영역을 북한식으로 쓴 적이 있었다. 이 문제에 대해서는 남북한 한글 코드의 충돌 문제 항목을 참고 바람.

7.3. 7비트 2바이트 완성형

최상위 비트를 사용할 수 없는 환경에서 사용하기 위해 만들어졌다. aB와 같이 로마자 소문자 뒤에 대문자가 오는 경우 또는 }a와 같이 기호 뒤에 로마자가 오는 경우 등 영어에서 일반적으로 쓰이지 않는 조합에 자주 쓰이는 한글을 넣은 방식이다. 이 방식을 사용하는 한글 카드가 저렴했기 때문에 애용됐지만, 표현할 수 있는 글자 수가 1300여 자로 제한되고 진짜로 소문자 + 대문자 조합을 의도한 경우가 한글로 표시되는 경우도 있어서(dBASE가 '늦ASE'로 출력됐다) 쓰이지 않게 됐다.

----
  • [1] 가장 마지막에 올 글자는 힣이겠지만… 이런 건 아햏햏 같은 조어가 아닌 이상 쓰일 일이 없을 것이다. 참고로 이런 안이한 생각이 완성형이 가지고 있는 주요 문제점을 불러왔다. 일단 예시로 든 힣이란 글자만 봐도 웃음소리의 의성어로 쓸 여지가 있으니.
  • [2] ㅂㅞㄺ 앞의 공백처럼 보이는 문자는 '한글 채움 문자'(0xA4D4, U+3164)이다. KS X 1001에서는 완성형 2350자에 없는 한글을 저 채움 문자 + 낱자 셋으로 표현하도록 규정하고 있다. 즉 파이어폭스 쪽이 표준인 셈.
  • [3] 이상하게도 이런 게임은 아직도 유니코드가 아닌 일본어 로케일을 사용하는 경우가 많아서 어플로케일이 아직도 필수에 가깝다.
  • [4] 옛 도스 환경의 조합형 한글 글꼴은 오히려 2350자 완성형 글꼴보다 용량이 적다(!). 초성 몇 벌, 중성 몇 벌, 종성 몇 벌(보통 초성 8벌, 중성 4벌, 종성 4벌이었다)을 디자인해 놓고 일정한 규칙에 따라 그 자형들을 조합해서(정확히는 겹쳐서. 일종의 레이어로 생각하면 된다) 11172자를 출력했기 때문이다(당시에는 글꼴을 이렇게 만들고 초성, 중성, 종성을 겹쳐서 출력했다). 필요한 자형 수는 많아야 몇백 개. 반면 완성형 글꼴은 2350자를 하나하나 디자인해야 하기에 옛 도스 환경의 조합형 한글 글꼴보다 용량이 클 수밖에 없다.
  • [5] 예를 들어 아의 햅틱 같은 폰 경우 위에 나타난 쓩, 뷁, 뛔, 쿈 등을 모두 표기할 수 있다.
  • [6] 다만 일본어에서 외래어나 의성어, 의태어를 제외하면 ん 앞에 장음이 오는 경우는 거의 없으며, 특히 한자 음독에는 ん 앞에 장음이 오는 경우가 아예 존재하지 않는다. 그래서 '슈운'이라고 적어도 그게 본래 しゅん임을 알 수 있기는 하다.
  • [7] EUC-KR을 특정 '프로그램'으로 알고 있는 것으로 보아, 문자 인코딩에 관련한 깊은 지식이 있는 블로거는 아닌 듯하다. 물론 이걸 알고 모르고를 떠나, '믜'가 입력이 안 되는 완성형 체제 자체는 까여야 마땅하다. 다만, 옛 한국어의 자음 + 는 늬, 희 등 일부를 제외하고는 모두 자음 + ㅣ로 변했기 때문에(기차 ← 긔챠, 마디 ← 마듸, 거미 ← 거믜, 나비 ← 나븨, 키(신장) ← 킈, 티끌 ← 틧글, 피우다 ← 픠우다), 현대 한국어 정서법에 따르면 '설미'가 돼야 하긴 하다. 물론 인명이니 본인이 특이한 표기를 쓰겠다고 하면 할 말 없지만…
  • [8] 알파벳 계열은 많아야 100개 정도, 한글은 대략 11000글자…
  • [9] 사실 이건 PC에서 문자 처리를 폰트를 이용해서 할 경우 비트맵으로 불러들여 처리하는 것보다 성능이 떨어지기에 도입된 방식이다. 이 때문에 2000년 이전에 개발된 게임의 경우 내부 글자를 폰트로 처리하는 경우는 별로 없다. 이때의 국산 게임도 완성형 폰트를 비트맵 파일로 만들어 표현하는 경우가 많았다.
  • [10] 똑같은 문자를 의도적으로 여러 개 배당하면 정보 처리에 혼란만 주기 때문에 충분히 병크라고 할 수 있다.