// 이 파일이 하는 일: "Postman으로 API 테스트" 코스 — 브라우저 화면 없이 백엔드 API를
// 직접 두드리는 도구 Postman을 8개 섹션으로 안내하는 정적 학습 페이지.
// (도구 소개 → 설치·화면 구성 → GET 첫걸음 → POST+로그인 → 컬렉션 → 환경변수 → 응답 검증 → 개발 흐름)
// 학습 포인트: API 호출이 없는 '내용 고정' 페이지다. 스타일은 global.css의
// 가이드 전용 클래스(step-card, code-block, tip 등)를 재사용한다 — 색을 여기서 하드코딩하지 않는다.
// 요청/응답 예시는 JSX 중괄호/백틱 충돌을 피하려고 파일 상단의 백틱 문자열 상수로 정의한다.

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

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

const CODE_WHY_POSTMAN = `평소의 여행 경로:
[브라우저 화면] → 버튼 클릭 → [React 프론트] → fetch → [백엔드 API] → [DB]

Postman을 쓰면:
[Postman] ──────────── 직행 ──────────→ [백엔드 API] → [DB]

프론트 화면이라는 '중간 단계'를 건너뛰고,
백엔드의 문(엔드포인트)을 직접 두드려 봅니다.
→ "버그가 프론트 탓인지 백엔드 탓인지" 를 가르는 가장 빠른 방법!`;

const CODE_UI_MAP = `Postman 화면 지도 (처음 열면 여기만 보면 돼요)

┌─────────────────────────────────────────────┐
│ [Workspaces]                    [환경 선택 ▼] │ ← 오른쪽 위: 환경(섹션 6)
├──────────┬──────────────────────────────────┤
│ 사이드바   │  GET ▼ │ https://... 주소창 │ Send │ ← 요청 만드는 곳
│ Collections│ ────────────────────────────────│
│ (섹션 5)  │  Params | Headers | Body | ...   │ ← 요청에 딸려 보낼 것들
│           │ ────────────────────────────────│
│ History   │  응답 영역: Body / Status / Time  │ ← 서버의 답장
└──────────┴──────────────────────────────────┘

외울 건 딱 셋: ① 메서드+주소 ② Send 버튼 ③ 아래 응답 영역`;

const CODE_FIRST_GET = `첫 GET 요청 — 순서대로 따라 하기

1) 메서드 드롭다운: GET 선택 (기본값이라 그대로 두면 됨)
2) 주소창에 입력:  https://edu.awesomedevapp.com/api/health
3) 파란 Send 버튼 클릭!

응답 영역에 이렇게 뜨면 성공:
Status: 200 OK        Time: 120ms       Size: ...

{
  "status": "UP"
}

→ 방금 여러분은 화면(프론트) 없이 서버와 직접 대화했습니다.
  브라우저 주소창에 쳐도 GET은 되지만, Postman은
  상태코드·시간·헤더까지 한눈에 보여주는 게 다릅니다.`;

const CODE_LOGIN_POST = `POST /api/auth/login — 우리 플랫폼에 진짜 로그인해 보기

1) 메서드: POST 로 변경
2) 주소:   https://edu.awesomedevapp.com/api/auth/login
3) Body 탭 → raw 선택 → 오른쪽 드롭다운을 JSON 으로!
4) 입력:

{
  "email": "내 계정 이메일",
  "password": "내 비밀번호"
}

5) Send!

성공 응답 (200):
{
  "name": "홍길동",
  "role": "INTERN"
}

일부러 비밀번호를 틀려 보세요 → 401 Unauthorized 가 옵니다.
"틀리면 어떤 답이 오는지" 확인하는 것도 테스트의 절반이에요.`;

const CODE_COOKIE = `로그인 후 쿠키는 어디에? — Postman이 알아서 챙깁니다

응답 영역의 Cookies 탭을 눌러 보세요:
┌──────────────────────────────────────┐
│ SESSION   abc123...   HttpOnly  Secure │ ← 서버가 발급한 출입증
└──────────────────────────────────────┘

브라우저처럼 Postman도 쿠키 통(Cookie Jar)이 있어서,
같은 도메인으로 보내는 다음 요청에 자동으로 붙여 줍니다.

→ 로그인 요청 한 번 성공시킨 뒤,
  GET /api/checklist 를 보내면 '로그인한 사람'으로 인식돼요.
  로그아웃 상태를 테스트하고 싶으면 Cookies에서 지우면 끝.`;

