정 인 상 (충북대학교 국어국문학과 교수)
  이제, 한글의 개념과 관련하여 그 범위와 코드 체계를 생각해 보면, 이전의 격렬했던 논쟁에서 보았듯이 결코 간단한 문제가 아니다. 불과 몇 년 전만 하더라도 한글 문제는 컴퓨터마다 서로 다른 코드 체계를 가지고 있어서 자료의 호환성 여부로 큰 어려움과 불편이 따랐으나, 이제는 컴퓨터에서의 한글 코드 체계가 거의 통일되어 있어 여간 다행스러운 일이 아니다. 먼저, 아직도 사용되고 있는 한글 코드의 두 형태인 완성형 한글과 조합형 한글의 장단점을 간단히 짚어 보기로 한다.

  완성형으로 되어 있는 현행 한글 코드는 한글의 개념에서 보면 결코 납득하기 어려운 방식이다. 완성형 한글은 현대국어에서 사용되고 있는 2,350자에 한자 4,888자, 특수문자 986자 합계 8,224글자로 구성된 것인데, 한글 자모의 정상적인 결합에 의한 모든 한글 자형들을 수용하고 있지 않다는 결함을 지닌다. 이러한 글자 수의 제약은 있는 글자만 사용하고 없는 글자는 사용하지 않으면 그만이지만, 나중에 코드의 개선이나 확장에 심각한 문제가 따른다는 점도 또 다른 결함이라고 할 수 있다.

  완성형이란 이름은 자모가 결합된 한글 하나하나를 독립된 글자로서 코드화하고 한글의 모양도 독립적으로 처리하였다는 뜻인데, 공교롭게도 이름 그대로 ‘완성형’이어서 이 코드 체계는 어떠한 개선이나 변경이 가해질 수 없음을 전제로 한, 그야말로 ‘완성된’ 체계인 것이다. 원래는 국제적인 정보교환을 위한 글자 수의 제약에 의하여 한글의 글자 수가 이렇게 줄어든 것으로, 실용적인 면에서는 전혀 문제가 없는 것처럼 이야기되기도 하지만 국어학적인 면에서는 실용적인 문제가 없는 것도 아니다.

  완성형 한글은 현행 맞춤법과 현행 국어 어휘들을 그 기준으로 한 것인데, 이 맞춤법이나 국어 어휘라는 것은 시간이 흐르면 바뀌는 것인 만큼 앞으로 맞춤법이 바뀌어서 새로운 글자가 사용되게 되거나, 새로운 글자로 표시되어야 하는 새 어휘가 생기게 된다면 그때에 그 새로운 글자를 사용하기 위해서는 또 다시 한글 코드를 바꾸어야 하거나 아니면 새 글자를 배열 뒤에 적당히 추가하여 한글 배열이 맞지 않는 한글 코드를 사용할 수밖에 없게 되는 것이다.

  예를 들어 요즈음 ‘겁이 난다’ 하는 경우에 ‘겁시 난다’ 라고 말하는 사람들이 있는가 하면, ‘깨끗이’라는 말을 ‘깨끄치’라고 발음하는 사람들이 많이 있는데, 만일 언젠가 이러한 발음들이 표준어로 규정된다면, 그 때는 이들을 문법적으로 표현하기 위하여 ‘겂’과 ‘끛’이라는 글자가 필요하지만 완성형에는 이러한 글자가 없으니, 표현할 방법이 없는 것이다. 그렇다고 이러한 글자들을 한글 배열에 맞도록 추가할 수도 없는 것이다.
 ‘겁’과 ‘것’ 사이에 ‘겂’이 들어 가야 하는데 그 사이에는 이미 빈 칸이 없으며, ‘끙’과 ‘끝’ 사이에 ‘끛’이 들어가야 하는데 이 사이에도 빈 칸이 없는 것이다. 한 글자라도 중간에 넣게 되면 다음 글자부터 순차적으로 코드값이 바뀌게 되어 전체적으로 다른 코드 체계가 되는데, 어느 순간에 한글 코드를 바꾼다는 것은 지금까지 축적된 수많은 자료들을 코드 변환 없이 그대로 이용할 수 없게 만들어서, 그 불편을 감당하기 어려우며, 또 한글 배열이 맞지 않는 코드 체계를 사용하면 정보 교환에서의 불편함을 역시 감당하기 어려운 것이다. 따라서 한글의 코드 체계는 정말 장기적인 안목에서 영구히 지속될 수 있는 가장 타당한 방식이 선정되어야만 한다는 것은 아무리 강조해도 지나치지 않다고 생각한다. 이러한 점에서 볼 때에 완성형 한글 방식은 국어 자료 처리를 위해서는 물론이거니와 우리의 일상적인 문자 생활과도 결코 조화되기 어려운 방식임을 지적하고자 한다. 그럼에도 불구하고 이러한 완성형 한글이 정부 표준 규격으로 인정되어 시행되고 있는 것은 우리의 문자 생활을 위해서는 매우 불행한 일이라고 아니할 수 없다. 더욱이 이러한 완성형 한글을 바탕으로 해서 개발된 한글 운영체계(도스)는 그 확산 추세에 비추어 볼 때 앞으로의 공과(功過)에 대하여 필자로서는 걱정이 앞선다.

  또한, 완성형 한글은 한글의 기본 자모인 자음이나 모음에 그 고유한 코드값이 부여되어 있지 않고 단지 음절 구성 글자에만 고유한 코드값이 주어져 있다는 결함도 있다. 한글은 실용적으로는 모아쓰기를 하고 있지만 그 본질적인 면에서는 음소문자이기 때문에 국어 자료의 전산 처리에 있어서 음소 단위의 처리가 보장되어야 할 필요가 있다. 물론 완성형이라고 해서 이러한 음소별 처리가 불가능한 것은 아니지만 그 처리 환경의 효율은 조합형보다 나을 수가 없을 것으로 생각된다. 예를 들어 모음이 ‘ㅘ’ 인 글자를 지정하려면, 완성형에서는 해당되는 모든 글자들을 목록으로 제시하여야만 하지만, 조합형에서는 ‘ㅘ’의 코드값을 지정함으로써 해당되는 모든 글자를 다루게 되는 것이다. 이러한 음소별 처리는 국어학이라는 전문적인 면에서만 필요한 것이 아니고 국어의 실제 사용의 측면에서도 흔히 필요하게 된다. 국어의 모든 어휘들이 반드시 온전한 글자로서만 구성되어 있는 것이 아니라 경우에 따라서는 중성 또는 받침만으로 구성되어 있거나, 중성 + 받침, 받침 + 글자 등의 구조로도 만들어져 있기 때문에 이러한 어휘들의 처리를 위해서는 자모별로 코드화가 이루어져야 하기 때문이다. 예를 들어 ‘간다, 온다, 운다……’ 등에서와 같이 ‘-ㄴ다’가 사용된 글자를 지정하고자 할 때 완성형과 조합형의 우열이 드러나게 되는 것이다.
1 2 3 4 5