모노레포

모노레포는 따로 두었을 여러 프로젝트와 패키지를 하나의 버전 관리 저장소에 모아 두는 방식이다. 웹 앱과 API 서버, 공용 UI 라이브러리, 내부 도구가 한 저장소에 나란히 놓이고 커밋 이력과 리뷰 창구도 하나다. 가장 큰 장점은 원자적 변경이다. 공용 타입의 필드 이름을 바꾸고 이를 쓰는 모든 코드를 고치는 일이 한 커밋에서 끝나고 CI가 전체를 함께 검증한다. 패키지를 따로 배포할 때 생기는 버전 불일치가 사라지는 것이다. 의존성 관리가 한곳에 모이고 코드 공유에 배포 단계가 필요 없다는 점도 이점이다. 대가는 도구다. 아무 설정 없이 쓰면 변경 하나에 전체를 다시 빌드하고 테스트하므로, 의존성 그래프를 이해하고 결과를 캐시하는 실행기가 필요하다. 자바스크립트에서는 Turborepo와 Nx, 더 큰 규모에서는 Bazel이 그 역할을 맡고 pnpm 워크스페이스가 패키지를 연결한다. 모노레포는 모놀리스와 다르다. 코드는 여전히 서비스별로 따로 배포할 수 있다.

A monorepo is a single version-controlled repository that holds several projects or packages that would otherwise live apart. A web app, an API server, a shared UI library, and internal tooling sit side by side, with one commit history and one place to open a pull request. The benefit is atomic change: renaming a field in a shared type and updating every consumer happens in one commit that CI verifies as a whole, so the cross-package breakage typical of separately versioned libraries disappears. Dependency management is centralised, and code sharing needs no publish step. The cost is tooling. Naive setups rebuild and retest everything on each change, so monorepos rely on task runners that understand the dependency graph and cache results: Turborepo and Nx in the JavaScript ecosystem, Bazel at larger scale, with pnpm or Yarn workspaces linking packages. Google and Meta run famously large ones. A monorepo is not the same as a monolith, since the code can still deploy as separate services. The main pitfall is adopting it for a couple of packages, where the extra configuration costs more than the coordination it saves.