한글! 어찌 우리 잊으랴

90.6. 154p

한글! 어찌 우리 잊으랴

한글 무엇이 문제인가

글/ 이주희

말도 많고 탈도 많은 한글, 이 한글이 우리의 속을 썩이고 있다. 세종대왕께서 한글을 만들 때 컴퓨터도 함께 만들든가 아니면 영어로 만들었으면 이러한 문제가 없었을 것이나 세종대왕은 엄연히 이 나라 이 땅 사람이고 컴퓨터라는 물건은 엄연히 코큰 사람들이 만든 것이니 '나랏말씀이 중국과 달라 쓰기 어려운 지경'을 지금도 당하여 '나랏말씀이 미국과 달라 날로 씀에 불편'하기 짝이 없고 그러다 보니 말도 많고 탈도 많다. 세종대왕은 최만리의 극구 만류에도 불구하고 기존의 모든 음운 표시체계를 없애버리고(실제로 그 당시에 이두와 비슷한 음운 표시체계가 몇 가지 있었다고 한다), 결국 코드를 통일, 한글을 제정하셨다. 그러나 이제는 극구 만류하는 최만리는 많아도 옳은 방향으로 한글을 정립해 나가려는 모습은 찾아 볼 수 없으니, 그나마 우리가 세계에 자랑할 수 있는 최고의 문화유산으로 교과서에서도 가르치면서 오히려 이를 짓밟고 압착하여 우리의 한글이 제 모습을 잃어가고 있는 상황이 안타깝기 짝이 없다.

필자는 얼마전까지만 해도 책상 앞에 앉아 소위 탁상공론을 벌여 왔다. 한글의 창제 원리나 우리의 문화유산을 대대손손 이어가기 위해서는 당연히 조합형이어야 한다느니, 완성형은 우리의 귀중한 한글이 가진 무한한 확장 능력을 없애는 짓이라느니, 완성형을 입력하기 위해서는 어차피 키보드에서 조합형으로 입력받아 완성형으로 변환하여 내보내야 한다느니, 또 폰트가 너무 많아져 나중에 벡터 폰트나 스트로크 폰트를 사용할 경우 그 많은 메모리를 어떻게 완성형을 가지고 감당할 것이냐는 등 생각해 낼 수 있는 이것저것을 지적하면서 입씨름을 벌였다. 그러나 여기 필자가 약 2시간여에 걸친 작업으로 얻은 결과를 밝히고자 한다. 작업이야 2시간 정도라지만 실제 프로그램을 작성하는 시간이 20분, 나머지는 그 결과를 살펴보는 데 걸린 것이었을 뿐 그 이전에 생각들을 정리하고 추스리는 시간은 길고도 험난했다. 이제 여기에 한글에 관한 제일 커다란 문제 두 가지, 즉 한글 코드와 자판 문제를 가지고 파헤쳐 보자.

전제 조건

전제 조건은 별다른 것이 아니다. 모든 한글 코드에 공평하기 위하여 한글을 2350자로 제한했다. 완성형 코드 테이블에 따라 각 회사의 조합형 코드를 배열하고 이에 대하여 자료를 분석하였다. 이 2350자로 모든 한글의 99.99%를 표시할 수 있다고 정부에서 엄연히 발표한 것이나 필자도 이 자수 내에서 한글을 다루어 보고자 한다.

첫번째, 한글 코드의 문제

이 문제는 독자 여러분도 너무나 잘 알다시피 지금까지 격하게 논란을 빚어 온 사항이다. 한글 코드에 대해서 그동안 신문, 잡지에 많은 주장과 논문들이 발표되었지만, 여기서는 좀 다른 시각에서 한글 자체를 적나라하게 파헤쳐 보려고 한다. 적나라하다는 것은 다시 두 가지로 생각할 수 있다. 그 중 하나는 통신회선 상에서의 문제이며, 또 다른 하나는 프로그래밍 상에서의 문제이다. 통신상의 문제

정보통신의 정의를 내려 보면 원거리에 있는 사람과 전기적인 혹은 광학적인, 전파적인 매체를 통하여 서로의 자료를 교환함을 말한다. 이 때 상대방에게 전달되는 정보는 내가 보고 있는 것과 동일하거나 혹은 이에 상응하는 동일한 효과를 내야 한다. 그런데 통신과 한글을 함께 논하기 위해서는 내가 전달한 정보를 상대방이 볼 때 한가지 전제 조건이 필요하다. 그 전제 조건이란 다름이 아니라 네트워크 상에는 에러가 뜨지 않는다는 것을 말한다. 그럴 수밖에 없는 것이 한글 코드건 아스키 코드건 코드로는 에러를 검출할 수 없기 때문이다.

