완성형 한글 부호의 제정 배경과 보완 방안

강석* · 조증성** · 박동순***

        1. 서론

  국가 표준(KS)은 기술 발전 단계상 최고도의 수준에서 제정되는 것만은 아니며, 다수가 동의해 나가는 과정에서 최선의 것이 되어야 상호간에 이익을 준다. 표준 규격 제정시에는 기술 발전의 추이가 감안되어야 하나, 사용자 선호도와 괴리되어 합의가 이루어지지 못할 때 사용 범위와 적용 대상을 한정시켜 표준 규격이 제정될수 있다.
  KS C 5601의 적용 범위를 '정보 교환용'으로 한정하였다. 정보 교환이란, 서로 다른 시스템 사이에서 정보를 상호 이용할 목적으로 시스템 간에 정보를 교환하는 것으로, 통신망과 같은 전송 선로를 이용하거나 테이프, 플로피디스크 등과 같은 Media를 통하여 정보를 교환하는 것을 의미한다. 따라서, KS C 5601은 위의 적용 범위 내에서 정보 교환에 사용하는 부호의 표현 형식에 대해 규정한 것이다. 또한, 정보 교환용의 적용 범위는 P/C에서 대형 컴퓨터까지를 포함한다.
  그러나 현실적으로 행정 전산망용 워크스테이션, 교육용 P/C 등의 대량 구매처의 구매 조건으로 KS C 5601의 내부 적용이 제시되어 조합형, 완성형 논란이 다시 야기되고 있다. 여기에서 '내부'라는 어휘에서 시스템의 어디까지가 내부인가의 기술적 견해는 시각에따라 차이가 있을 수 있으며 P/C의 경우에는 더욱 정의하기가 어렵다.
  그러나 타 시스템과의 정보 교환시에는 완성형 체계로 교환하는 것이 효율적이라는 것이 국가 표준 부호 제정시의 결론이며 정부는 사용 목적에 따라 이를 권장하고 있다. 최근의 KS C 5601 관련 논란은 거의 모두 내부 처리 측면에서 논란으로 파악하고 싶다. 즉, 안 나오는 한글, 자소 분리, 순차 정렬, 글꼴 등의 문제는 내부 처리 측면이며, '정보 교환용 부호'라는 적용 범위의 한정을 벗어나 있다. 정보 교환을 위해 제정된 KS 코드가 교환상 어떤 문제가 있다면 전면 재검토가 당연하지만 정보 교환용을 전제로 한 국가 표준이 일반 사용자에게는 심각한 문제를 야기시키지는 않는다고 본다. 현재 전문 사용자 집단(어문, 문헌 정보, CTS, DTP 등) 내에서 각각 필요한 부호를 확장·부여하여 잘 사용하고 있으나, DB 구축과 전산망을 통한 교환이 점차 확산되고 있어, 사전에 일정 수준까지의 합의가 필요하다는 견해가 대두된것이다.
  본고에서는 KS C 5601의 제정 배경과 완성형의 장단점을 먼저 살펴보았다. 다음으로 KS C 5601의 문제점 및 보완 방안에 대하여 논하였으며, 끝으로 정보 교환용 부호의 발전 방향에 대하여 서술하였다.


        2. 한글한자 코드 표준화

    (1) 한글한자 코드 표준화 의의

  언어란 그 나라 문화 수준의 척도이자 지적인 산물이다. 그러한 언어를 컴퓨터 내에서 나타내기 위한 가장 기본적인 단위가 바로 문자 코드이다. 따라서 문자 코드는 그 언어의 기본 구조와 원리에 맞게 정해져야 하고, 효율적으로 구현할 수 있도록 고안되어야 하며, 이의 표준화를 전제로 개발되어야 할 것이다.
  문자 코드는  컴퓨터 시스템에서 가장 기본적인 요소라고 할 수 있다. 코드 체계가 한번 바뀌면 컴퓨터 시스템은 물론이고 주변 기기, 소프트웨어 등을 위시하여 모든 업무에서 작성된 자료 등, 컴퓨터와 관련된 것이 대폭 변경되어야 하는 어려움이 있다. 따라서 이에 대한 연구 개발이 진지하고 장기적으로 지속되어 온 것이 사실이다.
  코드의 표준화가 가져다 주는 장점이나 의의는 매우 광범위하고 크다. 먼저 개발이나 생산시에 중복 투자를 피할 수 있고, 새로운 기술 개발이 활성화되어 국제적인 경쟁력을 키울 수 있다. 동시에 사용자에게는 혼란을 배제해 주며 보다 우수한 다량의 소프트웨어를 공급하여 주고, 주변 기기들을 최대한으로 활용할 수 있도록 해 줌으로써 사무 자동화나 업무 개선에 큰 기여를 할 수가 있다.
  따라서 우리나라의 전반적인 사무 효율을 신장시키고, 생산자에게는 시장의 규모가 훨씬 확대되므로 대량 생산으로 인한 원가 절감과 새로운 제품의 개발 의욕이 고취되어 다양한 제품 생산을 할 수가 있다. 이는 결국 사용자에게 보다 많은 선택 범위를 제공함으로써 컴퓨터 사회의 실현을 효과적이고 조속하게 이룩할 수 있는 순환계를 계속해 갈 것이다.

    (2) 표준 코드 제정의 고려 요건

  컴퓨터는 영어 문화권에서 개발되어 사용되어 왔기 때문에, 모든 컴퓨팅 환경이 영어 위주로 설계되어 있다. 운영 체제, 프로그램 개발 환경, 명령어, 각종 소프트웨어, 터미널, 프린터 등 모두가 영어 문자 체제를 기본으로 설계, 제작되고 영문과는 기본 구조가 다른 한글을 이들 환경에서 사용하고자 하는 데는 많은 부가적인 어려움이 따른다. 컴퓨터에서 한글을 사용하고자 하는 노력의 궁극적인 목적은 사용자에게 한글과 영문의 특성 차이에 대한 특별한 고려들이 배제된 환경을 제공함으로써 가장 자연스러운 형태로 컴퓨터를 이용하게 끔 하는 것이다. 즉, 한글 운영 체제, 한글 응용 프로그램, 한글 프로그램을 지원해 주는 것이다. 이러한 환경에의 적절한 코드 선택은 최소한의 노력으로 한글 환경을 조성해 줄 수 있어 중요한 요건 중의 하나이다. 따라서 표준 한글한자 코드 체계를 제정할 때는 다음과 같은 요건들을 고려해야 한다.
  ① 한글의 특성
  한글의 최소 단위는 자소이다. 이 자소들은 일정한 국문법상 규칙에 따라 조합되어 음절을 형성하는데 이 음절이 실제적인 발음 단위이면서 또한 의미 단위, 처리 단위가 된다. 한글과 영어를 비교해 보면 그 특성을 뚜렷이 알 수 있다. 영어를 포함한 라틴 계열의 문자는 하나의 문자가 도형으로 표현될 때 일정한 크기로 쓰여지는 반면 한글은 2개 또는 3개, 경우에 따라서는 5개의 자소들이모여서 일정한 크기의 도형으로 표현된다. 즉, 영어를 기계화할 때는 입력, 처리 및 출력의 단위가 모두 같아 컴퓨터에서 사용하는 코드는 한 문자 단위로 코드를 부여하면 된다. 그러나 한글은 자소 단위로 입력하고 출력은 음절 단위로 모아서 쓰도록 되어있다. 따라서 한글 코드를 마치 영문과 같이 자소 단위의 의미만 갖도록 하면 입력에는 어려움이 없으나 음절 단위의 처리나 출력에는 불편한 코드가 된다. 결국 한글 코드는 자소 단위와 음절 단위의 의미를 갖고 있어야 입출력 및 처리가 효율적인 코드가 된다.
  ② 영문 환경과의 호환성
  대부분의 업체에서 채택했던 한글 코드를 보면 외국에서 만들어진 소프트웨어와의 호환성을 제일 먼저 고려하고 있다. 그 이유는 현재 국내에 보급되고 있는 컴퓨터 시스템 소프트웨어들을 거의 외국에 의존하는 상황에서 가능하면 외국 소프트웨어를 수정하지 않고 한글을 쓸 수 있도록 하는 것이 경제적이며, 본래 영문 소프트웨어에서 제공하는 기능을 제한없이 그대로 사용 가능하기 때문이다.
  ③ 국제 규격과의 호환성
  국제간 정보 교환의 필요성이 나날이 증대되고 있어 한글·한자 코드 체계는 국제 표준과 일치해야 할 필요성이 있다. 그 이유는 ISO(International Standards Organization)에서 규정하는 통신 제어와 장치 제어용 문자를 위한 영역(이하 C0영역이라 함), 텍스트 제어를 위한 문자 영역(이하 C1영역이라 함)과 도형 문자 부호값이 겹쳐서는 안 된다.
  ④ 효율적인 한글 처리
  한글 처리용 제반 알고리듬에서 시간적 복잡성(Time complexity)을 최소로 줄일 수 있고 최소의 기억 공간에 최소의 정보량을 코딩할 수 있어야 한다.
  ⑤ 한자 수용 문제
  한글, 한자의 코드 체계를 각각 다르게 하여 체계적인 확장법을 따른다면 한자 수용 문제는 한글 코드를 정하는데 고려될 사항은 아니나 체계적인 확장법을 따르지 않고 하나의 코드 체계로 한글, 한자를 코드화하려면 한자 수용 능력도 고려해야 한다. 즉 충분한 확장성을 가져야 한다.
  ⑥ 프로그램의 작성 용이
  한글을 컴퓨터에서 이용되는 동작의 대상으로 생각할 때 이들 동작에 아무런 무리가 없어야 한다.


        3. 표준 코드 개정 배경 및 연구 진행 경위

  '70년대 초 당시 한글 코드는 24자모를 영문 ASCII 코드에 1:1로 대응하여 사용하는 n바이트 코드 체계가 여러 형태로 난립하고 있었으며 풀어쓰기 입력 중 각 음절 간의 구분이 명확하지 않아 각 음절 사이에 delimeter를 입력해야 하므로 타건수의 증가와 기억 용량의 낭비를 감수해 왔다. 이러한 문제점을 해결하기 위해 '74년 KS C 5601 정보 교환용 부호를 제정하게 되었으며 이때 제정된 규격은 51자모를 ASCII 코드에 1:1대응시켜 사용한 7비트의 n바이트에 대하여 규정하였다. 그러나 이 규격도 한글에 대한 연구가 연구소나 일부 대기업에 편중된 채, 급신장하는 외국의 기술을 받아들여야 하는 당시의 상황에서 선도적인 제조업체에서는 표준 코드를 사용하기보다는 받아들이는 기술에 적합한 자소 배열 및 코드 체계를 만들어 사용하는 데 만족하였다.
  '81년 KAIST/SEC가 중심이 되어 한글 코드 표준화를 위한 연구가 처음으로 착수되어 '82년에 KS C 5601의 개정과 아울러 KS C 5619 한자 부호계를 제정하였다. 이 규격에서는 기본 부호계는 7단위 한글 부호로 하고, 보조 부호계는 8단위 한글 부호 및 16단위 한글 부호(2바이트 조합형)로 하였으며, 한자 부호계(KS C 5619)는 2바이트 완성형으로 구성하였다. 이 규격은 그때까지 최대 27개까지 달하던 부호계를 어느 정도 통일시키는 데 기여하였으나 보조 부호계의 종류가 많았고, 정부 차원에서의 제도 및 정책 부족과 인식 부족으로 기술적 및 재정적 지원이 미흡하였기 때문에 표준 규격을 채택할 인센티브가 충분치 않았으며 관련 업체 간의 이해 관계로 표준 코드가 정착되지 못하였다. 이로 인해, 이 기종 간의 호환성 결여, 중복 투자 및 사용자 선택이 자유롭지 못하는 등의 문제는 계속 남게 되었다. 정부, 제조업체, 사용자 모두 이런 문제점에 대한 심각성을 인식하여 표준코드에 대한 재정립의 필요성에 대한 의견을 같이 하게 되었으며, '85년에 정보 교환용 2바이트 완성형 단일 부호 체계로 KS C 5601이 개정되었다.
  KS C 5601-'82표준 코드의 개정을 위해 연구진은 85년 9월부터 국내에 사용되고 있는 코드 체계의 현황과 국내외 규격 및 한글 코드 관련 자료의 분석과 함께 정보 산업체를 대상으로 설문 조사를 실시하였다. 설문 조사 회신 업체 29개사 중 93%가 하나로 통일된 한글 코드를 원하고 60%는 외부(정보 교환용)뿐만 아니라 내부(정보 처리용) 코드로도 사용할 수 있는 표준 코드가 필요하다고 응답했으며, 또 한글 표준 시안 작성시 고려해야 할 사항으로 통신 호환성 및 효율성, 코드 변환의 용이성, 외국 S/W 및 H/W와의 호환성 유지, S/W 한글화 용이성, 국제 규격과의 관련성, 자료 처리의 효율성 및 보편성이 제시되었다.
  이들 관련 자료를 토대로 단일 코드 제정, 국제 규격 존중, 적용 범위의 구체화, 각계의 의견 수렴을 기본 방침으로 세워 이와 가장 적합하다고 판단되는 2바이트 조합형과 완성형을 예비시안으로 작성, 산업체에 대하여 의견 조사 및 공청회를 가졌다. 그 결과 완성형 시안은 국제 규격, 한자 수용 능력, S/W 한글화 등에서유리하고, 조합형 시안은 코드 변환의 용이성, 한글 특성, 국내 사용 현황에서 우세하다는 의견이 나왔다. 조사된 자료를 가지고자문 회의를 실시하여 토의한 끝에 코드 변환용 VLSI를 정부에서 개발, 공급하고 표준 코드를 따르는 업체들의 희생을 최소화시켜야 한다는 조건하에 국제 규격을 그대로 만족시키는 2바이트 완성형 시안을 표준 시안으로선정하였다. 표준 시안으로 선정된 2바이트 완성형 부호에 대하여 공청회와 전문가 토론회를 개최하여 각계각층의 의견을 수집한 결과 표준 시안에 대한 요구 사항은 다음과 같았다.

