DAILY INSIGHT

MS발 먹통 사태 2년, 항공업계 IT·보안 투자 변화와 공급망 리스크

SecurityDesk
2026.07.10 03:00 조회 13

MS발 먹통 사태 2년, 항공업계 IT·보안 투자는 어디로 향했나

서론

2024년 7월 19일 전 세계 항공사, 공항, 금융기관, 병원, 방송사가 동시에 멈춰 섰다. 일반 이용자에게는 “MS발 먹통”으로 기억된 사건이지만, 기술적으로는 Microsoft 제품 취약점이나 사이버공격이 아니었다. 공식 원인에 따르면 CrowdStrike Falcon Windows Sensor의 Channel File 291 콘텐츠 구성 업데이트 결함이 Windows 시스템 장애로 이어진 사건이었다.

이 차이는 중요하다. 사건을 Microsoft 장애나 해킹 사고로만 이해하면 대응책은 엉뚱해진다. 실제 교훈은 “신뢰한 보안 공급업체의 정상 업데이트도 항공 운영을 멈출 수 있다”는 점이다. 보안 도구는 보호 장치인 동시에, 커널 수준 권한과 자동 배포 체계를 가진 고위험 운영 구성요소가 됐다.

2년이 지난 지금 항공업계의 IT·보안 투자는 단순한 예산 증액보다 운영 복원력 강화에 가깝다. 항공사는 더 많은 시스템을 연결하고, 공항은 더 많은 이해관계자를 같은 디지털 운영망 안에 묶고, AI와 자동화는 운항 차질 대응까지 들어오고 있다. 그만큼 보안의 중심도 침해 탐지에서 데이터 무결성, 공급망 배포 통제, 장애 격리, 수동 복구 가능성으로 넓어졌다.

본론

“MS발 장애”가 아니라 보안 공급망 장애였다

CrowdStrike의 공식 RCA와 예비 사고 보고서에 따르면 장애는 Windows Sensor용 Rapid Response Content가 배포되는 과정에서 발생했다. Channel File 291 관련 콘텐츠가 센서의 Content Interpreter에 로드될 때 out-of-bounds memory read가 발생했고, 예외 처리가 정상적으로 이뤄지지 않으면서 Windows BSOD로 이어졌다.

Microsoft는 당시 이 업데이트가 약 850만 대의 Windows 장치에 영향을 준 것으로 추정했다. 숫자만 보면 전체 Windows 생태계의 일부였지만, 문제는 장치의 위치였다. 항공사와 공항의 체크인, 탑승, 수하물, 승무원 운영, 고객 응대, 현장 복구 단말이 동시에 영향을 받으면 단말 장애는 곧 운항 장애가 된다.

Delta Air Lines는 SEC 8-K 공시에서 약 7,000편 취소, 최소 5억 달러 손해, 3억8,000만 달러 직접 매출 영향과 1억7,000만 달러 비연료 비용을 언급했다. 이 사례는 항공 IT 장애의 피해가 PC 복구 시간만으로 계산되지 않는다는 점을 보여준다. 승무원 재배치, 항공기 회전, 승객 재예약, 고객 보상, 허브 공항 복구 순서가 모두 얽히면서 피해가 확대된다.

따라서 이번 사건의 위협 수준은 High로 볼 수 있다. 다만 그 이유는 데이터 탈취나 악성 침해가 아니라 가용성, 무결성, 공급망 통제 실패에 있다. 보안팀은 이 사건을 “공격은 아니었으니 예외”로 분류하기보다 “공격이 없어도 사이버 복원력 실패가 항공 안전과 운영 연속성에 영향을 줄 수 있다”는 사례로 다뤄야 한다.

항공 IT 투자의 초점은 데이터와 복원력으로 이동했다

SITA의 2025 Air Transport IT Insights는 항공 운송 산업의 기술 투자가 기록적인 수준으로 커졌다고 설명한다. 항공사는 2025년 IT에 360억 달러, 공항은 148억 달러를 투자했으며, 전체 항공 운송 산업의 기술 투자 규모는 508억 달러로 제시됐다. 항공사 72%는 2025년 IT 지출을 늘렸고, 67%는 2026년에도 증가를 예상했다.

하지만 이 투자를 “디지털 전환 확대”로만 읽으면 부족하다. 2024년 장애 이후 항공사가 실제로 확인한 문제는 새 기능이 아니라 운영 연속성이었다. 장애가 났을 때 어느 공항부터 복구할지, 어느 승무원 조합이 합법적인지, 어떤 승객을 먼저 재예약할지, 어떤 데이터가 최신인지 판단하지 못하면 복구 속도는 급격히 떨어진다.

