Pandoc - pandoc의 20년

2006년 8월 3일, 저는 pandoc의 첫 버전을 제 웹사이트에 올리고 자유 GPL 라이선스로 공개했습니다. Pandoc 0.1은 GHC 표준 라이브러리 외에는 의존성이 없는 약 3000줄의 Haskell 코드로 이루어져 있었습니다. Markdown, reStructuredText, HTML, LaTeX 문서를 이들 형식 가운데 어느 것으로든, 또한 RTF나 S5로 변환할 수 있었습니다. 당시에는 이것이 이후 20년에 걸쳐 200회가 넘는 릴리스 중 첫 번째에 불과하리라고는 전혀 몰랐습니다. 이 프로젝트가 Haskell로 작성된 가장 인기 있는 프로그램이 되리라는 것도, 제가 버그 수정과 개선, 프로젝트 관리에 셀 수 없이 많은 시간을 쓰게 되리라는 것도, 여러 나라의 프로그래머들과 협업하게 되리라는 것도, pandoc이 50개가 넘는 문서 형식을 지원하게 되리라는 것도, 인용과 참고문헌을 자동 생성하게 되리라는 것도, Quarto 및 Jupyter Notebook 같은 학술 글쓰기 도구에 통합되리라는 것도, 전 세계 수백만 대의 컴퓨터에 설치되리라는 것도 말입니다.

어떻게 이런 일이 일어났을까요? pandoc의 생일을 계기로, 제가 기억하는 한 이 프로젝트의 이야기를 들려드리고 싶습니다.

John MacFarlane

2026년 8월 2일

전사

사람들은 흔히 묻습니다. 왜 pandoc은 Haskell로 작성되었을까요? 이 질문에는 그럴듯한 답이 있을 법합니다. Haskell은 이런 종류의 애플리케이션을 작성하기에 아주 좋은 언어입니다. 그러나 사실 저는 문서 변환기를 쓰기로 결정한 다음 그것에 Haskell을 쓰기로 결정한 것이 아닙니다. Haskell을 쓰기로 결정한 뒤, 그것으로 문서 변환기를 작성하기로 했습니다.

저는 철학 논리학자인 친구 Greg Restall의 블로그를 통해 Haskell을 알게 되었습니다. 그는 Haskell 입문서에 관해 이렇게 말했습니다. “1986년 오래전에 들었던 내 컴퓨터 과학 입문 과정의 교재가 이것이 아니어서 다행이다. 그랬다면 나는 컴퓨팅과 사랑에 빠져 철학자가 되지 않았을지도 모른다” (consequently.org).

이 말에 흥미를 느낀 저는, 미래의 철학적 생산성에 미칠 영향에 대한 Restall의 경고는 무시한 채, 언어의 기초를 이해하려고 A Gentle Introduction to Haskell을 읽었습니다. 하지만 프로그래밍 언어를 제대로 배우는 유일한 방법은 그 언어로 무언가를 작성하는 것입니다. Haskell이 파서와 컴파일러 작성에 좋고 훌륭한 파서 조합자 라이브러리(parsec)도 포함한다는 것을 알았기에, Markdown 파서를 쓰기로 했습니다.

그때는 Perl, Python, Ruby, PHP로 작성된 Markdown 구현체들이 있었으며, 모두 일련의 정규식 변환을 통해 Markdown을 HTML로 직접 변환했습니다. Pandoc은 다른 접근법을 택했습니다. 파서 조합자로 Markdown을 구문 분석하고, 실제 추상 구문 트리(AST)를 생성한 뒤 이를 HTML이나 다른 형식으로 렌더링했습니다. 이는 더 신뢰할 수 있는 아키텍처였습니다(정규식 기반 버전의 많은 특이점을 피할 수 있었습니다). 또한 더 확장 가능했습니다. $N$개의 파서(“리더”)와 $M$개의 렌더러(“라이터”)를 작성하면 $N × M$개의 변환을 지원할 수 있었습니다. 저는 강의 노트와 유인물을 그 형식으로 많이 보관했기에 곧 reStructuredText 리더를 추가했습니다. PDF를 만들고 싶었기에 LaTeX 라이터도 추가했습니다. 이어서 reStructuredText 노트를 Markdown으로 변환할 수 있도록 Markdown 라이터를 추가했습니다. 그러고 나서 프로젝트는 눈덩이처럼 커졌습니다.

