arXiv에 올해 올라온 SWE-WebDevBench 논문이 있다. 주요 6개 에이전트 코딩 플랫폼을 같은 기준으로 평가했다. 보안 점수는 65% 미만이었다. 엔지니어링 품질 기준에서는 60% 미달이었다. 두 숫자가 같은 방향을 가리킨다.

코드 생성 속도는 올랐고, 보안 검증 단계는 그 속도를 따라가지 못했다.

에이전트 코딩 도입을 결정한 팀이 처음 부딪히는 건 기능이 아니다. “생성된 코드가 안전한지 누가 보장하는가”라는 질문이다. 스프린트 사이클이 절반으로 줄었는데 코드 리뷰 단계에서 보안 지적이 쌓이기 시작하면, 결국 속도 이득이 거기서 상쇄된다. SWE-WebDevBench의 60% 함정은 이 지점을 측정한 것이다.

논문이 공통적으로 짚은 실패 패턴은 두 가지다.

첫째, 사양 병목이다. 에이전트가 코드를 짜기 전 받는 요구사항에 보안 기준이 없으면, 생성 단계에서 취약점이 이미 구조 안에 들어온다. 명세 자체가 안전하지 않을 때 코드만 검사하는 건 이미 늦다.

둘째, 프론트-백엔드 디커플링이다. 프론트 에이전트와 백엔드 에이전트가 독립적으로 코드를 만들 때, 경계 검증이 빠지는 구간이 생긴다. 두 에이전트가 서로의 출력을 암묵적으로 신뢰하는 순간, OWASP Agentic AI Top 10이 노리는 접점이 열린다.

이 문제를 파이프라인으로 해결하는 오픈소스 도구가 Crucible이다. OWASP Agentic AI Top 10을 기반으로 90개 공격 시나리오를 구성하고, 전체를 62초 안에 실행한다. CI에 붙이면 코드가 머지되기 전 자동 통과 조건이 된다. 보안 게이트를 수동 리뷰 단계에 맡기는 대신 파이프라인에 내장하는 것이다.

Claude Mythos Preview가 Mozilla Firefox와 협력한 사례도 같은 방향을 가리킨다. 2026년 4월 한 달 동안 Firefox 코드베이스에서 수정된 보안 버그 수가 직전 15개월 합산보다 많았다. 모델 능력이 올라간 게 맞지만, 그 능력이 실제로 발현된 건 체계적인 보안 게이트가 함께 있었기 때문이다.

OpenAI는 Running Codex Safely 가이드라인에서 에이전트 코딩을 안전하게 운용하는 구조로 세 축을 명시했다. 샌드박스 실행, 사람 승인 단계, 네트워크 정책이다. 텔레메트리는 이 전체를 기록하는 레이어로 별도로 다룬다. 속도와 보안이 함께 작동하려면 이 구조가 파이프라인 안에 이미 있어야 한다.

PM에게 실질적인 행동 지점은 하나다. 에이전트가 만든 코드가 배포 파이프라인에 들어오기 전에, 보안 시나리오를 통과했는지 확인하는 자동 게이트가 있는지 점검하는 것이다. Crucible 같은 도구를 CI에 붙이는 데 하루를 넘지 않는다. 게이트 없이 에이전트 코딩 속도만 올리면 SWE-WebDevBench가 측정한 60% 함정이 기다린다.

여러분 팀의 에이전트 코딩 파이프라인에 보안 게이트가 있습니까? 있다면 그게 몇 단계입니까?