솔직히 말해서, 최근 이런 상황이 늘어나고 있지 않나요?

AI에게 "이 기능 좀 추가해줘"라고 부탁했더니, 30분 뒤에 10개 파일, 400줄의 차분(diff)이 돌아온다. 실행해 보니 제대로 작동한다. "오, 괜찮은데?"라고 생각하며 머지(merge)한다.

……그런데, 그 3일 뒤. 다른 버그가 발생해서, "아, 저 변경 사항이 원인일지도 몰라. 한 번 되돌리고 싶다"라고 생각하는 순간, 굳어버리게 됩니다.

• 어떤 커밋에서 그 변경이 들어갔는지 알 수 없다
• 하나의 커밋에 기능 추가, 리팩토링(refactor), 로그 수정이 전부 섞여 있다
• 커밋 메시지가
  update

fix

wip

뿐이라서 무엇을 했는지 기억나지 않는다 - 되돌리려 해도 원하지 않는 변경까지 함께 휩쓸려 들어간다

이거, 꽤 흔히 있는 일이라고 생각합니다.

여기서 깨달아야 할 점이 하나 있습니다. AI로 빨라진 것은 '코드를 쓰는' 부분뿐이라는 점입니다. "나중에 읽기", "리뷰하기", "되돌리기", "원인 특정하기"는 오히려 이전보다 더 힘들어졌습니다. 왜냐하면 인간이 손으로 쓰던 시절보다 훨씬 더 많은 양의 변경 사항이 훨씬 더 빠르게 쌓여가기 때문입니다.

그리고 그 "읽기·되돌리기"의 토대가 되고 있는 것이, 사실은 커밋(commit)과 PR(Pull Request, 풀 리퀘스트)의 설계입니다. 아주 사소하죠. git 이야기라면 이미 알고 있다고 생각할지도 모릅니다. 하지만 AI가 대량으로 코드를 뱉어내는 시대가 되면서, 가장 효과를 발휘하는 것이 바로 이 가장 사소한 부분이기도 합니다.

이 기사에서는 커밋을 '단순한 저장'이 아니라 '리뷰와 롤백(rollback)의 최소 단위'로 설계한다는 사고방식을, 용어의 의미부터 첫걸음까지 가능한 한 쉽게 정리해 나가겠습니다. git은 다룰 줄 알지만 "커밋 설계" 같은 것은 의식해 본 적이 없다는 분들에게 꼭 읽어보길 권하는 내용입니다.

이 기사의 코드와 이름은 모두 설명용 더미(dummy)
(example-app / payment-service 등)입니다. 특정 제품이나 개인 정보는 포함하지 않습니다.

"알고 있다"는 분은 건너뛰어도 좋습니다. 하지만 이 부분을 모호하게 둔 채 진행하면 후반부가 흐릿해지므로, 만약을 위해 정리합니다.

커밋(commit): 변경의 "세이브 포인트"입니다. 게임에서의 저장과 마찬가지로, "여기까지의 상태"를 이름(메시지)과 함께 기록하는 행위, 또는 그 기록 자체를 말합니다.

차분(diff): 어떤 커밋에서 "어느 행을 어떻게 바꿨는가"를 나타낸 것입니다. -는 삭제된 행, +는 추가된 행입니다. 리뷰에서 인간이 실제로 살펴보는 것은 기본적으로 이것입니다.

PR(Pull Request, 풀 리퀘스트): "이 변경 사항들을 메인 브랜치에 반영해도 될까요?"라고 요청하는 리뷰 의뢰 단위입니다. 여러 커밋을 모아서 리뷰, 토론, 머지(merge)하는 장소입니다.

git blame: 특정 파일의 각 행이 "어떤 커밋에서, 누가, 언제" 변경되었는지 표시하는 명령어입니다. "이 정체불명의 한 줄, 왜 들어있는 거지?"를 추적할 때 사용합니다.

git bisect: "언제부터 버그가 들어갔는지"를 **이분 탐색(binary search)**으로 특정하는 명령어입니다. 나중에 자세히 다루겠습니다. 범인 찾기의 강력한 아군입니다.

git revert: 어떤 커밋의 변경을 "취소하는" 새로운 커밋을 만드는 명령어입니다. 이력은 지우지 않고, 위에서 "없었던 일"로 덮어쓰는 이미지입니다.

