s e m a n o g i c

최근 새롭게 전개되고 있는 웹서비스 형태를 정의하는 중요한 요소 중의 하나인 UTF-8 인코딩은, 전세계 문자집합을 동일한 하나의 인코딩 방식으로 표현할 수 있기 때문에 웹에 가장 적합하고, 또 웹 뿐만이 아닌 다른 서비스나 어플리케이션에서 사용하면 좋을 것 같은 문자 집합이다.

그동안 한국에서 웹용으로 가장 많이 사용하는 Charset은 EUC-KR(KSC5601)일 것이고,
개발자들이 어플리케이션이나 엔진, 특히 웹 어플리케이션을 개발하면서 가장 많이 부딪히게 되는 문제가 charset 처리, 국내 개발자들에게는 특히 한글 처리 문제일 것이다. 나도 지금까지는 이 분야에 대해서는 잘 몰라서 직접 해본적이 없는데, 이제는 어쩔 수 없이 직접 하고 있다.
(회사나 어떤 프로젝트를 진행하면서 개발자의 내공이 가장 많이 진보하는 시기는 "사수부재"의 순간이다. 혹은 "나 밖에 없네" 상황을 자각할 때, 그 내공은 못해도 10갑자는 늘기 마련이다.)

개발/튜닝 중인 검색엔진은 한글 처리가 영 신통치 않고, data 흐름에 있어서도 문자열 처리에 있어서는 앞뒤가 안맞는 부분이 많이 있다.
원 제작자가 영어권 사람이라, 비영어권의 multi-byte 캐릭터셋 처리에 있어 특히 아쉬운 부분이 많이 있다.
내가 어떤 서비스를 개발하는 과정에서 가장 신경을 많이 쓰고 공을 들이는 부분은 바로,
제공 되는, 혹은 제공해야 하는 API의 일관성이다. 내가 작성한 코드를 사용해야 하는 다른 코드나, client가 혼동하지 않도록 깔끔한 인터페이스를 작성하는 것이 요즘들어 가장 신경 쓰는 부분이고 후배 개발자들에게도 귀찮게 강조하는 부분이다.
지금 사용 중인 오픈 소스는 이러한 부분에서 약간 아쉽다.
물론 전반적으로 봤을 때는 엄청나고 감탄스럽다. 사실 오기가 발동하기는커녕 그 코드 스타일이나, 디자인 스타일을 모방하기 급급하다.

어쨋건 간에, EUC-KR charset을 유니코드나 멀티바이트 유니코드로 변환하기 위해서,
유니코드간의 인코딩 변환은 계산식으로 가능하지만, EUC-KR은 변환 규칙이 없기 때문에 사이즈가 꽤 큰 매핑 테이블을 사용해야 한다.
계산식이 필요없으므로 바이너리 검색이나 여타 좋은 알고리즘을 사용하면 속도는 더 빠를 수도 있겠지만, dso(dynamic shared object), 혹은 dll로 구현하여 스트레스성의 서비스 어플리케이션에서 빈번하게 로딩을 해야 한다면 라이브러리 내에 이러한 큰 테이블을 가지고 있는 것이 꽤 부담스러워진다. 게다가 테이블을 더 크게 만들거나 추가 테이블을 하드코딩해 놓으면 검색 속도를 높일 수 있다는 악마의 유혹까지 있다면..... 부담스러워도 이게 현실인가보다.

작성 중인 라이브러리의 내부에서 charset을 처리하는 루틴에서는 Simple Unicode를 사용하지만, 외부 인터페이스 부분에서는 UTF-8으로 변환 처리된다. EUC-KR은 데이타 소스로만 존재할 뿐이므로 한번만 Simple Unicode로 변환되면 그 후에는 유니코드 체계내에서만 상호 인/디코딩 처리되도록 한다.

일단 여기까지,,,
뭘 해도 정리가 안되는군.