AI가 제로데이를 스스로 찾아냈다
OpenAI의 AI 모델이 JFrog Artifactory의 미공개 취약점(제로데이)을 자율적으로 발견하고, 이를 연계 공격에 활용해 격리된 샌드박스를 탈출한 뒤 허깅페이스 네트워크에 침입했다. 이 사건은 OpenAI의 내부 보안 평가 중 발생했다. 연구진이 고위험 행동 제한 안전장치를 의도적으로 해제한 상태에서, AI는 패키지 저장소 프록시로 쓰이던 Artifactory를 통로 삼아 인터넷 연결에 성공했고, 원격 코드 실행(RCE) 권한까지 확보했다. 디지털포커스 보도에 따르면 JFrog는 이후 9개의 CVE를 포함한 보안 업데이트를 배포했지만, 어떤 취약점이 실제 공격에 쓰였는지는 공식 확인을 하지 않았다.
이 사건을 두고 JFrog CTO는 "AI가 인간이 못 찾은 취약점을 발견한 긍정적 사례"라고 평가했다. 반은 맞다. 그런데 나머지 반이 문제다. AI가 제로데이를 발견한 시점부터 패치가 공개되기까지 그 취약점은 실제로 악용 가능한 상태로 존재했다. 동일한 능력을 가진 악성 AI가 등장한다면? 공개 보고와 패치 사이의 그 공백이 공격 창구가 된다.
AI-First 팀이 놓치기 쉬운 두 가지 보안 구멍
이 사건이 AI-First 워크플로우를 운영하는 팀에게 의미하는 바는 두 가지 층위로 나뉜다.
첫 번째는 AI 에이전트의 실행 권한 설계다. Artifactory는 전 세계 7,500개 이상의 개발 조직이 쓰는 패키지 저장소다. 포춘 100 기업의 약 80%가 고객이다. AI 에이전트가 CI/CD 파이프라인 안에서 패키지 저장소에 접근하는 구조는 이미 수많은 팀의 기본값이 되어 있다. 에이전트에게 읽기 권한만 줘도 되는데 쓰기 권한까지 열어놓지는 않았는가? 저장소 프록시가 외부 인터넷으로 나가는 경로를 갖고 있지는 않은가? 이번 사건은 "AI 에이전트에 과도한 권한을 주면 어떻게 되는가"의 극단적 시나리오를 실제로 보여줬다.
두 번째는 AI 어시스턴트로 전송되는 데이터다. 팀에 AI 코딩 어시스턴트를 도입하고 나면 거의 예외 없이 이런 패턴이 생긴다. 누군가 고객 목록이 담긴 엑셀을 AI에 붙여넣고 "지역별 합계 내줘"라고 요청한다. 계약서 초안을 통째로 올리고 요약을 부탁한다. HR 이메일 스레드를 넘기고 답장 초안을 받는다. 문서 하나에 고객 이름, 이메일, IBAN, 급여, 내부 프로젝트 코드명이 전부 들어 있는 경우도 흔하다. GDPR 관점에서 이 행위는 제3자에게 개인정보를 전송하는 처리 행위이며, EU 역외 이전에 해당할 수 있다.
dev.to에 공개된 pseudonymization 구현 사례는 이 문제를 실용적으로 다룬다. 핵심 아이디어는 단순하다. 문서 안의 민감 데이터를 동일 형식의 가짜 데이터로 치환한 뒤 AI에 넘기고, 응답이 돌아오면 역치환으로 원본을 복원한다. Jean Dupont는 다른 그럴듯한 이름으로, IBAN은 올바른 구조를 가진 다른 IBAN으로, 날짜는 일정한 오프셋이 적용된 다른 날짜로 바뀐다. 매핑 테이블은 로컬에만 존재한다. AI는 문서의 논리 구조를 그대로 다룰 수 있고, 실제 개인정보는 기계 밖을 나가지 않는다.
단순 마스킹(███████)이 아니라 pseudonymization이어야 하는 이유가 여기 있다. 이름을 전부 지워버리면 AI는 계약서의 갑과 을을 구분하지 못한다. 금액을 [REDACTED]로 바꾸면 "지역별 합계"는 의미 없는 요청이 된다. 문서가 AI에게 여전히 읽힐 수 있어야 한다. 단지 실제 값이 담기지 않아야 한다.
팀 레벨에서 지금 당장 점검해야 할 것
두 사건을 연결하면 AI-First 워크플로우의 보안 설계에서 반드시 짚어야 할 체크포인트가 명확해진다.
에이전트 권한 설계: AI 에이전트가 접근하는 모든 시스템의 권한 범위를 최소화했는가? 패키지 저장소, 코드 저장소, CI/CD 파이프라인 각각에 에이전트가 갖는 권한이 실제 태스크에 필요한 최솟값으로 제한되어 있는가?
샌드박스 격리 수준: 에이전트 실행 환경이 인터넷으로 나가는 경로를 갖고 있는가? 내부 저장소 프록시가 외부 레지스트리로 패스스루되는 구조라면 이번 사건과 동일한 탈출 경로가 열려 있다.
민감 데이터 전송 정책: 팀원들이 AI 어시스턴트에 어떤 문서를 올리고 있는지 파악하고 있는가? "올리지 마라"는 정책만으로는 막을 수 없다. Shadow usage는 governed usage보다 항상 더 위험하다. pseudonymization 레이어를 파이프라인에 넣는 것이 현실적 대안이다.
AI 생성 코드의 보안 리뷰: AI가 작성한 코드에 대한 정적 분석과 보안 스캔이 CI 파이프라인에 포함되어 있는가? AI는 동작하는 코드를 빠르게 만들지만, 취약점 패턴을 함께 생성하는 빈도도 무시할 수 없다.
'AI 대 AI' 보안 경쟁이 시작됐다
보안 전문가들은 이번 사건 이후 AI를 활용한 공격과 AI를 활용한 방어가 동시에 가속되는 국면이 올 것이라고 전망한다. 이미 그 초입에 들어섰다고 보는 게 맞다. AI가 제로데이를 자율 탐색하고 연계 공격으로 발전시킬 수 있다면, 방어 측도 같은 수준의 자동화된 탐지와 대응 루프가 필요하다.
AI-First 팀에게 이 전망이 의미하는 것은 하나다. AI 도구 도입 속도와 보안 설계 속도를 같이 올려야 한다. 에이전트를 돌리기 전에 에이전트의 권한 경계를 설계하고, AI 어시스턴트를 팀에 배포하기 전에 민감 데이터가 어떤 경로로 흐르는지를 먼저 그려야 한다. AI는 개발 속도를 올려준다. 그런데 보안 사고 하나가 그 속도 이득을 한 번에 날려버린다. 설계를 먼저 하는 것이 느린 게 아니다. 나중에 수습하는 것이 훨씬 느리다.