사용자 "잘못 끼운 첫 단추가 문제, 지금이라도 머리 맞대자"
컴퓨터에서 우리 글을 표현하는 방법에 복잡한 역사가 있다는 것을 많은 컴퓨터 사용자들은 알고 있을 것이다. 흔히 ‘완성형코드’ 라 불리는 KSC 5601이 1987년 정부에 의해 표준으로 정해짐으로써 잘못 단추를 끼운 이래, 우리 한글 코드는 전쟁터를 방불케 하는 혼란 속에 지금에 이르고 있다. 특히 한글 윈도95 발표 시점에 이르러 부각된 확장완성형 논쟁을 거쳐 유니코드를 바탕으로 한 KSC 5700의 발표로 한글 코드 문제는 새로운 국면에 접어든 느낌이다.
거두절미하고 한글 코드가 가져야 할 속성에 대해 생각해보자. 무엇보다도 우리 글을 모두 표현할 수 있어야 한다는 것이 가장 먼저 지적돼야 할 것이다. KSC 5601 완성형이 가진 가장 큰 문제 역시 우리 글을 2천3백50자로 제한했다는 것이다. 이것은 우리가 사용하고 있는 현대어조차 표기할 수 없는 말도 안되는 코드체계다. 이 코드가 10년 가까이 우리의 표준으로 사용돼 왔다는 것은 큰 문제가 아닐 수 없다.
한글 도스, 한글 윈도 3.1, 각종 응용프로그램과 데이터 파일이 모두 완성형으로 만들어졌기 때문에, 지금 시점에서 아무리 좋은 대안이 나온다고 해도 결국 우리는 큰 비용을 지불하지 않고는 올바른 길로 돌아올 수 없는 처지가 되고 만 것이다.
이론의 여지 없이 한글 코드는 체계적으로 구성되어야 한다. 한글 코드의 일관성 있는 배열은 긴 안목에서 매우 중요한 의미를 가진다. 윈도 95 발표 무렵 물의를 빚었던 마이크로소프트의 확장완성형은 현대어 1만1천1백72자를 모두 표기할 수 있고 기존 KSC 5601 완성형과 호환된다는, ‘두 마리 토끼’ 를 잡은 아이디어의 산물이었다.
그러나 이 코드는 근시안적인 코드라는 비난을 면하기 어렵다. 우선 한글 코드의 순서를 무시하고 있다. 따라서 응용프로그램에서 소팅(sorting)하는데 문제가 발생한다. 물론 이러한 문제는 운영체제 차원이나 응용프로그램 차원에서 쉽게 해결할 수도 있을 것이다. 그러나 근본적인 문제를 그대로 남겨둔 채로 해결하는 것보다는 근본을 치유하는 것이 백년대계로서 합당하다.
확장완성형이 안고 있는 문제는 코드 체계의 혼란을 가중시켰다는 점이다. 그동안 우리는 완성형과 조합형이란 두 가지의 표준 코드를 통합하려고 얼마나 많은 애를 써 왔는가. 사용자들은 통신에서 다운받은 텍스트 파일을 출력하기 위해 프린터의 KS/KSSM 전환을 하는 것이 얼마나 불편했는지, 또 코드 변환을 위한 프로그램을 실행하느라 얼마나 많은 시간을 낭비했는지 기억할 것이다. 이러한 상황에서 정부와 업계에서 표준으로 인정받지도 못한 일개 기업(마이크로소프트)의 작품인 확장완성형이 운영체제에서 사용된다면 우리 사용자는 좋으나 싫으나 이를 표준 아닌 표준으로 인정하지 않을 수 없는 종속적인 상황에 놓였던 것이다.
마이크로소프트가 포기를 선언한 확장완성형은 이미 ‘죽은 코드’ 임에 틀림없다. 그러나 한글 윈도95를 조금 조작하면 확장완성형을 읽고 쓸 수 있어 아직도 불씨는 남아 있다. 지금에 와서 한글 윈도 95에 포함된 확장완성형을 완전히 들어내라는 것은 무리한 요구일 터이고, 다만 혹시나 확장완성형에 미련이 있는 개발자가 있다면 잘못된 생각임을 깨달아야 할 것이다.
‘죽은 코드’ 에 대한 미련 버려라
한글 코드 문제는 지난해 12월 유니코드를 근간으로 하는 KSC 5700이 발표되면서 일단락됐다. KSC 5700은 유니코드를 바탕으로 체계적으로 구성된 것이 일단 맘에 든다. 아직도 조합형을 주장하는 많은 사용자들이 있지만, 조합형만이 한글의 구현 원리에 맞는다는 단순한 논리로 유니코드를 무조건 배척한다는 것은 기분에 치우친 판단으로 보인다. 현실적 시각으로 살펴보면 KSC 5700이 사용면에서 조합형과 비교해 크게 불편할 것이 없다.
사실 필자도 현 시점에서 조합형에 대한 미련을 완전히 떨치기는 어렵다. 그러나 결론적으로 KSC 5700도 좋은 대안이 될 수 있다고 생각한다. 이제 남은 문제는 KSC 5700이 가지고 있는 문제점과 이 문제를 어떻게 해결해 나갈 것인가에 대한 논의다(정부는 KSC 5700를 표준으로 제정하면서 활용도가 떨어지는 시점까지는 KSC 5601을 표준으로 인정하겠다는 고육지책을 함께 발표했다).
가장 큰 문제는 KSC 5700 체제에서 어떻게 기존의 완성형과 조합형을 수용할 것인가 하는 것이다. 마이크로소프트 확장완성형과는 달리 KSC 5700은 기존의 KSC 5601 완성형과 호환되지 않는다. 언젠가는 모든 프로그램과 자료를 KSC 5700으로 전환해야 한다고 했을 때 그 방법과 시기에 대한 깊은 연구가 필요하다. 가장 마찰을 줄일 수 있고 합리적인 방법을 찾아보아야 한다. 정부와 업계의 각고의 노력이 없이는 이러한 과도기는 예상 외로 길어질 수 있고, 이에 따라 사용자가 입는 피해도 엄청날 것이다.
마이크로소프트에서는 차후 버전에서 유니코드를 근간으로 하고 다국언어 지원 구조를 통해 완성형과 조합형 데이터를 수용한다는 계획을 가지고 있다고 한다. 이러한 기능이 구현된다면 비록 한글 코드의 완벽한 해결책은 아닐지라도 상당히 편리한 대안이 될 수 있을 것이다.
여러 가지 문제를 해결하는데 있어 누구 한사람의 노력만 가지고는 아무것도 되지 않는다. 가장 중요한 역할은 정부다. 정보통신부를 주축으로 한 정부 부처 담당자들이 확고한 의지를 가지고 한글 코드 문제 해결의 주도적인 역할을 해야 한다. 여기에 마이크로소프트를 포함하는 업계, 한글학회를 포함한 학계, 그리고 사용자 대표로 구성된 한글 코드 컨소시엄을 구성해 보다 체계적으로 접근할 필요가 있다. 충분한 연구와 토의를 거쳐 한글 코드의 나아갈 방향과 문제점을 연구하고 의견을 통일한 후 채택된 안을 과감한 밀고 나가야 한다. 지금도 늦지 않았다. 한글 코드 문제는 우리의 글을 살리고 문화를 계승하는 중요한 일이다. 지금까지의 고통과 낭비를 더 이상 되풀이하지 않기 위해서는 현재의 어려움을 감수하더라도 개혁이 필요하다. 우리 사용자 개발자 정부 모두 각성하고 세종대왕의 웃음을 다시 찾아 줄 수 있도록 뛰어야 할 것이다.
프로그래머 '하나의 한글코드' 로 더 이상의 정력 낭비 막아야
프로그래머의 한 사람으로 필자는 한글코드 문제로 많은 사람들의 귀중한 시간이 낭비된다는 것이 안타깝다. 한글은 세계적으로 인정받는 우수한 글자다. 이 글자를 컴퓨터에서 표현하기 위한 코드를 제정할 당시 세종대왕이 한글을 창제할 때 들인 시간과 노력만큼 더 고민을 했었다면 좋았을 것이라는 아쉬움이 항상 남는다.
무엇보다도 시급한 일은 한글코드 문제가 어떻게 해결되든 간에 단일안이 나와야 한다는 것이다. ‘어떻게’ 라는 단어에 반감을 품을 사람도 있겠지만, 한글코드가 한글다워야 한다는 대원칙에는 동의할 것이다. 그러나 국제적인 코드 제정에는 각 국가의 이해관계가 얽혀 있어 어쩌면 한글다운 코드 제정이 힘들지도 모른다는 우려도 사라지지 않는다.
현재와 같이 조합형과 완성형이 모두 공존하는 상태에서는 두가지 코드를 모두 지원하거나 둘 중 하나를 지원하는 프로그램을 작성해야 한다. 이에 따라 능력있는 프로그래머들이 조합형·완성형 에뮬레이터나 코드변환기를 만드는데 많은 시간을 보내고 있는 실정이다. 이것은 의미없는 일에 노력을 허비하는 꼴이다.
운영체제가 도스의 텍스트 기반에서 윈도 환경으로 변화를 하면서 PC상에서는 마이크로소프트사의 완성형을 지원하는 윈도를 대다수 사람들이 사용하고 있다. 그렇다면 우리의 한글은 완성형으로 갈 수 밖에 없는 것인가? 자식의 이름도 완성형코드 범주 안에서 지어야 하는 현실을 못마땅하게 생각하는 사람들도 많다. 필자 역시 우리말을 사랑하는 한 사람으로서 우리말을 제대로 다 표현할 수 없는 현재의 완성형 한글 코드를 절대 선호하지 않는다.
지금과 같은 상황이라면 결국 조합형과 완성형이 공존하게 될 텐데, 국가와 소프트웨어 산업에 종사하는 모든 이들이 함께 나서지 않으면 이중적인 투자는 계속 될 것이다. 따라서 프로그래머로서 단일안을 원하는 것은 너무 당연하다.
국내의 프로그래머들은 운영체제는 물론이고 툴이나 커스텀 컨트롤 모두를 외국에서 만들어진 것을 사용하고 있다. 이유는 단 하나, 우리나라에서 만들어진 것이 극히 미비하기 때문이다. 그러나 외국에서 만들어진 운영체제와 툴을 우리나라에서 사용하려면 한글이 지원되지 않아 사용에 한계가 있다. 이것은 단순히 메뉴 정도를 한글화하는 것을 뜻하는 것은 아니다. 당연히 한글을 정확히 표현할 수 있어야 하고, 모든 한글을 사용할 수 있어야 한다.
코드체계만이 문제 아니다
한글코드가 완성형에서 확장완성형으로 정해질 경우 프로그래머로서 느끼는 불편함은 더 늘어난다. 코드 자체가 섞여 있기 때문에(정확히 표현하자면 기존 완성형 코드에 입력이 안되는 글자들을 여유있는 자리에 집어넣었기 때문에) 정렬이나 찾기를 할 때 결과를 예측하기 힘들다는 것이다. 비록 글자를 정렬해주는 함수를 한국 마이크로소프트사에서 지원해준다고 해도, 그것을 국내의 프로그래머들은 아쉬운 나머지 사용할 수 있을지 몰라도 세계의 모든 프로그래머들이 사용할 것이냐는 의문을 남긴다.
이 문제는 프로그래머에게 있어서 코드 구성 단위의 문제만큼이나 심각하다. 시스템 프로그래머를 제외한 대다수의 프로그래머는 데이터베이스의 자료를 읽어서 처리한 결과를 화면 위에 보여주는 작업을 하고 있다. 이 때 정렬은 무척 중요한 개념이다. 자료를 마구잡이식으로 볼 사람은 아무도 없기 때문이다.
누구나 자신이 원하는 형태대로 자료가 정렬되기를 원한다. 2바이트를 고려하지 않더라도 일반적인 에디터에서 정렬되는 수준의 결과라면 만족할 만하다. 그런데 확장완성형의 경우 코드를 정렬해주는 함수를 사용하지 않는 툴이나 커스텀 컨트롤을 사용한다면 한글 정렬은 뒤죽박죽이 될 것이다.
더욱 중요한 것은 한글코드가 2바이트 코드라는 점이다. 물론 이는 우리 한글코드가 2바이트라는 것이 문제라기보다는 소프트웨어의 강대국이라는 미국이 사용하는 영어가 1바이트로도 충분히 표현되는 것을 문제의 발단으로 보는 편이 타당하다. 동양권을 제외한 외국 대부분의 소프트웨어들이 2바이트 코드를 지원하지 않는데, 툴이나 커스텀 컨트롤 같은 개발자 도구들은 특히 이런 현상이 심하다.
덕분에 우리 개발자들은 2바이트코드를 지원하는지 여부를 확인하기 위해서 많은 시간을 보내야만 한다. 또 해당하는 기능의 프로그램을 개발하기 위해서 많은 시간을 보내거나, 비록 한글은 지원되지만 실제로는 2바이트 문자 처리를 하지 않기 때문에 한글을 두개의 문자로 보고 작동하다가 실행중 다운되는 커스텀 컨트롤도 상당히 된다.
국내에서도 소프트웨어의 생산성에 관심이 높아지면서 서서히 툴이나 커스텀 컨트롤 시장이 부각되고 있지만, 2바이트 지원문제를 해결하지 못해 난관에 부닥쳐 있다. 볼랜드사의 델파이도 초기에는 데이터베이스 브라우저에서 한글을 보여주는데 약간의 문제가 있었고(지금은 수정되었지만), 마이크로소프트의 비주얼 베이식도 한글 입력을 처리하는데 문제점을 내포하고 있다.
이것들은 툴보다는 운영체제가 사용하는 한글 코드의 지원에 문제가 있는 경우가 대부분이다. 즉 운영체제가 한글이 2바이트라는 점을 명확하게 지원하지 못하기 때문에 생기는 문제인 것이다. 이는 다시 말해 프로그래머에게 있어서 한글의 코드 체계만이 문제가 아니라 코드의 구성단위도 문제가 된다는 것을 의미한다. 만약 애초부터 서양의 컴퓨터 제작자들이 동양권을 고려했더라면 모든 코드는 2바이트가 되었을 것이다.
이제 세계는 하나의 영역으로 간주되고 있다. 따라서 2바이트라는 구성단위의 문제는 시간이 해결해줄 지도 모른다. 그러나 정부와 업체가 앞장 서서 우리 글을 충분히 표현할 수 있는 한글 코드를 단일안으로 확정해서 발표하고, 이것을 한국의 표준 한글 코드안으로 세계 소프트웨어 시장에 널리 알리지 않는 한 귀중한 시간을 비생산적인 분야에 낭비하는 일은 계속될 것이다.
세계적으로 우수한 글자인 한글이 왜 후손들에 의해서 정보화 시대를 가로막는 걸림목이 되어야 하는지 안타깝기만 하다. 특히 한국인이 아닌 다른 나라 사람들이 자신의 운영체제에 지원하고자 하는 한글코드를 정하고 표준을 변경하는 작금의 실정이 을씨년스럽기만하다.
