서로 성격은 다르지만 관련 있는 여러 프로젝트를 어떻게 통합(or 하지 않는걸) 선호하시나요?
예를 들어, 동일 서비스에 대해 front-end, back-end(api), serverless, batch, pipeline, ... 등등 있다면
-
Mono-repo
서비스가 같다면 레포지토리는 하나다! 각 프로젝트는 패키지/폴더 구조로
-> 커밋 관리는 어떻게..? CI/CD나 pre-commit 같은 hook 복잡해질텐데.. -
Git Submodules
성격이 다르면 최소한 git 히스토리는 따로 관리해야지! 그래도 최대한 하나로 묶어서..
-> sub module sync 등 러닝 커브.. 머지도 복잡해지고.. 다른 개발자들이 따라올까? -
각자 도생 repo
심플하게! 다른 프로젝트면 레포도 다르게!
-> A 서비스 보려면 무슨 레포 봐야해요? 어 이거랑, 저거랑,.. 또 뭐 있더라...
정답은 없는것 같지만 어떤 걸/왜 선호하시는지 궁금합니다!
https://monorepo.tools/
위 사이트 안 보셨으면 한번 보시면 좋을 것 같구요.
서브 모듈은 개인 경험상 비추합니다.
서브 모듈로 다른 저장소의 코드를 공유하고 싶으면 차라리 패키지로 배포하는 게 나을 것 같네요.
모듈이 별로 크지 않다면 모노레포
모듈이 크다면 서브모듈
아니면 오픈소스 배포할 때 서브모듈만 기여하게 하고 메인레포는 자체적으로 관리하게 설정하고 싶다면
서브모듈로 분리하는 것 같습니다.
근데 서브모듈 끼면 오픈소스할 때 다른 사용자가 기여를 위해 테스트나 빌드관련해서 문서 작성하기가 조금은 복잡해지는 것 같긴합니다.
그래서 개인적으로는 둘의 기여가 다른 경우가 아니라면 모노레포로 하거나
다른 깃헙으로 하는데 각각을 패키지로 배포하거나, 도커이미지로 하는 방식으로 관리하기는 것 같습니다
예전에는 그냥 각자 독립적인 repo들을 사용했지만 최근에는 서브모듈을 사용하는 방법으로 완전히 틀었습니다.
예전에는 git에 대한 이해도가 낮아서 서브모듈을 제대로 활용하지 못했지만, 현재는 서브모듈을 사용하는 게 더 나을 것이라고 생각해서입니다.
다만 서브모듈을 사용하면 해당 서브모듈에 대한 커밋을 하고 부모 repo에도 커밋을 다시 해야 하는데 그 결과 두 시기가 벌어지게 되어 repo의 일관성이 떨어지는 문제가 발생한다는 문제가 뒤따르는 것 같습니다.
- API 서버를 직접 구현하는 경우에는 API 규약을 맞추기 위해서 프론트엔드-백엔드 모노레포를 사용했습니다
- Supabase와 같이 DB에 의존성이 강한 2티어 아키텍처 프로젝트의 경우에는 스키마 자동 생성 도구에 의존해서 프론트엔드와 백엔드를 별도의 레포로 분리했습니다
- 디자인 시스템의 경우에는 아직 완전히 해결하진 못했는데 일단 서브모듈은 학습 곡선이 가팔라서 철회했고 프로젝트 템플릿이 나은 방향이라고 생각중입니다
저희 회사의 경우에는 프로젝트 당 팀원이 적고 프론트엔드와 백엔드의 언어와 기술스택이 분리되어있어서 직무간 교차 기여는 거의 없었습니다. 모든 IT 시스템과 마찬가지로 결국 조직 구성을 따라가는 것 같네요
제가 Mono-repo 경험이 없어서 궁금한게 하나 있는데요. Mono Repo로 할 때, 여러 프로젝트나 서비스에 공통적인 모듈(ex. 디자인 시스템)은 각각 Mono Repo에 들어가는 식이 되나요? 아니면 얘는 어쩔 수 없이 별도의 Repo로 빠져서 참조하는 식으로 하나요?
저는 회사에서나 개인 프로젝트에서느 프론트 백엔드 배치 등 구분하지 않고 하나의 git으로 관리하고 있습니다.
하위호환을 지키기보다 둘을 같이 수정하면 편한 경우도 있고요. 둘 다 팀 규모가 작아서 괜히 나눠서 좋을 게 없다고 할지... 깃허브 액션은 변경된 부분만 돌게 설정해두는 수고 정도는 감수할 만 했습니다. 무엇보다도 백엔드 프론트 구분보다는 서로가 서로에게 기여할 수 있는 게 좋다고 할까요. (프롬트 작업하다가 백엔드에 필요한 게 있으면 직접 추가하거나, 에러도 직접 고치는 등...)
음 확실히 규모가 작거나 역할군이 엄격하지 않으면 모노레포를 선호하시는거 같군요! 깃 히스토리가 섞이는? 것도 크게 게의치 않으시나요? (어차피 다 보는 코드니까?)
재미있는 점은 제 사이드 프로젝트에서도 그러는데요. 지금 12명 정도랑 같이 작업을 했는데. 한 명 한 명마다 프론트에서 백엔드까지 한 호흡으로 작업을 합니다. 버티컬 슬라이스랑 유사한 것도 같네요.
그걸 섞인다고 보지 않는 편이에요. 하나의 PR에서 프론트랑 백엔드랑 둘 다 수정하는 경우도 많아서요. 저희는 모두가 풀스택 4명이라는 기조라서, 백엔드/프론트 가리지 않고 서로 리뷰도 하고 변경사항도 알아야 합니다.