
  <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>Sat, 15 Aug 2026 00:00:00 GMT</lastBuildDate>
      <atom:link href="https://www.youngju.dev/tags/scoping/feed.xml" rel="self" type="application/rss+xml"/>
      
  <item>
    <guid>https://www.youngju.dev/blog/career/2026-08-15-career-skills-scoping-and-problem-framing.en</guid>
    <title>Framing the Problem — How to Avoid Perfectly Solving the Wrong One</title>
    <link>https://www.youngju.dev/blog/career/2026-08-15-career-skills-scoping-and-problem-framing.en</link>
    <description>A perfect solution to the wrong problem is usually worse than a rough solution to the right one, because a rough answer signals that it is not finished and a perfect one signals that it is. This piece covers the three questions that unwind a request back into a problem, how to write non-goals with reasons attached before writing the goals, a six-line problem statement, and the test that separates narrowing scope from quietly swapping the problem for an easier one. It also explains why framing sits on the most expensive side of verification. Part 6 of the What Stays Expensive series.</description>
    <pubDate>Sat, 15 Aug 2026 00:00:00 GMT</pubDate>
    <author>fjvbn2003@gmail.com (Youngju Kim)</author>
    <category>career</category><category>skills</category><category>problem-framing</category><category>requirements</category><category>scoping</category>
  </item>

  <item>
    <guid>https://www.youngju.dev/blog/career/2026-08-15-career-skills-scoping-and-problem-framing.ja</guid>
    <title>問題を定義する力 — 間違った問題を完璧に解く失敗を避ける</title>
    <link>https://www.youngju.dev/blog/career/2026-08-15-career-skills-scoping-and-problem-framing.ja</link>
    <description>間違った問題を完璧に解いた成果物は、正しい問題を粗く解いた成果物よりたいてい悪い。粗い答えは足りないという合図を出しますが、完璧な答えは終わったという合図を出すからです。この記事は、要求をそのまま受け取らずに問い返す三つの質問、作らないものを理由付きで先に書く非目標の書き方、六行の問題記述、そして範囲を縮めることと問題をすり替えることを見分ける基準を扱います。問題定義がなぜ検証費用の最も高い側に残るのかも説明します。高いまま残る技術シリーズの第6回です。</description>
    <pubDate>Sat, 15 Aug 2026 00:00:00 GMT</pubDate>
    <author>fjvbn2003@gmail.com (Youngju Kim)</author>
    <category>career</category><category>skills</category><category>problem-framing</category><category>requirements</category><category>scoping</category>
  </item>

  <item>
    <guid>https://www.youngju.dev/blog/career/2026-08-15-career-skills-scoping-and-problem-framing</guid>
    <title>문제를 정의하는 능력 — 잘못된 문제를 완벽히 푸는 실패를 피하는 법</title>
    <link>https://www.youngju.dev/blog/career/2026-08-15-career-skills-scoping-and-problem-framing</link>
    <description>잘못된 문제를 완벽히 푼 결과물은 맞는 문제를 어설프게 푼 결과물보다 대개 더 나쁩니다. 어설픈 답은 부족하다는 신호를 주지만 완벽한 답은 끝났다는 신호를 주기 때문입니다. 이 글은 요구사항을 액면 그대로 받지 않고 되묻는 세 개의 질문, 무엇을 만들지 않을지를 이유와 함께 먼저 적는 비목표 작성법, 여섯 줄짜리 문제 진술서, 그리고 범위를 줄이는 것과 문제를 바꿔치기하는 것을 구별하는 기준을 다룹니다. 문제 정의가 왜 검증 비용이 가장 비싼 쪽에 남는지도 함께 설명합니다. 비싸게 남는 기술 시리즈의 6편입니다.</description>
    <pubDate>Sat, 15 Aug 2026 00:00:00 GMT</pubDate>
    <author>fjvbn2003@gmail.com (Youngju Kim)</author>
    <category>career</category><category>skills</category><category>problem-framing</category><category>requirements</category><category>scoping</category>
  </item>

    </channel>
  </rss>
