이 스레드를 보면서 예전의 complexity merchants에 대한 이야기가 떠오르는 경험 공유 요청. 모노레포로 이동하면 기술적 희생이 있다는 의견에 전혀 동의하지 않는 입장. 계층적 파일 시스템의 파워를 이해하면 모노레포의 가치를 알 수 있음. CI/CD가 여기저기 흩어진 구성보다 모노레포 하나로 구성하는 게 훨씬 더 명확. 모노레포의 핵심은 전체 조직이 원자적인 커밋을 할 수 있다는 점임. 많은 개발자를 조율할 때 그 효용이 압도적임. 한 번에 리베이스하고 한 번의 큰 미팅이면 충분. 팀원들이 서로 안 좋아해 협업하지 않아도 관리 측면에서 모노레포는 큰 HR 도구 역할.
최근 개발자들은 지나치게 분리, 마이크로서비스, 다수의 작은 레포지토리, 모놀리스를 극도로 피하는 경향이 있음. 이는 복잡성을 키워 조직 구조 문제를 미래의 기술적 문제로 전환하는 결과. 소프트웨어 시스템의 내부 종속성도 제대로 인식하지 못함. 이전 직장에서 프로토콜 버퍼 스키마 파일을 업데이트하는 데 낭비된 시간이 믿기지 않을 정도. 다행히 지금 회사는 그렇지 않음.
여러 프로젝트에서 커밋을 추적하는 것은 있으면 좋은 정도이며, 실제로 의존성 추적이나 다운스트림 테스트 트리거 면에서 큰 차이 없음. 멀티레포 자동화로도 충분히 가능. 모노레포가 도움은 되지만 완전하지도 않고, 비용도 큼. 배포나 빌드가 원자적으로 처리되지 않음. 모노레포 규모가 커지면 git에서 벗어나 새로운 툴이 필요하고 이건 아주 큰 작업. 경험이 없으면 쉽게 말할 수 있는 부분 아님.
모노레포의 장점은 분명 존재하지만, 관리 비용이 polyrepo보다 더 비쌈. 어떤 상황에서든 무조건 모노레포가 좋은 것은 아님. 자세한 설명은 이 글 참고. 비용 대비 효과는 상황에 따라 다름.
프로그래밍 환경 설계에서 팀에 더 많은 파워를 줄수록 문제도 늘어난다는 게 유익한 경험칙. 기술적으로는 원자적 커밋이 더 강력한 파워가 아니고 오히려 적은 파워지만, 나쁜 인터페이스로 일하는 걸 가능하게 하므로 오히려 문제를 유발하는 파워임.
모노레포로 바꾸면 변화가 더 원자적이라는 믿음은 함정이라는 의견. [원문 인용: 모노레포의 가장 큰 허상은 전체 코드베이스에 원자적 커밋이 가능하다는 것. 실제로는 다양한 배포 아티팩트가 있는데, 서비스와 클라이언트 등을 한 번에 바꿔도 배포는 비동기적으로 일어남. 여러 레포에서는 여러 PR로 작업해야 하므로 위험 인식이 깔림. 모노레포의 CI는 주로 서비스 계약(CI job) 검증 역할을 하며, 필요시 변경 이유 명시가 요구됨.]
빅테크 모노레포에는 두 가지 유형이 있음. 첫째는 글에서 말한 전사적 단일 "THE" 모노레포로, 커스텀 VCS/CI가 필요하고 200명 엔지니어가 지원함. Google, Meta, Uber가 이 방식. 이 경지에 오르기까지 고통은 상상 이상이며, 보통 더 작게 나눈 "팀 단위" 모노레포에서 점차 확장. 각 스택/언어/팀마다 Bazel, Turborepo, Poetry 같은 도구로 각자 관리하다 시간이 지나면 더 큰 모노레포로 합쳐짐. 그러나 이 둘 모두 개발자와 비즈니스 모두 수백만 달러, 수백만 시간의 투자가 들어가며, 결국은 이 과정을 견딘 개발자들의 지원으로 유지.
대형 모노레포 회사에서 일했을 때 모노레포를 훨씬 더 선호. 단일 모노레포가 서비스 그래프, 코드 호출 구조 등 전체를 투명하게 파악하는 데 아주 도움이 됨. 폴리레포의 경우 지식이 팀별로 분산, 신규 코드 인수도 어렵고, 코드 아카이브 파악은 마치 미궁 탐험. 폴리레포는 오래된 디스코드/슬랙 메시지처럼 잊혀지는 느낌. 모노레포가 비용이 많이 들면, 폴리레포도 마찬가지로 다른 방식의 비용 발생. 모노레포는 거대한 대륙의 초식동물, 폴리레포는 다양한 종이 어둠에 묻힘.
현재 회사에서 백엔드가 약 11개 git 레포로 나뉘어 있으며, 기능 한 건을 위해 4~5개 머지 리퀘스트가 필요해 매우 번거로움. 여러 프로젝트를 모으기 위해 모노레포 도입을 검토 중. 그런데 레포를 합칠 수 없다면 모노레포 대안은 무엇인지 궁금.
언어와 무관하게 쉽고 강력한 모노레포 오케스트레이션 시스템은 아직 없음. Bazel은 복잡하고 배우기 어렵지만 최근엔 문서화가 많이 개선됨. Buck, NX, Pants 등 다른 선택지도 있지만 각각 특징이 있고, 특히 웹 지원은 제한적임. 대부분의 CI가 이런 툴을 제대로 지원하지 않아 설정이 까다로움. 참고로 Microsoft의 Rush가 최고의 경험 제공, 특히 프론트엔드/노드JS 모노레포에는 Rush 추천 Rush 공식 사이트.
대부분의 모노레포가 Google, Uber, Meta같은 대기업 규모까지 커지지는 않는 현실 언급. 서비스 수도 회사마다 다르고, 많아도 100개 정도라면 VCS 스케일 문제 없고 LSP 태그도 무리 없이 랩톱에서 다 돌아감. 모든 테스트를 CI에서 무작정 돌려도 거의 무난. 결론: 모든 회사가 구글 규모를 필요로 하진 않음.
현재 회사는 언어 스택별로 모노레포를 구축하는 중. 꽤 괜찮은 절충안임.
모노레포 vs 멀티레포 논의에서 자주 나오지 않는 포인트는 '역 콘웨이의 법칙' 발생. 레포 구조가 조직 구조와 문제 해결 방식에 영향을 준다는 점. 모노레포는 공통 인프라 팀에 영웅적 작업을 유발, 공통 영역을 건드릴 때 잠재적 깨짐이 많아져 기능 하나 개발에도 난이도 상승. 멀티레포에서는 팀 간 여러 PR과 조율, 내부 정치 등이 필요하지만 더 다양한 개발자가 역할을 분산해 처리 가능.
모노레포에서도 중앙에 깊이 연결된 변경이라면 여러 단계로 나눠 적용할 수 있음. 그 과정에서 여러 PR 및 조정, 정치적 이슈도 다뤄야 하지만, 오히려 모노레포라서 롤아웃 상황을 더 명확하게 볼 수 있음.
폴리레포에서는 공통 영역에서의 변경이 다운스트림 레포들에 반영되지 않아 각 레포가 다른 버전에 고정되고, 수년간 업데이트가 안 되어 고생하는 사례가 훨씬 더 흔함.
조직이 애초 방향성을 레포 구조로 선택하고 나중에 기술 선택이 따라온다는 가정이 맞는지 질문. 실제론 구체적인 repo 구조보다 더 근본적인 조직 철학(파편화 vs 공유) 결정이 선행. 방향이 바뀌더라도 코드 관리 방식은 수정할 수 있음. 멀티레포라도 엔지니어가 거의 모든 코드 접근 가능하고, 모노레포도 강한 격리와 별도의 CI나 배포 관리 규칙 적용 가능.
모노레포에서는 프로젝트 간 손쉬운 변경이 폴리레포에서는 너무 번거로워서 아예 시도조차 안 되는 경우가 훨씬 더 많음.
대형 테크 기업 경험상 빌드 시스템 관리에는 아예 전담 팀이 필요. 대형 모노레포는 소스 파일을 필요 시 다운로드하는 가상 파일 시스템 기반. 기사에서 언급 안 된 점은, 거의 모든 개발이 데이터센터에서 동작하는 개발 서버에서 진행, 50~100코어 환경 혹은 온디맨드 컨테이너(수시로 최신 커밋으로 업데이트) 활용. IDE가 dev server와 통합돼 언어나 서비스별로 사전준비/자동설정까지 chef/ansible로 자동화. 랩톱에서 직접 대규모 모노레포 개발할 일은 매우 드뭄(예외: 모바일/맥앱 등).
아마 같은 빌드 팀에서 일한 경험자. 모노레포 개발 환경이 로컬이든 원격이든, 재현성(reproducibility)이 더 중요. 이미징되는 원격 dev server면 더 쉽고 신뢰도 높음.
적은 규모 팀에서도 데이터센터 개발환경 활용 경험. 요즘 하드웨어 가격과 밀도를 보면 자체 랙을 꾸려 dev/staging/test 등 온디맨드 툴 다 돌리는 게 훨씬 합리적. 프로덕션과 유사한 개발 환경을 공유하게 되면 모노레포 방식이 아주 달라보임. 하지만 중소 기업은 빌드 시스템에 투자할 여력이 없고, 그런 대형 빌드 시스템 문제 자체가 생기지 않음(최소 10~20인 규모, 아주 복잡한 제품이어도 유지보수는 파트타임이 전부일 수도 있음).
Molnett(serverless cloud)에서 Bazel 기반 모노레포로 엄청난 효율을 경험한 소규모 팀(풀타임 1.5명) 이야기. Tilt+Bazel+Kind로 전체 플랫폼과 쿠버네티스 오퍼레이터까지 랩톱에서 기동, Mac/Linux 모두 지원. Bottlerocket 기반 OS 및 Firecracker까지 로컬에서 검증 가능. tool layer 구축으로 모든 개발자 동일 버전 go/kubectl 사용, 로컬 설치 필요 없음. 관리에 노력은 들지만, ex Google SRE 멤버 덕에 가능. 앞으로도 이런 방식만 원함. (주요 언어는 Golang, Bash, Rust)
1.5명 소규모라면 단일 레포가 당연. Bazel 경험은 아주 나빴지만, 대규모 프로젝트에는 쓸 가치가 있을 수도. 2명 미만 규모에는 오히려 Kind+Tilt만으로 충분. tool layer도 Go가 이미 go.mod로 어느 정도 해결. kubectl도 비슷하게 가능. ex-Googler의 연봉 수준도 고민 필요. Bazel 유지비용이 앞으로도 가치 있길 바람.
우리 회사는 시스템드(systemd) 기반 서비스 및 ansible playbooks로 배포, tmuxinator로 백엔드/DB/검색엔진/프론트엔드까지 모든 서비스 dev 모드로 터미널 한 번에 자동 기동. root에 ‘tmuxinator’ 명령 한번이면 전체 dev 환경이 뚝딱. 단일 모노레포가 이전보다 압도적으로 편리.
비슷한 상황, Bazel 도입 효과 극대화 경험 공유. tool layer 덕에 일관되게 개발 환경 유지 가능. 직접 bazel run을 써야 하는데, 좀 더 나은 자동화 방법을 궁금해함. 어떻게 동작하는지 알려주기를 요청.
2명 규모에서 마이크로서비스/K8s 패턴 자체가 오버엔지니어링. 이 정도 인원 규모에서는 어떤 방식이든 문제 없음. 예전엔 Dropbox/SVN/MS VCS 등 어떤 방식이든 다 돌아갔고(불편한 점은 있었지만), 다 문제가 되지 않았음. 이 규모에서는 모두가 전체 프로세스를 머릿속에 그릴 수 있음. 복잡한 도구나 인프라가 성공 요인이 아니라는 경험 공유.
지난 4년간 여러 회사에서 세 번이나 모노레포 설정 작업한 프리랜서 경험 공유. 프론트엔드에 한정해 JavaScript/TypeScript 생태계만 써서 그나마 관리 쉬움. 실제 좋은 모노레포는 내부적으로 폴리레포처럼 동작, 각각의 프로젝트가 독립적으로 개발/배포/호스팅 가능하지만 하나의 코드베이스에 공존하며 공통 구성요소(UI 등)도 자유롭게 공유, 일관된 룩앤필 보장. 실전 가이드로 참고 자료 추천.
이건 실제로 폴리레포가 아니라 모노레포를 제대로 구축한 사례임.
결국, 모든 것은 경우에 따라 다름. 우리 회사는 약 40여 개의 git 레포를 별도 CI로 관리, 빌드/테스트/패키징 후 최종적으로 통합 파일 시스템 이미지를 만들어 인티그레이션 테스트. 컴포넌트 간 Flatbuffers 메시지로 통신하며 flatbuffers도 서브모듈로 관리. 다운스트림 의존성 처리가 힘들긴 하나, progressive enhancement로 어느 정도 유연성 확보. 이런 경우 멀티레포인지, 서브모듈 많은 모노레포인지 진단 자체가 애매. 모노레포로 바꾸면 장점이 있을지는 미지수. 결국 트레이드오프와 감내할 불편의 종류 선택 문제.
모노레포 도구 관련 블로그 작성자 경험. 사람들이 모노레포의 장점만 강조하지만, 실제로 성공적인 모노레포 운영의 복잡함은 대부분 이면에서 devops/devtools 팀이 감당. 따라서 도입은 신중해야 하지만, 잘 구축하면 충분한 가치 제공.
잘 관리된 모노레포 경험은 너무 좋아서 다른 워크플로우로 되돌아가기 싫음. 하지만 준비 안 된 "우리도 모노레포 하자" 식은 악몽. 만약 준비된 모노레포 환경과 도구를 패키지로 팔면 비즈니스 기회가 클 거라 생각.
NX가 이미 그런 사업을 하고 있음. 이전 스타트업에서 처음부터 NX로 개발해 15명 R&D팀으로도 100명 규모의 표준화를 실현. 새로운 회사(스타트업 인수한 곳)는 무계획 "우리도 모노레포" 시도로 참사. 지금 NX로 이관 중인데 효과 아주 좋음.
대형 조직에서 모노레포가 오히려 팀 간 의존성을 극도로 제한해 코드 재사용을 저하시킬 수도 있다는 점을 경험. 라이브러리 팀이 바꾸려면 하위 사용자 모두 업데이트해야 하는데, 예상치 못한 방식으로 사용하는 팀 때문에 수정이 복잡하게 꼬임(Hyrum's Law). 결국, 대기업은 내부 복붙, 포크, 엄격한 접근제어, 느린 변경 승인 등으로 귀결.
범용으로 활용할 라이브러리를 만들 땐 API 설계에 신중해야 함. 가능하면 API는 바꾸지 않고, 바꿔야 한다면 대규모 변경을 확실히 기획하거나 새 함수로 대체+구버전 deprecated 처리 권장. 소규모 코드라면 복붙도 괜찮음.
그래도 모노레포의 장점은 모든 사용처를 쉽게 찾고, 필요시 원자적으로 변경/수정 가능하다는 점.
모든 소프트웨어는 의존관계를 고려해야 하며, 모노레포는 오히려 라이브러리나 사용자 입장에 있어서 서로를 바꿀 권한이 증가.
Hacker News 의견
이 스레드를 보면서 예전의 complexity merchants에 대한 이야기가 떠오르는 경험 공유 요청. 모노레포로 이동하면 기술적 희생이 있다는 의견에 전혀 동의하지 않는 입장. 계층적 파일 시스템의 파워를 이해하면 모노레포의 가치를 알 수 있음. CI/CD가 여기저기 흩어진 구성보다 모노레포 하나로 구성하는 게 훨씬 더 명확. 모노레포의 핵심은 전체 조직이 원자적인 커밋을 할 수 있다는 점임. 많은 개발자를 조율할 때 그 효용이 압도적임. 한 번에 리베이스하고 한 번의 큰 미팅이면 충분. 팀원들이 서로 안 좋아해 협업하지 않아도 관리 측면에서 모노레포는 큰 HR 도구 역할.
최근 개발자들은 지나치게 분리, 마이크로서비스, 다수의 작은 레포지토리, 모놀리스를 극도로 피하는 경향이 있음. 이는 복잡성을 키워 조직 구조 문제를 미래의 기술적 문제로 전환하는 결과. 소프트웨어 시스템의 내부 종속성도 제대로 인식하지 못함. 이전 직장에서 프로토콜 버퍼 스키마 파일을 업데이트하는 데 낭비된 시간이 믿기지 않을 정도. 다행히 지금 회사는 그렇지 않음.
여러 프로젝트에서 커밋을 추적하는 것은 있으면 좋은 정도이며, 실제로 의존성 추적이나 다운스트림 테스트 트리거 면에서 큰 차이 없음. 멀티레포 자동화로도 충분히 가능. 모노레포가 도움은 되지만 완전하지도 않고, 비용도 큼. 배포나 빌드가 원자적으로 처리되지 않음. 모노레포 규모가 커지면 git에서 벗어나 새로운 툴이 필요하고 이건 아주 큰 작업. 경험이 없으면 쉽게 말할 수 있는 부분 아님.
모노레포의 장점은 분명 존재하지만, 관리 비용이 polyrepo보다 더 비쌈. 어떤 상황에서든 무조건 모노레포가 좋은 것은 아님. 자세한 설명은 이 글 참고. 비용 대비 효과는 상황에 따라 다름.
프로그래밍 환경 설계에서 팀에 더 많은 파워를 줄수록 문제도 늘어난다는 게 유익한 경험칙. 기술적으로는 원자적 커밋이 더 강력한 파워가 아니고 오히려 적은 파워지만, 나쁜 인터페이스로 일하는 걸 가능하게 하므로 오히려 문제를 유발하는 파워임.
모노레포로 바꾸면 변화가 더 원자적이라는 믿음은 함정이라는 의견. [원문 인용: 모노레포의 가장 큰 허상은 전체 코드베이스에 원자적 커밋이 가능하다는 것. 실제로는 다양한 배포 아티팩트가 있는데, 서비스와 클라이언트 등을 한 번에 바꿔도 배포는 비동기적으로 일어남. 여러 레포에서는 여러 PR로 작업해야 하므로 위험 인식이 깔림. 모노레포의 CI는 주로 서비스 계약(CI job) 검증 역할을 하며, 필요시 변경 이유 명시가 요구됨.]
빅테크 모노레포에는 두 가지 유형이 있음. 첫째는 글에서 말한 전사적 단일 "THE" 모노레포로, 커스텀 VCS/CI가 필요하고 200명 엔지니어가 지원함. Google, Meta, Uber가 이 방식. 이 경지에 오르기까지 고통은 상상 이상이며, 보통 더 작게 나눈 "팀 단위" 모노레포에서 점차 확장. 각 스택/언어/팀마다 Bazel, Turborepo, Poetry 같은 도구로 각자 관리하다 시간이 지나면 더 큰 모노레포로 합쳐짐. 그러나 이 둘 모두 개발자와 비즈니스 모두 수백만 달러, 수백만 시간의 투자가 들어가며, 결국은 이 과정을 견딘 개발자들의 지원으로 유지.
대형 모노레포 회사에서 일했을 때 모노레포를 훨씬 더 선호. 단일 모노레포가 서비스 그래프, 코드 호출 구조 등 전체를 투명하게 파악하는 데 아주 도움이 됨. 폴리레포의 경우 지식이 팀별로 분산, 신규 코드 인수도 어렵고, 코드 아카이브 파악은 마치 미궁 탐험. 폴리레포는 오래된 디스코드/슬랙 메시지처럼 잊혀지는 느낌. 모노레포가 비용이 많이 들면, 폴리레포도 마찬가지로 다른 방식의 비용 발생. 모노레포는 거대한 대륙의 초식동물, 폴리레포는 다양한 종이 어둠에 묻힘.
현재 회사에서 백엔드가 약 11개 git 레포로 나뉘어 있으며, 기능 한 건을 위해 4~5개 머지 리퀘스트가 필요해 매우 번거로움. 여러 프로젝트를 모으기 위해 모노레포 도입을 검토 중. 그런데 레포를 합칠 수 없다면 모노레포 대안은 무엇인지 궁금.
언어와 무관하게 쉽고 강력한 모노레포 오케스트레이션 시스템은 아직 없음. Bazel은 복잡하고 배우기 어렵지만 최근엔 문서화가 많이 개선됨. Buck, NX, Pants 등 다른 선택지도 있지만 각각 특징이 있고, 특히 웹 지원은 제한적임. 대부분의 CI가 이런 툴을 제대로 지원하지 않아 설정이 까다로움. 참고로 Microsoft의 Rush가 최고의 경험 제공, 특히 프론트엔드/노드JS 모노레포에는 Rush 추천 Rush 공식 사이트.
대부분의 모노레포가 Google, Uber, Meta같은 대기업 규모까지 커지지는 않는 현실 언급. 서비스 수도 회사마다 다르고, 많아도 100개 정도라면 VCS 스케일 문제 없고 LSP 태그도 무리 없이 랩톱에서 다 돌아감. 모든 테스트를 CI에서 무작정 돌려도 거의 무난. 결론: 모든 회사가 구글 규모를 필요로 하진 않음.
현재 회사는 언어 스택별로 모노레포를 구축하는 중. 꽤 괜찮은 절충안임.
모노레포 vs 멀티레포 논의에서 자주 나오지 않는 포인트는 '역 콘웨이의 법칙' 발생. 레포 구조가 조직 구조와 문제 해결 방식에 영향을 준다는 점. 모노레포는 공통 인프라 팀에 영웅적 작업을 유발, 공통 영역을 건드릴 때 잠재적 깨짐이 많아져 기능 하나 개발에도 난이도 상승. 멀티레포에서는 팀 간 여러 PR과 조율, 내부 정치 등이 필요하지만 더 다양한 개발자가 역할을 분산해 처리 가능.
모노레포에서도 중앙에 깊이 연결된 변경이라면 여러 단계로 나눠 적용할 수 있음. 그 과정에서 여러 PR 및 조정, 정치적 이슈도 다뤄야 하지만, 오히려 모노레포라서 롤아웃 상황을 더 명확하게 볼 수 있음.
폴리레포에서는 공통 영역에서의 변경이 다운스트림 레포들에 반영되지 않아 각 레포가 다른 버전에 고정되고, 수년간 업데이트가 안 되어 고생하는 사례가 훨씬 더 흔함.
조직이 애초 방향성을 레포 구조로 선택하고 나중에 기술 선택이 따라온다는 가정이 맞는지 질문. 실제론 구체적인 repo 구조보다 더 근본적인 조직 철학(파편화 vs 공유) 결정이 선행. 방향이 바뀌더라도 코드 관리 방식은 수정할 수 있음. 멀티레포라도 엔지니어가 거의 모든 코드 접근 가능하고, 모노레포도 강한 격리와 별도의 CI나 배포 관리 규칙 적용 가능.
모노레포에서는 프로젝트 간 손쉬운 변경이 폴리레포에서는 너무 번거로워서 아예 시도조차 안 되는 경우가 훨씬 더 많음.
대형 테크 기업 경험상 빌드 시스템 관리에는 아예 전담 팀이 필요. 대형 모노레포는 소스 파일을 필요 시 다운로드하는 가상 파일 시스템 기반. 기사에서 언급 안 된 점은, 거의 모든 개발이 데이터센터에서 동작하는 개발 서버에서 진행, 50~100코어 환경 혹은 온디맨드 컨테이너(수시로 최신 커밋으로 업데이트) 활용. IDE가 dev server와 통합돼 언어나 서비스별로 사전준비/자동설정까지 chef/ansible로 자동화. 랩톱에서 직접 대규모 모노레포 개발할 일은 매우 드뭄(예외: 모바일/맥앱 등).
아마 같은 빌드 팀에서 일한 경험자. 모노레포 개발 환경이 로컬이든 원격이든, 재현성(reproducibility)이 더 중요. 이미징되는 원격 dev server면 더 쉽고 신뢰도 높음.
적은 규모 팀에서도 데이터센터 개발환경 활용 경험. 요즘 하드웨어 가격과 밀도를 보면 자체 랙을 꾸려 dev/staging/test 등 온디맨드 툴 다 돌리는 게 훨씬 합리적. 프로덕션과 유사한 개발 환경을 공유하게 되면 모노레포 방식이 아주 달라보임. 하지만 중소 기업은 빌드 시스템에 투자할 여력이 없고, 그런 대형 빌드 시스템 문제 자체가 생기지 않음(최소 10~20인 규모, 아주 복잡한 제품이어도 유지보수는 파트타임이 전부일 수도 있음).
Molnett(serverless cloud)에서 Bazel 기반 모노레포로 엄청난 효율을 경험한 소규모 팀(풀타임 1.5명) 이야기. Tilt+Bazel+Kind로 전체 플랫폼과 쿠버네티스 오퍼레이터까지 랩톱에서 기동, Mac/Linux 모두 지원. Bottlerocket 기반 OS 및 Firecracker까지 로컬에서 검증 가능. tool layer 구축으로 모든 개발자 동일 버전 go/kubectl 사용, 로컬 설치 필요 없음. 관리에 노력은 들지만, ex Google SRE 멤버 덕에 가능. 앞으로도 이런 방식만 원함. (주요 언어는 Golang, Bash, Rust)
1.5명 소규모라면 단일 레포가 당연. Bazel 경험은 아주 나빴지만, 대규모 프로젝트에는 쓸 가치가 있을 수도. 2명 미만 규모에는 오히려 Kind+Tilt만으로 충분. tool layer도 Go가 이미 go.mod로 어느 정도 해결. kubectl도 비슷하게 가능. ex-Googler의 연봉 수준도 고민 필요. Bazel 유지비용이 앞으로도 가치 있길 바람.
우리 회사는 시스템드(systemd) 기반 서비스 및 ansible playbooks로 배포, tmuxinator로 백엔드/DB/검색엔진/프론트엔드까지 모든 서비스 dev 모드로 터미널 한 번에 자동 기동. root에 ‘tmuxinator’ 명령 한번이면 전체 dev 환경이 뚝딱. 단일 모노레포가 이전보다 압도적으로 편리.
비슷한 상황, Bazel 도입 효과 극대화 경험 공유. tool layer 덕에 일관되게 개발 환경 유지 가능. 직접 bazel run을 써야 하는데, 좀 더 나은 자동화 방법을 궁금해함. 어떻게 동작하는지 알려주기를 요청.
2명 규모에서 마이크로서비스/K8s 패턴 자체가 오버엔지니어링. 이 정도 인원 규모에서는 어떤 방식이든 문제 없음. 예전엔 Dropbox/SVN/MS VCS 등 어떤 방식이든 다 돌아갔고(불편한 점은 있었지만), 다 문제가 되지 않았음. 이 규모에서는 모두가 전체 프로세스를 머릿속에 그릴 수 있음. 복잡한 도구나 인프라가 성공 요인이 아니라는 경험 공유.
지난 4년간 여러 회사에서 세 번이나 모노레포 설정 작업한 프리랜서 경험 공유. 프론트엔드에 한정해 JavaScript/TypeScript 생태계만 써서 그나마 관리 쉬움. 실제 좋은 모노레포는 내부적으로 폴리레포처럼 동작, 각각의 프로젝트가 독립적으로 개발/배포/호스팅 가능하지만 하나의 코드베이스에 공존하며 공통 구성요소(UI 등)도 자유롭게 공유, 일관된 룩앤필 보장. 실전 가이드로 참고 자료 추천.
결국, 모든 것은 경우에 따라 다름. 우리 회사는 약 40여 개의 git 레포를 별도 CI로 관리, 빌드/테스트/패키징 후 최종적으로 통합 파일 시스템 이미지를 만들어 인티그레이션 테스트. 컴포넌트 간 Flatbuffers 메시지로 통신하며 flatbuffers도 서브모듈로 관리. 다운스트림 의존성 처리가 힘들긴 하나, progressive enhancement로 어느 정도 유연성 확보. 이런 경우 멀티레포인지, 서브모듈 많은 모노레포인지 진단 자체가 애매. 모노레포로 바꾸면 장점이 있을지는 미지수. 결국 트레이드오프와 감내할 불편의 종류 선택 문제.
모노레포 도구 관련 블로그 작성자 경험. 사람들이 모노레포의 장점만 강조하지만, 실제로 성공적인 모노레포 운영의 복잡함은 대부분 이면에서 devops/devtools 팀이 감당. 따라서 도입은 신중해야 하지만, 잘 구축하면 충분한 가치 제공.
잘 관리된 모노레포 경험은 너무 좋아서 다른 워크플로우로 되돌아가기 싫음. 하지만 준비 안 된 "우리도 모노레포 하자" 식은 악몽. 만약 준비된 모노레포 환경과 도구를 패키지로 팔면 비즈니스 기회가 클 거라 생각.
대형 조직에서 모노레포가 오히려 팀 간 의존성을 극도로 제한해 코드 재사용을 저하시킬 수도 있다는 점을 경험. 라이브러리 팀이 바꾸려면 하위 사용자 모두 업데이트해야 하는데, 예상치 못한 방식으로 사용하는 팀 때문에 수정이 복잡하게 꼬임(Hyrum's Law). 결국, 대기업은 내부 복붙, 포크, 엄격한 접근제어, 느린 변경 승인 등으로 귀결.
범용으로 활용할 라이브러리를 만들 땐 API 설계에 신중해야 함. 가능하면 API는 바꾸지 않고, 바꿔야 한다면 대규모 변경을 확실히 기획하거나 새 함수로 대체+구버전 deprecated 처리 권장. 소규모 코드라면 복붙도 괜찮음.
그래도 모노레포의 장점은 모든 사용처를 쉽게 찾고, 필요시 원자적으로 변경/수정 가능하다는 점.
모든 소프트웨어는 의존관계를 고려해야 하며, 모노레포는 오히려 라이브러리나 사용자 입장에 있어서 서로를 바꿀 권한이 증가.
모노레포에서는 내 상황에 맞게 변경이 쉬우므로 코드 재사용 확률이 폴리레포보다 높음.