○ 국제 규격(ISO-2022)은 따르는 게 유리함.
○ 정보 교환용 부호만이라도 단일안으로 통일시켜야 함.
○ 한자 사용은 필수적임.
○ 조합 가능한 한글은 전부 사용할 수 있어야 함.
  이 모든 사항들을 검토한 후 정보 교환용 부호로 2바이트 완성형 부호를 규정하고 완성형 부호를 내부 처리용으로 사용하지 못하는 기종들을 고려하여 2바이트 조합형과 7비트 부호의 권장안을 추가시킨 안을 최종 시안으로 확정하였다. 2개의 권장안은 현재 사용되는 여러 종류의 조합형 및 7비트 부호들이 각각 신제품 개발에의 적용을 통해 한 종류로 통일되도록 유도하기 위하여 포함시켰다.
  이 한글 코드는 한자와특수 문자가 추가된 후 한국 공업 표준 심의회 정보 처리부회의 심의를 거쳐 1987년 8월 31일 KS C 5601 정보 교환용 부호로 개정되었으며 행정 전산망용 워크스테이션과 교육용 PC에서 채택되는 등의 파급 효과에 의해 많은 제조업체들이 이를 수용하여 점진적으로 정착되어 가고 있는 과정에 있다.

        4. 한글한자 표준 코드(KS C 5601-87)

  정보 처리 및 데이터를 전송하는 시스템에서 정보 교환에 사용하는 부호의 표현 형식에 대하여 규정한 것으로, 2바이트 완성형 코드 체계로 구성되어 있다. 2바이트 완성형 코드는 '가나다'순으로 정렬하되 사용 빈도가 높은 음절을 선택하여 한 음절마다 코드를 순서대로 부여한 코드 체계이다. 이 코드 체계는 ISO-2022의 복수 바이트 개념을 사용한 2바이트 단위의 코드 체계로서 국제정보 교환용 부호계의 제어영역인 C0, C1 영역을 피하여 구성되어 있으며 각 코드의 비트 구성은 그림 1과 같은 형태로 되어 있다.

