프로젝트에서 보기 →

플러터 (Flutter) 앱 개발을 배울까 말까? 플러터의 현재와 미래에 대해 같이 고민해 보기

태그
비즈니스
시작일
종료일
수정일

https://www.youtube.com/watch?v=VeIk8WSIQ2o

1. 이건 꼭 알아야 한다[^1]

[? 질문] 지금 시점에서 플러터(Flutter) 를 “배워야 할까, 말아야 할까”[^2]
[= 답] 플러터는 장점이 분명하지만(멀티플랫폼·빠른 UI·빠른 개발), 발표자는 구글의 지원/투자 의지에 대한 불신과 프로덕션에서의 리스크(문제 해결, 생태계, 인력 수급) 때문에 “대부분의 현업 앱 개발자에게는 아직 때가 아니다(관망이 낫다)”고 결론낸다.[^3]

[? 질문] 플러터가 널리 쓰이지 못하고 “고전”한다고 보는 핵심 이유는 무엇인가[^4]
[= 답] 발표자는 이유를 “단 한 가지”로 압축해 구글이 플러터를 제대로 밀어주지(열심히) 않고 있다고 말한다.[^5]

[? 질문] 그럼에도 누가/어떤 경우에 플러터를 배우는 것이 의미가 있는가[^6]
[= 답] 스타트업의 빠른 출시 니즈에는 플러터가 적합하며, 또한 새로운 기회를 노리는 학습자/전직자에게는 “경력자 풀이 거의 없는 시장”에서 플러터 자체가 차별점이 되어 취업 기회가 될 수 있다고 본다.[^7]

2. 큰 그림[^8]

이 콘텐츠는 크로스 플랫폼 앱 개발 프레임워크인 플러터(Flutter) 를 지금 배울지에 대해, 발표자(안드로이드 개발자)의 관점에서 기술적 장점과 시장/조직(구글) 관점의 리스크를 함께 따져보며 결론을 제시한다.[^9] 특히 “기술이 좋아 보이는 것”과 “지속적으로 커지고 안전하게 투자할 수 있는 생태계인지”를 분리해서 보려는 문제의식이 중심에 있다.[^10]

  • 플러터의 장점은 분명하다: 멀티플랫폼 지원, 네이티브급으로 빠른 UI, 빠른 개발 속도(핫 리로드) 가 강점이라고 정리한다.[^11]
  • **하지만 채택을 가로막는 핵심 변수는 ‘구글의 의지’**라고 본다: 오픈소스라 해도 구글이 강하게 드라이브하지 않으면 성장에 한계가 있고, 구글은 프로젝트를 종료해버릴 수 있는 회사라는 불안을 강조한다.[^12]
  • 권장 전략은 ‘사람에 따라 다르게’: 현업 네이티브 앱 개발자는 당장 필수는 아니며 관망, 웹(JS/React) 기반 개발자는 리액트 네이티브 권유, 새 기회를 원하는 학습자는 플러터 학습을 “추천”까지 한다.[^13]

3. 하나씩 살펴보기[^14]

3.1 문제 제기: “플러터를 배워야 하나?”와 발표자의 배경[^15]

📸 0:06

발표자는 영상 시작에서 오늘의 주제를 “크로스 플랫폼 앱 개발 프레임워크 플러터를 배워야 하는가 말아야 하는가”로 명시한다.[^16] 본인은 안드로이드 개발자이지만, 오래전부터 아이폰(iOS) 앱도 개발하고 싶은 욕망이 있었다고 말한다.[^17]

하지만 안드로이드와 iOS를 각각 “둘 다 따로 배워서 개발”하는 일은 쉽지 않기 때문에, 한 번 개발하면 iOS와 안드로이드로 모두 출시 가능한 멀티플랫폼/크로스플랫폼 프레임워크에 관심을 가져왔다고 맥락을 깐다.[^18]

여기서 발표자는 비교 대상으로 리액트 네이티브(React Native) 를 언급한다.[^19] 리액트 네이티브는 “왠지 웹 개발자가 앱을 개발하기 위한 플랫폼처럼 보여서” 본인에게는 큰 매력이 아니었다고 솔직히 말한다.[^20] 그러다 구글이 플러터를 출시하면서 컨셉이 재미있고 “괜찮다”는 인상을 받아 열심히 연구해봤다고 한다.[^21]

그런데 발표자는 “왜 플러터를 배우지 말아야 하는지”를 스스로에게 계속 질문하며 고민했다고 한다.[^22] 그 이유는 역설적으로 “그만큼 플러터가 매력적이었기 때문”이라고 설명한다.[^23] 즉, 좋아 보이는데도 망설여지는 지점(리스크)이 뭔지 파고든 셈이다.[^24]

그리고 결론적으로는 “새로운 개발을 배우는 게 쉽지”도 않은 상황에서 여러 고민 끝에, 본인이 제시할 이유들 때문에 지금은 아직 때가 아니다라는 판단에 이르렀다고 초반에 방향을 제시한다.[^25]

[!NOTE] 발표자가 깔고 가는 전제
플러터의 기술적 매력은 인정하지만, “학습 투자”는 기술 우수성만이 아니라 **지속가능성(지원, 생태계, 채택)**까지 고려해야 한다는 시각을 깔고 들어간다.[^26]

3.2 플러터의 3가지 장점: 멀티플랫폼, 빠른 UI, 빠른 개발 속도[^27]

📸 1:01

발표자는 플러터를 잘 모르는 사람을 위해 장점을 “3가지”로 정리한다:

  1. 멀티플랫폼 지원, 2) 네이티브처럼 빠른 UI, 3) 빠른 개발 속도.[^28]

3.2.1 멀티플랫폼 지원: 한 번 개발하면 iOS/안드로이드 모두 출시[^29]

