LaTeX에 점진적 타입을 입힌 ExactTeX, PDF 없이 문서의 결함을 잡는다

학술 논문이나 기술 문서를 LaTeX로 써 본 사람이라면 익숙한 장면이 있다. 상호 참조를 잘못 걸어도 컴파일은 조용히 성공하고, 본문에는 물음표 두 개(??)나 엉뚱한 번호가 박힌 채 PDF가 나온다. 그림을 가리켜야 할 참조가 표를 가리키고 있어도, 문장에서는 "그림"이라 써 놓고 실제 선언은 표여도 LaTeX는 아무 불평 없이 잘못된 단어를 찍어낸다. ExactTeX는 이 오래된 공백을 겨냥한다. LaTeX를 대체하려는 것이 아니라, 문서가 '정상인지'를 PDF를 열어보기 전에 알 수 있게 만드는 검사 계층이다.

핵심 아이디어는 TypeScript가 JavaScript에 대해 한 일과 같다. 바로 점진적 타이핑(gradual typing)이다. .tex 파일의 확장자를 .xtex로 바꾸기만 해도 그대로 동작하며, 검사받고 싶은 대상에만 이름을 붙이는 방식이다. 이름 붙이지 않은 부분은 평범한 LaTeX로 남아 바이트 단위 그대로 통과한다. 개발자는 문서의 어느 만큼을 주석 처리(annotate)할지 스스로 정하고, 그렇게 명시한 부분에 대해서만 검사가 보장된다.

두 단계의 주석과 '열린 미지 타입'

주석에는 두 층위가 있다. @id(x)는 어떤 LaTeX 구성 요소에든 붙어 참조 검사와 안전한 이름 변경을 제공한다. 정리(theorem)든 알고리즘이든 컴파일러가 그것이 무엇인지 몰라도 동작한다. 반면 \figure(x) 같은 타입 지정 블록은 컴파일러에 검사할 필드까지 넘겨준다. 이미지가 실제로 존재하는지, 캡션이 있는지, 표의 열 개수가 tabular 정의와 맞는지까지 확인하는 식이다. 잘못된 참조, 예컨대 @ref(sec:results)를 @ref(sec:resutls)로 오타 내면 ExactTeX는 그 자리에서 오류를 낸다. 게다가 오류 메시지가 LaTeX 특유의 난해한 표현이 아니라, 사용자가 직접 붙인 이름으로 말한다는 점이 실무적으로 중요하다. 도구가 사람의 언어로 대화하려면 먼저 이름이 있어야 하고, 그 이름을 부여하는 것이 바로 이 문법의 목적이다.

설계의 중심에는 ?O라는 '열린 미지 타입'이 있다. 문서 대부분은 컴파일러가 모델링하지 않는 순수 LaTeX이며, ExactTeX는 이를 나중에 고쳐야 할 결함으로 보지 않는다. 오히려 언어가 상정하는 정상 상태로 본다. 일반적인 점진적 타입 시스템에서 '미지(?)'는 고정된 타입 집합 안의 불확실성을 뜻하지만, LaTeX는 어떤 패키지든 새 생성자를 정의할 수 있어 그 집합이 열려 있다. ?O는 모든 것과 '일관(consistent)'하므로, 모델링되지 않은 LaTeX가 얽힌 부분은 절대 검사에 실패하지 않는다. 즉 .tex를 .xtex로 바꾸고 아무것도 손대지 않아도 검사는 깨끗하게 통과한다. 이것이 진입 장벽 없는 '온램프'를 말이 아닌 구조적 보장으로 만드는 장치다.

검사 커버리지와 파일 안에 사는 수정 이력

ExactTeX는 문서의 몇 퍼센트가 검사 대상인지를 커버리지 수치로 보고한다. TypeScript의 noImplicitAny에 대응하는 개념이다. 절대값보다 추세가 중요한데, 60%였던 파일이 30%로 떨어졌다면 파서가 모델링하지 못하는 무언가가 새로 들어왔다는 신호다. xtex inventory 명령으로는 문서 안의 각 식별자를 클래스, 참조 횟수, 선언 위치와 함께 표로 뽑아볼 수 있다.

또 하나 눈에 띄는 것은 수정 이력(revision) 모델이다. 워드는 .docx 안에 변경 추적 정보를 담아 도구가 편집 제안을 주고받을 수 있지만, LaTeX에는 그런 표준이 없어 도구마다 제각각 계층을 만들고 서로 호환되지 않는다. ExactTeX는 이 모델을 포맷 자체에 넣는다. 외부 검증, 즉 참고문헌 항목이나 URL·DOI·저장소를 실제 온라인 출처와 대조하는 작업은 별도의 문으로 분리돼 있다. 검증 단계가 날짜가 찍힌 기록을 남기면 컴파일러는 그것을 오프라인에서 재생하므로, 네트워크가 컴파일 과정에 끼어들지 않는다.

무엇이 단단하고 무엇이 아직 여린가

구현은 하나의 무의존성 코어와 세 개의 얇은 표면으로 이뤄진다. 터미널의 xtex, 에디터를 위한 xtex-lsp, 그리고 WebAssembly 빌드다. 세 경로가 같은 입력에 대해 동일한 답을 내도록 CI의 패리티(parity) 스위트가 강제한다. 브라우저에서는 Vitela라는 에디터로 지금 바로 써볼 수 있는데, 컴파일러의 WebAssembly 빌드 위에서 같은 검사·진단·탐색이 로컬에서 돈다. 빌드에는 Rust 1.88 이상이 필요하지만 컴파일러 자체는 외부 의존성을 내려받지 않는다.

개발자가 이 도구를 평가할 때 가장 정직하게 봐야 할 대목은 성숙도다. 문서를 실어 나르는 부분, 곧 손대지 않은 LaTeX가 바이트 단위로 그대로 나온다는 전송 보장은 가장 오래되고 가장 많이 검증된 불변식이다. 100여 쪽 분량에 패키지 40개, 색인, 장별 참고문헌, TikZ가 들어간 책이 정식 TeX Live와 동일한 페이지 수로 컴파일됐다. 반면 여러 사람이 문서를 두고 논쟁하게 해주는 부분, 즉 변경 모델은 아직 새것이다. 2026년 8월 실사용 중 하룻저녁에 결함 세 건이 드러났는데, 모두 '문서가 텍스트를 어디에 담는가'에 대해 서로 다른 규칙을 참조하던 두 코드 경로에서 비롯됐다. 세 건 모두 이전 컴파일러에서 실패하는 테스트와 함께 수정됐다. 요컨대 문서를 실어 나르는 부분은 신중하게 다져졌고, 사람들이 문서를 두고 의견을 나누게 하는 부분은 아직 여물어 가는 중이다. 논문을 저널에 넘길 때 여전히 .tex 파일을 낸다는 점, LaTeX 생태계를 떠날 필요가 없다는 점은 도입 부담을 크게 낮춘다. 다만 TypeScript가 그랬듯 이것은 '덜 쓰기 위한' 도구가 아니라, 도구가 더 많이 알도록 사람이 더 쓰는 거래라는 점을 분명히 이해하고 접근할 필요가 있다.