AI 에이전트가 당신의 저장소(Repo)에 커밋하면 어떤 일이 벌어지는가

몇 주 전, 저는 AI가 위대한 평등화 도구가 아니라 위대한 증폭기(amplifier)라고 주장했습니다. AI는 개발자가 이미 가지고 있는 특성을 좋든 나쁘든 증폭시킵니다. AI를 사용하는 주니어는 주니어 수준의 코드를 시니어의 속도로 만들어냅니다. AI를 사용하는 시니어는 시니어 수준의 코드를 초자연적인 속도로 만들어냅니다.

이 포스트는 그 증폭이 눈에 보이게 나타나는 지점, 즉 당신의 Git 히스토리에 대해 다룹니다.

Claude Code, Cursor, GitHub Copilot, Windsurf와 같은 AI 코딩 어시스턴트(AI coding assistants)를 도입한 모든 팀은 그들의 저장소(repo)에 새로운 종류의 기여자를 도입하게 되었습니다. 때로는 명시적으로 태그(co-authored-by: claude)가 붙기도 하고, 때로는 보이지 않기도 합니다. 어느 쪽이든 AI가 생성하는 커밋(또는 AI의 도움을 받은 개발자가 생성하는 커밋)은 다르게 보이며, Git은 몇 주 안에 그 차이를 드러냅니다.

주의 깊게 살펴봐야 할 점과 왜 Git 실무의 기본 원칙이 그 어느 때보다 중요한지에 대해 설명하겠습니다.

두 가지 종류의 AI 보조 커밋

AI의 도움을 받아 몇 달 동안 운영된 저장소를 열고 다음 명령어를 실행해 보세요:

git log --oneline --since="3 months ago" | head -50

두 가지 패턴이 나타나는 것을 볼 수 있을 것입니다.

패턴 A — 주니어가 증폭된 커밋:

a7f3c21 fix stuff
9e2b8f4 more changes
12a4e5c update
...

거대한 커밋, 모호한 메시지, 명확한 범위(scope)의 부재. 개발자가 AI에게 "이 버그를 고쳐줘"라고 요청하고 AI가 만들어낸 결과물을 그대로 커밋한 것입니다. 한 달 뒤에는 이 커밋들이 실제로 무엇을 하는지 아무도 알 수 없게 됩니다.

패턴 B — 시니어가 증폭된 커밋:

a7f3c21 feat(search): add cursor-based pagination for users endpoint
9e2b8f4 perf(search): replace LIKE '%q%' with full-text index
12a4e5c test(search): add edge cases for empty query and unicode input
...

작고 원자적(atomic)이며 잘 설명된 커밋입니다. 개발자가 AI를 가이드하여 집중된 변경 사항을 생성하게 했고, 각 단위를 별도로 커밋했으며, 미래의 디버거(debugger)가 고마워할 만한 메시지를 작성했습니다.

동일한 AI. 대략적으로 동일한 프롬프트(prompts). 하지만 근본적으로 다른 커밋 히스토리.

이것이 중요한 이유

Pattern A 커밋으로 가득 찬 Git 히스토리는 이분법적 탐색 (bisect)을 할 수 없고, 깔끔하게 되돌릴 (revert) 수 없으며, 나중에 팀에 합류하는 그 누구도 이해할 수 없는 Git 히스토리입니다. 커밋의 세분성 (granularity)에 의존하는 모든 도구 — git bisect, git revert, git blame, git log --follow — 가 무용지물에 가까울 정도로 성능이 저하됩니다.

AI 이전에는 나쁜 커밋이 서두르는 개발자들로부터 발생했습니다. 나쁜 커밋을 작성하는 것 또한 노력이 필요했기 때문에(거대한 "fix stuff" 커밋이라 할지라도 개발자가 코드를 직접 작성해야 했습니다) 상대적으로 드물었습니다. 하지만 이제 나쁜 커밋을 만드는 것은 매우 쉽습니다. AI는 작동하는 코드를 빠르게 생성하며, 만약 개발자가 커밋을 구조화하기 위해 잠시 멈추지 않는다면, 모든 것이 구분되지 않은 하나의 덩어리 (blob)로 쌓이게 됩니다.

이것이 가장 순수한 형태의 증폭 효과 (amplification effect)입니다. AI가 나쁜 커밋 관행을 유발하는 것은 아니지만, 팀이 하루에 생성할 수 있는 나쁜 커밋의 양을 제한하던 마찰 (friction)을 제거해 버립니다.

숙련된 AI 보조 개발자들은 무엇이 다른가

