
  <rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
    <channel>
      <title>Chaos and Order</title>
      <link>https://www.youngju.dev/blog</link>
      <description>천천히 올바르게. AI Researcher &amp; DevOps Engineer Youngju&#39;s blog. GPU/CUDA, LLM, MLOps, Kubernetes AI workloads, and data engineering — plus mindset essays on confidence, routines, health, and sport psychology.</description>
      <language>ko</language>
      <managingEditor>fjvbn2003@gmail.com (Youngju Kim)</managingEditor>
      <webMaster>fjvbn2003@gmail.com (Youngju Kim)</webMaster>
      <lastBuildDate>Fri, 31 Jul 2026 00:00:00 GMT</lastBuildDate>
      <atom:link href="https://www.youngju.dev/tags/mdx/feed.xml" rel="self" type="application/rss+xml"/>
      
  <item>
    <guid>https://www.youngju.dev/blog/2026-07-31-mdx-markdown-pipeline-performance</guid>
    <title>마크다운/MDX 파이프라인 성능 — satteri와 네이티브 코어가 실제로 바꾸는 것</title>
    <link>https://www.youngju.dev/blog/2026-07-31-mdx-markdown-pipeline-performance</link>
    <description>JavaScript 생태계를 위한 고성능 마크다운·MDX 처리기 satteri가 GeekNews에 오르면서, 문서 사이트 빌드 시간이 다시 화제가 됐습니다. 이 글은 수천 페이지 규모의 MDX 빌드에서 시간이 실제로 어디로 가는지를 파싱·변환·컴파일·번들·프리렌더 다섯 단계로 나누고, 추측 대신 측정하는 프로파일링 절차를 제시합니다. unified/remark/rehype의 플러그인 체인이 왜 비용의 큰 몫인지, satteri 같은 Rust 코어가 그것을 어떻게 바꾸고 무엇을 포기하는지, 그리고 공개된 속도 수치 중 무엇이 검증된 벤치마크이고 무엇이 아닌지를 구분해 적었습니다.</description>
    <pubDate>Fri, 31 Jul 2026 00:00:00 GMT</pubDate>
    <author>fjvbn2003@gmail.com (Youngju Kim)</author>
    <category>mdx</category><category>markdown</category><category>build-performance</category><category>unified</category><category>static-site</category>
  </item>

    </channel>
  </rss>
