항공 예약 시스템: 왜 아직도 메인프레임에서 사용되는가?

2026년에 스마트폰으로 항공편을 예약하면, 예약 요청은 모바일 앱, 웹 서비스, 결제 처리 시스템 등 여러 단계의 최첨단 기술을 거친 후 실제로 좌석을 확보하는 시스템에 도달합니다. 대부분의 경우, 이 시스템은 1960년대에 뿌리를 둔 소프트웨어이며, 여행 업계가 수십 년 동안 교체하려고 노력해 왔지만 완전히 성공하지 못한 인프라에서 작동합니다. Sabre, Amadeus, Travelport는 전 세계 거의 모든 항공편 예약을 처리합니다. 이들은 수백 개의 항공사, 수천 개의 여행사, 그리고 수백만 가지 좌석 조합에 걸친 실시간 재고 정보를 통해 매년 수십억 건의 거래를 처리합니다. 이 중 가장 오래된 시스템은 1964년 IBM 메인프레임에서 시작되었는데, 당시 예약 시간을 90분에서 단 몇 초로 단축시켜 상업 항공 산업에 혁명을 일으켰습니다.

이러한 시스템들이 현재 위치에 그대로 남아 있는 이유는 조직의 관성이나 엔지니어링의 보수성 때문이 아닙니다. 오히려 소프트웨어가 핵심 운영 프로세스에 너무 깊숙이 자리 잡아서 현실적인 일정상 교체 비용과 위험을 정당화할 수 없을 때 발생하는 현상, 그리고 업계가 이를 교체하려 하기보다는 핵심 기능을 중심으로 현대화하는 방식으로 대응해 온 과정을 보여주는 이야기입니다. 대규모 레거시 시스템 현대화 작업을 하는 사람이라면 누구나 항공 예약 시스템이 "실패할 수 없을 만큼 중요한 시스템"이 실제로 무엇을 의미하는지 가장 명확하게 보여주는 사례 연구라고 생각할 것입니다.

기원: 메인프레임이 항공사 문제를 해결한 이유

원래 SABRE(Semi-Automated Business Research Environment)는 제품이 아니라 특정 운영 위기에 대한 맞춤형 솔루션이었습니다. 1950년대 후반, 아메리칸 항공은 수동 예약 시스템이 감당할 수 없을 정도로 빠르게 성장하고 있었습니다. 좌석 예약은 전화 통화, 실물 재고 카드 수동 확인, 예약 보류, 콜백, 그리고 종이 기록이라는 복잡한 과정을 거쳐야 했는데, 이 과정은 예약당 평균 90분이 소요되었고 확장성에 한계가 있었습니다.

1964년 IBM 7090 메인프레임 두 대를 기반으로 구축되고 미국과 캐나다 전역의 1,500개 단말기에 연결된 SABRE 시스템이 완전히 가동되었을 때, 시간당 7,500건의 예약을 거의 오류 없이 처리할 수 있었습니다. 항공사는 처음으로 실시간 좌석 재고를 유지하고, 승객 기록을 완벽하게 저장하며, 전체 네트워크에서 즉시 예약을 가능하게 할 수 있었습니다. 예약 시간은 90분에서 몇 초로 단축되었습니다.

이러한 시스템을 가능하게 한 아키텍처적 선택, 즉 메인프레임 하드웨어에서의 중앙 집중식 트랜잭션 처리는 철학적인 이유로 선택된 것이 아닙니다. 1964년 당시 실시간 항공사 재고 관리 시스템의 지연 시간, 신뢰성, 동시 접속 요구 사항을 충족할 수 있는 유일한 아키텍처였기 때문에 선택된 것입니다. 그리고 이 시스템은 매우 효과적이어서 이후 모든 항공 예약 시스템의 아키텍처 템플릿이 되었습니다.

