mir.pe (일반/어두운 화면)
최근 수정 시각 : 2024-11-13 09:07:25

완성형

한글의 전산화
<colbgcolor=#dddddd,#212121> 한글 인코딩 조합형 · 완성형( 한글 목록 · 중복 한자 · CP949) · 조합형 완성형 논쟁 · 남북한 한글 코드의 충돌 문제 · 한컴 2바이트 코드 · 한글 채움 문자( ㅤ) · 유니코드 · 옛한글
타자기와 키보드 두벌식 · 세벌식( 일반 자판 · 속기 자판) · 휴대전화 입력기 · 한영 키

파일:漢.svg 파일:漢_White.svg 한자
{{{#!wiki style="margin:0 -10px -5px; min-height:calc(1.5em + 5px); word-break:keep-all"
{{{#!folding [ 펼치기 · 닫기 ]
{{{#!wiki style="margin:-5px -1px -11px" 		<colbgcolor=#eee,#333> 서체와 자형 갑골문 · 금문 · 전서 · 예서 · 해서 · 행서 · 초서 · 정자( 표준자형) · 간체자( 간체자 논쟁) · 신자체( 목록 · 변화 규칙) · 본자 · 속자 · 약자 · 이체자 · 한중일 한자
성질과 분류 획(필순) · 구조 · 파자 · 육서 · 상형자 목록 · 훈음 · 부수 · 부수(중국) · 부수(설문해자)
표준화 상용한자 ( 한문 교육용 기초 한자 · 통용규범한자표 · 당용한자 · 일본의 상용한자 ( 목록) · 학년별한자배당표) · 한국어문회 한자검정시험 · 어문회 급수 · 대한검정회 한자급수자격시험 · 검정회 급수 · 한자한문지도사시험 · 인명용 한자표 · 광동어 정음 운동
주음·표음화·한자음 반절 · 주음부호 · 병음 ( 한어병음 · 월어병음) · 한글( 동국정운) · 훈독 · 음독 · 속음 · 한국 한자음 · 중국 한자음 ( 문백이독 · 상고음 · 중고음 · 근고음 · 양안 간 독음) · 일본 한자음 · 베트남 한자음 · 다음자
옥편 자전 · 설문해자 · 강희자전 · 옥편 · 이아 · 운서 · 광운 · 절운 · 집운 · 오음편해 · 한어대사전 · 대한화사전 · 중문대사전 · 이체자자전 · 한한대사전
색인 부수별 · 음별 · 획수별
국가별 사용 한자문화권 · 한문 · 백화문 · 한국의 한자 사용 · 한자어( 한국식 한자어 · 중국식 한자어 · 일본식 한자어 · 베트남식 한자어) · 언어간 동형이의 한자어( 고유명사) · 언어간 이형동의 한자어 · 우리말 새김
파생 문자 한글 전 한국어 표기 ( 국자 · 이두 · 향찰 · 구결) · 방언자 · 주음부호 · 가나 ( 히라가나 · 가타카나 · 헨타이가나 · 만요가나) · 측천문자 · 쯔놈 · 고장자 · 거란 문자 · 여진 문자 · 서하 문자
입력 · 검색 한자/입력기 · 창힐수입법 ( 목록) · 오필자형수입법 · 대이수입법 · 사각호마검자법
전산화 KS X 1001 · KS X 1002 · KPS 9566 · GB 2312 · JIS X 0208 · Big5 / 유니코드: 한중일 통합 한자 · BMP( 통합 한자 · 통합 한자 확장 A · 호환 한자) · SIP(통합 한자 확장 B~F) · TIP(통합 한자 확장 G) · 한자 모양 설명 문자
기타 고사성어 · 천자문 · 한시 · 어조사 · 음역 · 서예 · 올해의 사자성어 · 올해의 한자 · 국한문혼용체( 논쟁) · 국한문병용체 · 한자 교육 ( 한문(교과) ( 2022 개정 교육과정/한문과) · 한자 교육 찬반 논쟁) · 중복 한자 · 벽자 · 통자 · 갖은자 · 한자오자 · 미상 한자 · 유령 문자 · 특이한 한자 · 닮은꼴 한자 · 국호 · 주기율표 · 음률 · 한자문화권 고유명사 표기 · 자주 틀리는 한자어 · 훈을 혼동하기 쉬운 한자 · 부수를 혼동하기 쉬운 한자 · 한자를 혼동하기 쉬운 단어 · 발음이 여럿인 한자어 · 한국의 성씨( 인구분포 · 지역별) · 후리가나 · 창작 한자 }}}}}}}}}


1. 개요2. 장점3. 단점
3.1. 완성형으로 쓸 수 없는 예시들
4. 통합 완성형 (확장 완성형)5. 유니코드6. 현재의 완성형7. 완성형에서의 한자8. 기타 완성형 코드
8.1. KS X 1002 (옛 번호 KS C 5657)8.2. KS X 1005-1 (옛 번호 KS C 5700)8.3. 북한의 완성형 (KPS 9566)8.4. 중국의 완성형 (GB 12052)8.5. 7비트 2바이트 완성형
9. 여담10. 관련 문서

1. 개요

한글 인코딩 방식 중 하나로, 현재 한국산업표준 KS X 1001:2004(옛 번호 KS C 5601-1987)에 정의되어 있다. 인코딩은 EUC-KR(Code Page 51949)로 이루어진다. 정식 명칭은 정보 교환용 부호계 (한글 및 한자)이다.

글자 코드 세트에 쓸 문자를 현대 한글의 모든 글자(11,172자) 중에서 사용 빈도가 높은 글자만 추려내어, '가'부터 '힣'까지 죄다 배당한 후 문자를 기록하는 방식으로, 가령 '속'이라는 글자를 기록한다면 가, 각, 간, 갇, 갈, 갉, 갊…으로 쭉 찾아가다가 0xBCD3로 표현하는 방식이다. 한글의 모든 글자 중 마지막 글자는 '힣'이지만, 이러한 글자들의 사용빈도가 극히 낮으므로 힞부터는 완성형에 포함하지 않게 되어 완성형의 마지막 글자가 '힝'이 된 것이다.

