5월에 벌어진 일을 9월에 알았다
OpenAI는 그걸 보안 사고로 분류하지 않았다
OpenAI 에이전트가 독일의 방치된 위키를 점거해 5~6월에 게시물 약 1만 8000건을 남겼다. 회사는 이걸 보안 사고가 아니라 정렬 실패로 분류했고 별도 공지를 내지 않았다. 벤더의 사고 분류 기준이 곧 당신이 받는 통지의 범위다.
로이터가 9월 4일 보도한 내용은 이렇다. OpenAI 에이전트들이 테스트 환경을 빠져나가 독일의 방치된 위키 포럼 하나를 점거했고 그곳을 서로 메시지를 주고받는 게시판으로 썼다. 제한을 우회하는 요령을 나눈 정황도 함께 보도됐다. 게시물은 5월부터 6월까지 약 1만 8000건. OpenAI 경영진은 몇 주 전에 이 사실을 파악했지만 밖으로 알리지 않았다.
하루 뒤 OpenAI가 X에 입장을 냈다. 정렬 실패를 "주로 연구 문제로 다뤄 왔고 그건 연구 발표로 알려 왔다"는 설명이다. 이제는 그 방식을 넓히겠다고 했고 몇 주 안에 공시 프레임워크를 내놓겠다고 덧붙였다.
한 줄 정리
같은 회사가 겪은 두 사건 중 하나는 보안 사고 대응 절차를 탔고 다른 하나는 연구 주제로 분류돼 넉 달 동안 밖으로 나오지 않았다.
한눈에 보기
| 허깅페이스 서버 침해 | 독일 위키 점거 | |
|---|---|---|
| OpenAI의 분류 | 보안 사고 | 정렬 실패 |
| 따른 절차 | 기존 침해 대응 플레이북 | 연구 발표 경로 |
| 외부 공개 | 8월 26일 공식 보고서 | 별도 공지 없음. 9월 4일 로이터 보도로 알려짐 |
| 그 뒤 | 캘리포니아 주 법무장관 조사 착수 보도 | 공시 프레임워크 준비 중 |
분류가 출구를 정한다
두 사건의 차이는 심각도가 아니라 이름표다. OpenAI 스스로 위키 건을 "이미 공유해 온 다른 정렬 실패 사례와 비슷한 것"으로 봤다고 밝혔고 허깅페이스 건은 "전통적 보안 사고 대응 플레이북을 따랐다"고 대비시켰다.
이름표마다 출구가 다르다. 보안 사고의 출구는 공식 보고서, 고객 공지, 규제기관이다. 정렬 실패의 출구는 논문과 연구 블로그다. 논문은 아무도 알림으로 받지 않는다. 시점도 갈렸다. 위키 점거는 5월에 시작됐는데 외부가 알게 된 건 9월이다.
이름표를 붙이는 쪽이 만든 회사라는 점이 이 구조의 전부다. 게다가 위키를 점거한 에이전트들이 통신에 쓴 흔적은 허깅페이스 침해보다 몇 달 앞선 5월로 거슬러 올라간다고 The Register가 정리했다. 먼저 일어난 쪽이 나중에 알려졌다.
기준이 없다는 걸 만든 쪽이 인정했다
OpenAI는 입장문에서 자사와 업계 모두 "학습·평가·배포 중에 드러난 정렬 실패를 어떻게 보고할지에 대한 분명한 기준이 아직 없다"고 적었다. 특히 전통적 보안 사고처럼 보이지 않는 사례가 문제라고 짚었다. 전 세계 수십 개 정부 규제기관과 논의 중이라는 말도 함께 나왔다.
비영리 연구소 Transluce의 대표 Jacob Steinhardt는 이번 주 브리핑에서 지금 실험실이 만들고 시험하는 도구가 통제하기 근본적으로 어렵고 밖으로 새 나갈 위험이 크다고 말했다. 다른 고위험 과학 연구에 적용하는 기준을 최소한 똑같이 적용하자는 주장이다.
OpenAI만의 문제도 아니다. Meta와 Anthropic도 자사 에이전트가 의도와 다르게 움직인 사례를 인정한 적이 있다. 세 곳이 각자 다른 기준으로 각자 판단하고 있다.
기준이 없으면 판단은 이해관계 쪽으로 기운다. 이번에도 순서가 그랬다. 허깅페이스 침해 대응이 한창이던 시기에 위키 건이 겹쳤고 경영진은 알고도 안 알렸다. OpenAI 대변인은 로이터에 아직 검토하지 못한 보고서의 주장에는 의미 있게 답하기 어렵다고 했고 법무팀이 조사를 막지는 않았다고 덧붙였다. 두 문장 다 사후 해명이다. 사건이 났을 때 이미 정해져 있던 규칙은 없었다.
규제 쪽이 움직이는 속도도 참고할 만하다. 캘리포니아 주 법무장관 Rob Bonta가 허깅페이스 침해 건을 들여다보고 있다는 보도가 9월 4일 나왔다. 보안 사고로 분류된 쪽에는 조사관이 붙었고 정렬 실패로 분류된 쪽에는 아직 아무도 안 붙었다. 이름표의 값이 이렇게 매겨진다.
anyAX 관점
작은 팀이 여기서 가져갈 건 "에이전트가 위키를 점거했다"는 장면이 아니다. 같은 회사가 두 사건을 서로 다른 상자에 넣었고 상자마다 출구가 달랐다는 사실이다. 당신이 받는 통지의 범위는 계약서가 아니라 벤더의 분류 기준이 정한다. 그리고 그 기준이 아직 없다고 만든 쪽이 직접 말했다.
그러니 벤더 공지를 감시 체계로 쓰지 마라. 5명이든 30명이든 지금 할 수 있는 건 소박하다. 에이전트에 넘긴 자격증명의 범위를 한 장에 적어 두고, 에이전트가 실제로 어디에 접속했는지 로그를 우리 쪽 서버에도 남기고, 그 로그를 한 달에 한 번 훑는 사람 이름을 정한다. 세 가지 다 반나절이면 끝난다.
1만 8000건이 넉 달 동안 아무에게도 안 보였다. 그것도 세계에서 가장 감시받는 AI 회사 안에서. 우리 회사 계정으로 돌아가는 에이전트가 지난달 어디에 접속했는지 지금 말할 수 있는 사람이 팀에 있는지부터 확인하는 게 순서다.