모노레포 공부일지_1

0. 실강에서 실시간 이슈

: 완전 루트폴더(~)에 yarn을 잘못 설치하면 모든게 꼬임...!! 조심 또 조심

---

1. monorepo란?

• 단순의미 => monolithic + repository = 단단히 하나로 된 git 저장소

---

2. monorepo 실습

• yarn init

• packages 레포의 package.json파일 수정

  {
  ...
  	"private" : true,
    "workspaces" : "packages/*"
  }

• packages/common 폴더 구조
  index.js, package.json

• packages/server 폴더 구조
  index.js, package.json

• yarn1과 yarn2는 비슷한데, yarn2에서 더 좋아진게 있음.
  비슷한 점 : 타고들어가는 기능, 의존이 됨.
  yarn1 불편한 점 : 버전을 다 써줘야 함.

• yarn set version berry 1.22 -> 3.3 바뀜

• yarn init -w 알아서 패키지 세팅(아까 pricate과 worksapce를 직접 쳐줘야했는데, 이젠 기본으로 세팅됨)
  

• 폴더를 타고들어가서 실행하지 말고, root에서 yarn workspace 명령어를 수행하는 것을 추천!

• yarn workspace 목적이 의존성을 루트에서 통합하는게 목적도 있는데, 안에서 하면 안에 nodemodule폴더가 생긴다던가 할 수 있어서, 명령어를 칠때는 루트에서 치는 것을 추천

• 설정이 바뀌면 root에서 꼭 yarn 쳐줘야 적용

• yarn workspace @wanted/web run dev을 치면 실행됨.

• 공통 함수에 input이나 output 형태가 바뀌면 (breaking change?) 코딩 타임에 바로 error를 볼 수 있음. 이런것들이 모노레포의 핵심.
  흔히 쓰는 라이브러리로 한 경우, 파괴적인 변경을 실시간으로 알 수 없음.

  • 핵심 : 패키지.json이 다 따로 있지만 하나의 프로젝트인 것 처럼 쓸 수 있다!

• 타입스크립트 사용을 위한 공식 문서 : https://yarnpkg.com/getting-started/editor-sdks
  -> yarn berry는 npm과 모듈을 불러오는 방식이 달라 문제가 발생
  ->순서
  yarn dlx @yarnpkg/sdks vscode
  yarn add -D typescript
  yarn dlx @yarnpkg/sdks typescript
  깃에는 순서를 바꿔서 올려두심 곧 고쳐주신다 함.
  

• arcanis.vscode-zipfs : zip으로 깔리기 때문에 이게 꼭 있어야 함.
  -> recommendations 설정 해두면, 다른사람들이 사용할 때 이거 설치할건지 문구가 뜨게 됨.

"paths" : {
	"@wanted/lib": ["../../packages/lib/src/index"]
} //이걸 추가해 줘야 클릭한 경우 해당 함수로 이동할 것!

---

3. Q&A

- Q: package name에 @를 같이 넣어주는 이유

• A: 관습. lib이라고 한다면, 라이브러리나 외부에서도 많이 쓰이기 때문에, 명시적으로 내부 패키지에 있는 디펜던시다라는 것을 보여주기 위해 보통 @회사명/lib 이런식으로 많이 씀!

- Q: 모노레포를 구축할 때 yarn workspace + lerna 조합을 많이 쓰던데, yarn workspace만으로도 모노레포 구축이 충분한지

• A : 충분히 가능. lerna는 더 고수준의 툴 느낌. lib 폴더를 수정했다 하면, 내부 패키지지만 npm에 퍼블리시 할 수 있는데, 그럼 버전 정보가 되게 중요한데 수정된걸로 작은 변경이 일어나면 "1.0.1" 큰 변동은 "2.0.0"식으로 변경하는데, 그때 이 버전을 자동으로 해주는게 lerna!

- Q 멀티레포로 만들었던 프로젝트를 모노레포로 마이그레이션 한다고 할 때, 기존의 레포를 모노레포로 전환하는식으로 진행하나요? 아니면 새로운 모노레포 프로젝트에 기존 코드들을 가져오는 방식으로 진행되나요?

