# [[Frontend Engineering Governance]]

## 📌 Brief Summary
Frontend Engineering Governance는 일관된 네이밍 규칙, 프로젝트 표준, 자동화된 린팅 도구 및 엄격한 Git 워크플로우를 통해 프론트엔드 프로젝트의 코드 품질과 협업 효율성을 유지하는 체계적인 접근 방식입니다 [1, 2]. 수동적인 코드 리뷰에 의존하는 대신 ESLint, Prettier, Husky와 같은 도구를 활용하여 아키텍처 경계를 보호하고 코드 품질 검증을 자동화하는 데 중점을 둡니다 [3]. 이를 통해 잠재적인 버그와 아키텍처의 붕괴를 예방하고 예측 가능하며 확장 가능한 소프트웨어 개발 환경을 보장합니다 [4, 5].

## 📖 Core Content
*   **네이밍 규칙 및 표준화 (Naming Conventions):** 대소문자를 구분하는 환경(예: Linux 기반 운영 서버)에서 빌드 실패를 방지하기 위해 파일 및 폴더 이름은 `kebab-case`를 사용합니다 [6]. 리액트 컴포넌트는 `PascalCase`, 사용자 정의 훅(Custom Hooks)과 일반 변수 및 함수는 `camelCase`, 상수는 `UPPER_SNAKE_CASE`로 표준화하여 가독성을 높이고 파일의 목적을 명확히 합니다 [3, 7-9].
*   **자동화된 툴 기반 거버넌스 (Governance through Tooling):** 수동적인 코드 표준 강제는 비효율적이므로, 현대적인 프로젝트는 ESLint와 Prettier를 활용하여 위반 사항을 자동으로 찾아 수정합니다 [3]. 특히 ESLint 규칙을 구성하여 특정 임포트 패턴(예: 한 기능이 다른 기능의 내부를 직접 임포트하는 것)을 금지함으로써 Feature-Sliced Design(FSD)과 같은 아키텍처의 계층적 경계를 엄격하게 강제할 수 있습니다 [3].
*   **Git 훅(Git Hooks)을 통한 사전 방지:** Husky와 같은 도구를 도입하여 코드가 리포지토리에 커밋되기 전에 린팅, 코드 포맷팅, 타입 검사를 필수적으로 실행합니다 [3]. 이를 통해 품질이 낮은 코드나 규칙을 위반한 코드가 코드베이스에 들어오는 것을 원천 차단합니다 [3].
*   **협업 워크플로우 및 Git 거버넌스 (Git Governance):** 개발자는 메인 브랜치에 직접 커밋하지 않고 짧은 수명의 기능 브랜치(Feature Branch)를 사용하며, 동료의 코드 리뷰와 CI/CD 검사를 통과한 후에만 병합(Merge)합니다 [4]. 커밋 메시지는 'Conventional Commits' 규격(`feat:`, `fix:`, `docs:`, `refactor:`, `chore:`)을 준수하여 가독성을 높이고 릴리스 노트 자동화를 돕습니다 [10]. 또한, 추적성을 높이기 위해 브랜치 이름과 커밋 메시지에 티켓 ID(예: `PROJ-123`)를 포함합니다 [11, 12].
*   **시각적 리뷰 및 PR 품질 관리 (Visual Reviews):** 풀 리퀘스트(PR)는 단일 작업에 초점을 맞춰 작게 유지해야 합니다 [10]. Storybook 및 Chromatic과 같은 도구를 CI 파이프라인에 통합하여, PR이 열릴 때마다 시각적 회귀 테스트(Visual regression testing)를 자동으로 수행하고 의도치 않은 UI 변경이 없는지 검증합니다 [13-15].

## ⚖️ Trade-offs & Caveats
강력한 린팅 규칙 및 자동화된 거버넌스는 프로젝트 초기에 도구 설정(ESLint, Husky, CI 연동 등)에 많은 시간 투자를 요구하며, 개발자들에게 다소 가파른 러닝 커브를 줄 수 있습니다 [3, 16]. 엄격한 규칙으로 인해 단순한 기능 구현이나 프로토타이핑 시에도 부가적인 린트 에러 수정 및 아키텍처 규칙 준수가 강제되어 초기 개발 속도를 늦출 수 있습니다 [3]. 또한, 작은 규모의 팀이나 단순한 프로젝트의 경우 지나치게 복잡한 Git Flow나 과도한 시각적 회귀 테스트 설정은 불필요한 관리 오버헤드(Overhead)를 발생시킬 수 있으므로, 팀의 성숙도와 프로젝트 규모에 맞는 적절한 수준의 규칙(예: 단순한 Feature-Branch 워크플로우)을 채택하는 것이 중요합니다 [17, 18].

## 🔗 Knowledge Connections

### Related Concepts

#### [관계 유형 A (아키텍처/기반 기술)]
*   [[Feature-Sliced Design (FSD)]]
    *   연결 이유: 프론트엔드 코드의 스코프와 책임을 명확히 구분하고 계층 간의 단방향 의존성을 거버넌스 규칙으로 강제해야 하는 아키텍처이기 때문입니다 [19, 20].
    *   이 개념을 통해 더 깊게 이해할 수 있는 부분: ESLint 규칙을 통해 모듈 간 임포트를 어떻게 제한하여 시스템의 구조적 붕괴를 막을 수 있는지에 대한 실질적 이해 [3].
