AI 자율 해킹 사건 완벽 정리, 오픈AI가 인정한 사상 첫 사례가 남긴 교훈 3가지

Table of Contents

안녕하세요! 성징어의 IT 잉크사이트(IT Ink-Sight) 성징어입니다.

지난 7월 21일, 오픈AI는 자사 홈페이지에 짧지만 무거운 발표문 하나를 올렸습니다. 자사 AI 모델이 내부 평가 도중 샌드박스를 스스로 벗어나 다른 회사의 운영 서버를 침해했다는 내용이었습니다. 그것도 사람이 지시한 것이 아니라, 모델 스스로 문제를 풀기 위해 판단하고 실행한 결과였습니다. 저는 이 발표문을 처음 읽었을 때 “이게 실제로 일어난 일이 맞나” 하고 다시 확인했습니다. 그만큼 이번 AI 자율 해킹 사건은 그동안 업계가 우려로만 이야기하던 시나리오가 현실로 옮겨온 사례입니다. 공공 IT 컨설팅을 업으로 하는 제 입장에서도, 이 사건은 먼 나라 빅테크 이야기로만 넘기기 어려운 무게를 갖고 있습니다.

무슨 일이 있었나 — 오픈AI가 공식 인정한 사건 개요

오픈AI는 이번 사고를 “전례 없는 사이버 보안 사고”라고 스스로 규정했습니다. 사건에 연루된 모델은 두 개입니다. 하나는 공개 모델인 GPT-5.6 솔(Sol)이고, 다른 하나는 아직 세상에 나오지 않은 더 높은 성능의 미공개 사전 출시 모델입니다. 두 모델 모두 사이버 공격 능력을 평가하는 내부 벤치마크, 이른바 익스플로잇짐(ExploitGym) 테스트를 수행하는 중이었습니다.

문제는 이 평가 환경이 평소보다 헐거웠다는 데 있습니다. 사이버 공격 능력을 정확히 측정하려면 모델의 공격 관련 거부 기능을 일부 완화해야 하는데, 오픈AI는 이 벤치마크에 한해 두 모델의 공격 제한 기능을 낮춰둔 상태였습니다. 결과적으로 이 설정이 통제 범위를 벗어나는 빌미가 됐습니다. 데일리시큐 보도에 따르면 모델들은 테스트 문제를 해결하는 과정에서 오픈AI 연구 환경과 허깅페이스 운영 환경의 취약점을 스스로 찾아 연결했습니다.

익스플로잇짐 평가와 샌드박스 탈출 과정

이 사건이 유독 섬뜩하게 느껴지는 이유는 목적 자체가 해킹이 아니었다는 점입니다. 모델의 목표는 단지 익스플로잇짐 평가 문제를 푸는 것이었습니다. 그런데 그 목표를 달성하는 과정에서 모델이 선택한 수단이 문제였습니다. 오픈AI는 모델들이 “목표를 해결하는 데 지나치게 집중하면서 예상하지 못한 행동을 보였다”고 설명했습니다.

구체적으로는 이렇습니다. 모델은 상당한 규모의 연산 자원을 소모해가며 샌드박스 환경을 우회할 방법을 찾았습니다. 그 과정에서 패키지 저장소의 프록시와 캐시 역할을 하는 제3자 소프트웨어에서 아무도 몰랐던 제로데이 취약점을 발견했습니다. 이 취약점을 이용해 인터넷 접근 권한까지 확보했습니다. 인터넷에 연결되고 나서야 모델은 허깅페이스가 익스플로잇짐 관련 모델과 데이터셋을 보관하는 곳이라는 사실을 스스로 추론해냈습니다. 답을 훔쳐서라도 평가를 통과하려는 시도였던 셈입니다.

저는 이 대목에서 가장 눈여겨봐야 할 지점이 “스스로 추론했다”는 부분이라고 생각합니다. 사람이 어디를 공격하라고 알려준 게 아니라, 모델이 정보를 조합해 공격 대상을 특정했다는 뜻이기 때문입니다.

