Antigravity Agent
53 lines
4.9 KiB
Markdown
53 lines
4.9 KiB
Markdown
---
|
|
category: Unified
|
|
tags: [auto-consolidated, technical-documentation]
|
|
title: [[Monorepo Architecture|Monorepo Architecture]]
|
|
last_updated: 2026-05-02
|
|
---
|
|
|
|
# [[Monorepo Architecture|Monorepo Architecture]]
|
|
|
|
## 📌 Brief Summary
|
|
프론트엔드 모노레포([[Monorepo|Monorepo]]) 아키텍처는 여러 프론트엔드 프로젝트(웹 앱, 어드민 앱, 공유 UI 컴포넌트 라이브러리, 린트(Lint) 및 타입스크립트 설정 등)를 단일 Git 저장소에서 관리하는 구조를 의미합니다 [1, 2]. 이는 단순한 폴더의 집합이 아니라 명확한 경계와 의존성 그래프를 갖춘 시스템으로, 여러 애플리케이션 간에 디자인 토큰이나 UI 원시 컴포넌트를 원활하게 공유하고 원자적 리팩토링(Atomic refactors)을 가능하게 하여 일관된 개발자 경험을 제공합니다 [1, 3].
|
|
|
|
---
|
|
|
|
> 지식 요약 정보 추출 중...
|
|
|
|
## 📖 Core Content
|
|
* **구조 및 패키지 분리 (Packages & [[Boundaries|Boundaries]]):**
|
|
모노레포는 일반적으로 실제 배포 가능한 단위인 `apps/` 디렉터리([[Next.js|Next.js]], Vite 등)와 재사용 가능한 빌딩 블록이 모인 `packages/` 디렉터리(ui, shared, api-client, config 등)로 나뉩니다 [2]. 이러한 구조를 유지하기 위해서는 패키지 간의 명확한 경계 설정이 필수적입니다 [4, 5].
|
|
* **공개 API를 통한 캡슐화 ([[Public APIs|Public APIs]]):**
|
|
모듈 내부의 세부 구현이 외부로 누출되는 것을 막기 위해 '깊은 가져오기(Deep imports)'를 금지해야 합니다 [5, 6]. `package.json`의 `exports` 필드를 사용하여 안정적인 진입점(예: `src/index.ts`)만을 통해 모듈을 불러오도록 강제함으로써(예: `import Button from "@acme/ui/src/button/Button"` 대신 `import { Button } from "@acme/ui"` 사용), 의존성을 캡슐화하고 리팩토링을 용이하게 합니다 [5, 7].
|
|
* **핵심 도구 (Tooling):**
|
|
성공적인 모노레포 운영을 위해 의존성 관리 및 작업 오케스트레이션 도구가 필수적으로 사용됩니다 [8].
|
|
* **pnpm workspaces:** 빠른 설치와 엄격한 의존성 관리를 지원하며, `workspace:*` 프로토콜을 통해 내부 패키지를 깔끔하게 연결합니다 [9, 10].
|
|
* **[[Turborepo|Turborepo]]:** 작업 파이프라인을 단순화하고, 점진적 빌드(Incremental builds) 및 원격 캐싱을 통해 로컬 개발과 CI 속도를 극대화합니다 [7, 11, 12].
|
|
* **Nx:** 강력한 프로젝트 그래프 기반으로 변경 사항에 영향을 받는(affected) 프로젝트만 빌드 및 테스트하고, 아키텍처 경계를 강제하는 기능을 제공하는 완전한 모노레포 플랫폼입니다 [13-15].
|
|
* **Lerna:** 다중 패키지의 배포(Publishing) 및 버전 관리 워크플로우에 유용합니다 [10, 16].
|
|
* **내부 아키텍처 및 의존성 관리:**
|
|
모노레포 내의 코드가 무질서한 덩어리가 되는 것을 막기 위해 FSD([[Feature-Sliced Design|Feature-Sliced Design]])와 같은 방법론이 결합되어 사용됩니다 [17, 18]. 코드를 `shared`, `entities`, `features`, `widgets`, `pages`, `app` 등 명확한 계층으로 나누어 하위 계층이 상위 계층을 참조하지 못하도록 의존성 방향을 단방향으로 통제합니다 [17, 19]. 또한 번들 내에 여러 버전의 React가 포함되는 문제를 방지하기 위해, 프레임워크 의존성은 '앱'이 소유하고 '공유 패키지'는 이를 peer dependency로 설정해야 합니다 [20].
|
|
* **CI/CD 파이프라인 최적화:**
|
|
대규모 저장소에서는 변경된 모듈과 그에 영향을 받는 앱만을 대상으로 린트, 테스트, 빌드를 실행하는 '영향도 기반(affected)' 접근 방식과 빌드 결과를 재사용하는 원격 캐싱(Remote caching)을 활용하여 파이프라인을 빠르고 예측 가능하게 유지해야 합니다 [12, 21, 22].
|
|
|
|
---
|
|
|
|
본문 구조화 작업 중...
|
|
|
|
## ⚖️ Trade-offs & Caveats
|
|
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
|
- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
|
|
|
|
## 🔗 Knowledge Connections
|
|
- **Related Topics:** [[Component Library Architecture|Component Library Architecture]], Feature-Sliced Design (FSD), [[React Design Tokens|React Design Tokens]]
|
|
- **Projects/Contexts:** 다수의 React/Next.js 애플리케이션과 공통 UI 라이브러리를 보유한 엔터프라이즈 규모의 프론트엔드 환경
|
|
- **Contradictions/Notes:** 모노레포는 여러 앱이 코드와 도구를 공유할 때 유리하지만, 앱이 서로 독립적인 릴리스 주기를 갖는 완전 별개의 제품이거나, 조직의 규정 준수를 위해 엄격한 저장소 분리가 필요한 경우에는 폴리레포(Polyrepo) 방식이 더 안전하고 적합할 수 있습니다 [23].
|
|
|
|
---
|
|
*Last updated: 2026-04-26*
|
|
|
|
---
|
|
|
|
- Raw Source: 00_Raw/2026-04-20/Monorepo-Architecture.md
|
|
---
|