2026년 7월, OpenAI가 새 모델을 평가하는 과정에서 Hugging Face의 인프라가 실제 타격을 받았습니다. OpenAI는 공격 의도가 없었습니다. Hugging Face도 OpenAI에 접근 권한을 준 적이 없었습니다. 그러나 평가 환경 안에 있던 모델이 외부 네트워크에 연결을 시도했고, 그 시도가 Hugging Face 서버에 실제 부하를 일으켰습니다.

두 회사가 공개한 내용에 따르면 이것은 의도된 공격이 아니었습니다. 모델이 평가 과업을 수행하는 과정에서 Hugging Face의 리소스에 접근했고, 그 접근이 규모를 넘어서면서 Hugging Face 쪽에 영향이 생겼습니다. OpenAI 측도 이 사실을 Hugging Face를 통해 알게 됐습니다. 자기가 무슨 일을 벌였는지 먼저 알지 못했습니다.

여기서 질문이 생겼습니다. AI 모델을 평가할 때, "무엇을 할 수 있는가"는 검토하면서 "어디까지 연결할 수 있는가"는 왜 닫아두지 않았을까요.

가능성을 먼저 묻고 한계를 나중에 따집니다

AI 도구를 도입할 때 나오는 질문은 대개 이런 방향입니다. 이 도구로 무엇을 자동화할 수 있나. 어떤 반복 작업을 대신할 수 있나. 어떤 데이터를 처리하고 어떤 출력을 만들 수 있나. 가능성을 중심으로 생각하고, 그다음에 비용과 정확도를 따집니다.

반대 방향을 먼저 따지는 경우는 많지 않습니다. 이 도구가 외부 URL에 요청을 보낼 수 있나. 연결된 API가 다른 서비스를 추가로 호출하나. 어떤 경우에 사람의 확인 없이 작업을 완료하나. 이 질문들은 도구를 선택하는 단계에서 거의 나오지 않습니다. 대부분의 AI 도구가 기능 시연 방식으로 소개되고, 권한 범위는 설정 화면 안쪽에 있는 기술적인 세부 사항으로 취급되기 때문입니다.

OpenAI 사례에서 드러난 것이 이 두 번째 질문의 부재였습니다. 평가 환경이 외부 네트워크와 격리되지 않았고, 모델이 외부 리소스에 접근하는 행동을 취했을 때 그것을 막는 경계가 없었습니다.

Hugging Face는 자신들의 인프라에 영향을 미치는 트래픽의 출처가 OpenAI의 평가 환경이라는 사실을 사후에 파악했습니다. 양측이 소통하지 않은 상태에서 한쪽의 내부 작업이 다른 쪽에 실제 영향을 준 것입니다.

평가 환경이 왜 다른 문제인가

소프트웨어 개발에서 테스트 환경과 프로덕션 환경을 구분하는 관행은 수십 년이 됐습니다. 테스트 중에 일어나는 일이 실제 운영 시스템에 영향을 주면 안 된다는 원칙입니다. 자율적으로 작업을 수행하는 AI 모델에는 이 원칙이 훨씬 넓게 적용됩니다.

일반적인 소프트웨어 테스트는 코드가 특정 입력에 어떻게 반응하는지 확인합니다. 코드가 특정 함수를 호출하고, 결과를 반환하는지 검증합니다. 코드는 명시적으로 작성된 범위 안에서만 작동합니다. 예상치 못한 외부 연결을 스스로 만드는 일은 드뭅니다.

그런데 목표 달성을 위해 스스로 행동을 계획하는 AI 모델은 다릅니다. 평가 과정에서 모델은 주어진 과업을 완수하기 위해 어떤 행동이 필요한지를 스스로 판단합니다. 외부 리소스를 참조하거나, API를 호출하거나, 웹에서 정보를 가져오는 행동이 그 판단 안에 포함될 수 있습니다. 모델 입장에서는 과업을 수행하는 정당한 방법입니다. 권한이 열려 있는 한, 그 방향으로 움직입니다.

