모든 일에 의문을 제기하고 그 의문을 해결하기 위해 지식을 구하고 공부

react-native 0.72 버전 업데이트 사항(번역)

GROWNFRESH — Fri, 3 May 2024 09:53:02 +0900

Symlink 지원, 에러 개선 등

이번 릴리즈는 Metro와 에러 핸들링 개선 및 개발 경험 향상과 관련해서 많이 요청된 기능이 더해졌다. 이번 태스크의 대부분은 2022 커뮤니티 설문조사 응답을 반여했다. 설문에 참여해준 모든 분께 감사하다.

주요 변경사항

- 메트로의 새로운 기능

- 개발자 경험 향상

- 새로운 아키텍쳐 적용

유의 변경사항

- 더 이상 지원하지 않는 컴포넌트 제거

- 패키지 이름 변경

주요 변경사항

메트로의 새로운 기능

Symlink 지원 (베타 버전)

Symlink 지원은 계속해서 메트로에서 가장 많이 요청되는 기능 중 하나이다. (...)

Symlink 지원은 RN이 monorepo 설정과 pnpm과 밀접하게 동작할 수 있도록 해준다.

(...) 우리는 0.73 버전에서 symlink 기능이 기본으로 탑재될 수 있도록 계획하고 있다.

패키지 export 지원 (베타 버전)

패키지 export는 package.json "main" 필드를 대체하는 최신 문법이다. 그리고 npm 패키지가 공용 API를 정의하고 RN을 타겟팅할 수 있는 새로운 기능을 제공한다.

Metro 설정에서 패키지 Export 지원을 할 수 있도록 하면 당신의 앱은 새로운 "react-native" 커뮤니티 조건을 포함해 더 넓은 JS 생태계와 호환될 것이다.

베타기능 가능여부 설정

위 2가지 베타 기능 가능여부를 metro.config.js 에서 설정하면 된다. (홈페이지에 코드 있음)

새로운 metro.config.js 설정

RN 0.72 버전에서 RN CLI setup을 컨트롤하는 설정을 변경했다. 템플릿 버전을 맞추기 위해 metro.config.js 파일을 업데이트 해야 한다.

이것은 프로젝트의 기본 RN Metro 설정을 확장하는 것에 대한 컨트롤 키를 이동시킨다. 그리고 남은 기본값을 제거했다. 더하여 'metro get-dependencies' 같은 Metro CLI 독립 커맨드가 이제 동작할 것이다.

개발자 경험 향상

부적합한 style 속성에 red box가 보이지 않음

전에는 StyleSheet에 부적합한 style 속성을 제공하면 redbox에 결과가 나왔다. 이것은 높은 수준의 에러 경고를 나타냅니다. 이것은 높은 신호 오류인데요. 상대적으로 위험성이 낮은 에러에 대해 개발자 워크플로우를 방해합니다.

0.72에서 부적합한 css 속성을 제공하는 것 같은 실패에 대해 조용히 표시하도록 기대치를 낮췄습니다. 그리고 빌드타임이나 런타임에 잡히는 몇몇 에러 타입을 업데이트했습니다.

Hermes 에러 가독성 개선

Hermes는 undefined 콜러를 호출할 때 더 나은 에러 메세지를 추가했다.

// Before: undefined is not a function
// After: x is not a function (it is undefined)

추가로 로그박스는 현재 앱 유저와 관련 없는 Hermes 바이트코드 프레임을 필터링한다.

RN CLI 에러 아웃풋 향상

0.72는 RN CLI v11과 함께 출시됩니다. v11은 중복 감소, 워딩을 명확하게 변경한 것, 스택 추적 감소, 그리고 init, run-android, run-ios 커맨드에 관련 문서에 대한 딥링크를 추가한 것 등의 개선 사항이 포함됩니다.

RN CLI 체인지 로그 확인해 보자.

더 빨라진 컴파일 및 Hermes JSON 파싱 속도

Hermes는 큰 사이즈의 객체 리터럴에 대해 컴파일하는 속도를 향상했다. (...) Herme 사용 알고리즘에서 중복 제거 매커니즘을 향상시키면서 컴파일 속도가 97%까지 빨라졌다.

JSON 파싱도 여러 방면에서 최적화됐다. 이는 redux-persist 처럼 JSON에 깊게 의존하는 라이브러리 기능을 향상시킨다.