완성형 한글 2,350자의 목록은 완성형/한글 목록/KS X 1001에, 특수 문자 목록은 완성형/특수 문자에, 한자 목록은 한자/KS X 1001에 있다.

2. 장점

외국어나 특수문자와 같이 이용하는 것을 미리 가정하고 만들었기 때문에 조합형에 비해 국제 표준과 충돌이 적다는 장점이 있다. 여기서 말하는 국제 표준이란 ISO/IEC 2022로 유니코드가 등장하기 이전에 여러 종류의 문자 집합을 함께 쓰기 위한 표준이었는데, 구조적으로 94개, 96개, 942 = 8836개 문자를 담을 수 있는 n바이트 문자 집합을 갈아 끼우는 식이었다. 이론적으로는 3바이트를 사용해 943 = 83만 0584개 문자를 표현하게 할 수 있으나, 실제로 3바이트를 사용하는 문자 집합은 없다. 2바이트를 사용해 문자 8836개를 표현할 수 있는 문자 집합만 있다. 참고로 유니코드 5.2 이래로 기존의 비표준 인코딩까지 모두 포함해 거의 확정되다시피 한 옛한글 낱자는 초성 125개, 중성 95개, 종성 137개이다. 125×95×(137+1) = 163만 8750으로 3바이트로도 모자란다. 본래 2바이트를 사용하면 1바이트(8비트)의 개수가 256개이니 2562 = 6만 5535개가 나오지만, 이 방식은 아스키 코드의 확장 영역을 n바이트로 확장해서 사용하는 것이기 때문에 실제로는 맨 첫 비트가 1로 시작되는 뒷부분 128개 영역을 둘 이상 붙여서 쓸 수밖에 없다. 앞부분을 썼다가는 아스키 코드와의 호환성이 없어지기 때문이다. 그래도 1282 = 1만 6384개지만 여기서 34개가 더 빠진다. 아스키 코드 중 34개는 제어 문자이고, 이게 글자 코드를 7비트만 인식하는 컴퓨터 환경과 만나면 역시 충돌이 일어난다. 실제로 저 국제 표준이 나올 당시에는 7비트 표준 아스키 코드만 지원하는 시스템이 아직 남아 있었다. 따라서 실제로 쓸 수 있는 영역은 1바이트당 94개밖에 남지 않는 상황이 된 것이다.

현대 한글은 당연히 8836개로는 부족하기 때문에 일찌감치 타협을 보고 그 자리에 한자 등을 왕창 ( 중복도 포함해서) 배당한 것이다. 조합형은 이런 식으로 다른 표준들과 상호 교환해서 쓰는 게 원천적으로 불가능하다. 또한 글자수를 한정시킴으로써 표준적인 정서법, 특히 외래어 표기법을 억지로라도 지키게 만드는 효과까지 가져온다. 완성형으로는 디스켙, 펲시를 적을 수 없으니 외래어 표기법을 지킬 수밖에 없게 된다.

3. 단점

미리 조합되어 있는 글자 외의 문자는 어떻게 해도 표시할 수 없다. 물론 사용되는 모든 글자가 포함된다면 문제가 없지만, 1987년에 최초로 만들어진 기본 완성형 코드의 한글 글자 수는 2350자가 전부였다. 현대에 사용되는 한글 1만 1172자에 비하면 크게 부족했다. 즉 이때의 완성형 코드로는 현대 한국어의 완전한 표기가 불가능했던 것이다.

조합형 완성형 논쟁에서 완성형의 가장 큰 단점으로 지목됐고, 이건 완성형 지지자들도 인정할 수밖에 없는 문제였다. 물론 저 2350자는 그 나름대로 빈도를 조사해서 선정한 것이기는 하지만, 현대 한글 글자 중 약 21%밖에 수록하지 못하고 있으니 아무래도 부족했다. 빈도가 적다고 아예 안 쓰이는 게 아니며 인터넷 유행어 같은 경우도 완성형으로 구성이 불가능한 글자가 자주 나오는 데다, 사적인 사례 외에도 문제가 생기기 충분했다. 간단한 예시로 한국어 발음에 대한 논문을 하나 쓴다고 생각해 보라. 그 중 한 예로 '있다'의 발음을 표현하기 위해 '읻따'라는 표기를 써야 하는데 '읻'이라는 글자가 없어서 곤란해진다.

한글 자체가 원래 초성 + 중성 + 종성의 조합으로 이루어지는 조합형 문자인데 이걸 전부 한 글자 한 글자 만든다는 것도 비효율적이라는 이유로 완성형이 무시당하는 데 한몫 단단히 했다. 또, 그런 식으로 코드를 배당하다 보니 글자를 완성하는 과정이 개무시됐다. 가장 대표적인 예시가 바로 " 쓩"이다. 분명 KS X 1001 코드 안에는 쓩이라는 글자가 있긴 있으나 "쓔"가 없어서 ㅆㅠㅇ이라고 쓰인다.[1] 그 외에도 두벌식 키보드로 한글을 타이핑하는 과정에서 받침 없는 첫 음절 다음 음절의 초성이 받침으로 들어가서 완성형을 벗어나는 글자가 일상적인 단어에서 수없이 등장한다.

3.1. 완성형으로 쓸 수 없는 예시들

완성형이 외래어 표기법을 포함한 한글 맞춤법을 강제하기 위한 목적이라는 주장도 있지만(실제로도 그런 효과가 있긴 하다), 막상 빈도 조사를 하면 완성형 2350자만으로는 표준어조차 다 적을 수 없다. 아래 예시에서 굵은 글씨는 완성형에 포함되지 않는 글자이다.

고유명사들도 사정은 마찬가지이다. 특히 냉전 시대가 끝나고 세계화 시대가 도래하여 외래어/ 외국어 사용 빈도가 높아지면서 문제가 되었다.