Claude Code나 Cursor를 사용하여 실제 프로덕션 작업을 수행하는 숙련된 개발자와 함께 일해 본 적이 있다면, 그들이 데모에서 보여주는 방식과는 다르게 일한다는 것을 눈치챌 것입니다. 데모에서는 개발자가 AI에게 기능을 만들어 달라고 요청하고, 결과물을 수락한 뒤, 커밋하고 끝내는 모습을 보여줍니다. 숙련된 개발자들은 좀처럼 그런 식으로 일하지 않습니다.

그들이 실제로 하는 방식은 다음과 같습니다:

단 한 줄의 코드를 쓰기 전에 작업을 커밋 단위로 나눕니다. AI에게 프롬프트 (prompt)를 입력하기 전에 그들은 다음과 같이 생각합니다: "이 기능에는 세 개의 커밋이 필요해. 리팩토링 (refactor), 새로운 엔드포인트 (endpoint), 그리고 테스트 (tests). 한 번에 하나씩 작업하자." 그런 다음 기능 단위가 아닌 커밋 단위로 AI에게 프롬프트를 입력합니다.

AI 결과물에서 '하지 않은 것'을 검토합니다. AI는 프롬프트에 답하는 코드를 생성합니다. 하지만 당신이 묻지 않은 것들에 대해서는 답하지 않습니다. 숙련된 개발자들은 "어떤 예외 케이스 (edge case)가 누락되었는가? 어떤 에러가 처리되지 않았는가? 규모가 커지면(at scale) 어떻게 되는가?"를 자문하며 AI의 결과물을 읽고, 결과물이 실제로 준비될 때까지 반복 (iterate)합니다.

그들은 커밋 메시지를 직접 다시 작성합니다. 도구가 자동 생성된 메시지를 제공할 때조차, 시니어들은 이를 다시 작성합니다. 메시지는 '무엇(what)'이 아니라 '왜(why)'를 설명해야 하기 때문입니다. AI는 '무엇'이 변했는지는 볼 수 있지만, 그것이 왜 적절한 변경이었는지는 알 수 없습니다.

그들은 리팩터링(refactor)과 기능 추가(feature)를 분리합니다. 기존 코드를 리팩터링하는 동시에 새로운 기능을 추가하는 변경 사항은 바이섹트(bisect) 작업 시 악몽이 됩니다. 시니어들은 리팩터링을 먼저 수행하고, 이를 커밋한 뒤, 아무것도 망가지지 않았음을 검증한 다음, 별도의 커밋으로 기능을 추가합니다.

이 중 어느 것도 AI에만 국한된 것은 아닙니다. 이것들은 Git 위생(Git hygiene)의 기본 원칙입니다. AI는 이러한 원칙들을 건너뛰기 더 쉽게 만들기 때문에, AI가 이 원칙들을 극적으로 더 중요하게 만들었을 뿐입니다.

3개월 후, Git이 드러내는 것들

AI의 도움을 받은 지 어느 정도 시간이 흐른 팀에 다음 쿼리들을 실행해 보면, 증폭 효과(amplification effect)를 정량화할 수 있습니다.

PR당 커밋 수 — 집중도 테스트 (concentration test):

# 각 PR은 보통 몇 개의 커밋을 가지고 있는가?
gh pr list --state merged --limit 100 --json commits \
  --jq '.[] | .commits | length' | sort | uniq -c | sort -rn

AI의 도움을 받든 받지 않든, 건강한 팀은 대부분의 PR이 2~6개의 커밋으로 구성됩니다. 만약 갑자기 팀의 PR 절반이 500줄 이상의 코드에 단 1개의 커밋만을 포함하고 있다면, 그것은 주니어의 패턴이 증폭된 결과입니다.

커밋 메시지 품질 — 범위 테스트 (scoping test):

# 평균 커밋 메시지 길이
git log --since="3 months ago" --pretty=%s \
  | awk '{ sum += length($0); count++ } END { print "avg length:", sum/count, "chars" }'

좋은 커밋 메시지를 작성하는 팀은 제목 줄의 평균 길이가 50~~80자입니다. AI의 첫 번째 제안을 그대로 승인(rubber-stamp)하는 팀은 평균 20~~30자입니다. AI를 도입한 후 팀의 수치가 낮은 범위로 떨어졌다면, 그것은 하나의 신호입니다.

커밋당 변경된 파일 수 — 원자성 테스트 (atomicity test):

# 각 커밋은 평균적으로 몇 개의 파일을 수정하는가?
git log --since="3 months ago" --name-only --pretty=format:'---' \
  | awk '/^---$/ { if (count > 0) print count; count = 0; next } { count++ } END { if (count > 0) print count }'

...

원자적 커밋 (Atomic commits)은 1~5개의 파일에 영향을 미칩니다. 만약 AI 도입 후 평균 커밋 파일 수가 15개 이상으로 급증했다면, 커밋이 더 이상 개별 변경 사항에 국한되지 않고 있다는 뜻입니다.

