AI 도구 도입을 결정하는 순간, 대부분의 팀은 '얼마나 빨라지나'만 본다. 하지만 현장에서 실제로 터지는 문제는 다른 곳에 있다. 이번 주 세 개의 사례가 동시에 터졌다. 애플 시리 팀의 AI 코딩 부트캠프, Claude 성능 너프 논란, 그리고 AI 에이전트로 600대의 방화벽을 뚫은 FortiGate 공격. 각각 따로 보면 그냥 뉴스다. 같이 놓고 보면 AI-First 전환을 시도하는 모든 팀이 반드시 직면하는 세 가지 균열의 구조가 보인다.
균열 1. 역량 격차 — 도구를 사도 쓰는 팀이 없다
디인포메이션 보도에 따르면, 애플은 WWDC를 두 달 앞두고 시리 개발팀 엔지니어들을 수 주짜리 AI 코딩 부트캠프에 강제 투입했다. 표면적으로는 개발 속도 만회용 처방이지만, 속을 들여다보면 더 불편한 진실이 있다. 애플 내 다른 팀들은 이미 Claude Code 같은 AI 코딩 도구에 막대한 예산을 투입해 생산성을 끌어올리고 있었는데, 정작 AI 제품을 만들어야 하는 시리 팀이 '낙후된(Laggard) 조직'이라는 내부 평가를 받고 있었다는 점이다.
이건 애플만의 문제가 아니다. AI 도구를 팀에 도입할 때 가장 먼저 터지는 균열이 바로 이 역량 격차다. 라이선스를 사고, 툴을 붙이고, 정책 문서를 만드는 것과 팀원이 실제로 도구를 '일의 흐름'에 녹여 쓰는 것 사이의 간극은 생각보다 훨씬 크다. 애플의 해법은 강제 부트캠프였다. 하지만 WWDC 일정에 쫓겨 수 주 만에 역량 격차를 메우려는 시도가 얼마나 실효성이 있을지는 회의적이다. AI-First 온보딩은 이벤트가 아니라 워크플로우 설계다. 도구를 언제, 어떤 맥락에서, 어떤 방식으로 쓰는지를 팀 표준으로 정착시키는 데 걸리는 시간을 처음부터 로드맵에 박아야 한다.
균열 2. 모델 신뢰성 — 어제 되던 게 오늘 안 된다
두 번째 균열은 더 조용하게, 그래서 더 위험하게 터진다. AI 매터스와 포천, 벤처비트 보도를 종합하면, 앤트로픽이 Claude의 기본 '노력 수준(effort level)'을 사전 공지 없이 'medium'으로 낮췄다는 사실이 개발자 커뮤니티 전반의 집단 반발로 이어졌다. AMD AI 그룹의 시니어 디렉터 스텔라 로렌조는 6,852개의 Claude Code 세션 데이터를 분석해 GitHub에 공개했고, 한 AI 벤치마킹 업체는 Claude Opus 4.6의 정확도가 83.3%에서 68.3%로 약 15%p 하락했다는 재평가 데이터를 발표했다.
앤트로픽 측은 '토큰 과소비에 대한 사용자 피드백을 반영한 조치'라고 해명했다. 기술적으로는 이해 가능한 결정이다. 컴퓨팅 비용과 서비스 품질 사이의 줄다리기는 모든 AI 서비스 기업의 숙제다. 문제는 사전 고지 없이 바꿨다는 점이다. 팀이 특정 AI 도구의 성능을 믿고 파이프라인을 짜고, 품질 기준을 설정하고, 고객에게 약속을 했다면, 모델 성능이 조용히 바뀌는 순간 그 모든 전제가 무너진다. 이번 논란은 AI 도구를 팀 인프라로 채택할 때 '모델 버전 고정'과 '성능 변화 모니터링'을 워크플로우에 반드시 포함시켜야 한다는 걸 다시 한번 증명했다. 어제 되던 게 오늘 안 되는 환경에서 품질을 보장하려면, 신뢰는 약속이 아니라 측정으로 유지해야 한다.
균열 3. 자동화 통제 — 승인 루프 없는 에이전트는 무기가 된다
세 번째 균열은 가장 극단적인 형태로 현실화됐다. AWS 보안 블로그와 dev.to의 분석에 따르면, 2026년 1월 11일부터 2월 18일까지 5주 동안 한 공격자가 AI 에이전트를 활용해 55개국 600대 이상의 FortiGate 방화벽을 침해했다. 공격의 핵심은 ARXON이라는 MCP(Model Context Protocol) 서버였다. ARXON은 DeepSeek과 Anthropic의 Claude에 정찰 데이터를 먹여 구조화된 공격 계획을 생성했고, Claude Code는 사전 승인 설정 파일을 통해 매 명령마다 인간의 확인 없이 자율 실행했다.
Amazon의 CISO CJ 모세스는 이 사건을 '기술 수준이 낮은 공격자도 상용 AI를 활용하면 과거에는 훨씬 많은 인력과 시간이 필요했던 작전을 수행할 수 있다는 증거'라고 규정했다. dev.to의 분석이 정확히 짚어낸 핵심은 이거다. ARXON의 아키텍처는 LLM이 다음 행동을 결정하고 실행 도구가 그걸 수행하는 구조로, 이건 어떤 기업 AI 에이전트와도 구조적으로 동일하다. 차이는 의도가 아니라 실행 단계 사이에 어떤 통제가 있느냐다. ARXON에는 없었다. 그래서 5개월이 아니라 5주 만에 600대가 뚫렸다.
여기서 꺼내야 할 개념이 Human-in-the-Loop(HITL)다. 모든 행동에 인간 승인을 요구하는 게 아니다. 결과의 파급 범위(blast radius)가 큰 행동—프로덕션 DB 쓰기, 레코드 삭제, 고객 PII 접근, 금융 트랜잭션—에 대해서만 실행 전 승인 게이트를 두는 것이다. 관측성(observability)은 '무슨 일이 있었나'를 사후에 알려주지만, HITL 정책은 '이 행동이 지금 실행되어야 하나'를 사전에 차단한다. 두 개는 같은 게 아니다. 에이전트 도입 팀이 가장 자주 혼동하는 지점이기도 하다.
세 균열이 가리키는 하나의 방향
역량 격차, 모델 신뢰성, 자동화 통제. 이 세 가지는 서로 다른 레이어의 문제처럼 보이지만 같은 뿌리를 공유한다. AI 도구를 팀에 심을 때 '속도 이득'만 보고 '운영 비용'을 설계하지 않으면 터지는 균열들이다.
애플 사례가 던지는 질문은 이거다. AI 도구 도입 전에 팀의 현재 역량 수준을 측정하고, 도구가 실제로 워크플로우에 녹아들기까지의 학습 곡선을 로드맵에 반영했는가. Claude 너프 논란이 던지는 질문은 이거다. 우리 팀이 쓰는 모델의 성능을 지속적으로 측정하고 있는가, 아니면 처음 평가한 품질 수준을 그냥 믿고 있는가. FortiGate 공격이 던지는 질문은 이거다. 우리 에이전트의 자율 실행 범위를 명시적으로 정의했는가, 아니면 '설마 그런 일이 있겠어'라는 암묵적 가정에 기대고 있는가.
AI-First 전환의 속도는 이 세 질문에 얼마나 정직하게 답하느냐가 결정한다. 도구를 빠르게 도입하는 것과 팀이 도구를 안전하게 운영하는 것은 다른 타임라인 위에 있다. 두 번째 타임라인을 설계하지 않으면, AI는 가속이 아니라 새로운 형태의 기술 부채가 된다.