Antigravity Agent
209 lines
25 KiB
Markdown
209 lines
25 KiB
Markdown
---
|
|
category: Architecture
|
|
tags: [auto-wikified, technical-documentation, merged, architecture]
|
|
title: Monorepo
|
|
description: "모노레포(Monorepo)는 여러 애플리케이션(예: 고객 포털, 관리자 대시보드, 모바일 최적화 웹 앱 등)과 공유 라이브러리 패키지를 단일 저장소(Repository)에서 함께 호스팅하여 관리하는 아키텍처 패턴입니다 [1]."
|
|
last_updated: 2026-05-04
|
|
---
|
|
|
|
# Monorepo
|
|
|
|
|
|
## 📌 Brief Summary
|
|
모노레포(Monorepo)는 여러 애플리케이션(예: 고객 포털, 관리자 대시보드, 모바일 최적화 웹 앱 등)과 공유 라이브러리 패키지를 단일 저장소(Repository)에서 함께 호스팅하여 관리하는 아키텍처 패턴입니다 [1]. 최근의 대규모 웹 애플리케이션 및 마이크로 프론트엔드 환경에서는 복잡한 의존성 그래프를 관리하기 위해 Turborepo나 Nx와 같은 도구를 사용하는 모노레포가 산업 표준으로 자리 잡고 있습니다 [1-3]. 이를 통해 개발자는 매번 npm 패키지를 발행할 필요 없이 공유 코드의 변경 사항을 실시간으로 확인하며 개발할 수 있습니다 [4].
|
|
|
|
## 📖 Core Content
|
|
* **프론트엔드 및 대규모 UI 컴포넌트 관리 (Vue 3 등):**
|
|
대규모 멀티 모듈 시스템 및 마이크로 프론트엔드 아키텍처에서 모노레포는 코드베이스를 효율적으로 유지하기 위한 필수 전략입니다 [3]. Turborepo나 Nx를 활용하면 여러 개의 애플리케이션과 공통 컴포넌트가 담긴 `packages/ui` 폴더를 한 저장소 내에서 호스팅할 수 있습니다 [1].
|
|
* **지능형 캐싱 (Intelligent Caching):** Turborepo는 '핑거프린팅(fingerprinting)' 시스템을 사용하여 변경되지 않은 컴포넌트의 빌드 과정을 건너뜁니다. 이를 통해 CI/CD 소요 시간을 최대 80%까지 단축할 수 있습니다 [1].
|
|
* **워크스페이스 링킹 (Workspace Linking):** 로컬 심볼릭 링크(symlink)를 통해 공유 컴포넌트(예: Vue 3 Component)에 대한 변경 사항이 이를 사용하는 앱에 즉각적으로 반영되어 개발 편의성을 높입니다 [4].
|
|
* **실제 활용 사례:** TikTok과 같은 기업은 20만 개의 파일로 구성된 거대한 규모의 프론트엔드 모노레포를 관리하고 있습니다 [5].
|
|
|
|
* **백엔드 마이크로서비스 설계 (NestJS 등):**
|
|
NestJS와 같은 백엔드 환경에서 시스템을 마이크로서비스 구조로 분리할 경우, `nest new --monorepo` 명령어 또는 Turborepo/Nx 워크스페이스를 설정하여 모노레포를 구축하는 것이 권장됩니다 [2]. 이때 모든 서비스가 공통으로 임포트하여 사용하는 DTO(Data Transfer Object)와 같은 코드는 단일 `libs/` 패키지 내부에 배치하여 공유합니다 [2].
|
|
|
|
## ⚖️ Trade-offs & Caveats
|
|
* **운영 및 유지보수의 복잡성:** 특히 NestJS와 같은 백엔드 마이크로서비스 환경에서 모노레포를 채택할 경우, 여러 서비스 간에 공유되는 라이브러리를 관리하는 것이 매우 고통스럽고 복잡한 작업이 될 수 있습니다 [6].
|
|
* **버전 관리 및 배포 오버헤드:** 공유 라이브러리의 버전을 여러 서비스에 걸쳐 관리하고, 이들의 동기화 상태를 유지하며 배포(Deploy) 파이프라인을 다루는 과정에서 상당한 관리적 난제(Technical Debt)가 발생할 수 있습니다 [6].
|
|
|
|
|
|
---
|
|
*Last updated: 2026-05-03*
|
|
|
|
## 📚 Legacy Insights & Additional Context
|
|
> [!NOTE]
|
|
> Below is content merged from previous versions of this documentation.
|
|
|
|
## 📌 Brief Summary
|
|
> 모노레포(Monorepo)는 다수의 애플리케이션과 라이브러리 패키지(공유 컴포넌트, 유틸리티 등)를 포함하는 서로 연결된 여러 패키지들을 단일 저장소([[Repository|Repository]])에서 관리하는 소프트웨어 아키텍처입니다 [1, 2]. 대규모 프로젝트의 코드 공유를 용이하게 하지만, 패키지마다 개별적인 설정이 중복될 경우 '설정 드리프트(Configuration Drift)' 현상과 같은 유지보수의 어려움을 초래할 수 있습니다 [2, 3]. 이를 효과적으로 관리하기 위해 설정의 중앙 집중화와 루트(Root) 레벨에서의 오케스트레이션(Orchestration) 전략이 활용됩니다 [4, 5].
|
|
|
|
---
|
|
|
|
> 모노레포(Monorepo) 기반 구성 중앙화란 다수의 애플리케이션과 라이브러리가 존재하는 대규모 저장소에서 [[ESLint|ESLint]]나 Prettier와 같은 도구의 설정 파일 중복을 제거하고 단일 진실 공급원([[Single_Source_of_Truth|Single Source of Truth]])을 마련하는 아키텍처 패턴입니다 [1], [2]. 중앙화된 설정 패키지를 구축하고 이를 루트 레벨에서 오케스트레이션하여 공통 규칙을 전역적으로 관리함과 동시에 패키지 고유의 자율성을 유지합니다 [3]. 이를 통해 코드의 유지보수성을 극대화하고 개발 환경의 일관성 및 검사 속도를 크게 향상시킵니다 [4].
|
|
|
|
---
|
|
|
|
> 모노레포(Monorepo) 설정 중앙화는 대규모 프로젝트 내 여러 패키지에 분산되어 있는 코드 컨벤션([[ESLint|ESLint]], Prettier 등) 설정을 단일 핵심 패키지로 통합하고 관리하는 아키텍처입니다 [1-3]. 이를 통해 조직 내 코드 품질 규칙의 단일 진실 공급원([[Single_Source_of_Truth|Single Source of Truth]])을 구축하여 설정 파편화를 방지합니다 [3, 4]. 결과적으로 전역적인 규칙 업데이트를 용이하게 하고, 중복을 제거하여 린팅 검사 및 유지보수 효율을 극대화합니다 [3, 5].
|
|
|
|
---
|
|
|
|
> 모노레포(Monorepo) 아키텍처 설정은 여러 애플리케이션과 라이브러리가 공존하는 대규모 프로젝트 환경에서 [[ESLint|ESLint]], Prettier, Husky, [[lint-staged|lint-staged]] 등의 도구들을 효율적으로 구성하고 관리하는 방법론입니다 [1-3]. 중복된 설정 파일로 인한 관리의 어려움을 피하기 위해 중앙 집중식 설정 패키지와 루트 오케스트레이션(Root Orchestration)을 도입하여 단일 진실 공급원([[Single_Source_of_Truth|Single Source of Truth]])을 형성합니다 [2-4]. 이를 통해 패키지별 자율성을 유지하면서도 전역적인 코드 품질 규칙을 일관되고 빠르게 강제할 수 있습니다 [4, 5].
|
|
|
|
---
|
|
|
|
> 프론트엔드 및 모노레포(Monorepo) 개발 환경 설정은 대규모 프로젝트에서 코드 품질과 스타일의 일관성을 유지하고 중복된 설정을 줄이기 위한 핵심 과정입니다. [[Turborepo|Turborepo]]와 같은 모노레포 환경에서는 여러 애플리케이션과 패키지가 혼재하므로 중앙 집중식 ESLint 및 Prettier 설정 패키지를 구축하는 것이 권장됩니다 [1, 2]. 여기에 [[Husky|Husky]]와 lint-staged를 결합하여 변경된 파일에 대해서만 린팅(linting)과 포맷팅([[Formatting|Formatting]])을 수행하도록 오케스트레이션(orchestration)함으로써 개발자의 생산성과 커밋 속도를 크게 향상시킬 수 있습니다 [3, 4].
|
|
|
|
## 📖 Core 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].
|
|
* **빌드 도구 캐싱 활용:** 중앙 집중화된 설정 패키지를 [[Turborepo|Turborepo]] 등의 글로벌 의존성(Global Dependency)으로 설정하면, 규칙 변경 시 모든 패키지의 캐시를 올바르게 무효화하면서도 변경된 파일에 대해서만 빠른 린팅과 검사를 수행할 수 있습니다 [9]. (참고로 모노레포 도구 생태계에는 Turborepo 외에도 Nx, Bazel, Lerna 등이 존재합니다 [10, 11]).
|
|
|
|
---
|
|
|
|
- **문제점 (설정 관리의 악몽):** 대규모 모노레포 환경에서는 [[Next.js|Next.js]] 앱, 라이브러리 패키지, 공유 코드 등 각 패키지마다 `.eslintrc.json`과 `.eslintignore` 같은 설정 파일이 중복되어 존재하기 쉽습니다 [1], [5]. 이러한 설정의 파편화와 복제는 패키지 간 규칙의 불일치를 초래하고 일괄적인 업데이트를 어렵게 만들며, 특히 모노레포 루트에서 `[[lint-staged|lint-staged]]`를 실행해 변경된 파일만 검사하고자 할 때 개별 패키지의 규칙을 존중하기 어렵게 만드는 큰 단점이 있습니다 [1], [5].
|
|
- **해결을 위한 3단계 아키텍처:**
|
|
1. **중앙화된 설정 패키지 (Centralised Config Package):** 모노레포 내부에 별도의 패키지(예: `@repo/eslint-config`)를 생성하여 기본(Base), Next.js, 라이브러리 용도의 조합 가능한 사전 설정(Preset)을 구성합니다 [3], [6], [7]. 이를 통해 핵심 규칙에 대한 단일 진실 공급원을 제공하며, 이 패키지의 규칙을 변경하면 모든 패키지가 일관되게 혜택을 받습니다 [2].
|
|
2. **패키지 레벨 설정의 자율성:** 각 패키지는 최소한의 설정 파일(`eslint.config.mjs`)만을 가져 중앙 패키지의 사전 설정을 임포트해 사용합니다 [2]. 동시에 패키지 특정 오버라이드(override) 규칙을 추가할 수 있어 각 패키지의 자율성을 보장합니다 [2], [4].
|
|
3. **루트 오케스트레이션 설정 (Root Orchestration Config):** 모노레포 루트에 파일 글로브 패턴을 기반으로 적절한 사전 설정에 매핑하는 최상위(root) 오케스트레이션 설정을 생성합니다 [8]. 이 계층은 패키지의 경계를 존중하여 개별 패키지에 올바른 규칙이 할당되도록 제어하는 핵심 비결(Secret Sauce)입니다 [8].
|
|
- **도구 통합 및 기대 효과:**
|
|
- **빠르고 정교한 검사:** 루트 설정이 도입된 상태에서 [[Husky|Husky]]와 `lint-staged`를 연동하면, 커밋 시 변경된 파일만을 식별해 루트 설정이 해당 파일을 적절한 패키지 특정 규칙에 매핑하여 검사(Linting)를 수행합니다 [9].
|
|
- **캐싱을 통한 성능 최적화:** [[Turborepo|Turborepo]] 전역 의존성으로 중앙 ESLint 구성 패키지를 설정하면 설정이 변경될 때마다 캐시를 무효화하고 린트 결과를 효과적으로 캐싱하여 속도를 높일 수 있습니다 [9], [4].
|
|
- **코드베이스 정화 효과:** 중복 설정 파일 및 종속성을 삭제함으로써 `package.json` 라인 수와 락(lock) 파일 크기가 현저히 줄어들고, 전체 모노레포에서 코드 라인이 크게 감소하는 순효과를 얻을 수 있습니다 [10].
|
|
|
|
---
|
|
|
|
* **발생하는 문제점 (설정 파편화)**
|
|
대규모 모노레포(예: [[Turborepo|Turborepo]] 기반) 환경에는 다수의 [[Next.js|Next.js]] 애플리케이션, 라이브러리, 공유 코드 패키지가 혼재되어 있습니다 [2]. 패키지마다 중복된 `.eslintrc.json`과 `.eslintignore` 파일 및 의존성이 흩어져 있으면, 규칙을 전역적으로 업데이트하기 어렵고 설정이 일관되지 않게 어긋나는 '설정 드리프트(Configuration Drift)'가 발생하여 유지보수에 큰 악영향을 미칩니다 [1-3].
|
|
|
|
* **중앙화 아키텍처 설계**
|
|
이러한 문제를 해결하기 위한 구조는 크게 세 가지 요소로 나뉩니다 [6].
|
|
1. **중앙 설정 패키지 생성**: 내부적으로 공통 사용할 패키지(예: `@repo/eslint-config`)를 생성하고, Base, Next.js, Library용 등 목적에 맞는 조합 가능한(composable) 프리셋을 내보냅니다 [6-8].
|
|
2. **개별 패키지 적용**: 개별 패키지들은 불필요한 중복 설정 대신, 중앙 패키지에서 제공하는 프리셋을 가져와(import) 사용하되 필요한 패키지별 오버라이드(override)만 최소한으로 선언합니다 [4, 5, 9].
|
|
3. **루트 오케스트레이션(Root Orchestration)**: 모노레포 최상단에 전역 설정 파일(`eslint.config.mjs`)을 만들고 파일 패턴(glob pattern)을 이용해 특정 패키지 경로에 적절한 프리셋을 매핑합니다 [10]. 이는 각 패키지의 경계를 존중하면서도 하나의 위치에서 통제할 수 있게 해줍니다 [10].
|
|
|
|
* **자동화 도구와의 결합 및 이점**
|
|
* 루트 레벨에서 `[[Husky|Husky]]`와 `[[lint-staged|lint-staged]]`를 오케스트레이션 설정과 결합하면, 커밋 전(pre-commit)에 변경된 파일만 효율적으로 검사하면서도 각 패키지에 맞는 린트 규칙을 정확히 적용할 수 있습니다 [11].
|
|
* 중앙화된 설정을 적용하면 패키지 전반에 걸친 중복 의존성을 제거해 `package-lock.json` 크기가 축소되고, 전반적인 코드 라인 수가 대폭 감소합니다 [12].
|
|
* 또한 `Turborepo`의 캐싱 기능과 맞물려 캐시 무효화를 최소화하고 빠른 린팅과 신속한 커밋이 가능해집니다 [5, 11].
|
|
|
|
* **기술적 유의사항**
|
|
* 해당 중앙화 구성 방식은 플랫 구성(Flat Config) 형식을 지원하는 ESLint 9 버전 이상에 최적화되어 있습니다 [3, 7].
|
|
* ESLint 8 환경에서 이 패턴을 적용하려면 `.eslintrc.js` 파일 확장자와 CommonJS 모듈 내보내기를 사용하는 등의 추가적인 조정이 필요합니다 [13].
|
|
|
|
---
|
|
|
|
- **기존 모노레포 설정의 문제점**
|
|
일반적인 모노레포에는 [[Next.js|Next.js]] 애플리케이션, 라이브러리 패키지, 공유 코드 등이 함께 존재합니다 [2]. 패키지마다 개별적으로 `.eslintrc.json`과 `.eslintignore` 파일을 작성하고 ESLint와 Prettier 종속성을 중복으로 설치하게 되면, 린팅 규칙이 파편화되고 관리가 매우 어려워집니다 [2]. 특히 모노레포 루트 단위에서 `lint-staged`를 실행하여 변경된 파일만 검사하려 할 때, 각 패키지의 고유한 규칙을 준수하면서 실행하는 것이 큰 장애물로 작용합니다 [3].
|
|
|
|
- **루트 오케스트레이션 및 중앙 집중식 아키텍처**
|
|
현대적인 모노레포 환경에서는 구성 중복을 줄이기 위해 다음과 같은 3단계 아키텍처를 도입합니다 [3].
|
|
1. **중앙 집중식 설정 패키지 생성:** `@repo/eslint-config`와 같은 내부 패키지를 만들어 TypeScript 지원 및 Prettier 통합 등을 포함하는 기본(base) 설정과 Next.js, 일반 라이브러리에 맞춘 사전 설정(Preset)을 모듈로 구성합니다 [3, 6, 7].
|
|
2. **패키지 레벨 설정 적용:** 각 애플리케이션 및 라이브러리 패키지는 독자적인 설정 파일을 중복 생성하는 대신, 중앙에서 만든 설정을 최소한의 코드로 가져와(import) 사용합니다 [4].
|
|
3. **루트 오케스트레이션(Root Orchestration) 구성:** 모노레포 루트의 설정 파일에서 특정 파일 패턴(Glob pattern)에 따라 알맞은 패키지 설정이 적용되도록 매핑합니다 [8]. 이를 통해 각 패키지의 경계를 존중하면서 전역 기본 규칙을 적용할 수 있습니다 [8].
|
|
|
|
- **작업 파이프라인 연동과 성능 최적화**
|
|
- **Husky와 lint-staged 연동:** 루트 `package.json`에 `lint-staged`를 구성하고 Husky의 `pre-commit` 훅을 설정하여, 루트 설정(Root config) 기준으로 변경된 파일만 효율적으로 린트할 수 있습니다 [9]. 이 과정에서 루트 설정의 파일 패턴 매핑을 통해 개별 패키지 규칙이 안전하게 보장됩니다 [9].
|
|
- **[[Turborepo|Turborepo]] 캐싱 통합:** 중앙 ESLint 설정 패키지를 `turbo.json`의 전역 종속성(global dependency)으로 추가함으로써, 린트 규칙이 변경될 때 모든 패키지의 Turborepo 캐시를 자동으로 무효화하여 항상 최신 규칙이 적용되도록 합니다 [9].
|
|
- **공식 지침의 대안:** `lint-staged`의 공식 가이드는 루트에 도구를 설치하고 각 패키지별 개별 설정 파일을 두어 '가장 가까운(closest) 구성'을 격리하여 사용하도록 권장합니다 [10]. 하지만 루트 오케스트레이션을 활용하면 여러 설정을 조율하여 더욱 유지보수가 편하고 빠르며 유연한 중앙 집중식 환경을 갖출 수 있습니다 [11].
|
|
|
|
---
|
|
|
|
* **모노레포 환경의 문제점**
|
|
여러 개의 [[Next.js|Next.js]] 애플리케이션과 라이브러리 패키지가 포함된 대규모 모노레포에서는 각 패키지마다 `.eslintrc.json` 및 `.eslintignore` 파일이 중복 생성되고 린트 규칙이 일관성 없이 적용되는 유지보수 문제가 발생하기 쉽습니다 [5, 6]. 특히 모노레포 루트에서 `lint-staged`를 실행하여 변경된 파일만 검사하려 할 때, 각 패키지의 독립적인 린팅 규칙을 존중하게 만드는 것이 주요한 해결 과제입니다 [2].
|
|
|
|
* **중앙 집중식 구성(Centralised Config) 패키지 구축**
|
|
* 이러한 구성 중복 문제를 해결하기 위해 `@repo/eslint-config`와 같은 내부 공유 패키지를 생성하여, 상황에 맞게 조합할 수 있는 프리셋(base, next.js, library)을 구성합니다 [2, 7].
|
|
* **Base Config**: ESLint 9의 평면 구성(flat config) 포맷을 기반으로 하며, TypeScript 지원, Prettier 통합(충돌 규칙 비활성화)을 기본으로 포함합니다 [7].
|
|
* **Next.js Config / Library Config**: Next.js 앱을 위한 React 전용 린팅 규칙과 비 React 패키지를 위한 가벼운 TypeScript 규칙을 각각 분리하여 작성합니다 [8].
|
|
|
|
* **루트 오케스트레이션(Root Orchestration) 구성**
|
|
* 모노레포 루트에 `eslint.config.mjs`를 생성하여 파일 패턴(glob pattern)에 따라 각 패키지에 적절한 구성을 매핑합니다 [9].
|
|
* 이 방식은 `lint-staged`가 모노레포 루트에서 실행되더라도 패키지 경계를 존중하여 각 패키지가 자신에게 맞는 올바른 규칙(예: Next.js용 또는 라이브러리용)을 부여받도록 해줍니다 [9, 10].
|
|
|
|
* **Husky 및 lint-staged 연동**
|
|
* 루트의 `package.json`과 `.husky/pre-commit` 파일에 `lint-staged`와 Husky를 연동하여 커밋 시 변경된 파일에 대해서만 ESLint와 Prettier가 실행되도록 설정합니다 [3].
|
|
* 이를 통해 코드 전체를 린트하는 시간을 절약하고, 개발자가 코드를 커밋할 때 자동으로 포맷팅과 린트 수정을 적용할 수 있습니다 [3, 4].
|
|
|
|
* **Turborepo와의 캐싱 통합 및 도입 효과**
|
|
* `turbo.json`에 ESLint 구성 패키지를 전역 종속성으로 추가하여 린트 결과를 캐싱하고 설정 변경 시 전체 캐시를 무효화할 수 있습니다 [3].
|
|
* 이를 통해 패키지 수준의 중복 설정이 크게 줄어들고([[Single_Source_of_Truth|Single Source of Truth]] 확보), `lint-staged` 및 캐싱을 통한 빠른 커밋이 가능해지며, 새로운 패키지 추가 시 확장성과 개발자 경험(DX)이 크게 향상됩니다 [4, 11].
|
|
|
|
## ⚖️ Trade-offs & Caveats
|
|
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
|
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
|
|
|
|
---
|
|
|
|
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
|
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
|
|
|
|
---
|
|
|
|
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
|
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
|
|
|
|
---
|
|
|
|
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
|
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
|
|
|
|
---
|
|
|
|
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
|
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
|
|
|
|
## 🔗 Knowledge Connections
|
|
- **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].
|
|
|
|
---
|
|
*Last updated: 2026-04-19*
|
|
|
|
---
|
|
|
|
---
|
|
|
|
- **Related Topics:** [[ESLint|ESLint]], Prettier, lint-staged, [[Turborepo|Turborepo]]
|
|
- **Projects/Contexts:** 대규모 모노레포 환경의 린팅 및 포매팅 설정 현대화 프로젝트
|
|
- **Contradictions/Notes:** 공식적인 `lint-staged` 모노레포 가이드에서는 최상위에 `lint-staged`를 설치하고 각 패키지마다 별도의 구성 파일을 두어 고립되게 처리하라고 안내하며 루트 설정이 하위 설정을 자동으로 채워주지 않는다고 명시하지만 [11], 루트 오케스트레이션 구성을 도입하면 최상위에서 실행하면서도 패턴 매핑을 통해 각 패키지의 규칙을 성공적으로 병합·제어할 수 있습니다 [8], [12].
|
|
|
|
---
|
|
*Last updated: 2026-04-19*
|
|
|
|
---
|
|
|
|
---
|
|
|
|
- **Related Topics:** [[ESLint|ESLint]], Prettier, Turborepo, [[Husky|Husky]], [[lint-staged|lint-staged]]
|
|
- **Projects/Contexts:** 대규모 모노레포(Monorepo) 프로젝트, 다중 패키지 관리 환경
|
|
- **Contradictions/Notes:** 모노레포 환경에서 `lint-staged`를 적용하는 구조와 관련하여 다른 관점이 존재합니다. 일반적인 가이드에서는 패키지 간의 격리성 확보를 위해 각 패키지별로 독립된 설정 파일을 둘 것을 권장하지만 [14, 15], Turborepo를 활용하는 모노레포 환경에서는 최상위에서 '루트 오케스트레이션(Root Orchestration)'을 통해 파일 패턴으로 린팅을 중앙 제어하는 것이 중복 제거와 일관성 면에서 더 효과적인 해결책으로 제시되고 있습니다 [6, 9, 16].
|
|
|
|
---
|
|
*Last updated: 2026-04-19*
|
|
|
|
---
|
|
|
|
---
|
|
|
|
- **Related Topics:** [[Turborepo|Turborepo]], ESLint, Prettier, [[Husky|Husky]], [[lint-staged|lint-staged]]
|
|
- **Projects/Contexts:** Next.js 애플리케이션 및 라이브러리 관리, 모노레포 린트 자동화
|
|
- **Contradictions/Notes:** 소스 [10]에 따르면 `lint-staged`의 공식 지침은 여러 하위 패키지의 구성 파일을 상호 격리된 상태로 취급하여 가장 가까운 파일을 적용하라고 설명하지만, 소스 [3, 8, 12]에서는 단일 진실 공급원을 기반으로 루트에서 파일 패턴을 매핑해주는 루트 오케스트레이션(Root Orchestration) 방식이 유지보수와 실행 속도 면에서 모노레포에 더 뛰어난 해결책이라고 주장합니다.
|
|
|
|
---
|
|
*Last updated: 2026-04-19*
|
|
|
|
---
|
|
|
|
---
|
|
|
|
- **Related Topics:** [[Turborepo|Turborepo]], ESLint, Prettier, [[Husky|Husky]], [[lint-staged|lint-staged]]
|
|
- **Projects/Contexts:** Next.js 애플리케이션 및 내부 라이브러리 패키지 관리
|
|
- **Contradictions/Notes:** 모노레포에서 `lint-staged`의 공식 권장 사항은 각 패키지별로 별도의 설정 파일을 두고 가장 가까운 구성 파일이 적용되도록 하는 것이지만 [12, 13], Turborepo를 활용하는 현대적인 접근 방식에서는 루트 오케스트레이션 구성 파일(`eslint.config.mjs`)을 통해 파일 패턴을 각 프리셋에 중앙에서 매핑하는 방식이 더 효율적인 해결책으로 제시됩니다 [9, 10]. 또한, ESLint와 Prettier를 함께 사용할 경우 포맷팅 충돌을 방지하기 위해 반드시 `[[eslint-config-prettier|eslint-config-prettier]]`를 설정 배열의 마지막에 위치시켜야 합니다 [14].
|
|
|
|
---
|
|
*Last updated: 2026-04-19*
|
|
|
|
---
|