Global Software

유전자 비율의 보존에 대한 하디-바이베크로 법칙대로 그리고 조엘이 언급한대로 변하지 않는 비율중의 하나는 Global Software에 대해 이해하고 있는 프로그래머의 비율이다. 이는 많은 비율의 서구에서는 굳이 고려하지 않아도 경제적 손실이 크지 않다 - 즉 별로 상관없다 - 는 점에서 기인하는 것이겠으나 사실 딱히 우리나라 라고 낫지는 않다. 

GS의 Global이란 의미는 크게 2가지로 나눌수 있는데 첫째는 Territory 지원 둘째는 Lanaguage 지원이다. 

Territory(영역) 지원은 문화적 차이에 의한 지원 기능이다. 예컨데 첫째 요일이 월요일이나 일요일이냐가 서로 다르고 2009년의 1월의 첫째주를 1-3일로 보느냐 혹은 4-10일로 보느냐도 서로 다르다. 날짜 포맷이 05/08/10라고 했을때 이를 2005년 8월 10일로 해석하는 나라도 있고 2010년 5월 8일로 해석하는 나라도 있다. 中華民國94年07月21日 같은 날짜 포맷도 있다. 가까운 일본의 경우만 봐도 에도 몇년 혹은 쇼와 몇년 식의 정권을 기준으로 삼은 날짜 포맷도 있다. 
숫자의 경우 동양은 만단위로 끊는 2,000.00 이 익숙하지만 서양은 천단위인 20,000.00 으로 사용한다. 게다가 20.000,00(오타가 아니다) 같은 포맷을 사용하는 터키같은 나라도 있다. 영역지원이 되는 대표적인 소프트웨어는 윈도우와 오라클이 있다.


이 포스트의 주요 내용인 Language 지원은 어찌보면 간단하기도 달리 보면 복잡하기도 한 문제다. 언어 지원에 대해 많이 나오는 Term들은 인코딩, 디코딩, ContentType, ISO-8859-1, 이메일(브라우저)이 깨져 보여요, UTF-8, Unicode, UTF32, Cdoe 947, i18n, NLS-Lang, KO16MSWIN949, KSC5601 등등 매우 많다. 이 얘기는 IT에서 언어지원의 역사가 그리 순조롭게 진행되지 않았다는 뜻이기도 하다.

실제 컴퓨터는 문자 그 자체를 저장하는게 아니고 전기신호를 통한 이진 비트를 통해 정보를 저장한다. 그래서 인코딩-디코딩 영어 그대로 해석하자면 문자를 비트를 통해 코드화 시키는 것을 인코드라고 하고 반대로 코드를 화면에 문자로 보여주는 것을 디코드라고 부른다. 여기서 중요한 점은 인코드와 디코드 방식이 동일해야 문자를 제대로 표현할 수 있다는 점이다. 예컨데 A를 65(0100 0001)라고 인코드 시켰으면 디코드시에 65는 A라고 읽어야 하는 상호 합의의 약속 같은 것이다.

컴퓨터가 처음 발명된 구미에서는 알파벳과 약간의 특수문자만 사용해도 충분했기 때문에 1byte=8bit의 00-FF까지의 256개의 코드를 사용해도 충분했었다. 아니 오히려 남았기 때문에 00-7F 까지의 128개만 사용하는 ASCII라는 코드 페이지를 가지고 있었다. 문제의 시초는 10000000 - 11111111 까지의 여분이었다. 많은 사람이 128-255 사이에 위치한 코드에 대해 지엽적인 생각으로 몇몇 강조문자와 선그리기 문자따위에 사용하였다. 미국 이외의 지역에 PC는 각종 OEM 문자 집합을 지역적으로 정의하였기 때문에 컴퓨터간 문자호환은 되지 않았다. 여기까지는 비교적 상식이다

아시아권으로 넘어오면서 문자체계는 더욱 복잡해졌는데 알파벳이 아닌 수천개의 문자를 저장해야 했으므로 1byte로 문자를 저장하긴 무리였다. 그래서 다소 이상해보이지만 첫번째 비트가 1이면 2byte를 묶어서 하나의 문자를 표현하고 첫번째 비트가 0이면 1byte 문자를 표현하는 DBCS라는 인코드 방식이 생겼다.(물론 이전의 ASCII 문서의 호환을 위해서이다.) 이를테면 16bit로 표현했을때 B0 A1 41 은 B0는 첫째 비트가 1이므로 B0 A1은 묶어서 디코딩을 하고 41은 첫째 비트가 0 이므로 41 한 바이트만을 디코딩해서 "가a"로 해석하는 방식이다.