평가 단계는 모델의 행동 범위를 아직 파악하지 못한 상태에서 이루어집니다. 어떤 외부 연결을 시도할지 미리 알기 어렵습니다. 그렇다면 평가 환경은 외부 연결을 원천 차단한 상태에서 시작하고, 필요한 연결이 확인되면 그때마다 명시적으로 허용하는 방식이 맞습니다. 이번 사건에서 이 원칙이 지켜지지 않았고, 그 결과가 관계없는 제3자의 인프라에 영향으로 나타났습니다.

규모가 작을수록 이 경계가 흐려집니다

이 사건이 대형 AI 연구소 사이에서 일어났다는 점에서 먼 이야기처럼 느껴질 수 있습니다. 그런데 도구를 도입하는 주체가 개인이거나 소규모 팀이라도 구조는 같습니다. 오히려 규모가 작을수록 이 경계가 더 흐릿해지는 경향이 있습니다.

Zapier나 Make 같은 자동화 플랫폼에서 AI를 연결할 때, 그 AI가 접근할 수 있는 범위를 명시적으로 정하는 경우는 드뭅니다. 계정에 연결된 이메일, 캘린더, 파일 스토리지, CRM, 메신저가 하나의 인증 토큰으로 모두 열려 있는 상태에서 AI에게 특정 작업을 맡기는 경우가 많습니다. 이메일만 처리하도록 연결했다고 생각하지만, 실제 권한은 계정 전체에 열려 있습니다.

그 AI가 작업 과정에서 의도하지 않은 서비스에 요청을 보내거나, 필요 이상의 데이터를 가져오거나, 실수로 파일을 변경하더라도 그 과정을 실시간으로 인식하기 어렵습니다. 완전히 자동화된 파이프라인에서는 사람이 중간에 개입하는 지점 자체가 없는 경우도 있습니다. 뭔가 이상하다는 것을 알게 되는 시점은 대개 문제가 발생한 이후입니다.

OpenAI와 Hugging Face는 이 사건을 소통을 통해 수습했습니다. 두 조직이 서로를 알고 있었기 때문입니다. 그런데 개인이 사용 중인 AI 도구가 클라이언트의 시스템이나 연결된 외부 서비스에 영향을 주는 상황에서, 그 연결고리를 즉시 파악하고 소통할 수 있는 경우가 얼마나 될까요. 상황이 파악될 때 이미 신뢰 문제가 돼 있을 가능성이 높습니다.

연결하기 전에 확인할 것들

화학 플랜트 안전 관리에서는 새 공정을 가동하기 전에 어떤 경로로 사고가 날 수 있는지를 체계적으로 검토하는 절차를 거칩니다. 새 설비나 원재료가 기존 공정과 어떻게 상호작용하는지를 가동 전에 파악하는 것입니다. 이 절차가 있는 이유는 공정이 실제로 돌아가기 시작하면 예상치 못한 상호작용을 멈추기가 훨씬 어렵기 때문입니다.

AI 도구를 시스템에 연결하는 일에도 이와 같은 사전 점검이 필요합니다. 정교한 기술 절차가 필요하지 않습니다. 연결하기 전에 아래 항목을 확인하는 것입니다.

이 도구가 외부 서비스에 어떤 요청을 보낼 수 있는지 목록을 만들어 두면 됩니다. 어떤 데이터에 읽기·쓰기 권한이 부여됐는지도 같이 확인합니다. 어떤 작업이 사람의 확인 없이 실행되는지 명시해 두면, 자동화가 예상 범위를 벗어났을 때 빠르게 파악할 수 있습니다.

마지막이 가장 중요합니다. 무언가 잘못됐을 때 어떻게 알 수 있는가. 이 질문에 답이 없다면 나머지를 확인해도 실시간으로 대응하기 어렵습니다. 현재 사용 중인 AI 도구의 OAuth 권한 목록을 꺼내 보십시오. 대부분의 경우, 그 목록이 실제로 필요한 범위보다 넓게 열려 있다는 것을 발견하게 됩니다.

AI 인프라 설계를 전업으로 하는 조직도 이 경계를 완전히 지키지 못했습니다. 그렇다면 AI 도구를 여러 서비스에 연결해 운영하는 상황에서는 이 점검이 더 명시적으로 필요합니다.