---
title: "컨벤셔널 커밋, 진짜 중요한 건 타입이 아니라 스코프라는 반론"
published: 2026-06-05T15:39:38.000Z
canonical: https://jeff.news/article/3798
---
# 컨벤셔널 커밋, 진짜 중요한 건 타입이 아니라 스코프라는 반론

이 글은 컨벤셔널 커밋이 커밋 메시지에서 정작 중요한 스코프를 뒤로 밀고 타입을 앞세운다고 비판해. 자동 변경 로그 생성, 시맨틱 버전 결정, 빌드 트리거 같은 장점도 실제 개발 현장에서는 기대만큼 잘 작동하지 않는다고 주장해.

## 컨벤셔널 커밋의 문제는 “구조화”가 아니라 “뭘 앞에 두느냐”임

- 글쓴이는 컨벤셔널 커밋이 커밋 메시지에서 가장 덜 중요한 정보를 맨 앞에 둔다고 봄
  - 컨벤셔널 커밋 형식은 대략 `타입(스코프): 설명` 구조임
  - 여기서 타입은 fix, feat, chore, docs, refactor 같은 변경 종류고, 스코프는 compiler, auth, core 같은 변경 영역임
  - 글쓴이 주장은 간단함. 개발자가 커밋 로그를 볼 때 진짜 찾는 건 “어떤 타입의 변경인가”가 아니라 “어디가 바뀌었나”라는 것

- 스코프가 선택 사항인 것도 강하게 비판함
  - 기여자는 최근 코드베이스에서 자신이 작업하는 영역에 무슨 변화가 있었는지 알고 싶어 함
  - 디버거는 버그가 나타난 컴포넌트를 건드린 커밋을 찾고 싶어 함
  - 장애 대응자는 장애 시점 근처에 auth 같은 민감한 영역을 건드린 변경이 있는지 빠르게 훑고 싶어 함
  - 그런데 컨벤셔널 커밋은 이런 스코프를 선택 사항으로 두고, 타입을 필수처럼 앞세운다는 게 문제라는 얘기임

- 타입은 생각보다 중복 정보가 많고, 때로는 억지 분류가 됨
  - 예를 들어 “네임스페이스가 붙은 에스브이지 style 요소가 제거되지 않게 막음” 같은 설명만 봐도 버그 수정이라는 걸 알 수 있음
  - 반대로 어떤 커밋은 버그 수정이면서 리팩터링이고, 동시에 새 기능 지원일 수도 있음
  - 이런 상황에서 하나의 타입을 고르라고 하면 정보가 명확해지는 게 아니라 오히려 현실을 납작하게 만듦

> [!IMPORTANT]
> 이 글의 핵심은 “커밋 메시지를 대충 쓰자”가 아님. 커밋 로그의 독자가 실제로 찾는 정보는 타입보다 스코프라는 주장임.

## 자동화 장점도 생각보다 구멍이 많다는 주장

- 변경 로그 자동 생성은 가장 큰 약속이지만, 글쓴이는 이걸 별로 좋은 아이디어로 보지 않음
  - 변경 로그는 사용자용 문서라서 버전 사이에 기능적으로 뭐가 달라졌는지를 설명해야 함
  - 커밋 로그는 개발자용 기록이라서 코드베이스가 어떤 과정을 거쳐 바뀌었는지를 보여줘야 함
  - 한 기능이 여러 커밋으로 만들어지는 건 개발자에게는 의미 있지만, 사용자는 “그 기능이 생겼다”만 알면 됨

- 시맨틱 버전 자동 결정도 실제 이력에서는 자주 삐끗할 수 있음
  - 깨지는 변경을 넣었다가 되돌리면 도구는 여전히 메이저 버전 증가를 판단할 수 있음
  - 반대로 당시에는 몰랐지만 나중에 보니 호환성을 깨는 변경이었다면 마이너나 패치로 잘못 나갈 수 있음
  - 어떤 변경은 뒤의 커밋과 합쳐졌을 때 더 이상 깨지는 변경이 아닐 수도 있음

