Anthropic의 Project Glasswing은 critical software 보안을 위해 AWS, Apple, Broadcom, Cisco, CrowdStrike, Google, JPMorganChase, Linux Foundation, Microsoft, NVIDIA, Palo Alto Networks 등이 참여하는 이니셔티브입니다. 핵심은 Claude Mythos Preview 같은 프런티어 모델을 방어자와 유지보수자에게 조기 제공하는 것입니다.
공식 페이지에 따르면 Anthropic은 최대 1억 달러 사용 크레딧과 400만 달러 규모의 오픈소스 보안 조직 기부를 약속했고, 40개 이상의 critical software infrastructure 조직에도 접근권을 확대했습니다. 목표는 취약점 식별과 수정, critical codebase 강화, 방어 워크플로 가속입니다.
이번 소식은 기능 목록을 외우는 문제가 아니라, 제품과 운영 방식이 어디로 이동하는지 읽는 문제입니다. AI 도구가 점점 더 많은 맥락을 읽고, 더 긴 작업을 맡고, 더 많은 외부 시스템과 연결되면서 개발팀의 책임도 바뀌고 있습니다. 예전에는 모델이 답을 잘 내는지만 확인하면 됐지만, 이제는 모델이 어떤 권한으로 무엇을 실행했고, 어떤 로그가 남았고, 실패했을 때 어디에서 멈췄는지까지 봐야 합니다.
특히 작은 팀일수록 새 기능을 빠르게 붙이고 싶어 합니다. 그 자체는 맞는 방향입니다. 다만 빠른 도입과 무관리 도입은 다릅니다. Project Glasswing을 실제 서비스에 적용하려면 최소한 입력 데이터, 권한 경계, 관측 가능성, 비용 상한선을 같이 설계해야 합니다. 이 네 가지가 없으면 초반 데모는 좋아 보여도 운영 단계에서 문제를 빨리 찾지 못합니다.
제품팀은 이번 변화를 ‘사용자가 더 편해진다’로만 보면 부족합니다. 사용자가 편해질수록 더 중요한 것은 기대치 관리입니다. AI가 자연스럽게 말하거나, 코드를 실행하거나, 디자인을 만들어주거나, 보안 분석을 대신해주면 사용자는 결과를 소프트웨어의 공식 동작처럼 받아들입니다. 그래서 UI에는 능력보다 한계를 더 선명하게 드러내야 합니다.
예를 들어 추천, 자동 실행, 에이전트 작업, 보안 분석처럼 결과의 파급이 큰 기능은 “AI가 이렇게 판단했습니다”에서 끝나면 안 됩니다. 어떤 소스가 쓰였는지, 어떤 단계가 자동으로 처리됐는지, 사용자가 되돌릴 수 있는지, 사람 검토가 필요한 지점은 어디인지 보여줘야 합니다. 이 설명 계층이 없으면 초기 전환율은 올라가도 장기 신뢰는 흔들립니다.
개발팀은 API 문서만 보고 바로 붙이기 전에 실패 모드를 먼저 정의하는 편이 좋습니다. 모델이 틀린 답을 내는 경우보다 더 자주 터지는 문제는 타임아웃, 권한 부족, 도구 호출 실패, 잘못된 캐시, 오래된 컨텍스트입니다. 그래서 첫 번째 설계 문서는 프롬프트가 아니라 운영표여야 합니다.
이 기준을 잡아두면 모델이 바뀌어도 팀이 흔들리지 않습니다. 반대로 모델별 튜닝만 잔뜩 해두면 다음 업데이트 때 같은 검증을 다시 해야 합니다.
운영팀이 가장 많이 놓치는 부분은 ‘성공한 요청’입니다. 장애는 눈에 띄지만, 성공처럼 보이는 잘못된 자동화는 늦게 발견됩니다. Project Glasswing 같은 변화는 정상 응답률만 보면 좋아 보일 수 있습니다. 하지만 실제로는 더 많은 권한을 사용하거나, 더 많은 문맥을 읽거나, 더 큰 작업을 더 조용히 처리할 수 있습니다.
따라서 도입 직후에는 성공률과 함께 다음 지표를 봐야 합니다. 사람 검토에서 반려된 비율, 사용자가 되돌린 비율, 도구 호출 실패 후 재시도 횟수, 평균 응답 비용, p95 지연시간, 민감 데이터가 포함된 요청 비율입니다. 이 지표들은 화려하지 않지만 실제 운영 품질을 가장 빨리 보여줍니다.
한국 시장에서는 개인정보, 결제, 고객센터, 사내 문서처럼 민감한 업무가 빠르게 연결됩니다. 그래서 글로벌 발표를 그대로 복사하기보다 국내 서비스 구조에 맞춰 한 번 더 번역해야 합니다. 예를 들어 고객센터에 붙인다면 상담원 보조인지, 사용자가 직접 만나는 챗봇인지, 내부 QA인지에 따라 안전장치가 전혀 달라집니다. 개발도구에 붙인다면 개인 저장소인지, 회사 저장소인지, 배포 권한이 있는 저장소인지가 핵심입니다.
작게 시작하려면 읽기 전용 업무부터 붙이는 게 낫습니다. 문서 검색, 로그 요약, 코드 리뷰 초안, 디자인 방향 탐색처럼 되돌리기 쉬운 업무에서 품질과 비용을 먼저 확인하고, 그 다음에 쓰기 권한이나 자동 실행을 열어야 합니다. 이 순서를 지키면 실험 속도를 잃지 않으면서도 사고 반경을 줄일 수 있습니다.
1단계는 기존 업무 10개를 고르는 것입니다. 실제 사용자가 반복해서 하는 작업이어야 하고, 성공 기준이 명확해야 합니다. 2단계는 같은 입력을 새 기능과 기존 방식에 모두 넣고 결과를 비교하는 것입니다. 3단계는 결과 품질보다 운영 신호를 먼저 봅니다. 지연시간, 비용, 도구 호출, 승인 필요 횟수, 로그 품질이 여기에 들어갑니다. 4단계는 작은 사용자 그룹에만 열고, 반려 사례를 모아 프롬프트보다 정책을 먼저 고칩니다.
이 방식은 느려 보이지만 실제로는 빠릅니다. 문제가 생긴 뒤 전체 기능을 롤백하는 것보다, 처음부터 권한과 관측성을 작게 잡는 편이 훨씬 싸기 때문입니다.
AI가 취약점을 더 빨리 찾을 수 있게 되면 공격자도 빨라집니다. Project Glasswing의 의미는 특정 모델 공개보다, 핵심 소프트웨어를 지키는 조직들이 공동으로 AI 방어 역량을 키워야 한다는 데 있습니다.
출처: Anthropic, Project Glasswing, https://www.anthropic.com/project/glasswing
