항공 SI 신입 온보딩 가이드 ① – 항공 시스템을 처음 만났을 때 무엇부터 봐야 할까

SI 시스템통합 신입개발자 온보딩 항공시스템

✈️ 항공 SI 신입 온보딩 가이드 ①

항공 시스템을 처음 만났을 때 무엇부터 봐야 할까

이 글은 항공·UATM·SWIM 프로젝트에 처음 투입된 SI 개발자 / 설계자 / 시스템 엔지니어를 위한 입문 가이드다.

“왜 이렇게 복잡한가?”에 대한 답을 개념 → 구조 → 시스템 역할 순서로 정리한다.

1. 항공 시스템은 왜 이렇게 복잡할까?

항공을 처음 접하면 가장 먼저 드는 생각은 보통 이거다.

“비행 정보 하나 관리하는데 왜 시스템도 많고 규칙도 이렇게 많지?”

이유는 단순하다.

✦ 항공은 단일 조직의 문제가 아니다

항공은 다음 주체들이 동시에 같은 하늘을 사용한다.

각 주체는 책임 범위도, 시스템도, 목적도 다르다.

Image

Image

👉 항공 시스템의 본질은 **“하나의 정답을 공유해야 하는 분산 시스템”**이다.

2. 항공 시스템의 큰 틀 (ATM / UTM)

2.1 ATM (Air Traffic Management)

2.2 UTM / UATM

👉 UAVTM, UATM 프로젝트도 결국 ATM 구조를 확장한 것이다.

3. 비행계획(Flight Plan)은 왜 필요한가?

3.1 비행은 “자유 이동”이 아니다

그래서 등장한 것이 비행계획(Flight Plan, FPL) 이다.

4. 전통적인 FPL 방식 (과거의 항공 IT)

기존 항공 시스템은 메시지 중심이었다.

대표적인 메시지들

Image

Image

이 방식의 한계

👉 이 한계가 FF-ICE의 출발점이다.

5. FF-ICE란 무엇인가?

ICAO가 정의한 미래 항공 정보 관리 개념이다.

핵심 질문 하나로 요약하면

“비행을 메시지가 아니라 하나의 디지털 객체로 관리할 수 없을까?”

FF-ICE의 핵심 개념

개념설명
Single Flight Object하나의 비행 = 하나의 데이터
Lifecycle 관리생성 → 변경 → 종료
Revision변경 이력 관리
Trajectory4차원 비행 경로

Image

Image

6. SFPL, eFPL, FPL2012 — 헷갈리는 용어 정리

항공 SI 신입이 가장 많이 헷갈리는 부분이다.

용어한 줄 설명
eFPL항공사가 전자적으로 제출한 비행계획
FPL2012ICAO가 정의한 메시지 포맷
SFPL시스템이 내부적으로 관리하는 비행계획 객체

👉 메시지는 수단, 👉 SFPL이 실체(State)

7. SWIM은 “시스템”이 아니다

여기서 두 번째 큰 오해를 바로잡자.

SWIM의 정체

👉 항공 정보 공유를 위한 아키텍처·표준·원칙

EUROCONTROL이 실제 구현 규격을 주도

Image

Image

SWIM이 제공하는 것

8. 항공 SI 회사는 무엇을 만드는가

이제 SI 관점에서 역할이 보인다.

우리가 설계하는 핵심 시스템

모듈역할
FDPSFPL 생성·관리
ESI / CIS내부 ↔ SWIM 연계
Validation문법·업무 규칙 검증
Transformation메시지 ↔ 내부 모델
Monitoring연계 상태 감시

👉 그래서 요구사항에 항상 등장하는 키워드가 **“유효성, Revision, FF-ICE 규칙, SWIM 준수”**다.

관련 태그 글

← 생각하는 중등수학 ③ — 나머지는 실패한 계산일까? 생각하는 중등수학 ② — 음수는 왜 만들어졌을까? →
각주