IBM의 트랜잭션 처리 시설(TPF)은 원래 SABRE를 위해 설계되었지만, 이후 전체 항공 산업의 운영 환경이 되었습니다. IBM에 따르면 거의 모든 대형 은행, 보험사, 소매업체, 항공사가 여전히 TPF를 사용하고 있습니다. 1987년 아마데우스(Amadeus)가 설립되었을 때도 TPF를 기반으로 했으며, 갈릴레오(Galileo, 현재 트래블포트)가 글로벌 데이터 시스템(GDS)을 출시했을 때도 TPF를 활용했습니다. 현재 상업 항공 분야에서는 세대에 걸친 여객 서비스 시스템이 공존하고 있으며, 많은 시스템이 여전히 TPF 메인프레임에서 운영되고 있습니다. 이는 TPF 기술 자체에 의문이 제기된 적이 없어서가 아니라, 메인프레임 하드웨어에서 TPF가 제공하는 트랜잭션 처리량, 신뢰성, 장애 허용치가 다른 아키텍처에서 동등한 규모로 재현하기 매우 어렵다는 것이 입증되었기 때문입니다.

이러한 시스템이 대규모 환경에서 실제로 하는 일은 무엇일까요?

항공 예약 시스템이 작동하는 규모는 소프트웨어 엔지니어링 관점에서 직관적으로 이해하기 어렵습니다. 글로벌 유통 시스템은 좌석 가용성뿐만 아니라 엄청나게 복잡한 조합 재고 문제를 관리합니다.

단일 대서양 횡단 항공편에는 수백 가지의 운임 등급이 있습니다. 각 운임 등급에는 사전 구매 요건, 최소 체류 기간, 이용 불가 날짜, 변경 수수료, 경유 허용 여부, 제휴 항공사와의 코드셰어 협정 등 특정 규칙이 적용됩니다. 두 항공사를 이용하고, 경유를 거치고, 왕복하는 예약의 경우 수천 가지의 유효한 운임 조합이 발생할 수 있으며, 이러한 조합들을 실시간 재고와 대조하여 확인하고 가격을 책정하고 보류해야 합니다. 일반적으로 이 과정은 1초 이내에 완료됩니다.

예약이 가장 많은 시간대에는 Sabre와 Amadeus가 함께 초당 수만 건의 거래를 처리합니다. 분당이 아니라 초당입니다. 각 거래에는 실시간 재고 조회, 운임 규정 평가, PNR(승객 이름 기록) 생성 또는 수정, 그리고 출발 관제, 상용 고객 우대 프로그램 및 부가 서비스 시스템과의 연동이 포함됩니다. 보장된 응답 시간은 밀리초 단위로 측정됩니다. 여행사나 예약 시스템이 운임 확인을 위해 몇 초 이상 기다리면 시간 초과 오류가 발생하여 재시도하거나 거래를 포기하기 때문입니다.

메인프레임 하드웨어에서 TPF(Trusted Processing Failure)는 다른 산업 분야의 IT 전문가들이 믿기 어려울 정도로 낮은 장애율로 이러한 처리량을 제공합니다. 메인프레임의 내결함성, 이중화된 프로세서, 핫스왑 가능한 구성 요소, 수십 년간 축적된 견고한 운영 체제 코드는 1990 ...

현대화 시도: 10년간의 프로그램이 실제로 보여준 것은 무엇이었는가

항공 예약 시스템 현대화의 역사는 핵심 시스템을 대체하려는 프로그램들이 시작되었지만, 수년 후에는 핵심 시스템을 감싸는 형태의 하이브리드 시스템으로 귀결된 역사입니다.

아메리칸 항공의 제트스트림 프로젝트는 2000년대에 세이버 메인프레임 PSS를 교체한다는 명확한 목표로 시작되었지만, 결국 자체 개발 대신 새로운 세이버 제품을 도입하는 것으로 마무리되었습니다. 자체 개발이 더 나은 시스템을 더 빠르게 구축할 수 있을 것이라는 초기 가정은 거의 모든 대규모 레거시 시스템 교체 프로그램에서 마주하는 현실과 같았습니다. 기존 시스템에는 아무도 알지 못했던 요구사항들이 있었는데, 교체 시스템이 그 요구사항을 충족하지 못하게 되면서 비로소 그 요구사항들이 드러나게 된 것입니다.

