> For the complete documentation index, see [llms.txt](https://overleaf-pro.ayaka.space/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://overleaf-pro.ayaka.space/latex/ko/in-depth-articles/07-an-introduction-to-luatex-part-1-what-is-it-and-what-makes-it-so-different.md).

# LuaTeX 소개(1부): 그것은 무엇이며—무엇이 그렇게 다른가?

LuaTeX는 하나의 *도구 모음*—이것은 다양한 문서를 조판할 수 있는 정교한 소프트웨어 도구와 구성 요소를 포함하고 있다. 또한 이 글의 부제는 LuaTeX에 대해 두 가지 질문을 던진다. 즉, 그것은 무엇이며—무엇이 그렇게 다르게 만드는가? “그것은 무엇인가?”에 대한 답은 분명해 보일 수 있다. “TeX 조판 엔진이다!” 실제로 그렇지만, 더 넓은 관점에서 보면, 그리고 이 글의 저자도 동의하듯이, LuaTeX는 매우 다재다능한 TeX 기반의 *문서 구성 및 엔지니어링 시스템*.

### LuaTeX 설명하기: 어디서 시작할까?

LuaTeX에 관한 이 첫 번째 글의 목표는 이 TeX 엔진이 무엇을 제공하는지, 그리고 왜/어떻게 그 설계가 사용자가 복잡한 조판 및 디자인 문제에 대한 다양한 해결책을 구축/설계/창조할 수 있게 하는지 이해할 수 있는 맥락을 제시하는 것이다. 또한 점점 더 많은 사용자가 끊임없이 변화하는 기술 생태계에 적응할 수 있는 TeX 기반 소프트웨어를 필요로 하게 됨에 따라, 어느 정도의 “미래 대비”도 제공할 수 있을 것이다. 이 글의 저자 의견으로는, LuaTeX의 기능과 잠재력을 이해하기 시작할 때 그 기능을 나열하고 설명하는 것이 반드시 최선의 출발점은 아니다. 이런 접근은 다른 TeX 엔진에 익숙하지 않은 독자들에게는 특히 도움이 되지 않을 것이며, 기능 기반 비교 역시 그들에게는 별로 의미가 없을 가능성이 크다.

독자의 인내심을 소진시킬 위험을 무릅쓰고(“본론으로 빨리 들어가!”) 나는 좀 더 “총체적”인 접근을 취할 것이며, 유용한 배경을 제공하되 그 대가로 추가적인 읽을거리가 생기고—이해를 돕기 위해 몇 가지 프로그래밍 주제까지 다루게 될 것이다. 2부에서 [2부](/latex/ko/in-depth-articles/09-an-introduction-to-luatex-part-2-understanding-directlua.md) 에서는 사용하는 것을 살펴보고 `\directlua` 하지만 지금은 LuaTeX를 이해하기 위한 기본 토대를 마련하려 한다.

이 글은 LuaTeX에 대한 이해와 애정을 키워 온 저자의 개인적인 “여정”을 강하게 반영한다. 즉, 먼저 LuaTeX 개발 뒤에 있는 철학에 대해 조금 알고, 그것을 소프트웨어 도구의 집합체로 본다면, 이 놀라운 소프트웨어가 열어 주는 방대한 해결 영역을 더 잘 이해하게 될 것이다.

## LuaTeX: 학계나 수학만을 위한 것이 아니다!

LuaTeX에 내장된 풍부한 기능과 역량은 전통적인 LaTeX를 통해 매우 높은 품질의 조판을 제공할 뿐만 아니라, 복잡한 문서 제작 및 엔지니어링 문제에 대한 맞춤형 비-LaTeX 기반 해결책을 개발할 수 있는 엄청난 여지도 제공한다. LuaTeX에는 강력한 Lua 스크립팅 언어가 내장되어 있어, 예를 들어 Lua를 사용해 외부 소프트웨어 라이브러리인 “플러그인”을 LuaTeX에 불러올 수 있다. 이를 통해 높은 수준의 자동화, 기존 소프트웨어 시스템이나 워크플로와의 통합, 그리고 데이터·텍스트·그래픽 처리에 특화된 소프트웨어의 활용이 더욱 가능해진다.

역사적으로 TeX는 특히 수학 분야에서 학술 저작/출판과 연관되어 왔지만, LuaTeX은 특히 상업용 PDF 문서 제작을 포함한 여러 다른 영역에서도 상당한 잠재력을 지닌다. 그 한 가지 예가 [speedata publisher](https://speedata.github.io/publisher/) 인데, 이 시스템은 XML 기반 워크플로 안에서 PDF 생성 엔진으로서 LuaTeX만을 사용하며—LaTeX는 전혀 사용하지 않는다. 실제로 speedata publisher에는 사실상 TeX 코드가 거의 없는데—나는 [Patrick Gundlach](https://twitter.com/patrickgundlach)에게 물어보았고, speedata publisher의 개발자인 그는 총합으로 약 3줄의 TeX 코드만 사용한다고 확인해 주었다. 그 강력한 조판 기능은 LuaTeX의 Lua API(이 글에서 나중에 다루는 주제)를 사용한 Lua 코드로 설계되고 구현되어 있다.

## 짧은 개인 이야기: 내가 LuaTeX를 처음 발견한 방법

나는 2009년 말/2010년 초, 당시 아직 중간 베타 릴리스 단계(버전 0.50)에 있던 LuaTeX를 처음 알게 되었다. 그때 나는 아랍어를 배우려는 노력의 결과로 나온 손글씨 노트를 조판할 TeX 기반 소프트웨어를 찾고 있었다. 구글 검색을 통해 TUG 2009 컨퍼런스의 비디오 모음([지금은 YouTube에 있는](https://www.youtube.com/playlist?list=PL2D4DD50DC9C0BA0E))을 찾았고, 그 안에는 Hans Hagen의 [ConTeXt 패키지](http://wiki.contextgarden.net/Main_Page)를 통해 매우 높은 품질의 아랍어 조판 시연이 포함되어 있었다. 그 영상들에는 또한 [The LuaTeX Project: version 1까지 절반](https://youtu.be/AKv4po9PGW0).

이라는 제목의 발표도 포함되어 있었다. 그 절묘한 아랍어 조판을 생성하는 데 사용된 TeX 엔진은 “LuaTeX”라는 것이었다. 당시 나는 과학(물리학) 출판 분야에서 일하고 있었고 TeX/LaTeX에 대해서는 잘 알고 있었지만 LuaTeX는 들어본 적이 없었다. 나는 흥미를 느껴 이 새로운 TeX 엔진에 대해 더 알고 싶어졌다. LuaTeX는 아직 베타 개발 단계에 있었고 빠르게 개발이 진행 중이었기 때문에, 최신 업데이트를 계속 따라가고 싶었다. 그래서 가장 좋은 방법(적어도 나에게는)은 LuaTeX 실행 파일을 소스 코드에서 직접 빌드(컴파일)하는 것이었다. LuaTeX 실행 프로그램 외에도, LuaTeX를 실행할 환경을 제공하는 “TeX 설치”가 필요하다(예: texmf.cnf, 매크로 패키지, 글꼴 등). 거대한 [TeX Live](https://www.tug.org/texlive/) 배포판을 내려받아 설치하는 대신, 나는 LuaTeX을 탐구하기 위해 완전히 최소한의 맞춤형 TeX 설치를 만들기로 했다(나는 이를 개인 블로그에 [기록해 두었다](http://www.readytext.co.uk/?cat=30)). LuaTeX의 새 릴리스마다 참조 매뉴얼이 함께 제공된다(예:[버전 1.0.4](https://www.tug.org/svn/texlive/tags/texlive-2017.1/Master/texmf-dist/doc/luatex/base/luatex.pdf?revision=44591\&view=co)). 이 매뉴얼은 소프트웨어의 최신 기능과 역량을 문서화하지만, 이것은 *참조* 매뉴얼이며, 이 놀라운 TeX 엔진을 처음 시작하려는 초보자에게 적합한 설명은 (필연적으로) 비교적 적다. 저수준 TeX 개념에 대한 어느 정도의 친숙함이 전제된다. 내가 LuaTeX를 비교적 이른 개발 단계에서 발견했기 때문에, 당시에는 좋은 입문 자료를 찾기가 비교적 어려웠고, 그래서 여러 가지를 탐색하고 실험하고(그리고 약간 좌절도 겪으며…) 나서야 비로소 퍼즐 조각들이 맞춰지기 시작했다. 말할 필요도 없이, 나는 이 놀라운 소프트웨어에 매료되면서 아랍어 공부를 갑작스럽게 중단하게 되었고, 결국 아랍어 조판을 위한 LuaTeX [플러그인을 작성하는 쪽으로](http://www.readytext.co.uk/?p=3143) 방향을 바꾸게 되었다!

내 LuaTeX “여정”은 확실히 매우 비선형적이었지만, 그 과정에서 (Lua)TeX(그리고 TeX 설치)에 대해 “기초부터” 배울 기회를 얻었다. 내 블로그에는 당시 내가 탐구하고 작업했던 다양한 주제를 바탕으로 한 다채로운 [글](http://www.readytext.co.uk/?cat=3) 이 모여 있다. 바라건대, 이 글이 그 시간과 경험을 적절히 활용하여 다른 사람들이 LuaTeX의 기능을 탐구하기 시작하는 데 흥미를 갖도록 돕기를 바란다. LuaTeX는 계속 개발되고 있으며, 이 글을 쓰는 시점에는 TeX Live 2017과 함께 배포된 버전 1.0.4에 도달했다. 개발자들은 매우 활발하게 활동하고 있으며, 발견된 버그는 대개 보고된 직후 수정된다. 예를 들어 [dev-luatex 메일링 리스트](https://mailman.ntg.nl/mailman/listinfo/dev-luatex) 를 통해서나 [온라인 LuaTeX 버그 트래커](http://tracker.luatex.org/my_view_page.php)를 통해서이다. 버전 1.0에 도달하기 훨씬 전부터 LuaTeX는 생산 환경에서 사용할 수 있었지만—물론 기능이 계속 진화하고 있었고, 때때로 변경으로 인해 기존 TeX 코드가 깨질 수 있다는 점은 감수해야 했다. 오늘날 LuaTeX는 물론 Overleaf와 ShareLaTeX 플랫폼에서도 (LuaLaTeX로서) 지원된다.

## 변화하는 세계 속의 TeX: 새로운 기술과 워크플로

분명히 TeX 엔진은 기술적으로 정적인 세계에서 작동하는 것이 아니며, 때때로 TeX 엔진에 즉시 그리고 명백하게 포함될 후보가 되는 혁신이 등장한다. 그런 혁신 중 하나가 아래에서 간략히 논의할 OpenType 가변 글꼴이다. TeX 기반 조판 소프트웨어가 매우 다재다능하다는 데는 의심의 여지가 거의 없지만, 오늘날 TeX 엔진은 빠르게 변화하고 매우 다양한 소프트웨어 생태계 안에서 작동한다. 새로운 워크플로는 통합의 필요성과, TeX가 그중 한 구성 요소일 뿐인 다양한 문서/조판 해결책을 구현할 수 있는 유연성을 더욱 부각시킨다.

TeX는 현재 사용자와의 관련성을 유지해야 할 뿐만 아니라, 후속 세대에게도 유용하게 남을 수 있는 콘텐츠 제작 해결책을 가능하게 함으로써 새로운 사용자도 끌어들여야 한다. 이들은 TeX를 독립형 도구로 사용하고 싶어 하지 않을 수도 있으며, Overleaf 같은 온라인 협업 플랫폼을 통해 전체 워크플로의 일부로 사용하고자 할 수도 있다.

잠깐 [tex.stackexchange](https://tex.stackexchange.com/) 를 훑어보기만 해도 TeX 기반 소프트웨어로 만들어지고 구현되는 문서와 해결책의 엄청난 다양성을 확인할 수 있다. 사람들은 자신들이 생성하고자 하는 훨씬 더 많은 사용 사례와 콘텐츠 유형을 찾아내며 놀라운 기발함을 보여 주곤 한다. 또한 TeX 기반 마크업/콘텐츠를 처리하여 PDF가 아닌(그리고 DVI도 아닌) 출력, 예를 들어 MathML/XML과 HTML을 생성할 수 있는 워크플로의 필요성은 그 어느 때보다 커졌다. 예를 들어 TeX를 [JATS XML](https://jats.nlm.nih.gov/) 형식으로 “변환”하는 것(학술지 출판에서 오랫동안 사용되어 왔음)뿐 아니라, 최근에는 전자책 출판에서 사용되는 epub의 부상도 있다.

### 가변 글꼴 기술—시대가 변하고 있다

2016년 9월 14일, Microsoft, [Google](https://opensource.googleblog.com/2016/09/introducing-opentype-font-variations.html), [Adobe](https://blog.typekit.com/2016/09/14/variable-fonts-a-new-kind-of-font-for-flexible-design/) 및 Apple은 새로운 글꼴 기술을 발표했다: [OpenType 가변 글꼴](https://medium.com/@tiro/https-medium-com-tiro-introducing-opentype-variable-fonts-12ba6cd2369). 이 기술을 자세히 살펴보지는 않겠지만, 그럼에도 잘 알려진 글꼴 전문가들인 [Thomas Phinney](https://twitter.com/ThomasPhinney) 및 [John Hudson](https://twitter.com/TiroTypeworks) 은([트위터에서](https://twitter.com/ThomasPhinney/status/917087509342851072)) 가변 글꼴 기술이 이전의 많은 글꼴 혁신보다 훨씬 빠르게 채택되고 있다고 지적해 왔다. 이는 모바일 기기에 존재하는 수많은 서로 다른 화면 크기/해상도에 적응하는 반응형 디자인이 필요한 웹 디자이너들의 요구에 의해 크게 추진된 것으로 보인다.

분명히 OpenType 가변 글꼴은 글꼴 기술에서 흥미롭고 신나는 발전이며, TeX 사용자들도 분명 이익을 얻을 수 있다. 실제로 이 문제는 필연적으로 [tex.stackexchange에서 제기되었고](https://tex.stackexchange.com/questions/355104/tex-luatex-xetex-fontspec-support-for-opentype-variable-fonts) LuaTeX의 지원은 LuaTeX [메일링 리스트에서 논의되었다](https://www.tug.org/pipermail/luatex/2016-September/006204.html).

덧붙여 말하자면, “매개변수적” 글꼴 생성에 기반한 글꼴 기술이 완전히 새로운 아이디어는 아니라는 점도 언급할 만하다. Knuth의 METAFONT와 Adobe의 Multiple Master 기술은 구현 세부 사항은 상당히 다르지만, 어떤 면에서는 초기 선구자들이다.

### 가변 글꼴: 우리는 언제 그것을 원하는가—지금

새롭고 유용한 기술 표준/사양은, 사양 자체의 문구에 있는 모호성이나 해석의 여지를 정리할 시간을 포함하여, 목표 생태계인 개발자와 구현자들 속에 “정착”될 시간이 필요하다. 개발자들은 문서를 읽고 이해한 뒤, 이를 실제로 작동하는 소프트웨어로 바꿔야 한다. 여기에는 글꼴과 이를 사용할 기술, 즉 호환되는 브라우저와 조판 엔진을 만드는 일도 포함된다. TeX 개발자들은 가변 글꼴 기술을 구현(프로그래밍)할 때 신뢰할 수 있는 “벤치마크”로 사용할 수 있는 고품질 가변 글꼴에 접근할 수 있어야 한다.

가변 글꼴 같은 새로운 기술을 TeX에 구현하는 것은 *잠재적* 으로 TeX 엔진 내부를 수정해야 할 필요성을 제기한다. 물론 그렇게 해야 할 필요성은 해당 기술의 성격과, 결정적으로 TeX의 어떤 동작 측면이 변경 대상인지에 달려 있다. TeX 엔진 자체를 반드시 수정해야 하는 것은 아니며, 해당 프로그램에서 사용되는 “구성 요소”(외부 코드 라이브러리)를 포함한 지원/부가 소프트웨어만 변경하면 되는 경우도 있다. 내부적으로 TeX 엔진은 *끔찍할 정도로* 복잡하다. 신뢰할 수 있는 수정을 할 수 있을 만큼 TeX의 소스 코드를 이해하려면 상당한, 그리고 매우 전문적인, 전문 지식이 필요하며(그런 지식은 매우 제한적으로만 존재한다). 또한 어떤 수정도 TeX 엔진의 장기적인 안정성/호환성에 악영향을 미치지 않아야 하는데, 이는 TeX 공동체와 이후 저자의 (La)TeX 파일을 처리하는 이들에게 매우 중요하다. 특히 학술 출판사와 Overleaf, ShareLaTeX 같은 클라우드 기반 서비스가 그렇다.

많은 TeX 사용자는 가변 글꼴을 활용하는 데 관심이 있을 것이다. 예를 들어 새로운 디자인 가능성을 구현하거나 까다로운 조판 문제에 대한 해결책을 찾는 데 말이다. 어떤 의미에서 딜레마가 있다. 즉, TeX 사용자는 새로운 기술에 접근하길 원하지만 그 구현은 매우 제한된 자원, 즉 이를 실제로 가능하게 만들 수 있는 자격을 갖춘 개발자 수에 달려 있기 때문이다. TeX 내부를 수정하는 것은 어렵고, 일반적으로 가능한 한 피하는 것이 최선이다. 그렇다면 TeX에 새로운 기능/역량의 특정 범주를 추가하는 다른 방법이 있을까? 있다! 그리고 LuaTeX는 그 길을 택했다.

#### 초기 실험: OpenType 가변 글꼴과 LuaTeX

LuaTeX의 설계는 가변 글꼴 기술에 대한 빠른 실험을 가능하게 했다. 이미 2017년 4월 시점에 LuaTeX를 사용하는 ConTeXt TeX 형식에는 [베타 버전](https://mailman.ntg.nl/pipermail/ntg-context/2017/088343.html) 이 있었고, 이는 OpenType 가변 글꼴을 구현했다. 이것이 가능했던 이유는 ConTeXt의 글꼴 지원이 Lua 코드로 구축되어 있고(또한 ConTeXt에는 Lua로 작성된 자체 fontloader가 있다).

## LuaTeX: 배경과 역사

TeX 용어로 보면 LuaTeX는 10년 넘게 활발히 개발되었음에도 “막 등장한 신예”다. LuaTeX 웹사이트는 [문서화한다](http://www.luatex.org/roadmap.html) LuaTeX가 2005년에 시작되었고, (내 생각에는) 활발하고 지속적인 개발은 2006년에 시작되었다는 것을. 그 본질적 복잡성과 이를 만든 이들의 헌신 덕분에, LuaTeX는 1.0 버전에 도달하기까지 정말로 10년의 개발이 필요했으며, 이는 [그 개발자들이 발표한](https://mailman.ntg.nl/pipermail/dev-luatex/2016-September/005882.html) (Hans Hagen, Hartmut Henkel, Taco Hoekwater, Luigi Scarso) 2016년 9월 27일.

그 릴리스 발표문에는 중요한 원칙 진술이 담겨 있다:

> “우리의 주요 목표는 내부 동작을 조정할 필요 없이 사용자가 확장할 수 있는 TeX 변형을 제공하는 것이다.”

이 문구는 LuaTeX 개발의 배후 철학을 완벽하게 담아내며, TeX 기반 소프트웨어가 이미 언급한 과제들—새로운 기술의 채택과 새로운 세대의 사용자에게도 관련성을 유지하는 일—에 대응할 수 있는 경로를 가리킨다.

이제 이 글의 부제에 담긴 두 번째 질문, 즉 “무엇이 그렇게 다르게 만드는가”에 답할 차례다. “...내부 동작을 조정할 필요 없이 사용자의 확장을 허용한다”의 의미를 탐구함으로써 LuaTeX가 “제공하는 것”의 본질을 더 잘 이해할 수 있다.

## LuaTeX: TeX의 “블랙박스”를 열다

Knuth의 원래 TeX 프로그램은 오늘날 사용되는 모든 현대 TeX 엔진의 공통 조상이며, LuaTeX는 사실상 최신 진화 단계이다. pdfTeX 프로그램에서 파생되었지만 많은 추가 기능을 가져오는 몇 가지 강력한 소프트웨어 구성 요소가 더해졌다. Knuth가 TeX 소프트웨어의 원래 버전을 작성할 때, 그는 또한 TeX 언어를 그 조판 동작을 제어하고 프로그래밍하는 방법으로 제공했다. 약 320개의 저수준 명령(원시 명령)이 TeX 매크로 패키지의 사용자와 개발자에게 제공되었다. 이러한 명령들은 TeX의 조판 동작 일부 측면에 대해 서로 다른 정도의 제어나 영향을 제공했지만, TeX의 내부 기능, 알고리즘, 의사결정 과정, 데이터와 데이터 구조의 상당 부분은 사용자에게 숨겨져 있었다. 엄밀히 말해 Knuth의 TeX 프로그램이 완전히 “블랙박스”였다고 하기는 어렵지만, 분명히 매우 짙은 회색에 가까웠다. 물론 소스 코드는 공개되었지만, 대부분의 사람들에게 그것 역시 이해 불가능한 블랙박스다.

TeX 내부의 여러 과정은 다소 “블랙박스”라고 할 수 있다. 하지만 LuaTeX는 TeX 기반 내부 구조를 열어 사용자가 TeX 엔진 깊숙한 곳에서 일어나는 한때 숨겨져 있던 많은 과정에 훨씬 더 큰 접근권과 제어권을 갖게 한다. LuaTeX는 또한 새로운 기능들을 제어할 수 있는 많은 새로운 primitive 명령을 추가한다.

### LuaTeX: pdfTeX에서 파생되었지만 pdfTeX의 코드는 사용하지 않는다

정확성을 위해, LuaTeX를 pdfTeX에서 파생되었다고 설명했지만 LuaTeX가 pdfTeX의 원래 프로그램 코드를 직접 사용하는 것은 아니라는 점을 밝혀둘 필요가 있다. LuaTeX의 개발자 중 한 명인 Taco Hoekwater는 정말로 *헤라클레스적인* 임무를 맡아 LuaTeX의 핵심 TeX 엔진을 깨끗하고 현대적인 C 코드(CWEB)로 다시 작성했다.

#### 역사적 참고

부분적으로는 Knuth의 원래 TeX 소스 코드가 오래되었기 때문인데—현대의 후손들은 그 코드에서 파생되었다—그것을 수정해 새 TeX 기반 조판 엔진을 적응시키거나 만드는 일은 복잡하고 얽힌 과정이다. 그 과정의 일부는 Pascal 코드를 C 코드로 변환하는 것을 필요로 하는데, 이는 [상당한 수준의 복잡성](http://www.readytext.co.uk/?p=2529)을 피할 수 없다. 그 결과 생성된 기계 생성 C 코드는 매우 장황하고 읽거나 이해하기가 극도로 어렵다. 분명히 LuaTeX의 코드를 완전히 다시 작성하면 Pascal에서 C로의 변환 과정 전체를 우회할 수 있다.

## LuaTeX의 구성 요소

서론에서 우리는 LuaTeX를 “도구 모음”이라 언급하고 이를 “문서 구성 및 엔지니어링 시스템”이라고 설명했다. 또한 LuaTeX 1.0 발표에서 개발자들이 다음과 같이 말했다는 점도 보았다:

> “우리의 주요 목표는 내부 동작을 조정할 필요 없이 사용자가 확장할 수 있는 TeX 변형을 제공하는 것이다.”

이제 이러한 흐름을 하나로 모아, 이 모든 것이 *실제로 무엇을 의미하는지* 에 초점을 맞출 차례다.

### LuaTeX 퍼즐 조각들

겉껍질 아래를 들여다보면, 실제 실행 프로그램인 LuaTeX 소프트웨어가 여러 소프트웨어 구성 요소의 집합으로 만들어져 있으며, 이들이 결합되어 LuaTeX의 전체 기능을 제공한다는 것을 볼 수 있다. 물론 이는 새로운 일이 아니며 대부분의 소프트웨어가 그렇게 구성된다. 그러나 LuaTeX가 다른 TeX 엔진과 다른 점은, 이러한 구성 요소들이 TeX의 내부 기능, 즉 TeX의 조판 알고리즘, 의사결정 과정, 데이터와 데이터 구조의 많은 부분에 사용자가 훨씬 더 큰 접근권을 갖도록 하는 방식으로 결합되어 있다는 것이다. TeX 내부를 이렇게 열어 줌으로써 사용자는 실제 TeX 엔진 자체를 수정할 필요 없이 새로운 조판 해결책을 만들 수 있다.

### LuaTeX의 Lua: “블랙박스”를 여는 열쇠

Lua는 매우 강력하면서도 배우기 쉬운 스크립팅 언어로 [브라질에서 유래했고](https://www.lua.org/about.html)—1993년에 만들어졌으며 지금도 활발히 개발되고 있다. Lua의 강점 중 하나는 서로 다른 소프트웨어 구성 요소들을 “접착”하는 프로그래밍 언어로 사용될 수 있다는 점이며, 이를 통해 단순하지만 다재다능한 스크립팅 언어로 그것들을 사용할 수 있게 해준다. Lua는 LuaTeX TeX 엔진의 내부 동작을 여는 데 중심적인 역할을 하지만, 이를 어떻게 달성하는지 더 잘 이해하려면 두 가지 프로그래밍 개념을 아주 간단히 살펴볼 가치가 있다:

* 응용 프로그래밍 인터페이스(API);
* 프로그래밍 언어 바인딩.

이 개념들에 익숙하다면 이 섹션은 건너뛰어도 좋다. 두 주제 모두 자세히 다루지는 않을 것이다. 우리는 엄밀한 기술적 엄밀성을 목표로 하는 것이 아니라, LuaTeX와 관련하여 이 개념들의 의미와 중요성을 알아둘 수 있을 만큼의 배경만 제공하려 한다.

### 응용 프로그래밍 인터페이스(API)

당신이 어떤 코드를 작성한 프로그래머라고 상상해 보자. 다른 사용자들(다른 프로그래머들)이 유용하게 여길 수 있지만, 당신의 코드는 복잡해서 사용자가 그런 저수준 세부 사항을 신경 쓰게 하고 싶지 않다. 또한 그 프로그래머/개발자들은 당신이 작성한 코드와 같은 프로그래밍 언어를 사용하고 있다고 하자. 더 나아가 코드의 일부를 다시 작성할 계획이 있다고 가정해 보자. 예를 들면 더 빠르게 만들거나 메모리를 덜 쓰게 하는 식이다. 기존 사용자는 그것에 대해 걱정할 필요가 없어야 한다. 당신이 계획하는 변경 사항은 그들의 프로그램을 망가뜨려서는 안 된다. 그렇다면 해결책은 무엇일까?

답은 API라는 것에 있다. 즉, *응용 프로그래밍 인터페이스*다. 사용자가(다른 프로그래머들이) 변경될 수도 있는 당신 코드의 저수준 세부 사항에 접근하도록 요구하는 대신, 당신은 특정한 *함수* 집합을 제공한다. 다른 프로그래머들은 그 함수들을 사용할 수 있다. 그 함수들은 당신 코드에 대한 *인터페이스* 이며, 이를 통해 다른 개발자들은 *애플리케이션* 을 당신 프로그램의 내부 동작을 속속들이 알지 못한 채 만들 수 있다. 어떤 면에서는 이것을 당신의 코드를 둘러싸고 사용자들을 지저분한 저수준 세부 사항으로부터 “단절”시키는 추가 레이어라고 생각할 수 있다.

그 함수들(인터페이스)을 바꾸지 않는 한, 당신은 소프트웨어의 더 낮은 수준 세부 사항을 자유롭게 수정하고 업데이트할 수 있으며, 자신의 코드를 사용해 애플리케이션을 만드는 이들의 작업을 방해(망가뜨림)하지 않을 수 있다. 그래서 이를 응용 프로그래밍 인터페이스라고 부른다.

#### API: LaTeX 패키지의 비유

LaTeX 패키지에서 제공하는 명령을 사용할 때, 그 패키지의 명령들을 일종의 API로 생각할 수 있다. 사용자 입장에서는 그 명령 뒤에 있는 TeX와 LaTeX의 마법 같은 처리(즉, 패키지 코드 내부)에 반드시 관심을 가질 필요가 없다. 당신이 원하는 것은 그것들이 제공하는 기능을 활용하는 것뿐이다.

### 프로그래밍 언어 바인딩

우리는 유용한 코드 집합( *라이브러리*)을 작성하고/발표하는 프로그래머가, 같은 *같은* 프로그래밍 언어를 사용하는 다른 프로그래머들이 그 라이브러리(코드 모음)를 활용할 수 있도록 소위 응용 프로그래밍 인터페이스(함수 집합)를 제공할 수 있다는 점을 보았다. 양쪽(라이브러리 개발자와 사용자)이 *같은* 프로그래밍 언어 *를 사용할 때는 이것이 괜찮다. 하지만 다른* 프로그래밍 언어를 사용하는 프로그래머들도 그 라이브러리를 활용하고 싶다면 어떻게 될까? 예를 들어 Lua 언어로 스크립트를 작성하면서도 C/C++ 같은 프로그래밍 언어로 작성된 라이브러리를 사용하고 싶을 수 있다. 어떤 식으로든 두 서로 다른 프로그래밍 언어(Lua와 C/C++)가 서로 “소통”할 능력이 필요하다. 이 문제의 한 가지 해결책이 바로 소위 [언어 바인딩](https://en.wikipedia.org/wiki/Language_binding).

언어 바인딩의 기술적 세부 사항을 살펴보는 것은 이 글의 범위를 벗어나므로, 일반 원칙만 간결하게 요약하겠다. 본질적으로 원래 라이브러리에 적절한 추가 “레이어”의 코드를 더하면 다른 프로그래밍 언어(예: Lua)와 “소통”할 수 있다. 그 코드 계층을 *바인딩*이라고 부른다. 이는 두 언어가 API를 통해 상호 운용할 수 있게 하며, 두 번째 언어(예: Lua)의 프로그래머가 라이브러리가 제공하는 기능/서비스에 접근할 수 있도록 해준다.

![언어 바인딩의 개념을 보여 주는 개략도.](/files/3b25bf92dbf2b4aff4b9b046d95c3130bb6b6666)

**그림 1**: Lua로 작성된 프로그램이 다른 프로그래밍 언어로 작성된 외부 라이브러리를 사용할 수 있게 하는 언어 바인딩의 개념을 보여 주는 개략도. Lua 바인딩을 사용함으로써 LuaTeX의 내부 구성 요소, 그리고 그에 따라 LuaTeX의 내부 조판 기능 대부분이 사용자가 복잡한 조판 문제에 대한 해결책을 개발하는 데 이용 가능해진다.

## LuaTeX: 프로그래밍을 위한 두 가지 옵션—TeX와 Lua

본질적으로 LuaTeX는 두 가지 프로그래밍 언어를 지원하는 TeX 엔진이다. 전통적인 TeX 기반 언어와 Lua 스크립팅 언어가 그것이다. 물론 같은 TeX 문서에서 두 언어를 모두 사용할 수도 있고, 원한다면 TeX만 사용하는 방식, 예를 들어 LaTeX(LuaLaTeX) 매크로 패키지를 통해 조판을 계속할 수도 있다. TeX(또는 LaTeX)는 사용하거나 배우기 쉬운 프로그래밍 언어가 아니며, TeX의 수많은 특이성을 진정으로 마스터한 사람도 비교적 적다. TeX의 [토큰](https://www.overleaf.com/blog/522-what-is-a-tex-token) 과 확장 개념은 대부분의 사람들이 프로그래밍 언어에 대해 기대하고 경험하는 것과는 꽤 낯설다.

Lua의 추가는 훨씬 더 접근하기 쉽고 전통적인 프로그래밍 언어를 통해 TeX 기반 조판을 사용할 수 있는 능력을 열어 준다. 이 글 서두에서 언급했듯이, Lua API를 사용하면 [사실상 TeX 코드 없이 정교한 조판을](http://wiki.luatex.org/index.php/TeX_without_TeX).

### LuaTeX는 많은 새로운 primitive를 추가한다

모든 TeX 엔진은 소위 primitive 명령 수백 개를 제공한다. 이는 각 개별 조판 엔진이 지원하는 TeX 기반 언어의 기본 구성 요소이다. Donald Knuth가 발표한 TeX의 원래 버전은 약 320개의 명령을 제공했지만, 더 새로운 TeX 엔진들(pdfTeX, XeTeX, LuaTeX)은 각각 많은 새로운 primitive를 추가하여 사용자가 각 엔진의 추가 기능과 역량에 접근할 수 있게 했다. LuaTeX의 상당한 수의 새로운 primitive는 그 [참조 매뉴얼](https://www.tug.org/svn/texlive/tags/texlive-2017.1/Master/texmf-dist/doc/luatex/base/luatex.pdf?revision=44591\&view=co).

에 문서화되어 있다. LuaTeX가 도입한 많은 새로운 primitive 가운데 하나는 바로 `\directlua{...}` 인데, 이것이 Lua 코드를 사용하는 관문이다. LuaTeX 엔진의 내부에 접근하여 정교한 조판 도구와 해결책을 만들 수 있게 해준다.

### \directlua{...}: Lua 프로그래밍으로 가는 관문

논의했듯이, Lua 스크립팅 언어는 LuaTeX의 TeX 기반 조판 엔진과 LuaTeX를 구성하는 여러 구성 요소가 제공하는 기능에 접근할 수 있는 “레이어”를 제공하는 것으로 볼 수 있다. 또한 Lua 언어는 LuaTeX의 확장성을 가능하게 하는 메커니즘이기도 한데, Lua가 특화된 외부 소프트웨어/코드 라이브러리를 불러올 수 있기 때문이다.

LuaTeX가 제공하는 Lua 인터페이스(Lua 기반 함수 집합)는 통틀어 그 *Lua API*라고 불리며, LuaTeX의 내부 엔진/구성 요소와 사용자의 문서 사이의 “통신 연결”이다.

### 간단한 \directlua{...} 예제

다음 *매우 단순한* 예제는 가능성의 빙산의 일각에 닿기에도 부족하다. 그러나 이는 TeX의 매개변수에 접근하는 “TeX 방식”과 “Lua 방식” 사이의 상호 작용의 기본 아이디어를 보여 주는 데 도움이 된다.

다음에 유의하자:

* `\hsize` 는 조판 줄의 폭을 결정하는 내부 매개변수의 값을 설정하는 TeX primitive(명령)이다. 예를 들어, 보통은 적절한 값으로 설정하며 `\vbox{...}`. `\hsize` 는 Lua 코드로 접근하거나 수정할 수 있는 *많은* TeX 매개변수 중 하나일 뿐이다.
* TeX 매개변수에 접근하는 것은 *아주 작은* 부분일 뿐이다. LuaTeX의 Lua API는 훨씬 더 많은 기능을 가진다!

```latex

\documentclass{article}
\begin{document}
\let\\\relax % 확장 문제를 피하려고 \\의 의미를 다시 정의
현재 {\ttfamily\string\hsize}의 값은 다음과 같다(\LaTeX{}를 통해):
\the\hsize\par
\directlua{
%Lua API를 사용하여 \hsize의 현재 값을 가져옴
local hs=tex.hsize
% Lua API 함수를 사용해 일부를 출력
% LaTeX 코드와 \hsize의 값
tex.print("여기 {\\ttfamily\\string\\hsize}
의 값이 Lua 코드에서 보고되었습니다(스케일드 포인트 단위): ")
tex.print(hs.."\\par")
% Lua API를 사용하여 \hsize의 새 값을 설정
tex.hsize="400pt" % 또는 tex.hsize=400*65536(스케일드 포인트 단위)를 사용
}%
% \directlua가 끝난 후 LaTeX에게
% \hsize의 새 값을 알려 달라고 요청
{\ttfamily\string\hsize}의 값이 다음과 같이 보고되었다
\LaTeX{}에 의해 {\tt\string\directlua}가 끝난 후:
\the\hsize\par
\end{document}
```

LuaTeX가 위의 LaTeX 코드를 조판한 결과를 보여 주는 이미지가 여기에 있다:

![LuaTeX 실행 결과](/files/9b2c6897db9370919a0995ea988a7377f13e6c62)

TeX의 “속임수”인 `\let\\\relax` 가 LuaTeX가 Lua 코드를 “확장”하는 과정에서 생기는 문제를 피하기 위한 것임을 유의하자. 이 주제는 아래에서 간단히 언급한다.

### Lua 코드 사용하기

TeX/LaTeX 문서에서 Lua 코드를 사용하는 데는 두 가지 주요 옵션이 있다:

1. **인라인**: Lua 코드를 당신의 안에 직접 작성하기 `.tex` 문서 안에서(위의 예와 같이);
2. **외부**: Lua 코드를 외부에 저장하기 `.lua` 코드 파일에 저장하고 Lua의 기능을 사용하여 이를 불러와 실행하기.

옵션 (1)은 더 짧은 Lua 코드 조각에 가장 적합합니다. 옵션 (2)는 더 큰 프로그램이나 Lua 코드 라이브러리에 사용됩니다. 이는 TeX의 이른바 `\catcode` 값들(“꽤 답답할” 수 있습니다). 이러한 `\catcode` 문제의 원인은 LuaTeX에 내장된 Lua 인터프리터에 입력되기 전에 Lua 코드가 “확장”되기 때문입니다. 이 확장은 이해하기 까다로울 수 있으므로 다음 글에서 더 자세히 살펴보겠습니다.

물론 .tex 파일에서 Lua 코드를 사용하는 데 도움을 주는 LaTeX 패키지도 있습니다. 예를 들어, 다음을 사용할 수 있습니다 [luacode 패키지](https://ctan.org/pkg/luacode?lang=en).

## 요약 및 이 글의 파트 2 소개

LuaTeX를 구성하는 소프트웨어 구성 요소들과 내장된 Lua 스크립팅 언어는, 다양한 복잡한 조판 문제를 해결할 수 있는 솔루션을 구축하고 TeX 기반 조판 엔진과의 긴밀한 통합으로 이점을 얻을 수 있는 문서 제작 워크플로를 설계하는 데 강력한 조합을 제공합니다. 에 [이 글의 파트 2](/latex/ko/in-depth-articles/09-an-introduction-to-luatex-part-2-understanding-directlua.md) LuaTeX가 제공하는 가장 강력한 명령을 심층적으로 살펴봅니다: `\directlua`.

그때까지, LuaTeX를 즐겁게 사용하세요!

## 감사의 말

저자는 다음 분께 진심으로 감사드립니다 [Luigi Scarso](https://twitter.com/luigi_scarso), LuaTeX 개발자 중 한 명으로서 이 글의 초안을 읽고 매우 유익한 여러 의견과 제안을 해 주신 데 대해 감사드립니다. 남아 있는 사실 오류나 누락은 물론 저자의 책임입니다. 또한 다음 분께 감사드리고 싶습니다 [Patrick Gundlach](https://twitter.com/patrickgundlach), 개발자 [speedata publisher](https://speedata.github.io/publisher/), 제 질문에 답해 주신 데 대해 감사드립니다.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://overleaf-pro.ayaka.space/latex/ko/in-depth-articles/07-an-introduction-to-luatex-part-1-what-is-it-and-what-makes-it-so-different.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.