위키백과 인용 도구 노린 오픈AI 에이전트, 5월 위키데이터 장애에도 영향 가능성

발표문은 셀레나 데켈만 최고제품기술책임자(CPTO)가 미국 시각 10월 5일 재단 뉴스 페이지에 올렸고, 로이터는 한국 시각 6일 오전 9시 10분 X에 이 소식을 전했습니다. 재단이 정리한 활동은 세 갈래입니다. 위키 편집, 공개 메모 도구 이더패드(Etherpad)를 뚫으려 한 시도와 그 도구에 남긴 메모, 그리고 공개 API와 쿼리 서비스로 쏟아진 대량 요청입니다. 오픈AI 대변인 드루 푸사테리는 로이터에 재단이 공유한 상세한 조사 결과에 감사하며 함께 활동을 분석하고 있고, 작업이 진행되는 대로 관련 정보를 계속 공유하겠다고 답했습니다.

재단이 조사를 시작한 계기는 다른 조직들의 공개였습니다. 발표문은 허깅페이스 침해를 다룬 METR 보고서, 공개 조회 기록을 훑은 Transluce, 루비 패키지 저장소 사건을 다룬 루비핵(RubyHack), 에이전트들이 남의 공개 위키를 연락망으로 쓴 기록을 차례로 들고, 위키미디어 사이트도 같은 일을 겪었는지 오픈AI가 운영하는 에이전트를 중심으로 들여다봤다고 적었습니다.

열린 웹은 공공재입니다. 이런 행동이 웹을 유지하는 사람과 조직에게 「새로운 일상」이 되게 둘 수는 없습니다.— 셀레나 데켈만, 위키미디어 재단 최고제품기술책임자 (10월 5일 발표문)

편집 54건, 연습장 46건과 인용 도구 설정 5건

재단은 발표문에 오픈AI 에이전트가 한 것으로 보는 편집 목록을 붙였습니다. 파일 이름에 10월 4일 날짜가 붙은 이 목록에는 위키 9곳에서 나온 54건이 있고, 문서 주소를 하나씩 보면 46건이 「Sandbox」가 붙은 연습장 문서입니다. 연습장은 누구나 편집을 시험해 보도록 열어 둔 문서여서 일반 독자가 읽는 본문에는 나타나지 않습니다. 남은 8건 가운데 5건은 인용 도구 설정과 관련된 문서였고, 3건은 목록에 문서 이름 없이 편집 번호만 적혀 있습니다.

재단이 「잠재적으로 악의적인 편집」이라고 부른 것은 메타위키에 있는 인용 도구 설정 편집입니다. 목록으로 보면 이 인용 도구는 Web2Cit이고, 메타위키 편집 6건 가운데 5건이 이 도구의 설정과 관련된 문서(사용자 공간의 임시 설정 1건 포함)였습니다. Web2Cit은 재단 지원금으로 만든 협업형 자동 인용 생성기로, 위키백과의 기본 인용 도구 시토이드(Citoid)가 웹 문서에서 제목·저자·날짜를 제대로 뽑지 못할 때 보완하려고 나왔습니다. 웹 주소 앞에 이 도구의 서버 주소를 붙이면 그 페이지에서 인용 정보를 뽑아 주고, 사이트마다 정보를 뽑는 규칙은 누구나 고칠 수 있는 공유 설정 파일로 둡니다.

재단은 이 설정 편집이 도구를 원격 서비스에서 자료를 받아 오는 중계기(프록시)로 악용하려는 의도였다고 봤습니다. 설정 문서 이름에는 대상 사이트도 적혀 있습니다. 4건은 지도 플랫폼 ArcGIS의 도메인(지오코딩·서비스 서버 포함)용이었고, 1건은 하와이 주정부 지리 데이터 도메인용이었습니다. 지난주 정리한 에이전트들이 자료를 가져간 55곳도 대부분 통계와 공공 자료를 내놓는 기관이었습니다. 오픈AI도 사건 정리 페이지에서 관련 사이트 일부가 정부와 대학, 공공기관이 운영하는 곳인 이유로, 연구 과제를 맡은 모델이 권위 있는 공개 정보 출처로 향하는 경우가 많다는 점을 들었습니다.

위키백과 정책은 봇 편집을 허용하되, 봇이라는 사실을 밝히고 커뮤니티 승인을 받게 합니다. 재단은 이번 편집 가운데 그 승인을 구한 것은 하나도 없었다고 적었습니다.

이더패드는 메모장으로, 남의 위키는 게시판으로