"우리는 시스템 스택 깊숙이 들어가 핵심 엔진을 바꾸고 규칙을 분리하여 신속하게 변경할 수 있도록 해야 합니다." 젯스트림 프로그램 당시 아메리칸 항공 IT 책임자들이 한 이 말은 문제점을 정확하게 설명합니다. 레거시 시스템에 내재된 규칙들, 즉 운임 산정 로직, 코드셰어 협정 구현, 규정 준수 계산, 수익 관리 통합 등은 수십 년에 걸친 사업 변화를 거치면서 축적되었지만, 기존 시스템을 실행하고 그 동작을 관찰하지 않고는 추출할 수 있도록 어떤 형태로든 문서화되어 있지 않았습니다.

2010년대에 본격적으로 시작된 세이버 자체의 현대화 프로그램은 10년 이상 소요되었고 수십억 달러의 비용을 들여 대부분의 코드를 온프레미스 메인프레임 인프라에서 마이그레이션했습니다. 2019년 기준으로 세이버 코드의 약 11%만이 여전히 온프레미스 데이터 센터에서 실행되고 있으며, 나머지는 모두 마이그레이션되었습니다. 2026년 2월, 세이버는 웨스트젯과 장기 PSS(프로세스 서비스 제공업체) 계약을 갱신했는데, 이는 10년에 걸친 현대화 노력과 수십억 달러의 투자에도 불구하고 PSS가 여전히 사업의 핵심 기반임을 보여줍니다.

아마데우스는 메인프레임 폐기를 보다 완벽하게 진행하여 마지막 메인프레임까지 클라우드 인프라로 전환하는 중요한 이정표를 달성했습니다. 아마데우스는 핵심 데이터 모델과 트랜잭션 아키텍처를 유지하면서 기능 구성 요소를 점진적으로 교체하는 방식을 채택하여, 하드웨어가 변경되었음에도 불구하고 메인프레임에서 시작된 아키텍처적 결정 사항들을 효과적으로 보존했습니다. 트랜잭션 의미 체계, PNR 구조, 재고 관리 로직 등은 기본적인 설계를 유지하면서 최신 인프라로 성공적으로 이전되었습니다.

교체가 생각보다 어려운 이유: 숨겨진 복잡성

항공 예약 시스템이 메인프레임에서 계속 사용되는 이유로 흔히 언급되는 것은 비용과 위험입니다. 물론 두 가지 모두 현실적인 문제입니다. 하지만 이는 모든 핵심 레거시 시스템 현대화 프로그램에 적용되는 더 근본적인 기술적 현실을 보여주는 증상일 뿐이며, 이를 정확하게 이해하는 것이 중요합니다.

코드 내에만 존재하는 비즈니스 규칙. 글로벌 유통 시스템의 운임 구성 로직은 수십 년에 걸친 규제 요건, 항공사 간 양자 협정, IATA 표준 개정, 그리고 비즈니스 규칙 변경 사항을 반영하는데, 이러한 사항들은 구현 코드와는 별도로 어떤 형태로든 문서화되어 있지 않습니다. 명세가 곧 구현인 셈입니다. 명세 없이 구현을 교체한다는 것은 기존 시스템의 동작을 철저하게 관찰하여 명세에 명시된 내용을 재구성해야 한다는 것을 의미하는데, 이는 수년이 걸릴 뿐만 아니라 모든 예외 상황을 포착할 만큼 완벽한 관찰이 불가능하기 때문에 결코 완료될 수 없는 과정입니다.

현대 아키텍처에서 재현하기 어려운 트랜잭션 의미론이 있습니다. TPF는 PNR, 좌석 예약, 승객 기록 업데이트, 결제 승인 및 확인 기록 전체에 걸쳐 일관성을 보장하는 동기식 원자적 트랜잭션 처리를 제공합니다. 이러한 모든 작업은 단일 원자 단위로 커밋되거나 전혀 커밋되지 않습니다. 분산 마이크로서비스 아키텍처에서 이를 재현하려면 신중한 오케스트레이션, 보완 트랜잭션 및 분산 잠금 관리가 필요하며, 이는 복잡하고 동기식 메인프레임 방식보다 속도가 느릴 수 있습니다. 항공 업계의 경험에 따르면 좌석 재고 관리에서 "최종 일관성"은 용납할 수 없는 속성입니다. 초과 예약된 항공편은 나중에 해결될 일시적인 불일치가 아니라 구체적이고 운영상 치명적인 실패입니다.

