AI 에이전트를 활용한 코딩은 이미 임계 속도를 넘어섰다. claude-code 같은 도구로 리팩터링을 맡기고, 여러 작업을 병렬로 돌리는 일이 일상이 되어가고 있다. 그런데 이상하게도 프로그래밍 바깥의 업무, 이를테면 문서 정리나 이슈 관리, 커뮤니케이션 동기화 같은 영역에서는 같은 수준의 확산이 일어나지 않고 있다. 개발자 타일러 오버비는 이 격차의 핵심 원인을 하나로 지목한다. 바로 버전 관리(version control)의 부재다.
git 없이 에이전트를 쓴다는 것
논지를 이해하려면 git 저장소 바깥에서 코딩 에이전트를 쓰는 상황을 상상해보면 된다. 겉보기에 사소한 리팩터링 하나조차도 스트레스와 오류의 온상이 된다. LLM이 어떤 부분을 어떻게 바꿨는지 추적하는 것이 거의 불가능해지기 때문이다. 변경 내용을 감사(audit)하는 일은 두 가지 시점에서 가치가 있다. 하나는 지금 이 순간, 다음 작업으로 넘어가기 전에 변경이 합리적인지 확인할 때이고, 다른 하나는 나중에 어떤 코드가 왜 그렇게 작성됐는지 되짚어볼 때다. 버전 관리가 없으면 이 두 가지가 모두 막힌다.
더 근본적인 문제는 되돌릴 방법이 없다는 데 있다. LLM이 코드베이스를 망가뜨렸을 때 복구할 수단이 없다면 그 자체로 위험하다. 흥미로운 것은 이 위험이 LLM이 '실수'를 저지르지 않아도 성립한다는 점이다. 모델이 아무리 똑똑하더라도, 사람이 프롬프트에서 설계 제약 하나를 빠뜨리는 것만으로 충분히 나쁜 결과가 나올 수 있다. 또한 버전 관리가 없으면 '개발 브랜치'와 '프로덕션'의 구분도 없고, 여러 LLM이 각기 다른 브랜치에서 병렬로 작업하게 만드는 것도 불가능하다. 오버비 자신도 작은 스크립트 하나를 맡길 때조차 늘 새 git 저장소를 만든다고 말한다. 오직 자신의 삶을 편하게 하기 위해서다.
여러 서비스에 걸친 '풀 리퀘스트' 계층
문제는 코딩 바깥에서 이런 가드레일과 편의 장치를 갖춘 도구를 찾기가 거의 불가능하다는 데 있다. 소프트웨어 개발 과정 자체가 이슈 트래커, 풀 리퀘스트, 문서, 이메일과 메신저, 회의로 흩어져 있고, 이 채널들 사이의 정보를 항상 최신 상태로 동기화하는 일만으로도 하나의 풀타임 업무가 된다. 예컨대 이메일 대화에서 나온 새 정보를 이슈에 반영하는 식으로, 한 서비스의 정보가 다른 서비스로 넘어가지 않은 지점을 LLM에게 찾게 하는 작업을 떠올려보자. 오버비는 오늘날의 모델이라면 이 일 자체는 해낼 수 있다고 본다. 진짜 걸림돌은 이 서비스들 중 어느 것도 LLM이 '제안한 행동을 사람이 검토하도록' 하는 내장 장치를 갖고 있지 않다는 데 있다.
그가 제시하는 한 가지 방향은 기존 서비스를 건드리지 않고 프록시를 두는 것이다. 이 프록시가 일종의 '풀 리퀘스트' 계층 역할을 하며, 여러 하위 서비스에 걸친 변경을 스테이징하고, 게시 전에 검토받게 한다. 에이전트는 이 프록시를 통해 행동하고, 프록시는 변경을 모아두었다가 사람이 검토·승인·게시할 수 있게 한다.
또 다른 방향은 아예 GitHub, 구글 독스 같은 외부 서비스를 떠나 모든 것을 git 안으로 끌어들이는 것이다. 오버비는 제인 스트리트(Jane Street)의 사례를 든다. 이 회사는 코드 리뷰 코멘트를 소스 코드 안에 주석 형태로 직접 삽입하는 방식으로 리뷰를 진행하는데, 모든 과정이 버전 관리로 추적되기 때문에 LLM을 리뷰에 끌어들이는 일이 손쉬워진다. 그렇다면 이슈도, 풀 리퀘스트와 코드 리뷰 메타데이터도, 구글 독스에 있던 설계 문서도 모두 코드와 같은 저장소에 마크다운으로 체크인해두면 어떨까. 그러면 코드와 이슈, 문서의 변경을 서비스 간 조율 없이 하나의 원자적(atomic) 업데이트로 처리할 수 있다.
한계와 실무적 함의
다만 오버비 스스로도 가장 큰 장애물을 인정한다. 어지간한 헌신 없이는 사람 입장에서의 사용자 경험이 크게 후퇴한다는 점이다. 넘지 못할 벽은 아니지만 상당한 작업이 필요하다는 것이다. 이 지점은 한국의 실무 팀에도 그대로 적용된다. 이슈·문서·리뷰를 저장소로 통합하자는 아이디어는 매력적이지만, 비개발 구성원까지 git 워크플로에 적응시키는 비용을 감당할 수 있느냐가 관건이다.
주목할 만한 통찰은 이 글의 'LLM'이라는 단어를 '주니어 개발자'나 '시니어 개발자'로 바꿔도 논지가 그대로 성립한다는 점이다. 브랜치와 변경 이력, 원자적 커밋이 주는 이점은 에이전트만의 것이 아니라 사람에게도 똑같이 유효하다. 결국 이것은 AI를 위한 인프라인 동시에 개발자 생산성 도구다. 오버비는 여기서 실용적인 조언을 덧붙인다. 개발자 생산성 도구에 투자를 끌어내기는 늘 어렵지만, 앞으로 몇 년간은 'AI 인프라'라는 명목이 승인을 받기 쉬울 것이고, 그것이 마침 개발 경험까지 개선한다면 그 명분을 전략적으로 활용해볼 만하다는 것이다.