현재 일상적인 작업의 대부분은 새 기능보다 작은 버그 수정, 미세 개선, 이슈·풀 리퀘스트 검토, CI·릴리스 빌드·코드 서명·웹사이트 같은 인프라 복구, 문서 개선, 관리자·사용자와의 논의임

20년간의 규모와 기여

현재 Pandoc은 51개 입력 형식과 76개 출력 형식을 지원해 확장 조합을 제외하고도 3,876가지 변환이 가능함

핵심 패키지 pandoc, pandoc-lua-engine, pandoc-server, pandoc-cli는 테스트를 제외하고 Haskell 코드 85,684줄로 구성됨

texmath, typst, djot, commonmark, asciidoc, citeproc, Pandoc/Lua 인터페이스처럼 주로 Pandoc을 위해 존재하는 의존성까지 포함하면 약 두 배가 됨

GitHub에서 해결된 이슈는 7,346개이며, 20년 동안 600명 넘는 사람이 기여함

변경한 소스 코드 줄 수 기준 주요 기여자는 다음과 같음

John MacFarlane 372,317줄, Albert Krewinkel 77,136줄, Jesse Rosenthal 39,664줄

Christian Despres 15,314줄, Alexander Krotov 8,657줄, Matthew Pickering 6,919줄

MarLinn, Evan Silberman, Nikolay Yakimov, Mauro Bieg, Emily Bourke, Yan Pas, reptee, Anton Antich, massifrg 등도 주요 기여자에 포함됨

장기간 활동한 기여자에는 John MacFarlane, Albert Krewinkel, Andrew Dunning, Nikolay Yakimov, Thomas Hodgson, Mauro Bieg, Kolen Cheung, Pablo Rodríguez, Pascal Wagler 등이 포함됨

Haskell 선택에 대한 회고

Rust가 현재의 가장 명백한 대안일 수 있지만 직접적인 경험이 충분하지 않아 확정적으로 비교하기는 어려움

Pascal, C, Ruby, JavaScript·TypeScript로도 큰 프로젝트를 개발·유지해 봤지만, 이 언어들로 Pandoc 같은 프로젝트를 여가 시간에 관리하기는 어려웠을 것이라고 판단함

Haskell의 대수적 데이터 타입은 구조화된 문서를 깔끔하고 다루기 편하게 표현할 수 있게 함

강한 타입 시스템은 잘못된 타입 결합을 컴파일 오류로 잡아 대규모 변경에 필요한 수정 지점을 보여줌

컴파일이 성공하면 변경 작업이 끝난 경우가 많음

Python이나 JavaScript처럼 강한 타입 보호가 없는 언어에서는 오래된 코드의 큰 변경이 더 불안함

순수 함수는 타입에서 허용하지 않은 부작용을 일으킬 수 없음

파일 생성·삭제, 웹 요청, 전역 변수 변경 같은 동작이 없음을 알 수 있어 버그 방지에 유용함

Pandoc의 샌드박스 모드에서는 reader와 writer가 파일 시스템에 접근하지 않는다는 강한 보장을 제공함

Haskell 선택은 자원이 많지 않은 프로젝트에 적합한 적은 수의 고품질 기여자로 이어짐

Rust는 Haskell의 장점을 상당수 제공하면서 더 빠르고 메모리 효율적이며 작은 코드를 만들 수 있어 보임

Haskell은 여전히 추상화를 표현하기 편하고 개발자의 사고를 돕는 언어라는 점에서 더 인간공학적으로 평가됨

LLM 시대에도 Pandoc이 필요한가

현재 LLM은 인간 언어뿐 아니라 문서 형식도 어느 정도 변환할 수 있음

소규모 테스트에서 ChatGPT는 Markdown을 HTML로 잘 변환함

reStructuredText 변환도 준수했지만 HTML 변환보다 눈에 띄게 나빴음

새로 만든 경량 마크업 언어도 의도를 추측해 HTML 등으로 변환할 가능성이 있음

현재 Pandoc은 LLM 기반 변환보다 세 가지 큰 이점을 가짐

같은 변환에 훨씬 적은 에너지를 소비함

출력이 결정적이어서 같은 입력은 항상 같은 결과를 내고 결과를 예측할 수 있음

적어도 현재는 변환 신뢰성이 더 높음

향후에는 LLM이 Pandoc 같은 규칙 기반 도구보다 더 신뢰성 높은 변환을 만들 수도 있음

CommonMark는 복잡한 문자열을 사람이 자연스럽게 읽는 방식으로 해석하려 했지만, 이를 규칙으로 구현하기는 어려웠음

강조와 굵은 강조 규칙처럼 중첩 문법을 아무리 복잡하게 만들어도 사람의 해석과 알고리듬 결과가 달라지는 사례를 만들 수 있었음

