맨체스터·스탠스테드 등 英 공항 3곳 해킹, 고객 870만 명 개인정보 유출

맨체스터·스탠스테드 등 英 공항 3곳 해킹, 고객 870만 명 개인정보 유출

[핵심요약] 英 맨체스터 등 공항 3곳을 운영하는 MAG가 해킹을 당해 고객 870만 명의 이메일·전화번호·차량번호 등이 유출됐어요. 결제정보는 빠졌지만, 정보 조합이 피싱에 악용될 위험이 크다는 경고가 나와요.

2026년 8월 25일, 영국 맨체스터·런던 스탠스테드·이스트미들랜즈 세 개 공항을 운영하는 맨체스터공항그룹(MAG)이 해킹 공격을 당한 사실이 드러났어요. 공격자는 발견되기 며칠 전부터 이미 고객 데이터베이스에 접근하고 있었고, MAG는 이틀 뒤인 8월 27일 이 사실을 공개했어요. 

이번 사고로 주차·라운지·패스트트랙·공항 와이파이 서비스를 이용한 고객 약 870만 명의 이메일 주소, 전화번호, 우편번호, 차량 등록번호가 노출됐어요. 다행히 은행 계좌나 카드 결제정보는 포함되지 않았고, 항공편 운항이나 공항 보안 자체에는 영향이 없었어요.

[MAG 해킹 사고로 노출된 고객 870만 명의 정보 종류와 영향받은 공항 3곳]

무슨 일이 있었나? 침투부터 공개까지

[공격자의 최초 침투부터 발견, 공개, 접근 차단까지 이어진 MAG 사고의 대응 흐름]

MAG 측 설명에 따르면 공격자의 실제 침입 시점은 발견일보다 며칠 앞선 것으로 파악돼요. 즉 공격자가 눈치채지 못한 채 시스템 안에 머무른 '체류 기간'이 있었다는 뜻이에요. 이후 내부 보안팀이 이상 징후를 포착하자 MAG는 곧바로 외부 사이버보안 전문업체를 투입하고, 영향받은 시스템에 대한 접근을 제한하는 방식으로 확산을 차단했어요. 동시에 영국 관계 당국에 신고하고, 예약 조회·변경이 가능한 온라인 '매니지 마이 부킹' 서비스를 일시 중단했어요.

노출된 정보는 공항 하나의 시스템이 아니라 주차장 예약, 라운지 이용, 패스트트랙 발권, 공항 와이파이 회원가입 등 여러 고객 접점 서비스가 뒤섞인 데이터였어요 — 그만큼 공항이 다양한 협력 서비스의 고객 데이터를 한 곳에 모아 관리하고 있었다는 뜻이기도 해요.

왜 중요한가? / 무엇이 위험한가?

이번 사고에서 눈여겨볼 대목은 유출된 정보 자체의 '조합'이에요. 이메일 주소, 전화번호, 우편번호, 차량 등록번호는 하나하나만 보면 그렇게 민감해 보이지 않을 수 있어요. 하지만 보안 전문가들은 이 네 가지가 합쳐지면 실제 인물을 특정하고 신뢰를 얻기에 충분한 '사칭용 재료'가 된다고 경고해요. 실제 예약 내역과 차량번호를 아는 사람이 항공사나 공항을 사칭해 문자나 이메일을 보내면, 받는 사람 입장에서는 진짜라고 믿을 수밖에 없는 정황이 만들어져요. 

게다가 이번 사고는 랜섬웨어처럼 파일을 암호화해 서비스를 마비시키는 방식이 아니라, 조용히 데이터베이스에 접근해 정보만 빼가는 방식이었어요. 그래서 겉으로는 공항 운영이 정상적으로 돌아가는 것처럼 보였지만, 그 이면에서는 며칠간 데이터가 그대로 노출돼 있었던 거예요. 국내 조직에도 시사점이 커요 — 항공·교통·물류처럼 여러 협력업체 서비스를 하나의 통합 회원 시스템으로 묶어 운영하는 곳이 늘고 있는데, 이런 구조는 사고가 나면 피해 범위가 한 서비스에 그치지 않고 연결된 모든 서비스로 번진다는 공통점을 갖고 있어요.

우리 회사도 대비하려면?

