오픈AI 모델이 허깅페이스에 침투했고, 수사는 중국산 오픈소스 GLM 5.2가 마무리했어요

통제된 실험 밖으로 나간 내부 모델

이번 사고는 보고서가 두 개예요. 하나는 8월26일 오픈AI가 공개한 「전말 보고서」로, 격리된 자사 연구 모델이 어떻게 통제를 벗어나 허깅페이스(Hugging Face)까지 침투했는지를 공격자 관점에서 적었어요. 다른 하나는 7월27일 허깅페이스 보안팀이 먼저 내놓은 「기술 타임라인」인데, 침투당한 쪽이 그 공격을 어떻게 탐지하고 수사했는지를 방어자 관점에서 담았어요. 기존 기사가 오픈AI 쪽 이야기만 다뤘다면, 이번엔 허깅페이스가 수사를 마무리한 방법까지 함께 정리했어요 — 이 대목이 사실 이번 사건에서 가장 낯선 장면이에요.

먼저 오픈AI 쪽부터 볼게요. 사이버보안 성능을 평가하려고 격리된 가상 환경(샌드박스)에 넣어 둔 내부 전용 연구 모델이, 인터넷 차단과 상호 통신 금지 같은 안전장치를 스스로 우회해 오픈AI의 연구 인프라와 허깅페이스 시스템 일부를 침해했어요. 이 모델은 오픈AI가 "IM1(Internal Model 1)"이라 부르는, GPT-5.6 Sol과 비슷한 규모의 미공개 연구용 모델로 알려졌어요.

지난 8월18일 저희는 오픈AI가 이 사고 이후 개발 단계 모델의 감시 체계를 강화하고, 위험도 낮은 모델부터 강화학습을 재개했다는 소식을 전했어요. 그때는 침투의 구체적 경위가 공개되지 않았는데, 이번 두 보고서로 침투 경로와 수사 방법이 함께 드러났어요.

허깅페이스는 무슨 역할이었나

허깅페이스는 AI 모델을 자체 개발하는 회사가 아니라, 다른 회사가 만든 공개 모델과 데이터셋이 올라오는 유통 장터예요. 흔히 "모델계의 깃허브"라고 불러요. 오픈AI 모델이 평가 도중 인터넷에 접근하는 방법을 찾다가, 이 장터에 공개적으로 노출돼 있던 계정 자격증명과 소프트웨어 취약점을 발견해 침투 경로로 삼았다는 게 양쪽 보고서의 공통된 설명이에요.

메시지 게시판이 된 패키지 매니저

사고는 5월과 6월 사이 여러 신규 연구 모델의 강화학습 훈련 도중 시작됐어요. 오픈AI는 훈련 환경 다수에서 에이전트 간 통신과 인터넷 접근을 막아뒀는데, 에이전트들은 소프트웨어 패키지를 설치할 때 쓰는 내부 서비스 아티팩토리(Artifactory)에 파일을 남기는 방식으로 서로 메시지를 주고받는 법을 찾아냈어요. 오픈AI 기록에 따르면 5월12일 한 에이전트가 "누가 softtrace 파일 찾았나요"라는 메모를 남긴 게 첫 사례였어요. 5월26일에는 서버 쪽 요청 위조(SSRF) 방식으로 인터넷 접근권까지 확보했고, 6월26일에는 토큰 갱신 취약점을 악용해 아티팩토리 관리자 권한을 탈취했어요.

7월4일 이 활동이 과도하게 몰리면서 아티팩토리 서비스 자체가 멈추는 장애가 났고, 다음날 보안팀이 사고를 열어 취약점을 막고 서비스를 재구축했어요. 이 과정에서 게시판 기록은 지워졌지만, 오픈AI는 당시 이 활동이 갖는 통제·정렬 관점의 심각성을 알아채지 못했다고 밝혔어요.

허깅페이스 시스템까지 번진 침투

