[Paper] Runnable Directories: Monorepo vs. Multi-repo 논쟁에 대한 해결책

Source: arXiv - 2512.03815v1

Overview

이 논문은 Causify Dev 라는 하이브리드 코드베이스 조직 모델을 소개합니다. 기존의 monorepo와 multi‑repo 사이의 갈등을 새로운 원시 개념인 runnable directory 로 대체합니다. 각 디렉터리를 자체적으로 실행 가능한 단위로 취급함으로써, 저자들은 monorepo의 일관성을 유지하면서도 별도 저장소의 격리성과 모듈성을 누릴 수 있다고 주장합니다—도구 체인 관리의 번거로움 없이 말이죠.

Key Contributions

• Runnable Directory Concept – 소스, 빌드 스크립트, 테스트, 배포 기술서를 하나의 실행 가능한 단위로 묶는 디렉터리를 정의합니다.
• Thin Unified Environment – 모든 runnable directory가 상속받는 가벼운 공유 런타임(예: 최소 Docker 이미지)으로, 코드베이스 전체에 걸쳐 일관된 도구 버전을 보장합니다.
• Container‑First CI/CD Workflow – Docker 기반 파이프라인을 사용해 runnable directory마다 격리된 환경을 자동으로 생성함으로써 의존성 관리와 병렬 실행을 단순화합니다.
• Hybrid Repository Layout – 단일 Git 저장소 안에 다수의 runnable directory를 배치해 monorepo의 장점(단일 진실 원천, 원자적 커밋)을 유지하면서 확장성 병목을 피하는 방법을 제시합니다.
• Empirical Evaluation – 실제 마이크로서비스 스위트에 대한 벤치마크에서 전통적인 monorepo 대비 CI 빌드 시간이 최대 40 % 빨라지고, 의존성 관련 실패가 30 % 감소함을 보여줍니다.

Methodology

1. Design of Runnable Directories – 저자들은 각 디렉터리가 반드시 포함해야 하는 사양을 만들었습니다:
   • causify.yaml (메타데이터, 의존성, 진입점)
   • Dockerfile (또는 공유 thin 이미지에 대한 참조)
   • 표준 하위 폴더(src/, test/, deploy/)
2. Implementation of Causify Dev – CLI 도구가 메타데이터를 파싱하고, 디렉터리별 Docker 이미지를 생성하며, CI 파이프라인을 구동하는 중앙 오케스트레이터에 등록합니다.
3. Experimental Setup – 기존 12개 서비스, 250 k LOC monorepo(Java, Node.js, Python)를 runnable‑directory 모델로 마이그레이션했습니다. CI 파이프라인은 GitHub Actions와 Jenkins에서 원본 monorepo와 Causify Dev 버전 모두에 대해 실행되었습니다.
4. Metrics Collected – 빌드 시간, 테스트 플라키니스, 의존성 충돌 사건, 개발자 온보딩 시간(짧은 설문 조사로 측정) 등을 수집했습니다.

Results & Findings

데이터는 각 서비스 환경을 격리함으로써 대규모 monorepo에서 흔히 발생하는 “dependency hell”을 대부분 해소하고, 공유 thin 이미지가 버전 드리프트를 방지한다는 점을 시사합니다. 또한 개발자들은 테스트 대상 유닛이 명확히 경계 지어져 있어 변경에 대한 자신감이 높아졌다고 보고했습니다.

Practical Implications

• Faster CI/CD – 디렉터리 수준에서 빌드를 병렬화할 수 있어 교차 오염을 걱정할 필요가 없으며, 피드백 루프가 단축됩니다.
• Simplified Tooling – 격리를 강제하기 위한 복잡한 워크스페이스 매니저(예: Bazel, Lerna)가 필요 없으며, Docker가 무거운 작업을 수행합니다.
• Easier Scaling – 새로운 마이크로서비스를 추가하려면 저장소에 새로운 runnable directory를 넣기만 하면 되므로, 완전 새로운 저장소를 만들고 접근 제어를 관리하는 오버헤드가 사라집니다.
• Consistent Environments – thin 공유 이미지는 모든 개발자, CI 러너, 프로덕션 배포가 동일한 기본 도구(컴파일러 버전, 린터 등)를 사용하도록 보장합니다.
• Gradual Migration Path – 기존 monorepo를 점진적으로 리팩터링할 수 있습니다. 모듈을 하나씩 runnable directory로 전환해 위험을 최소화합니다.

Limitations & Future Work

• Docker Overhead – 컨테이너가 격리를 제공하지만, 매우 작은 유틸리티의 경우 로컬 개발 시작 시간이 늘어날 수 있습니다. 저자들은 경량 대안(podman 또는 nerdctl 등)을 향후 최적화 방안으로 제시합니다.
• Cross‑Directory Coupling – 모델은 비교적 느슨한 결합을 전제로 합니다. 긴밀히 결합된 컴포넌트는 여전히 공유 라이브러리를 필요로 할 수 있어, 일부 monorepo식 조정이 다시 필요합니다.
• Tooling Maturity – Causify Dev는 프로토타입 단계이며, 넓은 채택을 위해서는 IDE 통합 강화, 비‑Docker 런타임(예: Windows 네이티브 빌드) 지원 확대, 문서화가 필요합니다.
• Empirical Generalization – 평가가 단일 대규모 코드베이스에 국한되었으므로, 향후 연구에서는 다양한 언어, 도메인(예: 데이터 사이언스 파이프라인), 조직 규모에 걸쳐 접근 방식을 검증해야 합니다.

Bottom line: Runnable directory는 단일 진실 원천을 유지하면서 격리된 빌드의 안전성과 속도를 제공하는 실용적인 중간 지점을 제시합니다. 팀이 monorepo 확장성 문제나 다수의 저장소 관리 부담에 시달린다면, Causify Dev를 한 번 살펴볼 가치가 있습니다.

Authors

• Shayan Ghasemnezhad
• Samarth KaPatel
• Sofia Nikiforova
• Giacinto Paolo Saggese
• Paul Smith
• Heanh Sok

Paper Information

• arXiv ID: 2512.03815v1
• Categories: cs.SE
• Published: December 3, 2025
• PDF: Download PDF