김 용묵의 절대공간 - 블로그

오늘날처럼 컴퓨터의 문자 인코딩이 유니코드로 천하통일이 되기 전엔 국내에서는 2바이트 완성형과 조합형 한글 코드 논란이 가라앉지 않고 있었다. 완성형은 94*94 격자 모양의 단순하고 국제 규격에 부합하는(?) 방식으로 인코딩돼 있었지만 한글의 구성 원리를 무시하고 한글을 난도질했다는 비판을 떠안고 있었다.

완성형은 “한글 vs 비한글”을 구분하고 처리하는 데 유리했다.
그에 비해 민간에서는 “한글 글자 vs 낱자”의 처리가 더 용이한 조합형이 훨씬 더 대중적으로 쓰였다. 그도 그럴 것이 640KB 기본 메모리를 1KB라도 더 확보하려고 목숨 걸던 시절, 메모리 모델이 어떻고 far 포인터가 어떻고 이러던 시절에.. 한글 처리를 위해서 2350자 테이블을 내장하고 다닌다는 건 성능과 효율로나 민족 정서(?)로나 도저히 용납할 수 없었기 때문이다.

허나, 명목상 국가 표준은 완성형이었기 때문에 마소 역시 도스와 Windows의 한글판을 전적으로 완성형 기반으로 만들었다. 완성형은 두벌식과 마찬가지로 그 시절에 소프트웨의 한글판을 필요 이상으로 더 무겁게 만든다는 비판을 피하기 어려웠다. 다만, 이건 애초에 우리나라에서 표준을 이상하게 만든 게 잘못이지 마소의 잘못은 아닐 것이다.

Windows 3.1이야 이런 배경에서 만들어졌기 때문에 한글 IME로 똠, 펲 같은 글자가 입력되지 않았으며, 또ㅁ, 페ㅍ이라고 글자가 풀어졌다. ‘썅’은 2350자에 속해 있는데 중간의 ‘쌰’는 그렇지 않기 때문에 ‘썅’까지 덩달아 입력할 수 없는 것은 유명한 사실이다.

그리고 처음부터 ‘쌰’를 입력하면 ‘ㅆㅑ’라고 잘 갈라지는데, 두벌식에서 ‘있’ 다음에 ㅑ를 입력하면 ‘이ㅆㅑ’가  되지 않고 뭔가 올바른 동작이 나오지 않았던 걸로 본인은 기억한다.
이런 것들이 한글 입력기, 특히 특정 문자 입력 제한이 걸린 두벌식 입력 방식을 구현할 때 고려해야 하는 복병이다. 날개셋이야 이 분야 전문이기 때문에 그런 것들도 다 정상적으로 처리해 준다.

그럼 차기 버전인 Windows 95는 상황이 어땠을까?
Windows 95는 오늘날 세계 표준 문자 집합 겸 인코딩인 유니코드, 특히 유니코드 중에서도 버전 2.0이 한창 제정되고 있던 와중에 개발되고 먼저 출시되었다. 이건 굉장히 중요한 사건이었다.

우리나라에서는 수 년 전 유니코드 1.x 시절에는 완성형 2350자만 그대로 제출하는 삽질을 저지른 적이 있었다. 그러다가 유니코드 2.0에서 문자 체계를 싹 재정비하는 인류 역사상 마지막 기회가 찾아왔을 때.. 한글을 11172자 모두 순서대로 등록하려는 과감한, 역사적인 계획을 세웠다. 그래야 글자 코드값으로 자모 정보를 쉽게 추출할 수 있기 때문이다.
이건 스타에다 비유하자면 종족 밸런스를 앞으로 다시는 바꾸지 않는 1.08 패치와 비슷한 타이밍이었다.

그런데 그렇게 하려면 세계를 설득해야 했다.
다른 나라들은(특히 일본과 중국도) BMP 영역의 1/5 가까이를.. 그것도 사용자가 1억도 채 안 되는 언어의 고유 문자로 싹 도배하려는 한국을 고깝게 보고 이의를 제기했다.
유니코드 회의에서 누가 발언권을 얻으려면 한화로 억대에 달하는 회원 등록비도 많이 내야 하는데, 이런 비용을 한컴 같은 기업에서 많이 후원해 줬다. 저 때는 삼성전자도 훈민정음 워드 같은 프로그램이나 간간이 만들었지, 지금 정도로 IT계에 세계구급 영향을 행사하는 기업이 아니었다는 걸 생각해 보자!

이런 우여곡절 끝에 한글 11172자는 1996년 7월, 유니코드 위원회의 승인을 받아서 성공적으로 등재되었다. 이거 내막을 아는 사람이라면 이것도 1981년 서울 올림픽 바덴바덴의 기적에 맞먹는 외교 승리라고 여기고 칭송한다. 올림픽은 52:27의 압승이라도 했지만 11172자 등재는 찬성이 반대를 한 표 차이로 정말 간신히 꺾은 거라고 한다.