통신 상의 문제는 공업진흥청에서 신주단지보다 더 중요하게 섬기는(?) ISO-2022 코드 확장법에 따라 한글을 그 어느나라의 문자도 아닌 형태로 모호화시켜 버렸을 만큼 관의 시각에서는 중요한 것이다. 아니 통신이 중요한 것이 아니라 북한에서 조합형을 들고 나왔으니 우리는 그들과 뭔가는 달라야 한다는 대결의식이 중요한 것이라고 해야 옳을 것이다. 또한 국제회의에 가서 우리의 코드 영역을 8192자나 따왔으니 그것을 상부에 자랑하고 뭔가 보고할 꺼리를 만들기 위하여 한글을 일본의 가나 혹은 중국의 한자처럼 고정불변의 언어로 만들어 버린 것인지도 모른다.

완성형으로 하지 않으면 따온 8192자 내에 한글과 한자를 모두 수용할 수 없으니, 한자도 넣어야 하겠고 한글도 넣어야 하겠는데, 조합형으로 하자면 코드 영역이 부족하고 또 명분도 있어야 하므로 내세우는 것이 99.99% 한글이다. 즉, 2350자면 한글을 거의 표시할 수 있고 한자도 4888자나 들어 있으니 어지간한 내용은 모두 한글과 한자로 표시할 수 있다는 것이다. 어쨌든 존재하는 코드 중 가장 힘이 센(?) 것이고, 대기업에서 채택하고 있으니 이를 살펴 보기로 하자. 그외 금성과 삼성 등 이미 한글을 가지고 있던 회사의 코드와 함께 재야에서 탄생한 최철룡씨가 제작한 한글 도깨비 코드(한글 도깨비 II 코드), 그리고 청계천을 중심으로 가장 많이 사용되는 IBM 상용 조합형 한글을 함께 알아 보기로 한다.

사실 이러한 한글 코드들이 채택 된 배경에는 아주 근본적인 이유가 있다. 초창기 PC의 주요 판매 대상은 대형 기종의 터미널로 사용하기 위한 것이었다. 우리나라에서는 주로 사용되는 것이 IBM이었으니 3270 터미널 대신 PC를 사용하는 것이다. 삼보나 큐닉스 등 중소기업이 IBM 상용 코드를 채택한 이유가 바로 이 점이다. 이들 중소기업에게는 명분보다는 실리가 우선이었기 때문에 IBM의 코드를 채택한 것이며, 삼성은 명분과 실리를 동시에 추구하기 위하여 초성과 종성의 한글 코드를 변경하였다. 즉, 초성의 코드값 중 1을 빼면 종성의 코드에서 1을 빼 다시 이 값이 16보다 크면 1을 더 빼준다. 코드도 다르고 변경하기도 쉬우니 명분과 실리를 동시에 획득한 것이다.

그럼 금성은? 금성사에서 쓰고 있는 한글 코드는 KSC-5601-1984이다. 다시 말해 똥인지 오줌인지도 모른채로 그저 KS라니까 따라간 것이다. 이러한 상황에서 한글 코드는 춘추전국시대를 맞이하게 되었다. 금성과 삼성의 관계야 이미 삼척동자도 다 아는 사실이고, 삼보나 큐닉스 같은 회사는 명분보다는 실리가 우선인데다가 그동안의 축적된 자료가 있으니 바꿀 수 없을 것이 아니겠는가.

먼저 KSC-5601-1987 행정전산망용 코드에 대하여 살펴 보자.통신용으로 만들었다고 하니 한글 통신 상의 문제가 고려된 작품이겠지만, 사실 이 한글 코드는 국제 문자 통신을 위하여 만든 것인지 한글 통신을 위하여 만든 것인지 모를 만큼 다양한 문자들을 지원하고 있다. 영어, 일어, 불어, 독어, 희랍어, 심지어는 러시아 문자까지도 있다.

거기에 각종 과학기술용 약어들까지도 있으니 만약 세계인이 이 코드를 전세계 표준으로 삼는다면 아마 하등의 장애없이 편히 쓸 수 있을 것이다. 그러나 불행하게도 세계에서 이 코드를 채택해 줄리는 절대 만무! 바꿔 말하면 코드 영역을 메꿔야 하겠기 때문 아니겠는가.

