SWIM은 왜 쓰는 걸까? — 항공 시스템이 ‘연결’되는 진짜 이유
SWIM은 왜 쓰는 걸까?
이전 글에서 나는 항공 SI 프로젝트에 처음 들어오면서
“SWIM이라는 걸 계속 듣는데 정확히 뭔지 모르겠다”는 상태였다.
👉 (이전 글 참고) 항공 SI 온보딩 이야기 1편
문제는 ‘연결’이었다
항공 시스템은 생각보다 단순하지 않다.
- 관제 시스템 (ATC)
- 비행계획 시스템 (FDP)
- 공항 시스템 (AODB)
- 항공사 시스템
- 기상 시스템
👉 이 모든 시스템이 각자 따로 존재한다
문제는 여기서 발생한다.
❗ 서로 데이터 형식도 다르고
❗ 통신 방식도 다르고
❗ 연결 방식도 제각각이다
SWIM 없이 연결하면 어떻게 될까?
예전 방식은 단순했다.
- 시스템 A → 시스템 B 직접 연결
- 시스템 B → 시스템 C 또 직접 연결
결과는?
👉 지옥의 인터페이스 구조
- N:N 연결 구조
- 유지보수 난이도 폭발
- 장애 발생 시 원인 추적 어려움
그래서 등장한 게 SWIM이다
SWIM(System Wide Information Management)은
한마디로 정리하면 이거다.
“항공 시스템 간 데이터를 표준 방식으로 공유하는 플랫폼”
조금 더 쉽게 말하면:
👉 항공판 API + 메시지 플랫폼
SWIM의 핵심 개념 3가지
1. 표준화 (Standardization)
- 데이터 형식 통일 (XML / JSON)
- 인터페이스 정의 (Service)
👉 “이 데이터는 이렇게 생겼다”를 모두가 공유
2. 서비스화 (Service-Oriented)
기존:
- 시스템 간 직접 연결
SWIM:
- 서비스 등록 → 필요한 시스템이 호출
👉 REST API / MQ 기반 구조
3. 느슨한 결합 (Loose Coupling)
이게 핵심이다.
- 시스템 A는 B를 몰라도 된다
- 그냥 “서비스”만 알면 된다
👉 변경 영향 최소화
EUROCONTROL 기준으로 보면
유럽 SWIM 구조는 더 명확하다.
- REG (Registry) → 서비스 등록/조회
- IE (Information Exchange) → 데이터 전달
- ESI → 외부 시스템 연결
👉 즉,
- REG = API 문서 + 서비스 카탈로그
- IE = 메시지 브로커 (RabbitMQ 느낌)
그럼 결국 뭐가 좋아지는가?
정리하면 이거다.
✔ 개발자 입장
- 인터페이스 명확
- 재사용 가능
- 유지보수 쉬움
✔ 운영 입장
- 장애 추적 가능
- 모니터링 용이
- 확장성 확보
✔ 조직 입장
- 표준 기반 협업 가능
- 외부 기관 연동 쉬움
그런데 여기서 중요한 포인트
SWIM은 단순 기술이 아니다.
👉 “조직 간 데이터 공유 방식” 자체를 바꾸는 개념이다
그래서 도입이 어려운 거다.