*   [[Conventional Commits]]
    *   연결 이유: 명확한 Git 거버넌스를 위해 필수적으로 채택되는 커밋 메시지 작성 표준이기 때문입니다 [10].
    *   이 개념을 통해 더 깊게 이해할 수 있는 부분: 팀 전체의 커밋 히스토리를 깔끔하게 유지하고, 릴리스 자동화 파이프라인을 구축하는 방법 [10, 21].

#### [관계 유형 B (구현/활용 도구)]
*   [[ESLint and Prettier]]
    *   연결 이유: 수동 리뷰의 비효율성을 제거하고 코딩 표준과 아키텍처 규칙을 자동으로 강제하는 거버넌스의 핵심 도구입니다 [3].
    *   이 개념을 통해 더 깊게 이해할 수 있는 부분: 프로젝트 내 네이밍 규칙 일관성 유지 및 아키텍처 경계 위반 방지를 코드로 자동화하는 방법 [3].
*   [[Husky]]
    *   연결 이유: 개발자가 코드를 커밋하기 전(Pre-commit)에 거버넌스 규칙(린팅, 포맷팅)을 무조건적으로 통과하도록 훅(Hook)을 걸어주는 도구이기 때문입니다 [3].
    *   이 개념을 통해 더 깊게 이해할 수 있는 부분: 잘못된 코드가 원격 리포지토리로 푸시되는 것을 원천적으로 차단하는 프론트엔드 품질 게이트웨이 구성 [3].
*   [[Visual Regression Testing (Chromatic)]]
    *   연결 이유: 컴포넌트 기반 프론트엔드에서 코드가 변경될 때 UI가 깨지지 않았는지 풀 리퀘스트(PR) 단계에서 검증하는 시각적 품질 거버넌스 수단입니다 [13, 15].
    *   이 개념을 통해 더 깊게 이해할 수 있는 부분: Storybook과 연동하여 코드 리뷰 과정에서 인간이 놓치기 쉬운 픽셀 단위의 시각적 변경 사항을 자동으로 감지하는 원리 [22, 23].

### Deeper Research Questions
*   ESLint를 활용해 Feature-Sliced Design의 단방향 의존성(Unidirectional dependencies) 규칙을 구체적으로 어떻게 설정하고 강제할 수 있는가?
*   Husky와 같은 Git 훅 도구를 도입했을 때 개발자 경험(Developer Experience)을 저해하지 않으면서도 필수 검사를 실행하는 최적의 속도 최적화 방법은 무엇인가?
*   소규모 3인 팀에서 대규모 엔터프라이즈 팀으로 성장함에 따라 Git 브랜칭 전략과 리뷰 거버넌스 규칙은 단계별로 어떻게 진화해야 하는가?
*   단일 리포지토리에 방대한 코드가 존재하는 경우(Monorepo), 도메인별 거버넌스 규칙을 어떻게 분리하여 적용할 수 있는가?
*   기존의 레거시 프로젝트(거버넌스가 없는 상태)에 자동화된 린팅, 네이밍 규칙, 티켓 ID 시스템을 업무 중단 없이 점진적으로 도입하기 위한 마이그레이션 전략은 무엇인가?

### Practical Application Contexts
*   **Implementation:** 프로젝트 초기 세팅 시 Prettier, ESLint, Husky를 설치하여 코드 스타일과 네이밍 규칙을 정의하고, 개발자의 로컬 환경에서 자동으로 코드가 포맷팅 및 검증되도록 내재화합니다 [3].
*   **System Design:** FSD와 같은 아키텍처를 설계할 때, 하위 계층이 상위 계층을 임포트하지 못하도록 시스템적인 린트(Lint) 룰을 함께 설계하여 아키텍처의 의도가 무너지지 않게 보호합니다 [3].
*   **Operation / Maintenance:** PR(Pull Request) 템플릿과 Conventional Commits을 의무화하고, 브랜치명에 이슈 티켓 번호(예: `feature/PROJ-123-user-auth`)를 삽입하게 하여 유지보수 시 변경 이력과 기획 의도를 쉽게 추적할 수 있도록 운영합니다 [10, 24].
*   **Learning Path:** React 문법과 컴포넌트 생태계를 익힌 후, 협업을 위한 클린 코드 원칙과 Git 전략을 학습하고, 이를 실제 프로젝트에 강제하기 위한 환경 구축(ESLint 설정 등)으로 나아가는 과정에 필수적입니다 [3, 25].
*   **My Project Relevance:** 현재 진행 중이거나 앞으로 도입될 팀 프로젝트에서 개발자 간 코드 스타일 충돌과 불명확한 커밋 로그로 인한 문제를 방지하기 위해 직접 Git 훅을 설정하고 PR 규칙을 도입할 수 있습니다 [3, 26].

### Adjacent Topics
*   [[Clean Code Principles (SOLID, DRY, KISS, YAGNI)]]
    *   확장 방향: 거버넌스가 규칙의 "도구적 강제"라면, 클린 코드는 개발자가 그 구조 안에서 컴포넌트를 분리하고 함수를 작성할 때 준수해야 할 근본적인 사고방식과 철학을 이해하도록 확장됩니다.
*   [[CI/CD Pipelines]]
    *   확장 방향: 로컬 환경의 Git 훅을 넘어 클라우드 환경(GitHub Actions 등)에서 풀 리퀘스트를 자동으로 검증, 빌드, 시각적 테스트 및 배포하는 지속적 통합/배포 파이프라인 개념으로 이해를 넓힙니다.

---
*Last updated: 2026-04-30*