✈️ 항공 SI 신입 온보딩 가이드 ①
항공 시스템을 처음 만났을 때 무엇부터 봐야 할까
이 글은 항공·UATM·SWIM 프로젝트에 처음 투입된 SI 개발자 / 설계자 / 시스템 엔지니어를 위한 입문 가이드다.
“왜 이렇게 복잡한가?”에 대한 답을 개념 → 구조 → 시스템 역할 순서로 정리한다.
1. 항공 시스템은 왜 이렇게 복잡할까?
항공을 처음 접하면 가장 먼저 드는 생각은 보통 이거다.
“비행 정보 하나 관리하는데 왜 시스템도 많고 규칙도 이렇게 많지?”
이유는 단순하다.
✦ 항공은 단일 조직의 문제가 아니다
항공은 다음 주체들이 동시에 같은 하늘을 사용한다.
- 항공사 (AOC)
- 관제기관 (ATC)
- 공항
- 국가별 항공청
- 군
- 드론/도심항공(UTM/UATM)
각 주체는 책임 범위도, 시스템도, 목적도 다르다.
👉 항공 시스템의 본질은 **“하나의 정답을 공유해야 하는 분산 시스템”**이다.
2. 항공 시스템의 큰 틀 (ATM / UTM)
2.1 ATM (Air Traffic Management)
- 유인 항공기(여객기, 화물기) 중심
- 국가 관제기관이 주도
- 국제 표준 기반 운영
2.2 UTM / UATM
- 무인기·드론·도심항공
- 기존 ATM과 공역·정보를 공유
- 미래 항공의 확장 영역
👉 UAVTM, UATM 프로젝트도 결국 ATM 구조를 확장한 것이다.
3. 비행계획(Flight Plan)은 왜 필요한가?
3.1 비행은 “자유 이동”이 아니다
- 하늘은 공유 자원
- 충돌 방지 필요
- 공역 제한 존재
- 국가 간 비행은 사전 협의 필수
그래서 등장한 것이 비행계획(Flight Plan, FPL) 이다.
4. 전통적인 FPL 방식 (과거의 항공 IT)
기존 항공 시스템은 메시지 중심이었다.
대표적인 메시지들
- FPL : 비행계획 제출
- CHG : 변경
- DLA : 지연
- CNL : 취소
이 방식의 한계
- 최신 상태가 무엇인지 알기 어려움
- 메시지 순서가 꼬이면 복구 어려움
- 시스템마다 서로 다른 상태 보유
👉 이 한계가 FF-ICE의 출발점이다.
5. FF-ICE란 무엇인가?
ICAO가 정의한 미래 항공 정보 관리 개념이다.
핵심 질문 하나로 요약하면
“비행을 메시지가 아니라 하나의 디지털 객체로 관리할 수 없을까?”
FF-ICE의 핵심 개념
| 개념 | 설명 |
|---|---|
| Single Flight Object | 하나의 비행 = 하나의 데이터 |
| Lifecycle 관리 | 생성 → 변경 → 종료 |
| Revision | 변경 이력 관리 |
| Trajectory | 4차원 비행 경로 |
6. SFPL, eFPL, FPL2012 — 헷갈리는 용어 정리
항공 SI 신입이 가장 많이 헷갈리는 부분이다.
| 용어 | 한 줄 설명 |
|---|---|
| eFPL | 항공사가 전자적으로 제출한 비행계획 |
| FPL2012 | ICAO가 정의한 메시지 포맷 |
| SFPL | 시스템이 내부적으로 관리하는 비행계획 객체 |
👉 메시지는 수단, 👉 SFPL이 실체(State)
7. SWIM은 “시스템”이 아니다
여기서 두 번째 큰 오해를 바로잡자.
SWIM의 정체
- 서버 ❌
- 단일 플랫폼 ❌
- 특정 제품 ❌
👉 항공 정보 공유를 위한 아키텍처·표준·원칙
EUROCONTROL이 실제 구현 규격을 주도
SWIM이 제공하는 것
- 서비스 발견(Discovery)
- Publish / Subscribe
- Request / Reply
- 표준 정보 모델(AIXM, FIXM, WXXM)
- 보안·감사 체계
8. 항공 SI 회사는 무엇을 만드는가
이제 SI 관점에서 역할이 보인다.
우리가 설계하는 핵심 시스템
| 모듈 | 역할 |
|---|---|
| FDP | SFPL 생성·관리 |
| ESI / CIS | 내부 ↔ SWIM 연계 |
| Validation | 문법·업무 규칙 검증 |
| Transformation | 메시지 ↔ 내부 모델 |
| Monitoring | 연계 상태 감시 |
👉 그래서 요구사항에 항상 등장하는 키워드가 **“유효성, Revision, FF-ICE 규칙, SWIM 준수”**다.