Google IO 2024 Fluttter 새로운 소식 후기

올해도 Google IO 세션이 열렸고 다양한 사항들이 발표되었다. 그중 Flutter 관련 새로운 소식들이 있었다

이번 키노트에서 특히 강조한 내용은 5가지이다.

Gemini(AI), Flame(Game Engine), Macros(개발 생산성), Impeller(UI Rendering Engine), WebAssembly(Web)

Gemini

flutter만의 추가사항은 아니고 이번 IO 자체의 가장 중요한 이슈로 보인다.

구글의 자연어 처리 AI 모델이다. flutter에서도 적극적으로 지원한다는 내용이다. 기존에도 tflite_flutter 라이브러리를 통해 tensor flow를 통한 AI기능 구현이 가능한 사항이지만 Gemini를 통해 더 쉽게 자연어 처리 기술을 적용할 수 있을 것 같다.

https://pub.dev/packages/tflite_flutter

tflite_flutter | Flutter package

 

https://ai.google.dev/gemini-api/docs/get-started/tutorial?lang=dart&hl=ko

튜토리얼: Gemini API 시작하기  |  Google AI for Developers  |  Google for Developers

 

Flame

작년에 발표한 게임 엔진인 Flame의 성능이 향상되었다고 한다.

물론 유니티나 언리얼 엔진 같은 전용 엔진과 비교할 바는 아니지만 퍼즐류, 플래피버드 같은 단순한 형태의 게임은 개발이 가능할 것 같다. 렌더링에 있어 Impeller, skia와는 별도의 구조로 동작한다고 한다.

단순한 구조의 게임을 개발하고자 하는데 게임엔진을 학습하기 부담스러운 경우 괜찮은 선택지로 작용할 수 있을 것 같다.

 

Macros

개인적으로 이번 프리뷰에서 가장 흥미로운 부분이다.

컴파일 타임에 코드를 생성하는 도구이다. flutter의 경우 build_runner를 통한 코드 생성 프로세스를 자주 이용하는데 이 부분을 개선하고자 나온 기술로 보인다. 시연상으로는 json타입 직렬화, 데이터 타입, oberserve 생성 등의 기능을 구현하였다.

어노테이션 기반으로 동작하는 것으로 보이고 해당 어노테이션을 기반으로 컴파일 시점에 코드를 생성해 실행하는 것으로 보인다.

build_runner가 크게 불편한 방식은 아니지만 은근히 손이 많이 가는 패턴이긴 하다. 간혹 build_runner 실행을 까먹어서 문제가 되는 경우가 있고 생성된 코드를 가리거나 형상관리에서 제외하기 위해 별도 설정이 필요하기도 하며 간혹 이 부분의 코드를 수정해 버리는 개발자도 있다. 코드 검색 시 생성형 코드가 끼어 있어서 정신 사나운 부분이 있기도 하고, 결국 생성되는 코드는 생성된다는 것만 알고 신경 쓰지 않게 안 보이는 곳에 있는 게 최선이다. 또한 작은 단위의 개발을 진행할 때도 여러 가지 보조 라이브러리를 사용하는 게 번거롭기도 하다.

뭐 어찌 되었든 개발환경을 구성할 때 참조 라이브러리는 적을수록 좋다는 입장에서 기대되는 부분이다.

https://pub.dev/packages/macros

macros | Dart package

 

Impeller

작년에 발표된 Impeller이다. 지속적 업데이트가 이루어지고 있으며 기존 skia 형식에 비해 더 나은 성능을 기대할 수 있다고 한다. 특히 ios 환경에서의 개선이 있다고 한다. 작년 출시 직후에는 특정 상황에서 버그가 있다고 했던 것 같은데 아무래도 1년 이상 운영되고 발전되었기에 안정성과 성능상의 이점을 모두 취할 수 있을 것이다.

flutter 진영에서 지속적으로 강조하는 크로스 플랫폼 언어 중 성능상의 우위에 대한 핵심인 것 같다. 이미 flutter를 사용한다면 그냥 넘어가도 상관없고 "프로젝트에서 어떤 언어를 선택하여야 하는가"라는 고민을 하고 있다면 흥미롭게 볼 수 있을 부분이다.

WebAssembly

웹 언어의 트렌드인 WebAssembly이다.