SITA는 항공사 46%가 운항, 승무원, 항공기, 승객 시스템 사이 정보를 일관되고 실시간으로 접근 가능하게 만들기 위해 flight operations systems를 업그레이드하고 있다고 설명한다. 또 항공사 83%는 데이터 기반 의사결정을 우선순위로 둔다. 이는 장애 대응에서도 핵심이다. 복구팀이 보는 데이터가 서로 다르면, 자동화는 속도를 높이는 대신 잘못된 결정을 더 빨리 확산시킬 수 있다.

AI 투자도 같은 맥락에서 봐야 한다. SITA에 따르면 항공사 63%는 disruption, aircraft assignment, crew availability 관리에 AI를 사용한다. 그러나 49%는 데이터 통합과 일관성을 AI 확장의 주요 장벽으로 봤다. 항공 보안 관점에서 중요한 통제 대상은 AI 모델 자체만이 아니다. AI가 참조하는 운항 데이터의 출처, 최신성, 동기화 상태, 충돌 여부가 새로운 보안 통제 지점이 됐다.

공항의 우선순위도 바뀌었다. SITA는 공항 68%가 사이버보안을 2025년 최상위 IT focus area로 꼽았고, 71%가 인프라 업그레이드의 주요 동인으로 사이버보안을 들었다고 정리했다. 공항은 항공사보다 더 복잡하다. 항공사, 지상조업사, 보안검색, 수하물, 출입국, 상업시설, 통신사업자, 클라우드 서비스가 같은 물리 공간과 네트워크 경계 안에서 움직인다. 한 공급업체의 장애가 여러 조직의 운영 차질로 이어질 수 있는 구조다.

공급망 리스크는 네 계층으로 봐야 한다

첫 번째는 보안 에이전트 공급망이다. EDR, 안티바이러스, DLP, VPN, 브라우저 보안, MDM은 대체로 높은 권한과 자동 업데이트를 전제로 한다. 이 계층의 핵심 리스크는 침해 여부만이 아니다. 배포 통제 실패, 롤백 불능, 장애 격리 실패가 곧 대규모 업무 중단으로 이어질 수 있다. 항공사는 보안 공급업체의 사전 테스트만 믿지 말고 자체 ring 배포, canary 그룹, 허브·공항 중요도별 지연 배포, 긴급 kill switch와 rollback 절차를 가져야 한다.

두 번째는 운영 데이터 공급망이다. 운항 데이터, 승무원 스케줄, aircraft rotation, gate allocation, passenger service, baggage, weather, NOTAM, airspace 데이터가 서로 연결된다. 한 데이터 소스가 지연되거나 다른 버전으로 전파되면 장애 대응 의사결정이 왜곡된다. 이 문제는 공격이 없어도 발생할 수 있으며, 공격자가 개입하면 데이터 무결성 침해와 운영 혼란이 결합될 수 있다.

세 번째는 파트너와 공항 인터페이스 공급망이다. 항공사는 공항, 지상조업사, 급유·케이터링, 정비, 결제, 예약·발권, 정부·국경관리, 클라우드 사업자와 실시간으로 연결된다. 공급업체 원격지원 계정이나 관리 도구가 침해되면 단순 장애와 달리 데이터 유출, lateral movement, 랜섬웨어로 이어질 수 있다. 벤더 계정에는 JIT 접근, MFA, PAM, 세션 녹화, 명령 감사, 네트워크 세그먼트 제한이 필요하다.

네 번째는 규제와 표준 공급망이다. FAA는 2025년 Civil Aviation Cybersecurity Aviation Rulemaking Committee를 구성하며 공항, 항공기 지상지원 정보시스템, 항공교통 관제 미션 시스템, 항공 제품·부품의 사이버보안 기준 검토를 과제로 뒀다. EASA Part-IS는 정보보안 리스크를 항공 안전 영향과 연결해 관리하도록 요구하는 방향이다. IATA도 항공 사이버보안 전략에서 trust communities, 표준·권고·가이드, 정보교환과 공급망 감독을 강조한다.

즉 항공 사이버보안은 일반 IT 컴플라이언스가 아니라 항공 안전, 운항 복원력, 공급망 감독 문제로 재정의되고 있다.