atomic commit(아토믹 커밋): "하나의 커밋에는 하나의 논리적인 변경만 담는다"는 사고방식입니다. 이 이상 나누면 의미가 깨진다고 판단되는 최소 단위입니다.

Conventional Commits: 커밋 메시지에 feat:, fix:와 같은 "형식"을 붙이는 작성 규칙입니다. 인간과 기계 모두에게 읽기 쉬워집니다.

이 정도가 머릿속에 들어있다면 괜찮습니다. 그럼 본론으로 들어가겠습니다.

결론부터 말하자면, **AI는 '대량이고·섞여 있는' 차분을 내놓기 쉽기' 때문입니다. 그리고 대량이고 섞여 있는 차분은 나중에 읽는 것도 되돌리는 것도 인간에게 엄청나게 고통스럽습니다.

잠시 2026년의 상황에 대해서도 언급해 두겠습니다. AI 지원으로 작성된 PR은 인간이 직접 작성했을 때보다 사이즈가 커지는 경향이 있다고 여러 조사와 벤더 리포트에서 보고되고 있습니다(어떤 분석에서는 평균적으로 20% 정도 더 크다는 수치도 나오고 있습니다). 그리고 차분이 클수록 리뷰는 대충 하기 쉬워집니다. 인간은 수백 줄을 넘는 차분이 오면 대개 중간부터 "뭐, 괜찮겠지"라며 대충 훑어보게 되거든요. 솔직히 인정합시다, 그렇게 됩니다.

게다가 AI는 한 번의 응답으로 '기능 추가'도, '덤으로 하는 리팩터링 (refactor)'도, '로그 수정'도 전부 한꺼번에 해버릴 때가 있습니다. 이것이 이른바 tangled commit (엉킨 커밋) 입니다. 슈퍼마켓 봉투에 식재료, 세제, 건전지를 모두 뒤섞어 넣은 상태를 상상해 보세요. 계산대(리뷰)에서 확인하기도 힘들고,

한눈에 구별할 수 있습니다. '최근에 기능만 추가하고 테스트 코드는 안 썼네' 같은 것을 알아챌 수 있죠. -
기계가 처리 가능: 타입을 보고 자동으로 CHANGELOG(변경 기록)를 생성하거나, 버전 번호를 올릴 수 있습니다. feat

이라면 마이너, fix

이라면 패치, BREAKING CHANGE:

이 있으면 메이저라는 식으로 **SemVer(시맨틱 버저닝)**와 연동할 수 있습니다. -
AI에게도 읽기 쉬움: 나중에 AI에게 기록을 요약시키거나 릴리스 노트를 작성하게 할 때, 타입이 붙어 있으면 압도적으로 정확해집니다.

좋은 예와 나쁜 예를 나란히 비교해 보겠습니다.

# ❌ 나중에 내가 울게 될 것들
update
fix bug
...

아래 세 가지는 보기만 해도 '결제 관련을 건드렸구나', '돈 계산을 int로 바꿨구나'라고 알 수 있죠. 이게 반년 후의 나를 구합니다.

여기, 가장 전하고 싶은 부분입니다.

커밋 메시지는 자꾸 '무엇을 했는지(What)'만 쓰고 끝내기 쉽습니다. 하지만, 차이점(diff)을 보면 '무엇을 했는지'는 알 수 있거든요. +

와 -

를 읽으면 됩니다.

진정으로 나중에 필요해지는 것은, '왜 그렇게 했는지(Why)' 쪽입니다.

fix(auth): 토큰의 유효 기간을 24시간에서 1시간으로 단축
본문 (이유):
인시던트 #1234로 인해, 유출된 토큰이 장시간 유효했기 때문에
...

반년 후의 나(혹은 인계받은 누군가)가 '왜 여기 1시간이지?'라고 생각했을 때, git blame
으로 이 커밋에 도착하면, 답이 거기에 있습니다. 차이점에는 절대로 쓰여 있지 않은 '판단의 배경'이 남아 있는 거죠. 이건 미래의 나에게 보내는 편지 그 자체입니다.

