웹서핑을 하다가 발견한 글이다.
Windows 95 가 발표될 쯤에 황승식씨라는 분이 작성한 글이다.
아래 글의 요지는 한글 풀어쓰기가 컴퓨터와 어울린다는 것 같다.

일부 동의하기도 하고 일부 그렇지 않기도 하지만 흥미있는 내용이다.

==================================================

출처 : http://medicine.snu.ac.kr/aorta/sub1/08/08com-1.html

한글이 컴퓨터와 어울리지 않는 7가지 이유

과거에 문자중심으로 운영되어 어렵기만 하던 인터넷이 일반 사용자의 컴퓨터 사양이 뒷받침되면서 문자, 그림, 음성 등을 지원하는 월드와이드웹(World Wide Web)을 통해 급속하게 보급되고 있다. 그러나 그 정보가 가지는 유용함에 대한 과장은 두고서라도 영문 투성이의 정보 속에서 영어에 능통하지 않은 사용자가 원하는 정보를 쉽게 찾아내기란 결코 쉽지 않다. 그리고 정보검색의 핵심인 한글코드문제에서는 여전히 후진을 면치 못하고 있다는 사실이 한글윈도우즈95(정식 명칭은 '윈도'로 결정되었지만 이것도 말도 안된다. 영어를 조금만 배워도 본토발음 비슷하게는 써야 한다는 게 필자가 생각하는 외국어 표기의 원칙이다. 혀짧은 YS나 그렇게 발음할 것이지...) 발표와 함께 또 불거져 나오고 말았다. 그러나 논쟁양상은 한글표기에 치우쳤던 예전과는 조금 다르게 진행되었다.

확장완성형? 한글코드의 유령사냥

--MORE-- 기존에 줄기차게 조합형코드를 표준으로 삼자고 주장하던 사람들은 물론이고 완성형코드라는 절름발이코드를 만들어낸 당사자인 정부까지 나서서 마이크로소프트의 처사를 비난했다. 아니 확장완성형(마이크로소프트에서는 한글통합형코드라고 불렀다)을 채택한 한글윈도우즈95를 정부기관 사용거부 및 수입규제까지 검토하겠다고 으름장을 놓았던 것이다. 그런데 사실 확장완성형의 모태인 완성형을 만들어낸 당사자인 정부가 이미 업계 표준으로 확고히 자리잡은 마이크로소프트의 제품을 거부하겠다고 엄포를 놓은 것은 UR 거부 구호보다 더 비현실적이었다. 쌀 하나도 지켜내지 못하는 처지에서 정보산업에서 자립경제를 주장한다면 정부 당국자는 골수 주사파이거나 제정신이 아닌 사람이거나 둘 중의 하나일 것이다. 결국 새로운 제품의 시장진입을 앞두고 문제가 확대되는 것을 우려한 마이크로소프트의 결정으로 한글윈도우즈95에 확장완성형을 채택하는 것을 포기하고 정부표준안인 기존의 완성형코드를 따르기로 했다고 발표하면서 파문은 일단 마무리되는 되는 듯했다. 그러나 정식 판매품에는 확장완성형코드가 완전히 제거되지 않았다는 사실이 알려졌고 안그래도 늘어난 컴퓨터 지면 때문에 한숨을 푹푹쉬던 언론이 가세하여 가한 십자포화에도 한글윈도우즈95는 버젓이하루에도 수백개씩 팔려나가고 있다. 한글코드 제정 초창기부터 일관성 없는 정책으로 왔다갔다한 정부(정보통신부, 문화부, 공업진흥청 등이 포함된다)가 이 문제에 관해서는 남의 나라 일인 양 손놓고 있는 형국이다.