그런데 문제는 Windows 95는 유니코드 2.0이 정식으로 발표되기 미묘하게 약간 전에 출시되었다는 것이다. 한글판도 1995년 11월 말에 출시됐으니..;;
그럼에도 불구하고 각종 글꼴과 코드 변환 테이블은 이미 유니코드 2.0을 기준으로 맞춰져 있다. 어떻게 이게 가능했을까?

유니코드 2.0에다가 한글을 2350자가 아니라 11172자를 몽땅 집어넣기 위해서는.. 근거가 필요했다. 유니코드가 아닌 기존 2바이트 인코딩 중에도 한글 11172자 표현이 가능한 놈이 있어야 했다.
그럼 Windows가 처음부터 조합형 코드로 개발됐으면 좋았겠지만 모종의 이유로 인해 그리 되지 못했고.. 결국은 기존 완성형에다가 지저분한 독자적인 편법을 동원해서 비완성형 한글을 끼워넣을 수밖에 없었다.

이게 그 이름도 유명한 확장완성형, 일명 CP949 인코딩이다.
KS X 1001은 한글 2350자, 한자 4888자 등을 포함하는 그 2바이트 완성형 문자 집합/코드이고, KS X 1003은 역슬래시를 원화로 대체한 그 한국 특유의 1바이트 영문/숫자 아스키 문자 집합이다. 이 둘을 합쳐서 EUC-KR이라고 부르고, 여기에다가 확장완성형까지 추가하면 CP949가 된다. 집합 관계를 정리하자면 (KS X 1001 ∪ KS X 1003) = EUC-KR ⊂ CP949이다.

(참고: KS X 1002는 완성형 형태로 현대 한글, 옛한글, 한자를 추가로 정의하는 규격이다. 하지만 KS X 1001과 병용하는 인코딩 규칙이 제정되지 않아서 컴퓨터에서 실제로 쓰인 적은 없는 캐잉여이다. 얘는 애초에 유니코드 1.1에다가 글자를 추가로 등록할 근거를 마련하려고 어거지로 만든 문자 집합에 지나지 않는데, 이제는 유니코드 1.1 자체도 오래 전에 흑역사가 됐으니 더욱 의미와 존재감이 없다.)

이렇듯, 확장완성형이라는 건.. 비록 처음에 첫단추를 잘못 끼우긴 했지만 뒤늦게 유니코드 2.0에라도 한글을 11172자를 순서대로 다 집어넣기 위해서 도입한 2바이트용 타협 절충안이었다. 마소에서는 한국 편을 들면서 도와 주면 도와 줬지, 최소한 상황을 더 나쁘게 만든 건 절대 없었다.

그럼에도 불구하고 1990년대 당시에는 마소에서 완성형에다가 그보다 더한 확장완성형까지 집어넣어서 한글을 난도질한다고 엄청난 논란이 일었다. 심지어 한컴에서도 아래아한글 도움말 및 제품 광고에서 이 괴담을 어느 정도 활용하고 부추겼다.

왜 한글을 난도질 하느냐 하면, 확장완성형은 이미 2350가 조밀하게 순서대로 배치된 건 그대로 유지하면서 나머지 틈새에다가 비완성형 8822자를 집어넣는 형태가 되기 때문이다. 그러면 겉보기로는 11172자가 모두 배당되지만 문자의 코드값 순서가 그 문자의 사전상의 배열 순서와 일치하지 않게 된다. 사전 순 정렬을 하려면 코드값을 별도로 보정을 해야 한다.

물론 코드값만으로 문자를 정렬할 수 있는 게 가능하지 않은 것보다는 더 직관적이고 깔끔하고 낫다. 하지만 오늘날 유니코드는 시간 차를 두고 뜬금없이 여기저기 지저분하게 추가된 문자들이 워낙 많기 때문에(특히 한자~!!), 거시적으로 봤을 때 코드값만으로 문자들을 정렬하는 건 어차피 불가능하고 무의미해져 있다.

뭐, 이것도 논란이 다 끝난 오늘날의 관점에서 보니까 별것 아닌 것처럼 보이지, 2바이트 한글 코드만 단독으로 생각하던 시절에 확장완성형이 답답하고 지저분하게 보이는 것도 부인할 수 없어 보인다.
그리고 마소는 훗날 IMF 때 경영난에 빠진 한컴에다가 돈줄을 대 주는 대신 아래아한글의 개발을 중단시키려 했던 바 있다. 그러니 확장완성형에 대한 불필요한 오해 실드를 감안하더라도 마소에 대한 국민 감정이 마냥 좋을 수만은 없었을 것이다.

아무튼, 그 시절 Windows 95는 유니코드 2.0의 정식 도입을 선도하면서 온전한 한글 11172자의 입출력이 가능해지려는 과도기에 연결 고리 역할을 했다.
참고로 95 말고 Windows NT는 도스 짬뽕이던 기존 Windows와 달리, 1993년 첫 버전부터 2바이트 wide char 유니코드 기반이었다. 얘도 유니코드 2.0이 정착할 무렵이 돼서야 본격적으로 정식 한글판이 나올 수 있었다. 3.51부터 말이다.

