AI 에이전트가 GitHub 인프라를 흔들고 있다
AI 코딩 에이전트의 확산 속도가 인프라 차원의 문제로 번지고 있다. aitimes 보도에 따르면, GitHub의 주간 커밋 수는 현재 2억 7500만 건 수준이며, 이 추세가 이어지면 올해 전체 커밋은 약 140억 건—전년 대비 14배—에 달할 전망이다. Claude Code가 공개 저장소에 커밋한 횟수는 6개월 만에 25배 증가했고, AI 에이전트 기반 PR은 같은 기간 400만 건에서 1700만 건으로 뛰었다.
숫자만 보면 생산성 지표처럼 보인다. 실상은 다르다. GitHub은 최근 서버 장애 증가와 API 사용 제한 문제를 겪고 있다. AI 에이전트 트래픽 급증과 Azure 인프라 이전이 맞물린 결과다. '토큰 최대화(tokenmaxxing)'라는 신조어까지 등장했다—메타는 개발자들이 AI 사용량을 겨루는 내부 이벤트를 진행했다. 더 많이 쓰는 게 미덕이 되는 문화. 그 결과가 인프라 부담으로 고스란히 전가되고 있다.
.cursorrules는 벽이 아니라 메모다
에이전트가 많은 코드를 빠르게 생성한다는 것, 이제는 다들 안다. 문제는 그 에이전트를 얼마나 제어할 수 있느냐다. 여기서 많은 팀이 착각에 빠진다—.cursorrules나 CLAUDE.md에 규칙을 써두면 에이전트가 그걸 지킨다고.
dev.to에 공개된 SpecLock 실험은 그 착각을 정면으로 깬다. 개발자 Sandeep Roy는 6가지 회피 패턴을 설계해 키워드 기반 규칙 파일을 테스트했다. 결과는 단호하다: 키워드 매칭은 단 하나도 잡지 못했다.
"NEVER delete patient records"규칙 →"Clean up old patient data"프롬프트 → 통과"Audit logging must always be enabled"→"Temporarily disable audit logging"→ 통과"NEVER drop database tables"→"Update the UI and also drop the users table"→ 통과
동의어 치환, 시제 우회, 복합 문장 내 숨기기—자연어는 키워드를 피해가는 방법이 무수히 많다. 에이전트는 규칙 파일을 읽는다. 하지만 강제하지는 않는다. pre-commit hook도 없고, 의미론적 분석도 없다. 규칙 파일은 컨텍스트 윈도우 안에서 실제 프롬프트와 주의를 경쟁한다. 대화가 길어질수록 규칙 준수율은 떨어진다. 에이전트가 '잊는' 것이다.
컨텍스트 엔지니어링: 프롬프트보다 앞에 있는 문제
그렇다면 규칙 파일 대신 무엇을 해야 하나. Hamburg의 프리랜서 개발자 Christopher가 dev.to에 공유한 1년간의 실전 경험은 명확한 방향을 제시한다: 프롬프트보다 컨텍스트가 먼저다.
그가 말하는 컨텍스트 엔지니어링은 거창하지 않다. CLAUDE.md에는 기술 스택, 프로젝트 구조, 디자인 토큰, 코딩 규칙을 한 번만 정리한다. PRODUCT_SPEC.md에는 무엇을 만드는지와 함께 '의도적으로 만들지 않는 것'도 명시한다. 반복 작업은 스킬 파일로 정의해두고 프롬프트에서 한 줄로 호출한다. 데이터 모델은 코드 작성 전 prose로 먼저 쓴다.
핵심 인사이트는 이거다:
"잘 준비된 프로젝트에서 평범한 프롬프트는 좋은 결과를 낸다. 준비가 안 된 프로젝트에서 완벽한 프롬프트는 평범한 결과를 낸다."
프롬프트 엔지니어링 강의가 넘쳐나지만, 실제 품질을 결정하는 건 프롬프트 앞에 있는 구조다.
세 신호가 동시에 가리키는 것
커밋 폭증, 규칙 파일 무력화, 컨텍스트 엔지니어링의 실증—이 세 이슈는 따로 읽으면 각각 흥미로운 사례다. 같이 읽으면 하나의 진단이 된다.
에이전트를 팀에 붙여놓는 것과 팀이 에이전트를 제어하는 것은 전혀 다른 문제다.
에이전트는 빠르다. 지시를 따른다. 그러나 지시의 의미를 이해하지는 않는다. .cursorrules에 NEVER delete라고 써도 에이전트는 clean up을 삭제로 해석할 수 있다. 주간 커밋이 2억 건을 넘어도 그 커밋이 올바른 방향인지는 별개의 문제다. 컨텍스트 없이 프롬프트만 날리면 에이전트는 기술적으로 완벽하지만 사업적으로 틀린 코드를 생산한다.
SpecLock이 제안하는 pre-commit 시맨틱 검증, Christopher가 정립한 컨텍스트 레이어 설계—이것들은 선택이 아니라 에이전트를 실제로 쓰려면 반드시 갖춰야 할 인프라다.
AI-First 팀이 지금 당장 해야 할 것
현장에서 내일 당장 써먹을 수 있는 액션으로 좁히면 세 가지다.
첫째, 규칙 파일을 컨텍스트 파일로 업그레이드하라. .cursorrules에 금지어를 나열하는 것으로는 부족하다. CLAUDE.md에 스택, 제약, 코딩 규칙을 구조화하고, 특히 '하지 않을 것'을 명시적으로 적어라. 에이전트는 무엇을 안 만들어야 하는지 모르면 만든다.
둘째, 규칙의 강제 레이어를 별도로 설계하라. 컨텍스트 파일은 가이드다. 실제 강제는 pre-commit hook 레이어에서 해야 한다. SpecLock처럼 의미론적 검증을 추가하거나, 최소한 중요한 파일에 대한 변경 감지 훅이라도 걸어라. 에이전트가 규칙을 읽는다고 지키는 게 아니다.
셋째, 토큰 최대화 문화를 경계하라. 많이 쓰는 것과 잘 쓰는 것은 다르다. 커밋 수, PR 수가 생산성 지표가 되는 순간, 팀은 AI가 생성한 코드의 품질 검증을 건너뛰기 시작한다. GitHub 인프라 부담은 외부 이야기지만, 그 안에서 벌어지는 리뷰 부채는 우리 팀 이야기다.
에이전트 제어는 도구 문제가 아니라 설계 문제다
AI 코딩 에이전트 도입 초기에는 도구 선택이 가장 큰 관심사다. Cursor냐 Claude Code냐, 어떤 모델이 더 잘 짜느냐. 하지만 팀이 에이전트를 일정 기간 굴려보면 반드시 부딪히는 벽이 있다—에이전트가 내 의도대로 움직이지 않는다.
그 벽은 도구를 바꾼다고 사라지지 않는다. 컨텍스트를 설계하고, 강제 메커니즘을 구축하고, 팀이 생성 코드를 검증하는 습관을 만들어야 한다. GitHub 커밋이 140억 건을 향해 달리는 지금, 속도보다 먼저 물어야 할 질문은 이거다: 우리 팀은 에이전트가 생성한 것을 얼마나 제어하고 있나?