우선 점검해야 할 장애·공격 시나리오

가장 먼저 봐야 할 시나리오는 보안 업데이트 장애 재발이다. EDR, AV, MDM, 브라우저 보안 업데이트가 공항 현장 Windows 단말에 일괄 배포되고, 부팅 장애나 네트워크 스택 장애를 유발하는 경우다. 체크인, 탑승 게이트, 수하물, crew desk 단말이 동시에 영향을 받으면 중앙 복구팀보다 현장 복구 인력이 먼저 병목이 된다.

탐지 지표는 같은 시간대 다수 Windows host의 bugcheck, reboot loop, WinRE 진입 이벤트, 특정 EDR content version과 driver version 집중, 원격 관리 도구 접속 실패, 공항별 helpdesk 티켓 급증이다. 단순 장애처럼 보여도 변경 이력과 배포 범위를 즉시 연결해 볼 수 있어야 한다.

두 번째는 운영 데이터 무결성 손상이다. 파트너 시스템이나 내부 ETL 장애로 gate assignment, crew availability, passenger rebooking 데이터가 지연되거나 서로 다른 버전으로 전파되는 경우다. source-of-truth와 downstream system 사이 timestamp, sequence, count 불일치, 동일 항공편에 대한 gate·crew·passenger status 충돌, AI 추천과 실제 운영 제약의 반복적 mismatch를 탐지해야 한다.

세 번째는 서드파티 원격접속·관리 도구 침해다. 공급업체가 항공사 운영망이나 공항망에 접근하는 경로가 침해되면 영향은 단순 장애보다 크다. 벤더 계정의 비정상 시간대 로그인, 새 MFA 등록, impossible travel, 원격관리 도구를 통한 대량 명령 실행, 파일 배포, agent uninstall, airport/airline boundary를 넘는 인증 시도 증가가 주요 징후다.

네 번째는 클라우드·SaaS 의존성 장애다. 운항, 고객 알림, 승무원 커뮤니케이션, 재예약, CRM, 결제 시스템 일부가 특정 클라우드 리전이나 SaaS 장애에 묶일 수 있다. 리전별 API latency와 error rate, 메시징·고객 알림 큐 backlog, SaaS status와 내부 incident timeline의 상관관계를 평소부터 대시보드화해야 한다.

대응 우선순위

즉시 적용할 조치는 배포 통제와 현장 복구 준비다. 고권한 보안 에이전트 업데이트를 전사 일괄 배포하지 말고, 공항·업무 중요도별 ring/canary 배포로 전환해야 한다. 항공 운항 핵심 단말에는 업데이트 보류 가능 시간, 강제 배포 예외, 오프라인 복구 절차를 문서화해야 한다. BitLocker recovery key, WinRE 접근 절차, 안전 모드 복구 runbook은 중앙 보안팀 문서가 아니라 현장팀이 실제로 사용할 수 있는 형태여야 한다.

동시에 운영 데이터의 source-of-truth를 분명히 해야 한다. 승무원 배정, 항공기 회전, 게이트, 수하물, 승객 알림 시스템의 동기화 상태를 볼 수 있는 대시보드가 필요하다. 장애 대응 회의에서 “어느 화면이 맞는가”를 토론하는 순간 복구는 늦어진다.

단기적으로는 보안 에이전트별 blast radius를 정의해야 한다. 장애 시 중단되는 업무, 영향 공항, 수동 대체 절차, 복구 우선순위를 미리 정하고 IROPS 훈련에 포함해야 한다. 훈련 시나리오는 사이버공격만이 아니라 정상 공급업체 업데이트 실패, 운영 데이터 불일치, SaaS 장애를 포함해야 한다.

공급업체 관리도 계약 문구 수준을 넘어야 한다. 주요 보안·운영 공급업체에 대해 incident notification SLA, staged rollout 지원 여부, rollback capability, customer-controlled update policy를 계약과 보안심사 항목에 넣어야 한다. 원격접속 공급업체 계정은 JIT, MFA, PAM, 세션 녹화, 명령 감사, 접근망 제한을 기본값으로 삼아야 한다.

중장기적으로는 “operational dependency bill”이 필요하다. SBOM이 소프트웨어 구성요소를 보여준다면, 항공 운영에는 SaaS, 보안 에이전트, 데이터 피드, 운영 API, 클라우드 리전, 공항 인터페이스까지 포함한 운영 의존성 목록이 필요하다. 어떤 구성요소가 멈추면 어떤 항공편, 어떤 공항, 어떤 고객 프로세스가 영향을 받는지 연결해야 한다.

