숫자 세 개가 먼저다
최근 한 달 사이 AI-First 워크플로우를 직접 측정한 데이터 세 개가 거의 동시에 나왔다. Claude Code 30일 비용 추적 실험에서 나온 90% 비용 절감, Veracode 2026 보고서가 확인한 45% AI 생성 코드 보안 결함률, 그리고 실제 프로덕션 코드베이스에서 AI가 가속시킨 Shotgun Surgery 사례. 각각 따로 보면 흥미로운 아티클이지만, 세 개를 함께 놓으면 전혀 다른 질문이 튀어나온다. 우리 팀은 비용도, 품질도, 구조도—셋 중 어느 것도 설계한 적이 있는가?
비용: 90%는 틀리지 않았다, 단 전제가 있다
dev.to에 올라온 Claude Code 30일 추적 실험은 방법론이 꽤 엄밀하다. 저자는 매 세션마다 task_type을 lint, format, batch_op, refactor, debug, architecture 중 하나로 사전 분류한 뒤 Claude Sonnet과 로컬 Gemma 7B(Ollama) 중 어디서 실행할지를 결정했다. 결과는 예상보다 선명하게 갈렸다. 단일 파일 기계적 작업—lint, format, grep-and-replace 수준—은 Gemma에서 평균 품질 점수 4.4~4.8/5를 기록했고, 바운스율(Sonnet으로 재실행)도 낮았다. 반면 멀티파일 리팩토링, 디버깅, 아키텍처 작업은 Gemma에서 1.8~2.9점으로 뚝 떨어졌다.
저자가 계산한 절감 공식은 단순하다. 전체 세션의 절반 이상을 차지하는 기계적 작업을 로컬로 돌리면, 그 비용이 그대로 $0가 된다. Anthropic API 비용은 진짜 추론이 필요한 작업에만 태운다. 90%라는 숫자는 과장이 아니다—다만 '내 세션 중 기계적 작업이 몇 %인가'를 먼저 측정해야만 유효한 숫자다. 저자 본인도 솔직하게 명시한다. "이 숫자는 내 데이터다, 당신 것이 아니다. 일주일 로그를 먼저 돌려보라."
한 가지 더 주목할 포인트가 있다. 달러 절감보다 쿼터 절감이 더 실질적인 인사이트였다고 저자는 말한다. Pro 계정 구독이면 청구서는 고정이다. 그런데 기계적 작업에 쿼터를 태우다 보면 진짜 필요한 순간에 Sonnet이 없다. 로컬 라우팅은 비용 최적화이기 전에 쿼터 배분 전략이다.
품질: 45%는 통계가 아니라 운영 현실이다
"AI가 만든 코드의 거의 절반에 보안 결함이 있다"—이 수치를 처음 보면 과장처럼 들린다. CSET 조지타운(2024)과 Veracode(2026)가 각각 독립적으로 다섯 개 이상의 LLM을 대상으로 측정한 결과다. CodeRabbit의 PR 분석에서는 AI 생성 코드가 인간 작성 코드보다 1.7배 더 많은 이슈를 만들어냈고, Lightrun 데이터에 따르면 AI 생성 코드의 43%가 QA와 스테이징을 통과한 뒤 프로덕션에서 수동 디버깅을 요구했다.
dev.to 아티클이 인용한 Vercel 침해 사고는 이 맥락을 더 냉정하게 만든다. Vercel 직원이 사용하던 써드파티 AI 생산성 도구 Context.ai가 공격당했고, 그 경로로 Vercel 내부 시스템이 노출됐다. 고객 환경변수—API 키, DB 크리덴셜—가 22개월간 탈취됐는데도 감지되지 못했다. AI 코딩 에이전트 OpenClaw는 석 달 만에 CVE 8개를 쌓았고, SecurityScorecard는 인터넷에 노출된 인스턴스 13만 5천 개를 찾아냈다.
이 숫자들이 팀에게 요구하는 것은 공포가 아니라 검증 파이프라인이다. AI가 생성한 코드를 머지하기 전에 보안 스캔이 자동으로 돌고 있는가? 환경변수 로테이션 정책이 있는가? 팀원이 설치하는 AI 도구 확장의 의존성 감사가 이루어지고 있는가? 질문은 간단하지만, 팀 대부분이 아직 설계하지 않은 지점이기도 하다.
구조: AI는 두더지를 너무 잘 잡는다
Velog에 올라온 1인 프론트엔드 개발자의 회고는 기술 스택보다 더 본질적인 문제를 짚는다. React/Next.js 기반 캔버스 기능에 "저장 안 된 변경사항" 다이얼로그를 추가하는 흔한 요구사항이었다. AI는 사이드바 버튼에 onClick 가드를 붙이는 것을 도왔다. 작동했다. 다른 진입점에 같은 패치를 붙였다. 또 작동했다. 헤더 로고를 눌렀을 때 다시 뚫렸다. 패치를 붙이려다 멈췄다—이거 두더지 잡기다.
마틴 파울러가 정의한 코드 스멜 Shotgun Surgery, 즉 "하나의 변경 의도가 N개의 진입점을 동시에 수정해야 하는 상태"가 AI 덕분에 더 빠르게 누적되고 있었다. AI는 지금 이 자리의 최선을 제안한다. 전체 코드베이스의 패턴을 자동으로 감지해서 "이건 세 번째 비슷한 패치인데 추출할까요?"라고 먼저 물어주지는 않는다. AI의 응답 속도가 너무 빠르기 때문에 개발자의 메타인지가 따라잡지 못하는 것도 문제다.
저자가 스스로 멈추고 "근본적으로 다시 바라봐야 할 것 같아"라고 AI에게 물었을 때 답이 달라졌다. document capture phase 이벤트 리스너 하나로 모든 <a> 태그를 단일 choke point에서 처리하는 구조가 나왔다. 이전에 박았던 onClick 가드들은 전부 삭제됐다. 삭제된 줄이 추가된 줄보다 많았다.
저자의 결론은 단순하다. "이게 N번째 비슷한 패치인가? N≥2면 멈춰라." AI가 두더지를 못 잡는 게 아니다. AI는 두더지를 너무 잘 잡는다. 그래서 사람이 "지금 두더지 잡기 중이구나"를 알아차려야 한다.
맥락 해석: 세 문제는 하나의 뿌리를 공유한다
비용, 품질, 구조—세 문제는 표면적으로 달라 보이지만 같은 뿌리에서 자란다. AI 도구를 기본값으로 쓰되, 그 도구가 다루는 범위를 팀이 명시적으로 설계하지 않은 것이다.
비용 최적화 실험이 가장 먼저 요구한 것은 도구 교체가 아니라 작업 분류였다. 어떤 작업이 기계적이고 어떤 작업이 추론을 요구하는지 분류 기준을 팀이 먼저 합의해야 한다. 보안 품질 문제가 요구하는 것은 AI 사용 금지가 아니라 검증 게이트다. AI 생성 코드가 머지되기 전에 통과해야 할 체크포인트를 파이프라인에 심어야 한다. 구조 문제가 요구하는 것은 더 좋은 AI 모델이 아니라 메타인지 트리거다. 팀원이 패턴 반복을 스스로 인식하거나, 코드 리뷰 단계에서 Shotgun Surgery를 잡아낼 체크리스트가 필요하다.
세 가지 모두 AI가 해결하지 않는다. AI는 주어진 컨텍스트 안에서 최선을 제안할 뿐이다. 그 컨텍스트의 경계를 그리는 것은 팀의 몫이다.
팀에게 남는 세 가지 설계 질문
내일 당장 팀에서 확인해볼 수 있는 질문으로 압축하면 이렇다.
첫째, 우리 팀의 Claude Code 세션을 분류해본 적 있는가? lint, format, batch_op 같은 기계적 작업과 멀티파일 리팩토링, 아키텍처 결정 같은 추론 작업의 비율을 모른다면, 비용 최적화도 쿼터 배분도 근거 없는 직관에 기댈 수밖에 없다. 일주일 로그만 찍어도 팀의 실제 패턴이 보인다.
둘째, AI 생성 코드가 머지되기 전에 자동 보안 스캔이 돌고 있는가? 45% 결함률은 AI가 나쁜 도구라는 증거가 아니다. 검토 없이 머지하는 프로세스가 문제라는 신호다. CI 파이프라인에 SAST 도구 한 개를 추가하는 것으로 시작할 수 있다.
셋째, 팀의 코드 리뷰에 Shotgun Surgery 체크가 있는가? PR 리뷰어가 "이 패턴이 코드베이스에 몇 번째 등장하는가"를 묻는 습관이 없다면, AI가 가속하는 구조적 부채를 리뷰 단계에서 잡을 수 없다. 체크리스트 한 줄이 다음 Shotgun Surgery 사이클을 막는다.
전망: '설계 없는 속도'의 유효기간이 짧아지고 있다
AI 코딩 도구의 성능은 계속 오른다. 비용은 계속 내려간다. 그러나 이 세 가지 데이터가 동시에 나왔다는 것은, 도구의 발전과 별개로 팀의 설계 수준이 병목이 되는 시점이 이미 왔다는 신호다.
비용을 90% 아끼려면 분류 체계를 설계해야 한다. 품질 결함 45%를 절반으로 줄이려면 검증 파이프라인을 설계해야 한다. Shotgun Surgery 부채를 막으려면 메타인지 트리거를 설계해야 한다. 셋 다 AI가 알아서 해주지 않는다.
지금 당장 코드를 더 빠르게 쓰는 것보다, 팀이 AI를 어떤 경계 안에서 쓸지 명시적으로 합의하는 데 반나절을 쓰는 편이 더 높은 ROI를 낼 수 있다. 그 반나절을 미루는 비용은, 30일 후 측정 가능한 숫자로 돌아온다.