AI-First로 팀을 리빌딩할 때 가장 먼저 따지는 질문은 보통 이렇다. "이 도구, 내일 당장 쓸 수 있나?" 그런데 지금 현장에서는 다른 질문이 더 급해졌다. "이 도구, 쓰고 나서 어떤 청구서가 날아오나?" 청구서는 세 종류다. 법적 책임, 예산 초과, 그리고 아무도 설계하지 않은 사용량 구조. 세 가지 모두 AI 코딩 어시스턴트와 에이전틱 워크플로우를 팀에 도입한 순간부터 카운트다운이 시작된다.
첫 번째 폭탄: "AI가 짠 코드"는 법 앞에서 면죄부가 아니다
2024년 12월 발효된 EU 사이버 복원력법(CRA)의 핵심 조항들이 이제 실제 데드라인으로 다가오고 있다. 취약점 보고 의무는 2026년 9월, 전면 준수는 2027년 12월이다. dev.to의 분석에 따르면 CRA는 코드가 어떻게 생성됐는지 묻지 않는다. AI가 짰든 사람이 짰든, EU 시장에 제품을 출시한 제조사가 모든 취약점의 법적 책임을 진다.
문제는 AI 코딩 어시스턴트가 규제 준수를 최적화 목표로 삼지 않는다는 데 있다. Copilot, Claude, Cursor—어떤 도구든 목표는 테스트를 통과하는 작동하는 코드다. 보안 패치 가능성, 장기 유지보수성, 알려진 CVE 패턴 재현 여부는 모델이 아니라 팀이 책임진다. 보안 연구자들이 이미 확인한 사실이기도 하다. AI 생성 코드가 기존에 알려진 취약점 패턴을 의미 있는 비율로 재도입한다는 것.
CRA 범위는 생각보다 넓다. EU 고객이 있다면 법인 소재지와 무관하게 적용된다. 오픈소스 예외도 좁다. 유료 제품에 번들하거나 매니지드 서비스로 제공하면 제조사로 분류된다. 벌금은 최대 1,500만 유로 또는 전 세계 연매출의 2.5% 중 높은 쪽이다. AI 코딩 어시스턴트로 개발 속도를 높인 만큼, 코드 리뷰 레이어에 SAST 자동화를 기본 베이스라인으로 깔고 취약점 발생 시 24시간 ENISA 보고 파이프라인을 지금 설계해야 한다.
두 번째 폭탄: 에이전틱 워크플로우의 토큰 청구서
한 익명의 글로벌 기업이 한 달 만에 Anthropic Claude 사용료로 5억 달러(약 6,800억 원)에 달하는 청구서를 받았다는 보도가 나왔다(뉴스스페이스, 2025). 아직 독립 검증이 완료되지 않은 단일 사례이지만, 이 사건이 말해주는 구조적 문제는 명확하다. 수천 명의 직원이 사용 한도 없이 에이전틱 워크플로우를 돌렸고, 실시간 비용 모니터링은 없었으며, 아무도 이 사용량이 얼마짜리 청구서로 돌아올지 추적하지 않았다.
에이전틱 워크플로우는 단순 챗봇 질의와 비용 구조가 다르다. 여러 단계를 자동으로 수행하는 에이전트 파이프라인은 단일 질의 대비 최대 1,000배 더 많은 토큰을 소비할 수 있다. Claude Opus 기반 에이전트 프레임워크 테스트에서 하루 사용 비용이 109달러를 넘은 사례도 있다. 수천 명 규모로 제약 없이 운영하면 월 누적 비용이 기하급수적으로 증가하는 건 수학적 필연이다.
이 사건을 계기로 'tokenmaxxing(토큰맥싱)'이라는 용어가 회자되고 있다. 실질적인 비즈니스 성과와 무관하게 AI 토큰 소비량을 생산성의 지표처럼 과시하는 행태다. 아마존 내부에서 AI 사용량 리더보드 상위를 차지하려고 토큰 소비를 과장하다 적발된 사례까지 나왔다. 사용량 KPI가 실제 성과와 단절될 때 어떤 일이 벌어지는지를 보여주는 징후들이다.
세 번째 폭탄: 사용량 제한은 UX 문제가 아니라 아키텍처 문제다
dev.to의 Jenuel이 지적한 것처럼, AI의 가장 비싼 버그는 종종 잘못된 답이 아니라 아무 제한 없이 반복 요청된 올바른 답이다. 그런데 대부분의 팀은 AI 기능을 프로덕트에 붙이면서 "모델이 충분히 똑똑한가"를 먼저 검증하고, "이 기능이 실제 사용량을 감당할 수 있는가"는 나중으로 미룬다. 청구서가 도착한 뒤에야 비용 통제가 아키텍처 문제였다는 걸 깨닫는 패턴이 반복된다.
좋은 사용량 제한 설계는 다섯 가지 요소를 포함한다. 사용자·팀·인테그레이션 단위의 예산 상한, 기능별 비용 추적(채팅인지 에이전트 액션인지 문서 업로드인지), 작업 복잡도에 따른 모델 라우팅(보일러플레이트엔 경량 모델, 아키텍처 리뷰엔 프론티어 모델), 컨텍스트 트리밍과 캐싱, 그리고 사용자에게 제한 이유를 설명하는 명확한 피드백. 여기서 핵심은 AI 기능을 인색하게 만드는 게 목표가 아니라는 것이다. 월 예산이 소진된 뒤 아무 설명 없이 기능이 꺼지는 제품보다, 제한을 미리 설명하고 대안을 제시하는 제품이 훨씬 신뢰할 수 있다.
관찰 가능성(observability) 레이어도 재설계가 필요하다. 지연 시간과 토큰 수만 보는 AI 대시보드는 절반짜리다. 저렴한 모델로 라우팅했을 때 답변 품질이 얼마나 저하되는지, 컨텍스트 길이가 실제 성과를 개선하는지, 사용자가 프롬프트를 반복하는 이유가 첫 응답이 약해서인지—이 세 가지 질문에 함께 답할 수 있어야 진짜 운영 가능한 AI 기능이다.
세 폭탄은 하나의 리스크다
법적 책임, 비용 폭발, 사용량 설계 부재. 이 세 가지는 따로 오는 것처럼 보이지만 실제로는 같은 뿌리에서 자란다. AI 도구의 도입 속도가 거버넌스 설계 속도를 앞지를 때 발생하는 문제들이다. AI-First 팀 리빌딩을 주도하는 입장에서 솔직하게 말하면, AI 코딩 어시스턴트를 도입한 팀이 지금 가장 먼저 해야 할 일은 새 모델 벤치마크를 확인하는 게 아니다. CRA 스코프를 확인하고, 토큰 비용 대시보드를 세우고, 에이전트 루프에 하드 캡을 거는 것이다.
가트너는 2026년 전 세계 AI 관련 지출이 2조 5,900억 달러에 달할 것으로 전망한다. 그리고 전 세계 기업의 80~85%가 AI 인프라 비용을 25% 이상 잘못 추정하고 있다. 숫자가 커질수록 거버넌스 공백의 댓가도 커진다. AI가 더 이상 실험실의 소액 비용이 아니라 기업 손익계산서를 흔드는 자본 지출이 된 지금, "나중에 처리할 문제"는 없다. 세 가지 비용 폭탄 모두, 지금 설계 단계에서 막을 수 있는 것들이다.