조합형
* 컴퓨터 관련 정보 - 인코딩
[include(틀:한글 전산화)]
[목차]
개요
한글 인코딩 방식 중 하나. 한글의 제자원리에 부합하여 표현이 자유롭다는 장점이 있어 한때 많이 쓰였고 또 많은 사용자의 지지를 받았던 방식이지만 지금은 유니코드의 등장으로 필요성이 크게 줄어 옛한글의 표기 이외에는 거의 쓰이지 않는다.
코드에는 자모만을 배당해 두고, 자모의 조합으로 한글을 표현한다. 글자 하나를 만들 때 초성+중성+종성을 조합해서 만드는 것. 가령 '만'이라는 글자를 입력하면 ㅁ+ㅏ+ㄴ 해서 '만'이 되는 식이다. 이 때 자모 단위로 특정한 값을 가지고 이러한 값들의 나열로부터 글자를 조합하기 때문에 조합형이라고 한다.
완성형 글자로는 표현할 수 없는, 160만개가 넘는 한글 자모로 결합한 모든 글자를 표현할 수 있다는 장점을 지닌다. 단점은 사용 빈도와 용량 효율성. 조합형 한글자보다 완성형 한글자가 용량을 적게 차지하는건 둘째치고, 현대 한글은 1만자 정도에서 해결이 되며[* 한자는 2천자 정도.], 의성어 등을 빼면 실제 3천여 자 정도, 고문헌에 사용된 글자 수는 5천여 자 정도밖에 안된다. 자세한 것은 유니코드항목과 본 항목에서 후술.
표준이 아닌 것으로 많은 사람이 알고 있지만, 엄연한 표준 코드이다. KS X 1001의 부속서 3(구 KS C 5601-1992)으로 수록되어 있다.
현재 유니코드에는 완성형 현대 한글이 모두 들어있으며, 총 11,172자가 등록되어 있다. 한자는 7만자가 들어있다. 라틴 알파벹의 경우 소문자 26자, 대문자 26자로 모두 52자에 불과한 것에 비교하면 동아시아 문자들이 얼마나 공간을 많이 차지하는 지 알 수 있다. 대신 한국어에는 조합형 한글도 들어있다. 옛한글 완성형도 포함하면 100만자가 넘기 때문에 유니코드에 배당된 공간을 넘어서기 때문이다. 그래서 유니코드 문자 공간에 적게 배당해줘도 되는 조합형도 쓸 수 있도록 하여 옛한글도 표기할 수 있도록 한 것이다.
한글은 원래 자음과 모음의 낱자를 조합하여 하나의 음절 문자를 만들기 때문에 조합형으로 하는 것이 생성 원리상 맞으나, 완성형 한글은 한 글자에 유니코드 한 문자가 배당되어있지만, 조합형 한글은 초성, 중성, 종성마다 각각 유니코드 글자가 하나씩 배당되어 용량이 3배로 늘어나므로 옛한글을 쓸 때 외에는 잘 쓰지 않는다. 조합형이 유니코드 문자 배당 공간은 조금만 차지하지만, 문자로 만들어져서 컴퓨터에 저장될 때는 낱자 하나씩을 합쳐야 하므로 완성형보다 더 많은 공간이 필요하다.
키보드에서도 한글의 원리에 맞는 세벌식이 두벌식보다 낫다. 일단 ㅇ와는 음가가 전혀 다른 옛한글 ㆁ부터 살려서 종성에 써야 한다.
초창기(MS-DOS 시대까지)
완성형으로는 글자를 표현 하는 데 한계가 있기 때문에, 이를 타개 하고자 여러 종류의 조합형 방식이 개발 되었다. 각 종류에 따라 장점과 단점이 존재 한다.
1. n바이트 조합형: 한글 낱자 하나 당 1바이트씩 할당 하는 방식. 한글 창제원리를 완전히 반영 한다면 한 글자에 들어 가는 바이트 수가 들쭉날쭉이 된다. 가령 '무' 는 ㅁ + ㅜ로 최소 2바이트가 들어 가지만 '쀍'은 ㅃ + ㅜ + ㅔ + ㄹ + ㄱ으로 최대 5바이트까지 늘어 난다. 또한 문장 앞뒤에 시작(SI)과 끝(SO)을 알리는 별도 코드가 들어 갔다. 이래 저래 용량을 많이 잡아 먹는 코드라서 널리 퍼지지는 못 했다. 개인용 컴퓨터 도입 이전 대형 컴퓨터 시절부터 한글 처리에 쓰였던 방식이고 8비트 시절에 애플 II나 MSX 등에 채용 되었다.
2.3바이트 조합형: n바이트 조합형의 단점인 1글자의 길이가 일정하지 않다는 점과 최대 5바이트까지 메모리를 차지 한다는 점을 개선 하기 위해 1980년대 초에 나 온 방식. 초성 + 중성 + 종성 문자를 배당 하고(받침이 없는 글자는 채움 글자를 따로 쓴다) 조합 하는 3바이트 조합형을 고안 하기도 했지만, 글자당 2바이트를 소비 하는 완성형에 비해 효율이 낮다. 애플 II의 '중앙한글' 같은 워드 프로세서에 채용 되기도 했다.
3.2바이트 조합형: 보통 조합형은 2바이트 조합형을 의미 한다.[* n바이트와 같이 길이가 변하지도 않고, 완성형과 효율이 같기 때문에 경쟁력이 있다.] 2바이트 16비트에서 앞 1비트는 한글임을 알리고, 나머지 15비트를 5비트씩 잘라 배당 했다. 그런데 이 규격을 각 회사마다 독자적으로 정해 버려서[* 금성 조합형, 삼성 조합형, 그리고 삼보를 중심으로 한 상용 조합형 등.] 서로 호환이 되지 않았고, 2번째 바이트의 첫 비트가 0이면 다른 ASCII 코드와 충돌 할 수 있다. 나중에 이 것이 상용 조합형(삼보 조합형, KSSM)으로 정리 되고, 1992년에 표준으로 지정 된다(KS X 1001의 부속서 3으로 수록 됨). 지금이야 윈도우라는 통합 플랫폼이 있어서 인코딩의 문제가 단순히 다른 설정으로 다시 읽어 들이기만 하면 되는 정도지만, 당시에는 한글을 표현 하기 위해 특정 인코딩 전용 SW, 특정 인코딩 표현 하는 DOS의 버전, 특정 인코딩을 DOS에서 표시 하기 위한 램 상주 유틸리티, 그리고 전용 하드웨어 카드까지 동원 하던 시절이라 자기가 사용 하는 컴퓨터에서 구해 놓은 자료가 깨지면 당장 답이 없던 시대였다. 그래서 당시에는 동영상 코덱 변환 하듯이 문서자료의 인코딩을 변환 하는 프로그램들이 여럿 있었다.
DOS 시절에는 그래픽을 지원 하는 프로그램 개발자들에게 있어 완성형보다 선호 되었는데, 글꼴을 만들기가 용이하고 프로그램 사용에 있어서 훨씬 유연했기 때문이다. 키보드 입력값을 받아 합치기만 하면 글자가 완성 되는 조합형이라 속도 차이도 많이 났다. 여러 라이브러리들에서도 기본적인 지원은 조합형 방식부터 시작 했고, 몇 종류의 자모만 도트로 찍으면 됐기 때문에 지금은 그 무게 자체가 다르게 다가 오는 '폰트를 자작한 프로그램' 들이 많았다. 자체 한글을 내장한 앱은 조합형이라 할 정도.
조합형 완성형 논쟁 때, 조합형을 미는 사람들이 항상 주장 했던 것이 현대 한글을 모두 표현 할 수 있다는 것인데, 이 때 나 온 유명한 문장이 바로 "찦차를 타고 온 펲시맨과 쑛다리 똠방각하"다. 현대 한국인은 이 문장을 무리 없이 읽지만, 완성형 시스템에서는 표시 할 수도 읽을 수도 없으며, 실제로 타이핑하면 "찌ㅍ차를 타고 온 페ㅍ시맨과 쑈ㅅ다리 또ㅁ방각하"라고 나 온다. 또 이 문장을 조합형으로 쓴 문서를 예외 처리 없이 강제로 유니코드로 변환 하면 "뾼차를 타고 온 최시맨과 뉵다리 馱방각하"처럼 바뀌어 버린다.[[1]] 이 때문에 펲시맨, 펲시콜라의 경우 뒷날 한글 표기를 지금의 '펩시맨', '펩시콜라'로 바꾸었으며, 똠방각하는 '돔방각하'와 같이 적는 경우가 많았다.
확장 완성형(Windows 95) 이후
그러나 이후 마이크로소프트에서 Windows 95에 확장 완성형을 도입하면서 조합형은 완전히 묻혀버리게 되었다. 조합형이 주장하던 한글 완전 구현을 마소에서 뒷부분에 나머지 문자를 죄다 배당하는 방식으로 땜빵한 덕분. 당시 MS에서도 이전 버전에서 정부표준에 따라 도입했던 완성형의 문제를 이전부터 인식하고 있었다고 발표하면서 표준 완성형의 한계를 넘기 위해 글자를 새로 정리하려 했으나, 역시 기존 인코딩과의 호환을 넘을 수 없어 추가되는 문자(KSC5601-1992 조합형에서 남는 문자들)를 기존 완성형(KSC5601-1987)의 뒤에 추가했다. 이 선택의 문제점은 종전 완성형이 가나다 정렬되어 있고, 새로 추가된 확장 영역은 그 뒤에 다시 정렬되어 있기 때문에 가나다 순서로는 찾을 수 없고, 단순히 코드만을 가지고는 한글 가나다 정렬을 할 수 없다는 점이다. 물론 요즘은 코드 순으로 문자를 정렬하는 시스템은 존재하지 않는다.
조합형이 묻혀버리게 된 이유 중 또 다른 하나는 외국어. 한글의 최소 단위는 자모인 게 맞지만, 이게 발음을 가지려면 순서대로 자 + 모 혹은 자 + 모 + 자[* 일단 이중모음과 겹받침도 한 자모로 보자. 이걸 다 잘라 생각하는 게 n바이트식인데, 이건 더 어려워진다.] 순서로 문자를 정확히 조합해야 한다. 이렇게 조합된 글자 중 11,172자만 현대 한국어를 표현하는 데 쓰이며, 잘못 조합된 문자는 말이 안 되거나 옛한글이다. 조합형의 장점을 극대화하려면 모든 초성/중성/종성의 가짓수를 전부 가지고 정확히 3차원 배열의 순서대로 전체를 다 배열해야 하는데(이래야 조합형의 최대 장점인 조합 및 분해, 정렬의 규칙이 정립된다), 이 경우 엄청나게 많은 문자 영역이 발음 불가능하거나 옛한글과의 조합이 된다. 전 세계 어디에도 이런 방식의 문자는 없기 때문에[* 한자에도 회의자나 형성자 등 여러 글자를 합쳐서 새로운 글자를 만드는 시스템은 있긴 하지만, 얘네들은 말만 되면 아무 글자나 줏대 없이 막 합쳐대고, 또 그러다 보니까 쓰기 불편하다고 간략화되면서 규칙이 죄다 박살났다.] 외국어와 한국어를 하나의 문자셋에서 처리하기 위해서는 좋든 싫든 저 11,172자를 전부 줄 세울 수밖에 없었기 때문이다. 그나마도 너무 많다 보니 안 쓰일 것 같은 글자는 다 털어내고 2350자만 줄 세워 정리한 게 지금의 완성형 KS X 1001이다. 이후 조합형도 나중에 정리된 2바이트 상용 조합형이 KS X 1001의 부속서 3으로 들어가면서 한글 코드는 2개의 표준을 가지게 되었다.
유니코드(Windows NT) 이후
유니코드 체계에서는 완성형 현대 한글 11,172자와 조합형에 쓸 수 있는 한글 초중종성이 옛한글까지 모두 포함되어 있어서 두 방식 모두 사용이 가능하다. 따라서 완성형의 문제도 모두 사라진 상태. 따라서 완성형을 주로 쓰고, 완성형에 없는 한글(특히 옛한글)을 표현할 때는 조합형으로 보조하는 방법을 사용한다.
Windows NT부터는 운영 체제 내부에서 프로그램이 구동될 때 항상 유니코드로만 돌아가고, 유니코드의 구성에서 초성-중성-종성의 배열 조합(첫가끝)이 지원되는 특성상 프로그래밍을 할 때 조합형 코드를 자체적으로 구현해서 사용할 필요성은 사라졌다.
윈도우용 프로그램에서 끝까지 조합형을 지킨 프로그램으로 아래아 한글[* 정확히는 조합형을 개조해서 옛한글을 집어넣은 한컴 2바이트 코드를 사용했다.]이 있다. 그러나 아래아 한글도 2000년 워디안 버전으로 넘어가면서 유니코드로 바꿨다.
다만 단점도 있는데, 완성형에 비해 2~3배 가량의 용량[* 자모 하나하나가 3바이트 크기이다.]이 필요하여 비효율적이기 때문. 그래서 상술했듯 옛한글 이외에는 잘 쓰이지 않는다.
자모 조합(첫가끝[* 첫소리-가운데소리-끝소리의 준말.])
유니코드에서도 자모 조합(첫가끝)으로 한글을 만들 수 있다. 유니코드의 한글 자모 영역에는 초성, 중성, 종성의 자모 한 글자씩 나열되어 있으며 옛한글 자모까지 모두 포함되어 있고, 이를 그냥 나열하는 것으로 글자를 조합하여 보여줄 수 있다. 다만, 자모 하나하나가 유니코드 한 글자(3바이트)로 취급되기 때문에 데이터 길이가 3배로 늘어나는 문제는 존재한다. [보통 현대 한글을 표현할 때는 이용되지 않고, 주로 옛한글을 표시할 때 이용된다.]
예외적으로 macOS(OS X)에서는 첫가끝 코드가 자주 쓰인다. 애플의 HFS+ 파일 시스템은 한글 파일명을 디스크에 저장할 때 첫가끝 코드로 저장한다. 이 때문에 OS X에서 파일을 전송하면(혹은 압축하면) 윈도우나 리눅스에서 한글 파일명이 죄다 풀어쓰기로 변한다. macOS와 윈도우가 같은 유니코드를 쓴다 하더라도 정규화 방식에서 macOS는 유니코드의 정규화 방식 D(NFD)를 사용하였고, 윈도우에선 정규화 방식 C(NFC)를 사용하기 때문에 어긋나는 것. 현대 한글 NFC ↔ NFD 변환 테이블은 현대 한글 NFC ↔ NFD 변환 테이블 문서를 참고할 것.
> 이용신청서(완성형) → 이용신청서(첫가끝) > ※ 글꼴에 따라 합쳐져서 보일 수도 떨어져서 보일 수도 있다. "이용신청서(첫가끝)"으로 보인다면, 위의 글자를 메모장에 붙여넣고 각 음절을 backspace키로 지워보면 "ㅇ요시처ㅅ"가 된다.
macOS, 안드로이드, iOS 등 다양한 OS를 사용하게 되면서 한글이 자소 단위로 깨져 보인다는 문의가 많이 늘어났다. 윈도우 XP 시절에는 풀어진 모습으로 보여줬는데, 윈도우 비스타부터는 합쳐서 보여준다. 다만, 똑같아 보이는 문자라도 실제 적혀있는 문자는 다르니 같아보이는 파일명이 두 개가 있다든가, 파일 이름 순 정렬을 할 때 뜬금 없는 순서에 정렬이 되는 문제는 있다. 반디집의 경우에는 6.0 버전부터 이를 자동으로 교정해주는 기능을 지원한다.
1바이트 ASCII 코드만 지원하는 프로그램에서 어쩔 수 없이 쓰는 경우도 있다. 특히 유저들이 북미 게임의 한글 패치를 만들 때 이 조합형의 방법을 사용하는 경우가 많다. 북미 게임의 경우 내수용으로만 기획되었다면 1바이트 ASCII 코드만 지원하는 경우가 있는데, ASCII 코드의 확장 영역에다 한글 낱자를 집어넣은 일종의 커스텀 코드를 만들어 한글 낱자를 직결식 글꼴의 방법대로 화면에 출력한다. 폴아웃 3와 오블리비언이 대표적인 예.
[각주] [include(틀:포크 누락 문서)]분류:포크 누락 문서 분류:문자 전산 처리 분류:한글 전산 처리