// 이 파일이 하는 일: "Flutter" 코스 — 또 하나의 크로스플랫폼 도구인 Flutter를
// "웹 개발자가 보는 모바일" 관점에서 안내하는 정적 학습 페이지. Dart 언어와
// 자체 렌더링 엔진에서 출발해, React Native와의 비교·Dart 맛보기·'모든 게 위젯'·
// StatefulWidget 상태관리·선택 기준·우리 관점(React 자산 vs Dart 학습비용)까지
// 7개 섹션으로 지형을 읽는다. 목표는 "2개월에 앱 전문가"가 아니라 "길을 아는" 것.
// 학습 포인트: API 호출이 없는 '내용 고정' 페이지다. 색·간격은 global.css의
// 가이드 전용 클래스(step-card, code-block, tip, warn 등)를 재사용한다 — 색을 여기서
// 하드코딩하지 않고 var(--primary/--teal/--amber/--ink/--line/--card/--muted/--rose)만 쓴다.
// 예제 코드는 JSX 중괄호/백틱 충돌을 피하려고 파일 상단의 백틱 문자열 상수로 정의한다.
// (주의: Dart 예제 안에서 문자열 보간은 ${'{}'} 대신 $이름 형태만 써서 JS 템플릿 리터럴과 안 부딪히게 했어요.)

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

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

const CODE_WHAT_IS = `Flutter를 한 문장으로:

    "Dart로 UI를 짜면, Flutter가 화면의 픽셀을 직접 그려 준다."

여기서 핵심은 '직접 그린다'예요.

일반 앱                          Flutter 앱
──────────────────────       ──────────────────────
OS가 제공하는 버튼·목록을         OS 버튼을 안 빌리고,
빌려다 화면에 배치               자체 엔진이 버튼 모양을
(각 OS의 순정 부품 조립)          픽셀 단위로 직접 그림

비유: 남의 집 가구를 빌려 오는 게 아니라,
      내 목공소(렌더링 엔진)에서 가구를 통째로 깎아 만드는 것.
      → 그래서 안드로이드/iOS에서 화면이 거의 똑같이 나옵니다.

구성: Dart(언어) + 위젯(부품) + 렌더링 엔진(Impeller/Skia).
만든 곳: Google. 하나의 코드로 안드로이드·iOS·웹·데스크톱까지 목표.`;

const CODE_RN_COMPARE = `React Native vs Flutter — 같은 목표, 다른 길

                React Native            Flutter
─────────────────────────────────────────────────────────
언어            JavaScript/TypeScript   Dart
그리는 방식      OS의 '진짜' 네이티브      자체 엔진이 픽셀을
                부품을 빌려 씀            직접 그림 (부품 안 빌림)
화면 느낌        각 OS 순정 느낌에 가까움    어디서든 거의 동일
만든 곳          Meta(페이스북)           Google
생태계           npm·React 자산 그대로     pub.dev (Dart 전용)
우리 팀과의 거리   React를 이미 앎 → 가까움    Dart부터 새로 배움 → 멂

왜 둘 다 살아있나?
- RN: "웹(React) 지식을 모바일로 그대로 잇고 싶다"에 강함.
- Flutter: "디자인을 픽셀까지 통제하고, 애니메이션을 매끄럽게"에 강함.
→ 정답이 하나가 아니라, '무엇을 아끼고 싶은가'가 다른 두 도구예요.`;

const CODE_DART = `// Dart 맛보기 — JS를 알면 90%는 눈에 익어요 (세미콜론·타입만 추가된 느낌)

// 변수
var name = '미림';          // 타입 추론 (JS의 let과 비슷)
String grade = '3학년';      // 명시적 타입 — JS엔 없던 부분
final school = '미림마이스터고'; // final = 재할당 금지 (JS의 const 느낌)

// 널 안전성(null safety) — Dart의 자랑거리
String? nickname;           // ? 붙은 타입만 null이 될 수 있음
print(nickname ?? '별명 없음'); // ?? : null이면 오른쪽 값 사용

// 함수 — 반환 타입과 매개변수 타입을 앞에 적어요
int add(int a, int b) => a + b;   // 한 줄 함수는 => 로

// 리스트와 반복
var courses = ['네트워크', 'React', 'Flutter'];
for (var c in courses) {
  print('오늘의 코스: $c');   // $변수 로 문자열에 값 끼워넣기(보간)
}

// 클래스 — 위젯도 전부 클래스예요 (다음 섹션 예고)
class Student {
  final String name;
  Student(this.name);         // 생성자
}`;

