
  <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 tech blog. GPU/CUDA, LLM, MLOps, Kubernetes AI workloads, distributed training, and data engineering.</description>
      <language>ko</language>
      <managingEditor>fjvbn2003@gmail.com (Youngju Kim)</managingEditor>
      <webMaster>fjvbn2003@gmail.com (Youngju Kim)</webMaster>
      <lastBuildDate>Thu, 16 Jul 2026 00:00:00 GMT</lastBuildDate>
      <atom:link href="https://www.youngju.dev/tags/research-methods/feed.xml" rel="self" type="application/rss+xml"/>
      
  <item>
    <guid>https://www.youngju.dev/blog/2026-07-16-dora-platform-engineering-evidence</guid>
    <title>플랫폼을 쓰는 팀이 처리량 8%, 변경 안정성 14%가 더 낮았다 — DORA 데이터를 인과로 읽으면 안 되는 이유</title>
    <link>https://www.youngju.dev/blog/2026-07-16-dora-platform-engineering-evidence</link>
    <description>2026년 현재 내부 개발자 플랫폼 도입률은 90%로 보고됩니다. 그런데 그 숫자를 낸 DORA 리포트 자신의 데이터에는 불편한 결과가 같이 들어 있습니다 — 2024년 리포트에서 플랫폼 사용자는 개인 생산성이 8%, 팀 성과가 10% 높았지만 처리량은 8%, 변경 안정성은 14% 낮았고, DORA는 이걸 &quot;놀라운 결과&quot;라 불렀습니다. 더 중요한 건 DORA가 직접 내놓은 세 가지 가설 중 하나가 역인과라는 점입니다 — 이미 불안정하고 번아웃된 조직이 그걸 고치려고 플랫폼을 만든다는 것. 2025년 리포트에서 DORA는 아예 &quot;효과&quot;라는 단어를 버리고 &quot;비교&quot;로 표현을 낮췄습니다. 이 글은 원문 PDF를 근거로 이 연구들이 실제로 무엇을 측정했는지(전부 리커트 척도 자기보고입니다), 표본을 어떻게 모았는지(스노볼 샘플링입니다), 그리고 같은 도메인의 벤더 리서치를 어떻게 읽어야 하는지 정리합니다. 결론은 &quot;플랫폼을 하지 마라&quot;가 아니라, 이 숫자들로 할 수 있는 말과 할 수 없는 말을 구분하자는 것입니다.</description>
    <pubDate>Thu, 16 Jul 2026 00:00:00 GMT</pubDate>
    <author>fjvbn2003@gmail.com (Youngju Kim)</author>
    <category>platform-engineering</category><category>dora</category><category>internal-developer-platform</category><category>devex</category><category>research-methods</category>
  </item>

    </channel>
  </rss>
