클라우드의 생태계가 활발해지면서 Web 생태계에서는 Frontend와 Backend의 코드가 하나의 저장소에 있는 경우가 많습니다.
저장소 모델(Repository Model)에 대한 이야기는 “당신이 알아야할 저장소 모델(Repository Model)”을 통해 확인해 주세요.
동형(Isomorphic, Frontend와 Backend의 언어가 같음 ex. JS/TS) 웹개발이 흔해지면서 서로 같은 영향을 줄 수 있는 공통관심사항 or 횡단 관심사항(Cross-cutting concern)과 관점 지향 프로그래밍(AOP, Aspect Oriented Programming)을 공유해서 쓰는 경우가 많이 발생됩니다.
Frontend와 Backend를 분할하려는 것은 잘못된 접근 방식일 수 있습니다. 한쪽의 변경은 필연적으로 다른쪽에 영향을 미치므로 두 저장소를 지속적으로 수정하게 됩니다.
그렇기 때문에 Monorepo로 제품을 관리하는 경우
하나의 수정이 양쪽에 영향이 발생되고 이를 쉽게 commit에 함께 반영할 수 있습니다.
그리고 관련된 프로젝트가 같이 있을 경우 모든 프로젝트를 쉽게 검색 및 수정할 수 있습니다. 이는 유사한 기능을 추상화하고 공유 패키지(라이브러리)화하여 중복 작업을 줄입니다.
모든 사람이 모든 것을 볼 수 있게 되고 사람들이 더 많이 저장소에 참여하면서 무슨 일이 일어나고 있는지에 대해 더 잘 알고 느끼게 할 수 있습니다.
예를들어 앱 개발자는 서버 구성 요소를 만질 수는 없지만 자신의 작업과 함께 한다는 “느낌”을 가질 수 있습니다. 그러면서 협업과 함께 제품에 대한 “소유권”을 느끼도록 할 수 있습니다.
그리고 회사에서 표준화하려는 환경을 관리하기 쉽고 배포 또한 관리하기 쉽습니다.
- package.json과 같은 종속성 관리
- 공유된 패키지의 재사용(e.g. /design-system or /common-utils or /schema)
- configs (ESlint, TSconfig, etc)
- tests (from unit to e2e)
그래서 React, Jest, pnpm, Next.js 및 Yarn과 같은 주요 JS ecosystem tools는 Facebook 및 Google과 마찬가지로 Monorepos로 이동했습니다.
JS 커뮤니티의 많은 사람들은 Monorepos의 이점에 대해 들었지만 이 문제를 다루는 좋은 도구의 부족으로 인해 주저했지만 다양한 문제를 해결할 수 있는 도구가 많이 생겼습니다.
Monorepo Tools에 대한 이야기는 “Monorepo Tools”에서 확인해 주세요.
관련 전체 내용은 아래 영상에서도 소개되어 있습니다.