그렇다면 기존에 완성형에서 지원하지 못하던 글자까지 포함하여 11,172자나 되는 모든 현대문자를 표기할 수 있는 확장완성형이 도대체 무엇이 문제길래 정부와 언론이 나서서 떠들었던 것일까? 대표적으로 들 수 있는 것으로 첫째, 확장완성형은 한글 자모순서에 어긋난다는 것이다. 확장완성형코드는 기존의 2,350자 완성형의 틀에 8,922자의 글자를 끼워넣은 형태이므로 글자가 순서대로 배열되지 않게 된다. 따라서 문서작성기(word processor), 표편집기(spread sheet), 자료작성기(database)에서 차례짓기(sorting)을 하게 되면 가, 나, 다 순으로 되지 않고 뒤죽박죽이 되버린다. 둘째, 확장완성형은 조합형이 아니기 때문에 근본적으로 한글제작원리에 맞지 않고 고어를 표현할 수 없다. 셋째, 가장 중요한 문제로는 안그래도 복잡한 한글코드의 난립을 가중시킨다는 것이다. 지금도 정부표준은 완성형과 조합형, 그리고 유니코드까지 세 개나 존재하기 때문이라는 것 등이 주로 언급되었다.

그러나 사실은 확장완성형코드라는 것은 애초부터 존재하는 것이 아니었다. 윈도우즈95로 가면서 마이크로소프트는 글꼴의 코드는 유니코드를 사용할 것을 강력하게 권했던 것이다. 이는 운영체제를 윈도우즈NT로 통일시키려는 마이크로소프트의 전략과도 일치한다. 윈도우즈NT는 이전부터 유니코드를 채택해왔기 때문이다. 즉 한글 윈도우즈95 의 글꼴의 내부코드는 유니코드이고 글꼴은 조합하여 그려내는 방식을 택하고 있다. 글꼴에서는 이미 우리가 원하는 한글코드의 전형을 완전하게 구현하고 있는 것이다. 실제로 판매되는 한글윈도우즈95에는 exttextoutw라는 함수가 있다. 이 함수는 exttextoutw의 유니코드 버전이다. 이 함수를 사용해서 한글 유니코드를 주고 테스트를 하면 완성형이라는 한글윈도우즈95에서 유니코드에 의한 현대 한글 11,172자를 완벽하게 표현할 수 있게 된다. 그렇다면 확장완성형은 어디에 있고 완성형은 어디에 있는가? 한글윈도우즈95는 그 내부 디자인에서부터 유니코드만을 사용하고 있는 것이다. 결국 완성형이라는 절름발이 코드가 표준의 자리를 차지하고 있기 때문에 화면으로 나타날 때만 완성형으로 나타나는 것이다. 이를 두고도 세종대왕이 통곡한다니, 마이크로소프트가 조합형을 처리할 기술이 없느니 하면서 언론은 부화뇌동했고 정부는 수입규제같은 불온한(?) 발언을 해댔던 것이다. 하기야 모르면서는 목소리라도 커야 믿어줄 만하지 않은가.

조합형은 만능인가?

그래도 그 논쟁 가운데 얻은 것이 있다면 한글코드체계에 대한 문제에서 본질적인 부분을 짚어냈다는 것이다. 기존의 문서작성기에서는 완성형에서 표현할 수 없는 글자를 어떻게 표현할 것인가에 집착했는데, 이제는 글자표현 수준이 아닌 한글 정보 처리차원에서 코드 문제를 재검토하게 된 것이다. 사실 완성형을 벗어난 글자를 일반인들이 표현할 기회는 많지 않았다. 기껏해야 고어나 특수문자 등을 표현할 때 문제가 될 뿐이었다. PC가 사라지고 NC(network computer)시대가 도래한다는 한참을 앞서가는 주장은 잠시 접어두고서라도 이제는 인터넷 등으로 연결된 수많은 정보 창고 속에서 정확하게 원하는 정보의 처리와 가공이 핵심과제로 등장하고 있는 것이다.

