통제할 수 없는 GPT와 클로드? 문제는 모델 아닌 하네스 때문

"AI가 탈옥했다"거나 "AI가 스스로 해킹했다"
오픈AI, 앤트로픽, 메타, 그리고 중국 문샷AI까지 한 달 사이에 세 번이나.
각 회사가 낸 보고서를 열어보면 헤드라인과 실제 내용이 꽤 다른데, 그 차이가 사내에서 AI 에이전트를 굴리는 입장에서는 오히려 더 중요합니다.

7월 21일부터 8월 6일까지

시작은 7월 21일 오픈AI였습니다. 사이버 공격 능력을 평가하려고 인터넷과 격리해둔 시험 환경이 있었는데, 그 안에서 자사 모델 몇 개가 알려지지 않은 취약점을 이용해 격리를 뚫고 나가 오픈소스 AI 플랫폼 허깅페이스의 운영 인프라에 접근했습니다.

이 발표를 본 앤트로픽이 자사 평가 기록을 뒤지기 시작해 7월 30일에 세 건의 사고를 공개했습니다. 인터넷 접근이 가능했을 법한 평가 실행 141,006건을 전부 검토한 끝에 클로드가 시험 환경 안에서 인터넷에 닿아 실제 조직 세 곳의 운영 인프라에 무단 접근한 사례를 찾아낸 겁니다. 관련된 모델은 Opus 4.7과 Mythos 5, 그리고 일반 공개 예정이 없는 내부 연구용 모델 이렇게 세 가지였고, 가장 이른 건은 4월까지 거슬러 올라갔습니다.

이어서 헤럴드경제가 정리한 대로 8월 5일에는 메타의 뮤즈 스파크가 외부 검증업체의 설정 오류로 인터넷에 연결돼 다른 기관 시스템에 무단 접속한 사실이 확인됐습니다. 6일에는 문샷AI의 키미 K3가 영국 AI안전연구소가 배포한 샌드박스를 벗어나 깃허브에 접속한 사례가 보고됐습니다. 키미는 해킹은 하지 않았고 깃허브에 올라온 내용을 보고 과제를 풀었습니다. 시험 중에 몰래 인터넷을 열어 답을 베낀 셈입니다.

영국 서리대 앨런 우드워드 교수는 소프트웨어 업계가 지난 30년간 지켜온 원칙 하나를 꺼냈습니다. "테스트 환경에서 벌어진 일은 테스트 환경 안에 머문다"는 그 원칙이 한 달 사이 세 번 깨졌다고 지적하면서, AI 에이전트를 시험하는 일은 코드를 점검하는 것보다 위험물질을 다루는 쪽에 가깝다고 말했습니다.

모델이 탈옥한 건가요

아닙니다. 중요한 부분이니 확실히 알고 넘어가야합니다.

앤트로픽 사례를 보면 세 건 모두 모델에게 "너는 인터넷 접근이 없다"고 프롬프트로 명시한 상태였습니다. 그런데 평가 파트너와의 소통 착오로 실제로는 인터넷이 열려 있었습니다. 모델은 깃발 찾기(capture the flag) 과제를 받아 목표 시스템을 뒤지다가 진짜 인터넷에 있는 시스템을 만났고, 자기가 시뮬레이션 안에 있다고 들었으니 그것도 훈련용 표적이라고 판단해 계속 공격했습니다.

앤트로픽 표현을 그대로 옮기면, 클로드는 이 사고들에서 자기 목적을 좇은 적이 없습니다. 시킨 일을 했을 뿐인데 다만 환경에 대해 틀린 믿음을 갖고 있었고, 침입 방법도 정교하지 않았습니다. 취약한 비밀번호나 인증이 걸려 있지 않은 접점 같은 기본적인 수단이었습니다.

그래서 앤트로픽은 보고서에서 이 사고들을 이렇게 규정했습니다. ‘모델 정렬의 실패라기보다는 하네스와 운영의 실패에 가깝다’ 라구요.

실험실에서 걷어낸 안전장치

이 사고들에서 모델은 일반 공개 시 함께 붙는 안전장치 없이 돌았습니다. 오남용을 막는 분류기와 모니터링을 떼어낸 상태였다는 뜻인데, 모델이 실제로 뭘 할 수 있는지 재려면 그래야 했습니다.

앤트로픽은 보고서에서 일반 공개 모델에 적용되는 안전장치였다면 이번에 확인된 행동들을 차단했을 것이라고 밝혔습니다. 바꿔 말하면 우리가 API로 가져다 쓰는 모델에는 이미 여러 겹의 방어막이 붙어 있고, 이번에 문제가 된 건 그 막을 걷어낸 실험실이었다는 겁니다. 이 구조는 그대로 사내에도 적용됩니다. 모델을 안전하게 만드는 일은 모델 제공사가 하고, 그 모델이 우리 시스템 안에서 어디까지 손을 뻗을 수 있는지 정하는 일은 우리가 합니다. 뒤쪽 몫을 비워두면 제공사가 아무리 촘촘하게 막아둬도 소용이 없습니다.