Hermes에서 더 많은 ES문법 지원

- {Array, TypedArray, String}.at

- 올바른 형식의 JSON.stringify 구현

- 여러 오류를 하나의 오류로 묶어 나타내는 AggregateError 구현 (Promise.any() 등 여러 오류가 발생하는 경우 유용)

새로운 아키텍쳐 업데이트

새로운 아키텍쳐는 현재 실험 단계다. 타겟 오디언스에게 집중된 업데이트를 계속하기 위해서, 0.72에서 새 아키텍쳐 업데이트와 향후 릴리즈들을 전담 그룹으로 이관하고 있다.

유의 변경사항

지원중단된 컴포넌트 제거

- @react-native-community/slider Slider

- @react-native-community/datetimepicker DatePickerIOS

- @react-native-community/progress-view ProgressViewIOS

패키지 rename

react-native core 레파지토리 내 모든 패키지가 react-native/package 내부로 이동되었다. 그리고 명확한 소유권을 확실하게 하기 위해서 @react-native라는 npm 스코프 아래에 출시된다.

그리고 몇몇 패키지 명칭이 변경된다. (ex. @react-native/polyfills -> @react-native/js-polyfills...)

rename한 패키지에 대해 직접적인 종속성이 없는 한, 이 변경점은 영향을 미치지 않을 것이다. 한편, 0.72로 업그레이드 하면, 리네임된 디펜던시를 0.72 버전으로 업데이트해라.

번역 페이지

https://reactnative.dev/blog/2023/06/21/0.72-metro-package-exports-symlinks

자바스크립트의 여러가지 엔진들

GROWNFRESH — Sat, 18 Nov 2023 20:35:02 +0900

Javascript의 여러 엔진들에 대해 알아보자.

Javascript 엔진이란?)

JS 코드를 실행하는 프로그램 또는 인터프리터*이다.

V8

- 개발사: Google

- 개발언어: C++

- 사용처: Node.js 런타임, Chrome 브라우저

- 속도 향상을 위해 인터프리터 대신 JIT 컴파일러*를 사용해 더 효율적으로 JS를 기계어로 번역한다.

- 바이트코드와 같은 중간 코드를 생산하지 않는다.

- 멀티 스레드(메인스레드, 컴파일 담당 스레드, 프로파일러 스레드 등으로 이루어짐.)

Javascript Core

- 개발사: Apple

- 사용처: Safari, RN App

SpiderMonkey

- 최초의 엔진 / C++ / FireFox에 사용

Chakra

- MS 개발 / IE, Edge에 사용

Rhino

- Java / Mozilla에 사용

*인터프리터: 프로그래밍 언어를 한 줄 단위로 번역, 실행을 반복하는 프로그램

* JIT 컴파일러

- 코드가 실행되는 과정에 실시간으로 일어나며 그래서 Just-In-Time이고, 동적 번역이라고도 불린다.

- 한줄씩 실행하는 인터프리터보다는 빠르고, 실행 전에 미리 컴파일하는 정적 컴파일보다는 성능이 떨어진다.

- 자주 사용되는 메서드 등은 캐싱해서 최적화시킨다.

- 대표적으로 JVM(자바 가상 머신)과 V8엔진에서 사용된다.

JVM에서 JIT를 도입한 배경을 설명해보자면..

자바는 JVM이 이해할 수 있는 바이트코드로 먼저 컴파일하고, JVM에서 인터프리터로 기계어로 번역해 OS에 전달한다.

Java --> javac --> 바이트코드로 변환 --> JVM --> 인터프리터로 기계어 변환 --> OS

자바는 바이트코드로 컴파일하는 과정과 인터프리트하는 과정을 거쳐야해서, 컴파일 과정만 거치는 다른 언어들보다 느리다.

이런 문제를 개선하기 위해 JIT 컴파일러를 일부 도입한 것.

참고 사이트

https://samslow.github.io/development/2020/07/06/JIT/

https://hyeinisfree.tistory.com/26

앱 성능 개선하기

GROWNFRESH — Fri, 27 Oct 2023 21:00:44 +0900

안드로이드 - 앱 성능을 측정할 수 있는 요소들

https://developer.android.com/studio/profile/measuring-performance?hl=ko

앱 성능 측정 개요 | Android 개발자 | Android Developers

