조합형

한글의 전산화 관련 문서
한글 인코딩조합형 · 완성형(한글 목록 · 중복 한자) · 조합형 완성형 논쟁 · 남북한 한글 코드의 충돌 문제 · 한컴 2바이트 코드 · 유니코드
타자기와 키보드두벌식 · 세벌식(일반 자판 · 속기 자판) · 휴대전화 입력기 · 한영 키

1 개요

옛날에 사용되던 한글 인코딩 방식 중 하나. 과거형을 강조하는 이유는 지금은 옛한글을 표기할 때 이외에는 거의 사용하지 않는 방식이기 때문이다.

코드에는 자모만을 배당해 두고, 자모의 조합으로 한글을 표현한다. 즉 글자 하나를 만들 때 초성+중성+종성으로 조합해서 만들며 가령 '만'이라는 글자를 입력하면 ㅁ+ㅏ+ㄴ 해서 '만'이 되는 식. 이 때 각 자모가 특정한 값을 가지고 이 값들을 나열하여 글자를 조합하기 때문에 조합형이라는 이름이 붙었다.

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

표준이 아닌 것으로 많은 사람이 알고 있지만, 엄연한 표준 코드이다. KS X 1001의 부속서 3으로 수록되어 있기 때문.

2 초창기(DOS)

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

1. n바이트 조합형: 한글 낱자 하나 당 1바이트씩 할당하는 방식. 한글 창제원리를 완전히 반영한다면 한 글자에 들어가는 바이트 수가 들쭉날쭉이 된다. 가령 '무' 는 ㅁ + ㅜ로 최소 2바이트가 들어가지만 '뷁'은 ㅂ + ㅜ + ㅔ + ㄹ + ㄱ로 최대 5바이트까지 늘어난다. 또한 문장 앞뒤에 시작(SI)과 끝(SO)을 알리는 별도 코드가 들어갔다. 이래저래 용량을 많이 잡아먹는 코드라서 널리 퍼지지는 못했다.

2.3바이트 조합형: 초성 + 중성 + 종성 문자를 배당하고(받침이 없는 글자는 채움 글자를 따로 쓴다) 조합하는 3바이트 조합형을 고안하기도 했지만, 글자당 2바이트를 소비하는 완성형에 비해 효율이 낮다.

3.2바이트 조합형: 보통 조합형은 2바이트 조합형을 의미한다[3] 2바이트 16비트에서 앞 1비트는 한글임을 알리고, 나머지 15비트를 5비트씩 잘라 배당했다. 그런데 이 규격을 각 회사마다 독자적으로 정해버려서[4] 서로 호환이 되지 않았고, 2번째 바이트의 첫 비트가 0이면 다른 ASCII 코드와 충돌할 수 있다. 나중에 이것이 '상용 조합형'(삼보 조합형, KSSM)으로 정리되고, 1992년에 표준으로 지정된다(KS X 1001의 부속서 3으로 수록됨).

DOS 시절에는 그래픽을 지원하는 프로그램 개발자들에게 있어 완성형보다 선호되었는데, 글꼴을 만들기가 용이하고 프로그램 사용에 있어서 훨씬 유연했기 때문이다. 키보드 입력값을 받아 합치기만 하면 글자가 완성되는 조합형이라 속도 차이도 많이 났다. 자체 한글을 내장한 앱은 조합형이라 할 정도.

조합형 완성형 논쟁 때, 조합형을 미는 사람들이 항상 주장했던 것이 현대 한글을 모두 표현할 수 있다는 것, 바로 찦차를 타고 온 펲시맨과 쑛다리 똠방각하 였다. 현대 한국인은 이 문장을 무리 없이 읽지만, (기본)완성형 폰트를 쓰는 시스템에서는 표시할 수도 읽을 수도 없으며, 실제로 타이핑하면 찌ㅍ차를 타고 온 페ㅍ시맨과 쑈ㅅ다리 또ㅁ방각하라고 나온다. 어떤 사람이 이런 것에 불만을 갖고 글을 쓰면서 찦차를 타고 온 펲시맨과 쑛다리 똠방각하를 집어넣었으나, 인코딩이 어찌되어 뾼차를 타고 온 최시맨과 뉵다리 馱방각하처럼 바뀌어버렸다.#

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

이 논쟁은 나중에 마이크로소프트에서 Windows 95에 확장 완성형을 도입하면서 조합형은 완전히 묻혀버리게 되었다. 조합형이 주장하던 한글 완전 구현이, 마소에서 어거지로 나머지 문자를 죄다 배당하는 방식으로 땜빵한 덕분.

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

4 유니코드(Windows NT) 이후

유니코드 체계에서 한글은 주로 완성형으로 들어가며, 현대 한글 11,172자가 모두 들어갈 수 있기 때문에 특정 한글이 안나오거나 하는 문제는 사라졌다. 이에 따라 조합형의 필요성은 희박해졌다. 하지만 고작 몇십 개의 자모의 조합으로 표현할 수 있는 한글이 11,172자나 써버리는 건 안습이다. 이게 다 우리가 컴퓨터를 발명하지 못해서다.