AI가 없으면 이런 경계 사례를 받아들이고 규칙을 더 복잡하게 만드는 일을 멈춰야 한다고 판단했음

이제 의미와 의도를 이해하거나 적어도 이해를 모사하는 도구가 등장했으며, 저자가 의도한 서식을 어떤 경량 마크업 문법보다 더 잘 인식할 가능성이 생김

Pandoc은 20년 동안 전 세계 사용자가 반복적인 문서 변환 작업에 들이는 시간을 절약해 왔으며, 개발과 개선은 계속될 예정임

기술 스택 선택이 자발적으로 모이는 사람들과 자기 강화되는 문화에 미치는 영향은 흔히 과소평가됨
기술적으로 .NET은 과도한 설계와 쓸 만한 UI 프레임워크 부족에 시달리던 Java보다 간결하고 신선했지만, Java 진영에서는 소프트웨어 공학의 복잡한 주제를 깊이 논의할 동료를 만나기 쉬웠던 반면 .NET 진영은 2주짜리 CRUD 부트캠프 출신이 더 많았음
양쪽 모두 뛰어난 엔지니어와 부족한 개발자가 있었으나 그 분포에는 작지 않은 차이가 있었음

N개 파서와 M개 렌더러로 N×M 변환을 지원하는 Pandoc의 설계는 기본 원칙부터 올바르게 직접 구축한 소프트웨어가 어떻게 확장되며 유용성을 키우는지 잘 보여줌
LLM이 결정론적 신뢰성에 극도로 가까워지더라도, 대규모 일괄 작업에서는 Pandoc 같은 도구가 생태적·실용적 측면과 효율성에서 몇 자릿수 이상 뛰어나므로 앞으로 더 필요해질 것임

가장 어려운 부분은 좋은 중간 표현을 찾는 일인데, Pandoc은 그걸 해냈음

철학 교수인 John MacFarlane이 전 세계 수백만 명이 사용하는 도구들을 만들었다는 사실이 놀라움 Pandoc은 늘 가장 먼저 찾는 도구임

몇 년 전 Pandoc을 Bash 스크립트로 감싸 개인 웹사이트용 정적 사이트 생성기를 만들었고, HTML 템플릿과 Markdown 콘텐츠를 파일별로 병렬 처리해 다소 투박하지만 충분히 빠르게 사용 중임
트리 변환과 파싱은 함수형 프로그래밍에 완벽한 용도로 보임. 1990년대 Utrecht에서 Erik Meijer에게 함수형 프로그래밍 기반 컴파일러 수업을 들으며 파서 생성기, Modula-3 부분집합, 모나드 등을 다뤘음
이후 업무에서 직접 쓸 일은 거의 없었지만 Kotlin과 JavaScript 등이 함수형 개념을 받아들일 때 쉽게 적응했고, 이제 map이나 forEach는 여러 언어에서 for나 while을 대신하는 자연스러운 선택이 됨

유효한 HTML 생성 자체는 평범한 Rust로도 어렵지 않지만 파싱은 훨씬 까다로움
Markdown 파싱 라이브러리를 쓰면 구현 작업이 늘어나지만 Pandoc도 조정과 설정, 실행 환경별 의존성 설치가 필요함. 새 프로젝트라면 유연성을 위해 Rust 라이브러리를 택하겠지만 Pandoc 방식도 충분히 타당함

Pandoc을 하루에도 여러 번 사용해 Outlook 이메일과 코딩 도구 사이에서 콘텐츠를 변환함: 스크립트 cat email-to-xyz.md | md2clip clip2md > email-from-xyz.md

최소 정적 사이트 생성기로 find를 통해 모든 *.md 파일을 찾고, 출력 디렉터리를 만든 뒤 pandoc --quiet --template template.html "$file" -o "$out"으로 HTML을 생성해 사용함

요즘은 주로 Markdown→Typst 변환에 Pandoc을 쓰며, 이 작업을 아주 잘 처리함

Pandoc은 기여자 경험도 훌륭함
지난 몇 년간 Typst와 docx 관련 버그를 여러 건 보고했는데 언제나 친절하고 유용한 답변을 받았고, Haskell을 거의 몰라도 몇몇 PR이 병합됐음

가장 자주 쓰는 Pandoc 조각은 HTML에서 스타일, 래퍼 div, span, 인라인 속성 등을 제거하고 의미 구조만 남기는 함수임 pandoc -f html-native_divs-native_spans -t markdown-raw_html-raw_attribute | pandoc -f markdown -t html

Typst 같은 새 리더·라이터가 계속 통합되는 점도 좋음
전처리한 블로그 글을 Pandoc의 --pdf-engine=typst와 --template="templates/blog.typ" 옵션으로 넘겨 PDF를 생성하고 있음