// 이 파일이 하는 일: "앱의 지형" 코스 — 모바일 앱을 만드는 세 갈래 길
// (네이티브 · 크로스플랫폼 · 웹/PWA)을, 학생이 이미 배운 React/JS 지식을
// 다리 삼아 이해시키는 정적 학습 페이지. 목표는 "2개월에 앱 전문가"가 아니라
// "지형을 읽고, 내 실력으로 앱까지 가는 길을 아는" 수준이다.
// 학습 포인트: API 호출이 없는 '내용 고정' 페이지다. 스타일은 global.css의
// 가이드 전용 클래스(step-card, code-block, tip 등)를 재사용한다 — 색은 여기서
// 하드코딩하지 않고 var(--primary/--teal/--amber/--ink/--line/--card/--muted/--rose)만 쓴다.
// 예제 코드는 JSX 중괄호/백틱 충돌을 피하려고 파일 상단의 백틱 문자열 상수로 정의한다.

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

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

const CODE_THREE_PATHS = `모바일 앱을 만드는 세 갈래 길 — 한눈에

                     네이티브        크로스플랫폼      웹 / PWA
──────────────────  ────────────   ─────────────   ─────────────
언어                 Kotlin·Swift   JS/TS · Dart    HTML·CSS·JS
코드는 몇 벌?         플랫폼마다 1벌   한 벌로 둘 다     한 벌 (웹 그대로)
                     (안드+iOS=2벌)
성능·기기 접근        ★★★ 최상       ★★☆ 대체로 충분   ★☆☆ 브라우저 한계
앱스토어 배포         O              O               △ (설치는 '홈에 추가')
개발 속도·비용        느림·비쌈       빠름·중간        가장 빠름·쌈

비유: 세 갈래 길 = 그 나라에서 나고 자란 원주민(네이티브),
      두 나라 말을 다 하는 통역사(크로스플랫폼),
      어디서나 대충 통하는 여행 영어(웹).`;

const CODE_NATIVE = `// 같은 "좋아요 버튼" — 네이티브는 플랫폼마다 언어가 통째로 다릅니다.

// 안드로이드 (Kotlin + Jetpack Compose)
@Composable
fun LikeButton() {
    var count by remember { mutableStateOf(0) }
    Button(onClick = { count++ }) {
        Text("좋아요 $count")
    }
}

// iOS (Swift + SwiftUI)
struct LikeButton: View {
    @State private var count = 0
    var body: some View {
        Button("좋아요 \\(count)") { count += 1 }
    }
}

// 눈치챘나요? 두 코드의 '생각'은 똑같아요 —
// 상태(count)가 바뀌면 화면이 다시 그려진다. React의 useState와 판박이!
// 다만 언어·도구·문법이 완전히 달라서 '두 번' 만들어야 합니다.`;

const CODE_CROSS = `// React Native — React를 안다면 이미 절반 이상 아는 코드예요.
import { useState } from 'react';
import { View, Text, Button } from 'react-native';  // div 대신 View, p 대신 Text

function LikeButton() {
  const [count, setCount] = useState(0);   // ← 웹에서 쓰던 useState, 그대로!

  return (
    <View>
      <Text>좋아요 {count}</Text>
      <Button title="누르기" onPress={() => setCount(count + 1)} />
    </View>
  );
}

// 웹 React와 다른 점은 주로 '태그 이름':
//   <div>  → <View>      <p> → <Text>      onClick → onPress
// 컴포넌트·props·state·JSX의 사고방식은 그대로 재사용됩니다.
// 이 코드 한 벌이 안드로이드 '진짜' 버튼과 iOS '진짜' 버튼으로 함께 변신해요.`;

const CODE_PWA = `// PWA = 우리가 아는 웹사이트에 '앱 옷' 두 벌을 입힌 것

// ① manifest.json — "나 앱이에요" 명함 (아이콘·이름·시작 화면)
{
  "name": "미림 학습 플랫폼",
  "short_name": "mirim",
  "start_url": "/",
  "display": "standalone",   // 주소창 없이 앱처럼 꽉 차게
  "icons": [{ "src": "/icon-192.png", "sizes": "192x192" }]
}

// ② service worker — 브라우저 뒤에서 도는 '작은 비서'
//    네트워크 요청을 가로채 캐시로 응답 → 오프라인에서도 열림
self.addEventListener('fetch', (e) => {
  e.respondWith(caches.match(e.request));  // 저장해 둔 걸 먼저 내줌
});

// 결과: 홈 화면에 아이콘이 깔리고, 오프라인에서도 뜨고,
//       (최신 브라우저 한정) 푸시 알림까지. 단, 앱스토어엔 올라가지 않아요.`;

