42 lines
4.8 KiB
Markdown
42 lines
4.8 KiB
Markdown
---
|
|
id: P-REINFORCE-AUTO-E60BE3
|
|
category: "[[10_Wiki/💡 Topics/Programming & Language]]"
|
|
confidence_score: 0.90
|
|
tags: [auto-reinforced]
|
|
last_reinforced: 2026-04-20
|
|
github_commit: "[P-Reinforce] Continuous Worker - Git Hook을 이용한 CI_CD 자동화 파이프라인"
|
|
---
|
|
|
|
# [[Git Hook을 이용한 CI_CD 자동화 파이프라인]]
|
|
|
|
## 📌 한 줄 통찰 (The Karpathy Summary)
|
|
> Git 훅(Git Hooks)은 소스 코드 버전 관리 시스템인 Git의 특정 작업(commit, push 등) 전후에 자동으로 실행되도록 설정된 쉘 스크립트이다 [1]. 프론트엔드 및 Node.js 생태계에서는 주로 Husky와 lint-staged라는 도구를 활용하여 Git 훅을 설정하고 관리한다 [2], [3]. 이를 통해 코드가 원격 저장소나 CI 파이프라인으로 넘어가기 전인 로컬 단계에서 코드 스타일, 포맷팅(Prettier), 문법적 오류(ESLint) 등을 자동으로 검사하고 수정함으로써 일관된 품질을 강제하는 '최전선 방어선' 역할을 수행한다 [1], [4], [3].
|
|
|
|
## 📖 구조화된 지식 (Synthesized Content)
|
|
* **Git 훅(Git Hooks)의 종류와 한계**
|
|
Git 훅은 `.git/hooks/` 경로에 존재하는 스크립트로 `pre-commit`, `commit-msg`, `pre-push` 등으로 나뉜다 [1], [5]. 특히 `pre-commit`은 커밋이 생성되기 직전에 실행되어 포맷팅이나 린팅을 수행하며, `pre-push`는 푸시 전에 테스트 스위트를 실행하는 등 다소 무거운 작업에 적합하다 [1], [6], [7]. 하지만 로컬의 `.git/hooks/` 디렉토리는 버전 관리가 되지 않아 팀원 간 공유가 어렵고, 개발자가 `--no-verify` 옵션을 통해 훅을 우회할 수 있다는 태생적 한계가 존재한다 [2], [8].
|
|
|
|
* **Husky를 통한 Git 훅 공유 및 관리**
|
|
Husky는 Git의 기본 훅 경로(`core.hooksPath`)를 `.husky/` 디렉토리로 변경하여 훅 스크립트를 Git 버전 관리에 포함시킬 수 있게 해주는 도구이다 [2], [9]. `package.json`의 `prepare` 스크립트와 연동하면, 프로젝트를 클론한 팀원이 `npm install`을 실행할 때 자동으로 Husky 훅이 로컬 환경에 셋업되므로 모든 개발자에게 동일한 검사 규칙을 쉽게 강제할 수 있다 [10], [11], [12].
|
|
|
|
* **lint-staged를 활용한 검사 최적화 및 자동화**
|
|
프로젝트 규모가 커질수록 전체 코드베이스를 대상으로 ESLint나 Prettier를 실행하는 것은 수십 초 이상이 소요되어 개발 생산성을 떨어뜨린다 [2]. `lint-staged`는 현재 Git의 staged 상태인(커밋을 위해 추가된) 파일들에만 글로브(glob) 패턴을 매칭하여 명령어를 실행해 주는 오케스트레이션 도구(router)이다 [13], [14], [15].
|
|
보통 `pre-commit` 훅 내부에서 `lint-staged`를 호출하도록 구성하여, 변경된 파일들만을 대상으로 1~2초 만에 검사 및 자동 수정(`eslint --fix`, `prettier --write` 등)을 마칠 수 있다 [2], [7], [16]. 또한 `lint-staged`는 작업이 성공하면 변경된 내용을 자동으로 다시 스테이징(auto-staging) 처리해 주므로, 설정이 간편하다 [10], [17].
|
|
|
|
* **CI 파이프라인과의 역할 분담 (Hybrid Approach)**
|
|
Husky와 lint-staged 기반의 자동화는 개발자 경험(DX) 향상과 피드백 루프 단축을 위한 로컬 도구이다 [8], [18]. 개발자가 훅을 우회할 가능성이 상존하므로, 로컬 Git 훅이 CI(Continuous Integration)를 완전히 대체할 수는 없다 [19]. 따라서 로컬 훅을 통해 명백한 문제(불량 커밋 등)가 원격지에 올라가는 것을 사전에 방지하고, 최종적인 코드 품질 강제(enforcement boundary)와 전체 테스트 수행 등은 CI 파이프라인의 몫으로 남겨두는 형태가 이상적이다 [19], [18], [20].
|
|
|
|
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
|
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
|
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
|
|
|
|
## 🔗 지식 연결 (Graph)
|
|
- **Related Topics:** [[Husky]], [[lint-staged]], [[ESLint]], [[Prettier]]
|
|
- **Projects/Contexts:** [[자동화된 코드 품질 및 스타일 검사 워크플로우]]
|
|
- **Contradictions/Notes:** lint-staged는 버전 10부터 성공적으로 파일이 수정되면 자동으로 `git add`를 수행하므로, 설정 파일의 커맨드 목록에 수동으로 `git add`를 넣는 것은 중복 작업 및 레이스 컨디션(race condition)을 유발할 수 있어 더 이상 권장되지 않는다 [17], [21]. 또한, 로컬 Git 훅은 우회(`--no-verify`)가 가능하므로 완벽한 정책 집행 경계가 될 수 없으며, CI 서버를 보완하는 성격으로 사용해야 한다 [19], [8], [21].
|
|
|
|
---
|
|
*Last updated: 2026-04-19*
|
|
- Raw Source: [[00_Raw/2026-04-20/Git Hook을 이용한 CI_CD 자동화 파이프라인.md]]
|
|
---
|