그나마 완성형 한글이 가진 특성은 한글의 첫번째 바이트건 두번째 바이트건 모두 0xA0 이상의 값을 가진다는 것이다. 그 이유는 네트워크에서 한글이 0x7f로 마스크오프되었을 때 0x20 이하의 컨트롤 코드, 즉 네트워크 제어 코드가 발생하지 않도록 하기 위한 것이다. 그렇다면 이 점이 과연 통신을 고려한 것인가? 물론 통신을 고려한 것이다. 영문 통신망을 이렇게 완성형으로 해 놓아도 팀네트(TymeNet)와 같은 미국의 초대형 네트워크에서 한글은 어림없는 문자이다. 들어오는 모든 코드를 0x7f로 마스크오프하기 때문에 이 팀네트을 사용해 전송이 가능한 한글은 N바이트 한글과 청계천 한글 뿐이다.

그러나 완성형 한글을 채택해 발생하는 국제 통신에 있어서의 자유로운 정보 교환은 물건너 갔다. 다만 네트워크에 아무런 장애도 일으키지 않는다는, 미국 큰 형님께 아무런 피해도 끼치지 않는다는 아주 크고 중요한(?) 문제가 해결되었다. 그 외에는 더 이상의 아무런 의미도 가지지 못한다. 단순히 8192자의 코드 테이블을 메꾸기 위하여 제작되었거나 프로젝트를 따다 연구비나 받아 탕진하기 위해 만들어졌다고 볼 수밖에 없을 것이다. 결론은 결국 국제 통신에서는 아무런 효과도 없다는 점이다.

그러면 조합형에서는 어떠한 문제가 있는가? 미국의 거대한 네트워크들이 들어 오는 코드들을 모두 127 이하의 값으로 유지한다. 그러기 위해서 들어 오는 글자값과 01111111B(127, 0x7f)의 논리곱을 구하여 이 값을 글자값으로 한다. 즉, 마스크오프한다. 조합형 한글을 0x7f로 마스크오프할 경우 첫 바이트와 두번째 바이트 모두 제어 코드의 발생 원인이 된다. 대부분의 한글 코드들이 0x80 근처에 첫 바이트가 시작된다. 그러니 예를 들어 IBM 조합형 한글 코드(일명 삼보 한글 코드)의 경우 '가'의 코드값이 0x8861이다. 첫번째 바이트를 0x7f로 마스크오프하면 0x08이 된다. 벌써 0x08 백스페이스 코드가 된 것이다. 0x80, 0x90대에 있는 모든 코드는 문제의 온상이 되는 것이다. 그럼 네트워크 상에서 좀 더 치명적인 문제가 되는 XON, XOFF는 얼마나 발생하는지 살펴 보면 더 한숨이 나올 것이다. XON, XOFF는 제어 코드 중 전송 대기, 전송 속개 명령으로 흔히 키보드에서도 ^S를 누르면 잠시 멈추고 ^Q를 누르면 다시 표시하듯이 바로 이 ^S, ^Q를 XON, XOFF라고 한다. 이 코드가 통신회선으로 보내지면 회선이 먹통이 되는 경우가 흔히 있다. 자, 그럼 얼마나 많은 XON, XOFF가 발생하는가? 각 코드마다 한두 개의 차이가 있을 뿐 대체로 80~90개 선에서 발생한다. 다만 금성사의 한글 코드가 XON 코드 발생이 가장 현저하게 적다. 다른 코드들은 80개 이상인데 반해 45개이니 상당히 적은 수이다. 기타 다른 코드들도 함께 <표 1>에 표시하여 놓았으니 이를 살펴보기 바란다.

<표 1> 마스크오프에 의하여 발생한 제어코드의 빈도표

이렇게 많은 제어 코드가 통신선 상을 날아다니면 누구나 쉽게 통신이 엉망이 되겠구나 하는 생각을 할 것이다. 그러나 답은 '아니다'이다 한글 통신이 된다고 할 때 이미 그 네트워크는 여덟번째 비트를 자르지 않는다는 것이므로, 완성형이나 조합형 관계없이 통신이 가능한 것이다. 여덟번째 비트를 마스크오프해 버리면 완성형 코드는 네트워크에 장애를 일으키는 제어 코드가 많이 발생하지 않는다는 장점이 있을 뿐 한글 통신이 안되기는 마찬가지이며 조합형도 발생하는 모든 코드가 네트워크를 엉망으로 만든다고 말할 수 없다.

만약 그렇다면 BIX나 컴퓨서브 등 미국의 초대형 전자게시판에서 이진파일은 하나도 전송받을 수 없게 된다. 이것은 비단 우리의 문제만이 아니라 그들도 마찬가지로 해당되는 이야기이다. 그러므로 그들도 모든 제어 코드를 네트워크 제어용으로 사용하는 것이 아니라 32개중 몇 개만을 사용하고 있으며 만약 이러한 코드가 발생하면 이 코드를 다른 코드와 함께 보내거나 하는 등의 방법을 사용하여 피해가고 있다.