이것은 단순히 보여주기 위한 지표 (vanity metrics)가 아닙니다. 각 커밋은 코드베이스가 얼마나 디버깅 가능하고 (debuggable), 되돌리기 쉬우며 (revertable), 이해하기 쉬운지 (understandable)와 직접적인 상관관계가 있습니다.

커밋 품질을 유지하는 세 가지 실질적인 습관

팀이 Git 히스토리를 망가뜨리지 않으면서 AI를 사용하게 하고 싶다면 다음과 같이 하세요:

1. AI에게 다음 작업을 요청하기 전에 커밋하세요. 각 AI 상호작용을 하나의 논리적인 작업 단위 (logical unit of work)로 취급하세요. 만약 하나의 단위가 여러 관심사 (concerns)를 포함하고 있다면, 그 단위는 너무 큰 것입니다. 먼저 작업을 세분화하고, 진행하면서 커밋하세요.

2. 커밋 메시지는 직접 작성하세요. 차이점 (diffs)으로부터 메시지를 자동으로 생성하는 도구들은 편리하지만, "이유 (why)"를 놓칩니다. 자신만의 언어로 메시지를 작성하는 데 30초만 투자하세요. 미래의 당신이 몇 시간을 아끼게 될 것입니다.

3. AI가 작성했더라도 커밋하기 전에 차이점 (diff)을 검토하세요. 시니어들은 이를 자동으로 수행합니다. 이는 번역문을 교정하는 것과 같습니다. AI가 의도 (intent)를 코드로 번역했다면, 당신은 그 번역이 당신이 의도한 바와 일치하는지 확인하는 것입니다. 검토되지 않은 커밋은 AI가 생성했든 아니든 부채 (liability)가 됩니다.

도움이 되는 작은 관례

일부 팀은 AI의 도움을 받았음을 명시적으로 표시하기 위해 커밋 메시지에 태그를 도입했습니다:

feat(auth): add SAML SSO provider [ai-assisted]

Implemented SAML 2.0 response parsing using python-saml library.
...

이는 선택 사항이며 팀의 선호에 따라 다를 수 있습니다. 하지만 이는 두 가지를 명확하게 해줍니다. 즉, AI가 관여했다는 사실과 인간이 구체적으로 어떤 기여를 했는지입니다. 몇 달 후 버그가 발생하여 누군가 해당 라인을 git blame으로 확인했을 때, 코드가 AI에 의해 생성되었는지와 인간이 어떤 맥락 (context)을 적용했는지 즉시 확인할 수 있습니다.

이것은 방어적인 조치("내 탓이 아니야, AI가 썼어")가 아닙니다. 정보 제공을 위한 조치("이 변경 사항을 이해하는 데 필요한 맥락은 이것입니다")입니다.

시니어들이 알고 있는 조용한 사실

만약 당신이 1년 동안 AI 어시스턴트를 진지하게 사용해 왔다면, 헤드라인에는 나오지 않지만 아마 다음과 같은 점을 눈치챘을 것입니다. 당신은 이전보다 커밋 위생(Commit hygiene)에 더 주의를 기울이게 되었다는 사실입니다.

AI 도입 전에는 대충 커밋을 작성하더라도 그 비용이 선형적으로 발생했습니다. 하루에 약 5~~10개의 커밋을 생성했으므로, 나쁜 습관이 미치는 영향 범위(Blast radius)가 제한적이었습니다. 하지만 AI 도입 후에는 하루에 30~~50개의 커밋을 생성합니다. 나쁜 습관은 한 분기 만에 코드베이스(Codebase)를 파괴할 것입니다.

이 새로운 환경에서 번창하는 시니어들은 AI를 가장 격렬하게 사용하는 사람들이 아닙니다. 그들은 AI의 생산성 향상이 다른 곳에서의 규율(Discipline) 강화와 반드시 병행되어야 한다는 점을 조기에 깨달은 사람들입니다. AI가 코드 작성에서 아껴준 모든 시간은 그 코드를 구조화하고, 리뷰하고, 문서화하는 데 소비됩니다.

이것이 바로 작동 중인 증폭기(Amplifier)입니다. 이를 잘 활용하면 당신의 결과물은 배가 됩니다. 하지만 부주의하게 사용하면 기술 부채(Technical debt) 또한 그만큼 빠르게 배가됩니다.

이 포스트는 AI와 엔지니어링 기초에 관한 시리즈의 일부입니다. 저의 저서 Git in Depth는 원자적 커밋(Atomic commits), 커밋 메시지 구조(Commit message anatomy), 그리고 이섹트 워크플로우(Bisect workflows)를 포함하여, AI가 당신이 이미 알고 있다고 가정하는 Git의 기초 원리에 대해 658페이지에 걸쳐 다루고 있습니다.

Git 및 엔지니어링 실무에 관한 저의 모든 글 보기: dev.to/mdenda__.