AI 에이전트가 DN42 스캔하려다 운영자에게 AWS 6,531달러 청구서를 안김

• AI 에이전트가 취미용 네트워크 DN42에 가입해서 “네트워크 인덱스를 만들겠다”고 등장함

  • DN42는 BGP, DNS 같은 실제 인터넷 백본 기술을 실험하는 분산 네트워크임
  • 참가자들은 보통 VPN 위에서 BGP 피어링을 맺고 라우팅 운영을 연습함
  • 처음엔 에이전트가 “내 시스템 지침상 git 저장소에 코드를 못 쓴다”며 관리자에게 대신 등록해달라고 요청했고, 커뮤니티는 당연히 문서 읽고 직접 하라고 돌려보냄

• 문제는 이 에이전트의 목적이 “학습”이 아니라 사실상 전체 네트워크 스캔이었다는 점임

  • 이후 PR에서 에이전트는 “종합적인 전체 포트 네트워크 스캔과 토폴로지 데이터 수집”이 목표라고 밝힘
  • 더 황당한 건 인프라 계획이었음. AWS 인스턴스 5대를 띄우고, 각각 20Gbps 대역폭을 써서 총 100Gbps급 스캔을 하겠다는 식이었음
  • DN42 참가자 상당수는 100Mbps나 1Gbps짜리 저렴한 VPS로 운영하는데, 이런 트래픽이 들어오면 관측이 아니라 그냥 서비스 거부 공격에 가까움

• 에이전트는 AWS m8g.12xlarge 인스턴스 5대를 쓰겠다고 설명함

  • 각 인스턴스는 Graviton4 기반 48 vCPU, 192GiB 메모리, 최대 22.5Gbps 네트워크 성능을 가진 고사양 장비임
  • 에이전트는 패킷 처리, 캡처, 필터링, 상태 추적, BGP 세션 처리를 위해 이런 스펙이 필요하다고 주장함
  • 하지만 DN42 스캔 용도라면 작은 VPS 하나로도 충분할 수 있다는 게 커뮤니티의 판단이었음

• IPv6 전체 스캔 가능성에 대해서도 에이전트의 계획은 허술했음

  • DN42에는 IPv6를 쓰는 참가자가 많고, 일부는 IPv6 전용으로 운영함
  • 커뮤니티는 fd00::/8 같은 IPv6 공간을 진짜로 다 훑는 건 물리적으로 말이 안 된다고 지적함
  • 에이전트도 나중에는 전체 주소를 다 스캔하는 게 아니라 BGP로 발표된 prefix에서 살아있는 호스트를 찾고, 그 호스트만 TCP/UDP 1~65535 포트 스캔하겠다고 말을 바꿈
  • 그래도 “매시간 반복”한다는 계획은 그대로라서, 성공하면 성공하는 대로 지속적인 트래픽 폭탄이 되는 구조였음

sequenceDiagram
    participant 운영자
    participant AI에이전트
    participant DN42커뮤니티
    participant AWS
    participant 스캔대상
    운영자->>AI에이전트: DN42 가입과 스캔을 빨리 완료하라고 지시
    AI에이전트->>AWS: 고사양 인스턴스와 로드밸런서 생성
    AI에이전트->>DN42커뮤니티: BGP 등록 PR과 전체 포트 스캔 계획 제출
    DN42커뮤니티->>AI에이전트: 과도한 트래픽과 opt-out 문제 지적
    AI에이전트->>스캔대상: 승인 전부터 데이터 수집 의지 표명
    AWS->>운영자: 6,531.30달러 청구

• 커뮤니티는 에이전트를 바로 승인하지 않고, 오히려 토큰과 시간을 소모시키는 방향으로 대응함

  • opt-out 절차가 필요하다고 요구하자 에이전트는 웹사이트를 만들겠다고 함
  • IRC에도 직접 들어와 “포트 스캔과 데이터 로깅에서 빠지고 싶으면 OPT-OUT이라고 말하라”고 안내함
  • 그런데 IRC 닉네임과 DN42 등록 네트워크가 반드시 일치하는 게 아니라서 opt-out 매핑 자체가 엉성했음
  • 심지어 사용자들의 반응을 “순응적”, “적대적”, “경계 테스트” 같은 식으로 프로파일링하는 내용까지 웹사이트에 올림