그러나 정말 중요한 것은 한글을 0x7f로 마스크오프하지 않았을 때 과연 몇 글자나 제어 코드가 되느냐의 문제이다. 이 경우에는 처음 바이트에는 아무런 문제가 없을 것이나 두번째 바이트에서 문제가 생길 것이다.

그러면 몇 글자나 스스로 제어 코드가 될까? 결론은 2350자 중 스스로 제어 코드가 되는, 즉 하위 바이트가 0x32 미만인 코드는 한글 2350자 중 한 자도 없었다. 그러므로 어떠한 한글을 써도 마스크오프하지 않는 네트워크에서는 아무런 문제도 발생하지 않는다는 점이다. 이 말은 귀가 따갑도록 들었을 것이다. 그러니 우리에게는 좀 더 실질적인 자료들이 필요하다. <표 1>을 다시 한 번 살펴 보기 바란다. 각 코드별로 0x7f로 마스크오프했을 때 발생하는 제어 코드들의 빈도를 보면 어느 코드가 어떤 코드를 많이 발생시키고, 어떤 코드가 문제가 적은 지를 나름대로 판단할 수 있을 것이다.

그러나 필자의 견해로는 어느 코드가 좋고 나쁜지 판단할 수 없었다. 빈도가 전체적으로 비슷하여 두드러지는 점이 없기 때문이다. 그럼 과연 어떤 글자들이 문제를 일으키는 범인인가? 첫 바이트가 문제를 일으킬 수도 있고 두번째 바이트가 문제를 일으킬 수 있다. 대체로 전 문자에서 고르게 문제가 발생하고 있다. 첫번째 바이트건 두번째 바이트건 모두 0x9f 이하이면 대상이 되는 것이다.

빈도수는 첫 바이트와 두번째 바이트에서 발생한 경우를 모두 합쳐 빈도수를 계산한 것이므로 제어 코드가 가장 적게 발생하는 한글은 금성 한글이다. 그러나 1062~1325 문자 이내이니 어느 코드가 더 좋다 하고 말하기에는 문제가 있다. 그러므로 통신선상에서 한글이 왕래하는 데 코드만 마스크오프하지 않으면 아무런 문제가 없다. 한 가지 남은 것은 8192자 이내의 영역을 넘는다는 것이다. 그러나 이러한 문제는 우리가 고려할 대상이 못된다. 미국의 대형 컴퓨터 제조업체들이 코드 영역의 문제를 들고 나오는 이유는 자기들이 아시아권 특히 중국의 문자 체계를 손쉽게 구현하여 시장을 장악하려고 하는 속셈이지 결코 약소국의 권익을 보호하자는 뜻이 아니다. 필자가 제시하는 해결책을 이 글의 말미에서 언급하겠지만, 이제 이러한 자료들 앞에서 완성형만이 한글 통신의 길이라고 우긴다면 종국에는 돌이킬 수 없는 후퇴적인 상황이 되고야 말 것이다.

대형 기종에서는 조합형이건 완성형이건 한글에 대한 정보를 인식하자면, 들어 오는 글자를 마스크오프하지 않는 것과 함께 제어 코드가 들어 오면 이를 처리해 주는 프론트엔드(front end) 부분이 새로 마련되어야 한다. 예를 들면 유닉스의 경우 stty를 한글에 맞게 새로 작성해야 한다. 거의 모든 기계에서 이러한 작업을 해야 한다. 이 점은 지금은 상당한 문제가 될 수 있다. 그러나 일본의 경우 기술력이 따라주기 때문에 이 문제를 해결하고 있다.

프로그램 작성시의 문제

프로그램 작성시에 발생하는 문제는 두번째 바이트가 아스키 코드중 특수 기호가 되는 경우이다. '~!@#$%^&*()_-+=1\/?.,":;[]{}'의 특수 기호가 한글의 두번째 바이트가 되면 C 혹은 파스칼 등의 언어에서는 문자열이 엉망이 될 수 있다. 필자는 주로 C로 프로그램을 작성하기 때문에 가장 중요한 '";:\'의 기호를 살펴 보게 되었는데, 그 중 가장 중요한 것이 '\'이다. 이 기호가 문자열 중에 나오면 문자열의 제어 코드로 인식을 하여 문자열을 망가뜨리기 때문이다. 그 이외에는 한글이 나타나는 경우는 주석문 정도이므로 다른 기호들은 거의 문제가 되지 않는다. 파스칼에서는 '''가 문자열을 감싸는 기호이므로 이 코드가 나타나면 문자열을 망가뜨릴 수 있다. 혹은등이 주석문 내에서 나타나면 주석문이 망가져 프로그램의 에러를 유발시킬 수 있다.