여기서 AI가 등장합니다. 다만 주의할 점이 있습니다. AI는 차이점으로부터 'What'은 추측할 수 있지만, 'Why'는 당신의 머릿속에만 존재합니다. 따라서 AI에게 Why를 '결정하게 하는' 것이 아니라, '언어화하는 것을 도와달라고 요청'해야 합니다.

당신은 커밋 메시지 편집자입니다.
아래 git diff를 읽고 Conventional Commits 형식의 메시지 초안을 만들어 주세요.
출력 규칙:
...

돌아온 '확인받고 싶은 Why'에, 사람이 한 마디씩 답해서 본문에 추가합니다. 이렇게 하면, AI가 초안 작성하고, 인간이 의도를 주입하는 기분 좋은 분담이 가능해집니다. Why를 쓰는 건 2분입니다. 하지만 그 2분이 미래의 누군가의 몇 시간을 구합니다.

커밋을 정리했다면, 다음은 PR(Pull Request) 단위입니다. 원칙은 간단해서, 하나의 PR에는 하나의 목적이어야 합니다.

AI에게 맡기면 자꾸 '기능 A와, 관련 리팩토링, 그리고 김에 타입 에러 수정'을 하나의 PR에 담으려고 합니다. 하지만 리뷰어 입장에서 생각해 보세요. 500줄이 뒤섞인 차이점이 오면 어디부터 보겠어요?……대체로 안 보거든요. LGTM(좋아 보여요) 누르고 끝. 그거, 리뷰한 거랑 똑같습니다.

대책은 몇 가지 있습니다.

• PR을 작게 유지하기: Google의 코드 리뷰 가이드에서도 '작은 변경(Small CL)'이 권장됩니다. 작을수록 리뷰가 빠르고 정확하며, 되돌리기 쉽습니다. -
  PR 스태킹(Stacking): 큰 변경을 '기반 → 그 위 → 더 위에'처럼 쌓아 올린 작은 PR의 연속으로 만듭니다. 한 장씩 리뷰할 수 있습니다. -
  목적이 바뀌면, PR을 분리하기: '리팩토링 PR'과 '기능 PR'은 섞지 마세요. 이것만으로도 리뷰 품질이 확 달라집니다.

PR 설명문(description)은 리뷰어가 가장 먼저 읽는 '지도'입니다. 여기가 부실하면, 리뷰의 질이 떨어집니다. AI에게 초안을 작성하게 하면 편하지만, 반드시 '근거(어떤 파일의 어느 줄인지)'를 첨부하도록 하는 것이 요령입니다. 근거를 요구하면, AI의 '그럴듯한 거짓말'을 찾아내기 쉬워집니다.

당신은 PR 설명문 초안 작성자입니다. 아래 차이점으로부터 리뷰어용 설명을 작성해 주세요.
반드시 다음 헤딩으로 구성하세요:
## 이 PR의 목적 (1~2문)
...

'롤백 절차(rollback procedure)'를 PR에 반드시 적게 하는 것이 은근히 추천됩니다. '돌리는 방법을 먼저 언어화해 두면', 돌리는 게 무섭지 않거든요. 되돌릴 수 있는 안심이 있기 때문에, 빠르게 시도할 수 있습니다. 이건 다음 장과도 연결되는 이야기입니다.

AI로 대량의 변경을 내보내는 시대에, 가장 큰 안전장치는 '언제든 돌아갈 수 있다'는 상태입니다. 여기서는, 되돌리기 위한 도구 3가지를 소개합니다.

우선 대원칙입니다. 모두가 공유하는 브랜치에서는 git reset --hard로 히스토리를 되돌려서는 안 됩니다.

git revert <커밋>
: 해당 커밋의 변경 사항을 취소하는 새로운 커밋을 만듭니다. 히스토리는 남습니다. 따라서 공유 브랜치에서도 안전합니다.

• git reset --hard <커밋>
  : 그 지점까지 히스토리를 되돌리고 뒤를 버립니다. 로컬 작업도 사라집니다. 공유 브랜치에서 사용하면 다른 사람의 기록과 충돌하여 큰 사고가 납니다.

# ⭕ 공유 브랜치에서의 정답: 취소 커밋을 쌓는다
git revert a1b2c3d
# → "Revert: feat(cart): ..."라는 새 커밋이 생성됩니다. 안전합니다.
...