const CODE_DECISION = `무엇을 언제 고르나 — 상황별 처방전

이런 상황이면 …                            →  이 길이 유력
──────────────────────────────────────    ──────────────────
3D 게임·영상 편집·카메라를 극한으로 쓴다      →  네이티브
매 프레임 성능·최신 OS 기능이 생명이다        →  네이티브
안드로이드·iOS 둘 다, 인력·시간은 빠듯        →  크로스플랫폼
이미 팀이 React/JS에 능숙하다                →  크로스플랫폼(React Native)
웹 서비스가 이미 있고 '앱 같은' 접근만 원함    →  웹 / PWA
사내 도구·초기 MVP, 앱스토어 심사가 부담       →  웹 / PWA

황금률: "가장 단순한 길부터." 웹으로 되면 웹, 안 되면 크로스,
        그래도 벽에 부딪히면 네이티브. 처음부터 네이티브는
        대개 과잉 투자예요. (단, 성능이 제품의 본질이면 예외)`;

const CODE_OUR_STACK = `우리 스택에서 '앱까지'의 현실적인 지도

지금 우리가 가진 것:
  frontend/  → React + JSX (Vite로 도는 웹 프론트, 지금 이 화면!)
  backend/   → Spring Boot REST API (JSON을 돌려주는 서버)

여기서 앱으로 가는 두 갈래 (서버는 그대로 재사용!):
  A. PWA           — 지금 웹에 manifest + service worker를 얹어
                     '설치되는 웹'으로. 가장 적은 노력부터 시작.
  B. React Native  — 컴포넌트·props·state 지식을 그대로 들고 이사.
                     태그 이름(View/Text)만 새로 익히면 진짜 네이티브 앱.

★ 핵심: 어느 길이든 백엔드(Spring API)는 안 바뀝니다.
  앱은 결국 '같은 서버에 요청하는 또 하나의 화면'일 뿐이에요.
  네트워크 코스에서 배운 그 HTTP 요청을, 이번엔 폰이 보낼 뿐입니다.`;

// ── 이 페이지 안에서만 쓰는 작은 부품들 ──
// 학습 포인트: 같은 모양이 반복되면 컴포넌트로 뽑는다. props만 바꿔 재사용.
// (React 입문 코스에서 배운 그 원리를 이 파일이 그대로 실천하고 있어요.)
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: '웹 / PWA' },
  { n: 6, label: '선택 기준' },
  { n: 7, label: '우리의 길' },
];

