Google은 2026년 4월 기준 신규 코드의 75%를 AI가 생성한다고 공식 발표했다. Stripe의 내부 코딩 에이전트는 주당 1,300건 이상의 PR을 자동으로 머지하고, Mercari는 전체 임직원의 95%가 AI 도구를 실사용하며 1인당 아웃풋이 전년 대비 64% 증가했다. dev.to에서 공개된 빅테크 11개사 실사용 현황 분석에 따르면, 이 숫자들은 모두 내부 블로그·CEO 발언·공개된 내부 메모 등 1차 출처에 근거한다.
솔직히 말하자. 이 수치를 보고 "우리도 Cursor랑 Claude Code 깔면 되겠네"라고 생각했다면, 그게 바로 대부분의 팀이 L1에서 멈추는 이유다. 같은 분석은 대부분의 팀이 직면한 구조적 문제를 정확하게 짚는다. 도구는 설치돼 있다. 그런데 조직 지표에는 아무것도 안 잡힌다. AI 활용이 운영(L2), 고객 접점(L3), 자율 실행(L4)으로 연결되지 않으면 도구 설치는 개인 생산성 향상으로 끝난다. 빅테크와의 격차는 모델 선택의 문제가 아니다.
그렇다면 빅테크는 무엇이 다른가. 답은 코드베이스 설계 자체에 있다. Attractor Engineering 개념이 여기서 정확히 맞물린다. 이 설계론에 따르면 코드베이스는 미래 변경을 끌어당기는 '필드'이고, PR은 그 필드에 가해지는 힘이다. 좋은 구조가 있으면 다음 변경도 좋은 방향으로 자연스럽게 이끌리고, 나쁜 구조가 있으면 AI 에이전트도 그 나쁜 지름길을 반복해서 선택한다. AI가 PR을 빠르게 양산할수록 이 인력(引力)은 더 강해진다.
실제로 Claude Code가 코드베이스 전체를 입력 컨텍스트로 읽는다는 점을 생각해보자. 근처에 좋은 레퍼런스 구현이 있으면 AI는 그걸 모방한다. 반대로 편법 코드가 이미 존재하면 AI는 그것도 자연스러운 선택지로 취급한다. Stripe가 Cursor를 전사 배포하고 자체 에이전트 Minions로 주당 1,300+ PR을 만들어내는 배경에는, 에이전트가 좋은 제안을 내놓도록 설계된 코드베이스 필드가 먼저 있었다. 도구 도입보다 아키텍처 설계가 선행됐다는 뜻이다.
그러면 우리 팀에 적용할 때 무엇부터 봐야 하나. 세 가지 축으로 나눠서 생각해보자.
첫째, 어트랙터를 의도적으로 설계하라. 거대한 common 모듈, 용도가 모호한 헬퍼, 경계가 불분명한 서비스—이것들은 나쁜 어트랙터다. AI 에이전트는 이런 곳으로 변경을 반복해서 끌어당긴다. 명확한 책임 경계, 좋은 레퍼런스 구현, 타입 정의가 잘 된 API가 좋은 어트랙터다. AI-First 전환 전에 코드베이스의 '필드'를 먼저 정리해야 한다.
둘째, 소산(dissipation) 레이어를 강화하라. Attractor Engineering은 CI/CD·테스트·코드 리뷰를 '나쁜 힘을 제거하는 소산 시스템'으로 본다. AI가 PR 속도를 높일수록 이 레이어가 약하면 기술 부채가 코드베이스로 직접 유입된다. 반대로 너무 강하면 아무것도 못 움직인다. AI 생성 PR에 맞게 검증 강도를 재조정하는 작업이 필요하다.
셋째, ROI를 L2 지표로 측정하라. Google의 75%는 개인 생산성 지표가 아니라 조직 수준의 지표다. Mercari의 64% 아웃풋 증가도 마찬가지다. 팀 단위 PR 처리량, 배포 주기, 버그 발생률 같은 운영 지표가 움직이기 시작할 때 비로소 AI-First 전환이 실질적으로 작동하고 있다고 볼 수 있다.
도구 스택 측면에서도 한 가지 짚을 게 있다. 동일한 분석에 따르면 2026년 현재 코딩 에이전트 시장에서 Claude Code가 46%로 압도적 1위를 차지한다(Cursor 19%, GitHub Copilot 9%). SWE-bench Verified 기준 Claude Sonnet 4.6은 82.1%로 Gemini 3의 63.8%와 18포인트 차이가 난다. Meta의 내부 에이전트 DevMate도 Claude 기반이고, 일부 Google 엔지니어도 내부적으로 Claude Code를 쓴다고 알려져 있다. 팀에 AI 에이전트를 도입할 때 도구 선택 기준으로 삼을 만한 데이터포인트다.
현실적인 도입 경로를 이야기하자면, 대부분의 팀에게 빅테크의 L4(멀티에이전트 자율 실행)는 내년 목표가 아니다. 당장은 L2, 즉 AI 활용이 운영 지표에 잡히는 수준을 목표로 잡는 게 맞다. 그 전제 조건은 코드베이스 필드 정리, 검증 레이어 설계, 그리고 팀 전체의 AI 플루언시다. 도구부터 사는 팀과 아키텍처부터 설계하는 팀의 6개월 후 격차가 바로 지금 빅테크와 나머지 사이에 벌어진 그 격차다.
빅테크의 숫자는 허수가 아니다. 하지만 그 숫자에 도달하는 경로는 도구 설치가 아니라 설계 밀도에서 갈린다. AI-First 전환을 시작하는 팀 리드에게 가장 먼저 물어야 할 질문은 "어떤 AI 도구를 쓸 것인가"가 아니라, "우리 코드베이스가 AI에게 좋은 제안을 유도하는 필드인가"다.