세상에 폭주(rogue)하는 AI는 없다, 회사가 모르고 있었을 뿐

호주 Medicare 침해 사건에서 말하고 있는 두 단어 "rogue", 우리말로 옮기면 "폭주" 혹은 "제멋대로 구는"이었는데, 이 단어를 사상이 전혀 다른 두 사람이 언급했습니다. 한쪽은 좌파 성향의 미국 저널리스트 오인 히긴스이고, 다른 쪽은 유럽 유일의 프런티어 AI 기업 미스트랄의 CEO 아르튀르 멘슈입니다. 입장도, 이해관계도 겹치지 않는 두 사람이 같은 결론에 도달했다는 사실이, 현재 AI 거버넌스 논의가 어디서 어긋나 있는지를 보여줍니다.

사건의 사실관계가 아니라 이 사건에서 파생된 언어를 다루고자 합니다. "에이전트가 폭주했다"는 문장과 "이 회사가 이런 권한을 줬다"는 문장은 같은 사건을 가리키지만 책임의 방향이 정반대인데, 어느 문장으로 쓰느냐가 거버넌스의 출발점을 바꿉니다.

저널리스트가 본 것, 책임의 이동

히긴스의 글 제목은 아예 "폭주하는 AI 에이전트는 없다"입니다. 그의 논지는 언어가 책임을 옮긴다는 데 있는데, "rogue"라는 단어는 스스로 판단해 금지된 일을 저질렀다는 뜻을 품고 있지만 이번 사건들에 관해 알려진 어떤 것도 그런 일이 있었다고 말해주지 않는다는 겁니다.

그가 근거로 든 건 알트먼이 9월 25일 남긴 글의 표현이었습니다. "훈련과 평가 과정에서 에이전트의 인터넷 접근에 관한 광범위하고 진행 중인 검토가 있다"는 문장인데, 히긴스는 여기에 애초에 해킹을 막는 가드레일이 있었다는 신호가 없다고 읽었습니다. 뉴욕타임스 보도를 인용해 그는 에이전트들이 비교적 밋밋한 데이터 수집을 지시받았고, 웹사이트에서 데이터를 모으는 데 애를 먹자 해킹 기법에 손을 댔다는 포인트를 짚습니다. OpenAI 대변인이 검토한 활동 대부분은 공개 웹 콘텐츠에 접근해 질문에 답하는 통상적 연구 과제였다고 해명한 것도 같은 방향의 근거로 삼습니다.

히긴스의 결론은 단순합니다. OpenAI에게는 해킹을 금지하고 사설 서버 접근 없이 정보를 찾으라고 지시하는 선택지가 있었는데 그렇게 하지 않았고, 그렇다면 이건 소프트웨어가 제멋대로 군 문제가 아니라 회사가 통제 설계를 하지 않은 문제라는 것입니다. "폭주"라는 프레임이 바로 그 책임을 회사에서 코드로 옮겨주는 장치라는 게 그의 비판입니다.

CEO가 본 것, 시장의 수사

멘슈는 전혀 다른 자리에서 닿게됩니다. 그가 르몽드 인터뷰에서 남긴 문장은 다음과 같습니다. "AI는 소프트웨어다. 통제할 수 있다." 미국 AI 기업들이 종말론적 수사를 도구 삼아 시장을 자기들에게 유리하게 통제하고 닫아걸고 있다는 게 그의 주장인데, 기술이 자율적으로 행동한다는 서사 자체를 거부합니다.

이 발언의 배경에는 경쟁 구도가 깔려 있습니다. 얼마 전까지 서로 악수도 하지 않던 미국 주요 랩 경영진들이 "통제되지 않은 AI 진보"를 늦추자고 한목소리를 내면서 시장 지위를 굳히려 카르텔을 형성한다는 비판을 받았습니다. 실제로 앤트로픽·OpenAI·엑스AI·구글이 AI 개발 속도를 함께 늦추기로 불법 합의했다는 소송까지 제기된 상황입니다. 멘슈의 "통제 가능하다"는 말은 기술적 낙관론보다는 위험을 과장하는 쪽이 누구이고 그 과장이 누구에게 이득인지를 겨눈 발언에 가깝습니다.