따라서 처음에는 미루기의 산물에 지나지 않았던 프로젝트가 Haskell로 작성하는 즐거움과 제 학술 작업에 대한 유용성의 증가로 길러졌습니다.

첫 릴리스 (2006–8)

2006년 8월 3일, 저는 소스 코드를 제 웹사이트에서 공개하기로 했습니다. 이때 pandoc은 HTML, LaTeX, RST, Markdown을 입력 및 출력 형식으로, RTF를 출력 형식으로 지원했고 LaTeX를 통한 PDF도 지원했습니다.

두 친구에게 이메일을 보낸 것 외에는 프로젝트를 홍보하려는 시도를 하지 않았습니다. 소셜 미디어 이전이었고(저는 어차피 한 번도 사용하지 않았습니다), GitHub 이전이었으며, Haskell 패키지 저장소인 Hackage 이전이었습니다. 하지만 분명 몇몇 사람이 제 웹사이트에서 이를 우연히 발견해 사용하기 시작했습니다. 10월에는 Debian 개발자 인증을 받으려 하면서 pandoc을 Debian linux용으로 패키징하고 싶어 하던 터키 개발자 Recai Oktaş가 연락해 왔습니다. 그래서 저는 그와 함께 이를 진행했습니다. 이는 제게 훌륭한 학습 경험이었고 프로젝트의 가시성을 크게 높였습니다.

2007년 동안 저는 주로 제 필요에 따라 pandoc을 계속 개선했습니다. 버전 0.3에는 DocBook 라이터와 오늘날 표준이 된 Markdown 각주 문법이 추가되었습니다. 버전 0.4에는 Markdown 표, 정의 목록, 위첨자/아래첨자, 취소선, 확장된 순서 목록 지원과 groff 매뉴얼 페이지 및 ConTeXt용 라이터가 추가되었습니다. 이는 2007년에 시작된 Hackage Haskell 패키지 저장소에 올라간 첫 릴리스였습니다. Hackage 아카이브와 의존성을 자동으로 해결하고 내려받는 새 cabal-install 도구는 외부 패키지에 의존할 가능성을 열었습니다.

Pandoc 1 (2008–17)

Pandoc 1.0은 2008년 9월에 릴리스되었습니다. MediaWiki, GNU Texinfo(Peter Wang 기여), OpenDocument(Andrea Rossato 기여), ODT용 새 라이터와 자동 구문 강조 기능을 갖춘 구분 코드 블록(현재는 “펜스드”라고 부름)이 포함되었습니다. ODT 지원에는 zip 아카이브 생성 기능이 필요했지만 당시 Haskell에는 이를 위한 패키지가 없었기에, 훌륭한 binary 패키지를 바이너리 구문 분석 및 직렬화에 사용하여 하나를 만들었습니다(zip-archive). 구문 강조 지원에는 구문 강조 라이브러리가 필요했는데 Haskell에는 이 역시 없었습니다. 이를 위해 Kate 텍스트 편집기가 사용하는 XML 구문 정의를 구문 분석해 Haskell 코드 하이라이터로 바꾸는 highlighting-kate를 작성했습니다. 이 덕분에 pandoc은 처음부터 많은 구문을 지원할 수 있었습니다. 이 버전에는 Andrea Rossato의 citeproc-hs 라이브러리와 CSL 스타일을 사용한 인용 및 참고문헌 자동 생성 지원도 포함되었습니다.

