인천공항 발권 장애, 이것도 보안 문제일까?

보안 사고 소식이 자주 들리다 보니, 공항에서 발권이 멈췄다는 뉴스를 보면 해킹이 아닐까 하는 걱정부터 앞서게 된다. 항공권을 예약하고 공항에 도착해도, 눈에 보이지 않는 시스템이 작동하지 않으면 다음 단계로 갈 수 없다는 점도 불안하다.

다만 걱정과 확인된 원인은 구분해야 한다. 2026년 10월 30일 인천공항 장애에 관해 인천국제공항공사가 보도를 통해 설명한 내용은 ARINC 글로벌 네트워크 불안정과 TravelSky 발권 시스템 오류다. 뉴시스가 인용한 공사 관계자는 데이터 전송에 문제가 있었지만 해킹 등 정확한 원인은 확인되지 않았다고 밝혔다. 확인한 자료만으로는 이번 장애를 해킹이나 랜섬웨어로 단정할 수 없다.[1][3][4]

먼저 확인할 내용

• 공사 설명을 인용한 보도에 따르면 체크인·발권은 10월 30일 17시 정상화됐다.
• 네트워크 불안정은 현재 설명이며, 그 불안정을 일으킨 근본 원인까지 밝혀졌다는 뜻은 아니다.
• 과거 공항 보안 사고와 이번 장애는 별개다. 이번 장애로 승객 정보가 유출됐다는 사실도 확인되지 않았다.

언제, 어디서 문제가 생겼나?

새벽의 간헐적인 네트워크 장애와 정오 이후 중국 항공사 세 곳의 발권 중단을 나누어 봐야 한다. 아래 시각은 모두 2026년 10월 30일 한국시간(KST)이다.

• 04:30: 발권 시스템을 연결하는 ARINC 네트워크에 장애가 발생했다. 연합뉴스는 제1터미널 항공사 8곳, 제2터미널 5곳에서 간헐적으로 통신이 끊겼다고 보도했다. 공항 전체 항공사의 수속이 동시에 완전히 멈췄다는 뜻은 아니다.[1]
• 정오 무렵~오후: 중국동방항공·중국남방항공·중국국제항공(에어차이나)이 사용하는 TravelSky 발권 시스템에 오류가 생겨 일반 발권이 중단됐다. 한겨레·파이낸셜뉴스는 정오 또는 낮 12시께, 연합뉴스는 ‘오후 들어’라고 설명했다. 일부 수속은 수기로 진행됐다.[1][2][4]
• 16:00 집계: 한겨레가 전한 지연 항공편은 35편이다. 공항 내 대기 여객은 한때 약 1,200명이었다.[2]
• 17:00 집계·복구: 연합뉴스는 지연 38편, 대기 1,200여 명을 전했다. 공사는 이날 17시 체크인·발권 시스템이 모두 복구돼 전체 항공사의 수속이 정상화됐다고 밝혔다.[1][4]

35편과 38편은 집계 기준 시각이 다르다. 어느 하나를 틀린 수치로 지우기보다 ‘16시 기준 35편, 17시 기준 38편’이라고 읽는 편이 정확하다. 시스템 복구 시각이 곧 모든 대기열이 사라지거나 지연편이 해소된 시각은 아니라는 점도 구분할 필요가 있다.[1]

현장 지원 인력은 보도마다 집계 범위가 다르다. 뉴스1은 안내 인력 50여 명 추가 배치를, 한겨레는 안내·경비 인력 60명 추가 배치를, 파이낸셜뉴스는 안내·경비 인력 60여 명 추가 배치를 전했다. 같은 범위와 시점의 집계인지 확인되지 않아, 이 수치들을 더해 전체 투입 인원으로 볼 수는 없다.[2][4][5]

장애 시간도 마찬가지다. 연합뉴스의 ‘5시간여’는 정오 무렵부터 이어진 중국 항공사 발권 중단 구간과 맞물린다. 뉴시스의 ‘12시간여’는 새벽 04:30 최초 네트워크 장애부터 17시 복구까지를 설명한다. 모든 항공사의 모든 수속이 12시간 내내 중단됐다는 의미로 바꾸면 안 된다.[1][3][4]

ARINC와 TravelSky는 무엇을 하는 시스템인가?

쉽게 말하면 ARINC는 항공 통신·연결 서비스 쪽 이름이고, TravelSky는 이번 보도에서 중국 항공사 세 곳의 발권 시스템으로 등장한다. 둘을 하나의 프로그램 이름처럼 읽으면 장애 구간을 놓치기 쉽다.

Collins Aerospace의 ARINC AviNet Airport 제품 설명은 역할을 이해하는 데 도움이 된다. 이 서비스는 공유 광역통신망(WAN)을 통해 항공사의 셀프체크인 시스템과 백오피스 시스템을 글로벌 네트워크에 연결한다. 공항에서 체크인·탑승용 원격 호스트 애플리케이션으로 접근하도록 연결을 제공하는 것이다.[7]