git reset --hard와 git push --force는 공유 브랜치에서는 원칙적으로 금지입니다. 꼭 해야 한다면 '자신만의 미푸시 브랜치'로 한정하고, 팀이 공유하는 브랜치에 대한 강제 작업은 사람이 이중 확인하는 게이트를 거쳐야 합니다.

atomic commit이 효과를 발휘하는 곳이 바로 여기입니다. 1커밋 = 1목적이라면, git revert로 '그 변경 사항만'을 정확하게 취소할 수 있습니다. 하지만 복잡하게 얽힌(tangled) 커밋이라면, revert하는 순간 원하는 변경까지 함께 사라집니다.

"언제 사이에 버그가 생겼어. 근데 어느 커밋이 원인인지 모르겠네". AI가 대량의 커밋을 쌓아 올린 후에 실제로 일어날 수 있는 일입니다. 그럴 때의 마법 같은 도구가 git bisect입니다.

원리는 이분 탐색(binary search)입니다. '정상이었던 과거의 커밋'과 '고장 난 현재의 커밋'을 알려주면, git이 중간 지점의 커밋으로 이동시켜 줍니다. 사용자는 그저 "이건 정상인가요? 고장났나요?"라고 답하기만 하면 됩니다. 이것을 반복하면 100개의 커밋이라도 약 7번 만에 범인(버그를 유발한 커밋)을 찾아낼 수 있습니다.

# 탐색 시작
git bisect start
# 지금은 고장 난 상태입니다
...

테스트가 자동화되어 있다면, 판정조차 자동으로 할 수 있습니다.

# 테스트 스크립트의 종료 코드로 good/bad를 자동 판정
# (종료 코드 0 = good, 1~127 = bad)
git bisect start HEAD v1.4.0
...

이것은 1커밋이 작을수록 위력이 커집니다. 범인 커밋이 '기능 추가 + 리팩토링 + 정리 전부 포함'이라면, 특정할 수는 있어도 "그래서 이 중 어느 것 때문이야?"라는 질문에 부딪힙니다. atomic commit의 장점은 여기서도 발휘됩니다.

큰 변경 사항을 '머지(merge)는 하지만 아직 작동시키지는 않는' 상태로 만들어 두는 기술입니다. 이것이 있으면 문제가 생겨도 코드를 되돌리지 않고 스위치를 끄기만 하면 됩니다.

