"feat:", "fix:" 그만 붙여도 될까? — Conventional Commits 비판론 들여다보기

무슨 일이냐면요

깃 커밋 메시지를 쓸 때 feat:, fix:, chore: 이런 접두어 붙여본 적 있으시죠? 이걸 Conventional Commits(컨벤셔널 커밋)라고 불러요. 거의 업계 표준처럼 자리 잡았는데요. 한 개발자가 "이 방식이 정작 중요한 걸 놓치게 만든다"며 정면으로 비판하는 글을 써서 갑론을박이 벌어졌어요. 매일 커밋하는 우리한테 직접 와닿는 주제죠.

Conventional Commits가 뭐냐면

처음 들으신 분을 위해 설명하면요, 커밋 메시지 맨 앞에 정해진 규칙으로 '종류'를 붙이는 약속이에요. 예를 들면 이런 식이에요.

• feat: 로그인 화면 추가 (새 기능)
• fix: 결제 금액 반올림 오류 수정 (버그 수정)
• chore: 의존성 업데이트 (잡일)
• docs:, refactor:, test: 등등

비판의 핵심

글쓴이의 주장은 이거예요. 접두어 규칙에 신경 쓰느라 정작 더 중요한 '왜 이걸 바꿨는가'를 소홀히 하게 된다는 거죠.

생각해보면요, feat:인지 fix:인지 카테고리를 고르는 건 사실 별로 중요한 정보가 아니에요. 진짜 중요한 건 "이 변경이 왜 필요했고, 어떤 맥락에서 결정됐는가"잖아요. 6개월 뒤에 이 코드를 다시 볼 동료가 궁금한 건 "이게 feat였나 fix였나"가 아니라 "도대체 왜 이렇게 짰지?"거든요. 그런데 접두어 규칙에만 익숙해지면, feat: 기능 추가처럼 내용 없이 형식만 갖춘 영혼 없는 메시지를 양산하기 쉬워요.

게다가 카테고리 분류 자체가 애매할 때가 많아요. 버그를 고치면서 작은 기능을 곁들였으면 feat예요 fix예요? 리팩토링하다 성능이 좋아졌으면? 이런 고민에 에너지를 쓰는 게 과연 가치 있냐는 거죠. 또 "커밋 하나=변경 종류 하나"를 강제하다 보면, 사실 함께 묶여야 할 변경을 억지로 쪼개거나, 반대로 의미 없는 분류에 맞추느라 커밋을 부자연스럽게 만들기도 해요.

그럼 대안은

비판하는 쪽이 말하는 건 "규칙을 다 버리자"가 아니라 "형식보다 내용에 집중하자"예요. 좋은 커밋 메시지의 고전적인 원칙이 있어요. 제목 줄은 간결하게 '무엇을' 요약하고, 본문에는 '왜' 이 변경이 필요했는지, 어떤 대안을 검토했는지, 주의할 점은 뭔지를 풀어쓰는 거예요. 리누스 토르발스나 깃 커뮤니티가 오래전부터 강조해온 방식이죠. 접두어 한 단어보다 이 본문 한 문단이 훨씬 값지다는 거예요.

물론 반론도 있어요. 자동 버저닝·체인지로그가 정말 필요한 라이브러리 프로젝트에서는 Conventional Commits가 실용적인 가치가 분명하거든요. 그래서 결론은 "무조건 쓰지 마"가 아니라 "내 프로젝트에 이 자동화가 진짜 필요한지 따져보고 도입하라"에 가까워요.

한국 개발자에게

한국 회사들도 컨벤셔널 커밋을 컨벤션으로 깔아두는 곳이 많아요. 그런데 막상 보면 feat: 작업, fix: 수정 같은 알맹이 없는 메시지가 수두룩하죠. 형식은 지켰지만 정작 6개월 뒤에 도움이 안 되는 거예요.

팀에 적용한다면 이렇게 균형을 잡아보세요. 자동 릴리스가 필요한 라이브러리/패키지라면 접두어 규칙을 유지하되, 반드시 본문에 '왜'를 적도록 코드리뷰에서 챙기기. 반대로 그냥 사내 서비스라 자동 체인지로그가 필요 없다면, 접두어에 집착하기보다 메시지 본문의 품질을 평가 기준으로 삼는 거죠. 도구는 수단일 뿐이고, 목적은 '미래의 동료가 맥락을 이해하는 것'이라는 걸 잊지 않는 게 핵심이에요.

마무리

핵심은 이거예요. 커밋 메시지의 가치는 접두어가 아니라 '왜'를 설명하는 본문에 있다. 여러분 팀은 컨벤셔널 커밋을 쓰고 계신가요? 쓴다면 그게 정말 도움이 되던가요, 아니면 그냥 형식적인 의식처럼 느껴지던가요?