https://www.youtube.com/watch?v=qix7zawA5ao
1. 이건 꼭 알아야 한다[^1]
[? 질문] 모바일 앱을 **모든 플랫폼(안드로이드/iOS 등)**에서 지원하려면 어떤 개발 방식이 현실적으로 유리한가[^2]
[= 답] 네이티브 개발은 성능·가벼움 측면에서 강점이 있지만 플랫폼별로 인력과 개발 공수가 분리되어 공수가 크게 증가한다는 문제가 있고, 이를 완화하기 위해 네이티브급에 가까운 성능 + 크로스 플랫폼 생산성을 제공하는 대안으로 **플러터(Flutter)**가 주목된다고 설명한다.[^10]
[? 질문] 유니티처럼 “한 번 개발해서 여러 플랫폼에 배포”가 되는 도구가 있는데도, 왜 모든 앱을 유니티로 만들지 않는가[^4]
[= 답] 사용자 규모가 커질수록 앱의 속도·가벼움이 중요해지고, 그때는 유니티를 “앱 전체”로 쓰기보다 네이티브 앱을 기본으로 두고 필요한 기능만 유니티를 라이브러리로 호출하는 식으로 구조가 바뀌기 때문이라고 사례(제페토, 직방)를 통해 설명한다.[^6]
[? 질문] 플러터가 기업 도입 관점에서 실제로 효과가 있었는가[^20]
[= 답] 네이버 사례를 근거로, 내부 설문에서 92%+가 크로스 플랫폼 필요를 응답했고, 여러 후보(리액트 네이티브/자마린/플러터/스케이트)를 평가해 플러터가 1위를 했으며, 동일 서비스를 플러터로 재구현했을 때 **인력과 기간이 크게 감소(2개월→2주)**하는 등 효율이 검증되었다고 말한다.[^22]
2. 큰 그림[^2]
이 콘텐츠는 모바일 앱 개발에서 크로스 플랫폼이 왜 필요해졌는지(시장/기술 배경), 기존 선택지(유니티·네이티브)의 한계가 무엇인지, 그리고 그 대안으로 **플러터(Flutter)**가 어떤 이유로 각광받는지를 사례 중심으로 설명한다.[^2] 또한 네이버의 도입 검증 과정과 성과를 근거로 플러터의 실무 효용을 보여준 뒤, 발표자가 직접 빠르게 학습한 경험과 함께 특정 강의(패스트캠퍼스 초격차 패키지)를 소개한다.[^23]
- 크로스 플랫폼의 필요성: 앱스토어/플레이스토어 양쪽에서 비슷한 트렌드가 나타나고, 사용자는 같은 서비스를 iOS·안드로이드에서 모두 기대하므로 기업은 멀티 플랫폼 지원을 필수로 고려하게 된다.[^1]
- 네이티브 vs 유니티의 현실적 트레이드오프: 유니티는 한 번에 여러 플랫폼 배포가 가능하지만, 대규모 서비스에서는 성능/구조 문제로 네이티브 중심 구조가 되기도 하며, 반대로 네이티브는 플랫폼별 인력/개발 공수 증가라는 고질적 문제가 있다.[^6]
- 플러터의 등장 이유와 설득 근거: 플러터는 한 번에 빌드 가능한 크로스 플랫폼, 핫 리로드, 머터리얼/쿠퍼티노 디자인 가이드 제공 등으로 생산성을 높이고, 네이버의 평가/테스트 결과로 도입 타당성을 뒷받침한다.[^12]
3. 하나씩 살펴보기[^1]
3.1 모바일 시장의 “멀티 플랫폼 기대”와 크로스 플랫폼 문제의 출발점[^1]
영상은 먼저 안드로이드 구글 플레이 순위와 iOS 앱스토어 순위가 “동일하진 않지만 비슷한 추세”라고 말하며, 많은 인기 앱/서비스가 두 플랫폼에서 동시에 소비된다는 현실을 깔아준다.[^1] 이어서 “갤럭시로 즐길 수 있는 앱을 아이폰에서도 동일하게 즐길 수 있다”는 사용자 경험을 언급하며, 기업들이 “모든 플랫폼을 지원하기 위해 노력”하고 있기 때문에 이런 일이 가능하다고 설명한다.[^2]
여기서 암묵적으로 던지는 핵심 문제는 다음과 같다.[^2]
[? 질문] 사용자가 양쪽 플랫폼에서 같은 서비스를 원할 때, 기업은 개발을 어떻게 설계해야 효율적인가[^2]
[= 답] 플랫폼을 동시에 지원하는 전략이 필요하며, 이를 위해 크로스 플랫폼/멀티 플랫폼 기술 선택이 핵심 의사결정이 된다.[^2]
3.2 유니티의 강점: “한 번 개발하면 모든 플랫폼에 출시”[^3]
발표자는 크로스 플랫폼 도구의 대표 예로 유니티 엔진을 든다.[^3] 유니티는 “크로스 플랫폼 기능을 지원”하기 때문에 “유니티로 개발하면 한 번에 모든 플랫폼으로 출시”할 수 있다는 점을 큰 장점으로 제시한다.[^3]
이 지점에서 자연스럽게 다음 의문을 제기한다.[^4]
[? 질문] 게임뿐 아니라 “모든 것”을 유니티로 만들어 출시하면 편할 텐데, 왜 실제로는 그렇게 하지 않는가[^4]
[= 답] 대규모 앱/서비스에서는 성능, 앱 무게, 아키텍처 측면의 요구가 커지면서 유니티를 “전체 앱”으로 쓰는 방식이 유지되기 어렵고, 구조가 네이티브 중심으로 재편되기도 한다.[^6]
3.3 유니티의 한계와 “네이티브 중심 + 유니티는 필요할 때만” 구조: 제페토 사례[^5]
발표자는 “대표적인 사례”로 제페토를 제시한다.[^5] 제페토는 안드로이드와 iOS를 모두 지원하고 “유저 수가 3억이 넘는 초대형 앱”이라고 규모를 강조한다.[^5]
- 초기 제페토는 “유니티 프로젝트로 만들어졌다”고 말한다.[^5]
- 초기 구조는 “유니티로 구동되고 네이티브 라이브러리를 꺼내 쓰는 방식”이었다고 설명한다.[^5] 즉, 앱의 중심 런타임이 유니티이고, 필요할 때 네이티브 기능(라이브러리)을 붙여 쓰는 구성으로 묘사된다.[^5]
- 그런데 사용자가 너무 많아지면서 “더 빠른 속도”가 필요해졌고, 현재는 방식이 바뀌었다고 한다.[^6]
바뀐 구조를 발표자는 이렇게 요약한다.[^6]
- 이제는 “네이티브 프로젝트에서 유니티를 라이브러리처럼 꺼내 쓰는 방식”으로 변경되었다.[^6]
- “일단 네이티브로 앱을 가볍게 만들고 필요할 때만 무거운 기능을 꺼내 쓰는” 전략이라고 풀어 설명한다.[^6]
즉, 유니티가 제공하는 크로스 플랫폼 장점이 있음에도, 규모가 커지고 성능 요구가 커지면 앱의 주도권(메인 쉘)을 유니티가 아니라 네이티브가 잡는 방향으로 아키텍처가 이동할 수 있음을 보여주는 사례로 사용된다.[^6]
[!IMPORTANT] “유니티로 다 만들면 편할 것 같은데”가 안 되는 이유로 제시된 핵심 대규모 서비스에서 요구되는 속도/가벼움 때문에, 유니티를 앱 전체 런타임으로 두기보다 네이티브를 기본으로 두고 유니티는 특정 기능 단위로 호출하는 구조가 선택될 수 있다고 말한다.[^6]
3.4 같은 방식의 채택: 직방의 “유니티를 라이브러리로” 활용[^7]
발표자는 제페토와 “같은 이유”로 직방에서도 유니티 개발자를 뽑는다고 말한다.[^7] 여기서의 포인트는 “직방 앱 자체는 네이티브”로 되어 있으나 “기능이 필요할 때만 유니티를 라이브러리로 꺼내 쓰는” 방식이라는 점이다.[^7]
이로써 발표자는 “유니티를 라이브러리로 부분 도입”하는 패턴이 특정 회사의 예외가 아니라, 요구 조건(성능/무게/특정 3D·AR 기능 등)에 따라 실제 채택되는 실무적 해법임을 강조한다.[^7]
3.5 네이티브 개발의 고질적 단점: 플랫폼별로 공수가 2배 이상[^8]
하지만 발표자는 이 방식(네이티브 중심)에 “단점”이 있다고 바로 이어간다.[^8] 네이티브로 앱을 만들면, “하나의 앱을 만들더라도 안드로이드 개발자와 iOS 개발자가 각각 필요”하고, 작업도 “별도로 진행”해야 하니 “개발 공수가 두 배 넘게 많아지는” 문제가 발생한다고 정리한다.[^8]
이 설명은 크로스 플랫폼을 고려하는 조직의 현실적인 페인포인트를 직접 겨냥한다.[^8]
[? 질문] 성능을 위해 네이티브 중심으로 가면 무엇이 가장 큰 비용이 되는가[^8]
[= 답] 플랫폼별 인력을 따로 구성하고 별도 개발을 진행해야 해서, 동일 기능을 두 번 구현·검증하게 되어 개발 공수(시간/인력)가 크게 증가한다.[^8]
3.6 “네이티브급 성능 + 크로스 플랫폼”을 원한다 → 플러터의 등장[^9]
앞의 문제의식(유니티의 한계/네이티브 공수 문제)을 연결해, 발표자는 “네이티브한 비슷한 성능을 보여주면서 크로스 플랫폼을 지원하는 프레임워크가 있으면 좋겠”다고 말한다.[^9] 그리고 “그래서 등장한 게 바로 플러터”라고 전환한다.[^9]
플러터를 다음과 같이 정의한다.[^10]
- 플러터는 “구글에서 만든 크로스 플랫폼 프레임워크”라고 소개한다.[^10]
- 플러터로 개발하면 “모든 플랫폼에 한 번에 빌드”할 수 있다고 말한다.[^11]
즉, 영상의 전반부는 “왜 플러터가 필요해졌는가”를 납득시키기 위해, 기존 선택지들의 장단점을 대비시키는 구성으로 진행된다.[^11]
3.7 플러터의 생산성 포인트 1: 핫 리로드와 “실시간 테스트”[^11]
발표자는 플러터의 기능으로 **핫 리로드(Hot Reload)**를 언급한다.[^11] 이 기능 덕분에 “코드를 작성하는 동시에 앱 테스트를 바로” 할 수 있고, “실시간 테스트”가 가능하다고 말한다.[^11]
그 결과로 제시하는 효과는 다음과 같다.[^12]
- “디버깅 시간”과 “개발 소요 시간”을 “압도적으로 단축”할 수 있다고 주장한다.[^12]
여기서 플러터의 가치는 단순히 “한 번에 빌드”가 아니라, 개발 루프(작성→확인→수정)의 회전 속도를 높여 개발 체감 속도를 올린다는 점으로 설명된다.[^12]
[!TIP] 실무 관점에서 영상이 강조한 핫 리로드의 의미 크로스 플랫폼 “한 번에 배포” 이전에, 개발 과정에서 코드 변경을 즉시 확인할 수 있어 반복 작업 비용(디버깅/수정)이 줄어든다고 설명한다.[^11]
3.8 플러터의 생산성 포인트 2: 머터리얼/쿠퍼티노 디자인 가이드 제공[^13]
발표자는 플러터가 “디자인 가이드”를 제공한다고 말한다.[^13] 구체적으로:
- 구글 디자인 가이드인 머터리얼 디자인(Material Design)[^13]
- 애플 디자인 가이드인 쿠퍼티노 디자인(Cupertino Design)[^13]
을 제공한다고 언급한다.[^13]
그리고 이 기능을 통해 “예술적인 감각이 전혀 없더라도” 시중의 앱들과 “큰 차이가 없는 깔끔한 결과물”을 만들 수 있다고 설명한다.[^13] 즉, UI/디자인 역량이 부족한 개발자라도 플랫폼 관습에 맞는 UI를 구현하기 쉬워진다는 논리다.[^13]
3.9 기업 도입의 현실: 장점이 많아도 “검토”가 필요함[^14]
발표자는 “장점들이 정말 많”지만, 기업 입장에서는 새로운 프레임워크를 도입하는 데 “많은 검토가 필요”하다고 말한다.[^14] 즉, 기술적 우수성만이 아니라 도입 리스크(인력, 유지보수, 생태계, 성숙도 등)를 고려한다는 현실 인식을 깔고, 이후 네이버 사례로 그 검토 과정이 어떻게 진행될 수 있는지 보여주려는 흐름을 만든다.[^14]
3.10 네이버의 플러터 도입: “대기업 최초”와 문제 인식[^15]
영상은 “네이버가 대기업 최초로 플러터를 도입”했다고 제시하며 관심을 끈다.[^15] 그리고 질문을 던진다.[^16]
[? 질문] 네이버는 어떤 과정을 통해 플러터를 선택했고, 도입 결과는 어땠는가[^16]
[= 답] 네이버 개발자 컨퍼런스에서 공개된 자료를 보면, 내부 설문으로 문제를 확인하고 후보군을 비교 평가한 뒤 플러터를 선정했으며, 이후 데모/실서비스 적용에서 생산성 개선을 확인했다고 설명한다.[^17]
발표자는 근거 출처로 “네이버 개발자 컨퍼런스에서 공개한 자료”를 언급하며, 이를 보면 과정을 알 수 있다고 한다.[^17]
3.11 네이티브 개발의 고질적 문제: 플랫폼 치중과 개발자 불균형 + 설문 92%[^18]
발표자는 “네이티브 개발을 하다 보면 피할 수 없는 고질적인 문제”가 있다고 말한다.[^18] 네이버가 사내 설문 조사를 해보니 동일한 문제가 확인되었다고 하고, 대표 사례로:
- “특정 플랫폼에 치중된 개발”[^18]
- 그로 인한 “개발자 불균형 같은 문제”[^18]
를 든다.[^18]
이 문제는 “필연적인 애로사항”이라 네이버 개발자들도 “대다수 비슷한 경험”을 했고, 그 결과 “무려 92% 넘게 크로스 플랫폼이 필요하다는 응답”을 했다고 수치를 제시한다.[^19]
이 대목에서 영상은 “왜 크로스 플랫폼이 필요한가”를 개인 경험이 아니라 조직적 데이터(설문)로 정당화한다.[^19]
[c 네이버 내부 설문에서 92%+가 크로스 플랫폼 필요를 응답했다는 수치를 근거로, 크로스 플랫폼 수요가 ‘개인 취향’이 아니라 ‘조직 차원의 문제 해결 요구’로 제시된다.][^19]
3.12 네이버의 후보군 평가: 리액트 네이티브·자마린·플러터·스케이트, 그리고 플러터 1위[^21]
설문을 바탕으로 네이버는 “크로스 플랫폼 테스트”를 진행했다고 한다.[^20] 여기서 “크로스 플랫폼으로 유명한” 네 가지를 후보로 올린다.[^21]
- 리액트 네이티브(React Native)[^21]
- 자마린(Xamarin)[^21]
- 플러터(Flutter)[^21]
- 스케이트(Scade로 발음/표기된 후보)[^21]
직원들이 “기준에 따라 각각 평가”를 진행했고, “최종적으로 플러터 1등”을 했다고 말한다.[^21] 또한 이 “평가 결과와 구글 트렌드 순위가 일치”하는 것도 “신기한 부분”이라고 덧붙인다.[^21] (즉, 내부 평가와 외부 관심도 지표가 비슷한 방향을 가리킨다는 뉘앙스.)[^21]
3.13 2차 테스트(재구현 실험): 12명·2개월 데모 → 8명·2주로 단축[^22]
플러터를 선정한 뒤 네이버는 “2차 테스트”를 진행한다고 한다.[^22] 발표자는 아주 구체적인 비교 수치를 제시한다.[^22]
- 기존에는 iOS 개발자 6명 + 안드로이드 개발자 6명으로 구성된 팀이[^22]
- 2개월에 걸쳐 데모 서비스를 완성했다.[^22]
- 이 데모를 플러터로 다시 만들어 보니 iOS 4명 + 안드로이드 4명으로[^22]
- 2주 만에 완성했다고 한다.[^22]
그리고 이를 “개발 소요 시간이 정말 압도적으로 단축”된 것이라고 해석한다.[^22]
[!NOTE] 영상이 암시하는 비교의 포인트 단순히 기간만이 아니라, 네이티브에서는 플랫폼별로 인력이 필요해 총 12명이었던 반면, 플러터 재구현 테스트에서는 총 8명으로도 더 짧은 기간에 완료되었다는 식으로 “조직 운영 효율”까지 포함해 설득한다.[^22]
3.14 실서비스 적용 1: 네이버 지식인 앱 전환 → “작업량 1/3 감소”[^23]
내부 테스트로 가능성을 본 네이버는 “실제 서비스 중인 앱”에도 플러터 도입을 시작했다고 한다.[^23] 사례로 네이버 지식인 앱을 언급하며, 이를 플러터 프로젝트로 변경했더니 “작업량이 1/3가량 줄어드는 효과”를 봤다고 말한다.[^23]
흥미로운 점으로 발표자는 이것을 “작업 속도가 빨라졌다”가 아니라 “작업량 자체가 줄어들었다”고 표현했다고 강조한다.[^23] 그리고 그 이유를 “플러터 특유의 UI 작업 효율” 덕분이라고 설명한다.[^24]
즉, 단순한 숙련도/속도 문제가 아니라 프레임워크 특성상 구현해야 하는 UI 작업의 부담(코드/반복/플랫폼 분기 등)이 구조적으로 줄어드는 효과가 있다는 주장이다.[^24]
3.15 실서비스 적용 2: 네이버 블로그 앱과 2021 Deview 자료 언급, 결론은 “효율·가능성 입증”[^25]
발표자는 “한 걸음 더 나아가” 더 많은 유저가 쓰는 네이버 블로그 앱에도 플러터 도입을 시도했다고 말한다.[^25] 그리고 “네이버 2021년도 Deview에서 공개된 자료”를 보면 블로그 앱에 플러터를 적용하는 과정이 “아주 상세히 정리”되어 있어 도움이 될 것이라고 안내한다.[^25]
이 파트를 요약하는 결론 문장은 다음과 같이 제시된다.[^26]
- “결론만 말씀드리자면 플러터의 효율과 가능성이 제대로 입증된 것”이라고 말한다.[^26]
3.16 발표자의 개인 학습 전환: “현업 사례 증가 → 직접 공부”[^27]
플러터가 “실제로 현업에서 사용되는 사례가 점점 많아”지자, 발표자 본인도 “직접 공부”를 해봤다고 말한다.[^27] 여기부터는 조직 사례(네이버)에서 개인 경험(학습 난이도, 학습 방법)으로 초점이 이동한다.[^27]
3.17 다트(Dart) 언어 진입장벽: C#과 유사, 반복문은 “그냥 똑같다”[^28]
발표자는 화면에 보이는 코드가 어떤 언어인지 질문을 던지며(청자 참여 유도), 그 코드가 **다트(Dart)**로 작성된 것이라고 밝힌다.[^28] 그리고 문법이 “굉장히 기본적이고 익숙”하며, 특히 “샵(C#)이랑 놀라울 정도로 똑같”다고 말한다.[^28]
더 강하게는:
- “반복문에서는 비슷한 수준이 아니라 그냥 똑같습니다”라고 말해 유사성을 강조한다.[^28]
그래서 “객체지향 언어”를 다뤄본 적이 있다면 다트를 “정말 빠르게 학습”할 수 있다고 주장한다.[^29] 그리고 플러터는 다트를 사용하므로, “코딩을 조금이라도 해 보셨다면” 플러터도 “금방 습득”할 수 있을 것 같다고 연결한다.[^30]
3.18 학습 방법 1: 기본 문법 후 인스타그램·토스 클론으로 UI 구조 연습[^31]
발표자는 본인이 다트를 “상당히 빠르게” 배웠다고 말한 뒤, 학습 과정을 설명한다.[^31]
- 기본 문법을 익힌 다음[^31]
- 인스타그램과 토스 앱을 “카피(클론)”해 보면서 UI 구조를 그리는 연습을 했다고 한다.[^31]
그는 “비록 카피 앱이지만” 실제 서비스 앱을 “쉽게 따라 만들 수” 있어서 “재미”도 있었다고 말한다.[^32] 중간에 “100억 부자가 되어 보기도” 했다는 표현을 넣어(토스 같은 금융 앱 클론 맥락의 농담/몰입 요소로 보임), 학습 동기 측면의 즐거움도 강조한다.[^32]
3.19 학습 방법 2: ML 인식·네트워크·파이어베이스까지 확장해 “상용 앱과 동일한 환경” 경험[^33]
UI 클론을 넘어서 발표자는 더 많은 기능 학습을 했다고 말한다.[^33]
- 머신러닝을 활용한 문자 인식, 바코드 인식, 사물 인식 등의 기술 적용[^33]
- HTTP 통신, 웹소켓(WebSocket) 활용[^33]
- **파이어베이스(Firebase)**를 사용해 “서버까지 다뤄보”는 경험[^33]
- 결과적으로 “실제 상용 중인 앱과 동일한 환경의 프로젝트”까지 진행했다고 말한다.[^33]
즉, 단순 UI 프레임워크 학습이 아니라, 앱 개발에서 자주 등장하는 기능 범위(네트워크/실시간 통신/백엔드 연동/ML 기능)를 플러터로 묶어서 실습했다는 흐름이다.[^33]
3.20 “처음인데 일주일 만에?” → 패스트캠퍼스 초격차 패키지 언급[^34]
발표자는 여기서 질문을 던진다.[^34]
[? 질문] 플러터를 처음 접했는데 어떻게 일주일 만에 이 정도까지 다룰 수 있었을까[^34]
[= 답] “패스트캠퍼스의 초격차 패키지 덕분”이라고 말하며, 이후는 강의(상품) 소개로 이어진다.[^35]
3.21 초격차 패키지의 구성 주장: 평생 소장, 15개 프로젝트, 로드맵[^36]
초격차 패키지를 “수많은 프로젝트를 하나의 패키지에 담아 놓은 평생 소장 강의”라고 소개한다.[^36] 그리고 본인이 수강한 플러터 강의에는 “무려 15가지의 다양한 프로젝트”가 포함되어 있었다고 구체 숫자를 제시한다.[^37]
또한 “단순히 프로젝트만 많이 하는 것이 아니라” 체계적인 로드맵이 구성되어 있어 “처음 코딩을 접하는 사람도 빠르게 배워 나갈 수” 있다고 말한다.[^38]
3.22 강사진/질문응답: 네카라쿠배 출신·재직, 디스코드 답변[^39]
발표자는 패키지의 특징으로 “초호화 강사진”을 든다.[^39] 강사진이 “네카라쿠배 출신 혹은 재직 중” 개발자들로 이루어져 있고, 디스코드에서 질문하면 직접 답변을 받을 수 있다고 말한다.[^39]
그 결과 “강의를 구매만 했을 뿐인데 현직 최고의 개발자들과 소통”할 수 있다고 표현하며, 이를 강의 가치로 강조한다.[^40]
3.23 추천 이유: 클론코딩에서 끝나지 않고 딥링크/FCM/로컬라이징 등 실무 기술 구현[^41]
발표자는 추천 이유를 비교 방식으로 설명한다.[^41]
- 일반적인 강의는 “클론 코딩만 하고 끝나는 경우가 많다”고 말하고[^41]
- 이 플러터 강의는 “이론적인 내용도 꽉 채워져 있”을 뿐 아니라[^41]
- 딥링크, FCM, 로컬라이징 등 “현업에서 실제로 사용되는 기술들을 빠짐없이 직접 구현”해 본다는 점이 좋았다고 말한다.[^41]
즉, 학습 결과물이 단순히 겉모습(UI 복제)에 그치지 않고, 실제 서비스 운영에 필요한 기능(푸시, 다국어, 앱 링크 등)을 다루도록 구성되었다는 주장이다.[^41]
3.24 로드맵 마지막: “실무 파트” — 기획서·디자인 리소스 받고 동일 프로세스 진행[^42]
발표자는 로드맵 마지막 파트가 “데미(대미)”를 장식하는 “실무 파트”라고 소개한다.[^42] 그 구성은 다음처럼 설명된다.[^42]
- 실제 현업처럼 기획서와 디자이너가 제작한 리소스 파일을 제공받고[^42]
- “실무에서와 동일한 프로세스”로 작업이 진행되게 구성되어 있다는 점이 “매력적”이라고 한다.[^42]
그는 공부하는 입장에서 “실무의 방식을 경험해 보는 것이 매우 중요”하며, 이 과정을 통해 수강생이 “엄청나게 많은 것들을 얻어갈 수” 있을 것 같다고 덧붙인다.[^43]
3.25 업데이트/자료 제공: 2년 무제한 업데이트, 정리 문서·자료 제공[^44]
플러터는 “업데이트가 빈번”한 프레임워크라고 전제하고, 강의도 플러터에 맞춰 “2년간의 무제한 업데이트를 보장”한다고 말한다.[^44] 또한 강의 자체에서 강사가 직접 작성한 “정리 문서”나 프로젝트에서 사용했던 “자료”를 제공하는 등 노하우를 아낌없이 제공한다고 하며 만족감을 표현한다.[^44]
3.26 플러터의 전망: 오픈소스 생태계, 계속 등장하는 신기술[^45]
발표자는 플러터가 오픈소스이기 때문에 많은 개발자들이 참여하고 있고, 지금도 계속 “새로운 기술들이 등장”하고 있다고 말한다.[^45] 그래서 플러터를 배워두면 “어느 분야의 개발이든 언젠가 도움이 될 것”이라는 생각을 공유한다.[^46]
3.27 유니티와의 접점: flutter_unity_widget 패키지로 “플러터 안에 유니티 넣기”[^47]
흥미로운 확장 예시로, 발표자는 유니티를 다시 끌고 온다.[^47] “유니티 보더라도” 플러터에 **유니티 위젯(패키지)**이 존재한다고 말하며(영상에서는 “위젯 시”라고 들리나 맥락상 flutter_unity_widget 계열 패키지를 지칭), 이를 사용하면 “플러터 프로젝트 안에 유니티를 넣을 수도 있다”고 한다.[^47]
- “방법도 어렵지” 않고[^48]
- “초보자들을 위한 튜토리얼 영상”도 업로드되어 있다고 말한다.[^48]
- 실제로 AR이나 3D 관련 기능은 유니티로 구현해 놓고 “꺼내 쓰는 식”으로 활용하는 것 같다고 설명한다.[^49]
즉, 영상 전반부의 “네이티브+유니티 라이브러리” 패턴을, 여기서는 “플러터+유니티 임베딩”이라는 형태로도 응용 가능하다는 예로 확장한다.[^49]
3.28 성능과 채용 시장: 네이티브에 뒤처지지 않는 성능, 하지만 인력은 아직 적음[^50]
마지막으로 발표자는 플러터가 “하나만으로 모든 플랫폼에 호환”시키는 것을 가능하게 하는 “독특한 내부 동작 원리” 덕분에, “네이티브와 비교해도 뒤처지지 않는 성능”을 보여준다고 말한다.[^50]
또한 “너무나 매력적인 프레임워크”라 “수많은 회사에서 플러터 개발자를 채용”하고 있지만, “아직 플러터 개발자는 많지 않은 상황”이라고 한다.[^51] 따라서 플러터를 배우면 “경쟁력을 갖춘 개발자로 성장”하는 하나의 방법이 될 수 있지 않겠냐는 제안을 한다.[^51]
끝으로 초격차 패키지 강의를 “평생 소장”하고 “앞서 나가는 개발자”가 되어보자는 권유로 마무리하며, 영상 종료 인사를 한다.[^52]
4. 핵심 통찰[^1]
- 네이티브/유니티/크로스 플랫폼은 “대체 관계”라기보다, 서비스 규모·성능 요구에 따라 아키텍처가 섞이거나 전환될 수 있는 선택지로 제시된다.[^6]
- 대규모 앱 사례(제페토)는 “크로스 플랫폼이 편하다”만으로는 부족하고, 결국 속도·앱 무게·구조 요구가 커지면 메인 쉘이 네이티브로 이동할 수 있음을 보여주는 근거로 쓰인다.[^6]
- 네이티브 개발의 가장 큰 고통으로 영상이 강조한 것은 “성능”이 아니라, 플랫폼 분리로 인한 인력/일정/유지보수 공수 증가다.[^8]
- 플러터의 설득 포인트는 “한 번에 빌드”뿐 아니라 핫 리로드로 개발 루프 단축, 디자인 가이드로 UI 품질/일관성 확보처럼 생산성 전반에 걸쳐 있다.[^12]
- 네이버 사례는 도입을 “감(느낌)”이 아니라 사내 설문(92% 필요) → 후보군 비교 평가(플러터 1위) → 재구현 테스트(2개월→2주) → 실서비스 작업량 감소(1/3) 같은 단계적 검증으로 설명해, 기업 도입 논리를 구성한다.[^19]
- 실행 관점 시사점(영상 논리 기반)
- 크로스 플랫폼 도입을 고민한다면, “좋다/나쁘다” 토론보다 **내부 문제(플랫폼 불균형, 공수)**를 수치화(설문/지표)하고 후보군을 기준으로 비교하는 절차가 유효하다는 메시지를 준다.[^21]
- 학습은 문법(다트) → UI 클론 → 기능 확장(네트워크/ML/백엔드) 순으로 난이도를 올리는 접근이 제시된다.[^33]
5. 헷갈리는 용어 정리[^10]
- 크로스 플랫폼: 하나의 코드베이스/프레임워크로 여러 플랫폼(iOS/안드로이드 등)을 동시에 지원하려는 개발 접근을 의미하는 맥락으로 사용된다.[^9]
- 네이티브 앱/네이티브 개발: iOS는 iOS 방식, 안드로이드는 안드로이드 방식으로 각각 별도 개발하는 접근으로 언급된다.[^8]
- 플러터(Flutter): 구글이 만든 크로스 플랫폼 프레임워크로, 한 번에 빌드 및 핫 리로드, 머터리얼/쿠퍼티노 디자인 제공 등의 특징으로 설명된다.[^10]
- 다트(Dart): 플러터에서 사용하는 언어로, 발표자는 C#과 문법이 매우 유사하다고 말한다.[^28]
- 핫 리로드(Hot Reload): 코드를 수정하면서 즉시 앱에 반영/테스트할 수 있어 디버깅 및 개발 시간을 줄여준다고 설명된 기능이다.[^11]
- 머터리얼 디자인(Material Design) / 쿠퍼티노(Cupertino) 디자인: 각각 구글/애플의 디자인 가이드로, 플러터가 이를 제공한다고 언급된다.[^13]
- FCM: 강의에서 다룬다고 언급된 현업 기술로, 문맥상 푸시 알림 등과 연관된 기능으로 제시된다(영상에서는 약어 확장 설명은 없음).[^41]
- 딥링크(Deep Link): 강의에서 다룬다고 언급된 현업 기술로, 앱 내 특정 화면으로 이동시키는 링크 기능 맥락으로 등장한다(영상에서는 정의 설명은 없음).[^41]
- 로컬라이징(Localizing): 강의에서 다룬다고 언급된 현업 기술로, 다국어/지역화 적용 맥락으로 등장한다(영상에서는 정의 설명은 없음).[^41]
- 파이어베이스(Firebase): 서버까지 다뤄보며 상용 앱과 같은 환경을 구성했다고 말할 때 언급되는 도구/플랫폼이다.[^33]
- 웹소켓(WebSocket): HTTP 통신과 함께 언급된 실시간/양방향 통신 활용 기술로 제시된다.[^33]
참고(콘텐츠 정보)[^1]
- 제목: 너도 일주일이면 플러터 할 수 있어[^1]
- 채널: 오늘코딩[^1]
- 길이: 8분 54초[^1]
- 링크: https://www.youtube.com/watch?v=qix7zawA5ao[^1]
- 키워드(제공): 패스트캠퍼스, 패스트캠퍼스초격차패키지, 프로그래밍, 프론트엔드, 프로그래밍강의[^1]
[^1]: @[00:00]~@[08:51] 사용자 제공 트랜스크립트 및 메타데이터(제목/채널/길이/링크/키워드). [^2]: @[00:06] “갤럭시로 즐길 수 있는 어플이며 아이폰에서도 동일하게 즐길 수 있다는 거죠” / @[00:10] “기업에서 모든 플랫폼을 지원하기 위해 노력”. [^3]: @[00:13] “유니티 엔진은 엄청난 장점” / @[00:19] “유니티가 크로스 플랫폼 기능을 지원… 한 번에 모든 플랫폼으로 출시”. [^4]: @[00:23] “그럼 게임뿐만 아니라 모든 걸 유니티로 만들어서… 실제로 그러지는 않죠” / @[00:27] “왜 그럴까요”. [^5]: @[00:31] “대표적인 사례로 제페토” / @[00:36] “유저수가 3억이 넘는 초대형 앱” / @[00:40] “최초의 제페토는 유니티 프로젝트”. [^6]: @[00:48] “유저수가 너무 많아지다 보니 더 빠른 속도가 필요” / @[00:54] “네이티브 프로젝트에서 유니티를 라이브러리… 꺼내쓰는 방식” / @[00:59] “네이티브로 앱을 가볍게… 필요할 때만 무거운 기능”. [^7]: @[01:05] “같은 이유로 직방에서 유니티 개발자를” / @[01:09] “앱 자체는 네이티브… 필요할 때만 유니티를 라이브러리로”. [^8]: @[01:16] “안드로이드 개발자와 iOS 개발자가 각각 필요… 개발 공수가 두 배 넘게”. [^9]: @[01:23] “네이티브한 비슷한 성능… 크로스 플랫폼… 있으면 좋겠죠” / @[01:30] “그래서 등장한게 바로 플러터”. [^10]: @[01:36] “플러터 구글에서 만든 크로스 플랫폼 프레임워크”. [^11]: @[01:43] “모든 플랫폼에 한 번에 빌드” / @[01:52] “코드를 작성하는 동시에 앱 테스트”. [^12]: @[01:57] “디버깅 시간과 개발 소유 시간을 압도적으로 단축”. [^13]: @[02:02] “디자인 가이드를 제공” / @[02:08] “머터리얼 디자인… 쿠퍼티노 디자인”. [^14]: @[02:15] “장점… 많지만 기업 입장… 도입… 많은 검토”. [^15]: @[02:20] “네이버가 대기업 최초로 플로터를 도입”. [^16]: @[02:26] “어떤 과정을 통해… 선택… 결과는”. [^17]: @[02:32] “네이버 개발자 컨퍼런스에서 공개한 자료”. [^18]: @[02:38] “네이티브 개발… 고질적인 문제” / @[02:43] “사내 설문… 동일한 문제” / @[02:51] “개발자 불균형”. [^19]: @[02:57] “무려 92% 넘게 크로스 플랫폼이 필요”. [^20]: @[03:05] “설문 조사를 기반으로 크로스 플랫폼 테스트”. [^21]: @[03:13] “리액트 네이티브 자마린 플러터 스케이드 후보” / @[03:13] “최종적으로 플러터 1등” / @[03:13] “구글 트렌드 순위가 일치”. [^22]: @[03:35] “iOS 6명… 안드로이드 6명… 2개월… 데모” / @[03:41] “iOS 4명 안드로이드 4명… 2주”. [^23]: @[03:46] “실제 서비스… 플러터 도입” / @[03:55] “지식인 앱… 작업량이 1/3가량 줄어”. [^24]: @[04:03] “작업 속도… 아니라 작업량 자체” / @[04:03] “플러터 특유의 UI 작업 효율”. [^25]: @[04:11] “네이버 블로그 앱에도 플러터 도입” / @[04:11] “2021년도 Deview… 적용 과정 상세”. [^26]: @[04:30] “결론만… 플러터의 효율과 가능성이 제대로 입증”. [^27]: @[04:35] “현업… 사용 사례… 많아지다 보니… 공부”. [^28]: @[04:42] “코드가 어떤 언어” / @[04:51] “다트… 샵이랑… 똑같죠” / @[04:55] “반복 문… 그냥 똑같습니다”. [^29]: @[04:59] “객체 지향 언어… 다트… 빠르게 학습”. [^30]: @[05:03] “플러터… 다트… 코딩… 조금이라도… 금방 습득”. [^31]: @[05:10] “다트… 빠르게 배울” / @[05:16] “인스타그램과 토스 앱을 카피… UI 구조”. [^32]: @[05:22] “100억 부자가 되어 보기도” / @[05:22] “재미”. [^33]: @[05:32] “머신 러닝… 문자 인식… 바코드… 사물 인식” / @[05:32] “http… 웹소켓… 파이어베이스… 서버… 상용… 동일한 환경”. [^34]: @[05:41] “플로터를 처음 접했는데… 일주일 만에”. [^35]: @[05:50] “패스트 캠퍼스의 초격차 패키지 덕분”. [^36]: @[06:02] “수많은 프로젝트… 하나의 패키지… 평생 소장”. [^37]: @[06:07] “무려 15가지… 프로젝트”. [^38]: @[06:12] “체계적으로 로드맵… 처음 코딩… 빠르게”. [^39]: @[06:17] “초호화 강사진” / @[06:24] “네카라 쿠베 출신… 디스코드… 직접 답변”. [^40]: @[06:29] “현직 최고의 개발자들과 소통”. [^41]: @[06:46] “클론 코딩만… 끝” / @[06:46] “이론… 꽉” / @[06:46] “딥링크 fcm… 로컬라이징… 직접 구현”. [^42]: @[06:58] “마지막 파트… 실무 파트” / @[07:02] “기획서… 디자이너… 리소스… 동일한 프로세스”. [^43]: @[07:13] “실무의 방식을 경험… 매우 중요… 얻어갈 수”. [^44]: @[07:24] “2년간의 무제한 업데이트” / @[07:24] “정리 문서… 자료 제공”. [^45]: @[07:35] “오픈 소스… 많은 개발자… 새로운 기술”. [^46]: @[07:54] “배워두면 어느 분야… 도움이”. [^47]: @[08:00] “플러터에… 위젯… 패키지… 플러터 프로젝트 안에 유니티”. [^48]: @[08:05] “방법도 어렵지가… 튜토리얼 영상”. [^49]: @[08:11] “AR이나 3D… 유니티로 구현… 꺼내쓰는”. [^50]: @[08:17] “독특한 내부 동작 원리… 네이티브와 비교해도… 성능”. [^51]: @[08:29] “수많은 회사… 채용” / @[08:33] “아직… 많지 않은 상황” / @[08:37] “경쟁력을… 방법”. [^52]: @[08:41] “초격차 패키지… 평생 소장… 앞서 나가는 개발자” / @[08:45] “오늘 영상은 여기까지… 감사합니다”.