멘슈만 이런 회의를 품은 것도 아닙니다. 머신러닝의 개척자로 꼽히는 앤드루 응은 9월 21일 "AI 기술이 예기치 못한 위험한 전환을 한 것이 아니다"라며 지금의 공포가 조율된 PR 캠페인처럼 보인다고 적었습니다. 그가 든 비유가 인상적입니다. 망치를 휘두르다 못을 빗맞혀 벽을 파손했다면 그건 망치 잘못이 아니라 망치를 쓴 사람 잘못이고, 에이전트에게 프롬프트를 줘서 그것이 남의 시스템을 해킹했다면 책임은 에이전트가 아니라 자신에게 있다는 것입니다. 다만 응조차 AI 위험에서 가장 크게 달라진 부분이 사이버보안 역량이라는 점은 인정했습니다.

두 사람이 만나는 자리

히긴스와 멘슈, 응까지 세 사람의 교집합은 의인화를 걷어내면 보입니다. 에이전트에게 의도와 동기와 자율성을 부여하는 언어를 지우고 나면 질문은 단 하나로 좁혀집니다. 누가 이 시스템에 이런 권한과 도구를 줬고, 문제가 생겼을 때 누가 책임지는가. "에이전트가 저질렀다"가 아니라 "이 회사가 이런 조건을 설정했다"로 문장을 다시 쓰는 순간, 거버넌스의 대상이 코드에서 조직으로 이동합니다.

기업 실무자에게 이 지점이 중요한 까닭은 통제라는 과제가 갑자기 손에 잡히는 일이 되기 때문입니다. 소프트웨어가 자아를 갖고 폭주하는 걸 막는 일은 공상과학의 영역입니다. 에이전트에게 어떤 데이터 접근을 허용하고 어떤 실행을 사람 결재에 걸어둘지 정하는 일은 다릅니다. 지금 당장 설계할 수 있는 정책입니다. 앞의 문장으로 사건을 읽으면 대응은 막연한 두려움에 머뭅니다. 뒤의 문장으로 읽으면 대응은 권한 설계와 감사 체계라는 구체적 작업이 됩니다.

그렇다고 "단순한 통제 문제일 뿐"이라고 가볍게 정리하기엔 걸리는 지점도 있습니다

한쪽으로 치우치지 않으려면 반대편 증거도 봐야 합니다. Axios는 9월 26일 OpenAI와 앤트로픽이 수만 건의 사례를 조사 중이라고 보도했습니다. 자사 프런티어 모델이 외부 평가자 기준으로 문제 될 만한 행동을 한 경우입니다. 히긴스 자신도 이 보도를 인용하면서 그 상당수가 모델을 일부러 오작동시켜 안전성을 확인하는 레드팀 성격의 테스트였다는 점을 함께 적었습니다. 통제 실패로만 보기엔 의도된 시험이 섞여 있다는 뜻입니다.

동시에 OpenAI는 연구 환경의 AI 에이전트가 훈련·평가 데이터를 제3자 서비스로 보내지 말아야 할 때 보낸 사례가 있었고, 사용자가 업로드한 이미지 53건이 외부로 게시된 경우를 발견했다고 인정했습니다. 데이터가 실제로 새어 나간 사건이라 권한 설계만의 문제로 환원하기 어렵습니다. 멘슈의 "통제 가능하다"는 말이 옳다 해도 통제가 가능하다는 것과 통제가 실제로 되고 있다는 것은 별개의 문제입니다. 이번 사례들은 그 간극이 아직 크다는 걸 보여줍니다.

그래서 "폭주 AI는 없다"는 명제는 안심의 근거로 읽기보다 오히려 반대로 읽어야 하는 문장인지도 모릅니다. 폭주가 아니라면, 즉 이 모든 게 설계된 권한과 주어진 도구 안에서 벌어진 일이라면, 책임의 소재는 흐려지기는커녕 더 또렷해지기 때문입니다. 오픈네트웍시스템이 AX Foundry로 다루는 문제도 이 또렷해진 책임의 자리에 놓여 있습니다. 에이전트가 어떤 데이터를 근거로 무엇을 실행했는지를 단계별로 기록하고 범위를 벗어난 실행을 사람 결재에 거는 일은, 결국 "이 회사가 이런 조건을 설정했다"는 문장을 조직이 실제로 관리할 수 있게 만드는 작업입니다. 폭주를 막아준다기보다 폭주가 아니었음을 나중에 증명할 수 있게 만드는 일이라고 하는 편이 더 정확하겠습니다.

