리눅스에서 왜 유튜브 제목의 초중종성이 분리되는가

리눅스에서 몇몇 유튜브 영상을 보면 제목이 요상하게 초/중/종성이 분리되어 있는 걸 볼 수 있다.

마침 이 NHN NEXT 페이지가 매우 인상적인데, 리눅스에서는 "NHN NEXT 2014학년도 2차 모집 안내동영상_서류제출안내" 영상의 제목이 끝의 "류제출안내"만 "ㄹㅠㅈㅔㅊㅜㄹㅇㅏㄴㄴㅐ"와 같이 보인다.

http://www.youtube.com/user/NHNNEXT

아마도 이 영상을 올리신 분은, 맥에서 "류제출안내"를 파일이름에서 복사해서 붙여넣기 하셨을 것이다.

근본 원인: 맥 오에스의 파일시스템

문제의 시작은 맥 오에스 파일시스템이 내부적으로 유니코드 인코딩을 NFD로 (참고: 유니코드 정규화) 사용하기 때문이다. 맥 오에스의 이 정책은 한글 뿐만 아니라 독일어 umlaut나 프랑스어 cedilla 같은 각종 액센트도 마찬가지로 적용된다. 한글의 경우 NFD는 한글 음절 코드가 U+1100의 한글 자모 코드로 변환되어 초중종성 코드로 나뉘게 된다.

이 문제는 유튜브 외에 여러 곳에서도 드러난다. 네트워크 파일시스템에서 한글 파일이름의 인코딩을 바꿔서 저장한다거나, 배포한 압축 파일의 파일이름도 초중종성이 분리되어 있거나, SVN으로 받은 한글 파일이름을 맥 방식으로 바꿔서 커밋한다든지, 구글 드라이브를 맥에서 싱크하니까 모든 한글 파일이름의 초중성을 분리한다든지 따위의 해프닝이다.

애플의 이러한 정책은 기술적 취지는 이해할 수 있다. 유니코드에서 같은 내용을 여러가지 방법으로 표현할 수 있는 문제가 있기 때문에, 전부 NFD로 바꾸면 한 가지 방법으로 전부 커버할 수 있으면서 유일성을 보장할 수 있다. 하지만 파일 이름이 파일 이름이 아닌 곳에서 드러난다는 건 문제이다. NFD가 틀린 인코딩은 아니다. 하지만 맞다 틀리다의 문제가 아니라, 일반적으로 많이 쓰이는 인코딩을 사용하는 게 상식적이지 않을까.

나눔 글꼴의 기능 미비

이 경우에도 결국 한 음절로 표시하면 되지 않느냐라고 물을 수 있는데, 리눅스의 글꼴이 그런 기능을 지원하면 가능하다. 하지만 현재 대부분 리눅스 배포판에서 사용하고 있는 나눔 글꼴에는 그런 기능이 들어 있지 않다. 이런 나눔글꼴 수정도 작업 중인 게 있으니 앞으로는 이런 기능의 글꼴이 일반적이 될 수도 있지 않을까.

Pango의 버그

윈도우나 맥용 글꼴이라고 해서 한글 자모 코드를 잘 지원하는 건 아니다. 그러면 왜 리눅스에서 유독 분리되어 보일까. 보통 현대 음절의 경우는 글꼴을 사용하기 전에 렌더링 엔진이 조합해 주기 때문이다. 별다른 기능이 아니기 때문에, gtk에서 사용하는 렌더러인 pango의 한글 렌더러를 처음 작성할 때부터 들어 있었는데 무슨 이유에서인가 망가져 있다. 다음 버그로 보고된 상태.

https://bugzilla.gnome.org/show_bug.cgi?id=705727

구글이 좀 고쳐주지

사실 가장 쉬운 해결 방법은 유튜브에서 자동으로 바로잡아 주는 것. 굳이 사용자가 올린 형태를 유지할 필요도 없을 것 같고, 어차피 내부적으로 검색도 하려면 변환하는 게 큰 문제는 아닐 것이다. 실제로 dropbox같은 경우 처리를 해 주는지 맥과 다른 OS 사이에서 한글 파일이름 공유에 문제가 없다.  하지만 구글에 뭐 고쳐달라고 요청한다고 고쳐주는 것 만큼 어려운 건 없으니...