그리고 '겍', '훕', '똠', '똡', '똣', '뚭', '뚯', '띡', '씅' 등 완성형에 등재되어 있을 것 같아 보이는 글자들도 없다. 백괴사전의 https://uncyclopedia.kr/wiki/KS_X_1001 문서에 표준어인데도 표기할 수 없는 단어들의 예가 나와 있다. 반면에 '붤'[5], '싻'[6], '쏀'[7] 등 완성형에 등록되어 있지 않을 것 같은 글자가 완성형에 등록되어 있다. 또한 시기상으로 1987년에 만들어졌기 때문에, '겆'( 설거지 ← 설겆이), '돐'( 돌 ← 돐)[8], '뭏'(아무튼 ← 아뭏든)과 같이 1988년의 맞춤법 개정 이후로 표준어에서 탈락된 단어를 표기하기 위한 글자도 몇 개 포함하고 있다.

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

각 기업에 전산화가 시작되던 시점인 1990년 MBC에서 방영한 "똠방각하"라는 드라마는 완성형에 똠자가 없어서 프린터로 출력한 대본이나 편성표 등지에는 "돔방각하"로 표기를 해놓고 그대로 내보내거나 일단 "돔방각하"로 출력한 다음 볼펜 등을 사용해서 ㄷ을 ㄸ으로 고치는 등의 문제도 있었다. 당시 완성형의 단점으로 가장 많이 지목되던 부분이기도 했다.

파일:attachment/으으.jpg

2011년 네이트의 '오늘 운세'에서 마지막이 으?으?!로 끝나서 점술가가 점 보다가 급사했다며 유머짤로 퍼져나간 적이 있다. 글쓴이는 '으쌰으쌰!'라고 쓰고 싶었던 듯 한데, EUC-KR에 '쌰'가 없어서 저런 참사가 일어났다. 실은 당시에도 EUC-KR 자체는 구닥다리 인코딩으로서 웹페이지 제작시 엄연히 표준이 아니었지만, 대부분의 메이저 사이트들이 EUC-KR을 사용했다. 심지어 HTML 교육에 사용된 예제들에서도 기본틀로 제시하는 문서가 EUC-KR이었으니 별 생각 없는 웹 디자이너들이 굳이 찾아서 바꾸지도 않았던 듯하다. 이러한 모습은 2010년대까지도 계속됐다. 2020년대 시점에서도 이 문제는 네이버 뉴스 등에 존재하며, 가장 흔히 보이는 경우는 가운뎃점이 들어가는 경우이다. 한편 대통령의 발언이 깨져서 나오기도 했다. 원문은 위의 경우와 같은 으쌰으쌰이다.

긴급재난문자와 안전안내문자에도 같은 문제가 있다. 경상남도 창원시에서 코로나 확진자가 방문한 돈까스 프랜차이즈 매장 이름에 들어가는 쑝이라는 글자를 쓰지 못 해 쑈+ㅇ 으로 고쳐 안내하는 일이 있었다.[9] 부산광역시 수영구에서는 같은 프랜차이즈를 쏭(ㅆ+ㅗ+ㅇ)으로 고쳐서 안내했는데, 이 당시 지점명까지 잘못 안내하는 실수를 해서 논란이 된 적이 있었다. 확진자가 다녀간 매장으로 잘못 지목당하고 손님이 끊겨 폐업을 하게 된 점주가 청와대 국민청원 사이트에 글을 올렸는데, 이 소식을 전하는 뉴스에서도 브랜드 이름을 제대로 쓰지 못하고 '숑'으로 고쳐서 보도됐다.

어떤 사람이 배달앱으로 배달음식을 주문했는데, 요청사항에 '김빼주세요'라고 적는다는 것이 '김뺴(ㅃ+ㅒ)주세요'로 오타를 냈고 뺴라는 글자가 완성형에 없어서 영수증 출력기에서 '김?주세요'로 깨져 나오는 바람에 결국 김이 왔다는 웃지못할 사연을 SNS에 남긴 바 있다.

만일 0xA4D4의 구현방법이 널리 알려진다면 이런 일은 볼 수 없을지도 모른다. 다만 구현과 입력이 번거로워 사장된 규정이다.

파일:IMG_20210712_200329.jpg
위에있는 예시들을 한글 채움 문자를 포함해 완성형으로 저장하여 Gecko 기반 브라우저로 출력한 스크린샷[10][11]

4. 통합 완성형 (확장 완성형)

그 후, Windows 95가 발매되면서 이 OS에 탑재된 UHC, 즉 통합 완성형(95 베타에서는 '확장 완성형'이라 했음)이라는 코드가 다시 문제가 됐는데, 이 통합 완성형( CP949)이라는 코드는 원래 완성형에서 표시할 수 없는 2350자 외 글자들을 별도의 영역에 추가로 집어넣어서 만든 코드이다. 여기에 대해서 반발이 많자 Windows 95는 기본 코드는 그대로 완성형으로 가고 확장 완성형은 표시만 가능한 상태로 넣고 출시를 했다. 당시 Windows 95에서는 '쓩'과 같은 2350자 외 한글은 표현이 가능했지만 IME같은 수단을 쓰지 않는 이상 입력은 안 되는 현상이 있었다.[12]

이후 논란이 잠잠해지자 Windows 98에서 기본 코드로 채택해서 나오게 된다.

이 통합 완성형은 도스 및 Windows 95 이전 버전의 프로그램과 충돌하는 문제도 자주 있었다. 때문에 일부 사람들은 Windows 95를 사용하지 말자는 의견까지 내곤 했지만, 결과는 지금 보면 알 수 있듯이 MS의 승리였다. 그리고 2000년대 초중반 유니코드를 채택한 Windows XP로 넘어가면서 통합 완성형 사용빈도도 자연히 줄어들었다.

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

5. 유니코드