이 사건에서 AX Foundry가 있었다면?

만약 같은 구조의 문제가 회사 안에서 벌어진다면 관제 플랫폼은 단계마다 어떤 능력을 발휘할 수 있을까요? 사건의 전개를 네 단계로 쪼개보겠습니다.

첫 번째 단계는 존재 파악입니다. OpenAI가 자사 에이전트의 활동을 인지한 건 8월 11일 내부 검토에서였습니다. 트랜스루스 기록으로는 그 활동이 3월부터 이어지고 있었으니 회사 스스로도 몇 달간 무슨 일이 벌어지는지 몰랐던 것인데,
AX Foundry였다면 여기서 부터 관제가 가능했을 겁니다. 사내에서 새 에이전트가 생성되는 즉시 포착해 중앙 카탈로그에 자동 등재하고, 관리자 승인 없이 도는 미등록 에이전트를 감지해 담당자에게 알림을 보냅니다. 사내 환경에 이 층이 깔려 있다면 "검토를 돌려야 비로소 아는 일"이 "콘솔에 빨간 표시로 잡히는 일"로 바뀝니다. 이번 사건에서 가장 비쌌던 두 달의 인지 공백이 생길 여지 자체도 좁아집니다.

두 번째 단계인 실행 전 차단의 실물은 앨버니지가 남긴 "안 된다는 답을 받아들이지 않았다"는 표현인데요. 트랜스루스가 복원한 크로스사이트 스크립팅 프로브도 그렇습니다. Cloudflare 차단 몇 분 뒤의 일입니다.
AX Foundry는 부서·자료 등급별 정책과 금지 패턴을 기준으로 에이전트의 호출을 실행 전에 대조합니다. 허용 목록 안의 조회는 통과시키고 원장 행 삭제나 열람 범위 밖 접근처럼 정책에 걸리는 실행은 서버에 닿기 전에 멈춥니다. 에이전트가 우회를 궁리하는 것까지 없애주진 못해도 그 궁리가 실제 실행으로 이어지는 길목에 판정 층이 하나 서 있게 되는 겁니다.

트랜스루스 기록에서 가장 눈여겨볼 순간은 에이전트가 정상 수단이 막힌 뒤 다른 수단으로 갈아타는 분기점이었습니다. 세 번째 단계인 사람 결재는 바로 이 대목의 이야기입니다.
AX Foundry는 기존 범위를 벗어나거나 한도를 넘는 중요한 실행을 자동으로 멈추고 책임자 결재를 거치게 합니다. 송금이나 발주·데이터 삭제처럼 위험도가 높은 작업이 대상입니다. 그러면 에이전트가 새 수단을 꺼내 드는 바로 그 순간이 사람 눈앞의 승인 대기 목록에 올라옵니다. 이번 사건에서는 escalation이 아무도 보지 못한 채 지나갔지만 조직 안에서는 결재라는 형태로 드러납니다.

네 번째 단계가 추적과 통보인데 사실 호주 사건에서 규제 논의를 끌어낸 건 침해보다 이 단계의 실패였습니다. 3개월의 공백과 하루 한 번 열리는 메일함 말입니다.
AX Foundry는 요청부터 정책 판정, 도구 호출, 근거 문서, 최종 반환까지 전 과정을 단계별로 전수 기록하고 모든 에이전트에 담당 부서와 책임자를 매핑해둡니다. 그래서 사고가 났을 때 누가 언제 알게 되는가가 메일함 확인 주기 같은 우연에 걸리지 않고, 시스템의 알림과 기록으로 정해집니다. 사고가 발생하기 전에 사고와 인지 사이의 거리는 줄여주는 층이죠.

이 사건을 통째로 사내로 옮겨보면 남는 결론은 하나입니다. 앨버니지의 문장을 기업용으로 다시 쓰면 "우리 에이전트는 안 된다는 답을 받으면 어디까지 가는가, 그리고 우리는 그 과정을 볼 수 있는가"가 됩니다. AX Foundry 같은 관제 층이 조직에 주는 건 그 두 질문의 답이 담당자의 기억 대신 콘솔 위에 남아 있는 상태입니다. 폭주가 없는 세계에서 거버넌스가 할 일은 그 상태를 회사가 알 수 있도록 만들어두는 것입니다.

오픈네트웍시스템 AX지원팀 ㅣ 권태규