Showdev: AI 지원 스킬로 지저분한 변경을 Conventional Commits 로 일괄 처리

발행: (2026년 2월 19일 오후 07:12 GMT+9)
6 분 소요
원문: Dev.to

Source: Dev.to

Showdev 커버 이미지: AI‑보조 스킬로 지저분한 변경을 Conventional Commits 로 배치하기

Hi DEV community 👋

저는 최근에 조금씩 손보고 있는 작은 프로젝트 conventional-commit-batcher 를 공유하고 싶습니다.
AI 도구의 도움을 받아 만든 첫 번째 “skill” 입니다. 몇 명의 프로그래머 친구들이 실제 진행 중인 브랜치에서 사용해 보았고, 지저분하고 뒤섞인 변경을 더 깔끔한 커밋 히스토리로 바꾸는 데 유용하다고 판단해 오픈소스로 공개하게 되었습니다.

TL;DR

  • 먼저 계획 – 의도에 따라 Commit Plan 생성
  • 배치 커밋 – 보통 git add -p 로 진행
  • 커밋 메시지 검증 – Conventional Commits 강제

어떤 문제를 해결하려고 하나요?

작업 트리 안에 리팩터링, 버그 수정, 문서, 잡일 등이 뒤섞여 있으면 (특히 주니어 개발자에게) 다음과 같은 상황이 쉽게 발생합니다:

  • 하나의 거대한 “misc” 커밋
  • 모호한 커밋 메시지

그 결과 리뷰, 되돌리기, git bisect 가 어려운 히스토리가 만들어집니다.
저는 이를 큰 의식 없이도 보다 리뷰하기 쉽고 추적 가능한 히스토리로 유도해 주는 무언가가 필요했습니다.

한 줄 요약

Plan‑first 커밋 배치 + 커밋 메시지 검증 – 혼합된 diff 를 논리적이고 리뷰 가능한 Conventional Commits 로 정리하고, 커밋이 적용되기 전에 메시지를 검증합니다.

작동 방식 (고수준)

먼저 계획

변경을 의도별(예: 리팩터 vs 버그 수정 vs 문서)로 그룹화한 Commit Plan 을 생성합니다.

배치 스테이징

“전체 추가” 대신 배치별로 (보통 git add -p 로) 변경을 스테이징합니다.

메시지 검증

실행 가능한 검증기를 사용해 Conventional Commits 형식을 강제합니다.

안전 게이트

충돌 마커, 민감한 문자열 등 위험 요소가 감지되면 조기에 중단합니다.

예시: 의도별 Commit Plan

1) refactor(auth): simplify token parsing
   changes: src/auth/*

2) fix(api): handle empty response safely
   changes: src/api/*

3) docs: update setup notes
   changes: docs/*

레포지토리 / 빠른 체험

Repository:

Vercel skills 생태계를 사용한다면 다음으로 시도해 볼 수 있습니다:

npx skills add cnkang/conventional-commit-batcher

에이전트 도구 없이도 괜찮나요? 레포에 포함된 검증기와 commit‑msg 훅 예시를 그대로 사용할 수 있습니다.

작은 전/후 예시

Before (전형적인 지저분한 브랜치)

  • update stuff
  • fixes
  • wip

After (동일 작업, 더 명확한 히스토리)

  • refactor(auth): simplify token parsing
  • fix(api): handle empty response safely
  • docs: update setup notes

리뷰, 되돌리기, bisect 가 얼마나 쉬워지는지 상상이 가실 겁니다.

작은 부탁: 사용해 보고 피드백을 공유해주세요

특히 “지저분한 브랜치”에서 직접 써보신다면 의견을 정말 감사히 받겠습니다:

  • 의도별 배치: 실제로 혼합된 변경을 논리적인 커밋으로 나누는 데 도움이 되나요? 그렇지 않다면 어떤 종류의 변경이 가장 분리하기 어려운가요(테스트 + 리팩터, 포맷팅 + 로직, lockfile 등)?
  • 팀 컨벤션: 어떤 규칙을 따르고 있나요(타입/스코프, 제목 길이, 이슈 레퍼런스, breaking change 등)?
  • 주니어 친화적 가드레일: 어떤 체크가 도움이 되고, 어떤 체크가 너무 엄격하다고 느껴지나요?
  • 다국어 커밋 메시지: 영어 외 다른 언어로 커밋을 작성하시나요? 그렇다면 type(scope) 은 영어로 유지하고 본문/제목을 현지화하는 것이 좋을까요, 아니면 완전 현지화된 메시지를 원하시나요(그럴 경우 검증은 어떻게 조정되어야 할까요)?

읽어 주셔서 감사합니다 🙇

시도해 보시고 도움이 되었든, 아니면 실패했든 결과를 알려주시면 좋겠습니다—어느 쪽이든 환영합니다.

0 조회
Back to Blog

관련 글

더 보기 »