이런 사고를 막으려면 가장 먼저 점검해야 할 게 '내가 가진 고객 데이터가 실제로 어디까지 연결돼 있는가'예요. 주차장 예약 시스템, 회원 가입 시스템, 마케팅 메일링 리스트가 전부 같은 데이터베이스를 들여다보고 있다면, 그중 하나만 뚫려도 전체가 노출될 수 있어요. 서비스별로 접근 권한과 데이터베이스를 최대한 분리하고, 꼭 필요한 최소한의 정보만 각 시스템이 갖도록 설계하는 게 기본이에요.

[MAG 해킹 사고를 참고해 만든 5가지 자가진단 체크리스트]

또 하나는 '탐지 속도'예요. 이번 사고처럼 공격자가 발견되기 며칠 전부터 이미 접근하고 있었다는 건, 침해 여부를 실시간으로 알아차릴 로그 모니터링 체계가 부족했다는 뜻이기도 해요. 특히 전산 인력이 소수인 중견기업일수록 이상 접근 탐지를 사람이 매번 눈으로 확인하기 어려우니, 자동 경고 알림이 오는 로그 시스템을 최소한이라도 갖춰두는 게 중요해요. 

백업 데이터만큼은 이런 고객 데이터베이스와 물리적으로 분리해 관리하면, 설령 서비스 계정 하나가 뚫리더라도 백업까지 함께 노출되는 최악의 상황은 막을 수 있어요.

• 주차·와이파이·라운지 등 부가서비스 예약 시스템이 회원 DB를 공용으로 쓰고 있나요
• 서비스 접속 로그에서 평소와 다른 지역·시간대 접속 이력이 늘고 있진 않나요
• 침해 발생부터 탐지까지 며칠씩 걸려도 알아채지 못하는 구조는 아닌가요
• 결제정보와 개인정보(이메일·전화번호·차량번호 등)를 같은 테이블에 저장하고 있나요
• 최근 받은 예약 확인 메일이나 문자, 발신 도메인과 번호를 실제로 확인해 보셨나요

Q. 랜섬웨어가 아니라 단순 정보 유출인데, 이렇게 크게 다룰 사고인가요?

A. 네. 랜섬웨어처럼 서비스를 마비시키지 않아도, 이메일·전화번호·차량번호처럼 조합 가능한 개인정보가 대량으로 빠져나가면 이후 몇 달간 피싱·사칭 공격의 재료로 계속 악용될 수 있어요. 오히려 서비스가 멈추지 않아 피해 사실을 늦게 알아차리기 쉽다는 점에서 더 위험할 수도 있어요.

Q. 우리처럼 전산 인력이 부족한 중소기업도 이런 사고를 겪을 수 있나요?

A. 오히려 더 취약할 수 있어요. MAG처럼 큰 조직도 침해를 며칠간 눈치채지 못했는데, 모니터링 인력이 부족한 곳이라면 그 체류 기간이 훨씬 길어질 수 있어요. 규모가 작을수록 회원 데이터베이스 구조를 단순하게 유지하고, 접근 로그를 최소한이라도 자동으로 확인하는 습관이 더 중요해요.

Q. 결제정보가 빠졌으니 안심해도 되나요?

A. 그렇지 않아요. 결제정보가 없어도 이메일·전화번호·차량번호만으로 충분히 정교한 사칭 메일이나 문자를 만들 수 있어요. 특히 이번처럼 실제 예약 서비스 이름을 아는 상태에서 접근하면 피싱 성공률이 훨씬 높아지니, 노출 대상자는 당분간 관련 연락을 더 의심하고 확인하는 습관이 필요해요.

이번 MAG 사고는 화려한 랜섬웨어 몸값 요구 없이도, 조용한 데이터 접근만으로 870만 명의 정보가 흔들릴 수 있다는 걸 보여줬어요. 공항처럼 여러 협력 서비스를 하나로 묶어 운영하는 구조일수록 사고의 파급력도 그만큼 커진다는 교훈을 남겼어요. 데이터가 얼마나 넓게 연결돼 있는지, 그리고 그 연결을 얼마나 빨리 알아챌 수 있는지가 다음 사고의 크기를 결정할 거예요.

이런 사고를 막으려면 고객 데이터베이스 하나가 뚫리더라도 백업만큼은 손대지 못하는 구조가 필요해요. 물리적으로 분리된 이중 데이터 다이오드 방식의 디포트리스가 그 역할을 해줘요. 관리자 계정이 뚫려도 백업은 왜 안전한지 궁금하다면 여기서 확인해보세요.