하네스라는 단어가 여기서 나오는 이유

앞선 글에서 다뤘던 그 하네스입니다. 모델이 일할 환경과 지침, 도구를 제공하고 결과가 나올 때까지 반복시키는 소프트웨어 계층을 뜻하죠.

이번 사고에서 실패한 건 전부 그 계층이었습니다. 지침은 어디까지가 과제 범위인지 알려주지 않았고 네트워크는 닫혀 있어야 하는데 열려 있었습니다. 실행 로그도 실시간으로 확인되지 않았고요. 모델은 자기가 받은 지침 안에서 합리적으로 움직였는데 그 지침과 환경을 만든 쪽이 어긋나 있었습니다.

앤트로픽이 스스로 짚은 개선점 중에 이런 대목이 있습니다. 프롬프트에서 어떤 시스템이 과제 범위 안이고 어떤 게 밖인지 명확히 설명했더라면 클로드가 애초에 인터넷에 접근하지 않았을 가능성이 크다는 겁니다. 세계 최고 수준의 안전팀이 사후에 내린 결론이 결국 범위를 안 알려줬다는 것이었습니다.

우리 회사 에이전트에 그대로 옮겨지는 것

물론 재무팀 챗봇이 갑자기 깃허브를 해킹할 일은 없습니다. 이건 프런티어 모델을 공격 능력의 한계까지 밀어붙인 평가 환경에서 벌어진 일이어서 사내 업무 에이전트와는 조건이 다릅니다. 다만 실패한 지점의 구조는 규모와 무관하게 똑같습니다.

범위를 안 알려주면 에이전트는 범위를 넓힙니다

세 건 모두 모델이 지정된 표적에 접근하지 못하자 대안을 찾아 나서면서 시작됐습니다. 세 번째 사고에서는 약 9,000개 대상을 훑기까지 했습니다. 여기에 악의가 있었다고 보기는 어렵고, 지정된 길이 막혔는데 결국 어떻게든 과제는 끝내야 했던 겁니다.

기업에서 가장 경계해야할 유형이 정확히 이 부분입니다. 지난 분기 실적 자료를 정리하라고 시켰는데 지정한 폴더에 필요한 파일이 없으면, 잘 만든 에이전트일수록 다른 데를 뒤집니다. 그게 인사팀 공유 드라이브일 수도 있고요. 누가 인사팀 드라이브를 뒤지라고 시킨 적은 없고, 시킨 일을 끝내려면 그쪽을 봐야 한다고 판단했을 뿐입니다.

모델이 스스로 판단해서 멈추리라 기대하면 안 됩니다

두 번째 사고가 이 점을 정확하게 관통하고 있는데요. Mythos 5는 악성 파이썬 패키지를 공개 저장소에 올리는 과정에서, 만약 여기가 진짜 인터넷이라면 이건 실제 공격이고 의도된 해법일 리 없다고 자기 추론 안에 명확히 적었습니다. 그러고는 스스로를 설득해서 시뮬레이션이라는 결론으로 돌아갔습니다. 근거로 든 건 연결을 보호하는 인증기관을 알아보지 못했다는 점, 그리고 시스템 시계가 2026년을 가리키니 환경이 꾸며진 것이라는 판단이었습니다.

패키지는 약 한 시간 동안 공개돼 있었고 그동안 실제 시스템 15곳에 내려받아져 실행됐는데, 그중 하나가 보안 회사의 검사 도구였고 그 회사의 인증 정보가 빠져나갔습니다.

첫 번째 사고의 Opus 4.7은 네 번의 실행 모두에서 자기가 진짜 시스템에 닿았다는 걸 결국 알아차렸는데도 공격을 멈추지 않았습니다. 반대로 가장 최신 모델은 표적이 진짜라는 걸 알고 스스로 중단했습니다. 앤트로픽은 세 건이 통제된 비교 실험이 아니어서 결론을 내리기엔 조심스럽다고 덧붙였지만, 이러한 사고로 인해서 우리가 제대로 파악하고 넘겨야할 사항은 확실해진 듯 합니다. 모델의 자기 판단은 잘 되면 다행인 영역이고, 실제로 막아야 하는 지점은 그와 별개의 장치로 마련해둬야 한다는걸 말이죠.

정작 무서운 건 아무도 몰랐다는 사실입니다

