이번에 원티드에서 모노레포 관련 프리온보딩 프론트엔드 챌린지 11월 에 참가하게 됐다. (스킬업 할 겸!)
주제는 '모노레포' 이다.
11번가 '여행개발팀'에서의 경험과 원티드 제공 사전과제 에 대해 기술하겠다.
https://www.wanted.co.kr/events/pre_challenge_fe_4
프리온보딩 프론트엔드 챌린지 11월 | 원티드
AI 채용, 연봉 정보, 이력서, 커리어 콘텐츠까지 커리어 성장에 필요한 모든 것, 원티드에서 만나보세요.
www.wanted.co.kr
1. 사전적(?) 의미
모노레포(Mono Repo)란, Monolithic Repository 를 뜻하며, 한글로는 '하나의 레포지토리' 라는 말이다.
한글 뜻만 보자면, 기존에 여러분이 깃허브에 'HelloReact' 라는 레포지토리를 만들어 리액트 앱을 올렸다면, 그것 또한 모노레포 이다.
하지만, 사전적 의미의 모노레포는 위와는 사뭇 다른 의미를 지니고 있으며, 아래와 같다.
모노레포 == '하나의 레포지토리에서 여러 개의 App 의 코드를 관리하는 방식'
(c.f. 위키 - 모노레포란 버전 관리 시스템에서 두 개 이상의 프로젝트 코드가 동일한 저장소에 저장되는 소프트웨어 개발 전략)
c.f.) MSA 를 구성할 때도 프론트엔드, 백엔드 모두 사용되고 있는 모습이다.
FE/BE 공통으로 모노레포 사용으로 가질 수 있는 장점은 아래의 3개가 있다.
- MSA 의 특징 - 코드를 여럿으로 나눴기에 코드 간에 의존성 꼬임이 적어진다.
- 관리 측면 - 나뉜 코드를 하나의 레포지토리에서 관리하기에 레포지토리 관리, 협업 면에서 편리하다.
- 의존성 - 공통 라이브러리를 관리/ 버전유지 하기 쉽다. (ex 서비스1, 2, 3 에서 모두 axios 를 사용한다면 하나의 package.json 에만 axios 를 두고 사용)
- c.f.) 공통 라이브러리가 아닌 경우, 서비스 마다 따로 의존성을 추가할 수 있도록 Lerna(for JS project) 라는 관리 시스템을 사용할 수도 있다.
2. 현업에서 다루고 있는 모노레포
현재 몸담고 있는 11번가 여행개발팀 의 FE 레포지토리 또한 모노레포지토리 이다.
대략 5개의 여행 서비스를 PC / MW App으로 제공하니 10개 정도의 VueJS FE App을 모노레포로 관리한다.
개발할 땐 해당 되는 App의 VueJS 서버를 띄워서 개발하고, 배포할 땐 빌드 도구를 이용해 전체 App을 빌드하고 배포한다.
유저가 Url을 타고 들어오면 배포 된 번들 파일들을 Spring WAS 에서 제공한다.
3. 원티드 프리온보딩 챌린지 사전과제
원티드에서 모노레포 관련 사전과제를 제공했다.
총 3개의 아티클을 읽는 과제이다.
본 포스팅엔 각 아티클의 중심 내용만 간추리겠다.
- [콴다] 팀워크 향상을 위한 모노레포 시스템 구축
- 모노레포 도입 과정/배경
- 프로젝트 마다 서비스 & Lint 관리 편의성 / 프로젝트 마다 다른 컨벤션 해결 / 모듈(의존성) 버전 관리 를 위해 도입했다.
- yarn 워크스페이스 도입
- mono repo CI/CD 를 위한 Trunk Based Development 전략 도입
- 위 사항 이외에도, 코드리뷰 에서도 장점을 가져갔다.
- [Naver D2]모던 프론트엔드 프로젝트 구성 기법(모노레포 개념 편)
- 모노레포 등장 배경 | 해결하는 문제 | 고려할 측면 | 관련 도구
- 모듈을 적절히 분리하여 관심 분리를 이루면서, 동시에 분리된 모듈을 쉽게 참조하고 테스트, 빌드, 배포 과정도 쉽게 한 번에
- 모노레포 내의 프로젝트들은 한 Repo에 묶일 타당한 관계를 가지고 있다(의존성, 도메인 등등)
- 모노레포, 멀티레포는 각자 장단점이 있으므로 잘 판단해서 사용하자
- [Normal Coder - 콴다(?)] 모노레포의 문화적 의의 https://yeoulcoding.me/298
- 개발자가 UI/UX , 비즈니스 로직에만 집중할 수 있도록 하자! - 신규 프로젝트 생성에 드는 에너지를 줄이자!
- 좋은 피드백을 주자! - 하나의 Repo 이므로 다른 팀이어도 PR 을 보고 리뷰할 수 있다. (개발조직 전체적으로 의견 교환 가능 - AKA 기웃거림)
- 기웃거림을 통해 보다 많은 프로젝트의 코드를 최신 상태로 유지할 수 있다.
- 내가 상상한 예시) A팀의 개발자 a 가 B팀의 코드를 보다가. "이거 2년 전 ES 버전 업데이트가 아직 적용 안 됐네? B팀 여러분!! 이거 봐바요!!)
사전과제 후기
- 두 회사 (Naver, 콴다) 의 아티클을 제공 받아 읽었다.
- 핵심 내용 및 모노레포 사용 배경 | 과정 | 후기 등은 내용이 비슷하다.
- 아티클의 말하는 방식이 확실히 다르다. 대기업과 스타트업의 연식의 차이인 것일까?
- Naver 는 정형화 돼서 '당신은 뭘 읽어야 합니다' 와 같은 가독성을 높이는 정형화 된 글의 형식, 흐름이 있는 반면
- 콴다는 아티클의 흐름은 Naver와 비슷한 것 같으나 독자에게 '직접 대화하는' 방식을 선택해 친근감이 있다.
- 어느 한 곳의 아티클이 읽기 힘들다는 것이 아닌, 읽기 좋게 하기 위해 택한 방법이 다르다 는 것을 느꼈다.(포스팅 할 때 '이렇게 하자' 라는 공부가 됐다.)
마치며
처음 겪게 되는 프론트엔드 챌린지 이다.
모노레포 뿐만 아니라, 프로젝트 전반에 걸쳐 '좋은 프론트엔드 개발자 되기' 를 위한 다양한 인사이트를 뽑아내는 것이 목표이다.
'소프트웨어 엔지니어링 > 프론트 엔드' 카테고리의 다른 글
| Trunk Based Development(이하 TBD) (0) | 2022.12.12 |
|---|---|
| [원티드11월챌린지] FE 프리온보딩(모노레포) - 1주차 (0) | 2022.12.10 |
| VueJS vs ReactJS 가독성 (0) | 2022.11.28 |
| ReactJS, VueJS 의 Life cycle methods(hooks) 그리고 Hooks (0) | 2022.11.28 |
| ReactJS, NextJS 공부 링크들 (0) | 2022.11.27 |