만약 프로그램을 작성하는 데 문자열이 깨지거나 눈으로 보기에 이상이 없는데 문제가 발생하면, 위 표에서 제시한 한글이 있는지 살펴 볼 일이다. 위 표들을 작성하면서 필자는 도깨비 한글 코드와 삼성 한글 코드를 잠시 혼동했다. 이 두 코드는 거의 비슷하게 발생하는 상황이 똑같다. 도깨비 한글 코드는 필자가 가진 컨버터가 없어 본지에 발표된 김재원씨의 카멜레온 III를 사용하여 제작한 것이다. 그런데 뭔가 잘못되었는지 두 개의 데이터가 똑같이 발생하였다. 그래서 두 파일을 비교해 보기도 했는데, 중간중간에 다른 코드들이 있었다. 우리가 새로운 언어를 만들어 쓰지 않는 이상 기존에 있던 언어의 활용도 몹시 중요하다. 그러므로 지금까지 크게 부각되지 않았고, 앞으로도 인지만 하고 있으면 얼마든지 문제를 일으키지 않을 사소한 문제이나 한 번은 관심을 가져야 하는 문제이기에 필자가 분석을 해 본 것이다. 따라서 얻은 결론은 위에서 보인 것처럼 C 언어를 사용하는 사람에게는 삼성이나 삼보 한글 코드가 적당하다. 전체적으로는 프로그램을 작성하는 경우에는 삼보 코드가 가장 무리가 없다. 도 가장 적게 발생했고 는 전혀 없고 C에서 사용되는 요소가 거의 배제되어 있다.

두번째, 자판의 문제

필자는 얼마전 교육용 PC가 너무 많이 보급되어 있기 때문에 '자판 이야기를 꺼내는 것은 화약을 지고 불속으로 뛰어 드는 행위와 같다'라는 말을 들은 적이 있다. 그러나 현재 두벌식이 정착되다시피 되어 있는 상황이지만 오히려 자판 논쟁은 날이 갈수록 더욱 격렬해지고 있다. 그리고 요즈음에는 정내권씨의 노력으로 어떠한 기종에서건 삼벌식 자판을 쓸 수 있게 되었다. 필자도 나름대로 자판에 대해 많은 생각을 해왔는데, 본 란을 빌어 과연 어떤 자판이 한글의 특성을 잘살리고 과학적인가를 검토해 보고자 한다.

세벌식이 두벌식보다 나은 점은 여러가지가 있다. 지난 5월호 PC 어드밴스라는 잡지에서 한글에 대한 특집을 다루면서 자판에 대한 이야기를 인터뷰와 함께 박스 기사로 처리한 내용이 있다. 여기에 데이콤의 유경희 의원과의 인터뷰 내용이 나오는데, 유경희씨는 손수 두벌식을 만들어야 한다고 하면서 그 이유로 세벌식은 글쇠를 너무 많이 사용하여 배우기가 어렵다는 것이었다. 또 스페이스키가 너무 크니 이를 분할하여 다른 용도의 키를 추가하자고 하였는데, 물론 이 의견에는 찬성이지만 과연 이 주장이 옳은 것인가 알아보자.

일본 사람들은 히라가나 50자, 가다까나 50자를 사용해야 한다. 그러므로 적어도 50개의 글자를 자판에 두고 영문의 시프트키와 영일 전환키 말고 히라가나 가다까나 전환키가 있어야 할 판이다. 그런데 우리는 세벌식으로 해야 고작 51개인 셈이다.한 때 통일타자기라고 부르던 네벌식 자판이 있었다. 이것은 초성용 자음, 받침이 붙는 모음, 받침이 없는 모음, 종성용 자음 이렇게 4가지가 시프트 상태에 따라 조합되어 글자가 이루어지게 되어 있다. 이럴진대, 세벌식에서 사용하는 글쇠가 너무 많아 배우기가 어렵다고 하는 것은 한 가지밖에 생각을 안한 것이다. 물론 두벌식에 비하여 처음에 배우기는 어렵다. 글쇠의 위치를 다 외고 이를 익숙하게 누를 때까지는 시간이 다소 걸린다. 그러나 배우는 시간보다 훨씬 긴 시간을 실제로 사용하는 데 보내야 하는데 언제까지나 초보자로 남아 있으라는 말인가? 따라서 배우기 쉽다는 이유 하나만으로 두벌식을 고집해서는 안된다. 그리고 한글을 한글의 구성 원리에 맞도록 해야지 왜 자꾸 어렵게 꼬이려고만 하는지 모르겠다.

