서비스 중인 Flutter 앱을 모노레포로 전환하기
스토어에 등록된 서비스는 다섯개. 회사의 아이덴티티가 확실한 만큼 다섯개의 서비스가 가지는 큰 흐름은 크게 다르지 않았다. 큰 기능을 필두로 약간의 Add-on 같은 느낌의 기능이 추가되어 서비스 명을 다르게 가져간 느낌이었다.
메인 기능이 비슷하다면 모노레포로 전환하는 것이 가능하다는 생각이 들었다. 그래서 모노레포로 전환하기 위해 고려해야할 것들을 생각해봤다.
1. 서비스가 여러개이다.
2. 여러 서비스에 중복된 모듈들이 import 되어 있다.
3. 여러 서비스에 비슷한 기능들이 적용되어있다.
4. 비슷한 기능의 앱을 계속 제작할 여지가 있다.
5. 일부 기능을 SDK로 전환할 가능성이 있다.
6. 서비스가 커 모듈별로 관리해야 한다.
나는 이 6가지 기준 중에 5가지에 해당되고 있었고 특히 4번은 이곳에서 빈번하게 일어나는 일이기 때문에 초기 프로젝트 세팅 과정을 줄일 필요가 있었다.
앱 개발 / 배포 프로세스가 정립되지 않은 상황이라 모노레포를 포함한 내용을 CPO님과 PO님께 공유드리고 피드백을 받는 자리를 만들었다. (CTO 자리가 아직 공석이라 PO분들과 미팅했다.) 이 과정에서 모노레포로 가야한다고 설득하기 위해서 이 부분을 강조했다.
동일한 기능을 사용하는 패키지들이 같은 코드로 작성된 패키지를 사용하여 퍼포먼스를 평준화 할 수 있다.
PoC나 데모용 서비스에 사용할 수 있는 템플릿을 mason으로 생성해 프로젝트 초기 개발 시간을 단축시킬 수 있다.
폴더마다 Pull해줘야 하는 Git submodule과는 다르게 한번 Pull 받으면 모든 패키지가 업데이트 된다.
패키지별 버전관리도 가능하며 후에 특정 패키지를 외부 배포해야한다면 해당 시점에 submodule로 전환하면 된다.
PO분들 답게 가장 긍정적으로 보신 포인트는 개발 시간 단축과 퍼포먼스 평준화였다. 지금은 여러개로 되어있는 서비스가 후에는 통합 SaaS로 전환한다면 앱도 여러개를 사용할 의미가 모호해지기때문에 이 경우를 대응하기에도 적합하다는 점을 이야기 했다.
Flutter는 melos를 활용해서 모노레포를 적용할 수 있다. 이미 Flutter 자체도 모노레포로 되어있기때문에 구조가 헷갈리면 Flutter Repository를 보고 구조를 대강의 구조를 이해했다. 물론 Firebase도 모노레포다.
melos에서 권장하는 구조는 이렇다.
my_project
apps
apps_1
apps_2
packages
package_1
package_2
pubspec.yaml
README.md
이제 packages로 분리할 수 있는 기능들을 추려보고 패키지로 분리하는 과정이 필요하다. 나는 이런 기준으로 분리했다.
1. 모든 앱에서 사용하는 유틸
- 로그, network, i18n
2. 서비스
- location, bluetooth, storage
3. 공통사용 패키지
- firebase
패키지는 위의 기준으로 분리하고 분석을 진행하면서 리팩토링을 먼저 진행하는 서비스부터 apps로 추가할 예정이다.
한번에 모든 서비스를 모노레포로 추가하는 것 보다, 순차적으로 추가하면서 패키지 안정성을 테스트 하믄 것을 목표로 진행하고 있다. 초반에는 모노레포 전환과 유지보수가 병행되어야하기때문에 업무가 복잡해지는 점을 감안해서 일정을 잡아야한다는 점은 필수.
말이 모노레포지 결국 한 프로젝트기 때문에 초기에 많은 고민을 하면서 적용하는 것을 추천한다.