const CODE_COLLECTION = `컬렉션 = 요청들을 담아 두는 폴더 (즐겨찾기 + 실행 순서)

📁 AWESOMEDEV 수습 플랫폼        ← 컬렉션 (New → Collection)
 ├─ ① POST /api/auth/login       로그인 (출입증 받기)
 ├─ ② GET  /api/checklist        내 체크리스트 조회
 ├─ ③ POST /api/checklist/1/submit  항목 제출
 └─ ④ POST /api/auth/logout      로그아웃

주소창에 매번 다시 치지 말고, 만든 요청을 Save 해서
컬렉션에 쌓아 두세요. 위→아래로 하나씩 실행하면
"로그인 → 조회 → 제출" 이라는 실제 사용 시나리오가 됩니다.

수업 시간의 실험 노트와 같아요 — 한 번 정리해 두면
내일도, 팀 동료도 똑같이 재현할 수 있습니다.`;

const CODE_ENV = `환경(Environment) — 로컬 ↔ 운영을 스위치 하나로 전환

변수 이름: baseUrl

[local 환경]              [prod 환경]
baseUrl =                 baseUrl =
http://localhost:8080     https://edu.awesomedevapp.com

요청 주소는 이렇게 씁니다 (중괄호 2개!):
{{baseUrl}}/api/auth/login
{{baseUrl}}/api/checklist

오른쪽 위 드롭다운에서 local ↔ prod 만 바꾸면
컬렉션 전체가 통째로 다른 서버를 향합니다.
내 PC의 Spring Boot(8080)를 테스트하다가,
같은 요청을 운영 서버로 쏘는 걸 클릭 한 번으로!`;

const CODE_STATUS = `상태코드 — 서버의 답장에 찍힌 도장

2xx  성공          200 OK / 201 Created(만들어짐)
4xx  요청한 쪽 잘못  400 Bad Request(형식 오류)
                   401 Unauthorized(로그인 안 함)
                   403 Forbidden(권한 없음 — 로그인은 했는데!)
                   404 Not Found(그런 주소 없음)
5xx  서버 잘못      500 Internal Server Error(백엔드 코드가 터짐)

테스트할 때 확인하는 3종 세트:
① Status  — 도장이 기대한 숫자인가? (성공만 말고 실패 케이스도!)
② Body    — JSON 내용이 설계서(명세)와 같은가?
③ Time    — 유난히 느린 API는 없나? (수백 ms가 넘으면 의심)`;

const CODE_WORKFLOW = `프론트 없이 백엔드부터 검증하는 개발 흐름

전통적(느린) 방법:
백엔드 작성 → 프론트 화면까지 다 만듦 → 브라우저에서 클릭
→ 안 됨 → 어디가 문제인지 몰라서 양쪽 다 뒤짐 😵

Postman 흐름(우리 방식):
1) Spring Boot로 API 작성
2) Postman으로 바로 두드림 — 200? Body 맞음? 실패 케이스 OK?
3) 백엔드가 '확실히 맞다'는 확신을 얻은 뒤
4) React에서 fetch 연결 → 화면이 이상하면 이제 프론트만 보면 됨!

범인 후보를 미리 한 명씩 지워 두는 수사와 같습니다.
백엔드 개발자는 화면이 없어도 자기 코드를 증명할 수 있어야 해요.`;

// ── 이 페이지 안에서만 쓰는 작은 부품들 ──
// 학습 포인트: 같은 모양이 반복되면 컴포넌트로 뽑는다. 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: 'API를 직접 두드리기' },
  { n: 2, label: '설치와 화면 구성' },
  { n: 3, label: 'GET 첫걸음' },
  { n: 4, label: 'POST와 로그인' },
  { n: 5, label: '컬렉션으로 정리' },
  { n: 6, label: '환경변수' },
  { n: 7, label: '상태코드와 검증' },
  { n: 8, label: '백엔드 우선 개발 흐름' },
];

