// 이 파일이 하는 일: "사용자 리서치 기초" 코스 — "내 감"이 아니라 진짜 사용자에게
// 묻고·지켜보는 방법을 7개 섹션으로 안내하는 정적 학습 페이지.
// (감 vs 사용자 → 인터뷰 기본기 → 관찰의 힘 → 페르소나 → 사용성 테스트 → 설문의 함정 → 실전 실습)
// 학습 포인트: API 호출이 없는 '내용 고정' 페이지다. 스타일은 global.css의
// 가이드 전용 클래스(step-card, code-block, tip 등)를 재사용한다 — 색을 여기서 하드코딩하지 않는다.
// 인터뷰 대본·체크리스트 같은 텍스트 자료는 JSX 중괄호/백틱 충돌을 피하려고
// 파일 상단의 백틱 문자열 상수로 정의한다.

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

// ── 텍스트 자료 상수들 ──

const CODE_GUT_VS_USER = `"내 감"과 "사용자의 현실"이 어긋난 (아주 흔한) 예

만든 사람의 생각                 실제 사용자
──────────────────────────   ──────────────────────────
"버튼이 딱 보이는데?"           스크롤을 안 내려서 버튼을 못 봄
"이 기능 다들 좋아할걸?"        존재 자체를 모름 (메뉴 못 찾음)
"용어가 직관적이잖아"           '커밋'이 뭔지 몰라서 멈춤
"3단계면 금방 하지"             2단계에서 뒤로가기 누르고 이탈

→ 만든 사람은 이미 답을 알고 화면을 봐요.
  처음 보는 사람의 눈은 "직접 물어보고 지켜봐야만" 얻을 수 있습니다.`;

const CODE_INTERVIEW_DO_DONT = `유도 질문 vs 열린 질문 — 한 끗 차이가 답을 바꿔요

나쁜 질문 (유도 질문)              좋은 질문 (열린 질문)
──────────────────────────    ──────────────────────────
"이 기능 편리하죠?"              "이 기능을 언제 마지막으로 썼어요?"
"검색이 빨라서 좋지 않아요?"      "원하는 걸 찾을 때 어떻게 하세요?"
"이 디자인 예쁘죠?"              "이 화면에서 처음 눈이 간 곳은요?"
"이런 기능 있으면 쓸 거죠?"       "지금은 그 문제를 어떻게 해결해요?"

규칙 1: "네/아니오"로 끝나는 질문을 피하기 → 이야기가 안 나와요
규칙 2: 미래("쓸 건가요?")보다 과거("써 봤나요?")를 묻기
         → 사람은 미래의 자신을 과대평가합니다
규칙 3: 내가 듣고 싶은 답을 질문에 심지 않기 ("편리하죠?" 금지)`;

const CODE_FIVE_WHYS = `"왜?"를 다섯 번 — 표면의 불만에서 진짜 원인까지 파고들기

수습생: "과제 제출 페이지가 불편해요."
왜?  → "제출했는지 안 했는지 헷갈려서요."
왜?  → "제출 버튼을 눌러도 화면이 그대로거든요."
왜 헷갈리죠? → "성공 메시지가 안 보여요."
왜 안 보일까요? → "메시지가 화면 맨 위에 뜨는데, 전 맨 아래를 보고 있어서요."
왜 맨 아래를 보고 있었어요? → "제출 버튼이 맨 아래에 있으니까요!"

표면: "페이지가 불편해요" (여기서 멈추면 뭘 고쳐야 할지 모름)
진짜 원인: 성공 메시지가 사용자의 시선과 다른 곳에 뜸
해결: 버튼 바로 옆에 성공 표시 → 명확한 수리 포인트!

주의: 취조하듯 "왜? 왜? 왜?"라고 다그치면 안 돼요.
"조금 더 자세히 말해 줄래요?" "그때 어떤 기분이었어요?"처럼
표현을 바꿔 가며 부드럽게 파고드는 게 기술입니다.`;

