복잡한 소프트웨어 프로젝트를 진행할 때, monorepo와 polyrepo 사이의 선택은 팀의 생산성과 코드 확장성에 큰 영향을 미칠 수 있습니다. 이 글에서는 각 접근 방식의 차이점, 장단점을 분석하고, 어떤 것이 적합한지 이해하도록 도와드립니다.
Monorepo와 Polyrepo란 무엇인가요?
Monorepo
Monorepo(모놀리식 저장소)는 여러 프로젝트, 서비스 또는 패키지의 소스 코드를 포함하는 단일 저장소로, 종종 서로 관련되어 있습니다.
my-monorepo/ packages/ frontend/ backend/ shared/ package.json turbo.json
Polyrepo
Polyrepo(다중 저장소)는 각 프로젝트, 서비스 또는 패키지가 자체 별도의 저장소를 갖는 것을 의미합니다.
repos/ frontend/ package.json backend/ package.json shared/ package.json
시각적 차이
장단점
Monorepo
장점:
- 코드 공유가 쉬워집니다 (예: 공유 라이브러리).
- 여러 프로젝트에 걸친 원자적 리팩토링.
- 의존성 및 설정의 중앙 집중 관리.
단점:
- 코드베이스가 커지면 무거워질 수 있습니다.
- 부분 빌드/테스트를 관리하기 위한 도구가 필요합니다 (예: Nx, Turborepo).
Polyrepo
장점:
- 각 팀/프로젝트가 독립적입니다.
- 소규모 프로젝트에서 관리가 더 쉽습니다.
- 세분화된 접근 정책을 허용합니다.
단점:
- 패키지를 게시하지 않고는 코드 공유가 어렵습니다.
- 저장소 간 리팩토링이 더 복잡합니다.
- 설정의 중복 가능성이 있습니다.
실용적인 예제: Turborepo를 사용한 Monorepo
Turborepo를 사용하여 frontend와 backend가 포함된 monorepo를 만들고 싶다고 가정해 봅시다.
1. Monorepo 초기화
npx create-turbo@latest
2. 일반적인 구조
my-monorepo/ apps/ web/ # frontend Next.js api/ # backend Node.js/Express packages/ ui/ # shared component library utils/ # shared functions turbo.json package.json
3. package.json의 workspace 예제
{ "private": true, "workspaces": [ "apps/*", "packages/*" ] }
4. 공유 라이브러리 가져오기 예제
packages/utils/src/formatDate.ts에 함수가 있다고 가정합니다:
// packages/utils/src/formatDate.ts export function formatDate(date: Date): string { return date.toLocaleDateString('en-US'); }
Frontend에서:
// apps/web/pages/index.tsx import { formatDate } from '@myorg/utils'; export default function Home() { return <div>Today is {formatDate(new Date())}</div>; }
언제 Monorepo를 선택해야 할까요?
- 여러 관련 프로젝트를 진행하는 중대규모 팀.
- 코드 공유와 대규모 리팩토링이 필요한 경우.
- 빠르게 성장하고 최적화된 빌드/테스트가 필요한 프로젝트.
언제 Polyrepo를 선택해야 할까요?
- 소규모 또는 독립적인 프로젝트.
- 서로 다른 제품을 담당하는 별도의 팀.
- 매우 엄격한 접근 정책.
결론
모든 상황에 맞는 완벽한 솔루션은 없습니다. 선택은 팀 규모, 프로젝트 복잡성 및 협업 필요성에 따라 달라집니다. 중요한 것은 트레이드오프를 인식하고 복잡성을 관리하기 위한 올바른 도구를 선택하는 것입니다.