새국어생활 제6권 제2호(1996년 여름)

【특집-21세기의 한글】

국어학에서 본 컴퓨터와 한글

정인상 / 충북대학교 국어국문학과 교수

Ⅰ

  한국 사람들은 입으로는 한국말을 하며, 눈으로는 한글을 읽고 쓴다. 컴퓨터를 이용하여 국어 정보 자료를 전산 처리함에 있어서 가장 우선적으로 해결되어야 할 문제는 컴퓨터에서 실현될 문자의 확립이며, 이러한 문자 가운데에서 한글 문자가 가장 큰 비중을 갖는다. 한국 사람들이 컴퓨터를 편리하게 사용하기 위해서는 컴퓨터에서의 한글 사용 환경이 보다 확대되고 그 입출력 방법도 더욱 편리하게 구성되어야 하는 것이다. 요즈음의 키보드에는 “한/영”, “한자” 키가 추가되어 있어서 한글과 영문을 번갈아 입력하려고 할 때는 “한/영” 키를, 한자를 입력하려고 할 때는 “한자” 키를 눌러 주면 된다. 이렇게 간단한 문제도 이전의 키보드에서는 개별 프로그램이 규정한 한글과 영문 전환 방법을 별도로 알고 있어야만 했던 것이다.
  한글을 사용하는 나라이지만, 컴퓨터를 사용하기 위해서는 아직도 한글보다 영어를 더 우선적으로 알아야 하는 것이 우리의 현실이다. 이것은 거의 대부분의 경우 컴퓨터 명령어가 영문으로 되어 있기 때문인데, 앞으로는 이러한 명령어가 한글로 표현되도록 해야 할 것으로 생각된다. 컴퓨터를 조작하기 위해서 우리의 언어가 아닌 영어를 반드시 알아야만 한다는 제약이 영구히 지속되어서는 안 될 것이다. 영원히 해결되지 않을 문제가 아니라 언젠가는 해결되어야 할 문제라면 영문 명령어의 한글화와 그 사용이 이제는 더 이상 지연되어서는 안 될 것으로 생각한다. 국어 정보 처리와 관련된 컴퓨터 사용은 이제는 더 이상 영어에 익숙해 있는 일부 전문인들의 독점물이 되어서는 안 되며 한글을 아는 한국 사람이라면 누구나 그 이용이 가능하도록 되어야 한다는 생각이다.
  그리고 이처럼 컴퓨터 명령어를 한글화하는 작업에 있어서 그 적절한 어휘의 선정을 위하여는 반드시 국어학자들의 조언이나 검토가 있어야만 할 것으로 생각한다. 이러한 명령어의 한글화 작업에 부응하여 키보드의 문자 표시도 현행 키보드처럼 영문 표시가 주가 되고 한글 표시가 종이 되는 것이 아니라 국내용으로는 어디까지나 한글 표시가 주가 되고 영문 표시가 종이 되는 방식으로 개선되어야 할 것으로 생각한다. 현행 컴퓨터 체계는 모든 것이 영문 위주로만 되어 있어 한글은 덤으로 겨우 들어 있는 느낌을 금할 수 없는데, 이것은 우리 나라의 국적있는 컴퓨터라고는 도무지 생각되지 않는 것이다.

  이제, 한글의 개념과 관련하여 그 범위와 코드 체계를 생각해 보면, 이전의 격렬했던 논쟁에서 보았듯이 결코 간단한 문제가 아니다. 불과 몇 년 전만 하더라도 한글 문제는 컴퓨터마다 서로 다른 코드 체계를 가지고 있어서 자료의 호환성 여부로 큰 어려움과 불편이 따랐으나, 이제는 컴퓨터에서의 한글 코드 체계가 거의 통일되어 있어 여간 다행스러운 일이 아니다. 먼저, 아직도 사용되고 있는 한글 코드의 두 형태인 완성형 한글과 조합형 한글의 장단점을 간단히 짚어 보기로 한다.
  완성형으로 되어 있는 현행 한글 코드는 한글의 개념에서 보면 결코 납득하기 어려운 방식이다. 완성형 한글은 현대국어에서 사용되고 있는 2,350자에 한자 4,888자, 특수문자 986자 합계 8,224글자로 구성된 것인데, 한글 자모의 정상적인 결합에 의한 모든 한글 자형들을 수용하고 있지 않다는 결함을 지닌다. 이러한 글자 수의 제약은 있는 글자만 사용하고 없는 글자는 사용하지 않으면 그만이지만, 나중에 코드의 개선이나 확장에 심각한 문제가 따른다는 점도 또다른 결함이라고 할 수 있다. 완성형이란 이름은 자모가 결합된 한글 하나하나를 독립된 글자로서 코드화하고 한글의 모양도 독립적으로 처리하였다는 뜻인데, 공교롭게도 이름 그대로 ‘완성형’이어서 이 코드 체계는 어떠한 개선이나 변경이 가해질 수 없음을 전제로 한, 그야말로 ‘완성된’ 체계인 것이다. 원래는 국제적인 정보교환을 위한 글자 수의 제약에 의하여 한글의 글자 수가 이렇게 줄어 든 것으로, 실용적인 면에서는 전혀 문제가 없는 것처럼 이야기되기도 하지만 국어학적인 입장에서는 실용적인 문제가 없는 것도 아니다.
  완성형 한글은 현행 맞춤법과 현행 국어 어휘들을 그 기준으로 한 것인데, 이 맞춤법이나 국어 어휘라는 것은 시간이 흐르면 바뀌는 것인 만큼 앞으로 맞춤법이 바뀌어서 새로운 글자가 사용되게 되거나, 새로운 글자로 표시되어야 하는 새 어휘가 생기게 된다면 그때에 그 새로운 글자를 사용하기 위해서는 또다시 한글 코드를 바꾸어야 하거나 아니면 새 글자를 배열 뒤에 적당히 추가하여 한글 배열이 맞지 않는 한글 코드를 사용할 수밖에 없게 되는 것이다.
  예를 들어 요즈음 ‘겁이 난다’ 하는 경우에 ‘겁시 난다’ 라고 말하는 사람들이 있는가 하면, ‘깨끗이’라는 말을 ‘깨끄치’라고 발음하는 사람들이 많이 있는데, 만일 언젠가 이러한 발음들이 표준어로 규정된다면, 그때는 이들을 문법적으로 표현하기 위하여 ‘겂’과 ‘끛’이라는 글자가 필요하지만 완성형에는 이러한 글자가 없으니, 표현할 방법이 없는 것이다. 그렇다고 이러한 글자들을 한글 배열에 맞도록 추가할 수도 없는 것이다. ‘겁’과 ‘것’ 사이에 ‘겂’이 들어 가야 하는데 그 사이에는 이미 빈 칸이 없으며, ‘끙’과 ‘끝’ 사이에 ‘끛’이 들어가야 하는데 이 사이에도 빈 칸이 없는 것이다. 한 글자라도 중간에 넣게 되면 다음 글자부터 순차적으로 코드값이 바뀌게 되어 전체적으로 다른 코드 체계가 되는데, 어느 순간에 한글 코드를 바꾼다는 것은 지금까지 축적된 수많은 자료들을 코드 변환 없이 그대로 이용할 수 없게 만들어서, 그 불편을 감당하기 어려우며, 또 한글 배열이 맞지 않는 코드 체계를 사용하면 정보 교환에서의 불편함을 역시 감당하기 어려운 것이다. 따라서 한글의 코드 체계는 정말 장기적인 안목에서 영구히 지속될 수 있는 가장 타당한 방식이 선정되어야만 한다는 것은 아무리 강조해도 지나치지 않다고 생각한다. 이러한 점에서 볼 때에 완성형 한글 방식은 국어 자료 처리를 위해서는 물론이거니와 우리의 일상적인 문자 생활과도 결코 조화되기 어려운 방식임을 지적하고자 한다. 그럼에도 불구하고 이러한 완성형 한글이 정부 표준 규격으로 인정되어 시행되고 있는 것은 우리의 문자 생활을 위해서는 매우 불행한 일이라고 아니할 수 없다. 더욱이 이러한 완성형 한글을 바탕으로 해서 개발된 한글 도스는 그 확산 추세에 비추어 볼 때 앞으로의 공과(功過)에 대하여 필자로서는 걱정이 앞선다.
  또한, 완성형 한글은 한글의 기본 자모인 자음이나 모음에 그 고유한 코드값이 부여되어 있지 않고 단지 음절 구성 글자에만 고유한 코드값이 주어져 있다는 결함도 있다. 한글은 실용적으로는 모아쓰기를 하고 있지만 그 본질적인 면에서는 음소문자이기 때문에 국어 자료의 전산 처리에 있어서 음소 단위의 처리가 보장되어야 할 필요가 있다. 물론 완성형이라고 해서 이러한 음소별 처리가 불가능한 것은 아니지만 그 처리 환경의 효율은 조합형보다 나을 수가 없을 것으로 생각된다. 예를 들어 모음이 ‘ㅘ’ 인 글자를 지정하려면, 완성형에서는 해당되는 모든 글자들을 목록으로 제시하여야만 하지만, 조합형에서는 ‘ㅘ’의 코드값을 지정함으로써 해당되는 모든 글자를 다루게 되는 것이다. 이러한 음소별 처리는 국어학이라는 전문적인 입장에서만 필요한 것이 아니고 국어의 실제 사용의 측면에서도 흔히 필요하게 된다. 국어의 모든 어휘들이 반드시 온전한 글자로서만 구성되어 있는 것이 아니라 경우에 따라서는 중성 또는 받침만으로 구성되어 있거나, 중성 + 받침, 받침 + 글자 등의 구조로도 만들어져 있기 때문에 이러한 어휘들의 처리를 위해서는 자모별로 코드화가 이루어져야 하기 때문이다. 예를 들어 ‘간다, 온다, 운다……’ 등에서와 같이 ‘-ㄴ다’가 사용된 글자를 지정하고자 할 때 완성형과 조합형의 우열이 드러나게 되는 것이다.

