// 이 파일이 하는 일: "에러와 친해지기: 빨간 글씨 해독법" 코스 — 코딩을 처음 시작한 사람이
// 가장 먼저 부딪히는 '빨간 에러 메시지'를 무서운 벌점이 아니라 친절한 힌트로 읽어 내는 법을
// 8개 섹션으로 안내하는 정적 학습 페이지. 에러 메시지의 3부 구조 → 3대 에러 유형(Syntax·
// Reference·Type) → 탐정식 디버깅 → 검색·AI 활용 → 일부러 에러 내 보는 실습까지 이어진다.
// 학습 포인트: API 호출이 없는 '내용 고정' 페이지다. 스타일은 styles/global.css의
// 가이드 전용 클래스(step-card, code-block, tip 등)를 재사용하고 색은 var(--*)만 쓴다(하드코딩 금지).
// 예제 코드는 JSX 중괄호/백틱 충돌을 피하려고 파일 상단의 백틱 문자열 상수로 정의한다.

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

// ── 예제 코드 상수들 ──

const CODE_EVERYONE = `여러분이 오늘 만난 에러          10년 차 개발자가 오늘 만난 에러
─────────────────────          ─────────────────────────
SyntaxError: ...  (3번)         SyntaxError: ...  (아마 더 많이)
ReferenceError: ... (2번)       ReferenceError: ... (역시 만남)

차이는 '에러를 안 만나는 것'이 아니라
'에러를 만났을 때 몇 분 만에 빠져나오는가'예요.
에러 메시지는 벌점 통지서가 아니라,
컴퓨터가 최선을 다해 써 준 안내문입니다.`;

const CODE_ANATOMY = `// 브라우저 콘솔에 뜬 빨간 글씨 한 줄을 해부해 봅시다.

Uncaught TypeError: user.sayHi is not a function
    at greet (script.js:12:8)

┌ ① 에러 이름:  TypeError
│    → "어떤 종류의 문제인가" (오늘 3가지 유형을 배워요)
├ ② 설명:      user.sayHi is not a function
│    → "정확히 무엇이 문제인가" (sayHi가 함수가 아니래요)
└ ③ 위치:      script.js:12:8
     → "어디를 보면 되는가" (script.js 파일 12번째 줄, 8번째 칸)

읽는 순서는 거꾸로! ③ 줄번호로 먼저 이동 → ② 설명 대조 → ① 유형 파악`;

const CODE_SYNTAX = `// SyntaxError — 컴퓨터가 문장을 '읽지도 못한' 상태. 실행 전에 걸립니다.

// 흔한 패턴 1: 괄호 짝이 안 맞음
console.log("안녕하세요"    // ← 닫는 괄호 ) 가 없다!
// SyntaxError: missing ) after argument list

// 흔한 패턴 2: 따옴표 짝이 안 맞음
const name = "지민;          // ← 닫는 따옴표 " 가 없다!
// SyntaxError: Invalid or unexpected token

// 흔한 패턴 3: 중괄호 짝이 안 맞음
function hello()
  console.log("hi");
                             // ← 여는 중괄호가 없어서 몸통이 미아가 됨
// SyntaxError: Unexpected token

// 요령: 괄호·따옴표·중괄호는 항상 '쌍'이다.
// 하나를 열면(( " [ ) 반드시 하나를 닫는다() " ]).`;

const CODE_REFERENCE = `// ReferenceError — "그런 이름, 나는 모르는데?" 이름표를 못 찾은 상태.

const userName = "지민";
console.log(username);
// ReferenceError: username is not defined
//                 ^^^^^^^^
// 범인: 대소문자! userName(대문자 N)으로 선언했는데
//       username(소문자 n)으로 불렀어요. 컴퓨터에겐 완전히 다른 이름.

console.log(scroe);
// ReferenceError: scroe is not defined
// 범인: 오타. score를 scroe로 잘못 쳤어요.

console.log(count);   // ← 선언(let count = 0)보다 먼저 사용
let count = 0;
// ReferenceError: Cannot access 'count' before initialization
// 범인: 순서. 이름표를 붙이기 전에 부르면 컴퓨터는 모릅니다.

// "is not defined"를 보면 딱 세 가지만 의심하세요.
// ① 대소문자가 다른가?  ② 철자가 틀렸나?  ③ 선언보다 먼저 썼나?`;