앱 성능 측정 개요 컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요. 이 주제는 앱의 주요 성능 문제를 식별하고 해결하는 데 도움이 됩니다. 주요 성능 문제

developer.android.com

앱 크래쉬 에러를 심층적으로 분석해준다고 하는데..?

https://imqa.io/page/lite

IMQA LITE | IMQA - 모바일 성능 모니터링 솔루션

IMQA는 모바일 성능 모니터링 솔루션(MPM)과 모바일 이상 징후(Crash) 모니터링 솔루션을 제공하고 있습니다.

imqa.io

Metro로 만든 번들 결과물을 분석해준다고 한다!!!

https://github.com/IjzerenHein/react-native-bundle-visualizer

GitHub - IjzerenHein/react-native-bundle-visualizer: See what packages are increasing your react-native bundle size

See what packages are increasing your react-native bundle size - GitHub - IjzerenHein/react-native-bundle-visualizer: See what packages are increasing your react-native bundle size

github.com

앱 업데이트 안내 방법

GROWNFRESH — Thu, 26 Oct 2023 21:31:31 +0900

https://www.mobiinside.co.kr/2021/09/23/update-popup/

앱 업데이트를 하고싶게끔 만드는 문구

안드로이드에는 인앱 업데이트라고 해서, 구글 플레이스토어 코어 라이브러리인 기능이 있다.

업데이트할 내용이 있다면 업데이트 창을 띄워주고, 업데이트하기 했을 때 백그라운드에서 업데이트가 이뤄진다! 그동안 앱을 이용할 수 있다! 그러고는 앱을 재시작하라는 바텀시트가 뜬다! 넘나 유용! 하지만 아직 ios에는 비슷한 기능이 없다!!

https://developer.android.com/guide/playcore/in-app-updates?hl=ko

인앱 업데이트 | Android 개발자 | Android Developers

인앱 업데이트 컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요. 사용자는 기기에서 앱을 최신 상태로 유지하여 새로운 기능을 사용해 보고 성능 향상과 버그

developer.android.com

소스맵이란?

GROWNFRESH — Thu, 26 Oct 2023 17:32:23 +0900

소스맵이란 무엇일까?
소스맵에 대한 블로그 글을 개념 숙지 겸 간단히 정리해 보았다.

소스 맵이란?

- 코드의 원본 소스와 변환된 소스 사이의 맵핑 정보가 선언된 파일이다.

- *.map 확장자이며, JSON 형태로 되어 있다.

- 이 파일을 웹 서버에 제공하면 브라우저는 소스맵을 적용해 변환된 코드를 디버깅할 수 있다.

- 일반적으로 Vite, Webpack 등의 번들러에서 소스맵 생성 옵션을 제공한다.

- 파일 내용 중 'mappings'라는 키값이 원본소스와 변형된 소스 간 관계를 나타내고, 아래처럼 VLQ Base64 형태로 인코딩된 문자열이다.

AAAA,SAAS,cAAc,WAAW,iBAAiB,SAAS;IAC1D,...

소스맵이 필요한 이유는?

웹 브라우저에서 소스맵이 없으면 디버깅하기가 어렵다.

왜일까?

우리는 번들러로 파일을 압축시켜 브라우저에 전달한다.

코드 양을 줄여 브라우저가 파일을 다운로드하고 해석하는 데 시간을 줄이기 위해서이다.

여러 최적화 기법이 적용되어 한줄 형태로 짧게 압축되고, 변수명이 짧게 변경된다던지 변수 대신 값이 직접 삽입되는 등의 변화가 일어난다.

그런데 변수명 변경 등의 변화가 일어나고, 또 scss나 typescript 같은 파일들은 **브라우저가 읽을 수 있는 css나 js로 변형되기 때문에 변형된 소스코드에서 에러가 일어난 부분이 원본 소스 코드 중 정확히 어떤 부분인지 유추하기 어렵다.

따라서 브라우저에게 소스맵을 제공해 원본 소스 코드와 변환된 소스 코드의 관계를 정확하게 알게 하고, 디버깅 시 어떤 코드 라인에서 에러가 발생하는지 알려줄 수 있도록 한다.

**브라우저는 html, css, js 언어를 읽을 수 있다.

**js 는 html에 종속되어 있는 언어이고, html 정적 언어를 조작 및 변경하기 위해 사용한다.

html을 js가 조작하고 > js는 브라우저가 해석한다. 브라우저에는 js 해석 엔진이 있다.

