// 이 파일이 하는 일: "CPU 깊이 보기" 코스 — CPU가 명령어 한 줄을 처리하는 원리에서 출발해
// 코어·스레드·클럭·캐시, 발열과 스로틀링, 제품 이름 읽는 법, 작업 관리자 관찰 실습,
// 그리고 "개발자에게 CPU가 중요한 순간(빌드 시간)"까지 7개 섹션으로 안내하는 정적 학습 페이지.
// 학습 포인트: API 호출이 없는 '내용 고정' 페이지다. 스타일은 global.css의
// 가이드 전용 클래스(step-card, code-block, tip 등)를 재사용한다 — 색을 여기서 하드코딩하지 않는다.
// 텍스트 다이어그램은 JSX 중괄호/백틱 충돌을 피하려고 파일 상단의 백틱 문자열 상수로 정의한다.

import { Link } from 'react-router-dom';

// ── 텍스트 다이어그램 · 표 상수들 ──

const CODE_CYCLE = `명령어 사이클 — CPU는 이 세 박자를 1초에 수십억 번 반복해요

┌──────────┐    ┌──────────┐    ┌──────────┐
│ ① 가져오기 │ → │ ② 해석    │ → │ ③ 실행    │ ─┐
│  (Fetch)  │    │ (Decode) │    │ (Execute)│  │
└──────────┘    └──────────┘    └──────────┘  │
      ↑                                        │
      └────────── 다음 명령어로! ←──────────────┘

① 가져오기: 메모리(RAM)에서 다음 명령어를 읽어 온다
② 해석:    "아, 이건 두 숫자를 더하라는 뜻이구나" 알아듣는다
③ 실행:    실제로 더하고, 결과를 저장한다

우리가 쓰는 자바(Java)·자바스크립트 코드도 결국
이런 기계 명령어 수백만 개로 번역돼서 이 사이클을 탑니다.`;

const CODE_KITCHEN = `CPU = 주방, 이렇게 비유해 보세요

코어(Core)     = 요리사 수         (8코어 = 요리사 8명)
스레드(Thread)  = 요리사의 손 놀림   (한 명이 두 요리를 번갈아 = 2스레드)
클럭(Clock)    = 손 놀리는 속도     (4.5GHz = 1초에 45억 박자)
캐시(Cache)    = 도마 옆 재료 선반   (냉장고=RAM까지 안 가도 되게)

예) "8코어 16스레드 4.5GHz" =
    요리사 8명이 각자 두 요리를 번갈아 하며,
    1초에 45억 박자로 손을 놀리는 주방`;

const CODE_CACHE = `캐시 3층 구조 — 가까울수록 작고 빠르다

CPU 코어 ── L1 캐시   손 안의 재료      (수십 KB,  가장 빠름)
         ── L2 캐시   도마 옆 선반      (수 MB)
         ── L3 캐시   주방 공용 선반    (수십 MB, 코어들이 공유)
              │
             RAM      복도 끝 냉장고    (수십 GB, 캐시보다 훨씬 느림)
              │
             SSD      지하 대형 창고    (TB급, RAM보다 또 훨씬 느림)

핵심: CPU 입장에서 RAM은 '멀어요'. 자주 쓰는 재료를
가까운 선반(캐시)에 미리 올려 두는 게 속도의 비밀입니다.`;

const CODE_THROTTLE = `발열 → 스로틀링(Throttling) 시나리오

평상시   : 4.5GHz로 신나게 달림          (온도 50~70℃)
무거운 작업: 온도 상승... 90℃ 돌파!
스로틀링  : CPU가 스스로 클럭을 낮춤       (4.5 → 3.0GHz)
           "이대로 달리면 타 버리니까 감속할게"
쿨링 회복 : 온도가 내려가면 다시 제 속도로

→ "게임(또는 빌드)이 처음엔 빠른데 몇 분 지나면 느려져요"의
  단골 범인이 바로 이 스로틀링이에요. 고장이 아니라 자기 보호!`;

