요약: Anthropic이 Project Glasswing을 약 150개 조직으로 확대했습니다. 핵심은 “AI가 취약점을 더 많이 찾는다”가 아니라 “검증, 공개, 패치, 배포가 병목이 된다”는 점입니다. 개발팀은 보안 AI 도구를 단순 스캐너처럼 보면 안 됩니다.
Project Glasswing은 Anthropic이 고성능 사이버 보안 모델인 Claude Mythos Preview를 제한된 파트너에게 제공해 중요한 소프트웨어를 안전하게 점검하려는 프로그램입니다. 초기 약 50개 파트너에서 시작했고, 공식 발표에 따르면 이후 150개가량의 새로운 조직으로 확대됩니다. 대상은 전력, 물, 의료, 통신, 하드웨어, 오픈소스 유지보수자처럼 공격 성공 시 영향 범위가 큰 조직입니다.
개발자 관점에서 이 뉴스가 중요한 이유는 보안 업무의 단위가 바뀌기 때문입니다. 지금까지 많은 팀은 정적 분석 도구, 의존성 스캐너, 코드 리뷰 체크리스트를 조합해 취약점을 관리했습니다. AI 보안 모델은 이보다 더 넓은 맥락을 봅니다. 코드 흐름, 설정, 배포 구조, 라이브러리 사용 패턴을 함께 읽고 취약한 조합을 찾을 수 있습니다.
하지만 더 많은 취약점을 찾는다고 자동으로 보안이 좋아지는 것은 아닙니다. 실제 병목은 triage, 재현, 우선순위 결정, 패치, 회귀 테스트, 배포입니다. Anthropic도 발표에서 검증·공개·패치가 새로운 병목이 되고 있다고 설명했습니다.
보안 도구가 취약점을 적게 찾을 때는 발견 자체가 가치였습니다. 하지만 AI가 수천 개 후보를 뽑아낼 수 있게 되면 문제는 달라집니다. 후보가 너무 많으면 개발팀은 무엇부터 고칠지 모릅니다. false positive가 섞이면 신뢰도도 떨어집니다. 결국 취약점 관리의 핵심은 모델 성능보다 운영 체계가 됩니다.
예를 들어 AI가 인증 미들웨어 우회 가능성을 제기했다고 합시다. 이 결과를 바로 티켓으로 넣으면 백로그만 늘어납니다. 먼저 재현 가능한 입력이 있는지 확인해야 합니다. 실제 배포 설정에서도 가능한지 봐야 합니다. 영향 범위가 관리자 기능인지 일반 사용자 기능인지 구분해야 합니다. 그다음 소유 팀, 패치 방향, 테스트 범위를 정해야 합니다.
보안 AI를 도입하는 팀은 “모델 결과를 누가 승인하는가”를 정해야 합니다. 자동으로 PR을 만들 수는 있지만, 자동으로 프로덕션에 머지하면 안 됩니다. 특히 인증, 결제, 개인정보, 인프라 권한 영역은 보안 담당자나 시니어 리뷰어의 승인이 필요합니다.
첫 번째 단계는 스코프 지정입니다. 전체 레포를 한 번에 스캔하면 결과가 많아집니다. 처음에는 인증, 파일 업로드, 권한 체크, 외부 API 호출, SQL/ORM 쿼리, deserialization, CI/CD 설정처럼 위험도가 높은 영역을 나눠야 합니다.
두 번째 단계는 결과 형식 표준화입니다. AI가 자연어로 “위험해 보입니다”라고 말하는 것은 티켓이 아닙니다. 최소한 파일 경로, 함수명, 취약점 유형, 공격 전제, 재현 절차, 영향도, 추천 패치, 테스트 방법이 있어야 합니다. 이 형식이 없으면 개발자는 매번 다시 조사해야 합니다.
세 번째 단계는 패치 검증입니다. 모델이 만든 패치가 기능을 깨지 않는지 테스트해야 합니다. 단위 테스트, 통합 테스트, 보안 회귀 테스트를 분리하는 것이 좋습니다. 예를 들어 파일 업로드 취약점이면 정상 이미지 업로드, 잘못된 확장자, MIME 우회, 대용량 파일, 경로 조작 입력을 함께 테스트해야 합니다.
네 번째 단계는 공개와 조율입니다. 오픈소스나 외부 라이브러리 취약점이면 공개 시점과 패치 배포 순서가 중요합니다. AI가 취약점을 찾아도 disclosure 프로세스가 없으면 오히려 위험합니다.
첫 번째 오해는 “AI가 찾았으니 진짜 취약점이다”입니다. 모델은 강력하지만 여전히 가정 위에서 추론합니다. 실행 환경, 네트워크 정책, 배포 설정, feature flag에 따라 실제 공격 가능성이 달라집니다. 따라서 재현이 필수입니다.
두 번째 오해는 “SAST를 대체한다”입니다. AI 보안 모델은 기존 도구를 대체하기보다 보완합니다. SAST는 빠르고 일관된 패턴 탐지에 강합니다. AI는 여러 파일과 실행 맥락을 연결하는 데 강합니다. 둘을 같이 써야 합니다.
세 번째 오해는 “보안팀만 쓰면 된다”입니다. 실제 패치는 대부분 제품 개발팀이 합니다. 보안팀이 결과를 던져주기만 하면 개발팀은 업무 중단으로 느낍니다. 따라서 취약점 결과는 개발자의 언어로 바뀌어야 합니다. 어느 함수에서 어떤 입력을 검증해야 하는지, 어떤 테스트를 추가해야 하는지까지 내려와야 합니다.
Node.js API 서버를 운영하는 팀을 예로 들어보겠습니다. 먼저 Express middleware, 파일 업로드 엔드포인트, 관리자 API, 결제 webhook, Prisma 쿼리 영역을 스캔 대상으로 분리합니다. AI 보안 모델에는 “실제 exploitable path가 있는 후보만 보고하고, 재현 절차가 없으면 낮은 신뢰도로 표시하라”고 지시합니다.
결과는 GitHub Issue 템플릿으로 변환합니다. 템플릿에는 위험도, 재현 가능성, 영향 범위, 관련 파일, 추천 패치, 테스트 케이스가 들어갑니다. 이후 보안 담당자가 false positive를 걸러내고, 각 소유 팀이 패치를 작성합니다. 패치 PR에는 AI가 제안한 테스트가 포함되어야 하며, CI에서 보안 회귀 테스트를 반드시 통과해야 합니다.
이 흐름은 복잡해 보이지만, 대량 취약점 후보를 다루려면 필요합니다. AI는 발견 속도를 높입니다. 사람과 프로세스는 피해를 줄입니다.
“AI 보안 스캐너”를 찾는 독자는 도구 목록을 원할 수 있습니다. 하지만 “Project Glasswing”을 검색하는 개발자는 더 넓은 변화를 봐야 합니다. 앞으로 고성능 보안 모델이 일반화되면 공격자와 방어자 모두 자동화 수준이 올라갑니다. 방어팀은 더 빠르게 찾아야 하고, 더 빠르게 고쳐야 하며, 더 정확하게 공개해야 합니다.
특히 오픈소스 유지보수자는 부담이 커질 수 있습니다. 취약점 리포트가 늘어나면 triage 시간이 늘어납니다. 프로젝트는 보안 리포트 양식, 비공개 연락 채널, 패치 릴리스 절차, 지원 버전 정책을 미리 정리해야 합니다. 회사 내부 레포도 마찬가지입니다. AI가 찾아낸 결과를 처리할 소유자가 없으면 아무 의미가 없습니다.
출처: Anthropic 공식 발표 “Expanding Project Glasswing”, Project Glasswing 초기 업데이트, Claude Security 안내.
