커밋 메시지 잘 쓰는 사람이 팀에서 인정받는 이유 (feat. 실전 컨벤션)

개발팀에서 일하다 보면 이런 말, 한 번쯤 들어봤을 것임(난 5년차임).

“커밋 좀 깔끔하게 남겨줘요…”
“이거 누가 언제 왜 고친 건지 로그 보고는 도저히 모르겠음;;”

솔직히 코드보다 커밋 메시지 때문에 빡치는 순간이 더 많다.
그래서 커밋 메시지를 잘 쓰는 사람 = 협업 잘하는 사람 으로 자동 인정된다. 생각보다 강력한 신뢰 포인트다.

또 물어보면 나도 기억안나거나 빡침 바빠죽겠는데

 

---

ㅋ 커밋 메시지가 깔끔하면 생기는 실무 이점

깔끔한 커밋개판 커밋

feat: 로그인 API 토큰 검증 추가	수정, 테스트, ㅁㄴㅇㄹ
PR 리뷰 속도 ↑	“이거 뭐임?” 묻느라 시간 낭비
나중에 버그 추적 쉬움	blame 찍으면 화남
신뢰도 상승	"이 사람 코드 감각 없나?"

커밋 메시지는 코드를 설명하는 최소한의 문서라고 봐도 된다.

---

실무에서 가장 많이 쓰는 컨벤션: Angular 스타일

<type>: <message> 예) feat: 유저 로그인 토큰 검증 로직 추가

- 대표 type 종류

type의미예시

feat	기능 추가	feat: 게시글 검색 API 추가
fix	버그 수정	fix: 비로그인 유저 검색 시 500 에러 해결
docs	문서 수정	docs: README에 실행 방법 추가
refactor	기능 변화 없는 코드 정리	refactor: 중복된 유저 필터 로직 분리
chore	빌드/패키지/환경 설정	chore: eslint 룰 적용
test	테스트 코드 관련	test: JWT 유효성 체크 테스트 추가

👉 규칙: git commit -m "type: 명확한 설명"
너무 고급 컨벤션 말고 한 줄 규칙만 지켜도 팀 퀄리티가 확 달라지긴 함(습관화 하자).

---

- 나쁜 커밋 vs 🎯 좋은 커밋 비교

나쁜 예시좋은 예시

 

수정함	fix: 검색 API null 입력 시 에러 처리
테스트	test: 댓글 생성 API 유효성 테스트 추가
readme	docs: 환경 변수 설정법 추가
ㅁㄴㅇㄹ	refactor: 유저 정보 필터링 로직 분리

한 줄만 제대로 써도 커밋 히스토리 퀄리티가 확 변한다.

---

- 팀에서 컨벤션 정할 때 팁

• type 최소 5개만 합의 (feat, fix, docs, chore, refactor)
• 영어 강제 NO. 한국어 메시지도 가능, 중요한 건 의도 명확하게
• feat: ~~~ 추가, fix: ~~~ 수정 같은 패턴 통일

"자유롭게 쓰세요"라고 하면 100% 망함.
“이 다섯 개만 써서 메시지 남겨줘요” → 이러면 팀이 정돈됨.

---

- 실무에서 쓰기 좋은 커밋 템플릿 (복붙용)

 

# Summary(한 줄 요약) type: 변경 내용 요약 # Example feat: 소셜 로그인 콜백 시 토큰 검증 추가

 

욕먹지 말고 깔끔한 습관 들입시다 

+ 주석도 깔꼼하게!!!