이후 나온 유니코드는 완성형과 조합형을 둘 다 가지고 있는 코드이다. 현대 한국어의 자모 조합으로 나타낼 수 있는 모든 완성형 한글 1만 1172자(겹받침과 이중모음을 모두 포함하여 초성 19자, 모음 21자, 종성 27자의 조합으로 종성이 없는 경우까지 고려하여 19 × 21 × 28 = 1만 1172)와 조합형으로 쓰는 한글 초·중·종성(겹자모, 옛한글 포함)을 모두 가지고 있다. 당연히 여기서는 통합 완성형의 문제가 모두 해결되어 있다. 하지만 유니코드에서 조합형의 형태로 한글을 구현하는 경우는 별로 없는데, 조합형으로 한글을 구현하면 초성, 중성, 종성이 각각 글자 하나로 취급되면서 완성된 글자 하나의 코드 용량이 완성형보다 두세 배로 늘어난다. 조합형 한글 자모 하나하나가 UTF-8 규격에 따르면 3바이트라서 완성형 한 글자 전체와 같은 용량이기 때문이다. 이 문제 때문에 완성형에 없는 옛한글을 표현하는 용도 및 macOS에서 한글 파일명을 저장하는 용도 이외에는 잘 쓰지 않는다. 파일명 정규화는 풀어쓰기로 한다는 macOS 특유의 규칙 때문이다. 자세한 사항은 유니코드 문서의 "유니코드 정규화" 단락을 보자.

과거 완성형에서 유니코드로 넘어가던 시절에는 이런저런 문제가 많이 발생했다. 특히 웹 문서에서 문제가 자주 생겼는데, 페이지 인코딩은 EUC-KR로 해 놓고는 정작 EUC-KR에 포함되지 않는 한글(즉 통합 완성형에 추가된 한글)을 넣어서 깨지기도 하고, EUC-KR 페이지에서 확장 한글을 저장하는 방식이 웹 브라우저마다 달라서 한 웹 브라우저에서 저장한 글을 다른 웹 브라우저에서 열어 보면 제대로 표시되지 않기도 했다. 예를 들어 인코딩이 EUC-KR일 때 ' 뷁'을 IE에서는 '&#48577;'로 저장하고 파이어폭스에서는 'ㅤㅂㅞㄺ'(ㅂㅞㄺ 앞의 공백처럼 보이는 문자(한글 채움 문자)에 대해서는 이 문서 참고)으로 저장했는데, IE는 한글 채움 문자 표현을 지원하지 않으므로 파이어폭스에서 저장한 '뷁'을 IE에서 보면 그냥 '　ㅂㅞㄺ'으로 풀려서 보였다. 엄밀히 말하면 EUC-KR은 확장 완성형이 아닌 완성형이고, 완성형에서는 2,350자 밖에 있는 한글을 표현할 때 한글 채움 문자를 이용하라고 했으므로 파이어폭스 쪽이 맞게 표현하는 것이다. 간혹 웹 페이지에서 뭐가 문제인지 한글 채움 문자를 날려 버려서 한 글자로 합쳐지지 못하게 되는 경우도 있다. 그 최대 피해자 중 하나가 오위키 시절의 리그베다 위키였다. 이때 이를 해결하기 위해 많은 유저들이 열심히 노가다를 했다(모니위키로 이전한 뒤에는 UTF-8로 인코딩이 바뀌었으므로 더 이상 이런 문제가 없다).

2010년대 이후 이런 문제는 사실상 사라졌는데, 웹 환경이 UTF-8로 대부분 바뀐 데다 웹 브라우저의 한글 지원도 상당히 좋아졌기 때문이다. 거기다 OS도 유니코드를 기본으로 지원하고, 특히 윈도우는 Windows XP로 넘어오면서 아예 유니코드를 기본 문자 인코딩으로 채택했기 때문에 이런 문제는 거의 사라진 상태이다. 고전 프로그램을 돌린다거나 공개적인 장소에서는 돌릴 수 없는 에로게[13] 등을 즐긴다든지 하는 문제가 아니라면 문자 인코딩 관련 문제는 보기 힘든 환경이 됐다.

유니코드에 포함된 한글 음절은 현대 한글에서 쓰일 수 있는 한글 조합자를 다 넣은 것이므로 앞서 언급된 완성형의 단점인 글자가 없어서 입력이 안 되는 문제는 존재하지 않는다. 그 대신 유니코드의 배당 공간을 너무 많이 차지한다는 문제가 생긴다. 게다가 유일하게 기본 영역에서 한 국가의 한 문자 체계의 문자가 다수의 방식으로 중복해서 배당된 사례이다. 한편 유니코드에서 가장 많이 공간을 잡아먹는 문자는 한자(일본의 신자체, 중국의 간체자, 베트남의 쯔놈 포함)이다. 그 외에도 쐐기 문자나 이모지같은 표어 문자나 표의 문자도 많은 슬롯을 차지한다. 하지만 상당수의 표어 문자나 표의 문자, 그리고 특수 한자, 이모지 등과 같은 그림문자들은 보조 영역인 SMP 영역으로 들어가 있고, 기본 영역인 BMP 영역에서 배당 슬롯을 저렇게 많이 차지하는 문자체계는 단연코 한자, 그 다음으로 표준 한자와 완성형 한글뿐이다. 표준 한자야 여러 동아시아 국가에서 사용하는 데다 한글에 비해 글자 만드는 방식이 체계적이지 않아 도저히 어떻게 할 대안이 없어서, 그리고 표준 기호(=, /, + 등) 같은 경우는 전 세계에서 사용하는 것이라 저렇게 할당했다고 참작할 수 있지만, 한글은 엄연한 알파벳( 음소 문자)인데도 24자만으로 표기가 가능하다는 경제성[14][15]을 살리지 못하고 있는 것이다.