• A : 양쪽 다 지원 가능. 소스코드의 히스토리가 중요하다 하면은 git에서 이전해주는 명령어 있으니까 이건 그냥 선택의 문제. 기존 레포에서 변경했다 안되면 롤백도 되긴 하지만 불편하니까 새로 놓고 git 이전으로 history까지 옮기는 방법을 추천.

- Q 백엔드가 js 쪽 프레임워크를 선택한다했을 때 백엔드까지 모노레포로 같이 관리하는게 좋을지 백엔드는 따로 분리시키는게 좋을지

• A : 같은걸 사용한다면 같이 있는게 좋다고 봄! api 응답 모듈들도 모델 자체(dto)도 다 거기 들어가 있을 텐데, 이걸 다 share하면 편하니까! 백엔드와 프론트가 실시간 동기화가 되기 때문에, 넣을 수 있다면 넣는게 조흠!!

- Q cache된 패키지들 다 git ignore 안되고 있는데, 패키지들을 갖이 원격 저장소에 올리는 편이 좋은건 아니죠?

• A : cache 폴더를 같이 git 저장소에 올리게 되면은 바로 zero install이 됨. 의존성 설치할 때 지금은 yarn berry pnp를 쓰고 있어서 pnp로 나와있는데 pnp를 같이 올리는게 zero install. 의존성을 설치 안해도 바로 돌아가는 것? 올려도 되고 안올려도 되고. 올리게 되면 zero install. 맞아요 의도된 것. 싫으면 ignore에 넣으면 됨.

- Q yarn1을 쓸일이 없다고 하셨는데 왜 그런가요? 저희 회사에서는 pnp를 지원하지 않는 패키지가 여럿 있고, 큰 기능이 필요없고 컴포넌트나 기능만 공통으로 가져가기 위해 yarn1을 사용하려고 했었는데요, yarn berry로 시작하는 이유가 있으실까요. 단지 yarn berry가 yarn 1보다 더 지원하는 기능이 많아서인가요?

• A : yarn berry에서도 pnp를 쓰지 않는걸로 사용할 수 있음. pnp라는 모듈을 쓰고 있는건데, 지원하지 않는 패키지들이 있음. yarn berry에서 이걸 같이 호환해서 사용할 수 있게 제공중! 로드링커라는게 있음. yarn berry로 마이그레이션을 이렇게 하세요라는 페이지가 있는데 여기 참고해보기, 기존에 pnp가 아닌 node modules로 되어있을 것 아니에요? yarn yml에다가 nodeLinker: node-modules라고 넣고 yarn을 다시 해보면 될 것! 이건 나는 pnp모드로 사용하지 않겠다는 의미. yarn1을 써도 되기는 하는데, 이렇게 써도 됨~!

- Q 멀티레포로 디자인 시스템을 관리하여, 별도로 임포트 하여 사용했는데 모노레포로 할 경우 이때의 단점들이 개선된다는 말씀이시죠?

• A : props같은게 계속 변화하는 상황같이 많은 변경이 일어나는 상황에서는 모노레포로 전환해서 이런 변경상황이 바로 변환되도록 하는게 좋은 것 같음.

- Q package를 내부 서비스에서 import 할 때 꼭 index에서 export 해준 것만 import할 수 있을까요? 폴더구조가 깊어지면 일일이 export 해주기가 까다로울 것 같아서요

• A : entry index를 만드는게 좋음. 아니면 좀 지저분해짐. 꼭대기에 만들어서 쓰는 것을 추천.

- Q root 패키지에 workspace로 추가되어있는 packages의 하위 폴더를 만들때, 특별한 커맨드로 만들어줘야하나요?(페키지제이슨이 자동 생성 안돼서요)

• A : 네. 하위폴더에서 init 해주면 됩니다.

- Q yarn1에서 설치된 라이브러리 내부를 볼 때 node_modules안에서 보고 수정할 수 있는데 yarn berry에서는 어디서 확인하고 수정할 수 있을까요??

