숫자보다 중요한 것: 누가 먼저 찾았는가
지난주 두 개의 뉴스가 거의 동시에 나왔다. Anthropic의 보안 특화 모델 Claude Mythos Preview가 Mozilla Firefox에서 취약점 271건을 탐지했다는 것, 그리고 Microsoft 보안 대응 센터(MSRC)가 AI 에이전트를 내부 취약점 탐지 프로세스에 공식 통합하기 시작했다는 것이다.
271이라는 숫자에 먼저 반응하는 건 자연스럽다. 그런데 현장 관점에서 더 중요한 질문은 따로 있다. 그 취약점들을 공격자가 먼저 찾았는가, 방어자가 먼저 찾았는가. Mozilla의 답은 명확하다. Firefox 150 릴리스 전, 제품이 배포되기 전에 AI가 먼저 훑었고, 271건 전부 패치됐다. 공격자가 쓸 수 있는 재료가 시장에 나오기 전에 소각된 셈이다.
기존 보안 리뷰의 구조적 한계
솔직히 말하면, 기존 보안 코드 리뷰 프로세스는 태생적으로 샘플링이다. 시니어 보안 엔지니어가 코드베이스 전체를 커버하는 건 물리적으로 불가능하다. 릴리스 일정은 항상 촉박하고, 보안 리뷰는 대부분 크리티컬 경로 바깥에서 최소한으로 돌아간다. 그 결과가 지금까지 반복돼온 패턴이다. 공격자가 숨어 있던 취약점을 먼저 발굴하고, 기업은 피해가 터진 뒤에야 패치를 밀어낸다.
Microsoft MSRC가 자체 블로그에서 밝힌 것처럼, AI 기반 취약점 탐지 시스템은 "가용 리소스에 의해서만 제한될 뿐 24시간 가동"된다. 인간 전문가가 며칠 걸릴 분석을 AI는 시간 단위로 수행한다. 범위도 다르다. 인간 리뷰어가 커버하기 어려운 넓은 공격 표면을 AI는 일관된 품질로 처리한다. 이전 모델(Opus 4.6)로 Firefox 148에서 22건을 찾은 게 불과 두 버전 전이다. Mythos는 같은 방식으로 271건을 찾았다. 모델 세대 하나 만에 탐지 건수가 10배 이상 뛰었다.
AI-First 팀에서 보안 자동화를 내재화하는 방법
그렇다면 팀 워크플로우 설계 관점에서 지금 당장 무엇이 바뀌어야 하는가.
첫째, 보안 리뷰를 릴리스 게이트 앞으로 당겨야 한다. Mozilla 사례의 핵심은 AI 분석이 배포 전 단계에서 실행됐다는 점이다. AI 코드 리뷰를 PR 단계에 붙이는 팀은 많아졌지만, 보안 취약점 스캐닝까지 CI/CD 파이프라인에 묶는 팀은 여전히 소수다. 지금은 AI 기반 취약점 탐지를 '있으면 좋은 것'이 아니라 배포 차단 조건으로 다뤄야 하는 시점이다.
둘째, AI가 찾는 속도에 맞는 수정 체계가 필요하다. MSRC가 명시적으로 짚은 부분이다. "취약점을 많이 찾는 것과 빠르게 고치는 것은 다른 문제"다. AI가 271건을 쏟아내면, 팀이 그것을 트리아지하고 우선순위를 정하고 패치를 만드는 체계가 뒷받침되지 않으면 오히려 노이즈가 된다. Microsoft는 이 문제를 "AI 속도에 맞춘 수정 자동화 시스템"과 "개발자 참여 병행"으로 풀고 있다. 자동화와 인간 판단의 레이어를 동시에 설계해야 한다는 뜻이다.
셋째, AI가 생성한 코드일수록 보안 검증 루프가 더 필요하다. 아이러니하지만 사실이다. Supabase 기반 앱을 AI 코드 생성 도구로 빠르게 스캐폴딩하면, RLS(Row-Level Security) 같은 데이터베이스 레벨 보안 설정이 기본적으로 빠져있는 경우가 많다. AI가 만든 코드를 AI가 검증하는 루프를 팀 워크플로우에 구조로 심지 않으면, 속도 이득이 보안 부채로 돌아온다.
냉정하게 볼 것들
낙관론만 늘어놓을 수는 없다. Mythos는 공개 직후 무단 접근 의혹이 제기됐고 Anthropic이 조사 중이다. 같은 AI 도구를 공격자가 쓰면 어떻게 되는가라는 질문은 여전히 유효하다. MSRC 스스로도 "공격자들이 AI를 도입하더라도"라는 전제를 달고 이야기한다.
그러나 이 질문에 대한 답은 단순하다. 공격자도 언젠가 같은 수준의 도구를 쓸 것이다. 그렇다면 방어자가 먼저 자사 코드베이스를 AI로 샅샅이 훑는 것이 손을 놓고 있는 것보다 명백히 낫다. "공격자가 AI를 쓰면 위험하다"는 우려가 방어자의 선제 도입을 막는 논리로 쓰이는 순간, 그게 더 큰 리스크다.
학습 곡선도 현실적으로 봐야 한다. AI 취약점 탐지 도구를 파이프라인에 통합하는 건 하루 만에 끝나지 않는다. 탐지 결과 트리아지 프로세스 설계, 오탐 필터링 기준 수립, 팀원 교육이 함께 따라온다. 도입 결정 전에 이 비용을 솔직하게 계산하는 게 먼저다.
전망: 보안 리뷰의 역할 분리
Microsoft가 제시하는 방향은 명확하다. "에이전트 기반 레드팀을 소프트웨어 개발 프로세스에 직접 내재화"하고, "코드가 작성되고 배포되는 과정에서 즉시 문제를 식별하고 해결"하는 구조다. 보안 리뷰가 릴리스 직전 체크리스트에서 개발 주기 전체에 분산된 자동화 레이어로 바뀐다는 뜻이다.
AI-First 팀 설계 관점에서 이 변화는 역할 재편을 요구한다. 보안 엔지니어의 역할은 직접 취약점을 찾는 것에서 AI 탐지 결과를 판단하고 우선순위를 정하며 수정 방향을 결정하는 것으로 무게중심이 옮겨간다. 코드를 많이 아는 것보다 AI가 뽑아낸 신호에서 진짜 위협을 구분하는 판단력이 더 중요해진다.
'당하기 전에 찾아내는 게임'으로의 전환은 이미 시작됐다. 팀이 지금 해야 할 질문은 'AI 보안 도구를 도입할 것인가'가 아니라, '어느 단계에서, 어떤 구조로 내재화할 것인가'다.