const CODE_NAMING = `인텔 vs 라이젠 — 이름만 봐도 급이 보인다

인텔:  Core i7-14700K
       │    │  │└─ 뒤 숫자+접미사: 세부 모델 (K=오버클럭 가능, F=내장그래픽 없음)
       │    │  └── 앞 두 자리 14 = 14세대 (클수록 최신)
       │    └───── i3 < i5 < i7 < i9  (등급, 클수록 상위)
       └────────── 브랜드

라이젠: Ryzen 7 7700X
        │    │  │└─ 접미사 (X=고성능, G=내장그래픽 강화)
        │    │  └── 첫 자리 7 = 7000번대 세대
        │    └───── 3 < 5 < 7 < 9  (등급, 인텔 i3~i9와 대응)
        └────────── 브랜드

함정 주의!
"i7이 i5보다 무조건 빠르다" ← 세대가 다르면 틀릴 수 있어요.
최신 세대 i5가 몇 년 전 i7을 이기는 일은 아주 흔합니다.
등급(체급)과 세대(연식)를 반드시 같이 보세요.`;

const CODE_TASKMGR = `작업 관리자로 내 CPU 관찰하기 (Windows)

1) Ctrl + Shift + Esc  →  작업 관리자 열기
2) [성능] 탭  →  왼쪽에서 [CPU] 선택

여기서 찾아보세요:
  · 이름          예) Intel Core i5-1240P  ← 섹션 5로 해독!
  · 코어 / 논리 프로세서   예) 12 / 16      ← 요리사 수 / 손 수
  · 기본 속도 vs 현재 속도  (GHz)          ← 지금 몇 박자로 일하나
  · L1/L2/L3 캐시 크기                    ← 선반 3층의 크기
  · 이용률(%) 그래프

3) 그래프 위에서 우클릭 → [그래프 변경] → [논리 프로세서]
   → 코어(스레드)별 그래프가 바둑판처럼 쫙!
   유튜브를 틀거나 npm run build를 돌리면서
   어떤 칸이 바빠지는지 지켜보세요.`;

const CODE_BUILD = `개발자의 하루와 CPU — 빌드 시간으로 체감하기

우리 스택에서 CPU를 갈아 넣는 순간들:
  · npm run build      React 프론트 번들링 (수십 초~수 분)
  · ./mvnw package     Spring Boot 컴파일+패키징
  · docker build       이미지 빌드 (레이어마다 컴파일·압축)
  · 테스트 전체 실행    케이스 수백 개 병렬 처리

간단 계산: 빌드 3분짜리를 하루 20번 돌리면?
  3분 × 20회 = 하루 60분이 '기다림'
  CPU 업그레이드로 빌드가 1분이 되면 → 하루 40분 회수!

그래서 회사가 개발 장비에 투자하는 건 사치가 아니라 계산이에요.
(참고: 우리 EC2 서울 서버도 vCPU 수에 따라 빌드·배포 속도가 달라집니다.)`;

// ── 이 페이지 안에서만 쓰는 작은 부품들 ──
// 학습 포인트: 같은 모양이 반복되면 컴포넌트로 뽑는다. props만 바꿔 재사용.
function Section({ n, title, sub, children }) {
  return (
    <section className="step-card" id={`sec-${n}`}>
      <div className="step-head">
        <span className="step-num">{n}</span>
        <div>
          <h3>{title}</h3>
          {sub && <span className="step-sub">{sub}</span>}
        </div>
      </div>
      <div className="step-body">{children}</div>
    </section>
  );
}

function Code({ children }) {
  return <pre className="code-block"><code>{children}</code></pre>;
}

const SECTIONS = [
  { n: 1, label: '연산의 원리' },
  { n: 2, label: '코어·스레드·클럭' },
  { n: 3, label: '캐시 L1~L3' },
  { n: 4, label: '발열과 스로틀링' },
  { n: 5, label: '이름 해독하기' },
  { n: 6, label: '작업 관리자 실습' },
  { n: 7, label: '개발자와 CPU' },
];