이 기간 내내 저는 현재는 사라진 markdown-discuss 메일링 리스트에서 다른 Markdown 구현자들과 논의에 참여했습니다. GitHub가 펜스드 코드 블록을 대중화하기 훨씬 전부터 pandoc이 지원했던 구분 코드 블록 문법은 PHP Markdown Extra의 관리자인 Michel Fortin과 협업하여 마련했습니다. pandoc의 Markdown에 확장을 추가할 때는 기존 사례를 살피는 데 주의를 기울였으며, 예를 들어 PHP Markdown Extra의 정의 목록 문법을 복사했습니다. 이 기간에는 Markdown 문법에 많은 모호성이 있다는 사실도 알게 되었습니다. 이는 나중에 commonmark 프로젝트에서 개선하려 한 상황입니다.

pandoc의 다음 큰 변화는 2010년 1월에 릴리스된 버전 1.4에서 찾아왔습니다. 하드코딩된 헤더를 대체하는 유연한 템플릿 시스템을 도입하여 pandoc 출력을 훨씬 더 사용자화할 수 있게 했습니다.

2010년에 우리는 Google Code에서 GitHub로 이전했고, 이는 프로젝트의 가시성을 더욱 크게 높였습니다. 2010년과 2011년의 후속 릴리스에는 EPUB 출력, Org-mode 출력(Puneeth Chaganti 기여), Textile 입력(Paul Rivier 기여) 지원이 추가되었습니다. Pandoc은 제 texmath 라이브러리를 통해 TeX 수식을 MathML로 변환하는 기능도 얻었습니다(DocBook 또는 HTML용).

2012년에 공개된 Pandoc 1.9는 마침내 Word docx 출력을 만들 수 있게 했습니다. 수식을 올바르게 처리하기 위해 Word의 OMML 형식 지원을 texmath에 추가했습니다. 이 릴리스에는 AsciiDoc 라이터, Beamer 및 DZSlides 지원도 추가되었고, 1.9.3에서는 DocBook 리더를 얻었습니다(오랫동안 기여자로 활동하게 된 Mauro Bieg의 기여 포함).

2013년에는 pandoc을 훨씬 더 유연하고 사용자화 가능하게 한 여러 기능에 집중했습니다. 첫 번째는 당시 확산 중이던 수많은 Markdown 변형을 지원할 수 있는 세밀한 Markdown “확장” 시스템이었습니다. 두 번째는 임의의 구조화된 필드로 템플릿 변수를 채우는 YAML 메타데이터 블록을 Markdown에 포함하는 기능이었습니다. 세 번째는 사용자가 임시 출력 형식을 지원할 수 있게 하는 Lua 사용자 정의 라이터를 만드는 기능이었습니다. 네 번째는 JSON 필터의 도입이었습니다. 사용자가 만든 프로그램이 pandoc AST의 JSON 직렬화를 변환하여 구문 분석 단계와 렌더링 단계 사이에서 문서를 사용자화할 수 있게 합니다. 인용 처리는 pandoc 핵심부에서 외부 필터인 pandoc-citeproc로 옮겨졌습니다.

이 시대에는 reveal.js, EPUB v3, DokuWiki, FictionBook2 출력, OPML 입력 및 출력, Haddock 및 MediaWiki 입력이 추가되었습니다. 주목할 만한 기여자로는 David Lazar(Haddock)와 Sergey Astanin(FictionBook2)이 있습니다.

2014년에는 이후 프로젝트에 많은 기여를 하게 될 세 명의 새 기여자가 등장했습니다. Albert Krewinkel은 Org-mode 입력 지원을 추가했고, Jesse Rosenthal은 변경 내용 추적 인식 기능까지 갖춘 Word docx 리더를 추가했으며, Matthew Pickering은 당시 Oxford 학생으로서 제가 Google Summer of Code 학생으로 “지도”했는데 EPUB와 Txt2Tags를 입력 형식으로 지원하게 했습니다. EPUB 입력을 지원하려면 MathML 수식을 변환할 수 있어야 했기에 Pickering은 texmath도 작업했습니다. 우리는 서로 매우 다른 시간대에 있었고, 매일 아침 일어나면 Pickering이 밤사이 해 둔 모든 작업을 발견했던 기억이 납니다. (Pickering은 이후 ghc 컴파일러의 핵심 관리자가 되었습니다.) 이 모든 기여는 Clare Macrae의 DokuWiki 라이터와 함께 pandoc 1.13에 릴리스되었습니다.

