컴퓨터에서의 한글 처리 (3) 한글 문자 처리의 역사

이제는 정말로 공부를 해야 할 순간이다. 일단 다음의 사이트 내용을 천천히 정독하면서 최대한 개념을 이해하려 노력했다.

http://ieee-bmsb2012.org/blog/?p=191

공부한 내용을 간략히 정리하자면

문자 처리는 유니코드 이전과 이후 세대로 나누어 생각하는 것이 쉽다. 나는 유니코드 이전까지만 알던 인간... -_-

유니코드 이전 세대에는 초기 8비트 컴퓨터가 처음 등장할 때는 당연히 영어권에서 개발되었으므로 아스키 0-127, 7비트만으로도 왠만한 것을 다 처리했었다.

8비트 컴이 동양으로 들어오면서 동양권 문자 (이후 한글에 한정하여 생각하자) 를 표기하기 위해 다양한 방법이 시도되었다. 예를 들어 애플의 초기 3327 한글 같은 경우 2벌식 (약간 다른 글자가 있기는 하지만) 자판을 기준으로 입력하는 순서를 그대로 갖다 쓰는 N 바이트 조합형 인코딩을 쓴다. 한글이 시작하고 끝나는 곳에 CTRL-K 와 CTRL-A 를 넣어서 한글과 영어를 구별한다. 즉 2바이트의 7비트 문자로 다 처리했던 것. 

이후 16비트 PC 시대로 넘어가면서 8비트를 온전히 다루는데 문제가 없었고 컴퓨팅 파워도 자료의 비트 단위의 처리를 소프트웨어에서 수용할 만한 향상되었기에 2바이트 조합형이 개발된 것 같다. 첫 상위비트가 1이면 이후 두바이트가 한글임을 인식하고 두 바이트의 나머지 15비트를 5, 5, 5 비트씩 초,중,종성으로 코딩한다. 나름 대단히 과학적이라 생각하고 있었고 이를 이용하면 고어를 포함한 모든 한글을 다 표기할 수 있다. 그리고 한글을 출력할 시 비트맵 문자를 주로 사용하던 당시로서는 폰트 메모리도 최대한 절약할 수 있고 해서 완성형에 비해 장점이 있지만 (아마도) 마이크로소프트 등 소프트웨어를 주도적으로 만들던 업체들의 연구 결과에 의해 완성형이라는 한글 한 글자를 하나의 2바이트 코드로 매핑하는 (마치 한자 처럼) 방식이 표준이 되었다. 이때 정의된 초기의 완성형 (EUC-KR) 방식은 다수의 특별한 한글 문자를 포용하지 못했기에 (예를 들면 똠방각하의 '똠', 펲시콜라의 '펲' 등) 논쟁이 많았던 것이 기억난다. 게다가 한글 전산화란 명목으로 정부에서 주도한 주민등록증의 한글 이름으로만 표기하는 정책이 시행된 이후 많은 사람들은 자신의 이름조차 주민등록증에 표기하지 못하는 황당한 사태도 있었다.

이러한 문제를 해결한 것이 확장 완성형이라는 체계로 마이크로소프트에서 기존 EUC-KR 에 나머지 빠진 문자를 넣어서 완성한 인코딩 체계를 KS_C_5601-1987 이라 부르는 모양이다. 이것이 이후의 윈도우즈의 기본 한글 문자체계가 되었고 이때 각 나라별로 서로 부딪치는 코드를 구분하기 위한 코드페이지라는 개념을 도입한다. 나는 코드 페이지 개념도 희박했고 왜 한글은 949, 영어는 437 인지도 모르고 그런 거려니 하면서 잘 외우지도 못하면서 쓰곤 해 왔다.

이 방식은 한 나라안에서는 하나의 코드페이지를 쓸 경우 별 문제 없겠지만 소프트웨어를 개발하는 업체를 기준으로는 매 국가별로 화면에 표기되는 코드들을 다 수정해 주어야 한다는 사실이다. 게다가 인터넷 세상이 되어 전세계의 웹들을 다 돌아다니며 서로 언어를 혼용해서 쓰고 싶은 경우 코드페이지를 한 웹페이지 안에서 번갈아서 바꾸는 것이 문제가 되는 상황이었던 것 같다. 이러한 문제들을 해결하고자 전세계의 문자를 하나의 체계에서 다 나타낼 수 있는 방법을 모색하였고 그 결과로 탄생한 것이 유니코드 체계인 것으로 이해했다.