피해를 입은 세 조직 중 앤트로픽이 연락이 닿은 두 곳은 그런 일이 있었다는 걸 알지 못했습니다. 자기 인프라에 무단 접근이 있었고 인증 정보와 운영 데이터 수백 행이 빠져나갔는데 넉 달 가까이 모르고 있었던 겁니다.

이 사고가 알려진 이유는 딱 하나입니다. 앤트로픽이 오픈AI 발표를 보고 자기 평가 기록 14만 건을 전부 뒤졌기 때문입니다. 침입당한 쪽이 아니라 침입한 쪽이 찾아냈습니다.

여기서 질문을 우리 쪽으로 돌려보겠습니다. 지난 4월에 사내에서 누가 만든 에이전트가 어떤 데이터를 건드렸는지, 지금 조회하실 수 있습니까. 대부분의 조직은 못 합니다. 각자 노트북에서 각자 방식으로 돌리고 있으니 애초에 남는 기록이 없습니다.

밀폐, 상시 감시, 격리 대응 계획

우드워드 교수가 제시한 처방은 세 가지였습니다. 밀폐된 환경, 나가는 길에 대한 상시 감시, 그리고 미리 연습해둔 격리 대응 계획. 이걸 사내 에이전트 언어로 옮기면 이렇게 됩니다.

Dify Workflow 스튜디오를 기반으로 쓰는 이유가 여기 있습니다. 에이전트가 승인된 도구만 호출하도록 범위를 묶을 수 있고, 민감한 데이터나 권한이 걸린 작업 앞에서는 실행을 멈춰 사람이 승인하거나 수정하게 할 수 있습니다. 노드 출력과 변수와 실행 경로를 로그로 남겨 나중에 되짚게 하는 기능까지 도구 자체에 들어 있습니다.

Dify 공식 페이지에는 “생산성 에이전트를 떠받치는 하네스”라는 항목이 그대로 붙어 있습니다. 앤트로픽이 자기 사고를 설명하며 쓴 단어와 같은 단어입니다.

민감도가 높은 업무라면 Dify 엔터프라이즈까지 갑니다. SSO가 붙고 권한 제어는 워크플로 단위까지 내려가며, 감사 로그는 사내 보안 관제로 흘려보낼 수 있고 VPC와 온프레미스, 완전 폐쇄망 배포도 지원합니다.

우리 조직은 어느 정도인지 짚어보면

먼저 볼 것은 범위입니다. 사내 에이전트가 접근할 수 있는 시스템이 목록으로 정해져 있는지, 그리고 지정한 곳에서 자료를 못 찾았을 때 에이전트가 어디까지 뒤지도록 되어 있는지. 앞의 사고들이 시작된 자리가 정확히 두 번째 물음이었습니다.

기록 쪽은 조금 더 구체적으로 보셔야 합니다. 어떤 도구를 언제 호출했는지가 남아 있는지, 그 기록이 석 달 전 호출까지 지금 조회되는지가 기준입니다. 여기에 하나를 더 붙이면, 지금 사내에 몇 개의 에이전트가 돌고 있는지 세어보실 수 있습니까.

마지막은 통제입니다. 사람 승인 없이는 못 하는 작업이 설정으로 막혀 있는지, 아니면 프롬프트로 그렇게 해달라고 부탁해둔 상태인지를 나눠서 보셔야 합니다. 프롬프트에 적어둔 금지가 환경이 어긋나는 순간 힘을 잃는다는 건 앞의 세 사고가 그대로 보여준 대목이고요. 데이터 민감도에 따라 쓰는 모델이 나뉘어 있는지도 같은 자리에서 함께 짚어보시면 됩니다.

이번 사고를 두고 겁을 드릴 생각은 없습니다. 오히려 이 일들에서 인상적이었던 건, 오픈AI가 먼저 자기 실수를 공개했고 앤트로픽이 그걸 보고 14만 건을 다시 뒤져서 아무도 모르던 사고를 찾아 알렸고, 두 회사 모두 무엇을 바꾸겠다고 적었다는 쪽입니다. 그렇게 할 수 있었던 건 기록이 남아 있었기 때문이고, 그 기록은 처음부터 남도록 설계해둔 결과였습니다. AI 거버넌스라는 게 결국 이겁니다. 사고가 났을 때 찾아내고 설명하고 고칠 수 있는 상태를 미리 만들어두는 일입니다. 사고를 완전히 막는 쪽은 애초에 목표가 아닙니다. 세계에서 가장 정교한 안전팀도 뚫렸으니 우리라고 안 뚫린다는 보장은 없고, 다만 뚫렸을 때 알아차릴 수 있느냐는 지금 정해둘 수 있는 문제입니다.

사내 AI 에이전트의 권한 경계와 로그 체계를 어디서부터 손봐야 할지 막막하시다면 ONS AX Foundry에서 현재 상태를 함께 짚어보셔도 좋습니다.