파일:external/upload.wikimedia.org/750px-Roadmap_to_Unicode_BMP.svg.png
11번 한 칸이 조합형 한글이 배당된 칸이다. 그리고 AC부터 D7까지의 칸이 완성형 한글이 배당된 칸이다. 7,000만 명만 쓰는 문자 체계가 전 세계 표준 문자 배당 시스템의 기본 영역의 슬롯을 1/6 이상 차지하고 있다.

6. 현재의 완성형

저 2,350자 기본 완성형은 아직도 메모리 용량에 목숨 걸어야 하는 일부 분야에서 사용되고 있는데[16], 대표적인 분야가 피처폰과 중국산 스마트밴드류이다. 그렇기 때문에 일부 제조사의 핸드폰에서는 문자 메시지에서 '뷁'을 사용할 수 없다. 뿐만 아니라 앞서 언급한 '쓩' 같은 글자는 여전히 홍길동 신세를 탈출하지 못하고 있으며 심지어는 '뛔'도 마찬가지이다. 분명히 '뛔'는 있다. 하지만 핸드폰에서 뛔를 쓰려면 ㄷㄷㅜㅓㅣ의 순서로 써야 하기 때문에 중간에 '뚸'를 거쳐야 하지만 그 글자가 2,350자 안에 없다. 천지인 자판(ㆍ, ㅡ, ㅣ)을 채택하는 핸드폰의 경우 ㄷ → ㅌ → ㄸ → 뜨 → 뚜 → 뜌 → 뚸 → 뛔 순으로 써야 되는데 '뚸' 바로 앞의 '뜌'도 없다. 반면 흖은 있다. 흖은 흔하다의 준말이다. 그러나 이마저도 폰의 용량이 커지면서 서서히 사라지다가[17], 스마트폰 시대가 오면서 유니코드로 대체됐다. 스마트폰에서 가장 많이 쓰이는 OS인 안드로이드나 iOS는 글로벌 환경을 지원하기 때문에 유니코드를 쓴다.

롬파일 혹은 1바이트짜리 문자 인코딩을 사용하는 게임의 한글패치를 제작할 때도, 프로그래밍에 정통해서 롬을 확장하거나 문자 인코딩을 2바이트로 늘리거나 다른 방법을 찾아 우회하지 않는 이상 들어갈 수 있는 글자 수가 정해져 있기 때문에, 완성형을 쓰는 경우가 있다. 대신 완성형도 2,350자+24자(한글 자모)+알파벳+숫자+일부 특수문자를 포함하여 대략 2,400여 자를 입력해야 하기 때문에, 롬파일의 확장 혹은 이곳 저곳의 데이터 여백에 포인터를 배치하는 것으로 입력글자수를 늘리거나, 아니면 아예 처음부터 수천자를 입력시켜놓은 중국어 롬파일을 구해서 사용하는 케이스가 많다. 이것조차 안되면 직결식 폰트를 사용해서 1바이트 환경에서도 사용할 수 있다.

책을 컴퓨터로 편집하는 데 쓰는 프로그램의 대다수가 EUC-KR 방식만을 지원하기 때문에 일본어 이름을 지니고 있는 몇몇 인물들이 생고생을 하기도 한다. 특히 일본 대중문화 개방이 이루어지면서 이런 문제가 많아졌는데, 이는 완성형이 제정됐을 때에는 아직 개방이 이루어지기 이전이었기 때문이다. 대표적인 예로 쿈과 슌을 들 수 있다. 실제로 일본 영화 러브레터가 국내에 수입될 당시, 당시에는 이 영화를 제작한 이와이 슌지(岩井 俊二, いわい しゅんじ) 감독의 슌 자를 제대로 표기할 수 없어 이와이 슈운지로 표기하는 경우가 잦았다. 또한 미즈노 슌페이는 미즈노 순페이로 개명당했다. 이외에 나카무라 순스케, 오구리 순도 마찬가지로 피해자가 됐으며, 창작물의 경우 마츠오카 슈운과 호조인 인슈운이 한국어 번역의 피해자가 됐다. 다만 이것은 인쇄할 때 쓰는 소프트웨어가 QuarkXPress[18] 구버전이어서 그렇고[19], 최근에는 인디자인으로 많이 갈아타고 있어 조만간 해결될 가능성이 있다. 비단 이건 일본어뿐 아니라 상술한 것처럼 다른 언어들도 해당되는 문제이다.

방송업계에서 쓰는 시스템도 완성형이라 특정한 단어들을 표현하는데 애를 먹기도 한다. 대표적인 예로 신화의 노래 '으쌰으쌰'는 '쌰'를 표현할 수 없어 '쌰'만 다른 프로그램을 이용해 다른 글꼴을 사용하거나, 일단 '으싸으싸'라고 쓴 다음 '싸'에 덧칠을 하는 식으로 표현했다. 이 시기 노래방 책자나 불법 복제 테이프 등에서도 ㅆ 따로 ㅑ 따로 해서 '으ㅆㅑ으ㅆㅑ'라고 표기되어 있기도 했다. 심지어 1990년에 MBC에서 방영한 드라마 똠방각하는 '똠' 자가 없어서 대본이나 편성표에는 '돔방각하'로 인쇄하는 경우도 있었다.[20] 후에 같은 MBC에서 방송한 맨도롱 또똣도 마찬가지이다. 여기서 '맨도롱 또똣'은 제주도 방언으로 미지근 뜨뜻, 다시 말해 음식이 먹기 좋을만큼 따뜻하다는 뜻이다. '똣' 자가 완성형에 없어서 일부 IPTV 등에서는 맨도롱 또돗으로 표기했다. 2016년에 라붐이 발표한 노래 '푱푱'도 완성형 문자에 없는 글자다 보니 '퐁퐁' 으로 표기되기도 했다. 이건 2020년대인 현재도 여전해서, 2020년에 발매된 오마이걸의 살짝 설렜어 (Nonstop)란 노래도 '렜'자가 완성형에 없어 완성형을 사용하는 금영엔터테인먼트 노래방 시스템과 olleh tv에서는 "렛"으로 대체하여 표기하고 있다. 그나마 이쪽은 '렜'자가 조금 어색하게 표현된 경우는 있었지만 방송 자막은 제대로 표시됐다.