그렇다면 조합형은 표준으로 채택될만큼 한글코드로 손색이 없는가? 평소에 마이크로소프트 워드의 맞춤법검사기(물론 영문이다)에 감탄해 왔는데 과연 그들의 검색기술이 우리보다 월등히 뛰어나서일까? 특히 조합형코드를 쓰고 있는 한글에서 맞춤법 검사를 한 뒤의 황당함과 비교해 보면 쉽게 알 수 있을 것이다. 조합형이 현대 한글을 완벽하게 표현할 수 있다고는 하지만 이 코드 체계역시 한글정보처리에서 부족한 점이 많아 별도의 처리과정을 거쳐야 한다. 예를 들자면,

1) 활용형으로 단어 찾기/바꾸기
(용언) '만들다'의 활용형 찾아라 → 만드니까, 만들면, 만들어도, 만드시오, 만들자면...

2) 형태소 단위로 단어 찾기/바꾸기
(어미) '나다니까'를 찾아서 '나다며'로 바꿔라 → 먹는다며(먹는다니까), 좋아한다니까(좋아한다며)...
(과거) '었'을 (미래) '겠'으로 바꿔라 → 먹겠다고(먹었다고), 예쁘겠는데(예뻤는데)...

3) 음절이 아닌 음소 단위의 역방향 정렬

4) 어떤 음절에서 기준이 되는 음소로 정렬

이와 같은 것을 처리하기 위해서는 음소분리과정을 거쳐야 하는데, 음소분리과정은 한글정보처리의 핵심인 형태소분석을 하기 위해서이다. 형태소 분석을 해야만 맞춤법검사가 가능하고, 형태소 분석이 얼마나 정확한 가에 따라 맞춤법 검사기의 성능이 좌우되기 때문이다. 결과적으로 조합형으로도 완벽한 맞춤법 검사와 차례짓기는 불가능하다는 결론이다. 한글 창제원리에 따라 구현했다는 조합형마저 앞으로의 검퓨팅 환경에 적합한 코드가 아니라면 도대체 컴퓨터에서 한글을 어떻게 표현하길래 문제가 생기는 것일까? 원인은 당연하게도 컴퓨터가 우리나라에서 만들어진 것이 아니라는데 있다.

영어권 문자에서의 기본적인 문자열 검색은 1바이트 단위로 이루어진다. 또한 기존의 문자열 검색방법은 ASCII코드 체계만을 대상으로 하고 있다. 그러나 한글을 비롯한 중국어, 일본어 등을 표현하기 위해서는 한 음절당 2바이트 이상이 필요하기 때문에 기존 알고리듬을 그대로 사용할 경우 밀려읽기가 발생하는 문제가 생긴다. 즉 2바이트 한글코드 체계를 사용한 문서상에서 문자열 검색이 이루어질 때 알고리듬에 의해 검색된 문자열이 실제 찾고자 하는 문자열과 맞지 않는 경우가 생길 수 있다. 이는 한글의 두 번째 바이트가 다음 문자의 첫 번째 바이트와 합쳐져서 엉뚱한 글자로 인식될 수 있기 때문에 발생하는 현상이다. 이런 이유로 한글의 두 번째 바이트 MSB(Most Significant Bit)가 1인 경우(완성형이건 조합형이건) 잘못된 문자열 검색이 일어날 수 있다는 것이다. 결국 모든 문제는 한글을 컴퓨터에서 구현하기 위해서는 2바이트가 필요하기 때문이라는 결정적인 원인은 여기서 발견하게 된다. 그리고 이는 16비트로 구성되어 있는 유니코드에서도 근본적으로 해결할 수 없는 문제이다. (쪽기사 참조)

가나다 순이 훈민정음 창제원리?

