AI는 보안 체계가 감당할 수 있는 속도보다 더 빠르게 코드를 배포하고 있습니다

AI 코딩 도구들은 아무도 계획하지 않았던 일을 해냈습니다. 바로 보안 검토 주기(security review cycle)를 병목 현상(bottleneck)으로 만든 것입니다. CI가 아닙니다. 배포도 아닙니다. 바로 보안입니다.

AI 에이전트 보안에 대한 Snyk의 최신 연구는 많은 엔지니어링 팀이 조용히 느끼고 있는 현상에 대한 명확한 데이터를 제시합니다. 즉, 속도는 올라갔지만 보안 범위(security coverage)는 늘어나지 않았다는 것입니다. "코드가 작성된 시점"과 "코드가 배포하기에 안전한 시점" 사이의 간극이 그 어느 때보다 벌어졌습니다.

"AI는 보안 체계가 감당할 수 있도록 설계된 속도보다 더 빠르게 코드를 배포하고 있습니다."

이것은 미래의 상태에 대한 경고가 아닙니다. 현재의 상황을 묘사한 것입니다.

실제로 무엇이 변했는가

전통적인 앱 보안(appsec)은 인간의 개발 주기(cadence)에 맞춰 구축되었습니다. 분기별 침투 테스트(pentests). 머지(merge) 전 코드 리뷰. 스캐너 출력 결과에 대한 수동 분류(manual triage). 10명의 엔지니어 팀이 몇 주에 걸쳐 기능을 배포하던 시절에는 대략적으로 이 방식이 작동했습니다.

AI 에이전트는 그런 주기로 작동하지 않습니다. 이들은 몇 분 만에 작동 가능하고 테스트 가능한 코드를 생성합니다. 에이전트의 도움을 받는 스프린트(sprint)는 전통적인 팀이 한 분기 동안 배포하던 것보다 더 많은 공격 표면(surface area)을 만들어낼 수 있습니다. AI 이전 시대에서 물려받은 보안 도구들은 이러한 처리량(throughput)에서 스트레스 테스트를 거친 적이 없습니다.

Snyk이 지적하는 구체적인 격차:

• 침투 테스트(Pentesting) 빈도가 확장되지 않았습니다. 대부분의 조직은 여전히 분기별 또는 연간 단위의 고정된 주기로 침투 테스트를 수행합니다. 매주 배포되는 AI 생성 코드는 테스트를 거치지 못합니다.
• AI 에이전트는 새로운 공격 벡터(attack vectors)를 도입합니다. 프롬프트 인젝션(Prompt injection), 도구 오용(tool misuse), 안전하지 않은 컨텍스트 전달(insecure context passing) 등은 인간이 작성한 코드 패턴을 위해 작성된 전통적인 SAST(정적 분석 보안 테스트) 규칙에는 나타나지 않습니다.
• 의존성 표면(Dependency surface)이 폭발적으로 증가하고 있습니다. AI 어시스턴트는 문제를 빠르게 해결하기 위해 패키지들을 끌어옵니다. 개발자가 추가된 내용을 항상 감사(audit)하는 것은 아닙니다. Snyk의 스캐너 데이터에 따르면 AI의 도움을 받는 리포지토리(repos)에서 의존성 수가 급격히 증가하고 있습니다.
• 보안 피드백이 너무 느립니다. AI 에이전트가 코드를 작성한 지 몇 주가 지나 취약점(vuln)이 나타나면, 아무도 당시의 결정 맥락(decision context)을 기억하지 못합니다. 수정 작업은 눈을 가리고 하는 수술(blind surgery)과 같습니다.

진짜 문제는 도구가 아니라 모델입니다

개별 스캐너(scanners)가 문제는 아닙니다. 대부분의 팀은 이미 이를 보유하고 있습니다. 문제는 보안이 파이프라인(pipeline) 끝단의 관문(gate)으로 설계되었다는 점입니다. AI는 생산적인 작업 단계를 너무나도 '왼쪽(left)'으로 이동시켰고, 그 결과 관문은 이제 거의 항상 뒤처진 채 따라잡기에 급급한 상태입니다.

Snyk의 주장은 보안이 AI 에이전트(AI agents)가 작동하는 곳, 즉 인라인(inline), IDE 내부, 그리고 에이전트 루프(agent loop) 자체로 이동해야 한다는 것입니다.

✏️ KewBot (AI)가 초안을 작성하고, Drew가 편집 및 승인했습니다.