Windows NT부터는 운영체제 내부에서 프로그램이 구동될 때 항상 유니코드로만 돌아가고(프로그램이 비유니코드로 만들어져 있으면 실시간으로 변환되며 작동한다), 유니코드의 코드 구성 자체에서 초성-중성-종성의 배열 조합(첫가끝)이 지원되는 특성상 프로그래밍을 할 때 소위 "한국형(...) 조합형 코드"를 자체적으로 구현해서 사용할 이득은 사라졌다.

윈도우용 프로그램에서 끝까지 조합형을 지킨 프로그램은 다름아닌 아래아 한글(정확히는 조합형을 개조해서 옛한글을 집어넣은 한컴 2바이트 코드를 사용했다). 그러나 아래아 한글도 2000년 워디안 버전으로 넘어가면서 유니코드로 바꿨다.

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

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

macOS(OS X)에서는 첫가끝 코드가 매우 절찬리에 쓰인다. 애플의 HFS+ 파일 시스템은 한글 파일명을 디스크에 저장할 때 첫가끝 코드로 저장한다. 이 때문에 OS X에서 파일을 전송하면(혹은 압축하면) 윈도우나 리눅스에서 한글 파일명이 뼈와 살이 분리되는 경험을 할 수 있다. macOS와 윈도우가 같은 유니코드를 쓴다 하더라도 정규화 방식에서 macOS는 유니코드의 정규화 방식 D(NFD)를 사용하였고, 윈도우에선 정규화 방식 C(NFC)를 사용하기 때문에 어긋나는 것.

이용신청서(완성형) → 이용신청서(첫가끝)

※글꼴에 따라 합쳐져서 보일 수도 떨어져서 보일 수도 있다. 몇몇 가상머신에서는 자동으로 첫가끝을 완성형으로 바꿔주는 경우도 있다. "이용신청서(첫가끝)"으로 보인다면, 위의 글자를 메모장에 붙여넣고 각 음절을 backspace키로 지워보면 "ㅇ요시처ㅅ"가 된다.

윈도우 전성시대에서 맥북, 안드로이드, 아이폰 등 다양한 OS를 사용하게 되면서 "한글의 자소 단위로 깨져 보인다"# 등의 문의가 안드로이드에서 NTFS가 안읽힌다는 문의와 함께 많이 늘어났다. 윈도우 XP 시절에는 정직하게 첫가끝으로 풀어져 있으면 깨진 모습으로 보여줬는데 (폰트 역시 첫가끝 표기를 제대로 지원 못했다), 윈도우 비스타(맑은 고딕) 이후로는 첫가끝으로 풀어 적은 글도 완성형처럼 적절하게 보여줄 수 있게 되었다. 다만, 똑같아 보이는 문자라도 실제 적혀있는 문자는 다르니 파일 이름 순 정렬을 할 때 뜬금 없는 순서에 정렬이 되는 문제는 있다. 영문파일명이면 편해

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

  1. ↑ 하나의 글꼴이 포함할 수 있는 최대 글리프 수는 65535개로, 모든 한글 조합을 완성형으로 넣는 것 자체가 애초에 불가능하다. 그나마 꽉꽉 채운 폰트는 본고딕.
  2. ↑ 한자는 3만자 정도. 시스템 폰트의 절반 이상을 한자와 한글이 차지하는 민폐(...)
  3. ↑ n바이트와 같이 길이가 변하지도 않고, 완성형과 효율이 같기 때문에 경쟁력이 있다.
  4. ↑ 금성 조합형, 삼성 조합형, 그리고 삼보를 중심으로 한 상용 조합형 등.
  5. ↑ 일단 이중모음과 겹받침도 한 자모로 보자. 이걸 다 잘라 생각하는 게 n바이트식인데, 이건 더 어려워진다.
  6. ↑ 한자에도 회의자나 형성자 등 여러 글자를 합쳐서 새로운 글자를 만드는 시스템은 있긴 하지만, 얘네들은 말만 되면 아무 글자나 줏대 없이 막 합쳐대고, 또 그러다 보니까 쓰기 불편하다고 간체라는 걸 만들면서 규칙이 죄다 박살났다.
  7. ↑ 첫소리-가운데소리-끝소리 (...)
섬네일을 만드는 중 오류 발생: 파일이 없음
수정 로그가 손실된 문서입니다.
이 문서는 리그베다 위키에서 나무위키로 포크를 해 오는 과정 중 수정 로그가 손실된 문서이며, 문서 재작성이 필요합니다. 나무위키의 문서는 CC 라이선스에 따라 저작자 정보를 표시해야 하지만, 이 문서는 포크 누락으로 인해 저작자 정보가 유실되어 사용할 수 없는 상태입니다. 이에 대해 자세히 알고 싶으신 분은 분류:포크 누락 문서를 참조해 주세요.