const CODE_SAY_VS_DO = `말과 행동은 다르다 — 같은 사람, 다른 데이터

인터뷰에서 한 말                  옆에서 지켜본 행동
──────────────────────────    ──────────────────────────
"검색 기능 잘 써요"              검색창 대신 메뉴만 5번 클릭
"매뉴얼 읽고 시작해요"           매뉴얼 안 열고 바로 버튼부터 누름
"에러 메시지 꼼꼼히 읽어요"      에러 창이 뜨자마자 0.5초 만에 닫음
"단축키 애용해요"                마우스로만 조작 (Ctrl+S도 안 씀)

거짓말이 아니에요 — 사람은 자기가 '그랬으면 하는 모습'으로
자신을 기억해요. 그래서 리서치는 두 발로 서야 합니다:
한 발 = 묻기(인터뷰), 다른 발 = 지켜보기(관찰).`;

const CODE_PERSONA = `페르소나 예시 — 우리 학습 플랫폼의 대표 사용자

┌─────────────────────────────────────────────┐
│  김미림 (18) — AWESOMEDEV 신입 수습생          │
├─────────────────────────────────────────────┤
│ 배경   미림마이스터고 3학년. HTML/CSS는 해봤지만  │
│        Git·서버·배포는 이번이 처음.              │
│ 목표   과제를 기한 안에 제출하고, 코드 리뷰에서   │
│        "잘했다"는 말을 듣고 싶다.               │
│ 불안   "질문하면 바보 같아 보일까 봐" 검색으로    │
│        30분을 헤맨 뒤에야 멘토에게 물어본다.      │
│ 환경   학교 PC(Windows) + 집 노트북, 폰으로도    │
│        학습 페이지를 자주 열어 본다.             │
├─────────────────────────────────────────────┤
│ → 이 카드가 있으면 회의에서 이렇게 말할 수 있어요: │
│   "그 용어, 미림이가 알아들을까?"                │
│   "미림이는 폰으로도 보는데 이 표가 잘리진 않을까?"│
└─────────────────────────────────────────────┘

페르소나 = 리서치에서 만난 여러 실제 사용자의 공통점을
한 명의 '대표 인물'로 뭉친 카드. 상상으로 지어내면 소설이 되고,
리서치 데이터로 만들면 나침반이 됩니다.`;

const CODE_USABILITY_MINI = `5분 미니 사용성 테스트 — 진행 순서

준비 (1분)
  · 과제 1개를 정한다. 예) "학습 센터에서 네트워크 코스를 찾아
    섹션 5(DNS)로 이동해 보세요."
  · 관찰 기록용 메모장을 연다.

진행 (3분)
  1. 과제를 '목표'로만 말한다 — 방법을 알려주면 반칙!
     ○ "네트워크 코스의 DNS 섹션을 찾아가 보세요"
     ✕ "위 메뉴에서 학습 센터 누르고, 목록에서..."
  2. "생각을 소리 내어 말해 주세요"라고 부탁한다.
     ("음... 메뉴가 어디지... 이건가?" ← 이게 전부 데이터!)
  3. 입을 꾹 다물고 지켜본다. 헤매도 3분간은 돕지 않는다.
     (도와주고 싶어 손이 근질거리는 그 순간이 바로 발견의 순간)

정리 (1분)
  · 어디서 멈칫했나? 어디서 잘못 눌렀나? 뭐라고 중얼거렸나?
  · "감사합니다!" — 테스트당한 건 사람이 아니라 화면이라는 걸
    꼭 말해 주세요. 참가자는 언제나 옳습니다.`;

