Flutter 앱에서 비즈니스 로직을 더 잘 관리하는 방법 — monorepo 사용하기

Andrew Lee

Published in

andrewlee1228

6 min readDec 9, 2021

안녕하세요 👋

플러터 개발자 Andrew Lee 입니다.
소프트웨어 개발자이며 새로운 것을 배우는 것을 좋아합니다. 오늘 하루는 자신을 향상시키고 무언가를 할 수있는 기회입니다!

오늘은 플러터 앱을 개발함에 있어서 앱 비즈니스 로직을 더 잘 관리 할 수있는 방법이 충분히 이야기되지 않는다고 느끼고 있어서 공유하고자 합니다.

단순합니다. monorepo를 사용합니다 …하지만 그게 뭔가요? 🧐

monorepo는 단일 저장소에 여러 프로젝트를 저장하는 소프트웨어 개발 전략입니다.

구체적인 예시를 들어볼까요?

단일 저장소에 프런트 엔드, 백엔드 앱, 구성 및 기타 관련 하위 프로젝트가있는 경우

new_fullstack_project
    -> front-end
    -> backend-end
    -> configuration

2. 단일 저장소에 여러개의 앱 프로젝트가 있는경우

coupang_eats_monorepo
    -> app
      -> 고객용 앱A
      -> 드라이버용 앱B
      -> 관리자용 웹C
    -> eats_common_features
    -> eats_design_system
    -> eats_network
    -> eats_utils

Flutter의 우수한 모듈성

하나의 저장소에 여러 개의 Flutter 앱을 만들 수 있지만 제가 말하고자 하는 것은 약간 다릅니다. 플러터는 모듈의 도움을 받아 플랫폼간에 로직을 분리할 수 있습니다.
(오해하지 마세요! monorepo는 그 방법중에 하나 일 뿐이에요!)

설명을 위해 Coupang Eats와 같은 앱을 담당하고 있다고 하겠습니다. 그래서 우리는 3 개의 앱을 유지해야합니다.

고객 용 앱 — 앱 A
드라이버 용 앱 — 앱 B
라이딩 위치 만 보여주는 웹 버전 — 앱 C

따라서 앱 A 와 B 는 로그인, 인앱 커뮤니케이션(주문전달,수락과 같은 기능) 그리고 일부 지도 메커니즘과 같은 몇 가지 유사점을 가지고 있지만 앱 C 에는 지도, 위치, ETA(예상도착시간) 만 표시하는 매우 단순화 된지도가 있습니다.

이 경우에는 각각 다른 저장소에 3 개의 (Flutter) 앱을 만들고 하나의 단일 저장소에 공통적으로 사용될 12 개 이상의 패키지와 플러그인을 만듭니다. 공유 로그인, 인앱 커뮤니케이션, ETA 계산 등이 모두 그곳에있을 수 있습니다.

왜 이러한 앱 설계가 필요할까요?
주로 코드 중복을 방지하기 위한 것이지만 개발 팀이 특정 앱 목표에 대해서만 작업하도록하는 것입니다. 개발자가 A, B,C 에서 같은 기능에 대해서 각각 수정해야 한다면. 그것은 회사에 많은 돈과 시간이들 것입니다!

처음부터 바로 할 필요는 없다는 것을 기억하세요.

첫 번째 앱을 작성할 때 코드를 재사용 가능하고 확장 가능하게 만들기 위해 몇 가지 좋은 프로그래밍 관행을 따릅니다. 그렇다면 큰 문제없이 코드를 별도의 코드베이스로 쉽게 이동할 수 있습니다.

이제 monorepo 플러그인/패키지 아이디어에 설득이 되셨나요 ?
그렇다면 Flutter 프로젝트에서 어떻게 사용하는지 살펴보겠습니다.

예 — “Coupang Eats”