export default function AppLandscapePage() {
  return (
    <div>
      {/* 히어로: 이 코스가 무엇을 겨냥하는지 — '전문가'가 아니라 '지형 읽기' */}
      <div className="hero">
        <div className="eyebrow">Course · 앱 개발</div>
        <h1>앱의 지형<br />— 모바일 개발의 세 갈래 길</h1>
        <p>
          같은 "앱"이라도 만드는 길은 하나가 아니에요. 네이티브, 크로스플랫폼,
          웹/PWA — 세 갈래 길엔 저마다 장단점과 어울리는 상황이 있습니다. 이 코스의
          목표는 <strong>2개월 만에 앱 전문가가 되는 것이 아니라</strong>, 지형을 읽고{' '}
          <strong>여러분이 이미 아는 React/JS를 다리 삼아</strong> "내 실력으로 앱까지
          가는 길"을 그려 보는 거예요.
        </p>
        <div className="chip-row">
          <span className="chip">예상 소요 70분</span>
          <span className="chip">실습: 비교·판단 중심</span>
          <span className="chip">선수 지식: React 입문</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>
        <p>
          좋은 소식은, <strong>여러분은 이미 출발선을 한참 지나 있다는 것</strong>이에요.
          앱 화면도 결국 "상태가 바뀌면 화면이 다시 그려진다"는 React의 그 사고방식으로
          만들어지고, 앱이 데이터를 가져오는 방식도 웹과 똑같이{' '}
          <span className="icode">HTTP 요청 → JSON 응답</span>입니다. 새로 배우는 건
          '전혀 다른 세계'가 아니라 '익숙한 개념의 다른 옷'인 경우가 많아요.
        </p>
        <div className="tip">
          <b>이 코스의 약속</b> 여기서 Kotlin이나 Swift 문법을 통째로 외우진 않아요.
          대신 "어떤 길들이 있고, 각각 언제·왜 고르는가"를 확실히 잡습니다. 세부 문법은
          길을 정한 다음에 파도 늦지 않아요 — <strong>지도 먼저, 삽질은 나중</strong>.
        </div>
      </Section>

      <Section n={2} title="세 갈래 길 개요" sub="네이티브 · 크로스플랫폼 · 웹, 무엇이 다른가">
        <p>
          모바일 앱을 만드는 방법은 크게 셋으로 나뉩니다. 셋을 가르는 핵심 질문은
          딱 하나예요. <strong>"내 코드가 폰의 하드웨어(카메라·센서·GPU)에 얼마나 가까이,
          몇 겹을 거쳐 닿느냐?"</strong> 가까울수록 빠르고 강력하지만 손이 많이 가고,
          멀수록 편하고 싸지만 할 수 있는 일에 한계가 생깁니다.
        </p>
        <Code>{CODE_THREE_PATHS}</Code>
        <p>
          아래 그림이 이 코스 전체의 뼈대예요. 세 길 모두 <strong>맨 아래의 OS·하드웨어는
          똑같이 공유</strong>합니다. 다른 건 "그 위에 몇 겹의 다리를 얹느냐"뿐이에요.
        </p>
        <svg className="diagram" viewBox="0 0 660 380" xmlns="http://www.w3.org/2000/svg" role="img" aria-label="세 갈래 길 비교도: 네이티브는 Kotlin과 Swift 코드가 OS API를 직접 호출하고, 크로스플랫폼은 자바스크립트나 Dart 한 벌이 리액트 네이티브 브리지나 플러터 엔진을 거치며, 웹과 PWA는 HTML CSS JS가 브라우저 엔진을 거친다. 세 길 모두 맨 아래의 안드로이드 iOS 운영체제와 카메라 센서 GPU 하드웨어를 똑같이 공유한다.">
          {/* 네이티브 열 */}
          <text x="130" y="24" textAnchor="middle" fontSize="14" fontWeight="600" fill="var(--primary)">네이티브</text>
          <rect x="50" y="38" width="160" height="46" rx="8" fill="var(--card)" stroke="var(--primary)" strokeWidth="2" />
          <text x="130" y="60" textAnchor="middle" fontSize="13" fill="var(--ink)">Kotlin · Swift</text>
          <text x="130" y="77" textAnchor="middle" fontSize="11" fill="var(--muted)">플랫폼마다 1벌</text>
          <line x1="130" y1="84" x2="130" y2="116" stroke="var(--line)" strokeWidth="2" />
          <rect x="50" y="116" width="160" height="46" rx="8" fill="var(--card)" stroke="var(--line)" />
          <text x="130" y="138" textAnchor="middle" fontSize="13" fill="var(--ink)">OS API 직접 호출</text>
          <text x="130" y="155" textAnchor="middle" fontSize="11" fill="var(--muted)">다리 없음 · 가장 가까움</text>
          <line x1="130" y1="162" x2="130" y2="286" stroke="var(--primary)" strokeWidth="2" />
          <path d="M130 298 L124 286 L136 286 Z" fill="var(--primary)" />

          {/* 크로스플랫폼 열 */}
          <text x="330" y="24" textAnchor="middle" fontSize="14" fontWeight="600" fill="var(--teal)">크로스플랫폼</text>
          <rect x="250" y="38" width="160" height="46" rx="8" fill="var(--card)" stroke="var(--teal)" strokeWidth="2" />
          <text x="330" y="60" textAnchor="middle" fontSize="13" fill="var(--ink)">JS/TS · Dart</text>
          <text x="330" y="77" textAnchor="middle" fontSize="11" fill="var(--muted)">한 벌로 둘 다</text>
          <line x1="330" y1="84" x2="330" y2="116" stroke="var(--line)" strokeWidth="2" />
          <rect x="250" y="116" width="160" height="46" rx="8" fill="var(--card)" stroke="var(--line)" />
          <text x="330" y="137" textAnchor="middle" fontSize="12" fill="var(--ink)">RN 브리지·Flutter 엔진</text>
          <text x="330" y="155" textAnchor="middle" fontSize="11" fill="var(--muted)">얇은 다리 한 겹</text>
          <line x1="330" y1="162" x2="330" y2="286" stroke="var(--teal)" strokeWidth="2" />
          <path d="M330 298 L324 286 L336 286 Z" fill="var(--teal)" />

          {/* 웹 / PWA 열 */}
          <text x="530" y="24" textAnchor="middle" fontSize="14" fontWeight="600" fill="var(--amber)">웹 / PWA</text>
          <rect x="450" y="38" width="160" height="46" rx="8" fill="var(--card)" stroke="var(--amber)" strokeWidth="2" />
          <text x="530" y="60" textAnchor="middle" fontSize="13" fill="var(--ink)">HTML · CSS · JS</text>
          <text x="530" y="77" textAnchor="middle" fontSize="11" fill="var(--muted)">웹 한 벌 그대로</text>
          <line x1="530" y1="84" x2="530" y2="116" stroke="var(--line)" strokeWidth="2" />
          <rect x="450" y="116" width="160" height="46" rx="8" fill="var(--card)" stroke="var(--line)" />
          <text x="530" y="138" textAnchor="middle" fontSize="13" fill="var(--ink)">브라우저 엔진</text>
          <text x="530" y="155" textAnchor="middle" fontSize="11" fill="var(--muted)">두꺼운 다리 · 가장 멈</text>
          <line x1="530" y1="162" x2="530" y2="286" stroke="var(--amber)" strokeWidth="2" />
          <path d="M530 298 L524 286 L536 286 Z" fill="var(--amber)" />

          {/* 공유되는 바닥: OS + 하드웨어 */}
          <rect x="50" y="300" width="560" height="58" rx="10" fill="var(--card)" stroke="var(--line)" strokeWidth="2" />
          <text x="330" y="324" textAnchor="middle" fontSize="13" fontWeight="600" fill="var(--ink)">OS: 안드로이드 · iOS</text>
          <text x="330" y="344" textAnchor="middle" fontSize="12" fill="var(--muted)">하드웨어 — 카메라 · 센서 · GPU · 저장소 (세 길이 함께 씀)</text>
        </svg>
        <p className="muted" style={{ fontSize: 12.5, textAlign: 'center', marginTop: 2 }}>그림: 세 갈래 길은 위쪽 '언어와 다리'만 다르고, 아래쪽 OS·하드웨어는 똑같이 공유한다 — 다리가 두꺼울수록 편하지만 하드웨어에서 멀어진다</p>
        <div className="tip">
          <b>기억할 한 문장</b> "다리를 얹을수록 편해지지만, 하드웨어에서는 멀어진다."
          이 저울 하나가 세 길의 성능·비용·자유도 차이를 거의 다 설명해요.
        </div>
      </Section>

      <Section n={3} title="네이티브란" sub="그 플랫폼의 원주민 언어로 직접 말하기">
        <p>
          <strong>네이티브(native)</strong>는 각 플랫폼이 공식으로 정한 언어·도구로 앱을
          만드는 방식이에요. 안드로이드는 <strong>Kotlin</strong>(과거엔 Java)으로{' '}
          <span className="icode">Android Studio</span>에서, iOS는 <strong>Swift</strong>
          (과거엔 Objective-C)로 <span className="icode">Xcode</span>에서 만듭니다. 요즘의
          화면(UI)은 각각 <strong>Jetpack Compose</strong>(안드로이드)와{' '}
          <strong>SwiftUI</strong>(iOS)로 그리고요.
        </p>
        <Code>{CODE_NATIVE}</Code>
        <p>
          장점은 명확해요. <strong>하드웨어에 가장 가깝기 때문에 가장 빠르고</strong>,
          카메라·센서·최신 OS 기능을 <strong>제일 먼저, 제일 완전하게</strong> 쓸 수 있어요.
          고사양 3D 게임, 영상 편집, 정밀한 카메라 앱이 네이티브를 고르는 이유입니다.
          단점도 그만큼 분명하죠 — 안드로이드용과 iOS용을 <strong>사실상 두 번</strong>{' '}
          만들어야 하고, 서로 다른 언어·도구를 아는 인력이 양쪽 다 필요합니다.
        </p>
        <div className="warn">
          <b>iOS의 현실적 제약</b> iOS 앱을 <strong>빌드하려면 맥(macOS)</strong>이
          필요해요. Xcode가 맥에서만 돌기 때문이죠. "아이폰 앱도 만들자"는 결정에는
          장비·계정 비용이 따라온다는 걸 미리 알아 두면 나중에 당황하지 않습니다.
        </div>
      </Section>

      <Section n={4} title="크로스플랫폼이란" sub="한 벌의 코드로 안드로이드와 iOS 둘 다">
        <p>
          "두 번 만드는 건 너무 비싸다. 한 벌로 둘 다 안 될까?"에 답하는 게{' '}
          <strong>크로스플랫폼(cross-platform)</strong>이에요. 대표 주자는 둘입니다.
          Meta가 만든 <strong>React Native</strong>(JavaScript/TypeScript)와 Google이 만든{' '}
          <strong>Flutter</strong>(<span className="icode">Dart</span> 언어)예요.
        </p>
        <p>
          두 도구의 '그리는 방식'은 살짝 달라요. <strong>React Native</strong>는 우리가 쓴
          컴포넌트를 <strong>진짜 네이티브 위젯</strong>으로 바꿔 화면에 올리고,{' '}
          <strong>Flutter</strong>는 자체 엔진으로 <strong>화면을 직접 그립니다</strong>
          (픽셀을 스스로 칠하는 쪽). 방식은 달라도 목표는 같아요 —{' '}
          <strong>코드 한 벌로 두 플랫폼</strong>.
        </p>
        <Code>{CODE_CROSS}</Code>
        <p>
          여러분에게 특히 반가운 건 <strong>React Native</strong>예요. 위 코드를 보면{' '}
          <span className="icode">useState</span>, props, JSX, 컴포넌트 — 전부 React 입문
          코스에서 배운 그대로죠. 바뀐 건 주로 <strong>태그 이름</strong>입니다
          (<span className="icode">&lt;div&gt;→&lt;View&gt;</span>,{' '}
          <span className="icode">&lt;p&gt;→&lt;Text&gt;</span>). 성능은 네이티브만큼
          극한은 아니지만 <strong>대부분의 앱엔 충분</strong>하고, 개발 속도와 비용은
          크게 절약됩니다.
        </p>
        <div className="tip">
          <b>왜 우리에게 매력적인가</b> 우리 프론트가 이미 React라서, React Native는{' '}
          <strong>'새 언어'가 아니라 '같은 사고방식의 확장'</strong>이에요. 웹에서 쌓은
          컴포넌트 설계 감각이 그대로 자산이 됩니다. (7번 섹션에서 이어서 봅니다.)
        </div>
      </Section>

      <Section n={5} title="웹앱 · PWA란" sub="설치되는 웹 — 이미 있는 웹에 '앱 옷'을 입히기">
        <p>
          세 번째 길은 아예 앱을 따로 만들지 않는 거예요. <strong>웹앱</strong>은 그냥
          모바일 브라우저에서 잘 열리게 만든 웹사이트고, 여기에 몇 가지를 얹어 "앱처럼"
          쓰게 한 게 <strong>PWA(Progressive Web App)</strong>입니다. 핵심 재료는 둘이에요 —{' '}
          <span className="icode">manifest.json</span>(앱 명함)과{' '}
          <span className="icode">service worker</span>(뒤에서 도는 작은 비서).
        </p>
        <Code>{CODE_PWA}</Code>
        <p>
          이 두 가지 덕분에 PWA는 <strong>홈 화면에 아이콘으로 설치되고, 오프라인에서도
          열리고,</strong> 최신 브라우저에선 푸시 알림까지 받을 수 있어요. 개발은{' '}
          <strong>우리가 이미 아는 HTML·CSS·JS 그대로</strong>라 가장 빠르고 저렴합니다.
          이미 웹 서비스가 있다면 "앱까지" 가는 가장 가까운 길이에요.
        </p>
        <div className="warn">
          <b>공짜 점심은 없다</b> PWA는 <strong>앱스토어에 정식 등록되지 않고</strong>
          ('설치'는 브라우저의 홈에 추가), 블루투스·정밀 센서 같은 <strong>일부 하드웨어
          기능은 제한</strong>됩니다. iOS에서는 지원 범위가 안드로이드보다 좁은 편이라,
          "웹으로 다 될 것"이라고 단정하기 전에 <strong>필요한 기능이 브라우저에서
          되는지</strong>부터 확인해야 해요.
        </div>
      </Section>

      <Section n={6} title="무엇을 언제 고르나" sub="정답은 '상황'에 달려 있다 — 선택의 기준표">
        <p>
          "그래서 뭐가 제일 좋아요?"라는 질문엔 정답이 없어요. 좋은 답은 항상{' '}
          <strong>"무엇을 만드는데요?"라는 되물음</strong>에서 시작합니다. 아래 표는
          현업에서 실제로 쓰는 판단 기준을 압축한 거예요.
        </p>
        <Code>{CODE_DECISION}</Code>
        <p>
          기준을 관통하는 축은 결국 몇 개로 좁혀집니다. <strong>① 성능·하드웨어 요구</strong>
          (얼마나 극한인가), <strong>② 예산·시간·인력</strong>(두 번 만들 여유가 있나),{' '}
          <strong>③ 팀이 이미 가진 실력</strong>(무엇에 능숙한가),{' '}
          <strong>④ 앱스토어 등록이 꼭 필요한가</strong>. 이 넷을 놓고 저울질하면
          대개 길이 보여요.
        </p>
        <div className="tip">
          <b>가장 흔한 실수</b> "멋있어 보이니까 처음부터 네이티브"입니다. 대부분의 초기
          제품은 <strong>가장 단순한 길로 시작해</strong> 사용자가 붙고 한계가 보일 때
          더 가까운 길로 옮겨도 늦지 않아요. <strong>과잉 투자보다 '나중에 갈아타기'가
          싸다</strong>는 걸 기억하세요.
        </div>
      </Section>

      <Section n={7} title="우리 회사 관점" sub="React 자산을 살려 '앱까지' 가는 현실적인 길">
        <p>
          이제 우리 상황에 대입해 봅시다. 우리는 <strong>프론트가 React,
          백엔드가 Spring Boot REST API</strong>예요. 이 자산을 버리지 않고 앱으로
          넓히는 길이 실제로 존재합니다.
        </p>
        <Code>{CODE_OUR_STACK}</Code>
        <p>
          가장 중요한 한 가지를 강조할게요. <strong>어느 길을 가든 백엔드(Spring API)는
          그대로 재사용된다</strong>는 점이에요. 앱은 마법이 아니라, 웹 화면과 똑같이{' '}
          <span className="icode">GET /api/...</span> 요청을 보내 JSON을 받아 그리는{' '}
          <strong>'또 하나의 화면'</strong>일 뿐입니다. 네트워크 코스에서 배운 그 HTTP
          요청을 이번엔 폰이 보낼 뿐이죠. 그래서 백엔드를 튼튼히 배워 둔 게 앱 시대에도
          그대로 힘이 됩니다.
        </p>
        <p>
          그러니 여러분의 로드맵은 분명해요. <strong>지금은 React를 깊게, 백엔드를
          단단히.</strong> 그 실력이 쌓이면 React Native로의 이사도, PWA 얹기도 큰 도약이
          아니라 <strong>자연스러운 다음 걸음</strong>이 됩니다. "앱 전문가"라는 간판보다
          "필요할 때 옳은 길을 고를 줄 아는 개발자"가 훨씬 오래가요.
        </p>
        <div className="tip">
          <b>스스로 점검</b> 친구에게 30초 안에 이렇게 설명할 수 있나요? "네이티브는 원주민
          언어라 빠르지만 두 번 만들고, 크로스플랫폼은 한 벌로 둘 다인데 React Native면
          우리 지식이 거의 그대로 쓰이고, PWA는 있는 웹에 앱 옷을 입히는 가장 싼 길이다."
          — 이 세 문장이 나오면 이 코스의 목표는 달성입니다.
        </div>
      </Section>

      <div className="step-card">
        <div className="step-body">
          <h3 style={{ marginBottom: 6 }}>📱 여기까지 왔다면</h3>
          <p className="muted">
            이제 "앱을 만든다"는 말이 하나가 아니라 <strong>세 갈래 길</strong>이라는 걸,
            그리고 각각 언제·왜 고르는지를 설명할 수 있게 됐어요. 무엇보다 —{' '}
            <strong>여러분이 배운 React가 앱으로 가는 진짜 다리라는 것</strong>을 봤습니다.
            다음은 그 세 길 중 가장 넓은 문, 안드로이드를 조금 더 가까이서 들여다볼 차례예요.{' '}
            <Link to="/learn/android-basics"><strong>안드로이드 기초</strong></Link> 코스에서
            Kotlin과 앱의 구성 요소를, 우리가 아는 개념에 하나씩 포개어 만나 보세요.
          </p>
        </div>
      </div>
    </div>
  );
}