제 1 바이트

제 2 바이트

b8 b7 b6 b5 b4 b3 b2 b1 b8 b7 b6 b5 b4 b3 b2

b1

M

  X     X     X     X     X     X    X

M

  X    X     X     X    X     X    X

default : M = 1

그림 1. 각 코드의 비트 구성

  표준 코드의 체계 내에는 그림 2와 같이 사용 빈도가 높은 한글 2,350자, 한자 4,888자와 숫자, 외국 문자, 기호, 단위 등을 포함한 특수 문자 987자가 정의되어 있고, 이 규격에 포함되지 않은 한글, 한자 및 특수 문자들을 위한 사용자 정의 영역을 포함하고 있다.
  표준 코드의 사용 방법은 완성형 한글 코드가 따르는 ISO-2022 정보 교환용 부호 확장법을 따른다. 이 확장법은 여러  종류의 1바이트 또는 2바이트(Multiple Byte) 코드 집합 중 4개까지를 G0, G1, G2와 G3에 지시(Designate)시켰다가 사용자가 필요로 하는 코드를 호출(Invoke)하여 쓰도록 되어 있다. ISO-2022는 7단위 코드용과 8단위 코드용이 각각 따로 있는데 7단위 환경에서는 1개의 코드 조합을 한 순간에 사용할 수 있는 반면 8단위 환경에서는 2개까지의 코드 집합을 동시 호출하여 쓸 수 있다.
  외국 소프트웨어를 보면 G0는 로마 문자(ASCII)로 쓰이는 경우가 많다. 외국에서는 또 G1,G2 및 G3 중 일부를 소프트웨어 고유의 문자 집합으로 고정시켜 놓고 쓰는 경우도 있기 때문에, 한글 코드는 외국 소프트웨어들의 한글화 용이성 등을 고려해서 G1, G2 또는 G3 중 아무데나 지시할 수 있도록 하였다. 각 코드 집합의 지시에 사용되는 Escape Sequence의 끝 부분을 나타내는 종단 문자(Final Character)는 3/4을 쓴다. 또 한글/한자와 로마 문자만을 사용하는 컴퓨터에서는 Escape Sequence 없이  각 바이트의 MSB만으로 각 문자 집합을 구분할 수 있도록 하였다(로마 문자:MSB=0, 한글/한자: MSB=1).
  그리고 현재 난립하고 있는여러 종류의 16단위 부호와 7단위의 한글 낱자 부호들의통일을 유도하기 위해 권장안을 제시하였다. 이 권장안은 정보 교환용 부호를 내부적으로 사용 못하는 시스템과 관련 장비에서 사용 하도록 하며, 정보 교환용으로 사용하지 않는 것을 원칙으로 하고 있다.