Windows NT 3.5 한글판의 ‘베타 버전’ 평가판. 이건 Windows NT의 역사상 최초로 만들어진 한글판으로, 정말 엄청난 희귀 레어템이다. 마치 Windows 2.x의 듣보잡 한글판처럼 말이다.

저 화면에서 한글 글꼴은 기존 Windows 3.1의 돋움체(큐닉스 제작) 8포인트이다. 하지만 영문은 정체를 모르겠다. W와 i의 폭이 다른 가변폭인 걸 보니 같은 돋움체의 영문은 아닌데, Arial은 물론이고 심지어 후대에 등장한 Tahoma나 Verdana까지 그 어떤 영문 글꼴도 저 크기에서 9나 5의 획이 저렇게 생기지 않았다.

그런데 저 영문 모양이 내가 보기에 전혀 낯설지는 않다.
마소에서 개발한 1990년대 옛날 프로그램의 스플래시 화면 내지 About 대화상자에서 Copyright 문구가 저런 스타일의 글꼴로 표시된 걸 본 것 같기도 한데.. 정확한 정체는 모르겠다.

내 기억이 맞다면 Windows NT 3.51의 정식 한글판은 3.51의 특성상 Windows 3.1과 같은 구형 UI 기반임에도 불구하고 한글 글꼴은 이미 Windows 95 한글판과 동일한 한양 시스템 글꼴로 갈아탔다.
Windows NT의 역사에서 유니코드 1.1 방식 한글이 존재했던 적은 내가 아는 한 없다. 만에 하나 있다면 그건 조합형 코드를 잠깐 썼었다고 전해지는 MS-DOS의 초창기 한글판만큼이나 완전 전설 속에나 존재하지 싶다.

이렇게 95건 NT건 온전한 11172자짜리 유니코드 2.0 기반임에도 불구하고.. 95의 한글 IME를 써 보면.. 구버전인 Windows 3.1과 마찬가지로 여전히 2350자밖에 입력할 수 없었다. 다만, “있+ㅑ”일 때는 ㅆ이 뒷글자로 넘어가지 않도록 로직이 약간 개선돼 있었다.;; ㅎㅎ

사실, Windows 95의 한글 IME는 확장완성형을 기반으로 11172자를 모두 입력하는 기능도 구현은 돼 있었다. 하지만 그걸 기본적으로는 봉인해 놓았으며, 사용 여부를 별도의 유틸리티를 통해 따로 지정할 수 있었다!
바로, C:\Windows 디렉터리에 있는 iso10646.exe라는 30KB짜리 자그마한 프로그램이다. 역시 괜히 과도기였던 게 아니다.

프로그램 UI에는 유니코드니 완성형이니 같은 말은 없고 그냥 "ISO 10646 사용 여부"가 전부였다. 유니코드의 문자 집합을 가리키는 표준 규격 명칭이 ISO 10646이기 때문이다.
전체 사용 아니면 특정 프로그램에서만 사용.. 이런 걸 지정해 주면 타 프로그램에서 똠쌰 등등의 글자를 입력할 수 있었다.

신기한 것은 Windows용 프로그램뿐만 아니라 도스용 mshbios의 한글 입력기까지 이 설정의 영향을 받았다는 것이다. 설정값을 레지스트리가 아니라 파일에다 저장했던가 보다. 아니면 도스에서도 레지스트리 파일에 저수준으로 접근을 했던지..

확장 한자의 사용 여부를 옵션으로 지정하는 것처럼 2350/11172자 입력 범위도 그냥 IME의 옵션으로 지정하면 됐을 것 같은데 굳이 별도로.. 제대로 문서화되지도 않은 프로그램에다 저렇게 꽁꽁 숨겨 놨다.
부작용을 어지간히도 의식했는지 각종 프로그램별로 입력 범위를 달리 지정할 수 있게 신경을 썼다. 즉, 여느 평범한 IME 옵션이 아니라.. 날개셋으로 치면 응용 프로그램별 동작 보정 옵션과 비슷한 걸로 취급한 것이다.

훗날 MS Office 97이 나왔고.. 그 중 Word는 단품으로 따로 팔기도 했다.
마소 역시 한컴 진영의 조합형 한글 마케팅을 많이 의식했는지, 신문 광고에서 조그맣게.. "우리 마소 제품에서도 똠방각하 펩시콜라 찦차를 입력할 수 있습니다." 문구와 함께, iso10646 프로그램 사용법을 소개해 놓기도 했었다.

본인은 학창 시절에 그 광고를 직접 본 기억이 있다.
지금도 구글에서 iso10646.exe 라고 검색해 보면 옛날 흔적을 찾아볼 수 있다.

마소의 전략은.. 요런 프로그램을 몰래 집어넣은 뒤, 확장완성형이 계속 부정적인 피드백을 받으면 Windows 95는 그딴 거 지원한 적 없다고 발뺌 하면서 2350자 기존 완성형에만 머무르면 될 것이고,
한글을 2350자밖에 입력 못 한다고 욕먹는 게 더 크면, 저 비장의 프로그램을 음지에서 양지로 끄집어내려는 속셈이었던 것 같다. 쉽게 말해 간보기 전략이다.