// 설정에서 기능의 ON/OFF를 전환
const flags = {
newCheckout: process.env.FEATURE_NEW_CHECKOUT === "on",
...

새로운 코드에 문제가 생겨도, FEATURE_NEW_CHECKOUT을 off로 바꾸면 즉시 이전 동작으로 돌아갑니다. revert조차 필요 없습니다. 되돌아갈 경로를 여러 개 준비해 두는 것이 공격적인 한 수를 가볍게 만듭니다.

지금까지의 원칙들은 개인의 마음가짐만으로는 금방 무너집니다. 그래서 시스템으로 지켜야 합니다. CI(자동 체크)에 통합시켜 버리세요.

commitlint를 사용하면 Conventional Commits 형태가 아닌 커밋을 걸러낼 수 있습니다.

// commitlint.config.js
module.exports = {
extends: ["@commitlint/config-conventional"],
...

이것을 git hook(커밋 시 자동 체크)에 연결합니다. husky나 lefthook을 사용하는 것이 일반적입니다.

# lefthook.yml 예시
# commit-msg 훅에서 매번 메시지 타입을 체크한다

# lefthook.yml
commit-msg:
commands:
...

이렇게 하면, update 같은 부실한 메시지는 커밋 단계에서 막힙니다. 처음에는 "시끄럽다"고 생각하겠지만, 1주일이면 익숙해지고 반년 뒤에는 감사하게 될 겁니다.

GitHub Actions를 이용해 PR 전체의 커밋 타입 체크와 거대한 PR에 대한 경고까지 넣어둡니다.

# .github/workflows/commit-quality.yml
name: commit-quality
on: pull_request
...

여기서 중요한 것은, 거대한 PR은 "실패(block)"가 아니라 "경고(warning)"로 설정해 두는 것입니다. 사정상 커밋이 커지는 경우도 있기 때문에, 기계가 무조건 막기보다는 인간에게 "정말로 이 사이즈로 괜찮겠어?"라고 질문을 던지는 형식을 취합니다. 비난하는 축이 아니라, 인지(awareness)를 돕는 축으로 말이죠.

형식이 갖춰져 있으면 semantic-release와 같은 도구를 사용해 "형식에 따라 버전을 결정하고, CHANGELOG를 생성하고, 태그를 다는 것"까지 자동화할 수 있습니다. feat가 포함되면 마이너(minor), fix라면 패치(patch), BREAKING CHANGE라면 메이저(major) 업데이트가 됩니다. 꾸준한 형식화가 릴리스 작업 자동화라는 형태로 이자(interest)를 낳는 셈입니다. 성실함이 빛을 발하는 지점이죠.

지금까지의 내용을 한 장으로 정리합니다. AI 시대의 커밋 운영에서 무엇을 인간이 쥐고, 무엇을 AI에게 맡길 것인가.

한마디로 요약하자면, "무엇을, 왜 바꿨는가"는 인간의 영역이고, "어떻게 쓰는가"는 AI의 영역입니다. 커밋의 의도와 리뷰 판단은 AI에게 넘겨서는 안 되는 인간의 일입니다. 반대로 말하면, 이 부분만 제대로 쥐고 있다면 작성 작업은 얼마든지 AI에게 맡겨도 좋습니다.

• AI 생성물 1개 = 커밋 1개로 만들어버리는 것: 생성 단위와 커밋 단위는 별개입니다. 의미 단위로 다시 나누어야 합니다.
• 메시지에 Why를 쓰지 않는 것: 차이점(diff)을 보면 What은 알 수 있습니다. 본문에는 "왜"를 남겨야 합니다.
• 거대한 PR을 기계로 무조건 block 하는 것: 사정이 있을 때도 있습니다. 경고로 설정하여 판단을 인간에게 돌려주세요.
• 공유 브랜치에서 reset --hard / force push를 하는 것: 이력을 망가뜨려 주변 동료들을 휘말리게 합니다. 공유 브랜치에서는 revert를 사용하세요.
• AI 메시지를 맹신하는 것: 차이점과 일치하지 않는 "그럴듯한 거짓말"이 섞일 수 있습니다. 근거를 대조한 후 채택하세요.
• 규칙을 너무 많이 넣어서 형식화만 되는 것: 처음부터 형식을 20개씩 정하지 마세요. feat/fix/refactor/docs/test/chore 정도로 시작하세요.
• 규약이 목적이 되어버리면 완화하기: "깨끗한 이력"이 목적이 아닙니다. "나중에 도움이 되는 것"이 목적입니다. 수단이 무거워지면 덜어내세요.
• 너무 작게 나누어 문맥이 흩어지면 되돌리기: 원자성(atomic)은 중요하지만, 한 줄씩 커밋하여 의미를 추적할 수 없다면 본말전도입니다. "이 이상 나누면 의미가 깨진다"가 최소 단위입니다.
• 비가역적 작업은 반드시 인간 게이트를 거칠 것: force push, 이력 수정, 운영 환경 공개·배포·태그 삭제는 AI에게 자동 실행시키지 마세요. 제안 단계에서 멈춰야 합니다.

마지막으로, 커밋 관련 사고가 났을 때 치명적인 포인트를 짚어보겠습니다.

비밀 정보를 커밋 내용이나 커밋 메시지에 절대 포함하지 마세요.

API 키, 토큰, 패스워드, .env 내용, 개인정보, 사내 고유 ID나 URL 등. 한 번 커밋하여 push하면 나중에 삭제하더라도 이력(history), 포크(fork), 캐시 등에 남는다는 전제로 생각해야 합니다. .gitignore와 gitleaks 같은 비밀 정보 탐지 도구를 pre-commit/CI에 넣어 유입을 입구에서 차단하는 것이 기본입니다.

그 외의 철칙:

• AI에게 차이점(diff)을 붙여넣는 것은 "외부로 정보를 유출하는 것"이라는 의식을 가질 것. 비밀이나 개인정보가 포함된 차이점을 무의식적으로 외부 서비스에 붙여넣지 마세요.
• AI가 생성한 커밋 메시지나 PR 설명은 "주장"이지 "사실"이 아니다. 차이점과 대조한 후 채택하세요. 아래의 리뷰용 프롬프트가 도움이 됩니다.
• 비가역적 작업(force push, 이력 수정, 공개, 배포)은 반드시 인간의 승인 게이트를 거치게 하세요. AI가 자동으로 하게 두지 마세요.

당신은 커밋 안전 리뷰어입니다. 다음 커밋(메시지 + diff)을 점검하고,
다음 사항을 보고하세요. 최종 판단은 인간이 한다는 전제하에, 단정적인 말투가 아닌 지적 사항으로 제시할 것.
체크 항목:
...

내용이 길어졌으니 마지막으로 요약하겠습니다.

AI로 인해 "쓰는 것"은 빨라졌습니다. 하지만 "읽고, 리뷰하고, 되돌리는 것"은 인간의 업무로 남았습니다. 그리고 그 토대가 되는 것이 바로 커밋과 PR의 설계였습니다.

• 원자적 커밋 (Atomic Commit): 1개의 커밋에 1개의 의미. 리뷰와 롤백(Rollback) 모두 이것이 핵심입니다.
• Conventional Commits: 형식을 갖추면 사람, 기계, 그리고 AI에게도 친절해집니다.
• 커밋 메시지의 Why: 차이점(Diff)만으로는 설명할 수 없는 '이유'를 남깁니다.
• 작은 PR과 되돌릴 수 있는 도구 (revert / bisect / feature flag): 되돌릴 수 있다는 안심이 공격적인 시도를 가볍게 만듭니다.
• CI를 통한 체계화: 마음가짐은 무너지기 마련입니다. 그렇기에 자동 체크(Automated Check)를 통해 보호받아야 합니다.

모두에게 공통적인 것은, "미래의 자신과 팀을 위해, 지금 조금 정돈해 둔다"라는 자세입니다.

제가 항상 중심에 두는 질문이 하나 있습니다. "이 선택, 내일의 내가 '고마워요'라고 말해줄 쪽은 어느 쪽일까?". 커밋 메시지에 Why를 두 줄 추가하는 것도, PR을 작게 나누는 것도 바로 이것 때문입니다. 오늘의 내가 아주 조금의 수고를 더하면, 반년 뒤의 나(혹은 업무를 인계받은 누군가)가 "와, 제대로 써줘서 고마워요"라고 하게 됩니다. 커밋은 미래의 자신에게 남기는 편지입니다. 비난하기 위한 기준이 아니라, 배려하는 마음으로 남겨두는 것이죠.

그리고 하나 더. 코드를 쓰는 속도는 AI 덕분에 모두가 비슷해질 것입니다. 하지만, "나중에 읽을 수 있고, 되돌릴 수 있으며, 팀에서 다룰 수 있는 이력을 설계하는 능력"은 쉽게 빼앗기지 않는, 쌓여가는 자산이라고 생각합니다. 무엇을, 왜 바꿨는지(What / Why)를 파악하는 것은 인간이 하고, 어떻게 쓸지(How)는 AI에게 맡깁니다. 이러한 역할 분담을 할 수 있는 사람이 앞으로의 AI 시대에 강할 것이라고 느낍니다.

마지막으로, 내일부터 실천할 수 있는 작은 4단계 스텝을 남겨둡니다.

• 다음 커밋 하나만이라도, Conventional Commits의 형식(feat:, fix: 등)을 붙여보기.
• 그 커밋의 본문에 '이유(Why)'를 딱 한 줄만 추가해보기.
• AI가 큰 차이점(Diff)을 만들어냈다면, git add -p를 사용하여 두 개로 나누어 보기.
• "만약 문제가 생기면 어떻게 되돌릴 것인가"를 PR 설명에 한 줄 적어보기.

이것만으로도 내일의 당신은 분명 "고마워요"라고 말해줄 것입니다. 전부 한꺼번에 하지 않아도 괜찮습니다. 65점이면 충분합니다. 하나씩 해 나갑시다.

• Conventional Commits (conventionalcommits.org)
• Google Engineering Practices — Code Review Developer Guide 「Small CLs」
• git 공식 문서 (git revert / git reset / git bisect / git add -p)
• AI 지원 개발로 인해 PR이 대형화되고 리뷰 부하가 증가하는 경향에 관한 각종 조사 및 벤더 리포트 (2026)
• 도구: commitlint / husky / lefthook / semantic-release / gitleaks