그림 2, KS C5601 부호표

  완성형 코드는 한정된 수의 한글만을 사용할 수밖에 없는 제약과 한 음절에 대해 자소 단위로 구분하고자 할 때 구분을 위한 모듈을 항상 거쳐야 한다는 점이 어느 정도 문제로서 제기될 수 있다. 반면에 한글 코드 영역이 보다 압축적으로 배열될 수 있고, ISO의 국제 표준 규격에 따를 수 있기 때문에 국가간에 정보 교환을 할 때 나름대로의 용이성과 이점을 가지고 있다. 이 코드 체계의 장단점을 요약하면 다음과 같다.

○ 빈도수가 높은 한글만 골라 함축적으로 코드를 배열하므로 한글의 영역이 작아지나, 약 6,000자의 한자 및 특수 문자를 사용할 수 있다.
○ 컴퓨터의 제어, 작동, 사용자의 편이, 효율성 등에 주안점을 두어 제어 코드와 컴퓨터의 OS에서 특수한 의미로사용되는 meta character를 피해 한글을 코드화하고 있어 한글화에 용이하다. 대부분 OS에서는 ?, *, +, \, [] 등의 기호에meta character(20H-3F, 5B-5F, 7B-7E 사이) 개념을 두어 사용자의 편의를 도모하고 있다.
○ 출력자형을 완성형으로 가지면 한글의 입출력과 통신시 처리 속도가 비교적 우수하다. 특히 출력시 문자 자형을 직접 Access하므로 매우 빠르게  처리된다. 반면에 모든 글자에 대해 자형을 가지고 있어야 하므로 메모리가 많이 필요하다.
○ 출력자형을 Pattern형으로 가지면 완성형 코드를 조합형으로 변환하는 처리를 추가해야 한다.
○ 나타낼 수 없는 한글이 있으므로 사용자 정의 영역 및 확장 문자가 필요하다.
○ 한글의 각 글자에 대한 자소 구분이 어렵다. 자소 구분을 위해서 항상 구분 모들을 거쳐야 한다.

        5. 현행 표준 코드의 문제점

  1987년 정보 교환용 부호(KS C 5601)가 개정된 후 행정 전산망 워크스테이션과 교육용 컴퓨터의 표준 규격으로 KS 완성형 부호가 채택됨으로써 정부 차원의 컴퓨터 수요가 급증하면서 많은 생산업체들이 표준 코드를 수용하고 있다. 그러나 사용자집단이 다양해지고 각계각층에서 요구가 분출되면서 3년이 지난 지금 조합형과 완성형 간의 논쟁이 재론되고 있다. 이는 표준 코드 발표 이후 사용에 대한 홍보 부족과 사용상 나타난 문제점을 보완수정해 나가는 유지 보수 체계가 마련되지 못한 때문이라 할 수 있다. 그동안 각계에서 제기된 KS 완성형 코드 문제점에 대하여 알아보면 다음과 같다.

    (1) 모든 한글을 표현할수 없다는 문자 수 부족 문제

  KS C 5601 에 제정된 한글 글자 수 2,350자는 99.99% 이상의 빈도를 갖는 수로서 일반 사용자가 한글을 표현할 때는 불편을 느끼지 못한다. 그러나, 국어학자, 출판업계, 신문사 등 여러 분야에서 방언, 고어, 의성어, 의태어를 표현할 때 극히 드물게 표시할 수 없는 경우가 발생한다. 이와 같은 경우 현행 KS C 5601 표준 코드에서는 2가지 방법에 의해 사용할 수 있도록 정의하고 있다. 첫째는 사용자 정의 문자를 사용하는 경우로 이때 정의된 문자는 정보 전달시 필요한DRCS 방식의 규약이 정의되기 전까지 정보 교환으로 사용하지 않는 것을 원칙으로 하였다. 그러나 이 경우 컴퓨터마다 사용자 정의 문자 처리 시스템을 가져야 하며, 사용자 정의 문자의 한글을 순차적으로 분류할 때 처리 프로그램 자체가 사용자마다 달라져 호환성이 없어지며, 사용자 정의 문자에 대한 교환 방법이 정의되지 않은 상태에서 사용자가 임의로 문자를 정의하여 사용하기 때문에 사용자와 사용자 사이의 통신 또는 전달에 혼란을 야기시킬 수 있다. 둘째는 한글 낱자 부호를 이용하여 완성형 부호 내에 정의되어 있지 않은 글자를 표현한다. 즉, 2,350자에 포함되어 있지 않은 한글은 초성 자음, 모음, 받침 자음으로 분류하여 각 부분에 해당되는 특수 문자 영역의 한글 낱자 부호를 정보 교환에 사용하는 경우로 모든 한글의 표현이 가능하다. 이때 한글 낱자만의 정보 교환과 구분하기 위하여 음절마다 '채움' 문자를 추가시켜 교환한다.
  이 방법은 낱자로 구성된 한글을 조합할 수 있는 오토마타와 화면상에 출력할 수 있는 처리 방식이 시스템에 구현되어야 한다. 이 방법은 채움이나 자소가 각각 2바이트씩 차지하므로 '"A'이라는 문자를 전송하기 위해서 다음의 예에서 보는 바와 같이 총 8바이트가 필요하지만 아주 드물게 발생하는 경우로 Space상의 문제는 별로 중요시 되지 않는다. 그러나 스크린 에디터, 워드프로세서 등과 같은 소프트웨어에서 화면에 디스플레이시킬 때 내부 기억 크기가 가변 길이를 갖게 되어 한글 구현시 어려움이 따른다. 이 방법에 따르는 한글 코드 발생 방법 및 화면 출력 방법은 그림 3과 같다.