const CODE_SURVEY_TRAPS = `설문의 함정 3종 세트

함정 1 — 유도하는 문항
  ✕ "새로워진 편리한 검색 기능에 만족하시나요?"
     ('편리한'이라는 답을 문제에 심어 놨어요)
  ○ "검색 기능 사용 경험은 어땠나요? (매우 불만족~매우 만족)"

함정 2 — 응답자 쏠림 (표본 편향)
  플랫폼을 좋아하는 사람일수록 설문에 잘 응해요.
  "만족도 90%!"가 사실은 "설문에 답해 준 팬들의 만족도 90%"일 수 있죠.
  → 응답 안 한 사람들은 어떤 사람일지 항상 의심하기.

함정 3 — 숫자만 있고 이유가 없음
  "만족도 2점"이 나와도 설문만으론 '왜'를 몰라요.
  → 마지막에 주관식 한 칸: "가장 불편했던 순간을 적어 주세요."
    점수(무엇)는 설문이, 이유(왜)는 인터뷰가 잘합니다.`;

const CODE_FIELD_NOTE = `실습 기록 템플릿 — 그대로 베껴서 채우면 됩니다

■ 5분 사용성 테스트 기록
  날짜/참가자: 7/16, 동기 수습생 ○○
  과제: "학습 센터에서 ___ 코스를 찾아 ___ 해 보세요"

  발견 1
    본 것: 메인에서 학습 센터 메뉴를 찾는 데 40초 걸림 (푸터까지 스크롤)
    들은 것: "메뉴 이름이 '학습 센터'인지 '코스'인지 헷갈려요"
    내 해석: 메뉴 라벨이 기대와 다를 수 있음 → 라벨 검토 제안

  발견 2
    본 것: 코스 페이지에서 pill-nav를 안 누르고 계속 스크롤만 함
    들은 것: (아무 말 없이 지나침)
    내 해석: 바로가기 내비게이션의 존재를 인지 못함

  발견 3
    본 것 / 들은 것 / 내 해석: ...

규칙: '본 것·들은 것'(사실)과 '내 해석'(의견)을 반드시 분리!
사실은 나중에 봐도 사실이지만, 해석은 틀릴 수 있으니까요.`;

// ── 이 페이지 안에서만 쓰는 작은 부품들 ──
// 학습 포인트: 같은 모양이 반복되면 컴포넌트로 뽑는다. 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: '관찰의 힘' },
  { n: 4, label: '페르소나 맛보기' },
  { n: 5, label: '사용성 테스트' },
  { n: 6, label: '설문의 함정' },
  { n: 7, label: '실전 실습' },
];