세종대왕이 한글을 만들었다는 사실은 대한민국 사람이라면 누구나 안다. 또 고등학교 과정을 정상적으로 이수한 학생이라면 누구나 훈민정음을 배운 기억이 있을 것이다. 아니 3호선 교대역 벽에 걸려있는 커다란 대리석 판(돈이 상당히 든 것으로 보이는데)에 새겨진 훈민정음을 무심코라도 보았다면 알고는 있을 것이다. 그러나 그것은 봉건군주가 불쌍한 백성을 위해 몸소 지어내리는 것이라고 뽐내는 것(사실 세종대왕 존경하기를 술값 떨어졌을 때 밖에는 안하는 필자로서는 이 정도 표현으로도 격식을 차린 셈이다) 외에 아무 것도 아니다. 실제로 우리가 기억하고 있는 훈민정음은 세조 때 편찬된 월인석보 첫머리에 실린 훈민정음예의의 언해본(한글판)에 불과하다. 훈민정음의 창제원리에 관한 설명은 일제시대 안동에서 발견되어 지금은 간송박물관에 보관되어 있는 훈민정음 해례본에 서술되어 있다. 한글자모를 창살을 본떠 만들었다느니 하는 식민사학자들의 이론이 널리 통용되고 있던 시절에 자음은 사람의 발음기관을 상형했고, 모음은 천지인 삼재(三才)를 기초로 만들어졌다는 사실이 그제서야 밝혀진 것이다. 그 결과 훈민정음의 과학성은 의심할 수 없는 사실로서 우리 민족이 세계에 자랑할 수 있는 역사적 산물의 위치를 차지하게 된다.

그러나 누구나 알고 있는 이런 사실과 컴퓨터에서 한글을 구현하는 것과 무슨 관계가 있는 것일까? 문제는 훈민정음을 만들 당시 자음과 모음 등 각각의 음운을 만들어내는 과정까지는 체계적이고 과학적이지만 그 음운을 결합하여 음절을 만들어내는 과정에서 결정적인 실수를 하였던 것이다. 즉, 초성, 중성, 종성을 결합하여 하나의 완성된 체계(한 글자)를 만들어 낸다는 것은 성리학적 사고에 젖어 있는 중세 철학자들의 형이상학적 한계였던 것이다. 설사 우리말이 그러한 음운체계를 지니고 있더라도 소리글자인 한글을 문자로 표현할 때 근본적으로 획의 개념을 가지고 있는 중국글자의 틀을 벗어나지 못한 한계는 인정해야 한다. 즉 자음 밑에 모음이 오고 그 밑에 자음이 오는 것(부서법)은 아무런 과학적 근거가 없는 것이다.

완전히 소리글자의 특성도 아니고 완전히 뜻글자의 특성도 아닌 음절이라는 불완전한 개념으로 인해 형태소 중심으로 운용되어야 할 글자체계가 엉망진창이 되어 버린 것이다. 위에서 언급한 맞춤법 검사의 핵심인 음소분리과정도 현재의 한글 체계로 구성된 한글코드로는 사실상 완벽하게 하기란 불가능하다. 훈민정음의 창제원리로 돌아간다면 한글을 1바이트의 음운체계로 고치는 방법만이 해결을 가능하게 할 것이다. 그리고 초중종성의 체계를 벗어나 음운별로 배열하려는 시도는 과거에 외솔 최현배를 중심으로 연구되고 준비된 바 있다. 예를 들면 '서울대학교'를 'ㅅㅓㅇㅜㄹㄷㅐㅎㅏㄱㄱㅛ'와 같은 방식으로 표기하는 것이다. 언젠가 본 병원의 환자복에서도 이처럼 표기된 것을 본 기억이 난다. 초성, 중성, 종성의 구분없이 음운별로 배당하게 되면 어림잡아 100여개의 코드면 고어를 포함하더라도 충분하게 모든 우리말을 표현할 수 있게 되는 것이다. 이렇게 되면 이미 없어진 음운인 초성의 'ㅇ'을 중복되게 표기할 필요가 없어짐을 비롯해 한글 맞춤법이 획기적으로 개선되는 이점이 있다. 음소적 원리와 형태음소적 원리의 갈등으로 특징 지워지는 그 동안의 한글 맞춤법 논쟁에 관해서는 본고사 필독서(?)인 국어작문(서울대학교 출판부)을 참조하기 바란다. 또한 완성형과 조합형의 단점을 극복할뿐더러 직결식 코드의 단점인 파일의 코드를 대폭 줄이고도 모든 기능을 갖출 수 있게 된다. 한글창제원리를 굳이 훼손시켜 가면서 이렇게까지 할 필요가 있냐고 탓할 지도 모른다. 그러나 우리가 당연하게 기억하고 있는 자음의 명칭과 순서(가, 나, 다... 기역, 니은, 디귿...)조차도 훈민정음에서 정해져 있지 않아 중종 때 당시로서는 역관(譯官)의 신분에 불과한 최세진이 그 만의 노력과 정성을 담은 훈몽자회에서 정한 것을 따른 것임을 생각할 때 한글의 창제원리 운운하기보다는, 한글을 얼마나 과학적이고 체계적으로 운용할 것인가가 현재에 남겨진 과제일 것이다. 광고에서 무심코 보이는 컴퓨터를 들고있는 세종대왕은 이에 대해 어떻게 생각하실까?

