bluemsi/2nd
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
a7d1e60ccfc0642051ada21864443d6eed39ca80
2nd/10_Wiki/Topics/Architecture/Monorepo.md
T

25 KiB
Raw Blame History

category, tags, title, description, last_updated
category tags title description last_updated
Architecture
auto-wikified
technical-documentation
merged
architecture
Monorepo 모노레포(Monorepo)는 여러 애플리케이션(예: 고객 포털, 관리자 대시보드, 모바일 최적화 웹 앱 등)과 공유 라이브러리 패키지를 단일 저장소(Repository)에서 함께 호스팅하여 관리하는 아키텍처 패턴입니다 [1]. 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)에서 관리하는 소프트웨어 아키텍처입니다 [1, 2]. 대규모 프로젝트의 코드 공유를 용이하게 하지만, 패키지마다 개별적인 설정이 중복될 경우 '설정 드리프트(Configuration Drift)' 현상과 같은 유지보수의 어려움을 초래할 수 있습니다 [2, 3]. 이를 효과적으로 관리하기 위해 설정의 중앙 집중화와 루트(Root) 레벨에서의 오케스트레이션(Orchestration) 전략이 활용됩니다 [4, 5].

모노레포(Monorepo) 기반 구성 중앙화란 다수의 애플리케이션과 라이브러리가 존재하는 대규모 저장소에서 ESLint나 Prettier와 같은 도구의 설정 파일 중복을 제거하고 단일 진실 공급원(Single_Source_of_Truth)을 마련하는 아키텍처 패턴입니다 [1], [2]. 중앙화된 설정 패키지를 구축하고 이를 루트 레벨에서 오케스트레이션하여 공통 규칙을 전역적으로 관리함과 동시에 패키지 고유의 자율성을 유지합니다 [3]. 이를 통해 코드의 유지보수성을 극대화하고 개발 환경의 일관성 및 검사 속도를 크게 향상시킵니다 [4].

모노레포(Monorepo) 설정 중앙화는 대규모 프로젝트 내 여러 패키지에 분산되어 있는 코드 컨벤션(ESLint, Prettier 등) 설정을 단일 핵심 패키지로 통합하고 관리하는 아키텍처입니다 [1-3]. 이를 통해 조직 내 코드 품질 규칙의 단일 진실 공급원(Single_Source_of_Truth)을 구축하여 설정 파편화를 방지합니다 [3, 4]. 결과적으로 전역적인 규칙 업데이트를 용이하게 하고, 중복을 제거하여 린팅 검사 및 유지보수 효율을 극대화합니다 [3, 5].

모노레포(Monorepo) 아키텍처 설정은 여러 애플리케이션과 라이브러리가 공존하는 대규모 프로젝트 환경에서 ESLint, Prettier, Husky, lint-staged 등의 도구들을 효율적으로 구성하고 관리하는 방법론입니다 [1-3]. 중복된 설정 파일로 인한 관리의 어려움을 피하기 위해 중앙 집중식 설정 패키지와 루트 오케스트레이션(Root Orchestration)을 도입하여 단일 진실 공급원(Single_Source_of_Truth)을 형성합니다 [2-4]. 이를 통해 패키지별 자율성을 유지하면서도 전역적인 코드 품질 규칙을 일관되고 빠르게 강제할 수 있습니다 [4, 5].

프론트엔드 및 모노레포(Monorepo) 개발 환경 설정은 대규모 프로젝트에서 코드 품질과 스타일의 일관성을 유지하고 중복된 설정을 줄이기 위한 핵심 과정입니다. Turborepo와 같은 모노레포 환경에서는 여러 애플리케이션과 패키지가 혼재하므로 중앙 집중식 ESLint 및 Prettier 설정 패키지를 구축하는 것이 권장됩니다 [1, 2]. 여기에 Husky와 lint-staged를 결합하여 변경된 파일에 대해서만 린팅(linting)과 포맷팅(Formatting)을 수행하도록 오케스트레이션(orchestration)함으로써 개발자의 생산성과 커밋 속도를 크게 향상시킬 수 있습니다 [3, 4].