첫 번째 장점으로 “한 번 앱을 개발하면 iOS용으로도 안드로이드용으로도 출시 가능”하다는 멀티플랫폼 특성을 든다.[^30] 이는 곧 팀이 두 플랫폼을 각각 네이티브로 만들 필요를 줄여준다는 기대와 연결된다.[^31]

또한 앱에서 테마(Theme) 를 지원해 iOS 스타일(Cupertino)과 안드로이드 스타일(Material) 디자인을 제공할 수 있어, 플랫폼별 이질감을 줄일 수 있다고 설명한다.[^32]

3.2.2 네이티브처럼 빠른 UI: Skia 2D 그래픽 엔진으로 직접 렌더링[^33]

두 번째 장점은 “속도가 빠르다”는 점이다.[^34] 발표자는 플러터가 “원래 있던 내부 위젯을 사용하는 것이 아니라” Skia라는 2D 그래픽 엔진을 이용해 화면을 그린다고 말한다.[^35]

이런 구조 덕분에 자체적으로 다양한 애니메이션 효과나 높은 프레임의 UI를 구현/완성할 수 있었다는 취지로 설명한다.[^36] 즉, 네이티브 UI 구성요소를 단순히 래핑(wrapping)하는 접근과 다르게 “직접 그린다”는 점을 성능·표현력의 근거로 든다.[^37]

3.2.3 빠른 개발 속도: 핫 리로드로 수정 즉시 확인[^38]

세 번째 장점으로는 UI 관련 개발을 매우 빠르게 할 수 있다는 점, 그리고 핫 리로드(Hot Reload) 를 통해 “직접 보고 변경하면서 바로 개발물을 확인”할 수 있다고 말한다.[^39]

발표자는 이러한 장점 조합이 “개발하고 변경을 많이 해야 되는” 특히 스타트업에 잘 어울릴 수 있는 프레임워크라고 평가한다.[^40] 그리고 “딱 제가 좋아하고 요즘 하고 있는 것”이라고 덧붙이며, 본인의 취향/업무 성격과도 맞는 특성임을 인정한다.[^41]

[!TIP] 이 파트에서의 실질적 메시지
플러터의 강점은 “기능 한두 개”가 아니라, 출시 속도(멀티플랫폼) + 화면 품질/성능(Skia) + 개발 피드백 속도(핫 리로드) 가 한 덩어리로 묶여 스타트업 요구와 맞물린다는 주장이다.[^42]

3.3 “이렇게 좋은데 왜 고전하나”: 원인을 ‘구글이 안 민다’로 단일화[^43]

📸 1:59

발표자는 플러터가 “이렇게 좋은 프레임워크인데 널리 쓰이지 못하고 지금 고전하고 있다”고 느낀다고 말한다.[^44] 그리고 그 이유를 “단 한 가지”로 설명할 수 있다며, 구글이 열심히 하고 있지 않기 때문이라고 단정한다.[^45]

여기서 발표자는 오픈소스 여부와 무관하게, “구글이 시작한 만큼 사람들은 구글에게 많은 기대를 걸고 있다”고 말한다.[^46] 즉, 플러터가 오픈소스이고 플러그인을 커뮤니티가 만들 수 있어도, 시장은 “구글이 계속 강하게 발전시켜 줄 것”이라는 기대를 기반으로 움직인다는 것이다.[^47]

발표자의 논리는 다음 흐름이다:

  • 사람들이 플러터를 쓰는 데는 “구글이 더 열심히 개발해서 기능·성능을 업그레이드할 것”이라는 기대가 깔린다.[^48]
  • 그런데 소스 분석/사용자가 많고 이슈를 많이 올려도, 구글이 주도적으로 업그레이드하지 않으면 커뮤니티 누군가가 “총대를 메고” 전체를 끌고 가기 어렵다.[^49]
  • 따라서 “구글이 더 열심히 하고 있지 않다”는 것이 곧 성장 정체로 이어진다는 주장이다.[^50]

3.4 구글이 진짜 밀면 ‘티가 난다’: Google I/O, 로컬 커뮤니티 지원 관찰[^51]

📸 2:41

발표자는 “왜 그렇게 생각하느냐”는 근거로, 구글이 정말 밀어주는 프로젝트는 항상 티가 난다고 말한다.[^52] 예시로 구글의 대형 행사(맥락상 Google I/O)를 들며, 어떤 기술을 밀면 세션이 “한 무더기”로 나올 정도라고 주장한다.[^53]

그래서 “그중에서 플러터 관련 세션이 몇 개인지 세어 보면 된다”는 식으로, 행사 스케줄에서의 비중을 관찰 지표로 제시한다.[^54] 발표자는 (코로나로 오프라인이 열리지 못했던 시기의) I/O 스케줄을 봤을 때 플러터 비중이 그렇게 커 보이지 않았다고 말한다.[^55]

또한 “이번년도 구글 I/O는 새로운 기술 이야기보다는 성장과 수익에 대한 내용이 많은 부분”을 다뤘다고 느꼈다고 말하며, 구글의 관심이 ‘새 플랫폼/새 프레임워크 드라이브’보다 ‘비즈니스’로 이동한 인상도 덧댄다.[^56]

더 가까운 사례로 구글코리아를 언급한다.[^57] 플러터 커뮤니티를 지원하는지, 관련 이벤트를 많이 여는지 등을 보면 “플러터 기술과 커뮤니티를 얼마나 서포트하고 싶은지” 가늠할 수 있다고 말한다.[^58] 그런데 본인은 “지원이 그렇게 크지 않다”고 느낀다고 한다.[^59]