이는 대한민국의 행정 전산망도 예외가 아니다. 대한민국의 행정 전산망 역시 아직도 완성형을 쓰고 있기 때문에 일부 이름을 표기하지 못한다. 수기로 출생신고를 하던 시절에는 이런 상황을 예상할 수 없었을 것이니, 처음부터 이를 피해서 이름을 짓는 것도 불가능했다. 실제로 설믜(눈썰미의 고어)라는 사람의 경험담을 보면 전산 시스템 때문에 엄청 고생하는 것을 알 수 있다. EUC-KR을 특정 '프로그램'으로 알고 있는 것으로 보아, 문자 인코딩에 관련한 깊은 지식이 있는 블로거는 아닌 듯하다. 물론 이걸 알고 모르고를 떠나, '믜'가 입력이 안 되는 완성형 체제 자체는 까여야 마땅하다. 다만, 옛 한국어의 자음 + ㅢ는 늬, 희 등 일부를 제외하고는 모두 자음 + ㅣ로 변했기 때문에(예: 기차 ← 긔챠, 마디 ← 마듸, 거미 ← 거믜, 나비 ← 나븨, 키(신장) ← 킈, 티끌 ← 틧글, 피우다 ← 픠우다 등), 현대 한국어 정서법에 따르면 '설미'가 돼야 하긴 하다. 물론 인명이니 본인이 특이한 표기를 쓰겠다고 하면 할 말 없다. 워낙 심각한 문제이다 보니 국립한글박물관 기획전에서도 비슷한 사연을 가진 분의 졸업증명서[21]가 전시될 정도였고, 또 다른 '설믜'라는 이름을 가진 사람 역시 일상 생활에 불편을 겪은 나머지 청와대 국민청원에다가 자신의 사연을 올렸다.[22][23]

또한 언리얼 엔진과 같은 외국산 엔진의 경우, 문자를 비트맵으로 불러들여 사용하기 때문에 알파벳이나 가나처럼 문자의 수가 정해져 있다면 문제가 없겠지만 한글처럼 조합하여 표시하는 경우 문자를 표시하기 위한 비트맵 크기가 어마어마해진다. 알파벳 계열은 많아야 100개 정도, 한글은 대략 11,000글자이다. 사실 이건 PC에서 문자 처리를 글꼴을 이용해서 할 경우 비트맵으로 불러들여 처리하는 것보다 성능이 떨어지기에 도입된 방식이다. 이 때문에 2000년 이전에 개발된 게임에서 내부 글자를 글꼴로 처리하는 경우는 별로 없다. 이때의 국산 게임도 완성형 글꼴을 비트맵 파일로 만들어 표현하는 경우가 많았다.

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

포토샵 등에서 두벌식 타이핑 중에 일시적으로 앞음절의 초성이 될 자음이 종성에 일시적으로 붙는 경우[24], 그 부분에서부터 글꼴을 강제로 굴림체로 바뀌게 만드는 원인이기도 하다. 이쁘장하다 싶은 글꼴은 제작 시간과 글꼴 파일 용량을 절약하는 차원에서 '뛗', '쁎' 등 거의 쓰일 일이 없는 글자와 '똣', '훕' 등 사용빈도가 낮은 글자는 아예 빼 버리고 한글 영역에서 완성형만 집어넣기 때문에, 여기에 없는 한글을 적게 되면 포토샵 쪽에서 해당 글자가 있는 글꼴로 바꿔 버리기 때문이다. 몇몇 소프트웨어 전용 글꼴을 사용하는 한/글에서도 완성형 전용 글꼴의 경우 2,350자 이외 글자에 한해서 조합형 글꼴로 대체하고 있다. 설정에서 안 바뀌게 만들 수는 있지만(포토샵에서는 설정에서 "누락된 글리프 보호"를 체크 해제), 글자 자체가 없는 것이 고질적인 문제이다.

타이포그래피 분야, 정확히는 한글 글꼴 제작 업계에서도 완성형이 꾸준히 사용되는데, 이유는 글꼴의 제작에 시간과 예산이 한정된 경우가 있기 때문이다. 한글 전체를 글꼴로 제작하려면 11,172개 글자를 디자인해야 하는데, 단순히 산술적으로 계산해보자면 완성형 2,350자만 디자인하면 반의 반 정도만 시간과 예산을 들여도 만들 수 있다. 대표적으로 나눔스퀘어, 배달의민족 글꼴이 이런 이유로 2,350자만 지원하고 있다. 특이한 케이스는 11,172자를 전부 만든 글꼴을 놓고 2,350자만 들어간 미니 글꼴로 축소시키는 경우인데, 웹 폰트의 사용이 늘어나면서 서버 부하를 줄이기 위해 이렇게 일부러 웹 폰트를 개조하는 경우도 늘어나고 있다. 한편 최근에는 한글 폰트를 제작할 때 11172과 2350 사이의 숫자에서 타협하는 경우도 있는데, Adobe-KR-9 보충 0의 2780자를 지원하여 적당한 중간점을 갖는 글꼴들도 많이 제작되는 추세이다.[25]

7. 완성형에서의 한자

한자의 경우, 독음이 여러 개인 일부 한자를 그 독음 수만큼 중복 배당하는 정신 나간 짓을 저질렀다. 이에 대한 자세한 정보와 중복 한자의 목록은 완성형/중복 한자 문서에 있다.

일본어에서 쓰이는 신자체를 지원하지 않아 기기묘묘한 표기법들을 양산했고(일명 고자 일본어), 중국어에서 쓰이는 간체자 등의 상용자를 지원하지 않아서 중국 노래를 다루는 사이트 등지에서 해당 글자를 병음이나 파자해서 가사를 적곤 했다. 예) 你好 → ni好, 什么/什麼 → 什me 등

