// 이 파일이 하는 일: "UI/UX 기초" 코스 — UI와 UX의 차이에서 출발해
// 시각적 위계·일관성·피드백·색·여백·휴리스틱을 거쳐 '화면 비평' 실습까지
// 8개 섹션으로 안내하는 정적 학습 페이지. 개발·디자인 수습생 모두 대상.
// 학습 포인트: API 호출이 없는 '내용 고정' 페이지다. 스타일은 global.css의
// 가이드 전용 클래스(step-card, code-block, tip 등)를 재사용한다 — 색을 여기서 하드코딩하지 않는다.
// 텍스트 표·예시는 JSX 중괄호/백틱 충돌을 피하려고 파일 상단의 백틱 문자열 상수로 정의한다.

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

// ── 텍스트 표 · 예시 상수들 ──

const CODE_UI_VS_UX = `UI vs UX — 케첩병으로 이해하기

              유리 케첩병               거꾸로 세우는 플라스틱병
─────────────────────────────────────────────────────────
UI(보이는 것)  반짝반짝, 고급스러움        투박함
UX(겪는 것)   탁탁 쳐도 안 나옴, 튐       뚜껑 열면 바로 나옴

→ UI = 화면의 생김새 (색, 글꼴, 버튼 모양, 배치)
→ UX = 그걸 쓰면서 겪는 전체 경험 (쉬운가? 빠른가? 짜증나는가?)

좋은 제품 = 예쁜데(UI) 쓰기도 편한(UX) 제품.
둘 중 하나만 좋으면 "예쁜 쓰레기" 또는 "못생긴 명작"이 됩니다.`;

const CODE_F_PATTERN = `사용자의 눈이 움직이는 길 — F패턴

■■■■■■■■■■■■■■■   ← ① 맨 윗줄은 끝까지 읽고
■■■■■■■■
■■■■■           ← ② 그 아래는 점점 짧게 훑다가
■■■
■■              ← ③ 왼쪽 가장자리만 쭉 내려가며 스캔
■

→ 눈길 모양이 알파벳 F를 닮았다고 해서 F패턴.
→ 결론: 중요한 것일수록 '위쪽·왼쪽·크게' 둬야 합니다.`;

const CODE_HIERARCHY = `우리 학습 플랫폼 대시보드의 시각적 위계 (눈이 가는 순서)

1순위  [ 72% ]        ← 제일 크고 진한 진행률 숫자
2순위  [과제] [코스] [공지]   ← 그다음 크기의 탭
3순위  · 과제 목록 항목들     ← 작고 촘촘한 텍스트

왜 이 순서로 눈이 갈까?
→ 크기가 다르고(72%가 제일 큼), 굵기가 다르고, 여백으로 떨어져 있어서.
→ 디자이너가 "이 순서로 봐 주세요"라고 화면에 써 둔 무언의 안내입니다.`;

const CODE_FIVE_STATES = `버튼·화면이 가져야 하는 5가지 상태 (티켓 풀 FE-01·FE-02와 연결!)

상태        예시                          없으면 생기는 일
──────────────────────────────────────────────────────────
로딩       "제출 중..." + 버튼 잠금        연타 → 중복 제출 사고
성공       "제출 완료!" 초록 메시지        됐는지 몰라서 또 누름
실패       "제출 실패: 다시 시도해 주세요"   조용히 실패 → 사용자는 낸 줄 앎
빈 상태    "아직 과제가 없어요"            버그인지 원래 없는 건지 헷갈림
비활성     회색 버튼 + 못 누름             마감 지났는데 눌러서 에러`;

const CODE_SUBMIT_BUTTON = `우리 과제 제출 버튼 해부 — 이런 코드가 상태를 만듭니다

<button disabled={submitting}>
  {submitting ? '제출 중...' : '제출하기'}
</button>

submitting이 true인 동안:
1) 글자가 "제출 중..."으로 바뀜   → 사용자에게 "일하는 중" 신호
2) disabled로 잠김               → 연타로 두 번 제출되는 사고 방지

버튼 하나에 UX 두 가지(피드백 + 실수 방지)가 들어 있어요.`;