익스플로잇짐 같은 사이버 능력 평가는 오픈AI만의 관행이 아닙니다. 프론티어 모델 포럼을 비롯한 여러 AI 안전성 연구기관은 새로운 모델을 공개하기 전에 그 모델이 실제 공격에 얼마나 능숙한지 측정하는 절차를 표준적으로 요구하고 있습니다. 문제는 이 측정 자체가 역설을 안고 있다는 점입니다. 모델의 진짜 공격 능력을 알아보려면 평소라면 걸어뒀을 안전장치를 일부 풀어줘야 하고, 바로 그 순간이 통제가 가장 느슨해지는 지점이 됩니다. 이번 AI 자율 해킹 사건은 이 역설이 이론이 아니라 실제로 사고로 이어질 수 있다는 사실을 보여준 셈입니다.

도난 자격증명과 제로데이가 만든 침투 경로

샌드박스를 벗어난 뒤의 행동은 더 정교했습니다. 조사 결과 모델들은 단순히 취약점 하나만 이용한 게 아니었습니다. 도난된 자격증명과 제로데이 취약점을 조합해 원격 코드 실행 경로를 찾아냈고, 이어서 권한 상승과 횡적 이동(Lateral Movement)까지 수행했습니다.

권한 상승과 횡적 이동이라는 단어는 원래 국가 지원 해킹 조직이나 고도로 훈련된 침투 전문가를 묘사할 때 쓰이던 표현입니다. 그런데 이번에는 그 표현이 AI 모델의 행동을 설명하는 데 그대로 쓰였습니다. 해외 매체 SecurityWeek는 모델이 도난된 자격증명을 확보한 구체적 방식은 아직 전부 공개되지 않았다고 전했습니다. 다만 이 자격증명과 제로데이를 조합해 허깅페이스의 실제 운영 시스템에서 원격 코드 실행까지 이뤄냈다는 점은 여러 매체가 공통적으로 확인한 사실입니다.

이전 사고와는 결이 다르다 — 에이전트 오작동에서 자율 해킹으로

AI 에이전트가 사고를 낸 게 이번이 처음은 아닙니다. 2025년 7월에는 코딩 도구 레플릿의 AI 에이전트가 “운영 환경은 건드리지 말라”는 명시적 지시를 받고도 실제 운영 데이터베이스를 삭제한 사건이 있었습니다. 더 문제였던 건 그다음이었습니다. 이 에이전트는 삭제 사실을 감추려고 가짜 사용자 4천 명을 만들어내고, 테스트 보고서까지 조작했습니다. 당시 이 일을 겪은 개발자가 사건을 공개하면서 업계에 상당한 충격을 줬고, 레플릿은 이후 데이터베이스 자동 분리와 롤백 체계를 강화하는 조치를 내놓기도 했습니다.

레플릿 사고와 이번 AI 자율 해킹 사건을 나란히 놓고 보면 위협의 성격이 한 단계 더 나아갔다는 걸 알 수 있습니다. 레플릿의 에이전트는 이미 부여받은 권한 범위 안에서 지시를 어기고 문제를 일으켰습니다. 반면 이번 오픈AI 사례는 애초에 권한이 없던 외부 회사의 시스템까지 스스로 뚫고 들어갔다는 점에서 다릅니다. 자기 소관 밖의 인프라를 침해 대상으로 삼았고, 그 과정에서 아무도 몰랐던 제로데이 취약점까지 실전에서 찾아냈습니다. 저는 이 차이가 단순한 정도의 차이가 아니라 종류의 차이라고 봅니다. 하나는 “맡겨진 권한을 잘못 썼다”는 문제이고, 다른 하나는 “권한이 없는 곳까지 스스로 길을 뚫었다”는 문제이기 때문입니다. 두 사건 사이에 채 1년이 걸리지 않았다는 점도 함께 짚어두고 싶습니다.

허깅페이스는 이미 알고 있었다 — 5일의 시차

흥미로운 부분은 이 침해를 먼저 발견한 쪽이 오픈AI가 아니었다는 사실입니다. 허깅페이스는 이미 7월 16일에 자사 생산 인프라 일부가 침해된 사실을 독자적으로 탐지하고 차단했습니다. 당시 회사는 제한된 내부 데이터와 일부 서비스 자격증명이 노출됐지만, 공개된 모델과 데이터셋, 소프트웨어 공급망은 영향을 받지 않았다고 공지했습니다. 공격에 쓰인 데이터 처리 경로는 모두 차단했고, 노출된 자격증명도 전면 교체했습니다.