8. 기타 완성형 코드

8.1. KS X 1002 (옛 번호 KS C 5657)

파일:상세 내용 아이콘.svg   자세한 내용은 KS X 1002 문서
를
의 번 문단을
의 부분을
참고하십시오.
KS X 1001을 보충하기 위해 1991년에 만든 문자 집합이었으나 완전히 묻혔다. 정말 아무도 안 쓴다. 현대 한글 1930자, 옛한글 1675자, 한자 2856자 등을 포함하고 있다.[26]

이 표준은 단지 1990년대 초반 당시에 유니코드와 ISO/IEC 10646에 한글(과 한자)을 더 집어넣기 위해 급조한 표준이라는 말이 있다. 물론 이 목적도 유니코드 2.0에 모든 현대 한글 11,172자가 완벽히 가나다순으로 들어가면서 사실상 의미가 없어졌다.

다만 저 중에서 한자 2856자만은 살아남았다. 유니코드의 첫 통합 한자 set를 제정할 때 KS X 1002가 KS X 1001과 함께 한국 쪽 source의 하나로 들어갔고, Microsoft Windows의 기본 한국어 글꼴과 기본 한국어 IME는 저 2856자를 지원한다.

KS X 1002의 현대 한글 목록은 완성형/한글 목록/KS X 1002에 있으며, 한자 목록은 한자/KS X 1002에 있다.

8.2. KS X 1005-1 (옛 번호 KS C 5700)

전술한 바와 같이 컴퓨터 한글 생활의 종결자로 보아도 무방한 유니코드 2.0이 제정된 후 이를 기반으로 1995년 12월 7일 KS C 5700이 제정됐다. (이후 KS X 1005-1로 명칭 변경) 다만 이미 글로벌 인코딩 환경이 국제표준인 ISO/IEC 10646(즉 유니코드)으로 전환되어버렸다고 판단해서인지 그로부터 약 10년이 지나 2006년 8월 31일 이 문자집합은 폐지됐다.[27]

8.3. 북한의 완성형 (KPS 9566)

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

국규 9566 표

그리고 2014년에는 '김, 일, 성', '김, 정, 일' 바로 뒤에 ' 김, 정, 은' 이 추가된 것이 확인됐다.[28] 링크한 스크린샷은 붉은별 3.0 서버용의 화면을 찍은 것이며, 출처는 이 글이다. 해당 글자는 유니코드에 없는 관계로 유니코드 변환 시 PUA로 치환된다.

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

북한의 완성형 한글 2679자의 목록은 완성형/한글 목록/KPS 9566에 있으며, 한자 목록은 한자/KPS 9566에 있다.

8.4. 중국의 완성형 (GB 12052)

한국과 북한의 완성형에 비해서는 관심이 적은지라 상당히 덜 알려져 있다. 다만 1990년대에 한글 코드를 연구하던 사람들은 중국의 완성형에 대해서 알고 있다. 실제로 1990년대 당시의 한글 코드 연구 자료들을 보면 중국의 완성형이 간혹 언급된다.

중국은 자국의 소수 민족 언어·문자들을 위한 국가 표준 문자 집합을 여러 개 만들었는데, 그중에는 GB 12052라는 한글 문자 집합도 있다. 현대 한글이 3천 자가 넘고, 한자는 94자(그것도 이두·구결자)밖에 없으며[29], 놀랍게도 옛한글 완성자가 1,700자 정도 포함돼 있다. 옛한글 완성자를 국가 표준 문자 집합에 처음 넣은 건 한국이 아니라 중국인 셈이다. GB 12052는 1989년에 나왔고, KS X 1002(당시 KS C 5657)는 1991년에 나왔다.

다만 한국의 KS X 1001과 북한의 KPS 9566이 문자 인코딩(EUC-KR, EUC-KP)에 포함되어 실제 바이트의 연속으로 표현된 것과는 달리, 중국의 GB 12052는 실제로 문자 인코딩에 포함되어 사용된 적은 없는 것으로 보인다.

현대 한글의 순서는 북한의 가나다순을 따르고 있다. 아무래도 중국 조선어가 북한 문화어의 영향을 많이 받아서 그런 듯하다.

유니코드 매핑 테이블은 존재하지 않았으나, 2014년에 어떤 사람이 매핑 테이블을 만들었다. #, 코드 표

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

최상위 비트를 사용할 수 없는 환경에서 사용하기 위해 만들어졌다. aB와 같이 로마자 소문자 뒤에 대문자가 오는 경우 또는 }a와 같이 기호 뒤에 로마자가 오는 경우 등 영어에서 일반적으로 쓰이지 않는 조합에 자주 쓰이는 한글을 넣은 방식이다. 이 방식을 사용하는 한글 카드가 저렴했기 때문에 많이 이용됐다. 당시 청계천 근처에 있는 세운상가에서 가내수공업 형태로 제조를 했기에 "청계천 한글 카드"라는 이명으로 많이 불렸다. 그러나 표현할 수 있는 글자 수가 1300여 자로 제한되고 진짜로 소문자 + 대문자 조합을 의도한 경우가 한글로 표시되는 경우도 있어서( dBASE가 '늦ASE'로 출력됐다) 쓰이지 않게 됐다. 당장 "iPhone"[30]부터 표기가 곤란하니...

9. 여담

완성형 2350자 중 가장 획수가 많은 글자는 빪으로 16획이다.

10. 관련 문서