const CODE_COLOR_ROLES = `색은 장식이 아니라 정보 — 색마다 맡은 역할이 있어요

색          역할                우리 플랫폼 예시
────────────────────────────────────────────────
파랑        행동 (눌러도 됨)      제출하기, 저장 버튼, 링크
빨강        위험 · 오류          삭제 버튼, "제출 실패" 메시지
초록/청록    성공 · 완료          "제출 완료!", 완료 체크 표시
회색        비활성 · 보조         못 누르는 버튼, 부가 설명

규칙 하나: 같은 색 = 같은 의미.
빨강을 오늘은 '삭제'에, 내일은 '추천'에 쓰면 색의 언어가 무너집니다.`;

const CODE_SPACING = `여백은 낭비가 아니라 그룹핑 — 근접성의 법칙

나쁜 예 (전부 같은 간격)          좋은 예 (관련 있는 것끼리 붙임)

제목                            제목
설명                            설명
                                          ← 큰 여백 = "여기서 단락 바뀜"
버튼A                           버튼A  버튼B   ← 붙어 있음 = 한 세트
버튼B
라벨                                      ← 큰 여백
입력칸                          라벨
                                입력칸   ← 라벨과 입력칸은 한 몸

→ 가까이 있는 것은 관련 있어 보인다. 이게 근접성(proximity)입니다.
→ 그리고 왼쪽 정렬선 하나만 맞춰도 화면이 갑자기 정돈돼 보여요.`;

const CODE_HEURISTICS = `니엘슨 사용성 어림법(휴리스틱) — 10개 중 오늘은 5개만

어림법              쉬운 말               우리 플랫폼에서는?
─────────────────────────────────────────────────────────────
① 시스템 상태 보여주기  "지금 뭐 하는 중인지 말해줘"  "제출 중..." 로딩 표시
② 사용자의 언어        "개발자 말고 사람 말로"       "Error 500" 대신
                                            "잠시 후 다시 시도해 주세요"
③ 실수 방지           "사고 나기 전에 막아줘"       삭제 전 "정말 삭제할까요?"
                                            확인창, 마감 후 버튼 비활성
④ 일관성             "같은 건 같게 생겨라"        모든 페이지가 같은
                                            step-card·버튼 스타일
⑤ 미니멀리즘          "필요 없는 건 빼라"          대시보드 첫 화면엔
                                            진행률·과제만 (설정은 뒤로)`;

const CODE_CRITIQUE = `화면 비평 연습장 — 이대로 채워서 멘토에게 보여 주세요

고른 화면: (예: 대시보드 / 과제 제출 페이지 / 로그인 화면)

[좋은 점 3가지] — 오늘 배운 용어로!
1. 예) 진행률 숫자가 제일 커서 시각적 위계가 명확하다 (섹션 2)
2.
3.

[아쉬운 점 3가지] — "왜" 아쉬운지 근거까지
1. 예) 제출 버튼과 삭제 버튼이 같은 색이라 색의 역할이 겹친다 (섹션 5)
2.
3.

→ 아쉬운 점에는 반드시 근거(어느 섹션의 어떤 원칙?)를 붙이세요.
  "그냥 별로예요"는 비평이 아니라 투정입니다.
→ 근거 있는 아쉬운 점은 그대로 디자인 티켓(DZ-02)이 됩니다!`;

// ── 이 페이지 안에서만 쓰는 작은 부품들 ──
// 학습 포인트: 같은 모양이 반복되면 컴포넌트로 뽑는다. 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: 'UI vs UX' },
  { n: 2, label: '스캔과 위계' },
  { n: 3, label: '일관성' },
  { n: 4, label: '피드백과 상태' },
  { n: 5, label: '색의 역할' },
  { n: 6, label: '여백과 정렬' },
  { n: 7, label: '사용성 어림법' },
  { n: 8, label: '화면 비평' },
];

