개발자들이 커밋 메시지를 작성할 때 흔히 사용하는 컨벤셔널 커밋(Conventional Commits) 방식이 실제 개발 효율성을 저해한다는 주장이 나왔습니다. 이 방식은 `<type>[optional scope]: <description>` 형태로 커밋 메시지에 일관된 의미를 부여하려 하지만, 변경의 종류(type)를 우선하고 변경이 영향을 미치는 범위(scope)를 선택 사항으로 두어 정작 중요한 정보가 뒤로 밀린다는 비판입니다.
컨벤셔널 커밋의 핵심 문제는 변경의 '종류'보다 '어떤 영역'을 건드렸는지가 더 중요하다는 점을 간과한다는 것입니다. 기여자들은 마지막 기여 이후의 변화나 충돌 가능성을 파악하기 위해, 디버거는 버그가 발생한 컴포넌트 관련 변경을 찾기 위해, 장애 대응자는 문제 발생 시점 주변의 영향을 받은 영역을 확인하기 위해 커밋 로그를 읽습니다. 이들에게는 `fix`나 `feat` 같은 변경 유형보다는 `compiler`나 `auth` 같은 변경 범위가 훨씬 더 유용한 정보입니다. 또한, 하나의 커밋이 버그 수정, 리팩터링, 기능 추가 등 여러 성격을 동시에 가질 수 있어 `type`이 중복되거나 제한적일 수 있으며, `description`만으로도 변경의 성격을 충분히 알 수 있는 경우가 많아 `type` 접두사가 불필요하다는 지적도 있습니다.
자동 CHANGELOG 생성이나 시맨틱 버전(Semantic Versioning) 증가는 컨벤셔널 커밋의 주요 장점으로 꼽히지만, 이 역시 한계가 명확합니다. 커밋 로그는 개발자를 위한 것이고 CHANGELOG는 최종 사용자를 위한 것이므로 독자의 목적이 다릅니다. 복잡한 프로젝트에서는 하나의 기능이 여러 커밋에 걸쳐 구현되거나, 되돌리기(revert) 커밋처럼 개발자에게는 중요하지만 최종 사용자에게는 의미 없는 변경도 존재합니다. 또한, `type`에 기반한 시맨틱 버전 증가는 하위 호환성 파괴 여부를 잘못 판단하거나, 나중에야 문제가 드러나는 등의 오류를 유발할 수 있습니다. 빌드 및 배포 프로세스 트리거 역시 커밋 제목의 `type`보다는 `git diff`를 통해 실제 변경 파일을 식별하는 것이 더 안전하고 정확하다는 대안이 제시됩니다.
대신 리눅스(Linux), FreeBSD, Git, Go, Node.js 등 유수의 오픈소스 프로젝트들은 이미 `subsystem: description`이나 `package: description`과 같이 '범위 중심'의 커밋 메시지 형식을 사용하고 있습니다. 이는 변경이 영향을 미치는 코드 영역을 명확히 보여주어 개발자들이 커밋 로그를 훨씬 효율적으로 탐색할 수 있게 돕습니다. 컨벤셔널 커밋이 가진 장점들이 실제 이점으로 이어지지 못하고, 오히려 AI가 생성하는 커밋 메시지의 기본 선택지가 되면서 안티패턴이 확산되는 경향이 있다는 비판은, 개발 커뮤니티가 커밋 메시지 작성 방식에 대한 근본적인 재고를 해야 할 시점임을 시사합니다.