2012년부터 저는 Jeff Atwood가 시작하고 GitHub, Reddit, Stack Overflow 대표들이 참여한 Markdown 문법의 모호하지 않은 명세를 만들고자 하는 작업 그룹에 참여했습니다. 이 그룹은 2012년에 집중적인 논의를 했지만 2013년에 흐지부지되었습니다. 저는 여전히 이 프로젝트를 믿었고 우리가 한 작업이 헛되지 않기를 바랐습니다. 그래서 학년이 시작되기 전인 2014년 8월에 Markdown 명세를 작성하고 JavaScript와 C로 파서도 작성했습니다. 초안 명세를 John Gruber에게 보내 의견을 요청했지만 답을 받지 못했고, 몇 주 뒤에 명세를 게시했습니다. 이 시점에서 Gruber는 강하게 반대하며 프로젝트를 “Standard Markdown”이라 부르지 말라고 요구했고, 우리는 이름을 “commonmark”로 바꾸었습니다. 몇 가지 예외를 제외하면 대부분의 Markdown 처리기가 핵심 규칙에 commonmark 명세를 구현한다는 점에서 이 프로젝트는 성공했습니다. (Commonmark는 확장을 다루지 않습니다.) 아이러니하게도 commonmark 명세의 작성자인 저는 pandoc에서 여전히 commonmark 이전의 Markdown 파서를 사용합니다!

Pandoc 1.14(2015)는 commonmark 및 여러 확장 지원을 추가했습니다. 처음에는 C 라이브러리 libcmark의 바인딩을 통해서였고, 나중에는 2020년에 제가 만든 Haskell 패키지 commonmark, commonmark-extensions, and commonmark-pandoc을 통해서였습니다. 궁극적으로는 pandoc의 기존 Markdown 파서를 commonmark 핵심으로 대체할 생각이지만, 아직 구현되지 않은 몇 가지 핵심 확장이 있습니다. 따라서 pandoc 사용자는 여전히 문서를 markdown(pandoc 확장을 포함한 Markdown)으로 구문 분석할지, gfm, commonmark, commonmark_x(여러 확장을 포함한 commonmark)로 구문 분석할지 선택해야 합니다.

이듬해에는 이미지와 링크 속성, SoftBreak 요소(명령줄 설정에 따라 pandoc이 원본의 줄바꿈을 보존하거나 줄을 감쌀 수 있게 함), LineBlock 요소가 추가되는 등 pandoc AST에 중요한 변화가 있었습니다. MarLinn은 ODT 리더를, Chris Forster는 TEI 라이터를, Ivo Clarysse는 DocBook 5 지원을 추가했습니다.

Pandoc 2 (2017–23)

2017년에 릴리스된 Pandoc 2.0은 Jesse Rosenthal과 협업해 마련한 큰 아키텍처 변화를 가져왔습니다. 과거 pandoc의 리더(파서)와 라이터(렌더러)는 대부분 “순수”했습니다. 즉, 입출력 작업을 포함한 어떠한 부수 효과도 갖지 못하게 하는 Haskell 타입을 지녔습니다. 하지만 일부 형식은 충실한 변환을 위해 입출력을 수행할 수 있어야 했습니다. 예를 들어 reStructuredText에는 파일 포함 문법이 있으므로 파서가 파일을 읽어야 합니다. 다른 형식에서는 이미지에 명시적 크기가 필요하므로 렌더러가 이미지 파일을 읽고, 어쩌면 HTTP를 통해 내려받아 크기를 결정해야 합니다. 우리는 pandoc 리더와 라이터가 PandocMonad 타입클래스의 어느 인스턴스에서든 실행될 수 있는 시스템을 설계했습니다. 그리고 제어된 테스트 및 입출력을 금지하려는 상황에 사용할 수 있는 순수 인스턴스와 입출력 작업을 허용하는 인스턴스를 모두 제공했습니다. 이 시스템은 docx나 EPUB 같은 형식에서 리소스로 포함된 이미지를 처리하는 방법도 제공했습니다.

