| |
| |
 |
|
| |
|
|
| |
|
|
| |
|
|
|
|
| 정
인 상 (충북대학교 국어국문학과 교수) |
한자가
정확하게 몇 자가 필요할 것인가에 대해서는 뭐라고 분명하게 말하기 어렵다. 단지, 현행
정부 표준 규격의 한자가 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자만이 다른 프로그램과
호환이 되는 것이다. 그러므로 컴퓨터에서의 한글 실현 방식은 옛글자와 한자 등을 포함하여
램 상주 방식으로 처리되어야만 자료 처리를 원만하게 할 수 있다는 것을 지적하고자 한다.
자료 처리를 위해서 컴퓨터를 사용하는 쪽에서는 워드 프로세서는 자료 입력의 도구에 지나지
않는 것이다. |
|
4
|
|
 |
|
|
|
|
|
|
