> 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/more-topics/18-how-overleaf-created-the-tex-primitive-reference-data.md).

# Overleaf가 TeX 기본 명령 참조 데이터를 만든 방법

이 글에서는 TeX primitive 명령의 두 상호 참조 표를 만드는 데 사용된 방법과 기법을 설명합니다:

* [TeX 엔진별로 정리한 TeX primitive](/latex/ko/more-topics/46-tex-primitives-listed-by-tex-engine.md) 그리고;
* [CJK TeX 엔진별로 정리한 TeX primitive](/latex/ko/more-topics/45-tex-primitives-listed-by-cjk-tex-engine.md).

이 정보는 세부 사항에 관심 있는 독자를 위해 제공되지만, 상호 참조 표 자체를 사용하는 데 필수적인 것은 아닙니다. 다양한 독자의 필요를 고려하여, 우리는 아주 짧은 요약판과 함께 더 깊이 살펴보고자 하는 분들을 위한 보다 긴 설명을 제공합니다.

## 짧은 요약/개요 버전

상호 참조 표를 만들기 위해 Overleaf는 9개의 TeX 엔진 소스 코드를 처리하여 각 엔진이 지원하는 primitive 목록을 추출했습니다. 그 과정에서 9개의 텍스트 파일(TeX 엔진당 1개 파일)이 생성되었습니다. 이 9개의 primitive 집합을 합쳐 “마스터 목록”을 만들었는데, 이는 사실상 개별 primitive 집합의 합집합으로, 서로 다른 엔진에 걸쳐 총 약 1000개의 고유한 primitive가 존재하게 되었습니다. 각 엔진에 대해, 해당 엔진의 primitive 목록을 마스터 파일(모든 명령의 집합)과 상호 참조하여 그 약 1000개 명령 중 어떤 것을 지원하는지 확인했습니다. 그 비교 결과는 다음 두 표에 정리되어 있습니다:

* [TeX primitive 상호 참조 데이터](/latex/ko/more-topics/46-tex-primitives-listed-by-tex-engine.md)
* [TeX primitive 상호 참조 데이터(CJK 엔진용)](/latex/ko/more-topics/45-tex-primitives-listed-by-cjk-tex-engine.md)

## “소프트웨어 빌드” 101: 그게 무슨 뜻일까?

이 글의 나머지 부분에서는 “TeX 엔진을 빌드한다”는 개념을 언급하는데, 프로그래머가 아니거나 C나 C++처럼 컴파일되는 언어를 사용해 본 적이 없다면 익숙하지 않을 수 있습니다. 여기서의 목적상, 소프트웨어—즉 TeX 엔진—를 빌드한다는 것은 프로그램을 구성하는 요소들, 곧 프로그램 개발에 사용된 프로그래밍 언어로 작성된 소스 코드 파일들로부터 실행 가능한 TeX 프로그램을 만드는 과정입니다.

## 전체 버전: 자세한 내용이 궁금하신가요? 계속 읽어보세요...

TeX 기반 조판 엔진은 모두 TeX 언어의 “방언”을 지원합니다. 즉, 각 엔진의 조판 기능을 제어하고 매크로—사용자 정의 명령 시퀀스—를 만들고 정의하기 위한 구성 요소를 제공하는 특정 primitive 명령 집합이 있습니다. LaTeX용이든 plain TeX용이든 또는 다른 어떤 매크로 패키지용이든, 모든 매크로는 결국 primitive 명령으로 구성됩니다. 다만 TeX primitive의 “기반층”에 도달하기까지는 추가 매크로의 여러 층을 상당히 깊이 파고들어야 할 수도 있습니다. primitive 명령 참조 데이터를 만들기 위해 분석한 9개의 TeX 엔진 집합은 물론 많은 명령을 서로 공유하지만, 각 TeX 엔진은 그 “버전”의 TeX에 특화된 기능을 지원하도록 개발자가 추가한 고유한 primitive 명령도 가지고 있습니다.

