리눅스와 한글문제-아직 작성중

제목은 한글문제입니다. 이번에 이야기 할 것은 한컴의 워드프로세서가 아니라 우리가 지금 사용하는 바로 이 한글을 말합니다.

리눅스는 아시다시피 오픈소스로 공개된 커널을 기반으로 이리저리 손을 대서 만들어낸 물건입니다. 따라서 모든 세계인들이 활용 할 수 있게 만들어야 하고 또 그렇게 되고 있습니다. 그런데 워낙 리눅스 이용 인구가 적은 한국은 한글 문제에 자주 봉착합니다. 아니 한글 자체가 문제가 아니라 UTF-8과 EUC-KR의 호환문제, 게다가 Microsoft만 만들고 쓰는 CP949같은 코드 파편화 문제입니다. 사실 한글을 읽고 쓰는 것은 전혀 문제가 없습니다. 유니코드라는 국제 표준이 나오면서 전세계의 언어를 통합 관리하게 되었기 때문에 이 유니코드만 사용한다면 한글문제, 아니 전세계의 모든 언어의 문제는 해결이 가능합니다.

문제는...... 표준을 지키지 않는 것들입니다. 저는 "비표준"이나 "사실상의 표준"을 참 싫어합니다. 비표준이야 어쩔  수 없는 경우가 많다고 해도(예를 들면 M5.5같은 애매한 나사라던가....이건 M5나 M6을 쓰면 안 되나?) 사실상의 표준이라고 이를 고수하는 것도 좀 웃기다는 생각이 듭니다. 사실상의 표준이라면 이를 표준으로 지정하면 되는데 ISO에서 이를 표준으로 지정하지 않는다?

대체 무엇이 문제일까요? 대표적인 것이라면 플래시가 있습니다. 브라우저 플러그인 방식인데다가 멀티코어 사용에 문제가 있고, 어느 한 회사(Adobe)의 독점 형태로 제공되고 있다 보니 문제가 참 많습니다. 하지만 그래픽적 효과를 이렇게 쉽게 보여줄 수 있는 녀석도 없어서 플래시는 지금 웹 그래픽에서는 표준이다시피 합니다. 하지만 HTML5에서 플래시의 기술은 들어가지 않았습니다. 넣으려면 넣을 수도 있었을텐데 말입니다. 그 이유는 모바일 플래시를 써보신 분들은 아시겠지만 엄청난 연산량에 따른 문제라고 하는군요.

그러고보니 반대로 한 회사에서 만들어서 쓰다가 ISO의 표준지정으로 바뀐 기술도 있습니다. 바로 PDF! 그러고 보니 이 물건도 Adobe의 결과물이군요. PDF는 현재 문서표준으로 지정되어 있어서 모든 기술이 공개되어있습니다. 위의 플래시 기술이 완전공개가 되지 못한 것(플래시 기술의 일부는 공개가 되어있습니다. 오픈소스의 결과물이라고는 하지만...)과는 차원이 다르지요.

자 다시 한글 표준으로 돌아와서 이제 어떤 문제가 있는지 확인 해 봅시다. 먼저 MS는 CP949라는 뭔가 해괴한 EUC-KR호환 한글코드를 사용합니다. 그 와중에 내부에서는 유니코드를 사용합니다. (뭐하는 짓이야...) 그리고 KS표준에 보면 EUC-KR과 유니코드를 동시에 올려놓았습니다. 그리고 UTF-8이라는 유니코드와 아스키 호환 코드도 존재합니다. ISO는 당연히 유니코드만이 표준입니다.

네 점점 가관입니다. 특히 KS표준이 참 막장이네요. EUC-KR과 유니코드를 같이 표준으로 채택하는 바람에 통일이 이루어지지 못했습니다. 그럼 CP949는? 이건 표준 아닙니다. 그냥 MS가 만들어낸 확장 완성형 기반입니다. 마치 옛날에 조합형 vs 완성형 싸움 비슷한 생각이 드는군요. 현재로써는 완성형이 이긴 것 같기는 하지만 한/글 워드프로세서가 조합형을 썼기에 지금의 위치에 오른 것을 생각해보면....

이러한 문제는 멀리 갈 것도 없이 UTF-8을 기본으로 사용하는 리눅스/OSX에서 윈도에서 압축한 ZIP파일을 풀면 여실히 드러납니다.한글 파일명이 대책없이 깨집니다. CP949는 EUC-KR 호환이라고 했지요? 원인은 여기있습니다. 때문에 반디집같은 프로그램은 UTF-8환경을 한번 거치는 것 같기는 합니다만,(한글이 아닌 다른 외국어로 쓰인 파일명을 읽기 위함 그런데 이것이 UTF-8에서 압축한 한글에도 먹히는 것입니다.)

언제나 매번 문제를 일으키지만 해결될 기미가 안 보이는 한글문제... ISO의 권고사항만 지키면 큰 문제는 없을 것 같은데 왜 안 지키는 사람들이 많을까요? 제발 적당히 배운티 내지 않았으면 좋겠습니다.