이제 코드는 사람만 짜지 않는다 — '에이전트 시대의 Git'이라는 화두

'사람이 쓰는 Git'에서 '에이전트가 쓰는 Git'으로

Git이랑 GitHub는 사람이 코드를 짜고 사람이 리뷰하던 시절에 설계됐어요. 그런데 요즘은 AI 코딩 에이전트가 알아서 브랜치를 따고, 커밋을 수십 개씩 쌓고, PR까지 올리는 시대가 됐잖아요. 그러다 보니 '에이전트 시대에 맞는 Git 플랫폼'을 내세우는 새 프로젝트들이 하나둘 등장하고 있어요. 이번 항목도 그런 흐름 위에 있죠. 그래서 오늘은 특정 제품 자랑보다, '왜 버전 관리를 다시 생각해야 하나'라는 본질을 같이 짚어볼게요.

뭐가 문제냐면

기존 워크플로우가 깔고 있던 가정들이 하나씩 깨지고 있어요. 차근차근 풀어볼게요.

먼저 양과 속도예요. 사람은 하루에 몇 커밋이지만, 에이전트는 분 단위로 변경을 쏟아낼 수 있어요. 사람이 일일이 따라가며 리뷰하기가 벅차지죠. 다음은 작성자 추적이에요. '이 코드 누가 짰어?'라는 질문이 애매해져요. 사람인지, 에이전트인지, 어떤 모델인지 책임과 감사(audit) 기록이 필요해지거든요. 그리고 리뷰 방식도 바뀌어요. 줄 단위 diff로 한 줄 한 줄 보는 것보다, '원래 의도가 뭐였는지' 의미 단위로 보고 싶어지죠. 마지막으로 안전한 실행이에요. 에이전트가 만든 코드를 격리된 샌드박스에서 자동으로 돌려보고 검증하는 게 기본이 돼야 해요.

업계 맥락

이건 한 회사만의 고민이 아니에요. GitHub도 Copilot 코딩 에이전트로 '에이전트가 직접 PR을 올리는' 방향을 밀고 있고, Devin 같은 자율 에이전트, Graphite 같은 스택형 PR 도구도 비슷한 문제를 풀려 해요. 공통된 방향은 하나예요. 버전 관리를 '사람 중심'에서 '사람+에이전트 협업 중심'으로 다시 짜는 거죠.

한국 개발자에게

당장 GitHub 버리고 갈아타라는 얘기는 절대 아니에요. 다만 팀에 코딩 에이전트를 들이려 한다면, 지금 쓰는 브랜치 보호 규칙, CI 게이트, 작성자 표기 정책을 '에이전트가 대량으로 PR을 쏟아내는 상황'에 맞게 미리 점검해 두는 게 좋아요. 리뷰 병목이 터지고 나서 손대면 늦거든요. 누가 무엇을 머지할 수 있는지, 자동 테스트가 어디까지 막아주는지를 다시 그려보세요.