위의 넷 중에 어떤 방법이든 바로잡으면 제대로 동작한다.

Pango 한글 렌더링

hangul-hackers 리스트와 수동 CC

-------------------

요즘 Pango 1.15.x 개발버전이 한창 진행되고 있고 해서, 한글 렌더링 모듈을 좀 손대려고 합니다..  발전적인 의견 있으면 주세요.

여담이지만 Pango의 한글 렌더링 모듈의 장기적인 발전 방향은, 아이러니하게도 글꼴이 다 알아서 하고 전용 모듈이 사라지는 것입니다.  현재까지는 (사실상 특수한 문서를 작성하지 않는한 사용하지 않는) 첫가끗이나 방점 등 렌더링 모듈이 일부러 신경을 써야 하는 기능들을 지원하는 글꼴은 소수입니다.  아마도 그런 글꼴이 널리 쓰이게 될때까지는 한글 모듈은 과도기적으로 그 글꼴을 구분하고 기능 조절을 하는 역할을 해야 할 것입니다.

어쨌든, 현재로선 거기까진 무리이고, 몇가지 최적화정도만 해야 겠네요:

1. 한글음절을 일부러 초/중/종으로 나눴다가 다시 합치는 동작 제거 - 일반화하기 위해 이렇게 했었지만, 일단 한글음절일 경우에 CPU 낭비인 데다가, 첫가끗으로 구성되어 있는 경우에도 나눠져 있는 걸 다시 합치면서 글꼴이 가진 능력을 활용하지 못하는 경우가 있습니다.

2. 동적 버퍼 제거 - L+V+T*M 이렇게 이론상 길이가 n인 1개 음절이 될 수 있기 때문에 realloc을 하는 버퍼를 두었는데 만들 때부터 신경쓰이는 부분이었습니다.  가능하면 버퍼없이 utf8 string에서 ucs4로 변환하지 않고 처리하도록 해 보지요.  :D

3. 그리고 안에 감춰져 있지만, pango_string_set_size()로 야금야금 크기를 늘려나가는 것도 내부적으로는 끊임없는 realloc()을 수행하게 해서 속도 저하 요인이 되는데요.  결과 글리프의 개수를 쉽게 알아낼 수 있을 것도 같은데, 이 부분은 좀 생각해 봐야 겠구요...

자, 여기까지 읽어보시고 "아! 내 그놈 데스크탑의 속도가 빨라지겠구나"라고 생각하신다면 그건 아니구요.  텍스트 렌더링의 대부분의 로드는 래스터라이징 자체와 래스터된 결과 데이터를 옮기는 데 있습니다. Pango 한글 모듈이 하는 일이라곤 유니코드 스트링을 보고 글꼴에서 어떤 글리프를 사용할까를 선택하는 정도이기 때문에 전체 텍스트 렌더링은 큰 향상을 기대하기 어려울 겁니다.  그냥 개발자의 결벽증인듯?

4. 2/3은 사실 그렇게 최적화 결벽증이고..  일단 1정도만 하고 슬슬 글꼴을 구분하는 능력을 부여할 수 있습니다.  렌더링 모듈에서 어떤 기능이 있냐 없냐를 테스트하는 건 확실하지 않지만 안 될 것 같고..  글꼴 이름으로 구분해서 앞에서 말씀드린 과도기적 역할을 할 수는 있죠. 

방점은 알아서 해 주는 글꼴을 본 적이 없고..  일단 첫가끗이 되냐 안되냐로 구분해서 음절을 자체적으로 합치려고 시도하느냐 아니냐를 결정할 수 있겠죠.  (그런데 한글음절로 표현할 수 있는데 일부러 첫가끗코드로 쓰는 그런 경우가 제가 테스트할 때 빼고 있는지 모르겠습니다.  :-)