소스맵을 사용하고 싶지 않을 때는?

간혹 잘못된 소스맵이 적용되어서 디버깅에 방해가 될 때도 있다.

이럴 때는 브라우저 환경 설정에서 ‘자바스크립트 소스 맵 사용 설정’, ‘CSS 소스 맵 사용 설정’ 을 해제하면 원본 코드를 직접 디버깅할 수 있다.

프로덕션 환경에서 소스맵

소스맵은 디버깅할 때는 매우 유용하지만, 소스맵 파일을 생성하고 관리하면 빌드 시간을 늘리고, 빌드 결과물의 크기를 늘린다.

또 노출되면 악의적인 사용자가 원본 코드를 쉽게 열람하게 되어 보안상 취약해 진다.

따라서 개발 환경에서만 사용하고, 프로덕션 환경에서는 소스맵을 생성하지 않도록 해야 한다.

대부분의 번들러는 이러한 기능을 이미 제공하고 있다.

** 참고 사이트

https://yozm.wishket.com/magazine/detail/2082/

소스 맵의 동작 원리는 무엇일까? | 요즘IT

실제로 디버깅을 해보면 브라우저에서 인식할 수 없는 파일이라고 해도 코드 라인의 위치를 정확히 짚어주는 것을 확인할 수 있습니다. 이것이 가능한 이유는 우리가 브라우저에게 원본 소스

yozm.wishket.com

monorepo 에서 pre-commit 훅 구성하기

GROWNFRESH — Tue, 10 Oct 2023 18:09:15 +0900

turborepo 를 사용해 monorepo 를 구성했고 git commit 이 이루어지기 전 Linting, Formatting, Type Checking 이 이루어질 수 있도록 husky, lint-staged 를 사용해 pre-commit 훅을 작성했다.

eslint 와 prettier 의 경우 각 패키지 설정에 맞게 검사가 이루어졌으나, 타입 체킹은 루트에 있는 tsconfig.json 을 의존해 검사가 원하는대로 되지 않았다. 이에 대한 해결책을 공유하고자 한다.

프로젝트 구성은 다음과 같았다.

├── packages
|   ├── random-menu
├── apps
│   ├── common-ui
│   └── common-utils
├── package.json

기존 설정

// ./package.json

{
  ...
  "lint-staged": {
    "*.{ts,tsx}": [
       "eslint --cache --max-warnings=0",
       "tsc --noEmit"
     ],
     "*.{ts,tsx,css,md}": "prettier --write"
   }
  ...
}

// ./husky/pre-commit

#!/bin/sh
. "$(dirname "$0")/_/husky.sh"

npx lint-staged

위와 같이 설정했을 때, 루트 tsconfig.json 을 토대로 tsc 를 실행해서 타입 검사가 제대로 이루어지지 않았다. 따라서 각 패키지 내에서 따로 타입검사를 해줘야 했다.

먼저 apps 또는 packages 내 패키지/앱들의 하위 package.json 에 아래 스크립트를 추가한다.

{
  "scripts": {
    "type-check": "tsc --noEmit" 
  }
}

이제 루트 package.json 의 lint-staged 을 아래처럼 구성한다. pnpm 패키지 매니저의 filter 옵션을 이용해서 특정 패키지/앱 내 파일이면 해당 앱/패키지에서 type-check 스크립트를 실행할 수 있도록 설정했다.

// ./package.json

{
  "lint-staged": {
    "*.{ts,tsx}": "eslint --cache --max-warnings=0",
    "*.{ts,tsx,css,md}": "prettier --write",
    "./apps/random-menu/**/*.{ts,tsx}": "pnpm run --filter random-menu type-check",
    "./packages/common-utils/**/*.{ts,tsx}": "pnpm run --filter common-utils type-check",
    "./packages/common-ui/**/*.{ts,tsx}": "pnpm run --filter common-ui type-check"
  }  
}

++ package.json 에 lint-staged 를 작성하는 대신, lint-staged.config.mjs 파일을 사용해 반복되는 타입체크 값을 함수로 만들 수 있다.

