한글 97에서 한글 워디안으로 변화.
2000년 무렵에 한글과컴퓨터 사가 많은 비난을 받았던 원인입니다. 달라진 어플리케이션, 달라진 파일 형식. 한글 97에 익숙한 사람에게 새로운 방식은 쉽게 받아들어지지 않았습니다.
하지만 한글 97이 편했음에도, 한글 워디안을 크게 반겼으며, 워디안을 쉽게 쓰기 위해 새로운 기능을 많이 연구해 보았죠.
수많은 새로운 기능 중에서도 ‘유니코드’를 지원한다는 것은, 다국어 문자와 언어 시스템에 많은 관심을 갖는 저에게는 큰 선물이었으니까요.
한글이 처음 윈도우로 등장하였을 때 부터, 한글은 Windows에서 제공하는 API나 툴킷을 사용하기 보다는, 필요한 것을 직접 구현하였습니다. 97 버전을 벗어난 워디안에서도 이러한 경향은계속 되었으며, UI와 유니코드 지원 부분이 모두 독자적인 코드로 동작하였습니다.
Windows 9x와 초창기의 Windows XP까지, Windows는 유니코드를 제대로 처리하지 못하였습니다. 독자적인 한글의 유니코드 처리 시스템은 윈도우즈에서 지원하지 않는 스크립트 등에 대해서도 지원하며, 한글의 글로벌 화를 위해 많은 노력을 기울였다고 생객합니다.
그리고 시간은 흘러흘러 2010을 앞두고 있는 지금. Microsoft는 자사의 유니코드 처리시스템 크게 향상 시켰으며, 많은 부분에서 한글보다 뛰어나게 처리해 주고 있습니다. 하지만 한글 2010 CBT는 여전히 자신만의 유니코드 처리 시스템을 고집하면서도, 스스로의 발전을 도모하지 않는 것 같스니다.
이건 한글과컴퓨터 사의 정책 문제일 수도 있습니다.
Q: 저장 다이얼로그에 다국어 문자를 붙어넣기하면 글자가 ?로 변경되어 저장할 수 없습니다.
A: 이전 버전에서 다국어 문자가 들어간 파일을 읽을 경우 문제가 생겨서, 다국어를 저장할 수 없도록 한 것입니다.(설계대로)
이제 2010년입니다. Windows의 기본 프로그램은 모두 유니코드 파일명을 정상적으로 처리하며, 최근에 제작된 많은 응용 프로그램도 유니코드 파일을 읽고 쓰는데 문제가 없습니다.
한글에서 유니코드 파일명을 입력할 수 없어도, 탐색기를 이용하면 유니코드가 들어가게 파일명을 바꿀 수가 있지요. 결국, 한글에서 저장 방식을 제한한다고 해결되는 문제가 아닙니다. 과거의 버전을 버리더라도 해결해야 문제는 해결해야하며, 과거의 문제는 과거 프로그램의 패치를 통해서 해결해야 할 것이라고 생각합니다.
또 다른 문제는 정렬에서 유니코드를 전혀 고려하지 않는다는 것입니다. 
왼쪽은 간단한 단어들에 대해, 한글 2010에서 가나다 정렬을 한 것입니다.
간단히 살펴봐도 기호-로마자-기호-로마자-가나-한글(한자)-로마자로 매우 복잡하게 정렬되어 있습니다.
유니코드와 같이 한 개의 문자에 대해서 여러 자형(대문자 A와, 강세붙은 Á, 전각문자Ａ)이 존재하는 경우에는, 문자를 정렬할 때 이를 동일한 객체 또는 인접한 객체로 인식해야 합니다. 하지만 이러한 것은 한글이나, 가나 일부에만 적용되어 있을 뿐, 오히려 가장 흔히 사용되는 로마자에 대해서도 지원하지 않고 있습니다.
왼쪽의 결과를 보면, 대체적으로 유니코드의 코드 순서에 따라 정렬된 것으로 보이며, 일부 특수한 경우에만 사전을 사용한 것 같습니다. 정식 버전이 출시되기 전에는 정렬 사전을 더 추가해야 할 필요성이 있다고 생각합니다.
다음은 한글 자모의 문제입니다. 유니코드에서는 Hangul Jamo 문자 영역이 있으며, 이 문자 영역의 낱글자를 이용하여 한글 syllables를 표현할 수 있습니다. 한글에서도 Hangul Jamo의 문자를 입력하면 syllables가 출력되도록 되어있습니다. 하지만 글꼴 및 크기 표현에 있어서는 아직까지는 문제가 있습니다.
크기는 모든 글꼴에서 지정한 크기보다 크게 출력됩니다. 모양은 일부 글꼴에서만 적용되는데, 적용되는 글꼴의 수는 함초롱돋움 및 함초롱바탕 밖에 없습니다.
간단하게 한글 2010의 유니코드 지원에 대해 적어 보았습니다. 비록 아직까지는 문제가 많지만 한글 2010 버전에서는 이러한 문제가 해결되기를 바랍니다.