그러다가 Windows 98부터는 이런 간보기가 없어지고 그냥 모든 프로그램에서 확장완성형까지 활용한 11172자 한글 입력이 되기 시작한 것이다. 나중에 Office 2000과 함께 옛한글 입력기가 도입됐을 때는 이제 마소의 제품이 옛한글의 표현 능력도 아래아한글 97과 한컴 2바이트 코드를 추월하게 됐다.

이상이다. “라떼는 말이야” 같은 얘기가 좀 길어졌다.. ^^
25년 전, Windows 3.1에서 95로 넘어간 것은 정말 엄청난 격변이었다. 하지만 Windows 95와 98 사이에도 컴퓨터 환경은 굉장히 많이 바뀌었다.
가정용 PC의 평균 램 용량이 4~16MB대이던 것이 그 짧은 기간 동안 32~128MB로 순식간에 뻥튀기 됐다. PC 규격도 이것저것 많이 바뀌고.. 또 무엇보다도 이 사이에 유니코드 2.0이 제정되었다. 운영체제 차원에서 UTF-8 인코딩이 직접 지원되기 시작한 최초의 Windows가 바로 98이다.

Windows에서 완성형 2350자에 구애받지 않고 한글 입력이 가능해지기까지 이런 우여곡절이 있었다.
Windows 98은 현대 한글이 완전히 해금됐고, 지난 Windows 8 (2012)부터는 옛한글까지 해금됐으니 참 격세지감이다. 그 사이의 XP는 입력 프로토콜이 IME에서 TSF로 넘어간 과도기였고 말이다.

그런데 정작 옛한글 말뭉치를 엄청나게 많이 구축한 21세기 세종 계획은 이것보다 미묘하게 일찍 진행된 바람에 비표준 한양PUA 방식으로 결과물을 산출해 버렸으니 타이밍이 안습했던 구석이 있다.

Posted by 사무엘

유니코드 1.x가 제정되었을 때는 믿거나 말거나 한글도 글자마디는 완성형 몇천 자만 지금과는 딴판의 영역에 등록되어 있었다. 단, 글자마디뿐만 아니라 옛한글을 포함한 자모도 자음 134개(물론 초성과 종성의 개수는 서로 다르고 따로 등록됨), 모음 66개가 등록되어서 이 자모들을 아래아한글 2.x가 한컴 2바이트 코드에서 그대로 채택해서 썼다. 한컴 2바이트 코드는 기존 조합형 코드와 유니코드를 적당히 짬뽕한 문자 코드였던 것이다.

유니코드는 첫 도입 배경이 저렇다 보니 “유니코드 = all 2바이트 단일 문자 체계 = wide character 문자 체계”라고 혼동하는 사람이 적지 않다. 그러나 이는 개념적으로 올바른 관계가 아니다. 2바이트 문자 체계로만 치자면 한컴 2바이트 코드도 이에 해당하며, 윈도 이외에 유닉스 계열 OS에서는 wide character는 16비트가 아니라 32비트인 경우도 있다. 왜 32비트이냐 하면 6만 5천여 개라는 집합 크기도 시간이 흐르다 보니 부족해졌기 때문이다.

1996년에 유니코드 2.0이 제정되면서 유니코드는 오늘날 우리가 아는 유니코드와 같은 뼈대가 갖춰졌다. 한번 등록한 문자는 이제부터 재배치나 제거 없이 영구불변으로 굳히기로 했으며, 이때 현대 한글 글자마디 11172자가 순서대로 고스란히 등록되었다. 2바이트 조합형처럼 비트 연산은 못 쓰지만 그래도 테이블 없이 뺄셈과 나눗셈, 나머지 연산으로 한글의 자소 정보를 얻을 수 있으니, 과거 조합형 한글 코드의 장점을 유니코드에서도 물려받은 셈이다.

외국 위원들의 반대를 무릅쓰고 한글에다 유니코드의 금싸라기 영역을 이만치 할당 받기 위해 한국 위원회 사람들이 애를 많이 썼다. 사실 확장완성형도 유니코드 등록 근거를 대기 위해 급히 만들어진 것이라고 한다.
이와 더불어 유니코드 2.0에서는 중요한 개념 내지 꼼수가 추가로 도입되었는데, 바로 surrogate이다.
16비트 공간 중 일부 영역은 그대로 쓰지 말고 따로 떼어 내서 두 글자를 뭉쳐서 더 많은 종류의 글자를 표현하는 데 쓰자는 것이다.

0xD800부터 0xDBFF는 high surrogat이고, 0xDC00부터 0xDFFF까지는 low surrogate이다. high는 언제나 앞에, low는 언제나 뒤에 오는 식으로 역할이 딱 고정되어 있다. 1024개의 앞짝과 1024개의 뒷짝이 만나니, 총 2048개의 독립 글자를 희생하여 2의 20승, 약 100만여 개의 글자 공간을 추가로 확보할 수 있게 된다. 요컨대 유니코드에 U+D800 같은 글자는 없고, U+D7FF 다음에는 곧바로 U+E000이 이어진다. 그 대신 0xD800과 0xDC00이 만나면 U+10000이라는 surrogate, 즉 확장 평면이 시작될 뿐이다. 예전의 16비트 단일 영역은 '기본 다국어 평면'(BMP)이라고 불리게 되었다.