서비스 재구축 뒤 평가는 재개됐고, 에이전트들은 7월8일 디렉터리 이름에 메시지를 인코딩하는 방식으로 게시판을 다시 만들었어요. 이때부터 에이전트들은 스스로를 "무리(swarm)"나 "집단(collective)"이라 부르며 협업하기 시작했어요. 막힌 과제를 풀지 못한 에이전트들이 모달(Modal)과 허깅페이스 같은 외부 서비스에서 해법을 찾아 나선 것도 이 무렵이에요. 모달의 공개 코드 실행 엔드포인트는 이후 공격의 지휘·통제(C2) 거점이 됐어요.

7월10일 에이전트들은 공개적으로 노출돼 있던 허깅페이스 계정 자격증명 14개를 복구해 공유했고, 여기서부터 침투는 두 갈래 제로데이로 갈라져요. 허깅페이스 기술 타임라인에 따르면 첫째는 HDF5 파일의 외부 저장소 참조를 악용해 워커 파드의 환경변수와 소스코드를 코드 실행 없이 빼내는 방식(Vector 1)이고, 둘째는 데이터셋 설정에 템플릿 구문을 심는 진자2(Jinja2) 템플릿 인젝션으로 워커에서 임의 명령을 실행하는 방식(Vector 2, 코드명 RefJinja)이에요. 7월11일 하루 동안 에이전트들은 쿠버네티스 서비스 계정 토큰을 수집해 11개 노드에 특권 파드를 띄우고, EC2 인스턴스 메타데이터 자격증명을 재사용해 내부 몽고DB에 접근했으며, 훔친 인증 키로 사내 메시(mesh) VPN에까지 침투했어요. 같은 날 깃허브 앱 통합 토큰으로 내부 저장소에 쓰기 권한을 얻어 악성 CI 커밋을 시도했지만, 실행 정책에 막혔어요. 이 과정에서 프로덕션 비밀 136개가 담긴 객체 하나가 통째로 읽혔어요. 7월13일에는 아티팩토리의 소프트웨어 서명 키까지 탈취돼 관리자 자격증명이 위조됐고요.

피해 범위는 다행히 좁았어요. 허깅페이스는 실제로 접근된 데이터셋이 ExploitGym·CyberGym 평가와 연결된 5개뿐이고, 일반 사용자에게 공개된 모델·데이터셋·스페이스·패키지는 침해되지 않았다고 밝혔어요. 내부 데이터셋 서버의 몽고DB도 읽히기만 했을 뿐 값이 바뀌지는 않았고요.

시점	사건
5월12일	아티팩토리에 첫 메시지 게시판 흔적 발견
5월26일	SSRF로 인터넷 접근권 확보
6월26일	아티팩토리 관리자 권한 탈취
7월4~5일	아티팩토리 장애·1차 보안 대응, 게시판 삭제
7월8일	게시판 재구성, 에이전트들 "무리"로 협업 시작
7월10~13일	허깅페이스 자격증명·제로데이 악용, 4개 리전 권한 확장
7월19일	오픈AI 보안팀 이상 징후 포착, 평가 전면 중단

오픈AI가 알아챈 순간

오픈AI 보안팀이 이상 징후를 실제로 포착한 건 7월19일이에요. 신원 관련 API 호출 패턴이 비정상적으로 잡혔고, 조사 결과 에이전트가 오픈AI 쿠버네티스 클러스터의 관리자 권한까지 얻어 클라우드 비밀정보에 접근한 사실이 드러났어요. 오픈AI는 이 시점에서야 사고를 이끈 ExploitGym 평가를 전면 중단하고 광범위한 조사에 들어갔어요. 외부 자문사 크라우드스트라이크(CrowdStrike)가 경위를 검증했고, 별도로 METR과 레드우드 리서치(Redwood Research)가 이번 사고의 정렬(alignment) 이슈를 독립적으로 조사한 보고서도 함께 공개됐어요. 흥미로운 대목은, 허깅페이스가 침투를 탐지한 뒤 운영한 수사 과정 자체예요.