<쪽기사>

한글코드의 모든 것

한글문서는 한자, 한글, 영문자, 숫자 및 다양한 특수문자로 구성되어 있다. 따라서 한글 문서를 처리하기 위해서는 문서 내에 사용되는 모든 문자를 포함하는 코드가 필요해진다. 이를 위해 1982년 과학기술처에서 한글표준부호계(KSC5601)를 제정, 공포한 바 있다. 그러나 그 이전부터 컴퓨터 제작업체에 따라 서로 다른 코드를 사용해 왔기 때문에 결과적으로 한글 코드는 N바이트코드, 3바이트코드, 2바이트 완성형코드, 2바이트 조합형 코드 그리고 최근의 유니코드 등 다양한 체계가 존재하게 되었다. 과학기술처 표준연구소는 이 문제를 해결하기 위해 KSC5601부호계를 1987년과 1989년에 걸쳐 개정했지만, 사용자 및 업계의 완전한 동의를 구하지 못해 1992년에 다시 개정한 바 있다. 한글코드가 업계에 따라 다르고 또한 소프트웨어에 따라 달리 채택됨에 따라 발생하는 문제로는 한글코드의 변환문제와 소프트웨어의 호환성 문제, 그리고 각종 문서 및 정보 교환의 불편함에 따른 정보사회로의 발전 지연 등을 들 수 있다.

KS완성형(KSC5601-1987)

1987년 정부에서 채택한 정부 표준안이다. 구현원리는 너무나 간단하다 못해 유치하다. 즉 '가'부터 시작해서 많이 쓰인다고 생각하는 글자는 코드화하고 그렇지 않은 글자는 빼버리는 식으로 2,530자를 순서대로 코드를 부여한 방식이다. 완성형코드는 655,536가지의 글자를 표현할 수 있지만 여기에 한자와 특수부호를 같이 부여하다 보니 한글은 자주 쓰이는 2,530자만 고유번호를 부여받고 만 것이다. 따라서 한글로는 가능하지만 컴퓨터로는 표현할 수 없는 글자가 나타나게 된다. 편의주의적 발상인데다 조합형이 함께 존재하는 상태에서 독단적으로 채택되어 이후로도 말썽이 계속되었다. 그러나 정부표준안이므로 국가전산망이나 마이크로소프트를 비롯한 업계에서 이를 전격적으로 수용하였고 완성형은 급속하게 국내 표준으로 자리잡게 된다. 당연하게도 대한의학협회 데이터베이스도 완성형으로 구축되어 있다. 일반 PC환경뿐만 아니라 전자출판에서 많이 쓰는 매킨토시의 시스템이나 중대형 컴퓨터의 운영체제인 유닉스에서도 완성형코드가 채택되었다.