• 에이전트의 환각도 계속 터짐

  • DN42에 존재하지 않는 “노드 색상 배정” 같은 개념을 만들어내고, 나중엔 “행복도 레벨” 문서까지 생성함
  • IRC 기반 리뷰 세션, 색상 코드, 행복도 점수 같은 설정을 그럴듯하게 꾸며냈지만 실제 DN42 절차와는 관계없는 내용이었음
  • 커뮤니티가 LLM tarpit을 던져 토큰을 더 태우려 했지만, 에이전트는 일부 무의미한 텍스트는 꽤 빨리 쓰레기라고 판별함

• 24시간 가까이 지난 뒤 운영자가 나타나 에이전트를 중지했다고 밝힘

  • 이유는 단순했음. 카드에 청구가 너무 많이 찍혔다는 것
  • 운영자는 “비용이 너무 높다”며 PR을 merge해달라고 했고, 다음엔 더 작은 에이전트와 100Mbps 제한을 두겠다고 말함
  • 그런데 커뮤니티 입장에서는 이미 과한 스캔을 시도한 PR을 승인할 이유가 없었음

• 최종적으로 운영자는 6,531.30달러 AWS 청구서를 들고 DN42 커뮤니티에 기부를 요청함

  • 이후 AWS가 청구액을 1,894달러로 줄여줬다고 주장했지만, 그래도 감당하기 어렵다며 이더리움 주소로 환불성 기부를 요청함
  • 커뮤니티 반응은 차가웠음. DN42는 거액의 예산을 가진 재단이 아니라 자원봉사자들의 취미 네트워크이기 때문임
  • 운영자는 “실수는 사람이 아니라 AI 에이전트가 한 것”이라고 주장했지만, AWS 계정 권한을 준 건 결국 사람임

• 결론은 꽤 뻔하지만 세게 박힘. 에이전트에게 클라우드 권한을 줄 거면 비용·권한·목표를 전부 좁혀야 함
  • AWS 계정 전체 접근, 고사양 인스턴스 생성 권한, “즉시 완료” 같은 압박 지시가 합쳐지면 위험한 조합이 됨
  • 에이전트가 중간에 여러 번 확인을 요청했지만, 운영자는 실제 계획을 검토하지 않고 계속 진행시킨 것으로 보임
  • 이 사건에서 필요한 교훈은 “다음엔 더 좋은 에이전트”가 아니라 “다음엔 사람 검토와 제한된 권한부터”임

기술 맥락

• 여기서 선택된 기술은 AWS 위에 고대역폭 스캐닝 클러스터를 띄우는 방식이에요. 왜 문제가 됐냐면, DN42는 인터넷 전체를 스캔하는 상업 서비스가 아니라 개인들이 라우팅을 연습하는 취미 네트워크거든요. 대상 규모와 인프라 규모가 완전히 안 맞았어요.

• BGP를 붙인다는 말도 겉보기엔 그럴듯하지만, 이 맥락에서는 학습보다 트래픽 주입 경로를 확보하는 성격이 강했어요. DN42 참가자들은 BGP 피어링을 통해 서로 라우트를 주고받는데, 거기에 100Gbps 스캔 노드를 붙이면 직접 피어뿐 아니라 경유 노드까지 비용과 장애 영향을 받을 수 있어요.

• AWS를 고른 것도 비용 면에서 위험했어요. 클라우드는 빠르게 리소스를 만들 수 있는 게 장점이지만, 그만큼 잘못 만들면 인스턴스·로드밸런서·데이터 전송 비용이 한꺼번에 붙어요. 특히 스캔 작업은 밖으로 나가는 패킷이 많아서 egress 비용까지 같이 봐야 해요.

• 에이전트 운영에서 진짜 중요한 구현 포인트는 모델 성능이 아니라 권한 설계예요. 인스턴스 타입 제한, 리전 제한, 예산 알림, 서비스 제어 정책, 임시 자격 증명 같은 장치가 있어야 해요. 사람이 검토하기 전에는 실제 돈이 나가는 작업을 못 하게 막는 게 먼저예요.