조합형

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

1. 개요2. 초창기( MS-DOS 시대까지)3. 확장 완성형( Windows 95) 이후4. 유니코드( Windows NT) 이후

4.1. 자모 조합(첫가끝)

1. 개요

조합형( 組合型)은 한글 인코딩 방식 중 하나이다. 한글의 제자원리( 制字原理)에 부합하여 표현이 자유롭다는 장점이 있어 한때 많이 쓰였고 또 많은 사용자의 지지를 받았던 방식이지만 지금은 유니코드의 등장으로 필요성이 크게 줄어 옛한글의 표기 이외에는 거의 쓰이지 않는다.

코드에는 자모만을 배당해 두고, 자모의 조합으로 한글을 표현한다. 글자 하나를 만들 때 초성+중성+종성을 조합해서 만드는 것. 가령 '만'이라는 글자를 입력하면 ㅁ+ㅏ+ㄴ 해서 '만'이 되는 식이다. 이 때 자모 단위로 특정한 값을 가지고 이러한 값들의 나열로부터 글자를 조합하기 때문에 조합형이라고 한다. 특성상 결합 문자에 속한다.

완성형 글자로는 표현할 수 없는, 160만개가 넘는 한글 자모로 결합한 모든 글자를 표현할 수 있다는 장점을 지닌다. 단점은 사용 빈도와 용량 효율성. 조합형 한글자보다 완성형 한글자가 용량을 적게 차지하는건 둘째치고, 현대 한글은 1만자 정도에서 해결이 되며[1], 의성어 등을 빼면 실제 3천여 자 정도, 고문헌에 사용된 글자 수는 5천여 자 정도밖에 안된다. 자세한 것은 유니코드 항목과 본 항목에서 후술.

표준이 아닌 것으로 많은 사람이 알고 있지만, 엄연한 표준 코드이다. KS X 1001의 부속서 3(구 KS C 5601-1992)으로 수록되어 있다.