export default function UserResearchPage() {
  return (
    <div>
      {/* 히어로: 이 코스가 무엇을 바꿔 주는지 */}
      <div className="hero">
        <div className="eyebrow">Course · 디자인</div>
        <h1>사용자 리서치 기초<br />— "내 감"을 내려놓고 사용자에게 묻기</h1>
        <p>
          좋은 제품은 만든 사람의 감이 아니라 <strong>사용자의 입과 손</strong>에서
          나옵니다. 이 코스에서는 인터뷰로 묻고, 관찰로 확인하고, 5분짜리 사용성
          테스트까지 직접 해 봐요 — 실습 상대는 바로 옆자리 동료 수습생입니다.
        </p>
        <div className="chip-row">
          <span className="chip">예상 소요 50분</span>
          <span className="chip">실습 2개 + 미니 테스트</span>
          <span className="chip">준비물: 동료 수습생 1명</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>
          내가 만든 화면은 나에게 <strong>절대 낯설 수 없어요</strong>. 버튼이 어디 있는지,
          다음에 뭘 눌러야 하는지 전부 알고 보니까요. 자기 방 불을 끄고도 침대까지
          걸어갈 수 있는 것과 같죠 — 하지만 처음 온 손님은 문턱에 발가락을 찧습니다.
          사용자는 언제나 <strong>불 꺼진 방에 처음 들어온 손님</strong>이에요.
        </p>
        <Code>{CODE_GUT_VS_USER}</Code>
        <p>
          그래서 리서치의 첫 마음가짐은 이거예요: <strong>"나는 사용자가 아니다."</strong>
          우리 회사에서도 마찬가지 — 이 학습 플랫폼을 만드는 사람(멘토·개발자)과
          쓰는 사람(수습생)은 아는 것도, 익숙한 용어도 달라요. 그 틈을 메우는 유일한
          방법이 <strong>직접 묻고 지켜보는 것</strong>, 즉 사용자 리서치입니다.
        </p>
        <svg className="diagram" viewBox="0 0 640 360" xmlns="http://www.w3.org/2000/svg" role="img" aria-label="관찰에서 가설, 테스트, 배움을 거쳐 다시 관찰로 돌아오는 리서치 순환도">
          <circle cx="320" cy="180" r="110" fill="none" stroke="var(--line)" strokeWidth="1" strokeDasharray="4 5" />

          <path d="M 400 95 A 110 110 0 0 1 445 155" fill="none" stroke="var(--line)" strokeWidth="2" strokeLinecap="round" />
          <polygon points="445,155 433.8,148.4 441.8,142.4" fill="var(--line)" />
          <path d="M 445 205 A 110 110 0 0 1 400 265" fill="none" stroke="var(--line)" strokeWidth="2" strokeLinecap="round" />
          <polygon points="400,265 403.2,251.8 411.2,259" fill="var(--line)" />
          <path d="M 240 265 A 110 110 0 0 1 195 205" fill="none" stroke="var(--line)" strokeWidth="2" strokeLinecap="round" />
          <polygon points="195,205 206.2,211 198.2,218.2" fill="var(--line)" />
          <path d="M 195 155 A 110 110 0 0 1 240 95" fill="none" stroke="var(--line)" strokeWidth="2" strokeLinecap="round" />
          <polygon points="240,95 236.8,108.2 228.8,101" fill="var(--line)" />

          <rect x="252" y="46" width="136" height="48" rx="8" fill="var(--card)" stroke="var(--primary)" strokeWidth="2" />
          <text x="320" y="67" textAnchor="middle" fontSize="14" fontWeight="600" fill="var(--ink)">관찰</text>
          <text x="320" y="84" textAnchor="middle" fontSize="11.5" fill="var(--muted)">묻고 지켜보기</text>

          <rect x="362" y="156" width="136" height="48" rx="8" fill="var(--card)" stroke="var(--teal)" strokeWidth="2" />
          <text x="430" y="177" textAnchor="middle" fontSize="14" fontWeight="600" fill="var(--ink)">가설</text>
          <text x="430" y="194" textAnchor="middle" fontSize="11.5" fill="var(--muted)">아마 여기서 막힐 것</text>

          <rect x="252" y="266" width="136" height="48" rx="8" fill="var(--card)" stroke="var(--amber)" strokeWidth="2" />
          <text x="320" y="287" textAnchor="middle" fontSize="14" fontWeight="600" fill="var(--ink)">테스트</text>
          <text x="320" y="304" textAnchor="middle" fontSize="11.5" fill="var(--muted)">과제 주고 입 다물기</text>

          <rect x="142" y="156" width="136" height="48" rx="8" fill="var(--card)" stroke="var(--rose)" strokeWidth="2" />
          <text x="210" y="177" textAnchor="middle" fontSize="14" fontWeight="600" fill="var(--ink)">배움</text>
          <text x="210" y="194" textAnchor="middle" fontSize="11.5" fill="var(--muted)">사실과 해석 분리</text>

          <text x="320" y="174" textAnchor="middle" fontSize="13" fontWeight="600" fill="var(--ink)">내 감이 아니라</text>
          <text x="320" y="194" textAnchor="middle" fontSize="12" fill="var(--muted)">한 바퀴 돌 때마다 확신 대신 근거</text>

          <text x="320" y="340" textAnchor="middle" fontSize="12" fill="var(--muted)">배움은 끝이 아니라 다음 관찰의 출발점입니다</text>
        </svg>
        <p className="muted" style={{ fontSize: 12.5, textAlign: 'center', marginTop: 2 }}>그림: 리서치 순환도 — 관찰 → 가설 → 테스트 → 배움, 그리고 다시 관찰로</p>
        <div className="tip">
          <b>기억할 한 문장</b> 회의에서 "사용자들이 이걸 좋아할 거예요"라는 말이 나오면
          속으로 물어보세요 — <strong>"그건 물어본 결과인가요, 내 감인가요?"</strong>
          이 질문 하나가 리서처의 시작입니다.
        </div>
      </Section>

      <Section n={2} title="인터뷰 기본기" sub="유도 질문 금지, 그리고 '왜?'를 다섯 번">
        <p>
          인터뷰는 그냥 수다가 아니라 <strong>기술</strong>이에요. 제일 흔한 실수는
          내가 듣고 싶은 답을 질문에 심어 버리는 <strong>유도 질문</strong>입니다.
          "이거 편리하죠?"라고 물으면 대부분 "네..."라고 해요 — 면전에서 "별로예요"라고
          말하기는 어려우니까요. 이건 데이터가 아니라 <strong>예의</strong>를 수집한 겁니다.
        </p>
        <Code>{CODE_INTERVIEW_DO_DONT}</Code>
        <p>
          두 번째 기술은 <strong>"왜?"를 다섯 번</strong> 묻기예요. 사용자의 첫 대답은
          보통 표면의 불만("불편해요")이고, 진짜 원인은 몇 겹 아래에 숨어 있거든요.
          양파 껍질을 벗기듯 한 겹씩 파고들어야 <strong>고칠 수 있는 지점</strong>이 나옵니다.
        </p>
        <Code>{CODE_FIVE_WHYS}</Code>
        <div className="warn">
          <b>주의 — 인터뷰는 취조가 아니에요</b> "왜요? 왜요? 왜요?"를 기계처럼 반복하면
          상대는 심문받는 기분이 듭니다. "조금 더 얘기해 줄래요?", "그때 어땠어요?"처럼
          표현을 바꾸고, 상대의 침묵도 3초쯤 기다려 주세요 — 좋은 답은 침묵 뒤에 나와요.
        </div>
        <div className="tip">
          <b>직접 확인해 보기 ①</b> 옆자리 동료 수습생에게 5분만 빌려서 미니 인터뷰를
          해 보세요. 주제: <strong>"우리 학습 플랫폼에서 과제를 제출할 때의 경험"</strong>.
          규칙은 두 가지 — (1) "네/아니오"로 답할 수 있는 질문 금지,
          (2) 첫 대답에서 멈추지 말고 "왜?"를 최소 3번 파고들기.
          끝나면 <strong>몰랐던 사실 1개</strong>를 메모해 두세요. 반드시 하나는 나옵니다.
        </div>
      </Section>

      <Section n={3} title="관찰의 힘" sub="말과 행동은 다르다 — 그래서 지켜봐야 한다">
        <p>
          인터뷰만으로 충분하지 않은 이유가 있어요. 사람은 거짓말을 하려는 게 아니라,
          <strong> 자기 행동을 정확히 기억하지 못해요</strong>. "운동 자주 하세요?"라고
          물으면 "일주일에 세 번쯤요"라고 답하지만, 실제 기록을 보면 한 번인 경우가
          많은 것처럼요.
        </p>
        <Code>{CODE_SAY_VS_DO}</Code>
        <p>
          그래서 리서치의 황금 조합은 <strong>인터뷰(말) + 관찰(행동)</strong>입니다.
          말은 사용자의 <strong>생각과 기대</strong>를, 행동은 <strong>현실</strong>을
          보여줘요. 둘이 어긋나는 지점이 발견되면 — 축하해요, 거기가 바로
          제품이 고쳐져야 할 가장 값진 자리입니다.
        </p>
        <div className="tip">
          <b>관찰 연습</b> 오늘 동료가 플랫폼이나 Gitea(edu.awesomedevapp.com:3000)를 쓰는
          모습을 어깨너머로 1분만 지켜보세요(허락은 받고요!). 마우스가 헤매는 곳,
          한숨이 나오는 순간, 같은 버튼을 두 번 누르는 장면 — 본인은 불편하다고
          말한 적 없는 것들이 보이기 시작할 거예요.
        </div>
      </Section>

      <Section n={4} title="페르소나 맛보기" sub="우리 플랫폼의 페르소나 = 바로 여러분, 수습생!">
        <p>
          리서치를 하다 보면 사용자 이야기가 수십 개 쌓여요. 이걸 회의 때마다
          "그... 어떤 분이 그러셨는데..."라고 꺼내긴 어렵죠. 그래서 여러 실제 사용자의
          공통점을 <strong>한 명의 대표 인물 카드</strong>로 뭉칩니다 — 그게
          <strong> 페르소나</strong>예요. 반 전체 급식 취향을 조사해서
          "우리 반 대표 입맛" 한 장으로 정리하는 것과 같아요.
        </p>
        <Code>{CODE_PERSONA}</Code>
        <p>
          재미있는 사실: <strong>이 학습 플랫폼의 페르소나가 바로 여러분</strong>이에요.
          멘토들이 코스를 만들 때 "수습생이 이 용어를 알까?", "폰으로 봐도 표가 안 깨질까?"를
          기준으로 결정해요. 여러분이 지금 느끼는 편함과 불편함이 곧 이 플랫폼의
          리서치 데이터인 셈이죠.
        </p>
        <div className="warn">
          <b>페르소나의 함정</b> 리서치 없이 상상으로 만든 페르소나는 소설 속 인물일
          뿐이에요. "20대 여성, 커피를 좋아함" 같은 카드는 아무 결정도 도와주지 못합니다.
          <strong> 목표와 불안</strong>이 담겨야 진짜 페르소나예요 — 위 카드에서
          "질문하면 바보 같아 보일까 봐" 같은 줄이 결정을 바꾸는 부분입니다.
        </div>
      </Section>

      <Section n={5} title="사용성 테스트 미니 방법" sub="과제를 주고, 입을 다물고, 지켜보기">
        <p>
          사용성 테스트는 거창한 실험실이 필요 없어요. 핵심은 딱 세 가지 —
          <strong> 과제를 주고</strong>, <strong>입을 다물고</strong>,
          <strong> 지켜보는 것</strong>. 참가자 한 명, 5분이면 충분히 시작할 수 있습니다.
          운전면허 기능 시험과 비슷해요: "주차해 보세요"라고 과제만 주고 옆에서
          지켜보지, "핸들을 왼쪽으로 꺾으세요"라고 알려주지 않죠.
        </p>
        <Code>{CODE_USABILITY_MINI}</Code>
        <p>
          제일 어려운 건 <strong>침묵</strong>이에요. 참가자가 헤매면 도와주고 싶어서
          입이 근질근질하거든요. 하지만 도와주는 순간 그 테스트는 끝 — 실제 사용자
          옆에는 도와줄 사람이 없으니까요. 참가자가 막히는 그 순간이 버그 리포트보다
          귀한 <strong>발견</strong>입니다.
        </p>
        <div className="tip">
          <b>마법의 주문</b> 참가자가 "이거 맞아요?"라고 물으면 이렇게 답하세요 —
          <strong> "평소라면 어떻게 하실 것 같아요?"</strong> 답을 알려주지 않으면서도
          상대를 존중하는, 사용성 테스트 진행자의 필살기입니다.
        </div>
      </Section>

      <Section n={6} title="설문의 함정" sub="숫자는 쉽게 모이지만, 쉽게 거짓말한다">
        <p>
          설문은 매력적이에요 — 한 번에 수십 명의 답을 숫자로 받을 수 있으니까요.
          하지만 <strong>잘못 만든 설문은 잘못된 확신</strong>을 줍니다. 틀린 지도를
          들고 자신 있게 걷는 것보다는 지도가 없는 편이 나아요.
        </p>
        <Code>{CODE_SURVEY_TRAPS}</Code>
        <p>
          정리하면 — <strong>설문은 "무엇(what)"과 "얼마나(how many)"</strong>를 재는
          도구이고, <strong>"왜(why)"는 인터뷰와 관찰</strong>이 잘합니다. 설문 결과에서
          이상한 숫자를 발견하면, 그게 인터뷰 주제가 되는 거예요. 도구마다 잘하는 일이
          다릅니다 — 드라이버로 못을 박으려 하지 마세요.
        </p>
        <div className="tip">
          <b>직접 확인해 보기 ②</b> 설문 문항 고치기 연습. 아래 문항의 문제를 찾아
          열린 문항으로 고쳐 보세요 — <span className="icode">"새로 열린 알찬 학습 센터
          코스들이 도움이 되었나요? (네/아니오)"</span>. 힌트: 유도하는 형용사가 2개,
          네/아니오 강요가 1개 숨어 있어요. 고친 문항을 멘토에게 보여주고 피드백을 받아 보세요.
        </div>
      </Section>

      <Section n={7} title="실전 실습 — 5분 사용성 테스트" sub="동료 수습생 1명 + 발견 3개 기록하기">
        <p>
          이제 배운 걸 전부 합칠 시간이에요. 오늘 안에 <strong>동료 수습생 한 명</strong>을
          섭외해서, 우리 학습 플랫폼으로 <strong>5분 사용성 테스트</strong>를 진행하고
          <strong> 발견 3개</strong>를 기록하세요. 섹션 5의 진행 순서를 그대로 따라 하면 됩니다.
        </p>
        <ol className="olist">
          <li>과제 1개 정하기 — 상대가 아직 안 해본 일이면 더 좋아요. 예) "학습 센터에서
            네트워크 코스를 찾아 DNS 섹션으로 이동하기"</li>
          <li>과제를 <strong>목표로만</strong> 전달하고, "생각을 소리 내어 말해 달라"고 부탁하기</li>
          <li>3분간 입 다물고 관찰 — 멈칫한 곳, 잘못 누른 곳, 중얼거림을 메모</li>
          <li>끝나면 "왜?"를 2~3번 물어 진짜 원인 파기 (섹션 2의 기술!)</li>
          <li>아래 템플릿으로 발견 3개를 정리해 멘토에게 공유하기</li>
        </ol>
        <Code>{CODE_FIELD_NOTE}</Code>
        <div className="warn">
          <b>꼭 지키기</b> 기록에서 <strong>사실(본 것·들은 것)</strong>과
          <strong> 해석(내 생각)</strong>을 반드시 분리하세요. "메뉴를 40초간 못 찾음"은
          사실이고, "메뉴 이름이 나쁘다"는 해석이에요. 사실은 시간이 지나도 사실이지만,
          해석은 틀릴 수 있습니다 — 섞어 쓰면 나중에 뭐가 진짜였는지 알 수 없어요.
        </div>
        <div className="tip">
          <b>보너스</b> 여러분의 발견 3개는 진짜로 이 플랫폼을 좋게 만드는 데 쓰일 수
          있어요. 정리한 기록을 멘토에게 전달해 보세요 — 수습생의 리서치가 실제 개선으로
          이어지는 경험, 그게 이 실습의 진짜 목표입니다.
        </div>
      </Section>

      <div className="step-card">
        <div className="step-body">
          <h3 style={{ marginBottom: 6 }}>🔍 여기까지 왔다면</h3>
          <p className="muted">
            이제 "내 감"이 아니라 <strong>물어보고(인터뷰), 지켜보고(관찰),
            시켜보는(사용성 테스트)</strong> 방법을 알게 됐어요. 사용자를 이해했으니
            다음은 그 이해를 화면으로 옮길 차례 — 리서치에서 나온 발견을 실제 코드로
            고쳐 보고 싶다면 <Link to="/learn/coding"><strong>코딩 기초</strong></Link> 코스로,
            발견을 팀에 전달하는 연습은 섹션 7의 실습 기록을 멘토와 리뷰하는 것부터
            시작해 보세요. 발견 3개 기록, 잊지 않았죠?
          </p>
        </div>
      </div>
    </div>
  );
}