모노레포를 만드는 것은 아주 간단합니다. 원하는 모든 패키지와 플러그인을 배치할 단일 디렉토리를 만든 다음 해당 디렉토리를 저장소의 루트로 설정하기만 하면 됩니다. 그리고 git push 를 해주시면 준비가 되었습니다.

Flutter 프로젝트에서 어떻게 사용하나요?

로컬 및 원격(git을 통해)의 두 가지 방법으로 모노레포를 사용할 수 있습니다.

내부에서 개발하는 동안 다음과 같은 패키지와 함께 로컬로 복제된 저장소를 자주 사용합니다.

dependencies:
  eats_common_features:
    path: ../coupang_eats_monorepo/eats_common_features

coupang_eats_monorepo repo 로부터 eats_common_features패키지 를 사용하고 있습니다.

그런 다음 앱을 출시할 준비가 되면 다음과 같이 git을 사용하도록 변경합니다.

dependencies:
  eats_common_features:
    git:
      url: git://github.com/andrewlee1228/coupang_eats_monorepo.git
      path: eats_common_features

해당 리포지토리에서 많은 플러그인을 사용할 수 있습니다. 구조는 다음과 같습니다.

dependencies:eats_common_features:
    git:
      url: git://github.com/andrewlee1228/coupang_eats_monorepo.git
      path: eats_common_featureseats_design_system:
    git:
      url: git://github.com/andrewlee1228/coupang_eats_monorepo.git
      path: eats_design_systemeats_network:
    git:
      url: git://github.com/andrewlee1228/coupang_eats_monorepo.git
      path: eats_network

공유 코드 monorepo의 이점

많은 사람들이 monorepo를 좋아하기도 하고 싫어하기도 합니다.
다음은 당신의 private dependencies을 위해 모노레포를 사용하는 것의 이점입니다.

- One CI
(하나의 CI: 단일 저장소에서 관리되므로 여러 프로젝트에 걸쳐 활성화된 코드 리포지토리 또는 여러 개발자가 작성하거나 수정한 소스를 지속적으로 통합하고 테스트하는 것에 좋습니다.)

- Modularity (모듈성: 공통된 코드가 모듈화되어서 관리됩니다.)

- Reusability
(재사용성: 여러 프로젝트에서 사용하는 경우 공유 코드는 여러 프로젝트 리포지토리가 아닌 모노 리포지토리에 저장됩니다. 이렇게 하면 모든 앱이 동일한 기능 집합을 사용하고 사용 위치에 따라 다르게 작동하지 않도록 할 수 있습니다.
어느날 회사의 비즈니스가 확장되어 넷플릭스와 같은 서비스로 “Coupang Play”를 출시하겠다고 결정이 났다면 모토레포 구조에서 쉽게 디자인시스템과, 로그인 화면 유저의 세션관리 등을 쉽게 재활용 할 수 있을 것 입니다.)

항상 모노레포를 사용해야 하나요? 모노 레포는 무엇에 사용해야 하나요?

혼자 프로젝트를 시작할 때 모든 것을 하나의 리포지토리에 보관하는 것이 더 쉽습니다. 처음에는 디렉토리 구조를 나누어 관리하여 시작해보시고 점진적으로 더 많은 것이 나오고 규모가 커지면 앱의 비즈니스 로직을 각 부분을 별도의 저장소로 분리해 보세요.

저는 플러그인/패키지를 monorepo 에서 관리하고 사용하고 있습니다. 대부분의 앱이 공통 논리를 사용합니다.

누군가가 monorepo를 사용하는 것을 고려한다면 — 저는 제 목표를 달성했습니다!
협업할 개발자가 있다면 모노레포 도입에 대해서 같이 토론해보시기 바랍니다 : )

Next Steps

monorepo를 사용하여 multi package로 프로젝트를 관리하기로 하였다면
이를 좀 더 쉽게 도와주는 도구 melos가 있습니다.
이와 관련한 다음 스토리를 읽어보세요