- 빌드나 배포 트리거를 커밋 타입에 거는 건 더 위험하다고 봄
  - `docs: 오타 수정`이라고 써놓고 실제로 인증 서브시스템에 취약점을 넣는 악성 커밋을 상상해보라는 것
  - 이런 건 코드 리뷰에서 잡아야겠지만, 자동화가 타입 문자열만 믿으면 사람이 놓쳤을 때 방어선이 없음
  - 글쓴이는 변경 파일을 `git diff`로 보고 빌드나 검사를 정하는 게 더 낫다고 주장함

## 대안은 프로젝트에 맞는 스코프 접두 커밋

- 글쓴이는 리눅스, 프리비에스디, 깃, 고, 닉스오에스 같은 오래 살아남은 프로젝트들을 예로 듦
  - 이 프로젝트들은 공통적으로 프로젝트 맥락에 맞는 스코프를 커밋 앞에 둠
  - 리눅스 커널이면 서브시스템, 고 프로젝트면 패키지 경로, 마이크로서비스 구조면 서비스명이 자연스러운 스코프가 됨
  - 즉 “모두가 같은 타입 목록을 쓰자”가 아니라 “우리 프로젝트에서 가장 잘 검색되는 변경 영역을 앞에 두자”는 접근임

- 회사 환경에서는 컨벤셔널 커밋이 더 이상해질 수 있다는 지적도 있음
  - 감사나 변경 관리 때문에 모든 커밋에 티켓 번호를 넣어야 하는 팀이 많음
  - 그러면 스코프 자리에 티켓 번호가 들어가고, 유일하게 쓸모 있던 메타데이터가 검색 가치 낮은 숫자로 대체됨
  - 결과적으로 타입은 앞에 남고, 정작 변경 영역은 사라지는 괴상한 로그가 만들어짐

- 마지막으로 글쓴이는 컨벤셔널 커밋이 “브랜딩 전쟁”에서 이겼을 뿐이라고 봄
  - 실제로는 스코프 중심 커밋이 더 오래되고 큰 프로젝트에서 잘 쓰였는데, 이름 붙이고 표준화한 컨벤셔널 커밋이 더 널리 퍼졌다는 것
  - 특히 AI가 커밋 메시지를 만들 때 컨벤셔널 커밋을 기본값처럼 쓰면서 이 패턴이 더 번지고 있다는 비판도 덧붙임

---
## 기술 맥락

- 이 글에서 말하는 기술적 선택은 커밋 메시지를 어떤 기준으로 구조화할지예요. 컨벤셔널 커밋은 변경의 종류를 앞에 두고, 스코프 커밋은 변경된 영역을 앞에 둬요.

- 왜 이게 중요하냐면 커밋 로그는 예쁜 기록물이 아니라 디버깅 도구에 가깝기 때문이에요. 장애가 났을 때 `fix` 커밋만 볼 수는 없어요. 버그는 `feat`, `refactor`, `docs`라고 적힌 커밋에서도 얼마든지 들어갈 수 있거든요.

- 스코프 중심 방식은 검색과 추적에 강해요. 인증 장애면 auth 관련 커밋을 보고, 컴파일러 버그면 compiler 관련 커밋을 보면 돼요. 프로젝트 구조가 커밋 제목 앞에 드러나니까 로그가 코드베이스 지도처럼 동작하는 셈이에요.

- 반대로 컨벤셔널 커밋의 자동 변경 로그와 버전 자동화는 팀에 따라 여전히 쓸모가 있을 수 있어요. 다만 이 글이 짚는 것처럼 그 자동화가 실제 변경의 의미를 대신 판단해주지는 못해요. 결국 릴리스 노트와 커밋 로그는 독자와 목적이 다르다는 걸 분리해서 봐야 해요.

## 핵심 포인트

- 커밋 로그를 읽는 개발자에게 중요한 정보는 fix나 feat 같은 타입보다 변경된 영역인 스코프임
- 변경 로그와 커밋 로그는 독자가 다르기 때문에 커밋 메시지로 사용자용 변경 로그를 자동 생성하는 건 한계가 큼
- 리눅스, 깃, 고, 닉스오에스 같은 프로젝트는 프로젝트 맥락에 맞는 스코프 접두 커밋을 사용함

## 인사이트

팀에서 컨벤셔널 커밋을 쓰고 있다면 한 번쯤 찔릴 만한 글이야. 규칙이 있다는 안정감보다, 그 규칙이 실제 디버깅과 운영에 어떤 정보를 남기는지가 더 중요하다는 얘기임.