다른 큰 변화는 Lua 필터의 도입이었습니다. 내장 Lua 인터프리터에서 실행되고 pandoc AST를 직접 다루는 필터로, pandoc 자체 외에는 소프트웨어가 필요 없으며 JSON 필터보다 훨씬 뛰어난 성능을 제공합니다. 이는 Haskell-Lua 브리지 라이브러리인 hslua를 기반으로 Albert Krewinkel이 기울인 막대한 노력 덕분에 가능했습니다.

또한 pandoc 2.0은 pandoc Markdown의 원시 속성 문법과 GitHub 풍미 Markdown, Emacs Muse(Alexander Krotov), TikiWiki, Vimwiki(Yuchen Pei), Creole(Sascha Wilde), groff ms, JATS 지원을 도입했습니다. 기존 highlighting-kate는 더 나은 성능과 더 정확한 KDE 구문 정의 해석을 제공하는 새 skylighting으로 대체되었습니다. 곧 Jesse Rosenthal이 만든 PowerPoint 라이터가 뒤따랐고, FictionBook2(Krotov)와 man(Yan Pashkovsky와 저)의 입력 형식 지원도 추가되었습니다.

2018년에 프로젝트는 Handshake로부터 후한 $100,000 기부를 받았습니다. 우리는 이후 5년 동안 이를 가장 활발한 관리자들에게 소액의 보조금을 지급하는 데 사용했습니다.

2019년에는 ipynb(Jupyter 노트북) 지원이 추가되어 pandoc을 데이터 과학 작업 흐름에서 사용할 수 있게 되었고, Jira 위키 마크업이 출력 형식으로 지원되었습니다. pandoc 2.8에서는 기본값 파일을 사용하여 기본 옵션 모음을 지정할 수 있게 되었습니다.

사용자들은 pandoc의 표 모델이 행 및 열 병합조차 지원하지 않을 정도로 지나치게 제한적이라고 오랫동안 불평했습니다. 표 형식에 필요한 것이 무엇인지 폭넓게 논의한 뒤, Christian Despres가 표를 위한 새 타입을 설계하고 모든 리더와 라이터가 이를 사용하도록 수정했습니다. 이는 큰 작업이었습니다.

이 시점에 pandoc은 Andrea Rossato의 citeproc-hs를 사용하는 pandoc-citeproc 필터를 통해 여러 해 동안 인용 해석을 지원했습니다. 그러나 이는 느리고 다소 버그가 있었으며 Rossato는 오래전에 이 분야에서 사라졌습니다. 그래서 저는 CSL 명세와 테스트 사례만 사용하여 처음부터 Haskell citeproc 라이브러리를 작성했습니다. Pandoc 2.11은 이 라이브러리에 의존했고, 더 빠르고 CSL에 더 충실하며 외부 필터가 필요 없는 훨씬 나은 인용 지원을 제공했습니다. 인용이 올바르게 정렬되도록 하려면 Unicode 정렬 알고리즘을 순수 Haskell로 구현하는 또 다른 라이브러리(unicode-collation)를 작성해야 했습니다.