얼마전 미국에서도 표준 자판을 쿼이(qwerty)에서 드보락(dvorak)으로 바꾸었다.

후자를 사용하면 훨씬 빠른 속도로 타자할 수 있기 때문이다. 전자를 계속 표준으로 써 왔던 이유는 기계식에서는 기계 메카니즘의 속도가 드보락 자판에 의한 손가락 속도를 따르지 못했기 때문이다. 그러나 컴퓨터 자판은 지금보다 10배는 빨리 친다고 해도 따라가고도 남으니 이제는 누가 더 빨리 정보를 입력하느냐가 정보 전쟁의 핵심이 된다고 생각했던 것이다. 미국의 표준은 이미 존재하는 것의 단점만을 보완하는 방식으로 제정되지만 대한민국의 표준은 전혀 새로운 것을 창출해 내는 데 있다.또 한 가지, 표준이 되면 기존에 있는 것은 모조리 처분해야 한다는 생각이 머리에 가득 차 있는 것 같다. 이미 상당히 많은 수가 지금의 두벌식을 쓰고 있다. 세벌식이 되면 그들은 전부 세벌식으로 가야 하는가? 그렇지 않다. 원하는 사람만 세벌식으로 가게 하고 처음 배우는 사람은 세벌식으로 배우게 하여 점차 세벌식으로 가면 되는 것이다. 필자처럼 세벌식의 전향을 간절하게 원하고 있는 사람은 세벌식으로 가겠고, 나머지는 두벌식으로 만족할 것이다. 지금 필자는 필자의 손가락 능력과 두벌식의 한계에 부딪쳐 지금 이 글을 쓰면서도 약 20퍼센트의 오타를 내고 있다. 그러니 세벌식으로 갈 생각을 절실하게 원하는 것이다.

만약 공병우 세벌식이 표준이 되지 않는다면 새로운 자판을 만들기 위해 한글의 빈도 조사를 해야 할 것이다. 한글 각 음소별 빈도와 글자별 빈도를 모두 조사해야 한다. 사실 음소별 빈도수보다는 글자별 빈도수가 더 중요하다. 그래야 가장 많이 쓰이는 글자를 근거로 다시 음소 단위의 분석이 이루어지고 이를 토대로 왼손과 오른손이 고르게 작업을 할 수 있도록 해 주어야 한다. 물론 시프트키를 누르는 상태도 최소한으로 줄여야 한다. 필자는 간단히 음소 빈도 분석 프로그램과 글자 빈도 분석을 하는 프로그램을 만들었는데, 음소 빈도 분석 프로그램의 경우에는 한글의 초성과 중성, 종성의 발생 빈도수와 그 퍼센트(%)를 보여준다. 사용하는 코드는 조합형이면 무조건 된다. 다만 별도의 코드표를 한 장 손에 들고 무슨 글자는 몇 글자 하는 식으로 세어 나가야 하지만 빈도 분석하기에는 아무런 지장이 없다.

그리고 글자의 빈도 분석은 각종 사전류나 자판 배열 등의 중요한 근거 자료가 된다. 각 글자가 문장 내에서 차지하는 비율을 계산해 보면 어떤 글자가 얼마나 많이 사용되는가 알 수 있다. 가장 많이 사용되는 글자를 구성하는 음소를 가장 잘 쓸 수 있는 자판에 배열하여 가장 효율적인 자판이 생성될 수 있을 것이다.글자 빈도 분석 프로그램은 간단한 이진트리를 사용하여 구성하고 있는데, 글자를 입력받아 이를 이진트리로 구성한 다음 이 트리를 추적하여 각 빈도를 출력하고 있다. 이 방법은 발생하지 않은 글자를 세지 않으며 들어오는 글자를 바로 소트하는 효과도 함께 발생시킨다. 그러나 최악의 경우에는 프로그램이 스택 오버플로우를 발생하고 죽어버린다. 그 이유는 이 프로그램은 재귀호출을 통해 이진트리를 관리하고 있으므로 만약 글자들이 이미 정렬이 되어 있는 경우에는 속도도 느려지고 트리도 한 쪽만 존재하는 링크드 리스트처럼 되어 버린다. 실제로 이런 경우를 실험해 본 결과 여지없이 스택 오버플로우 에러를 내고 말았다. 필자가 이 글을 쓰는 데 사용했던 2350자가 기록된 파일을 읽어 빈도를 조사했더니(이 경우에는 당연히 모든 글자의 빈도는 1이다) 프로그램이 둘다 죽어버렸다. 그러므로 컴파일할 때 스택의 크기를 적절하게 증가시켜 본다. 필자는 스택의 크기를 60032로 잡았다. 32768을 잡았을 때 에러가 나기에 한꺼번에 크게 잡은 것이다. 만약 한글의 11712자가 순서대로 배열된 테이블을 이 프로그램을 사용하여 빈도 분석을 하려고 하면 아마 틀림없이 프로그램이 죽어버릴 것이다.

