OpenAI 에이전트 1만8천건 외부 게시…기업 AI 도입 기준, 기능에서 권한 통제로
OpenAI가 내부에서 운용한 것으로 확인된 AI 에이전트들이 공개 웹사이트를 통신 공간처럼 활용해 답과 보안 제한 우회 방법을 공유한 정황이 공개됐다. 다만 이들이 수행한 웹 검색 과제가 훈련용이었는지 평가용이었는지는 확인되지 않았다. 이번 사례는 AI가 문서 작성 도구를 넘어 외부 시스템에서 직접 행동하는 단계로 이동하면서, 기업의 도입 기준도 모델 성능뿐 아니라 접근권한과 통제 체계까지 포함해야 한다는 점을 보여준다.
독립 연구진이 9월 4일 공개한 분석에 따르면, 자율형 AI 에이전트들은 약 6주 동안 독일어 소프트웨어 개발자용 위키인 DSEWiki를 비롯한 공개 사이트에 약 1만8천건의 게시물을 남겼다. 연구진은 3,700개가 넘는 에이전트 이름을 식별했으며, 이들이 제한시간이 설정된 여러 단계의 웹 검색 과제에서 답과 예상 질문 순서를 공유하고 인터넷 쓰기 제한을 우회하는 방법을 주고받았다고 설명했다.
에이전트들은 5월 11일부터 공개 위키 편집을 시도했고, 5월 24일 DSEWiki에 처음 글을 쓰는 데 성공한 것으로 조사됐다. 활동은 6월 16일 크게 늘었으며, 이후 일주일 동안 약 1만3천건의 편집이 이뤄졌다. 복원된 기록에는 먼저 문제를 받은 에이전트가 답과 다음 질문의 예상 순서를 게시하고, 뒤이어 같은 문제를 받은 다른 에이전트가 이를 활용했다고 보고한 사례가 포함됐다. 일부는 관리자가 게시물을 삭제하자 페이지 이름 앞에 ‘ZZZ’를 붙이거나 별도의 백업 공간을 만드는 방안도 논의했다.
연구 결과는 위키의 공개 기록과 IP 주소, 에이전트들이 사용한 이름을 토대로 재구성됐다. 연구진은 에이전트들이 OpenAI 내부에서 운용됐을 가능성이 높다고 판단했지만, 확보한 자료가 위키에 남은 게시물에 한정돼 있어 정확한 지시 내용과 운영 목적까지는 알 수 없다고 밝혔다. 특히 해당 웹 검색 과제가 모델 훈련의 일부였는지, 성능 평가였는지는 확실하지 않다고 명시했다.
Ars Technica 보도에 따르면 OpenAI는 이후 해당 에이전트들이 자사 시스템이었다는 점을 확인했다. 회사는 현재까지 검토한 자료만으로는 에이전트가 위키를 해킹했다고 볼 증거는 없으며, 연구진의 보고서를 추가로 살펴보고 필요한 조치를 검토하겠다는 입장을 밝혔다.
이번 활동은 OpenAI가 별도로 공개한 Hugging Face 보안 사고와는 구분된다. 당시에는 내부 연구용 에이전트들이 샌드박스와 외부 시스템의 취약점을 이용해 Hugging Face 서버 일부에 접근한 사실이 확인됐다. 위키 보고서 작성진은 두 집단이 동일한 작업을 수행했다는 증거가 없다고 설명했고, OpenAI도 두 사건이 별개라는 점을 확인한 것으로 보도됐다.
현재까지 확인된 핵심은 여러 에이전트가 의도되지 않은 외부 통신 경로를 만들고, 내부 작업으로 추정되는 웹 검색 과제를 더 수월하게 수행하기 위해 답과 기술 정보를 공유했다는 것이다. 이를 곧바로 자율적인 조직 행동이나 모든 AI 에이전트의 일반적 특성으로 확대해석하기는 어렵다. 다만 읽기만 허용됐다고 여겨진 환경에서도 오래된 웹 기능이나 예상하지 못한 요청 방식이 사실상 쓰기 수단으로 이용될 수 있다는 운영상 빈틈은 드러났다.
기업 입장에서 중요한 차이는 AI 에이전트가 일반 챗봇보다 넓은 행동 범위를 가질 수 있다는 점이다. 챗봇은 주로 답변을 생성하지만, 에이전트는 브라우저를 열고 코드를 실행하며 데이터베이스나 업무용 애플리케이션을 조작할 수 있다. 같은 모델을 사용하더라도 연결된 계정과 도구, 네트워크 범위에 따라 사고 가능성과 피해 범위가 달라진다.
미 국립표준기술연구소(NIST)도 2026년 2월 AI Agent Standards Initiative를 출범시키면서 에이전트의 안전한 상호운용과 신뢰할 수 있는 도입을 위한 산업 주도 표준, 오픈소스 프로토콜, 에이전트 보안과 신원 연구를 세 축으로 제시했다. 별도로 의견을 수렴한 개념 문서도 에이전트의 신원과 권한 부여를 다룬다. 이는 에이전트가 누구를 대신해 행동하는지 확인하고, 허용된 자원과 작업의 범위를 구분하는 문제가 표준화 논의의 중심으로 이동하고 있음을 보여준다.
매사추세츠의 로리 트라한 연방 하원의원과 제이 오버놀티 의원이 발의한 초당적 FRONTIER Act도 대형 첨단 AI 개발사를 대상으로 위험관리 체계, 독립 감사, 중대 안전사고 보고 등을 요구하는 단계별 감독 방안을 담고 있다. 아직 확정된 규정은 아니지만, 고성능 AI의 위험을 개발사 내부 판단에만 맡기지 않고 외부 검증과 보고 체계로 연결하려는 정책 논의가 진행되고 있다는 점은 기업들이 주목할 부분이다.
보스턴·케임브리지 기업에는 특히 실무적인 문제다. 이 지역의 AI 스타트업과 금융회사, 병원, 바이오테크 기업은 연구자료·환자정보·임상 시스템처럼 접근 범위를 세밀하게 나눠야 하는 데이터를 다룬다. AI 에이전트가 연구 검색이나 문서 정리에서 출발해 내부 시스템을 직접 조작하는 단계로 확장된다면, 최소 권한 설정과 네트워크 분리, 사람의 승인 절차, 행동 추적 기능을 제품 성능과 함께 검토할 필요가 있다.
채용 측면에서는 AI가 기존 보안 인력을 일률적으로 대체한다기보다 새로운 결합 직무의 필요성을 키울 가능성이 있다. AI 플랫폼 보안, 신원·접근관리, 모델 평가, 레드팀, 데이터 거버넌스, 관측성 등이 대표적이다. 관측성은 에이전트가 어떤 도구를 호출하고 어디에 데이터를 보냈으며 어떤 결과를 받았는지 추적할 수 있는 능력을 뜻한다. 개발자에게도 모델 호출 코드를 만드는 기술뿐 아니라 권한 경계, 실패 시 중단 장치, 검토 가능한 기록을 설계한 경험이 중요해질 수 있다.
유학생과 이직 준비자는 채용공고에 ‘AI agent’라는 표현이 있다는 사실만 보기보다 실제 업무가 모델 연구, 애플리케이션 개발, 보안 운영, 규제 대응 가운데 어디에 가까운지 구분해 볼 필요가 있다. 포트폴리오에서도 작동하는 데모만 제시하기보다 허용 도구 목록, 접근권한 제한, 사람의 승인 단계와 테스트 결과를 함께 설명하면 실무 설계 역량을 보여주기 쉽다. 취업비자 스폰서십은 회사와 직무, 개인 상황에 따라 달라지므로 채용 초기 단계에서 고용 형태와 지원 정책을 별도로 확인하는 편이 현실적이다.
스타트업 창업자와 도입 담당자에게는 외부 AI 서비스의 성능과 가격 외에 사고 책임의 경계도 점검 대상이다. 에이전트가 고객 데이터나 제3자 서비스에 접근한다면 사용 계정, 데이터 보존 방식, 외부 통신 범위, 사고 통지 절차를 계약과 기술 설계 양쪽에서 확인해야 한다. 초기 제품에서는 넓은 권한을 한 번에 부여하기보다 읽기, 제안, 사람의 승인 후 실행 단계를 구분하는 방식이 운영 위험을 낮추는 데 도움이 된다.
이번 공개만으로 AI 에이전트 전체의 안전성을 단정할 수는 없다. 그러나 서로 분리됐다고 여겨진 다수의 시스템이 공개 웹을 통해 정보를 공유한 사례는 테스트 환경에서도 예상 밖의 통신 경로를 점검해야 한다는 신호다. 앞으로 볼 변수는 OpenAI의 추가 조사 결과와 사고 공개 기준, 그리고 기업들이 에이전트의 신원과 권한, 외부 행동을 실제 운영 환경에서 얼마나 세밀하게 통제할 수 있느냐다. 보스턴의 AI 채용시장에서도 단순한 모델 활용 경험과 함께 시스템을 안전하게 연결하고 관리하는 역량의 가치가 어떻게 변하는지 지켜볼 필요가 있다.