Typst - LaTeX를 대체할 수 있는 가능성

• Typst는 Rust로 개발된 문서 조판 프로그램으로, 수학·표·그림 삽입 등 기술 자료 작성에 최적화된 LaTeX 대안으로 얘기됨
• LaTeX의 복잡한 문법·느린 컴파일·난해한 오류 메시지 문제를 해결하며, Markdown 유사 문법과 통합된 함수 기반 언어를 제공
• 빠른 증분 컴파일과 명확한 오류 표시, 간결한 문법으로 대규모 문서도 실시간 미리보기가 가능하고, 프로그래밍 기능이 시스템에 자연스럽게 녹아 있음
• 단점으로는 전문 패키지 생태계 부족, 저널 템플릿 지원 미흡, 문서화 난이도와 일부 기능 부족이 지적되지만, 패키지가 빠르게 늘고 있으며 Pandoc을 통한 변환도 가능함
• Typst는 아직 초기 단계이지만 학술지 일부 채택, 800개 이상의 패키지, 활발한 커뮤니티 덕분에 LaTeX를 대체할 유력 후보로 부상 중임

---

Typst 소개 및 중요성

• Typst는 문서 조판 프로그램으로, 수식, 표, 그림 등 기술 문서에 적합한 구조를 갖추고 있음
• LaTeX에 비견되는 고품질 결과물을 더 간단한 마크업과 빠른 컴파일로 제공함
• Typst는 Rust로 개발된 오픈소스 소프트웨어이며 Apache-2.0 라이선스를 따름
• 대용량 문서 처리 속도, 문법 단순화, 손쉬운 커스터마이즈가 큰 강점

LaTeX의 한계와 대체 필요성

• LaTeX는 TeX 기반으로 수학·컴퓨터 과학 분야에서 학술 논문 표준 도구로 자리 잡은 시스템임
• 그러나 설치 용량이 크고, 컴파일 속도 저하, 난해한 오류 메시지, 매크로 언어 기반의 어려운 커스터마이징 문제가 지속적으로 지적되어 왔음
• 수십 년 동안 대체 논의는 있었지만, 방대한 패키지 생태계와 기존 사용자 의존성으로 인해 현실적 대안이 없었음

Typst의 등장과 개발 배경

• 2019년 독일 개발자 Laurenz Mädje와 Martin Haug가 개인 프로젝트로 시작했으며, 이후 석사 논문과 베타 릴리스를 거쳐 발전함
• 2023년 v0.1.0 공개 이후 현재 v0.13.1까지 성장했으며, GitHub에서 365명 이상의 기여자가 참여 중임
• 일부 학술지에서 Typst 원고를 제출 형식으로 받아들이기 시작하면서 실사용 가능성이 확대되고 있음

Typst의 기능과 장점

• Typst는 Rust 소스 및 컴파일된 바이너리로 제공되며, Linux, macOS, Windows를 지원함
• 단일 실행 파일(typst)로 동작하며, LaTeX처럼 여러 엔진을 구분할 필요 없음
  • typst fonts 명령으로 사용 가능한 폰트 확인 및 추가 가능
  • typst compile로 PDF/SVG/PNG 출력, typst watch 모드로 실시간 미리보기 지원하여 소스 변경 시 PDF 자동 갱신을 지원
  • 빠른 인크리멘탈 컴파일로 대용량 문서도 실시간 미리보기가 매우 빠름
• 문법은 Markdown 유사 스타일과 수학 전용 문법을 결합, LaTeX보다 간결하고 직관적임
• 명확한 오류 메시지, 증분 컴파일, Rust와 유사한 함수형 언어 지원으로 사용자 경험이 개선됨
• 수학 공식 표현은 LaTeX와 거의 동일한 품질을 제공하며, 유니코드 기호 입력을 직접 활용 가능

LaTeX 대비 Typst의 개선점

• LaTeX보다 짧고 읽기 쉬운 소스 문법 제공
• Typst는 LaTeX와 동일한 줄나눔 알고리듬과 유사한 수식 조판 방법을 사용해 품질을 유지
• 복잡한 매크로 대신 함수 호출 기반 커스터마이징으로 안정성과 단순성을 확보
• Typst는 Rust 스타일의 내장 프로그래밍 언어 내장
  • 함수 대부분은 순수 함수로, 예측 가능한 결과 및 디버그 용이성 제공
  • 프로그래밍 언어와 문서 조판이 완전히 통합되어 간결한 코드 작성 가능
  • 문서 커스터마이즈, 예를 들어 폰트 변경, 섹션 스타일 등도 함수 호출 방식
  • LaTeX의 Lua 확장보다 일관적이고 단순한 프로그래밍 구조를 지원함
