클로드 코드로 코드를 고친 뒤 가장 귀찮은 일이 커밋 메시지 쓰기였습니다. 무엇을 바꿨는지 다시 훑어보고 요약하는 일인데, 이건 클로드가 아주 잘합니다. 다만 깃은 협업의 기록이라, 잘못 다루면 팀원에게 피해가 갑니다. 그래서 안전장치를 갖춘 워크플로가 필요합니다.
기본 원칙 3가지
- 작업 전에 브랜치를 만든다 — 기본 브랜치(main)에서 직접 작업하지 않습니다.
- 커밋과 푸시는 내가 요청할 때만 — 클로드가 알아서 올리지 않게 합니다.
- 기록을 지우는 명령은 막는다 — 강제 푸시, 하드 리셋 등.
이 원칙을 CLAUDE.md에 적어 둡니다.
## Git 규칙
- 작업 시작 전 기능 브랜치를 만든다 (main에서 직접 커밋 금지)
- 커밋·푸시는 사용자가 요청할 때만 한다
- force push, reset --hard, 브랜치 삭제는 하지 않는다
- 커밋 메시지: 한국어, 첫 줄 50자 이내, 무엇을 왜 바꿨는지
워크플로: 작업부터 PR까지
1. 브랜치 만들기
작성자 박스 기능을 추가할 거야. feature/author-box 브랜치를 만들어 줘.
2. 작업 진행
평소처럼 기능을 구현합니다. 큰 작업이면 플랜 모드로 계획부터 검토합니다.
3. 변경 내용 검토
커밋 전에 꼭 변경 사항을 확인합니다.
지금까지 변경한 파일 목록과 각 파일의 변경 요약을 보여 줘.
의도하지 않은 변경이 있으면 표시해 줘.
여기서 디버깅용으로 넣었던 출력문, 임시 파일, 관련 없는 포맷 변경 등이 발견되곤 합니다.
4. 커밋 메시지 작성과 커밋
변경 내용을 커밋해 줘. 커밋 메시지는 CLAUDE.md 규칙대로.
클로드가 변경 내용을 분석해 메시지를 작성합니다. 예를 들면 이런 식입니다.
글 하단에 작성자 소개 박스 추가
- 사이트 로컬 테마에 post.html 오버라이드 추가
- 작성자 이름은 front matter의 author 값을 사용
- 공용 프레임워크 템플릿은 수정하지 않음
무엇을 했는지보다 왜 그렇게 했는지가 들어간 메시지가 나중에 기록을 볼 때 훨씬 유용합니다.
5. PR 설명 작성
깃허브를 쓴다면 PR 설명도 맡길 수 있습니다.
이 브랜치의 PR 설명을 써 줘.
- 변경 배경
- 주요 변경 사항
- 테스트 방법
- 리뷰어가 특히 봐 줬으면 하는 부분
GitHub CLI(gh)가 설치되어 있으면 클로드가 PR 생성까지 도울 수 있습니다. 이때도 생성 전에 내용을 확인하는 단계를 거칩니다.
위험한 명령 막기
CLAUDE.md 규칙만으로는 100% 보장되지 않으므로, 권한 설정으로 한 번 더 막아 둡니다. /permissions에서 차단 목록에 추가하거나 설정 파일에 적습니다.
{
"permissions": {
"deny": [
"Bash(git push --force:*)",
"Bash(git reset --hard:*)"
]
}
}
권한 규칙의 정확한 문법은 버전에 따라 다를 수 있으니 공식 문서를 확인하세요. 더 강하게 막고 싶다면 훅으로 해당 명령을 차단할 수도 있습니다.
커밋 단위 요령
- 기능 하나에 커밋 하나: 여러 기능을 한 커밋에 섞지 않습니다.
- 리팩터링과 기능 변경 분리: "포맷 정리" 커밋과 "기능 추가" 커밋을 나누면 리뷰가 쉬워집니다.
- 클로드에게 나눠 달라고 요청: "변경 내용을 성격별로 나눠 여러 커밋으로 만들어 줘"라고 하면 파일을 묶어 나눠 커밋합니다.
푸시 버튼은 사람이 누릅니다
클로드 코드에게 깃 작업을 맡기면서 커밋 메시지의 질이 오히려 좋아졌습니다. 예전에는 귀찮아서 "수정", "버그 픽스" 같은 메시지를 남기곤 했는데, 지금은 변경 이유까지 담긴 메시지가 남습니다. 다만 푸시 버튼은 항상 내가 누른다는 원칙은 지킵니다. 원격 저장소에 올라간 기록은 팀 전체의 것이니까요.
📌 3줄 요약
- 작업 전 브랜치 생성, 요청 시에만 커밋·푸시, 기록 삭제 명령 금지를 CLAUDE.md에 적으세요.
- 커밋 전에 변경 목록과 의도하지 않은 변경을 반드시 확인합니다.
- 권한 설정이나 훅으로 위험한 깃 명령을 이중으로 막아 둡니다.