그러나 앞서 말했듯이 인코딩과 디코딩 방식은 서로 합의가 되어 있어야 한다고 했는데 "가"를 "B0 A1"으로 디스크에 저장하는 인코딩과 디스크에 저장되어 있는 "B0 A1"을 "가"로 표현하는 디코딩 방식은 한국에서 사용하는 방식일뿐 일본은 일본 나름대로 중국은 중국 나름대로의 각기 다른 인코딩과 디코딩을 사용했기 때문에 여전히 지역적으로 다른 컴퓨터간의 문서 교환은 불가능했다. 머 그렇다라도 현실적으로 지역이 다른 컴퓨터간 문서교환은 그리 자주 일어나지 않았기 때문에 그리고 소프트웨어를 다른 나라에 팔때 이런 노가다식의 코드 변환 작업을 해주는 누군가가 있었기 때문에 크게 불편을 느끼지 않았다. 게다가 컴퓨터를 사용하는 인구는 아주 소수였기 때문에 이런 문제는 널리 인지되지는 않았다.

이 시기에 우리나라에서는 2byte를 패리티 1bit + 초성 5 bit + 중성 5 bit + 종성 5bit로 표현하자는 조합형 한글과 패리티 1bit + 그냥 15bit 코드로 사용하자는 완성형 한글 사이의 표준 다툼이 있었는데 당시 대표적인 아래아 워드 프로세스는 조합형 한글을 밀고 있었고 MS 워드는 완성형 한글을 지원하고 있었다. 국문학 대학 교수들도 사설을 통해 우리나라 문자는 조합형 한글이 더 적절하다고 주장하였지만 컴퓨터가 단순히 국내에서만 사용되는 것은 아닌 만큼 상대적으로 복잡한 코드 표현방식과 한글이 아니지만 자주 사용하는 다른 글자를 표현하는데 문제(즉 16bit가 모두 한글을 코드화하는데 사용되면 다른 그림문자나 한문등은 어떻게 해야 하는문제가 있다.)가 있었던만큼 승패는 이미 예견된 것이었다.

많은 사람들이 이때 MS Word의 로비나 밀어붙이기식의 방법때문에 어쩔수 없이 완성형 한글이 도입된거라고 오해하지만 사실 컴퓨터를 하는 입장에서는 이후 네크웍을 통한 문자 교환을 생각하면 완성형 한글이 좀 더 적합한 방식이었다고 생각한다. 조합형 한글은 현재 한글의 모든 한글을 표현할 수 있었지만 워드 프로세스에서 자주 사용되는 한자나 특수문자 등을 표현하기 위해 추가적인 코드 페이지를 필요로 했고(1+5+5+5= 2byte였기 때문에 여유 코드가 없다.) 완성형 한글은 패리티 1비트를 제외하고 32000개의 문자집합을 영역별로 나누어 한글뿐 아니라 자주 사용되는 한자, 일본어, 특수문자 까지 2byte의 코드 페이지에 같이 담아둘수 있는 장점이 있는 반면에 "햏"이나 "똠" "믜" "먄" "숖" 같이 자주 사용되지 않는다는 이유로 코드화 되지 않는 한글은 사용할 수 없는 단점이 있었다.

한국의 완성형과 조합형 같은 지역적인 문제들은 다른 아시아권에서도 마찬가지긴 했지만 그 해결책이 완벽한것은 아니더라도 어쨌든 그럴듯하게 작동하였고 컴퓨터에서 문자를 표현하는 문제는 잠시 해결된듯 보였지만 사실 더 큰 문제를 내포하였다.. 컴퓨터가 네트워킹화 되고 인터넷이라는게 생기면서 컴퓨터간 문자 교환의 문제는 지역간에 서로 다른 인코딩과 디코딩은 심각한 문제가 되었다. 이전까지 각 나라에서는 자기 나라만의(혹은 나라에서도 몇가지 계파로 갈라지거나) 인코드 디코드 코드 페이지를 사용하였는데 당연히 다른 나라 컴퓨터와 통신시 A나라에서 A'라는 인코등 방식을 사용해 글자를 보내면 B 나라에서는 B'라는 디코딩 방식으로 문자를 표현할려고 하였으므로 제대로 된 문서로 보이지 않았다. 특정 텍스트 파일의 인코딩 방식은 텍스트 파일 자체에 저장된 것이 아니었기 때문에 어떤 글자나 텍스트를 읽을때 어떤 디코딩 방식을 사용해야 할지 알수 없으므로 모든 글자는 ?로 표현되거나 알수 없는 - 소위 깨진 글자로 보이게 된다.


다음에..