컨벤셔널 커밋, 진짜 중요한 건 타입이 아니라 스코프라는 반론

컨벤셔널 커밋의 문제는 “구조화”가 아니라 “뭘 앞에 두느냐”임

• 글쓴이는 컨벤셔널 커밋이 커밋 메시지에서 가장 덜 중요한 정보를 맨 앞에 둔다고 봄

  • 컨벤셔널 커밋 형식은 대략 타입(스코프): 설명 구조임
  • 여기서 타입은 fix, feat, chore, docs, refactor 같은 변경 종류고, 스코프는 compiler, auth, core 같은 변경 영역임
  • 글쓴이 주장은 간단함. 개발자가 커밋 로그를 볼 때 진짜 찾는 건 “어떤 타입의 변경인가”가 아니라 “어디가 바뀌었나”라는 것

• 스코프가 선택 사항인 것도 강하게 비판함

  • 기여자는 최근 코드베이스에서 자신이 작업하는 영역에 무슨 변화가 있었는지 알고 싶어 함
  • 디버거는 버그가 나타난 컴포넌트를 건드린 커밋을 찾고 싶어 함
  • 장애 대응자는 장애 시점 근처에 auth 같은 민감한 영역을 건드린 변경이 있는지 빠르게 훑고 싶어 함
  • 그런데 컨벤셔널 커밋은 이런 스코프를 선택 사항으로 두고, 타입을 필수처럼 앞세운다는 게 문제라는 얘기임

• 타입은 생각보다 중복 정보가 많고, 때로는 억지 분류가 됨

  • 예를 들어 “네임스페이스가 붙은 에스브이지 style 요소가 제거되지 않게 막음” 같은 설명만 봐도 버그 수정이라는 걸 알 수 있음
  • 반대로 어떤 커밋은 버그 수정이면서 리팩터링이고, 동시에 새 기능 지원일 수도 있음
  • 이런 상황에서 하나의 타입을 고르라고 하면 정보가 명확해지는 게 아니라 오히려 현실을 납작하게 만듦

자동화 장점도 생각보다 구멍이 많다는 주장

• 변경 로그 자동 생성은 가장 큰 약속이지만, 글쓴이는 이걸 별로 좋은 아이디어로 보지 않음

  • 변경 로그는 사용자용 문서라서 버전 사이에 기능적으로 뭐가 달라졌는지를 설명해야 함
  • 커밋 로그는 개발자용 기록이라서 코드베이스가 어떤 과정을 거쳐 바뀌었는지를 보여줘야 함
  • 한 기능이 여러 커밋으로 만들어지는 건 개발자에게는 의미 있지만, 사용자는 “그 기능이 생겼다”만 알면 됨

• 시맨틱 버전 자동 결정도 실제 이력에서는 자주 삐끗할 수 있음

  • 깨지는 변경을 넣었다가 되돌리면 도구는 여전히 메이저 버전 증가를 판단할 수 있음
  • 반대로 당시에는 몰랐지만 나중에 보니 호환성을 깨는 변경이었다면 마이너나 패치로 잘못 나갈 수 있음
  • 어떤 변경은 뒤의 커밋과 합쳐졌을 때 더 이상 깨지는 변경이 아닐 수도 있음

• 빌드나 배포 트리거를 커밋 타입에 거는 건 더 위험하다고 봄

  • docs: 오타 수정이라고 써놓고 실제로 인증 서브시스템에 취약점을 넣는 악성 커밋을 상상해보라는 것
  • 이런 건 코드 리뷰에서 잡아야겠지만, 자동화가 타입 문자열만 믿으면 사람이 놓쳤을 때 방어선이 없음
  • 글쓴이는 변경 파일을 git diff로 보고 빌드나 검사를 정하는 게 더 낫다고 주장함

대안은 프로젝트에 맞는 스코프 접두 커밋

• 글쓴이는 리눅스, 프리비에스디, 깃, 고, 닉스오에스 같은 오래 살아남은 프로젝트들을 예로 듦

  • 이 프로젝트들은 공통적으로 프로젝트 맥락에 맞는 스코프를 커밋 앞에 둠
  • 리눅스 커널이면 서브시스템, 고 프로젝트면 패키지 경로, 마이크로서비스 구조면 서비스명이 자연스러운 스코프가 됨
  • 즉 “모두가 같은 타입 목록을 쓰자”가 아니라 “우리 프로젝트에서 가장 잘 검색되는 변경 영역을 앞에 두자”는 접근임

• 회사 환경에서는 컨벤셔널 커밋이 더 이상해질 수 있다는 지적도 있음

  • 감사나 변경 관리 때문에 모든 커밋에 티켓 번호를 넣어야 하는 팀이 많음
  • 그러면 스코프 자리에 티켓 번호가 들어가고, 유일하게 쓸모 있던 메타데이터가 검색 가치 낮은 숫자로 대체됨
  • 결과적으로 타입은 앞에 남고, 정작 변경 영역은 사라지는 괴상한 로그가 만들어짐

• 마지막으로 글쓴이는 컨벤셔널 커밋이 “브랜딩 전쟁”에서 이겼을 뿐이라고 봄

  • 실제로는 스코프 중심 커밋이 더 오래되고 큰 프로젝트에서 잘 쓰였는데, 이름 붙이고 표준화한 컨벤셔널 커밋이 더 널리 퍼졌다는 것
  • 특히 AI가 커밋 메시지를 만들 때 컨벤셔널 커밋을 기본값처럼 쓰면서 이 패턴이 더 번지고 있다는 비판도 덧붙임

---

기술 맥락

• 이 글에서 말하는 기술적 선택은 커밋 메시지를 어떤 기준으로 구조화할지예요. 컨벤셔널 커밋은 변경의 종류를 앞에 두고, 스코프 커밋은 변경된 영역을 앞에 둬요.

• 왜 이게 중요하냐면 커밋 로그는 예쁜 기록물이 아니라 디버깅 도구에 가깝기 때문이에요. 장애가 났을 때 fix 커밋만 볼 수는 없어요. 버그는 feat, refactor, docs라고 적힌 커밋에서도 얼마든지 들어갈 수 있거든요.

• 스코프 중심 방식은 검색과 추적에 강해요. 인증 장애면 auth 관련 커밋을 보고, 컴파일러 버그면 compiler 관련 커밋을 보면 돼요. 프로젝트 구조가 커밋 제목 앞에 드러나니까 로그가 코드베이스 지도처럼 동작하는 셈이에요.

• 반대로 컨벤셔널 커밋의 자동 변경 로그와 버전 자동화는 팀에 따라 여전히 쓸모가 있을 수 있어요. 다만 이 글이 짚는 것처럼 그 자동화가 실제 변경의 의미를 대신 판단해주지는 못해요. 결국 릴리스 노트와 커밋 로그는 독자와 목적이 다르다는 걸 분리해서 봐야 해요.