3~4년 전부터 모바일 서비스 개발에 대해 멀티플랫폼으로 가능하도록 하는 것은 큰 관심사이자 채용시장에서 경쟁력을 갖출 수 있는 도전과제라고 생각하고 있었습니다. 개인적으로는 네이티브앱 개발 환경에 익숙하고, 특히 안드로이드 개발 경험이 많은 상황이다보니 상대적으로 KMM 에 좀 더 관심이 많았습니다. 하지만 팀 차원에서 해당 기술을 활용하기에는 개발 환경 구성상 제약사항이나(특히 iOS 버전이 올라갈때 마다 발생되는), 기술의 숙련도 차이로 인한 업무 비대칭이나 구조적인 기술부채 발생 등 우려되는 이슈로 어렵지 않을까 하여 적극적으로 시도해보기 보다는 수박 겉핥기 식으로 고민만 하고 있었던 것 같습니다. 💦
당시에는 시장에서 React Native 개발자에 대한 수요가 높다고 판단했으나, 장기적으로 Flutter가 좀 더 낫지않을까 막연한 생각이 있었습니다. 이 후, Google I/O 2022 에서 소개된 Flutter 에서 플랫폼 확장성이 용이한 Flutter 에 대해 마음이 좀 더 기울어지게 된 것 같습니다.(?)
우연한 기회로 새로운 팀에 합류하여 Flutter 를 활용하여 서비스를 만들게 되었습니다. 빠르게 실무환경에 적응하기 위하여 준비한 것 부터 어느덧 Flutter 를 이용하여 개발을 시작한지 100일정도 된 이야기와, 개인적인 생각을 가벼운 회고 형식으로 정리해 봤습니다.
학습하기
개인적으로 어떤 미션을 해내기 위하여, 아래 두가지 전략을 잘 활용하면 온전히 내 것을 만들 수 있다고 생각합니다. 그리고 이 전략을 적절히 잘 활용할 수 있는 상황인지 판단하는 것이 중요합니다.
- 일단 부딪쳐 본다. > 경험한 내용에 대한 지식을 학습한다. > 동일한 상황에서 이전에 실행한 것과 지식을 적절히 활용한다.
- 필요한 지식을 습득한다. > 하나하나 실천해 본다. > 실천한 것들이 올바른지 다시한번 지식을 탐구해 본다.
요약하면 ‘학습 — 실행 — 학습 — 실행 … 의 반복’이며 이것을 상황별로 잘 사용하는 것입니다. ‘학습 — 실천’ 혹은 ‘실천 — 학습’ 두 단계 만으로는 온전히 내것이 되지 않기 때문에 반드시 이 과정의 반복단계를 실행할 수 있는 환경에 있거나, 의도적으로라도 하는것이 중요하며, 개인이나 팀 차원에서 회고 단계가 있다면 더 없이 좋습니다.
합류 전 학습할 수 있는 시간동안 아래와 같이 초기 학습을 시작했습니다. 목표는 ‘코드를 읽고 그것이 어떤 의미인지 이해하는데 필요한 시간을 최소화' 하는것으로, 빠르게 책 한권을 패스하고 이론적으로 이해하기 위해 정리를 시작했습니다. 도움이 되었던 내용은 Flutter Codelab, Dart — language tour 였습니다. 실무에서 부딪쳐 보면서 자세한 내용을 알 수 있을거라 생각해서, 코드의 흐름이나 클래스의 선언, 문법, UI 의 구현 방법 등 코드를 읽거나, 최소한의 디버깅을 할 수 있을 수준으로 학습하는것에 중심을 두었습니다. 개인적으로, IDE 의 지원을 어느정도 제약을 두고 UI 까지 코드 작성 해 볼수 있는 dartpad 사이트가 도움이 많이 되었습니다.
IDE 는 Android Studio 와 VSCode 가 사용 가능한 것으로 알려져있으나 개인적으로 좀 더 익숙한, 그리고 팀 전체적으로 활용하기로 결정된 Android Studio 를 활용하고 있습니다. IDE 의 부가 기능들을 활용할 수 있는 configuration 을 구성하여 단일 툴을 활용하는 것이 좋습니다. 개인적으로 생산성 향상에 도움을 주었다고 느꼈던 것은 Live Templates 기능이었습니다. kotlin 과 비교했을 때 상대적으로 boilerplate code 작성이 많이 필요하다고 느꼈으며, 기본 UI 작성을 위한 ‘stful’ 템플릿은 이러한 입력 시간을 상당히 많이 단축시켜줬습니다.
Flutter Youtube 를 통해 자주 좋은 정보를 올려주고 있으며, Twitter 를 이용하여 적극적으로 엔지니어와 소통을 하려고 하고있어, Slack — RSS 피드를 설정하여 지속적인 정보를 얻는데 활용하고 있습니다. 아래 Twitter 는 연동해 두었습니다. (https://blog.codemagic.io/top-flutter-developers-to-follow-on-twitter/ 와 같은 내용을 검색하여 도움을 얻으면 좋을 것 같습니다.)
- https://twitter.com/flutteriodaily
- https://twitter.com/FlutterDev
- https://twitter.com/flutterreleases
- https://twitter.com/dart_lang/
회고
hello dart, hello flutter
코드 작성 레벨에서 초기 적응간 어려웠던 부분은 2가지 정도 생각납니다. 하나는 클래스 생성자 작성하기, 또 하나는 async — await 부분입니다. 클래스의 동작을 위한 외부 정보를 주입하기 위해 보통 생성자에 파라미터로 값을 전달하는데, required / optional named paramter 문법을 혼용해서 사용이 불가능한 부분, 파라미터로부터 클래스 내부 변수를 초기화 하는 코드에서 , 와 ; 의 오묘한 구분감이나(?), 객체 초기화를 위한 cascade notation syntax 가 더해져 빠른 코드작성에 어려움을 겪었습니다. async — await 문법의 경우, async 함수 내부에서 공통 코드를 async 함수로 분리할 때, 분리 후 해당함수를 호출하는 부분에서 분리한 함수가 동기 처리가 보장된다고 생각하고 await 을 빼먹는 실수를 종종 했습니다. 언어적으로 적응이 어려웠던 부분은 시간이 잘 해결해 줬습니다. (정말 플러터 개발자가 된거 같은 기분입니다 🤪)
시작한지 얼마 되지 않기 때문에 시간이 흐를수록 초기에 작성했던 코드들이 아쉬운 부분이 많이 보이는(?) 현상이 있습니다. 예를들어, 위에서 겪었던 어려움에서 작성된 코드나 enum 을 활용한 코드의 경우입니다. dart, flutter 도 빠르게 개선되고 있기 때문에 틈틈히 리팩토링을 통해 더 깊은 이해를 가져갈 수 있도록 노력이 필요하다고 생각합니다.
mobile app dev team
Flutter 시작 초기에는 이슈에 대한 접근이나 해결 방식을 네이티브 앱 개발자 관점에서 접근하는 것을 볼 수 있었습니다. 예를들어 Push 수신후 처리, 디바이스의 진동 및 사운드 제어, 웹뷰와 관련된 이슈, 권한 획득 프로세스 등입니다. 이는 결국 문제를 해결하는 과정에서 isAndroid / isIOS 와 같은 분기 코드가 먼저 떠오르게 합니다. 이 부분 역시 각 플랫폼 환경에서 문제를 해결하기 보다 공통 코드로 문제를 해결하는 방향으로 빠르게 적응할 수 있도록 노력했습니다.
보통 조직에서 앱 개발자는 현실적인 이유 등에서 iOS / Android 개발자 분들을 한 팀으로 운용합니다. 이에 따라 제품의 공통적인 요구사항이나 네이티브 앱에서의 새로운 기술에 대한 교류는 잘 되지만, 실제 실무에서 사용하는 기술이나 아키텍처, 구현부에 있어 차이가 있을 수 있습니다. Flutter 를 기술스택으로 사용하면서 앱 개발자간 Android / iOS 를 나누어 생각하지 않고, 제품 관점에서 동일한 코드를 바탕으로 고민을 하다보니 코드리뷰나 개선사항에 대한 토론을 다 같이, 심도있게 할 수 있다는 부분이 너무 좋았습니다. (새로운 기술을 배우는 즐거움은 덤!!)
multi-platform engineering
Flutter 는 하나의 코드로 여러 모바일 앱, 웹, 데스크톱 앱을 모두 지원하기 때문에 최대한 분기 코드는 없애는게 좋지만, 분기가 필요할 경우에도 로직과 구현체를 플랫폼별로 잘 분기처리 할 수 있도록 코드 작성에 주의를 기울일 필요가 있습니다. 그리고 맡은 과제에 대하여 iOS, Android 뿐만 아니라 타겟 플랫폼이 웹이나 데스크톱도 대상이라면 이에 대한 배경 지식들도 있어야 합니다.
흥미로운 부분은 Flutter 에서 현재 웹인지 아닌지 여부를 판별하는 kIsWeb 의 경우입니다. 1 == 1.0 은 네이티브와 앱이 모두 true 이지만, identical(1, 1.0) 결과 웹에서만 true 입니다. 이러한 현상이 발생하는 이유는 Numbers 문서를 참조하세요.
플랫폼 별 분기 처리해야 하는 경우 어느정도 아름답지 않은 코드를 감수할 수 있어야 합니다(??) . 예를들어, 파이어베이스 초기화 시 필요한 옵션을 얻어오는 코드는 아래와 같습니다.
멀티플랫폼을 지원하기 때문에, 이를 테스트코드로 잘 작성하는 것 또한 중요해 보입니다. 이를 위해 debugDefaultTargetPlatformOverride 프로퍼티를 설정할 수 있습니다.
기술적인 부분 뿐만 아니라, 다양한 플랫폼에 대한 개발자로서 기술 경험, 사용자 경험 등을 폭넓게 알고있으면 더 도움이 될 것으로 생각합니다. 실제로 플랫폼별로 요구사항이 미묘하게 다르거나, 플랫폼에 따라 어쩔수 없이 의존적인 이슈들도 대응해야 하므로 그 경계를 잘 판단해서 해결할 수 있는 능력이 중요하다고 느꼈습니다. 제품이 지원하는 대상 플랫폼을 명확히 정의하고 플랫폼에 대한 이슈 대응 원칙을 팀 차원에서 잘 수립하는것이 도움이 될 것으로 판단되는데, 이는 타겟 플랫폼 이외에는 지원하지 않는것으로 정의하기 위함이 아니라 이 후에 새로운 플랫폼을 빠르게 추가 확장하는데 더 도움이 될 것이라고 생각합니다.
마지막으로, 개인적으로 앱 개발시 테스트 환경을 구축할 수 있는가에 대하여 많이 생각하는 편입니다. Flutter 는 웹 타겟으로도 빌드가 가능하므로 웹에서 device_preview 를 이용하여 모바일 기기(Android, iOS) 별로 화면 구성을 통해 내부 테스트 환경 구축 등에 활용할 수 있습니다.
Flutter 개발자를 시작하게 되면서부터, 새로운 것을 배우고 멀티플랫폼 관점에서 생각하게 되어 생각의 폭을 넓혀 문제 해결을 접근하게 되는 것이 즐겁게 느껴집니다. 한동안은 Flutter 에 대한 이야기를 작성하지 않을까 생각해 봅니다 :)
