102 lines
6.1 KiB
Markdown
102 lines
6.1 KiB
Markdown
---
|
|
id: wiki-2026-0508-monorepo-architecture
|
|
title: Monorepo Architecture
|
|
category: 10_Wiki/Topics
|
|
status: needs_review
|
|
canonical_id: self
|
|
aliases: []
|
|
duplicate_of: none
|
|
source_trust_level: A
|
|
confidence_score: 0.92
|
|
tags: [uncategorized]
|
|
raw_sources: []
|
|
last_reinforced: 2026-05-08
|
|
github_commit: pending
|
|
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
|
tech_stack:
|
|
language: unspecified
|
|
framework: unspecified
|
|
---
|
|
|
|
# [[Monorepo Architecture]]
|
|
|
|
## 📌 한 줄 통찰 (The Karpathy Summary)
|
|
프론트엔드 모노레포([[Monorepo]]) 아키텍처는 여러 프론트엔드 프로젝트(웹 앱, 어드민 앱, 공유 UI 컴포넌트 라이브러리, 린트(Lint) 및 타입스크립트 설정 등)를 단일 Git 저장소에서 관리하는 구조를 의미합니다 [1, 2]. 이는 단순한 폴더의 집합이 아니라 명확한 경계와 의존성 그래프를 갖춘 시스템으로, 여러 애플리케이션 간에 디자인 토큰이나 UI 원시 컴포넌트를 원활하게 공유하고 원자적 리팩토링(Atomic refactors)을 가능하게 하여 일관된 개발자 경험을 제공합니다 [1, 3].
|
|
|
|
## 📖 구조화된 지식 (Synthesized Content)
|
|
* **구조 및 패키지 분리 (Packages & [[Boundaries]]):**
|
|
모노레포는 일반적으로 실제 배포 가능한 단위인 `apps/` 디렉터리([[Next.js]], Vite 등)와 재사용 가능한 빌딩 블록이 모인 `packages/` 디렉터리(ui, shared, api-client, config 등)로 나뉩니다 [2]. 이러한 구조를 유지하기 위해서는 패키지 간의 명확한 경계 설정이 필수적입니다 [4, 5].
|
|
* **공개 API를 통한 캡슐화 ([[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]]:** 작업 파이프라인을 단순화하고, 점진적 빌드(Incremental builds) 및 원격 캐싱을 통해 로컬 개발과 CI 속도를 극대화합니다 [7, 11, 12].
|
|
* **Nx:** 강력한 프로젝트 그래프 기반으로 변경 사항에 영향을 받는(affected) 프로젝트만 빌드 및 테스트하고, 아키텍처 경계를 강제하는 기능을 제공하는 완전한 모노레포 플랫폼입니다 [13-15].
|
|
* **Lerna:** 다중 패키지의 배포(Publishing) 및 버전 관리 워크플로우에 유용합니다 [10, 16].
|
|
* **내부 아키텍처 및 의존성 관리:**
|
|
모노레포 내의 코드가 무질서한 덩어리가 되는 것을 막기 위해 FSD([[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].
|
|
|
|
## 🔗 지식 연결 (Graph)
|
|
- **Related Topics:** [[Component Library Architecture]], [[Feature-Sliced Design (FSD)]], [[React Design Tokens]]
|
|
- **Projects/Contexts:** 다수의 React/Next.js 애플리케이션과 공통 UI 라이브러리를 보유한 엔터프라이즈 규모의 프론트엔드 환경
|
|
- **Contradictions/Notes:** 모노레포는 여러 앱이 코드와 도구를 공유할 때 유리하지만, 앱이 서로 독립적인 릴리스 주기를 갖는 완전 별개의 제품이거나, 조직의 규정 준수를 위해 엄격한 저장소 분리가 필요한 경우에는 폴리레포(Polyrepo) 방식이 더 안전하고 적합할 수 있습니다 [23].
|
|
|
|
---
|
|
*Last updated: 2026-04-26*
|
|
|
|
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
|
|
|
**언제 이 지식을 쓰는가:**
|
|
- *(TODO)*
|
|
|
|
**언제 쓰면 안 되는가:**
|
|
- *(TODO)*
|
|
|
|
## 🧪 검증 상태 (Validation)
|
|
|
|
- **정보 상태:** needs_review
|
|
- **출처 신뢰도:** A
|
|
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
|
|
|
## 🧬 중복 검사 (Duplicate Check)
|
|
|
|
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
|
- **처리 방식:** UPDATE (자동 정규화)
|
|
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
|
|
|
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
|
|
|
- **과거 데이터와의 충돌:** 없음
|
|
- **정책 변화:** 없음
|
|
|
|
## 🕓 변경 이력 (Changelog)
|
|
|
|
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
|
|------|-----------|-----------|--------|
|
|
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
|
|
|
## 💻 코드 패턴 (Code Patterns)
|
|
|
|
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
|
|
|
```text
|
|
# TODO
|
|
```
|
|
|
|
## 🤔 의사결정 기준 (Decision Criteria)
|
|
|
|
**선택 A를 써야 할 때:**
|
|
- *(TODO)*
|
|
|
|
**선택 B를 써야 할 때:**
|
|
- *(TODO)*
|
|
|
|
**기본값:**
|
|
> *(TODO)*
|
|
|
|
## ❌ 안티패턴 (Anti-Patterns)
|
|
|
|
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)* |