LaTeX에서 막혔을 때 답을 가진 사람은 대개 tex.stackexchange.com에 있습니다. 다만 이 커뮤니티에는 입장료가 있고, 그 입장료는 예의가 아니라 최소 재현 예제(minimal working example, 줄여서 MWE) 입니다. 얼마나 진지하냐면, TeX Live에는 최소 예제를 공유하기 쉽게 만드는 것만이 목적인 mwe라는 패키지가 들어 있고, texdoc minexample을 치면 오직 “최소 예제를 만드는 법”만 다루는 21쪽짜리 소책자가 열립니다. 이 페이지에서는 LaTeX 질문을 어디로 가져갈지——TeX Stack Exchange, Usenet의 comp.text.tex이 남긴 것, TUG와 각국 사용자 모임, 패키지의 이슈 트래커——그리고 답이 돌아오는 질문법, 곧 300쪽짜리 문서를 스무 줄까지 깎아 내는 손놀림을 다룹니다.
묻기 전에 tex.stackexchange.com을 검색합니다
LaTeX 질문의 대부분은 이미 누군가가 같은 표현으로 물었습니다. TeX Stack Exchange(tex.stackexchange.com)가 만들어진 것은 2010년 8월입니다. 이 날짜는 전해 들은 이야기가 아니라 LaTeX 팀 자신의 소식지에 남아 있습니다. TeX Live에 함께 실리는 『LaTeX3 News』 제5호(2011년 1월)는 TeX Stack Exchange 질의응답 사이트가 만들어져 빠르게 성장했으며, 집필 시점에 약 2,800명이 2,600개의 질문을 올려 답변이 모두 5,600개, 하루 2,200명이 방문한다고 적고 있습니다. 내 컴퓨터에서 texdoc l3news를 치면 같은 쪽이 열립니다. 십수 년이 지나 자릿수가 두 개쯤 늘었지만, 정말로 불어난 것은 무엇보다 과거 질문의 재고입니다. 검색에는 요령이 하나 있습니다. 문제를 자기 말로 풀어 쓰지 말고 오류 메시지를 원문 그대로 붙여 넣는 것입니다. ! Undefined control sequence나 ! Missing $ inserted 같은 한 줄이 가장 좋은 검색어입니다.
그 앞의 삼십 년 동안 TeX 논의의 중심은 Usenet 뉴스그룹 comp.text.tex이었습니다(독일어권에는 de.comp.text.tex이 있었습니다). 얼마나 중심이었는지는 그 시절 책의 감사의 글을 보면 알 수 있습니다. Victor Eijkhout은 『TeX by Topic』(Addison-Wesley, 1991)의 감사의 글에서 토론 목록 TeXhax, 네덜란드의 TeX-nl, 그리고 comp.text.tex의 참가자들에게 고마움을 표하며 그들의 질문과 답이 생각할 거리를 주었다고 적었습니다. 이 책은 TeX Live에 함께 실려 있어 texdoc texbytopic으로 읽을 수 있습니다. 감사의 글까지 그대로 읽히므로 중심이 옮겨 간 과정을 눈으로 확인할 수 있습니다. 뉴스그룹은 지금도 살아 있지만, 오늘 LaTeX 질문을 한다면 첫 선택지는 TeX Stack Exchange입니다. 오래된 글이 검색에 걸리는 일은 여전하니, 걸렸을 때는 반드시 몇 년도 글인지 확인하세요.
최소 재현 예제(MWE)란 무엇인가
MWE란 문제를 재현할 수 있는 가장 짧은 “완결된” 문서이며, 이때 ‘완결’은 엄격하게 읽어야 합니다. Nicola L C Talbot의 『Creating a LaTeX Minimal Example』(2014, TeX Live 동봉, texdoc minexample)은 서두에서, 최소 예제에는 문제와 무관한 패키지나 코드가 하나도 들어가서는 안 되지만 문서 클래스와 document 환경은 반드시 포함해야 한다고 못 박습니다. 곧 조각이 아닙니다. 상대가 그대로 저장해 pdflatex에 넣을 수 있는 것——이름에 들어 있는 ‘working’이 뜻하는 바가 그것입니다. 반대로 \begin{document}가 없는 세 줄짜리 코드 조각을 붙이면 첫 답변은 “완전한 예제를 올려 주세요”가 되고, 왕복이 한 번 늘어납니다.
% A minimal working example: complete, compilable, and as short as it can be.
% Nothing here that does not bear on the problem being reported.
\documentclass{article}
\usepackage{booktabs}
\begin{document}
\begin{tabular}{ll}
\toprule
left & right \\
\bottomrule
\end{tabular}
\end{document}예제에 그림이 필요할 때가 곤란합니다. 내 사진은 보낼 수 없고, 보낸다 해도 상대 환경에는 없기 때문입니다. 여기서 힘을 발휘하는 것이 mwe 패키지입니다. \usepackage{mwe}라고 쓰면 graphicx를 읽어 들이고, example-image, example-image-a, example-image-16x9, example-grid-100x100bp 같은 표준 이미지들을 TeX 트리에서 바로 쓸 수 있게 해 줍니다. TeX Live를 설치한 사람이면 누구나 이미 가지고 있으므로, \includegraphics{example-image}가 들어간 예제는 누구의 컴퓨터에서도 그대로 컴파일됩니다. 같은 이치로 본문이 길게 필요할 때는 lipsum의 \lipsum[1-3]이나 blindtext의 \blindtext를 씁니다(mwe는 lipsum이 있으면 자동으로 읽어 들입니다). 첨부 파일이 필요 없는 예제는 그 이유만으로도 답이 빨라집니다.
300쪽을 스무 줄로 깎기——building up과 hacking down
길은 둘뿐이며, Talbot은 그것을 building up(쌓아 올리기)과 hacking down(깎아 내리기)이라 부릅니다. 쌓아 올리기는 \documentclass{article}과 빈 document 환경만으로 시작해 문제가 나타날 때까지 하나씩 더해 가는 방법이고, 깎아 내리기는 실제 문서의 사본에서 문제가 사라질 때까지 덜어 내는 방법입니다. 원고가 짧으면 쌓아 올리기가, 300쪽이라면 깎아 내리기가 빠릅니다. 다만 깎아 내릴 때 한 줄씩 하면 안 됩니다. 절반씩 지우세요. 전처리부의 앞 절반을 주석 처리해 문제가 그대로면 그 절반은 무죄임이 한 번에 밝혀집니다. 남은 절반을 다시 절반으로, 또 절반으로——열 몇 번이면 수백 줄이 몇 줄이 됩니다. 이것이 곧 이진 탐색이며, \include된 장에도 같은 수를 쓸 수 있습니다.
- 사본을 만듭니다. 원본
.tex은 절대 건드리지 않고, 모든 삭제는 복사본 위에서 합니다. - 본문부터 버립니다.
\include된 장, 그림, 표, 참고문헌을 덜어 내고\begin{document}바로 뒤에 문제가 되는 한 줄만 남깁니다. - 전처리부를 절반씩 지웁니다. 문제가 남으면 지운 쪽은 무죄이고, 문제가 사라지면 방금 지운 쪽을 의심해 다시 절반으로 나눕니다.
- 직접 만든 매크로를 펼칩니다.
\newcommand를 그 내용으로 바꿔 놓으면 “내 매크로의 문제”와 “패키지의 문제”가 갈립니다. - 클래스를
article로 바꿔 봅니다. 그랬더니 재현되지 않는다면 클래스가 원인이며, 그것도 훌륭한 발견입니다. 보고할 때 그 사실까지 함께 적으면 됩니다. - 깎을 때마다 컴파일합니다. 너무 깎아서 문제가 이미 사라졌다는 것을 모른 채 계속 진행하는 것이 가장 흔한 실패입니다.
다 깎았으면 마지막으로 버전 정보를 덧붙입니다. 손으로 적을 필요는 없습니다. \documentclass 앞에 \listfiles 한 줄을 넣고 컴파일하면 .log 끝에 *File List*라는 절이 생기고, 읽어 들인 파일들의 날짜와 버전이 모두 나열됩니다. 여기에 엔진(pdflatex / xelatex / lualatex)과 배포판(TeX Live 2024, MiKTeX, Overleaf)을 적어 주면 답하는 사람이 사실상 내 환경을 재구성할 수 있습니다. 오류는 요약하지 말고, !로 시작하는 줄과 뒤따르는 몇 줄을 그대로 붙여 넣으세요. “뭔가 오류가 납니다”라는 설명은 원문 한 줄보다 반드시 정보가 적습니다.
% \listfiles before \documentclass, then look at the end of the .log:
*File List*
article.cls 2023/05/17 v1.4n Standard LaTeX document class
size10.clo 2023/05/17 v1.4n Standard LaTeX file (size option)
booktabs.sty 2020/01/12 v1.61803398 Publication quality tables
***********Stack Exchange 밖의 창구——TUG, 각국 사용자 모임, 이슈 트래커
TUG(TeX Users Group) 는 1980년에 발족한 국제 비영리 회원 조직으로, TeX Live를 포함한 개발을 뒷받침하고 기관지 TUGboat를 발행하며 연례 학회를 엽니다. TUGboat가 단순한 읽을거리가 아니라는 것은 내 컴퓨터에서 확인할 수 있습니다. 투고용 클래스 파일 ltugboat.cls가 TeX Live에 함께 들어 있고(저작권 표시는 “Copyright 1994-2023 TeX Users Group”, 관리 주체는 TUG 자신입니다), texdoc tugboat을 치면 투고자용 안내서 ltubguid.pdf가 열립니다. 다시 말해 TeX에 관해 알게 된 것을 써서 발표하고 싶어지면, 그 조판 도구는 이미 설치되어 있는 셈입니다.
TeX 세계는 나라별 사용자 모임으로도 지탱됩니다. TeX Live 공식 안내서는 감사의 글에서 TUG, 독일어권의 DANTE e.V., 네덜란드의 NTG, 폴란드의 GUST가 필요한 기술적・행정적 기반을 제공해 주었다고 적고, “가까운 TeX 사용자 모임에 가입해 달라”는 말과 함께 tug.org/usergroups.html을 안내합니다. 스페인어권의 CervanTeX도 TeX Live에 FAQ를 기여하고 있으며 tlmgr info es-tex-faq로 확인할 수 있습니다. 일본어권에서는 일본어 TeX 개발 커뮤니티(texjporg) 가 pLaTeX・upLaTeX, jsclasses(원래 오쿠무라 하루히코가 만들었습니다), dvipdfmx의 일본어 지원, gentombow, ptex2pdf 등을 관리하며 TeX Wiki(texwiki.texjp.org)를 운영합니다. 일본어로 묻는다면 오쿠무라 선생의 TeX 포럼(okumuralab.org/tex/)이 사실상의 창구입니다. 그 밖에 latex.org 포럼, 메일링 리스트 [email protected], Reddit의 r/LaTeX가 있습니다.
질문이 아니라 버그라는 확신이 들면 갈 곳이 달라집니다. 패키지 고유의 결함은 저자의 이슈 트래커로 갑니다. 주소는 찾아다닐 필요가 없습니다. 이미 내 컴퓨터에 있기 때문입니다. tlmgr info <패키지이름>의 출력에 cat-contact-bugs나 cat-contact-repository 줄이 있다면 그것이 공식 보고처입니다(예를 들어 tlmgr info mwe는 GitHub 이슈 페이지를 돌려줍니다). 한편 LaTeX 본체, 곧 커널의 결함은 LaTeX Project(latex-project.org)로 보내며, 이때는 latexbug 패키지를 씁니다. 이 패키지는 버그를 분류하기 위한 것으로, LaTeX 팀은 버그 보고에 첨부하는 테스트 파일에 이것을 읽어 들이도록 요청합니다. 읽어 들이면 그 버그가 정말 커널의 것인지 제3자 패키지의 것인지 판정해 줍니다. 주소를 잘못 쓴 보고는 어디에도 닿지 않은 것과 같습니다.
| 보낼 곳 | 어울리는 용건 | 비고 |
|---|---|---|
tex.stackexchange.com | “어떻게 쓰면 되는가”, “왜 오류가 나는가” 전반 | 2010년 8월 개설. 먼저 검색하고, 그다음 MWE와 함께 질문 |
texwiki.texjp.org | 일본어 환경의 설치・설정과 일본어 글꼴 | 일본어 TeX 개발 커뮤니티가 운영 |
[email protected] | 토론에 가까운 주제, 역사적 경위에 대한 상담 | TUG의 메일링 리스트. 즉답형은 아닙니다 |
cat-contact-bugs | 특정 패키지의 버그와 기능 요청 | tlmgr info <패키지이름>이 주소를 알려 줍니다 |
latexbug | LaTeX 커널 자체의 버그 | 테스트 파일에 읽어 들이면 보낼 곳을 가려 줍니다 |
답이 돌아오는 질문을 쓰는 법
필요한 것은 넷뿐입니다. 짧은 증상 설명, MWE, 오류 원문, 그리고 시도해 본 것. Talbot은 앞의 소책자에서 증상 설명은 간결하게 하고, 원인을 좇기 위해 무엇을 시도했는지 나열하며, 프로젝트 전체에 대한 긴 이야기로 빠지지 말라고 권합니다. 정보가 너무 많으면 읽을 마음이 사라지기 때문입니다. 그리고 잊히기 쉬운 전제 하나를 분명히 적어 둡니다. 아무도 보수를 받지 않고, 답할 의무도 없다는 것——그러니 요구나 비난처럼 들리는 문장은 피하라는 것입니다. 이 조언이 2014년에 쓰였고 지금도 같은 모습으로 TeX Live에 실려 있다는 사실 자체가 이 커뮤니티의 기풍을 말해 줍니다. 하나 덧붙이자면, “하고 싶은 것”을 적는 일을 잊지 마세요. 실패한 방법만 보여 주면 아무도 더 쉬운 다른 길을 제안할 수 없습니다.