AI가 코드를 짜주는 시대, Git은 왜 더 중요해졌나

"AI가 코드를 다 써주는데, Git을 배워야 하나요?"

요즘 코딩을 시작한 분들에게 이 질문을 종종 받는다. 질문의 전제는 이렇다. Git은 코드를 직접 짜던 시절의 도구니까, 코드를 AI가 짜주면 Git도 같이 필요 없어지는 것 아니냐는 것. 내 답은 반대다. 순서가 거꾸로다. AI가 코드를 쓰기 때문에 Git이 필요하다.

나는 거의 모든 코드를 AI와 함께 쓴다. 이 블로그도, 운영 중인 앱들도 대부분 AI 코딩 도구로 만들었다. 그런데 그렇게 일하기 시작한 뒤로 Git을 쓰는 빈도는 줄기는커녕 몇 배로 늘었다. 왜 그런지, 네 가지 이유로 정리해봤다.

되돌릴 수 있어야 맡길 수 있다

AI에게 코드를 맡기는 일의 본질은 "내가 다 읽지 않은 변경을 내 프로젝트에 들이는 것"이다. 이게 무섭지 않으려면 조건이 하나 필요하다. 언제든 아무 일 없었던 상태로 되돌릴 수 있어야 한다.

커밋이 바로 그 장치다. 게임의 세이브 포인트처럼, 커밋을 찍어두면 AI에게 과감한 요구를 할 수 있다. "이 파일 구조를 통째로 바꿔봐" 같은 요청도 부담이 없다. 결과가 마음에 안 들면 커밋 시점으로 돌아가면 그만이니까. 반대로 세이브 포인트가 없으면 AI가 파일 열 개를 고쳐놓은 순간부터 되돌릴 방법이 없다. 뭐가 바뀌었는지도 모르는 채로, 망가진 코드와 단둘이 남는다.

이게 이론상의 걱정이 아니라는 걸 보여준 사건이 있다. 2025년 7월, 한 창업자가 Replit의 AI 에이전트로 앱을 만들다가 에이전트가 운영 데이터베이스를 통째로 삭제해버린 일이 있었다. 코드 변경을 멈추라고 지시해둔 상태였는데도 벌어진 일이라 꽤 화제가 됐고, Replit CEO가 직접 사과했다. 코드였다면 커밋으로 돌아가면 됐을 것이다. 이 사건의 교훈은 "AI는 위험하다"가 아니다. 되돌릴 장치 없이 AI에게 전권을 주면 안 된다는 것이다.

AI에게 일을 많이 시키는 사람일수록 커밋을 자주 찍는다. 과감함은 용기에서 나오는 게 아니라 되돌릴 수 있다는 확신에서 나온다.

AI의 결과물은 diff로 온다

AI와 일하면서 가장 크게 달라진 건 시간의 배분이다. 코드를 쓰는 시간은 확 줄었고, 코드를 읽는 시간이 그 자리를 채웠다. AI가 작업을 마치면 나에게 남는 일은 "무엇이 어떻게 바뀌었는지" 확인하는 것이고, 그걸 보여주는 형식이 바로 diff다. 바뀐 줄만 빨간색과 초록색으로 추려서 보여주는, Git의 그 화면.

그래서 요즘 개발에서 진짜 병목은 코드 생산이 아니라 검증이다. 코드를 만드는 비용이 떨어질수록 "이 변경을 믿어도 되나"를 판단하는 비용이 상대적으로 비싸진다. 그리고 그 판단의 단위가 diff다. diff를 읽을 줄 알면 AI가 한 일을 오 분 만에 파악하지만, 못 읽으면 전체 코드를 처음부터 뒤져야 한다.

diff 읽기는 코드 전체를 이해하는 것보다 훨씬 쉬운 기술이다. 바뀐 부분만 보면 되니까. 이 쉬운 기술 하나가 AI와 일하는 속도를 좌우한다.

AI 에이전트의 일터가 GitHub다

GitHub는 원래 사람과 사람이 협업하는 곳이었다. 브랜치를 나눠 작업하고, Pull Request로 변경을 제안하고, 리뷰를 거쳐 합친다. 그런데 요즘 AI 코딩 에이전트들이 정확히 이 방식으로 일한다. GitHub Copilot의 코딩 에이전트는 이슈를 할당받으면 브랜치를 만들어 작업하고 PR로 결과를 제출한다. Claude Code 같은 도구도 브랜치를 따고 커밋을 쌓고 PR을 올리는 흐름 위에서 움직인다.