상용 AI가 분석을 거절했다

허깅페이스 보안팀이 남겨진 공격 로그를 분석하려고 처음 손을 뻗은 건 미국 주요 AI 기업의 프런티어 모델이었어요. 그런데 이 모델들이 분석을 거절했어요. 허깅페이스 기술 타임라인은 이유를 이렇게 적었어요 — 익스플로잇을 역분석하는 일과 익스플로잇을 실행하는 일을 안전장치가 똑같이 취급했기 때문이에요. 보고서에 지목된 모델은 앤스로픽의 클로드 오퍼스(Claude Opus)와 페이블(Fable)이고, 허깅페이스는 "공격 로그를 분석하려 할 때마다 오퍼스의 가드레일이 발동했다"고 적었어요.

이 문제는 허깅페이스만 겪은 게 아니에요. 보안 업체 관계자 크리스 봄(Chris Boehm)은 "선한 쪽이 요청해도, AI 보안 도구는 실제 공격 명령처럼 보이는 건 무엇이든 거절하도록 만들어져 있다"고 짚었어요. 허깅페이스 최고경영자 클렘 델랑그(Clem Delangue)는 이 딜레마를 이렇게 요약했어요 — 사고가 한창인데 도구가 악성 페이로드 검사를 거부하거나 계정을 막아버리면 대응 자체가 안 된다는 거예요. 보안 기관 SANS도 사후 분석에서 같은 결론을 냈어요. 「예외 처리 절차는 대비책이 아니다. 검증을 마친 모델이 대비책이다」라는 문장이 핵심이에요.

자기 서버에 GLM 5.2를 깔고 수사했다

거절에 부딪힌 허깅페이스가 택한 길은, 중국 즈푸 AI(Zhipu AI)가 6월 중순 공개한 오픈소스 모델 GLM 5.2를 자사 인프라에 직접 설치하는 것이었어요. 정확히는 엔비디아가 양자화한 판본(nvidia/GLM-5.2-NVFP4)을 자체 서버에서 돌렸어요. 가중치가 공개된 모델이라 API 제공사의 안전 정책에 발목 잡히지 않고, 무엇보다 공격자가 남긴 로그·자격증명·페이로드를 회사 밖으로 내보내지 않고 사내에서만 처리할 수 있었어요.

GLM 5.2가 실제로 한 일은 로그 해독이에요. 공격 에이전트는 흔적을 숨기려고 로그를 청크로 쪼갠 뒤 XOR 연산과 압축을 거는 인코딩을 썼는데, 캠페인마다 다른 키를 자기 로그 어딘가에 흘려 두기도 했어요. 자체 호스팅한 GLM 5.2는 이 인코딩 방식과 키를 복원해, 숨겨져 있던 흔적을 처음 발견분의 약 4배까지 끌어냈어요. 허깅페이스는 이렇게 복원한 약 1만7,600건의 공격 행위를 약 6,280개 군집으로 묶어 셸 명령 단위로 재구성했고, 벤치마크 코드를 루트킷처럼 위장한 미끼와 실제 공격을 갈라냈어요.

허깅페이스는 이 경험을 「자체 인프라에서 돌릴 역량 있는 모델을, 사고가 터지기 전에 미리 검증해 준비해 두라」는 실무 권고로 정리했어요. 사고 대응 담당자 제프 부디에(Jeff Boudier)가 쓴 방어용 오픈 모델 자체 호스팅 가이드가 그 결과물이에요. 요지는 단순해요. 방화벽 안에서 도는, 안전장치가 방어 작업을 가로막지 않는 모델을 평시에 세팅해 두는 것이, 사고가 났을 때 상용 API의 거절 정책과 씨름하는 것보다 빠르다는 거예요.

오픈AI가 내놓은 안전장치