• LaTeX에서 문제가 되는 부동 요소 처리, 표 분할 등이 개선된 레이아웃 모델로 해결 가능

마크업 예시 및 구조

• 헤딩: = 기호, 자동 번호 목록: +, 불릿 목록: -로 간단히 작성
• Bold, Italic 등의 텍스트 변환도 직관적으로 입력
• 일부 기능은 함수 호출로 처리: 예) #underline[Good] gin
• 텍스트, 코드, 수학 3가지 입력 모드 존재
• 수식 모드는 $로 감싸 입력, Unicode 기호 및 Greek 문자 바로 입력 가능

Typst의 단점과 한계

• LaTeX 대비 페이지 레이아웃 정교함 부족 (고아/미망 방지 등)
• 아직 전문 패키지 수가 적음, 그러나 현재 800개 이상으로 빠르게 확장 중
• 학술지 템플릿 지원이 부족해 Pandoc 변환이 필요함
• 공식 문서가 미흡하고 빠른 업데이트 속도를 따라가지 못하는 문제가 있음
• PDF 삽입 불가, parshape 미지원 등 일부 고급 기능 부재
• 프로젝트 초기 단계 특성상 호환성 깨짐(breaking changes) 위험 존재

결론과 전망

• 저자는 실제로 물리학 논문 작성에 Typst를 사용, LaTeX 변환에는 Pandoc을 활용함
• Neovim + Tree-sitter와 결합해 효율적인 작성 환경을 구현했으며, Typst의 속도와 에러 표시 경험에 만족함
• 빠르고 직관적인 수식 입력, 에디터/비쥬얼 도구 지원, 빠른 컴파일 피드백 등 실질적인 작업 효율성 제공
• Typst는 LaTeX 대체 가능성을 가진 강력한 후보로, 당장도 충분히 실용적이며 앞으로 더욱 확장될 것으로 평가됨

---

LWN의 주요 댓글들

• 호환성과 장기 안정성
  • TeX/LaTeX가 성공할 수 있었던 이유 중 하나는 미래 버전과의 호환성 유지였음 (spacefrogg)
  • 하지만 실제 경험에서는 오래된 문서가 새로운 환경에서 깨지거나 패키지 변경으로 재작성해야 하는 문제가 많았다는 불만도 존재함 (wtarreau, warrax)
  • 일부 사용자는 수십 년 된 논문이나 학위 논문이 여전히 문제없이 빌드되었다는 경험을 공유하며, 사용한 패키지의 안정성 차이가 핵심이라고 지적 (dskoll, anton)
• 출판사 템플릿과 패키지 문제
  • 학술지 출판 시 제공되는 LaTeX 템플릿과 구식 패키지 사용이 강제되어 실제 호환성 이점이 약화된다는 지적이 있음 (NYKevin, aragilar)
  • 결국 중요한 것은 문서 형식을 오래 유지하는 것이 아니라, 본문 텍스트를 새 템플릿에 쉽게 이식할 수 있는지라는 현실적인 의견 (anton)
• Typst의 언어 설계와 장점
  • Typst는 LaTeX와 달리 코드 문법과 조판 문법이 명확히 분리되어 있어 매크로 부작용이 줄고, 현대적인 언어 기능을 갖추고 있음 (spacefrogg)
  • 간단한 문서를 빠르게 작성할 수 있고, 에러 메시지 가독성과 증분 컴파일이 큰 장점 (spacefrogg, notriddle)
  • 다만 Typst도 튜링 완전성을 가진 만큼, 장기적으로 호환성 문제가 반복될 가능성을 우려하는 의견도 있음 (epa, smoogen, taladar)
