https://www.youtube.com/watch?v=I4k1dJzzuYs
description: |-
1. 이건 꼭 알아야 한다^1
[? 질문] 플러터(Flutter)는 무엇이며, 왜 배우는가^2
[= 답] 플러터는 구글이 만든 앱 개발 프레임워크로, 한 번의 코딩으로 **안드로이드와 iOS(더 나아가 데스크탑까지)**에 배포하는 크로스 플랫폼 개발을 목표로 하며, 빠른 실행 속도(네이티브 코드로 전환), 자체 UI 위젯, 핫 리로딩 같은 생산성 기능 때문에 배울 가치가 있다고 설명한다.^2^53
[? 질문] 모바일 앱 개발 방식(네이티브/하이브리드/크로스 플랫폼)은 어떻게 구분되며 각각의 특징은 무엇인가^15
[= 답] 네이티브는 OS별 전용 도구/언어로 개발(안드로이드=Android Studio+Java/Kotlin, iOS=Xcode+Objective-C/Swift)하고, 하이브리드는 웹(HTML 등) UI + 네이티브 컨테이너의 혼합이며, 크로스 플랫폼은 한 코드로 여러 플랫폼에 배포하는 방식으로(React Native, Xamarin Forms, Flutter 등) 구분된다고 정리한다.^15^26^42
[? 질문] 플러터의 장단점은 무엇인가(특히 초심자가 두려워하는 지점 포함)^47
[= 답] 장점은 빠른 속도, 네이티브 코드로의 변환, 자체 위젯 제공, CLI, 핫 리로딩 등이고, 단점은 Dart라는 새 언어 학습 부담과 앱 용량이 네이티브보다 평균 약 40% 크다는 점을 든다(다만 용량 단점은 실제 사용에서 큰 문제는 아닐 수 있다고 덧붙인다).^47^55^60
2. 큰 그림^2
이 콘텐츠는 플러터를 처음 시작하는 초급자를 대상으로, 본격적인 실습에 앞서 모바일 앱 개발 환경과 방식의 전체 지형(OS 구도, 네이티브/하이브리드/크로스 플랫폼 차이)을 먼저 설명하고, 그 흐름 속에서 플러터의 위치와 장단점을 이해시키는 도입 강의이다.^3^47
- 학습 로드맵/목표: 약 10개월 과정을 통해 앱스토어/플레이스토어에 등록 가능한 수준의 앱 제작을 목표로 한다.^5
- 모바일 개발 방식의 구분: 네이티브, 하이브리드, 크로스 플랫폼으로 나누고(요즘은 주로 네이티브 vs 크로스 플랫폼 중심), 각각 도구/언어/특성을 비교한다.^15
- 플러터 선택 이유: 크로스 플랫폼 중에서도 실행 속도(네이티브 변환), 자체 위젯, 핫 리로딩 같은 개발 효율이 강점이며, Dart 학습과 앱 크기 증가 같은 단점도 함께 제시한다.^47^55
3. 하나씩 살펴보기^1
3.1 강의 시작: 초급자 대상, 전체 과정 기획과 목표^1
강사는 “플러터 처음 시작하는 초급자 과정”을 시작한다고 선언하며, 이 파트는 플러터 자체로 곧장 들어가기 전에 개발 환경의 큰 범주를 먼저 짚고 들어가겠다고 말한다.^1 이는 학습자가 플러터가 “어떤 세계 안에서 어떤 자리에 있는지”를 먼저 이해하도록 만들기 위한 전개다.^3
이어서 전체 커리큘럼의 큰 기간을 소개한다.^4 처음에는 “초급 3개월 + 중급 3개월 + 실전 프로젝트 4개월”로 설명하다가, 계산을 다시 하며 총 기간이 약 10개월이라고 바로잡는다.^4^6 그리고 이 기간 동안의 목표를 “일반 앱스토어나 플레이스토어에 등록할 수 있는 수준의 앱을 만드는 것”이라고 명확히 한다.^7
또한 정말 ‘초급’에 맞게 프로그래밍 지식이 전혀 없다는 전제로 진행하겠다고 강조한다.^8 다만 대부분의 수강자들은 이미 언어나 툴을 1~2개 정도는 접해봤을 수 있으며, 초반부에 중복되는 내용이 나오더라도 “복습한다는 생각으로 가볍게 따라오라”고 안내한다.^9^11
[!IMPORTANT] 초급자 설계의 전제^8 이 강의 파트는 “전혀 프로그램 지식이 없다”는 가정에서 출발하며, 도입부는 모바일 개발의 큰 구조를 이해시키는 데 시간을 쓴다.^3
3.2 ‘Flutter’라는 이름/의미와 정체(프레임워크, 구글 제작)^12
강사는 먼저 “플러터”라는 발음을 확인하며, 영어 읽기로 “Flutter(플러터)”라고 소개한다.^12 단어 뜻은 “펄럭이다”라는 의미라고 설명하며, 느낌을 전달한다.^14
그 다음 플러터의 정체를 “개발 프레임워크”로 정의하고, “구글에서 만든 프레임워크”라고 출처를 명시한다.^2 또한 이 기술을 어디에 주로 쓰느냐는 질문을 던지며, “주로 모바일(및 웹) 개발 쪽에 많이 있다”는 방향으로 사용처를 연결한다.^15
[? 질문] 플러터라는 이름은 무엇을 뜻하나^14
[= 답] “Flutter”는 “펄럭이다”라는 뜻이며, 강의에서는 플러터의 명칭 의미를 가볍게 짚고 넘어가며 용어 친숙도를 높인다.^14
3.3 모바일 OS 시장 구도: 사실상 안드로이드 vs iOS^17
강사는 모바일 앱 개발을 이해하려면 먼저 “모바일 OS”를 봐야 한다고 전개한다.^17 모바일 OS는 여러 가지가 있지만, 현재 시장은 사실상 두 OS가 나눠 먹는 구조라고 말한다.^19
그 두 축은 **안드로이드(Android)**와 iOS다.^20 안드로이드는 삼성 등 다수가 사용하는 안드로이드 폰의 OS이고, iOS는 아이폰(및 맥 계열과 연결되는 애플 생태계)의 OS라고 설명한다.^21
여기서 핵심은, 모바일 앱 개발을 논할 때 대상 플랫폼이 대부분 **두 진영(안드로이드/애플)**이라는 점이며, 이후 “개발 방식” 논의가 이 구도를 기반으로 전개된다.^19
3.4 모바일 앱 개발 ‘방식’의 구분: 네이티브 vs 하이브리드 vs 크로스 플랫폼^23
강사는 모바일에서 앱을 개발하는 운영 방식(개발 방식)을 크게 세 가지로 나눌 수 있다고 말한다.^23 다만 “요즘은 거의 두 가지로 많이 추렸다”고 덧붙이는데, 그 이유는 현장에서 네이티브와 (광의의) 크로스 플랫폼/하이브리드가 중심축으로 인식되기 때문이라는 뉘앙스로 진행한다.^24
먼저 전통적인 구분으로는 네이티브 앱 vs 하이브리드 앱이 많이 언급되어 왔다고 말한다.^25 그리고 “요즘 하나가 더 나왔다”며 추가 축을 꺼내는데, 그것이 크로스 플랫폼이다.^27 또한 현장에서는 크로스 플랫폼을 하이브리드 쪽으로 “혼합”해서 부르기도 하지만, 엄밀히는 하이브리드와 다르며 “정확히 말하자면 하이브리드는 아니고 크로스 플랫폼”이라고 용어를 정리한다.^28
[!NOTE] 용어 혼용 경고^28 강의에서는 “하이브리드”라는 말이 크로스 플랫폼까지 섞여 불리기도 하지만, 정확히는 별개로 구분해야 한다고 선을 긋는다.^28
3.5 네이티브 개발: OS별 도구/언어가 갈린다 (Android Studio/Xcode, Java·Kotlin/Objective‑C·Swift)^30
네이티브 개발 방식의 핵심은 “운영체제별로 네이티브 개발 환경이 달라진다”는 점이라고 한다.^30 앞서 시장이 안드로이드와 iOS로 나뉘었으므로, 네이티브 개발도 사실상 두 갈래로 갈라진다.^31
안드로이드 네이티브 개발 도구/언어^33
- 개발 도구: 강사는 안드로이드에서 가장 많이 쓰는 것이 Android Studio라고 말한다.^33 이는 IntelliJ 계열을 구글이 라이선스 형태로 가져와 제공하는 배경을 언급하며, 무료로 제공된다는 취지로 설명한다.^34
- 개발 언어: “기본으로 Java를 썼었다”고 말한 뒤, 최근에는 Java의 라이선스 문제가 있어 구글이 Kotlin을 밀고 있다고 설명한다.^36
iOS 네이티브 개발 도구/언어, 역사적 배경^38
- 개발 도구: iOS(아이폰 계열)에서는 개발 도구로 Xcode를 많이 쓴다고 정리한다.^38
- 개발 언어(과거~현재):
- 과거 중심: Objective‑C를 오랫동안 사용해 왔다고 말하며, 역사가 “약 35년 이상”으로 매우 오래됐다고 강조한다.^39
- 역사/사례: 스티브 잡스가 애플에서 쫓겨났을 때 만들었던 NeXT 컴퓨터, 그때 만든 **NeXTSTEP(유닉스 기반, X 윈도우처럼 화면이 나오는 형태)**가 당시 혁신적이었지만 상용화에는 실패했다는 이야기를 곁들인다.^41^43 그럼에도 이후 잡스가 애플로 복귀한 뒤에도 그 흐름이 발전하며 Objective‑C가 이어져 왔다는 서사를 덧붙인다.^44
- 현재 지향: Objective‑C가 “너무 어렵다”는 문제의식에서 더 편리한 언어로 Swift가 등장했다고 설명한다.^45
결과적으로 네이티브 진영은 안드로이드(Java/Kotlin) vs iOS(Objective‑C/Swift)로 “양 진영이 완전히 갈라진다”고 정리하며, 네이티브의 학습/개발 난이도가 높게 느껴질 수 있음을 암시한다.^46
3.6 하이브리드 방식: 웹 기술 + 네이티브 컨테이너의 ‘혼합’^47
강사는 네이티브 개발이 쉽지 않았던 배경(자바/오브젝트C 기반 개발의 어려움)을 언급하며, 웹 붐과 모바일 붐 속에서 “웹 화면을 그대로 옮길 수 없겠느냐”는 요구가 하이브리드 방식으로 이어졌다고 설명한다.^48
하이브리드의 정의는 “웹 기술과 네이티브 기술을 섞어 놓은 것”이라고 한다.^49 구체적으로:
- 화면(UI)은 “대부분 외부로 만든다”고 하며, 다시 말해 HTML로 주로 만든다고 표현한다.^50
- 네이티브가 하는 일은, HTML을 보여주기 위한 “브라우저 같은 컨테이너”를 네이티브로 만드는 것이라고 설명한다.^51
- 앱 실행 시 동작: 네이티브 앱이 실행되면서 URL로 외부 HTML을 가져오거나, 또는 앱 내부의 로컬 HTML을 읽어 화면을 구성할 수 있다고 말한다.^52
그래서 “혼합(웹+네이티브)”이란 의미로 하이브리드라는 명칭이 생겼다고 다시 한 번 용어의 이유를 확인한다.^53
[? 질문] 하이브리드에서 ‘하이브리드’는 무엇의 혼합인가^49
[= 답] 웹 기술(주로 HTML 기반 UI)과 네이티브 기술(HTML을 담는 컨테이너/브리지 역할)을 섞어 만든 방식이기 때문에 ‘혼합’이라는 의미로 하이브리드라고 부른다.^49^53
3.7 하이브리드의 장점/단점: 개발 속도 vs 성능·네이티브 UX^54
강사는 하이브리드 방식의 장단점을 표로 보듯이 구두로 정리한다.^54
장점^55
단점: 성능과 UX/네이티브 UI의 괴리^57
단점은 반드시 존재하며, 그중 “항상 문제시되는 게 성능(속도)”이라고 강조한다.^57
또한 네이티브 앱에는 OS별로 공통적으로 기대되는 고유 UI 디자인/컴포넌트 경험이 있는데(예: 콤보박스, 드롭다운 리스트, 체크박스, 스위치 등), 웹의 디폴트 UI는 그것과 다르다고 지적한다.^59
OS와 상관없이 동일한 UI를 보여주는 것은 장점이 될 수 있지만, 실제 사용자는 iOS면 iOS 특유의 UX, 안드로이드면 안드로이드 특유의 UX를 기대하기 때문에 만족을 못 할 수 있다고 설명한다.^61
더 큰 프로젝트로 가면 페이지를 매번 읽어오는 방식에서 성능 문제가 더 두드러질 수 있고, 통신 문제(데이터 통신량 등)도 있을 수 있다고 덧붙인다.^63
[!WARNING] 하이브리드의 반복 지적 포인트^57 강의에서 하이브리드의 대표 단점은 “속도/성능”이며, 프로젝트가 커질수록 페이지 로딩/통신 부담이 문제로 나타날 수 있다고 말한다.^57^64
3.8 하이브리드 프레임워크 예시: Ionic(아이오닉)의 특징(Angular, UI, 라이브 리로딩, 개발 서버, CLI, 커뮤니티)^65
강사는 하이브리드 개발 프레임워크가 여러 가지 있지만 대표적으로 **Ionic(아이오닉)**을 짚어 보자고 한다.^65
아이오닉의 장점^67
- 풍부한 UI 제공을 장점으로 든다.^67
- HTML 기반이며, 더 정확히는 Angular 기반이라고 설명한다.^68
- 따라서 기존에 Angular로 **싱글 페이지 애플리케이션(SPA)**을 하던 사람에게 유리하다고 말한다.^69
- 라이브 리로딩(live reloading) 기능이 있으며, 코딩한 내용이 실행 화면에 실시간 반영된다고 설명한다.^70
- 내장 개발 서버를 제공하여 외부에 별도 서버를 둘 필요 없이 자체적으로 가능하다고 한다.^76
- CLI(Command Line Interface) 지원: 커맨드라인에서 한 줄씩 타이핑해 결과값을 바로 보는 방식이 가능하고, 간단한 디버깅/테스트 용도로 유용하다고 설명한다.^77
- 커뮤니티 규모: 사용자가 많아 대규모 커뮤니티가 존재하며, 개발 중 막히는 것은 구글 검색하면 대개 나온다는 식으로 커뮤니티의 실용적 장점을 설명한다.^79
아이오닉의 단점^81
단점은 “아까랑 똑같이 속도(성능)”라고 다시 정리한다.^81
[!TIP] 라이브 리로딩이 개발 생산성에 미치는 영향^70 강의에서는 UI 작업에서 “코드 수정 → 즉시 화면 반영”이 되지 않으면 컴파일/실행 반복으로 시간이 크게 늘어나며, 라이브 리로딩이 개발 시간을 극적으로 줄인다고 설명한다.^72
3.9 크로스 플랫폼의 의미: 한 번 코딩해서 여러 플랫폼에 배포^82
강사는 크로스 플랫폼이 비교적 “오래되지 않았다”는 인식이 있을 수 있다고 말하며(언어/기술은 있었지만 사용자에게 널리 알려진 건 상대적으로 최근이라는 취지), 먼저 의미를 정의하자고 한다.^82
크로스 플랫폼이란 “한 번 코딩으로 여러 곳에 사용”한다는 의미라고 설명한다.^84 즉 한 번 만들어서 iOS와 안드로이드에 모두 설치할 수 있고, 동시에 개발 가능하다는 것이다.^85 더 나아가 요즘은 데스크탑까지 하나로 배포되는 흐름도 언급한다.^86
강사는 이런 점이 “되게 좋겠죠”라고 반응을 유도하면서도, 크로스 플랫폼 역시 장단점이 있다고 말하며 다음 비교로 넘어간다.^87
[? 질문] 크로스 플랫폼이란 정확히 무엇인가^84
[= 답] 한 번의 코딩으로 iOS/안드로이드(더 나아가 데스크탑 등) 여러 플랫폼에 배포/사용하는 개발 방식이다.^84
3.10 크로스 플랫폼 시장/종류: React Native, Xamarin Forms, Flutter의 구도와 배경(회사/기반기술)^89
강사는 크로스 플랫폼 영역에서 현재 시장을 많이 차지한 것은 React Native라고 말하며, Flutter는 후발주자라고 설명한다.^89 또 MS 계열에는 Xamarin(자마린) Forms가 있다고 소개한다.^91
정리하면 유명한 축이 대략 세 가지라고 제시한다.^92
- React Native: “리액트인데 네이티브 버전”이라고 설명하며, 리액트를 했던 사람에게 유리하다고 말한다.^93 다만 “복잡하다”는 평가를 덧붙인다.^95
- Xamarin Forms: MS 계열이고, 꽤 많이 쓰인다고 말한다.^96
- Flutter: “우리가 배울 것”이며 후발주자라고 재강조한다.^98
또한 각 기술의 기반을 대략적으로 이렇게 연결한다:
- React Native는 “말 그대로 HTML 기반이라고 보면 되고 타입스크립트 기반”이라는 식으로 웹/JS 생태계 연관성을 강조한다.^99
- Xamarin Forms는 C# 기반으로 보면 된다고 설명한다.^100
그리고 회사/진영 구도도 언급한다: (강의에서) 리액트 네이티브는 페이스북, 자마린은 MS, 플러터는 구글로 나눠 보면 된다고 말한다.^101
+++ 상세 보충: 강의 내 표현의 맥락 강의에서는 React Native를 “HTML 기반, TypeScript 기반”으로 설명하는데, 이는 React Native의 개발 경험이 웹 프론트엔드(React/JS·TS)와 연결된다는 “학습/생태계 관점”의 설명으로 들린다.^99 +++
3.11 Flutter(플러터)의 강점: 속도(네이티브 코드 변환), 자체 위젯, CLI, 핫 리로딩^103
이제 강사는 “우리는 다 배울 건 아니고 플러터만 볼 것”이라며, 플러터 중심으로 장점을 구체화한다.^103
(1) 빠른 속도와 네이티브 코드 변환^105
플러터의 “가장 좋은 점”으로 일단 속도가 빠르다고 말한다.^105 여기서 말하는 속도는 “실행 속도”라고 уточ한다.^106
그 이유로 “완전 네이티브 코드로 전환된다”고 설명한다.^107 즉 개발자가 짠 플러터 코드가 최종적으로 네이티브로 변환되어 돌아간다는 의미라고 한다.^108 예시로 iOS에서는 Xcode 쪽 네이티브로 전환되어 실행된다고 이해하면 된다고 말한다.^109
(2) 자체 위젯(컴포넌트) 제공^110
플러터는 “자체 위젯을 제공”한다고 말하며, 플러터에서는 UI 구성 단위를 “위젯(widget)”이라고 부른다고 소개한다.^110
또한 “컴포넌트라고 생각해도 된다”, 같은 단어라는 식으로 용어를 연결한다.^112
위젯/컴포넌트는 결국 “화면 UI를 갖는 라이브러리”로 보면 된다고 설명한다.^113
(3) 퓨시아(Fuchsia) OS 언급: 구글의 또 다른 OS와 플러터^114
강사는 흥미 요소로, 구글이 안드로이드 말고 모바일 OS를 하나 더 만들고 있다는 이야기를 꺼낸다.^114 그 OS가 **Fuchsia(퓨시아)**라고 하며, 안드로이드 같은 OS이고 PC와 호환된다는 이야기를 덧붙인다.^115 (이 맥락은 플러터가 구글 생태계와 맞물려 확장될 가능성을 암시하는 흐름이다.)^114
(4) CLI 지원^117
플러터도 CLI가 제공된다고 말하며, 커맨드라인에서 한 줄씩 타이핑해 바로 실행/결과를 볼 수 있다고 설명한다.^117
(5) 핫 리로딩(Hot Reloading) 제공과 개발 시간 단축^119
강사는 플러터가 핫 리로딩을 제공한다고 말한다.^119 즉 개발 화면에서 타이핑하면 실행 화면에 바로 반영된다는 것이다.^120
이는 앞서 아이오닉의 라이브 리로딩과 같은 생산성 포인트로, 개발 시간이 “엄청나게 단축”된다고 다시 강조한다.^121
여기서 강사는 개인 경험을 덧붙인다: 본인은 React Native는 써보지 않았지만, Xamarin Forms에서도 핫 리로딩 기능이 일부 제공되긴 하나 “완벽히 제공되지는 않는다”고 말한다.^122 특히 외부 라이브러리를 쓰면 제공이 안 되는 경우가 있다고 한다.^124 그래서 Xamarin의 핫 리로딩은 “돈 주고 샀다”는 언급을 하며, 그만큼 개발 시간 단축 효과가 크다고 강조한다.^125 반면 플러터는 기본 제공이라 “너무 좋다”고 평가한다.^127
그리고 다시 한 번 “이게 없으면 개발 시간이 몇 배 더 길어진다”고 못 박으며, 핫 리로딩을 매우 중요한 장점으로 강조한다.^128
[!IMPORTANT] 플러터의 생산성 장치: 핫 리로딩^119 “타이핑 즉시 화면 반영”은 UI 개발에서 반복 실행/컴파일을 줄여 개발 시간을 크게 단축하며, 강사는 이것이 없으면 개발 시간이 몇 배 늘어난다고까지 말한다.^120^128
3.12 Flutter의 단점: Dart 학습 부담, 앱 크기(네이티브 대비 평균 40% 증가)와 그 해석^129
강사는 장점만 있을 수 없으니 단점도 보자며 플러터의 단점을 정리한다.^129
(1) 새로운 언어 Dart의 학습 부담^131
첫 번째로, 플러터는 자바나 C# 같은 익숙한 언어가 아니라 **Dart(다트)**라는 언어를 “새로 배워야 한다”는 점이 부담이라고 말한다.^131 개발 언어는 이미 매우 많은데 또 하나를 배워야 한다는 심리적 장벽을 언급한다.^133
다만 바로 완화 설명을 덧붙인다. Dart의 첫인상은 “거의 자바”, 혹은 “C/C#과 거의 다 똑같다”고 말하며, 전혀 생소하지 않다고 한다.^134
또한 Dart 진영에서 “자바나 C를 해온 사람은 1시간이면 배운다”는 말이 있다고 전하며(물론 그 1시간은 기초 수준이라는 단서를 붙임), 대략 “한 80%는 너무 편하게 먹고 들어간다”는 식으로 진입 장벽을 낮춰 설명한다.^136^138
[? 질문] 다트(Dart)는 얼마나 낯선가, 초심자/기존 개발자에게 부담인가^131
[= 답] 새 언어라는 점에서 부담이지만, 문법/인상이 자바·C계열과 매우 비슷해 전혀 생소하지 않고, 자바/C 경험자는 기초를 빠르게 익힐 수 있다고 설명한다.^134
(2) 앱 용량 증가: 네이티브 대비 평균 40% 더 큼^139
두 번째 단점으로 앱의 크기를 든다.^139 강사는 “네이티브 앱보다 평균 약 40% 정도 사이즈가 더 크다”고 수치를 제시한다.^140
그러나 이 단점의 “의미”를 평가하며, 실제로는 큰 의미가 없을 수 있다고 덧붙인다.^141 예를 들어 네이티브로 10MB가 나왔으면 플러터는 13MB 정도 나온다는 계산으로 설명한다.^142 사용자들이 이 차이로 크게 클레임을 걸지는 않을 것 같다고 말하며, 이유는 “한 번 설치하고 실행하는 것”이기 때문이라고 한다.^143
만약 매번 실행할 때마다 10MB를 다운로드해야 하고 플러터는 13MB를 매번 받아야 한다면 문제가 달라지겠지만, 일반적인 앱 설치/실행 맥락에서는 “한 번 설치하면 끝”이므로 이 단점은 결정적이지 않을 수 있다는 견해를 제시한다.^145
[!NOTE] ‘40% 용량 증가’의 맥락적 해석^140 강의는 플러터 앱 크기가 네이티브보다 평균 40% 크다는 수치를 말하면서도, 설치 1회성이므로 사용자 불만으로 직결되진 않을 수 있다고 해석한다.^140^146
3.13 (비교 언급) React Native: 커뮤니티와 복잡성^147
강사는 “리액트 얘기도 좀 있긴 한데 우리가 직접 배울 건 아니”라며 짧게만 언급한다.^147 React Native는 플러터보다 먼저 보급되어 커뮤니티가 발달했고, 페이스북 지원을 받으며, 리액트 인터페이스 등을 그대로 쓰다 보니 사용자층 확보가 쉬웠다고 말한다.^148
하지만 “되게 복잡하다”고 평가하며, 결론적으로 “리액트도 있다 정도로 보면 될 것”이라고 정리한다.^150
3.14 마무리: 다음 파트 예고(플러터를 구체적으로 살펴보기)^152
강사는 이번 영상에서 모바일 개발 환경(네이티브/하이브리드/크로스 플랫폼)을 먼저 살펴봤고, 다음에는 “플러터 하나에 대해서 구체적으로 살펴보겠다”고 예고하며 마무리한다.^152
4. 핵심 통찰^15
- [h 플러터를 배우기 전에 ‘모바일 개발 방식 지도(네이티브/하이브리드/크로스 플랫폼)’를 먼저 잡는 것이 학습 효율을 높인다] 강의는 플러터 소개 전에 OS 구도와 개발 방식의 차이를 길게 설명하며, 플러터의 장점이 “무엇과 비교해 어떤 맥락에서 좋은지”를 이해시키려 한다.^3^47
- [h 네이티브 개발의 본질적 비용은 ‘플랫폼 분리’에서 온다] 안드로이드와 iOS가 지배하는 시장에서, 네이티브는 도구와 언어가 갈라져(Android Studio/Java·Kotlin vs Xcode/Objective‑C·Swift) 학습·유지 비용이 커진다.^30^38
- [h 하이브리드는 ‘웹 재사용’으로 속도를 얻는 대신 성능과 네이티브 UX 일관성을 잃을 수 있다] 웹 UI를 HTML로 만들고 네이티브는 컨테이너 역할을 하는 구조는 빠른 개발을 주지만, 성능과 OS 고유 UI/UX 기대치를 충족시키기 어렵다는 지적이 나온다.^49^57
- [c 크로스 플랫폼의 핵심 가치는 “한 번 코딩해 여러 플랫폼 배포”라는 구조적 이득이다] 강의는 크로스 플랫폼의 정의 자체가 곧 장점이라고 말하며, iOS/안드로이드 동시 개발 및 데스크탑 확장 가능성까지 연결한다.^84^87
- [h 플러터의 차별점은 “네이티브 변환 기반의 속도”와 “위젯 중심 UI”에 더해 “핫 리로딩” 같은 개발 경험이다] 실행 속도(네이티브 변환)와 함께, UI를 위젯으로 구성하고 핫 리로딩으로 반복 비용을 줄이는 것이 강조된다.^105^119
- [m ‘새 언어(Dart)’의 심리적 장벽은 존재하지만, 기존 자바/C 계열 경험자에게는 완화된다] 새 언어 부담을 인정하면서도 문법 유사성(자바·C#과 비슷)으로 진입장벽이 낮다고 설득한다.^131^136
- [m 앱 크기 증가(평균 40%)는 숫자로는 단점이지만, 사용 맥락(설치 1회)에서는 치명적이지 않을 수 있다] 강의는 10MB→13MB 예시로 체감 영향을 재해석한다.^140^146
실행 시사점(강의 흐름을 따라 실제 행동으로 옮기면):
- 네이티브/하이브리드/크로스 플랫폼을 비교 표로 직접 정리해 보고, 본인이 만들 앱의 요구(성능, UI/UX, 개발 속도, 인력 구성)에 맞춰 선택 기준을 세운다.^23^84
- 플러터 학습 전, “Dart가 새 언어”라는 두려움은 문법 유사성을 염두에 두고 빠르게 기초 문법을 훑는 방식으로 진입 장벽을 낮춘다.^134
- 핫 리로딩과 CLI 같은 개발 생산성 기능을 실제 설치/실행 환경에서 체감하는 것이 학습 동기 유지에 도움이 된다.^117^121
5. 헷갈리는 용어 정리 (해당 시에만)^15
네이티브 앱(Native App): OS별 전용 개발 도구/언어로 만드는 앱. 안드로이드는 Android Studio와 Java/Kotlin, iOS는 Xcode와 Objective‑C/Swift 같은 구성이 예로 제시된다.^30^36^45
하이브리드(Hybrid): 웹 기술(주로 HTML 기반 UI)과 네이티브 기술(웹을 담는 컨테이너)을 혼합한 방식. 앱 실행 시 URL로 외부 HTML을 가져오거나 로컬에서 읽는 방식이 언급된다.^49^53
크로스 플랫폼(Cross-platform): 한 번 코딩해 iOS/안드로이드(그리고 경우에 따라 데스크탑) 등 여러 플랫폼에 배포하는 방식.^84
위젯(Widget): 플러터에서 UI 구성 단위로 부르는 요소. 강의에서는 컴포넌트와 같은 의미로도 설명하며, 화면 UI를 갖는 라이브러리로 이해하라고 말한다.^110^113
핫 리로딩(Hot Reloading): 코드를 수정하면 실행 화면에 즉시 반영되는 기능으로, 개발 시간(특히 UI 개발)을 크게 줄여준다고 강조된다.^119^121
CLI(Command Line Interface): 커맨드라인에서 명령을 입력해 결과를 바로 확인하는 인터페이스로, 테스트/디버깅에 유용하다고 설명된다.^77