google은 flutter/dart 언어를 통해 웹개발 언어에 대한 영향력을 높이려 한다. 웹 프런트 언어의 경우 javascript 기반 언어들(react, vue, angular... )의 영향력이 강한 상황이고 백엔드까지 점유율을 높이고 있기에 범용성이라는 장점은 훨씬 더 커질 수밖에 없다. 다만 js 기반 언어의 특성에서 기인하는 불편함과 성능상의 문제들이 있기에 이런 부분에 문제점을 느끼는 사람이라면 flutter를 통한 web. 개발이 흥미가 있을 수 있다.

일단 지금 flutter로 개발한 후 web 환경에서 배포하려면 js로 변환되어 배포되는 것을 확인할 수 있는데 이 중 렌더링에 해당하는 부분을 WebAssembly를 통해 처리하도록 개선한다는 내용이다. 구글의 발표에 따르면 android 환경의 처리속도를 1로 가정하면 js는 4, WebAssembly는 2라고 한다. 즉 웹 환경에서 기존보다 최대 2배의 성능 향상을 기대할 수 있다는 의미이다.

(지속적으로 관리되는) 생성형 언어의 큰 장점이다. 작은 규모의 작업(혹은 아무것도 없이) 언어의 발전으로 성능향상을 기대할 수 있다.

개인적 소감

• 웹 퍼포먼스 강조
  모바일 웹과 네이티브 앱을 동일하게 개발하려는 요구는 지속적으로 보이고 있다. 일단 같은 기기 환경이기에 같은 UI를 제공한다면 사용자 경험으로나 인력관리로나 큰 이점을 얻을 수 있다. 일단 라이브러리를 제외하면 97%의 코드가 범용적으로 사용 가능하다고 하며 이번에 WebAssembly를 통해 웹에서의 실행 시 더 좋은 퍼포먼스까지 기대할 수 있을 것이다.
• 생성형 AI 적용 난이도 개선
  Gemini관련 사항은 플러터 환경만이 아닌 이번 IO의 주요 테마이다. 이전에도 tensor flow를 통해 개발이 가능하지만 tensor flow의 경우 기술적인 난이도가 다소 있다. 정확히는 모델링을 직접 관리한다는 게 생각보다는 쉽지 않을 수 있다. 기술 난이도를 낮춰 더 쉽게 적용이 가능하며 성능 또한 일정 이상 보장될 수 있다.
• 기본 성능 강조
  flutter의 비교군은 react native가 가장 유력할 것이다. 그리고 react native와 비교했을 때 가지는 강점을 기본 성능으로 여기는 듯하다. 아무래도 내부를 향하는 웹뷰를 통한 렌더링에 비해 canvas 레벨에서 직접 그리는 flutter의 엔진은 구조적으로 성능상 비교우위를 가질 수밖에 없다. 범용성의 영역으로 넘어가면 웹 시장을 지배하는 react에 비해 부족할 수밖에 없으니 더 성능을 강조하는 것 같다.

크로스 플랫폼 시장 예측?

10~20년 전의 서비스들은 웹에서 사용하는 것을 위주로 개발이 진행되었다. 그렇기에 웹에서 운영되던 서비스를 앱으로 옮기는 형태의 작업들이 많았는데 이 지점에서 react native가 큰 장점이 있었다고 생각한다.(+ angular app) 내부 기능이야 다시 구현한다 해도 UI의 대부분을 재활용 가능하고 언어가 같기에 유연한 인력관리가 가능했다.

하지만 요즘에는 이런 경향들이 많이 줄어들었다. 사용자가 모바일 환경을 선호하는 경향이 더 강해졌으며 이로 인해 앱에서만 서비스를 지원하기도 하는 상활도 많이 볼 수 있다.

사용자의 눈높이는 언제나 그 시장에서 가장 뛰어난 서비스에 맞춰지기에 모바일 환경에서의 서비스는 성능상의 이점을 가지는 앱을 중심으로 하고 웹 환경은 이를 보조하는 형태로만 나오기도 한다. 다만 앱 서비스의 가장 큰 진입장벽인 "앱 설치"를 해결하기 위해 웹 서비스가 일부 필요할 수도 있다.

앱 환경이 우선인 상황이기에 꼭 웹에서 많이 쓰이는 언어인 js 기반 언어를 사용할 필요가 없으며 웹 어셈블리로 인한 성능이슈도 있으니 flutter의 영향력이 더 커질 수 있을 것 같다는 생각이다.

 

https://io.google/2024/explore/da049081-00e1-4476-80da-1cd039302ac6/intl/ko/

Google I/O 2024