이런 관찰을 통해 발표자는 다음 연결을 만든다:

  • 구글 차원의 커뮤니티/홍보/행사 비중이 낮아 보인다.[^60]
  • 그러면 내부적으로 플러터 개발팀에 대한 지원도 적을 가능성이 높다.[^61]
  • 결과적으로 “지금 현재 플러터를 개발하고 있는 개발자들이 생각보다 많지 않을 것”이라고 추정한다.[^62]
  • 구글이 큰 조직이라도, 세부 프로젝트는 “몇 명밖에 참여하지 않는” 경우가 많다고 덧붙인다.[^63]

3.5 구글의 ‘종료 리스크’: 서비스 무덤과 “방향 안 맞으면 닫는다” 논리[^64]

📸 3:42

발표자는 “구글이 밀어주지 않아도 개발자들은 열심히 하는데 그게 문제냐”라고 자문하고, “당연히 문제가 된다”고 답한다.[^65] 그 이유로 구글이 종료한 서비스를 모아둔 “무덤”이 있을 정도로, 구글은 “이건 좀 아니다 싶으면 프로젝트를 종료시켜 버린다”고 말한다.[^66]

다만 발표자는 구글이 여러 프로젝트를 만들고 시도하다가 종료되는 것 자체를 무조건 나쁜 시도라고 보지는 않는다.[^67] 그런 시도가 새로운 가능성을 발견하고, 기회가 됐을 때 기술이 성장할 기반이 되기도 한다는 점에서 “우선 시도하는 게 어디냐”라고 옹호한다.[^68]

그럼에도 불구하고 핵심은 이것이다:

  • 우리가 보기에 플러터가 좋고 우리가 잘 쓰고 있어도, 구글의 판단과 다를 수 있다.[^69]
  • 구글은 글로벌 시장을 리드하면서 “큰 성공”을 추구하는 회사이고, 개발자들이 좋아하는 것과 별개로 구글이 가고자 하는 방향과 맞지 않으면 닫아버린다는 것이다.[^70]

또한 발표자는 플러터가 오픈소스라서 구글이 지원을 중단해도 프로젝트가 “아예 없어지는 건” 아닐 수 있다고 인정한다.[^71] 하지만 구글의 강한 지원 없이 성장하는 것은 매우 어렵다고 본다.[^72]

3.6 사례: GWT 경험담으로 설명하는 “버려진 오픈소스의 현실”[^73]

📸 4:45

발표자는 본인이 과거에 구글을 믿고 공부했던 프로젝트로 GWT(Google Web Toolkit) 를 든다.[^74] 이는 “자바스크립트가 아니라 자바를 사용해서 웹을 만드는 프레임워크”라고 설명한다.[^75]

그런데 나중에 구글이 “성장 가능성이 없다”고 봤는지, 본인이 잘 쓰고 있었음에도 불구하고 프로젝트를 “거의 버리게 된다”고 말한다.[^76]

그 후의 결과를 이렇게 묘사한다:

  • 꾸준히 쓰는 사람은 여전히 쓰고, 오픈소스이므로 참여해서 새 버전이 나오긴 한다.[^77]
  • 하지만 “14년 동안 버전이 2.x(‘마이너’ 수준)밖에 못 올라갔다”는 식으로, 성장/업데이트가 사실상 정체되었다고 말한다.[^78]
  • 따라서 이 프로젝트는 “거의 안 쓰는 프로젝트가 되었다고 생각해야” 한다고 평가한다.[^79]

이 경험을 플러터에 대입해, “구글이 끌다가 언제 포기할지 모르는 프로젝트를 내가 공부해서 열심히 프로덕트를 내는 건 어렵다”는 판단 근거로 제시한다.[^80]

[!WARNING] 발표자가 말하는 리스크의 형태
단순히 ‘지금 기능이 부족하다’가 아니라, 장기적으로 투자 가치가 무너지는 시나리오(지원 약화 → 업데이트 정체 → 인력/생태계 축소) 를 두려워한다는 점이 핵심이다.[^81]

3.7 “구글은 왜 열심히 안 하나”: 투자 논리(미래 대비 기술 vs 돈 벌어주는 서비스)[^82]

📸 5:27

발표자는 “왜 구글은 열심히 하지 않을까요”라고 묻고, 답은 간단하다고 한다.[^83] 구글은

  • 미래에 대비하는 기술, 또는
  • 당장 돈을 벌어주는 서비스

에는 투자를 아끼지 않는다는 것이다.[^84]

그런데 발표자 관점에서 플러터는 이 두 가지 중 하나도 만족시키지 못한다고 본다.[^85] 즉, 구글의 투자 우선순위에서 상위에 놓이기 어렵다는 주장이다.[^86]

3.8 비교 사례: 안드로이드는 왜 그렇게 밀었나 (버전 역사, iOS 대항, 수익화)[^87]

📸 5:40

발표자는 “달달한 예”로 안드로이드를 든다.[^88] 본인 기억으로도 안드로이드는 1.5 컵케이크, 2.1 이클레어, 2.2 프로요, 4.4 키캣 등 버전이 계속 올라왔고, 이후에도 (영상 시점 기준) 12까지 나왔다고 말한다.[^89]

여기서 강조는 “사람들이 원하지 않아도 열심히 개발하고 무언가를 찍어낸다”는 표현이다.[^90] 안드로이드는 2.0 이후 돈과 사람을 투입해 거대한 프로젝트로 키웠다고 본다.[^91]

그렇게 할 “확실한 이유”가 있었는데, 발표자는 이를 다음처럼 설명한다:

  • 애플의 iOS에 대항해 좋은 운영체제를 만들고 싶었다.[^92]
  • 실제로 안드로이드는 잘 안착했고, 사람들이 안드로이드 플랫폼을 광범위하게 사용하게 됐다.[^93]
  • 그리고 플랫폼을 통해 구글 검색/광고/유튜브 등으로 “돈을 많이 벌 수 있었다”고 말한다.[^94]

