병합된 PR 10개 중 4개에 이미 AI 코드가 들어가 있다. UNLV 연구팀이 개발한 PatchTrack이 오픈소스 프로젝트 255개의 PR을 분석해 내놓은 수치다. 그것도 개발자가 스스로 "ChatGPT를 썼다"고 밝힌 사례만 집계한 최솟값이다. 실제 AI 침투율은 이보다 훨씬 높을 가능성이 크다.
같은 시기, Vercel은 4월 19일 보안 인시던트를 공식 확인했다. 공격 벡터는 예상외로 단순했다—누군가 연결해둔 서드파티 AI 도구의 Google Workspace OAuth 앱이 침해됐고, 민감하게 표시되지 않은 환경 변수들이 노출 위험에 처했다. Vercel 측은 플랫폼 배포의 30% 이상이 이제 코딩 에이전트에 의해 시작된다고 밝혔다. 6개월 만에 1000% 증가한 수치다.
그리고 dev.to에 올라온 'Boring code is an organizational tell' 분석은 세 번째 경고를 전한다. 에이전트가 등장하기 전에도 '영리한 코드'는 조직의 복잡성을 반영했다. 에이전트가 등장한 이후, 그 복잡성은 제동 없이 가속된다.
세 가지 신호가 하나의 맥락으로 수렴한다
이 세 가지 사건을 따로 읽으면 각각 '흥미로운 연구', '벤더 보안 사고', '코드 품질 에세이'로 분류된다. 하지만 AI-First 워크플로우를 운영하는 팀 리드 입장에서 보면, 세 개는 같은 문제를 다른 각도에서 가리키고 있다.
코드베이스에 AI가 얼마나 들어와 있는지, 팀이 정확히 모른다.
PatchTrack 연구가 불편한 이유는 40.7%라는 숫자 자체가 아니다. 이 수치를 측정할 도구 없이 지금까지 팀을 운영해왔다는 사실이다. AI 코드가 어느 방식으로 얼마나 반영됐는지—완전 채택인지, 선택적 추출인지, 구조적 통합인지—를 추적하지 않았다면, 팀의 코드베이스에 대한 이해는 이미 불완전하다.
Vercel 사고는 그 불투명성이 보안 리스크로 직결된다는 걸 실증했다. 코딩 에이전트가 배포한 프로젝트는 인간이 배포한 것보다 AI 인퍼런스 프로바이더를 20배 더 많이 호출한다. 더 많은 외부 연결, 더 넓은 공격 표면. Vercel은 이미 2025년 7월 한 달에만 v0가 1만 7천 건의 비보안 배포를 차단했다고 밝혔다—NEXT_PUBLIC_ prefix에 DB 자격증명을 그대로 박아 넣는 패턴이 반복적으로 등장했다.
'Boring code' 분석은 이 문제의 근원에 있는 조직 구조를 짚는다. 코드 복잡성은 엔지니어의 영리함이 아니라, 영리함에 인센티브를 주는 조직 구조에서 나온다. 에이전트는 그 인센티브 구조를 그대로 학습한다. "에이전트는 자신 앞에 놓인 코드, 프롬프트, 예시에서 로컬 일관성을 최적화할 뿐—아키텍처 판단력을 행사하지 않는다." 영리한 패턴이 가득한 코드베이스에 에이전트를 풀면, 에이전트는 그 영리한 패턴을 충실하게 재생산한다.
팀 리드가 지금 당장 잡아야 할 세 가지
1. AI 코드 침투율 가시성 확보
40%가 넘는 코드가 AI에서 왔을 때, 그 사실을 모르는 것과 아는 것은 리스크 수준이 다르다. PatchTrack처럼 PR 단위로 AI 기여를 추적하는 도구를 도입하거나, 최소한 PR 템플릿에 AI 활용 여부를 명시하는 컨벤션을 팀에 심어라. '자기 공개(Self-Admitted)' 방식은 불완전하지만 시작점으로는 충분하다. 측정하지 않는 것은 통제할 수 없다.
2. 에이전트 액션에 대한 감사 추적 설계
Vercel 사고의 핵심 교훈은 "어느 에이전트가, 언제, 누구의 자격증명으로 이것을 했는가"에 답하지 못하면 보안 포스처가 없다는 것이다. 에이전트 세션, 배포, 권한 부여—이 세 가지는 반드시 귀속 가능하고 검토 가능해야 한다. OAuth 앱 연결에 대한 승인 프로세스를 높이고, 민감 환경변수를 명시적으로 분리하는 것은 지금 당장 할 수 있는 최소 조치다.
3. 코드 리뷰에서 '복잡성 거부권' 구조 만들기
'Boring code' 분석이 지적하는 것은 코드 리뷰가 정확성 검사는 하지만 복잡성 검사는 거의 하지 않는다는 점이다. 에이전트 시대에 이 공백은 치명적이다. 엔지니어가 하루에 수십 개의 아키텍처 마이크로 결정을 프롬프트를 통해 내리고, 에이전트는 그것을 망설임 없이 실행한다. "이 PR이 코드베이스를 더 이해하기 어렵게 만드는가"를 리뷰 기준으로 명시적으로 추가하라. 그리고 그 거부권이 시니어의 코드에도 동등하게 적용되는 문화가 없다면, 리뷰는 형식에 불과하다.
AI가 코드를 짜는 시대의 팀 리드 역할
PatchTrack 연구에서 AI 코드가 거부된 가장 큰 이유는 코드 품질이 아니었다—팀의 코딩 관습, 아키텍처 철학과 맞지 않아서였다. AI가 기술적으로 올바른 코드를 제안해도 팀의 맥락을 모르면 걸러진다. 지금까지는 그게 방어막이었다.
하지만 에이전트가 코드베이스 전체를 컨텍스트로 갖는 시대가 되면, 그 방어막은 얇아진다. 'Boring code' 분석이 명명한 '의도 부채(intent debt)'—결정 이유가 프롬프트의 컨텍스트 윈도우와 함께 사라지는 문제—는 기술 부채와 달리 측정도, 상환도 어렵다. 인시던트에서 발견된다.
팀 리드가 AI-First 워크플로우에서 통제해야 하는 것은 AI가 쓰는 코드의 양이 아니다. AI가 팀의 아키텍처 철학을 학습할 수 있도록 그 철학을 코드와 문서로 명시화하는 것, 에이전트의 액션이 추적 가능하도록 파이프라인을 설계하는 것, 그리고 복잡성이 유입되는 속도보다 리뷰와 이해가 뒤처지지 않도록 팀의 흡수 속도를 높이는 것이다.
AI 코드 40%는 임계값이 아니라 시작점이다. Vercel의 데이터대로라면 에이전트 배포는 6개월 만에 10배가 됐다. 그 속도라면 팀이 통제 구조를 설계하지 않은 채 보내는 다음 6개월은, 지금까지와 전혀 다른 코드베이스를 마주하는 시간이 될 것이다.