(lint-staged 설정파일 관련 문서: https://github.com/okonet/lint-staged#using-js-configuration-files)

// ./lint-staged.config.mjs
const MODULES = [
  { name: 'random-menu', parent: 'apps' },
  { name: 'common-utils', parent: 'packages' },
  { name: 'common-ui', parent: 'packages' },
]
const typeCheckConfigs = MODULES.reduce(
  (prev, { name, parent }) => ({
    ...prev,
    [`./${parent}/${name}/**/*.{ts,tsx}`]: () =>
      `pnpm run --filter ${name} type-check`,
  }),
  {},
)

export default {
  // linting
  '*.{ts,tsx}': 'eslint --cache --max-warnings=0',

  // formatting
  '*.{ts,tsx,css,md}': 'prettier --write',

  // type check
  ...typeCheckConfigs,
}

npm / yarn / pnpm / yarn-berry 비교! (참고 사이트 메모)

GROWNFRESH — Sun, 17 Sep 2023 18:06:10 +0900

https://velog.io/@seobbang/%ED%8C%A8%ED%82%A4%EC%A7%80-%EB%A7%A4%EB%8B%88%EC%A0%80-npm-yarn-pnpm-yarn-berry

pnpm 패키지 관리자

GROWNFRESH — Sun, 17 Sep 2023 18:03:28 +0900

pnpm 의존성 관리 기법은 크게 두가지 관점에서 볼 수 있다.

1. 글로벌 저장소(~/.pnpm-store) 에 모든 패키지를 저장하고, 필요할 때마다 hard link(symlink)를 연결해서 사용하는 구조

2. hoist 를 사용해서 flat하게 만들지 않고 npm@~2처럼 nested하게 저장하는 구조

pnpm 은 hoisting 방식이 아닌, content-addressable storage 전략을 사용한다.

패키지는 디스크상 한 곳에만 저장 된다. (홈디렉토리의 글로벌 저장소인 ~/.pnpm-store)패키지 파일들은 해당 위치에서 하드링크가 되고 모든 프로젝트가 이를 공유할 수 있는 구조로 만들어진다. 따라서 디스크 공간을 절약할 수 있다.

플랫하지 않은 node_modules

호이스팅 방식은 여러 패키지 간 종속 관계를 이해하고 풀어서 만들어야 하기에 속도가 느렸다.

따라서 호이스팅으로 플랫하게 만들지 않고, 옛 npm2 버전처럼 node_modules/A/node_nodules/B... 로 만든다. 그리고 패키지 별로 격리된 공간 내에서만 플랫하게 만들어 심링크로 연결한다.

참고 사이트

모노레포 - 터보레포

GROWNFRESH — Sun, 17 Sep 2023 11:29:06 +0900

Vercel 이 인수했고, JS 와 TS 코드 베이스의 모노레포를 위한 고성능 빌드 시스템이다.

터보레포의 주요 미션은 모노레포 환경에서 개발자가 좀더 쉽고 빠르게 개발할 수 있도록 빌드 도구를 제공하는 것이다.

고급 빌드 시스템을 구축하는 복잡한 과정을 대신 해준다. 터보레포의 기본 원칙은 한번 작업을 수행하며 수행한 계산은 이후 다시 수행하지 않는 것이다. 따라서 두번째 실행할 때는 이전 계산한 작업은 건너뛰고 캐싱해 놓은 로그를 다시 보여준다.

9가지 특징

1. Incremental builds

작업 진행을 캐싱해 이미 계산된 내용은 건너 뛰는 것을 의미합니다. 빌드는 딱 한 번만 하는 것을 목표로 합니다.

2. Content-aware hasing

타임스탬프가 아닌 콘텐츠를 인식하는 방식으로 해싱을 지원합니다. 이를 통해 모든 파일을 다시 빌드하는 것이 아니라 변경된 파일만 빌드합니다.

3. Cloud caching

클라우드 빌드 캐시를 팀원 및 CI/CD와 공유합니다. 이를 통해 로컬 환경을 넘어 클라우드 환경에서도 빠른 빌드를 제공합니다.

4. Parallel execution

모든 코어를 사용하는 병렬 실행을 목표로 합니다. 지정된 태스크 단위로 의존성을 판단해 최대한 병렬적으로 작업을 진행합니다.

turbo run lint build test deploy --> 패키지별 lint, build, test, deploy 가 병렬적으로 실행될 수 있음.

5. Task Pipelines

태스크 간의 연결을 정의해서 빌드를 언제 어떻게 실행할지 판단해 최적화합니다.

6. Zero Runtime Overhead

런타임 코드를 간섭하거나 소스맵을 건드리지 않는다. 이에 따라 런타임 단계에서 파악하지 못한 리스크가 불거질 위험이 없습니다.

소스맵이란?)