• A : 소스로 들어간건 보실 수 있겠지만, pnp모듈 쓸때는 불가능!

- Q 모노레포의 packages 를 github의 submodule 로 관리하는 것도 괜찮은지 궁금합니다

• A : 좋아요! 페키지로 내보낼 수 있는데, 우너하는 것만 서브모듈로 내보내서 다른 레포아이들도 같이 쓸 수 있도록 가능. 런타임이 아닌 에딧타임에서 에러를 바로 할 수 있기 때문에 들어와서 해도 좋고, 그게 싫으면 그냥 밖에 내보내도

- Q turbo, rush, pnpm, lerna 등 여러개의 모노레포툴 중 yarn berry 쓰시는 이유가 궁금합니다

• A : yarn berry를 써보고 어려운 부분을 느낀 다음, turbo 레포로 넘어가면 이야 진짜 최고다라는 것을 경험할 수 있어서 yarn berry부터 하는 중! turbo로 가긴 할것!!

- Q 모노레포가 MSA와 비교하면 어떤 장점이 있는지

• A : 둘은 다름. MSA를 잘 하기 위한 툴로 모노레포를 쓴다라고 생각해 주면 됨.

- Q packages lib에 있는 것들은 나중에 npm에 배포해서 사용하는 건가요? : 필요에 따라 상황에 맞게 사용. 페키지 구성에 따라 다름.

- Q 마이크로 프론트엔드 = 모노레포 일까요?

• A : 조사해본 결과 일반적인 방식. 하지만 꼭 그렇지는 않을수도!

- Q 레파지토리를 통합하시면 깃 전략은 어떻게 가져가시나요?

• A : tbd를 많이 사용. 2주차 첫시간에 배울 것ㅎㅎ 모노레포는 TBD(Trunk base development)를 회사들이 많이 씀~!

---

4. 이론 및 정리

a. 모노레포로 구성하는 case

• 크게 두가지. (세밀하게 보면 많지만, 크게 보면 두가지)

  case1. B2C, B2B, admin

  원티드는 원티드의 저장소가 있고 내부 직원만 들어갈 수 있는 admin이 있고, dashborad 저장소가 있음. 원티드는 3가지 저장소로 다 따로 되어있음.(package.json이 따로 있다는 것) 이걸 멀티레포 == 폴리레포라고 함.
  딱 봐도 wanted는 하나의 원티드인데, 3개에서 공유하는게 많을 것! 하지만 다 따로 구현되고 있음. 이걸 apps폴더와 packgaes 폴더로 만들고 하나의 모노레포로 가져갈 준비 중. eslint나 프리티어 등의 설정들은 다 맞출 예정. 배민도 우리와 비슷한 상황. 세개의 레포로 하다가 하나로 합침. 이런게 첫번째 케이스!

  case2. monolith -> 마이크로 서비스

  토스는 한 패키지 안에 30개 서비스를 두고 있었는데 이제는 다 분리함. 페키지스를 공통으로 네이밍 했지만, 토스는 libraries, apps를 services로 해둠. libraries에 컴포넌트, eslint 등을 넣음. 토스는 yarn berry로 함.

b. 모노레포가 아닐 경우(폴리레포) 문제점

• 오래걸리는 배포시간 (10 ~ 15분).
• 이벤트 페이지에 트래픽 증가시 채용 페이지에 영향을 줌.
  -> 원래 api 하나가 영향을 받으면 전체적으로 밀리는건 어쩔 수 없는거 아님?
  => 그렇긴 한데, 큰 덩어리 별로 잘 나눠서 캐싱 정책을 잘 잡고, 서로 영향이 없게 마이크로 서비스를 하려고 함.
• 패키지 설치시 다른 서비스에도 영향을 줌.
  -> 이벤트에만 쓰는 패키지인데 다른 곳에도 영향을 줌.