III

  조합형 한글이 완성형 한글보다는 우수하다고 하더라도 국어학적 입장에서 볼 때는 몇 가지 원리적인 문제가 야기된다. 국어학에서 생각하는 한글의 개념은 훈민정음(訓民正音)이 창제된 후로 문헌에 사용된 모든 한글을 포함하기 때문에, 현대의 일상적인 한글보다 그 범위가 넓으며, 그만큼 한글 문자의 수효가 급격히 늘어나게 된다. 여기에서 이들 옛한글들을 포함한 모든 한글을 입출력하려고 할 때 컴퓨터에서의 한글에는 다음과 같은 문제가 야기된다.
  첫째는 한글의 수효에 관한 문제이다. 흔히 한글 코드 문제로 인식되어온 완성형 한글과 조합형 한글의 본질도 이러한 한글의 수효에 대한 문제에 지나지 않는다. 완성형 한글은 현행 한글의 사용 빈도수를 근거하여 가려 뽑은 2,350자의 한글만을 사용하는 방식이며, 조합형 한글은 현행 맞춤법에서 규정된 초성, 중성, 종성의 결합에 의한 11,172자의 한글 전부를 사용하는 방식이기 때문이다. 국어학적 입장에서는 말할 것도 없고 일상적인 면에서도 글자의 수효가 풍부한 조합형이 우수하다는 것은 이미 앞에서 말한 바 있다. 한글 문제는 조합형 한글 11,172자를 그 출발점으로 해서 그 위에 더 보완될 점이 있는지를 따져야 할 것이며, 완성형 2,350자를 놓고서 보완점을 찾는 것은 무의미한 일로 생각된다.
  이제 국어학적 입장에서의 한글의 수효는 현행 맞춤법에 규정된 11,172자를 넘어서, 고문헌에 사용된 옛글자들과 국어학적 분석에 의한 어간 형태의 옛글자들을 포함하여야 하는데, 이 글자들을 조합형 방식으로 실현하려면 초성, 중성, 종성의 자모 수효가 상당히 늘어나게 된다. 필자가 이전에 조사한 바에 의하면 초성 51가지, 중성 27가지, 받침 54가지가 되는 것을 확인한 바 있다. 이외에도 한글의 수효는 더 늘어날 것이다. 방언 형태를 분석하다 보면 현행 맞춤법에서 벗어난 글자가 있으며, 개화기 문헌에도 현행 맞춤법에서 벗어난 한글 형태가 상당수 있기 때문이다. 이들 자모들의 숫자는 이미 현행 2바이트 조합형 코드 구조가 수용할 수 있는 초성, 중성, 받침 별 32개의 범위를 넘어선 것이므로 자모별 조합형은 기대할 수가 없다. 따라서 현행 조합형 한글 바탕 위에 옛글자는 한자와 같은 방식의 완성형을 가미하여 사용할 수 밖에 없을 것으로 생각된다.
  둘째로는 한글 코드 체계의 문제이다. 이 문제는 앞에서 이야기한 완성형과 조합형의 문제가 아니라, 조합형 가운데에서 코드화할 자모 단위와 그 배열 순서의 문제이다.
  먼저, 자모 단위에 있어서 ‘ㅘ, ㅝ, ㅢ ……’와 같은 겹모음이나 ‘ㄶ, ㄺ……’ 등과 같은 겹받침들을 하나의 단위로 할 것인가 두 개의 단위로 할 것인가 하는 문제가 있다. 한글의 기본 문자 수를 흔히 자음 14자, 모음 10자 합계 24자라고 하는 입장에서는, 옛글자를 포함하더라도 자음 17자(순경음 제외), 모음 11자 합계 28자밖에 안 되므로 이들 문자에만 코드값을 부여하면 될 것이다. 즉 기본 문자가 아닌 모든 겹자모들을 모두 단자모 형식으로 풀어서 코드화하면 되는 것이지만 이것은 컴퓨터의 효율성이나 우리 문자 생활의 실용적인 측면에서는 수용하기 어려운 것으로 생각된다. 이전에 ‘N 바이트 한글’이라는 이름의 코드 체계에서 이러한 방법 일부가 사용되다가 사라지게 된 것도 그 비효율성 때문이었다. 따라서 현행 2바이트 조합형의 방식과 같이 한글 자형의 초성, 중성, 받침을 각각 한 단위로 하여 그 고유한 코드값을 할당하는 방식은 현실적으로 수용할 수밖에 없는 방식이다. 다만, 코드값이 할당되어야 하는 초성, 중성, 받침의 종류에 있어서는 현행 2바이트 조합형보다 개선될 점이 있는 것으로 생각된다.
  현행 2바이트 조합형은 초성 19자, 중성 21자, 받침 27자로서 이들의 산술적인 결합에 의한 글자 수효는 모두 11,172자가 된다. 한글의 자모들이 이렇게 선정된 것은 물론 현행 맞춤법에 의거한 것이지만 컴퓨터에서 한글을 실현하는 기준은 한글 맞춤법과는 무관하게 컴퓨터가 허용하는 범위에서 우리의 문자 생활 전반의 실용성과 효율성에 입각하여 결정되어야 하는 것이다. 컴퓨터는 결코 한글 맞춤법의 부속 장치가 아니기 때문이다. (물론 한글 맞춤법도 컴퓨터의 부속 장치가 아니다.)

  2바이트 코드 체계에서는 초성, 중성, 받침별로 각각 32개까지의 코드화가 가능하지만, 컴퓨터 운영체제로 MS-DOS를 사용하는 경우에는 MS-DOS 자체의 제약에 의하여 초성 32개, 중성 24개, 받침 31개까지만 코드로 사용할 수 있다. 여기에서 내용이 없는 표지(FILL CODE)를 하나씩 할당하고 나면 실제로 내용이 있는 초성, 중성, 받침의 구별 가능한 수효는 각각 31개, 23개, 30개가 된다. 이 범위 안에서 실제로 수용할 한글의 자모를 선정하고 배열하여야 하는데 이 모든 영역을 한글만으로 사용하는 것은 한자(漢字)나 특수문자 등의 수용을 고려할 때 허용되기 어렵다. 따라서 한글의 영역은 한자를 수용하는 그만큼 줄어들 수밖에 없다.
  한자가 정확하게 몇 자가 필요할 것인가에 대해서는 뭐라고 분명하게 말하기 어렵다. 단지, 현행 정부 표준 규격의 한자가 4,888자인 사정과, 아래아 한글의 한자가 제1 수준 한자 4,888자와 제2 수준 한자 10,880자 합계 15,768자인 사정을 말할 수 있을 정도이다. 경험적으로 한자를 섞어서 비교적 전문적인 글을 쓰는 경우에도 정부 표준 규격의 4,888자 정도이면 크게 부족하다는 느낌은 들지 않는다. 따라서 한자는 기본적으로 이 정도가 수용되면 무난할 것으로 생각된다. 2바이트 완성형 방식으로 제1 바이트를 기준으로 하여 제2 바이트를 아스키 64 (@)부터 시작하게 할 때 4,966자가 수용될 수 있는 계산이 나온다. 여기에 특수문자와 사용자 정의 문자 1,000여 자를 배려한다면, 최종적으로 초성 23개, 중성 23개, 받침 30개를 수용하게 된다. 이 수효는 현행 조합형 한글의 수효보다 초성에서 4개, 중성에서 2개, 받침에서 3개의 자모가 더 많은 것이다.
  이처럼 컴퓨터의 코드 구조상 초성, 중성, 받침의 종류는 각각 몇 개씩이라도 더 확장될 여지가 있는 것으로 생각된다. 그리고 이렇게 추가되는 영역은 우리의 옛글자를 실현하기 위한 방편으로 마땅히 고어 자모가 추가되어야 할 것으로 생각한다. 그리고 이러한 고어 자모의 선정에 있어서는 고문헌에서의 출현 빈도수와 옛 어휘들의 기본형 표시를 기준으로 삼을 수 있다. 그리하여 현행 한글 자모(字母) 이외에 고어 자모를 더 추가한다면 초성에는 ‘ㅸ, ㅿ, ㅺ, ㅼ’ 의 4가지를 추가하고, 중성에는 ‘ㆍ, ㆎ’ 2가지를, 받침에는 ‘ㅭ, ㅸ, ㅿ’ 3가지를 추가하는 것이 가장 바람직할 것으로 생각한다. 그리고 추가되는 고어 자모의 배열 순서는 현행 고어 사전들의 배열 순서가 타당하다고 생각되지만 중성자의 경우는 ㆍ를 ㅏ보다 앞서서 배열하였으면 한다.
  한편, FILL 코드는 그 배열의 순서가 현행의 순서와는 다르게 수정되어야 할 것으로 생각된다. 즉 기존의 코드 체계에서는 초성, 중성, 받침의 모든 FILL 코드가 해당 자모보다 앞에 배열되어 있으나 이렇게 되면 한글 자모 관계의 순서 처리가 올바르지 않게 된다. 실제로 ‘ㄱㄴㄷㄹㅁㅂㅅㅇㅈㅊㅋㅌㅍㅎㅏㅑㅓㅕㅗㅛㅜㅠㅡㅣ’를 기존의 코드 체계에 따른 배열 처리를 한 결과는 ‘ㅏㅑㅓㅕㅗㅛㅜㅠㅡㅣ ㄱㄴㄷㄹㅁㅂㅅㅇㅈㅊㅋㅌㅍㅎ’처럼 되어 우리의 일상적인 사용 순서와는 맞지 않게 되어 있다. 이것을 수정하기 위해서 초성의 FILL 코드는 ㄱ 의 앞이 아니라 ㅎ 의 뒤에 배열되도록 해야 한다. 이렇게 하면 ‘’과 같은 글자는 초성이 없다고 해서 ‘가’ 보다 앞에 오는 것이 아니라 ‘히’ 보다 뒤에 오도록 되는 것이다. 중성과 받침의 FILL 코드는 기존과 같이 해당 자모의 앞에 배열시킨다.
  셋째로는 한글 실현 방식의 문제이다. 한글 실현 방식에는 먼저 하드웨어 방식과 소프트웨어 방식으로 구별할 수 있는데, 하드웨어 방식은 컴퓨터에 하드웨어 장치를 추가로 설치하여야 하는 만큼, 개인 사이에 컴퓨터의 동일한 한글 환경을 보장하기 어려울 뿐 아니라, 하드웨어 개량판이 나올 때마다 새로운 장치를 교체해야 하는 번거로움도 감당하기 쉽지 않다. 요즘은 컴퓨터의 메모리 용량도 넉넉한 만큼 소프트웨어 한글을 사용하더라도 큰 불편은 없으리라 본다. 이러한 소프트웨어 한글 방식에는 한글 도스 방식, 프로그램 내장 방식, 램 상주 방식 등이 있는데, 한글 도스 방식은 현재 한글 MS DOS 6.2 가 사용되고 있으나 완성형 한글이기 때문에 국어학적으로는 실용적이지 못하다.
  프로그램 내장 방식은 개별적인 응용 프로그램(워드 프로세서, 통계 프로그램, 데이타 베이스, 통신 프로그램, 게임 프로그램, 백과사전 등의 문헌 CD 등등) 속에 한글 실현 기능이 들어 있어서 해당 프로그램을 사용함에 있어서 한글을 동시에 사용할 수 있는 방식이다. 한글 사용의 처음과 끝이 해당 프로그램 내에 국한된다면 상관없으나 해당 프로그램에서의 한글로 된 내용을 다른 프로그램에서 재사용할 필요가 있거나 그 역의 경우에는 호환성 여부가 문제가 된다. 해당 프로그램에서의 한글 코드와 재사용하려는 다른 프로그램에서의 한글 코드가 동일해야만 추출된 한글 내용을 바르게 이용할 수 있으며 그 역도 마찬가지이다. 이러한 내장 한글 방식의 응용 프로그램에서 한자(漢字)와 같은 특수한 문자들을 처리하기 위하여 독자적인 코드 체계를 채택한 경우는 자료의 호환성이 보장되지 않는 것이다.
  램(RAM) 상주 방식 한글은 한글을 실현시키는 프로그램을 메모리에 올려 놓고 한글을 사용하는 방식이다. 이에는 바이오스(BIOS) 지원 방식과 타임 인터럽트 지원 방식 등이 있는데 다른 프로그램, 특히 영문 소프트웨어를 그대로 사용할 때 문제가 발생하기도 한다.
  국어학에서 컴퓨터를 사용하는 동기를 보면, 문서를 작성하여 인쇄하는 워드프로세서 기능으로 이용하려는 동기와 자료를 입력해 놓고서 그 자료들을 검색하거나 색인화하려는 동기 두 가지로 크게 구별할 수 있다. 문서 작성용 워드 프로세서로는 아래아 한글 프로그램이 가장 널리 사용되고 있는데, 국어학에서 필요한 옛글자, 한자 등을 충분히 지원하는 점이 단연 두드러진다. 여기에서 단순히 문서 작성과 인쇄만을 위한 목적이라면 아래아 한글 프로그램으로 만족스러울 것이다. 그러나 아래아 한글에서만 제공하는 문자들은 앞에서 말한 프로그램 내장 방식의 문자 코드 체계이기 때문에 외부 프로그램에 의한 자료로서의 처리 방법이 봉쇄되어 있다. 여기에서 작성된 내용은 현대 한글과 제1 수준 한자 4,888자만이 다른 프로그램과 호환이 되는 것이다. 그러므로 컴퓨터에서의 한글 실현 방식은 옛글자와 한자 등을 포함하여 램 상주 방식으로 처리되어야만 자료 처리를 원만하게 할 수 있다는 것을 지적하고자 한다. 자료 처리를 위해서 컴퓨터를 사용하는 입장에서는 워드 프로세서는 자료 입력의 도구에 지나지 않는 것이다.

