2026년 10월 30일 인천공항에서 일부 항공사의 체크인과 탑승권 발급이 지연됐습니다. 이 사건을 ‘예약불가’라고만 부르면 신규 항공권 구매 문제와 공항 현장 수속 문제가 섞입니다.
와... 이때 제가 만약 현장에 있었다면 여행자로써 많이 당황스러웠을 것 같네요.
확인한 보도의 중심은 출국 당일 수속 장애이며, 이 글은 공개된 경과와 기업 IT 운영에 적용할 복구 확인 기준을 구분해 살펴봅니다.
최초 통신 이상과 발급 중단은 시작 시점이 상이
언론 10월 30일 보도에 따르면 오전 4시 30분부터 일부 항공사 발권 네트워크에서 문제가 발생했고, 두 터미널의 항공사 13곳에서 간헐적인 통신 끊김이 나타났습니다. 낮 12시부터는 외국 항공사 일부의 일반 탑승권 발급이 사실상 중단됐습니다.
언론 후속 보도는 공사 설명을 인용해 오후 5시 기준 ARINC와 TravelSky 장애가 복구됐다고 전했습니다. 한때 대기 여객은 약 1,200명이었습니다. 최초 이상부터 복구까지는 약 12시간 30분, 낮 12시부터 계산한 발급 중단 구간은 약 5시간이므로, 서로 다른 시작점을 같은 장애 시간으로 비교하면 안 됩니다.
다만 이 시간표만으로 모든 항공사가 내내 발급을 중단했다고 볼 수는 없습니다. 개별 항공편의 지연 지속 시간 역시 시스템 복구 시각과 별도로 확인해야 합니다.
통신 연결만 확인하면 업무 복구 점검의 공백 발생
보도에는 ARINC 연결 문제와 일부 항공사의 TravelSky 발권시스템 장애가 함께 등장합니다. 그러나 상세 장애보고서 없이 장비 고장, 소프트웨어 결함, 사이버공격 중 하나로 원인을 확정할 수는 없습니다. 공개 경과에서 읽을 수 있는 운영상의 과제는 외부 연결 상태와 실제 수속 처리 결과를 따로 확인해야 한다는 점입니다.
AWS의 운영 준비 가이드도 구성요소 상태뿐 아니라 사용자 경험을 관찰하고 복구 절차를 시험하도록 설명합니다. 이를 기업 업무에 적용하면 ‘연결 성공’과 ‘필수 업무 완료’를 별도 판정 항목으로 두는 방법이 됩니다. 아래 기준은 이 사건에서 실제 시행됐다고 확인한 조치가 아니라 일반적인 점검 제안입니다.
예를 들어 승인된 테스트 환경에서는 접속 여부, 대상 정보 조회, 업무 처리 결과 저장, 출력 또는 결과 통지까지 차례로 확인할 수 있습니다. 실제 운영 데이터로 검증해야 한다면 담당자 승인과 영향 통제를 전제로 하고, 같은 요청을 무작정 반복하지 않도록 기존 처리 결과부터 확인해야 합니다.
이중화는 두 경로가 함께 의존하는 곳부터 확인
AWS의 의존성 분석 가이드는 대기 환경이 주 환경과 독립적으로 동작할 수 있어야 하며, 외부 서비스가 전환 후에도 이용 가능한지 살펴보도록 안내합니다. 서버나 회선을 추가해도 두 경로가 같은 필수 외부 서비스를 거치면 그 서비스의 장애 영향을 함께 받을 수 있습니다.
기업 담당자는 서비스별로 ‘주 경로·대체 경로·공통 의존 대상·전환 권한·확인할 업무 결과’를 한 줄에 정리해 볼 수 있습니다. 대체 경로가 다른 회선만 쓰는지, 인증이나 거래 처리까지 독립적인지 구분하면 투자 대상을 좁히는 데 도움이 됩니다. 이번 인천공항의 실제 이중화 구성이나 전환 실패 여부는 확인되지 않았으므로, 이 분석을 해당 공항의 설계 결함 판정으로 연결해서는 안 됩니다.
수기 처리 뒤에는 대조와 대기 업무 정리 잔존
MBC 보도에서는 일부 항공사가 탑승권을 수기로 발급했다고 전했습니다. 수기 처리는 제한된 업무를 이어갈 수단이지만, 전산이 돌아왔다는 이유만으로 수기 기록까지 정리됐다고 판단할 수는 없습니다. 이 사건에서 복구 후 어떤 대조 절차를 수행했는지는 확인되지 않았습니다.
일반적인 운영 방안으로는 수기 처리 건을 구분해 남기고, 전산에 이미 반영된 건과 미반영 건을 담당자가 대조한 뒤 필요한 후속 처리를 하는 절차를 마련할 수 있습니다. 무조건 재입력하면 중복 처리가 생길 수 있으므로 업무별 식별 기준과 책임자를 먼저 정해야 합니다. 통신 복구, 업무 처리 재개, 대기 건 정리를 구분해 안내하면 현장도 다음 확인 항목을 알 수 있습니다.
자주 묻는 질문
온라인 항공권을 다시 구매해야 합니까?
이 사건의 수속 지연만으로 기존 예약이 취소됐다고 볼 근거는 없습니다. 재구매에 앞서 해당 항공사에 기존 예약 상태와 이용편의 후속 안내를 확인하는 편이 타당합니다.
주차 예약이나 공항 전체 시스템도 멈춘 사건입니까?
확인한 자료는 일부 항공사의 체크인·탑승권 발급을 다룹니다. 이 근거만으로 주차 예약이나 공항 전체 서비스의 중단까지 확대할 수는 없습니다.
해킹이나 개인정보 유출로 확인됐습니까?
확인한 보도만으로 사이버공격이나 개인정보 유출을 확정할 수 없습니다. 원인에 관한 공식 조사 결과와 영향 범위 발표가 추가로 필요합니다.
결론
이번 사례를 기업 IT 점검에 적용한다면 복구 완료 조건을 먼저 구체화하는 것이 좋습니다. 외부 서비스가 끊겼을 때 가능한 대체 업무, 실제 처리 결과의 확인 방법, 수기 기록 대조 책임자를 정해 두십시오. 복구 공지에는 기술적으로 돌아온 부분과 아직 정리 중인 업무를 나누어 적어야 이용자와 현장이 같은 상태를 이해할 수 있습니다.