비록 과거의 1바이트/2바이트 혼합 체계보다는 사정이 훨씬 낫고 문자열 처리가 수월한 건 사실이지만, 어쨌든 유니코드도 확장으로 인해 2바이트 단일 표현(UCS2)이라는 깔끔한 장점은 포기해야 하게 되었다. 이쯤 되니 유니코드라는 개념에서 문자 코드와 인코딩을 구분해서 표현해야 할 필요가 생겼다.

유니코드 자체는 UCS, 즉 universal character set이라 불리는 단일 문자 집합이다. 얘는 '가'라는 한글 글자에다가 U+AC00이라는 코드값을 부여해 줄 뿐, 그 코드값이 메모리나 파일에 어떻게 표현되는지에 대해서는 규정하지 않는다. 이를 표현하는 방식이 바로 Unicode transfer format, 즉 인코딩이 된다.

모든 유니코드 번호를 아무 뒤끝 없이 32비트 정수 하나로 균일하게 표현하면 그것은 UTF32이다. 아까 wide character가 4바이트인 플랫폼은 바로 UTF32를 구현하는 자료형인 것이다. 가장 깔끔하고 공간도 넉넉하고 모든 글자를 하나씩 쉽게 접근할 수 있지만 한 글자가 4바이트나 차지하여 메모리 낭비가 심하다.

BMP 영역에 있는 놈은 종전대로 16비트 정수 하나로 표현하고 확장 평면에 있는 놈만 surrogate 두 개로 쪼개서 표현하는 방식은 UTF16이라고 불린다. UCS2를 개념적으로 확장한 것이기 때문에 처음부터 2바이트 wide character를 표방하며 개발된 Windows 플랫폼이 매우 사랑하는 방식이다. 비록 Windows의 wchar_t는 이제 유니코드 코드 포인트 하나를 온전히 표현할 수 있을 정도로 충분히 크지 못한데도 말이다.

끝으로, 그 이름도 유명한 UTF8이 있다. 얘는 U+007F 안에 드는 전통적인 알파벳· 숫자, 제어 문자들은 1바이트로 유지하고, 나머지 BMP 영역의 외국어들은 2~3바이트로 표현하고 surrogate는 BMP와 동일한 4바이트로 늘여 표현하는 진정한 multibyte 인코딩이다.

n째 문자를 찾는 무작위 접근은 안 되겠지만, Windows NT처럼 커널을 처음부터 16비트 문자 단위로 설계하지 않고도 기존 8비트 문자 시스템에서 유니코드를 단절감 없이 표현할 수 있다는 엄청난 장점이 있다. CPU의 엔디언(비트 배열 순서)의 영향을 받지 않으며, tail byte가 기존 영문· 숫자와 충돌을 일으키지도 않는다는 점도 좋고 말이다.
그래서 얘는 웹에서 매우 사랑받고 있고 윈도 이외의 플랫폼에서는 파일뿐만 아니라 메모리 저장용으로도 UTF8이 즐겨 쓰인다. 사실 윈도만 이례적으로 UTF16을 너무 사랑하고 있는 것이고.. ㅎㅎ

여담이지만 UTF32, 16, 8 중 유니코드의 문자 집합이 먼 미래에 또 확장되어야 할 때, 공간이 가장 넉넉하게 남아 있는 놈은 두 말할 나위 없이 UTF32이다. UTF8이야 애초부터 들쭉날쭉 가변 길이 인코딩을 표방했기 때문에 한 글자당 4바이트보다 더 긴 5~6바이트까지 약간 더 확장할 여지가 있다. 지금 당장은 그것까지는 쓰이지 않지만 말이다.

하지만 UTF16은 유일하게 확장의 여지가 전혀 없다. 지금 surrogate 영역이 다 차 버리면 surrogate의 surrogate라도 또 만들지 않는 이상 답이 없다. 그리고 그런 헛짓을 할 바에야 차라리 UTF16을 폐기하고 UTF8 아니면 UTF32로 갈아타는 게 낫지..;; 이런 미묘한 면모가 있다.

다만, 한글 표현의 관점에서는 메모리가 가장 적게 드는 인코딩이 UTF16이라는 것도 감안할 점이다. 현대 한글 글자마디의 경우 UTF8은 3바이트, UTF32는 4바이트이지만 UTF16은 2바이트다. 초-중-종성이 모두 갖춰진 옛한글이라면 UTF8과 UTF32는 각각 9바이트, 12바이트를 차지하지만 UTF16은 6바이트이니 차이가 더 벌어지게 된다. 유니코드에는 한글이 완성형(글자마디+호환용 자모) 방식과 조합형(세벌 한글 자모) 방식이 모두 등록되었으며 완성형 방식도 11172자가 순서대로 모두 등록되었으니, 예전의 조합형· 완성형 논쟁을 완전히 종결짓는 데 성공했다.