통합 표면. 성숙한 항공사 PSS는 출발 통제, 수익 관리, 마일리지 프로그램, 공항 시스템, 타사 GDS 연결, 코드셰어 파트너, 규제 보고 등 수백 개의 외부 시스템과 연결되어 있습니다. 각 연결에는 특정 인터페이스 계약, 메시지 형식, 타이밍 요구 사항, 오류 처리 동작 등이 있으며, 기존 시스템은 이러한 사항들을 구현했고 모든 종속 시스템은 이를 기반으로 구축되었습니다. PSS를 교체하려면 기존의 모든 인터페이스 계약을 동시에 유지 관리하거나(교체 아키텍처에 제약을 가함) 모든 종속 시스템과 변경 사항을 조율해야 합니다(이는 단일 프로그램이 관리할 수 있는 범위를 넘어 범위가 확장됨).

실시간 데이터 문제. 항공권 예약은 실시간 데이터이며, 몇 달 전에 예약된 내용을 그대로 이행해야 합니다. 기존 시스템의 데이터를 남겨두고 새 시스템으로 깔끔하게 전환할 수 있는 지점은 없습니다. 마이그레이션 과정에서 모든 실시간 PNR(예약 번호)을 기존 시스템에서 새 시스템으로 이전해야 하며, 관련 규정, 운임, 제한 사항 및 부가 서비스까지 모두 그대로 유지해야 합니다. 데이터 손실 없이 기존과 동일한 동작을 보장하면서 전 세계적인 규모의 PNR 마이그레이션을 수행하는 것은 기업 현대화에서 가장 어려운 기술적 과제 중 하나로 입증되었습니다.

건축적 대응: 핵심을 중심으로 현대화하기

아마데우스, 세이버, 그리고 개별 항공사에서 실제로 성공을 거둔 접근 방식은 대체가 아니라 전략적 포괄 및 점진적 추출입니다.

API 래핑은 핵심 예약 기능을 최신 REST 또는 SOAP API로 노출하여 새로운 애플리케이션이 핵심 거래 로직을 건드리지 않고도 최신 인터페이스를 통해 기존 시스템과 상호 작용할 수 있도록 합니다. 항공사들은 최신 요청을 TPF 거래 호출로 변환하고 구조화된 응답을 반환하는 API 계층 위에 모바일 앱, 웹 예약 엔진, 고객 서비스 도구를 구축해 왔습니다. 녹색 화면 터미널은 최신 GUI로 대체되지만, 기본 거래 처리 방식은 변경되지 않습니다.

핵심 기능이 아닌 부분을 분리하는 방식입니다. 수익 관리, 로열티 프로그램 관리, 보고 및 분석, 승무원 스케줄링 등 핵심 기능과 인접한 기능들을 하나씩 분리하여 최신 인프라에 재구현합니다. 각 분리 작업은 가장 위험도가 높은 핵심 트랜잭션 부분을 건드리지 않고 레거시 시스템의 규모를 줄여줍니다. 10년 이상에 걸친 점진적 분리 과정을 통해 레거시 시스템의 역할은 포괄적인 애플리케이션 플랫폼에서 특정 트랜잭션에 집중하는 엔진으로 축소됩니다.

아키텍처를 그대로 유지한 클라우드 인프라. 아마데우스는 메인프레임 폐기 과정에서 워크로드를 클라우드 인프라로 이전하면서도 메인프레임에서 시작된 트랜잭션 아키텍처를 그대로 보존했습니다. 하드웨어는 변경되었지만, 소프트웨어 설계, 데이터 모델, 트랜잭션 의미 체계, PNR 구조는 수십 년 동안 타당성이 입증된 아키텍처 설계 원칙을 그대로 유지했습니다.