그림 3. 채움 문자 방식의 한글 코드 발생 방법 및 화면 출력 방법

    (2) 한글 입력시 전단계의 글자가 없는 5개 문자의 경우

  초성+중성+종성 3개 낱자로 구성되어야 하는 한 음절의 경우 그 글자의 전단계인 초성+중성만으로도 한 음절이 구성될 수 있어야 하는데 개정된 표준 코드에 이러한 경우에 해당되는 5개 글자(, 쌰, 쎼, 쓔, 쬬)가 있다. 예를 들어 '쎼'는 코드표에 없어 코드표에 있는 '쏀'도 입출력을 할 수 없게 되어 있다. 이 경우는 키보드를 통해 한글을 입력할 때 화면상에 한글이 디스플레이되는 과정에서 발생하는 문제로 출력용 폰트를 무엇으로 쓰느냐에 따라 달라진다. 우선, Pattern형 폰트(자소 조합 방식)를 사용하는 시스템에서는 입출력시 전단계 없는 글자의 문제가 대두되지 않는다. 이 5개 글자는 다만 화면상에 디스플레이시킬 경우에만 사용하고 코드는 발생시키지 않아도 되기 때문이다. 다만, 완성형 폰트를 채택한 시스템의 경우 이 5개 글자에 대한 코드가 정의되어 있지 않으면 통상적으로 폰트도 지원되지 않아 입출력이 전혀 불가능하게 되는 문제가 발생한다. 따라서 이 경우에는 사용자 정의 영역의 앞 5자 영역에 차례로 정의하여 사용하기로 표준 코드 개정 직후 잠정 합의하였다.

     (3) 한글 형태소 분석이어려운 점

  컴퓨터 응용 분야 중 고도 기술의 하나인 인공지능 연구에서 자연어 처리에 필요한 한글 자소의 구별 방법이 직접적으로, 간편하게 제공되지 못한다는 문제가 있다. 한글 문자의 인식, 자동 번역 시스템, 한글 맞춤법에 의한 철자 자동 검색 프로그램 개발 등의 분야에서 어간과 어미의 구분, 조사의 선택 등의 처리시 코드에 의하여 직접적으로 처리하는 방법이 없다. 그러나 프로세싱상 약간의 부하는 주지만, 처리 전단계에서 자소를 구별해 내는 모듈이 제공된다면 해결은 가능한 것이다.


        6. 보완 방안

  현행 완성형 표준 코드(KS C 5601)의 문자 수 부족으로 인한 문제점을 보완하기 위해서는 다음과 같은 방법들이 고려될 수 있다. 문자 수 부족으로 인한 문제는 크게 세 가지 보완 방안을 들 수있다.
  첫째는 완성형 부호 내에 없는 글자를 정보 교환시 사용하는 낱자 부호를 시스템 내부에서 처리할 수 있도록 구현하는 것이다. 이 방법은 앞서 설명한 바와 같이 한 음절당 8바이트의 space을 차지하는 것과 내부 메모리 사이즈가 화면과 1:1 대응이 되지 않아 스크린 에디터나 워드프로세서 등과 같은 소프트웨어에서 한글을 출력할 때 처리가 어려운 단점을 가지고 있으며, 또한 순차적으로 한글을 분류할 때 처리 프로그램을 개발하여야 한다.
  둘째는 DRCS 방식의 규약을 정의하여 없는 글자를 DRCS 방식에 의해 교환함과 아울러 DRCS 방식을 처리할 수 있는 시스템을 개발하여 제공하는 것이다. 앞의 두 가지 방법들은 확장 문자 세트를 개발하지 않고현행 KS C 5601을 수정, 보완하는 방법들이다.
  셋째는 ISO 2022 확장법에 따라 확장 문자 세트를 개발하는 것이다. 확장된 문자판에 한글, 한자를 배열하는 방법은 여러 가지 형태로 생각할 수 있다. 대표적으로 두 가지 방법을 생각할 수 있다.
  하나는 현재의 제1자판 외에 자판 1개(혹은 2개)를 늘려 각 자판에 한글, 한자를 수준별 선정하여 배열한다. 각 자판에 배열할 수 있는 공간은 8,836자가 된다. 또 다른 하나는 2개의 자판을 확장한 후 제2자판에는 KS C 5601에서 정의하지 않은 한글 8,822자 모두를 배열하고 제3자판에는 한자를 배열하는 것이다. 이들 방법은 ISO 2022 부호 확장법에 따라 확장할 수 있기 때문에 국제 규격과의 호환성을 유지할 수 있으나 기존 KS C 5601 내의 문자와 확장 세트의 문자들을 혼용하여 사용할 때 Sort 및 Search 등의 처리를 위한 모듈이 개발되어야 한다. 이와 같이 코드 확장으로 인하여 필요한 모듈들은 하드웨어와 소프트웨어 생산업체 및 관련 종사자들이 사용자 입장에서서 사용자가 느끼지 못하도록 User Interface에 보다 많은 노력을 기울여야 하며 이에 따르는 부담은 공동의 노력으로 많은 생산업체가 긴밀하게 협조하고 서로 자원을 공유하여 전체적인 효율을 극대화시키면 상당히 줄일 수 있을 것이다.


        7. 결론

  현재까지 조사된 사용자들의 요구들을 종합하여 보면 이상적인 한글 코드를 제정하기 위해서는 다음과 같은 요건들을 만족하여야 한다고 생각한다.