📖 Core Content

  • 대규모 모노레포의 관리 문제점: 전형적인 모노레포는 Next.js와 같은 사용자/관리자용 애플리케이션과 데이터 파서, 타입, API 클라이언트 등의 공유 라이브러리로 구성됩니다 [1]. 규모가 커질수록 수십 개의 패키지에 ESLint, Prettier 등의 설정 파일이 중복해서 생성되며, 이는 일관되지 않은 규칙 적용, 의존성 중복, 그리고 개별 패키지에 맞춘 [[lint-staged|lint-staged]] 실행의 어려움 등 심각한 유지보수 악몽(Maintenance Nightmare)으로 이어집니다 [1-3].
  • 중앙 집중식 설정 (Centralised Configuration): 설정 드리프트를 방지하기 위해 단일 진실의 원천(Single_Source_of_Truth) 역할을 하는 중앙 집중식 설정 패키지(예: @repo/eslint-config)를 생성하여 활용합니다 [2, 4, 6]. 베이스 규칙을 정의하고 필요한 프레임워크나 라이브러리 환경에 맞게 조합(Composable)하여 사용함으로써, 린팅 규칙 변경이나 보안 업데이트를 전체 모노레포에 동시다발적으로 쉽게 전파할 수 있습니다 [2, 4].
  • 루트 오케스트레이션 (Root Orchestration): 모노레포 환경에서 Husky와 lint-staged 같은 도구가 각 패키지의 규칙을 준수하면서도 효율적으로 동작하게 하려면, 루트(Root) 레벨에서 파일 패턴별로 적절한 패키지 설정을 매핑하는 오케스트레이션 설정이 필요합니다 [4, 7, 8]. 이를 통해 패키지 간의 자율성을 보장하면서도 중앙에서 도구를 통제할 수 있습니다 [7, 8].
  • 빌드 도구 캐싱 활용: 중앙 집중화된 설정 패키지를 Turborepo 등의 글로벌 의존성(Global Dependency)으로 설정하면, 규칙 변경 시 모든 패키지의 캐시를 올바르게 무효화하면서도 변경된 파일에 대해서만 빠른 린팅과 검사를 수행할 수 있습니다 [9]. (참고로 모노레포 도구 생태계에는 Turborepo 외에도 Nx, Bazel, Lerna 등이 존재합니다 [10, 11]).
  • 문제점 (설정 관리의 악몽): 대규모 모노레포 환경에서는 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와 lint-staged를 연동하면, 커밋 시 변경된 파일만을 식별해 루트 설정이 해당 파일을 적절한 패키지 특정 규칙에 매핑하여 검사(Linting)를 수행합니다 [9].
    • 캐싱을 통한 성능 최적화: Turborepo 전역 의존성으로 중앙 ESLint 구성 패키지를 설정하면 설정이 변경될 때마다 캐시를 무효화하고 린트 결과를 효과적으로 캐싱하여 속도를 높일 수 있습니다 [9], [4].
    • 코드베이스 정화 효과: 중복 설정 파일 및 종속성을 삭제함으로써 package.json 라인 수와 락(lock) 파일 크기가 현저히 줄어들고, 전체 모노레포에서 코드 라인이 크게 감소하는 순효과를 얻을 수 있습니다 [10].

  • 발생하는 문제점 (설정 파편화) 대규모 모노레포(예: Turborepo 기반) 환경에는 다수의 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 애플리케이션, 라이브러리 패키지, 공유 코드 등이 함께 존재합니다 [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 캐싱 통합: 중앙 ESLint 설정 패키지를 turbo.json의 전역 종속성(global dependency)으로 추가함으로써, 린트 규칙이 변경될 때 모든 패키지의 Turborepo 캐시를 자동으로 무효화하여 항상 최신 규칙이 적용되도록 합니다 [9].
    • 공식 지침의 대안: lint-staged의 공식 가이드는 루트에 도구를 설치하고 각 패키지별 개별 설정 파일을 두어 '가장 가까운(closest) 구성'을 격리하여 사용하도록 권장합니다 [10]. 하지만 루트 오케스트레이션을 활용하면 여러 설정을 조율하여 더욱 유지보수가 편하고 빠르며 유연한 중앙 집중식 환경을 갖출 수 있습니다 [11].

  • 모노레포 환경의 문제점 여러 개의 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 확보), lint-staged 및 캐싱을 통한 빠른 커밋이 가능해지며, 새로운 패키지 추가 시 확장성과 개발자 경험(DX)이 크게 향상됩니다 [4, 11].

⚖️ Trade-offs & Caveats

  • 과거 데이터와의 충돌: 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
  • 정책 변화: Programming & Language 분야의 자동 자산화 수행.
  • 과거 데이터와의 충돌: 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
  • 정책 변화: Programming & Language 분야의 자동 자산화 수행.
  • 과거 데이터와의 충돌: 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
  • 정책 변화: Programming & Language 분야의 자동 자산화 수행.
  • 과거 데이터와의 충돌: 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
  • 정책 변화: Programming & Language 분야의 자동 자산화 수행.
  • 과거 데이터와의 충돌: 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
  • 정책 변화: Programming & Language 분야의 자동 자산화 수행.

🔗 Knowledge Connections

  • Related Topics: ESLint, Prettier, lint-staged, Husky, 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, Prettier, lint-staged, Turborepo
  • Projects/Contexts: 대규모 모노레포 환경의 린팅 및 포매팅 설정 현대화 프로젝트
  • Contradictions/Notes: 공식적인 lint-staged 모노레포 가이드에서는 최상위에 lint-staged를 설치하고 각 패키지마다 별도의 구성 파일을 두어 고립되게 처리하라고 안내하며 루트 설정이 하위 설정을 자동으로 채워주지 않는다고 명시하지만 [11], 루트 오케스트레이션 구성을 도입하면 최상위에서 실행하면서도 패턴 매핑을 통해 각 패키지의 규칙을 성공적으로 병합·제어할 수 있습니다 [8], [12].

Last updated: 2026-04-19

  • Related Topics: ESLint, Prettier, Turborepo, Husky, 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, ESLint, Prettier, Husky, lint-staged
  • Projects/Contexts: Next.js 애플리케이션 및 라이브러리 관리, 모노레포 린트 자동화
  • Contradictions/Notes: 소스 [10]에 따르면 lint-staged의 공식 지침은 여러 하위 패키지의 구성 파일을 상호 격리된 상태로 취급하여 가장 가까운 파일을 적용하라고 설명하지만, 소스 [3, 8, 12]에서는 단일 진실 공급원을 기반으로 루트에서 파일 패턴을 매핑해주는 루트 오케스트레이션(Root Orchestration) 방식이 유지보수와 실행 속도 면에서 모노레포에 더 뛰어난 해결책이라고 주장합니다.

Last updated: 2026-04-19

  • Related Topics: Turborepo, ESLint, Prettier, Husky, 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

Reference in New Issue View Git Blame Copy Permalink