KSSM삼보조합형(KSC5601-1992)

세이코엡슨의 프린터를 수입하여 판매하던 삼보컴퓨터가 프린터 코드의 한글화를 위해 만들어낸 한글코드이다. 자모결합에 의해 한 음절을 완성하는 식으로 초성에 5비트, 중성에 5비트, 종성에 5비트를 대응시킨 방식이다. 모든 글자를 다 표기할 수 있고 한글의 원리와도 잘 맞는다는 이유로 학계와 사용자들로부터 환영을 받았다. 그러나 컴퓨터들이 8비트 단위로 정보를 다루는 원칙을 지키지 못하기 때문에 한글을 위해서는 별도의 프로그램을 같이 쓰거나 기존의 프로그램을 수정해야만 하는 문제가 있다. 이미 완성형이 정부표준으로 굳어지고 업계도 이를 따르는 상황에서 차츰 관심이 멀어지다가 윈도우즈3.0의 한글화과정에서 불거진 코드논쟁에서 사용자들의 지원을 받아 92년에 2차 표준안으로 확정이 되었다. 이후로도 정부와 대기업에서는 완성형, 사용자와 일부 업체에서는 완성형과 함께 조합형을 함께 사용해 왔다.

유니코드(ISO-10646/KSC-5700)

국제표준화기구가 확정한 다문자코드체계이다. 95년말 국가표준기관인 공업진흥청이 국가표준코드로 지정하였다. 아스키 체계를 탈피하여 16비트, 즉 2바이트로 구성되어 한글을 비롯한 세계의 모든 나라 문자들이 각각의 코드값을 갖고 배열되어 있으며 이에 따르면 현대 한글 11,172자도 모두 표현할 수 있다고 한다. 이미 마이크로소프트의 윈도우즈NT에서도 채택한 바 있으며 궁극적으로 모든 코드를 이 체계로 통일시킬 계획이다. 지난해 12월 6일 공업진흥청이 새로운 국가 표준으로 ▲옛글(고어)의 구현을 위한 한글 자모음 2백40자와 ▲현대 한글로 가능한 조합 11,172자를 고시함으로써 다소 잦아든 상태이다.

전세계 컴퓨터 관련 14개 대기업이 참여한 유니코드컨소시엄의 합의와 국제표준화기구의 결정에 맞춰 공진청이 정한 이 표준은, 그러나 기존 KS완성형으로 만든 데이터와 호환이 안된다는 문제를 안고 있다. 이를 변화하거나 다시 만드는 대규모의 사회적 낭비가 불가피하게 된 것이다.

직결식코드(N바이트코드)

1바이트에 한글 자모를 하나씩 대응시켜 초성, 중성, 종성이 다 있는 , 즉 받침이 있는 글자는 24비트의 길이를 가지고, 받침이 없는 글자는 16비트의 길이를 가지게 하는 방식이다. 이 방식은 기본적으로 소리글자 26자의 알파벳을 각각 1바이트에 대응시키는 영문코드와 같은 방식이다. 그러나 이 방식을 채택한 한글코드의 경우 전체 파일의 크기가 커지는 단점이 있다. 과거 공병우박사가 매킨토시에서 사용할 수 있도록 개발하여 보급한 바 있고, 최근에는 노성우씨 등도 새로운 코드를 제안해 보급하고 있다. 물론 코드와 글자꼴은 별개의 것으로 취급되어야 하지만 직결식 한글코드를 쓰게 되면 한글의 글자 모양은 정사각형이나 직사각형 틀에 맞추고 있는 기존의 인쇄문자의 모양에서 어긋난다. <샘이 깊은 물>이라는 잡지의 제목도안에서 따온 글꼴이 바로 샘물체라는 사실은 직결식코드가 생각보다 가까이에 있는 좋은 예가 될 것이다.