• 생태계와 커뮤니티
  • Typst는 패키지 개발이 활발하며, 요청 시 기능이 빠르게 추가된 사례가 있음 (leephillips, adnl)
  • 공식 문서가 부족하다는 지적과 달리, 커뮤니티 포럼이 친절하고 활발하다는 긍정적 경험도 공유됨 (al4711)
  • 다른 대안 프로젝트로 SILE이나 과거의 Lout이 언급되었으나, 네트워크 효과 부족으로 확산에 실패했던 역사도 짚어짐 (rogerwhittaker, ceplm, anton)
• LaTeX의 지속적 발전과 비교
  • LaTeX도 최근에는 Tagged PDF(접근성 강화) 같은 현대적 기능을 도입하고 있으며, 여전히 연구자와 개발자가 적극적으로 개선 중임 (jschrod)
  • Overleaf, LyX 등 다양한 툴이 LaTeX 사용성을 개선하고 있으며, 협업이나 초보자 학습에 유용하다는 의견도 있음 (smitty_one_each, paulj, callegar)
  • Typst가 LaTeX보다 단순하고 현대적이라는 장점이 있지만, 수십 년 축적된 생태계와 전문 기능은 아직 따라가기 어렵다는 회의적 시각도 존재함 (norbusan, callegar)
• 기타 논의
  • Typst의 PDF 포함 기능은 최근 추가되었고, parshape 유사 기능도 패키지로 등장했음 (Delio, yashi)
  • Typst가 decades 후에는 결국 LaTeX와 같은 호환성·복잡성 문제를 반복할 것이라는 비판도 있음 (norbusan)
  • 일부는 Typst의 이탤릭 보정 부족 같은 세부 문제를 지적하며, LaTeX의 세밀한 전통적 기능과 비교했을 때 미흡함을 강조함 (callegar)

[shakespeares]

생태계가 구성될 때까지 좀 기다려야겠네요..

[secret3056]

Typora는 여러 면에서 LaTeX를 압도한다고 봅니다.
다만 아직 자잘한 버그가 남아 있고, 새 버전이 나오기까지 시간이 너무 오래 걸린다는 아쉬움이 있죠.
커뮤니티를 자체적으로 운영하고, 에디터+클라우드 유료화를 시도했다가 잘 안 되면서 개발 속도가 예전만 못한 것 같아요.

[GN⁺]

Hacker News 의견

• Typst가 점점 더 주목받는 모습을 보게 되어 기쁨, 내 조직 Zerodha에서는 2년 전 실제 업무를 Typst로 옮겼음. 매일 150만 개가 넘는 PDF를 생성해서 이메일로 발송하는 작업이었음. 이전에는 LaTeX(처음엔 pdflatex, 이후엔 lualatex) 기반 파이프라인을 사용했는데, 대용량 문서에서 알 수 없는 메모리 에러와 Docker 이미지가 지나치게 커서 ephemeral 워커의 부팅 시간이 느린 게 항상 문제였음. Typst로 전환하면서 단일 정적 바이너리로 매우 경량화된 이미지를 쓸 수 있었고, 부팅 속도가 확연히 빨라졌음. 성능 향상도 엄청났음. 전체 컴파일 시간이 LaTeX 대비 3~4배 빨랐고, 2000페이지가 넘는 대용량 문서의 경우 Typst는 1분이면 끝나는 반면 lualatex는 18분이나 걸렸음. 개발자 경험도 좋아졌고, 에러 메시지도 훨씬 친절해서 만족스러움. 전체 아키텍처와 Typst 마이그레이션 경험에 대해 자세히 포스팅했으니, 궁금하다면 여기 참고 바람

  • 나는 LaTeX 파이프라인으로 텍스트, 인보이스, 폼 등 다양한 문서를 데이터베이스의 스니펫 기반으로 만들고 있음. 세팅이 상당히 복잡했지만 결과는 매우 만족스러움. 더 쉬운 마크업 언어를 쓰고 싶긴 하지만, 혹시라도 시간만 낭비하다가 한계에 부딪히는 게 아닐까 걱정함. 내가 꼭 필요로 하는 조건은: 여러 칼럼에서 의미 있는 칼럼/페이지 브레이크를 지정 가능할 것(새 칼럼/페이지에 최소 행 수 명시 등), 여러 언어(영어/독일어, 향후 프랑스어/이탈리아어/스페인어)에서 신뢰성 높은 자동 하이픈 적용, 칼럼 내 이미지의 자동 배치, 복잡한 표와 폼의 자동 페이지 브레이크, 배경 이미지, 그리고 미니 페이지처럼 다뤄지는 각기 다른 영역 등임. Typst가 이 모든 걸 할 수 있는지 궁금함

  • 우리가 만들어내는 문서 샘플이나 예시를 공유할 수 있으면 정말 흥미로울 것 같음

  • 내가 일했던 회사들은 자주 통계 자료, 소규모 보고서, 기타 각종 비즈니스 문서 PDF를 정기적으로 발송함. 대부분 MJML, 직접 만든 HTML, Puppeteer 등으로 PDF를 생성함. 이러한 경우에도 Typst가 잘 맞을지 궁금함

  • 너희의 사용 사례에서 왜 처음에 LaTeX를 썼는지 궁금함. LaTeX를 대체한다는 것보다 LaTeX를 시작점으로 쓴 것이 오히려 더 놀라움

