모노레포 장단점을 일반론으로 외웠는지, 도입을 결정할 때 팀 규모·릴리즈 정책·도구 성숙도까지 트레이드오프로 엮어 설명할 수 있는지를 가른다.
모노레포는 여러 앱과 패키지를 하나의 저장소에서 함께 버전 관리하는 방식이다. 공통 모듈을 직접 참조해 변경 영향과 의존성 일관성을 한눈에 잡을 수 있는 대신, 코드베이스가 커지면 빌드·테스트 시간과 권한·코드오너 정책이 같이 무거워진다. 그래서 모노레포는 "한 저장소면 다 해결"이 아니라 캐시·affected build·소유권 모델로 운영 비용을 다시 깎아내야 굴러간다.
멀티레포에서 공유 라이브러리 버전 어긋남으로 고생한 적이 있다면 모노레포의 의존성 일관성 이득과 묶어 설명할 수 있다
CI가 풀 빌드로 느려져 캐시나 affected build를 도입해본 경험이 있다면 운영 비용 쪽 이야기로 자연스럽게 연결할 수 있다
공용 컴포넌트 변경이 다른 팀 앱에 영향을 줬던 사고가 있다면 코드오너·릴리즈 분리 정책 이야기로 이을 수 있다
사내 디자인 시스템이나 SDK를 운영해본 적이 있다면 통합 버전 vs 독립 버전 선택 근거를 본인 사례로 풀 수 있다
아직 공개된 답변이 없어요. 첫 공개 답변을 남겨보세요.