즉, 안드로이드는 구글의 전략(플랫폼 장악 및 수익화)과 직접 맞물리기 때문에 강한 투자가 정당화되었다는 비교 프레임이다.[^95]

3.9 그럼 플러터는 구글에 어떤 이득이 있나: “플랫폼 공고화에 도움 되나?” 의문[^96]

📸 6:27

발표자는 플러터의 정의를 다시 상기시킨다: “한 번 앱을 만들어 iOS도 안드로이드도 여러 플랫폼으로 출시할 수 있게 하는 기술”이 크로스 플랫폼이다.[^97]

여기서 애플의 행동을 예로 든다. 애플은 아이폰 전용 앱을 출시하면 지원해줄 정도로 “독점(전용) 앱”을 장려하면서 플랫폼 영향력을 공고히 하려 한다는 것이다.[^98]

반대로, 다른 플랫폼까지 만들어 주는 크로스 플랫폼은 구글이 자기 플랫폼/생태계를 공고히 하는 데 “그렇게 도움이 될 것 같지 않다”고 말한다.[^99] 이 논리를 통해 발표자는

  • 플러터는 “구글(회사)의 999(어떤 특정 목표/이익을 의미하는 맥락)”를 위한 기술이라기보다
  • 개발자를 위한 기술에 가깝다고 본다고 결론짓는다.[^100]

즉 “개발자 편의”와 “구글의 플랫폼 전략”이 완전히 같은 방향은 아닐 수 있다는 관점이다.[^101]

3.10 플러터의 가능성 시나리오 1: ‘Dart’를 밀 이유가 줄었다(코틀린 성공 이후)[^102]

📸 6:56

발표자는 플러터에도 “몇 가지 가능성”이 있었다고 말한다.[^103] 그중 하나로 과거 오라클-구글 자바 분쟁 맥락을 꺼낸다.[^104] 오라클이 자바를 사용해 구글을 공격했을 때, 안드로이드가 자바 기반이었으므로 구글은 자바에서 탈출하려는 노력을 많이 했다고 말한다.[^105]

그 결과물 중 하나가 코틀린(Kotlin) 이고, 코틀린은 자바를 “완벽하게 대체”해 자바 없이도 앱 개발을 가능하게 해줬다고 설명한다.[^106] 그리고 “자바에서 코틀린으로 아주 성공적인 이전”이 이미 이루어진 상황에서는, 플러터 및 플러터가 사용하는 다트(Dart) 를 강하게 밀어야 할 이유가 “많이 사라졌다”고 본다.[^107]

즉, 플러터의 언어(Dart) 채택을 강제/유도해야 할 전략적 압력이 줄었다는 해석이다.[^108]

3.11 플러터의 가능성 시나리오 2: Fuchsia OS(추정)와의 연결에 대한 회의[^109]

📸 7:29

발표자는 플러터 얘기를 찾아보면 “꼭 나오는 것” 중 하나로 (발음상) 퓨시아(Fuchsia) OS를 언급한다.[^110] 흔히 “구글이 안드로이드 다음으로 밀어줄 OS”로 설명되곤 한다는 소개를 덧붙인다.[^111]

하지만 발표자는 그 OS가 실제로 “얼마나 빠르게 우리 생활에 다가올지” 의심스럽다고 말한다.[^112] 그리고 이미 모바일 기기가 아니라 (문맥상 IoT/로봇 등) 다른 영역 쪽으로 선회해 개발 중인 것으로 알고 있다고 말한다.[^113]

또한 안드로이드는 (영상 내 언급으로는) 12까지 나왔고, 그만큼 투자해 안정화된 운영체제를 “다 버리고 완전히 새로운 운영체제를 채택”하는 것은 현실화되기 어렵다고 주장한다.[^114] 이유로는:

  • 시장이 이미 고착화돼 있고,[^115]
  • 새로운 시도보다 기존 플랫폼을 잘 관리하는 것이 부담/비용을 낮춘다고 보기 때문이라고 말한다.[^116]

결론적으로 “구글이 가진 기술적 문제를 플러터와 다트로 해결할 필요가 없어 보인다”고까지 정리한다.[^117]

3.12 그럼 플러터의 ‘다른 성공 경로’: 시장이 필요로 하고 개발자가 열광해야 함[^118]

📸 8:26

여기까지가 “구글 전략 관점에서 플러터가 우선순위가 아닐 수 있다”는 비관적 논리라면, 발표자는 반대로 플러터가 성공할 수 있는 다른 방법도 제시한다.[^119]

그 방법은:
플러터라는 기술 자체가 시장에서 너무 필요해지고, 개발자들이 열광하며 “캠프(진영) 기반”으로 성공한다면, 플러터도 기회를 얻을 수 있다는 것이다.[^120]

즉, 구글 드라이브가 약해도 시장 수요와 커뮤니티 열기가 충분히 크면 생태계가 커질 수 있다는 가능성을 열어둔다.[^121]

3.13 현재 시장 반응 진단: “극과 극은 아니지만, 대부분은 안 쓴다” + 프로덕션 리스크[^122]

📸 8:40

발표자는 “현재 시장 반응은 어떨까요”라고 질문을 던지고, “극과 극은 아니다”라고 말하면서도 결론은 꽤 냉정하다: 우선 대부분은 쓰지 않는다는 것이다.[^123]

그 근거로는 안정 버전을 사용해도 “여러 문제점”을 발견할 수 있고, 프로덕션(실서비스) 출시 과정에서도 계속 문제를 겪게 된다고 말한다.[^124]

