Monorepo 도입배경

honney·2023년 12월 1일

Track1

목록 보기

1/1

모노레포 도입배경

프로젝트 개발상황

데스크탑뷰로 MVP모델 구현을 완료한 상태이다. 사용자 유입이 모바일 기기를 통해 많이 되다 보니 다음 스텝은 자연스럽게 모바일뷰 개발이 되었다.

모바일 뷰를 개발하기 위해 생각한 방법들

다음과 같은 방법이 떠올랐다.
1. 기존의 있는 코드에 미디어 쿼리를 하나씩 박아서 반응형을 만든다.
2. 규정하는 모바일 사이즈가 되었을 경우 새로운 모바일 컴포넌트를 랜딩하는 방식으로 한다.

2-a. 기존 레포지토리에서 모바일 폴더를 만들고 새로 컴포넌트를 만든다.
2-b. 새로운 레포지토리를 만들어서 m.track1.site라는 독립적인 서비스를 운영한다.(track1.site에서는 모바일 사이즈가 되었을 경우 m.track1.site로 리다이렉트 데탑사이즈가 되었을 경우는 track1.site로 리다이렉트)

생각보다 고민해야할것이 많았다. 왜냐하면 데스크탑뷰에서 디자인적인 부분을 많이 덜어내야겠다는 디자이너의 의견이 나왔고, 이번 모바일 디자인을 기준으로 태블릿, 데스크탑뷰까지 통일성 있게 디자인을 할 예정이라고 했다.

그렇다면 1번을 선택하는것은 리소스가 큰 낭비라서 탈락.

2-a번과 2-b번을 두고 고민을 해보았을때, 각각의 장점과 단점을 나누어서 생각해봤다.

2-a의 장점 : 기존에 있는 함수나 타입들을 다시 설정하는 리소스가 필요없이 바로 개발 가능
2-a의 단점 : 저장소가 더욱 무거워 질거라 예상,

2-b의 장점 : 저장소가 2-a에 비해서는 가벼움, 보다 깔끔하게 코드를 작성할 수 있음, 이후 데스크탑 뷰 리뉴얼 할 때도 2-a보다는 깔끔할거라 예상.
2-b의 단점 : 프로젝트 초기셋팅에 들어가는 비용이 크다.

모노레포를 선택하게 된 이유

아무래도 깔끔하게 코드를 작성하는 부분에서 팀원들의 동의와 나 또한 2-b에 더 마음이 갔다. 그렇게되면 새로운 히스토리에서 시작을 하는것이고, 해당 프로젝트와 동일한 초기셋팅들을 다시해야하는 리소스가 가장 마음에 들지 않았다.
커뮤니티를 통해 모노레포 기술을 접하게 되었고, 기존 환경에서 코드들을 재사용할 수 있다는 점에서 모노레포가 가장 적절하다고 생각하여 도입하게 되었다.