Files

T

koriweb 5ba5a55c78 feat: Wiki 지식 자산 업데이트 - UX Scenarios, Frontend, Game Design, Topics 추가 [2026-05-08]

2026-05-08 19:52:07 +09:00

6.0 KiB

Raw Blame History

id, title, category, status, canonical_id, aliases, duplicate_of, source_trust_level, confidence_score, tags, raw_sources, last_reinforced, github_commit, inferred_by, tech_stack

title

대규모 모노레포(Turborepo) 환경에서의 린트 오케스트레이션

📌 한 줄 통찰 (The Karpathy Summary)

대규모 모노레포(Turborepo) 환경에서는 여러 패키지가 혼재하여 린트(ESLint, Prettier) 설정이 중복되고 일관성이 떨어지며 모노레포 루트에서 [[lint-staged]]를 실행하기 까다로운 문제가 발생합니다 [1-3]. 이를 해결하기 위해 중앙 집중식 설정 패키지를 구성하고, 모노레포 루트에서 파일 패턴을 기반으로 적절한 프리셋을 매핑하는 오케스트레이션 구성을 도입합니다 [3, 4]. 이 아키텍처는 패키지별 자율성을 유지하면서도 Husky 및 lint-staged와 결합하여 변경된 파일만 효율적으로 검사할 수 있도록 지원합니다 [5, 6].

📖 구조화된 지식 (Synthesized Content)

기존 모노레포 린트 관리의 한계: 대규모 모노레포에는 Next.js 애플리케이션, 라이브러리 패키지, 공유 코드 등이 함께 존재합니다 [2]. 기존에는 패키지마다 .eslintrc.json 및 .eslintignore 파일이 중복으로 생성되어 유지보수가 어렵고 패키지 간 규칙의 일관성이 떨어지는 문제가 있었습니다 [1, 2]. 특히, 커밋 시 변경된 파일만 검사하기 위해 모노레포 루트에서 lint-staged를 실행할 때, 각 패키지의 고유한 린트 규칙을 존중하게 만드는 것이 매우 어려운 과제였습니다 [3].
중앙 집중식 설정 패키지 도입: 이 문제를 해결하기 위해 모노레포 내에 전용 설정 패키지(예: @repo/eslint-config)를 생성하여 기본(Base), Next.js, 라이브러리용 프리셋 등 조합 가능한 구성(composable preset configurations)을 만듭니다 [3, 7]. 이 중앙 집중식 패키지는 핵심 규칙에 대한 단일 진실 공급원(Single Source of Truth) 역할을 하며, 개별 패키지는 이를 가져와 자율적으로 특정 규칙을 덮어쓸 수 있습니다 [5].
루트 오케스트레이션 구성(Root Orchestration Config): 핵심 해결책은 모노레포 루트에 eslint.config.mjs를 생성하여 파일 글로브(glob) 패턴을 적절한 린트 구성에 매핑하는 것입니다 [4]. 이 오케스트레이션 파일은 전역적으로 기본 규칙을 적용하면서, 파일 경로에 따라 Next.js 구성이나 라이브러리 구성을 적절히 지휘하여 패키지 경계(package Boundaries)를 존중합니다 [4].
Husky 및 lint-staged와의 통합: 커밋을 수행할 때 Husky가 pre-commit 훅을 트리거하고 lint-staged가 변경된 파일을 식별합니다 [6]. 이때 ESLint는 루트 구성을 기반으로 실행되며, 매핑된 파일 패턴에 따라 각 패키지별 규칙에 맞게 변경된 파일만 린트 검사를 수행합니다 [6].
Turborepo를 통한 캐싱 최적화: turbo.json에 ESLint 설정 패키지를 전역 종속성으로 추가하여 관리합니다 [6]. 이 설정을 통해 Turborepo는 린트 결과를 실행 간에 캐시하며, 중앙 설정이 변경될 때만 전체 패키지의 캐시를 무효화하므로 검사 속도가 획기적으로 향상됩니다 [6, 8].

⚠️ 모순 및 업데이트 (Contradictions & Updates)

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

🔗 지식 연결 (Graph)

Related Topics: ESLint, Prettier, Husky, lint-staged
Projects/Contexts: Turborepo를 활용한 다중 애플리케이션 및 라이브러리 통합 관리
Contradictions/Notes: 분산된 린트 구성 방식은 개별 패키지의 제어력을 높여줄 것 같지만 실제로는 심각한 중복과 유지보수 문제를 야기합니다. 소스는 오히려 중앙 집중식 설정과 루트 오케스트레이션을 결합하는 방식이 종속성 중복을 줄이고(package-lock.json 축소), 전체적인 코드 라인 수를 감소시키면서도 패키지별 자율성을 보장할 수 있다고 강조합니다 [5, 8, 9].

Last updated: 2026-04-18

🤖 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: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)

# TODO

🤔 의사결정 기준 (Decision Criteria)

선택 A를 써야 할 때:

(TODO)

선택 B를 써야 할 때:

(TODO)

기본값:

(TODO)

❌ 안티패턴 (Anti-Patterns)

[안티패턴]: (TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)

6.0 KiB Raw Blame History