feat: Wiki 지식 자산 업데이트 - UX Scenarios, Frontend, Game Design, Topics 추가 [2026-05-08]
This commit is contained in:
@@ -1,18 +1,30 @@
|
||||
---
|
||||
category: Architecture
|
||||
tags: [auto-wikified, technical-documentation, merged, architecture]
|
||||
id: wiki-2026-0508-monorepo
|
||||
title: Monorepo
|
||||
description: "모노레포(Monorepo)는 여러 애플리케이션(예: 고객 포털, 관리자 대시보드, 모바일 최적화 웹 앱 등)과 공유 라이브러리 패키지를 단일 저장소(Repository)에서 함께 호스팅하여 관리하는 아키텍처 패턴입니다 [1]."
|
||||
last_updated: 2026-05-04
|
||||
category: Architecture
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [auto-wikified, technical-documentation, merged, architecture]
|
||||
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
|
||||
|
||||
|
||||
## 📌 Brief Summary
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
모노레포(Monorepo)는 여러 애플리케이션(예: 고객 포털, 관리자 대시보드, 모바일 최적화 웹 앱 등)과 공유 라이브러리 패키지를 단일 저장소(Repository)에서 함께 호스팅하여 관리하는 아키텍처 패턴입니다 [1]. 최근의 대규모 웹 애플리케이션 및 마이크로 프론트엔드 환경에서는 복잡한 의존성 그래프를 관리하기 위해 Turborepo나 Nx와 같은 도구를 사용하는 모노레포가 산업 표준으로 자리 잡고 있습니다 [1-3]. 이를 통해 개발자는 매번 npm 패키지를 발행할 필요 없이 공유 코드의 변경 사항을 실시간으로 확인하며 개발할 수 있습니다 [4].
|
||||
|
||||
## 📖 Core Content
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **프론트엔드 및 대규모 UI 컴포넌트 관리 (Vue 3 등):**
|
||||
대규모 멀티 모듈 시스템 및 마이크로 프론트엔드 아키텍처에서 모노레포는 코드베이스를 효율적으로 유지하기 위한 필수 전략입니다 [3]. Turborepo나 Nx를 활용하면 여러 개의 애플리케이션과 공통 컴포넌트가 담긴 `packages/ui` 폴더를 한 저장소 내에서 호스팅할 수 있습니다 [1].
|
||||
* **지능형 캐싱 (Intelligent Caching):** Turborepo는 '핑거프린팅(fingerprinting)' 시스템을 사용하여 변경되지 않은 컴포넌트의 빌드 과정을 건너뜁니다. 이를 통해 CI/CD 소요 시간을 최대 80%까지 단축할 수 있습니다 [1].
|
||||
@@ -22,7 +34,7 @@ last_updated: 2026-05-04
|
||||
* **백엔드 마이크로서비스 설계 (NestJS 등):**
|
||||
NestJS와 같은 백엔드 환경에서 시스템을 마이크로서비스 구조로 분리할 경우, `nest new --monorepo` 명령어 또는 Turborepo/Nx 워크스페이스를 설정하여 모노레포를 구축하는 것이 권장됩니다 [2]. 이때 모든 서비스가 공통으로 임포트하여 사용하는 DTO(Data Transfer Object)와 같은 코드는 단일 `libs/` 패키지 내부에 배치하여 공유합니다 [2].
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
* **운영 및 유지보수의 복잡성:** 특히 NestJS와 같은 백엔드 마이크로서비스 환경에서 모노레포를 채택할 경우, 여러 서비스 간에 공유되는 라이브러리를 관리하는 것이 매우 고통스럽고 복잡한 작업이 될 수 있습니다 [6].
|
||||
* **버전 관리 및 배포 오버헤드:** 공유 라이브러리의 버전을 여러 서비스에 걸쳐 관리하고, 이들의 동기화 상태를 유지하며 배포(Deploy) 파이프라인을 다루는 과정에서 상당한 관리적 난제(Technical Debt)가 발생할 수 있습니다 [6].
|
||||
|
||||
@@ -34,7 +46,7 @@ last_updated: 2026-05-04
|
||||
> [!NOTE]
|
||||
> Below is content merged from previous versions of this documentation.
|
||||
|
||||
## 📌 Brief Summary
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 모노레포(Monorepo)는 다수의 애플리케이션과 라이브러리 패키지(공유 컴포넌트, 유틸리티 등)를 포함하는 서로 연결된 여러 패키지들을 단일 저장소([[Repository|Repository]])에서 관리하는 소프트웨어 아키텍처입니다 [1, 2]. 대규모 프로젝트의 코드 공유를 용이하게 하지만, 패키지마다 개별적인 설정이 중복될 경우 '설정 드리프트(Configuration Drift)' 현상과 같은 유지보수의 어려움을 초래할 수 있습니다 [2, 3]. 이를 효과적으로 관리하기 위해 설정의 중앙 집중화와 루트(Root) 레벨에서의 오케스트레이션(Orchestration) 전략이 활용됩니다 [4, 5].
|
||||
|
||||
---
|
||||
@@ -53,7 +65,7 @@ last_updated: 2026-05-04
|
||||
|
||||
> 프론트엔드 및 모노레포(Monorepo) 개발 환경 설정은 대규모 프로젝트에서 코드 품질과 스타일의 일관성을 유지하고 중복된 설정을 줄이기 위한 핵심 과정입니다. [[Turborepo|Turborepo]]와 같은 모노레포 환경에서는 여러 애플리케이션과 패키지가 혼재하므로 중앙 집중식 ESLint 및 Prettier 설정 패키지를 구축하는 것이 권장됩니다 [1, 2]. 여기에 [[Husky|Husky]]와 lint-staged를 결합하여 변경된 파일에 대해서만 린팅(linting)과 포맷팅([[Formatting|Formatting]])을 수행하도록 오케스트레이션(orchestration)함으로써 개발자의 생산성과 커밋 속도를 크게 향상시킬 수 있습니다 [3, 4].
|
||||
|
||||
## 📖 Core Content
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **대규모 모노레포의 관리 문제점:** 전형적인 모노레포는 [[Next.js|Next.js]]와 같은 사용자/관리자용 애플리케이션과 데이터 파서, 타입, API 클라이언트 등의 공유 라이브러리로 구성됩니다 [1]. 규모가 커질수록 수십 개의 패키지에 ESLint, Prettier 등의 설정 파일이 중복해서 생성되며, 이는 일관되지 않은 규칙 적용, 의존성 중복, 그리고 개별 패키지에 맞춘 `[[lint-staged|lint-staged]]` 실행의 어려움 등 심각한 유지보수 악몽(Maintenance Nightmare)으로 이어집니다 [1-3].
|
||||
* **중앙 집중식 설정 (Centralised Configuration):** 설정 드리프트를 방지하기 위해 단일 진실의 원천([[Single_Source_of_Truth|Single Source of Truth]]) 역할을 하는 중앙 집중식 설정 패키지(예: `@repo/eslint-config`)를 생성하여 활용합니다 [2, 4, 6]. 베이스 규칙을 정의하고 필요한 프레임워크나 라이브러리 환경에 맞게 조합(Composable)하여 사용함으로써, 린팅 규칙 변경이나 보안 업데이트를 전체 모노레포에 동시다발적으로 쉽게 전파할 수 있습니다 [2, 4].
|
||||
* **루트 오케스트레이션 (Root Orchestration):** 모노레포 환경에서 [[Husky|Husky]]와 lint-staged 같은 도구가 각 패키지의 규칙을 준수하면서도 효율적으로 동작하게 하려면, 루트(Root) 레벨에서 파일 패턴별로 적절한 패키지 설정을 매핑하는 오케스트레이션 설정이 필요합니다 [4, 7, 8]. 이를 통해 패키지 간의 자율성을 보장하면서도 중앙에서 도구를 통제할 수 있습니다 [7, 8].
|
||||
@@ -129,7 +141,7 @@ last_updated: 2026-05-04
|
||||
* `turbo.json`에 ESLint 구성 패키지를 전역 종속성으로 추가하여 린트 결과를 캐싱하고 설정 변경 시 전체 캐시를 무효화할 수 있습니다 [3].
|
||||
* 이를 통해 패키지 수준의 중복 설정이 크게 줄어들고([[Single_Source_of_Truth|Single Source of Truth]] 확보), `lint-staged` 및 캐싱을 통한 빠른 커밋이 가능해지며, 새로운 패키지 추가 시 확장성과 개발자 경험(DX)이 크게 향상됩니다 [4, 11].
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
|
||||
|
||||
@@ -153,7 +165,7 @@ last_updated: 2026-05-04
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[ESLint|ESLint]], Prettier, lint-staged, [[Husky|Husky]], [[Turborepo|Turborepo]]
|
||||
- **Projects/Contexts:** 대규모 소프트웨어 엔지니어링 및 CI/CD 파이프라인, 자동화된 코드 거버넌스(Automated Governance)
|
||||
- **Contradictions/Notes:** 모노레포 내 `lint-staged` 적용과 관련하여 `lint-staged`의 공식 지침은 저장소 루트에 도구를 설치하고 각 패키지에 완전히 격리된 별도의 설정 파일을 두는 것을 권장하지만 [12, 13], Turborepo를 활용하는 모던 아키텍처 환경에서는 루트에 오케스트레이션 설정 하나를 두고 파일 패턴을 각 패키지 환경에 매핑하는 방식이 더 나은 개발자 경험(DX)을 제공하는 대안으로 제시되기도 합니다 [4, 8].
|
||||
@@ -206,3 +218,52 @@ last_updated: 2026-05-04
|
||||
*Last updated: 2026-04-19*
|
||||
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
Reference in New Issue
Block a user