[G1-Sync] Manual knowledge update

10_Wiki/Topics/Programming & Language/팀 단위 코드 품질 및 컨벤션 유지.md

@@ -1,5 +1,5 @@
 ---
-id: P-REINFORCE-AUTO-9B19C8
+id: [[P-Reinforce]]-AUTO-9B19C8
 category: "10_Wiki/💡 Topics/Programming & Language"
 confidence_score: 0.90
 tags: [auto-reinforced]
@@ -10,14 +10,14 @@ github_commit: "[P-Reinforce] Continuous Worker - 팀 단위 코드 품질 및
 # [[팀 단위 코드 품질 및 컨벤션 유지]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
-> 팀 단위 코드 품질 및 컨벤션 유지는 다수의 개발자가 협업하는 환경에서 일관된 코드 스타일을 적용하고 결함을 사전에 방지하여 소프트웨어의 전반적인 품질을 향상시키는 과정입니다. 이를 위해 ESLint와 Prettier 같은 정적 분석 및 포매팅 도구를 활용하며, Husky와 lint-staged를 통해 Git 훅(Hook) 단계에서 규칙 준수를 강제합니다. 더불어 기계적인 검사와 사람의 아키텍처 판단이 결합된 하이브리드 코드 리뷰와 명확한 거버넌스 정책을 통해 코드베이스의 건전성을 지속적으로 개선합니다.
+> 팀 단위 코드 품질 및 컨벤션 유지는 다수의 개발자가 협업하는 환경에서 일관된 코드 스타일을 적용하고 결함을 사전에 방지하여 소프트웨어의 전반적인 품질을 향상시키는 과정입니다. 이를 위해 [[ESLint]]와 [[Prettier]] 같은 정적 분석 및 포매팅 도구를 활용하며, [[Husky]]와 [[lint-staged]]를 통해 Git 훅(Hook) 단계에서 규칙 준수를 강제합니다. 더불어 기계적인 검사와 사람의 아키텍처 판단이 결합된 하이브리드 코드 리뷰와 명확한 거버넌스 정책을 통해 코드베이스의 건전성을 지속적으로 개선합니다.
 
 ## 📖 구조화된 지식 (Synthesized Content)
 * **정적 분석 및 포매팅 도구 활용 (ESLint & Prettier)**
-  팀원 간의 코딩 스타일 차이를 줄이고 문법적 오류를 방지하기 위해 정적 분석 도구인 ESLint(Linter)와 스타일 교정 도구인 Prettier(Formatter)를 함께 사용합니다 [1-4]. 두 도구 사용 시 포매팅 역할이 겹쳐 규칙 충돌이 발생할 수 있으므로, `eslint-config-prettier` 패키지를 사용하여 Prettier와 충돌하는 ESLint의 포매팅 규칙을 비활성화하는 방식이 가장 권장됩니다 [5-9].
+  팀원 간의 코딩 스타일 차이를 줄이고 문법적 오류를 방지하기 위해 정적 분석 도구인 ESLint(Linter)와 스타일 교정 도구인 Prettier(Formatter)를 함께 사용합니다 [1-4]. 두 도구 사용 시 포매팅 역할이 겹쳐 규칙 충돌이 발생할 수 있으므로, `[[eslint-config-prettier]]` 패키지를 사용하여 Prettier와 충돌하는 ESLint의 포매팅 규칙을 비활성화하는 방식이 가장 권장됩니다 [5-9].
 
-* **모노레포(Monorepo) 환경의 설정 중앙화**
-  Turborepo 등 여러 패키지가 존재하는 대규모 모노레포 환경에서는 각 패키지마다 설정 파일이 중복되는 것을 막기 위해 중앙 집중식 설정 패키지(예: `@repo/eslint-config`)를 구성합니다 [10-13]. 이를 통해 팀 전체의 린팅 규칙을 단일 소스(Single Source of Truth)로 관리하고, 개별 패키지에서는 이를 확장(extend)하여 패키지별 자율성을 유지하면서 일관성을 지킬 수 있습니다 [14, 15].
+* **모노레포([[Monorepo]]) 환경의 설정 중앙화**
+  [[Turborepo]] 등 여러 패키지가 존재하는 대규모 모노레포 환경에서는 각 패키지마다 설정 파일이 중복되는 것을 막기 위해 중앙 집중식 설정 패키지(예: `@repo/eslint-config`)를 구성합니다 [10-13]. 이를 통해 팀 전체의 린팅 규칙을 단일 소스([[Single Source of Truth]])로 관리하고, 개별 패키지에서는 이를 확장(extend)하여 패키지별 자율성을 유지하면서 일관성을 지킬 수 있습니다 [14, 15].
 
 * **Git 훅(Hook)을 통한 컨벤션 자동 강제 (Husky & lint-staged)**
   작성된 코드가 원격 저장소로 푸시되기 전에 규칙 위반 코드가 커밋되는 것을 막기 위해 Husky와 lint-staged를 활용합니다 [16-22]. `pre-commit` 단계에서 전체 코드가 아닌 변경된(staged) 파일에 대해서만 ESLint 및 Prettier를 실행함으로써 검사 속도를 높이고, 규칙에 어긋난 커밋을 자동으로 차단하여 생산성 저하 없이 코드 품질을 강제할 수 있습니다 [21-26].
@@ -33,7 +33,7 @@ github_commit: "[P-Reinforce] Continuous Worker - 팀 단위 코드 품질 및
 - **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[ESLint]], [[Prettier]], [[Husky]], [[lint-staged]], [[코드 리뷰(Code Review)]], [[정적 애플리케이션 보안 테스트(SAST)]]
+- **Related Topics:** [[ESLint]], [[Prettier]], [[Husky]], [[lint-staged]], [[코드 리뷰([[Code Review]])]], [[정적 애플리케이션 보안 테스트([[SAST]])]]
 - **Projects/Contexts:** [[모노레포(Monorepo) 설정 중앙화]], CI/CD 파이프라인 자동화, [[AI 거버넌스 정책(AI Usage Policy)]]
 - **Contradictions/Notes:** 소스에 따르면 ESLint와 Prettier는 함께 사용할 때 포매팅 규칙에서 충돌이 발생할 수 있으며, 이를 해결하기 위해 `eslint-config-prettier`를 사용하여 ESLint의 관련 기능을 끄는 것이 공식 권장 사항입니다 [5, 9]. 또한, 자동화된 코드 리뷰 도구가 매우 빠르고 일관적이지만 비즈니스 로직의 의도나 아키텍처의 문맥을 이해할 수는 없으므로(Context Blindness), 자동화가 수동 리뷰를 완전히 대체해서는 안 되며 상호 보완적으로 사용해야 한다고 강조합니다 [47, 48].