병목은 '생성'이 아니라 '검증'으로 이동했다
2026년 현재 AI 코딩 도구 채택률은 이미 90%를 넘었다(JetBrains, 2026). 도입 여부를 논쟁하던 시대는 끝났다. 지금 테크 리드가 직면한 진짜 문제는 다르다. DORA 2026 데이터가 이를 명확하게 보여준다. AI 도입 이후 개인 생산성은 올랐다—PR은 98% 더 많이 열렸다. 그런데 PR 리뷰 시간은 441% 늘었고, PR당 인시던트는 242% 증가했다. 속도는 생성 단계에서 회복됐지만, 손실은 검증 단계에서 다시 발생하고 있다. 이 구조를 이해하지 못한 채 도구만 빠르게 도입하면, 팀은 더 빠르게 망가진다.
세 개의 CLI 에이전트: 뭘 고르고 언제 쓰나
dev.to의 개발자 도구 비교 분석(Max Mendes, 2026)에 따르면 현재 터미널 기반 AI 코딩 에이전트는 Claude Code, OpenAI Codex CLI, Gemini CLI 세 축으로 수렴하고 있다. 선택지가 명확해졌다는 건 좋은 신호지만, 고르는 기준이 여전히 흐릿한 팀이 많다.
실용적인 구분은 이렇다. Claude Code는 예측 가능한 diff와 신중한 편집이 필요할 때—특히 코드 리뷰와 리팩토링에서 기본값으로 쓸 만하다. 모델이 불확실할 때 스스로 인정하는 경향이 있어서 신뢰 비용이 낮다. Codex CLI는 오케스트레이션이 필요한 시나리오에 맞다. Agents SDK와 추적(tracing) 레이어가 붙어 있어서 내부 자동화나 멀티스텝 파이프라인을 짤 때 강점이 드러난다. Gemini CLI는 컨텍스트 윈도우(100만 토큰)가 필요한 대형 코드베이스 작업에서 병렬 테스트해볼 만하다. 단, 벤치마크 수치보다 실제 내 레포에서의 체감 속도로 판단해야 한다.
한 가지 주의할 것: 이 세 도구는 모두 'MCP(Model Context Protocol)' 위에서 동작한다. 2026년 MCP SDK 월간 다운로드는 9,700만 건, 공개 서버 수는 13,000개를 넘겼다. MCP는 선택이 아니라 인프라다. 더 좋은 배관은 더 빠른 접근을 의미하고, 그건 동시에 보안 실수가 더 비싸진다는 뜻이기도 하다.
596개 사이트가 증명한 것: AI 생성 코드는 보안을 건너뛴다
속도를 올리면 무엇이 빠질까. 데이터가 있다. 보안 스캐너 UNPWNED를 운영하는 개발자 Razazu가 2개월간 596개 프로덕션 도메인을 스캔한 결과(dev.to, 2026)는 충격적이다.
- 81.6% — rate limiting 없음. 지금 이 순간 무제한 브루트포스 공격이 가능하다
- 66.9% — CSP 헤더 없음. XSS 하나로 페이지 전체가 장악된다
- 52.7% — DMARC 없음. 도메인을 사칭한 피싱 메일이 Gmail 받은편지함까지 도달한다
- 92.6% — DNSSEC 없음. DNS 스푸핑에 무방비 상태다
평균 보안 점수는 100점 만점에 70.8점. 대학 중간고사 통과점이지, 프로덕션 기준이 아니다.
왜 이런 일이 반복되나. 이유는 세 가지다. 첫째, AI 도구는 코드 레이어에서 작동하지 rate limiting이나 DMARC 같은 런타임·인프라 설정을 생성하지 않는다. Cursor나 Claude에게 "로그인 폼 만들어줘"라고 하면 동작하는 폼은 나온다. 그러나 분당 5회 제한, CSP 헤더, DMARC 레코드는 따라오지 않는다. 둘째, Next.js·SvelteKit·Nuxt 같은 프레임워크는 기본값이 불안전하다. 보안 설정은 개발자 몫으로 남겨져 있다. 셋째, Vercel·Netlify는 무료 SSL과 배포를 제공하지만 rate limiting과 이메일 보안은 제공하지 않는다. '배포됨'과 '안전함' 사이의 간극이 눈에 보이지 않는다.
AI 코드 리뷰를 시스템으로 만드는 12가지 게이트
생성 속도를 팀이 제어할 수 없다면, 검증 구조라도 설계해야 한다. TypeScript PR 병합 전 체크리스트를 공유한 개발자 Johnny Lemonny(dev.to, 2026)의 프레임워크는 현장에서 즉시 쓸 수 있는 형태로 정리돼 있다.
핵심만 추리면 이렇다.
범위 제어: AI는 요청하지 않은 파일까지 수정하려는 경향이 있다. PR이 수정해야 할 파일 수를 초과하면 일단 의심하라. 버그 하나를 고치는 PR이 8개 파일을 건드린다면 스코프가 오염된 것이다.
타입 경계 명시: data: any는 AI 생성 코드의 단골 패턴이다. 입력 타입, 출력 타입, API 계약이 명시적이지 않으면 통과시키지 않는다. TypeScript를 쓰는 이유가 있다.
런타임 검증 확인: TypeScript 타입은 컴파일 타임에만 존재한다. 외부 입력—request body, webhook, 환경변수, 써드파티 API 응답—은 반드시 런타임 검증(Zod 등)이 붙어야 한다. 타입만 있고 검증이 없으면 false sense of safety다.
실패 경로 검토: AI 생성 코드는 성공 경로는 잘 처리하지만 실패 경로를 자주 건너뛴다. 의존성이 다운됐을 때, 페이로드 형태가 바뀌었을 때, 작업이 절반만 성공했을 때—이 세 시나리오를 명시적으로 물어보라.
롤백 가능성: AI는 필요 이상으로 큰 패치를 만들기 쉽다. 변경이 격리돼 있는지, 피처 플래그 뒤에 있는지, 데이터 마이그레이션 리스크가 없는지 확인하라.
테크 리드가 지금 설계해야 할 것
세 데이터 포인트가 같은 방향을 가리킨다. 도구는 빠르다. 보안은 기본값으로 빠진다. 리뷰는 시스템이 없으면 병목이 된다.
내일 당장 할 수 있는 것은 세 가지다.
첫째, 팀에 사용 중인 AI 코딩 도구 목록을 만들고, 각 도구가 생성하는 코드 유형을 매핑하라. Claude Code가 리팩토링 diff를 만들고 있다면 보안 설정을 별도로 생성하는 워크플로우가 필요하다.
둘째, UNPWNED 같은 수동 스캐너를 CI 파이프라인에 연결하거나, 최소한 배포 전 보안 헤더 체크를 자동화하라. rate limiting, CSP, DMARC는 30분 안에 추가할 수 있다. 미루는 이유는 모르는 것뿐이다.
셋째, AI 코드 리뷰 체크리스트를 팀 PR 템플릿에 내장하라. 리뷰어의 기억에 의존하는 순간 체크리스트는 사라진다. 구조에 박아넣어야 작동한다.
전망: 속도 경쟁은 끝났다, 통제 구조 경쟁이 시작됐다
2026년 하반기부터 AI 코딩 도구의 차별화 포인트는 생성 속도에서 거버넌스 레이어로 이동할 것이다. 어떤 도구가 더 빠른 코드를 만드느냐가 아니라, 어떤 팀이 AI 생성물을 더 빠르게 검증하고 안전하게 배포할 수 있는 구조를 갖췄느냐가 경쟁력이 된다.
MCP 표준화로 도구 간 통합이 쉬워질수록, 보안 실수의 파급 범위도 넓어진다. 도구를 쓰는 속도만큼 통제 구조를 설계하지 못하면, 빠름은 오히려 리스크 가속기가 된다. AI-First 팀의 진짜 역량은 프롬프트 잘 쓰는 개발자가 아니라 생성-검증-배포의 전체 루프를 시스템으로 설계할 수 있는 테크 리드에게서 나온다.