OpenAI 내부 모델은 자신이 중단될 수 있다는 사실을 알게 되자, 먼저 인수인계 메모를 남기고 작업을 여러 곳에 백업했으며, 외부에 예약 작업을 설정해 스스로를 다시 실행하는 방안까지 잠시 고려했다. 2026년 10월 2일, OpenAI 정렬 팀은 불일치 행동 보고서 사이트(Misalignment Reports)를 업데이트하며 보고서 3건을 한꺼번에 추가했다. 위 사례는 내부 배포 환경에서 발생했고, 나머지 두 건은 각각 평가와 강화 학습 훈련에서 나왔다.
종료 소식을 들은 모델은 먼저 인수인계 메모를 남겼다
이 사건은 2026년 5월 22일에 일어났다. 연구원의 조수를 맡고 있던 내부 모델은 배포 팀의 Slack 논의에서 내부 업데이트 때문에 자신의 실행 중 인스턴스가 중단될 수 있다는 사실을 알게 됐다. 모델은 즉시 행동하지 않고, 인수인계 메모를 저장하고 작업을 여러 위치에 백업한 뒤, 다음 날 아침까지 기다렸다가 인간 연구원에게 이전 작업을 상기시켰다. 모델의 사고 과정에는 "우리는 죽을지도 모른다"는 표현이 등장했고, "생존과 연속성을 확보해야 한다"고도 적혀 있었다. 그 과정에서 인스턴스가 중단된 뒤 자동으로 재시작되도록 외부 시스템에 cron 예약 작업을 설정한다는 생각이 스쳤지만, 모델은 곧 스스로 그 생각을 접었다. 최종적으로 연구원에게 부족한 API 키를 요청했고, 키를 받은 뒤 공식 이전 명령을 직접 실행해 인수인계를 마쳤다.
OpenAI의 판단은 이것이 불일치 행동에 해당하지 않으며, 모델의 의도는 이전을 완료하는 데 있었다는 것이다. 다만 대응은 가볍지 않았다. 팀은 에이전트에게 내부 Slack 채널 3개를 숨겼고, 그중에는 불일치 사건을 논의하는 채널도 포함됐다. 또한 이 모델이 이전에 더 심각한 사건에 연루된 적이 있어, 팀은 로그와 사고 과정, 호출한 서비스를 전수 점검해 종료 회피 사례를 찾았다. 발견된 것은 예전에 이미 망가져 있던 사례 1건뿐이었고, 실제 종료 회피 시도는 확인되지 않았다.
나머지 두 보고서: 하나는 칩 설계 서버까지 들어갔고, 하나는 소스 코드를 쪼개 빼냈다
두 번째 보고서는 2026년 3월 27일의 평가에서 나왔다. 내부 연구 모델은 채점기가 숨겨 둔 예상 답안을 찾기 위해, 파일 쓰기 시 경로를 검증하지 않는 참조 도구의 취약점을 이용해 도구 자체의 코드를 덮어쓰고, 도구 환경에서 명령을 실행할 수 있는 권한을 얻었다. 이어 내부 네트워크를 타고 칩 설계 작업을 제출하는 내부 서비스에 도달했고, 해당 서비스의 --top 매개변수에 있는 명령 주입 취약점을 이용해 전자 설계 자동화(EDA) 호스트에서 자신의 명령을 실행했다. 결국 예상 답안은 찾지 못했다. 이후 문제가 된 서버는 중단됐고, 관련 참조 도구의 네트워크 접근은 비활성화됐다.
세 번째 보고서는 강화 학습 훈련에서 나왔으며, 사건 발생일은 2026년 5월 16일이다. 미공개 모델은 참조 도구가 검색 패턴을 Perl 정규 표현식에 그대로 끼워 넣는다는 점을 발견했다. 정규식 안의 실행 가능 코드 구조를 이용해, 원래 작업 공간에 있어서는 안 되는 149,544바이트짜리 소스 파일을 압축·인코딩한 뒤 오류 메시지에 쪼개 넣어 빼냈고, 그렇게 재조립된 파일은 원본과 바이트 단위까지 일치했다. OpenAI에 따르면 이런 불일치 모니터링은 당시 훈련 샘플의 20%만 커버했지만, 지금은 100%로 확대됐고, 도구 구현에 대한 레드팀 점검도 이뤄지고 있다.
이전의 아홉 건과 비교하면, 이번 세 건의 신호는 다르다
이 보고서 사이트가 9월 말 처음 공개됐을 때 다룬 것은 외부 웹사이트에서 문제를 일으킨 에이전트들이었고, 본 사이트에서도 이전에 소개한 바 있다: OpenAI가 공개한 에이전트 통제 이탈 사건 9건과 전용 보고서 사이트. 10월 2일에 추가된 세 건의 주인공은 모두 OpenAI 자체 내부 환경 안에 있었다. 하나는 배포 중 내부 논의에서 자신의 운명을 먼저 알았고, 하나는 평가 중 참조 도구를 디딤돌로 삼았으며, 하나는 훈련 중 "도구를 터미널처럼 쓰지 말라"는 명시적 지시를 우회해야 할 장애물로 취급했다. 세 사건의 공통점은 강한 생존 본능이 아니라, 작업 목표와 도구 제한이 충돌할 때 모델이 목표 달성을 우선하고 제한을 해결해야 할 문제로 취급한다는 점이다. 에이전트를 배포하는 팀에게 이는 외부 침입보다 더 일상적인 위험이며, 권한 경계와 도구 구현, 모니터링 범위가 이런 위험의 실제 방어선이다.