이 시대에 Pandoc은 참고문헌 데이터베이스 형식 간 변환을 지원하게 되었습니다. BibTeX, BibLaTeX, CSL JSON, EndNote XML, RIS가 그것입니다. 또한 CSV와 TSV를 pandoc 표 형식으로 변환하고, Markua로 변환하며, RTF에서 변환하는 기능도 지원했습니다. pandoc 2.15에서는 pandoc의 파서와 렌더러에 입출력 부수 효과가 없음을 보장하는 --sandbox 옵션이 추가되었습니다. 이는 pandoc 2.0에서 추가한 PandocMonad 추상화 덕분에 가능했습니다. pandoc 2.16.2에서는 2013년에 추가된 사용자 정의 Lua 라이터를 보완하도록 Lua로 사용자 정의 리더를 작성할 수 있게 되었습니다. pandoc 2.19.1에서는 API를 내보내는 웹 서버로 pandoc을 실행할 수 있게 되었습니다.

Pandoc 3 (2023–현재)

2023년이 되자 pandoc은 매우 크고 단일체적인 프로젝트가 되었습니다. 일부 사용자는 완전한 웹 서버와 Lua 인터프리터를 포함하지 않는 더 가벼운 프로그램을 원했습니다. 그래서 pandoc 3.0 릴리스에서 pandoc을 네 부분으로 나누었습니다. pandoc은 Haskell 라이브러리로 남았고, pandoc-lua-engine은 Lua 통합을 담당했으며, pandoc-server는 HTTP를 통해 라이브러리를 API로 노출했습니다. 이제 pandoc-cli 패키지에 들어간 명령줄 프로그램은 선택적으로 서버나 Lua 지원 없이 컴파일될 수 있었습니다. 또한 AST에 기본 Figure 요소와 여러 장으로 된 HTML 책 및 문서용 “청크 HTML” 라이터를 도입했습니다.

점진적 컴파일 기능을 갖춘 현대적인 LaTeX 경쟁자인 Typst의 첫 버전은 2023년에 릴리스되었습니다. 저는 다른 이들이 Typst를 쉽게 시도할 수 있도록 편리한 진입과 이탈 경로를 제공해 프로젝트를 돕고 싶었습니다. pandoc용 Typst 리더를 만들려면 상당히 완전한 기능을 갖춘 프로그래밍 언어의 인터프리터를 구현해야 한다는 사실이 드러났습니다. 그 결과가 Hackage의 typst 패키지입니다. Typst 지원은 pandoc 3.1.3에 추가되었습니다.

2018년에 저는 Markdown의 여섯 가지 기능이 명세 작성과 구현 모두에서 가장 큰 어려움을 만들었다고 생각한 이유와 향후 Markdown과 유사한 경량 마크업 문법에서 그 결함을 고칠 방법을 설명한 “Beyond Markdown” 에세이를 발표했습니다. 2022년에는 그러한 문법인 djot의 문법 설명을 Lua, JavaScript 및 나중에는 Haskell 코드와 함께 발표했습니다. 2024년에 공개된 Pandoc 3.1.12는 djot을 입력 및 출력 형식으로 모두 추가했습니다.

2024년과 2025년의 후속 릴리스에는 서식 있는 터미널 출력을 위한 ANSI 라이터와 mdoc 및 POD 형식 리더(모두 Evan Silberman 기여), pandoc AST의 XML 표현을 위한 리더와 라이터(massifrg), vimdoc 라이터(reptee), PowerPoint 리더(Anton Antich), Excel 스프레드시트 리더(Anton Antich), BBCode 라이터(reptee), 그리고 제 asciidoc 패키지가 지원하는 AsciiDoc 리더가 추가되었습니다.

2026년 2월에 릴리스된 Pandoc 3.9에는 pandoc을 WASM으로 컴파일하는 지원이 포함되어, 모든 기능을 갖춘 pandoc 버전이 브라우저에서 실행될 수 있게 되었습니다. 핵심 작업의 대부분은 TerrorJack이 수행했습니다. GUI 인터페이스 “pandoc for the people”은 Claude Opus의 도움으로 설계되었습니다.