1. 조합 가능한 모든 한글 지원
2. 한글의 언어 정보 및 자소 정보의 유지
3. 고어 및 한자 지원
4. 국제 규격과의 호환성 유지
5. 일정한 byte로 음절 표시
6. 사용하기 쉬운 코드
  현재의 7단위 또는 8단위 환경에서는 위의 요건들을 모두 만족시키는 정보 교환용 한글·한자 부호의 제정은 불가능하다. 위의 요건들을 만족하려면 ISO 2022의 부호 확장법이 아닌 16단위(2-byte) 이상의 환경이 요구된다. 정보 교환용 부호 제정의 세계적인 추세를 보면 하드웨어 및 소프트웨어 기술의 발전에 힘입어전 세계에서 사용되는 주요 문자들을 포함하는 문자 코드를 제정하려는 추세이다. 
  예로써, IOS/IEC JTC1/SC2/WG2에서 제정 중인 DP 10646과 미국 일부의 대기업을 중심으로 제정하고 있는 Unicode를 들 수 있다.
DP 10646은  4-byte 체계로써 256X256X256X256=65536X65536의 문자를 부호화할 수 있다. 그러나 현재 컴퓨터 기술 수준으로 32단위 환경을 지원하는 하드웨어 개발이나 소프트웨어의 제작은 비경제적이므로 DP 10646에서는 16단위로 전 세계 문자를 표시할 수 있는BMP(Basic Multilingual Plane)를 먼저 제정하고 있다. 나머지 영역들은 확장을 위해 남겨 두고 있다. 그러나 이 코드 체계는 제어 문자 영역에 문자를 할당할 수 없으므로 36,100의 코드 영역을 사용할 수 있다. 반면 Unicode는 16단위의 코드 체계로써 제어문자 영역에도 문자를 할당할 수 있으므로 65536의 코드 영역을 사용할 수 있다.
  그러나 이 코드 체계는 제어 문자 영역을 사용하고 한자 통합을 조건으로 하므로 유럽 국가들을 포함한 한국 및 일본의 반대로 국제 규격으로 채택되지 못하였다. 그러나 현재 미국의 마이크로소프트사에서는 Unicode의 16단위 환경을 지원하는 OS를 개발 중에 있으며 곧 이러한 OS를 바탕으로 한 워크스테이션들이 우리에게 선보이게 될 것으로 생각한다.
  그러므로 이러한 세계적 추세로 볼 때 머지않은 장래에 이상적인 한글 코드를 제정하기 위한 앞에서 언급한 요건들을 만족시키는 충분한 영역이 우리에게 주어질 것으로 생각된다.
  우리도 조합형이니 완성형이니 하는 논란만 계속할 것이 아니라, 이러한 세계적인 추세에 맞추어 앞에서 언급한 요구 조건들을 만족하는 효과적인 코드로 KS C 5601을 어떻게 발전시켜 나갈 것인가에 대해서 서로 협력하여 연구해야 할 것이다. 아울러 연구 결과가 국제 표준에 반영되도록 합심해서 노력해야 할 것이다.