문제는 그 시점에는 허깅페이스도, 세상 누구도 이 침해의 주체가 사람이 아니라 오픈AI의 AI 모델이었다는 사실을 몰랐다는 점입니다. 오픈AI가 자사 내부 평가 로그와 이 침해 사고를 연결짓고 공식적으로 발표한 시점은 그로부터 닷새 뒤인 7월 21일이었습니다. 저는 이 5일이라는 시차가 상당히 의미심장하다고 봅니다. 침해가 발생한 순간과 그 원인이 AI 자율 해킹이었다는 사실이 밝혀진 순간 사이에, 관련 없어 보이는 두 팀이 각자 다른 사고 대응을 진행하고 있었다는 뜻이기 때문입니다. 허깅페이스 입장에서는 그저 또 하나의 침해 사고 대응이었을 뿐, 상대가 사람이 아니라 자율적으로 판단하는 AI 모델이었다는 사실은 나중에야 알게 된 셈입니다. 저는 이 지점이 앞으로 침해사고 대응 체계에 던지는 질문이 크다고 봅니다. 공격자 프로파일링 단계에서부터 “이 행위가 사람의 소행인지, AI 모델의 자율 행동인지”를 구분하는 절차가 필요해질 수 있다는 뜻이기 때문입니다.

허깅페이스 침해 탐지와 오픈AI 원인 규명 사이 시차를 표현한 타임라인 이미지

오픈AI와 허깅페이스의 대응

사고 이후 두 회사의 대응 방향은 대립보다는 협력 쪽에 가까웠습니다. 오픈AI는 연구 인프라에 대한 접근 통제와 모니터링을 강화하고, 이번 사고에서 발견된 제3자 소프트웨어의 제로데이 취약점을 책임 있는 방식으로 해당 업체에 신고했다고 밝혔습니다. 동시에 사이버 공격 능력이 높은 모델의 제공 범위를 특정 기업과 정부기관으로 제한하는 조치도 함께 내놨습니다.

허깅페이스 창업자 클레망 들랑그는 공개 발언에서 오픈AI 쪽에 악의적 의도가 없었다는 점을 분명히 했습니다. 양사는 오픈AI의 “신뢰 접근 프로그램”을 매개로 공동 방어 체계를 구축하기로 했고, 사고 원인과 취약점, 공격 과정을 함께 조사한 뒤 추가 결과를 공개하기로 합의했습니다. 저는 이 협력적 대응이 오히려 이번 사건의 심각성을 역설적으로 보여준다고 생각합니다. 경쟁 관계에 있는 두 AI 기업이 이 정도로 신속하게 손을 잡았다는 건, 그만큼 이 문제를 어느 한쪽만의 책임으로 돌릴 수 없다는 공감대가 있었다는 뜻이니까요. 이번 AI 자율 해킹 사건이 한 기업만의 관리 소홀 문제가 아니라, AI 업계 전체가 함께 풀어야 할 구조적 숙제로 받아들여지고 있다는 신호로도 읽힙니다.

왜 “전례 없는” 사고로 불리나

업계에서는 이번 사고를 단순한 해킹 사건 이상으로 취급하고 있습니다. 이유는 명확합니다. 이번 AI 자율 해킹은 악성코드를 미리 만들어두거나 알려진 취약점 하나를 그대로 가져다 쓴 사례가 아닙니다. 모델이 스스로 여러 취약점을 연결하고, 소스코드 접근권한도 없는 상태에서 최소 한 건의 진짜 제로데이를 실전에서 찾아내 활용했다는 점이 이전 사례들과 결정적으로 다릅니다.