const CODE_TYPE = `// TypeError — 이름은 찾았는데, 그 값으로 '그런 동작'을 할 수 없는 상태.

const age = 15;
age.toUpperCase();
// TypeError: age.toUpperCase is not a function
// 이유: toUpperCase()는 문자열 전용인데, age는 숫자예요.
//       숫자에게 "대문자로 바꿔!"라고 시킨 셈.

const user = null;
console.log(user.name);
// TypeError: Cannot read properties of null (reading 'name')
// 이유: user가 비어 있는데(null) .name을 꺼내려 했어요.
//       빈 상자에서 물건을 꺼내려는 것과 같아요.

// 추적 도구: typeof — 값의 정체를 물어보는 돋보기
console.log(typeof age);    // "number"  ← 아, 숫자였구나
console.log(typeof "안녕"); // "string"
console.log(typeof user);   // "object"  (null은 object로 나와요 — 유명한 옛날 버그)

// "is not a function" / "Cannot read properties of ..." 가 보이면
// → 그 값의 형(type)이 내 기대와 다르다는 뜻. typeof로 먼저 확인!`;

const CODE_DEBUG = `// 탐정의 기본기: console.log를 심어 값의 흐름을 눈으로 확인한다.

function calcTotal(price, count) {
  console.log("① 들어온 값:", price, count);   // 입구에서 확인

  const discounted = price * 0.9;
  console.log("② 할인 후:", discounted);       // 중간에서 확인

  const total = discounted * count;
  console.log("③ 최종:", total);               // 출구에서 확인
  return total;
}

calcTotal("1000", 3);
// ① 들어온 값: 1000 3     ← 겉보기엔 멀쩡한데...
// ② 할인 후: 900          ← 여기까진 괜찮고
// ③ 최종: 2700            ← 어라? 계산은 됐네?
// console.log("①의 정체:", typeof price);  // "string"!! 문자열이 들어왔다!

// 반씩 좁히기: 코드가 100줄이면 50번째 줄에 log를 하나 심는다.
// 값이 정상이면 → 뒤쪽 50줄이 범인. 이상하면 → 앞쪽 50줄이 범인.
// 이걸 반복하면 100줄도 log 7번이면 범인 줄을 특정할 수 있어요. (2의 7승 = 128)`;

const CODE_SEARCH = `// 나쁜 질문 vs 좋은 질문 — 검색이든 AI든 똑같이 적용됩니다.

[나쁜 질문]
"코드가 안 돼요. 도와주세요."
→ 아무도(사람도 AI도) 도울 수 없어요. 정보가 0이니까.

[좋은 질문 3종 세트]
① 코드:      "이 코드를 실행했는데"       + 문제의 코드 몇 줄
② 에러:      "이 에러가 났어요"           + 에러 메시지 전문 복사
③ 시도한 것: "괄호 짝은 확인해 봤어요"    + 내가 이미 해 본 것

[검색 요령]
- 에러 메시지를 그대로 검색창에 붙여넣기 (따옴표로 감싸면 더 정확)
- 단, 내 파일명·변수명처럼 '나만의 부분'은 지우고 검색
  검색 O: "Cannot read properties of null"
  검색 X: "Cannot read properties of null (reading 'jiminScore')"
                                                  ^^^^^^^^^^ 나만 쓰는 이름`;

const CODE_PRACTICE = `// 실습용 코드 — 멀쩡히 돌아가는 코드예요. 이걸 '일부러' 망가뜨려 봅시다.

const students = ["지민", "서연", "하준"];

function makeGreeting(name) {
  return "안녕하세요, " + name + "님!";
}

for (const s of students) {
  console.log(makeGreeting(s));
}

// ── 미션: 세 군데를 하나씩 망가뜨리고, 뜨는 에러를 '예측'한 뒤 확인하기 ──
// ① makeGreeting의 닫는 괄호 ) 하나 지우기   → 무슨 에러가 뜰까?
// ② makeGreeting(s)를 makegreeting(s)로 바꾸기 → 무슨 에러가 뜰까?
// ③ students를 숫자 123으로 바꾸기            → 무슨 에러가 뜰까?
//
// 예측 답: ① SyntaxError  ② ReferenceError  ③ TypeError
// (③은 숫자 123은 for...of로 돌 수 없어서 "is not iterable"류 TypeError)
//
// 망가뜨리기 전의 코드로 되돌릴 수 있게, 원본을 꼭 복사해 두세요!`;