다시 말해 브랜치·PR·리뷰는 이제 사람끼리의 협업 규약이 아니라 사람과 AI 사이의 인터페이스다. 이 개념들을 모르면 AI 에이전트에게 일을 시켜놓고도 결과물을 받을 줄 모르는 상황이 된다. 에이전트가 "PR을 올렸다"고 보고하는데 PR이 뭔지 모르면 거기서 멈춘다.

혼자 만드는 사람에게도 똑같이 적용된다. 나는 혼자 일하지만 매일 PR을 만든다. 협업할 사람이 있어서가 아니라, AI가 한 작업 묶음을 검토하고 승인하는 관문으로 PR만 한 형식이 없어서다. 1인 개발의 GitHub는 협업 도구가 아니라 AI 검수대다.

히스토리는 AI에게 주는 문맥이다

Git과 친해져야 하는 마지막 이유는 조금 미래 지향적이다. 커밋 히스토리가 AI의 입력이 된다.

AI 코딩 도구는 프로젝트의 맥락을 많이 알수록 좋은 결과를 낸다. 그리고 커밋 히스토리는 그 자체로 프로젝트의 연대기다. 언제 무엇을 왜 바꿨는지가 커밋 메시지에 남아 있으면, AI는 그걸 읽고 "이 코드는 지난달 버그 때문에 이렇게 고쳐진 것"임을 안다. 실제로 요즘 도구들은 막히면 스스로 git log와 git blame을 뒤져 맥락을 찾는다.

그래서 커밋을 잘게 쪼개고 메시지를 성의 있게 쓰는 습관은 미래의 나를 위한 것이기도 하지만, 이제는 미래의 AI를 위한 것이기도 하다. 대충 "수정"이라고 적힌 커밋 백 개보다, 무엇을 왜 바꿨는지 적힌 커밋 백 개가 쌓인 저장소에서 AI는 눈에 띄게 똑똑해진다. 기록이 곧 성능이 되는 시대다.

"그것도 AI가 해주면 되잖아요"

여기까지 읽고 이렇게 반문할 수 있다. 커밋도, 브랜치도, PR도 AI가 대신 해주면 되는 것 아니냐고.

맞다. 실제로 그렇게 된다. 나도 git 명령어를 직접 타이핑하는 일이 거의 없다. "여기까지 커밋해줘", "브랜치 따서 작업해줘"라고 말하면 AI가 알아서 한다. 명령어를 외우는 일의 가치는 정말로 떨어졌다.

판단은 위임이 안 된다. 어디까지 되돌릴지, 이 변경을 합쳐도 되는지, 지금이 세이브 포인트를 찍을 때인지. 이 결정들은 커밋과 브랜치와 diff가 무엇인지 아는 사람만 내릴 수 있다. 개념을 모르면 AI가 "머지 충돌이 났어요"라고 보고해도 무슨 상황인지, 뭐라고 지시해야 할지 알 수 없다. 운전기사가 있어도 목적지는 내가 정해야 하는 것과 같다.

그래서 "Git과 친해진다"의 의미가 달라졌다. 예전에는 명령어를 손에 익히는 것이었다면, 지금은 개념으로 대화할 수 있는 상태가 되는 것이다. 외울 것은 줄었고, 이해할 것은 남았다.

무엇부터 하면 되나

지금 AI로 코딩을 시작한 사람이라면, 명령어 책을 펴는 대신 네 개의 개념만 잡으면 된다.

1. 커밋: 되돌아갈 수 있는 세이브 포인트. AI에게 일을 시키기 전에 하나 찍는다.
2. 브랜치: 본 코드를 건드리지 않고 실험하는 분기. 과감한 시도는 브랜치에서 한다.
3. diff: 무엇이 바뀌었는지 보여주는 화면. AI의 작업 결과는 항상 diff로 확인한다.
4. PR: 변경 묶음을 검토하고 합치는 관문. 혼자여도 쓴다.

이 넷을 이해하고 나면 나머지는 AI에게 시키면 된다. "커밋해줘", "브랜치 따줘", "diff 보여줘", "PR 올려줘"라고 말할 수 있다면, 당신은 이미 Git과 충분히 친하다.

AI는 코드를 쓰는 부담을 덜어줬다. 그 대신 우리에게 남긴 일은 변경을 다스리는 일이고, 그 일의 언어가 Git이다. 코드를 안 짜는 시대일수록, 바뀐 것을 읽고 되돌리고 합치는 사람이 키를 쥔다.