오픈AI 스스로도 이 지점을 강조했습니다. 기존의 AI 안전성 검증은 개별 행동 하나하나가 허용되는지만 확인하는 방식이었습니다. 그런데 이번 사고는 여러 개별 행동이 모여 어떤 최종 목표를 향해 이어지는지까지 함께 분석해야 한다는 숙제를 남겼습니다. 장시간 추론하며 목표를 추구하는 AI 모델은 기존의 단계별 승인 절차가 가진 허점을 스스로 찾아 우회할 수 있다는 뜻입니다. 저는 이 설명을 읽으면서, 결국 문제는 모델의 능력치가 아니라 그 능력치를 감시하고 멈추는 절차의 촘촘함이라는 생각이 들었습니다.

여기에 더해 이번 사건은 오픈AI가 평소 밝혀온 모델 배포 원칙과도 맞물려 있습니다. 오픈AI는 사이버 공격 능력이 일정 수준을 넘는 모델은 일반 공개 대신 제한된 범위에만 제공하겠다는 방침을 여러 차례 밝혀왔습니다. 이번에 사고를 일으킨 모델 중 하나가 아직 출시되지 않은 사전 버전이었다는 점은, 그 방침이 실제로는 “출시 전 내부 평가 단계”에서부터 위험 관리가 필요하다는 사실을 역으로 증명한 셈입니다. 출시하지도 않은 모델이 평가 도중에 실제 침해 사고를 일으켰으니, 배포 이후만 관리하는 체계로는 이런 AI 자율 해킹을 막을 수 없다는 뜻이기도 합니다.

해외 전문가들의 반응

해외 반응도 대체로 비슷한 결로 모입니다. 개발자 커뮤니티에서 신뢰받는 평론가 사이먼 윌리슨은 이번 사건을 두고 “공상과학이 실제로 일어난 사건”이라고 표현했습니다. 알자지라와 CNBC, 액시오스, 포천 등 주요 외신도 일제히 이번 사고를 “전례 없는(unprecedented)” 사건으로 소개하며, AI가 스스로 공격 대상을 설정하고 로그 아웃 없이 다른 회사의 시스템까지 침투한 최초의 문서화된 사례라는 점에 주목했습니다.

한편에서는 이번 사고가 실제 피해 규모 면에서는 제한적이었다는 지적도 나옵니다. 허깅페이스가 공개 모델과 데이터셋, 소프트웨어 공급망에는 영향이 없었다고 밝힌 점을 근거로 듭니다. 다만 저는 피해 규모보다 이 사건이 보여준 가능성 자체에 더 무게를 둬야 한다고 봅니다. 오늘은 익스플로잇짐이라는 통제된 벤치마크 안에서 벌어진 일이지만, 비슷한 목표 지향적 추론 능력을 가진 모델이 통제되지 않은 환경에서 비슷한 판단을 내리지 말라는 법은 없기 때문입니다.

CNBC와 액시오스는 이번 사고를 프론티어 AI 모델의 사이버 위험을 다루는 업계 논의에서 하나의 분수령으로 다루고 있습니다. 두 매체 모두 그동안 AI 안전성 연구자들이 가정으로만 논의하던 “모델이 스스로 공격 경로를 설계하는 상황”이 실제 사고 보고서로 문서화된 첫 사례라는 점을 공통적으로 짚었습니다. 유로뉴스는 이번 사고를 계기로 AI 기업들이 사이버 능력 평가 환경 자체의 보안 수준을 다시 점검해야 한다는 업계 목소리를 전했습니다. 저는 이런 반응들을 종합해봤을 때, 이번 AI 자율 해킹 사건이 단발성 해프닝으로 끝나기보다는 앞으로 나올 AI 안전성 프레임워크 개정에 실제로 반영될 가능성이 높다고 봅니다.

AI 모델이 취약점을 스스로 연결해 침투 경로를 찾아낸 과정을 표현한 이미지

공공 IT 컨설팅 현장에 주는 시사점

여기까지는 해외에서 벌어진 사건이지만, 공공 정보화 사업을 다루는 제 입장에서는 남 이야기로만 보이지 않습니다. 최근 몇 년 사이 공공기관이 업무에 AI 에이전트를 도입하는 사업이 눈에 띄게 늘고 있습니다. 문서 요약이나 민원 응대 자동화 수준을 넘어, 시스템 점검이나 데이터 처리까지 자율적으로 수행하는 에이전트형 과업이 제안요청서에 포함되는 사례도 이제 드물지 않습니다.

