메뉴 바로가기 검색 및 카테고리 바로가기 본문 바로가기

한빛출판네트워크

한빛랩스 - 지식에 가능성을 머지하다 / 강의 콘텐츠 무료로 수강하시고 피드백을 남겨주세요. ▶︎

IT/모바일

플러터를 사용해야 할까?

한빛미디어

|

2021-03-05

|

by 에릭 윈드밀

19,310

 
안드로이드와 iOS 애플리케이션을 한 번에 개발하는 완벽 가이드
『플러터 인 액션』 중
 

여러분은 아마도 플러터를 반신반의할 수도 있다. 이런 생각은 매우 합당하다. 플러터는 새로운 기술, 즉 기존 API와 호환되지 않는다. 이는 중요한 기능이 지원되지 않을 수도 있음을 뜻한다. 또한 어느 날 갑자기 구글이 플러터 지원을 중단할 수도 있다. 다트도 아직 유명한 언어가 아니며 필요한 서드 파티 라이브러리가 충분하지 않을 수도 있다.
여러분은 플러터를 사용해야 할지 말아야 할지 혼란에 빠졌겠지만, 이제 그 생각을 바꿔보자. 우선 구글 애즈 같은 주요 수입원 서비스 내부에서 다트를 사용하므로 더 이상 API가 크게 바뀌는 일은 없을 것이다.
다트 최신 버전은 2.9이며, 이는 언어가 충분히 안정화되었다는 의미다. 당분간은 호환성을 깨는 변화는 없을 것이다. 마지막으로 필요한 모든 기능을 플러터가 제공하지는 않지만 자신만의 네이티브 플러그인(예를 들어 구글 지도, 카메라, 위치 기반, 디바이스 저장소 플러그인 등)을 만들 수 있다. 그리고 계속해서 새로운 기능이 추가되고 있다.
· · ·
자바스크립트 다리가 없음
크로스 플랫폼 기술로 앱을 개발할 때 자바스크립트 다리 때문에 성능이 제한된다. 스크롤이 끊기며, 앱이 최상의 성능을 발휘하지 못하고, 디버깅도 어렵다.
플러터는 실제 네이티브 코드로 컴파일하며 크롬이 사용하는 렌더링 엔진(스키아Skia)을 사용하므로 실행 시 다트를 변환하지 않는다. 즉 사용자의 디바이스에서 플러터 앱을 실행하면 성능이나 생산성이 저하되지 않는다.
컴파일 시간
네이티브 모바일 개발 경험을 가진 독자라면 가장 어려운 문제 중 하나가 개발 주기다. iOS는 컴파일 시간이 길기로 유명하다. 플러터에서 전체 컴파일은 보통 30초가 걸리며 핫 리로드 덕분에 점진적 컴파일은 1초도 걸리지 않는다. 현재 필자가 근무하는 회사에서는 플러터의 개발 주기가 빠르므로 모바일 클라이언트 기능을 먼저 개발한 다음 웹 클라이언트를 개발한다.
한 번 구현하고, 한 번 테스트하고 모든 곳에 배포하기
앱을 한 번 구현하고 테스트도 한 번만 구현하면 iOS, 안드로이드로(그리고 곧 웹도!) 배포할 수 있다. 다트 유닛 테스트는 아주 쉬우며 플러터는 테스팅 위젯 라이브러리를 제공한다.
코드 공유
플러터 기술은 자바스크립트로도 가능하다. 하지만 네이티브 개발로는 불가능하다. 플러터와 다트 덕분에 웹과 모바일 앱은 클라이언트 뷰를 제외한 모든 코드를 공유할 수 있다. 의존성 주입dependency injection을 이용하면 앵귤러다트AngularDart 앱과 플러터 앱에 같은 모델과 컨트롤러를 사용할 수 있다(플러터는 웹, 데스크톱도 지원할 예정이다). 웹 앱과 모바일 앱이 같은 코드 공유를 원하지 않더라도 iOS 앱과 안드로이드 앱은 필연적으로 모든 코드를 공유한다.
덕분에 모바일 팀의 생산성을 극대화할 수 있다. 필자도 모바일 기능을 먼저 개발한다. 웹, 모바일이 비즈니스 로직을 공유하므로 모바일 기능을 먼저 개발하면 같은 컨트롤러 데이터를 이용하므로 웹에서는 뷰만 개발하면 된다.
생산성과 협업
iOS, 안드로이드 팀이 따로 활동하는 시대는 지났다. 웹 앱에 자바스크립트를 사용하든 다트를 사용하든 플러터 개발은 웹 앱과 비슷하므로 모든 팀을 하나로 합칠 수 있다. 자바스크립트 웹 개발자가 플러터와 다트를 효과적으로 사용하는 개발자가 되기란 누워서 떡 먹기다. 필자의 생각이 맞는다면 새로 합쳐진 팀은 세 배나 생산적인 팀이 된다.
코드 유지 보수
한 개의 버그를 고치면 모든 클라이언트의 버그가 함께 고쳐진다. 특별한 상황에서만 iOS 앱 또는 안드로이드 앱에서 버그가 생길 수 있다. 이런 상황에서 대부분의 버그는 실제 버그가 아니라 플러터의 내장 위젯이 OS 설계 시스템을 따르는 데서 발생하는 외형적인 문제로 텍스트 크기, 정렬 등 쉽게 고칠 수 있는 버그가 대부분이다.
· · ·
플러터를 사용해야 할까?
사람마다 어떤 기술에 대해 장점과 단점을 말하곤 한다. 결국 대부분의 기술은 장단점을 모두 갖는다. 플러터는 어떨까? 이미 여기저기에 필자의 답을 뿌려 놓았지만 한 번 더 정리해보자.
여러분이 보조 프로젝트나 새 프로젝트를 시작하는 개인 개발자라면 답은 쉽다. 플러터를 사용하면 된다. 플러터는 완벽한 선택이다. 다트와 플러터에 익숙해질수록 장기적으로 더 큰 이득을 얻는다.
여러분이 새로운 기술 도입 여부를 결정해야 하는 CTO라면 조금 복잡하다. 새 프로젝트를 시작하거나 웹 개발자의 기술을 활용할 계획이라면 플러터를 사용하자. 결과적으로 좋은 성과를 내는 응집된 팀이 만들어질 것이며 여러분의 모든 모바일, 앱 개발자는 플러터에 금세 익숙해질 것이다. 하지만 이미 규모가 큰 iOS 팀과 안드로이드 팀을 갖고 있다면 플러터 선택에 조금 더 신중할 필요가 있다. 두 클라이언트를 각각 담당할 팀을 유지할 충분한 자원이 있다면 플러터 앱을 다시 만들 이유가 적어진다. 새로운 기술에 도박을 걸 이유가 없다. 플러터는 누구나 네이티브 품질의 앱을 만들 수 있게 도와주지만, 이미 네이티브 앱을 갖고 있다면 무리하게 플러터 앱으로 전환할 필요가 없다(에어비앤비가 리액트 네이티브를 포기한 이유도 이 때문이다).
한 시간이면 새로운 플러터 앱을 만들어 구동할 수 있다. 기존에 iOS나 안드로이드 앱을 개발했던 개발자라면 이미 필요한 도구가 갖춰져 있으므로 더 빨리 플러터 앱을 만들 수 있다. 직접 플러터 앱을 만들어보자.
· · ·
댓글 입력
자료실

최근 본 상품0