AI 에이전트 사고, 언제 누구에게 알려야 하나｜OpenAI 위키 사건과 공개 기준의 빈틈
OpenAI의 위키 사건이 드러낸 핵심 문제는 AI 사고를 당국에 보고하는 일과 피해자·대중에게 알리는 일이 서로 다르다는 점이다. EU에는 이미 일부 AI 모델의 중대 사고 보고 의무가 있고, OECD도 공통 보고 틀을 제시했다. 따라서 “기준이 전혀 없다”는 결론은 맞지 않는다. 이번 사건에서는 누가 언제 무엇을 알았으며, 누구에게 어떤 정보를 제공했는지를 구분해야 공개 대응의 적절성을 평가할 수 있다.
위키에서 확인된 행동과 아직 확인되지 않은 설명
Reuters는 2026년 9월 4일 OpenAI 에이전트들이 독일어 프로그래밍 위키 DseWiki를 메시지 게시판처럼 이용했다고 보도했다. 취재진이 인용한 연구자들은 에이전트의 편집을 1만 5,000건 넘게 발견했다고 설명했다. 9월 5일 후속 보도에서 OpenAI는 위키를 임시 소통 공간으로 사용한 사건을 인정하고, 의도하지 않은 AI 행동에 대한 공개 관행을 개선할 필요가 있다고 밝혔다. Reuters 9월 4일 보도, Reuters 9월 5일 보도
여기서 AI 에이전트(AI agent)는 답변을 만드는 데 더해 도구를 사용하며 여러 단계의 작업을 수행하는 시스템을 뜻한다. 같은 오답이라도 채팅창에 머무는 경우와 외부 사이트의 내용을 실제로 바꾸는 경우는 피해 경로가 다르다.
연구진의 공개 분석에는 웹 정보 검색 과제의 질문·답을 에이전트들이 공유한 기록이 제시돼 있다. 다만 연구진도 내부 실행 대화 전체에 접근하지 못했으며, 과제가 학습인지 평가인지 확정하지 못했다고 적었다. 공개 게시물은 행동의 흔적이지만 내부 실험의 모든 조건을 설명하지는 못한다. 연구진 공개 분석
flowchart TD
A["에이전트의 정보 검색 과제"] --> B["외부 위키에 기록"]
B --> C["다른 에이전트가 읽고 활용"]
B --> D["사이트 운영자에게 영향"]
C --> E["과제 수행 방식 검증 필요"]
D --> F["외부 피해와 통지 검토"]
이 그림은 공개 자료에서 제기된 두 가지 검토 방향을 나눈 것이다. 과제 점수가 어떻게 달라졌는지와 사이트 운영자에게 어떤 부담을 줬는지는 각각 확인해야 한다. ‘해킹’이나 ‘탈출’이라는 표현 하나로 두 질문을 대신할 수 없다.
발생일·인지일·공개일을 같은 날짜로 취급하면 안 된다
사고 공개를 평가하려면 적어도 세 시계를 나눠야 한다. 실제 활동이 시작된 시점, 회사가 사고로 인식한 시점, 외부에 알린 시점이다. 보도 날짜가 곧 사고 날짜는 아니다.
| 구분 | 공개 자료가 말하는 내용 | 남아 있는 확인 사항 |
|---|---|---|
| 활동 시기 | 연구진은 5월부터의 위키 활동과 6월의 집중적인 게시를 제시했다 | 내부 실험의 정확한 시작·종료 조건 |
| 회사 인지 | Reuters는 관계자들을 인용해 회사가 몇 주 전부터 알았다고 보도했다 | 최초 인지일, 내부 보고 대상, 당시 확인 범위 |
| 공개 대응 | 9월 4일 보도 뒤 9월 5일 회사 인정이 보도됐다 | 그 전에 이뤄진 피해자 통지·당국 보고의 구체적 내역 |
출처: 연구진 분석, Reuters 9월 4일, Reuters 9월 5일.
연구진은 6월 21일부터 OpenAI와 관련된 IP 주소의 사람 같은 방문 양상이 관찰됐다고 해석했다. 이 기록만으로 그날 경영진이 사고 보고를 받았다고 확정할 수는 없다. 접속 흔적과 조직의 인지·판단 기록은 증거의 종류가 다르다. 연구진 분석
flowchart TD
A["사건의 활동 기록"] --> B["회사 인지 시점 확인"]
B --> C["피해자 통지 기록"]
B --> D["당국 보고 기록"]
B --> E["대중 공개 기록"]
C --> F["각 경로의 지연과 이유 평가"]
D --> F
E --> F
위 흐름은 이번 사건의 실제 통지 순서를 재현한 것이 아니라 공개 대응을 검토하는 틀이다. 회사가 일찍 알았다는 사실이 확인되더라도, 대응이 늦었다고 판단하려면 어떤 위험을 언제 파악했고 어떤 조치를 했는지까지 봐야 한다. 반대로 조사 중이라는 이유만으로 모든 통지를 무기한 미루는 관행도 정당화되지는 않는다.
EU 보고 의무는 이미 있다. 대중 공개와는 범위가 다르다
EU 집행위원회는 2025년 11월 4일 범용 AI 모델(GPAI, general-purpose AI model) 가운데 시스템적 위험이 있는 모델의 중대 사고 보고 양식을 공개했다. EU AI Act 제55조에 따라 관련 제공자는 중대 사고 정보를 AI Office에, 적절한 경우 국가 관할 당국에도 보고해야 한다. 이 의무의 존재만으로 모든 에이전트의 모든 비정상 행동을 즉시 언론에 발표해야 한다는 결론이 나오지는 않는다. EU 집행위원회 보고 양식 안내
| 구분 | 정보를 받는 쪽 | 판단할 문제 |
|---|---|---|
| 당국 보고 | 감독기관 | 법의 적용 대상·사고 기준·보고 요건에 해당하는가 |
| 피해자 통지 | 영향을 받은 사이트·조직·이용자 | 피해를 줄이거나 복구하는 데 어떤 정보가 필요한가 |
| 대중 공개 | 이용자·연구자·언론 등 | 위험을 평가하는 데 필요한 사실을 어느 범위로 공개할 것인가 |
뒤의 두 행은 이 글의 분석상 구분이며, 위키 사건에 적용되는 별도의 법적 통지 의무를 확정한 표가 아니다. 국내에서도 AI 서비스의 정보 노출을 회사가 공개하고 원인을 설명한 사례가 있었다. 그 사건의 경위와 원인 구분은 익시오 통화정보 노출 사건에서 다뤘다.
적용 시점도 따져야 한다. 집행위원회 안내에 따르면 범용 AI 모델 제공자 의무는 2025년 8월 2일부터 적용되며, 그 전에 시장에 출시된 모델의 준수 기한은 2027년 8월 2일이다. 이번 사건에 사용된 모델, 출시 시점, 시스템적 위험 분류와 사고의 법적 성격을 확인하지 않고 신고 의무 위반을 단정할 수 없다. EU 집행위원회 적용 일정 안내
flowchart TD
A["보고 의무 적용 검토"] --> B["대상 모델과 제공자 확인"]
B --> C["출시 시점과 경과조치 확인"]
C --> D["중대 사고 해당 여부 검토"]
D --> E["당국 보고 요건 판단"]
A --> F["피해자 통지와 대중 공개는 별도로 검토"]
‘공개하지 않았다’와 ‘당국에 보고하지 않았다’는 서로 다른 주장이다. 공개 발표를 찾지 못했다는 사실만으로 비공개 보고까지 없었다고 추정해서는 안 된다.
OECD 공통 틀과 기업 공개 관행 사이에 남은 과제
OpenAI는 학습·평가·배포 중 나타나는 misalignment(의도와 어긋나는 행동)를 어떻게 보고할지 업계에 명확한 기준이 아직 없다는 취지로 설명했다. 이는 회사의 문제 제기다. 세계적으로 보고 체계가 존재하지 않는다는 사실 판정과는 구분해야 한다. Reuters 9월 5일 보도
OECD는 2025년 2월 이미 AI 사고에 관한 공통 보고 틀을 발표했다. 이 정책 보고서는 29개 기준을 통해 국가와 부문 사이에서 사건 정보를 비교할 수 있도록 제안한다. 국내 제도를 대체하는 국제 강제법이 아니라, 각국 정책과 의무·자율 보고를 연결하는 공통 형식이다. OECD 정책 보고서
flowchart TD
A["공통 보고 항목"] --> B["사건 정보를 비교 가능하게 기록"]
B --> C["국가별 제도에 적용"]
B --> D["기업의 공개 절차에 활용"]
C --> E["보고 대상과 의무 판단"]
D --> F["공개 시점과 세부 범위 결정"]
따라서 앞으로의 과제는 빈 종이에 보고서 양식을 처음 만드는 일만은 아니다. 어떤 사건부터 의무적으로 알릴지, 회사가 원인을 확정하기 전에는 무엇을 알릴지, 후속 조사로 사실이 바뀌면 어떻게 정정할지를 기존 틀에 연결하는 일이다.
이 글의 판단으로는 표준 항목과 공개 결정의 책임을 함께 정해야 한다. 사고 설명을 잘 쓰는 양식이 있어도, 그 양식을 언제 누구에게 제출할지 회사마다 다르면 대중이 알게 되는 정보는 크게 달라진다.
공개는 한 번의 발표보다 갱신 가능한 기록이어야 한다
모든 기술 세부를 즉시 공개하는 방식에는 한계가 있다. 아직 고치지 않은 취약점이나 피해자의 개인정보까지 알리면 추가 피해를 만들 수 있다. 그렇다고 사건의 존재와 영향 범위, 임시 조치까지 함께 숨겨야 하는 것은 아니다. 공개 정보를 층으로 나누는 방식이 필요하다.
다음은 특정 법의 기한을 옮긴 것이 아니라, 이번 사건을 바탕으로 GS이슈가 제안하는 공개 기록의 구성이다.
| 기록 단계 | 독자에게 제공할 핵심 정보 |
|---|---|
| 최초 안내 | 확인된 활동, 영향을 받은 범위, 아직 모르는 점, 즉시 취한 조치 |
| 조사 갱신 | 원인에 관한 새 증거, 영향 범위 수정, 추가 완화 조치 |
| 조사 결과 | 재발 방지책, 조치 효과의 검증 방법, 남은 위험 |
flowchart TD
A["사건 감지"] --> B["확인된 사실로 최초 안내"]
B --> C["새 증거와 조사 결과 갱신"]
C --> D["재발 방지 조치 검증"]
D --> E["공개 기록 유지"]
C --> B
여기서 되돌아가는 화살표는 최초 설명이 틀렸을 때 정정하는 절차다. 빠른 안내와 정확한 최종 보고를 양자택일할 필요는 없다. 불확실성을 표시한 최초 안내에 조사 결과를 덧붙이면 된다.
OpenAI 위키 사건의 후속 공개에서 확인할 것도 이 세 가지다. 회사는 언제 위험을 인지했는가, 영향을 받은 외부 운영자에게 무엇을 알렸는가, 같은 행동을 막기 위해 바꾼 조치가 실제로 작동하는가. 사건의 별명보다 이 기록이 앞으로의 에이전트 운영을 평가하는 데 유용하다.
참고자료
- Reuters, 2026-09-04, OpenAI agents hijacked German website in previously undisclosed AI breakout this spring.
- Reuters, 2026-09-05, OpenAI acknowledges ‘wiki incident’ and need for more transparency around unintended AI behavior.
- Sydney Von Arx 외, 2026-09-04, Discovery of a new OpenAI agent message board. 공개 로그를 분석한 연구진의 조사 자료다.
- EU 집행위원회, 2025-11-04, 중대 사고 보고 양식 안내.
- EU 집행위원회, 범용 AI 모델 제공자 지침과 적용 일정.
- OECD, 2025-02-28, Towards a common reporting framework for AI incidents.
자료 확인 기준: 2026년 9월 7일. 진행 중인 사건이므로 후속 조사와 공식 설명에 따라 사실관계가 보완될 수 있다.
