숫자 세 개가 같은 주에 등장했다. 구글 내부 신규 코드의 75%가 AI 생성이라는 Cloud Next 2026 발표, Stanford AI Index 2026의 22~25세 개발자 고용 20% 감소 통계, 그리고 Cursor·Claude Code 같은 AI 코딩 에이전트가 IDOR(Insecure Direct Object Reference) 취약점을 구조적으로 놓친다는 실증 사례. 각각 따로 읽으면 흥미로운 뉴스지만, 테크 리드 입장에서 세 개를 동시에 놓고 보면 불편한 질문이 도출된다. AI가 코드를 쓰는 시대, 우리 팀은 무엇을 다르게 설계해야 하는가.
신호 1. AI 생성 비율 75%—이건 자랑이 아니라 경고다
순다르 피차이는 Cloud Next 2026 키노트에서 구글 엔지니어들이 작성하는 신규 코드 중 75%가 AI로 생성된 후 엔지니어 승인을 거친다고 밝혔다. 불과 반년 전인 지난 가을 50%에서 뛴 수치다. 에이전트와 엔지니어가 협력한 코드 마이그레이션 속도는 엔지니어 단독 대비 6배 빨랐다고도 했다.
이 숫자를 생산성 지표로만 읽는 건 절반만 읽는 것이다. 핵심은 '엔지니어 승인'이라는 병목에 있다. 생성량이 50%에서 75%로 늘었다는 건, 같은 수의 시니어가 검토해야 할 AI 산출물의 양이 1.5배로 늘었다는 뜻이기도 하다. 리뷰 프로세스를 그대로 두고 생성량만 늘리면 승인이 형식화된다. '빠르게 LGTM'이 기본값이 되는 순간, 코드 품질의 실질적인 게이트키퍼가 사라진다.
구글 규모에서 이 수치가 가능한 이유는 내부에 Gemini Enterprise Agent Platform, Vertex AI 기반의 체계적인 에이전트 관리 인프라가 있기 때문이다. 당신 팀에서 AI 생성 비율만 따라가려 하면, 구조 없이 속도만 올리는 꼴이 된다.
신호 2. 주니어 고용 20% 감소—진짜 문제는 파이프라인이 끊긴다는 것
Stanford AI Index 2026은 22~25세 소프트웨어 개발자 고용이 2024년 대비 약 20% 감소했다고 측정했다. 같은 기간 30~40대 시니어 개발자 헤드카운트는 오히려 증가했다. 보고서는 거시경제 요인도 인정하면서도, AI가 유의미한 기여 요인이라고 명시했다.
메커니즘은 단순하다. 시니어 개발자가 AI를 써서 보일러플레이트, 기본 CRUD, 루틴 테스트를 직접 처리하게 됐다. 과거라면 주니어에게 넘겼을 작업들이다. Stanford 보고서는 AI가 소프트웨어 개발 생산성을 평균 26% 향상시켰다고 측정했는데, 이 26%가 주니어 역할을 흡수한 것이다.
테크 리드 관점에서 더 불편한 함의가 있다. 시니어는 주니어를 거쳐야 만들어진다. 주니어가 줄어드는 속도만큼, 3~5년 뒤 시니어 공급도 줄어든다. 지금 채용 결정을 내리는 관리자들이 이 파이프라인 단절을 인식하지 못한 채 단기 비용 효율만 보고 있다면, 팀은 2~3년 후 시니어 인력난으로 되돌아올 청구서를 지금 쌓고 있는 셈이다.
실용적인 대응은 두 가지다. 주니어 온보딩을 'AI 감독자 역할'로 재설계하거나, 기존 주니어 포지션에 AI 활용 역량을 필수 조건으로 넣어 학습 경로를 바꾸는 것. AI가 대체한 루틴 작업 대신, AI 산출물 검증·프롬프트 설계·테스트 명세 작성 같은 역할로 진입 경로를 재정의해야 한다.
신호 3. IDOR—AI는 인증은 알지만 인가는 모른다
dev.to에 올라온 실증 사례 하나가 AI 생성 코드의 구조적 맹점을 정확히 짚었다. Cursor로 대부분 빌드된 사이드 프로젝트를 리뷰했더니, 모든 라우트에 JWT 인증 미들웨어가 붙어 있는데도 /api/documents/:id 엔드포인트에 소유권 검증이 없었다. 로그인만 된 사용자라면 누구든 다른 사람의 문서를 ID 순회로 전부 읽어올 수 있는 구조였다.
이유는 명확하다. AI 코딩 에이전트(Cursor, Claude Code, Copilot 모두)는 수백만 개의 튜토리얼과 StackOverflow 답변으로 학습됐다. 튜토리얼은 인증(Authentication)은 가르치지만 인가(Authorization)는 거의 가르치지 않는다. "인증된 사용자인가"는 묻지만, "이 사용자가 이 리소스에 접근할 권한이 있는가"는 묻지 않는다. 프롬프트에 없으면 코드에도 없다.
픽스 자체는 세 줄이다. doc.userId !== req.user.id를 확인하고 403을 반환하면 된다. 하지만 팀 차원의 문제는 이 세 줄이 누락됐을 때 아무도 알아채지 못했다는 것이다. AI가 생성한 코드는 구조적으로 깔끔해 보인다. 미들웨어도 있고, 에러 처리도 있다. 그래서 리뷰어가 '보안 관련 체크리스트'를 별도로 갖고 있지 않으면 그냥 통과된다.
이 패턴이 IDOR에만 국한되지 않는다는 점이 중요하다. AI는 프롬프트가 요구한 기능은 구현하지만, 프롬프트가 명시하지 않은 보안 제약은 기본적으로 생략한다. 소유권 검증, 레이트 리미팅, 감사 로그—이것들은 기능 설명에 포함되지 않는 한 AI 산출물에 등장하지 않는다.
팀 설계를 바꿔야 할 세 가지 결론
세 신호를 종합하면 팀 설계에서 바꿔야 할 지점이 세 개로 수렴한다.
첫째, AI 생성 비율과 리뷰 역량을 함께 스케일해야 한다. 생성량이 늘면 리뷰 품질이 희석된다. 리뷰어가 "AI가 썼으니 괜찮겠지"라는 인지 편향에 빠지지 않도록, AI 산출물 전용 리뷰 체크리스트와 자동 정적 분석(semgrep 등 소유권 검증 패턴 탐지 포함)을 파이프라인에 포함시켜야 한다.
둘째, 주니어 역할을 재정의하지 않으면 시니어 파이프라인이 끊긴다. 지금 당장 채용 비용을 아끼는 것처럼 보여도, 루틴 작업을 경험하며 성장하는 경로가 사라지면 3년 뒤 팀이 더 비싼 대가를 치른다. AI 활용 능력 자체를 주니어 역할의 핵심 역량으로 넣고, 진입 경로를 명시적으로 설계해야 한다.
셋째, 보안 명세는 프롬프트 안에 있어야 한다. AI에게 CRUD 엔드포인트를 만들어달라고 하면 CRUD만 나온다. 소유권 검증, 권한 범위, 감사 로그 요구사항을 프롬프트와 기술 명세에 명시하지 않으면 AI는 그걸 생략할 것이다. '보안은 나중에 추가'가 아니라, 기능 명세 시점부터 보안 요구사항을 함께 작성하는 프로세스가 필요하다.
AI가 코드를 빠르게 쓰는 시대의 테크 리드 역할은 속도를 따라가는 것이 아니다. AI가 놓치는 것을 구조적으로 잡는 팀을 만드는 것이다. 75%라는 숫자는 자랑이 아니라, 나머지 25%가 감당해야 할 무게를 보여주는 수치다.