export default function UiUxPage() {
  return (
    <div>
      {/* 히어로: 이 코스가 누구를 위한 것이고 무엇을 얻어 가는지 */}
      <div className="hero">
        <div className="eyebrow">Course · 디자인</div>
        <h1>UI/UX 기초<br />— 쓰기 좋은 화면의 비밀</h1>
        <p>
          "이 화면 뭔가 불편한데 왜인지 모르겠어" — 그 <strong>왜</strong>를 말로 설명할 수
          있게 되는 코스예요. 디자인 수습생은 물론, 화면을 직접 만드는 개발 수습생에게도
          필수입니다. 각 섹션의 <strong>"직접 확인해 보기"</strong>는 우리 플랫폼의 진짜
          화면과 코드로 해 보세요 — 남의 앱 비평보다 내가 만들 앱 비평이 백배 남습니다.
        </p>
        <div className="chip-row">
          <span className="chip">예상 소요 60분</span>
          <span className="chip">개발자도 필수</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="UI와 UX는 다르다" sub="보이는 것과 겪는 것">
        <p>
          <strong>UI</strong>(User Interface)는 화면에 <strong>보이는 것</strong> — 색, 글꼴,
          버튼 모양, 배치예요. <strong>UX</strong>(User Experience)는 그걸 쓰면서{' '}
          <strong>겪는 것</strong> — 쉬운지, 빠른지, 짜증 나는지의 전체 경험이고요.
          케첩병이 딱 좋은 비유입니다.
        </p>
        <Code>{CODE_UI_VS_UX}</Code>
        <p>
          유리병은 식탁 위에서 예쁘지만(UI 승) 케첩이 안 나와서 바닥을 탁탁 쳐야 하죠(UX 패).
          거꾸로 세워 두는 플라스틱병은 투박하지만 뚜껑만 열면 바로 나옵니다.
          <strong> 좋은 제품은 둘 다</strong>를 잡아요 — 예쁜데 편하기까지 한 것.
          그리고 둘이 충돌하면, 대부분의 경우 <strong>편함(UX)이 이겨야</strong> 합니다.
        </p>
        <div className="tip">
          <b>직접 확인해 보기</b> 오늘 쓴 앱 중에서 "예쁜데 불편한 것" 하나,
          "안 예쁜데 편한 것" 하나를 찾아 보세요. 그리고 우리 학습 플랫폼은
          어느 쪽에 가까운지 첫인상을 메모해 두세요 — 섹션 8에서 그 메모가 재료가 됩니다.
        </div>
      </Section>

      <Section n={2} title="사용자는 읽지 않는다 — 스캔한다" sub="F패턴과 시각적 위계">
        <p>
          충격적인 사실: 사용자는 화면의 글을 <strong>읽지 않아요</strong>. 시험지 훑듯이{' '}
          <strong>스캔</strong>합니다. 눈길이 움직이는 대표적인 모양이 <strong>F패턴</strong>이에요.
        </p>
        <Code>{CODE_F_PATTERN}</Code>
        <svg className="diagram" viewBox="0 0 640 360" xmlns="http://www.w3.org/2000/svg" role="img" aria-label="화면 위를 눈이 F자로 훑는 경로 도해. 제목에서 시작해 맨 윗줄을 끝까지 가로로 읽고, 그 아래를 짧게 훑은 뒤 왼쪽 가장자리를 세로로 스캔한다.">
          <rect x="40" y="30" width="360" height="300" rx="8" fill="var(--card)" stroke="var(--line)" />
          <rect x="60" y="52" width="240" height="18" rx="8" fill="var(--ink)" opacity="0.75" />
          <rect x="60" y="96" width="320" height="10" rx="8" fill="var(--muted)" opacity="0.45" />
          <rect x="60" y="116" width="300" height="10" rx="8" fill="var(--muted)" opacity="0.45" />
          <rect x="60" y="156" width="200" height="10" rx="8" fill="var(--muted)" opacity="0.45" />
          <rect x="60" y="176" width="170" height="10" rx="8" fill="var(--muted)" opacity="0.45" />
          <rect x="60" y="216" width="90" height="10" rx="8" fill="var(--muted)" opacity="0.3" />
          <rect x="60" y="246" width="80" height="10" rx="8" fill="var(--muted)" opacity="0.3" />
          <rect x="60" y="276" width="70" height="10" rx="8" fill="var(--muted)" opacity="0.3" />
          <rect x="60" y="306" width="60" height="10" rx="8" fill="var(--muted)" opacity="0.3" />
          <polyline points="66,61 300,61 66,61 66,101 380,101 66,101 66,161 260,161 66,161 66,310" fill="none" stroke="var(--primary)" strokeWidth="2.5" strokeLinecap="round" />
          <circle cx="66" cy="61" r="6" fill="var(--primary)" />
          <circle cx="66" cy="310" r="6" fill="var(--rose)" />
          <text x="308" y="66" fontSize="12.5" fill="var(--primary)">① 제목</text>
          <text x="390" y="105" fontSize="12.5" fill="var(--primary)">② 가로 스캔</text>
          <text x="270" y="165" fontSize="12.5" fill="var(--primary)">③ 점점 짧게</text>
          <text x="82" y="336" fontSize="12.5" fill="var(--rose)">④ 왼쪽 세로 스캔</text>
          <line x1="40" y1="30" x2="40" y2="330" stroke="var(--teal)" strokeWidth="3" />
          <line x1="40" y1="30" x2="400" y2="30" stroke="var(--teal)" strokeWidth="3" />
          <text x="430" y="60" fontSize="14" fontWeight="600" fill="var(--ink)">눈길이 그리는 F</text>
          <text x="430" y="88" fontSize="12.5" fill="var(--muted)">청록 = 눈이 가장 오래</text>
          <text x="430" y="106" fontSize="12.5" fill="var(--muted)">머무는 위·왼쪽 띠</text>
          <rect x="430" y="130" width="176" height="52" rx="8" fill="var(--card)" stroke="var(--amber)" />
          <text x="444" y="152" fontSize="12.5" fill="var(--ink)">여기 = 중요한 것</text>
          <text x="444" y="171" fontSize="12.5" fill="var(--muted)">제목 · 진행률 · 주요 버튼</text>
          <rect x="430" y="240" width="176" height="52" rx="8" fill="var(--card)" stroke="var(--line)" strokeDasharray="5 4" />
          <text x="444" y="262" fontSize="12.5" fill="var(--muted)">오른쪽 아래 = 거의 안 봄</text>
          <text x="444" y="281" fontSize="12.5" fill="var(--muted)">놓쳐도 되는 것만</text>
          <line x1="412" y1="200" x2="412" y2="232" stroke="var(--line)" strokeWidth="2" strokeDasharray="4 4" />
        </svg>
        <p className="muted" style={{ fontSize: 12.5, textAlign: 'center', marginTop: 2 }}>그림: 제목 → 가로 스캔 → 점점 짧게 → 왼쪽 세로 스캔. 그래서 중요한 것은 위·왼쪽에.</p>
        <p>
          그래서 화면에는 <strong>시각적 위계</strong>(visual hierarchy)가 필요해요 —
          중요한 것부터 눈에 들어오도록 <strong>크기·굵기·색·위치</strong>로 순서를 매기는 것.
          신문 1면을 떠올려 보세요. 제일 큰 헤드라인 → 중간 제목 → 본문 순서로
          자연스럽게 눈이 가죠. 그건 우연이 아니라 설계입니다.
        </p>
        <Code>{CODE_HIERARCHY}</Code>
        <div className="tip">
          <b>직접 확인해 보기</b> 우리 플랫폼 대시보드를 열고 3초만 보고 눈을 감아 보세요.
          뭐가 기억나나요? 아마 큰 진행률 숫자일 거예요. 그다음 다시 열어서
          내 눈이 <strong>어떤 순서로</strong> 움직이는지 관찰해 보세요 —
          큰 숫자 → 탭 → 목록. 그 순서를 만든 게 크기·굵기·여백입니다.
        </div>
      </Section>

      <Section n={3} title="일관성 — 같은 것은 같게" sub="디자인 시스템이라는 약속">
        <p>
          파란 버튼이 이 페이지에서는 '저장'인데 저 페이지에서는 모양도 색도 다르다면?
          사용자는 페이지마다 <strong>사용법을 다시 배워야</strong> 해요. 반대로 모든 화면에서
          버튼·카드·경고창이 같은 모양이면, 한 번 배운 걸 어디서든 써먹을 수 있죠.
          이게 <strong>일관성</strong>입니다. 학교의 모든 교실 문손잡이가 같은 방식으로
          열리는 것과 같아요 — 아무도 그걸 '배웠다'고 느끼지 않지만, 다 다르면 매일 고생합니다.
        </p>
        <p>
          이 약속을 문서와 코드로 정리한 게 <strong>디자인 시스템</strong>이에요.
          "우리 서비스의 버튼은 이 색·이 크기, 경고는 이 모양" 하고 부품을 정해 두고
          모든 화면이 그 부품만 조립해서 쓰는 거죠. 거창하게 들리지만 —
        </p>
        <div className="tip">
          <b>직접 확인해 보기</b> 우리 프로젝트의{' '}
          <span className="icode">frontend/src/styles/global.css</span>를 열어 보세요.
          지금 보고 있는 이 페이지의 <span className="icode">step-card</span>,{' '}
          <span className="icode">tip</span>, <span className="icode">chip</span> 클래스가
          거기 있어요. 네트워크 코스도, 이 코스도 <strong>같은 클래스</strong>를 씁니다 —
          이게 바로 우리의 <strong>미니 디자인 시스템</strong>이에요. 새 페이지를 만들 때
          CSS를 새로 짜지 않고 이 부품을 재사용하는 것, 그게 일관성을 지키는 방법입니다.
        </div>
        <div className="warn">
          <b>흔한 실수</b> "이 페이지만 특별하니까 버튼 색을 살짝 다르게..." — 그 '살짝'이
          쌓이면 화면마다 다른 앱처럼 보여요. 다르게 만들고 싶다면 먼저 물어볼 것:
          <strong> 정말 의미가 다른가?</strong> 의미가 같으면 모양도 같아야 합니다.
        </div>
      </Section>

      <Section n={4} title="피드백과 상태 — 눌렀으면 반응이 있어야 한다" sub="화면의 5가지 상태">
        <p>
          엘리베이터 버튼을 눌렀는데 불이 안 들어오면? 또 누르고, 또 누르죠.
          화면도 똑같아요. 사용자가 뭔가 하면 <strong>즉시 반응</strong>이 있어야 하고,
          화면은 지금 상태를 늘 말해 줘야 합니다. 잘 만든 화면은 다음 5가지 상태를
          전부 준비해 둬요.
        </p>
        <Code>{CODE_FIVE_STATES}</Code>
        <p>
          개발 수습생이라면 티켓 풀의 <strong>FE-01(로딩 상태)·FE-02(빈 상태)</strong>가
          정확히 이 이야기예요. 우리 과제 제출 버튼을 해부해 보면 이렇게 생겼습니다.
        </p>
        <Code>{CODE_SUBMIT_BUTTON}</Code>
        <div className="tip">
          <b>직접 확인해 보기</b> 우리 플랫폼에서 과제를 하나 제출해 보면서 관찰하세요.
          버튼이 <strong>"제출 중..."</strong>으로 바뀌는 순간, 성공 메시지가 뜨는 순간을
          눈으로 확인! 그리고 과제가 하나도 없는 계정 화면(빈 상태)은 어떻게 생겼는지도
          찾아 보세요. 5가지 상태 중 우리 플랫폼에 <strong>빠진 상태</strong>가 있다면 —
          축하해요, 방금 개선 티켓 하나를 발견한 겁니다.
        </div>
      </Section>

      <Section n={5} title="색의 역할" sub="색은 장식이 아니라 정보다">
        <p>
          신호등을 생각해 보세요. 빨강=멈춤, 초록=가도 됨 — 색 자체가 <strong>정보</strong>죠.
          화면의 색도 똑같이 역할이 정해져 있어요.
        </p>
        <Code>{CODE_COLOR_ROLES}</Code>
        <p>
          두 가지를 더 챙겨야 해요. 첫째, <strong>명도 대비</strong> — 연회색 바탕에 흰 글씨처럼
          바탕과 글자의 밝기 차이가 작으면 읽기 힘들어요. 예쁜 색이어도 <strong>읽히지 않으면
          탈락</strong>입니다. 둘째, <strong>접근성</strong> — 색약인 사용자는 빨강과 초록을
          구분하기 어려울 수 있어요. 그래서 색 <strong>하나에만</strong> 의존하면 안 되고,
          "실패"라는 <strong>글자</strong>나 아이콘을 함께 줘야 합니다.
          신호등도 색만이 아니라 <strong>위치</strong>(위=빨강)로 한 번 더 알려 주잖아요.
        </p>
        <div className="tip">
          <b>직접 확인해 보기</b> 우리 플랫폼에서 파란 요소만 골라 세어 보세요 —
          전부 '누르면 뭔가 일어나는 것'인가요? 만약 눌리지도 않는 것이 파랗다면,
          색의 언어를 어기고 있는 거예요. 그리고 화면 밝기를 최저로 낮춰서
          여전히 다 읽히는지도 확인해 보세요 (간이 명도 대비 테스트!).
        </div>
      </Section>

      <Section n={6} title="여백과 정렬" sub="여백은 낭비가 아니라 그룹핑이다">
        <p>
          초보가 가장 많이 하는 실수: "빈 데가 아까우니까 뭘 더 채우자."
          하지만 여백은 낭비가 아니라 <strong>정보를 묶어 주는 도구</strong>예요.
          사람 눈은 <strong>가까이 있는 것들을 한 덩어리로</strong> 봅니다 —
          이걸 <strong>근접성</strong>(proximity)이라고 해요. 문장 사이 띄어쓰기가 없으면
          못읽는것과같은원리예요. 방금 불편했죠? 그게 여백의 힘입니다.
        </p>
        <Code>{CODE_SPACING}</Code>
        <p>
          <strong>정렬</strong>은 여백의 단짝이에요. 요소들의 왼쪽 끝을 가상의 세로선 하나에
          맞추기만 해도 화면이 갑자기 정돈돼 보입니다. 공책에 줄이 있으면 글씨가
          가지런해 보이는 것과 같아요. 들쭉날쭉한 화면의 범인은 대부분
          "정렬선이 여러 개"인 경우입니다.
        </p>
        <div className="tip">
          <b>직접 확인해 보기</b> 지금 이 페이지에서 <span className="kbd">F12</span> 개발자
          도구를 열고, 이 카드(<span className="icode">step-card</span>)에 마우스를 올려
          보세요. 파란색(콘텐츠)과 초록/주황색(패딩·마진)이 표시돼요 —
          카드 안쪽의 그 투명한 띠가 전부 <strong>일부러 설계된 여백</strong>입니다.
          제목과 본문, 카드와 카드 사이의 간격이 서로 다른 것도 관찰해 보세요.
          간격의 크기 차이가 곧 "얼마나 가까운 사이인지"의 표현이에요.
        </div>
      </Section>

      <Section n={7} title="사용성 어림법" sub="니엘슨 휴리스틱, 오늘은 5개만">
        <p>
          UX 학자 제이콥 니엘슨이 정리한 <strong>사용성 어림법(휴리스틱) 10가지</strong>는
          화면을 평가하는 체크리스트로 전 세계에서 쓰여요. 오늘은 그중 우리에게 가장
          자주 필요한 5개만, 우리 플랫폼 사례와 짝지어 봅니다.
        </p>
        <Code>{CODE_HEURISTICS}</Code>
        <p>
          눈치챘겠지만 ①은 섹션 4(피드백), ③도 섹션 4(제출 버튼 잠금), ④는 섹션 3(일관성)에서
          이미 배운 내용이에요. 휴리스틱은 새로운 지식이 아니라, 오늘 배운 것들에
          <strong> 이름표를 붙여 체크리스트로</strong> 만든 것에 가깝습니다.
        </p>
        <div className="tip">
          <b>직접 확인해 보기</b> 우리 플랫폼에서 일부러 틀려 보세요 — 로그인할 때 비밀번호를
          틀리게 넣거나, 필수 입력칸을 비우고 제출해 보기. 그때 뜨는 메시지가
          ② <strong>사용자의 언어</strong>인가요, 개발자의 언어(에러 코드)인가요?
          사람 말로 "무엇이 잘못됐고 어떻게 하면 되는지" 알려 주면 합격입니다.
        </div>
      </Section>

      <Section n={8} title="직접 해보기: 화면 비평" sub="좋은 점 3, 아쉬운 점 3 — 배운 용어로">
        <p>
          이제 오늘 배운 걸 전부 꺼내 쓸 시간이에요. 우리 플랫폼의 화면 <strong>하나</strong>를
          골라(대시보드, 과제 제출, 로그인 — 뭐든 좋아요) 아래 틀대로 비평을 써 보세요.
          핵심 규칙은 하나: <strong>느낌이 아니라 용어로</strong> 말하기.
          "왠지 답답해요" 대신 "여백이 부족해서 그룹핑이 안 보여요(섹션 6)"처럼요.
        </p>
        <Code>{CODE_CRITIQUE}</Code>
        <div className="warn">
          <b>비평의 예의</b> 비평은 화면을 향하는 것이지, 만든 사람을 향하는 게 아니에요.
          "이 버튼은 위계가 약하다"는 비평, "누가 이렇게 만들었냐"는 공격.
          여러분이 만든 화면도 곧 누군가의 비평 대상이 됩니다 — 받고 싶은 방식으로 하세요.
        </div>
        <div className="tip">
          <b>이 실습이 진짜인 이유</b> 여기서 나온 근거 있는 아쉬운 점은 그대로
          디자인 티켓 <strong>DZ-02</strong>의 재료가 돼요. 수습 기간에 여러분의 비평이
          실제 서비스 개선으로 배포될 수 있다는 뜻입니다. 멘토에게 비평을 보여 주고,
          함께 티켓으로 다듬어 보세요.
        </div>
      </Section>

      <div className="step-card">
        <div className="step-body">
          <h3 style={{ marginBottom: 6 }}>🎨 여기까지 왔다면</h3>
          <p className="muted">
            이제 "뭔가 불편해"를 <strong>용어와 근거</strong>로 말할 수 있게 됐어요.
            다음은 그 비평을 <strong>시안으로 만들 차례</strong> —{' '}
            <Link to="/learn/figma"><strong>피그마 기초</strong></Link> 코스에서
            섹션 8의 아쉬운 점을 직접 고친 화면을 그려 보세요. 말로 하는 비평보다
            그림으로 보여 주는 개선안이 백배 힘이 셉니다.
          </p>
        </div>
      </div>
    </div>
  );
}
