문자는 사람의 말을 시공간을 초월해 시각적으로 전달할 수 있도록 정해진 부호다. 그래서 문자는 모양이 중요하다. 마찬가지로 컴퓨터의 부호체계(코드)란 우리가 사용하는 문자를 컴퓨터가 알아 볼 수 있는 숫자로 바꾸어 같은 모양으로 인식하게 하는 것을 말한다. 보내는 사람이 ‘가’라고 써서 보내면 받는 사람도 ‘가’ 라고 알아볼 수 있어야 한다.
정보를 외부에 전달하거나 내부에 저장하는 컴퓨터의 문자코드는 전압과 자기적 성질의 변화를 나타내기 쉬운 이진수의 형태로 표현된다. 다만 컴퓨터에 저장돼 있는 내용을 사람이 알아볼 수 있도록 숫자가 글자의 모양으로 바뀌어 컴퓨터 화면에 나타나는 것이다.
컴퓨터용 문자코드는 컴퓨터에서 어떤 문자가 어떤 숫자로 나타내지는가에 대한 규약이다. 개인용 컴퓨터에서 일반적으로 사용되는 ASCII 규약에 의하면 컴퓨터에서는 ‘A’를 ‘65’라는 숫자로, ‘B’는 ‘66’ 이라는 숫자로 나타내게끔 돼 있다. 이런 약속이 없었다면 내 컴퓨터에서 만든 편지의 내용이 받는 사람의 컴퓨터에서는 전혀 엉뚱하게 나타날 수 있다. 그래서 각 나라는 그 나라에서 사용되는 문자를 컴퓨터에서 어떻게 나타낼지에 대한 규약을 정하고 모든 컴퓨터들이 이 표준 부호체계를 사용한다.
완성형 코드에 쌓인 불만
정부가 지난 87년 제정한 한글 표준코드는 가장 많이 사용되는 음절 2천3백50자를 추려 2바이트로 구성된 부호를 부여한 ‘2바이트 완성형’ 이다. 그 이전에는 2바이트를 5비트씩 세 덩어리로 나눠 거기에 초· 중· 종성에 해당하는 부호를 부여한 ‘2바이트 조합형’을 비롯한 여러코드가 혼용되던 상황이었다.
조합형 한글코드는 87년 표준이 제정될 당시에도 널리 사용되고 있었으나 국가기간망 주전산기용 운영체제로 유닉스(UNIX)가 채택되는 바람에 이 부호체계를 표준으로 정할 수 없었다. 유닉스가 지원하는 7비트 부호계로 한글이나 한자를 나타내기 위해서는 ‘ISO 2022’ 라는 국제표준을 따라야 했고, 이 표준으로 나타낼 수 있는 두 바이트 글자의 수는 8천여자에 지나지 않았던 것이다. 그리하여 1만1천1백72자의 현대 한글을 완벽히 나타낼 수는 없지만 2천3백50자로 ‘비교적’ 자주 쓰이는 한글을 한정하고 나머지는 한자와 특수문자에 할당한 것이 ‘KSC5601-1987’이다.
그러나 개인용 컴퓨터의 보급이 확산되고 컴퓨터가 다양한 용도로 사용되면서 한글을 완벽하게 표현할 수 없는 완성형 코드에 대한 불만이 사용자들로부터 나오기 시작했다. 또한 완성형 한글이 “평상시 사용되는 글자들의 대부분을 나타낼 수 있기 때문에 실제로 사용하는데 문제가 없다”던 말은 ‘똠방각하’의 ‘똠’자를 쓸 수 없는 등 언어의 변화를 수용할 수 없는 사례가 나타나면서 설득력을 잃었다.
이같은 여론을 의식한 정부는 89년 표준연구소(현재의 표준과학연구원)에 용역을 의뢰해 문제의 해결에 나섰다. 그러나 ISO 2022의 코드 확장방식에 의해 모자라는 글자들을 추가하려던 연구팀은 곧 난관에 부딪히고 말았다. 하드웨어 업체들이 기술상의 문제를 내세워 2022식 코드 확장방식에 대해 강력히 반발했기 때문이다.
결국 연구팀은 1년후 ‘KSC 5657’ 이라는 불완전한 추가 부호체계를 내는 것으로 연구를 마무리지었고, 이 표준은 제정 후 아무도 거들떠 보지 않는 유명무실한 것이 됐다. 그러나 이 연구를 통해 완성형 코드의 근본적인 문제점이 드러나면서 92년 조합형 한글코드가 KS규격에 추가될 수 있었다.
마이크로소프트의 말 바꾸기
조합형 한글 코드를 수용한 92년 개정안이 발표되기 전에 만들어진 MS-도스와 윈도는 완성형 한글만을 지원하고 있다. 도스환경에서 작동하는 대부분의 국산 응용프로그램들은 우리글을 제대로 표현할 수 있는 조합형 한글을 지원했다. 운영체제가 조합형 한글을 지원하지 않았기 때문에 텍스트 입출력을 응용 소프트웨어가 직접 처리해야 하는 부담을 안아야 함에도 불구하고 워드프로세서를 포함한 많은 소프트웨어가 이 방식을 택했다.
그러나 행정 전산망용 소프트웨어와 컴퓨터 통신용 소프트웨어, 한글화된 외국산 소프트웨어 등 완성형 한글을 사용하는 소프트웨어들도 상당히 많은 것이 현실이다. 하나의 사용자가 경우에 따라 완성형과 조합형 소프트웨어를 번갈아 사용하기 때문에 정확한 통계는 내기 힘들지만, 관공서를 제외한 대부분 사용자들이 워드프로세서로 만든 데이터는 2바이트 조합형 한글코드로 되어 있다고 해도 크게 틀리지는 않을 것이다.
요즘은 조합형 한글을 기본으로 하는 워드프로세서를 채택한 공공기관들도 많아 서로 코드체계가 다른 소프트웨어 사이의 데이터 호환이 점점 심각한 문제로 대두되고 있다. 그리고 이러한 문제는 운영체제가 여러개의 소프트웨어를 동시에 사용할 수 있는 멀티태스킹 기능을 지원하는 윈도로 이행하면서 더욱 심각해지고 있다.
다행히 운영체제를 독점적으로 공급하고 있는 마이크로소프트사도 이런 문제점을 인정해서 94년말 윈도95부터는 운영체제에서 조합형 한글을 지원하겠다고 발표했다. 그런데 지난해 5월 19일 조합형 한글은 온데 간데 없이 엉뚱한 ‘확장완성형’ 을 지원하겠다고 해 많은 사람들을 놀라게 한 것이다.
마이크로소프트가 발표후 얼마되지 않아 ‘통합형’ 한글코드라고 다시 명명한 이 코드에서는 기존의 완성형 2천3백50자로 나타낼 수 없었던 문자들을 몇 개의 영역에 추가로 배치해 놓아 현대 한글 중 못 나타내는 글자는 없다. 그러나 문자의 배열이 한글사전의 배열순서를 무시하고 있어 데이터베이스 등 모든 소프트웨어의 기본코드로 사용하는 데는 무리가 있었다. 윈도95에서 조합형 한글을 지원하려니 기존 소프트웨어들과의 호환성에 문제가 발생해 이같은 과도기용 코드가 만들어졌던 것으로 보인다. 통합형 한글코드 발표 직후 사용자들로부터 거센 반발이 있었음은 물론이다.
최근의 논쟁은 작년 8월 영문 윈도95의 출시를 앞두고 세인의 관심이 다시 한글코드로 쏠리면서 일어났다. 8월말부터 열띤 논란이 일기 시작하면서 급기야 정보통신부가 코드를 문제삼아 윈도95를 정부의 구매규격에서 제외시키겠다는 발표를 내놓았고, 이 문제를 국정감사에서 다루기 위해 관련부서에 자료를 요청하는 국회의원들도 나오기 시작했다. 결국 마이크로소프트는 9월22일 윈도95에서 통합한글 지원계획을 취소하고 기존의 KSC 5601 완성형 코드만을 지원하겠다고 후퇴, 문제를 일단락지었다.
한글코드논쟁의 원인 제공자
최근에 논란을 불러일으켰던 한글 코드 문제는 소프트웨어업계의 이해관계, 여기에 안일하게 대처한 정부 등이 빚어낸 해프닝으로 결론지을 수 있다. 통합형 코드는 문건으로 허가(국가표준 승인)된 것은 아니지만 이미 지난 5월 정보통신부나 공업진흥청 등 당국이 사실상 묵인했던 시스템이다. 당시 정부관계자들은 어차피 유니코드가 대세인 마당에 이 코드에 가장 가까운 통합형을 암묵적으로 인정하지 않을 수 없는 입장이었다. 그러나 통합형 코드는 언론 및 소프트웨어업계가 한글코드의 귀착점으로 공동 인식하고 있는 유니코드(ISO 10646-2)와 아무런 관계가 없으며, 오히려 방해물이 될 가능성이 높다.
통합형은 사용자나 소프트웨어업계가 주장해온 현대 한글 1만1천1백72자를 모두 표현할 수 있으며 문자 구현방식도 유니코드와 동일한 방식을 채택하고 있다. 그러나 통합형은 외관상으로 드러나지는 않지만 내부 문자처리에서 사전식(가나다순) 배열을 따르지 않으며 정부표준이 아니라는 한계를 갖고 있다.
통합형이 사전식 배열을 따르지 않는 것은 문자판에 기존 KSC 5601 완성형 2천3백50자 및 확장 완성형 문자세트 KSC 5657의 1천9백30자와 여기에서 제외된 6천8백92자 등 3개의 문자세트를 각각 별개로 위치시켰기 때문이다. KSC 5601은 정부가 80년대말 사용빈도수가 가장 높은 것을, KSC 5657은 그 다음으로 높은 것을 각각 가나다 순으로 추려놓은 것이다. 반면 유니코드는 이같은 정부표준을 무시하고 1만1천1백72자를 ‘헤쳐 모여’시킨 다음 처음부터 하나의 문자판에 배열해 놓고 있다.
마이크로소프트측은 처음부터 유니코드를 채택하지 않은 것에 대해 몇 가지 이유를 들었다. 우선 기존 KSC 5601을 채택해온 대다수 응용소프트웨어와의 호환은 물론 2-3년 후면 대세가 될 유니코드와의 호환을 위해서라는 것이다. 즉 한글 윈도95는 MS-도스와 윈도3.1 등 기존 환경과, 한글 윈도 97쯤에 해당될 2-3년후 환경과의 징검다리 역할을 수행해야 하는 임무를 띠고 있다는 것이다.
기존 KSC 5601에서 막바로 유니코드로 이식하는 것이 전혀 불가능한 것은 아니지만, 이를 해결하기 위해서는 마이크로소프트 뿐 아니라 국내 소프트웨어업계 모두 엄청난 기술적 부담을 요구하고 있다고 밝히고 있다. 반면 통합형은 지금 당장 유니코드에 대한 해결책이 요구되는 것도 아닐 뿐더러 기존 코드시스템의 틀 안에서 유니코드로 이식하기 위한 징검다리를 제공하기 때문에 부담이 없다는 것이다.
그러나 마이크로소프트의 입장과 달리 사용자들은 먼저 것보다 조금 나은 코드일지는 몰라도 앞으로 제대로된 코드를 쓰는데 걸림돌이 될 가능성이 있다는 점을 우려했다. 일례로 요즘 완성형 코드가 좋다고 하는 사람은 찾아볼 수 없으나 이미 그 코드로 만들어진 데이터가 많기 때문에 앞으로도 한동안은 대부분의 소프트웨어에서 이 코드를 지원해야 한다.
업계는 ‘표준’ 외치고 정부는 수수방관
윈도95용 한글코드를 둘러싸고 벌어진 이번 한글코드 논쟁은 사실 국내 컴퓨터 사용환경 및 산업구도가 짜여지기 전인 80년대 중반부터 본격화돼 왔다. 앞서 기술한 것처럼 정부는 행정전산망을 포함한 5대 국가기간전산망사업 시행을 앞둔 87년 통신이나 네트워크 전송 효율성을 위해 2천3백50자를 모은 완성형을 국가 표준(KSC 5601-1987)으로 제정했다.
그러나 당시 민간에서는 청계천상가의 7비트 코드와 삼보컴퓨터가 규정한 KSSM 등 2바이트 조합형 코드가 업계표준으로 양립하고 있는 상황이었다. 바로 이같은 상황이 본격적인 코드논쟁의 불씨를 잉태시켰던 것이다.
완성형에 대한 민간업계의 강한 반발이 계속되자 정부는 92년 KSSM을 근간으로 하는 조합형 규격도 마련, 표준(KSC 5601-1992)으로 제정했다. 하지만 이미 많은 소프트웨어들이 KSC 5601-1987을 지원할 수밖에 없는 상황이었다. 가장 주된 이유는 마이크로소프트가 발표한 MS-도스나 한글 윈도 3.1 등의 운용체제가 한결같이 KSC 5601-1987만을 지원해왔기 때문이다.
이때 한글과 컴퓨터사는 ‘아래아한글 2.x’ 등 응용 소프트웨어에 KSC 5601-1987과 함께 조합형 코드를 지원해왔지만, 이 역시 정부 표준 KSC 5601-1992와는 무관한 것이었다. 이같은 논쟁은 결과적으로 공업진흥청이나 체신부(정보통신부의 전신) 또는 문화체육부 등 관련부처의 한글코드정책이 능동적이지 못했으며 업계표준에 대한 지도관리가 제대로 이뤄지지 못했기 때문에 발생한 것이다. 이로 인해 마이크로소프트가 완성형 코드만을 지원하는 편법을 구사하고도 컴퓨터환경의 주도권을 행사할 수 있었고, 한글과 컴퓨터가 자체 제작한 코드를 정부표준인양 포장해서 목소리를 높여도 제재를 가할 수 없었다는 얘기다.
컴퓨터용 부호체계가 유독 우리나라에서만 논란의 대상이 되는 것은 우리글이 로마자 같은 음소문자와 일본의 가나와 같은 음절문자의 특성을 함께 지닌 독특한 문자체계이기 때문이다. 영문 부호체계의 경우 ASCII말고도 IBM의 자체 표준인 EBCDIC라는 것이 있다. 두 체계가 다른 것이긴 하지만 알파벳 하나를 한 글자로 보는데는 일치하고 있다.
우리글은 경우에 따라 ‘가’ ‘나’ ‘다’ 같은 음절을 한 글자로 취급하기도 하고 ‘ㄱ’이나 ‘ㅏ’ 같은 자모를 한 글자로 보기도 한다. 그래서 음절 하나 하나에 독특한 부호를 부여하거나 자모 하나 하나에 부호를 부여하더라도 컴퓨터가 알아볼 수 있다.
그동안 한글 코드 논쟁에서는 완성된 음절 하나 하나에 부호를 부여한 것을 '완성형'으로 자모 하나 하나에 붙인 것을 '조합형' 한글코드로 불렀다. 결국 무엇을 한 글자로 볼 것인가에 대한 견해 차이를 극복하는 것이 한글코드 논쟁을 종식시킬 수 있는 근본적인 해결책이라는 것이 전문가들의 지적이다.
한글 코드 문제의 츨발점
컴퓨터는 자료 처리시 정보를 표현하거나 기록할 때 글자의 모양을 기억시키는 것이 아니라 0과 1의 2진 부호로 코드화해 저장한다. 2진수는 1과 0만 사용하므로 8자리의 2진수로 구성되는 조합의 수는 2의 8제곱, 즉 2백56가지의 서로 다른 글자를 표시할 수 있다. 이때 8개의 비트가 모여 구성된 하나의 글자를 바이트라고 한다.
알파벳이나 숫자 기호 등을 표시하는데는 하나의 바이트로 충분하다. 그러나 한글은 음소문자인 영문과 달리, 풀어서 입력한 자음과 모음을 다시 모아 출력해야 한다는 제약점이 있다. 영문은 하나의 문자가 도형으로 표현될 때 일정한 크기로 쓰여지는 반면 한글은 2개 또는 3개 이상의 음소들이 일정한 크기의 도형으로 표현된다. 다시말해 한글을 표시할 때는 한 글자당 1바이트로는 모자란다는 얘기다.
