순다르 피차이 구글 최고경영자(CEO)가 10일(현지시간) 미국 캘리포니아주 마운틴뷰 쇼어라인 엠피씨어터에서 열린 '구글 연례 개발자 회의(I/O)'에서 연설을 하고 있다. 연합뉴스
구글이 사람처럼 묻고 답하는 인공지능(AI) 챗봇 '바드'(Bard)를 미국과 한국 등 전세계 180개국에서 전면 공개했다. 이에 따라 지난해 11월 출시된 오픈AI의 챗GPT와 본격적인 경쟁이 전개될 전망이다.
순다르 피차이 구글 최고경영자(CE)는 10일(현지시간) 미국 캘리포니아주 마운틴뷰 쇼어라인 엠피씨어터에서 개최한 '구글 연례 개발자 회의(I/O)'에서 "오늘부터 바드 이용을 위한 대기자 명단 운영을 종료한다"고 밝혔다. 바드 전면 공개는 지난 3월 출시한 지 한 달 반 만이다.
바드에는 구글의 최신 대규모 언어 모델(LLM) 팜2(PaLM)가 탑재됐다. 팜2는 지난해 4월 선보인 팜의 업그레이드 버전으로, 100개 이상의 언어를 지원한다. 5300억개의 파라미터(매개변수)를 바탕으로 과학·수학에 대한 추론뿐 아니라 코딩 작업도 한다고 구글은 설명했다.
그동안 영문만 지원해온 바드는 이날부터 한국어와 일본어 지원하기 시작했다. 바드의 두 번째 지원 언어가 한국어인 것이다. 구글은 조만간 40개의 언어로 서비스를 지원할 예정이라고 밝혔다.
바드의 질문과 답변에는 시각적인 요소도 추가됐다. 이에 따라 이용자 질문에 이미지를 제시해 답할 수 있다. 바드에는 시각 분석을 통해 관련 정보를 가져올 수 있도록 구글 렌즈(Google Lens)가 결합된다.
눈의 피로를 줄이기 위해 다크모드(어두운 화면에 흰 글자) 기능이 적용됐다. 다음 주부터는 답의 출처 표기 기능도 추가된다. 바드 답변은 바로 구글 G메일과 문서로도 내보낼 수 있다.
바드가 내놓을 오답을 의식한 듯 피차이 CEO는 "현재 사용되는 대규모 언어 모델들은 아직 한계가 있는 초기 기술"이라며 "앞으로 관련 서비스를 확장해 나가면서 품질을 중시하고 엄격한 기준을 유지하며 AI 원칙을 준수해 나갈 것"이라고 말했다. https://www.joongang.co.kr/article/25161607
1) CDATA로 감싼 JAVASCRIPT부분이 의도치 않게 XML Parser 에 의해 잘못 인식되는 것을 막기 위함. 2) XHTML이 아닌 HTML로 인식되는 경우에도 JAVASCRIPT가 문제없이 동작하도록 하기 위함. 3) javascript안에서 태그를 사용할 경우 CDATA 선을 해줘서 오류처리를 막기 위함.
그 중 두 번째 Recode를 위한 기술로 Flutter를 선택한 이유는 다음과 같습니다.
Flutter는 최근 모바일 앱뿐 아니라 PC와 웹 개발도 가능하게 돼 플랫폼 확장성을 확보할 수 있었고, 기술 공개 후 빠르게 발전하고 있어서 필요한 정보를 보다 수월하게 획득할 수 있을 것이라고 판단했습니다.
공통 코드로 UI를 구성할 수 있으며 자유도가 높았습니다. 특히 KMM 개발 당시Android Compose UI개발 만족도가 높았던 터라 선언형 UI 패러다임으로 완전히 전환하고자 했던 저희 목적에 부합했습니다.
네이티브 대비 성능 부분에서 위험성이 낮았고, 네이티브 기능을 개발할 때는MethodChannel을 활용하면 크게 제약 받는 부분이 없었습니다.
통합 개발 환경(IDE) 부분에서 팀 원 모두에게 익숙한 Android Studio를 활용할 수 있었습니다(참고).
Flutter로 다시 갈아엎자 ㅆ (←웃는 눈 모양입니다)
Flutter는 Dart 언어를 사용합니다. 따라서 Dart 언어에 익숙해지지 못하면 Flutter로 제대로 개발할 수 없습니다. 이때Dart tour 문서를 참고하면 언어 특징을 빠르게 훑어보기 좋습니다. Dart 언어의 상세한 부분까지 잘 소개한 문서입니다. Dart 언어를 개략적으로 이해한 후에Flutter Codelab 페이지를 읽어보면 Flutter를 보다 쉽게 이해할 수 있습니다.
Recode는 Dart 언어를 익히고 Flutter에 익숙해지는 것으로 시작해서 시작부터 출시까지 약 3개월 정도 진행했습니다. 제한된 기간 내에 1.0과 3.0 모드를 모두 제공해야 했으므로 공식 문서를 보며 Dart와 Flutter를 학습하면서 동시에 스펙 - 뷰 상태 - 로직을 잘 분리해 나가며 학습과 개발을 동시에 진행했습니다. Recode 시작 당시에는 Flutter SDK 3.0.2이었고, 출시할 즈음에는 Flutter SDK 3.0.5로 개발했습니다.
Flutter는선언형 UI 개발을 하기 때문에 가장 큰 고민 거리는 UI 상태 관리입니다. 상태 관리와 관련해서provider와bloc,getx등의 패키지가 있는데요. 처음 Recode를 시작할 때 패키지 학습 비용 및 패키지 의존성으로 인한 부담 때문에 직접 구현하는 형태로 진행했습니다. 상태 변경을 위해서ChangeNotifier를 활용했고, 상태 집단은 StateModel로 관리했습니다. 제품 개발에 반드시 필요한 패키지(예를 들어FlutterFire,google_maps_flutter등)가 아니라면 가급적 직접 구현하는 것을 원칙으로 정했습니다.
KMM과 비교해 구현 난이도가 높았던 사례
Flutter로 갈아엎으면서 KMM과 비교해 구현 난이도가 높았던 부분도 있었습니다. 권한 획득이나 푸시 수신 시나리오 같은 경우 각 플랫폼에서 제안하는 개발 가이드라인에 차이가 있는데요. KMM 때는 네이티브 영역을 각각 구현해 코드 복잡도가 높지 않았는데 Flutter로 변환하면서 하나의 코드로 작성하다 보니 플랫폼에 따른 분기 코드가 종종 발생해서 코드 가독성을 저해하는 부분이 있었습니다. 아래는 Flutter로 변환한 후 Android와 iOS 앱 실행 후 흐름입니다.
Android 앱 실행 흐름
iOS 앱 실행 흐름
플랫폼별로 SDK나 패키지 작동이 달랐던 사례
플랫폼별로 SDK나 패키지 작동이 기대와는 조금씩 달랐던 경우도 있었습니다. 예를 들어 앱 내 진동 효과를 발생시키는 코드를 플랫폼별로 다르게 구현해야 하는 경우입니다. Android는Vibration패키지에서 제공하는 인터페이스를, iOS에서는 Flutter SDK에서 제공하는 인터페이스를 사용하는 것이 요구 사항에 가장 적합하게 작동했습니다. 스펙에는 진동이 300ms, 500ms, 1000ms와 같은 방식으로 정의돼 있었는데 플랫폼별로 작동에 차이가 있어서 이를 구현할 때 분기가 필요했습니다.
위와 같은 코드는 Recode 출시 후 단계적으로 추상화하며 플랫폼별 구현체로 리팩토링하고 테스트 코드를 작성하면서 보다 가독성이 높고 유지 보수하기 좋은 형태로 변경하고 있습니다. 아래는 위 코드를 개선한 결과입니다.
de_theme_effect.dart
// The interface is reused.
void _vibrate300() => VibrationHelper.vibrate(VibrationEffect.effect300);
...
enum VibrationEffect { effect300, effect500, effect1000 }
class VibrationHelper {
// vibration only support Android, iOS platform.
static void vibrate(VibrationEffect effectType) {
// Note) PlatformUtils also an abstract class of each platform implementations.
if (PlatformUtils.isAndroid) {
_vibrateAndroid(effectType);
} else if (PlatformUtils.isIOS) {
_vibrateIOS(effectType);
} else {
log('${effectType.name} vibrate fail, Unsupported platform type');
}
}
static void _vibrateAndroid(VibrationEffect effectType) async {
// implementation as a vibration package.
if (await Vibration.hasVibrator() == true) {
switch (effectType) {
case VibrationEffect.effect300:
Vibration.vibrate(duration: 300);
break;
case VibrationEffect.effect500:
Vibration.vibrate(duration: 500);
break;
case VibrationEffect.effect1000:
Vibration.vibrate(duration: 1000);
break;
}
}
}
static void _vibrateIOS(VibrationEffect effectType) {
// implementation as a flutter(default) package.
switch (effectType) {
case VibrationEffect.effect300:
HapticFeedback.lightImpact();
break;
case VibrationEffect.effect500:
HapticFeedback.mediumImpact();
break;
case VibrationEffect.effect1000:
HapticFeedback.heavyImpact();
break;
}
}
}
Dart
트러블 슈팅 사례
두 번째 Recode 과정 중에 경험한 주요 트러블 슈팅 사례를 소개하겠습니다.
Google 지도 관련 이슈
먼저 Google 지도와 관련해서 발생한 두 가지 이슈를 소개하겠습니다.
의존 관계 업데이트 후 사이드 이펙트로 앱 성능 저하
배송원 앱에서는 배송원 위치와 가맹점 위치, 고객 드위치를 지도 위에 마커로 표시합니다. 지도는 Google 지도(google_maps_flutter) 패키지를 사용하고 있고, Google 지도를 사용하기 위해 아래와 같이 pubspec.yaml에Caret 문법를 활용해 의존 관계를 추가해 놓았습니다. 그런데 어느 순간 앱 성능이 급격히 저하되는 이슈가 발생했고, 확인 결과google_map_flutter버전이 올라가면서 각 플랫폼 구현체 의존 관계가 업데이트된 것을 확인할 수 있었습니다. 이슈 발생 전후 pubspec.lock을 비교해 보면 아래와 같습니다.
이슈 발생 원인은google_map_flutter가 2.2.0으로 버전이 올라가면서google_map_flutter_android패키지 의존 관계가 업데이트돼 발생한 사이드 이펙트였습니다. 이슈를 해결하기 위해 pubspec.yaml에 선언한google_maps_flutter패키지 버전을 caret 문법 대신 고정된 버전을 사용하는 것으로 수정했습니다.
pubspec.yaml
# AS-IS: Performance degradation due to version-up
dependencies:
google_maps_flutter: ^2.1.3 // It means '>=2.1.3 <3.0.0'
# TO-BE: Specify as fixed version
dependencies:
google_maps_flutter: 2.1.9
YAML
네이티브 영역에서 크래시 발생
Google 지도와 관련해 발생한 또 한 가지 이슈가 있습니다. 출시 후 Android 버전에서 crash-free(* 특정 기간 동안 비정상 종료가 발생하지 않은 사용자 비율)가 약 96~97%로 불안정한 상태가 지속됐습니다. Crashlytics 로그에서는ByteBuffer나Thread등 네이티브 영역에서 크래시가 발생한 것으로 나타나 정확한 원인을 파악하기 힘든 상황이었는데요. 크래시 발생 시 생성된 로그를 분석한 결과 강제 로그아웃이 발생해 로그인 화면으로 전환될 때 이런 상황이 발생하는 것을 확인할 수 있었습니다. 배송원 앱은 로그인에 성공하면 Google 지도를 화면에 표시하는데 이때 화면 전환 등으로 지도가 표시되는 화면이 사라질 때 크래시가 발생하는 것으로 예상됐습니다.
이 이슈는Google MapView의Rendering옵션을LATEST로 사용하면 해결할 수 있는 것으로 알려져 있었습니다(참고). 이를 참고해서 Android 네이티브 소스 코드를 수정해 crash-free를 99% 이상으로 안정화할 수 있었습니다. 현재google_maps_flutter_android패키지 2.4.0 버전부터는LATEST렌더링 옵션을 제공하도록 개선돼(참고) Flutter 소스 코드에서도 렌더링 옵션을 수정할 수 있도록 업데이트됐습니다(이와 관련해google_maps_flutter에 등록된이슈를 참고하시기 바랍니다).
제스처 미작동 이슈
아래 화면은 배송원 앱의 주문 상세 확인 화면입니다. 이 화면에서는 크게 좌우로 스와이프해 페이지 닫기,PageView내에서 좌우로 스와이프해 탭 화면 이동, Google 지도 내에서 핀치 줌(pinch zoom) 제스처가 가능합니다. 그런데 Android 기기에서 Google 지도 내 핀치 줌이 작동하지 않는 이슈가 발생했습니다.
제스처와 관련해 발생하는 문제는 두 가지였습니다.
Gesture Arena에서 여러 제스처가 경쟁해 Google 지도 제스처가 제대로 작동하지 않음
Gesture Arena에서 좌우 페이지 스와이프 제스처, 페이지 백 제스처, 상하 스크롤 제스처, 지도 제스처 등 여러 제스처가 경쟁해 Google 지도 제스처가 제대로 작동하지 않는 경우가 발생했습니다. 이때 Gesture Arena에서 경쟁하지 않고 즉시 모든 터치 이벤트를 받을 수 있게 하려면gestureRecognizers에EdgarGestureRecognizer를 추가해야 합니다.
EdgarGestureRecognizer는 일반적으로AndroidView.gestureRecognizers에서 전달되며 뷰 범위 내 모든 터치 이벤트를 내장된Android View로 즉시 발송하기 때문에 Gesture Arena에서 경쟁하지 않고 모든 터치 이벤트를 즉시 발송하므로 모든 터치를 전달받을 수 있습니다. Google 지도와 같이 모든 이벤트를 즉시 받아야 하는 뷰의 경우 유용하게 사용할 수 있습니다.
PageView 이동 시 첫 번째 페이지의 Google 지도에서 멀티 터치가 제대로 작동하지 않음
이 문제는viewportFraction이 기본 값인1.0인 경우 페이지가 완전히 넘어갔다고 판단하지 않아서 포커스를 완전히 넘겨주지 않아 발생한 문제였습니다.PageView의allowImplicitScrolling 프로퍼티를true로 설정해서 다음 화면 요소로 이동했다고 판단되면 포커스를 이동하도록 설정해 해결할 수 있었습니다.
텍스트 표시 관련 이슈
일본어 한자가 중국어 번체로 표시됨
iOS 기기 중 특정 기기에서 일부 문자가 일본어가 아닌 중국어(번체)로 표시되는 이슈가 발생했습니다. 예를 들어, '配達設定(배달설정)' 문구에서 일본어 한자('設')가 아닌 중국어 한자('設')로 표시되는 이슈로, 기기나 OS에서 제공하는 폰트마다 이런 이슈가 있을 것으로 예상했습니다.
배송원 앱 설정 화면 > 중국어 한자 표시 이슈
이 이슈를 해결하기 위해 스타일 프로퍼티(TextStyle)에locale 프로퍼티를 각 언어에 맞게 잘 설정해 줬지만 해결되지 않았습니다. 이에 iOS 기본 폰트에서 일본어 한자를 제대로 지원하지 않는 경우가 있다고 판단했고, iOS의fontFamilyFallBack 프로퍼티를 [.AppleSystemUIFont', 'Hiragino Sans']로 설정해 해결할 수 있었습니다. 아래는 코드 실행 결과입니다.
iOS와 Android 앱은 기기 설정에서 디스플레이 및 텍스트 크기를 변경할 수 있습니다. 기기 설정에서 이 옵션을 최소 및 최대로 설정할 경우 화면이 제대로 표시되지 않는 이슈가 발생했습니다. 이를 수정하기 위해 디자인 팀과 논의해MediaQuery위젯을 이용해서textScaleFactor를0.7~1.4로 제한하고, 필요에 따라 고정된 텍스트 크기로 표시되는 위젯을 만들어 대응했습니다.
백그라운드 상태에서 FCM(Firebase Cloud Messaging) 수신 시 isolate 관련 이슈
firebase_messaging패키지를 이용하면 앱이 백그라운드에 있는 상태에서 FCM 푸시 수신 처리가 가능합니다(참고). 그런데 이때SharedPreference에 접근할 경우 'When received, an isolation is spawned. Since the handler runs in its own isolate outside your applications context, it is not possible to update application state or execute any UI impacting logic.' 메시지와 함께 오류가 발생합니다.
Dart 앱은 단일 스레드 프레임워크이며 스레드 대신isolate에서 작동합니다. Isolate를 새로 만들고 서로 통신할 수는 있지만 각 isolate는 고유한 메모리 힙을 할당받기 때문에 공유하는 메모리는 없습니다. 백그라운드에서의 푸시 콜백은 새로운 isolate에서 전달하는 것이기 때문에 메인 isolate의 메모리 데이터를 사용할 수 없어서 위와 같은 오류가 발생합니다. 이 문제는 앱 디렉터리 하위에 JSON 형식의 파일로 데이터를 저장하고 관리할 수 있는 유틸리티를 만들어서 FCM 수신 시 로컬에 데이터 저장이 필요한 경우에는 이 유틸리티를 사용하는 것으로 해결했습니다.
기술 변경으로 더욱 돈독해진 팀워크
두 번째 Recode 과정에서는 새로운 기술을 학습하면서 동시에 그 기술을 활용해 제품을 만들어 내는 과정을 진행했습니다. Flutter 기술을 완벽히 이해하고 있지 않아서 여러 가지 우려가 있었지만 결과적으로 긍정적인 피드백이 많았습니다. 두 번째 Recode 프로젝트 회고에서 KMM에서 Flutter로 전환한 결과 가장 좋았던 점으로 모든 분들이 공감해 주신 것은 동일한 소스 코드로 고민과 토론이 가능해졌다는 점이었습니다.
KMM으로 개발할 때는 Android와 iOS, KMM 각 영역에서 개발자가 본인 업무에 해당하는 영역에서만 개발을 진행하면서 각자의 관심 기술에만 집중했고, 이는 결국 장기적인 관점에서의 협업 측면이나 기술 성장 측면에서 아쉬움을 남겼는데요. Flutter로 전환하면서 Flutter라는 기술과 Dart라는 언어를 이용해 함께 고민하고 학습하며 그 내용을 실제 프로덕트에 반영하는 기회를 얻었고, 그 과정에서 발생한 급박한 상황 역시 생각보다 더 긍정적으로 회고됐습니다. 저희와 같이 소수(3~4명) 인원이 하나의 앱을 개발할 때는 같은 언어로 함께 고민하며 프로젝트를 진행하는 게 성장과 협업 측면에서 더 큰 동기를 부여할 수 있다는 것을 느꼈습니다.
팀 전체 관점에서도 공감대가 넓어졌습니다. 데마에칸 서비스 중 배송원 앱뿐 아니라 가맹점 앱, 리테일 앱 역시 Flutter를 활용하고 있기에 팀 차원에서 기술 교류가 시작됐고, 각 앱에서 공통으로 사용하는 모듈도 개발 가능해져 협업 측면에서도 좋아졌습니다. IDE나 CI/CD 환경 혹은 각 프로젝트의 아키텍처를 공유할 수 있게 됐고, 리팩토링이나 테스트 코드 등도 함께 고민하고 공유할 수 있어서 개인은 물론 팀 전체가 함께 성장하는 데 큰 도움이 되고 있습니다(공통 모듈을 만들어 활용하고 있는 내용은Flutter 패키지로 공통 모듈 리팩토링하기를 참고하세요). 🙂
마치며
모바일 앱 개발 기술로 Flutter를 고민하고 있다면 아래와 같은 이유로 추천합니다.
한정된 자원으로 멀티 플랫폼 개발을 할 수 있습니다. Android와 iOS뿐 아니라 PC와 웹으로도 개발할 수 있어서 다양한 형태로 제품을 검증할 수 있고 QA 환경 구성에도 유리합니다.
앱 개발자에게 멀티 플랫폼 기술은 네이티브 개발자에게 다음 단계를 도전하기 위한 큰 과제와도 같기 때문에 커리어를 쌓고 채용 시장에서 경쟁력을 높일 수 있는 좋은 기회라고 생각합니다.
개인과 팀 모두 고민하고 성장하기 위한 환경을 고민하고 있다면 좋은 선택이라고 생각합니다.
배송원 앱은 Recode 후 새로운 버전에서 사용자에게 더 좋은 가치를 안정적으로 제공하기 위해 Flutter로 모듈화하고 테스트 코드를 작성하는 것에 집중하고 있습니다. Flutter 개발자분들과 더 나은 상태 관리 방법과 효율적인 의존 패키지 버전 관리 방법, 보다 빠른 빌드 및 배포 자동화 구성 방법, 그리고 새로운 프로덕트를 더 잘 만드는 방법 등을 고민하고 있습니다(개발자라면 대부분 공감할 부분들이라고 생각합니다 🙂 ). 사용자에게 더 나은 서비스를 제공할 수 있다면 세 번째 Recode를 진행해야 할 상황이 오는 게 조금은 기다려지기도 한다고 생각하며 글을 마치겠습니다.
회사 입장에서 어려움 점을 이해해 보고 주니어 개발자가 꼭 알아야 할 점을 파악해 봅니다.
1️⃣ 주니어 개발자는 1, 2년의 투자 기간이 필요하다
최소 1, 2년 정도 한 사람에게 투자할 수 있는 팀이 아니라면 주니어 개발자를 고용하지 않는 것이 좋다. 특히 투자자들에게 결과물을 빨리 내야 하는 스타트업에는 적합하지 않은 고용 방법일 수 있다.
2️⃣ 그들에게는 경력이 많은 관리자가 필요하다
경력이 없거나 자질이 없는 관리자는 주니어 개발자를 고용하거나 멘토 할 수 없다. 주니어 개발자를 고용하려면 경력이 풍부한 관리자가 필요하다.
3️⃣ 잘 정의된 업무만 줄 수 있다
주니어에게 몇 주 만에 결과물을 내야 하는 업무를 줄 수 없다. 따라서 팀은 최소 6개월에서 12개월 안에 결과물을 낼 수 있는 프로젝트를 갖고 있어야 한다. 하지만 실상에서 '주니어'에게 적합한 프로젝트를 많이 가진 팀이 없다.
4️⃣ 주니어 개발자에게 투자한 만큼 이득을 못 볼 수 있다
실리콘 밸리의 엔지니어는 같은 회사 근무 기간이 평균 18개월에서 24개월이다. 그만큼 이직이 잦은데, 주니어 개발자를 성장시키기 위해 약 1년에서 2년 투자하면 이득을 보기 전에 그들은 다른 회사로 이직할 확률이 크다.
📌 원문에는 '시니어 개발자의 생산력을 저하한다'라는 포인트도 있지만, 개인적으로 주니어 개발자를 발굴하고 그들을 성장시키는 것 또한 시니어 개발자의 직책이라고 생각합니다. 단기적으로 생산력을 저하할 수 있어도, 여러 가지 프로세스 개선(예: 개발자 온보딩 코스 만들기, 자주 묻는 질문에 대한 답변 문서화하기, 그룹 학습 세션 정기적으로 열기, 다른 사람에게 위임하기 등등)을 통해 생산력을 올릴 수 있고, 무엇보다도 장기적으로 보면 좋은 일이라고 생각합니다. 그리고 팀마다 적합한 시니어/주니어 비율을 갖는 것이 '회사의 책임'이라고 생각합니다. 좋은 시니어/주니어 비율과 학습 프로세스 개선은 오히려 생산성을 높일 수 있다고 봅니다.
📌 주니어 개발자가 알아둬야 할 점
글을 읽고 주니어 개발자가 알아야 할 점을 생각해 봤습니다.
1. 경험이 많은 관리자가 있는 팀을 찾자. 2. 주니어 개발자에게 투자할 수 있는 팀인지 확실하게 알아보자. 3. 시니어/주니어 비율이 상대적으로 좋은 팀으로 가자. 4. 온보딩 프로세스나 문서화가 잘되어 있는 팀은 주니어 개발자로써 학습 속도를 끌어올리는 데 도움 된다. 5. 주니어 개발자의 성장을 돕고 '그들의 성장'을 '직책'이라고 여기는 시니어 개발자와 관리자와 함께 일하는 것이 좋다.