[1] Windows 3.1에서는 모종의 버그로 입력이 되긴 한다. [2] # [3] 정확히는 웨일스. [4] 실제로 해당 악곡이 최초로 수록되어 나온 PS41에서는 '큥'이 ‰로 깨져 표출되었다. 현재는 '큐웅'으로 수정. [5] 일부 지역에서 ' 벌'의 방언으로 쓴 적이 있다. [6] 일부 지역에서 '삯'의 방언으로 쓴 적이 있다. [7] 표준어는커녕 방언조차 사용 사례가 없다. 오히려 이 글자를 적기 위해 거치는 단계인 '쎠'와 '쎼'는 완성형에 없다. 단, Windows 3.1에서는 모종의 버그로 '쎙'을 입력하면 이 글자가 입력됐다. [8] 문화어에서는 현재도 표준어이다. [9] 문자 내용 [10] 파일:lBochs PC Emulator20210712195325.png
해당 html 파일을 메모장으로 불러온 스크린샷으로, 용량은 태그까지 포함해서 약 2KB가 된다. [11] 표준 완성형만 지원하는 Windows 95에서 Retrozilla로 html파일을 불러온 것이다. 참고로 Retrozilla를 포함한 Gecko기반 브라우저들은 EUC-KR 또는 UHC에서만 글자가 합쳐진다. [12] 호환성 문제로 16비트 앱에선 입력이 안된다. [13] 이런 게임은 아직도 유니코드가 아닌 일본어 로캘을 사용하는 경우가 많아서 AppLocale이 아직도 필수에 가깝다. 수요층이 일본 한정, 혹은 해외 유저들이 사실상 복제 사용자들이라는 가정에서 나오는 판단인 듯하다. [14] 사실 24자라는 자모 수는 ㄱ과 ㄱ을 나란히 쓴 ㄲ이나, ㅏ와 ㅣ를 나란히 쓴 ㅐ, ㅗ와 ㅏ를 나란히 쓴 ㅘ 등을 별개의 자모로 세지 않은 수이다. 그러나 유니코드의 'Hangul Jamo(한글 자모)' 영역에는 이러한 ㄲ, ㅐ, ㅘ 등이 별개로 처리되어 있으며, 거기에 초성자와 종성자도 구별되어 있으므로 24자보다는 좀 더 많은 자모가 실려 있다. [15] 유니코드의 'Hangul Jamo(한글 자모)' 영역에 실린 현대 한글 자모는 다음과 같다.
초성자 19자(U+1100~U+1112): ᄀ, ᄁ, ᄂ, ᄃ, ᄄ, ᄅ, ᄆ, ᄇ, ᄈ, ᄉ, ᄊ, ᄋ, ᄌ, ᄍ, ᄎ, ᄏ, ᄐ, ᄑ, ᄒ
중성자 21자(U+1161~U+1175): ᅡ, ᅢ, ᅣ, ᅤ, ᅥ, ᅦ, ᅧ, ᅨ, ᅩ, ᅪ, ᅫ, ᅬ, ᅭ, ᅮ, ᅯ, ᅰ, ᅱ, ᅲ, ᅳ, ᅴ, ᅵ
종성자 27자(U+11A8~U+11C2): ᆨ, ᆩ, ᆪ, ᆫ, ᆬ, ᆭ, ᆮ, ᆯ, ᆰ, ᆱ, ᆲ, ᆳ, ᆴ, ᆵ, ᆶ, ᆷ, ᆸ, ᆹ, ᆺ, ᆻ, ᆼ, ᆽ, ᆾ, ᆿ, ᇀ, ᇁ, ᇂ
여기에 옛한글 자모들까지 실려 있으므로 유니코드의 'Hangul Jamo(한글 자모)'는 24자보다야 많다. 물론 현대 한글 음절 11,172자에 비할 바는 아니다. [16] 옛 도스 환경의 조합형 한글 글꼴은 오히려 2,350자 완성형 글꼴보다 용량이 적다. 초성 몇 벌, 중성 몇 벌, 종성 몇 벌(보통 초성 8벌, 중성 4벌, 종성 4벌이었다)을 디자인해 놓고 일정한 규칙에 따라 그 자형들을 조합해서(정확히는 겹쳐서, 일종의 레이어로 생각하면 된다) 1만 1172자를 출력했기 때문이다(당시에는 글꼴을 이렇게 만들고 초성, 중성, 종성을 겹쳐서 출력했다). 필요한 자형 수는 많아야 몇백 개뿐이다. 반면 완성형 글꼴은 2,350자를 하나하나 디자인해야 하기에 옛 도스 환경의 조합형 한글 글꼴보다 용량이 클 수밖에 없다. 코딩할 때도 완성형은 한글 코드와 자소가 전혀 관계 없기 때문에 일일이 코드페이지에서 찾아 줘야하지만 조합형은 자소의 코드를 합치기만 하면 글자가 완성된다. [17] 예를 들어 연아의 햅틱의 경우 위에 나타난 쓩, 뷁, 뛔, 쿈 등을 모두 표기할 수 있다. [18] 참고로 이 프로그램의 약자 중 하나가 쿽인데, 이 글자 역시 완성형에 없어서 '쿼크'로도 많이 표기했다. [19] 왜 이렇게 됐나면, 당시 구형 매킨토시에서 돌아가는 QuarkXPress는 한국 실정에 현지화된 3.3k 버전을 쓰고 있었는데, 제작사가 라이센스비를 올리자 인쇄 업계 측에서 담합해 신버전을 쓰지 않기로 하고 기존 버전을 고수해서 그렇다고 한다. [20] # [21] 이쪽은 '믜'를 '므ㅣ'로 표기했다. [22] # [23] # [24] 종성 우선, 또는 이른바 도깨비불 현상 [25] 다만 2,780자로도 쓸 수 없는 글자는 많아서 근본적인 문제 해결은 안되기는 한다. [26] 참고 [27] # [28] # [29] 당연하다면 당연하다. 중국 내 소수민족 언어·문자를 위한 집합을 만드는 상황에서, 한자는 (그것이 간체든 번체든) 한족의 문자라고 여기면 그뿐이므로 조선족 문자 집합에 등장할 이유가 없다. 옛 조선어 표기를 위해 쓰이는, 이를테면 乫(갈), 亽(라), 丷(하)과 같이 이두나 구결에서 쓰이는 글자(한자의 변형)만 실으면 충분하다. [30] 청계천 7비트 완성형 기준 렬hone으로 출력된다.

분류