컨벤셔널 커밋보다 중요한 것은 범위다, 커밋 메시지 규칙을 다시 보자는 주장

왜 타입보다 범위가 먼저인가

기사의 문제 제기는 단순하다. 개발자가 커밋 로그를 읽을 때 가장 먼저 알고 싶은 것은 이 변경이 기능 추가인지 버그 수정인지보다, 어떤 모듈과 하위 시스템을 건드렸는지라는 것이다. 컨벤셔널 커밋은 feat, fix, chore 같은 유형을 제목 맨 앞에 두고 scope를 선택 사항으로 남겨 둔다. 작성자는 이 구조가 실제 디버깅과 장애 대응에 필요한 정보를 뒤로 미룬다고 본다. 버그는 어떤 유형의 커밋에서도 생길 수 있으므로 type만으로는 원인 범위를 좁히기 어렵다는 지적이다.

중복되는 정보와 짧은 제목 줄의 한계

예시로 제시된 fix(compiler): prevent namespaced SVG style elements from being stripped 같은 메시지는 설명문만 읽어도 버그 수정임을 알 수 있다. 즉 fix라는 접두사는 정보를 거의 추가하지 않는데도 제목 줄의 공간을 차지한다. 반대로 어떤 영역이 바뀌었는지 보여 주는 compiler나 core 같은 범위 정보는 실제로 검색성과 추적성을 높여 준다. 한 커밋이 리팩터링이면서 기능 추가이자 버그 수정일 수도 있다는 점도 type 체계의 경직성을 드러낸다. 작성자는 변경의 실체가 복합적인데 단일 분류값을 앞세우는 관행이 현실과 맞지 않는다고 본다.

자동화 약속이 왜 어긋나는가

컨벤셔널 커밋을 지지하는 대표 논리는 자동 체인지로그 생성과 시맨틱 버전 증가 판단이다. 그러나 기사에서는 커밋 로그와 체인지로그의 독자가 다르다고 반박한다. 커밋 로그는 개발자가 구현 흐름과 코드 변화를 추적하기 위한 기록이고, 체인지로그는 최종 사용자가 제품 변화만 빠르게 확인하기 위한 문서다. 되돌리기 커밋, 후속 수정, 여러 커밋에 걸친 기능 구현 같은 현실적인 상황을 생각하면 커밋 단위 type 분류만으로 버전 정책을 정확히 결정하기 어렵다. 심지어 docs 접두사를 단 커밋 안에서도 실제 취약점이 들어갈 수 있으므로 배포 판단을 제목에 의존하는 것도 위험하다.

실무에서 가능한 대안

작성자는 리눅스 커널, Go, Git, NixOS처럼 프로젝트의 서브시스템이나 패키지 경로를 앞세우는 범위 중심 접두사 방식을 대안으로 제시한다. 예를 들어 auth, compiler, net/http/cookiejar 같은 맥락이 먼저 보이면 로그를 훑는 사람이 훨씬 빠르게 변화 지점을 찾을 수 있다. 또한 빌드와 배포 자동화는 커밋 제목 분류보다 git diff의 실제 파일 변경 범위를 기준으로 삼는 편이 낫다고 주장한다. 결국 이 글은 커밋 메시지를 더 엄격하게 만들자는 제안이 아니라, 개발자가 실제로 쓰는 로그의 목적에 맞게 우선순위를 다시 세우자는 문제 제기에 가깝다.

원문 보기

출처: GeekNews 원문 링크