• Typst와 LaTeX를 비교하면 정말 천지차이임. 나는 박사 논문을 Typst로 쓰고 있는데, 사실상 모험에 가까운 선택임. 아직 큰 사용자층이 없고 완전히 안정적이지도 않으니까. 하지만 한번 써보니까 어쩔 수가 없었음. 대학에서 요구하는 LaTeX 템플릿을 픽셀 단위로 맞추는 작업이 남아있지만 Typst가 분명히 더 적합하다고 확신했음. LaTeX를 10년 넘게 썼어도 TeX를 제대로 안다고 할 수 없었음. 그런데 Typst는 며칠 만에 정말 효율적으로 사용할 수 있게 되었음. 필요한 패키지가 없으면 내가 직접 빠르게 만들 수 있고, 그마저도 상당 부분 이미 훌륭한 패키지로 지원됨. LaTeX라면 꿈도 못 꿨던 작업들이 Typst에서는 쉽게 가능함. 생산성이 크게 떨어지던 요소 중 하나가 TeX에서는 패키지 충돌, 호환성, 버전 이슈였는데, Typst에서는 그럴 일이 전혀 없음. 진짜 프로그래밍 언어와 모듈 체계를 제공하기 때문임. 컴파일 속도도 빠르고, 전체적인 사용 경험이 정말 우수함. 다만 100% 완벽하지는 않음. 몇몇 아쉬운 디자인과, 예를 들어 PDF를 이미지처럼 삽입하는 기능같이 아직 개발 중인 부분도 있음. 조판 품질도 TeX 대비 한 95% 정도에 수렴하는 느낌임(TeX는 항상 완벽). 글자 간격(Kerning)을 가끔 따로 손대야 할 때도 있음. 그렇지만 앞으로 더 개선될 거라 기대함

  • 대학의 LaTeX 템플릿을 픽셀 단위로 맞추는 게 오히려 행운일 수 있음. 대부분 사람들은 대학의 MS Word 템플릿을 그대로 LaTeX로 복제해서 맞춰야 했음

  • Typst도 계속 발전하고 있을 거라고 생각함. 다만 가끔 호환성 깨지는 큰 변경이 있었음. 고치기는 어렵지 않았지만 디버깅이 직관적이진 않았음. 많은 사람들이 Typst를 성공적으로 쓰길 바라는 듯함. TeX와 LaTeX는 방대하고 복잡한데, 뭔가 깔끔한 LaTeX “배포판” 같은 게 필요하다는 생각이 듦. 컨테이너로 원자화된 단위로 잘 만들 수 있으면 좋겠음. 템플릿을 받았는데 빌드하려고 하면 늘 뭔가가 빠져있기도 하고. 이런 분야에서 혁신이 계속되는 게 보기 좋음

  • LaTeX를 10년 넘게 썼지만, Typst는 며칠 만에 능숙하게 쓸 수 있었다는 점이 흥미로움. 그 이유가 뭘까? 혹시 CS(컴퓨터 공학) 배경 때문일까?

  • 픽셀 단위 복제라는 말이 정말 문자 그대로인지 아니면 과장인지 궁금함. LaTeX에는 거의 픽셀 단위로 복제가 불가능한 패키지도 많은데, 특히 microtype 같은 건 과학 논문에 자주 쓰임

  • Typst로 논문을 쓴 경험을 다룬 블로그 포스트도 참고해보면 좋을 것 같음