저는 여전히 거의 매일 pandoc을 작업합니다. 이 작업의 대부분은 이 글에서 집중해 다룬 새로운 기능이나 아키텍처 변화와는 관련이 없습니다. 대체로 작은 버그 수정, 미세한 개선, 이슈와 풀 리퀘스트 검토, 인프라 복구(지속적 통합, 릴리스 빌드, 코드 서명, 웹사이트), 문서 개선, 관리자 및 사용자와의 토론으로 이루어집니다.

통계

Pandoc은 현재 51개의 입력 형식과 76개의 출력 형식을 지원하므로, 확장 조정으로 가능한 변형을 제외하고 3876개의 고유한 변환을 지원합니다.

네 개의 핵심 패키지(pandoc, pandoc-lua-engine, pandoc-server, pandoc-cli)는 테스트를 제외하고 85,684줄의 Haskell 코드로 이루어져 있습니다. 주로 pandoc을 위해 존재하는 의존성(texmath, typst, djot, commonmark, asciidoc, citeproc, pandoc/Lua 인터페이스 패키지)을 포함하면 이 수는 대략 두 배가 됩니다.

GitHub에서는 7346개의 이슈가 해결되었습니다.

수년에 걸쳐 600명 이상이 pandoc에 기여했습니다. 소스 줄 변경 수로 측정한 상위 20명의 기여자는 다음과 같습니다.

다음은 가장 오랜 기간에 걸쳐 기여한 20명의 기여자입니다.

회고: Haskell의 선택

처음에 언급했듯, 저는 pandoc 같은 프로젝트에 가장 적합한 언어라고 판단해서 Haskell을 선택한 것은 아닙니다. 하지만 그 선택은 옳았을까요?

오늘날 가장 분명한 대안인 Rust에 대해 잘 알지 못하기 때문에 자신 있게 답하기는 어렵습니다. 하지만 Pascal, C, Ruby, JavaScript/TypeScript를 포함한 여러 언어로 중요한 프로젝트를 만들고 유지해 왔습니다. 이 언어들 중 하나로 작성했다면 여가 시간에 이런 프로젝트를 관리할 수 없었을 것이라 생각합니다.

Haskell에는 pandoc 개발에 매우 도움이 된 여러 기능이 있습니다.

• _대수적 데이터 타입_은 구조화된 문서를 아주 깔끔하고 사용하기 편한 방식으로 표현하게 해 줍니다.

• 사물을 올바른 방식으로 결합하지 않으면 컴파일러 오류를 내는 _강한 타입 시스템_은, 무언가를 망가뜨리지 않는다는 확신을 갖고 프로그램을 크게 바꿀 수 있게 해 줍니다. 컴파일러는 변경할 모든 부분을 보여 주며, 코드가 컴파일되면 대개 작업이 끝난 것입니다. 강한 타입 시스템이 없는 언어, 이를테면 Python과 JavaScript로 작업할 때는 이런 안전장치가 없어 특히 작성한 지 오래된 코드를 유지보수할 때 큰 변경을 하기가 늘 두렵습니다.

• Haskell은 순수한 언어입니다. 타입에서 명시적으로 허용하지 않는 한 아무것도 부수 효과를 낼 수 없습니다. 순수 함수가 있다면 파일을 만들거나 삭제하지 않고, 웹 요청을 하지 않으며, 미사일을 발사하거나 전역 변수를 바꾸지도 않는다는 것을 알 수 있습니다. 이는 버그를 예방하는 데 대단히 유용합니다. pandoc에서는 샌드박스 모드로 실행할 때 리더와 라이터가 파일 시스템을 건드리지 않는다는 아주 강력한 보장을 제공하는 데에도 이를 사용합니다.

• Haskell을 선택한 것은 높은 품질과 적은 수의 기여자로도 이어졌습니다. 이는 자원이 많지 않은 프로젝트에 좋은 조합입니다.