export default function CpuDeepPage() {
  return (
    <div>
      {/* 히어로: 이 코스가 어디서 출발해 어디까지 가는지 */}
      <div className="hero">
        <div className="eyebrow">Course · 컴퓨터 기초</div>
        <h1>CPU 깊이 보기<br />— 명령어 한 줄에서 빌드 시간까지</h1>
        <p>
          컴퓨터의 두뇌라 불리는 CPU가 실제로는 어떤 박자로 일하는지, 코어·스레드·캐시 같은
          스펙 용어가 무슨 뜻인지 주방 비유 하나로 꿰어 봅니다. 마지막엔{' '}
          <strong>내 PC의 작업 관리자</strong>로 오늘 배운 걸 전부 눈으로 확인해요 —
          스펙표를 읽을 줄 아는 개발자가 되는 게 이 코스의 목표입니다.
        </p>
        <div className="chip-row">
          <span className="chip">예상 소요 50분</span>
          <span className="chip">실습 2개 (내 PC로 바로)</span>
          <span className="chip">준비물: Windows PC 한 대</span>
        </div>
      </div>

      {/* 섹션 바로가기 */}
      <nav className="pill-nav">
        {SECTIONS.map((s) => (
          <a key={s.n} href={`#sec-${s.n}`}>
            <b>{s.n}</b>
            {s.label}
          </a>
        ))}
      </nav>

      <Section n={1} title="연산의 원리 — 명령어 사이클" sub="가져오고, 알아듣고, 실행한다. 그게 전부">
        <p>
          CPU는 마법의 상자가 아니에요. 하는 일은 딱 하나 —{' '}
          <strong>메모리에서 명령어를 가져와서(Fetch), 무슨 뜻인지 해석하고(Decode),
          실행한다(Execute)</strong>. 이 세 박자를 무한 반복할 뿐입니다.
        </p>
        <Code>{CODE_CYCLE}</Code>
        <p>
          요리사가 레시피를 <strong>한 줄 읽고 → 무슨 뜻인지 파악하고 → 칼질하는</strong> 것과
          똑같아요. 다른 점은 속도뿐 — CPU는 이 반복을 1초에 수십억 번 합니다.
          그래서 명령어 하나하나는 "두 숫자를 더해라" 수준으로 단순해도, 쌓이면
          게임이 되고, 우리 학습 플랫폼이 되고, AI가 되는 거예요.
        </p>
        <svg className="diagram" viewBox="0 0 640 300" xmlns="http://www.w3.org/2000/svg" role="img" aria-label="명령어 사이클 순환도: 가져오기, 해석, 실행 세 단계가 화살표로 이어지고 실행에서 다시 가져오기로 돌아온다">
          <rect x="30" y="60" width="160" height="96" rx="10" fill="var(--card)" stroke="var(--primary)" strokeWidth="2" />
          <text x="110" y="95" textAnchor="middle" fontSize="15" fontWeight="700" fill="var(--ink)">① 가져오기</text>
          <text x="110" y="114" textAnchor="middle" fontSize="12" fill="var(--muted)">(Fetch)</text>
          <text x="110" y="138" textAnchor="middle" fontSize="12" fill="var(--muted)">RAM에서 명령어 읽기</text>
          <rect x="240" y="60" width="160" height="96" rx="10" fill="var(--card)" stroke="var(--teal)" strokeWidth="2" />
          <text x="320" y="95" textAnchor="middle" fontSize="15" fontWeight="700" fill="var(--ink)">② 해석</text>
          <text x="320" y="114" textAnchor="middle" fontSize="12" fill="var(--muted)">(Decode)</text>
          <text x="320" y="138" textAnchor="middle" fontSize="12" fill="var(--muted)">무슨 뜻인지 알아듣기</text>
          <rect x="450" y="60" width="160" height="96" rx="10" fill="var(--card)" stroke="var(--amber)" strokeWidth="2" />
          <text x="530" y="95" textAnchor="middle" fontSize="15" fontWeight="700" fill="var(--ink)">③ 실행</text>
          <text x="530" y="114" textAnchor="middle" fontSize="12" fill="var(--muted)">(Execute)</text>
          <text x="530" y="138" textAnchor="middle" fontSize="12" fill="var(--muted)">계산하고 결과 저장</text>
          <line x1="190" y1="108" x2="228" y2="108" stroke="var(--muted)" strokeWidth="2" />
          <path d="M228 102 L240 108 L228 114 Z" fill="var(--muted)" />
          <line x1="400" y1="108" x2="438" y2="108" stroke="var(--muted)" strokeWidth="2" />
          <path d="M438 102 L450 108 L438 114 Z" fill="var(--muted)" />
          <polyline points="530,156 530,232 110,232 110,170" fill="none" stroke="var(--muted)" strokeWidth="2" />
          <path d="M104 170 L110 158 L116 170 Z" fill="var(--muted)" />
          <text x="320" y="252" textAnchor="middle" fontSize="12.5" fill="var(--muted)">다음 명령어로! — 이 세 박자를 1초에 수십억 번 반복</text>
        </svg>
        <p className="muted" style={{ fontSize: 12.5, textAlign: 'center', marginTop: 2 }}>그림: 명령어 사이클 — 가져오기(Fetch) → 해석(Decode) → 실행(Execute)의 무한 반복</p>
        <div className="tip">
          <b>미리 연결해 두기</b> 여러분이 React나 Spring Boot로 쓰는 코드도 결국 이 단순한
          명령어 수백만 개로 번역돼요. "내 코드 한 줄 = 기계 명령어 여러 개"라는 감각을
          지금 심어 두면, 나중에 성능 이야기가 나올 때 훨씬 쉽게 들립니다.
        </div>
      </Section>

      <Section n={2} title="코어 · 스레드 · 클럭" sub="요리사 몇 명이, 몇 박자로 일하는가">
        <p>
          CPU 스펙표의 용어들은 <strong>주방</strong>으로 바꿔 읽으면 한 번에 이해돼요.
          CPU라는 주방 안에 요리사(<strong>코어</strong>)가 여러 명 있고, 각자 일정한
          박자(<strong>클럭</strong>)로 손을 놀립니다.
        </p>
        <Code>{CODE_KITCHEN}</Code>
        <p>
          <strong>스레드</strong>가 헷갈리기 쉬운데, "요리사 한 명이 파스타 면을 삶는{' '}
          <strong>대기 시간</strong>에 옆 화구의 소스를 젓는" 기술이에요. 몸(코어)은 하나지만
          일감 줄(스레드)을 두 개 받아서 빈틈을 메우는 거죠. 그래서 8코어 16스레드는
          "요리사 8명인데 주문 창구는 16개"인 셈 — 진짜 16명만큼은 아니어도 8명보다는
          확실히 많은 일을 해냅니다.
        </p>
        <p>
          <strong>클럭(GHz)</strong>은 손 놀리는 속도예요. 4.5GHz면 1초에 45억 박자.
          다만 <strong>"클럭 높음 = 무조건 빠름"은 아닙니다</strong>. 박자당 해내는 일의 양(같은
          한 박자에 칼질을 한 번 하느냐 두 번 하느냐)이 세대마다 다르거든요 — 이 함정은
          섹션 5에서 다시 만나요.
        </p>
      </Section>

      <Section n={3} title="캐시 — 도마 옆 재료 선반" sub="L1, L2, L3… 가까울수록 작고 빠르다">
        <p>
          요리사가 재료 하나 꺼내러 매번 <strong>복도 끝 냉장고(RAM)</strong>까지 달려가면
          요리가 한없이 느려지겠죠. 그래서 자주 쓰는 재료를 <strong>도마 옆 선반</strong>에
          미리 올려 둡니다 — 이게 <strong>캐시</strong>예요. 그리고 이 선반이 3층으로 나뉘어 있죠.
        </p>
        <Code>{CODE_CACHE}</Code>
        <p>
          층수 규칙은 하나예요. <strong>코어에서 가까울수록 작고 빠르고, 멀수록 크고 느리다.</strong>{' '}
          L1은 손 안이라 순식간이지만 몇 줌밖에 못 담고, L3는 주방 전체가 나눠 쓰는 큰 선반이라
          넉넉하지만 몇 걸음 걸어가야 해요. CPU는 필요한 데이터를 L1 → L2 → L3 → RAM 순서로
          찾아보는데, 가까운 선반에서 바로 찾으면(<strong>캐시 히트</strong>) 빠르고, 없어서
          냉장고까지 가면(<strong>캐시 미스</strong>) 수십~수백 배 느려집니다.
        </p>
        <svg className="diagram" viewBox="0 0 640 360" xmlns="http://www.w3.org/2000/svg" role="img" aria-label="코어와 캐시 구조도: 코어마다 L1과 L2 캐시가 있고 L3 캐시는 코어들이 공유하며 RAM은 CPU 바깥에 있어 더 느리다">
          <rect x="40" y="30" width="400" height="230" rx="12" fill="var(--card)" stroke="var(--primary)" strokeWidth="2" />
          <text x="62" y="56" fontSize="14" fontWeight="700" fill="var(--primary)">CPU</text>
          <rect x="70" y="70" width="150" height="104" rx="8" fill="var(--card)" stroke="var(--line)" strokeWidth="1.5" />
          <text x="145" y="92" textAnchor="middle" fontSize="13" fontWeight="700" fill="var(--ink)">코어 1</text>
          <rect x="85" y="104" width="120" height="26" rx="6" fill="var(--card)" stroke="var(--teal)" strokeWidth="1.5" />
          <text x="145" y="121" textAnchor="middle" fontSize="12" fill="var(--ink)">L1 (수십 KB)</text>
          <rect x="85" y="138" width="120" height="26" rx="6" fill="var(--card)" stroke="var(--amber)" strokeWidth="1.5" />
          <text x="145" y="155" textAnchor="middle" fontSize="12" fill="var(--ink)">L2 (수 MB)</text>
          <rect x="260" y="70" width="150" height="104" rx="8" fill="var(--card)" stroke="var(--line)" strokeWidth="1.5" />
          <text x="335" y="92" textAnchor="middle" fontSize="13" fontWeight="700" fill="var(--ink)">코어 2</text>
          <rect x="275" y="104" width="120" height="26" rx="6" fill="var(--card)" stroke="var(--teal)" strokeWidth="1.5" />
          <text x="335" y="121" textAnchor="middle" fontSize="12" fill="var(--ink)">L1 (수십 KB)</text>
          <rect x="275" y="138" width="120" height="26" rx="6" fill="var(--card)" stroke="var(--amber)" strokeWidth="1.5" />
          <text x="335" y="155" textAnchor="middle" fontSize="12" fill="var(--ink)">L2 (수 MB)</text>
          <rect x="70" y="192" width="340" height="46" rx="8" fill="var(--card)" stroke="var(--rose)" strokeWidth="1.5" />
          <text x="240" y="220" textAnchor="middle" fontSize="12.5" fill="var(--ink)">L3 캐시 — 코어들이 공유 (수십 MB)</text>
          <line x1="240" y1="260" x2="240" y2="286" stroke="var(--muted)" strokeWidth="2" />
          <path d="M234 286 L240 298 L246 286 Z" fill="var(--muted)" />
          <rect x="70" y="302" width="340" height="46" rx="8" fill="var(--card)" stroke="var(--line)" strokeWidth="1.5" />
          <text x="240" y="330" textAnchor="middle" fontSize="12.5" fill="var(--ink)">RAM (수십 GB) — 복도 끝 냉장고</text>
          <text x="540" y="72" textAnchor="middle" fontSize="12" fill="var(--muted)">코어에 가까움</text>
          <text x="540" y="89" textAnchor="middle" fontSize="12" fill="var(--muted)">= 작고 빠르다</text>
          <line x1="540" y1="102" x2="540" y2="292" stroke="var(--muted)" strokeWidth="2" />
          <path d="M534 292 L540 304 L546 292 Z" fill="var(--muted)" />
          <text x="540" y="322" textAnchor="middle" fontSize="12" fill="var(--muted)">멀어질수록</text>
          <text x="540" y="339" textAnchor="middle" fontSize="12" fill="var(--muted)">= 크고 느리다</text>
        </svg>
        <p className="muted" style={{ fontSize: 12.5, textAlign: 'center', marginTop: 2 }}>그림: 코어별 L1·L2, 공유 L3, 그리고 CPU 바깥의 RAM — 가까울수록 작고 빠르다</p>
        <div className="warn">
          <b>스펙표의 숨은 실력자</b> — 같은 코어 수·클럭이라도 L3 캐시가 큰 CPU가 게임이나
          빌드에서 눈에 띄게 빠른 경우가 많아요. 코어 수와 클럭만 보고 CPU를 고르면
          절반만 보는 겁니다.
        </div>
      </Section>

      <Section n={4} title="발열과 쿨링, 그리고 스로틀링" sub="빨리 달릴수록 뜨거워지고, 뜨거우면 스스로 감속한다">
        <p>
          1초에 수십억 번 스위치를 켰다 끄면 당연히 <strong>열</strong>이 나요. 문제는 CPU가
          열에 약하다는 것 — 그래서 모든 PC에는 <strong>쿨링</strong>(방열판+팬, 고성능 PC는
          수랭)이 붙어 있고, CPU 자신도 비장의 자기 보호 기능을 갖고 있습니다.
          바로 <strong>스로틀링</strong>이에요.
        </p>
        <Code>{CODE_THROTTLE}</Code>
        <p>
          마라톤 선수가 전력 질주로 시작했다가 몸에 무리가 오면 <strong>스스로 페이스를
          낮추는</strong> 것과 같아요. 고장이 아니라 타 버리는 걸 막는 정상 동작입니다.
          노트북이 얇을수록 쿨링 공간이 좁아 스로틀링이 빨리 오고, 그래서{' '}
          <strong>같은 CPU라도 데스크톱과 얇은 노트북의 실제 성능이 다른</strong> 거예요.
          여름철 게임이 유독 버벅이는 것도, 노트북을 이불 위에 올려 두면(통풍구 막힘) 느려지는
          것도 전부 이 친구 소행이고요.
        </p>
        <div className="tip">
          <b>개발자의 습관</b> 빌드가 평소보다 이상하게 느리면 코드 탓만 하지 말고
          팬 소리·기기 온도부터 체크해 보세요. 통풍구를 확보하는 것만으로 빌드 시간이
          돌아오는 경우가 실제로 있습니다.
        </div>
      </Section>

      <Section n={5} title="인텔 vs 라이젠 — 이름 해독하기" sub="i7-14700K, Ryzen 7 7700X… 암호가 아니라 문법이에요">
        <p>
          CPU 시장은 크게 <strong>인텔(Core 시리즈)</strong>과{' '}
          <strong>AMD(Ryzen 시리즈)</strong> 두 진영이에요. 제품 이름이 암호처럼 보이지만,
          사실 <strong>등급(체급) + 세대(연식) + 접미사(옵션)</strong>라는 똑같은 문법으로
          만들어져 있어서 한 번 배우면 평생 읽습니다.
        </p>
        <Code>{CODE_NAMING}</Code>
        <p>
          중고차 고르기와 똑같아요. "그랜저(체급)냐 아반떼냐"만큼{' '}
          <strong>"2018년식이냐 2024년식이냐(세대)"</strong>가 중요하죠. 최신 연식의 중형차가
          10년 된 대형차보다 잘 달리는 것처럼, <strong>최신 세대 i5가 구형 i7을 이기는 건
          아주 흔한 일</strong>입니다. 친구가 "i7인데 왜 느리지?"라고 하면 이제 여러분이
          세대를 물어봐 줄 수 있어요.
        </p>
      </Section>

      <Section n={6} title="직접 확인해 보기 ① — 작업 관리자로 내 CPU 관찰" sub="지금까지 배운 용어를 전부 내 PC에서 찾아보기">
        <p>
          이론은 끝! 이제 <strong>내 PC의 CPU</strong>를 직접 들여다볼 차례예요.
          Windows 작업 관리자에는 오늘 배운 코어·스레드·클럭·캐시가 전부 표시됩니다.
        </p>
        <Code>{CODE_TASKMGR}</Code>
        <div className="tip">
          <b>직접 확인해 보기</b> <span className="kbd">Ctrl</span> +{' '}
          <span className="kbd">Shift</span> + <span className="kbd">Esc</span>로 작업 관리자를
          열고, 위 순서대로 따라가며 다음 세 가지를 노트에 적어 보세요.
        </div>
        <ol className="olist">
          <li>내 CPU의 정확한 이름 — 그리고 섹션 5의 문법으로 <strong>체급과 세대를 해독</strong>해 보기</li>
          <li>코어 수와 논리 프로세서(스레드) 수 — 우리 주방의 요리사는 몇 명?</li>
          <li>L1/L2/L3 캐시 크기 — 정말 층수가 올라갈수록 커지는지 확인</li>
        </ol>
        <div className="tip">
          <b>한 걸음 더</b> 그래프를 <strong>논리 프로세서</strong> 보기로 바꾼 뒤, 유튜브 영상을
          하나 틀어 보세요. 어떤 칸(코어)이 바빠지나요? 모든 코어가 조금씩 나눠 일하나요,
          한두 코어만 집중적으로 일하나요? 이 관찰이 다음 섹션의 복선입니다.
        </div>
      </Section>

      <Section n={7} title="개발자에게 CPU가 중요한 순간" sub="직접 확인해 보기 ② — 빌드 시간으로 체감하기">
        <p>
          "나는 게임 안 하는데 CPU가 왜 중요해요?" — 개발자에겐{' '}
          <strong>빌드</strong>가 게임이에요. 우리 스택(React·Spring Boot·Docker)의 빌드는
          코드 수천 개 파일을 컴파일하고 압축하는 <strong>CPU 총력전</strong>이거든요.
        </p>
        <Code>{CODE_BUILD}</Code>
        <div className="tip">
          <b>직접 확인해 보기</b> 우리 플랫폼 프론트엔드 저장소(
          <span className="icode">mirim-app/frontend</span>)를 받아 둔 PC에서, 작업 관리자의
          CPU 그래프(논리 프로세서 보기)를 <strong>옆에 띄워 놓고</strong> 터미널에{' '}
          <span className="icode">npm run build</span>를 실행해 보세요. 조용하던 코어들이
          일제히 100%로 치솟는 장관을 볼 수 있어요. 걸린 시간도 기록해 두세요 — 나중에
          장비가 바뀌면 비교해 보는 재미가 있습니다. (Gitea{' '}
          <span className="icode">edu.awesomedevapp.com:3000</span>에서 클론할 수 있어요.)
        </div>
        <p>
          하나 더 — 빌드 도중 그래프를 보면 <strong>모든 코어가 다 바쁜 구간</strong>과{' '}
          <strong>한 코어만 일하는 구간</strong>이 번갈아 나타나요. 병렬로 쪼갤 수 있는 일과
          순서대로만 해야 하는 일이 섞여 있기 때문이죠. "코어가 많다고 모든 게 코어 수만큼
          빨라지진 않는다"는 사실을 그래프 하나로 체감하게 됩니다.
        </p>
        <div className="warn">
          <b>서버도 마찬가지</b> — 우리 서비스가 도는 AWS EC2(서울)도 인스턴스 등급에 따라
          vCPU 수가 달라요. 배포 빌드가 느리다면 코드 문제일 수도 있지만, 서버의 요리사 수가
          부족한 걸 수도 있습니다. 스펙을 읽을 줄 알면 원인을 나눠서 볼 수 있어요.
        </div>
      </Section>

      <div className="step-card">
        <div className="step-body">
          <h3 style={{ marginBottom: 6 }}>🧠 여기까지 왔다면</h3>
          <p className="muted">
            이제 CPU 스펙표가 암호가 아니라 문장으로 읽혀요 — 명령어 사이클이라는 심장 박동,
            코어·스레드·클럭·캐시라는 주방의 구조, 스로틀링이라는 자기 보호, 그리고 이름
            해독법까지. 다음은 CPU가 재료를 가져오는{' '}
            <Link to="/learn/memory-storage"><strong>냉장고(메모리)와 창고(저장장치)</strong></Link>
            {' '}차례예요 — <Link to="/learn/network"><strong>네트워크의 이해</strong></Link> 코스와
            함께 들으면 "내 코드가 실행되는 무대" 전체가 그려집니다. 실습 ①·②에서 기록한
            숫자들은 멘토와의 주간 리뷰 때 가져와서 같이 해석해 보세요.
          </p>
        </div>
      </div>
    </div>
  );
}