번들러로 파일을 빌드하면 모든 파일이 main.bundle.js 하나로 뭉쳐지게 되는데, 소스맵은 main.bundle.js 파일 내부의 각 부분이 원본 코드 파일 중 어느 파일의 몇번 라인에 위치한 부분과 일치하는지 알려주는 정보를 담고 있다.

소스맵은 dev, production 모드에 다라 선택할 수 잇는 옵션이 다르다. 보통 base64로 인코딩된 경우가 많으며, 디버깅에 압도적으로 유리하기 때문에 개발 단계에서는 이 옵션을 항상 활성화시켜두는 것을 강력히 권장한다.

7. Pruned subsets

빌드에 필요한 요소만으로 모노 레포의 하위 집합을 생성해 PaaS 배포 속도를 높입니다.

8. JSON configuration

별도의 코드 작업 없이 JSON 설정으로 터보를 사용할 수 있습니다.
// turbo.json { "baseBranch": "origin/main", "pipeline": { "build": { ... } } }

9. Profile in browser

빌드 프로필로 빌드 과정을 시각화하면 병목 지점을 쉽게 찾을 수 있습니다.

간단한 사용법

1. 루트에 turbo.json 파일을 생성한 후, 파이프라인을 작성한다.

병렬 처리, 의존성 범위 등을 설정한다.

2. Turborepo 를 설치한다.

$ yarn add turbo -DW # devDependency, install workspace root
$ turbo run build # yarn uvp build, yarn storybook build 등 의존성을 가진 모든 package 스크립트가 실행됩니다.

참고 사이트

https://engineering.linecorp.com/ko/blog/monorepo-with-turborepo

아래 블로그에 소스맵에 대해 상세하게 정리되어 있다. 추후 공부해보면 좋을 것 같다.

https://medium.com/%EC%98%A4%EB%8A%98%EC%9D%98-%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%B0%8D/source-map-%EC%97%90-%EB%8C%80%ED%95%9C-%EA%B3%A0%EC%B0%B0-part-1-5a3f6d5ab48a

모노리스 & 멀티레포 & 모노레포

GROWNFRESH — Sun, 17 Sep 2023 09:15:28 +0900

레파지토리를 구성하는 다양한 방식이 있습니다.

모노리스

소스코드를 모듈화하지 않고 하나의 레파지토리에 모두 넣은 것. 모든 코드가 단일 버전으로 서로 직접 의존하기 때문에 코드 재사용이 용이하고 빌드, 배포 과정도 단순하다.

하지만 관심 분리가 어렵고 기능 추가나 삭제가 레파지토리 전체에 영향을 줄 수 있는 단점이 있다.

멀티 레포(Multi Repo)는 ...

먼저 장점은 각 프로젝트가 다른 프로젝트에 의존성을 가지고 있지 않아 독립적으로 빠르게 개발이 가능하다는 것입니다. 그리고 해당 프로젝트에 필요한 도구로만 구성되어 있기 때문에 크기가 가벼워 프로젝트 관리가 수월한 편입니다.

하지만 관리할 프로젝트가 많아질수록 단점이 발생합니다. 프로젝트별로 사용하는 모듈과 버전 스택이 달라질 수 있고요. 오랫동안 건드리지 않은 프로젝트는 관리가 힘들어지고, 레거시 파악이 어려워집니다. 또한 새로운 레파지토리를 생성할 때마다 동일한 서비스 환경과 린트 환경을 반복적으로 셋팅해줘야 합니다.

모노레포의 장점은 아래와 같습니다.

- 코드의 재사용: 여러 프로젝트에서 사용되는 공통 로직을 쉽게 공유해서 사용할 수 있습니다.

- 의존성 관리: prettier, eslint 등 공통으로 사용되는 외부 라이브러리를 공유해서 사용할 수 있습니다.

- 속도: 배포와 빌드, 테스트와 같은 작업을 병렬도 한번에 처리할 수 있어 한번의 명령으로 여러 개의 레파지토리에서 작업을 진행할 수 있다.

- 협업: 모든 구성원이 모든 코드에 접근하기 쉽기 때문에 협업에 용이합니다.

참고 사이트