export default function ToolPostmanPage() {
  return (
    <div>
      {/* 히어로: 이 코스가 어디서 출발해 어디까지 가는지 */}
      <div className="hero">
        <div className="eyebrow">Course · 부록 · 도구</div>
        <h1>Postman으로 API 테스트</h1>
        <p>
          브라우저 화면 없이 백엔드 API의 문을 직접 두드려 보는 도구, Postman을 배웁니다.
          우리 플랫폼의 로그인 API를 진짜로 호출해 보면서 <strong>"버그가 프론트 탓인지
          백엔드 탓인지"</strong>를 스스로 가려내는 힘을 길러요.
        </p>
        <div className="chip-row">
          <span className="chip">예상 소요 50분</span>
          <span className="chip">실습: 우리 API 실제 호출</span>
          <span className="chip">준비물: 내 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="API를 화면 없이 직접 두드리는 도구" sub="프론트라는 중간 단계를 건너뛰면 보이는 것들">
        <p>
          지금까지 우리는 API를 <strong>화면을 통해서만</strong> 만났어요. 버튼을 누르면
          React가 <span className="icode">fetch</span>로 요청을 보내고, 응답으로 화면이 바뀌죠.
          그런데 화면이 이상하면? 프론트가 요청을 잘못 보낸 건지, 백엔드가 답을 잘못 준 건지
          화면만 봐서는 알 수 없어요.
        </p>
        <p>
          <strong>Postman</strong>은 백엔드의 문(엔드포인트)을 <strong>직접</strong> 두드려 보는
          도구예요. 식당에 비유하면 — 평소엔 홀 직원(프론트)을 통해 주문하지만, Postman은
          주방(백엔드)에 직접 주문서를 넣어 보는 거죠. 주방에서 제대로 된 음식이 나오면
          문제는 홀에 있고, 주방부터 이상하면 백엔드를 고쳐야 합니다.
        </p>
        <Code>{CODE_WHY_POSTMAN}</Code>
        <div className="tip">
          <b>왜 배우나요?</b> 어썸데브의 개발 흐름에서 백엔드(Spring Boot) API는
          프론트가 완성되기 <strong>전에</strong> Postman으로 먼저 검증해요. 여러분이 만들
          과제 API도 마찬가지 — 이 코스가 끝나면 화면 없이도 내 API를 증명할 수 있습니다.
        </div>
      </Section>

      <Section n={2} title="설치와 화면 구성" sub="처음 열었을 때 봐야 할 곳은 딱 세 군데">
        <p>
          Postman 공식 사이트에서 무료 버전을 내려받아 설치하세요(Windows용).
          계정 가입을 권하는 화면이 나오지만, 우리 실습은 <strong>가입 없이 가볍게
          쓰는 모드로도 충분</strong>해요. 처음 화면이 복잡해 보여도 겁먹지 마세요 —
          실제로 쓰는 곳은 세 군데뿐입니다.
        </p>
        <Code>{CODE_UI_MAP}</Code>
        <p>
          핵심은 가운데 위쪽이에요. <strong>메서드(GET/POST...)를 고르고, 주소를 치고,
          Send를 누른다</strong> — 이게 Postman 사용법의 전부입니다. 나머지 탭(Params,
          Headers, Body)은 요청에 딸려 보낼 짐이고, 아래 응답 영역은 서버의 답장이에요.
        </p>
        <svg className="diagram" viewBox="0 0 640 360" xmlns="http://www.w3.org/2000/svg" role="img" aria-label="Postman 요청 구성 해부: 위쪽 요청 영역의 메서드·URL·Send 버튼과 헤더·바디 탭, 아래쪽 응답 영역의 상태코드와 본문">
          <text x="20" y="22" fontSize="13" fontWeight="bold" fill="var(--ink)">요청 (내가 만드는 것)</text>

          <rect x="20" y="34" width="600" height="150" rx="8" fill="var(--card)" stroke="var(--line)" />

          <rect x="36" y="52" width="80" height="32" rx="8" fill="var(--card)" stroke="var(--primary)" strokeWidth="2" />
          <text x="76" y="73" fontSize="13" textAnchor="middle" fill="var(--primary)" fontWeight="bold">POST ▼</text>

          <rect x="126" y="52" width="376" height="32" rx="8" fill="var(--card)" stroke="var(--line)" />
          <text x="140" y="73" fontSize="12.5" fill="var(--ink)">https://edu.awesomedevapp.com/api/auth/login</text>

          <rect x="512" y="52" width="92" height="32" rx="8" fill="var(--card)" stroke="var(--teal)" strokeWidth="2" />
          <text x="558" y="73" fontSize="13" textAnchor="middle" fill="var(--teal)" fontWeight="bold">Send</text>

          <text x="76" y="102" fontSize="12" textAnchor="middle" fill="var(--muted)">① 메서드</text>
          <text x="314" y="102" fontSize="12" textAnchor="middle" fill="var(--muted)">② 주소(URL)</text>
          <text x="558" y="102" fontSize="12" textAnchor="middle" fill="var(--muted)">③ 보내기</text>

          <line x1="36" y1="114" x2="604" y2="114" stroke="var(--line)" />

          <text x="46" y="133" fontSize="12.5" fill="var(--muted)">Params</text>
          <text x="112" y="133" fontSize="12.5" fill="var(--ink)" fontWeight="bold">Headers</text>
          <text x="186" y="133" fontSize="12.5" fill="var(--ink)" fontWeight="bold">Body</text>
          <line x1="106" y1="140" x2="166" y2="140" stroke="var(--amber)" strokeWidth="2" strokeLinecap="round" />
          <line x1="182" y1="140" x2="216" y2="140" stroke="var(--amber)" strokeWidth="2" strokeLinecap="round" />

          <text x="46" y="160" fontSize="12" fill="var(--muted)">Headers: Content-Type: application/json</text>
          <text x="46" y="176" fontSize="12" fill="var(--muted)">Body(raw · JSON): {'{ "email": ..., "password": ... }'}</text>

          <line x1="320" y1="184" x2="320" y2="216" stroke="var(--line)" strokeWidth="2" strokeDasharray="5 4" />
          <text x="332" y="206" fontSize="12" fill="var(--muted)">Send 누르면 서버로</text>

          <text x="20" y="238" fontSize="13" fontWeight="bold" fill="var(--ink)">응답 (서버의 답장)</text>

          <rect x="20" y="250" width="600" height="96" rx="8" fill="var(--card)" stroke="var(--line)" />

          <text x="38" y="274" fontSize="13" fill="var(--teal)" fontWeight="bold">Status: 200 OK</text>
          <text x="180" y="274" fontSize="12.5" fill="var(--muted)">Time: 120ms</text>
          <text x="290" y="274" fontSize="12.5" fill="var(--muted)">Size</text>
          <text x="366" y="274" fontSize="12.5" fill="var(--rose)">틀리면 401 Unauthorized</text>

          <line x1="38" y1="286" x2="602" y2="286" stroke="var(--line)" />

          <text x="38" y="308" fontSize="12.5" fill="var(--muted)">Body</text>
          <text x="90" y="308" fontSize="12.5" fill="var(--ink)">{'{ "name": "홍길동", "role": "INTERN" }'}</text>
          <text x="38" y="332" fontSize="12" fill="var(--muted)">먼저 Status(도장) → 그다음 Body(내용) → Time(속도) 순으로 읽습니다</text>
        </svg>
        <p className="muted" style={{ fontSize: 12.5, textAlign: 'center', marginTop: 2 }}>
          그림: Postman 요청 구성 해부 — 메서드·주소·Send와 헤더/바디, 그리고 아래 응답 영역
        </p>
        <div className="tip">
          <b>메서드 복습</b> GET은 "보여 줘"(조회), POST는 "새로 만들어 줘/처리해 줘",
          PUT/PATCH는 "고쳐 줘", DELETE는 "지워 줘". 백엔드 코스에서 배운
          그 HTTP 메서드를 이제 손으로 직접 골라서 보냅니다.
        </div>
      </Section>

      <Section n={3} title="GET 요청 첫걸음" sub="서버야, 살아 있니? — 3클릭으로 첫 대화">
        <p>
          첫 요청은 가장 안전한 것부터 — 서버가 살아 있는지 묻는 <strong>헬스체크</strong>예요.
          GET은 데이터를 <strong>읽기만</strong> 하는 요청이라 몇 번을 보내도 서버에
          아무 변화가 없어요. 마음 놓고 눌러 보세요.
        </p>
        <Code>{CODE_FIRST_GET}</Code>
        <div className="tip">
          <b>직접 확인해 보기 ①</b> 위 순서대로 우리 플랫폼에 GET 요청을 보내 보세요.
          성공했다면 응답 영역에서 <strong>Status·Time·Size</strong> 세 가지를 찾아 읽어 보고,
          이번엔 주소 끝을 일부러 <span className="icode">/api/healthhh</span>처럼 틀리게 쳐서
          <strong> 404</strong>가 오는 것도 확인! "틀렸을 때 뭐가 오는지"까지 봐야 테스트예요.
        </div>
      </Section>

      <Section n={4} title="POST와 JSON 바디 — 우리 로그인 API 호출" sub="진짜 로그인을 화면 없이 해 보기">
        <p>
          GET과 달리 <strong>POST</strong>는 서버에 데이터를 <strong>실어 보내는</strong> 요청이에요.
          그 짐칸이 <strong>Body</strong>이고, 우리 백엔드는 짐을 <strong>JSON</strong> 형식으로
          받습니다. 편지(요청)에 소포(JSON)를 동봉하는 셈이죠. 이번엔 우리 플랫폼에
          진짜로 로그인해 봅시다 — 여러분이 매일 로그인 화면에서 누르던 그 버튼이
          뒤에서 보내는 요청과 <strong>완전히 같은</strong> 요청이에요.
        </p>
        <Code>{CODE_LOGIN_POST}</Code>
        <p>
          로그인에 성공하면 서버는 <strong>쿠키</strong>라는 출입증을 발급해요. 좋은 소식:
          Postman도 브라우저처럼 쿠키를 <strong>자동으로 보관하고, 다음 요청에 자동으로
          붙여</strong> 줍니다. 여러분이 헤더를 손으로 만질 필요가 없어요.
        </p>
        <Code>{CODE_COOKIE}</Code>
        <div className="tip">
          <b>직접 확인해 보기 ②</b> 내 계정으로 로그인 POST를 성공시킨 다음, 바로
          <span className="icode">GET {'{{'}baseUrl{'}}'}/api/checklist</span>… 는 아직이고(환경변수는 섹션 6!),
          <span className="icode"> https://edu.awesomedevapp.com/api/checklist</span>를 GET으로 보내 보세요.
          내 체크리스트 JSON이 오면 쿠키가 자동으로 따라간 거예요. 이어서 Cookies에서
          쿠키를 지우고 같은 요청을 다시 — 이번엔 <strong>401</strong>이 옵니다.
        </div>
      </Section>

      <Section n={5} title="컬렉션 — 우리 API를 시나리오로 정리" sub="로그인 → 조회 → 제출, 실험 노트 만들기">
        <p>
          요청을 매번 주소창에 새로 치는 건 금방 지겨워져요. Postman의
          <strong> 컬렉션(Collection)</strong>은 요청들을 담아 두는 폴더입니다.
          단순한 즐겨찾기가 아니라, 위에서 아래로 실행하면 <strong>실제 사용 시나리오</strong>가
          되도록 순서대로 정리하는 게 요령이에요.
        </p>
        <Code>{CODE_COLLECTION}</Code>
        <p>
          요청을 만들고 <span className="kbd">Ctrl</span>+<span className="kbd">S</span>로
          저장하면 컬렉션을 고를 수 있어요. 각 요청에 <strong>"① 로그인"</strong>처럼
          번호와 설명을 붙여 두면, 다음에 열었을 때 (그리고 팀 동료가 봤을 때)
          무슨 순서로 실행해야 하는지 바로 보입니다.
        </p>
        <div className="tip">
          <b>직접 확인해 보기 ③</b> "AWESOMEDEV 수습 플랫폼" 컬렉션을 만들고,
          섹션 3~4에서 보낸 요청들을 저장해 넣으세요. 그리고 Postman을 완전히 껐다 켠 뒤
          컬렉션에서 로그인부터 순서대로 다시 실행 — 어제의 실험을 오늘 그대로
          재현할 수 있다는 것, 이게 컬렉션의 힘이에요.
        </div>
      </Section>

      <Section n={6} title="환경변수 — 로컬과 운영을 스위치로 전환" sub="주소를 고치지 말고, 환경을 바꿔라">
        <p>
          여러분이 과제로 만든 Spring Boot는 <span className="icode">localhost:8080</span>에서
          돌고, 우리 운영 서버는 <span className="icode">edu.awesomedevapp.com</span>에 있죠.
          같은 API를 두 서버에서 테스트하려고 주소를 매번 고치다 보면 언젠가 실수합니다.
          그래서 <strong>환경(Environment)</strong> — 주소의 앞부분을 변수로 빼 두고,
          스위치만 바꾸는 방식을 씁니다.
        </p>
        <Code>{CODE_ENV}</Code>
        <p>
          <span className="icode">{'{{'}baseUrl{'}}'}</span>처럼 <strong>중괄호 두 겹</strong>이
          Postman의 변수 문법이에요. 오른쪽 위 드롭다운에서 환경을 고르면 컬렉션의 모든 요청이
          한꺼번에 그 서버를 향합니다. 옷은 그대로 두고 무대 배경만 바꾸는 연극 같은 거죠.
          나중에 배울 <span className="icode">.env</span> 파일(백엔드 설정 주입)과 똑같은
          발상이라는 것도 기억해 두세요 — <strong>바뀌는 값은 코드가 아니라 설정으로.</strong>
        </p>
      </Section>

      <Section n={7} title="상태코드와 응답 검증" sub="서버의 답장에 찍힌 도장 읽는 법">
        <p>
          Send를 누른 뒤 가장 먼저 볼 곳은 Body가 아니라 <strong>Status</strong>예요.
          상태코드는 서버가 답장에 찍어 주는 도장 — 세 자리 숫자의 <strong>첫 자리</strong>만
          읽어도 큰 그림이 보입니다. 2로 시작하면 성공, 4로 시작하면 <strong>요청한 내
          쪽</strong> 잘못, 5로 시작하면 <strong>서버 쪽</strong> 잘못이에요.
        </p>
        <Code>{CODE_STATUS}</Code>
        <p>
          401과 403의 차이는 시험에 잘 나와요(진짜로 실무에서 헷갈립니다).
          <strong> 401</strong>은 "너 누군지 몰라"(로그인 안 됨), <strong>403</strong>은
          "너 누군지 아는데 이건 안 돼"(권한 부족) — 수습 계정으로 관리자 API를 부르면
          403이 오는 게 정상이에요.
        </p>
        <div className="warn">
          <b>운영 서버에 쓰기 요청 함부로 보내지 않기</b> — GET은 읽기라 안전하지만,
          POST·PUT·DELETE는 운영 DB의 <strong>진짜 데이터를 바꿉니다.</strong> 실수로 제출
          API를 두 번 쏘면 진짜로 두 번 제출돼요. 쓰기 연습은 반드시 <strong>내 로컬
          서버(localhost)</strong>나 멘토가 지정한 테스트 계정으로! 운영에 쓰기 요청을
          보내야 할 땐 멘토에게 먼저 확인받는 게 어썸데브의 규칙입니다.
        </div>
      </Section>

      <Section n={8} title="프론트 없이 백엔드만 테스트하는 개발 흐름" sub="화면이 없어도 내 API를 증명하는 법">
        <p>
          마지막으로, Postman이 실무에서 <strong>언제</strong> 쓰이는지 봅시다.
          백엔드와 프론트를 한꺼번에 만들고 브라우저에서 확인하면, 버그가 났을 때
          용의자가 둘이라 수사가 오래 걸려요. 그래서 우리는 <strong>백엔드부터
          Postman으로 검증을 끝내고</strong> 프론트를 연결합니다.
        </p>
        <Code>{CODE_WORKFLOW}</Code>
        <p>
          과제에서 Spring Boot API를 만들 때 이 흐름을 그대로 쓰세요 — 컨트롤러 하나를
          만들 때마다 Postman 컬렉션에 요청을 추가하고, <strong>성공 케이스와 실패
          케이스</strong>(빈 값, 틀린 비밀번호, 없는 ID)를 모두 눌러 봅니다. 코드 리뷰 때
          "Postman으로 이렇게 확인했어요"라고 컬렉션을 보여 주면, 그게 바로
          여러분 API의 <strong>증거 자료</strong>가 됩니다.
        </p>
        <div className="tip">
          <b>직접 확인해 보기 ④</b> 백엔드 과제 프로젝트를
          <span className="icode"> localhost:8080</span>으로 띄우고, 섹션 6에서 만든
          <strong> local 환경</strong>으로 스위치를 바꾼 뒤 내가 만든 API를 컬렉션에
          추가해 보세요. 성공 1개 + 실패 2개(잘못된 입력, 없는 데이터) 케이스까지
          저장하면 오늘 코스 완주입니다.
        </div>
      </Section>

      <div className="step-card">
        <div className="step-body">
          <h3 style={{ marginBottom: 6 }}>📮 여기까지 왔다면</h3>
          <p className="muted">
            이제 화면 없이도 API와 대화할 수 있어요 — GET/POST 요청 보내기, JSON 바디와
            쿠키, 컬렉션·환경변수로 정리하기, 상태코드로 답장 읽기까지. 이 도구는 앞으로
            모든 백엔드 과제의 기본기가 됩니다. 요청과 응답이 오가는 길 자체가 궁금하다면{' '}
            <Link to="/learn/network"><strong>네트워크의 이해</strong></Link> 코스에서 HTTP의
            밑바닥을, 두드릴 API를 직접 만들고 싶다면 <strong>백엔드 과제</strong>에서
            Spring Boot 컨트롤러 작성을 이어서 배워 보세요.
          </p>
        </div>
      </div>
    </div>
  );
}
