필즈상 수상자 테런스 타오(Terry Tao)가 AI 코딩 에이전트로 24개의 Java 수학 애플릿을 JavaScript로 이식했다. 몇 시간 만에. 에이전트가 만든 버그는 단 1개였고, 오히려 기존 코드에 숨어 있던 버그 2개를 새로 찾아냈다. 결과만 보면 AI 생성 코드의 품질이 나쁘지 않다는 얘기처럼 들린다.
하지만 타오 본인이 결정적인 단서를 남긴다. "이 시각화들은 논문의 핵심 구성요소가 아니라 보조 자료다. 버그가 발생하더라도 위험이 상대적으로 낮다." 즉, 그는 AI 생성 코드를 신뢰해서 쓴 게 아니라, 위험을 감수할 수 있는 영역을 먼저 특정하고 그 안에서 썼다. 이것이 핵심이다. 검증 구조는 코드 이후가 아니라, 어디에 AI를 쓸 것인지를 결정하는 순간부터 시작된다.
문제는 팀 전체가 타오처럼 판단하지 않는다는 데 있다. Vibe Coding 보안 체크리스트를 분석한 dev.to의 아티클은 이 현실을 냉정하게 짚는다. AI가 생성한 앱은 컴파일되고, 배포되고, 겉보기엔 완성된 것처럼 보인다. 그러면서 동시에 프로덕션 번들에 크리덴셜이 들어가고, 소스맵이 공개되고, 인증 없이 호출 가능한 API 라우트가 살아 있다. 자동화 스캐너가 잡지 못하는 건 주로 로그인 이후의 테넌트 격리, 서버사이드 권한 검증, RLS 정책의 실제 작동 여부 같은 영역이다. 에이전트는 요청받은 것만 구현하고, 구현하지 않은 것의 빈자리는 보고하지 않는다.
이 구조적 공백을 정면으로 겨냥한 접근이 GAUNTLEX다. 개발자 산조이(Sanjoy)가 만든 이 오픈소스 도구는 '스펙이 코드보다 먼저다'라는 전제에서 출발한다. 기존 SAST·DAST 도구들이 코드가 나온 뒤에 공격하는 반면, GAUNTLEX는 스펙 단계에서 동시에 두 에이전트를 돌린다. Builder는 스펙을 구현하고, Breaker는 같은 스펙을 읽고 독립적으로 공격 시나리오를 생성한다. 두 에이전트는 서로의 결과를 보지 않는다. 세 번째 에이전트인 Arbiter가 이 둘을 맞붙여 Adversarial Resilience Score를 산출하고, 임계값(기본 0.80) 미만이면 머지를 자동으로 블록한다.
이 구조가 실용적인 이유는 단순하다. 기존 보안 리뷰 프로세스의 병목은 코드 볼륨이 아니라 검토 타이밍이다. 레거시 현대화 프로젝트에서 수백만 줄의 코드를 재생성하면, 스펙도 수천 개가 동시에 쏟아진다. 사람이 스펙을 하나씩 리뷰하는 속도는 에이전트가 구현하는 속도를 따라잡지 못한다. 스펙 단계에서 자동화된 적대적 검증을 넣는 건 속도에 속도로 대응하는 설계다. 결과물은 CWE 번호뿐 아니라 NIST SSDF, OWASP SAMM, SOC 2, PCI DSS 같은 컴플라이언스 맵핑까지 나온다. 엔지니어와 감사자가 같은 리포트를 두고 대화할 수 있도록.
세 가지 소스를 엮으면 AI 생성 코드 검증의 레이어가 자연스럽게 그려진다. 첫째, 쓸 영역을 분류하라. 타오처럼 핵심 로직과 보조 자료를 명확히 구분하고, 위험 감수 가능 여부를 먼저 결정한다. 에이전트에게 맡기기 전에 '여기서 버그가 나면 어떤 피해가 생기나'를 답할 수 없다면, 그 영역은 아직 에이전트 대상이 아니다. 둘째, 스펙 단계에서 검증을 시작하라. GAUNTLEX처럼 코드 이전에 공격 시나리오를 생성하는 구조가 없다면, 최소한 스펙 리뷰에 보안 체크포인트를 넣어야 한다. 셋째, 배포 후 레이어를 층위별로 분리하라. Vibe Coding 체크리스트가 정리한 것처럼, 퍼블릭 URL 스캔 → 리포지토리 정적 분석 → IDE/CI 피드백 → 역할 기반 권한 테스트 → 데이터 레이어 별도 검증 → 비즈니스 로직 어뷰즈 케이스까지, 단계별로 다른 도구가 다른 표면을 담당해야 한다. 하나의 스캐너가 전부를 증명할 수 없다.
솔직히 말하면, 지금 대부분의 팀은 이 세 레이어 중 하나도 제대로 설계하지 않은 채 에이전트를 쓰고 있다. AI가 생성한 코드가 테스트를 통과하면 머지한다. 스캐너가 초록불을 켜면 배포한다. 그 초록불이 무엇을 보고, 무엇을 보지 않았는지는 확인하지 않는다. 에이전트의 속도는 기뻐하면서, 에이전트가 구현하지 않은 것의 빈자리는 팀이 모른다.
앞으로 AI 코딩 에이전트의 품질은 계속 올라갈 것이다. 그러나 검증 구조 없이 속도만 올리는 팀의 리스크도 같은 속도로 누적된다. GAUNTLEX 같은 스펙 레벨 검증 도구가 성숙하고, 레이어드 보안 체크리스트가 팀 표준으로 자리 잡는 방향은 이미 시작됐다. 남은 질문은 '언제 도입할 것인가'가 아니라, '지금 우리 팀의 검증 레이어가 에이전트의 속도를 따라가고 있는가'다.