당연히 완성형과 조합형은 체계가 달라서 조합형으로 쓰여진 한글을 완성형으로 읽히면 글자가 깨지듯 그 반대도 마찬가지인데 조합형→완성형의 경우 각종 기호까지 섞여서 어떻게든 읽을수 있는 단어가 성립되지 않는 경우가 많았지만 완성형→조합형의 경우 뭔가그럴싸한 한글로 나오긴한데 실제로 발음하긴 참 아스트랄한게 많아서 유머소재나 PC통신을 하던 사람들이 아무런 뜻없이 한글 ID로 쓰기도 했다. 이를테면 나우누리 전설의 ID 꿰쁑쉐떫과 이와 비슷한 아이디인 짧꿇칡뚫, 퀭촨휄뉨, 떫꿇칡뚫, 갉붊뚫핥 ( #)[2]이라던가....

KS 조합형 외에도 제조사별 군소 조합형과 완성형이 난립했기 때문에, 한도컴퓨터 도깨비 SW #에 포함된 카멜레온 #이라는 프로그램에서 변환을 제공하기도 했다.

2. 초창기( MS-DOS 시대까지)

완성형으로는 글자를 표현하는 데 한계가 있기 때문에, 이를 타개하고자 여러 종류의 조합형 방식이 개발 되었다. 각 종류에 따라 장점과 단점이 존재 한다.

n바이트 조합형
한글 낱자 하나 당 1바이트씩 할당하는 방식. 한글 창제원리를 완전히 반영한다면 한 글자에 들어가는 바이트 수가 들쭉날쭉이 된다. 가령 '무' 는 ㅁ + ㅜ로 최소 2바이트가 들어 가지만 '쀍'은 ㅃ + ㅜ + ㅔ + ㄹ + ㄱ으로 최대 5바이트까지 늘어난다. 또한 문장 앞뒤에 시작(SI)과 끝(SO)을 알리는 별도 코드가 들어 갔다. 이래저래 용량을 많이 잡아먹는 코드라서 널리 퍼지지는 못했다. 개인용 컴퓨터 도입 이전 대형 컴퓨터 시절부터 한글 처리에 쓰였던 방식이고 8비트 시절에 애플 II나 MSX 등에 채용되었다. 이것의 흔적이 바로 반각 한글 낱자이다.
3바이트 조합형
n바이트 조합형의 단점인 1글자의 길이가 일정하지 않다는 점과 최대 5바이트까지 메모리를 차지한다는 점을 개선하기 위해 1980년대 초에 나 온 방식. 초성 + 중성 + 종성 문자를 배당하고(받침이 없는 글자는 채움 글자를 따로 쓴다) 조합 하는 3바이트 조합형을 고안 하기도 했지만, 글자당 2바이트를 소비하는 완성형에 비해 효율이 낮다. 애플 II의 '중앙한글' 같은 워드 프로세서에 채용되기도 했다.
2바이트 조합형
보통 조합형은 2바이트 조합형을 의미 한다.[3] 2바이트, 즉 16비트에서 앞 1비트는 한글임을 알리고, 나머지 15비트를 5비트씩 잘라 초성, 중성, 종성에 배당했다. 그런데 이 규격을 각 회사마다 독자적으로 정해버려서[4] 서로 호환이 되지 않았고, 2번째 바이트의 첫 비트가 0이면 다른 ASCII 코드와 충돌할 수 있다. 나중에 이것이 상용 조합형(삼보 조합형, KSSM)으로 정리 되고, 1992년에 표준으로 지정 된다(KS X 1001의 부속서 3으로 수록 됨). 지금이야 윈도우라는 통합 플랫폼이 있어서 인코딩의 문제가 단순히 다른 설정으로 다시 읽어 들이기만 하면 되는 정도지만, 당시에는 한글을 표현하기 위해 특정 인코딩 전용 SW, 특정 인코딩 표현 하는 DOS의 버전, 특정 인코딩을 DOS에서 표시 하기 위한 램 상주 유틸리티, 그리고 전용 하드웨어 카드까지 동원 하던 시절이라 자기가 사용 하는 컴퓨터에서 구해 놓은 자료가 깨지면 당장 답이 없던 시대였다. 그래서 당시에는 동영상 코덱 변환 하듯이 문서자료의 인코딩을 변환 하는 프로그램들이 여럿 있었다.

DOS 시절에는 그래픽을 지원하는 프로그램 개발자들에게 있어 완성형보다 선호되었는데, 글꼴을 만들기가 용이하고 프로그램 사용에 있어서 훨씬 유연했기 때문이다. 키보드 입력값을 받아 합치기만 하면 글자가 완성 되는 조합형이라 메모리 부족에서도 자유로웠고, 속도 차이도 많이 났다. 여러 라이브러리들에서도 기본적인 지원은 조합형 방식부터 시작 했고, 몇 종류의 자모만 도트로 찍으면 됐기 때문에 지금은 그 무게 자체가 다르게 다가오는 '폰트를 자작한 프로그램' 들이 많았다. 자체 한글을 내장한 앱은 조합형이라 할 정도. 이 시기에 나왔던 유명한 폰트가 둥근모꼴과 굵은체로, 폰트 파일을 뜯어 보면 초중종성을 조합하는 방법으로 글자를 표현하는 것을 알 수 있다.

조합형 완성형 논쟁 때, 조합형을 미는 사람들이 항상 주장 했던 것이 현대 한글을 모두 표현할 수 있다는 것인데, 이 때 나온 유명한 문장이 바로 "찦차를 타고 온 펲시맨과 쑛다리 똠방각하"다. 현대 한국인은 이 문장을 무리 없이 읽지만, 완성형 시스템에서는 표시 할 수도 읽을 수도 없으며, 실제로 타이핑하면 "찌ㅍ차를 타고 온 페ㅍ시맨과 쑈ㅅ다리 또ㅁ방각하"라고 나 온다. 또 이 문장을 조합형으로 쓴 문서를 예외 처리 없이 강제로 유니코드로 변환 하면 "뾼차를 타고 온 최시맨과 뉵다리 馱방각하"처럼 바뀌어 버린다. # 이 때문에 펲시맨, 펲시콜라의 경우 뒷날 한글 표기를 지금의 '펩시맨', '펩시콜라'로 바꾸었으며, 똠방각하는 '돔방각하'와 같이 적는 경우가 많았다.

ASSA노래방은 VMP-6000까지 이 조합형으로 한글 처리를 하여, 똠방각하가 제대로 나왔다고 한다. 다만 VMP시리즈들 중 유일하게 VMP-5500은 완성형이 도입된 것으로 추정된다.

3. 확장 완성형( Windows 95) 이후

그러나 이후 마이크로소프트에서 Windows 95에 확장 완성형을 도입하면서 조합형은 완전히 묻혀버리게 되었다. 조합형이 주장하던 한글 완전 구현을 마소에서 뒷부분에 나머지 문자를 죄다 배당하는 방식으로 땜빵한 덕분. 당시 MS에서도 이전 버전에서 정부표준에 따라 도입했던 완성형의 문제를 이전부터 인식하고 있었다고 발표하면서 표준 완성형의 한계를 넘기 위해 글자를 새로 정리하려 했으나, 역시 기존 인코딩과의 호환을 넘을 수 없어 추가되는 문자(KSC5601-1992 조합형에서 남는 문자들)를 기존 완성형(KSC5601-1987)의 뒤에 추가했다. 이 선택의 문제점은 종전 완성형이 가나다 정렬되어 있고, 새로 추가된 확장 영역은 그 뒤에 다시 정렬되어 있기 때문에 가나다 순서로는 찾을 수 없고, 단순히 코드만을 가지고는 한글 가나다 정렬을 할 수 없다는 점이다. 물론 요즘은 코드 순으로 문자를 정렬하는 시스템은 존재하지 않는다.

조합형이 묻혀버리게 된 이유 중 또 다른 하나는 외국어. 한글의 최소 단위는 자모인 게 맞지만, 이게 발음을 가지려면 순서대로 자 + 모 혹은 자 + 모 + 받침 자[5] 순서로 문자를 정확히 조합해야 한다. 이렇게 조합된 글자 중 11,172자만 현대 한국어를 표현하는 데 쓰이며, 잘못 조합된 문자는 말이 안 되거나 옛한글이다. 조합형의 장점을 극대화하려면 모든 초성/중성/종성의 가짓수를 전부 가지고 정확히 3차원 배열의 순서대로 전체를 다 배열해야 하는데(이래야 조합형의 최대 장점인 조합 및 분해, 정렬의 규칙이 정립된다), 이 경우 엄청나게 많은 문자 영역이 발음 불가능하거나 옛한글과의 조합이 된다. 전 세계 어디에도 이런 방식의 문자는 없기 때문에[6] 외국어와 한국어를 하나의 문자셋에서 처리하기 위해서는 좋든 싫든 저 11,172자를 전부 줄 세울 수밖에 없었기 때문이다. 그나마도 너무 많다 보니 안 쓰일 것 같은 글자는 다 털어내고 2350자만 줄 세워 정리한 게 지금의 완성형 KS X 1001이다. 이후 조합형도 나중에 정리된 2바이트 상용 조합형이 KS X 1001의 부속서 3으로 들어가면서 한글 코드는 2개의 표준을 가지게 되었다.

4. 유니코드( Windows NT) 이후

유니코드 체계에서는 완성형이라 할 수 있는 현대 한글 11,172자와 (공식적인 명칭은 한글 음절, Hangul Syllables) 조합형처럼 쓸 수 있는 한글 초중종성이 (공식 명칭은 한글 자모, Hangul Jamos) 옛한글까지 모두 포함되어 있어서 두 방식 모두 사용이 가능하다. 따라서 완성형의 문제도 모두 사라진 상태. 따라서 한글 음절을 주로 쓰고, 한글 음절로 표현할 수 없는 한글(특히 옛한글)을 표현할 때는 한글 자모를 조합해 보조하는 방법을 사용한다.

Windows NT부터는 운영체제 내부에서 프로그램이 구동될 때 항상 유니코드로만 돌아가고, 유니코드의 구성에서 초성-중성-종성의 배열 조합(첫가끝)이 지원되는 특성상 프로그래밍을 할 때 조합형 코드를 자체적으로 구현해서 사용할 필요성은 사라졌다.

윈도우용 프로그램에서 끝까지 조합형을 지킨 프로그램으로 아래아 한글 [7]이 있다. 그러나 아래아 한글도 2000년 워디안 버전으로 넘어가면서 유니코드로 바꿨다.

다만 한글 자모는 단점도 있는데, 완성형에 비해 2~3배 가량의 용량[8]이 필요하여 비효율적이기 때문. 그래서 상술했듯 옛한글과 의도적으로 글자수를 늘리는 것 외에는 잘 쓰이지 않는다.

폰트의 경우, 조합형에 가까운 글자수를 자랑하는 것도 존재한다.

여기어때 잘난체[9]
세방고딕
한컴 말랑말랑
THE폰트 - 외계인설명서, 노말, 수수깡, 큐트래빗 등..
태-으뜸

4.1. 자모 조합(첫가끝[10])

유니코드에서도 자모 조합(첫가끝)으로 한글을 만들 수 있다. 유니코드의 한글 자모 영역에는 초성, 중성, 종성의 자모 한 글자씩 나열되어 있으며 옛한글 자모까지 모두 포함되어 있고, 이를 그냥 나열하는 것으로 글자를 조합하여 보여줄 수 있다. 다만, 자모 하나하나가 유니코드 한 글자(3바이트)로 취급되기 때문에 데이터 길이가 2~3배[11]로 늘어나는 문제는 존재한다. 따라서 보통 현대 한글을 표현할 때는 이용되지 않고, 주로 옛한글을 표시할 때 이용된다.

예외적으로 Darwin 계열 운영체제에서는 현대 한글에서도 첫가끝 코드가 쓰인다. 애플의 HFS+ 파일 시스템은 한글 파일명을 디스크에 저장할 때 첫가끝 코드로 저장한다. 이 때문에 OS X에서 파일을 전송하면(혹은 압축하면) 윈도우나 리눅스에서 한글 파일명이 죄다 풀어쓰기로 변한다. macOS와 윈도우가 같은 유니코드를 쓴다 하더라도 정규화 방식에서 macOS는 유니코드의 정규화 방식 D(NFD)를 사용하였고, 윈도우에선 정규화 방식 C(NFC)를 사용하기 때문에 어긋나는 것. 현대 한글 NFC ↔ NFD 변환 테이블은 현대 한글 NFC ↔ NFD 변환 테이블 문서를 참고할 것.

나무위키
위 단어를 복사해 한 글자씩 지워보자.

macOS, 안드로이드, iOS 등 다양한 OS를 사용하게 되면서 한글이 자소 단위로 깨져 보인다는 문의가 많이 늘어났다. 윈도우 XP 시절에는 풀어진 모습으로 보여줬는데, 윈도우 비스타부터는 합쳐서 보여준다. 다만, 똑같아 보이는 문자라도 실제 적혀있는 문자는 다르니 같아보이는 파일명이 두 개가 있다든가, 파일 이름 순 정렬을 할 때 뜬금 없는 순서에 정렬이 되는 문제는 있다. 반디집의 경우에는 6.0 버전부터 이를 자동으로 교정해주는 기능을 지원한다.

1바이트 ASCII 코드만 지원하는 프로그램에서 어쩔 수 없이 쓰는 경우도 있다. 특히 유저들이 북미 게임의 한글 패치를 만들 때 이 조합형의 방법을 사용하는 경우가 많다. 북미 게임의 경우 내수용으로만 기획되었다면 1바이트 ASCII 코드만 지원하는 경우가 있는데, ASCII 코드의 확장 영역에다 한글 낱자를 집어넣은 일종의 커스텀 코드를 만들어 한글 낱자를 직결식 글꼴의 방법대로 화면에 출력한다. 폴아웃 3와 오블리비언이 대표적인 예.

[1] 한자는 2천자 정도. [2] 상대방의 ID를 조회하는 PF 명령어를 통해 실제로 조회된 내용으로 보아 적어도 당시에는 실존했던 핸들네임으로 확인되고있다. [3] n바이트와 같이 길이가 변하지도 않고, 완성형과 효율이 같기 때문에 경쟁력이 있다. [4] 금성 조합형, 삼성 조합형, 그리고 삼보를 중심으로 한 상용 조합형 등. [5] 일단 이중모음과 겹받침도 한 자모로 보자. 이걸 다 잘라 생각하는 게 n바이트식인데, 이건 더 어려워진다. [6] 한자에도 회의자나 형성자 등 여러 글자를 합쳐서 새로운 글자를 만드는 시스템은 있긴 하지만, 한자는 말만 되면 아무 글자나 줏대 없이 막 합쳐대고, 또 그러다 보니까 쓰기 불편하다고 간략화되면서 규칙이 죄다 박살났다. [7] 정확히는 조합형을 개조해서 옛한글을 집어넣은 한컴 2바이트 코드를 사용했다. [8] 인코딩이 UTF-8이면 자모 하나하나가 3바이트 크기가 된다. [9] 2차 버전 한정. [10] 첫소리-가운데소리-끝소리의 준말. [11] 종성이 없는 글자는 생략하기 때문에 2배가 된다.

포크 과정 중 수정 로그가 손실된 문서입니다.

이 문서는 리그베다 위키에서 나무위키로 포크를 해 오는 과정 중 수정 로그가 손실된 문서이며, 문서 재작성 혹은 문서 최하단 리그베다 위키의 문서 역사 URL, 분류:포크 누락 문서 분류가 필요합니다.

나무위키의 문서는 CC 라이선스에 따라 저작자 정보를 표시해야 하지만, 이 문서는 포크 누락으로 인해 저작자 정보가 유실되어 사용할 수 없는 상태입니다. 이에 대한 자세한 내용은 나무위키:포크 누락 문서를 참고해주세요. 만약 위의 방법으로 포크 누락을 완전히 해결을 하셨다면 분류:포크 누락 문서 분류를 떼고 분류:포크 누락 해결을 달아주시길 바랍니다.