컴퓨터에서의 한글 코드 문제는 한자나 특수 문자 등과 관련되어 있기 때문에 한글 단독으로만 이야기할 수 없는 문제이다. 한글과 한자 이외에도 많은 문자가 필요하게 되지만 이들은 고정적인 코드를 부여하기 보다는 사용자 개개인의 특수성에 맡길 수밖에 없을 것으로 생각된다. 한글의 경우에도 고어 자형들이 약 1,000자 정도가 더 필요하며, 한자의 경우에도 그때그때의 상황에 따라 누락된 글자들이 더 필요하게 될 것이다. 또, 국어학의 입장에서는 구결이나 이두문자가 100여 자 정도 더 필요하다는 것도 지적되고 있다. 이외에도 각종 그래픽 도안 문자나 일본 문자, 희랍 문자, 영어 발음 기호 등등이 사용자의 특수성에 따라서 꼭 필요한 문자가 될 것이다. 이러한 문자들을 그 필요에 따라 사용 가능하게 하기 위해서는 사용자 정의 문자 영역을 어느 정도 확보해 두고 필요에 따라서 사용할 수밖에 없을 것으로 생각된다. 필자의 생각으로는 이러한 사용자 정의 문자 영역은 최소한 1,000자 정도는 되어야 할 것으로 보아 2바이트 완성형 방식으로 하면 1,146자가 수용될 수 있을 것으로 생각된다.
지금까지의 논의를 종합하면 한글은 현행 맞춤법의 한계를 벗어나서 모두 16,399글자를 수용하게 되며, 한자는 기본적으로 4,966자를 수용하게 된다. 뿐만 아니라 만일의 경우를 대비하여 1,146자의 사용자 정의 문자 영역을 마련하였기 때문에 한자 부족분이나 한글 코드로 처리되지 못하는 옛글자 등의 실현을 위하여 완성형 코드로 활용할 수 있다. 여기에서 한글 16,399자는 고어 자모를 일부 포함한 조합형이기 때문에, 고어에 관한 한 실제로는 사용되지 않는 글자가 상당히 들어 있다. 앞으로 정밀한 검토를 거쳐서 불필요한 옛글자 조합을 제외할 수 있게 된다면, 바꾸어 말하여 필요한 옛글자 목록이 완성된다면 이들을 현행 한글과 합하여 영구적인 완성형 방식의 코드 체계도 생각해 볼 수 있을 것이다. 이렇게 하면 코드 영역을 보다 효율적으로 사용하는 것이 되어서 한자의 수용 능력이 훨씬 늘어 나게 될 것이다. 컴퓨터에서의 한글 문제는 궁극적으로 현행 한글과 옛글자, 그리고 한자를 얼마나 많이 수용하는가 하는 문제이기 때문이다. 그러나 현재로서는 현행 조합형 한글을 약간 확장시키는 선에서만 논의를 하였는 바, 현행 조합형 코드 체계의 부족함을 보완하여 좀더 개선된 문자 코드 체계를 제시하면 다음과 같다.