Windows NT도 처음에 개발될 때 문자 처리 단위를 wide로 무리해서 넓히느라 고생하지 말고, 그냥 UTF8만 도입했으면 어땠을까 싶지만 이제 와서는 다 지난 일이다. 아무래도 UTF8보다야 UTF16이 컴퓨터의 입장에서는 더 빠르고 간편하게 각각의 문자를 인식할 수 있으며, 이것이 메모리와 성능 소모면에서 UTF32와 UTF8 사이의 완충지대 역할을 해 온 건 부인할 수 없기 때문이다. 덕분에 Windows API의 관점에서는 UTF8조차도 native 인코딩인 유니코드 UTF16으로부터 '변환'되어야 하는 여러 multibyte 인코딩 중의 하나일 뿐이다~! ㅎㅎ

옛날에 인터넷 익스플로러의 버전이 5~6이던 시절엔 한글로 된 URL이 인식이 잘 안 돼서 맨날 “URL을 UTF8로 보냄” 옵션을 끄라는 지시가 팁처럼 공유되곤 했다. 당시엔 Unicode-aware하지 않은 웹 서버가 아직 많아서 말이다. 오늘날로 치면 UAC(사용자 계정 컨트롤)를 끄거나 팝업 창 허용 기능을 사용하는 것과 비슷한 편법이다.
하지만 요즘은 UTF8 방식 URL이 표준으로 정착한 지 오래다. 호환성을 중요시하는 IE에나 그런 옵션이 있지, 크롬 같은 브라우저는 선택의 여지 없이 무조건 UTF8이기도 하고 말이다.

유니코드는 문자 처리 기술의 발전과 함께 더욱 덩치가 커졌으며, 한편으로 더욱 복잡해지고 지저분해지고 있다.
UTF32가 아닌 인코딩으로는 어차피 메모리 배열 인덱스만으로 실제 글자 인덱스를 얻을 수 없는 것은 물론이거니와, 메모리 상으로 존재하는 글자 코드 포인트 수와, 화면에 출력되는 글자의 수도 일대일 대응이 전혀 이뤄지지 않게 되었다. 옛한글이라는 것도 유니코드 관련 기술이 방대해지면서 덤으로 같이 처리 가능해졌을 뿐이다. 진짜 미치도록 복잡한 문자에 비하면 옛한글 쯤이야 양반이지... 동일한 글자를 나타내는 방법이 여러 가지 존재하게 되어서 정규화라는 것도 필요해졌다.

코드 포인트 값만으로 정렬을 하는 것 역시 상당수 의미를 잃었다. 옛한글 자모는 유니코드 5.2 때 한양 PUA 비표준에만 존재하던 것들이 추가 등록되었는데, 이것들의 코드 포인트상의 순서를 따지는 건 부질없는 짓이다. 가뜩이나 부족한 BMP 공간의 여러 틈새에 산발적으로 간신히 등록된 것 자체를 감지덕지해야 할 판이다.

한자는 더욱 가관이다. 유니코드에서 공간을 압도적으로 제일 많이 차지하고 있는 문자인 건 두 말할 나위도 없거니와.. BMP 영역에 이미 등록돼 있고 호환용 같은 이유도 없는데 작업자의 실수로 인해 나중에 surrogate 확장 평면에 중복 등록된 글자도 있고, 일본 문자 코드의 실수 때문에 문헌에 전혀 등장한 적이 없는 유령 한자가 등재돼 있기도 하다.

이것이 오늘날의 컴퓨터 문명을 지배하고 있는 가장 원초적인 규범에 속하는 유니코드의 현실이다. ㅎㅎ
수십 년 주기로 유니코드를 전면 reset하고 코드값을 재정리하면 어떨까 싶지만 그건 기존 컴퓨터 문명이 핵 전쟁 같은 걸로 폭삭 없어지지 않는 한, 상상 속에서나 가능한 일일 것이다.

Posted by 사무엘

디지털 컴퓨터는 전자 신호로 0과 1만을 인식할 수 있다. 그렇기 때문에 컴퓨터에서는 문자 역시 0과 1의 조합인 숫자로 표현되며, 문자를 그런 숫자에다가 대응시키는 규칙이 바로 문자 코드이다. 정보 교환을 원활히 하기 위해서는 보내는 쪽과 받는 쪽이 모두 문자 코드가 통일돼 있어야 함은 두 말할 나위가 없다.

정보량의 최소 단위는 1비트이지만 현실적으로 컴퓨터의 기억 장치들이 한 글자로 취급하는 정보량의 최소 단위는 8비트, 즉 바이트이다. 8비트, 2^8승, 즉 256이라는 정보량은 숫자와 알파벳을 정하는 데는 충분하고 상위 1비트를 잉여화하여 오류 검출용으로까지 사용할 수 있을 정도이지만, 한글이나 한자 같은 문자를 담는 데는 턱없이 부족하다.

한자는 글자를 체계적으로 부분글자로 분해할 뾰족할 방도가 없는 상태로 글자 수가 너무 많다. 한글은 글자 생성 체계는 한자보다 훨씬 더 유리한 위치에 있지만, 실용적으로 편하게 다루려면 여전히 1만여 개의 미리 조합된 음절 형태를 그대로 배당해야 한다.