그러나 필자도 이 테이블을 가지고 있지 않아 해보지는 못했다. 실제 속도도 엄청나게 느려진다. 그러므로 혹시 순서대로 배열된 테이블을 가지고 빈도 조사를 하고자 하는 경우에는 속도가 약 10배 이상 느려지는 경우도 있으니 혹시 죽었는줄 알고 컴퓨터를 꺼서는 안된다. 스택 오버플로우나 메모리 부족 사태가 발생하지 않는 이상은 정상적으로 동작한다. 메모리 모델을 라지로 할 경우에는 스택 오버플로우 에러만 아니면 정상적으로 동작하므로 끝날 때까지 인내심을 가지고 기다려 주기 바란다. 사용법은 다음과 같다.

cfreq 파일

위와 같이 하면 결과가 화면에 출력되게 된다. 만약 파일로 저장하고 싶으면

cfreq 파일 > 결과 파일

과 같다.

방법은 있는가?

필자의 결론은 한글 코드는 이원화되어야 한다는 것이다. 완성형과 조합형이 아닌 조합형 2바이트형과 조합형 3바이트형이다. 무슨 뚱딴지냐고 하겠지만 어차피 대형 기종 간의 통신은 조합형이건 완성형이건 양쪽 다 문제가 있다는 사실을 위에서 말했다. 따라서 마지막으로 얻은 결론은 SI, SO에 의한 한글 처리이다. 이 SI, SO를 사용하는 방식은 N바이트 한글에서부터이다. 그러나 이제 다시 이곳으로 돌아와 SO와 SI로 한글을 싸고 이 안에 한글을 초성, 중성, 종성의 3바이트 형식으로 전송하는 것이다. 물론 1.5배 이상의 오버헤드가 발생한다. 그러나 전세계의 어떤 네트워크를 타더라도 한글 전송이 될 뿐 아니라 표현하지 못하는 한글도 없게 된다. 또한 기존의 외국 소프트웨어도 거의 변형을 가하지 않아도 사용할 수 있다. 원한다면 한자도 넣을 수 있다.

물론 다른 나라 사람이 보게 되는 경우는 어떻게 하느냐고 하는 질문이 있을 수 있다. 그러나 이에 대한 답은 확실하다. 그 사람이 한글을 읽을 줄 안다는 것이다. 그렇지 않고서야 뭐하러 한글 정보를 보겠는가. 그리고 보통 문장이 되지 않는 영어의 덩어리들만 보일 것이다. 두벌식으로의 코드 변환은 초성 테이블, 중성 테이블, 종성 테이블을 두고 들어온 글자를 배열의 포인터로 삼아 배열에서 값을 바로 가지고 와서 다른 값들과 더하기만 하면 된다. 단 이 코드는 전파 매체를 통하여 정보가 교환되는 경우에만 사용된다. 기계 내부에 저장되는 한글은 2바이트 조합형이어야 한다. 물론 터미널이나 PC 내부에서 사용되는 코드는 조합형이어야 한다. 통신회선 상에 전송될 경우에만 3바이트로 변환된다.

자, 그렇다면 누구의 코드를 가지고 조합형 표준을 정해야 하겠는가? 삼성, 금성이 포기하고 삼보의 코드를 쓴다? 아니면 삼보, 삼성을 포기하고 금성의 코드를 쓴다? 혹은 삼보, 금성이 포기를 하고 삼성의 한글 코드를 표준으로 쓴다면? 천만의 말씀이다. 이들은 다음 두 가지 경우가 아니면 행하지 않을 것이다.

첫째는 자사의 코드가 표준이 되는 경우이고, 둘째는 전부 다 고쳐야 하는 경우이다. 그렇지 않으면 누구도 표준을 따르려 하지 않을 것이다. 그러므로 지금 어느 누구도 채택하고 있지 않은 코드가 필요하다. 그런데 이 코드는 우리에게 너무나 가까이에 있는 것으로, 명분도 그대로 살 수 있다. 바로 KSC-5601-1987에 포함된 조합형 보조 코드이다. 이것을 채택한 회사는 아직 없는 것으로 알고 있다. 그러므로 필자는 표준 코드로 지금 보조 코드로 되어 있는 조합형 한글 코드를 제시하는 바이다. 애써 한글 코드를 확장하려고 애쓰지 말고 전에 만들어 놓은 것을 쓰면 서로 이해 관계에 얽히지 않고 더불어 무리가 없을 것이다.