<문자 코드의 개선안>
BIT	초 성		중 성			받 침
00000	128	ㄱ	0	×	0	0	FILL코드
00001	132	ㄲ	0	×	32	1	ㄱ
00010	136	ㅺ	0	FILL코드	64	2	ㄲ
00011	140	ㄴ	0	ㆍ	96	3	ㄱㅅ
00100	144	ㄷ	0	ㆎ	128	4	ㄴ
00101	148	ㄸ	0	ㅏ	160	5	ㄴㅈ
00110	152	ㅼ	0	ㅐ	192	6	ㄴㅎ
00111	156	ㄹ	0	ㅑ	224	7	ㄷ
01000	160	ㅁ	1	×	0	8	ㄹ
01001	164	ㅂ	1	×	32	9	ㄹㄱ
01010	168	ㅃ	1	ㅒ	64	10	ㄹㅁ
01011	172	ㅸ	1	ㅓ	96	11	ㄹㅂ
01100	176	ㅅ	1	ㅔ	128	12	ㄹㅅ
01101	180	ㅆ	1	ㅕ	160	13	ㄹㅌ
01110	184	ㅿ	1	ㅖ	192	14	ㄹㅍ
01111	188	ㅇ	1	ㅗ	224	15	ㄹㆆ
10000	192	ㅈ	2	×	0	16	ㄹㅎ
10001	196	ㅉ	2	×	32	17	ㅁ
10010	200	ㅊ	2	ㅘ	64	18	ㅂ
10011	204	ㅋ	2	ㅙ	96	19	ㅂㅅ
10100	208	ㅌ	2	ㅚ	128	20	ㅸ
10101	212	ㅍ	2	ㅛ	160	21	ㅅ
10110	216	ㅎ	2	ㅜ	192	22	ㅆ
10111	220	FILL 코드	2	ㅝ	224	23	ㅿ
11000	224	漢字	3	×	0	24	ㅇ
11001	228	漢字	3	×	32	25	ㅈ
11010	232	漢字	3	ㅞ	64	26	ㅊ
11011	236	漢字	3	ㅟ	96	27	ㅋ
11100	240	漢字	3	ㅠ	128	28	×
11101	244	漢字	3	ㅡ	160	29	ㅌ
11110	248	漢字/폰트	3	ㅢ	192	30	ㅍ
11111	252	폰트	3	ㅣ	224	31	ㅎ

＊ × 표시는 MS-DOS 제약으로 사용이 불가능한 부분
＊ 한글 : 16,399자 (초성 23, 중성 23, 받침 30)
＊漢字 : 4,966자 ＊ 폰트 : 1,146자 (사용자 정의 문자)
＊ 빈칸 : 768자 (코드 배정 제약)