TeX 엔진의 primitive 명령은 실행 가능한 TeX 소프트웨어에 내장되어 있습니다. primitive는 사용자가 구성한 매크로가 아니라, 각 엔진의 조판 동작을 제어하는 데 사용되는 기본적이고 더 이상 나눌 수 없는/원자적인 지시문입니다. 따라서 어떤 TeX 엔진이 지원하는 primitive 명령의 확정적인 목록을 만드는 가장 신뢰할 수 있는 방법은 실행 가능한 TeX 프로그램이 실제로 만들어지는(컴파일되는) 소스 코드를 살펴보고, 그 소스 코드에 정의된 primitive 목록을 추출하는 것입니다. 쉬워 보이죠? 하지만 TeX의 40년에 걸친 개발 역사 때문에, LuaTeX를 제외한 TeX 엔진의 소스 코드 파일을 탐색/검토하는 일은 그리 간단하지 않습니다. 이러한 복잡성의 이유는 Knuth가 원래의 TeX 소스 코드를 작성할 때 사용한 도구, 프로그래밍 언어(Pascal), 그리고 방법론(문학적 프로그래밍)에 있습니다. 다른 모든 엔진은 결국 그 원본에서 비롯되었습니다.

LuaTeX의 경우는 예외라고 말할 수 있는데, 그 핵심 엔진 코드는 Pascal과 아래에서 자세히 설명하는 다른 레거시 복잡성(Web2C)을 제거하기 위해 C로 다시 작성되었기 때문입니다. 그 결과 LuaTeX의 소스 코드는 방대하지만, 그 “패키징”과 배포 방식은 다른 TeX 엔진에 비해 훨씬 이해하기 쉽습니다. 따라서 소스 코드로부터 빌드하는 워크플로/프로세스를 기준으로 TeX 엔진을 두 범주로 나누는 것이 편리합니다:

1. LuaTeX: 맞춤형(더 현대적인) 빌드 프로세스
2. 그 외 모든 엔진: 레거시(Web2C) 빌드 프로세스

## 레거시 코드의 맥락: 왜 (대부분의) TeX 엔진 빌드는 복잡한가

아래에서 살펴보겠지만, Knuth는 자신의 원래 TeX 소스 코드를 다음과 같은 단일 거대 파일로 공개했습니다. `tex.web` 이 파일은 7년마다 Knuth가 남아 있는 버그를 수정하기 위해 계속 업데이트하며, 새로운 기능은 절대 추가되지 않습니다. 순전히 버그 수정 작업일 뿐입니다.