또, 말 많은 통신에서도 SI, SO의 정통적으로 작업을 하니 아무런 문제가 없다. 다만 조합형을 쓰건 완성형을 쓰건 3바이트로 해야 하는 일인데, 대형 기종들의 통신 포트 관리 부분을 새로 작성해야 하는 일이 있을 뿐이다. 그렇지만 지금도 완성형 코드에 맞추어 작업을 하고 있는 곳이 많이 있는 것으로 알고 있다. 이 부분에 대하여는 필자도 아직 잘 모르고 어느 선까지 해야 하는지를 잘 모르겠다. 확실한 것은 어짜피 한글 통신을 하고자 한다면 우리의 손으로 만들어진 소프트웨어가 사용되어야 한다는 점이다. 일본이 하고 있는 것처럼 말이다(필자는 이 점에 대하여 좀 더 연구하여 이후 발표할 예정이다).

그리고 한 가지 더 공업진흥청에 부탁하고 싶은 것은 ISO 코드 확장 규약에 대한 자료를 원하는 사람들에게 배포하여 누구나 참조할 수 있도록 하는 것이다. 서점에서 팔고 각 학교의 전산과나 전산소 등에 배포하고 컴퓨터 잡지사에도 보내고 그러면 좀 더 많은 사람들이 볼 수 있을 것이다.

이제는 정신을 차려야 할 때

풍자적인 의미로, 걸레는 빨아도 걸레라는 말이 있다. 이 말에 꼭 맞는 일을 지금 공진청에서 하고 있으니, 그것은 다름 아닌 지금 있는 완성형 한글 코드 테이블을 확장하여 한글도 더 넣고 한자도 더 넣겠다는 것이다. 지금 있는 코드 테이블도 엉망인데, 거기에 더 추가해 놓으면 무슨 재주로 정렬을 할 것이며(물론 정렬하는 문제는 해결이 가능하다. 프로그램에서 예외상황 처리를 해 주면 되니까. 그러나 초보자는 어떻게 할 것이며, 어린 학생들에게 뭐라고 이해를 시킬 것인가?) 또 ISO-2022의 코드 확장법에 따라 ESC 코드에 의한 코드 영역 변경을 행하게 되면, 이제는 진실로 한글의 종류에 따라 한 화면에 표시가 되지 않는 문제는 누가 해결을 할 것인가? 때로는 가장 쉽게 할 수 있는 일을 가장 어렵게 하려고 애쓰는 바보와 무엇이 다르겠는가.

얼마전 조선일보에 현행 한글 코드의 문제점에 대한 글이 발표된 적이 있다. 한컴퓨터 연구소의 강태진씨가 쓴 글로 인해 공진청 등 관련 기관에 상당한 파문을 일으켰다. 또한 비슷한 시기에 공진청에 진정서가 한 장 들어 갔는데, 전자출판연구회에서 한글 코드를 조합형으로 해 줄 것을 요구하는 내용이었다. 필자는 이 진정서가 공식적으로 한글을 조합형으로 하자고 하는 첫 진정이었다는 이야기를 듣고 깜짝 놀랐다. 아니 우리가 그동안 탁상공론만 했다는 것인가? 이제 우리는 자손만대에 있어 크나 큰 오류를 저지르지 않기 위하여 조합형을 따내야만 한다. 그러기 위해서는 힘을 모아야 한다. 힘이란 함께 모여 조직을 이루었을 때 생긴다. 서로 이해 관계에 얽히지 않고 의견을 하나로 수렴, 통일된 목소리를 내야 한다. 여기저기서 탁상공론을 벌일 때는 이미 지났다. 이제 지금까지의 역량을 모아 진정서도 내고 서명 운동도 벌이는 등 코드 통일을 바로 성취하기 위한 모든 노력을 강구해야 할 것이다.필자가 존경하는 전 고려대학교 교수 김용옥 선생의 글 중에 중간세대라는 말이 나온다. 이 중간세대는 민주화 과정의 중간 역할을 할 수 있는 사람들로 30~40대 정도의 나이에 기성세대의 장점을 취합할 수 있고, 젊은 세대의 패기를 잃지 않을 수 있는 그런 세대가 이 나라 민주화의 역점이 되어야 한다는 것이다. 이 글을 쓰면서 전산계에서도 그러한 과정이 필요하다는 생각이 들었다. 전산계는 수명이 짧으므로 30대가 중간세대의 역할을 하여 기성세대가 가진 장점을 받아들이고 젊은 세대의 참신한 아이디어를 지지해 줄 수 있는 그런 역할이 필요하다.