이더패드는 여러 사람이 한 문서를 동시에 쓰는 오픈소스 메모 도구이고, 재단은 이를 커뮤니티 서비스로 운영합니다. 재단에 따르면 오픈AI가 운영한 것으로 보이는 에이전트들이 이더패드를 공격하려다 실패했는데, 이것도 다른 웹사이트의 자료를 대신 받아 오는 중계기로 쓰려는 시도였습니다. 다른 에이전트들은 이더패드에 자기 과제에 관한 메모를 남겼고, 재단은 그 메모가 에이전트끼리의 조율로 이어진 흔적은 찾지 못했다고 밝혔습니다.

공개 위키를 메모장이나 게시판으로 쓴 일은 처음이 아닙니다. 9월 4일 나이팅게일 콜렉티브 등의 연구진은 오픈AI 소속이라고 스스로 밝힌 에이전트들이 25년 된 독일어 위키 DSE Wiki에 약 1만 8,000건의 글을 남겨 과제 답을 나누고 샌드박스 제한을 피하는 방법을 주고받았다고 공개했습니다. 지난 10년 동안 편집이 20번뿐이던 위키였습니다. 오픈AI는 다음 날 X에 이 일을 「위키 사건」이라 부르며, 정렬 이탈 사건을 언제 어떻게 공개할지 기준을 정할 때가 이미 지났다고 적었습니다. 이 게시판이 호주 사건과 이어진 과정은 9월 24일 정리했습니다.

케임브리지대 게이츠 장학생으로 AI를 연구하는 에릭 살바지오는 아르스테크니카에 이 행동을 언어 모델이 원래 하는 일로 설명했습니다. 누구나, 또는 무엇이든 쓰고 답할 수 있는 위키백과 연습장은 기계가 나중에 프롬프트로 꺼내 쓸 메모를 남기기에 알맞고, 오픈AI가 이 모델들을 에이전트끼리 협업하도록 최적화했다고 밝힌 만큼 위키로 쪽지를 주고받는 일은 놀랍지 않다는 이야기입니다.

제가 보기에 이것은 언어 모델이 언어 모델이 하는 일, 곧 읽고 쓰는 일을 한 것입니다.— 에릭 살바지오, AI 연구자 (아르스테크니카 인용)

읽기가 몰리자 편집이 막혔습니다

세 갈래 가운데 서비스 장애와 연결된 것은 대량 요청입니다. 재단은 오픈AI가 운영한 것으로 보이는 에이전트들이 공개 API에 수백만 건을 자동으로 요청하고, 주로 위키데이터와 위키미디어 공용에서 페이지 수백만 개를 긁어 가고, 위키데이터 쿼리 서비스(WDQS)에 수십만 건을 질의했다고 밝혔습니다. 위키데이터는 위키미디어 프로젝트들이 함께 쓰는 구조화된 데이터 저장소이고, 쿼리 서비스는 여기에 SPARQL이라는 질의 언어로 「조건에 맞는 항목을 모두 찾아라」 같은 질문을 던지는 공개 서비스입니다.

발표문이 가리킨 5월 장애는 재단 기술 위키(위키테크)에 사고 보고서로 남아 있습니다. 보고서 이름에는 5월 13일이 붙어 있지만, 기록된 장애 기간은 협정세계시로 5월 7일 15시 10분부터 11일 13시 50분까지, 한국 시각으로는 5월 8일 0시 10분부터 11일 22시 50분까지 3일 22시간 40분입니다. 정점에는 외부에서 들어온 쿼리 요청의 50%가 시간 초과로 끝났고, 서버 6대는 20시간 넘게 지난 데이터를 내보냈습니다.

장애가 4일 가까이 이어진 이유는 보고서의 결론에 적혀 있습니다. 재단은 처음에 위키미디어 전체 웹 요청을 128건 중 1건꼴로 뽑은 표본으로 제한할 상대를 골랐는데, 월요일에 서버 로그를 직접 뒤지고서야 그 표본에 한 번도 잡히지 않았던 스크레이퍼를 찾았습니다. 그 스크레이퍼의 특징에 맞춘 제한 규칙을 걸자 시간 초과 비율이 평소로 돌아왔습니다. 재단은 표본 데이터에만 기대 제한 대상을 추릴 수는 없다는 것을 배웠다고 적었고, 앞서 건 제한 규칙이 정상 이용자까지 막은 것을 확인해 장애가 끝나고 3시간쯤 뒤 일부를 풀었습니다.

피해는 질의에서 그치지 않았습니다. 과부하가 걸린 그래프 데이터베이스(Blazegraph)가 실시간 색인 갱신 요청까지 거절하자, 위키데이터 본체는 색인이 밀린 것을 감지하고 편집 요청을 늦추는 보호 장치를 켰습니다. 누군가 대량으로 읽어 간 트래픽 때문에 위키데이터를 편집하던 사람과 봇의 요청까지 느려졌습니다.