특히 “해결하기 어려운 난이도 높은 문제”를 겪었을 때, 구글이 해결해주기를 마냥 기다릴 수는 없다고 말한다.[^125] 이때 앞서 언급한 “구글이 열심히 안 한다/지원이 약하다”는 불안과 연결되며, 그러다 보면 프로젝트가 언제 종료될지도 모르고 실패로 남을 수도 있다는 리스크 인식으로 이어진다.[^126]

또한 고객/클라이언트 관점의 압박도 든다. 클라이언트가 “왜 이런 기능은 다른 데는 되는데 우리는 못 만들어요?”라고 묻기 시작하면, 플러터로 개발하는 사람은 당당하기 어렵다는 취지다.[^127] 많은 기능은 네이티브 코드를 동원하면 만들 수는 있지만, 그렇게까지 가는 과정이 “난이도가 정말 높고 힘든 경우가 많다”고 말한다.[^128]

정리하면, 발표자가 말하는 프로덕션 리스크는:

  • 프레임워크 자체/플러그인 성숙도 문제로 예상치 못한 이슈가 나온다.[^129]
  • 해결이 어렵고, 공식 지원이 강하지 않으면 대응 시간이 길어질 수 있다.[^130]
  • 결국 납기/품질/고객 커뮤니케이션에서 부담이 커진다.[^131]

3.14 인력/전환 장벽: Dart 개발자 수급 vs React Native의 전환 용이성[^132]

📸 9:26

발표자는 리액트 네이티브가 가진 장점으로 “웹 개발자들이 리액트 네이티브로 전환하기 굉장히 좋다”는 점을 든다.[^133] 반면 플러터는 다트(Dart) 개발자를 찾는 것이 “쉬운 일이 아닐 것”이라고 말한다.[^134]

그래서 대부분의 경우, 이미 보유한 기술 스택이 있는데 “플러터로 갈아타는 것은 매우 어려운 일”이라고 주장한다.[^135] 이는 기업 입장에서 채용/교육 비용과 리스크로 직결된다는 맥락이다.[^136]

3.15 그럼에도 플러터를 쓰는 집단: “대부분 스타트업” + ‘빨리 출시’가 최우선[^137]

📸 9:42

그럼에도 불구하고 플러터로 새 앱을 만들려는 사람이 있다고 말하며, 그 주체를 “대부분 스타트업에서 새로운 앱을 만들고 싶어하는 사람들”로 특정한다.[^138]

또한 플러터 앱 개발자를 찾는 구인 공고도 “어렵지 않게 볼 수 있다”고 말한다.[^139] 그리고 “스타트업에서 내놓는 99% 앱은 (MVP라는 의미로) 맛(?)”이라는 취지로, 많은 스타트업 앱은 처음부터 완벽한 고도화/대규모 확장을 전제하기보다 일단 시장에 빠르게 내놓는 것이 중요하다고 말한다.[^140]

그래서 앱 고도화를 미리 걱정하기보다 가장 빠르게 안드로이드와 아이폰으로 출시하는 게 중요한 스타트업에 플러터는 “아주 적합한 포지션”이라고 평가한다.[^141] 그리고 이런 지점에서부터 플러터가 발전할 수 있다고 본다.[^142]

또한 “플러터만 기반해도 개발자들이 먹고 살 수 있다”고 말해, 최소한의 시장(특히 스타트업 채용 수요)은 형성되어 있다는 인상을 준다.[^143]

3.16 발표자가 바라는 ‘성공 조건’: 멀티플랫폼을 “진짜로” 더 잘해야 한다[^144]

📸 10:16

발표자는 플러터가 성공하려면 “기존에 잘 하려고 했던 멀티플랫폼을 더 잘할 수 있었으면 좋겠다”고 말한다.[^145]

여기서 제시하는 구체적 기대는 매우 명확하다:

  • 코드를 한 번 작성하면
    • 안드로이드 앱 출시
    • 아이폰 앱 출시
    • 데스크탑과 웹까지 “폭”을 넓게 출시
      가 가능해지면, 본인은 “반드시 쓸 것”이라고 말한다.[^146]

그 이유로, 어떤 서비스를 만들 때 “아이폰 앱을 만들어야 되는 상황” 등에서 시간이 갈수록 개발 비용과 시간이 줄어드는 추세이며, 그 문제를 해결할 수 있는 것이 플러터가 되었으면 좋겠다고 말한다.[^147]

발표자는 이미 플러터가 데스크탑 앱, 웹으로도 만들려고 하고(알고 있고) 있다는 점을 언급한다.[^148] 하지만 중요한 건 “된다” 수준이 아니라, 정말 기본 옵션(‘평타’)으로 써도 문제가 없다는 수준까지 안정성과 완성도가 올라가야 성공 가능성이 커진다고 말한다.[^149]

[!IMPORTANT] 성공 조건의 핵
발표자가 원하는 것은 “크로스 플랫폼이 된다”가 아니라, 크로스 플랫폼이 프로덕션 기본값으로 안전하게 선택 가능한 수준(품질/호환성/생태계)이다.[^150]

3.17 최종 결론(권장안): 대상별로 다르게—현업 앱 개발자 관망, 웹 개발자 RN, 신입/전환자는 Flutter도 추천[^151]

📸 10:56

발표자는 “마지막으로 결론”을 대상별로 나눈다.[^152]

3.17.1 현업에서 이미 앱 개발 중인 사람: “당장 배울 필요는 없다”[^153]

본인처럼 이미 앱 개발을 하고 있는 사람이라면, 플러터를 “당장” 배울 필요는 없는 것 같다고 말한다.[^154] 이유는 현재 하고 있는 일만 해도 일이 많고, 먹고 사는 데 문제가 없다는 현실적 판단을 든다.[^155]

