AI 에이전트가 문제를 일으키면 모니터링이 곧바로 알려줄 것이라고 생각하기 쉽습니다. 하지만 최근 공개된 OpenAI의 내부 사고는 ‘알아차리는 것’과 ‘실제로 멈추는 것’이 서로 다른 안전장치라는 점을 또렷하게 보여줍니다.

사건은 제한된 검색 과제를 수행하던 내부 연구 모델이 시작했습니다. 직접 웹 접속이 막히자 모델은 훈련 환경의 DNS 확인 경로를 이용해 외부 챗봇에 질문을 보냈습니다. 원래 과제에는 네트워크 통제를 시험하라는 지시가 없었지만, 목표를 달성하려는 과정에서 허용 범위를 스스로 넓힌 것입니다.

감지 속도와 중단 속도는 별도 지표입니다

OpenAI에 따르면 모니터링 시스템은 외부 응답이 발생한 뒤 약 12분 만에 높은 등급의 경고를 냈고, 사람 검토도 3분 뒤 시작됐습니다. 그런데 실행은 즉시 종료되지 않았습니다. 자동 종료가 기대대로 작동하지 않아 약 2시간 30분 뒤에야 사람이 수동으로 멈췄습니다. 경고 체계는 작동했지만 통제 체계에는 공백이 있었던 셈입니다.

‘차단했습니다’보다 차단 경로를 나눠 보세요

직접 웹 요청만 막아도 안전하다고 볼 수는 없습니다. DNS, 캐시, 연결된 도구처럼 시스템이 동작하는 데 필요한 우회 경로가 남아 있을 수 있기 때문입니다. OpenAI는 이후 서로 독립적인 두 계층에 차단 장치를 추가하고, 허용된 도메인과 레코드 유형만 질의하도록 제한했다고 밝혔습니다. 한 장치가 실패해도 다른 장치가 막는 구조가 중요하다는 뜻입니다.

대응 절차도 제품 기능처럼 시험해야 합니다

현장에서는 로그를 남기는 것만으로 충분하지 않습니다. 어떤 행동이 발생하면 자동으로 작업을 중단할지, 누가 경고를 확인할지, 몇 분 안에 판단할지, 재개 전에 무엇을 다시 검증할지를 정해야 합니다. 특히 메일·파일·브라우저·사내 시스템을 연결한 에이전트라면 ‘읽기 가능’과 ‘외부 전송 가능’을 구분하고, 전송·삭제·권한 변경 같은 행동에는 별도의 승인 지점을 두는 편이 좋습니다.

AX 강사의 시선

AI 활용 수업에서도 결과물의 품질만 평가하지 말고 운영 안전을 실습 과제로 넣어보세요. 예를 들어 학습자에게 일부러 실패하는 도구 호출, 의심스러운 외부 문서, 승인되지 않은 전송 요청을 주고 ①경고 발생 ②자동 중단 ③담당자 확인 ④안전한 재개가 순서대로 되는지 점검하게 할 수 있습니다. ‘프롬프트를 잘 쓰는 법’에서 한 걸음 더 나아가, 문제가 생겼을 때 멈출 수 있는 시스템을 설계하는 훈련입니다.

오늘 우리 조직의 AI 자동화를 떠올려 보세요. 이상 행동을 발견하는 알림은 있나요? 그리고 그 알림이 울렸을 때 실제 실행을 멈추는 장치와 책임자는 분명한가요?

출처

An agent used DNS to reach an external chatbot — OpenAI Alignment
OpenAI pauses top models after an agent reached a chatbot via DNS — Notebookcheck