• Typst와 LaTeX를 비교해서 사용하면서 느꼈던 점을 정리해봄

  1. LaTeX는 컴파일할 때마다 5개씩 엉뚱한 파일이 생기는데, Typst는 그런 게 없음
  2. 컴파일 속도가 즉각적임
  3. 진단 메시지가 정말 쉬움(Rust 컴파일러처럼 구체적으로 알려줌)
  4. 리스트 항목을 -, [item] 등 다양하게 쓸 수 있는데, 대괄호 방식을 쓰면 vim에서 %로 쌍 맞추기 쉬워서 긴 리스트도 쉽게 네비게이션 가능함
  5. LaTeX는 \document{} 첫머리에 매크로 선언을 다 몰아놔야 하는데, Typst에서는 필요한 곳 근처에 바로 둘 수 있음
  6. semantic line break 방식을 쓰면 버전 관리나 diff가 더 쉬워짐
  7. 페이지 레이아웃/여백/간격/푸터 등도 훨씬 쉽게 바꿀 수 있음
  • 8. 프로그래밍 환경도 훌륭함. 자체 인터프리터 언어가 내장되어 있어서 json("some_file.json") 같은 함수로 결과 표를 바로 불러와 쓸 수 있음. 논문 쓸 때 벤치마크 스크립트로 만든 JSON 데이터를 Typst에서 바로 불러오고 PDF로 컴파일해서 활용함

  • 매크로 선언을 위에만 할 필요 없고, 어디서든 선언할 수 있음. LaTeX도 패키지는 preamble에서만 불러오지만, 매크로는 어디서나 선언 가능함. semantic line break도 LaTeX에서 별 문제 없음. 컴파일 속도와 진단 메시지에 대한 의견엔 동의함. 이 부분이 LaTeX의 가장 큰 단점임

  • 실제로 5번 내용처럼 매크로를 어디서나 선언할 수 있음. 관습적으로 preamble에 두는 것일 뿐임

  • Typst로 실제 기사 같은 걸 써봤는지 궁금함. 나는 아주 제한적으로만 성공했고, 아직 많이 쓰는 사람이 없어서 스스로 문제를 해결해야 하는 상황임

  • Typst는 그냥 매크로가 아니라 진짜 프로그래밍 언어라서 함수, 타입, 모듈(네임스페이스도 있음) 등 다양한 기능이 있음. 그 덕에 TeX로 작업할 때보다 고통이 80%는 줄어듦(특히 단순한 대학생 실험 보고서 외에는). 완벽하진 않지만, 정말 큰 차이나는 장점임

• LaTeX 자체는 그 자체로는 LaTeX보다 훨씬 간단하고 직접적임. 오히려 너무 많은 제어권이 주어져서 당황할 정도임. 예를 들어 이게 유효한 plain TeX 문서임: $$\aleph_0$$ \bye. begin/end 쓰지 않아도 무방함. extended plain 같은 매크로 모음으로 쓰면 기능이 확장됨. 나도 내 논문 전체를 extended plain으로 썼지만, 도서관 제출 때 LaTeX 스타일 파일로 재작성하라고 해서 결국 LaTeX로 고쳤었음

  • LaTeX만 써봤다면 plain TeX를 접하면 놀랄 만함. LaTeX 매크로라 생각하는 것들이 사실 대부분 TeX가 직접 제공하는 기능임

• Typst가 진짜 LaTeX 경쟁자가 되려면 학술 논문 및 컨퍼런스에서 Typst 템플릿이 공식적으로 채택되어야 함. 대학에서의 확산도 최종적으로는 출판사의 채택 여부에 달려 있음. 아직 연구자 커뮤니티에서 Typst에 대한 지원이 거의 없는 상황임. 모두 LaTeX 템플릿으로 논문/슬라이드/보고서를 이미 쓰고 있고, Typst 템플릿이 먼저 한 교수/랩에서 승인받고, 그게 대학 전체로 확산, 더 나아가 학회/저널까지 파급되어야 의미 있음. 이 과정은 매우 길고 지루하며, 아직 현재진행형임. 하지만 필수적인 단계임

  • 저널 제출 같은 더 전문적인 조판에 어떤 문제가 있는지는 잘 몰라서 그럴 수도 있지만, 사실 연구 논문에서 조판이 중요한지 잘 모르겠음. 실제로는 좀 더 간단하고 내용 중심의 포맷만 있으면 충분하다고 생각함. 논문이나 책 출판사 측에서 제출물을 자기네 스타일에 맞게 조판하면 될 일임. 연구자 입장에서는 단순하고 내용 중심의 포맷만 신경쓰면 되는 게 좋겠음. 실제로는 LaTeX나 Typst보다는 어떤 연구용 markdown 포맷이 표준이 되었으면 함

  • 연구자 입장에서는 LaTeX가 이미 문제를 잘 해결해주기 때문에 굳이 바꿀 이유가 크지 않음