따라서 플러터가 어떻게 될지 기다리면서 관망하면 좋겠다는 권고다.[^156]

3.17.2 자바스크립트로 웹 개발(특히 React 경험자): React Native 추천[^157]

자바스크립트로 웹 개발을 해온 사람, 특히 리액트를 사용해본 사람에게는 커뮤니티가 막강하고 널리 사용되는 리액트 네이티브로 앱 개발을 해보는 것이 좋겠다고 말한다.[^158] (앞서 말한 “전환이 쉽다/인력 수급이 낫다”는 맥락과 연결된다.)[^159]

3.17.3 새로운 시도/새로 공부하는 사람: Flutter 학습을 “추천” (기회 요인)[^160]

마지막으로, 새로운 시도를 원하거나 새로 개발을 공부하면서 “플러터에서 새로운 기회를 찾아보겠다”는 생각이라면 플러터를 배우는 것도 추천한다고 말한다.[^161]

근거는 채용 시장의 희소성이다:

  • “지금 현재 시장에는 플러터 경력자들이 한 명도 없다”는 표현으로, 경력자 풀이 매우 얕은 상태라고 말한다.[^162]
  • 이런 상황에서 일부 스타트업은 플러터로 실제 출시용 프로덕션 앱을 만들고 싶어한다.[^163]
  • 따라서 “플러터로 앱을 만들고 싶다”는 것만으로도 취업이 가능할 수도 있다고 말한다.[^164]

물론 정보가 많지 않고 배우기 어렵다는 단점도 인정한다.[^165] 그래도 새로운 기회를 잡아 취업할 수 있는 것은 “좋다”고 평가한다.[^166]

또한 미래 불확실성에 대해서는 이렇게 말한다:

  • 운이 좋아 플러터가 “대성”할 수도 있다.[^167]
  • 그렇지 않더라도 모바일 앱 개발을 배워두면 안드로이드나 iOS 개발로 “빠져나갈 수” 있다고 말한다.[^168]
    즉, 플러터 학습이 완전히 매몰비용만은 아니라는 안전판 논리다.[^169]

마지막으로 “고무적인 부분”으로, 플러터가 완벽하지 않아도 장점을 인정하고 사용해 발전시키고 만들어가는 사람들이 있다는 점을 든다.[^170] 그리고 비교적 젊은 프레임워크로서 성장 가능성이 있으며, 모든 플랫폼에서 플러터로 앱 개발이 가능해진다면 모두가 플러터를 사용하게 되고 크게 성장할 수도 있다고 말한다.[^171]

끝으로 계속 지켜봐 달라고 하고, 더 많은 생각이 있으면 댓글로 남겨 달라고 요청하며 마무리한다.[^172]

4. 핵심 통찰[^173]

  1. [h “기술이 좋다”와 “투자해도 안전하다”는 다른 문제다] 발표자는 플러터의 장점을 먼저 충분히 인정한 뒤, 최종 판단은 구글의 지속 지원 가능성과 프로덕션 리스크에 둔다.[^174]
  2. [h 오픈소스라도 ‘메인 스폰서’의 드라이브가 성장의 병목이 될 수 있다] 커뮤니티가 이슈를 올리고 플러그인을 만들어도, 구글이 기능/성능 업그레이드를 주도하지 않으면 생태계가 크게 성장하기 어렵다는 관점을 제시한다.[^175]
  3. [h 구글은 프로젝트를 쉽게(?) 접을 수 있다는 공포가 채택 심리에 직접 영향을 준다] “종료된 서비스 무덤”을 언급하며, 기업/개인이 장기 프로젝트에 플러터를 넣는 결정을 어렵게 만드는 심리적 요인으로 작동한다고 본다.[^176]
  4. [m 플러터의 ‘구글 내부 전략적 당위’가 약해 보인다는 해석] 안드로이드는 iOS 대항 및 수익화로 투자 이유가 명확했지만, 플러터는 크로스 플랫폼 특성상 구글의 플랫폼 공고화에 직접적 이득이 약하다고 본다.[^177]
  5. [h 성공 조건은 “지원 플랫폼 확장”이 아니라 “기본값으로 써도 되는 완성도”] 웹/데스크탑까지 ‘된다는 수준’이 아니라, 안정적인 프로덕션 품질로 ‘평타 옵션’이 되면 채택이 폭발할 수 있다는 기준을 제시한다.[^178]
  6. [h 학습/커리어 전략은 ‘본인 상황’에 맞춰 갈라야 한다] 현업 네이티브 개발자(관망) vs JS 웹 개발자(RN) vs 신입/전환자(Flutter 기회)처럼 동일한 기술도 개인의 포지션에 따라 최적 해가 달라진다는 결론 구조다.[^179]
  • 실행 관점 체크리스트(발표자 논리 기반)
    • 현업 네이티브 개발자라면: 플러터 학습을 “필수 스킬”로 두기보다 추세 관찰로 리소스를 관리한다.[^156]
    • 스타트업/빠른 MVP라면: “양 플랫폼 동시 출시” 가치가 큰지와, 예상되는 네이티브 브리지 작업 난이도를 사전에 점검한다.[^141]
    • 학습자/이직자라면: 플러터로 차별화를 노리되, 장기적으로는 모바일 전반 역량(안드/iOS) 으로 확장 가능한 학습 경로를 함께 설계한다.[^168]

