한글 자모?
한글은 첫글자, 가운데글자, 끝글자(줄여서 첫가끝글자라고 합니다)로 구성된 조합형 문자입니다. 하지만 한글을 완성형 문자라고도 볼 수 있습니다. 현대 한글에서는 첫글자 19자, 가운데글자 21자, 끝글자 28자의 조합만 사용되고, 이 조합으로는 11172자의 문자를 만들 수 있습니다. 각각의 문자는 다른 문자의 조합에 영향을 주지 않기 때문에, 서로 독립적이 되고, 각각의 문자에 서로다른 문자코드를 부여하면 완성형이 되버리는 것입니다.
초창기 컴퓨터에서 한글 사용에 대해 논의가 되었을 때, 첫가끝글자마다 값을 지정하여 그 값의 조합으로 문자를 매핑하는 조합형과, 완성된 문자에 임의의 코드값을 주는 완성형이 제시되었습니다. 완성형이 모든 한글을 표시하지 못한다는 이유로 재야에서는 조합형이 대세였지만, 국가정책과 문서호환이라는 부분이 강조되어 결국 완성형이 조합형을 누르게 되었죠. 이러한 국가표준과는 달리 최초 ISO 10646 논의에서 ‘한글은 조합형으로만 구현하며, 완성형은 KS X 1001(당시 KS C 5601)과의 호환을 위해 2350자만 넣는다’라고 합의가 됩니다. 이때 정한 조합용 한글 낱글자 영역이 한글 자모입니다.
그러나 프로그래밍의 난이도, 조합 데이터의 크기 등을 문제 삼아 일부 회원국/사에서 현대한글의 완성 글자 11,172자를 넣을 것을 강력히 주장하였고, 결국은 호환용 글자 2,350자가 빠진뒤, 11,172자가 한글 음절(Hangul Syllables) 영역이 추가되고, 한글 음절 영역만 사용되면서 한글 자모 영역은 잊혀져 버리고 되었죠. Microsoft에서도 XP까지 이 영역을 지원하지 않았는데, Vista에서는 조합을 지원하게 되었습니다.
한글 자모로 글 써보기
여기에서는 간단하게 한글 자모로 글을 써보겠습니다. “물론” 비스타에서만 가능하죠. 아직까지 한글 자모로 입력가능한 IME가 없기 때문에 문자표로 대신 입력합니다.
1. 문자표 실행 : [스타트 메뉴]-[실행]-[charmap]
2. 글꼴 설정 : 굴림, 맑은 고딕 등 윈도우즈 기본 한글 글꼴 이나 한컴바탕, 한컴돋움
3. 고급보기 체크
4. 문자 집합 설정 : 유니코드
5. 유니코드로 이동 값 입력 : 1100
위와 같이 하면 아래와 같은 창이 뜨게됩니다.
첫소리 글자, 가운데소리 글자, 끝소리 글자에서 하나씩 골라서 더블클릭해보세요. 그럼 복사할 문자 칸에 조합된 문자가 출력됩니다. 여기서 생성된 글자를 복사해서 다른 프로그램에서도 볼수 있습니다.
아래는 위와 같은방법으로 해서 쓴 글입니다. 만약 한글 자모 지원을 조합하지 못하는 OS나 브라우저를 쓴다면 아래의 글이 풀어져서 보일 것입니다.
드디어 윈도우즈에서 한글 자모 조합을 지원하네요.
한글 자모 조합을 지원하는 글꼴은?
한글 자모를 지원하는 모든 한글 글꼴이 지원하는 것은 아닙니다. 오픈타입 한글 스크립트 테이블을 포함한 글꼴만 가능합니다.
비스타에 포함된 글꼴 중에는 굴림, 굴림체, 돋움, 돋움체, 궁서, 궁서체, 바탕, 바탕체, 맑은 고딕이 이를 지원하며 윈도우즈 용 글꼴 중에는 한컴바탕과 한컴돋움이 이를 지원합니다. 물론 더 많은 글꼴이 이를 지원할 거라 생각하지만, 제가 가지고 있는 글꼴 중에서는 이게 전부이네요.
뒷이야기
사실 비스타에서 한글 자모를 할 수 있다는 사실이 비스타가 나온지 몇 개월이 되도록 언급조차 안되고 있다는 사실에 놀랐습니다. 제가 한글 자모 조합이 가능하다는 것을 알게된 것도, 마이크로 소프트 개발자 중 한 분인 Michael Kaplan님의 블로그였습니다. 이 걸 알게된 뒤에 구글, 네이버 등 검색엔진에서 찾아도 Michael Kaplan님의 글 외에는 관련글이 없더군요. 가장 의문인 것은 마이크로소프트 사가 무척 조용하다는 것입니다. 도움말 어디에도 언급이 되어 있지않고, MSDN의 콤플렉스 스크립트 관련 글에도 전혀 등장하지 않으니까요. 설마, “모든 개발을 ‘미국 마소’에서 한국 마소는 전혀 모르고 있었다.”라는 것은 아닐테죠?
이제 본격적으로 한글 자모 조합이 가능해진 이상 Hangul Syllables와 Hangul Jamo의 선호, 채움 문자, 정렬, 고어 표시 등에 대해서도 많은 논의가 되어야 한다고 생각하며, 이 글이 그런 논의에 불씨가 되었으면 하네요.
참고
Sorting It All Out : We’re off on the road to Korea! We certainly do get around… – 한글 자모 조합이 가능하다는 걸 알게된 곳입니다. 글꼴, 언어관련 글이 많이 있습니다.
Hangul OpenType Specification – 오픈타입에서의 한글 처리에 관한 마이크로소프트의 글 입니다.
참고로 첫소리 글자와 가운데소리 글자 사이의 빈칸처럼 보이는 건 첫소리 채움문자입니다. 물론 첫소리에 포함되는 게 맞겠지만, 그림판에서 이미 잘못 그려버려서 그냥 놔두었습니다. ^^
한글 자모로 한글을 표현할 수 있다는 건 알겠는데 그래서 이게 어디에 활용될 수 있는 건가요? 기존에 한글을 잘 표시했었고 그나마 FF에서 지원하는 채움 문자+첫가끝 코드(맞나?) 표현 방식도 잘 쓰이지 않는데.. 새로운 방식이 가능하더라도 그게 굳이 쓰일 장점이 없다면 사람들이 찾지 않겠죠.
왜 한글 자모 방식이 비스타에 추가되었는지 모르겠지만 그게 없었던 시절과 생기고 나서 변화할 부분이 무엇인지 이해가 안 갑니다. 한국에서 조용한 이유도 그런 게 아닐까 하네요.
FF에서 지원하는 것은 KS X 1001을 인코딩하는 데 있어, 완성되어 있지 않은 한글을 조합하는 방식입시다.
여기에서 논의하고자 하는 것은, 유니코드의 한글 스크립트입니다. 유니코드의 한글 자모에는 옛글자의 첫가깥 글자가 포함되어 있고, 이를 조합하여 문자를 표현할 수 있습니다. 즉, 지금까지 유니코드의 사용자 영역을 통해 옛글자를 사용했던 것을 표준 유니코드 방식을 통해 가능해 진것으로, 이는, 앞으로 정보교환에 있어 뛰어난 호환성을 보장해 줄 수 있습니다.
물론, 현대 한글의 완성형 문자가 표준으로 들어간 이상, 이와 같은 방식으로 현대한글을 표현하는 것은 더 논의해 봐야할 일이라고 생각합니다.
적어주신거 따라서 해 봤지만 글자 조합이 전혀 되지 않습니다.
단순히 종성을 적으면 종성 한글자로 보일 뿐
(유니코드 조합이 가능한 현대어 적으면 그건 제대로 나타나긴 하네요.)
고어를 제대로 표현하기 위해서는 제대로 된 지원이라 할 수 없습니다.
네. 아직 고어 대해서는 조합이 안되는 것 같아요. 일단 더 연구중인데 아직까지는 뚜렸한 결론을 못내렸습니다. Apple쪽에서는 어떻게 처리하는지 알고 싶어서 Safari for Windows를 설치해봤는데(사파리는 애플의 글꼴 처리 라이브러리를 사용합니다.) 한글이 나오지 않아서 실패했네요. 뭐, 링크 된 페이지에서는 고어도 나오니 더 연구하고 문의해보면 결과는 있을거라 생각합니다.
연결된 곳은 전부 영어로 되어 있어서 못들어가 봤습니다.
인터넷이랑 제 업무쪽은 공부 하려고만 하면 계속 외국어에 막히는군요.
공부 해야지 생각한지 몇년이 지났건만 돈과 시간만 썼지 실제 진행은 안되고 있습니다. ㅜ.ㅜ
외국어를 편리하게 표기할 수 있는 소위 개량한글도 있습니다.
곧글&순글 이라고 합니다. 물론 일장일단 장단점은 있지만
곧글, 순글이 현행 한글과 비교해서 조합형으로 글자를 쓸 때 꽤 유용하다는 겁니다. 곧글&순글에서는 굳이 완성형 폰트를 만들 필요가 없습니다. 그렇다고 로마문자나 대다수의 음소문자들이 취하는 형식, 풀어쓰기(자모를 수평으로 1열로 배열) 하는 방식과는 차별화 되었기에 단순히 풀어쓰기라고 치부할 수도 없습니다.
곧글&순글에 대한 좀더 자세한 정보는 이곳에 있습니다.
http://www.godgul.com/
곧글 사이트 죽었습니다. 수정하셔야겠네요.
Michael Kaplan님의 블로그의 트랙백된 링크도 죽었습니다. 예전에는 pluu.pe.kr 도메인을 쓰신 모양이네요.
아 하고자 하는 얘기는 이게 아니고,
저는 윈도우즈XP SP3라서 그런지 예문이 firefox, IE8에서 모두 풀어져서 나오네요. 유니코드의 본래 취지와 다르게 환경에 따라 표현이 다르게 되는 건 이상하군요. Windows7에서는 어떻게 나올까 궁금하네요.
웹페이지가 UTF-8로 인코딩되어 있어서, 위의 예문도 자모당 3바이트씩 먹고 있는데, UTF-16으로 인코딩해 보니 2바이트씩 먹습니다.
이것을 보면 저 영역은 UTF-8의 2바이트 영역에도 못 들어서 3바이트씩 먹는건데, 이러면 받침까지 있을 경우 한 글자 표현에 9바이트나 먹습니다. UTF-16을 사용해도 6바이트군요. 다른 건 몰라도 저장용량이 3배에서 4.5배까지 커진다면 상시 한글표현용으로는 적합하지 않을 것 같습니다. 하지만 한글 관련 소프트웨어에서 내부 처리시에 사용한다면 자모 단위의 한글 처리가 보다 용이하겠네요. 사실인지 모르겠는데 한컴 한글에서는 내부 처리에 자체 제작한 조합형 한글이 쓰인다는 말도 들었던 것 같습니다.
고어 표현 및 연구나 앞으로의 신 자모 탄생(있을지 없을지 모르지만)대비를 위해서는 예비 영역의 확보가 필요한데, 문자표를 보니 각 성부 앞뒤로는 이미 여유가 없군요.
한글코드에 대해서 쓰자니 쓰고 싶은 말이 산더미인데, 댓글로 쓰기에는 제약이 따르네요.
새로운 자모는 Unicode의 새 버전에서 다른 영역에 추가되었어요.
우연히 검색하다 들렀네요…
이제 윈도에서도 조합형 한글이 된다는게 늦게나마 다행이라 생각합니다..(현재 까진 한글 이 내부적으로 조합형을 사용..^^)
완성형코드와 조합형코드의 논란은 이미 8비트 컴에서서 시작 했습니다..
과거 애플2의 3바이트형 한글(자1바이트 모1바이트받침1바이트)
그리고 경쟁 기종인 MSX(대우 IQ1000)은 n 바이트 한글 형식(모든 자모가1바이트)을 사용 했었습니다.. 모두 조합형이죠…ㅋ
어느듯 갑자기 IBM PC(당시 일반인들은 구입할엄두도 못냈음약5~600만대가격)를 교육용 피시로 정부는 발표하고 ksc5601이라는 완성형 한글(2바이트)을 가지고 나옵니다..
이유는 조합형은 너무 많은 메모리를 차지한다는 이유였습니다..
일반사용자 측면에서는 별문제가 없겠지만… 고급사용자들에게는
문제가 발생하기도 했죠… 영소문자 뒤에 영대문자를 붇이면 한글이 표현되게 했으니…
그래서 8비트인 MSX2(대우IQ2000) 에서는 2바이트형 완성형 한글을 선보입니다…
당근 그냥 사장 되었죠… 교육용PC가 16비트로 발표가 되었는데 누가 8비트를 쳐다 보겠나요?….
잠깐 지나가던 80년대 8비트 사용자 였습니다….
관계없는 말이지만, 지금의 첫가끝 코드는 완전한 조합형이 아니라 완성형 조각들을 합치는, 둘을 반 섞은 방식 같아요.