Conventional Commits, 정말 필요한 표준일까?

논의에서는 Conventional Commits가 변경 타입(Type)을 스코프보다 우선시하는 점을 비판한다. 실제 개발자, 디버거, 사고 대응팀 모두 코드의 어떤 영역(Scope)이 변경되었는지에 더 큰 관심을 가지지만, Conventional Commits는 스코프를 선택 사항으로 두면서 타입에 집중한다. 이는 코드베이스의 특정 부분을 추적하거나 충돌을 예측하려는 개발자들의 요구와 상반된다는 지적이다.

필자는 Conventional Commits의 커밋 타입(Commit Type)이 대부분의 경우 커밋 설명(Description)만으로도 명확히 파악 가능하다고 주장한다. 예를 들어, 'fix(compiler): prevent namespaced SVG <style> elements from being stripped'와 같은 메시지는 타입 없이도 버그 수정임을 알 수 있다. 오히려 타입 필드가 불필요한 공간을 차지하고, 하나의 변경이 여러 타입(버그 수정, 리팩토링, 기능 추가)에 해당될 수 있어 유연성을 저해한다고 비판한다.

Conventional Commits의 주요 약속 중 하나인 자동 CHANGELOG 생성 기능에 대해 비판적인 시각을 제시한다. CHANGELOG는 최종 사용자에게 비즈니스/기능적 변화를 전달하는 반면, 커밋 로그는 개발자에게 코드베이스의 변화 과정을 보여준다. 이 두 가지 목적이 다르므로, 이를 통합하려는 시도는 결과적으로 미흡한 결과를 낳는다고 지적한다. 특히 여러 커밋에 걸쳐 구현되는 기능이나 롤백(Revert) 처리가 사용자 관점에서는 무의미하다는 점을 강조한다.

커밋 타입에 기반한 자동 시맨틱 버전 관리(Semantic Versioning) 역시 현실적인 소프트웨어 개발 과정에서 발생하는 문제들로 인해 정확성을 담보하기 어렵다고 지적한다. 예를 들어, 치명적인 변경사항을 롤백(Revert)하는 경우에도 메이저 버전이 증가하거나, 의도치 않은 브레이킹 체인지(Breaking Change)를 뒤늦게 발견하는 경우 등에서 버전 관리 도구가 잘못된 판단을 내릴 수 있다. 이러한 문제를 해결하기 위해 히스토리 재작성(Rebase)을 고려할 수 있으나, 이는 워크플로우를 방해하거나 협업에 혼란을 줄 수 있다고 언급한다.

필자는 Linux, FreeBSD, Git, Go 등 성공적인 프로젝트들이 사용하는 스코프 기반 커밋 메시지(Scope-Prefixed Commit Messages)를 대안으로 제시한다. 예를 들어, Linux 커널은 서브시스템(subsystem), Go 프로젝트는 패키지 경로(package path)를 스코프로 사용한다. 이러한 방식은 변경 사항의 실제 영향 범위를 명확히 하여 개발자들이 코드 변경 내역을 더 효과적으로 이해하고 관리할 수 있도록 돕는다고 주장한다. 이를 위해 'scopedcommits.com'이라는 웹사이트를 통해 이러한 방식을 옹호할 계획임을 밝힌다.