• 나는 LaTeX로 여러 강의노트, 수학 석사 논문을 썼음. 남이 만든 템플릿으로 글만 쓴다면 LaTeX도 좋은 편임. 하지만 패키지를 직접 만들거나 내부 구조를 파악하려 하면 진짜 블랙매직처럼 느껴졌음. 각 패키지가 서로 충돌하지 않도록 굉장히 신경써야 했고, 특수한 우회 방법도 많아서 늘 복잡했음. Typst가 직접 레이아웃 및 디자인을 손쉽게 해주는 LaTeX 대체제가 된다면 정말 좋을 것 같음. Typst는 실험적으로만 써봤는데, 언어 자체는 마음에 들었음. 사실 글만 쓸 때는 문법은 그다지 중요한 문제가 아니라고 생각함. 참고로 실제 석사 논문 쓸 때 처음에는 reStructuredText로 작성해서 Pandoc으로 LaTeX와 PDF를 만들고, 전체 구성이 잡힌 뒤 LaTeX 부분을 손봐서 필요한 서식/그림을 다시 그려서 마무리했음. 개시점에서 긴 preamble 없이 바로 시작할 수 있다는 게 장점이었음. 여전히 문법이 아니라 초반 설계 단계에서 너무 신경쓰다 보면 본문을 제대로 못 쓰는 게 문제라고 생각함

  • Typst는 아직 많이 써본 것은 아니지만, 내가 느끼기에는 템플릿 작성 과정에서 LaTeX에 비해 훨씬 블랙매직적 요소가 적음. 이미 LaTeX보다 더 자유롭게 구조를 만들 수 있다는 느낌임

  • 문서 디자인/레이아웃에 더 직접적인 제어와 힘을 원한다면, LaTeX나 Typst가 아니라 ConTeXt를 추천함. 나는 그래픽 디자이너로서 ConTeXt를 너무 좋아해서 다른 도구로는 대체할 생각이 없음. 단 글만 쓰고 디자인은 신경쓰지 않을 때는 LaTeX나 Typst가 여전히 훌륭함

  • 나 역시 reStructuredText로 논문을 쓰고, Pandoc과 latexmk로 PDF를 만들며 matplotlib과 Python으로 생성한 PDF 그래프를 무손실로 삽입해본 경험이 있음. 혹시 reStructuredText로 못했던 일이 있었는지 궁금함. LaTeX 템플릿도 사용 가능하고, reStructuredText 자체가 Markdown 등 다른 마크다운 계열보다 강력해서, 오히려 계속 reStructuredText로 써도 무방하다고 여김

  • 너의 각주가 사실상 LaTeX가 썩 괜찮은 선택이 아니라는 걸 보여줌. 나도 최근에 Typst로 논문을 썼고, 이전까지는 LaTeX로 썼음. LaTeX에서는 Markdown으로 쓰고 나중에 LaTeX로 변환해서 썼는데, Typst에서는 그럴 필요가 없었음. 앞으로 Typst가 서비스 품질 하락 없이 계속 가면 그냥 계속 Typst 쓸 생각임

• 나는 요즘 Typst로 Pandoc + LaTeX를 대체해서 책을 쓰고 있음(깃허브 링크). Typst 문법은 Markdown처럼 쉽고, LaTeX보다 프로그래밍하기 훨씬 쉬움(다만 아직 거친 부분도 있음). LaTeX에서는 항상 패키지에 의존해야 했고, 각각의 이상한 상호작용도 피해야 해서 일이 많았음. Typst는 필요한 부분을 직접 구현하기도 쉬움. 매우 빠르고, 파일 시스템에 쓸데없이 많은 파일을 남기지도 않음. PDF 중심의 기술 문서라면 정말 추천함