비유하면 카운터와 항공사 쪽 시스템 사이에서 정보가 오가는 길에 가깝다. 길이 불안정하면 카운터 PC가 켜져 있어도 업무 처리가 늦어질 수 있다. 다만 이 제품 설명은 연결 서비스의 역할을 설명하기 위한 예시다. 이번 인천 장애의 정확한 영향 제품이 AviNet Airport였다고 확인한 것은 아니다.

TravelSky는 공식 회사 소개에서 중국 항공·여행 산업의 IT 솔루션 사업자라고 설명한다. 이번 국내 보도에서는 앞서 언급한 중국 항공사 세 곳이 쓰는 발권 시스템으로 지칭됐다. 어느 내부 구성요소에서 어떤 오류가 났는지까지 공개된 기술 분석으로 확인된 상태는 아니다.[4][8]

또 하나 구분할 이름이 ARINC MUSE다. 여러 항공사가 체크인 카운터와 게이트 자원을 함께 쓰도록 하는 승객 처리 플랫폼으로, 네트워크 연결 서비스와 같은 제품이 아니다. 같은 Collins·ARINC 계열 이름이 보이더라도, 이번 장애가 MUSE에서 발생했다는 뜻은 아니다.[7][9]

공식 설명은 무엇을 말했고, 무엇은 아직 말하지 않았나?

현재 설명은 문제가 드러난 구간을 알려주지만, 근본 원인을 확정하지는 않는다. 공사가 ARINC 글로벌 네트워크 불안정으로 보고 있다는 보도와, 왜 불안정해졌는지 확인됐다는 발표는 다른 이야기다.[1][3]

확인된 설명은 데이터 전송 문제, 발권 오류, 그리고 17시 복구다. 확인되지 않은 것은 해킹 여부, 구체적인 기술 원인, ARINC와 TravelSky 두 장애 사이의 인과관계다. 파이낸셜뉴스는 TravelSky의 ‘별도’ 장애로 서술하지만, 그것만으로 두 현상이 기술적으로 완전히 독립적이었다거나 앞선 장애가 뒤의 장애를 유발했다고 확정할 수는 없다.[3][4]

‘해킹 미확인’은 ‘해킹이 아니다’라는 결론도 아니다. 아직 판단할 증거가 공개되지 않았다는 의미로 읽어야 한다. 발권이 멈췄다는 사실만으로 승객 정보가 유출됐다고 추론할 수도 없다. 서비스 이용 가능 여부와 데이터 유출·변조 여부는 따로 확인할 사안이다.

2026년 10월 30일 22:31 KST까지 관련 보도와 인천공항공사·Collins Aerospace(RTX)·TravelSky의 공식 페이지를 재확인했지만, 확인 범위에서는 이번 인천 건 전용 기술 성명이나 공사의 근본 원인 분석 원문을 찾지 못했다. 이는 공지가 존재하지 않는다는 단정이 아니다. 여기서 인용한 공사 설명은 관계자 발언을 전달한 보도에 근거한다.

공항 수속이 멈추면 언제나 보안 사고인가?

아니다. 이용자에게 비슷하게 보이는 장애도 확인된 원인은 다를 수 있다. 비교할 만한 두 사례가 있다.

2025년 9월 Collins MUSE 관련 사고는 랜섬웨어가 확인된 사례다. RTX는 9월 24일자 SEC 8-K 공시에서, 9월 19일 MUSE 승객 처리 소프트웨어를 지원하는 시스템의 랜섬웨어 사고를 인지했다고 밝혔다. 영향을 받은 고객들은 백업·수동 처리로 전환했고 일부 항공편의 지연·결항을 겪었다고 설명했다. TechCrunch가 직접 받은 ENISA의 이메일 성명도 당시 공항 운영 장애를 제3자 랜섬웨어 사고로 설명했다. 이는 2025년 사례의 근거이지, 이번 인천 장애의 원인을 설명하는 자료는 아니다.[9][12]

반면 2024년 7월 19일 CrowdStrike 장애는 Windows용 Falcon 콘텐츠 업데이트의 결함이었다. CrowdStrike는 공식 고객 서한에서 사이버공격이 아니라고 명시했고, 예비 사후 보고서에서도 콘텐츠 구성 업데이트와 Windows 시스템 충돌을 설명했다. 보안 제품에서 생긴 대규모 장애라고 해서 공격으로 생긴 사고인 것은 아니다.[10][11]

비교의 목적은 이번 사건의 범인을 찾는 것이 아니다. ‘체크인이 멈췄다’는 결과와 ‘어떤 원인으로 멈췄다’는 판단 사이에 증거가 필요하다는 점을 확인하는 데 있다.

장애가 보안 사고인지 가릴 때 무엇부터 봐야 하나?

이용자는 공식 고지의 표현과 갱신 시각부터, 운영자는 그 고지를 로그·변경 이력과 함께 봐야 한다. 다음은 일반적인 확인 순서이며 이번 공항에서 특정 징후가 발견됐다는 뜻은 아니다.

