이미 Rust로 구현된 PDF 엔진이 있는데 왜 또 바이브 코딩으로 만들려는 걸까? 이 프로젝트가 기반으로 삼은 https://github.com/yfedoseev/pdf_oxide는 수년간 AI를 쓰기도, 쓰지 않기도 하며 수많은 문제를 고쳐 온 printpdf를 전혀 고려하지 않은 듯함. https://github.com/fschutt/printpdf는 MIT 라이선스이며 WASM으로도 빌드되고, https://fschutt.github.io/printpdf/에서 데모를 실행할 수 있음.
“rust pdf library”라고 한 번만 검색해도 나오는데, 다들 자기만의 어설픈 HTML → PDF 렌더러를 거듭 만들며 이미 해결된 예외 상황에 다시 부딪힘. 특히 조판에는 예외가 많음. 최근 Claude로 글꼴을 자동 추출하면서 1732년 책의 스캔본을 OCR로 인식하고 정리했는데, 다단 구성·각주·사이드바부터 줄바꿈에 따라 히브리어 RTL 텍스트가 사라지는 현상, 1비트 이미지 압축까지 수많은 문제를 수정해야 했음.
나도 AI를 많이 쓰니 AI 자체를 반대하는 건 아님. 불만은 기존 프로젝트에 쌓인 수년의 작업을 무시하고, 포크하는 대신 같은 작업을 토큰으로 처음부터 반복한다는 데 있음. 이미 존재하는지 조사하지도 않은 듯한 프로젝트가 수없이 생겨남. 새 접근법을 빠르게 탐색하는 데 도움이 될 때도 있지만, 대부분은 이미 해결된 예외 상황을 놓치게 됨.
수년간의 작업을 무시하는 건 사람일까, 그 사람이 쓰는 AI일까? 사람은 PDF 엔진 개발의 역사를 읽고 소화하지 못했다는 핑계라도 있는데, AI는 무슨 핑계가 있을까?
Bento PDF도 소개하고 싶음. https://www.bentopdf.com/은 브라우저에서 실행되고, 개인정보를 보호하며, 번거로운 절차 없이 쓸 수 있음. 원하면 로컬에서 직접 호스팅할 수도 있음.
Rust PDF 엔진은 이미 몇 달 전부터 존재했음. 바퀴를 다시 만들기보다는 기존의 훌륭한 프로젝트에 기여해야 함. 또 하나를 만드는 대신 PR을 보내는 편이 나음.
요즘 PDF 생성에는 주로 Typst를 사용함. 여러 입력을 typ 파일과 템플릿으로 변환하는 프런트엔드와 연결 도구를 직접 만들었고, Sphinx의 백엔드로도 사용 중임.
국제화·테마·템플릿은 어떻게 처리하나요? 전부 Typst 밖에서 정의하고, 예를 들어 Typst 컴파일러에 보조 파일을 추가하는 방식인가요?
최근 나도 비슷한 작업을 하고 있는데, Typst 파일이 템플릿이라 같은 입력이어도 템플릿에 따라 결과와 필요한 번역이 달라질 수 있어 작은 Typst 국제화 라이브러리를 만들었음. 각 Typst 파일에 필요한 번역 묶음을 반드시 함께 제공하도록 할 수도 있을 듯함.
이 PDF 엔진은 MuPDF 소스를 읽고 C에서 Rust로 옮긴 바이브 코딩 결과물인가요? 몇 군데에서 MuPDF를 참조한 듯한 흔적이 보임.
그렇다면 그 사실을 공개해야 하고, 라이선스도 Apache가 아니라 AGPLv3여야 함.