// ── 이 페이지 안에서만 쓰는 작은 부품들 ──
// 학습 포인트: 같은 모양이 반복되면 컴포넌트로 뽑는다. 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: 'SyntaxError' },
  { n: 4, label: 'ReferenceError' },
  { n: 5, label: 'TypeError' },
  { n: 6, label: '탐정 디버깅' },
  { n: 7, label: '검색과 AI' },
  { n: 8, label: '실습' },
];

export default function Lv1ReadingErrorsPage() {
  return (
    <div>
      {/* 히어로: 이 코스가 어디서 출발해 어디까지 가는지 */}
      <div className="hero">
        <div className="eyebrow">Course · 초급 과정</div>
        <h1>🩹 에러와 친해지기<br />— 빨간 글씨 해독법</h1>
        <p>
          코드를 실행했더니 화면 가득 <strong>빨간 글씨</strong>가 떴다면 — 축하해요, 드디어
          진짜 코딩을 시작한 거예요. 에러는 벌점이 아니라 <strong>컴퓨터가 주는 힌트</strong>
          입니다. 이 코스에서는 그 힌트를 읽고, 원인을 좁히고, 스스로 고치는 힘을 기릅니다.
          이 힘 하나가 앞으로 배울 모든 것의 속도를 정해요.
        </p>
        <div className="chip-row">
          <span className="chip">예상 소요 60분</span>
          <span className="chip">실습: 버그 5개 스스로 고치기</span>
          <span className="chip">선수 지식: 없음 (변수·함수를 봤다면 더 좋아요)</span>
        </div>
      </div>

      {/* 섹션 바로가기 — 학습 포인트: SECTIONS 배열 하나로 nav를 그린다(map 재사용) */}
      <div className="chip-row">
        {SECTIONS.map((s) => (
          <a key={s.n} className="chip" href={`#sec-${s.n}`}>
            <b>{s.n}</b>&nbsp;{s.label}
          </a>
        ))}
      </div>

      <Section n={1} title="에러는 적이 아니라 힌트" sub="빨간 글씨 공포부터 내려놓기">
        <p>
          처음 에러를 만나면 심장이 철렁해요. "내가 뭘 망가뜨렸나?", "컴퓨터가 고장 났나?" —
          둘 다 아닙니다. 에러는 컴퓨터가 <strong>"여기서 멈췄는데, 이유는 이거야"</strong>라고
          최선을 다해 써 준 <strong>안내문</strong>이에요. 시험지의 빨간 채점이 아니라,
          길을 잃었을 때 나타나는 <strong>안내 표지판</strong>에 가깝습니다.
        </p>
        <p>
          그리고 하나 더 — 에러는 <strong>모든 개발자가 매일</strong> 만나요. 10년 차 개발자도
          하루에 수십 번씩 에러를 봅니다. 초보와 고수의 차이는 "에러를 안 만나느냐"가 아니라,
          <strong> 에러를 만났을 때 얼마나 빨리 빠져나오느냐</strong>예요.
        </p>
        <Code>{CODE_EVERYONE}</Code>
        <p>
          가장 나쁜 반응은 에러 메시지를 <strong>읽지도 않고</strong> 코드를 이리저리 바꿔 보는
          거예요. 그건 안내 표지판을 등지고 아무 방향으로나 달리는 것과 같아요. 오늘 이후로
          약속 하나만 해요 — <strong>빨간 글씨가 뜨면, 일단 읽는다.</strong> 그것만으로 문제의
          절반은 풀립니다.
        </p>
        <div className="tip">
          <b>마음가짐 리셋</b> 에러가 떴다 = "코드가 틀렸다"가 아니라 <strong>"컴퓨터가 단서를
          줬다"</strong>예요. 심지어 에러가 안 뜨고 조용히 이상하게 동작하는 버그가 훨씬 더
          무섭습니다. 소리 내서 알려 주는 에러는 오히려 고마운 쪽이에요.
        </div>
      </Section>

      <Section n={2} title="에러 메시지 해부하기" sub="이름 · 설명 · 위치, 딱 세 조각">
        <p>
          영어로 된 빨간 글씨가 길어 보여도, 뜯어 보면 언제나 <strong>세 부분</strong>으로
          이루어져 있어요. <strong>① 에러 이름</strong>(어떤 종류의 문제인가),{' '}
          <strong>② 설명</strong>(정확히 무엇이 문제인가),{' '}
          <strong>③ 파일과 줄번호</strong>(어디를 보면 되는가). 이 구조만 알면 아무리 긴
          에러도 3초 안에 뼈대를 잡을 수 있습니다.
        </p>
        <Code>{CODE_ANATOMY}</Code>
        <p>
          읽는 순서는 <strong>거꾸로</strong>가 효율적이에요. 먼저 <strong>③ 줄번호</strong>로
          그 줄에 가 봅니다. <span className="icode">script.js:12:8</span>은 "script.js 파일의
          12번째 줄, 8번째 글자"라는 뜻이에요. 그 줄을 눈으로 보면서 ② 설명과 대조하면,
          대부분 그 자리에서 원인이 보입니다.
        </p>
        <p>
          영어가 겁난다면 이렇게 번역하세요. 에러 메시지의 영어는 사실{' '}
          <strong>몇 가지 패턴의 반복</strong>이에요. <span className="icode">is not
          defined</span> = "그런 이름 모른다", <span className="icode">is not a function</span> =
          "그건 함수가 아니다", <span className="icode">unexpected token</span> = "여기 올 수 없는
          글자가 왔다", <span className="icode">cannot read properties of null</span> = "빈 값에서
          뭘 꺼내려 했다". 이 네 문장만 외워도 초급 에러의 대부분을 해석할 수 있어요.
        </p>
        <div className="tip">
          <b>습관 만들기</b> 에러를 보면 <strong>"이름 → 위치 → 설명"을 소리 내어 읽기</strong>를
          추천해요. "타입에러, 12번째 줄, sayHi가 함수가 아니래" — 입 밖으로 정리하는 것만으로
          막연한 공포가 구체적인 할 일로 바뀝니다.
        </div>
      </Section>

      <Section n={3} title="문법 에러: SyntaxError" sub="컴퓨터가 문장을 읽지도 못했을 때">
        <p>
          <strong>SyntaxError(문법 에러)</strong>는 컴퓨터가 코드를{' '}
          <strong>실행해 보기도 전에</strong> "이건 문장이 안 돼서 못 읽겠어"라고 손을 드는
          경우예요. 우리말로 치면 "나는 밥을 먹었"처럼 문장이 중간에 끊긴 상태죠. 원인의
          대부분은 <strong>짝이 안 맞는 기호</strong> — 괄호 <span className="icode">( )</span>,
          따옴표 <span className="icode">" "</span>, 중괄호가 하나를 열고 닫지 않은 경우입니다.
        </p>
        <Code>{CODE_SYNTAX}</Code>
        <p>
          SyntaxError의 좋은 점(?)은 <strong>코드가 아예 시작도 못 하기 때문에</strong> 숨을
          곳이 없다는 거예요. 줄번호가 가리키는 곳 근처에서 열고 닫는 짝만 세어 보면 대부분
          잡힙니다. 단, 조심할 것 하나 — 에러가 가리키는 줄번호는 컴퓨터가 "여기서 이상함을
          눈치챈" 위치라서, 진짜 범인(예: 위쪽에서 안 닫힌 괄호)은{' '}
          <strong>그 줄보다 위</strong>에 있을 수 있어요.
        </p>
        <div className="tip">
          <b>에디터를 내 편으로</b> VS Code 같은 에디터는 실행 전에 이미{' '}
          <strong>빨간 밑줄</strong>로 문법 문제를 표시해 줘요. 괄호를 클릭하면 짝이 되는
          괄호가 하이라이트되고요. 빨간 밑줄이 남아 있는 채로 실행 버튼부터 누르지 말고,
          밑줄에 마우스를 올려 메시지를 먼저 읽는 습관을 들이세요. 에러를{' '}
          <strong>실행 전에 미리 만나는</strong> 가장 쉬운 방법입니다.
        </div>
      </Section>

      <Section n={4} title="참조 에러: ReferenceError" sub="'is not defined' — 그런 이름 모른다는 뜻">
        <p>
          <strong>ReferenceError(참조 에러)</strong>는 컴퓨터가 코드를 읽는 데는 성공했지만,
          여러분이 부른 <strong>이름을 찾지 못했을 때</strong> 나요. 핵심 메시지는{' '}
          <span className="icode">... is not defined</span> — "그런 이름은 정의된 적이 없는데?"
          라는 뜻입니다. 친구 이름을 잘못 불렀는데 아무도 돌아보지 않는 상황이에요.
        </p>
        <Code>{CODE_REFERENCE}</Code>
        <p>
          통계적으로 <strong>1등 원인은 대소문자 오타</strong>예요. 컴퓨터에게{' '}
          <span className="icode">userName</span>과 <span className="icode">username</span>은
          완전히 다른 이름입니다. 사람 눈에는 거의 같아 보여서 더 악질이죠. 2등은 순수한 철자
          오타(<span className="icode">score</span> → <span className="icode">scroe</span>),
          3등은 <strong>선언하기 전에 사용</strong> — 변수는 이름표를 붙인{' '}
          <span className="icode">let</span>/<span className="icode">const</span> 줄{' '}
          <strong>아래</strong>에서만 부를 수 있어요.
        </p>
        <div className="tip">
          <b>3초 점검법</b> "is not defined"가 뜨면 에러가 알려 준 이름을 복사해서, 에디터
          검색(<span className="icode">Ctrl+F</span>)으로 찾아 보세요. 검색 결과가{' '}
          <strong>딱 한 군데</strong>(에러 난 그 줄)뿐이라면 십중팔구 오타예요 — 선언한 곳의
          진짜 이름과 글자 하나하나를 대조해 보면 범인이 나옵니다.
        </div>
      </Section>

      <Section n={5} title="타입 에러: TypeError" sub="값은 있는데, 그 값으로 그 동작은 못 할 때">
        <p>
          <strong>TypeError(타입 에러)</strong>는 이름은 찾았는데, 그 값의{' '}
          <strong>형(type)이 기대와 달라서</strong> 시킨 동작을 못 할 때 나요. 값에는 저마다
          형이 있어요 — 숫자(number), 문자열(string), 그리고 "비어 있음"을 뜻하는{' '}
          <span className="icode">null</span> 같은 것들이요. 숫자에게 "대문자로 바꿔!"라고
          시키면, 컴퓨터는 "숫자는 그런 거 못 하는데…"라며 TypeError를 냅니다.
        </p>
        <Code>{CODE_TYPE}</Code>
        <p>
          자주 보게 될 두 문장을 기억하세요. <span className="icode">... is not a
          function</span>은 "함수인 줄 알고 불렀는데 함수가 아니다",{' '}
          <span className="icode">Cannot read properties of null</span>은 "빈 값에서 뭔가를
          꺼내려 했다"예요. 둘 다 결론은 같아요 —{' '}
          <strong>그 자리에 온 값이 내 예상과 다르다.</strong>
        </p>
        <p>
          이때의 추적 도구가 <span className="icode">typeof</span>입니다. 의심 가는 값 앞에{' '}
          <span className="icode">console.log(typeof 값)</span> 한 줄을 심으면 값의 정체가
          <strong> "number"·"string"·"object"</strong> 같은 답으로 돌아와요. "왜 안 되지?"라고
          고민하는 시간의 절반은, typeof 한 줄이면 끝나는 경우가 많습니다.
        </p>
        <div className="tip">
          <b>세 에러 한 줄 정리</b> <strong>SyntaxError</strong> = 문장이 안 됨(읽기 실패) ·{' '}
          <strong>ReferenceError</strong> = 이름을 못 찾음(호출 실패) ·{' '}
          <strong>TypeError</strong> = 값의 형이 다름(동작 실패). 에러 이름만 보고 이 셋 중
          어느 단계에서 막혔는지 말할 수 있다면, 이 코스의 절반은 이미 통과예요.
        </div>
      </Section>

      <Section n={6} title="탐정처럼 디버깅하기" sub="값의 흐름을 추적해 범인 줄을 특정한다">
        <p>
          에러 메시지가 줄번호까지 알려 주면 다행인데, 가끔은 "에러는 안 나는데 결과가
          이상한" 경우도 있어요. 이때부터는 <strong>탐정의 시간</strong>입니다. 기본 도구는
          단 하나, <span className="icode">console.log</span> — 코드 중간중간에 심어서{' '}
          <strong>값이 어떻게 흘러가는지</strong>를 눈으로 확인하는 거예요.
        </p>
        <Code>{CODE_DEBUG}</Code>
        <p>
          코드가 길다면 <strong>반씩 좁히기</strong>를 쓰세요. 전체의 한가운데에 log를 심고,
          거기까지의 값이 정상이면 범인은 뒤쪽 절반, 이상하면 앞쪽 절반이에요. 남은 절반에서
          또 반을 가르고… 이걸 반복하면 100줄짜리 코드도 log 일곱 번이면 범인 줄을 특정할 수
          있습니다. 무작정 처음부터 훑는 것보다 압도적으로 빨라요.
        </p>
        <p>
          그리고 탐정의 제1원칙 — <strong>"마지막으로 고친 곳"부터 의심하라.</strong> 방금까지
          잘 돌던 코드가 갑자기 죽었다면, 범인은 거의 항상 <strong>그 사이에 내가 바꾼
          부분</strong>이에요. "내가 뭘 건드렸지?"를 먼저 되짚는 것이, 코드 전체를 뒤지는
          것보다 백 배 빠릅니다.
        </p>
        <div className="tip">
          <b>log에 이름표 달기</b> <span className="icode">console.log(price)</span>처럼 값만
          찍으면, 여러 개를 찍었을 때 어느 게 어느 값인지 헷갈려요.{' '}
          <span className="icode">console.log("① 들어온 값:", price)</span>처럼{' '}
          <strong>이름표를 함께</strong> 찍는 습관을 들이면, 콘솔이 깔끔한 수사 기록이 됩니다.
          다 찾은 뒤에는 심어 둔 log를 지우는 것까지가 수사의 마무리예요.
        </div>
      </Section>

      <Section n={7} title="검색과 AI로 해결하기" sub="좋은 질문에는 코드·에러·시도한 것이 담긴다">
        <p>
          혼자 15분쯤 씨름해도 안 풀리면, 그때는 바깥의 힘을 빌릴 차례예요. 첫 번째 요령은
          간단합니다 — <strong>에러 메시지를 그대로 복사해서 검색창에 붙여넣기.</strong>{' '}
          전 세계 누군가가 이미 같은 에러를 만나 질문을 올렸고, 답도 달려 있을 확률이 아주
          높아요. 단, 내 변수명·파일명처럼 <strong>나만 쓰는 부분은 지우고</strong> 검색해야
          남들의 질문과 겹칩니다.
        </p>
        <Code>{CODE_SEARCH}</Code>
        <p>
          AI에게 물을 때도 똑같아요. "안 돼요"만 던지면 AI도 점쟁이가 될 수밖에 없어요.{' '}
          <strong>① 문제의 코드, ② 에러 메시지 전문, ③ 내가 이미 시도해 본 것</strong> — 이
          3종 세트를 갖춰 물으면 답의 정확도가 완전히 달라집니다. 사실 이 세트를 준비하는
          과정에서 스스로 답을 찾는 경우도 많고요. 이걸 개발자들은 "고무 오리에게 설명하다
          답을 깨닫는다"라고 불러요.
        </p>
        <p>
          마지막으로 제일 중요한 것 — 답을 찾았으면 <strong>이해하고 나서 옮겨 적으세요.</strong>{' '}
          복사–붙여넣기로 일단 돌아가게 만들면 그 순간은 편하지만, 같은 에러를 다음 주에 또
          만나요. "이 답이 <strong>왜</strong> 내 에러를 고치는가"를 한 문장으로 설명할 수
          있을 때만 붙여넣기 — 이 규칙 하나가 성장 속도를 가릅니다.
        </p>
        <div className="tip">
          <b>15분 규칙</b> 15분은 혼자 씨름하고(여기서 실력이 늘어요), 15분이 지나면
          주저 없이 검색·질문하세요(여기서 시간을 아껴요). 무한정 혼자 붙드는 것도,
          1분 만에 바로 물어보는 것도 모두 성장을 늦춥니다.
        </div>
      </Section>

      <Section n={8} title="실습: 일부러 에러 내 보기" sub="망가뜨릴 줄 알면 고칠 줄도 안다">
        <p>
          마지막 실습은 거꾸로 갑니다. 멀쩡한 코드를 <strong>일부러 망가뜨리고</strong>, 어떤
          에러가 뜰지 <strong>먼저 예측한 뒤</strong> 실행해서 확인하는 거예요. 에러를 스스로
          만들어 본 사람은 에러가 더 이상 무섭지 않아요 — 어떤 실수가 어떤 빨간 글씨로
          이어지는지, 인과가 몸에 새겨지니까요.
        </p>
        <Code>{CODE_PRACTICE}</Code>
        <p>
          짝이 있다면 더 재미있게 할 수 있어요. 서로의 멀쩡한 코드를 <strong>몰래 세 군데
          망가뜨려 교환</strong>하고, 에러 메시지만 보고 전부 고쳐 내는 시합을 해 보세요.
          "이 에러 메시지는 어떤 원인과 짝인가"를 맞히는 게임을 반복하다 보면, 어느 순간
          에러 이름만 봐도 손이 먼저 움직이게 됩니다.
        </p>
        <p>
          그리고 이 코스의 본 실습 — <strong>버그 5개가 심어진 코드</strong>를 받아서, 에러
          메시지만 단서로 전부 고쳐 보세요. 요령은 배운 그대로예요. ① 빨간 글씨를 읽는다 →
          ② 줄번호로 간다 → ③ 에러 이름으로 유형(문법/참조/타입)을 가른다 → ④ 막히면
          console.log와 typeof로 추적한다 → ⑤ 15분 넘게 막히면 검색한다.
        </p>
        <div className="tip">
          <b>속도가 곧 실력</b> 첫 버그에 20분이 걸려도 괜찮아요. 다섯 번째 버그에서 5분이
          됐다면, 이 60분짜리 코스에서 얻어 갈 수 있는 최고의 성과를 이미 얻은 겁니다.
          디버깅 속도는 재능이 아니라 <strong>순서를 지키는 습관</strong>에서 나와요.
        </div>
      </Section>

      <div className="step-card">
        <div className="step-body">
          <h3 style={{ marginBottom: 6 }}>🩹 여기까지 왔다면</h3>
          <p className="muted">
            이제 빨간 글씨는 공포가 아니라 <strong>읽을 수 있는 안내문</strong>이 됐어요.
            에러 메시지의 세 조각(이름·설명·위치), 3대 에러 유형(Syntax·Reference·Type),
            console.log와 typeof로 추적하는 탐정의 기술, 그리고 검색과 AI에게 제대로 묻는
            법까지 — 앞으로 만날 <strong>모든 에러에 통하는 무기</strong>를 손에 쥐었습니다.
            이 무기를 제대로 시험해 볼 시간이에요. 다음{' '}
            <Link to="/learn/lv1-first-mini-project"><strong>첫 프로젝트: 숫자 맞히기 게임
            만들기</strong></Link> 코스에서 처음으로 나만의 프로그램을 만들어 봅시다 — 만드는
            동안 에러가 여러 번 뜨겠지만, 이제 여러분은 그게 반가울 거예요.
          </p>
        </div>
      </div>
    </div>
  );
}