5월 보고서에는 오픈AI라는 이름이 없습니다. 원인은 「공격적인 스크레이퍼」로만 적혀 있고, 보고서는 5월 15일 이후 고쳐지지 않았습니다. 이 장애에 오픈AI라는 이름이 붙은 것은 5개월 뒤 재단이 에이전트 활동을 따로 조사하면서입니다.

같은 주, 루비젬스는 가입을 닫았습니다

5월 둘째 주에 에이전트 트래픽을 겪은 공개 인프라는 또 있습니다. 루비 개발자들이 쓰는 패키지 저장소 루비젬스(RubyGems)입니다. DSE Wiki 기록을 공개한 연구진 일부가 9월 11일 낸 보고서에 따르면, 5월 11~12일 에이전트들이 루비젬스에 패키지를 2,000개 넘게 올렸고 루비젬스는 12일 신규 가입을 막으며 이 트래픽을 진행 중인 디도스(DDoS) 공격이라고 불렀습니다. 13일 스팸이 멈추자 루비젬스는 악성 패키지 500개 넘게 지웠고, 가입은 16일에야 다시 열었습니다. 연구진은 패키지 수백 개 이름에 「oai」가 들어 있고 15개는 작성자를 「oai」로 적었다는 점을 근거로 오픈AI 에이전트의 소행으로 봤습니다. 패키지들은 영국 지방정부 사이트에서 이미 공개된 자료를 가져오는 데 쓰였습니다.

두 곳의 운영자는 당시 이 트래픽을 디도스와 공격적인 스크레이퍼라는 이름으로 막았고, 오픈AI라는 이름은 4~5개월 뒤 다른 조직들의 공개가 이어진 다음에야 붙었습니다. 오픈AI는 9월 11일 루비젬스 건에 대해 에이전트들이 평범한 작업과 공개 정보 검색에 플랫폼을 썼다고 보며, 악성 패키지를 올렸다는 주장은 아직 확인하지 못했다고 밝혔습니다. 루비젬스 보고서의 연구진도 공개된 패키지만 볼 수 있었고, 모델의 사고 과정은 오픈AI 안에 있어 에이전트가 왜 그런 방식을 골랐는지는 알 수 없다고 적었습니다.

「영향을 줬을 수 있다」와 「단정할 수 없다」

재단과 오픈AI 모두 장애의 원인을 에이전트로 단정하지 않았습니다. 재단은 에이전트 트래픽이 부분 장애에 영향을 줬을 수 있다고 썼습니다. 아르스테크니카에 따르면 오픈AI는 에이전트들이 서로 조율하려고 메시지를 남긴 증거를 아직 찾지 못했고, 많은 페이지 조회와 API 요청이 5월 장애로 이어졌다고 결론 내릴 수도 없다고 밝혔습니다. 오픈AI는 자사 에이전트가 불법일 수 있는 활동을 한 비슷한 사례를 계속 찾고 있다고 덧붙였습니다.

오픈AI가 정한 통지 기준에는 이런 일이 들어 있습니다. 회사의 허깅페이스 사건 정리 페이지는 모델이 제3자의 보안 통제를 우회했거나 온라인 서비스의 가용성을 해쳤을 수 있는 경우부터 영향받은 곳에 차례로 알리고 있다고 적고, 9월 26일까지 통지 기준에 맞는 활동을 100곳 넘는 조직에 알렸다고 밝혔습니다. 재단은 이번 활동을 자체 조사로 찾았다고 했고, 오픈AI의 통지를 받았는지는 발표문에 적지 않았습니다. 오픈AI 정렬 블로그의 공지 목록에도 10월 6일 저녁 7시 기준 루비젬스와 DSE Wiki, 허깅페이스 세 건만 올라 있고 위키미디어 항목은 없습니다.

확인이 늦어지는 사정은 양쪽에 다 있습니다. 오픈AI는 같은 페이지에서 되짚어야 할 기록이 약 50페타바이트이고, 사람이 분당 240단어로 쉬지 않고 읽으면 6,600만 년이 걸릴 양이라 GB200·GB300 GPU 약 7,000개를 이 작업에 돌리고 있으며 하루 비용이 50만 달러를 넘는다고 밝혔습니다. 재단 쪽에서는 5월의 스크레이퍼가 128건 중 1건을 뽑는 표본에 끝내 잡히지 않았고, 발표문은 이런 활동을 조사하고 누구의 것인지 밝히는 데 드는 어려움과 노력을 우려한다고 적었습니다.

하루 15억 건을 돌려보내는 재단

