# [[Team Collaboration and Code Governance]]

## 📌 Brief Summary
팀 협업 및 코드 거버넌스(Team Collaboration and Code Governance)는 프론트엔드 개발팀이 일관성 있는 코드를 작성하고 충돌 없이 효율적으로 협업하기 위한 규칙과 자동화 도구의 활용을 의미합니다 [1, 2]. 주요 요소로는 일관된 파일 명명 규칙, ESLint와 Prettier 등을 활용한 자동화된 린팅, 그리고 티켓 ID와 Pull Request(PR) 리뷰를 포함하는 효율적인 Git 브랜칭 전략이 있습니다 [3-5]. 이러한 표준화된 구조와 거버넌스는 대규모 프로젝트에서 인지적 부하를 줄이고, 코드 품질을 유지하며, 팀이 안전하게 확장할 수 있는 필수적인 기반을 제공합니다 [6-8].

## 📖 Core Content
*   **자동화된 코드 거버넌스와 린팅 (Automated Governance):** 현대의 프론트엔드 프로젝트에서는 코딩 표준을 수동으로 강제하는 대신 ESLint와 Prettier를 사용하여 위반 사항을 자동으로 감지하고 수정합니다 [3]. ESLint 규칙을 통해 특정 기능이 다른 기능으로부터 잘못된 임포트를 하는 것을 막아 아키텍처 경계를 강제할 수 있으며, Husky를 활용해 코드를 커밋하기 전에 린팅, 포맷팅, 타입 체킹을 실행하는 Git 훅(Git hooks)을 설정함으로써 고품질의 코드만 저장소에 병합되도록 보장합니다 [3, 9].
*   **표준화된 명명 규칙 (Naming Conventions):** 일관된 명명 규칙은 협업 시 혼란을 줄이고 코드베이스 탐색을 돕습니다 [10]. 운영체제 간(Windows/macOS 대 Linux) 대소문자 구분 문제로 인한 CI/CD 파이프라인 빌드 실패를 방지하기 위해 파일 및 폴더 이름은 `kebab-case`를 사용하고, React 컴포넌트 이름은 `PascalCase`를 사용하는 것이 강력히 권장됩니다 [11-13]. 상수나 Enum은 `UPPER_SNAKE_CASE`를 사용합니다 [14].
*   **소규모 팀을 위한 Git 브랜치 전략 (Git Workflow for Small Teams):** 2~5명의 소규모 팀에게는 무거운 Git Flow 대신 '보호된 main 브랜치가 있는 단순한 기능 브랜치 워크플로우(Feature-Branch Workflow)'가 가장 적합합니다 [15, 16].
    *   **브랜치 생성 및 명명:** 항상 안정적이고 배포 가능한 상태인 `main` 브랜치에서 분기하여 작업마다 수명이 짧은 기능 브랜치를 생성합니다 [17, 18]. 추적성을 높이기 위해 `feature/PROJ-123-user-auth`와 같이 작업 유형, 티켓 ID, 짧은 설명을 포함하는 명확한 브랜치 이름 규칙을 적용합니다 [19-21].
    *   **커밋 메시지 (Conventional Commits):** 코드는 의미 단위로 작게 자주 커밋해야 하며 [22, 23], `feat:`, `fix:`, `chore:`, `refactor:` 등의 접두사를 사용하는 관례적 커밋을 통해 변경 사항의 내용과 이유를 명확히 작성해야 합니다 [24, 25].
    *   **풀 리퀘스트(PR)와 코드 리뷰:** 변경 사항을 머지하기 위해서는 반드시 PR을 열고 최소 1명 이상의 팀원에게 리뷰를 받아야 하며, CI 테스트 통과를 필수로 요구합니다 [22, 23, 26, 27]. PR은 리뷰어가 빠르고 꼼꼼하게 검토할 수 있도록 작게 유지하는 것이 중요합니다 [24, 26]. 
    *   **병합 및 정리:** 머지 시에는 '스쿼시 머지(Squash Merge)'를 사용하여 main 브랜치의 히스토리를 깔끔하게 유지하고, 작업이 끝난 브랜치는 자동으로 삭제하도록 설정합니다 [23, 26, 28].
*   **시각적 리뷰 (Visual Reviews):** Storybook과 Chromatic 같은 도구를 연동하여 UI 변경 사항을 자동으로 캡처하고 베이스라인과 비교함으로써, 의도치 않은 UI 회귀(Regression)가 운영 환경에 배포되는 것을 방지하는 시각적 PR 리뷰 프로세스를 구축하는 것이 권장됩니다 [29-31].
*   **폴더 구조를 통한 협업 향상:** 팀의 모든 개발자가 기능 기반(Feature-based)과 같은 표준화된 폴더 구조를 따르면, 커뮤니케이션 비용이 감소하고 신규 개발자의 온보딩이 매우 빨라집니다 [8]. 또한 파일 작업 시 파일들이 분리되어 있어 개발자 간의 충돌을 최소화할 수 있습니다 [8].

## 🔗 Knowledge Connections
- **Related Topics:** [[Frontend Folder Structure]], [[Git Branching Strategies]], [[Clean Code Principles]], [[Feature-Sliced Design]]
- **Projects/Contexts:** [[React Project Setup]], [[Small Team Workflow]], [[Continuous Integration/Continuous Deployment (CI/CD)]]
- **Contradictions/Notes:** 소규모 팀(2~5명)의 경우 무거운 'Git Flow' 전략은 오버헤드가 커서 권장되지 않으며, 트렁크 기반(Trunk-based) 또는 짧은 수명의 기능 브랜치(Feature-branch) 워크플로우가 충돌을 방지하면서도 협업 효율성을 높이는 가장 실용적인 방법이라고 주장합니다 [15, 16, 32].

---
*Last updated: 2026-04-26*