기존 PNR 시스템과 함께 새로운 오퍼 및 주문 관리 기능이 도입됩니다. PNR 기반 기록을 최신 주문 관리 모델로 대체하는 IATA ONE Order 표준은 기존 PNR 기반 시스템과 함께 하나의 레이어로 구현되고 있습니다. Sabre의 차세대 오퍼 및 주문 기술은 2026년 WestJet과의 계약 갱신에서 언급되었으며, 이는 기존 PSS(승객 서비스 시스템)를 대체하는 것이 아니라, PNR 코어 시스템이 나머지 예약을 처리하는 동안 점차 예약 처리 비중을 늘려가는 현대적인 상업 레이어를 추가하는 방향으로 나아가고 있음을 보여줍니다.

이것이 핵심 임무 수행에 필수적인 기존 시스템 현대화에 미치는 영향은 무엇일까요?

항공 예약 시스템 사례는 항공 산업에만 국한된 것이 아닙니다. 이는 은행 핵심 시스템, 보험 정책 관리, 통신 요금 청구, 정부 복지 혜택 처리 등에서 나타나는 공통적인 패턴을 가장 잘 보여주는 예입니다. 이러한 패턴에는 비즈니스 규칙의 권위 있는 명세가 되고, 수십 개의 종속 시스템을 통합하는 허브 역할을 하며, 대규모 교체가 사실상 불가능한 규모와 신뢰성 요구 사항을 충족해야 하는 소프트웨어가 포함됩니다.

이러한 교훈은 모든 산업 분야에 걸쳐 공통적으로 적용됩니다.

현대화 작업을 시작하기 전에 코드에서 비즈니스 규칙을 추출하는 것은 필수적입니다. 운임 계산, 코드셰어 협정 로직, 규정 준수 규칙을 구현하는 COBOL 및 TPF 프로그램은 이러한 규칙에 대한 유일한 문서로 남아 있습니다. 이러한 로직을 먼저 추출하고 검증하지 않고 현대화 작업을 진행하면 모든 경우를 분석하지 않고는 모든 경우를 파악할 수 없으므로 모든 경우에 올바르게 작동하는 대체 시스템을 만들 수 없습니다.

의존성 맵은 마이그레이션 순서를 결정합니다. 가장 중요하고 통합이 잘 된 구성 요소부터 시작하여 PSS를 성공적으로 교체한 항공사는 없습니다. 모든 성공적인 현대화는 보고 시스템, 부가 서비스, 중요하지 않은 관리 기능 등 주변부에서 시작하여 점진적으로 내부로 확장해 나갔습니다. 이러한 순서는 의존성 그래프에서 도출됩니다. 즉, 내부 의존성이 가장 적은 구성 요소부터 먼저 처리하는 것이 가장 안전합니다.

모든 단계에서의 운영 검증은 필수적입니다. 기존 시스템과 새로운 시스템을 병렬로 실행하고 출력을 비교하며, 트래픽 전환 전에 동등성을 검증하는 이중 실행 검증 방식만이 시스템 장애가 물리적, 재정적, 규제적 결과를 초래하는 시스템의 신뢰성 요구 사항을 충족하는 유일한 방법입니다.

방법 SMART TS XL 항공사 관련 기존 시스템 분석에 적용됩니다.

자체 COBOL 프로그램, 요금 계산 시스템, 수익 회계, 로열티 포인트 계산, 규제 보고 시스템과 함께 Sabre 또는 Amadeus PSS를 운영하는 항공사는 모든 기업 메인프레임 현대화 프로그램이 직면하는 것과 동일한 분석적 과제에 직면합니다. 즉, 코드를 어떻게 처리할지 결정하기 전에 코드의 실제 내용을 파악하는 것입니다.

SMART TS XL의 정적 코드 분석 COBOL 프로그램에 내장된 비즈니스 규칙 로직, 즉 운임 유효성 검사 규칙, 수익 회계 계산, 로열티 등급 자격 로직 등 프로그램 코드 외에는 어디에도 존재하지 않는 로직을 추출합니다. PSS 핵심 시스템을 건드리지 않고 인접 시스템을 현대화하려는 항공사의 경우, 이 추출을 통해 대체 시스템이 반드시 일치해야 하는 사양을 생성할 수 있습니다.

