TECH 으로 돌아가기
TECH HACKER NEWS 1주 전 6분 읽기 23 READS

AI가 코드를 쏟아내는 시대, Git은 이대로 괜찮을까?

AI가 코드를 쏟아내는 시대, Git은 이대로 괜찮을까?

요즘 코드는 누가 쓰고 있나요

불과 몇 년 전만 해도 코드는 사람이 손으로 한 줄 한 줄 썼잖아요. 그런데 요즘은 어때요. 커서(Cursor), 클로드 코드(Claude Code) 같은 AI 코딩 에이전트한테 "이 기능 만들어줘" 하면 순식간에 수백 줄이 뚝딱 나와요. 심지어 한 명이 에이전트 여러 개를 동시에 굴리면서, A는 이 기능, B는 저 버그, C는 리팩터링을 병렬로 시키기도 하고요.

여기서 슬슬 이상한 게 느껴지기 시작해요. 우리가 매일 쓰는 버전 관리 도구, 그러니까 Git 말인데요. Git은 애초에 '사람이 사람 속도로 커밋을 쌓는' 걸 전제로 15년도 더 전에 설계된 도구예요. 리누스 토르발스가 리눅스 커널 개발자들이 이메일로 패치를 주고받던 시절을 위해 만든 거잖아요. 그런데 지금은 사람이 아니라 지치지 않는 에이전트 여러 대가 코드를 쏟아내는 시대가 됐어요. 과연 Git은 이 변화를 감당할 수 있을까요? 바로 이 질문을 정면으로 다룬 글이 나왔어요.

Git이 삐걱대는 지점들

무엇이 문제인지 하나씩 풀어볼게요.

첫째, 커밋의 의미가 흐려져요. 원래 커밋 메시지는 사람이 "내가 왜 이걸 이렇게 바꿨는지"를 남기는 편지 같은 거였어요. 그런데 에이전트가 5분마다 커밋을 찍어대면, 커밋 히스토리가 사람이 읽으라고 만든 이야기가 아니라 그냥 기계의 작업 로그가 돼버려요. 나중에 git log를 봐도 무슨 흐름인지 파악이 안 되는 거죠.

둘째, 병렬 작업의 충돌이에요. 이게 뭐냐면, 에이전트 여러 대가 동시에 같은 파일을 건드리면 나중에 그 결과들을 합칠 때 머지 충돌(merge conflict)이 잔뜩 생겨요. 사람 둘이 같은 줄을 고쳐도 충돌이 나는데, 열 대가 달려들면 그 충돌을 정리하는 데 오히려 사람이 더 많은 시간을 쓰게 돼요. 속도를 얻으려고 에이전트를 붙였는데 병목이 뒤로 옮겨간 셈이죠.

셋째, 리뷰가 안 따라가요. 사람은 하루에 코드 몇백 줄 검토하기도 벅찬데, 에이전트는 그 사이에 수천 줄을 만들어내요. Git의 diff(바뀐 부분만 보여주는 화면)는 '글자가 어떻게 달라졌나'만 보여줄 뿐, '이 변경이 원래 의도와 맞나'는 알려주지 못하거든요.

그래서 버전 관리는 어떻게 바뀔까

글이 짚는 방향을 정리하면 이래요. 지금 당장 현장에서 쓰이는 임시방편은 git worktree예요. 이게 뭐냐면, 하나의 저장소에서 브랜치마다 작업 폴더를 따로 떼어내는 기능인데요, 에이전트마다 격리된 작업 공간을 하나씩 쥐여줘서 서로 안 밟게 하는 용도로 요즘 재발견되고 있어요.

더 나아가서는 '글자의 차이'가 아니라 '의도의 차이'를 이해하는 버전 관리가 필요하다는 얘기가 나와요. 예를 들면 여러 에이전트가 각자 다른 방식으로 같은 기능을 구현하게 한 뒤, 테스트를 통과하는 결과만 골라 채택하는 식이에요. 코드를 '순서대로 쌓는 히스토리'가 아니라 '여러 실험을 동시에 돌리고 그중 이기는 걸 뽑는 후보군'으로 다루는 거죠. 에이전트의 중간 상태를 통째로 저장했다가 되돌리는 체크포인트 개념도 같이 거론돼요.

업계 흐름에서 보면

사실 "Git이 낡았다"는 도전은 전에도 있었어요. 페이스북(메타)이 대규모 저장소를 감당하려고 만든 Sapling, 러스트 진영에서 나온 Pijul, 그리고 요즘 주목받는 Jujutsu(jj) 같은 새 버전 관리 도구들이 그거예요. 재밌는 건, 이들이 원래는 '거대한 모노레포'나 '더 나은 브랜치 모델' 같은 사람 중심 문제를 풀려고 나왔는데, 이제는 그 논의의 무게중심이 AI 에이전트를 어떻게 감당하느냐로 옮겨가고 있다는 점이에요. 문제의 성격 자체가 달라진 거죠.

한국 개발자에게 주는 시사점

거창한 새 도구를 당장 도입하라는 얘기는 아니에요. 다만 팀에서 AI 에이전트를 본격적으로 쓰기 시작했다면, 지금부터 worktree로 에이전트별 작업 공간을 분리하고, 큰 변경은 잘게 쪼개 리뷰 가능한 단위로 관리하는 습관을 들여두면 좋아요. 커밋 메시지를 에이전트한테 맡기더라도 '사람이 읽을 요약'은 따로 챙기는 것도요. 결국 병목은 코드를 만드는 속도가 아니라 그걸 검토하고 합치는 속도로 옮겨가고 있으니까요.

마무리

"코드를 사람이 쓰던 시대의 도구로, 기계가 쓰는 시대를 버틸 수 있을까" — 이게 이 글의 핵심 질문이에요. 여러분은 지금 에이전트가 쏟아내는 변경을 어떻게 관리하고 계세요? Git이 결국 진화해서 살아남을 것 같으세요, 아니면 언젠가 완전히 새로운 도구로 갈아타게 될까요?


🔗 출처: Hacker News

SOURCE · HACKER NEWS
원문 전체 보기 → https://entire.io/blog/how-version-control-will-evolve-for-t...
SHARE
처리 중...