const CODE_WIDGET = `// 모든 게 위젯 — 버튼도, 글자도, 여백도, 정렬도 전부 '위젯'
// React가 "다 컴포넌트"라면, Flutter는 "다 위젯". 결이 아주 비슷해요.

class HelloCard extends StatelessWidget {   // 상태 없는 위젯 = React의 순수 컴포넌트
  const HelloCard({super.key});

  @override
  Widget build(BuildContext context) {      // build() = React의 return (JSX) 자리
    return Column(                           // 세로로 쌓는 '레이아웃 위젯'
      children: [
        Text('안녕, 미림!'),                  // 글자도 위젯
        SizedBox(height: 8),                 // 여백조차 위젯 (React의 margin 대신)
        ElevatedButton(
          onPressed: () {},                  // React의 onClick 자리
          child: Text('좋아요'),              // 버튼 '안'의 글자 — child로 감쌈
        ),
      ],
    );
  }
}

// 포인트: HTML 태그를 쓰는 게 아니라, 위젯을 '중첩'해서 화면을 조립합니다.
// Column > [Text, SizedBox, ElevatedButton > Text] ... 이 중첩이 곧 '위젯 트리'.`;

const CODE_STATEFUL = `// StatefulWidget — 값이 변하고 화면이 다시 그려져야 할 때
// React의 useState + setState 감각과 거의 판박이예요.

class LikeButton extends StatefulWidget {
  const LikeButton({super.key});
  @override
  State<LikeButton> createState() => _LikeButtonState();
}

class _LikeButtonState extends State<LikeButton> {
  int count = 0;                          // ← 이게 상태(state). React의 useState(0)

  @override
  Widget build(BuildContext context) {
    return ElevatedButton(
      onPressed: () {
        setState(() {                     // ← "상태 바꿨으니 다시 그려줘" 신호
          count++;                        //    (React의 setCount와 같은 역할)
        });
      },
      child: Text('좋아요 $count'),
    );
  }
}

⚠ count++만 하고 setState()를 감싸지 않으면? 값은 바뀌어도 화면이 안 바뀝니다.
   React에서 count = count + 1로는 재렌더가 안 되던 것과 완전히 똑같은 함정이에요.`;

const CODE_WHEN = `언제 Flutter를 고르나 — 상황별 감각 잡기

Flutter가 빛나는 경우
  ✓ 디자인을 픽셀까지 똑같이, 브랜드 UI를 강하게 통제하고 싶다
  ✓ 애니메이션·전환이 많은 화려한 화면 (자체 엔진이라 부드러움)
  ✓ 안드로이드/iOS를 하나의 코드로, 화면 차이 없이 내고 싶다
  ✓ 팀이 처음부터 배운다면 — Dart 하나로 통일된 경험

React Native가 더 어울리는 경우
  ✓ 이미 React/JS로 굴러가는 팀·코드가 있다 (지식 재사용)
  ✓ 화면을 각 OS의 '순정 느낌'에 최대한 맞추고 싶다
  ✓ npm 생태계·웹 인력을 그대로 모바일에 붙이고 싶다

둘 다 아닌 경우
  ✓ 카메라·센서·게임 등 성능을 극한까지 → 네이티브(Kotlin/Swift)
  ✓ 화면 몇 개짜리 정보성 앱 → 반응형 웹으로도 충분할 때가 많음`;