애플리케이션 종속성 매핑은 마이그레이션 순서를 결정하는 종속성 그래프를 구축합니다. 이 그래프는 항공사 측 프로그램이 PSS의 어떤 데이터 피드에 의존하는지, 보고 프로그램이 어떤 COBOL 배치 출력에 의존하는지, 구성 요소가 변경될 때 어떤 하위 시스템을 업데이트해야 하는지 등을 결정합니다. 종속성 그래프는 점진적이고 안전한 현대화를 가능하게 하는 핵심 요소이며, Sabre와 Amadeus가 핵심 시스템에 적용했던 것과 동일한 접근 방식을 항공사 측 코드에도 적용한 것입니다.

영향 분석 기능은 모든 현대화 결정에 앞서 제기되는 질문, 즉 "이 프로그램이 변경되면 다른 어떤 부분에 영향을 미칠까?"에 대한 해답을 제공합니다. 항공사 시스템의 경우, 수익 회계 프로그램의 계산 방식 변경이 규제 보고, 파트너 정산, 재무 통합에 동시에 영향을 미칠 수 있으므로, 변경 전에 영향 범위를 파악하는 것은 항공사의 신뢰성 요구 사항을 충족하는 변경 관리를 위한 필수 조건입니다.

레거시 현대화 분석은 현대화 전의 모든 프로그램, 그 복잡성, 의존성, 사용되지 않는 코드 비율, 그리고 마이그레이션 위험 분류를 포함한 완벽한 사전 현황을 제공합니다. 모든 항공사 현대화 프로그램의 핵심 교훈은 경계선부터 시작하여 내부로 확장하고 모든 단계에서 검증하는 것입니다. 이를 위해서는 경계선이 어디인지, 그리고 의존성 구조가 어떻게 생겼는지 정확히 파악해야 합니다. 이러한 지식은 코드가 진화하기 전에 작성된 문서가 아니라 실제 코드에 대한 구조적 분석을 통해 얻을 수 있습니다.

미션 크리티컬 소프트웨어의 지질학적 층위

2026년에 스마트폰으로 항공편을 예약할 때, 여러분은 여러 개의 뚜렷한 지질학적 계층으로 이루어진 소프트웨어를 접하게 됩니다. 가장 표면에는 현대적인 인터페이스가 있고, 그 아래에는 API 계층이 있으며, 그 아래에는 PSS 거래 엔진이 있습니다. 이 PSS 거래 엔진은 1960년대 이후로 상당히 변화했지만, 설계 당시에는 적절했고 너무나 안정적이어서 버릴 수 없는 거래 의미론과 데이터 모델을 유지하고 있습니다.

항공 예약 시스템은 현대화의 실패가 아닙니다. 그것은 지난 60년간 엔지니어와 경영진들이 합리적인 결정을 내린 결과물입니다. 그들은 매번 시스템 교체를 제안할 때마다 잘못된 선택을 할 위험이 제대로 작동하는 시스템을 유지하는 비용보다 크다는 것을 이해했습니다. 이렇게 오랫동안 살아남은 시스템은 거래 하나하나, 항공편 하나하나, 예약 시즌마다 그 가치를 증명해 온 결과입니다.

현대화 팀이 얻어야 할 실질적인 교훈은 오래된 시스템을 절대 교체해서는 안 된다는 것이 아닙니다. 교체 결정을 내릴 때는 시스템의 내용, 시스템에 대한 의존성, 그리고 실제 변경 범위에 대한 완벽한 이해를 바탕으로 해야 하며, 복잡성을 측정하기 전에 낙관적인 추정에 의존해서는 안 된다는 것입니다. 항공 업계는 이 교훈을 값비싼 대가를 치르며 배웠습니다. 새로운 코드를 한 줄도 작성하기 전에 시스템의 구조에 대한 완벽한 이해를 제공하는 분석 도구가 바로 이러한 교훈을 비용 효율적으로 얻을 수 있도록 해주는 핵심 요소입니다.