안녕하세요. ABC Studio에서 앱을 개발하고 있는 박유진, 최연두입니다. 2022년 상반기 신입 공채로 입사해 현재 Flutter로 일본의 음식 배달 서비스 Demaecan의 가맹점용 태블릿 앱을 개발하고 있습니다. 이번 글에서는 Android 개발자로 지원해서 Flutter 경험이 없던 저희가 Flutter에 적응해 나간 과정을 공유하려고 합니다.
네? Flutter요?! 할 수 있죠!
최종 합격 발표가 난 후 Android 개발자로서의 첫 커리어를 LINE에서 시작하게 돼 두근거리는 마음으로 기다리고 있던 작년 6월 9일, 전화 한 통을 받았습니다. 앞으로 하게 될 업무를 자세히 설명해 주시기 위해 팀에서 건 전화였는데요. 통화를 마무리하며 Android가 아닌 Flutter을 사용하게 될 것이라는 깜짝 놀랄 소식을 전해주셨습니다.
사실 돌이켜보면 최종 면접 때 "만약 입사 후 Android 네이티브가 아닌 일을 맡게 되면 어떨 것 같으세요?"라는 질문을 받았습니다. 그때는 대수롭지 않게 "개발자라면 변화하는 기술 트렌드를 빠르게 익히고 적응할 줄 알아야 한다고 생각합니다!"라고 자신만만하게 대답했는데요. 진짜 내 얘기가 되니 막막했습니다. 학교 공부와 인턴을 거치며 이제 조금 Android 개발을 알게 됐다고 생각했는데 다시 처음부터 시작해야 한다니!
하지만 '잘 이끌어 주실 자신이 있으니까 시키시는 거겠지?'하는 마음도 약간 있었습니다. 그렇게 팀을 한 번 믿어보자는 마음으로 불안한 첫걸음을 뗐습니다.
Flutter 온보딩
저희가 팀에 적응하고 실무를 시작할 수 있도록 팀에서는 아래와 같은 온보딩 커리큘럼을 준비해 주셨습니다. Flutter 공식 문서를 읽고 정리한 내용을 앱 개발자분들에게 공유하는 형태였습니다.
| 주제 | |
|---|---|
| 1주 차 |
|
| 2주 차 |
|
| 3주 차 |
|
| 4주 차 |
|
| 5주 차 |
|
| 6주 차 |
|
| 7주 차 |
|
| 8주 차 |
|
| 9주 차 |
|
처음 마주했을 때 방대한 커리큘럼이라는 생각이 들었는데요. 과연 총 8주간 온보딩을 진행하면서 다양한 경험을 할 수 있었습니다. 온보딩 중 몇 가지 기억에 남은 주제를 공유해 보려고 합니다.
가장 어려웠던 Flutter 상태 관리
제일 어려웠던 주제는 'Flutter 상태 관리(state management)'를 다루는 7주 차 커리큘럼이었습니다. 관련 공식 문서에서는 여러 상태 관리 기법을 소개하고 있는데요. 처음에는 어떤 상황에서 어떤 기법을 사용하는 것이 좋은지 'A to Z'를 설명해 보려고 했지만 이해하기가 쉽지 않아서 '자주 사용하는 상태 관리 기법'만 공유하기로 했습니다.
이후 실무에서 Redux를 사용하면서 이 상태 관리 기법을 언제, 어떻게, 왜 사용하는지 나름 기준이 생겼습니다. Redux는 전역 변수를 추가할 때마다 최소한 파일을 세 개 만들어야 하는데요. 이런 귀찮은 작업이 전역 변수를 하나 만들 때마다 신중하게 생각하도록 만들었고, 변수를 선언할 때 Redux에 의지해서 전역 변수를 쓰기보다는 최대한 로컬 변수를 쓰자는 나름의 기준이 생겼습니다.
뒤늦게 진가를 알게 된 Effective Dart
공부할 당시에 도대체 내가 무엇을 공부하고 있는 것인지 가장 알기 어려웠던 주제가 바로 3주 차의 Effective Dart입니다. 봐야 할 문서의 양이 가장 많은 주제였는데요. 문서에 적힌 수많은 텍스트가 쉴 새 없이 우리를 몰아치는데 당연한 내용인 것 같으면서도 한편으로는 '왜 이렇게 작성하는 게 좋은가'라는 의문에 답을 찾기 어려웠던 주제이기도 했습니다.
하지만 나중에 실무를 경험해 보니 이 내용이 가장 도움이 되는 내용이었습니다. Effective Dart 문서에서는 문서화를 위한 주석인 Dart Doc 사용법을 자세히 알려주는데요. 공부하면서 중요하다고 생각하는 몇 가지를 추려 체크 리스트를 만들었고, 그중에서 가장 중요한 세 가지를 아래에 옮겨와 봤습니다. 읽어보면 당연하다는 생각이 드실 수도 있지만, 실제로 확인해 보면 생각만큼 지키지 못하고 있다는 것도 알 수 있습니다.
- Do start doc comments with a single sentence summary
- Do separate the first sentence of a doc comment into its own paragraph
- Avoid redundancy with the surrounding context
체크 리스트를 만든 후 작성한 문서를 확인하면서 부족한 부분을 보완해 나가며 유지 보수하기 좋은 문서를 작성하는 나름의 기준을 잡을 수 있었습니다.
또한 문서를 작성하면서 얻은 부가 효과도 있습니다. 작성한 클래스와 멤버의 역할을 정확히 파악할 수 있다는 점입니다. 문서를 작성하며 의도한 대로 구현했는지 확인할 수 있기 때문에 역할을 넘어서는 동작을 잡아내거나, 담당하는 역할이 너무 많을 때는 역할을 분리해서 전체 구조를 보다 탄탄하게 만들 수 있었습니다.
가장 재미있었던 위젯 다루기
제일 재미있었던 주차는 위젯을 다루는 4, 5주 차였습니다. XML 대신 언어로 위젯을 만든다는 점과 위젯 트리를 구성해 가는 과정이 흥미로웠는데요. 특히 재밌었던 InheritedWidget을 짧게 소개하겠습니다.
아래 그림과 같이 InheritedWidget(이하 A)과 하위 노드 Widget(이하 B)이 있을 때, A의 데이터를 B에서 사용할 수 있습니다. 또한 final로 선언한 데이터를 가져와 사용할 때는 화면의 특정 영역(A가 루트 노드인 영역)에서 데이터를 싱글톤처럼 사용할 수 있는데요. 정말 활용도가 무궁무진하다는 생각이 들었습니다.
온보딩 커리큘럼 회고 - 다음 신입을 위한 커리큘럼 개선
Flutter 온보딩을 끝냈다고 바로 실무를 즉시 해낼 수 있는, 1인분을 할 수 있는 개발자는 되지 못했습니다. 다만 깊게 공부하고 준비하며 기초가 탄탄한 개발자로 성장할 수 있는 토대를 마련할 수 있었습니다. 온보딩 후 유진 님과 커리큘럼에 대한 회고도 진행했는데요. 아래와 같은 의견을 모을 수 있었습니다.
- 공부하면서 미리 읽었다면 앞 부분을 보다 쉽게 이해할 수 있을 것 같은 내용이 있었다.
- Flutter와 Dart를 무조건 병렬로 진행하는 게 좋은 것일까?
이런 의견을 바탕으로 커리큘럼에서 아쉽다고 느꼈던 부분을 보완해 아래와 같이 수정해 봤습니다.
| 수정 전 | 수정 후 | |
|---|---|---|
| 1주 차 |
|
|
| 2주 차 |
|
|
| 3주 차 |
|
|
| 4주 차 |
|
|
| 5주 차 |
|
|
| 6주 차 |
|
|
| 7주 차 |
|
|
| 8주 차 |
|
|
| 9주 차 |
|
|
혹시 Flutter 공부를 시작하신다면 참고하셔도 좋을 것 같은데요. 커리큘럼 수정의 주안점은 다음과 같습니다.
- Dart 이해도를 높이기 위해 초반에는 Dart에 집중할 수 있게 주제를 배치했습니다.
- Flutter에서 사용하는 키워드를 파악할 수 있는 내용을 앞에 배치했습니다.
- 온보딩을 진행하면서 흥미를 유지할 수 있도록 위젯 관련 부분을 앞으로 옮겼습니다.
- 가장 중요한 Flutter 상태 관리를 Flutter를 이해하고 나서 학습할 수 있도록 후반으로 옮겼습니다.
Flutter, 이제 실무에서 사용해 보자고!
그럼 실무에서 과연 Flutter를 어떻게 사용했는지 저희 두 사람의 이야기를 들려드리겠습니다.
박유진의 실무 이야기
실무를 시작하고 처음 느끼는 감정은 이미 촘촘하게 짜인 거대한 프로젝트에 내 코드가 누가 되지 않아야 하면서 동시에 내 몫을 하긴 해야 한다는 부담감과 두려움이었습니다. 이제 겨우 문서 읽기를 마친 상태에서 익숙치 않은 새로운 언어를 사용해야 했기 때문에 팝업이나 튜토리얼과 같은 간단한 기능 개발에도 시간이 오래 걸렸습니다. 얼른 익숙해지기 위해서 Flutter에서 제공하는 샘플 코드를 받아서 공부하거나 Codelabs을 차근차근 따라갔습니다.
- Basic Flutter layout concepts
- Take your Flutter app from boring to beautiful
- MDC-101 Flutter: Material Components (MDC) Basics
Flutter만의 아키텍처로!
실무를 시작하고 또 하나 신경 썼던 점은 아키텍처였습니다. Flutter는 상태 관리가 중요하기 때문에 여러 상태 관리 기법이 있습니다. 다음 버전에 도입하려고 하는 BLoC 구조를 미리 익혀보기 위해 기존 앱의 주문 목록 불러오기, 주문 상세 보기, 웹소켓 연결 등과 같은 주요 기능들만 떼와서 BLoC 구조에 맞는 샘플 앱을 만들었습니다. 팀원분들께 작업한 내용을 정기적으로 공유드리고 리뷰 받는 과정에서 Android에서 자주 사용했던 MVVM 패턴과 다른 점을 공부할 수 있었고, 이론만 공부하는 것으로는 해소되지 않던 애매한 부분들을 확실하게 이해할 수 있었습니다.
연습, 또 연습
더 나아가 지난 설 연휴에는 Flutter를 이용해 개인 프로젝트에 도전했습니다. Flutter는 Dart 코드로 위젯을 레고처럼 쌓아가는 선언형(declarative) UI로 뷰를 구성할 수 있습니다. 따라서 개인 프로젝트에서는 복잡하고 중첩된 UI를 정확하게 그려내는 연습을 많이 해서 그때그때 필요한 위젯을 찾아 쓸 수 있게 만드는 것에 초점을 맞췄습니다.
이처럼 개인 프로젝트를 한 번 진행하고 나니 Flutter만의 매력을 조금 더 제대로 느낄 수 있었습니다. iOS와 Android 모두 한 번에 개발할 수 있다는 점과, 핫 리로드(hot reload)를 사용하기 때문에 바로바로 UI를 확인할 수 있어서 개발 속도가 빨라진다는 점을 확실히 체감했습니다.
최연두의 실무 이야기
제 첫 실무 작업은 사용하지 않는 코드를 삭제하는 작업이었습니다. 사용처를 추적해 삭제하기만 하면 되는 작업이어서 금방 끝낼 수 있었고 다음 업무로 화면 하나를 구현하는 업무를 받았습니다.
새로 습득한 MECE
Android로 개발하면서 화면 단위 구현을 자주 해봤기 때문에 크게 어려운 과제라고는 생각하지 않았습니다. 요구 사항을 분석하고 설계하는 작업은 혼자 공부할 때도 자주 하던 작업이었기 때문인데요. 이번에는 팀원 리뷰를 받아야 한다는 게 달랐고, 리뷰를 받으면서 "연두 님, 화면 상태를 구분해 주셨는데 MECE를 만족하나요?"라는 질문을 받았습니다(MECE(Mutually Exclusive Collectively Exhaustive), 구성 요소들이 중복되지 않으면서 전체에서 누락되는 것이 없도록 세분화 및 구조화하는 것). 화면 상태에 이름을 붙이면서 다른 상태와 겹치는 이름을 부여했기 때문에 MECE를 만족하지 못한다는 것이 리뷰의 핵심이었고, MECE 원칙을 만족하기 위해 화면 상태 이름을 다시 검토했습니다. 이 과정을 통해 MECE 개념을 새롭게 습득할 수 있었습니다.
실무에서 '되다'는 좀 달라
요구 사항에 맞게 코드를 작성하고 결과를 공유하면서 "작동합니다! (다듬으면 거의 끝나요!)"라고 말하자 "오, 돼요? (이제 시작이네요!)"라는 답변을 받았습니다. 저는 대학 시절이나 취업을 준비하며 팀 프로젝트를 진행할 때 '되다'라는 말을 '작동하니 작업이 거의 끝나간다'는 의미로 사용했는데요. 지나고 보니 실무에서는 '설계 PoC(proof of concept)가 끝났으니 이제 인터페이스의 의도가 명확하게 드러나도록 구현하는 과정이 시작됐다'는 의미로 사용한다는 것을 알 수 있었습니다. 대화가 미묘하게 잘 통하지 않는다고 느낄 때는 서로 같은 의미로 단어를 사용하고 있는지 생각해 보는 것이 좋다는 것을 느꼈습니다.
사용자 편의를 위한 기능 추가
기획 요구 사항에는 없었지만 개발 과정에서 사용해 보니 불편한 점을 발견할 수 있었고, 텍스트 입력 창에서 이전 입력 내용을 지우는 요구 사항을 추가했습니다. 그런데 당시 구조에서 이 기능을 구현하면 기존에 없던 뷰와 뷰모델 간 상호 의존성이 생길 수 있었습니다.
- AS-IS:
Stateful Widget이 갖고 있는 상태를 뷰모델 함수로 넘겨주고 있었습니다. - TO-BE: 뷰모델이 갖고 있는 상태 값을
Stateful Widget이 보여주도록 변경했습니다.
결국 작은 기능을 추가하기 위해 구조를 변경했습니다. 이 경험을 통해 작은 기능 추가에도 구조적인 문제를 고려해 전체 구조를 재조정해야 하는 상황이 발생할 수 있다는 것을 깨달았습니다.
Flutter에서도 의미 있었던 Android 지식
박유진: Flutter는 물론이고 Dart라는 언어도 처음이었기 때문에 백지부터 시작하는 과정이 될 것이라고 예상했지만 생각보다 네이티브 개발 지식과 이어지는 내용이 많았습니다. Flutter 공식 문서에는 Flutter for Android Developers라는 페이지가 있기도 한데요. Android와 유사한 점을 비교해 가며 공부할 수 있었고, 차이점도 새롭게 알 수 있었습니다. 특히 생명 주기나 화면 전환같이 안정적인 앱을 위한 필수 개념에 관해 공부할 때는 기존 Android 지식을 기반으로 이해할 수 있어서 조금 수월했습니다.
최연두: 걱정했던 것과는 달리 Android 경험이 Flutter와 Dart를 익히는 데 있어서 큰 도움이 됐습니다. 덕분에 밑바닥부터 시작하는 게 아니라 이전 공부를 바탕으로 학습할 수 있었는데요. 가장 도움이 많이 된 지식은 Compose입니다. Compose는 선언형 UI이고 변경 점만 리빌드된다는 게 특징인데요. UI 그리는 작업에 유사한 부분이 많아서 적응하는 데 용이했습니다.
마치며
취업 준비를 하면서 LINE Engineering 블로그를 많이 읽었는데 신입사원으로서 포스팅을 한다니 감회가 새롭습니다.
입사 후 Android 개발을 하게 될 줄 알았지만 Flutter를 시작하게 돼 놀랐던 건 사실입니다. 하지만 그 과정에서 Flutter를 익히는 것뿐만 아니라 낯선 기술을 익히는 방법 자체를 배울 수 있었습니다. 변화하는 기술 트렌드 속에서 이상적인 개발자의 모습은 나에게 익숙한 것만 고집하지 않고 필요한 기술이라고 판단하면 빠르게 적용하는 것이라 생각합니다. 앞으로 또 새로운 프레임워크나 언어를 사용해야 할 일이 있을 텐데요. 상황에 유연하게 적응할 줄 아는 개발자가 되는 첫걸음을 뗀 것 같아서 기쁩니다.
이 포스팅을 작성하며 돌아보니 입사 후 지금까지 저희가 성공적으로 온보딩할 수 있도록 팀에서 많이 도와주셨다는 것을 느낄 수 있었습니다. 큰 어려움 없이 적응할 수 있었던 가장 큰 이유는, 팀에서 매주 진행하는 Flutter Scrum 시간처럼 궁금한 게 있을 때 쉽게 이야기를 나눌 수 있는 편안한 팀 분위기를 조성해 자연스럽게 Flutter에 스며들 수 있는 환경을 만들어주셨기 때문이라고 생각합니다. 잘 따라올 수 있도록 가이드해 주시고 여러 방면으로 살뜰히 돌봐주시는 ABC Studio 팀에 언제나 감사드립니다.
ABC Studio에서 Flutter를 사용하는 이야기가 더 궁금하시다면 아래 블로그를 참고해 주시길 바라며 이만 마치겠습니다. 긴 글 읽어주셔서 감사합니다.