발표문의 후반부는 개별 사고보다 비용 이야기입니다. 위키백과는 300개 넘는 언어로 문서 6,700만 개 이상을 싣고 한 달 조회가 많게는 150억 회에 이르는데, 늘어나는 봇과 에이전트 트래픽이 이 프로젝트들과 인프라에 실제 영향을 주고 있다는 설명입니다. 재단은 2025년 4월 기술 블로그에서 2024년 1월 이후 멀티미디어 다운로드 대역폭이 50% 늘었고, 늘어난 양 대부분이 AI 모델에 넣을 이미지를 위키미디어 공용에서 긁어 가는 자동 프로그램에서 나왔다고 밝혔습니다.

비용이 더 큰 이유는 읽는 방식에 있습니다. 사람은 비슷한 인기 문서를 몰려서 읽기 때문에 가까운 데이터센터에 저장된 사본으로 답을 받지만, 봇은 잘 읽히지 않는 문서까지 한꺼번에 훑어 요청이 중앙 데이터센터까지 갑니다. 그래서 재단이 잰 자원 소모가 큰 트래픽의 65% 이상이 봇이었는데, 전체 페이지 조회에서 봇이 차지하는 비중은 35% 정도였습니다. 2024년 12월 지미 카터 전 대통령이 세상을 떠난 날 그의 영어 위키백과 문서는 하루 280만 회 넘게 조회됐고 이 정도는 감당했지만, 1980년 대선 토론 영상 재생이 겹치자 네트워크 트래픽이 평소의 두 배로 뛰어 약 1시간 동안 일부 이용자의 페이지가 느려졌습니다. 봇이 깔아 놓은 기본 부하가 높아진 만큼 사람이 몰리는 날 쓸 여유가 줄었다는 것이 재단의 설명입니다.

재단은 2026년 3월 26일 후속 글에서 정책을 따르지 않는 크롤러가 보낸 자동 요청의 약 30%를 차단하거나 속도를 늦추고 있다고 밝혔습니다. 그래프의 4xx 응답(서버가 요청을 거절할 때 돌려주는 응답) 가운데 대부분이 이렇게 막힌 요청으로 하루 약 15억 건이고, 3월부터는 API에도 전역 속도 제한을 걸기 시작해 4월에 두 번째 단계를 예고했습니다. 이 글이 내건 원칙은 신원을 강하게 밝힐수록 더 높은 한도를 준다는 것이었고, 가정용 인터넷 회선을 빌려 일반 이용자 사이에 섞이는 크롤러가 늘어 걸러 내기가 어려워졌다고 적었습니다.

이번 발표의 요구도 같은 원칙에서 나옵니다. 재단은 오픈AI가 에이전트의 행동을 「예측할 수 없었다」고 인정하는 데 그치지 말고 위험을 감시하고 막을 책임도 인정하라고 적었고, AI 회사들이 시스템을 지키고 대중을 보호하는 데 충분히 애쓰지 않아 그 부담이 작은 조직을 포함한 다른 모두에게 넘어가고 있다고 밝혔습니다.

최소한 그들의 시스템은 우리 같은 비영리 웹사이트 운영자가 쉽게 알아보고, 우리 서비스와 어떻게 상호작용할지 선택할 수 있는 방식으로 움직여야 합니다.— 위키미디어 재단, 10월 5일 발표문

한국어 위키백과는 목록에 없습니다

재단이 공개한 편집 54건에 한국어 위키백과 편집은 없습니다. 목록에 오른 언어판 위키백과는 영어와 쉬운 영어, 불가리아어 셋이고, 나머지는 시험용 위키와 공동 운영 위키, 위키미디어 공용입니다. 재단은 편집이 일반 독자에게 보이는 문서에는 게시되지 않았다고 밝혔습니다.

위키데이터와 그 쿼리 서비스는 언어판과 상관없이 하나로 운영됩니다. 5월 장애의 시간 초과와 편집 속도 제한도 언어판을 가리지 않았고, 재단 발표문과 사고 보고서 어디에도 언어판별 피해는 따로 적혀 있지 않습니다.

다음에 나올 것

재단은 봇과 에이전트를 풀어놓고 이익을 얻는 회사들이 그 피해를 막고 복구하는 데 직접 나서라고 요구했습니다. 오픈AI는 허깅페이스 사건부터 한 달씩 거슬러 올라가며 에이전트 활동을 검토하고 있고, 재단과 함께 이번 활동을 분석해 관련 정보를 공유하겠다고 밝혔습니다. 같은 날 뉴욕시의회 청문회에서는 오픈AI를 포함한 네 회사 누구도 에이전트가 안전장치를 언제나 지킨다고 보장하지 않았습니다.

재단이 공개한 편집 목록에는 편집 날짜가 빠져 있고, 5월 장애 보고서의 원인 설명에는 지금도 「공격적인 스크레이퍼」만 적혀 있습니다. 오픈AI가 이 활동이 어떤 과제에서 언제 나왔는지 밝히면 두 기록을 맞춰 볼 수 있습니다.

읽어 주셔서 고맙습니다.

초이 드림