본 보고서는 서버, 웹, 모바일 플랫폼에서 구동되고 클라우드 및 온프레미스(On-premise) 환경으로 제공되는 사설 무인항공기 교통관리 시스템(Private Unmanned Aircraft System Traffic Management, 이하 Private UTM)의 성공적인 개발과 사업화를 위한 종합적인 청사진을 제시한다. 이를 위해 시스템 아키텍처, 개발 조직, 서비스 조직에 대한 심층적인 분석과 전략적 고찰을 담는다.
본격적인 논의에 앞서, 본 보고서에서 사용되는 ‘UTM’이라는 약어는 항공 분야의 무인항공기 교통관리(Unmanned Aircraft System Traffic Management)를 지칭함을 명확히 한다. 이는 네트워크 보안 분야의 통합 위협 관리(Unified Threat Management) 1 또는 지리 정보 시스템의 범용 횡축 메르카토르 도법(Universal Transverse Mercator) 3과는 무관한 개념이다.
대한민국 국토교통부가 발표한 ‘한국형 도심항공교통(K-UAM) 로드맵’과 ‘K-UAM 운용개념서 1.0’은 본 Private UTM 사업의 방향성을 결정하는 가장 중요한 준거점이자 거대한 시장 기회를 예고하는 지표이다.5 K-UAM 로드맵에 따르면, 국내 UAM 시장은 초기(2025년~), 성장기(2030년~), 성숙기(2035년~)의 3단계에 걸쳐 발전하며, 교통관리체계는 점차 항공교통관제사의 역할을 축소하고 ‘UAM 교통관리서비스 제공자(PSU: Provider of Services for UAM)’ 중심으로 진화할 것으로 전망된다.7
따라서 본 Private UTM 시스템은 이 PSU의 역할을 직접 수행하거나, PSU 자격을 획득하려는 사업자(예: 통신사, 항공사 컨소시엄)에게 핵심 기술 솔루션을 제공하는 것을 목표로 명확하게 포지셔닝해야 한다. 이는 단순히 소프트웨어를 개발하여 판매하는 것을 넘어, 국토교통부의 인증을 받아야 하는 규제 산업 내 핵심 플레이어로서의 지위를 확보하는 것을 의미한다.8
이러한 포지셔닝은 막대한 시장 기회 위에 서 있다. 전 세계 상업용 드론 배송 시장은 2025년 29억 달러 규모에서 연평균 24.7% 성장하여 2029년에는 70억 2천만 달러에 이를 것으로 예측되며 9, 드론 물류 및 운송 시장 전체는 2025년부터 2030년까지 연평균 48.1%라는 경이적인 성장률을 보일 것으로 전망된다.10 이러한 폭발적인 시장 성장은 안전하고 효율적인 드론 운용을 보장하는 UTM 시스템에 대한 수요를 필연적으로 견인한다. 정부 주도의 공공 UTM 개발과 더불어, 물류, 에너지, 농업, 공공 안전 등 특정 산업 분야에 고도로 특화된 Private UTM 솔루션에 대한 거대한 시장이 형성될 것임은 자명하다.11
이러한 시장 환경을 분석할 때, 단순한 표면적 사실을 넘어 더 깊은 차원의 전략적 방향성을 도출할 수 있다. 첫째, Private UTM 사업자는 단순한 기술 공급자가 아닌, ‘규제 기술(RegTech)’ 기업이자 ‘항공 서비스 제공자’로서의 정체성을 가져야 한다. K-UAM 운용개념서는 PSU를 비행계획 승인, 교통흐름 관리 등 항공 안전과 직결된 핵심 서비스를 제공하는 주체로 명시하고 있다.8 이는 미국 연방항공청(FAA)이 정의한 UTM 생태계에서 UAS 서비스 공급자(USS: UAS Service Supplier)가 FAA의 규제 하에 서비스를 제공하는 모델 13이나, 유럽 항공안전청(EASA)이 U-space 서비스 제공자(USSP: U-space Service Provider)의 인증을 요구하는 것과 동일한 맥락이다.15 즉, Private UTM 서비스를 제공한다는 것은 국가 항공 당국의 엄격한 규제 프레임워크 안에서 항공 안전의 일부를 책임지는 역할을 수행함을 의미한다. 따라서 사업 초기 단계부터 법률 검토, 규제 준수 전략, 책임 보험 가입, 데이터 보안 및 주권 문제(특히 온프레미스 고객 대상)에 대한 심도 있는 계획이 기술 개발과 반드시 병행되어야 한다. 이는 제3부에서 논의할 조직 구성에 법률 및 정책 전문가의 포함이 필수적임을 시사한다.
둘째, 시장 진입 초기 성공 전략은 ‘수평적 확장’이 아닌 ‘수직적 심화’에 달려있다. 드론이 활용되는 시장은 물류, 농업, 감시 및 모니터링, 공공 안전 등 매우 다양하게 세분화되어 있으며 9, 각 산업 분야는 요구하는 비행 패턴(예: 매핑을 위한 그리드 비행 vs. 시설 점검을 위한 웨이포인트 비행) 16, 수집 데이터의 종류, 보안 수준, 규제 요건 등이 모두 상이하다. 글로벌 상용 UTM 시장을 선도하는 ANRA Technologies나 OneSky와 같은 기업들은 특정 산업 분야(국방, 에너지, 물류)나 특정 고객(정부 기관, 공항)에 특화된 맞춤형 솔루션을 제공하며 성공적으로 시장에 안착했다.17 따라서 모든 산업 분야를 아우르는 범용 UTM 시스템을 개발하려는 시도보다는, 초기에는 가장 큰 시장 잠재력과 명확한 요구사항을 가진 특정 수직 시장(Vertical Market), 예를 들어 국내 대형 물류 기업이나 에너지 인프라 관리 기업을 목표로 하여 해당 분야의 문제를 완벽하게 해결하는 ‘킬러 애플리케이션(Killer Application)’을 구축하는 것이 성공 확률을 극대화하는 전략이다. 이는 최소 기능 제품(MVP: Minimum Viable Product) 개발 전략과도 일맥상통한다.
성공적인 Private UTM 시스템은 국제적인 표준을 준수하면서도 국내 환경에 최적화된 서비스 포트폴리오를 갖추어야 한다. FAA와 EASA는 UTM 및 U-space의 핵심 서비스를 명확히 정의하고 있으며, 이는 우리가 개발할 시스템이 갖춰야 할 기능의 글로벌 기준을 제시한다.
EASA는 U-space 공역 내에서 제공되어야 할 서비스로 4가지 필수 서비스(Mandatory Services)와 2가지 추가 서비스(Additional Services)를 규정하고 있다.15
FAA의 UTM 운용개념서(CONOPS) v2.0 역시 USS가 제공해야 할 서비스로 운영 계획 지원, 의도 공유, 전략적/전술적 충돌 회피, 원격 식별(RID) 등을 포괄적으로 제시하며, 이는 EASA의 서비스 분류와 개념적으로 거의 동일하다.13
이러한 글로벌 표준은 국토교통부의 K-UAM 운용개념서에서 정의된 PSU의 역할과도 정확히 부합한다. PSU의 핵심 역할인 ‘운항 안전정보 공유 및 교통흐름 관리’는 교통 정보, 기상 정보, 규정 준수 모니터링 서비스를 포괄하는 개념이며, ‘비행계획 승인 및 항로이탈 모니터링’은 비행 승인 및 네트워크 식별 서비스와 직접적으로 연결된다.8
이 분석을 바탕으로, Private UTM 시스템의 서비스 포트폴리오는 다음과 같이 설계되어야 한다.
이러한 서비스 포트폴리오 설계는 중요한 전략적 함의를 내포한다. UTM 플랫폼의 진정한 장기적 가치는 관제 기능 자체가 아니라, 플랫폼에 축적되는 방대한 양의 데이터를 가공하여 제공하는 데이터 서비스에 있다. 핵심 UTM 서비스(비행 승인, 교통 정보 등)는 FAA와 EASA 모두 표준화된 프로토콜과 API를 지향하므로 14, 시간이 지남에 따라 기술이 상향 평준화되고 상품화(Commoditization)될 가능성이 높다. 경쟁사와의 진정한 차별점은 플랫폼을 통해 축적되는 데이터를 어떻게 새로운 가치로 창출하느냐에 달려있다. OneSky가 자사의 핵심 역량으로 단순 관제가 아닌 ‘분석(Analytics)’을 강조하며, 비행 동역학과 시뮬레이션 기술을 기반으로 한 고도의 의사결정 지원 도구를 제공하는 것이 바로 그 예이다.21
수집된 데이터(비행 경로, 기체 상태, 통신 품질, 배터리 소모 패턴, 장애물 정보 등)는 그 자체로 엄청난 자산이다. 이 데이터를 분석하여 보험사에게는 드론 운용 리스크 평가 모델을 제공하고, 도시 계획가에게는 미래 항공 교통량 분석 데이터를 판매하며, 드론 제조사에게는 실제 환경에서의 운용 데이터를 피드백하여 제품 개선을 돕는 등 다양한 B2B 데이터 비즈니스로 확장이 가능하다. 따라서 시스템 아키텍처 설계 초기부터 데이터의 수집, 저장, 분석, 그리고 서비스화를 염두에 둔 ‘데이터 중심 아키텍처(Data-centric Architecture)’를 구축하는 것이 사업의 장기적인 성공을 위한 핵심 전략이 되어야 한다.
| 구분 | K-UAM (PSU) | FAA UTM (USS) | EASA U-space (USSP) |
|---|---|---|---|
| 핵심 역할 | 운항 안전정보 공유, 교통흐름 관리, 비행계획 승인, 항로이탈 모니터링 8 | 운영 계획 지원, 의도 공유, 충돌 회피, RID, 영공 관리 13 | U-space 공역에 대한 안전하고 효율적인 접근 촉진 22 |
| 필수 서비스 | - 비행계획 승인 - 교통흐름 관리 - 항로이탈 모니터링 | - 운영 의도 공유 (Intent Sharing) - 원격 식별 (RID) - 전략적 충돌 해소 (Strategic Deconfliction) | - 네트워크 식별 (Network ID)- 지리인식 (Geo-awareness)- 비행 승인 (Flight Authorisation)- 교통 정보 (Traffic Info) 15 |
| 추가/권장 서비스 | (명시적 구분 없음) | - 수요/용량 균형 - 비정상 상황 관리 | - 기상 정보 (Weather Info)- 규정 준수 모니터링 (Conformance Monitoring) 15 |
| 데이터 교환 | PSU간 네트워크, 항공교통관제기관 연동 | FIMS를 통한 FAA 연동, USS 네트워크 | CISP를 통한 공통 정보 공유, ATS 제공자와 정보 교환 |
제1부에서 정의한 전략적 프레임워크와 서비스 모델을 성공적으로 구현하기 위해서는 유연하고 확장 가능하며 안정적인 기술 아키텍처가 뒷받침되어야 한다. 본 장에서는 클라우드와 온프레미스 환경을 모두 지원하는 거시적 아키텍처부터 개별 기능을 담당하는 마이크로서비스의 상세 설계, 대용량 실시간 데이터 처리 파이프라인, 그리고 시스템의 두뇌 역할을 하는 핵심 알고리즘과 데이터베이스 모델까지 심층적으로 고찰한다.
Private UTM 시스템은 다양한 고객의 요구사항을 충족시키기 위해 클라우드 기반의 서비스형 소프트웨어(SaaS) 모델과 고객사 내부에 직접 설치하는 온프레미스 모델을 모두 지원해야 한다. 클라우드 모델은 빠른 구축, 유연한 확장성, 낮은 초기 도입 비용을 장점으로 내세워 스타트업, 중소기업, 상용 드론 서비스 제공자에게 매력적인 선택지이다.27 반면, 온프레미스 모델은 데이터 주권(Data Sovereignty)과 최고 수준의 보안을 요구하는 정부, 국방, 원자력 발전소와 같은 핵심 인프라 관련 고객에게는 필수적인 요구사항이다.28 이 두 가지 상이한 배포 모델을 효율적으로 지원하기 위해서는 두 환경 간에 손쉽게 이식(Porting)이 가능한 아키텍처 설계가 무엇보다 중요하다.
이를 위한 최적의 해결책은 컨테이너 기반 아키텍처를 채택하는 것이다. 시스템을 구성하는 모든 마이크로서비스를 도커(Docker)와 같은 컨테이너 기술로 패키징하고, 이를 쿠버네티스(Kubernetes)를 통해 오케스트레이션하는 것을 표준 아키텍처로 삼아야 한다.29 이 접근법은 다음과 같은 명확한 이점을 제공한다.
특히 온프레미스 환경에 솔루션을 구축할 때는 클라우드 환경과는 다른 차원의 엄격한 관리가 요구된다. 첫째, 인프라 표준화 및 문서화가 필수적이다. 고객사에 배포될 서버 하드웨어 사양, 스토리지 구성, 네트워크 장비 및 레이아웃, 보안 정책, 소프트웨어 패치 관리 절차 등을 명확한 표준으로 정의하고 철저히 문서화해야 한다. 이는 예측 가능한 성능을 보장하고, 장애 발생 시 신속한 원인 분석과 해결을 가능하게 하는 기반이 된다.28 둘째,
선제적 모니터링 시스템을 함께 제공해야 한다. CPU, 메모리, 디스크 사용량, 네트워크 처리량 등 핵심 시스템 지표를 실시간으로 추적하고 임계치 기반의 경고 시스템을 구축하여, 서비스에 영향을 미치기 전에 잠재적인 문제를 감지하고 예방 조치를 취할 수 있어야 한다.28 마지막으로, UTM 시스템은 국가 핵심 인프라의 일부로 간주될 수 있으므로,
강화된 보안이 요구된다. 제로 트러스트(Zero Trust) 아키텍처 원칙에 입각하여 모든 통신을 암호화하고, 네트워크를 기능별로 분리하며, 엄격한 역할 기반 접근 제어(RBAC)를 적용해야 한다.30
이러한 요구사항들을 종합해 볼 때, ‘온프레미스’는 단순한 배포 옵션 중 하나가 아니라, 별도의 전략과 자원이 필요한 고부가가치 ‘제품 라인(Product Line)’으로 접근해야 한다는 결론에 이른다. 온프레미스 솔루션은 소프트웨어 라이선스 판매로 끝나지 않는다. 고객은 설치, 구성, 지속적인 유지보수, 기술 지원, 보안 패치, 시스템 업그레이드 등 전반적인 라이프사이클 관리를 포괄하는 서비스를 기대한다.28 이는 클라우드 SaaS 모델과는 전혀 다른 역량과 조직 구조를 필요로 한다. 고객의 복잡하고 이질적인 IT 환경을 깊이 이해하는 솔루션 아키텍트, 신속한 장애 해결을 위한 전문 기술지원팀, 그리고 필요시 현장에 파견될 수 있는 필드 엔지니어 인력이 필수적이다. 따라서 온프레미스 솔루션은 높은 가격의 초기 라이선스 비용과 함께, 연간 유지보수 계약(Annual Maintenance Contract), 맞춤형 구축을 위한 전문 서비스(Professional Services), 운영자 교육 서비스 등을 포함하는 포괄적인 ‘엔터프라이즈 솔루션’으로 패키징되어야 한다. 이는 Comcast가 제공하는 매니지드 UTM(Managed UTM) 서비스 모델과 유사한 접근 방식이다.32 결과적으로, 사업 계획 수립 단계부터 클라우드와 온프레미스 사업 모델을 위한 별도의 손익분석(P&L), 가격 정책, 조직 및 인력 계획을 수립하는 것이 현명하다.
UTM 시스템은 비행 계획, 실시간 관제, 데이터 분석, 사용자 관리, 기체 관리 등 다양한 기능적 요구사항의 복잡한 집합체이다. 이러한 시스템을 단일 애플리케이션(Monolithic Architecture)으로 개발할 경우, 작은 기능 하나를 수정하더라도 전체 시스템을 다시 테스트하고 배포해야 하므로 개발 속도가 저하되고, 특정 기능의 장애가 전체 시스템의 중단으로 이어질 위험이 크다. 따라서 각 기능을 독립적으로 개발, 배포, 확장할 수 있는 마이크로서비스 아키텍처(MSA: Microservice Architecture)를 채택하는 것이 기술적, 사업적 관점에서 모두 최적의 선택이다.29 MSA는 시스템의 복잡성을 효과적으로 관리하고, 팀의 자율성을 높여 개발 속도를 가속화하며, 장애의 영향을 개별 서비스로 국지화하여 시스템 전체의 안정성을 향상시킨다.
본 Private UTM 시스템을 위한 핵심 마이크로서비스는 다음과 같이 정의할 수 있다. (표 2 참조)
이러한 마이크로서비스들 간의 상호작용은 두 가지 방식으로 이루어진다. 즉각적인 응답이 필요한 동기식 통신(Synchronous Communication)의 경우, 서비스 간 직접 호출을 위해 RESTful API (HTTP/JSON)나 더 높은 성능을 제공하는 gRPC를 사용할 수 있다.29 반면, 서비스 간의 의존성을 낮추고 대규모 이벤트를 안정적으로 처리하기 위한 비동기식 통신(Asynchronous Communication)에는
Apache Kafka와 같은 메시지 큐/이벤트 버스를 활용한다.33 예를 들어, 비행 계획 서비스에서 비행이 승인되면 FlightPlanApproved라는 이벤트를 Kafka에 발행하고, 알림 서비스와 교통 서비스는 이 이벤트를 각각 구독(Subscribe)하여 파일럿에게 알림을 보내고 실시간 교통 정보에 해당 비행을 등록하는 작업을 독립적으로 수행한다.
MSA를 성공적으로 구현하기 위해서는 단순히 서비스를 분리하는 것만으로는 부족하다. 서비스 디스커버리(Service Discovery)와 API 게이트웨이는 MSA의 성패를 좌우하는 핵심적인 인프라 구성요소이다. MSA 환경에서는 수많은 서비스 인스턴스들이 부하에 따라 동적으로 생성되고 사라지기 때문에, 클라이언트나 다른 서비스가 특정 서비스의 IP 주소와 포트 번호를 정적으로 설정하여 호출하는 것은 불가능하다.33 이 문제를 해결하기 위해, 모든 마이크로서비스는 시작 시 자신의 현재 네트워크 위치(IP, 포트)를
서비스 레지스트리(Service Registry)(예: Eureka, Consul)라는 중앙 저장소에 등록해야 한다. 다른 서비스가 특정 서비스와 통신하고자 할 때는, 이 레지스트리를 통해 해당 서비스의 최신 위치 정보를 동적으로 조회하여 연결한다. 이것이 바로 서비스 디스커버리 메커니즘이다. API 게이트웨이는 이 서비스 디스커버리 메커니즘과 긴밀하게 통합되어, 외부로부터 요청을 받으면 서비스 레지스트리를 조회하여 현재 가용한 최적의 마이크로서비스 인스턴스로 요청을 지능적으로 라우팅하는 역할을 수행한다.33 만약 이 두 구성요소가 없다면, MSA는 서비스 간의 의존 관계를 관리할 수 없는 스파게티 구조로 전락하여 유지보수가 불가능해질 것이다. 따라서 아키텍처 설계 초기부터 서비스 디스커버리, API 게이트웨이, 그리고 이들을 지원하는 클라이언트 사이드 로드 밸런싱, 서킷 브레이커(Circuit Breaker)와 같은 회복탄력성 패턴을 포괄하는 ‘서비스 메시(Service Mesh)’(예: Istio, Linkerd)의 도입을 적극적으로 고려해야 한다.
| 마이크로서비스 | 주요 책임(Responsibilities) | 핵심 기술 스택 (예시) | 비고 |
|---|---|---|---|
| API Gateway | 외부 요청 라우팅, 인증/인가, 로깅 | Spring Cloud Gateway / Kong | MSA의 단일 진입점 |
| User Service | 사용자, 조직, 역할(RBAC) 관리 | Java, Spring Boot, PostgreSQL | 인증/인가의 기반 |
| Drone Fleet Service | 기체, 배터리, 정비 이력, 운용 준비태세 관리 | Java, Spring Boot, PostgreSQL | 운용 안전성의 핵심 |
| Flight Plan Service | 비행 계획 생성, 검증, 승인 워크플로우 | Java, Spring Boot, PostgreSQL, PostGIS | A* 알고리즘 통합 |
| Airspace Service | 정적/동적 공역 정보 제공 | Go, PostgreSQL (PostGIS) | 지리인식 서비스의 기반 |
| Traffic Service | 실시간 교통 정보 통합 및 제공 | Go, Redis | ADS-B, Remote ID 데이터 처리 |
| Telemetry Ingestion | 대용량 텔레메트리 데이터 수집 | Go, MQTT, Kafka Connect | 높은 동시성 처리 요구 |
| Real-time Processing | 실시간 비행 상태 모니터링, 위험 감지 | Java, Kafka Streams / Flink | 강화학습 모델 통합 |
| Notification Service | 이벤트 기반 알림 발송 | Go, Kafka, Firebase/APNS | 비동기 처리 |
| Data Analytics Service | 비행 데이터 분석, 리포팅 | Python, Spark, Jupyter, Pandas | 데이터 기반 부가 가치 창출 |
Private UTM 시스템의 심장부는 수천, 수만 대의 드론이 초 단위로 쏟아내는 방대한 텔레메트리 데이터(위치, 고도, 속도, 배터리 상태, 센서 값 등)를 지연 없이 수집, 처리, 분석하여 유의미한 정보로 변환하는 능력에 있다. 이 도전 과제를 해결하기 위해, 확장 가능하고 내결함성(Fault-tolerant)이 뛰어난 실시간 데이터 파이프라인 구축이 필수적이다.
이러한 요구사항을 충족시키기 위한 아키텍처의 핵심으로 Apache Kafka를 제안한다. Kafka는 분산 스트리밍 플랫폼으로서, 초당 수백만 건의 이벤트를 처리할 수 있는 높은 처리량과 데이터 유실을 방지하는 내결함성을 제공하여 대규모 실시간 데이터 처리의 사실상 표준(De facto standard)으로 자리 잡았다.34 Kafka를 중심으로 한 데이터 파이프라인은 다음과 같이 구성된다.
이러한 복잡한 데이터 파이프라인을 구성하는 마이크로서비스들을 개발할 때, 단일 프로그래밍 언어에 얽매일 필요가 없다. 각 서비스의 특성에 가장 적합한 기술을 선택하는 폴리글랏 아키텍처(Polyglot Architecture)를 지향해야 한다. Go와 Java는 이 시스템의 핵심 백엔드 언어로서 각각 뚜렷한 강점을 가진다.
벤치마크 자료에 따르면, Go는 Java에 비해 컴파일 속도가 월등히 빠르고, 실행 파일의 크기가 작으며, 적은 메모리를 사용한다. 특히, 운영체제 스레드보다 훨씬 가벼운 ‘고루틴(Goroutine)’을 통한 동시성 처리 모델은 수많은 네트워크 연결을 동시에 처리해야 하는 I/O 중심(I/O-bound) 작업에서 탁월한 성능을 발휘한다.38 반면, Java는 수십 년간 발전해 온 자바 가상 머신(JVM)의 강력한 최적화 기술(예: JIT 컴파일러) 덕분에, 장시간 실행되는 복잡한 비즈니스 로직이나 대규모 데이터 처리와 같은 CPU 중심(CPU-bound) 작업에서 Go를 능가하는 성능을 보여주기도 한다.40
따라서 다음과 같은 기술 스택 적용 전략을 제안한다.
텔레메트리 수집 서비스, API 게이트웨이, 알림 서비스와 같이 수만 개의 드론 커넥션을 동시에 처리해야 하거나, 높은 동시성과 낮은 메모리 사용량이 중요한 I/O 중심의 마이크로서비스 개발에 최적이다.비행 계획 서비스, 데이터 분석 서비스와 같이 복잡한 비즈니스 로직, 데이터베이스 트랜잭션 관리, 방대한 외부 라이브러리 및 프레임워크 생태계 활용이 중요한 마이크로서비스 개발에 적합하다. 검증된 안정성과 높은 개발 생산성을 제공한다.이처럼 정교하게 설계된 데이터 파이프라인이라도 시간이 지남에 따라 불안정해질 수 있는 숨겨진 위험이 있다. 바로 데이터 구조의 변경 문제이다. 여기서 스키마 레지스트리(Schema Registry)는 데이터 파이프라인의 장기적인 안정성을 보장하는 숨은 영웅과 같은 역할을 한다. 수많은 마이크로서비스가 Kafka를 통해 비동기적으로 데이터를 주고받는 환경에서, 한 서비스가 데이터의 ‘구조(Schema)’를 사전 협의 없이 변경하면(예: 텔레메트리 데이터에 새로운 필드를 추가하거나 기존 필드의 데이터 타입을 변경), 이 데이터를 소비하는 다른 모든 서비스에서 심각한 데이터 파싱 오류가 발생하며 시스템 전체가 마비될 수 있다. 스키마 레지스트리는 모든 데이터의 스키마를 중앙에서 버전별로 관리하는 시스템이다.34 데이터를 발행하는 프로듀서는 데이터를 보내기 전에 먼저 스키마 레지스트리에 해당 데이터의 스키마를 등록하고, 실제 데이터와 함께 스키마의 고유 ID를 Kafka로 전송한다. 데이터를 구독하는 컨슈머는 메시지를 받으면 이 스키마 ID를 이용해 스키마 레지스트리에서 정확한 버전의 스키마를 조회하여 데이터를 안전하게 역직렬화(Deserialize)한다. 더 중요한 것은, 스키마 레지스트리가 하위 호환성 규칙(Backward Compatibility)을 강제하여, 기존 컨슈머 시스템을 망가뜨릴 수 있는 스키마 변경을 원천적으로 차단한다는 점이다. 결과적으로, 스키마 레지스트리를 도입하는 것은 개발팀 간의 불필요한 조율 비용을 줄이고 데이터 파이프라인의 예기치 않은 붕괴를 막아, 장기적으로 유지보수 가능하고 신뢰성 높은 데이터 아키텍처를 구축하기 위한 필수적인 투자이다.
Private UTM 시스템의 가치는 거시적인 아키텍처뿐만 아니라, 그 안에서 동작하는 핵심 기능들의 정교함과 신뢰성에 의해 결정된다. 본 절에서는 비행 계획 관리, 동적 경로 계획 등 시스템의 두뇌에 해당하는 기능들의 구현 방안을 심층적으로 분석한다.
FAA 운용개념서(CONOPS)에 명시된 바와 같이, 비행 의도(Intent) 정보의 공유는 UTM의 가장 기본적인 전제 조건이다.13 따라서 비행 계획을 표현하는 데이터 모델은 명확하고 포괄적이어야 한다. 이 데이터 모델은 최소한 다음의 정보들을 포함해야 한다.
flight_plan_id (고유 식별자), operator_id (운용 주체), drone_id (사용 기체), pilot_id (담당 조종사)비행 계획이 제출되고 승인되는 과정은 여러 마이크로서비스 간의 복잡한 상호작용을 수반한다. 이 과정을 명확히 정의하기 위해 UML 시퀀스 다이어그램(UML Sequence Diagram)을 활용하여 상호작용 흐름을 시각화할 수 있다.42 승인 절차의 흐름은 다음과 같이 요약될 수 있다.
submitFlightPlan(flightPlanData).createFlightPlan(flightPlanData).checkAirspaceRestrictions(operationVolume).checkStrategicConflicts(operationVolume).notifyAdmin(flightPlanId).approveFlightPlan(flightPlanId).FlightPlanApproved 이벤트를 발행한다.안전하고 효율적인 비행을 위해서는 정적 및 동적 환경을 모두 고려하는 지능적인 경로 계획 알고리즘이 필수적이다.
A* (A-Star) 알고리즘 (정적/사전 경로 계획): 비행 계획 수립 단계에서 고정된 장애물(건물, 지형)과 비행 제한 구역을 피해 출발지에서 목적지까지 최적의 경로를 찾는 데 매우 효과적인 알고리즘이다.45 A* 알고리즘은 각 노드(위치)를 평가할 때 다음의 비용 함수를 사용한다.
f(n)=g(n)+h(n)
여기서 n은 평가 대상 노드, $g(n)$은 출발 노드부터 현재 노드 n까지의 실제 누적 비용(예: 이동 거리, 에너지 소모량), $h(n)$은 현재 노드 n에서 최종 목적지까지의 예상 비용을 의미하는 휴리스틱(Heuristic) 함수(예: 직선 거리)이다. A*는 이 f(n) 값이 가장 작은 노드를 우선적으로 탐색함으로써 최적 경로를 효율적으로 찾아낸다. 더 나아가, 인구 밀집도나 지상 위험 요소를 포함하는 리스크 맵(Risk Map)을 비용 함수에 통합하여, 안전 제약 조건을 만족하면서 최단 거리를 찾는 제약 최단 경로 문제(Constrained Shortest Path Problem, CSP)로 확장하여 적용할 수 있다.47
강화학습 (Reinforcement Learning) (동적/실시간 경로 재설정): 실제 비행 중에는 예측 불가능한 상황이 발생할 수 있다. 갑작스러운 악천후, 긴급 항공기의 출현으로 인한 공역의 동적 폐쇄, 예기치 않은 다른 드론의 등장 등 정적 경로 계획만으로는 대응할 수 없는 상황에 대처하기 위해 강화학습이 강력한 해법을 제공한다.
이 두 가지 알고리즘은 상호 배타적인 것이 아니라, 상호 보완적으로 사용될 때 가장 큰 시너지를 낼 수 있다. 최적의 경로 계획 시스템은 정적 계획을 위한 A*와 동적 대응을 위한 강화학습의 하이브리드(Hybrid) 접근 방식을 요구한다. 이는 여러 연구에서도 그 효율성이 입증된 바 있다.46 구체적인 구현 시나리오는 다음과 같다.
이러한 하이브리드 접근법은 A*의 최적성과 강화학습의 적응성을 결합하여, 계산 효율성과 동적 환경 대응 능력을 모두 확보하는 가장 현실적이고 강력한 솔루션이다. 시스템 아키텍처는 이러한 하이브리드 경로 계획 모듈을 원활히 지원하도록 설계되어야 한다.
안전하고 효율적인 드론 운용을 위해서는 비행 데이터와 기체 정보를 체계적으로 관리하는 것이 무엇보다 중요하다. 수집된 데이터는 안전 감사, 성능 개선 분석, 규제 준수 증빙 등 다양한 목적으로 활용되는 핵심 자산이다.50 이러한 다양한 데이터의 특성을 효율적으로 관리하기 위해, 단일 종류의 데이터베이스가 아닌 데이터의 성격에 맞는 여러 종류의 데이터베이스를 조합하여 사용하는
폴리글랏 퍼시스턴스(Polyglot Persistence) 전략을 채택해야 한다.
Users (user_id, name, email, password_hash, role)Organizations (org_id, name, address)Drones (drone_id, org_id, model, serial_number, registration_id, firmware_version, last_maintenance_date)Batteries (battery_id, drone_id, model, serial_number, cycle_count, last_charged_date, capacity_mah)Pilots (pilot_id, user_id, certification_number, last_flight_date, total_flight_hours)FlightPlans (plan_id, pilot_id, drone_id, start_time, end_time, status, route_geom)Missions (mission_id, plan_id, objective, status, payload_data_link)telemetry
drone_id, mission_id, pilot_idlatitude, longitude, altitude, ground_speed, vertical_speed, battery_voltage, rssi (수신 신호 강도)이러한 데이터베이스 설계를 기반으로 한 기체 관리 시스템은 단순히 자산 목록을 나열하는 수준을 넘어서야 한다. 상업적 드론 운용에서의 기체 관리(Fleet Management)는 단순한 자산 목록이 아니라, 임무 수행 직전의 ‘운용 준비태세(Operational Readiness)’를 종합적으로 보장하는 지능형 시스템이어야 한다. 상업적 드론 운용에서 가장 중요한 것 중 하나는, 고객이 원하는 바로 그 시점에 드론이 안전하게 임무를 수행할 수 있는 최상의 상태를 유지하는 것이다.50
이는 단순히 드론의 목록을 관리하는 것을 넘어, 배터리의 충전 상태 및 노후도(수명 주기), 예정된 정비 일정, 설치된 펌웨어의 버전, 그리고 임무에 배정될 조종사의 자격 및 최근 비행 기록 등 복합적인 요소를 실시간으로 종합 분석하여 판단해야 함을 의미한다. 예를 들어, 시스템에서 특정 임무에 드론을 배정하려고 할 때, 드론 기단 서비스는 자동으로 다음과 같은 ‘준비태세 확인(Readiness Check)’ 로직을 수행해야 한다.
이러한 지능적인 ‘준비태세 확인’ 기능은 드론 기단 서비스의 핵심 로직이 되어야 하며, 앞서 설계한 데이터베이스 스키마는 이 로직을 지원하기 위한 모든 정보를 담고 있어야 한다. 이 기능은 인적 오류로 인한 안전사고를 예방하고, 비효율적인 수동 확인 절차를 자동화하여 전체적인 운영 효율성을 극대화하는 결정적인 역할을 수행할 것이다.
성공적인 Private UTM 시스템의 구축과 운영은 탁월한 기술 아키텍처만으로는 불가능하다. 빠르게 변화하는 시장 요구에 민첩하게 대응하고 혁신을 주도할 수 있는 개발 조직, 그리고 24시간 365일 무중단 서비스를 보장하며 고객의 신뢰를 얻을 수 있는 서비스 운영 조직의 설계가 병행되어야 한다.
전통적인 폭포수 모델이나 상명하달식의 경직된 조직 구조는 복잡하고 빠르게 진화하는 UTM 기술과 시장 요구에 효과적으로 대응하기 어렵다. 대신, 팀의 자율성과 팀 간의 유기적인 협력을 극대화하는 스포티파이(Spotify) 모델을 본 프로젝트의 개발 조직 프레임워크로 채택하는 것을 제안한다.52 이 모델은 대규모 조직이 애자일 원칙을 효과적으로 확장할 수 있도록 돕는 검증된 접근법이다.
스포티파이 모델의 핵심 구성 요소는 다음과 같다.53
이 모델에 따라, Private UTM 개발 조직은 다음과 같은 기능별 스쿼드로 구성될 수 있다. (표 3 참조)
그러나 스포티파이 모델을 성공적으로 적용하기 위해서는 한 가지 중요한 전제 조건을 이해해야 한다. 바로 ‘자율성(Autonomy)’과 ‘정렬(Alignment)’ 사이의 균형을 맞추기 위한 강력한 ‘아키텍처 거버넌스’가 필수적이라는 점이다. 스포티파이 모델의 가장 큰 장점인 스쿼드의 자율성은 동시에 가장 큰 위험 요소가 될 수 있다. 각 스쿼드가 완전히 독립적으로 기술을 선택하고 아키텍처를 변경한다면, 전체 시스템은 일관성을 잃고 파편화되어 결국에는 관리 불가능한 상태에 이를 수 있다.52 특히 UTM 시스템은 항공 안전과 직결된 고신뢰성 시스템(High-reliability system)이므로, 개별 스쿼드의 자유로운 결정이 시스템 전체의 안정성과 안전성을 저해하는 일은 절대로 용납될 수 없다.
이 문제를 해결하기 위해, 스포티파이는 ‘트리오(Trio)’라는 개념(Tribe Lead, Product Lead, Design Lead)을 도입하여 리더십 레벨에서의 정렬을 추구했다.53 본 프로젝트에서는 이를 한 단계 더 발전시켜,
‘아키텍처 위원회(Architecture Committee)’ 또는 ‘수석 엔지니어 길드(Principal Engineer Guild)’와 같은 공식적인 기술 거버넌스 기구를 설립하고 강력한 권한을 부여해야 한다. 이 조직은 여러 스쿼드에 영향을 미치는 주요 기술적 결정(예: 새로운 데이터베이스 기술 도입, 서비스 간 통신 프로토콜 변경, 공통 라이브러리 업데이트)을 사전에 검토하고 승인하는 역할을 수행한다. 또한, 전체 시스템의 기술 비전과 아키텍처 원칙을 수립하고 이를 모든 개발자에게 지속적으로 전파하여, 스쿼드들이 자율적으로 움직이면서도 큰 그림에서 벗어나지 않도록 조율해야 한다. 결론적으로, 스쿼드에게는 ‘어떻게(How)’ 구현할지에 대한 자율성을 최대한 보장하되, ‘무엇을(What)’ 만들고 어떤 ‘기술적 제약(Constraints)’ 하에서 만들어야 하는지에 대한 명확한 가이드라인은 중앙에서 강력하게 제시해야 한다. 이것이야말로 ‘느슨한 결합, 강한 응집(Loose Coupling, High Cohesion)’이라는 마이크로서비스의 핵심 원칙을 조직과 아키텍처 양쪽에서 성공적으로 구현하는 길이다.
| 트라이브 (Tribe) | 스쿼드 (Squad) | 미션 (Mission) | 챕터 (Chapter) |
|---|---|---|---|
| Air Traffic Core | Flight Operations Squad | 세계 최고 수준의 안전하고 효율적인 비행 계획 및 공역 관리 기능 제공 | Backend(Java), QA, DevOps, Product Owner |
| Air Traffic Core | Data Platform Squad | 초당 수백만 건의 드론 데이터를 실시간으로 처리하고 가치 있는 통찰력 제공 | Backend(Go, Java), Data Eng., SRE, QA |
| Application | Web Frontend Squad | 운영자와 관리자에게 최고의 사용자 경험을 제공하는 웹 애플리케이션 구축 | Frontend(React), UI/UX Design, QA |
| Application | Mobile Squad | 조종사가 현장에서 가장 신뢰할 수 있는 모바일 비행 통제 도구 개발 | Mobile(iOS/Swift, Android/Kotlin), UI/UX Design |
| Platform | Platform Engineering Squad | 모든 개발 스쿼드가 가장 빠르고 안정적으로 개발할 수 있는 인프라와 도구 제공 | DevOps, SRE, Security |
UTM 서비스는 항공기 운항과 직접적으로 연결되므로, 단 1분의 장애도 허용되지 않는 미션 크리티컬(Mission-critical) 서비스이다. 혁신적인 기능을 빠르게 개발하는 것만큼이나, 개발된 서비스를 24시간 365일 안정적으로 운영하고 고객의 신뢰를 확보하는 것이 사업의 성패를 좌우한다. 이를 위해 다음과 같은 전문화된 서비스 운영 조직의 구성이 필수적이다. (표 4 참조)
이러한 운영 조직을 설계할 때, 클라우드와 온프레미스 고객 지원의 근본적인 차이점을 인지하는 것이 매우 중요하다. 온프레미스 고객 지원은 클라우드 환경과는 본질적으로 다른 접근 방식과 고도의 전문성을 요구한다. 클라우드(SaaS) 고객 지원은 우리가 완벽하게 통제하는 표준화된 환경 위에서 이루어지므로, 문제 분석과 해결의 주도권이 우리에게 있다. 그러나 온프레미스 고객 지원은 우리가 통제할 수 없는, 고객사 각각의 매우 다양하고 복잡한 IT 환경(상이한 네트워크 장비, 방화벽 정책, 서버 하드웨어, 운영체제 버전 등) 위에서 발생한 문제를 해결해야 하는 과제를 안고 있다.28
이는 단순히 우리 소프트웨어에 대한 깊은 지식만으로는 부족하며, 네트워킹, 시스템 관리, 데이터베이스, 가상화, 보안 등 광범위한 인프라 전반에 대한 해박한 지식을 갖춘 엔지니어를 필요로 함을 의미한다. 또한, 고객사의 엄격한 보안 정책으로 인해 원격 접속이 불가능한 경우가 많으므로, 안전한 원격 지원 솔루션을 사전에 마련하거나, 필요시 현장에 직접 엔지니어를 신속하게 파견할 수 있는 체계와 인력을 갖추어야 한다. 따라서 서비스 운영 조직 내에 일반 기술 지원팀과는 별도로, 고도의 인프라 전문성을 갖춘 ‘엔터프라이즈 지원팀(Enterprise Support Team)’을 구성하고, 이들에게는 더 높은 수준의 기술 교육과 시스템 접근 권한을 부여하는 것이 바람직하다. 이들의 전문성이야말로 고가의 온프레미스 솔루션 계약을 유지하고, 고객과의 신뢰를 바탕으로 계약을 확장하는 핵심 동력이 될 것이다.
| 팀 (Team) | 주요 역할 (Role) | 핵심 책임 (Responsibilities) | 주요 성공 지표 (KPIs) |
|---|---|---|---|
| 기술 지원팀 | 고객 문제 해결의 최전선 | - SLA 기반 티켓 처리 - 기술 문서 및 지식 베이스 관리 - 고객 피드백 수집 및 제품팀 전달 | - 최초 응답 시간 (FRT) - 문제 해결 시간 (TTR) - 고객 만족도 (CSAT) |
| SRE팀 | 서비스의 수호자 | - 99.99% 가용성 보장 - 선제적 모니터링 및 알람 - 장애 대응 자동화(Runbook) - CI/CD 파이프라인 운영 | - 서비스 가용성(Uptime) - 서비스 수준 목표(SLO) 달성률 - 평균 장애 감지 시간(MTTD) - 평균 장애 복구 시간(MTTR) |
| 보안 운영 센터 (SOC) | 시스템의 방패 | - 24/7 보안 위협 탐지 및 대응 - 취약점 분석 및 패치 관리 - 보안 감사 및 규제 준수 지원 | - 평균 위협 탐지 시간(MTTD) - 평균 위협 대응 시간(MTTR) - 보안 사고 발생 건수 |
| 규제 준수팀 | 규제 환경의 네비게이터 | - PSU/USS/USSP 인증 획득 및 유지 - 항공 당국과의 공식 소통 - 규제 변경 사항 전파 및 내재화 | - 규제 인증 획득/유지 성공률 - 감사 지적 사항 ‘0’ |
본 보고서는 서버, 웹, 모바일에서 구동되는 Private UTM 시스템을 클라우드와 온프레미스 환경으로 제공하기 위한 포괄적인 기술 및 조직 전략을 제시했다. 분석 결과를 종합하여, 성공적인 사업 추진을 위한 핵심 성공 요인과 단계별 사업 확장 로드맵을 다음과 같이 권고한다.
성공적인 Private UTM 사업은 다음 세 가지 핵심 축의 유기적인 결합을 통해 달성될 수 있다.
이상의 전략, 아키텍처, 조직 원칙을 바탕으로 다음과 같은 3단계 사업 확장 로드맵을 제안한다.
이 로드맵은 불확실성이 높은 신규 시장에 진입하면서 위험을 최소화하고, 단계적으로 역량을 강화하며 지속 가능한 성장을 이루기 위한 전략적 경로를 제시한다. 성공적인 실행을 위해서는 각 단계별 목표에 맞는 자원 배분과 조직 역량 강화가 반드시 수반되어야 할 것이다.
| Drone Logistics and Transportation Market Analysis Report 2025-2030 | Same-day Delivery Expectations Fuel Growth As Alternatives for Last-mile Logistics Takes Off - ResearchAndMarkets.com - Business Wire, accessed August 13, 2025, https://www.businesswire.com/news/home/20250811859522/en/Drone-Logistics-and-Transportation-Market-Analysis-Report-2025-2030-Same-day-Delivery-Expectations-Fuel-Growth-As-Alternatives-for-Last-mile-Logistics-Takes-Off—ResearchAndMarkets.com |
| UTM Market Size & Share Insights and Trends | 2025-2030, accessed August 13, 2025, https://www.nextmsc.com/report/utm-market-ad3043 |
| Unmanned Aircraft System Traffic Management (UTM) | Federal Aviation Administration, accessed August 13, 2025, https://www.faa.gov/uas/advanced_operations/traffic_management |
| Regulation 2021/664 U-space Regulatory Framework | SKYbrary Aviation Safety, accessed August 13, 2025, https://skybrary.aero/articles/regulation-2021664-u-space-regulatory-framework |
| Our Work | OneSky, accessed August 13, 2025, https://www.onesky.xyz/our-work |
| U-Space Service Providers | AESA-Agencia Estatal de Seguridad Aérea - MTMS, accessed August 13, 2025, https://www.seguridadaerea.gob.es/en/ambitos/navegacion-aerea/proveedores-de-servicios-u-space |
| What is Unified Threat Management (UTM)? | Glossary | HPE, accessed August 13, 2025, https://www.hpe.com/us/en/what-is/unified-threat-management.html |