• 고지의 단어와 확정 수준: ‘네트워크 장애’, ‘업데이트 결함’, ‘침해’, ‘랜섬웨어’ 중 무엇을 밝혔는가. ‘조사 중’이나 ‘추정’을 빼고 전달하지 않는다.
• 영향 범위와 시작 시각: 어느 서비스·지역·고객에서 언제 문제가 시작됐는가. 운영자는 배포·설정 변경·회선 문제와 시간상 겹치는지 대조하되, 동시에 일어났다는 이유만으로 원인이라고 확정하지 않는다.
• 침해를 뒷받침하는 증거: 승인되지 않은 관리자 로그인, 파일 변조·암호화, 비정상 권한 변경 등의 기록이 있는가. 운영·보안 담당자가 보존된 로그를 함께 조사할 일이다. 일반 이용자가 내부 시스템을 직접 들여다볼 수 있는 항목은 아니다.
• 데이터 문제는 별도로 확인: 화면이 열리지 않거나 전송이 지연된다는 현상과 유출·변조 증거를 구분한다. 반대로 서비스가 복구됐다는 이유로 데이터 안전까지 확인됐다고 말하지 않는다.
• 서로 다른 공식 채널 대조: 공급업체 상태 안내, 공항·항공사 공지, 필요한 경우 조사기관 발표가 같은 시점을 설명하는지 확인한다. 오래된 기사나 검색 요약이 최신 상황을 대신하지 않도록 한다.

연결 시간 초과가 많다고 공격이 아니라고 할 수 없고, 외부에서 침해 징후가 보이지 않는다고 침해가 없었다고 할 수도 없다. 이 체크리스트는 독자가 원격으로 해킹 여부를 판정하는 도구가 아니라, 확인할 질문을 정리하는 도구다.

외부 서비스 하나에 기대고 있다면 무엇을 준비할까?

모든 시스템을 직접 만들기보다, 의존하는 곳과 중단됐을 때의 선택지를 알아두는 편이 현실적이다. 다음은 SaaS·로그인·결제·CDN 등을 이용하는 조직에 적용할 수 있는 일반론이지, 인천공항의 실제 설계나 대응 수준에 대한 평가가 아니다.

1. 멈추는 업무를 한 장에 적는다. 외부 로그인 서비스가 중단되면 기존 로그인 이용자도 일을 못 하는지, 결제 API가 느려지면 주문 조회까지 막히는지 구분한다. 서비스 이름뿐 아니라 업무 영향이 보여야 한다.
2. 대체 경로의 공통 의존점을 확인한다. 예비 주소가 있어도 같은 인증·네트워크·공급업체를 공유한다면 함께 영향을 받을 수 있다. 대체 경로가 없다면 없다고 기록하고, 허용 가능한 중단 시간과 비용을 비교한다.
3. 수동 처리에도 범위를 정한다. 누가 승인하고, 어떤 정보만 받고, 정상화 후 누가 대조할지 정한다. 개인정보를 과하게 모으거나 수동 기록을 방치하지 않도록 하며, 결제·예약을 다시 처리할 때 중복이 생기지 않게 확인한다.
4. 계속 재시도하는 대신 한계를 둔다. 시간 초과와 재시도 횟수를 정하고, 연속 실패 시 호출을 잠시 멈추는 방식 등을 검토한다. 다만 결제처럼 쓰기 작업은 실패 화면이 떠도 실제 처리가 끝났을 수 있으므로 결과 조회와 중복 방지 설계가 먼저다.
5. 연락망과 복구 후 질문을 남긴다. 상태 안내 주소, 장애 연락 담당, 복구 목표, 고객 안내 문안을 정리한다. 복구 뒤에는 원인 분석(RCA), 영향 범위, 대체 경로가 작동했는지 물어본다. 원인을 모르는 동안에는 모른다고 안내한다.

일반 이용자에게 필요한 준비는 더 작다. 항공사·공항의 최신 수속 안내를 확인하고, 지연으로 일정이 바뀌었다면 해당 항공사의 변경·환불·증빙 안내를 확인하는 것이다. 예약 확인 정보를 준비하는 것은 도움이 될 수 있지만, 출력물이나 캡처가 시스템 장애를 우회해 탑승을 보장하는 것은 아니다.

지금 내릴 수 있는 결론은 무엇인가?

이번 인천공항 장애를 보안 사고로 단정할 수 없으며, 원인이 확정되기 전의 설명은 가설과 구분해야 한다. 이용자로서 불안할 수는 있지만, 걱정이 곧 기술적 증거가 되는 것은 아니다.

이 글은 2026년 10월 30일 22:31 KST에 관련 보도와 공급업체·공사 공식 페이지를 재확인한 내용을 반영했다. 확인 범위에서 근본 원인을 새로 확정한 발표는 찾지 못했다. 한겨레 20:42 수정본에서도 17시 복구와 16시 기준 지연 35편이라는 수치는 유지됐다.

원인에 관한 후속 발표가 나오면 이 내용을 다시 확인할 필요가 있다. 그때까지 해킹 여부와 두 장애의 관계는 확인되지 않은 것으로 남겨 두는 것이 맞다. 이번 뉴스에서 먼저 배울 것은 공격을 짐작하는 요령보다, 외부 시스템이 멈췄을 때 확인된 정보와 대체 수단으로 대응하는 방법이다.