Hacker News 의견들
  • 솔직히 인상적이긴 한데, 내게 Markdown의 핵심은 극단적으로 단순함에 있음
    GUI 없이도 편집할 수 있고, 터미널의 VIM에서 작성해도 결과가 대충 어떻게 나올지 감이 잡히며, raw .md 파일 자체도 그냥 읽기 좋음
    그런데 여기에 기능을 계속 얹기 시작하면 낯선 명령을 자꾸 찾아보게 되고, 결국 기억도 안 나고 렌더링 없이는 모양도 확신이 안 서서 WYSIWYG 편집기를 바라게 됨
    QWERTY 키보드에 키릴 문자, 데바나가리, 중국어, 아랍어 키까지 다 넣자는 식의 발상과 비슷해 보이고, 그러면 결국 다시 hunt and peck으로 돌아가는 느낌임

    • 내게 Markdown의 큰 장점 중 하나는 반쯤 WYSIWYG라는 데 있음
      기본 문법이 원래 사람들이 텍스트에서 서식을 흉내 내던 방식을 재활용해서, 입력 자체가 대체로 그대로 읽기 좋음
      Markdown 작성법을 정확히 몰라도 대개 읽는 데는 문제 없고, 표는 표처럼 보이고 문단은 그냥 문단으로 보임
      가끔 문법을 다시 찾아보긴 하지만 그건 괜찮음. 능동 어휘보다 수동 어휘가 큰 건 자연스러움
      그래서 나는 입력 원문의 가독성으로 판단하는 편인데, 여기서 보여준 것들 중 상당수는 그 기준에서 아주 큰 득실이 없어 보임
      다만 수식 포매팅 예시는 못 봤고, 내가 LaTeX를 쓰는 드문 경우도 대부분 Markdown으로 안 되는 수학식 때문이라 그 부분이 실제로 어떻게 보일지는 궁금함
    • 그 주장은 꽤 설득력 있음
      그래도 Quarkdown은 LaTeX를 직접 치는 것보다는 분명 상위 호환처럼 보이고, Word 같은 GUI 편집기보다 결과 예측 가능성과 LLM 보조 편집 호환성도 더 나아 보임
    • 이상한 새 명령을 외울 필요도 없고 매끈한 UI/UX까지 갖춘, 더 초능력 있는 Quarkdown을 만들면 됨
      이름은 Microsoft Word면 되겠음
    • 나도 작은 Markdown renderer를 만들고 있는데, 이름 붙이는 것조차 어렵고 완성돼도 사람들이 쓰게 만드는 건 더 어려움
      요즘은 평범한 "plain markdown" 편집기만으로는 눈에 띄기 힘들고, HN 첫 페이지까지 가려면 결국 일반 Markdown을 넘어서는 기능성과 완성도가 있어야 하는 듯함
      일종의 자연선택처럼 느껴짐
    • Obsidian.md는 기본적인 Markdown용 WYSIWYG 편집기로 정말 훌륭함
  • 이런 도구와 마크업 언어들을 한 번에 비교한 자료가 있으면 좋겠음
    MyST, Pandoc, Quarkdown, Quarto, Typst를 나란히 놓고 보면 좋겠음
    Quarto와 Pandoc은 Pandoc Markdown을 쓰고, https://www.zettlr.com/도 마찬가지임
    반면 Quarkdown과 Typst는 LaTeX나 HTML+Javascript 쪽에 가까운 프로그래머블 마크업 언어 느낌이라, 아직 누가 진짜 LaTeX 후계자가 될지는 안 정해진 듯함

    • 대부분 직접 써 봤고 앞으로도 계속 쓸 생각인데, 대충 이렇게 구분하면 됨
      Markdown은 .txt에 약간의 문법 설탕만 뿌린 수준이고 PDF나 HTML로 내보낼 수 있음
      Quarto는 코드 블록을 실행하고 싶은 Markdown이고
      Typst는 현대적으로 다시 만든 LaTeX라서 잡다한 건 90% 줄었지만 기능도 10%쯤 빠진 느낌임
      학계는 원래 최신 걸 싫어해서 Typst를 써도 탐탁지 않아할 가능성이 큼
      Pandoc은 결국 PDF, HTML 같은 각종 포맷으로 내보내는 도구임
      대체로 필요한 도구가 어느 쪽인지 금방 보이고, asciidoc 같은 것도 있지만 markdown/quarto/typst 조합으로 안 덮이는 영역이 뭐가 있나 생각해 보면 많지 않음
      굳이 남는 건 WYSIWYG 편집기 정도임
    • 비교 목록에 djot도 넣을 만함
      Markdown의 잘 설계되고 꽤 철저한 superset처럼 보임
      https://djot.net/
    • Typst를 정말 좋아하고 싶었음
      LaTeX를 더 안 써도 된다면 최고였겠지만, 실제 프로젝트에 써 보니 코너 케이스가 너무 많아서 결국 다시 LaTeX로 돌아갔음
      LaTeX에 있는 것 중 빠진 부분도 있고, Pandoc 변환성이 부족한 것도 컸음
      마지막 10%만 채워지길 정말 바람
    • 이런 비교를 말하는 거라면 이미 있음
      https://github.com/iamgio/quarkdown#comparison
    • Pandoc은 다른 도구들과 계층이 다름
      중간 JSON 포맷에 대해 임의의 필터를 걸 수 있어서 원하는 변환을 사실상 뭐든 구현 가능하고, 각종 포맷을 그 JSON으로 또는 그 반대로 바꿔 줌
      그래서 나는 Pandoc 기반 시스템을 선호하고, 기본 도구가 못 하는 일도 간단한 inline filter로 해결되는 경우가 많음
  • 물리학 소프트웨어 표준 모형에 따르면 Quarkdown은 Atom에서 편집하면 Quarkup이 되고, Neutron Mail을 Proton Mail로 바꿔야 함
    단, 왼손으로 타이핑하면서 Electron 앱을 만들고 anti-Neutrinos AI blogpost까지 써야만 작동함

  • 내 짧은 평으로는, 이건 사실상 LaTeX 스타일 매크로를 넣은 Markdown에 가까움
    다만 여기서는 그걸 함수라고 부르는데, 아마 부작용이 있는 함수가 적어도 하나는 있어서일 듯함. 새 함수를 정의하는 그 함수 말임
    "모든 것이 함수"라는 문법적 순수성은 마음에 들지만, 구조와 스타일링을 HTML/CSS 식으로 자연스럽게 섞어 놓은 건 약간 미묘함. 물론 그 경계 자체가 원래도 흐릿하긴 했음
    그래도 꽤 멋지고, Markdown을 크게 바꾸려는 시도에 회의적인 반응이 많은 건 이해함
    함수를 과하게 쓰면 원문 가독성이 떨어질 수 있다는 비판도 맞고, 때로는 튜링 불완전성이 장점이 되기도 함
    하지만 Markdown에 함수를 더하는 설계로만 보면, 이건 꽤 깔끔한 디자인 축에 든다고 봄

  • 내가 Quarkdown의 작성자이자 프로젝트 리드임
    처음엔 대학 연구 프로젝트로 시작했는데, 2년 뒤 이런 모습이 될 줄은 상상도 못 했음
    관심 가져줘서 고맙고, 댓글들에 최대한 답해 보겠음

    • v3에서 굵게 표시 문법을 "고칠" 생각이 있는지 궁금함
      나는 늘 **bold***italic* 대신 *bold*_italic_가 더 맞다고 생각해 왔음
      Markdown의 추가 별표 하나는 설계가 별로고, 특히 휴대폰이나 태블릿에서 Markdown 편집할 때 꽤 불편함
    • 텍스트 포맷에 함수를 넣는 발상은 꽤 낯설게 느껴짐
      GUI 문서에서도 매크로는 보통 피하는 편인데, Quarkdown은 원래 복잡하고 반복적인 문서를 위해 설계된 건지 궁금함
      질문 받아줘서 고마움
    • https://iamgio.eu/2025-12-10-accidentally-in-silicon-valley/를 읽어봤는데, 잘 풀린 것 같아 보여서 기쁨
  • 문서를 훑어보니 평가 모델이 이 작업에 맞는지 조금 걱정됨
    텍스트 레이아웃은 보통 한 부분을 조정하면 다른 부분 배치가 무너져서 다시 레이아웃 패스를 돌려야 하므로, 고정점까지 반복하는 구조가 필요함
    Typst는 이를 위해 context 개념을 두고 있는데 https://typst.app/docs/reference/context/, Quarkdown에서는 비슷한 걸 못 봤음. 내가 놓쳤을 수도 있음
    나는 책 작업에서 pandoc/md/LaTeX 조합에서 Typst로 갈아탔고, 꽤 만족하고 있음
    현대적인 언어로 프로그래밍하는 느낌이 좋고, 속도도 pandoc+LaTeX보다 훨씬 빠름
    https://functionalprogrammingstrategies.com/

  • AsciiDoc 쪽에서 보면, Quarkdown의 문법 설계는 깔끔해 보이고 특히 사용자 정의 함수가 좋음
    다만 이 부류에서 더 어려운 건 소스 언어 자체보다 출력 파이프라인이라고 느낌
    교차 참조, admonition, 조건부 콘텐츠, 함수 기반 재사용 같은 Markdown 확장은 설계상 충분히 다룰 수 있음
    진짜 벽은 그다음인데, 예를 들면 PDF/UA를 만족하는 tagged PDF, 환경이 달라도 흔들리지 않는 deterministic build, 다국어 문서 사이트의 hreflang과 cross-document linking, 500페이지짜리 책에서도 버티는 incremental rebuild 같은 것들임
    특히 EU에서는 2025년 6월 28일 European Accessibility Act가 발효된 뒤 PDF/UA 중요성이 더 커졌음
    네 가지 doctype, 특히 paged 쪽을 어떻게 가져갈 계획인지 궁금함

  • 비교표에는 MyST도 들어가야 함
    https://mystmd.org/
    이쪽이 앞으로 새 Markdown 표준이 될 수도 있어 보임

    • 또는 Typst도 넣을 만함
      Markdown 확장은 아니지만 목표와 사용 사례가 꽤 비슷함
    • MyST + Sphinx 조합은 아주 좋음
      다만 강한 LSP 지원은 아쉽고, 적어도 나는 helix에서 제대로 돌리는 데 실패했음
      내 블로그도 pydata-sphinx-theme와 myst로 만들었음
    • 나는 그쪽을 잘 모름
      원하면 PR로 표를 직접 업데이트해 줘도 됨
  • 내 앱에서는 약간 다른 접근을 택했음
    가독성과 대형 Mermaid 다이어그램을 다루기 쉬운 쪽에 집중했고, 최근에는 지도처럼 탐색하는 전체화면 모드도 추가했음
    https://mdview.io/s/97af684b

  • 나는 SSG를 쓸 때 입력은 최대한 깨끗한 Markdown으로 두고, 서식 세부사항은 CSS에 몰아넣는 편을 선호함
    예를 들어 .abstract 같은 걸 굳이 쓰지 않아도, CSS가 첫 문단을 abstract처럼 처리하게 만들면 됨
    반대로 이 프로젝트는 더 풍부한 자급자족형 문서를 만드는 방향으로 보임
    CSS는 없지만 미리 정의된 스타일링 옵션이 많고, 그래서 초기 HTML이 자꾸 떠오름
    HTML 1은 색도 없고 서식도 거의 없어서 Markdown과 비슷했고, HTML 3쯤 가면 이것저것 많이 들어가기 시작했으니 그 흐름과 닮아 보임