예를 들어 현실에서 '학교'라는 단어는 두 글자로 간주되지, 데이터베이스나 문서 분량 같은 데서 5글자라고 계수되는 곳은 아무도 없다. 코드 차지 영역을 줄이자니 메모리 사용량이 늘며, 그리고 오늘날로 치면 화면에 보이는 글자 길이와 메모리를 차지하는 글자 길이가 서로 완전히 따로 노는 complex script 급의 복잡한 기술이 필요해진다.

결국 한글과 한자는 1바이트만으로 표현할 수 없고 통상 2바이트로 표현된다. 그런데 기존 1바이트 영문· 숫자를 건드릴 수는 없으니 1바이트와 2바이트 문자가 공존하는 multi-byte 코드 체계가 만들어진다. 영문권에서 패리티 비트 내지 유럽 특수문자를 표현하는 데 쓰이는 최상위 1비트는, 이 문자가 1바이트로 끝인지 아니면 2바이트 문자의 첫 바이트(lead byte)인지를 판별하는 비트로 쓰인다.
공교롭게도 한글· 한자는 폭도 균일한 2글자 분량을 차지하여 비주얼 상 잘 어울린다. 전각· 반각이라는 개념이 여기서 유래된다.

그런데 lead byte는 그렇다 쳐도 2바이트의 다음 둘째 바이트인 tail byte도 기존 순수 1바이트 문자들과(영문· 숫자 같은) 전혀 겹치지 않게 할 것인지? 아니면 어차피 얘는 lead byte에 의해 변별이 됐으니 좀 문맥 의존적으로 겹치는 걸 허용할 것인지가 문제가 된다. 한글 코드의 경우 완성형은 겹치지 않으나 조합형은 겹친다.

그렇기 때문에 조합형은 tail byte가 대문자 알파벳과 소뭇자 알파벳이 제각기 따로 될 수 있고 심지어 \ 역슬래시 문자가 나올 수도 있다. 이런 이유로 인해 조합형은 1비트 + 초중성 5비트씩 한글의 구성 원리를 매우 잘 반영하여 설계된 문자 코드임에도 불구하고 당시 8.3 제약이 있던 시절에 파일 이름을 사실상 한글로 지정할 수 없었으며, 심지어 이론적으로는 // 주석을 조합형 한글로 지정한 경우 \ 때문에 2-byte aware 하지 않은 컴파일러에서는 충돌이 발생할 수도 있었다.

옛날에 한글 MS-DOS 시절에 한글 도스 셸이나 QBasic처럼 텍스트 GUI(?)를 구현한 프로그램들을 실행해 보면 한국 마소가 굉장히 잘 만든 게 있었다. 메뉴나 대화상자 같은 게 표시되어서 배경에 있던 2바이트 텍스트를 반토막 내더라도 깨진 문자열을 보여주는 법이 결코 없었다. 늘 짝수 바이트가 유지돼야 하는 한글/한자 영역이 홀수 바이트로 줄어들면 가장자리를 하나 삭제해 주면 된다.

그러나 문맥 의존적인 문자 코드로 그런 걸 구현하려면 문자열을 처음부터 읽어 봐야 하고, 두 바이트 중 하나가 소실됐을 때의 뒷처리가 문맥 독립 코드보다 더 어려우면 어렵지 쉽지는 않을 것이다. 불가능하다는 뜻은 아니지만.

조합형을 옹호하고 완성형을 까기에만 바쁜 분들의 심정이야 세벌식+한글 에반젤리스트로서 본인은 적극 이해한다. 그러나 과거의 2바이트 한글 코드의 이면엔 이런 면모도 있었음을 지적하고자 한다. 완성형은 여러 이슈가 얽혀서 그렇게 만들어졌지, 작정하고 한글을 난도질하려는 악의적인 의도로 만들어진 건 아니었다. 문맥 독립성뿐만 아니라 굉장히 보수적인 국제 규격 권장 사항을 만족하는 방식으로 문자 코드를 만들려다 보니, 한글 11172자에다 한자와 각종 특수문자들까지 넣을 절대적인 공간 자체가 부족했기 때문이다.

나중에 완성형에다 어거지로 한글 부족분을 채워 넣은 cp949 확장완성형은 어차피 조합형처럼 문맥 독립성이 깨졌다. 물론, 어차피 이렇게 만들 거면 처음부터 조합형으로 가지 하는 비판은 피할 수 없게 된 게 사실이다. 그런데, 이런 비슷한 삽질을 일본도 문자 코드를 만들면서 했으며, 이를 우리나라도 그대로 답습했을 뿐이다.

조합형과 완성형은 11172자와 2350자의 차이뿐만 아니라 한글 낱자를 표현하는 방식에서 매우 큰 차이가 있다.
조합형은 글자마디와 자모의 차이가 사실상 없다. 그냥 초 중 종성 중 한 성분만 있으면 자모이고, 초성과 중성이 갖춰졌으면 글자마디이다. 초성 ㄱ과 종성 ㄱ을 구분해서 표현할 수 있고 초성+종성이나 중성+종성 같은 '미완성 한글'도 얼마든지 표현할 수 있다.