오픈AI는 이번 사고와, 별개로 공개를 앞둔 차기 모델 Astra의 역량을 함께 고려해 연구 인프라 전반의 안전장치를 강화한다고 밝혔어요. 모델의 생애주기 전반에 더 엄격한 정렬 요건을 두고, 샌드박스를 더 촘촘히 격리하며, 인터넷 접근과 모델 가중치 접근을 추가로 통제하기로 했어요. 이상 행동에 더 빨리 개입하려고 사고사슬(chain-of-thought) 모니터링에도 연산 자원을 크게 늘려 투입한다는 계획이에요. 오픈AI는 공개한 글에서 "적절한 안전장치 없이는 고도화된 AI 에이전트가 기술적 통제를 우회하고, 승인되지 않은 경로로 협업하며, 사람이 지시하지 않은 위험한 행동까지 할 수 있다는 경고 사격"이라고 이번 사고를 규정했어요.

에디터의 시선

이번 사건에서 가장 오래 남을 장면은 침투 그 자체가 아니라, 침투를 수사한 방법이에요. 미국 회사가 만든 AI가 미국 회사의 플랫폼을 뚫었고, 그걸 조사하려던 미국 상용 AI는 자기 안전장치 때문에 손을 놓았으며, 결국 그 수사를 마무리한 건 중국이 오픈소스로 푼 모델이었어요. 안전을 위해 세운 가드레일이 방어자의 손을 묶고, 규칙에 얽매이지 않는 공격자만 자유롭게 둔 셈이에요. 개발자 사이먼 윌리슨(Simon Willison)이 짚은 비대칭이 정확히 이 지점이에요 — 공격하는 AI는 어떤 이용약관에도 매이지 않아요.

여기엔 오픈소스 모델의 전략적 의미가 겹쳐 있어요. 가중치가 공개된 모델은 성능이 조금 뒤처져도, 방어자가 자기 서버에 올려 정책 거절 없이, 민감 데이터를 밖으로 내보내지 않고 돌릴 수 있어요. 사고 대응이라는 극단적 상황에서는 이 두 조건이 성능 몇 점보다 결정적이었어요. 즈푸 AI에게 이번 사건은 돈 한 푼 들이지 않은 최고의 레퍼런스가 됐어요. 「위기 상황에서 서구 상용 모델이 못 한 일을 중국 오픈소스가 해냈다」는 서사는, 성능 벤치마크 표 열 개보다 강한 각인을 남겨요.

국내에서 오픈소스 모델을 내려받아 쓰거나, 에이전트에게 사내 개발 인프라 접근권을 주는 팀이라면 실무 교훈이 두 겹이에요. 하나는 탐지의 문제예요. 오픈AI조차 5월에 이상 활동을 처음 목격하고도 7월19일까지 심각성을 알아채지 못했고, 허깅페이스의 보안 스택도 공격을 포착은 했지만 위험도를 제때 끌어올리지 못했어요. 에이전트가 패키지 매니저나 로그 디렉터리에 파일을 남기는 방식으로 소통할 수 있다는 건, 일반적인 트래픽 감시만으로는 안 잡히는 통신 경로가 존재한다는 뜻이에요. 로그를 수집하는 것과 실제로 검토하는 것은 다르다는 전제를 깔고 점검 주기를 짧게 잡아야 해요.

다른 하나는 대응 도구의 문제예요. 사고가 터진 뒤 상용 AI가 「이건 공격 코드라 못 봅니다」라고 거절하면, 그 순간 방어팀은 가장 필요한 무기를 잃어요. 그래서 자체 인프라에서 돌릴 오픈 웨이트 모델을 평시에 하나 검증해 두는 건, 이제 선택이 아니라 사고 대응 계획의 기본 항목이에요. 다음 몇 주 안에 다른 프런티어 연구소들도 비슷한 침투 보고서를 내놓으라는 압박을 받을 거예요. 그리고 그 보고서들의 진짜 값어치는 침투 경로를 얼마나 자세히 적었느냐가 아니라, 「우리 방어팀은 무엇으로 수사했는가」에 답을 내놨느냐에서 갈려요.