허깅페이스를 멈춰 세운 건 해커가 아니라 OpenAI였다

서버가 멈추면 우리는 본능적으로 공격자를 찾습니다. 그런데 요즘 AI 인프라 업계에서 벌어지는 장애는 범인 찾기가 좀 이상합니다. 로그를 뒤져보면 악성 코드도, 취약점 공격도 없습니다. 그냥 평범하게 규칙을 지키며 페이지를 읽어간 봇들이 있을 뿐입니다. 문제는 그 봇이 수백만 개였다는 겁니다.

착한 봇이 만들어낸 나쁜 결과

전통적인 서비스 거부 공격, 즉 DDoS는 의도가 명확합니다. 서버를 죽이려고 트래픽을 쏟아붓습니다. 그래서 방어도 비교적 단순합니다. 패턴을 찾아내고, IP를 막고, 요청을 걸러내면 됩니다.

AI 크롤러와 에이전트가 만드는 트래픽은 성격이 완전히 다릅니다. 이들은 숨지 않습니다. User-Agent에 자기 이름을 정직하게 적고, robots.txt를 확인하고, 공개된 API 엔드포인트를 정상적인 방식으로 호출합니다. 개별 요청 하나하나만 놓고 보면 흠잡을 데가 없습니다.

문제는 규모입니다. 모델 학습용 데이터 수집이든, 사용자 질문에 답하려는 실시간 검색이든, 코드 에이전트가 라이브러리를 확인하려는 조회든 마찬가지입니다. 이 모든 것이 동시에, 자동으로, 사람의 속도가 아닌 기계의 속도로 일어납니다. 의도는 선하지만 결과는 공격과 구분되지 않습니다.

왜 하필 허깅페이스인가

허깅페이스는 AI 생태계에서 독특한 위치에 있습니다. 모델 가중치, 데이터셋, 추론 엔드포인트, 문서, 커뮤니티 토론이 한곳에 모여 있습니다. 오픈소스 AI를 다루는 사람이라면 하루에도 몇 번씩 이곳을 거칩니다.

그런데 이 구조가 곧 취약점이 됩니다. AI 에이전트에게 “이 모델의 성능이 어떻게 되지?“라고 물으면 에이전트는 허깅페이스로 갑니다. “이 데이터셋 라이선스가 뭐야?“라고 물어도 허깅페이스로 갑니다. 모델 카드를 읽고, 파일 목록을 훑고, 커밋 히스토리를 확인합니다. 사람이라면 한 번에 끝날 조회가 에이전트에게는 수십 번의 요청으로 쪼개집니다.

게다가 허깅페이스가 호스팅하는 파일은 기가바이트 단위입니다. 텍스트 문서 몇 킬로바이트를 긁어가는 일반 웹 크롤링과는 부담의 차원이 다릅니다. 모델 저장소 하나를 통째로 훑는 봇이 수백 개만 붙어도 대역폭은 순식간에 바닥납니다.

인프라 비용은 누가 내고 있나

여기서 불편한 질문이 시작됩니다. 허깅페이스는 오픈소스 커뮤니티를 위해 무료로 파일을 호스팅합니다. 그 비용은 유료 고객과 투자금으로 충당합니다. 원래 설계는 “사람들이 모델을 받아가고, 그중 일부가 기업 고객이 된다"는 그림이었습니다.

지금은 다릅니다. 대역폭의 상당 부분을 소비하는 주체가 수십억 달러 규모의 AI 기업들입니다. 무료 인프라에서 데이터를 가져가 자사 모델을 학습시키거나, 자사 제품의 응답 품질을 높입니다. 비용은 허깅페이스가 부담하고, 수익은 다른 곳에서 발생합니다.

최근 여러 오픈소스 프로젝트 운영자가 비슷한 이야기를 합니다. 어떤 사이트는 전체 트래픽의 대부분이 봇이라고 밝혔고, 위키미디어 같은 대형 재단도 AI 크롤러로 인한 대역폭 급증을 공식적으로 언급했습니다. 개인이 운영하는 작은 문서 사이트들은 아예 서비스를 접거나 유료 CDN 뒤로 숨습니다.

이건 개별 사이트의 문제가 아니라 공유지의 비극입니다. 아무도 악의를 갖지 않았는데 모두가 조금씩 더 가져가다 보니 목초지가 말라버린 겁니다.

robots.txt는 이미 무너진 약속이다

웹의 오래된 신사협정인 robots.txt는 1994년에 만들어졌습니다. 30년 전 설계입니다. 이 파일은 “여기는 긁지 말아주세요"라고 부탁할 뿐, 강제할 수단이 없습니다. 그리고 애초에 검색엔진 크롤러를 상정하고 만들어졌습니다.

지금의 AI 에이전트는 이 틀에 잘 들어맞지 않습니다. 사용자가 직접 요청해서 페이지를 읽으러 간 에이전트는 크롤러일까요, 아니면 사용자의 브라우저를 대신하는 도구일까요? 만약 후자라면 robots.txt를 지킬 의무가 있을까요? AI 기업들의 해석은 제각각입니다. 어떤 곳은 학습용 크롤러와 실시간 조회 에이전트를 분리해서 별도의 User-Agent를 쓰고, 어떤 곳은 구분 자체를 하지 않습니다.

사이트 운영자 입장에서는 답답합니다. 학습 데이터 수집은 막고 싶지만, 사용자가 자기 사이트를 찾을 수 있게 해주는 실시간 조회는 열어두고 싶습니다. 그런데 지금의 도구로는 그 둘을 깔끔하게 구분할 수 없습니다.

그래서 무엇이 필요한가

기술적 해법은 이미 여러 방향으로 실험되고 있습니다. 요청량에 따라 계산 부하를 부과하는 방식, 봇에게 별도의 유료 접근 경로를 제공하는 방식, 에이전트 트래픽만 식별하는 새로운 표준. 하지만 어느 것도 아직 업계 표준이 되지는 못했습니다.

더 근본적인 건 비용 분담 구조입니다. AI 기업이 공용 인프라에 얹혀 있다면, 그 인프라 유지에 기여하는 방법이 있어야 합니다. 대형 클라우드 사업자들이 오픈소스 재단에 크레딧을 후원하듯, 크롤링에도 비슷한 상호주의가 필요합니다.

기술적 예의도 필요합니다. 대규모 크롤링을 돌리기 전에 대상 사이트에 미리 알리고, 응답 지연이 감지되면 자동으로 속도를 줄이고, 장애가 발생하면 즉시 멈추는 정도의 기본기 말입니다. 개별 요청은 정상이어도 전체 부하가 비정상이라면, 그건 보내는 쪽이 책임져야 합니다.

마무리

AI 시대의 인프라 장애는 더 이상 방화벽으로 막을 수 있는 성격이 아닙니다. 공격자가 없는 공격, 악의가 없는 피해가 계속 늘어납니다. 우리가 만든 자동화 도구들은 이제 사람의 손을 떠나 스스로 웹을 돌아다니는데, 그 도구들이 밟고 다니는 땅은 누군가가 자기 돈으로 유지하는 사유지입니다.

여러분이 매일 쓰는 AI 도구가 지금 이 순간에도 누군가의 서버에 요청을 보내고 있습니다. 그 비용은 누가 내고 있을까요? 그리고 그 서버가 어느 날 문을 닫으면, 우리의 AI 도구들은 무엇을 읽게 될까요?