그로몹 선생님, 유니코드에 한글이 두 영역에 들어 있습니다. 한 영역은 음절 영역으로 11172자의 완성된 음절이 가나다사전순으로 나열되어 있습니다. 말씀하신 '첫가끝'은 자모 영역에 해당합니다. 애초에 자모 영역만 있었다면 위의 일은 불필요하죠. 그래서 이런게 왜 필요한가 의문을 가지게 되시는 겁니다. 그런데 OS X를 제외한 다른 운영체제에서는 주로 음절 영역을 사용합니다. 그래서 자모 분해를 하려면 이 글에서 소개하는 작동이 필요합니다. 물론 다른 언어들에서는 대개 이보다 더 고수준의 변환 방법을 제공합니다.

유니코드의 한글 관련 부분은 모두 세 부분(크게 보아서)입니다.

  1. 한글호환자모: 주로 한글 자모 낱자를 표현하는 데 사용합니다. 우리가 한글로 사용하는 음절 문자를 나타내는 것이 아니므로 논외로 합니다.

  2. 한글음절문자: 이게 우리가 흔히 '한글'이라고 부르는 것이고 가에서 힣까지 11172자가 차례로 들어 있습니다.

  3. 한글 자모: 이것은 조합가능한 자모를 정의하고 있습니다.

그 결과, 유니코드로 한글을 표현하는 두 가지 방법이 생겨나게 됩니다. 예컨대 '가'를 \uAC00으로 표현하는 방법과, \u1100\u1161로 표현하는 방법이 그것입니다. 음절문자 코드를 사용하면 2바이트면 모든 현대한글을 다 표현할 수 있지만 자모조합으로 한글을 표현하면 초성에 2+바이트, 중성에 2+바이트, 종성에 2+바이트, 최소 4~6바이트가 필요하고요, 인코딩 방법에 따라서(예를 들어 UTF-8이면) 유니코드 2바이트가 3바이트로 인코딩되니까 크기가 꽤 늘어납니다. 한 글자를 표현하는 데도요.

어쨌든 이렇게 한글 자모 문자로 한글을 표현하는 방법을 통칭 "첫가끝"(공식 표현은 아닌 것으로 알고 있습니다)이나 LVT라고 부르는데, 옛한글과 같이 음절 문자에 정의되지 않은 한글을 표현하는 데는 이 방법밖에 없습니다. 초/중/종성 각각 하나의 코드가 필요하여 세벌이라고도 할 수 있을지 모르겠습니다.

현대 한글 음절 문자는 초성 19자, 중성 21자, 종성 28자를 가지고 만들 수 있는 모든 글자를 포함합니다.

조합용 자모에는 이보다 훨씬 많은 초/중/종성을 정의하고 있어서 지금은 사라진 옛한글도 자유롭게 표현할 수 있습니다. 조합 가능한 글자도 수백만자에 이르지요.

왜 이런 이야기가 유니코드에 나오는가 하면, 둘 다 표준이기 때문입니다.

clist 자료형에 데이터를 추가하는 데는 \clist_put_right:Nn \clist_put_left:Nn이 있습니다. 이것은 그냥 일반적인 리스트로 clist를 사용하는 것입니다.

그런데 clist를 스택처럼 사용할 때는 \clist_push:Nn과 \clist_pop:NN이 쓰입니다. 

이 스택의 top이 leftmost인 거죠.

seq 자료형은 좌우 양쪽을 top으로 쓸 수 있어서 스택뿐 아니라 큐로도 사용할 수 있게 되어 있습니다.

즉, \seq_pop_left:NN과 \seq_pop_right:NN이 있습니다.

그리고 \seq_push:Nn과 \seq_pop:NN도 정의되어 있는데 이것은 leftmost를 top으로 사용하는 스택입니다.

tl 자료형은 원래 스택이나 큐로 사용할 목적으로 만들어진 것이 아닌 듯합니다. 그래서 \tl_head:n과 \tl_tail:n밖에 없습니다. pop/push 명령이 없네요.

Comma lists(clist)를 스택으로 사용할 때는 성능상의 이유로 왼쪽을 top으로 사용하다고 하네요.

그러니까 성능상이 됐든 뭐가 됐든, 그건 난 모르겠고, (개콘의 경비아저씨 -_-;)

왼쪽을 탑으로 사용할꺼면 pop/push 연산의 이름을 shift/unshift로 해야하지 않느냐?

꼭 그런 것은 아니지만, 왼쪽이 탑일 때는 shift/unshift, 오른쪽이 탑일때는 pop/push라는 이름을

통상적으로 사용하니까.

한글 처리와 관련하여, 말씀하신 그런 일에 DohyunKim께서 적지않은 기여를 해오신 것으로 알고 있습니다.

감사와 존경의 말씀을 드립니다.

기술적으로 필요한 건 harfbuzz의 lua 바인딩인가요?

lua 바인딩은 당근 가능합니다. 다만 라이브러리 컴파일할 때 루아텍의 루아 버전에다 링크시켜야지 그렇지 않으면 두 버전의 루아끼리 충돌이 일어난다고 알고 있습니다. 그래서 만든 게 swiglib 프로젝트고요.

기술적 문제보단 정책의 문제가 더 큽니다. 우선 루아텍 개발팀 (특히 한스 하겐이 그렇죠. 루이기는 관대한 듯)이 외부 라이브러리에 대해 달갑지 않게 생각하고 있습니다. 또 텍라이브 팀도 새로운 라이브러리를 컴파일해서 tex live에 넣는 데 부담을 가지는 거 같습니다. 아무 라이브러리나 다 넣게 되면 매년 한 차례긴 해도 관리해야 할 것들이 무한대로 폭주할 수 있겠죠. 특히 이들이 대개 라틴 스크립트 권의 사람들이란 걸 감안하면 이해가 가는 면도 없지 않습니다. 현재 한스 하겐의 오픈타입 처리 코드 (쌩 루아 코드임다)가 라틴 문자는 대개 문제 없이 처리하니까요.

하지만 애초의 오리엔탈 텍이란 이름에 걸맞지 않게 아랍, 인도, 동남아 등등 complex script 쪽으로 가면 문제가 달라지죠. 한글은 우리의 세종대왕 덕분에 그리 복잡하지 않게 구현이 가능하기 땜에 현재의 쌩 루아 코드로도 대체로 무난하게 처리가 됩니다.(tone mark 제외하면요. tone mark 처리는 현재 luatexko가 하고 있습니다.)  다만 한글 처리 관련해서 심각한 문제가 발견되면 한스 하겐에게 사적으로 메일 보내서 버그를 잡고는 있습니다만, 이것도 나름 힘든 일이라 웬만하면 그냥 두기보기도 합니다. 여하튼 제대로 잘 작동하지 않는 스크립트가 많고 해서 사람들이 이미 성능이 공인된 하프버즈를 자꾸 생각하게 되는 것이구요.

https://goo.gl/jfyMKL 이런 걸 만들어서 테스트해보는 사람도 있더군요. 또한 http://goo.gl/0KkMfb 및 관련 글타래도 관심있으면 봐 보세요. 부정적인 기류가 완연하죠. 그래서 안 되겠다 싶어 최근에 한스 하겐에게 몇 건 버그 보고해서 버그잡이도 했어요. tex live에 아직 반영은 안 되고 있지만요. 음. 쓰다보니 게시판의 성격에 맞지 않게 너무 깊은 데까지 와 버렸네요. 하지만 케이턱엔 고수분들이 많으니까 뭐...