const CODE_OUR_VIEW = `우리 관점 — 냉정하게 손익 계산 (지금 우리 상황 기준)

우리가 이미 가진 자산(React)          Flutter를 택할 때의 비용
─────────────────────────────       ─────────────────────────────
· 프론트가 React로 돌아감              · Dart를 새 언어로 배워야 함
· 컴포넌트/상태/단방향 흐름에 익숙        · pub.dev 생태계를 새로 익힘
· Spring API를 이미 쓰고 있음           · 위젯 트리·빌드 컨텍스트 등
  (앱이 바뀌어도 서버는 그대로!)           Flutter 고유 개념 학습

옮겨 가는 지식(둘 다 공통)
  · "화면 = 상태의 함수" 사고방식은 그대로 통함
  · 컴포넌트(React) ↔ 위젯(Flutter)
  · useState/setState ↔ StatefulWidget/setState
  · props ↔ 생성자 매개변수

결론(과장 없이): "React를 배웠으니 개념의 8할은 이사 온다.
남는 2할이 Dart 문법과 위젯 트리." — 그래서 이 코스의 목표는
'Flutter 전문가'가 아니라 '지형을 읽고 필요할 때 갈 길을 아는' 것.`;

// ── 이 페이지 안에서만 쓰는 작은 부품들 ──
// 학습 포인트: 같은 모양이 반복되면 컴포넌트로 뽑는다. props만 바꿔 재사용.
// (React 입문 섹션 2에서 배운 걸 이 파일이 스스로 실천하는 중이에요.)
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: 'Flutter란' },
  { n: 2, label: 'RN과 비교' },
  { n: 3, label: 'Dart 맛보기' },
  { n: 4, label: '모든 게 위젯' },
  { n: 5, label: 'StatefulWidget' },
  { n: 6, label: '언제 고르나' },
  { n: 7, label: '우리 관점' },
];