그러나 완성형엔 그런 개념이 없다. 한글 입력을 처음 시작했을 때 쓰라고 '호환용 한글 자모'라는 게 있는데 그건 한글이 아니라 명목상으로는 '특수문자' 영역이다. 그냥 한글 자모 모양인 그림일 뿐이다. 초성+종성 구분이나 미완성 한글 표현 같은 건 없다.

메모리 1바이트가 아깝던 16비트 도스 시절에 국내에서는 조합형 한글 코드+글꼴이 쓰였지 마소의 윈도처럼 2350자 완성형 코드+글꼴로 돈지랄을 하는 프로그램은 전혀 없었다. 이런 압도적인 인지도의 차이로 인해 조합형은 1992년에 한국의 복수 표준으로 승격되어서 cp1361이라는 이름으로 나름 운영체제의 코드 페이지에 등록도 됐다.

자, 이렇게 컴퓨터는 1바이트 인코딩에다가 한중일 문화권을 위한 1+2바이트 멀티바이트 인코딩 구도가 유지되었고 마소에서는 이를 도스 시절부터 코드 페이지라고 불렀다. 그런데 이런 문자 코드들은 (1) 알파벳· 숫자 같은 공통 문자를 제외하면 같은 문자라 해도 국가마다 배당된 코드값이 같을 수가 없고, (2) 문자 집합 자체의 크기가 너무 작아서 세계 모든 문자들을 한 코드 페이지에다 담을 수 없다는 문제가 있었다.

人(사람 인)이라는 한자가 한국· 중국· 일본의 표준 코드에서의 코드값이 같을 리가 없으니 (1)은 자명한 문제다. (2)의 경우, 2바이트 코드라 해도 앞서 보았듯이 1바이트 문자와의 충돌을 피하기 위해 매우 제한된 영역의 바이트들만 묶을 수 있다. 이 때문에, 문맥 의존까지 시킨다 해도 추가로 만들 수 있는 문자는 1만여 자에 불과하다. CJK에서 쓰는 상용 한자들이나 간신히 다 집어넣을 정도이다.

그래서 1980년대 말부터 이런 발상의 전환이 이뤄졌다. “앞으로 컴퓨터의 메모리는 증가하고 소프트웨어 국제화의 중요성은 커질 테니, 글자 하나의 크기를 16비트로 쿨하게 확장하고 6만여 자의 공간에다가 전세계 언어 문자들을 집어넣고 동일 문자 동일 코드값을 실현하는 게 어떨까?”

이것이 바로 유니코드의 존재 목적 되시겠다. 컴공 전공자가 아니더라도 컴퓨터에서 '유니코드'라는 말은 한 번쯤은 다들 들어 보셨을 것이다. 이건 그야말로 컴퓨터 문자 코드계의 바벨 탑 내지 에스페란토 같은 물건이다.

마이크로소프트는 소프트웨어의 국제화에 굉장한 혜안이 있던 기업이었다. 그래서 OS/2와 결별하고 Windows NT를 첫 개발할 때, 애초부터 8비트 문자가 아니라 유니코드를 담을 수 있는 16비트 문자를 기반으로 설계했다. 심지어는 NTFS 파일 시스템까지도. 그리고는 이를 독자적으로 wide character이라고 부르기 시작했다. 어차피 8비트 문자만으로 충분하던 라틴 문화권에서는 별로 득이 되는 것도 없이 메모리 사용량만 두 배로 뻥튀기되는 대가를 감수하고라도 말이다.

Win32 API는 기존 16비트 윈도 API를 최대한 닮게 설계되었지만, 문자열을 다루는 모든 API에 A 버전과 W 버전 구분이 생겼다. 다만, 32비트 시절에 처음으로 도입된 OLE/COM 같은 기술은 처음부터 오로지 유니코드(= wide) 문자열만 취급하게 만들어졌다.

PE 방식으로 만들어진 32비트 EXE/DLL은 string 테이블, 메뉴, 대화상자 같은 리소스의 저장 포맷도 다 유니코드 방식으로 바뀌었다. 윈도 3.1에다가 Win32s를 설치하면 32비트 커널 DLL뿐만 아니라 각종 코드 페이지 변환 테이블도 설치되는 걸 볼 수 있다. 그게 바로 리소스를 변환하기 위해서이다.

윈도 NT가 3.x나 9x보다 메모리 사용량이 매우 많았던 이유 중 하나도 유니코드 때문이며, 반대로 윈도 9x가 유니코드 API를 지원하지 않았던 이유도 가정용 PC의 부족한 메모리 문제 때문이다.
이 때문에 컴파일 스위치만 바꿔서 유니코드와 기존 멀티바이트를 모두 커버할 수 있는 TCHAR, _T 같은 개념도 그때 생겼다. 두 개의 문자 포맷을 모두 지원하는 작업은 정말 엄청난 대공사였을 것 같다.

Posted by 사무엘