코드 생성은 빨라졌다. 그런데 검증은?
요즘 팀에서 종종 이런 보고가 들어온다. "하루 만에 앱 하나 뚝딱 만들었습니다." dev.to에 올라온 한 사례가 그걸 상징적으로 보여준다. 도메인 지식은 풍부하지만 정통 CS 배경이 없는 개발자가 AI 코딩 에이전트를 활용해 Flask 기반 풀스택 청구 앱을 단 하루, API 토큰 비용 $0.50으로 완성했다. VIN 디코딩, PDF 청구서 생성, 모바일 반응형 UI까지 갖춘 앱이다. 코드 한 줄 직접 타이핑하지 않고.
이 이야기가 인상적인 이유는 속도 때문만이 아니다. 이 개발자가 강조하는 건 "AI는 망치였고, 무엇을 만들지는 내가 알았다"는 점이다. 15년 넘는 자동차 정비 경험에서 나온 도메인 지식—부품 마크업 계산 방식, 세금이 부품에만 적용되는 이유, 작업 시간 추적이 고객 청구서에 노출되면 안 되는 이유—이 프롬프트의 품질을 결정했다. 그리고 그는 AI가 만든 코드를 직접 검토하고 오류를 잡아냈다고 명시한다. "AI는 실수를 한다. 도메인 지식 없이는 그 실수를 잡을 수 없다."
2,000개 스킬이 말해주는 AI 코딩 생태계의 속도
한편 dev.to에는 Claude Code 스킬 2,000개를 인덱싱한 분석도 올라왔다. 2025년 한 해 동안 Claude Code, Cursor, Codex 등 주요 AI 코딩 에이전트들이 "로더블 컨텍스트 패키지" 포맷을 경쟁적으로 도입하면서 공개 스킬 레지스트리가 폭발적으로 성장했다. 프론트엔드 디자인 패턴부터 Azure 배포 자동화까지, AI 코딩 에이전트가 소화할 수 있는 컨텍스트의 범위가 넓어졌다는 뜻이다.
이 생태계가 의미하는 바는 하나다. AI 코딩 도구의 맥락 이해 능력이 빠르게 확장되고 있고, 그 위에서 만들어지는 코드의 양과 속도도 함께 가속하고 있다. 팀에 AI 코딩 에이전트를 도입했다면, 지금쯤 코드 생성 속도가 이전과 비교가 안 될 만큼 올라갔을 것이다. 그런데 그 코드에 대한 보안 검증 구조는 같은 속도로 올라갔는가?
취약점도 AI 속도로 발견된다
앤트로픽이 프로젝트 글래스윙(Project Glasswing)을 통해 공개한 수치가 이 질문의 무게를 더해준다. 보안 특화 AI 모델 Claude Mythos Preview를 활용해 단 한 달 만에 고위험 또는 치명적 취약점 후보 1만 건 이상을 탐지했다. 이 중 1,000개가 넘는 오픈소스 프로젝트에 영향을 미치는 6,202건이 고위험 이상으로 분류됐고, 추가 검증을 거쳐 1,094건이 실제 치명적 취약점으로 확인됐다.
대표 사례로 언급된 울프SSL의 CVE-2026-5194는 CVSS 9.1점짜리 취약점이다. 공격자가 인증서를 위조해 정상 서비스처럼 가장할 수 있는 문제로, 금융·클라우드·IoT 환경 전반에 파급력이 미친다. 그런데 앤트로픽이 더 강조한 지점은 따로 있다. "취약점을 찾는 일은 점점 쉬워지고 있지만, 이를 검증하고 패치하는 일은 훨씬 어렵다." 현재까지 패치된 건수는 97건에 불과하다.
여기서 결정적인 비대칭이 드러난다. AI는 취약점을 인간보다 빠르게 찾는다. 그런데 그 취약점을 실제로 패치 가능한 형태로 검증하고, 원 프로젝트에 반영하고, 보안 권고문을 발행하는 속도는 여전히 사람의 속도다. 보안기업 엑스보우(XBOW)도 Mythos를 평가하면서 "취약점이 실제로 악용 가능한지 검증하는 능력과 판단 정확도에는 여전히 한계가 있다"고 지적했다.
AI-First 팀이 직면한 비대칭 구조
이 세 가지 사례를 함께 놓으면 AI-First 팀이 지금 직면한 구조적 문제가 선명하게 보인다.
- 코드 생성 속도: AI 에이전트 덕분에 하루 만에 풀스택 앱이 완성된다
- 취약점 발생 속도: 생성된 코드만큼 취약점도 같은 속도로 누적된다
- 취약점 탐지 속도: AI 보안 도구가 한 달에 1만 건을 찾아낸다
- 패치 및 검증 속도: 여전히 사람이 하나씩 확인해야 한다
네 번째 항목이 나머지 세 개의 속도를 따라잡지 못하면, AI-First 워크플로우는 오히려 기술 부채와 보안 취약점을 기존보다 빠른 속도로 누적하는 구조가 된다. 속도가 빨라지는 만큼 검증 구조도 함께 설계하지 않으면, 쌓이는 건 기능이 아니라 위험이다.
실용적으로 풀면: 검증 구조를 CI/CD 안에 박아넣어라
글래스윙 같은 AI 보안 도구는 아직 제한된 파트너에게만 공개돼 있다. 오픈AI의 데이브레이크(Daybreak), GPT-5.5 사이버 역시 검증된 보안 인력에게만 제한적으로 제공되는 접근 방식을 택하고 있다. 이건 우연이 아니다. AI 기반 취약점 탐지 능력이 공격자 손에 들어갈 경우의 리스크를 인지하고 있기 때문이다.
그렇다면 대부분의 팀이 지금 당장 할 수 있는 건 무엇인가. 세 가지를 짚는다.
첫째, 코드 생성 파이프라인에 보안 검증 스텝을 붙여라. AI가 코드를 만드는 속도만큼, Semgrep·CodeQL·Snyk 같은 정적 분석 도구를 PR 단계에 기본값으로 박아두는 것이 최소한의 방어선이다. 선택이 아니라 파이프라인의 일부로.
둘째, AI 생성 코드에는 더 엄격한 리뷰 기준을 적용하라. $0.50짜리 앱 빌드 사례가 보여주듯, AI는 자신있게 틀린 코드를 만든다. 도메인 지식이 있는 사람이 검토해야 잡힌다. "AI가 만들었으니 아마 맞겠지"는 통하지 않는다.
셋째, 오픈소스 의존성 관리를 지금 당장 점검하라. Mythos가 1,000개 넘는 오픈소스 프로젝트에서 취약점을 찾았다는 건, AI로 빠르게 만든 앱이 당겨오는 패키지 안에 이미 알려진 취약점이 있을 가능성이 높다는 뜻이다. Dependabot이나 SBOM 생성 도구를 CI에 붙여두는 게 현실적인 시작점이다.
전망: 생성 속도와 검증 속도의 격차가 팀 역량을 가른다
AI 코딩 도구의 성능은 계속 올라갈 것이다. 스킬 생태계는 더 풍부해지고, 에이전트가 처리할 수 있는 컨텍스트의 깊이도 깊어진다. 동시에 AI 기반 취약점 탐지 도구도 방어와 공격 양쪽에서 함께 진화한다.
이 흐름 속에서 팀 역량의 차이는 "AI를 쓰느냐"가 아니라 "생성 속도와 검증 속도를 함께 설계했느냐"에서 나온다. 빠르게 만드는 능력은 AI가 가져다준다. 빠르게 만들면서도 무너지지 않는 구조를 설계하는 것은 여전히 사람이 해야 할 일이다. AI-First 팀 리빌딩의 진짜 과제는 이 두 속도를 동기화하는 워크플로우를 짜는 것이다.