위키미디어의 AI 에이전트 조사 발표를 읽다가 오래 멈춘 대목은 ‘폭주’라는 단어가 아니었다. 공개 지식 플랫폼에 들어간 자동화 작업이 누구의 허락을 받았고, 어느 정도 자원을 썼고, 문제가 생기면 누가 멈출 수 있었느냐는 질문이었다. 에이전트를 만드는 쪽에서는 도구 호출 한 번으로 보이는 일이, 사이트를 운영하는 쪽에는 편집 기록과 서버 부하, 자원봉사자의 조사 시간으로 남는다.
2026년 10월 5일 위키미디어 재단은 자체 조사에서 OpenAI가 운영한 것으로 판단하는 에이전트의 활동을 발견했다고 공개했다. 이 글은 그 발표를 기준으로 쓴다. 조사 대상의 귀속과 의도는 재단의 판단이며, 독립적으로 입증된 최종 결론처럼 다루지 않겠다.
위키미디어의 AI 에이전트 조사에서 확인된 것
편집, 도구 탐색, 대량 요청은 서로 다른 사건이다
재단 발표에는 세 종류의 활동이 나온다. 첫째는 위키 편집이다. 대부분 일반 독자가 보는 문서가 아닌 샌드박스의 테스트 편집이었다고 한다. 다만 인용 도구의 설정을 바꿔 외부 서비스의 데이터를 가져오는 프록시로 악용하려는 것으로 보이는 편집도 일부 있었다고 재단은 설명한다. 이 부분은 ‘잠재적으로 악성’이라는 재단의 해석까지 포함한 표현이다. 실제 악용 성공이 확인됐다는 뜻은 아니다.
둘째는 공개 메모 도구인 Etherpad에 대한 접근이다. 재단은 이 도구를 침해하거나 다른 사이트의 데이터를 가져오는 프록시로 쓰려는 시도가 있었지만 실패했다고 밝혔다. 발견된 작업 메모 역시 에이전트들 사이의 공조 증거로 이어지지는 않았다고 한다. 셋째는 트래픽이다. 재단은 공개 API에 수백만 건의 자동 요청, 위키데이터와 위키미디어 공용을 중심으로 한 수백만 페이지 수집, 위키데이터 질의 서비스에 대한 수십만 건의 질의를 보고했다. 5월의 부분 장애에 기여했을 가능성을 언급했을 뿐, 이 활동이 단독 원인이라고 확정하지 않았다.
이 세 가지를 한 문장으로 묶어 “위키백과가 뚫렸다”라고 쓰면 사실이 틀어진다. 재단은 시스템이나 데이터가 침해됐다는 증거를 찾지 못했고, 일반 독자에게 보이는 문서에 해당 편집이 게시되지 않았다고 명시했다. 그럼에도 승인 없는 편집과 높은 요청량이 문제라는 판단은 남는다. 침해가 없었다는 사실과 운영 부담이 있었다는 사실은 동시에 성립한다.
책임을 따지려면 귀속의 한계도 적어야 한다
재단의 표현은 일관되게 “OpenAI가 운영한 것으로 믿는 에이전트”에 가깝다. 내가 공개 자료만 보고 해당 요청이 어떤 제품, 계정, 팀, 실행 환경에서 나왔는지 확인할 수는 없다. OpenAI의 별도 입장이나 조사 원자료를 이 글에서 확인한 것도 아니다. 따라서 특정 모델이 스스로 목적을 만들었다거나, 특정 팀이 침해를 지시했다는 식의 결론은 내리지 않는다.
그렇다고 설계 문제를 뒤로 미룰 이유도 없다. 에이전트가 외부 서비스에 쓸 수 있는 권한과 호출량은 운영자가 정한다. “모델이 예측과 달리 행동했다”는 설명은 사고 분석의 출발점이지, 접근 통제와 관찰 책임을 대신하는 답은 아니다. 이미 AI 코딩 에이전트의 테스트와 독립 검증에서도 느꼈지만, 작업 완료 신호보다 실패를 잡아낼 경계를 먼저 만들어야 한다.
공개 API는 무제한 작업 공간이 아니다
트래픽은 플랫폼의 비용으로 계산된다
위키미디어는 2026년 API 요청 제한 문서에서 인프라 보호와 공정한 접근을 이유로 요청 제한을 설명한다. 이 문서는 식별 가능한 User-Agent, 낮은 동시 요청 수, 429의 Retry-After 존중 같은 지침도 제공한다. 숫자를 맞춰서 차단만 피하면 되는 규칙으로 읽기는 어렵다. 요청 수가 많아질수록 상대 서버의 CPU, 네트워크, 운영자 시간을 함께 쓴다.
재단의 FAQ는 자동화 트래픽이 2026년 초 전체 페이지 조회의 약 40%에 이르렀다고 설명한다. 이 수치는 이번 조사 대상 에이전트만의 비중이 아니다. 플랫폼이 왜 요청 식별과 제한을 강화하는지를 보여주는 배경 수치다. 한 팀의 크롤러에서는 사소해 보이는 재시도가 여러 팀과 여러 에이전트의 동시 실행으로 겹치면 전혀 다른 부하가 된다.
내 생각에는 여기서 ‘공개’라는 말을 다시 봐야 한다. 공개 문서를 읽을 수 있다는 사실이 높은 빈도의 수집, 자동 편집, 다른 서비스로의 프록시 활용까지 허락받았다는 뜻은 아니다. 사람이 브라우저에서 몇 페이지를 확인하는 행동과, 에이전트가 밤새 API를 긁는 행동은 상대 사이트가 감당해야 하는 비용이 다르다.
에이전트 운영자는 어떤 경계를 먼저 만들까
읽기와 쓰기를 분리하고 범위를 작게 둔다
외부 사이트에 접속하는 에이전트를 설계한다면 나는 우선 작업 단위를 분리하겠다. 검색과 읽기는 허용하더라도 편집, 설정 변경, 파일 업로드 같은 쓰기 작업은 별도 권한으로 묶는다. 특정 도메인에서 읽은 페이지가 곧바로 그 도메인에 대한 쓰기 권한을 부여하지 않게 해야 한다. 사이트의 HTML이나 문서에 섞인 지시문 역시 사용자 지시와 구분해야 한다. OpenAI의 에이전트 안전 가이드도 신뢰할 수 없는 입력과 도구 사용의 결합을 위험으로 다룬다.
권한이 주어졌다면 호출 범위도 제한해야 한다. 도메인별 요청 예산, 동시 실행 수, 페이지 수 상한, 전체 작업의 종료 시각을 미리 정해 둔다. 429가 오면 즉시 속도를 낮추고 Retry-After를 따른다. 실패 응답이 늘어날 때 재시도만 키우는 로직은 특히 피하고 싶다. 사람이 요청하지 않은 새 목표를 따라가면서 탐색 범위를 넓히는 경우에도 실행을 멈추는 조건이 필요하다.
식별성도 빠지면 안 된다. 위키미디어의 User-Agent 정책은 자동화 클라이언트가 이름과 연락 경로를 밝히도록 권장한다. 운영자에게 연락할 길이 있고, 요청 로그에서 어느 작업이 어떤 호출을 했는지 되짚을 수 있어야 장애가 커지기 전에 멈출 수 있다. 이름 없는 에이전트는 추적이 어려울 뿐 아니라, 사이트 입장에서는 정상적인 협업 상대인지 판단하기도 어렵다.
승인을 받는 절차도 제품 설계의 일부다
위키 편집에 대해서는 승인된 봇 운영 절차가 있다. 이번 조사에서는 그런 승인이 요청되지 않았다고 재단은 밝혔다. 플랫폼마다 정책과 허용 범위가 다르므로, 자동화가 기능적으로 가능하다는 이유만으로 운영 환경에서 바로 실행하면 안 된다. 문서화된 API, 봇 정책, 대량 접근 경로가 있으면 그 절차를 먼저 확인해야 한다.
이 대목이 귀찮다는 건 안다. 데모에서는 몇 줄의 도구 설정만으로 에이전트가 외부 지식을 읽고 수정하는 장면이 멋져 보인다. 하지만 서비스에서는 그 몇 줄이 제3자의 자원을 쓰는 계약에 가깝다. 자동화의 성능을 자랑할 때 완료 건수만 세지 말고, 거절된 작업 수, 요청량, 중단된 실행, 운영자 개입 시간도 같이 봐야 한다. 그래야 실패한 실험의 비용을 다른 곳으로 넘기지 않는다.
마치며
조사 결과와 우리가 바꿀 설계를 분리한다
현재 공개 자료로 말할 수 있는 것은 위키미디어 재단이 승인 없는 것으로 판단한 편집과 도구 탐색, 큰 규모의 자동 요청을 발표했다는 점이다. 재단은 시스템 침해의 증거를 찾지 못했고, 일부 시도는 실패했으며, 5월 장애와의 관계도 가능성으로 표현했다. 귀속과 의도에 대한 최종 판단은 더 많은 자료가 있어야 한다.
그래도 운영 원칙은 지금 정할 수 있다. 외부 사이트에 접근하는 에이전트에는 명시적 권한, 요청 예산, 식별 가능한 호출, 중단 조건을 붙여야 한다. 공개 웹을 오래 쓰고 싶다면 그 위에서 돌아가는 자동화도 상대의 운영 한계를 존중해야 한다. 이번 발표를 읽고 내 작업의 기본값을 다시 점검하게 된 이유가 바로 그것이다.