모두가 쓰는 Conventional Commits, 정작 중요한 건 놓치고 있다?

feat:, fix:, chore:. 최근 몇 년간 깃 커밋 로그를 열어보면 이 접두사들이 빠지지 않고 등장합니다. Conventional Commits, 즉 정해진 형식으로 커밋 메시지를 쓰자는 약속이 어느새 업계 표준처럼 자리 잡았는데요. 그런데 요즘 개발자 커뮤니티에서는 “이제 그만 쓰자"는 반론이 슬슬 고개를 들고 있습니다. 다들 당연하게 따르던 규칙에 왜 의문이 생긴 걸까요.

먼저 짚고 넘어갈 게 있습니다. 이번 주제는 최근 한 달 사이 폭발적으로 논의된 따끈한 화제는 아닙니다. 오히려 몇 년에 걸쳐 꾸준히 반복되는 해묵은 논쟁에 가깝습니다. 그만큼 개발자들이 계속 곱씹는 주제라는 뜻이기도 하죠. 오늘은 이 논쟁의 핵심을 짚어보겠습니다.

Conventional Commits, 대체 뭐길래

Conventional Commits는 커밋 메시지 첫 줄에 정해진 타입을 붙이는 규칙입니다. 기능 추가는 feat, 버그 수정은 fix, 자잘한 작업은 chore 같은 식이죠. 형식은 보통 이렇게 생겼습니다.

feat(auth): add password reset endpoint

타입, 괄호 안의 범위(scope), 그리고 한 줄 설명으로 이어집니다. 이렇게 정해진 틀을 따르면 좋은 점이 분명 있습니다. 가장 큰 매력은 자동화입니다. feat가 몇 개, fix가 몇 개 쌓였는지 기계가 읽어서 버전 번호를 자동으로 올리고, 변경 이력(CHANGELOG)도 알아서 만들어 줍니다. semantic-release 같은 도구가 이 규칙 위에서 돌아가죠.

팀 입장에서도 일관성이 생깁니다. 누가 쓰든 커밋 첫 단어만 봐도 성격이 파악되니까요. 이 명확함 덕분에 수많은 오픈소스 프로젝트가 이 규칙을 채택했습니다.

“정작 중요한 건 왜(Why)인데”

반론의 핵심은 여기서 출발합니다. Conventional Commits는 커밋이 무엇(What)을 했는지에 집착하게 만든다는 지적입니다.

생각해보면 fix: 로그인 버그 수정이라는 메시지는 사실 정보가 거의 없습니다. 코드 변경분(diff)만 봐도 버그를 고쳤다는 건 알 수 있으니까요. 정작 6개월 뒤에 이 커밋을 다시 들여다보는 동료가 궁금한 건 따로 있습니다. 왜 이렇게 고쳤는지, 어떤 다른 방법을 시도했다가 포기했는지, 이 변경이 어떤 부작용을 낳을 수 있는지 말이죠.

좋은 커밋 메시지의 정수는 본문(body)에 있다는 게 반대 진영의 주장입니다. 제목 한 줄에 feat냐 fix냐 라벨을 붙이느라 에너지를 쓰는 동안, 정작 풍부하게 적어야 할 맥락과 의사결정 과정은 뒷전이 된다는 거죠. 형식을 채우는 데 만족하고 정작 본문은 비워두는 습관이 생긴다는 비판입니다.

타입 분류, 생각보다 애매하다

또 다른 불만은 분류 자체의 모호함입니다. 막상 커밋을 하려고 하면 이게 feat인지 fix인지, 아니면 refactor인지 헷갈리는 순간이 자주 옵니다.

성능을 개선했는데 그 과정에서 동작이 살짝 바뀌었다면 이건 어떤 타입일까요. 리팩터링이 버그를 같이 고쳤다면요. 현실의 커밋은 깔끔하게 한 가지 타입으로 떨어지지 않는 경우가 많습니다. 결국 개발자마다 판단이 갈리고, 팀 안에서도 같은 작업에 다른 라벨이 붙습니다. 일관성을 위해 도입한 규칙이 오히려 새로운 혼란을 만드는 셈입니다.

여기에 더해 잘못 붙인 타입은 자동 버전 관리를 망가뜨립니다. 사소한 수정인데 실수로 feat를 붙이면 버전이 엉뚱하게 올라가 버리죠. 자동화의 편리함이 곧 자동화의 위험으로 바뀌는 지점입니다.

형식보다 문화가 먼저다

그렇다고 Conventional Commits가 무조건 나쁘다는 결론은 성급합니다. 반대 진영도 인정하는 부분이 있습니다. 자동 릴리스가 꼭 필요한 라이브러리나 대규모 오픈소스에서는 이 규칙의 가치가 분명하다는 점입니다.

핵심은 맥락입니다. 도구가 메시지를 기계적으로 읽어야 하는 환경이라면 형식이 중요합니다. 반대로 사람이 읽고 사람이 이해해야 하는 게 우선인 팀이라면, 접두사 규칙보다 본문을 충실히 쓰는 문화가 훨씬 값집니다.

결국 진짜 질문은 “Conventional Commits를 쓸 것이냐 말 것이냐"가 아닙니다. “우리 팀의 커밋 메시지가 미래의 누군가에게 도움이 되는가"입니다. 형식은 그 목적을 위한 수단일 뿐인데, 어느 순간 수단이 목적이 되어버린 게 아니냐는 반성인 거죠.

규칙을 따르는 건 쉽습니다. 어려운 건 좋은 맥락을 글로 남기는 일입니다. 여러분의 마지막 커밋 메시지는 6개월 뒤의 동료에게 무엇을 말해줄 수 있을까요. 접두사 한 단어 너머에, 정작 적어야 할 이야기가 빠져 있지는 않은지 한번 돌아볼 때입니다.