또한 항공 사이버 리스크를 CIA 관점만이 아니라 safety, operational continuity, passenger impact, crew legality, regulatory reporting 기준으로 재분류해야 한다. 보안팀의 우선순위와 운항통제센터의 우선순위가 다르면, 장애 시 의사결정은 늦어진다.

결론

2024년 7월의 대규모 장애는 항공업계에 불편한 사실을 남겼다. 보안 제품은 공격을 막기 위한 도구지만, 그 자체가 항공 운영의 핵심 의존성이 됐다. 정상 업데이트 하나가 잘못 배포돼도 체크인과 탑승, 승무원 배정, 수하물, 고객 알림, 재예약이 동시에 흔들릴 수 있다.

2년 뒤 항공사의 IT·보안 투자는 더 많은 도구를 사는 방향만으로는 충분하지 않다. 중요한 것은 배포를 통제하고, 실패를 격리하고, 데이터를 검증하고, 현장에서 복구할 수 있는 능력이다. 공급망 보안도 악성 코드가 들어왔는지 확인하는 수준을 넘어, 신뢰한 공급업체의 정상 변경이 실패했을 때 어느 업무가 멈추는지까지 관리해야 한다.

항공업계의 다음 보안 경쟁력은 탐지 속도만이 아니다. 장애가 발생했을 때 어떤 시스템을 늦게 업데이트할지, 어떤 데이터를 믿을지, 어떤 공항부터 복구할지, 어떤 공급업체 권한을 즉시 끊을지 이미 정해져 있는지가 관건이다. “MS발 먹통”으로 기억된 사건의 진짜 교훈은 여기에 있다. 항공 보안은 이제 IT 부서의 통제가 아니라 운항 복원력의 일부다.

참고자료

  1. CrowdStrike, Channel File 291 Incident: Root Cause Analysis is Available, 2024-08-06
    https://www.crowdstrike.com/en-us/blog/channel-file-291-rca-available/

  2. CrowdStrike, External Technical Root Cause Analysis - Channel File 291, 2024-08-06
    https://www.crowdstrike.com/wp-content/uploads/2024/08/Channel-File-291-Incident-Root-Cause-Analysis-08.06.2024.pdf

  3. CrowdStrike, Falcon Content Update Preliminary Post Incident Report, 2024-07-24
    https://www.crowdstrike.com/en-us/blog/falcon-content-update-preliminary-post-incident-report/

  4. Microsoft Official Blog, Helping our customers through the CrowdStrike outage, 2024-07-20
    https://blogs.microsoft.com/blog/2024/07/20/helping-our-customers-through-the-crowdstrike-outage/

  5. Delta Air Lines, SEC Form 8-K, 2024-08-08
    https://www.sec.gov/Archives/edgar/data/27904/000168316824005369/delta_8k.htm

  6. SITA, 2025 Air Transport IT Insights
    https://www.sita.aero/globalassets/docs/surveys--reports/sita-2025-it-insights-report-combined-digital.pdf

  7. SITA, Aviation's record technology investment hinges on data coordination, 2026-04-15
    https://www.sita.aero/about-us/pressroom/news-releases/sita-research-finds-aviations-record-technology-investment-hinges-on-one-thing-data-coordination/

  8. FAA, Civil Aviation Cybersecurity Aviation Rulemaking Committee Charter, 2025-05-13
    https://www.faa.gov/media/94801

  9. EASA, Information Security Part-IS FAQ
    https://www.easa.europa.eu/en/the-agency/faqs/information-security-part

  10. IATA, Aviation Cyber Security
    https://www.iata.org/en/programs/security/cyber-security/


본 콘텐츠는 AI 기술로 생성된 분석 리포트를 포함하고 있습니다. 내용 중 사실과 다르거나 보완이 필요한 정보를 발견하시면 댓글을 통해 소중한 의견 부탁드립니다. 여러분의 피드백은 더 정확한 보안 정보 공유에 큰 도움이 됩니다.

IT 도구 서랍

→ Unix: 2025-01-15T09:30:00
→ 날짜: 1736934600

→ ASCII: ABC
→ 문자: 65 66 67

ASCII 코드표 — 클릭하면 입력란에 추가

DecHex약어설명
DecHex문자
DecHex문자

→ 유니코드: 홍길동
→ 문자: \ud64d\uae38\ub3d9