연재: 국어와 컴퓨터(1)/표준 한글 코드, 조합형:완성형 

  이번 호부터 ‘국어와 컴퓨터’를 연재한다. 그 첫 번째로, 현재도 논란이 계속되고 있는 표준 한글 코드에 대해, 조합형을 주장하는 쪽과 완성형을 주장하는 쪽 각각의 주장을 한꺼번에 싣는다. 각기 주장의 정당성의 근거와 문제점들을 살펴봄으로써 한글 코드 표준화의 바람직한 방향을 모색하고자 하는 것이다.
  다음 호 주제는 ‘한글 자판’이다.                                                                           -편집자註- 

새 한글 코드 어떻게 개정돼야 하나? *
-표준 한글 코드는 조합형이어야 한다-

강태진/한 컴퓨터 연구소


      1. 컴퓨터 한글 코드란 무엇인가?

  컴퓨터에 한번 입력된 자료는 우리가 아는 문자나 숫자의 형태에서 컴퓨터가 처리하기 쉬운 부호로 바뀌어서 기억 장치에 저장되는데 이 컴퓨터용 부호를 코드라고 말한다. 예를 들면, 미국에서 표준으로 쓰이는 ASCⅡ코드를 지원하는 컴퓨터들에서는 영문의 ‘A’는 컴퓨터 내부에서 숫자 65로 ‘B ’는 66으로 바뀌어 저장이 된다. 영문의 경우에는 대소문자와 숫자, 쉼표, 물음표, 느낌표 등을 나타낼 때 7비트(128개의 부호 표시 가능)로 충분하고 8비트 혹은 한 바이트(256개의 부호 표시 가능)를 쓰면 수학에서 사용되는 부호나 그리스 알파벳 등 영문 이외의 특수 문자도 표현이 가능하다.그래서 각 컴퓨터 메이커마다 조금씩 차이는 있지만 한 바이트를 이용해서 한 글자를 나타내는 방법이 로마자를 쓰는 문화권에서는 보편화되어 있다. 
  문제는 이렇게 로마자를 위주로 만들어진 코드 체계가 한글뿐 아니라 영문과 한자를 섞어 사용하는 우리의 현실에 적합하지 않다는 데있다. 물론 우리가 한글을 완전히 풀어쓰는 데 익숙해져 있다면 이야기는 다르다. 한자를 제외하고 이야기한다면 스물네 개밖에 되지 않는 한글 자모를 1바이트 코드 영역에 집어넣는 것은 어렵지 않은 일이다. 실제로 이와 같은 혹은 비슷한 방법으로 한글을 나타내는 컴퓨터들이 있는데 여기서 문제가 되는 것은 한글의 음절 하나가 컴퓨터의 메모리에서는 ‘ㄴ’ 같은 자모를 나타낼 때의 1바이트에서부터 ‘퉯 ’의 5바이트까지 될 수가 있어 자료 처리 과정이 복잡할 뿐 아니라 24자를 나타내기 위해 256개의 부호 표시가 가능한 한 바이트를 사용하는 것은 메모리의 낭비라는 점이다. 최근까지 국내에서 일반적으로 사용되는 코드는 두 바이트를 세 조각 내어서 한글의 음절을 초성, 중성, 종성으로 나타내 주는 두 바이트 조합형과 사용 빈도가 높은 2,350개의 한글 음절을 선별해 고유한 부호를 부여한 두 바이트 완성형 코드가 있다. 이 중 두 바이트 완성형 코드가국가 표준(KS C 5601)으로 제정되어 사용되고 있는데 이 부호 체계를 표준으로 받아들여 사용하는 데는 여러 가지로 석연치 않은 점이 많다.우선 표기가 가능한 글자 11,172자 중 2,350자만을 나타낼 수 있게 해 우리의 문자 생활을 요즘 출현 빈도가 높은 2,350자의 테두리안에 가두어 놓았다는 게 가장 큰 문제가 된다. 이 표준 코드를 사용하면서 예를 든 ‘퉯’자는 물론 ‘퉵’, ‘퇩 ’, ‘툅 ’ 중 한 자도 쓸 수가 없다. 말은 끊임없이 변한다. 신조어가 생기기도 하고 새로운 외래어가 자연스럽게 우리말로 자리 잡기도 한다. 같은 글자를 발음하는 방법도 시대에 따라 변하고 이러한 발음 방법을 반영해 때때로 맞춤법 자체를 바꾸기도 한다. 변하지 않는 말은 죽은 말이다.


       2. 표준 한글 코드의 문제점

  우리는 이렇게 쉬지 않고 변하는 우리말의 생동감을 완벽하게 표현해 줄 수 있는 우리의 글을 갖고 있다. 이렇게 훌륭한 우리의 글을 요즘 자주 쓰이는 글자 이천 몇 백 자로 제한을 해 버린다는 것은 아무리 생각해도 경솔한 결정이 아니라 할 수 없다. 그 외에도 한글 수의 두 배가 넘는 4,888자의 한자를 포함시킨 것, 영문으로 그냥 입력이 가능한 ‘Km’와 ‘ cal’ 등의 단위를 별개의 특수 부호로 지정한 것 등 KS C 5601코드를 명실상부한 표준 한글 코드로 사용하는 데는 문제점이 많다. 이러한 문제점을 인식한 정부는 연말까지 9천4백만원의 연구비를 들여 컴퓨터용 현행 표준 한글 ․한자 코드(KS C 5601)를 보완하는 작업을 시작했다. 표준 연구소에서 보완하고 있는 ‘새로운 ’표준 코드는 현행 코드와 같이 완성형 코드이다. 완성형 코드는 24개의 자모가 초성 자음, 모음, 받침 자음을 이루어 모든 음절을 나타내는 합리적인 한글의 기본 구조를 완전히 무시하고 우리말의 음절 하나하나를 한자처럼 서로 관계없는 별개의 부호로 처리한 비과학적인 부호 체계이다. 이러한 비과학적인 체계로 한글을 나타내려다 보니 조합이 가능한 한글 11,172자 중 2,350자만 표현이 가능했었다. 새 코드에서는 이러한 현행 부호 체계의 구조적인 문제는 그냥 놔두고 부족한 글자들만 누덕누덕 기워 붙이듯이 추가한다고 한다. 이러한 형태의 코드 보완 방법에 문제가 없을 리 없다. 이 글에서는 표준 연구소 측에서 제안하는 코드 보완 방법의 문제점을 지적하고 보다 이상적인 한글 코드를 얻기 위한 연구 방향을 제시해 보려 한다.
  우선 표준 연구소에서 제안하고 있는 새 코드의 문제점부터 살펴보기로 하자.
  첫째 새 코드를 사용하면 자료의 소팅이 제대로 되지 않는다. 소팅(sorting)이란 컴퓨터에 입력된 자료들을 어떤 원칙에 의해 순서대로 배열하는 것을 말하는데 ‘가나다라’순으로 자료를 배열할 수 있게 하기 위해 기존 코드에서는 ‘가’에 45,057이라는 값을, ‘나’에 45,834라는 값을 주고 있으며 그 사이의 사용 가능한 영역에는 ‘가 ‘와 ‘나 ‘ 사이에 올 수 있는 글자들로 꽉 차있다. 그런데 여기에 기준 코드에는 없었던 ‘갂’자를 더하려면 당연한 문제가 발생할 수밖에 없다. 기존의 글자들을 한 자씩 밀어 자리를 내주면 현행 코드 체계와 호환성을 잃게 될 것이기 때문에 표준 연구소 연구팀은 제2, 제3수준의 한글을 정하려 하고 있다. 이 제2수준 혹은 제3수준의 글자들은 같은 한글이면서도 배열시 제자리를 찾을 수 없게 되는 것이다.
  둘째 새 코드 체계는 또한 비경제적이다. 조합형 한글을 사용했을 때 불과 몇 십 자의 자모를 (혹은 조합된 글씨의 모양을 아주 좋게 한다 해도 몇 백 자모면 충분하다) 조합하여 완벽하게 나타내 줄 수 있는 한글의 글자꼴을 새 코드에서는 모두 11,172개를 갖고 있어야 한다. 업계에서는 이로 인한 컴퓨터의 원가 상승이 3만~4만 원 선이 될 것으로 본다는데 올해 PC의 예상 보급 수량이 40만~50만 대이니 최소 120억에서 200억 원의 국가적 손실이 새 표준 코드 때문에 생길 수 있다는 결론이다.
  셋째 새 코드 체계는 컴퓨터 과학의 발전을 가로막는 장애물이 될 수 있다. 완성형 한글을 가지고는 음절을 이루는 음소의 분석과 형태소의 분석이 불가능하기 때문에 컴퓨터 과학의 첨단 분야로 떠오르고 있는 인공 지능 연구를 통한 한글 문장 인식, 자동 번역 시스템 등을 만드는 일이 훨씬 힘들어진다.
  넷째 새 코드 체계는 우리의 인쇄 문화 발전을 저해하는 요인이 될 수 있다. 우리는 세계 최초로 납 활자를 발명한 조상을 갖고 있음을 자랑해 오면서도 현재 인쇄에 사용되는 서체에 있어서는 명조체와 고딕체 등 몇 개 되지 않는 글씨체에 의존을 하고 있는 실정이다. 수백 개의 서체를 이용하여, 다양하고 보다 설득력 있는 인쇄물을 만들어 내는 미국이나 일본의 경우를 부러워해야만 했던 가장 큰 이유는, 한글이 일본의 ‘가나 ‘나 영문 알파벳보다 글자 수가 적음에도 불구하고 한글의 서체 하나를 만드는 데 들어가는 수고가 너무 컸기 때문이다. 하지만 이제 컴퓨터를 이용하여 샘물체 같은 자형은 육칠십 개, 명조체는 육칠백 개 자모의 조합만으로도 하나의 서체를 만들기에 충분하게 되었는데 완성형을 고집한다는 것은 납 활자 시대로 다시 돌아가자는 것과 다를 바 없다. 게다가 만들어야 할 글자 수를 11,172자로 늘렸으니 새로운 한글 자형을 개발한다는 것은 이제는 정말 불가능한 일이 돼버린 것이다.
  표준연구소 팀은 위에서 언급한 완성형 코드의 문제점 중 소팅이나 음소 분석을 별개의 특수 프로그램을 이용해 해결할 수 있다고 말할지 모른다. 하지만 utility 프로그램은 주어진 완성형 코드가 ‘가나다라’ 순서에서 실제 어디쯤 위치하고 있는지에 대한 정보를 갖고 있는 'look up table' 혹은 ‘찾아보기 표’를 필요로 한다. 완성형 코드 때문에 상형 문자화 된 글자 하나를 구성하고 있는 자소를 알려면 역시 ‘찾아보기 표’가 필요하다. 11,172자를 위한 ‘찾아보기 표’는 컴퓨터의 내부에서 적어도 40k이상의 메모리를 차지하게 된다. 소팅과 자소 분석용으로 별개의 ‘찾아보기 표 ‘를 사용한다면 합해서 80k의 메모리를 필요로 하게 된다. 40k이건 80k이건 간에 640k를 기본 메모리로 하는 행망용 컴퓨터나 512k를 기본 메모리로 하는 교육용 컴퓨터에서는 터무니없이 큰 메모리의 낭비이다. 아마 이런 경우 가장 경제적인 ‘찾아보기 표 ‘는 한쪽에 완성형 코드 또 한쪽에 그에 대응하는 조합형 코드를 늘어 놓아 만들 수 있을 것이다. 결국은 필요할 때마다 완성형 코드를 조합형 코드로 바꾸어 사용해야 한다는 이야기이다. 데이터베이스 프로그램의 경우에는 효율적인 자료의 검색을 위해 자료 하나가 입력될 때마다 그 자료의 혹은 그 자료를 대표하는 색인 항목들의 소팅이 이루어지게 된다. 그렇기 때문에 ‘찾아보기 표 ‘는 컴퓨터의 메모리에 상주하고 있어야 하고 자료 하나가 추가될 때마다 불필요한 ‘찾아보기’ 과정을 거쳐야만 한다.
  완성형 코드는 또한 이렇게 힘들여 소팅한 자료의 검색 과정 자체를 엄청나게 비효율적으로 만들 수 있다. 간단한 예로 자료가 1,000개 입력되어 있는 데이터베이스에서 ‘갂’자로 시작하는 자료를 찾는 경우 조합형 코드라면 처음부터 자료의 색인 항목과 ‘갂 ‘자를 비교하여 같은 항목을 발견하거나 아니면 현재 비교되고 있는 항목이 ‘갂’ 보다 큰 값을 갖고 있는 ‘나’ 같은 글자였을 때 찾기를 중단하면 된다. 다시 말해 조합형 코드를 사용하는 한 우리는 ‘나 ‘자 다음에는 절대로 ‘갂 ‘이 올 수 없다는 사실을 알기 때문에 1,000개의 자료를 모두 읽어 보지 않고도 찾는 자료가 없다고 자신있게 말할 수 있는 것이다. 그렇지만 완성형 코드를 사용하는 경우에는 ‘하’자 다음에 ‘갂’자가 오기 때문에 1,000개의 자료를 모두 읽어 비교해 보기 전에는 이러한 확신을 가질 수 없게 되는 것이다. 이것이 얼마나 비효율적인 자료 검색 방법인지는 데이터베이스에 대해 잘 모르는 사람도 쉽게 이해할 수 있으리라 생각한다. 물론 찾고자 하는 항목과 비교되는 자료 하나하나를 그때그때 ‘찾아보기표 ‘를 사용하여 조합형 코드로 바꾼 후 비교하는 방법이 데이터베이스 전체를 검색하는 것보다는 효율적인 방법일 것이다. 하지만 검색시마다 이루어져야 하는 이 자료 변환 작업 자체가, 데이터베이스의 생명이라고 볼 수 있는 검색 속도를 늦추는 요인이 될 것이다.


      3. 한글 코드가 나아가야 할 방향

  물론 정부가 이러한 불합리함을 무릅쓰고, 또 10대4의 비율로 조합형을 지지한 업계의 의견을 무시하고 완성형 코드를 국가 표준으로 정해 계속 고집하는 데는 이유가 있다. 이것은 국제 표준 기구(ISO)에서 정한 정보 교환용 부호 규격에 입각한 코드를 국가 표준으로 해야 한다는 것이다. 국제 규격에 맞는 국가 표준을 정하는 것은 바람직한 일이다. 하지만 국제 규격에 맞추기 위해 국가 표준이 엉망이 된다면 이 문제는 당연히 다시 한번 생각해 보아야 한다. 민족의 자존심 같은 문제는 접어 두고라도 순전히 실리적인 측면에서 우리가 한글로 외국과 통신을 하거나 국제적인 자료를 주고받는 횟수와, 매일 우리가 우리나라 안에서 자료를 주고받아야 하는 횟수를 비교할 때 어느 쪽 위주로 표준이 정해져야 하느냐는 것은 너무나 자명한 일이다. 만일 우리가 사용하는 우리의 글을 가장 효율적으로 나타내는 코드가 국제 규격에 맞추어질 수 없다면 당연한 국내용과 국제용으로 두 가지 표준 코드가 정해져야 할 것이다.
  표준 연구소는 이번 한글 코드 보완 작업을 통해 정보 교환용뿐 아니라 정보 처리용으로 사용될 수 있는 한글 코드를 만든다고 한다. 나는 새로운 ‘국내 정보 교환/처리용 ‘ 코드는 완성형 코드가 아니라 2바이트 조합형 코드가 선택되어야 한다고 생각한다. 위에 언급한 완성형 코드의 모든 문제점은 한글의 기본 원리를 무시하고 한글을 상형 문자같이 나타내려고 하는 데서 발생한 것들이다. 처음부터 한글을 한글답게 나타내려 했다면 지금같이 코드를 보완하는 고생은 하지 않았을 것이고 또 보완이 된다 하더라도 겪게 될 손해를 감수하지 않아도 될 것이다. 우리의 말을 나타내는 코드는 반드시 한글의 자소 한 개 한 개에 별개의 값을 지정한 조합형 코드여야 한다. 2바이트 조합형 코드는 한글을 완벽하게 나타내 줄 뿐 아니라 한 자도 설계 방법에 따라 4~8천 자 정도 나타내 줄 수 있다. 이 코드는 PC에서만이 아니라 대형 IBM컴퓨터에서도 사용되고 있는 것으로 통신용으로도 큰 문제가 없어 한자 부분만 규격을 정해 준다면 국내용 국가 표준으로의 사용에 손색이 없으리라 본다.
  표준 연구소 팀 같이 수년간 한글 코드 문제를 전문적으로 연구했다고 할 수 없는 나는, 한때 ‘국내 정보 교환/처리용‘ 으로는 국가 표준 코드로는 2바이트 조합형 코드를 ‘국제 정보 교환용 ‘으로는 2바이트 완성형 코드를 사용하면 될 것이라는 생각을 해왔다. 그러나 요즘 이 문제에 대해 생각을 하면 할수록 ‘국제 정보 교환용’으로도 역시 조합형 코드가 사용되어야 한다는 생각을 갖게 된다. 내가 완성형 코드가 ‘국제 정보 교환용 ‘ 코드로도 부적합하다고 생각하는 것은 역설적일지 모르지만 국제 규격에 맞추어 설계되었다는 것을 유일한 장점으로 주장해 온 완성형 코드가, 멀티옥테트 코드로 곧 바뀌게 되는 국제 규격에는 맞지 않을 것 같기 때문이다. 멀티옥테트 코드는 어떤 컴퓨터에서 어떤 소프트웨어를 사용하더라도 어느 나라 말이건 나타낼 수 있다는 매력 때문에 이 코드가 일단 DIS(Draft International Standard)로만 승격이 되어도 각국의 컴퓨터 업체들이 이를 지원하는 하드웨어와 소프트웨어의 제작에 들어갈 전망이다. 그런데 이번에 보완되는 한글 코드는 멀티옥테트의 기본 다중 언어 문자 코트판(BMP: Basic Multilingual Plane)만 가지고는 부족하고 제2, 제3수준의 한글을 수용하기 위해 추가 문자판(supplementary plane)을 정해야만 한다. 추가 문자판의 제정은 문자 코드판 하나를 가지고 세계의 문자를 모두 표현하려는 BMP의 기본 원칙에 어긋날 뿐 아니라 설사 국제 규격으로 인정된다 하더라도 외국의 컴퓨터 업체들이 이를 지원할 리가 없다. 결국 이번 코드 보완을 통해 그동안 억울하게 생매장되었다가 제2의 생명을 얻게 될 글자들이 다시 사장될 가능성이 크다. 우리나라의 멀티옥테트를 지원하는 컴퓨터 시스템에서 만들어진 자료가 외국의 멀티옥테트 지원 컴퓨터에서는 엉뚱하게 나타나는 일이 얼마든지 발생할 수 있는 것이다. 이 외에도 멀티옥테트 코드 전체를 놓고 본다면 불필요한 특수 문자를 잔뜩 정의해 놓은 것, 멀티옥테트의 다른 나라 말 영역에 고스란히 있는 히라가나와 가타가나, 러시아 어 등의 외국어를 포함시킨 것 등 현행 표준 코트가 그대로 국제 표준의 한 부분으로 들어가는 데는 문제가 많다.
  그렇다면 국제 정보 교환용 코드는 어떻게 만들어져야 좋을까? 내 생각엔 조합형 코드를 사용하되 2바이트 조합형이 아니라 멀티옥테트 하나가 한글의 낱자 하나를 나타내는 코드가 가장 이상적이 아닐까 생각한다. 이렇게 하면 같은 양의 한글 자료를 나타내는 데 2바이트짜리 멀티옥테트를 기준으로 할 때 기존의 2바이트 코드 체계에 비해 2배에서 3배(평균 2.2배) 정도의 메모리를 차지하게 되지만 미국같이 1바이트 코드 체계를 써 온 모든 나라들도 기존의 코드에 비해 2배(4바이트짜리 멀티옥테트 사용시에는 4배)의 메모리를 필요로 하게 되므로 우리만 특별히 억울해 할 것은 없다. 또 이러한 이유로 인해 대부분의 나라들은 자국용 코드를 따로 사용하게 될 것이고 우리도 국내용으로는 앞에서 말한 것과 같이 2바이트 조합형 코드를 사용하면 될 것이다. 여기서 내가 말하는 낱자 코드는 기존의 n바이트 조합형 코드에서 쓰였던 것과는 조금 다르다. 초성과 종성의 자음이 각기 다른 값을 갖는 방법을 사용하면 과외로 SI나 SO 같은 특별한 제어 코드를 사용하지 않고도 소팅 등에서도 효율적인 한글 처리가 가능할 것이다. 이 방법의 장점은 고어의 완벽한 처리가 가능하며 (현 코드 보완 방법에서 제시하는 편법이 아니라 고어의 음소 분석도 가능케 하며) 한자를 꼭 써야 한다면 그동안 한글이 차지하고 있던 영역 대부분을 내주어 한자2,000여 자 정도를 더 수용할 수 있다는 것이다. 또, 왜 우리말 코드에 포함이 되어 있는지 알 수 없는 ‘히라가나’ 등의 외국어를 포함해 불필요한 특수 문자를 제거한다면 나타낼 수 있는 한자의 수는 더욱 늘어날 것이다.
  우리는 이번에 새 표준 한글 코드가 어떻게 재정 되느냐에 따라 정보화 시대에서의 우리의 앞날을 탄탄하게 다지느냐 그렇지 못하느냐 하는 갈림길에 서 있다 . 이 문제는 단순히 국내에서의 문제가 아니라 국제 정보 사회에서의 우리의 위치에도 영향을 끼치는 중요한 문제이다. 우리는 이러한 중요한 시점에서 불과 지난 2~3년 일부 PC 등에서 사용되었던 완성형 코드를 미련 없이 버리고 조합형 코드를 국가 표준으로 정하는 결단을 내려야 한다. 조합형 코드를 완성형으로 변환하는 것은 완벽할 수 없지만 완성형으로 구축된 자료는 조합형으로 간단히 완벽하게 변환할 수 있다. 완성형 카드를 조합형으로 대체하는 데 들어가는 비용은 그동안 국내에 보급된 전체 PC 수가 올해 한 해에 보급될 수보다도 적은 것을 감안하고 지금이라도 완성형 코드를 조합형으로 바꾸는 것이 손해가 아니라 국가적인 이익을 가져오는 일이다. 한글 코드를 만드는 작업에 관여한 모든 이들은 더 이상 완성형 코드를 사용해야 할 국내적인 명분도 국제적인 명분도 없다는 것을 깨닫고 하루속히 세종 대왕의 자손으로 부끄럽지 않은 훌륭한 한글 코드를 만드는 작업에 전념해야 할 것이다.