• 코드 공유가 어려움(ex. 공통 서브모듈을 github에 만든다는건 변경이 생겼을 때 버전관리를 계속 해 줘야하는데 그거 자체가 비용! 번거로움)
• 코드 중복이 많음
• 크리티컬 버그나 큰 변경시 비용이 많이 듬.(버전 업, test 등 비용이 계속 생김)
• 프로젝트별 일관되지 않은 도구 사용 (ex. eslint 설정 다르거나 그런 것, 다른 팀이 다른 것을 볼 때 다시 학습해야 함)

c. 모노레포로 바꾸면 생기는 장점

• 서비스별 배포 가능
• 빨라지는 배포시간 (이벤트 쪽이 바뀌면 이벤트 쪽만 올리기)
• 다른 서비스에 영향이 없음 (서로 영향을 안줌)
• 패키지별로 자유로운 의존성 선택
  어드민은 내부 서비스인데, 토스를 보니 내부 레포는 따로 있는 것 같음. 그래서 admin이 어떻게 될지 모름. admin만 따로 모아서 할지. 내부서비스만 따로 모아둔 레포가 필요할 것 같다는 생각이 들고있음.
• 새로운 프로젝트를 생성하는 오버헤드가 없음 (원티드는 전체 템플릿을 하나 만들려구 함->오버헤드가 적을 것)
• 모든 것을 버전 하나로 관리 (내부에서는 버전이 필요 없음! 버전이 그냥 하나로 통일)
• 개발자 모빌리티(프로젝트 간 이동이 좋음. 원티드팀이 데시보드 팀으로 옮겨도 알기 쉬움.)point. 크게 뭉쳐진걸 잘게 쪼개는데, 이걸 하나의 패키지로 가져간다.

• 즉, 모노레포란? 여러개의 개별 프로젝트를 잘 정의된 관계를 통해 하나의 레포에 담은 것!
  각 상황에 맞게 정의하면 됨. 답이 없음!
  모노레포의 모든 것

  기존의 폴리레포를 선택했던 것은 자율성 때문! 내가 하고싶은 대로 다 할 수 있음. 각자 원하는 라이브러리를 선택 가능했음.

d. 모노레포로 단점

• ui컴포넌트 쓰는 패키지가 react 17을 쓰는데, web에서 ui컴포넌트를 의존해서 쓰고있겠죠? 근데 react 18에서 나온 새로운 hook을 쓰고파. 그러면 다른 친구들도 모두 18을 써야함
  -> 근데 이런 경우도 괜찮다는 생각이 들음. 18로 올리자라는 의견이 나옴. 그럼 apps쪽에 담당자들 먼저 올려주세요~!하고 다 올렸음. 근데 데쉬보드팀이 바빠서 계속 17을 고수함. 이러면 압박을 받게 됨. 나만 바꾸면 다른 팀들도 빠르게 바꾸게 됨. 빠른 버전업을 할 수 있음ㅎㅎ 제품 지속가능하게 할 수 있도록 하는게, 꾸준한 업데이트를 해줘야 제품의 지속가능성을 가져간다는 생각이 드는데 리엑트 버전 업데이트를 못하게 되는 상황이 되어 버리는데 이런 경우는 엔지리어링에 효과가 있다? 멘토님은 빠른 버전업이 좋아서 단점으로는 크게 보이지 않는다.
• eslint 같은 것을 공통으로 쓰기 위해 설정해야 하는 것들이 많음.
  근데 잘 안나와 있어서, 설정의 피곤함이 있음..!! 꼼꼼히 찾아봐야해.. 그래서 직원이 많은 쪽은 강추 전 github CTO가 한 말이 있는데, 풀 마이크로 서비스로 전환한걸 후회하고 있음.
  -> 규칙은 아니고 내 생각은 이렇다 하셨는데 큰 문제가 없으면 monolith로 가라.
  -> 모노를 쪼개야 한다면 작은 서비스들이 아닌 큰 앱들로 분해하기
  원티드도 점점 커지다 보니 monolith에 문제가 있으니 마이크로로 변환하려는 것.
  만능이 아니니 이것도 읽고 판단해 보기!

잘 구조된 모노레포 open source를 읽는게 가장 좋은 학습 방법! 마지막에는 이걸 나누면서 고민해 보는 시간을 가질 것