export default function FlutterPage() {
  return (
    <div>
      {/* 히어로: 이 코스가 어디서 출발해 어디까지 가는지 */}
      <div className="hero">
        <div className="eyebrow">Course · 앱 개발</div>
        <h1>Flutter<br />— 또 하나의 크로스플랫폼</h1>
        <p>
          React Native가 유일한 길은 아니에요. Google의 <strong>Flutter</strong>는 전혀 다른
          방식으로 같은 목표(하나의 코드로 여러 OS)를 노립니다. 이 코스는 여러분이 배운
          <strong> React 지식을 다리 삼아</strong> Dart와 위젯을 읽고, "왜 도구가 둘이나
          있는지"와 "우리에게 무엇을 아끼고 무엇을 치르게 하는지"까지 — 지형을 읽는 걸
          목표로 합니다.
        </p>
        <div className="chip-row">
          <span className="chip">예상 소요 45분</span>
          <span className="chip">코드 예제 6개(읽기 위주)</span>
          <span className="chip">선수 지식: React 입문 · JS 기초</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="Flutter란" sub="Dart 언어 + 화면을 직접 그리는 자체 엔진">
        <p>
          <strong>Flutter</strong>는 Google이 만든 크로스플랫폼 UI 도구예요. 언어로는{' '}
          <span className="icode">Dart</span>를 쓰고, 하나의 코드로 안드로이드·iOS는 물론
          웹·데스크톱까지 화면을 낼 수 있게 하는 걸 목표로 합니다. 여기까지는 React
          Native와 비슷해 보이지만, <strong>결정적으로 다른 점</strong>이 하나 있어요.
        </p>
        <p>
          바로 <strong>화면을 그리는 방식</strong>입니다. 보통의 앱은 OS가 제공하는 '순정
          버튼·목록'을 빌려다 배치해요. 그런데 Flutter는 그걸 빌리지 않고,{' '}
          <strong>자체 렌더링 엔진</strong>(요즘은 <span className="icode">Impeller</span>,
          예전엔 <span className="icode">Skia</span>)이 버튼 모양까지 <strong>픽셀 단위로
          직접 그립니다</strong>. 남의 가구를 빌리는 대신 내 목공소에서 통째로 깎는 셈이죠.
        </p>
        <Code>{CODE_WHAT_IS}</Code>
        <div className="tip">
          <b>'직접 그린다'가 주는 것</b> 엔진이 화면을 통제하니 안드로이드와 iOS에서 UI가
          거의 똑같이 나오고, 애니메이션도 매끄럽게 뽑기 좋아요. 대신 "각 OS의 순정 느낌"과는
          살짝 멀어질 수 있습니다 — 이 트레이드오프가 섹션 2의 핵심이에요.
        </div>
      </Section>

      <Section n={2} title="React Native와 비교" sub="같은 목표, 정반대의 전략 — 그래서 둘 다 산다">
        <p>
          "이미 React Native가 있는데 왜 Flutter도 존재하지?" 이 질문의 답이 두 도구를
          이해하는 지름길이에요. 둘은 <strong>같은 목표(한 코드로 여러 OS)를 정반대의
          전략</strong>으로 풉니다.
        </p>
        <Code>{CODE_RN_COMPARE}</Code>
        <p>
          가장 큰 갈림길은 <strong>"OS 부품을 빌리느냐, 직접 그리느냐"</strong>예요.
          React Native는 자바스크립트로 지시를 내리면 <strong>진짜 네이티브 부품</strong>이
          화면에 놓입니다(그래서 각 OS 느낌에 가깝죠). Flutter는 부품을 빌리지 않고{' '}
          <strong>엔진이 다 그리니</strong> 어디서든 화면이 거의 동일합니다. 어느 쪽이
          '더 좋다'가 아니라, <strong>무엇을 아끼고 싶은가</strong>가 다른 거예요.
        </p>
        <div className="tip">
          <b>웹 개발자의 눈으로</b> React Native가 우리에게 가까운 이유는 단 하나 —{' '}
          <strong>언어와 사고방식(React)을 이미 안다</strong>는 점이에요. Flutter는 화면
          품질에서 강점이 있지만, 그 문 앞엔 <strong>Dart 학습</strong>이라는 통행료가
          있습니다. 이 통행료의 정체가 다음 섹션입니다.
        </div>
      </Section>

      <Section n={3} title="Dart 언어 맛보기" sub="JS를 알면 90%는 눈에 익는다">
        <p>
          Flutter의 언어 <strong>Dart</strong>는 Google이 만든 객체지향 언어예요. 다행히
          자바스크립트와 뿌리가 닮아서, <strong>JS를 안다면 문법의 대부분이 눈에 익습니다</strong>.
          크게 새로운 건 두 가지 — <strong>타입을 앞에 적는 것</strong>과{' '}
          <strong>널 안전성(null safety)</strong>이에요.
        </p>
        <Code>{CODE_DART}</Code>
        <p>
          <strong>널 안전성</strong>은 Dart의 자랑거리예요. 타입에{' '}
          <span className="icode">?</span>를 붙인 값만 <span className="icode">null</span>이 될
          수 있고, 나머지는 컴파일러가 "여긴 null이 올 수 없다"고 미리 보증합니다. JS에서
          그렇게 당하던 <span className="icode">undefined is not a function</span> 류의 사고를
          <strong> 실행 전에</strong> 막아 주는 안전벨트인 셈이죠.
        </p>
        <div className="warn">
          <b>실행 방식도 알아두면 좋아요</b> Dart는 개발 중엔 코드를 바로 실행(JIT)해{' '}
          <strong>핫 리로드(Hot Reload)</strong> — 저장하면 앱 상태를 유지한 채 화면만
          즉시 갱신 — 를 지원하고, 배포용으로는 <strong>기계어로 미리 컴파일(AOT)</strong>해
          빠르게 돕니다. React 개발의 HMR(저장 즉시 반영)과 느낌이 비슷해요.
        </div>
      </Section>

      <Section n={4} title="모든 게 위젯" sub="버튼도 여백도 정렬도 — 전부 위젯의 중첩(위젯 트리)">
        <p>
          React에서 화면이 <strong>컴포넌트</strong>의 조립이었다면, Flutter에서 화면은{' '}
          <strong>위젯(Widget)</strong>의 조립이에요. 그런데 Flutter의 위젯은 범위가 훨씬
          넓습니다. 버튼·글자는 물론이고 <strong>여백·정렬·간격 같은 '레이아웃'까지 전부
          위젯</strong>이에요. "모든 게 위젯"이 Flutter의 슬로건입니다.
        </p>
        <Code>{CODE_WIDGET}</Code>
        <p>
          위젯을 <strong>중첩</strong>해서 만든 구조를 <strong>위젯 트리</strong>라고 불러요.
          최상위 <span className="icode">MaterialApp</span>부터 아래로 화면 뼈대
          (<span className="icode">Scaffold</span>), 그 안의 상단바·본문, 다시 그 안의
          글자·버튼까지 — 큰 위젯이 작은 위젯을 품는 나무 구조입니다. React의 컴포넌트
          트리와 판박이라, 여러분에겐 낯설지 않을 거예요.
        </p>
        <svg className="diagram" viewBox="0 0 640 380" xmlns="http://www.w3.org/2000/svg" role="img" aria-label="Flutter 위젯 트리: 최상위 MaterialApp 아래 Scaffold, 그 아래 AppBar와 Column, 다시 그 아래 Text와 ElevatedButton, 버튼 아래 Text로 이어지는 중첩 구조. 잎에 해당하는 Text와 버튼은 초록 테두리로 강조.">
          <line x1="320" y1="54" x2="320" y2="86" stroke="var(--line)" strokeWidth="2" />
          <line x1="320" y1="124" x2="170" y2="160" stroke="var(--line)" strokeWidth="2" />
          <line x1="320" y1="124" x2="470" y2="160" stroke="var(--line)" strokeWidth="2" />
          <line x1="170" y1="198" x2="170" y2="250" stroke="var(--line)" strokeWidth="2" />
          <line x1="470" y1="198" x2="395" y2="250" stroke="var(--line)" strokeWidth="2" />
          <line x1="470" y1="198" x2="540" y2="250" stroke="var(--line)" strokeWidth="2" />
          <line x1="540" y1="286" x2="540" y2="322" stroke="var(--line)" strokeWidth="2" />
          <rect x="250" y="16" width="140" height="38" rx="8" fill="var(--card)" stroke="var(--primary)" strokeWidth="2" />
          <text x="320" y="40" textAnchor="middle" fontSize="13" fontWeight="600" fill="var(--ink)">MaterialApp</text>
          <rect x="250" y="86" width="140" height="38" rx="8" fill="var(--card)" stroke="var(--line)" />
          <text x="320" y="110" textAnchor="middle" fontSize="13" fill="var(--ink)">Scaffold</text>
          <rect x="95" y="160" width="150" height="38" rx="8" fill="var(--card)" stroke="var(--line)" />
          <text x="170" y="184" textAnchor="middle" fontSize="13" fill="var(--ink)">AppBar</text>
          <rect x="395" y="160" width="150" height="38" rx="8" fill="var(--card)" stroke="var(--line)" />
          <text x="470" y="184" textAnchor="middle" fontSize="13" fill="var(--ink)">Column</text>
          <rect x="95" y="250" width="150" height="36" rx="8" fill="var(--card)" stroke="var(--teal)" strokeWidth="2" />
          <text x="170" y="273" textAnchor="middle" fontSize="12" fill="var(--ink)">Text '미림 앱'</text>
          <rect x="335" y="250" width="120" height="36" rx="8" fill="var(--card)" stroke="var(--teal)" strokeWidth="2" />
          <text x="395" y="273" textAnchor="middle" fontSize="12" fill="var(--ink)">Text '안녕'</text>
          <rect x="470" y="250" width="150" height="36" rx="8" fill="var(--card)" stroke="var(--line)" />
          <text x="545" y="273" textAnchor="middle" fontSize="12" fill="var(--ink)">ElevatedButton</text>
          <rect x="470" y="322" width="150" height="34" rx="8" fill="var(--card)" stroke="var(--teal)" strokeWidth="2" />
          <text x="545" y="344" textAnchor="middle" fontSize="12" fill="var(--ink)">Text '좋아요'</text>
          <text x="626" y="150" textAnchor="end" fontSize="12" fill="var(--muted)">초록 = 잎 위젯(글자·버튼)</text>
          <text x="626" y="168" textAnchor="end" fontSize="12" fill="var(--muted)">위 → 아래로 중첩</text>
        </svg>
        <p className="muted" style={{ fontSize: 12.5, textAlign: 'center', marginTop: 2 }}>그림: Flutter 위젯 트리 — MaterialApp에서 Text·버튼까지 위젯이 위에서 아래로 중첩된다(React 컴포넌트 트리와 같은 구조)</p>
        <div className="tip">
          <b>React와 나란히 두기</b> <span className="icode">build()</span> 메서드가 React의{' '}
          <span className="icode">return (JSX)</span> 자리이고, 위젯 중첩이 JSX 태그 중첩이에요.
          다만 여백을 CSS <span className="icode">margin</span>으로 주는 대신{' '}
          <span className="icode">SizedBox</span> 같은 <strong>위젯</strong>으로 준다는 점만
          새롭습니다. "스타일도 위젯"이라는 감각에 익숙해지는 게 첫 관문이에요.
        </div>
      </Section>

      <Section n={5} title="상태관리 개요 — StatefulWidget" sub="useState/setState를 이미 안다면 절반은 끝">
        <p>
          위젯은 두 종류예요. 값이 안 변하는 <strong>StatelessWidget</strong>(React의 순수
          컴포넌트)과, 값이 변하고 그때마다 화면을 다시 그려야 하는{' '}
          <strong>StatefulWidget</strong>입니다. 좋아요 버튼처럼 <strong>클릭할 때마다 숫자가
          바뀌는</strong> 화면이 바로 후자예요.
        </p>
        <Code>{CODE_STATEFUL}</Code>
        <p>
          핵심은 <span className="icode">setState()</span>입니다. 상태 변수(위 예제의{' '}
          <span className="icode">count</span>)를 그냥 바꾸기만 하면 화면은 꿈쩍도 안 해요.
          변경을 <span className="icode">setState(() =&gt; ...)</span>로 <strong>감싸야</strong>{' '}
          Flutter가 "이 위젯 다시 그려야겠구나" 하고 <span className="icode">build()</span>를
          다시 부릅니다. React에서 <span className="icode">count = count + 1</span>로는 재렌더가
          안 되고 꼭 <span className="icode">setCount()</span>를 불러야 했던 것과{' '}
          <strong>완전히 같은 원리</strong>예요.
        </p>
        <div className="warn">
          <b>이 함정, 어디서 봤죠?</b> React 입문 섹션 4의 "직접 바꾸면 화면이 안 바뀐다"가
          여기서 그대로 반복돼요. 이름만 <span className="icode">setCount</span> →{' '}
          <span className="icode">setState</span>로 바뀌었을 뿐, <strong>"상태 변경은 반드시
          정해진 함수를 통해"</strong>라는 규칙은 동일합니다. 개념이 이사 온다는 게 이런 뜻이에요.
        </div>
        <div className="tip">
          <b>참고</b> 앱이 커지면 <span className="icode">setState</span>만으로는 벅차서{' '}
          Provider·Riverpod·Bloc 같은 상태관리 도구를 얹습니다. React에서 규모가 커지면
          Context나 Redux 계열을 찾는 것과 같은 흐름이에요 — 지금은 "그런 게 있다" 정도만
          알아 두면 충분합니다.
        </div>
      </Section>

      <Section n={6} title="언제 Flutter를 고르나" sub="정답은 상황이 정한다 — 도구는 목적의 함수">
        <p>
          도구 선택은 유행이 아니라 <strong>상황</strong>이 정해요. Flutter가 강한 자리와,
          오히려 다른 선택이 나은 자리를 나눠 두면 판단이 쉬워집니다.
        </p>
        <Code>{CODE_WHEN}</Code>
        <p>
          한 줄 요약: <strong>"디자인·애니메이션을 픽셀까지 통제하고 싶다"면 Flutter가,
          "React/JS 자산을 그대로 잇고 싶다"면 React Native가</strong> 유리해요. 그리고
          잊지 말 것 — 화면 몇 개짜리라면 <strong>반응형 웹</strong>으로 충분한 경우도 많고,
          센서·게임처럼 성능이 극한으로 필요하면 <strong>네이티브</strong>(Kotlin/Swift)가
          답일 수 있습니다. 크로스플랫폼이 항상 정답은 아니에요.
        </p>
        <div className="tip">
          <b>수습생용 판단 훈련</b> 새 앱 아이디어가 생기면 스스로 물어보세요. ① 화면 품질을
          얼마나 통제하고 싶나? ② 우리 팀이 이미 아는 언어는? ③ 웹만으로는 왜 안 되나?
          이 세 질문의 답을 적어 보는 것만으로도, "무작정 유명한 걸 고르는" 실수를 피할 수
          있어요.
        </div>
      </Section>

      <Section n={7} title="우리 관점 — React 자산 vs Dart 학습비용" sub="과장 없이, 손익을 계산해 본다">
        <p>
          마지막으로 <strong>우리 상황</strong>에 붙여 봅시다. 사실부터 정확히 — 우리
          플랫폼의 프론트엔드는 <strong>React</strong>이고, 서버는 <strong>Spring Boot</strong>예요.
          지금 이 학습 페이지도 React로 그려지고 있죠. 즉 우리에겐 이미 <strong>React라는
          자산</strong>이 있고, Flutter는 <strong>Dart라는 새 학습비용</strong>을 요구합니다.
        </p>
        <Code>{CODE_OUR_VIEW}</Code>
        <p>
          중요한 건 <strong>서버는 그대로라는 점</strong>이에요. 앱을 React Native로 짜든
          Flutter로 짜든, 데이터는 여전히 우리 <strong>Spring API</strong>에 요청해서
          받아옵니다("네트워크의 이해" 코스에서 배운 그 요청 그대로!). 그러니 앱 도구를
          고르는 일은 <strong>'화면을 무엇으로 그릴까'의 문제</strong>이지, 백엔드를 다시
          짜는 일이 아니에요.
        </p>
        <div className="warn">
          <b>과장 금지 — 이 코스가 약속하는 것</b> 2개월 만에 여러분을 "네이티브 앱
          전문가"로 만들어 주지 않아요. 그건 정직하지 않은 약속입니다. 대신 이 코스는{' '}
          <strong>지형을 읽는 눈</strong>을 줍니다. React·RN·Flutter가 각각 무엇을 아끼고
          무엇을 치르는지 알면, 필요할 때 <strong>여러분의 실력으로 그 길을 걸어갈</strong>{' '}
          수 있어요. "길을 아는 것"과 "이미 다 걸은 것"은 다르지만, 길을 알면 반드시 도착합니다.
        </div>
        <div className="tip">
          <b>다음으로</b> 도구가 무엇이든, 화면이 여러 개가 되는 순간 공통으로 마주치는 문제가
          있어요 — <strong>"이 화면에서 저 화면으로 어떻게 넘어가지?"</strong> 그게 다음
          코스의 주제입니다.
        </div>
      </Section>

      <div className="step-card">
        <div className="step-body">
          <h3 style={{ marginBottom: 6 }}>🧭 지형이 조금 보이기 시작했다면</h3>
          <p className="muted">
            이제 여러분은 크로스플랫폼에 <strong>React Native만 있는 게 아니라는 것</strong>,
            그리고 Flutter가 <strong>Dart와 위젯, 직접 그리는 엔진</strong>으로 다른 길을
            간다는 걸 설명할 수 있어요. 무엇보다 여러분이 배운 <strong>React의 상태·컴포넌트
            개념이 그대로 이사 온다</strong>는 것도요. 어떤 도구를 고르든 화면이 여러 개가
            되면 반드시 필요한 것 — 화면 간 이동, 즉{' '}
            <Link to="/learn/app-navigation"><strong>앱 내비게이션</strong></Link> 코스에서
            "이 화면에서 저 화면으로" 넘어가는 길을 이어서 배워 봅시다.
          </p>
        </div>
      </div>
    </div>
  );
}