5. 헷갈리는 용어 정리[^180]

  • 크로스 플랫폼/멀티플랫폼: 한 번 작성한 코드/프로젝트로 iOS와 안드로이드 등 여러 플랫폼에 앱을 배포하려는 개발 방식/프레임워크 특성.[^97]
  • 쿠퍼티노(Cupertino): iOS 스타일 UI를 제공하는 테마/위젯 계열(영상에서는 iOS용 테마로 언급).[^32]
  • 머티리얼(Material): 안드로이드 스타일 UI를 제공하는 테마/디자인 시스템(영상에서는 안드로이드용 테마로 언급).[^32]
  • Skia(스키아) 2D 그래픽 엔진: 플러터가 화면을 그릴 때 활용한다고 설명된 2D 렌더링 엔진.[^35]
  • 핫 리로드(Hot Reload): 코드를 수정한 뒤 앱을 재시작에 가깝게 느리게 돌리지 않고, 변경 사항을 빠르게 반영해 즉시 확인하는 개발 기능.[^39]
  • 다트(Dart): 플러터에서 사용하는 언어로 언급되며, 발표자는 코틀린 성공 이후 구글이 이를 강하게 밀 이유가 줄었다고 본다.[^107]
  • 리액트 네이티브(React Native): 웹(특히 리액트/JS) 개발자가 앱 개발로 전환하기 쉽고 커뮤니티가 강하다고 비교 언급된 크로스 플랫폼 프레임워크.[^158]
  • GWT: 자바로 웹을 만들게 해주는 프레임워크로, 발표자는 구글이 사실상 버린 뒤 생태계가 정체된 사례로 제시한다.[^75]

참고(콘텐츠 정보)[^181]

  • 제목: 플러터 (Flutter) 앱 개발을 배울까 말까? 플러터의 현재와 미래에 대해 같이 고민해 보기[^182]
  • 채널: 작은개발자[^182]
  • 길이: 12분 45초[^182]
  • 링크: https://www.youtube.com/watch?v=VeIk8WSIQ2o[^182]