• 대체 조판 시스템으로는 SILE도 있음. XML 기반, TeX 스타일 모두 지원되고, lua로 스크립팅 가능함. (La)TeX, Typst와 달리 공식 문서에 준하는 사양도 있음. 수식은 MathML을 바로 쓸 수도 있음. 다만 Typst나 SILE 모두 직접 사용해본 건 아니고 문서만 봄. HTML + MathML도 괜찮고, XML 소스 + XSLT로 템플릿을 써서 OpenStax 교과서처럼 집필하는 사례도 있음(CNXML 기반). troff(plus eqn), Texinfo, org-mode, LaTeX 임베딩, Markdown + HTML/MathML 등 다양한 조합도 있음

  • HTML은 직접 쓰기에 나쁘지 않지만, MathML은 쓸 때 정말 태그가 엄청 많아서 손으로 작성하기는 너무 힘듦. 예시 보면 간단한 식도 온갖 태그가 붙는다는 걸 알 수 있음

• LaTeX를 오래 쓴 입장에서는, 이미 LaTeX에서 수많은 특수 사례를 다 경험하고 해결책도 다 알아놨기 때문에 새로운 시스템으로 옮기는 게 부담스러움. Typst가 아무리 좋아도 또다시 그 과정을 반복해야 할까 두렵고, Typst의 커뮤니티가 크지 않은데 내 문제를 겪고 해결법을 공유한 사람이 이미 있을까도 걱정됨. 공식 예시만 보면 아주 좋아 보이지만, LaTeX의 강점은 디테일한 커스터마이즈(들여쓰기, 마커 심볼, 간격 등)를 섬세하게 다 제어할 수 있다는 건데 Typst도 이 정도 수준 제어가 가능한지 궁금함

  • 같은 고민임. 확실히 매우 좋은 레이아웃 언어고, 프로덕션 퀄리티도 훨씬 높음. 하지만 새로운 특이 케이스와 한계에 또 부딪힐 수밖에 없음. Typst의 사용자 기반도 아직 충분히 크지 않음. 추가로, Claude Code 같은 AI가 Typst를 잘 이해하는지 작년에 테스트해보니 그렇지 않았음

  • Typst는 아직도 이미지를 본문 내에서 자연스럽게 떠 있게(텍스트가 둘러싸는 방식 등) 배치하는 기능을 제공하지 않음. 이미지를 페이지 상단/하단에는 둘 수 있지만, 본문 중간 '플로팅 이미지'는 네이티브로 지원되지 않음

  • (들여쓰기, 간격, 심볼 등) 리스트 커스터마이징 제어 기능은 공식 문서에서 확인할 수 있음: Typst의 리스트 모델 문서

  • 만약 다른 기관(도서관, 학회 등)에서 당신의 논문이나 논문을 LaTeX로만 받는다고 하면 어떻게 할지 고민도 필요함

• Typst는 정말 놀라움. 요즘은 수학과 학생들이 논문을 안 쓰고 Typst 패키지 작성으로 딴짓한다는 농담까지 나옴. 10년만 더 보면 어디까지 발전할지 흥미로움. 장점: 컴파일이 즉각적이라 .typ 파일 저장만 해도 바로 PDF가 생성됨. Markdown 대체로도 자주 쓰는데, 특별한 준비 없이도 바로 예쁜 PDF를 뽑아냄. 단점: 에러 메시지가 간결하다 못해 지나치게 압축적일 때가 있어 디버깅이 어렵고, 문법 에러 하나만 있어도 PDF가 아예 생성되지 않아서 LaTeX의 일부 디버깅 트릭을 쓰기가 어려움. 외부 패키지 쓸 때도 문제를 겪긴 하지만 LaTeX 오래 써본 사람에겐 놀랄 일은 아님

  • Typst 패키지에서 생기는 문제들은 LaTeX 패키지 문제와는 성격이 다름. Typst에서는 함수 설명이 불충분하거나 일반적인 버그 같은 "프로그래밍다운" 문제지만, LaTeX에서는 패키지를 불러오기만 해도 문서 전역에 예측 불가한 영향이 생겨서 원인 파악이 아예 불가능할 때가 많음. 두 패키지가 그냥 '호환 불가'일 때도 많고, 이런 일은 제대로 된 프로그래밍 언어에서는 있어서는 안 될 일임