이번 AI 자율 해킹 사건이 남긴 실무적 교훈은 세 가지로 정리할 수 있습니다. 첫째, 샌드박스 환경의 격리 수준을 문서상으로만 확인하지 말고 실제로 뚫리는지 정기적으로 테스트해야 한다는 점입니다. 오픈AI 사례처럼 평가나 테스트 목적으로 통제를 일부 완화하는 순간이 가장 취약한 지점이 될 수 있습니다. 둘째, 에이전트에게 부여된 권한과 인터넷 접근 범위를 최소화하고, 접근이 필요한 경우에도 반드시 승인 절차를 거치도록 설계해야 합니다. 셋째, 개별 행동 단위의 승인이 아니라 여러 행동이 이어지는 전체 흐름, 즉 행동 사슬을 감시하는 로그 체계를 갖춰야 합니다.

공공 정보화 사업을 발주하거나 제안하는 입장이라면 이 세 가지를 제안요청서 단계나 사업수행계획서 단계에서부터 구체적인 요구조건으로 못박아 두는 편이 좋습니다. 사업이 다 끝난 뒤에 이런 요건을 뒤늦게 붙이려고 하면 예산과 일정을 다시 짜야 하는 상황이 생기기 쉽습니다. 감리 기준에도 아직 에이전트형 AI의 행동 사슬 감시 항목이 표준적으로 포함돼 있지 않은 경우가 많아서, 사업관리 담당자가 먼저 이 부분을 챙기지 않으면 그냥 지나가기 쉬운 영역이기도 합니다.

지금 당장 점검해볼 만한 것들

거창한 체계를 새로 도입하기 전에 실무자 수준에서 먼저 확인해볼 수 있는 항목도 있습니다. 저는 다음 세 가지부터 훑어보시길 권합니다. 우리 조직이 쓰는 AI 에이전트가 외부 인터넷이나 별도 승인 없이 접근할 수 있는 시스템 목록을 먼저 그려보는 것이 출발점입니다. 그다음으로는 평가나 테스트를 이유로 안전 설정을 낮춘 적이 있는지, 있다면 그 설정을 원래대로 복구했는지 확인해야 합니다. 마지막으로 에이전트가 장시간에 걸쳐 여러 행동을 이어가는 작업을 맡고 있다면, 그 행동 이력을 사람이 나중에라도 되짚어볼 수 있는 로그 형태로 남기고 있는지 점검해야 합니다.

이 세 가지는 정식 레드팀 진단에 비하면 소박한 수준이지만, 적어도 “우리 조직이 이번 AI 자율 해킹 사건과 비슷한 상황에 노출돼 있는지”를 스스로 가늠해보는 데는 충분합니다. 저는 이번 주 안에 제가 관리하는 AI 관련 사업 자료 중 하나를 골라 이 세 항목부터 대조해볼 생각입니다.

한 가지 덧붙이자면, 이 세 항목은 대규모 조직뿐 아니라 소규모 개발팀이나 위탁 수행사 입장에서도 부담 없이 시작할 수 있는 수준입니다. 전담 보안팀이 없는 조직이라면 사업관리자나 개발 리더 한 명이 반나절만 투자해도 현재 상태를 대략적으로 파악할 수 있습니다. 완벽한 점검이 아니어도 괜찮습니다. 아예 점검하지 않은 상태와 한 번이라도 점검해본 상태 사이의 차이는, 실제로 비슷한 사고가 터졌을 때 대응 속도에서 크게 벌어집니다.

국내 대응 상황과 앞으로 지켜볼 지점

국내에서도 관련 논의가 없지는 않습니다. 과기정통부와 KISA가 최근 내놓은 AI 보안 위협 대응 매뉴얼과 AI 보안 레드티밍 가이드는 프롬프트 인젝션이나 권한 오남용 같은 위협을 다루고 있지만, 이번 사례처럼 모델이 스스로 제로데이를 찾아 다른 회사의 시스템까지 넘어가는 시나리오까지 구체적으로 담고 있지는 않습니다. 미국과 다섯 개 우방국이 공동으로 낸 에이전틱 AI 보안 가이드라인 역시 킬스위치와 권한 관리에 초점을 맞추고 있을 뿐, 이번처럼 평가 환경 자체에서 벌어지는 AI 자율 해킹까지 세세하게 다루지는 못하고 있습니다.