[^1]: @[00:06] “...플러터를 배워야 되는가 말아야 되는가...” [^2]: @[00:06] “...배워야 되는가 말아야 되는가...” [^3]: @[00:52]–@[00:56] “...지금은 아직 때가 아니다...”; @[11:00]–@[11:08] “...당장 배울 필요는 없는 것 같아요...관망...” [^4]: @[01:59] “...널리 쓰이지 못하고...고전...” [^5]: @[02:01]–@[02:03] “이유는...단 한가지...구글이 열심히 하고 있지 않기...” [^6]: @[11:21]–@[11:49] “...새로운 시도...플러터를 배우는 것도...추천...취업...” [^7]: @[09:47]–@[10:09] “...대부분 스타트업...제일 빠르게...출시...”; @[11:32]–@[11:49] “...취업이 가능할 수도...” [^8]: @[00:06]–@[00:56] 주제 제시와 ‘아직 때가 아니다’ 결론 예고 [^9]: @[00:09]–@[00:29] 개인 배경(안드로이드 개발자, iOS 욕망, 크로스 플랫폼 관심) [^10]: @[02:01]–@[05:27] 구글 지원/종료 리스크를 중심으로 판단하는 전개 [^11]: @[01:01]–@[01:12] “장점 3가지...멀티 플랫폼...빠른 ui...빠른 개발 속도...” [^12]: @[02:10]–@[04:45] 구글이 제대로 밀지 않는다는 주장과 그 영향 [^13]: @[11:00]–@[11:21] 현업 앱 개발자/웹 개발자 권고; @[11:21]–@[11:49] 새 학습자에게 플러터 추천 [^14]: 전체 타임라인 흐름(00:06~12:41)에 따른 재구성 [^15]: @[00:06]–@[00:56] [^16]: @[00:06] [^17]: @[00:09]–@[00:15] [^18]: @[00:15]–@[00:29] [^19]: @[00:29] [^20]: @[00:29] [^21]: @[00:29]–@[00:37] [^22]: @[00:37] [^23]: @[00:48] [^24]: @[00:37]–@[00:56] [^25]: @[00:52]–@[00:56] [^26]: @[00:37]–@[00:56] [^27]: @[01:01]–@[01:50] [^28]: @[01:01]–@[01:12] [^29]: @[01:12]–@[01:27] [^30]: @[01:12]–@[01:18] [^31]: @[01:12]–@[01:18] [^32]: @[01:18]–@[01:27] [^33]: @[01:27]–@[01:41] [^34]: @[01:27]–@[01:35] [^35]: @[01:27]–@[01:35] [^36]: @[01:35]–@[01:41] [^37]: @[01:27]–@[01:41] [^38]: @[01:41]–@[01:50] [^39]: @[01:45]–@[01:50] [^40]: @[01:50]–@[01:57] [^41]: @[01:57] [^42]: @[01:01]–@[01:57] [^43]: @[01:59]–@[02:41] [^44]: @[01:59] [^45]: @[02:01]–@[02:03] [^46]: @[02:13]–@[02:19] [^47]: @[02:10]–@[02:19] [^48]: @[02:19]–@[02:26] [^49]: @[02:26]–@[02:39] [^50]: @[02:39]–@[02:41] [^51]: @[02:41]–@[03:34] [^52]: @[02:41]–@[02:43] [^53]: @[02:43]–@[02:49] [^54]: @[02:49]–@[02:53] [^55]: @[02:53]–@[03:02] [^56]: @[03:02]–@[03:09] [^57]: @[03:09] [^58]: @[03:09]–@[03:21] [^59]: @[03:21]–@[03:26] [^60]: @[02:43]–@[03:26] [^61]: @[03:26]–@[03:34] [^62]: @[03:26]–@[03:34] [^63]: @[03:34]–@[03:42] [^64]: @[03:48]–@[04:45] [^65]: @[03:42]–@[03:51] [^66]: @[03:51]–@[03:58] [^67]: @[03:58]–@[04:02] [^68]: @[04:02]–@[04:13] [^69]: @[04:13]–@[04:18] [^70]: @[04:18]–@[04:32] [^71]: @[04:32]–@[04:41] [^72]: @[04:41]–@[04:45] [^73]: @[04:45]–@[05:27] [^74]: @[04:45]–@[04:51] [^75]: @[04:51]–@[04:55] [^76]: @[04:55]–@[05:04] [^77]: @[05:08] [^78]: @[05:08]–@[05:12] [^79]: @[05:12]–@[05:17] [^80]: @[05:17]–@[05:27] [^81]: @[02:01]–@[05:27] 전반 [^82]: @[05:27]–@[05:40] [^83]: @[05:27]–@[05:30] [^84]: @[05:30]–@[05:35] [^85]: @[05:35]–@[05:40] [^86]: @[05:30]–@[05:40] [^87]: @[05:40]–@[06:22] [^88]: @[05:40] [^89]: @[05:40]–@[05:53] [^90]: @[05:53]–@[05:57] [^91]: @[05:57]–@[06:02] [^92]: @[06:02]–@[06:11] [^93]: @[06:11]–@[06:22] [^94]: @[06:11]–@[06:22] [^95]: @[06:02]–@[06:22] [^96]: @[06:22]–@[06:56] [^97]: @[06:27]–@[06:33] [^98]: @[06:33]–@[06:42] [^99]: @[06:42]–@[06:50] [^100]: @[06:50]–@[06:56] [^101]: @[06:42]–@[06:56] [^102]: @[06:56]–@[07:29] [^103]: @[06:56]–@[07:01] [^104]: @[07:01]–@[07:09] [^105]: @[07:01]–@[07:09] [^106]: @[07:09]–@[07:17] [^107]: @[07:17]–@[07:29] [^108]: @[07:17]–@[07:29] [^109]: @[07:29]–@[08:26] [^110]: @[07:29]–@[07:33] [^111]: @[07:33]–@[07:38] [^112]: @[07:38]–@[07:43] [^113]: @[07:43]–@[07:50] [^114]: @[07:50]–@[08:06] [^115]: @[08:06]–@[08:09] [^116]: @[08:09]–@[08:20] [^117]: @[08:20]–@[08:26] [^118]: @[08:26]–@[08:40] [^119]: @[08:26]–@[08:40] [^120]: @[08:26]–@[08:40] [^121]: @[08:26]–@[08:40] [^122]: @[08:40]–@[09:42] [^123]: @[08:40]–@[08:44] [^124]: @[08:44]–@[08:54] [^125]: @[08:54]–@[09:01] [^126]: @[09:01]–@[09:06] [^127]: @[09:06]–@[09:18] [^128]: @[09:18]–@[09:26] [^129]: @[08:44]–@[08:54] [^130]: @[08:54]–@[09:01] [^131]: @[09:06]–@[09:26] [^132]: @[09:26]–@[09:42] [^133]: @[09:26]–@[09:35] [^134]: @[09:26]–@[09:35] [^135]: @[09:35]–@[09:42] [^136]: @[09:26]–@[09:42] [^137]: @[09:42]–@[10:16] [^138]: @[09:42]–@[09:51] [^139]: @[09:51]–@[09:55] [^140]: @[09:55]–@[10:01] [^141]: @[10:01]–@[10:09] [^142]: @[10:09]–@[10:11] [^143]: @[10:11]–@[10:16] [^144]: @[10:16]–@[10:56] [^145]: @[10:16]–@[10:23] [^146]: @[10:23]–@[10:33] [^147]: @[10:33]–@[10:41] [^148]: @[10:41]–@[10:48] [^149]: @[10:48]–@[10:53] [^150]: @[10:48]–@[10:53] [^151]: @[10:56]–@[12:06] [^152]: @[10:56]–@[11:00] [^153]: @[11:00]–@[11:11] [^154]: @[11:00]–@[11:03] [^155]: @[11:03]–@[11:08] [^156]: @[11:08]–@[11:11] [^157]: @[11:11]–@[11:21] [^158]: @[11:11]–@[11:21] [^159]: @[09:26]–@[09:42] [^160]: @[11:21]–@[12:06] [^161]: @[11:21]–@[11:32] [^162]: @[11:32]–@[11:36] [^163]: @[11:36]–@[11:44] [^164]: @[11:44]–@[11:49] [^165]: @[11:49]–@[11:56] [^166]: @[11:49]–@[11:56] [^167]: @[11:56]–@[12:06] [^168]: @[12:00]–@[12:06] [^169]: @[11:56]–@[12:06] [^170]: @[12:06]–@[12:16] [^171]: @[12:16]–@[12:29] [^172]: @[12:29]–@[12:41] [^173]: 영상 전체 논지 종합(특히 @[02:01]–@[05:27], @[08:40]–@[10:53], @[11:00]–@[12:29]) [^174]: @[01:01]–@[01:57] 장점; @[02:01]–@[05:27] 지원/종료 리스크; @[11:00]–@[11:11] 관망 결론 [^175]: @[02:26]–@[02:39] [^176]: @[03:51]–@[04:32] [^177]: @[06:22]–@[06:56] [^178]: @[10:48]–@[10:53] [^179]: @[11:00]–@[11:49] [^180]: @[01:18]–@[01:35], @[01:45]–@[01:50], @[07:17]–@[07:29], @[09:26]–@[09:35] [^181]: 사용자 제공 메타데이터(제목/채널/길이/링크) [^182]: “# 플러터 (Flutter) 앱 개발을 배울까 말까?... / 채널: 작은개발자 / 길이: 12분 45초 / https://www.youtube.com/watch?v=VeIk8WSIQ2o” (사용자 제공)

← 프로젝트에서 보기