TeX 소스 코드의 파일 확장자(`.web`)는 낯설게 느껴질 수 있고, Knuth가 TeX를 어떤 언어로 작성했는지 궁금할 수 있습니다. 답은 Pascal이지만, `.web` 확장자에는 조금 더 설명이 필요합니다. Knuth는 자신이 [문학적 프로그래밍](https://en.wikipedia.org/wiki/Literate_programming) 이라고 부른 프로그래밍 방법론을 개발했는데, 여기서는 프로그램의 소스 코드와 문서를 하나로 결합해 확장자 `.web`: 그 파일 형식은 WEB 파일이라고 불립니다. 아래에서 WEB 파일을 조금 더 자세히 설명합니다.

### 새 TeX 엔진 만들기: Knuth의 조건

Knuth는 오랫동안 자신의 TeX 소스 코드(`tex.web`)를 누구에게나 자유롭게 공개해 왔지만, 절대적인 권리로서 중요한 조건 하나를 제시했습니다. 그의 (`tex.web`) 소스 코드는 프로그램 이름 “TeX”으로 직접 편집/수정되어 재배포되어서는 안 된다는 것입니다. 소스 코드에서 그는 이렇게 씁니다:

```
% 이 프로그램은 D. E. Knuth의 저작권 (C) 1982에 속하며, 모든 권리는 보유됩니다.
% 이 파일의 복사는 (1) 당신이 D. E. Knuth이거나, 또는
% (2) 사본에 절대로 어떠한 변경도 가하지 않는 경우에만 허가됩니다. (WEB 시스템은
% 보조 파일을 통한 변경을 허용하며, 마스터 파일은 그대로 유지되어야 합니다.)
```

그리고 또한:

```
이 프로그램이 변경되면, 그 결과 시스템을
`\TeX'라고 불러서는 안 됩니다. 공식 이름 `\TeX' 자체는
서로 완전히 호환되는 소프트웨어 시스템에만 예약되어 있습니다.
``\.{TRIP} 테스트''라고 하는 특별한 테스트 스위트는
특정 구현이
`\TeX'로 알려질 자격이 있는지 판단하는 데 도움을 주기 위해 제공됩니다 [cf.~Stanford Computer Science report CS1027,
1984년 11월].
```

본질적으로: 마스터 TeX 소스 코드를 직접 편집하여 수정된 버전을 배포하면서 그것을 계속 `tex.web`.라고 부르지 말라는 뜻입니다. 변경을 원한다면, 예를 들어 새 primitive를 추가하는 등, “보조 파일을 통한 변경” 방식으로 그 변경을 적용해야 하며, “TeX의 파생물” 프로그램에는 “TeX”과 구별되는 이름을 붙여야 합니다. 조판 형태($$\mathrm\TeX$$),는 미국수학회의 상표입니다.

### 레거시의 계승

현대적인 프로그래밍 언어와 방법론을 사용해 TeX를 완전히 다시 작성하려는 시도—예를 들어 두 개의 Java 기반 이니셔티브 [New Typesetting System](https://en.wikipedia.org/wiki/New_Typesetting_System) 및 [εχTEX](http://www.extex.org/) 및 다음과 같은 다른 것들도 [Clojure 기반의 하나](https://www.infoq.com/news/2015/01/implementing-tex-in-clojure)가 있었지만, 어느 것도 완전히 성공하지는 못했습니다. TeX를 추가로 발전시키기 위해 설계된 프로젝트와 이니셔티브의 역사는 흥미로운 주제이며, 독자들은 더 많은 정보를 얻기 위해 [영국 TeX FAQ를 방문해](https://texfaq.org/FAQ-enginedev) 보고 싶을 수 있습니다.

e-TeX, pdfTeX, XeTeX 및 기타 엔진처럼 성공을 거둔 비-LuaTeX 이니셔티브들도 *Knuth의 원래 코드 위에 직접* 구축되었습니다. 즉, 그의 소스 코드를 가져와 추가 기능—예를 들어 새 primitive 추가, PDF 출력 생성, UTF-8 텍스트 입력 지원 등—을 갖춘 새 엔진을 만들도록 “변경을 적용”한 것입니다. 이 방식은 눈에 띄는 성공을 가져왔지만, 동시에 이러한 파생 엔진이 Knuth가 40년 전에 만든 레거시 코드와 개발 기법을 그대로 계승한다는 뜻이기도 합니다.

여기서 핵심은 LuaTeX를 제외하면, Knuth의 원래 소스 코드에서 파생된 대부분의 TeX 엔진은 단일 거대 파일(보통 `tex.web`)을 가져와 그 새 엔진의 핵심 소스 코드를 담은 또 다른 단일 거대 파일을 생성하는 변경을 적용함으로써 만들어진다는 점입니다. 고급 독자라면 다음의 자격 요건이 붙은 [pdfTeX 및 XeTeX에 대한 주석으로 건너뛰고 싶을 수 있습니다.](#aside-xetex-and-pdftex).

### TeX의 약간 더 많은 역사/배경

TeX의 탄생 순간은 [Knuth의 일기에 1977년 3월 30일로 기록되어 있습니다](/latex/ko/in-depth-articles/55-what-s-in-a-name-a-guide-to-the-many-flavours-of-tex.md#the-genesis-of-tex-a-brief-history), 지금으로부터 40년이 훨씬 넘었습니다. 내부적으로 TeX는 소스 코드를 Knuth가 매우 세심하게 [예외적으로 자세히 문서화했습니다](https://www.amazon.co.uk/Computers-Typesetting-TeX-Program-TEX/dp/0201134373). 이를 위해 Knuth는 자신이 [문학적 프로그래밍](https://en.wikipedia.org/wiki/Literate_programming) 문학적 프로그래밍 `.web` 이라고 부른 프로그래밍 스타일을 개발했는데, 여기서 프로그램의 소스 코드와 문서가 하나로 결합되어 확장자 `tex.web`(WEB 파일이라고 부름)로 된 복합 파일로 공개됩니다. Knuth는 TeX 소프트웨어를 작성하는 프로그래밍 언어로 Pascal을 선택했고, 놀랍지 않게도 최종 문서를 쓰는 데는 TeX 조판 언어를 사용했습니다. 따라서 Knuth의 TeX 마스터 소스 코드는 다음과 같은 단일 거대 파일로 공개됩니다.

: Pascal 소스 코드와 문서용 TeX 조판 코드가 뒤섞인 파일입니다. `tex.web`프로그램이 Knuth의 문학적 프로그래밍 스타일/방법론(TeX, MetaFont, BibTeX 등처럼)으로 작성되었다면 문서나 소스 코드를 추출하기 위해 WEB 파일을 전처리해야 합니다. 프로그램 문서에 접근하려면 WEB 파일을 (예를 들어, [WEAVE](http://tug.org/texinfohtml/web2c.html#weave-invocation) 라는 유틸리티로 처리하며, 그러면 문서를 `.tex` 조판할 수 있는 파일로 생성합니다. Pascal 소스 코드를 추출하려면 다음과 같은 또 다른 유틸리티를 사용합니다. [TANGLE](http://tug.org/texinfohtml/web2c.html#tangle-invocation) 을 사용하며, 그러면 확장자 `.p` 를 가진 파일이 생성되고, 그 안에는 Pascal 소스 코드가 들어 있습니다.

작성 시점(2019년 초) Knuth의 TeX 최신 버전은 2014년 1월 날짜의 3.14159265입니다. 다시 말해, Knuth의 TeX 소스 코드는 약 25,000줄의 TeX/Pascal 코드가 들어 있는 단 하나의 파일에 담겨 있습니다!

### Pascal에서 C로

TeX가 탄생한 지 40여 년이 지난 동안 Pascal은 유행에서 벗어났고, 오늘날에는 원래의 Pascal 소스 코드로 TeX를 빌드하려는 사람은 거의, 혹은 아예 없다고 해도 과언이 아닙니다. Knuth가 Pascal을 사용한 점을 우회하기 위해 [Web2C](http://tug.org/texinfohtml/web2c.html) 라고 하는 워크플로가 (1987년 무렵) 설계되었는데, 여기서 TeX의 Pascal 소스 코드를 기계적으로(즉, 소프트웨어를 통해) C 코드에 해당하는 형태로 변환하고, 그런 다음 그 C 코드를 사용해 TeX를 컴파일하고 실행 파일을 빌드합니다. 이 방식은 잘 작동하지만, 단 하나의 단점은 기계적으로 생성된 C 소스 코드가 일반적인 사람이 훑어보도록 만들어진 것이 아니라는 점입니다. 그것은 *매우* 장황하고 거의 뚫을 수 없을 정도로 난해하며, 컴파일러를 위한 것이지 사람을 위한 것이 아닙니다—다음은 TeX의 Pascal 소스에서 생성된 C 코드의 작은 일부를 보여주는 스크린샷입니다:

![](/files/6222cbe8f29e6dffc83dcae41c0f16864ae626d4)

### 또 하나의 Knuth식 표현: WEB 변경 파일

앞서 언급했듯이 Knuth의 원래 소스 코드 위에 구축하려면 “변경을 적용”하거나, Knuth의 말로는 “보조 파일을 통한 변경”을 해야 합니다. 그런데 이것이 실제로는 무슨 뜻일까요? 바로 *변경 파일 메커니즘*.

### 변경 파일: 새 TeX 엔진을 만드는 메커니즘

어떤 식으로든 Knuth의 TeX를 확장하고자 하는 개발자, 즉 Knuth의 원래 작업을 기반으로 하려는 개발자들은 대개 TeX의 완전히 새로운 “버전”을 만들거나, 어떤 TeX 엔진에도 추가할 수 있는 *확장 기능* 을 제공하고자 합니다. 확장 기능의 예로는 [SyncTeX](https://github.com/jlaurens/synctex) 및 [EncTeX](https://ctan.org/pkg/enctex?lang=en)가 있습니다. 예를 들어 SyncTeX는 지금은 모든 TeX 엔진에 포함되는 매우 유용한 확장 기능입니다. EncTeX의 필요성은 Unicode를 인식하는 TeX 엔진의 발전으로 상당 부분 대체되었지만, EncTeX는 pdfTeX에 내장되어 있다는 점에 유의해야 합니다.

새로운 TeX의 “버전”(즉, Knuth의 원래 TeX의 파생물)을 만들고자 하든, 확장 기능을 만들고자 하든, 개발자들은 Knuth의 원래 소스 코드에서 시작해 새로운 TeX 엔진(또는 추가 기능 확장)을 만들기 위해 필요한 수정 사항을 적용합니다. 그러나 앞서 언급했듯이, TeX의 동작을 수정하고자 하는 사람은 반드시 “보조 파일을 통한 변경” 방식을 사용해야 합니다. 이러한 변경/수정은 *직접* Knuth의 원래 소스 코드를 편집하는 방식으로 적용해서는 안 되기 때문입니다. 개발자들은 소위 WEB *변경 파일 메커니즘*.를 사용해야 합니다. Knuth의 TeX를 수정하는 코드는 WEB “언어”로 작성되어 하나 이상의 코드 파일(라고 불리는 *변경 파일*)에 저장되며, 이후 *병합* 되어 Knuth의 원래이지만 손대지 않은 마스터 소스 코드와 합쳐집니다. 그 병합 과정은 이제 새/수정된 TeX 기반 소프트웨어의 *핵심* 소스 코드를 담은 새로운 복합 WEB 파일을 만듭니다. *변경 파일* 은 `.ch` 확장자를 갖는 경우가 많지만, 실제로는 개발자가 원하는 어떤 확장자도 사용할 수 있습니다.

#### 변경 파일은 어떻게 사용/적용하나요?

요즘에는 변경 파일을 적용하고 “마스터” WEB 파일을 수정하는 가장 쉬운 방법은 [TIE](https://ctan.org/pkg/tie).라는 유틸리티 프로그램을 사용하는 것입니다. 예를 들어, Knuth의 TeX를 수정하여 새 primitive를 몇 개 추가하거나 기존(표준) TeX primitive의 동작을 바꾸고 싶다고 가정해 봅시다. 여러분은 WEB 시스템의 문학적 프로그래밍 방식을 사용해 코드를 (Pascal로!) 작성하고, 예를 들어 `myprim.ch`.라는 파일에 저장합니다. 다음 단계는 여러분의 코드( `myprim.ch`)를 Knuth의 마스터 소스 파일 `tex.web` 와 병합하여 우리가 `mytex.web`.라고 부를 새로운 복합 WEB 파일을 만드는 것입니다. 이를 위해 TIE 프로그램을 다음처럼 실행하면 됩니다:

```
tie -m mytex.web tex.web myprim.ch
```

병합이 성공하면, 그 결과 새 WEB 파일 `mytex.web`이 생성되고, Knuth의 마스터 소스 파일 `tex.web` 은 요구사항대로 완전히 변경되지 않은 채로 유지됩니다.

이제 다른 사람이 여러분의 변경을 마음에 들어 하여, 여러분이 한 작업 위에 자기 변경을 추가하거나 더해 수정하고 싶다고 가정해 봅시다. 여러분의 수정된 TeX 버전(`mytex.web`)을 배포하는 대신, 변경 파일 `myprim.ch`만 게시/공유하기로 결정합니다. `이제 여러분의 작업을 기반으로 하려는 사람은 누구나 예를 들어` moreprim.ch *와 같은 자신의 변경 파일을 만들고 공유할 수 있습니다. 그러면 다른 사람도 두 변경 파일을 모두 활용하고 싶다면, 이를 Knuth의 원래 파일에 병합해 예를 들어* 두 `newmytex.web`:

```
라고 하는 또 다른 TeX 프로그램을 생성함으로써 새로운 복합 WEB 파일을 만들 수 있습니다.
```

### 실제 TeX 시스템: 여러 개의 변경 파일

위의 TIE 설명은 실제로 많은 TeX 엔진이 빌드되는 방식과 매우 가깝습니다. 즉, Knuth의 `tex.web` 에서 시작하여 일련의 변경 파일을 추가해 그 엔진의 WEB 소스 파일을 생성합니다. 각 TeX 엔진은 고유한 변경 파일 집합을 필요로 하며, 이 파일들은 엄격한 순서로 적용/처리(병합)되어야 합니다. 순서를 잘못하면 병합 과정이 실패하는데, 이는 순차적으로 이어지는 각 변경 파일이 체인에서 앞선 변경 파일이 도입한 변경 사항에 의존하기 때문입니다.

다음은 Knuth의 `tex.web` 에 여러 변경 파일을 적용해 `ktex.web`를 생성하는 TIE의 예시 실행입니다.—Knuth의 TeX에 수정 사항을 더해 Web2C 과정을 통해 C로 변환할 준비가 된(적합한) 복합 WEB 파일입니다. 또한 다음 사항에 유의하세요:

* `tex.ch` 는 매우 큰 변경 파일로, 많은 것들 중에서 TeX를 Kpathsea를 사용하도록 수정합니다.
* SyncTeX 확장 기능은 여러 변경 파일을 통해 추가됩니다.

```
tie -m ktex.web tex.web tex.ch enctex.ch synctex-def.ch0 synctex-mem.ch0 synctex-mem.ch2 synctex-rec.ch0 synctex-rec.ch1 synctex-rec.ch2 tex-binpool.ch
이것은 TIE, CWEB 버전 2.4입니다.
저작권 (c) 1989,1992 THD/ITI. 모든 권리 보유.
(tex.web)
(tex.ch)
(enctex.ch)
(synctex-def.ch0)
(synctex-mem.ch0)
(synctex-mem.ch2)
(synctex-rec.ch0)
(synctex-rec.ch1)
(synctex-rec.ch2)
(tex-binpool.ch)
....500....1000....1500....2000....2500....3000....3500....4000....4500
....5000....5500....6000....6500....7000....7500....8000....8500....9000
....9500....10000....10500....11000....11500....12000....12500....13000
....13500....14000....14500....15000....15500....16000....16500....17000
....17500....18000....18500....19000....19500....20000....20500....21000
....21500....22000....22500....23000....23500....24000....24500....
(오류는 발견되지 않았습니다.)
```

#### 보충: XeTeX 및 pdfTeX

완결성을 위해, pdfTeX과 XeTeX의 빌드 프로세스는 실제로 Knuth의 `tex.web`에서 시작하지 않는다는 점을 언급해야 합니다. 대신 다음으로 시작합니다. `pdftex.web` 및 `xetex.web` 각각 해당 파일에서 시작합니다. 아마도 변경 사항이 너무 광범위해서, Knuth의 원래 코드에 가해진 매우 중요한 수정 사항이 이미 포함된 WEB 파일을 공유/게시하는 것이 더 타당하기 때문일 것입니다.

### 예시: e-upTeX

일본 TeX 커뮤니티는 일본어 텍스트 조판의 복잡성을 다루기 위해 설계된 여러 TeX 엔진을 개발했습니다:

* **pTeX**: 일본어 조판을 지원하도록 확장된 Knuth의 TeX 엔진;
* **e-pTeX**: e-TeX와 pTeX의 결합(그리고 pdfTeX에서 도입된 몇몇 primitive 추가);
* **upTeX**: CJK(중국어, 일본어, 한국어)를 더 잘 처리하기 위한 확장을 더한, Unicode를 인식하는 pTeX 버전;
* **e-upTeX**: e-TeX와 upTeX의 결합(병합).

#### e-upTeX용 복합 소스 파일 생성

SyncTeX가 포함된 e-upTeX의 복합 WEB 소스 파일을 만들려면 Knuth의 `tex.web` 로 시작해야 하지만, 아래 순서로 **26** 개별 변경 파일

```
을 적용해야 하며, 그렇게 하면 primitive 명령 목록을 추출할 수 있는 단일 복합 파일이 생성됩니다:
etex.ch, tex.ch0, tex.ch, tex.ech, etex.ch0,
ptex-base.ch, uptex-m.ch, euptex.ch0, eptex.ech,
etex.ch1, euptex.ch1, synctex-def.ch0, synctex-ep-mem.ch0,
synctex-mem.ch0, synctex-e-mem.ch0, synctex-ep-mem.ch1,
synctex-p-rec.ch0, synctex-rec.ch0, synctex-rec.ch1,
synctex-e-rec.ch0, synctex-p-rec.ch1, fam256.ch,
pdfstrcmp-eup-pre.ch, pdfutils.ch, pdfstrcmp-eup-post.ch,
```

#### 변경 파일 적용: 어떤 파일을 어떤 순서로?

앞서 언급했듯이, 변경 파일은 엄격한 순서로 적용/처리하는 것이 매우 중요합니다. 그런데 필요한 파일이 무엇인지, 그리고 어떤 순서로 처리해야 하는지 어떻게 알 수 있을까요? 다행히도 그 핵심 정보는 TeX Live 배포판에 포함된 파일들 안에 기록되어 있으며, TeX Live 소스 코드를 살펴본 결과 각 TeX 엔진의 빌드 요구사항을 규정하는 규칙을 확인할 수 있었습니다. 그 규칙에 따라 Overleaf는 각 TeX 엔진에 대한 복합 WEB 소스 코드 파일을 재구성하고, 이후 데이터 처리용 primitive 목록을 추출할 수 있었습니다.

## 마지막으로: primitive 목록은 어떻게 추출하나요?

복합 WEB 파일이 만들어지면, 정규 표현식을 사용해 primitive 목록을 추출하는 작업은 간단합니다. 모든 primitive 명령이 다음과 같은 단일 Pascal 함수로 정의(“등록”)되기 때문입니다. `primitive(...)`. 다음은 Knuth의 `tex.web` 소스 코드에서 가져온 실제 예시입니다:

```
primitive("lineskip",assign_glue,glue_base+line_skip_code)
primitive("baselineskip",assign_glue,glue_base+baseline_skip_code)
primitive("parskip",assign_glue,glue_base+par_skip_code)
primitive("abovedisplayskip",assign_glue,glue_base+above_display_skip_code)
primitive("belowdisplayskip",assign_glue,glue_base+below_display_skip_code)
primitive("abovedisplayshortskip",assign_glue,glue_base+above_display_short_skip_code)
...
...
```

보시다시피, `primitive(...)` 함수는 정규 표현식을 이용한 텍스트 처리에 매우 적합합니다. 등록되는 primitive의 이름은 따옴표(`"..."`) 안에 있으며, 각 primitive의 동작을 분류하는 추가 데이터도 함께 있습니다(이에 대해서는 자세히 다루지 않겠습니다). 각 엔진의 primitive 목록을 추출한 뒤, 해당 데이터는 몇몇 Lua 스크립트로 처리되어 표 형식의 결과를 담은 HTML을 생성했습니다.

### LuaTeX로 돌아가기

LuaTeX는 다른 8개의 TeX 엔진과 정확히 같은 빌드 프로세스를 사용하지 않는다는 점을 언급했습니다. Web2C 프로세스, Pascal에서 C로의 변환, 그리고 변경 파일 메커니즘을 간단히 살펴본 이제, LuaTeX가 어디에서 다른지 설명할 수 있습니다. LuaTeX 개발자들은 번거로운 Pascal에서 C로의 변환 과정을 없애기로 결정했습니다. 다음에 언급된 바와 같이 [LuaTeX 참고 매뉴얼](http://www.pragma-ade.com/general/manuals/luatex):

> …컴파일 프레임워크는 web2c이며 우리는 그것을 계속 사용하지만 Pascal에서 C로 가는 단계는 없습니다.

LuaTeX 핵심 엔진은 C로 다시 작성되었기 때문에 빌드 프로세스는 다소 더 표준적이고 확실히 훨씬 편리합니다. 그 유용한 결과 중 하나는 LuaTeX가 지원하는 primitive가 별도의 C 소스 코드 파일로 깔끔하게 분리되어 있어, 이를 접근/목록화하는 작업이 상당히 쉬워졌다는 점입니다.

엄밀히 말하면, LuaTeX의 소스 코드 파일 중 일부는 Knuth의 문학적 프로그래밍 방법론의 변형인 [CWEB](https://en.wikipedia.org/wiki/CWEB)를 사용하며, 이는 Pascal이 아니라 C를 기반으로 합니다.

### WEB 파일만이 전부는 아닙니다: 다른 소스 코드도 필요합니다

LuaTeX를 제외한 어떤 TeX 엔진이든 복합 WEB 소스 파일을 생성한 뒤에는 Pascal 소스 코드를 추출하여 C 코드로 변환해야 하지만, 그것만으로는 충분하지 않습니다. WEB 소스(Pascal⮕C)에서 생성된 C 코드 외에도 대부분의 TeX 엔진은 일반적으로 C로 작성되는 여러 개의 추가 보조 소스 코드 파일(라이브러리)—예를 들어 [Kpathsea](https://www.tug.org/kpathsea/)—에도 의존(요구)합니다. 보조 소스 파일(라이브러리)은 WEB(Pascal)로 작성할 필요가 없거나, 그렇게 작성할 수 없는 기능을 구현합니다. TeX를 위해 WEB “언어”로 작성되는 것은 모두 Pascal 언어를 사용해야 하며, 이후 추출되어 기계가 생성한 C로 변환됩니다. 굳이 그렇게 할 필요가 없다면, 처음부터 C나 C++로 그냥 작성하면 됩니다.


---

# 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/more-topics/18-how-overleaf-created-the-tex-primitive-reference-data.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.