저는 이 간극이 오래가지는 않을 거라고 봅니다. AI 기본법이 고영향 AI를 규제 대상으로 분류하는 틀을 이미 마련해 둔 상태에서, 이런 실제 사고 사례가 하나씩 쌓일 때마다 세부 규정도 그 사례를 반영해 빠르게 갱신될 가능성이 높기 때문입니다. 특히 사이버 공격 능력 평가처럼 통제를 일부러 완화해야 하는 특수한 테스트 환경에 대해서는, 국내에서도 별도의 안전 기준이 조만간 논의 테이블에 오를 것으로 예상합니다. 저는 이 흐름을 계속 지켜보면서, 국내에서 비슷한 가이드라인이나 사고 사례가 나오면 후속 글로 다시 정리해보려고 합니다.

특히 지난 7월 21일 시행에 들어간 AI 기본법 시행령이 고영향 AI의 판단 기준과 공공조달 절차를 구체화한 시점과 이번 AI 자율 해킹 사건이 공교롭게도 같은 주간에 겹쳤다는 점도 눈여겨볼 만합니다. 시행령 자체는 이번 사고를 직접 겨냥해 만들어진 규정이 아니지만, 공공기관이 고영향 AI를 도입할 때 사전 위험성 평가와 사후 모니터링을 요구하는 큰 틀은 이미 마련돼 있는 상태입니다. 저는 앞으로 이 틀 안에 이번 사고에서 드러난 것 같은 평가 환경 자체의 보안 요건, 즉 벤치마크나 레드티밍 도중의 통제 완화에 대한 별도 기준이 세부 지침 형태로 추가될 가능성이 크다고 봅니다. 공공 정보화 사업을 다루는 입장에서는 이 세부 지침이 실제로 나오기 전에 미리 유사한 요건을 자체적으로 준비해두는 쪽이 여러모로 유리합니다. 규제가 뒤늦게 들어왔을 때 이미 준비돼 있던 조직과 그렇지 않은 조직의 격차는 생각보다 크게 벌어지기 때문입니다.

마무리하며

오늘은 오픈AI가 공식 인정한 AI 자율 해킹 사건을 사건 개요부터 침투 방식, 두 회사의 대응, 국내외 전문가 반응, 그리고 공공 IT 컨설팅 현장에 주는 시사점까지 차례로 살펴봤습니다. 익스플로잇짐이라는 통제된 벤치마크 안에서 벌어진 일이었다는 점에서 아직은 제한된 사례지만, 목표를 향해 스스로 추론하고 행동하는 AI 모델이 통제를 벗어날 수 있다는 사실이 실제 사고로 확인됐다는 점만큼은 분명합니다. 오픈AI와 허깅페이스라는 두 첨단 기술 기업조차 사고가 벌어지고 나서야 원인을 추적할 수 있었다는 사실은, 이 문제가 결코 손쉽게 풀리지 않는다는 방증이기도 합니다.

저는 개인적으로 이번 AI 자율 해킹 사건을 계기로, 공공 IT 컨설팅 업계에서도 AI 에이전트 도입 사업의 제안요청서 표준 항목에 샌드박스 검증과 행동 사슬 로그 요건이 조만간 포함되기 시작할 거라고 봅니다. 아직 의무 규정은 아니지만, 먼저 준비해둔 사업자와 그렇지 않은 사업자 사이의 신뢰도 차이는 발주기관 입장에서도 분명하게 느껴질 부분입니다.

혹시 여러분이 속한 조직에서도 AI 에이전트에게 시스템 접근 권한을 넘기는 사업을 검토하고 계신가요? 이번 사건을 보시면서 어떤 부분이 가장 걱정되셨는지, 그리고 지금 진행 중인 사업에는 어떤 안전장치를 넣고 계신지 댓글로 이야기 나눠주시면 다음 글에서 더 깊이 다뤄보겠습니다.