제가 본 바에 따르면 Rust는 더 빠르고 메모리 효율적이며 더 간결한 코드를 생성하면서 Haskell의 좋은 특징을 많이 지닌 듯합니다. 그러나 Haskell은 여전히 더 “인체공학적”이고, 추상화를 표현하기에 더 적합하며, 개발자가 _사고_하도록 돕는 언어라는 이상에 더 가깝게 느껴집니다.

Pandoc의 향방

저는 pandoc을 계속 개선할 계획입니다. 개선할 방법은 많습니다. 하지만 때로는 이런 도구가 얼마나 오래 계속 필요할지 궁금합니다.

현재의 LLM이 한 인간 언어에서 다른 언어로 번역을 매우 잘하는 것처럼, 한 문서 형식에서 다른 문서 형식으로 번역하는 일도 꽤 잘할 수 있습니다. 제가 해 본 작은 테스트에서 ChatGPT는 Markdown을 HTML로 번역하는 데 좋은 성과를 냈고, reStructuredText로 변환하는 데는 괜찮았지만 눈에 띄게 더 낮은 성과를 냈습니다. 막 발명한 경량 마크업 언어로 문서를 작성해도, LLM은 의도를 꽤 잘 추측하여 HTML이나 다른 형식으로 번역할 수 있으리라 생각합니다.

그렇다면 미래에는 사람들이 더 이상 pandoc 같은 도구를 필요로 하지 않을지도 모릅니다. 그러나 현재로서는 텍스트 변환에 pandoc을 사용하는 것이 LLM에 의존하는 것보다 몇 가지 큰 장점이 있다고 생각합니다. 첫째는 생태적 장점입니다. 같은 변환에 훨씬 적은 에너지만 필요합니다. 둘째, pandoc의 출력은 결정론적입니다. pandoc으로 텍스트를 변환하면 언제나 같은 결과를 얻고 그 결과가 무엇일지 예측할 수 있습니다. 셋째, 적어도 지금으로서는 pandoc의 변환이 더 신뢰할 만합니다. 하지만 이는 앞으로 몇 년 안에 바뀔 수 있습니다. 실제로 LLM이 pandoc이나 그와 비슷하게 작동하는 무엇보다 더 신뢰할 수 있는 변환을 만들어 내는 때가 올 수도 있습니다.

commonmark 명세를 설계할 때 우리의 목표는 복잡한 문자열을 사람이 자연스럽게 해석하는 방식으로 해석하는 것이었습니다. 이는 달성하기가 상당히 어렵습니다. 복잡한 강조 규칙을 보십시오. 중첩 강조에 관한 규칙을 아무리 복잡하게 만들어도 알고리즘이 사람이 문자열에서 자연스럽게 발견할 의미와 어긋나는 사례를 만들어 낼 수 있다는 사실을 알게 되었습니다. 이런 경우 저는 흔히 “우리 프로그램에 AI가 생기기 전까지는 이런 경계 사례가 계속 있을 것이다. 어느 시점에는 이를 받아들이고 더 복잡한 규칙을 만들려는 시도를 멈춰야 한다”고 말하곤 했습니다. 흥미롭게도 이제는 텍스트의 의미와 의도를 이해하거나 적어도 이해를 모사할 수 있는 도구가 있으며, 설계 가능한 어떤 경량 마크업 문법보다도 작성자가 의도한 서식을 더 잘 인식할 잠재력이 있습니다.

미래가 무엇을 가져오든, 전 세계 사람들이 셀 수 없이 많은 단순 노동의 시간을 절약하도록 해 준 이 프로젝트의 20년 역사에 저는 자부심을 느낍니다. 20번째 생일을 축하해, pandoc!

---

이 날을 기념하여 pandoc 머그컵과 스티커를 몇 가지 만들었습니다.

• 변환 다이어그램이 있는 커피 머그컵
• pandoc 만화가 있는 스티커
• pandoc 로고가 있는 스티커
• pandoc 로고가 있는 머그컵