Private UTM 시스템 개발 및 서비스 제공 전략

1. 전략적 프레임워크 및 서비스 모델

본 안내서는 서버, 웹, 모바일 플랫폼에서 구동되고 클라우드 및 온프레미스(On-premise) 환경으로 제공되는 사설 무인항공기 교통관리 시스템(Private Unmanned Aircraft System Traffic Management, 이하 Private UTM)의 성공적인 개발과 사업화를 위한 종합적인 청사진을 제시한다. 이를 위해 시스템 아키텍처, 개발 조직, 서비스 조직에 대한 심층적인 분석과 전략적 고찰을 담는다.

1.1 Private UTM의 개념과 시장 기회: K-UAM 생태계 내 포지셔닝

본격적인 논의에 앞서, 본 안내서에서 사용되는 ’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) 개발 전략과도 일맥상통한다.

1.2 핵심 서비스 포트폴리오 정의: 글로벌 표준과 K-UAM의 조화

성공적인 Private UTM 시스템은 국제적인 표준을 준수하면서도 국내 환경에 최적화된 서비스 포트폴리오를 갖추어야 한다. FAA와 EASA는 UTM 및 U-space의 핵심 서비스를 명확히 정의하고 있으며, 이는 우리가 개발할 시스템이 갖춰야 할 기능의 글로벌 기준을 제시한다.

EASA는 U-space 공역 내에서 제공되어야 할 서비스로 4가지 필수 서비스(Mandatory Services)와 2가지 추가 서비스(Additional Services)를 규정하고 있다.15

• 필수 서비스:

1. 네트워크 식별 (Network Identification): 비행 중인 모든 드론의 원격 식별 정보를 지속적으로 처리하고 권한 있는 사용자에게 제공하여 공역의 투명성을 확보한다.
2. 지리인식 (Geo-awareness): 드론 운용자에게 비행금지구역, 제한구역, 임시 비행 제한 등 운용 조건 및 공역 제한에 관한 정보를 제공하여 규정 준수를 지원한다.
3. UAS 비행 승인 (UAS Flight Authorisation): 개별 비행에 대한 운용 조건을 명시한 비행 승인을 제공하여 사전에 비행 계획의 안전성을 검토하고 인가한다.
4. 교통 정보 (Traffic Information): 운용 중인 드론의 인근에 위치한 다른 유인 항공기 및 무인 항공기의 교통 정보를 제공하여 충돌 위험을 줄인다.

• 추가 서비스:

1. 기상 정보 (Weather Information): 안전한 비행을 위한 기상 예보 및 실황 정보를 제공한다.
2. 규정 준수 모니터링 (Conformance Monitoring): 비행 중인 드론이 승인된 비행 계획과 규정을 준수하는지 실시간으로 확인한다.

FAA의 UTM 운용개념서(CONOPS) v2.0 역시 USS가 제공해야 할 서비스로 운영 계획 지원, 의도 공유, 전략적/전술적 충돌 회피, 원격 식별(RID) 등을 포괄적으로 제시하며, 이는 EASA의 서비스 분류와 개념적으로 거의 동일하다.13

이러한 글로벌 표준은 국토교통부의 K-UAM 운용개념서에서 정의된 PSU의 역할과도 정확히 부합한다. PSU의 핵심 역할인 ’운항 안전정보 공유 및 교통흐름 관리’는 교통 정보, 기상 정보, 규정 준수 모니터링 서비스를 포괄하는 개념이며, ’비행계획 승인 및 항로이탈 모니터링’은 비행 승인 및 네트워크 식별 서비스와 직접적으로 연결된다.8

이 분석을 바탕으로, Private UTM 시스템의 서비스 포트폴리오는 다음과 같이 설계되어야 한다.

• 핵심 서비스 (Core Services): 글로벌 표준과 K-UAM 요구사항을 모두 충족하는 4대 필수 서비스(네트워크 식별, 지리인식, 비행 승인, 교통 정보)를 기본으로 제공한다. 이는 규제 준수를 위한 최소 요건(Minimum Requirement)이자 시장 진입의 필수 조건이다.
• 부가 가치 서비스 (Value-added Services): 경쟁 우위를 확보하고 고객에게 차별화된 가치를 제공하기 위한 고급 서비스이다.
• 고정밀 기상 및 환경 데이터: 단순한 광역 기상 정보를 넘어, 도심 빌딩숲 사이에서 발생하는 미세 난기류(Urban Canyon Wind), 특정 지역의 전파 간섭 예측, 태양광 패널 점검을 위한 일사량 정보 등 특정 임무에 최적화된 고부가가치 환경 데이터를 제공한다.19
• AI 기반 고급 분석: 수집된 방대한 비행 로그, 기체 센서 데이터, 배터리 소모 패턴 등을 인공지능으로 분석하여 최적의 비행 경로 추천, 기체 이상 징후 예측, 배터리 수명 관리 최적화 등 예측 및 최적화 서비스를 제공한다. 이는 단순 관제를 넘어 운영 효율성을 극대화하는 핵심 기능이 될 것이다.12
• 엔터프라이즈 통합 (Enterprise Integration): 고객사의 기존 전사적 자원 관리(ERP), 공급망 관리(SCM), 자산 관리 시스템과 원활하게 데이터를 연동할 수 있는 표준 API 및 맞춤형 커넥터를 제공한다. 이는 ANRA, OneSky와 같은 선도 업체들의 핵심 경쟁력이며, 고객의 업무 프로세스에 깊숙이 통합될수록 대체 불가능한 솔루션이 된다.21
• 시뮬레이션 및 디지털 트윈 (Simulation & Digital Twin): 실제 드론을 비행시키기 전에 가상 환경에서 임무 전체를 시뮬레이션하고, 잠재적 위험 요소를 사전에 분석하며, 조종사를 훈련시킬 수 있는 기능을 제공한다. 이는 안전성을 획기적으로 높이고 운영 비용을 절감하는 강력한 도구이다.25

이러한 서비스 포트폴리오 설계는 중요한 전략적 함의를 내포한다. UTM 플랫폼의 진정한 장기적 가치는 관제 기능 자체가 아니라, 플랫폼에 축적되는 방대한 양의 데이터를 가공하여 제공하는 데이터 서비스에 있다. 핵심 UTM 서비스(비행 승인, 교통 정보 등)는 FAA와 EASA 모두 표준화된 프로토콜과 API를 지향하므로 14, 시간이 지남에 따라 기술이 상향 평준화되고 상품화(Commoditization)될 가능성이 높다. 경쟁사와의 진정한 차별점은 플랫폼을 통해 축적되는 데이터를 어떻게 새로운 가치로 창출하느냐에 달려있다. OneSky가 자사의 핵심 역량으로 단순 관제가 아닌 ’분석(Analytics)’을 강조하며, 비행 동역학과 시뮬레이션 기술을 기반으로 한 고도의 의사결정 지원 도구를 제공하는 것이 바로 그 예이다.21

수집된 데이터(비행 경로, 기체 상태, 통신 품질, 배터리 소모 패턴, 장애물 정보 등)는 그 자체로 엄청난 자산이다. 이 데이터를 분석하여 보험사에게는 드론 운용 리스크 평가 모델을 제공하고, 도시 계획가에게는 미래 항공 교통량 분석 데이터를 판매하며, 드론 제조사에게는 실제 환경에서의 운용 데이터를 피드백하여 제품 개선을 돕는 등 다양한 B2B 데이터 비즈니스로 확장이 가능하다. 따라서 시스템 아키텍처 설계 초기부터 데이터의 수집, 저장, 분석, 그리고 서비스화를 염두에 둔 ’데이터 중심 아키텍처(Data-centric Architecture)’를 구축하는 것이 사업의 장기적인 성공을 위한 핵심 전략이 되어야 한다.

2. Private UTM 시스템 아키텍처

제1부에서 정의한 전략적 프레임워크와 서비스 모델을 성공적으로 구현하기 위해서는 유연하고 확장 가능하며 안정적인 기술 아키텍처가 뒷받침되어야 한다. 본 장에서는 클라우드와 온프레미스 환경을 모두 지원하는 거시적 아키텍처부터 개별 기능을 담당하는 마이크로서비스의 상세 설계, 대용량 실시간 데이터 처리 파이프라인, 그리고 시스템의 두뇌 역할을 하는 핵심 알고리즘과 데이터베이스 모델까지 심층적으로 고찰한다.

2.1 거시적 아키텍처: 클라우드와 온프레미스 배포 모델

Private UTM 시스템은 다양한 고객의 요구사항을 충족시키기 위해 클라우드 기반의 서비스형 소프트웨어(SaaS) 모델과 고객사 내부에 직접 설치하는 온프레미스 모델을 모두 지원해야 한다. 클라우드 모델은 빠른 구축, 유연한 확장성, 낮은 초기 도입 비용을 장점으로 내세워 스타트업, 중소기업, 상용 드론 서비스 제공자에게 매력적인 선택지이다.27 반면, 온프레미스 모델은 데이터 주권(Data Sovereignty)과 최고 수준의 보안을 요구하는 정부, 국방, 원자력 발전소와 같은 핵심 인프라 관련 고객에게는 필수적인 요구사항이다.28 이 두 가지 상이한 배포 모델을 효율적으로 지원하기 위해서는 두 환경 간에 손쉽게 이식(Porting)이 가능한 아키텍처 설계가 무엇보다 중요하다.

이를 위한 최적의 해결책은 컨테이너 기반 아키텍처를 채택하는 것이다. 시스템을 구성하는 모든 마이크로서비스를 **도커(Docker)**와 같은 컨테이너 기술로 패키징하고, 이를 **쿠버네티스(Kubernetes)**를 통해 오케스트레이션하는 것을 표준 아키텍처로 삼아야 한다.29 이 접근법은 다음과 같은 명확한 이점을 제공한다.

• 이식성 (Portability): 동일한 컨테이너 이미지를 코드 변경 없이 AWS의 EKS, Google의 GKE, Azure의 AKS와 같은 퍼블릭 클라우드 환경과 고객사 데이터센터에 구축된 온프레미스 쿠버네티스 클러스터에 동일하게 배포할 수 있다.
• 확장성 (Scalability): 드론 관제 트래픽이 급증할 경우, 특정 기능(예: 텔레메트리 수집 서비스)의 컨테이너 인스턴스만 독립적으로 신속하게 확장(Scale-out)하여 부하에 대응할 수 있다.
• 회복탄력성 (Resilience): 특정 마이크로서비스에 장애가 발생하더라도, 쿠버네티스의 자가 치유(Self-healing) 기능이 자동으로 해당 컨테이너를 재시작하거나 정상적인 다른 인스턴스로 트래픽을 라우팅하여 전체 시스템의 장애 전파를 막고 다운타임을 최소화한다.

특히 온프레미스 환경에 솔루션을 구축할 때는 클라우드 환경과는 다른 차원의 엄격한 관리가 요구된다. 첫째, 인프라 표준화 및 문서화가 필수적이다. 고객사에 배포될 서버 하드웨어 사양, 스토리지 구성, 네트워크 장비 및 레이아웃, 보안 정책, 소프트웨어 패치 관리 절차 등을 명확한 표준으로 정의하고 철저히 문서화해야 한다. 이는 예측 가능한 성능을 보장하고, 장애 발생 시 신속한 원인 분석과 해결을 가능하게 하는 기반이 된다.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), 가격 정책, 조직 및 인력 계획을 수립하는 것이 현명하다.

2.2 마이크로서비스 아키텍처(MSA) 상세 설계

UTM 시스템은 비행 계획, 실시간 관제, 데이터 분석, 사용자 관리, 기체 관리 등 다양한 기능적 요구사항의 복잡한 집합체이다. 이러한 시스템을 단일 애플리케이션(Monolithic Architecture)으로 개발할 경우, 작은 기능 하나를 수정하더라도 전체 시스템을 다시 테스트하고 배포해야 하므로 개발 속도가 저하되고, 특정 기능의 장애가 전체 시스템의 중단으로 이어질 위험이 크다. 따라서 각 기능을 독립적으로 개발, 배포, 확장할 수 있는 **마이크로서비스 아키텍처(MSA: Microservice Architecture)**를 채택하는 것이 기술적, 사업적 관점에서 모두 최적의 선택이다.29 MSA는 시스템의 복잡성을 효과적으로 관리하고, 팀의 자율성을 높여 개발 속도를 가속화하며, 장애의 영향을 개별 서비스로 국지화하여 시스템 전체의 안정성을 향상시킨다.

본 Private UTM 시스템을 위한 핵심 마이크로서비스는 다음과 같이 정의할 수 있다. (표 2 참조)

• API 게이트웨이 (API Gateway): 모든 외부 요청(웹, 모바일, 외부 연동 시스템)이 시스템 내부로 들어오는 단일 진입점(Single Entry Point) 역할을 한다. 인증/인가, 요청 로깅, 서비스 라우팅, 속도 제한(Rate Limiting) 등 공통적인 횡단 관심사(Cross-cutting Concerns)를 처리한다.
• 사용자 서비스 (User Service): 사용자(조종사, 관리자, 운영자) 계정 정보, 조직 정보, 그리고 각 사용자의 역할에 따른 시스템 접근 권한을 관리하는 역할 기반 접근 제어(RBAC) 기능을 담당한다.
• 드론 기단 서비스 (Drone Fleet Service): 개별 드론 기체의 상세 정보(모델, 시리얼 번호, 등록 번호), 배터리 정보(수명 주기, 충전 상태), 정비 이력, 장착된 센서 및 페이로드 정보 등 기단 전체의 자산을 관리한다.
• 비행 계획 서비스 (Flight Plan Service): 비행 계획의 생성, 유효성 검증(공역 침범, 기체 성능 초과 등), 수정, 저장 및 관리자의 승인에 이르는 전체 워크플로우를 관리한다.
• 공역 서비스 (Airspace Service): 비행금지구역(No-fly zones), 제한구역 등 정적인 공역 정보와, 임시 비행 제한(TFRs)과 같은 동적인 공역 정보를 관리하고 조회 API를 제공하여 지리인식(Geo-awareness) 기능을 지원한다.
• 교통 서비스 (Traffic Service): ADS-B, Remote ID 등 다양한 소스로부터 실시간 항공 교통 정보를 수신하여 통합하고, 특정 지역의 유/무인 항공기 교통 상황 정보를 다른 서비스에 제공한다.
• 텔레메트리 수집 서비스 (Telemetry Ingestion Service): 수많은 드론으로부터 초 단위로 전송되는 대용량 텔레메트리 데이터(위치, 고도, 속도 등)를 실시간으로 수집하여 데이터 파이프라인으로 전달하는 역할을 한다.
• 실시간 처리 서비스 (Real-time Processing Service): 수집된 텔레메트리 데이터를 실시간으로 처리하여 비행 상태 모니터링, 승인된 항로 이탈 여부 감지, 다른 항공기와의 잠재적 충돌 위험 분석 등 핵심적인 관제 로직을 수행한다.
• 알림 서비스 (Notification Service): 이메일, SMS, 모바일 푸시 알림 등 다양한 채널을 통해 사용자에게 비행 승인, 공역 경고, 긴급 상황 등 중요한 이벤트를 통지한다.
• 데이터 분석 서비스 (Data Analytics Service): 시스템에 축적된 방대한 비행 데이터를 분석하여 통계 리포트, 운용 효율성 분석, 기체 이상 징후 예측 모델 등 부가 가치 서비스를 제공한다.

이러한 마이크로서비스들 간의 상호작용은 두 가지 방식으로 이루어진다. 즉각적인 응답이 필요한 **동기식 통신(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)의 도입을 적극적으로 고려해야 한다.

2.3 실시간 데이터 처리 및 분석 아키텍처

Private UTM 시스템의 심장부는 수천, 수만 대의 드론이 초 단위로 쏟아내는 방대한 텔레메트리 데이터(위치, 고도, 속도, 배터리 상태, 센서 값 등)를 지연 없이 수집, 처리, 분석하여 유의미한 정보로 변환하는 능력에 있다. 이 도전 과제를 해결하기 위해, 확장 가능하고 내결함성(Fault-tolerant)이 뛰어난 실시간 데이터 파이프라인 구축이 필수적이다.

이러한 요구사항을 충족시키기 위한 아키텍처의 핵심으로 Apache Kafka를 제안한다. Kafka는 분산 스트리밍 플랫폼으로서, 초당 수백만 건의 이벤트를 처리할 수 있는 높은 처리량과 데이터 유실을 방지하는 내결함성을 제공하여 대규모 실시간 데이터 처리의 사실상 표준(De facto standard)으로 자리 잡았다.34 Kafka를 중심으로 한 데이터 파이프라인은 다음과 같이 구성된다.

1. 데이터 수집 (Ingestion): 드론 또는 지상관제시스템(GCS)은 네트워크 대역폭이 제한적인 엣지 환경에 최적화된 경량 메시징 프로토콜인 MQTT를 사용하여 텔레메트리 데이터를 엣지 게이트웨이로 안전하게 전송한다.36 엣지 게이트웨이는 수신된 데이터를 Kafka Connect 또는 맞춤형으로 개발된 Kafka 프로듀서(Producer)를 통해 Kafka 클러스터의 특정 토픽(Topic)으로 발행(Publish)한다.34 이때, 데이터의 지리적 위치 정보를 기반으로 지오해싱(Geohashing) 알고리즘을 적용하여 Kafka 토픽의 파티션 키로 사용하면, 특정 지역의 데이터를 동일한 파티션으로 모을 수 있어 후속 처리 단계에서 지역 기반의 병렬 처리를 용이하게 하고 성능을 크게 향상시킬 수 있다.37
2. 데이터 처리 (Processing): Kafka Streams 라이브러리나 Apache Flink, Apache Spark Streaming과 같은 분산 스트림 처리 프레임워크를 사용하여 Kafka 토픽의 데이터를 실시간으로 구독(Subscribe)하고 가공한다. 이 단계에서 수행되는 핵심 로직은 다음과 같다.

• 승인된 비행 계획 대비 실제 항적의 일치 여부를 지속적으로 모니터링 (Conformance Monitoring)
• 드론이 비행금지구역이나 제한구역을 침범하는지 실시간으로 감지
• 주변의 다른 항공기와의 미래 경로를 예측하여 잠재적 충돌 위험을 분석하고 경고 생성
• 급격한 배터리 소모, GPS 신호 불량 등 기체의 비정상적인 패턴을 감지하여 조기 경보

3. 데이터 저장 (Storage) 및 서빙 (Serving):

• 실시간으로 처리된 최신 비행 상태 정보(현재 위치, 속도, 경고 상태 등)는 인메모리 데이터 그리드(In-memory Data Grid)(예: Redis, Hazelcast)에 저장하여, 웹/모바일 관제 대시보드에서 수많은 사용자가 지연 없이 조회할 수 있도록 한다.
• 수집된 모든 원본 텔레메트리 데이터와 처리 결과 데이터는 장기적인 분석, 규제 준수 증빙, 사고 조사를 위해 데이터 레이크(Data Lake)(예: AWS S3, HDFS)에 비용 효율적으로 저장하고, 정형화된 분석을 위해 **데이터 웨어하우스(Data Warehouse)**로 적재한다.

이러한 복잡한 데이터 파이프라인을 구성하는 마이크로서비스들을 개발할 때, 단일 프로그래밍 언어에 얽매일 필요가 없다. 각 서비스의 특성에 가장 적합한 기술을 선택하는 **폴리글랏 아키텍처(Polyglot Architecture)**를 지향해야 한다. Go와 Java는 이 시스템의 핵심 백엔드 언어로서 각각 뚜렷한 강점을 가진다.

벤치마크 자료에 따르면, Go는 Java에 비해 컴파일 속도가 월등히 빠르고, 실행 파일의 크기가 작으며, 적은 메모리를 사용한다. 특히, 운영체제 스레드보다 훨씬 가벼운 ’고루틴(Goroutine)’을 통한 동시성 처리 모델은 수많은 네트워크 연결을 동시에 처리해야 하는 I/O 중심(I/O-bound) 작업에서 탁월한 성능을 발휘한다.38 반면, Java는 수십 년간 발전해 온 자바 가상 머신(JVM)의 강력한 최적화 기술(예: JIT 컴파일러) 덕분에, 장시간 실행되는 복잡한 비즈니스 로직이나 대규모 데이터 처리와 같은 CPU 중심(CPU-bound) 작업에서 Go를 능가하는 성능을 보여주기도 한다.40

따라서 다음과 같은 기술 스택 적용 전략을 제안한다.

• Go: 텔레메트리 수집 서비스, API 게이트웨이, 알림 서비스와 같이 수만 개의 드론 커넥션을 동시에 처리해야 하거나, 높은 동시성과 낮은 메모리 사용량이 중요한 I/O 중심의 마이크로서비스 개발에 최적이다.
• Java (with Spring Boot): 비행 계획 서비스, 데이터 분석 서비스와 같이 복잡한 비즈니스 로직, 데이터베이스 트랜잭션 관리, 방대한 외부 라이브러리 및 프레임워크 생태계 활용이 중요한 마이크로서비스 개발에 적합하다. 검증된 안정성과 높은 개발 생산성을 제공한다.

이처럼 정교하게 설계된 데이터 파이프라인이라도 시간이 지남에 따라 불안정해질 수 있는 숨겨진 위험이 있다. 바로 데이터 구조의 변경 문제이다. 여기서 스키마 레지스트리(Schema Registry)는 데이터 파이프라인의 장기적인 안정성을 보장하는 숨은 영웅과 같은 역할을 한다. 수많은 마이크로서비스가 Kafka를 통해 비동기적으로 데이터를 주고받는 환경에서, 한 서비스가 데이터의 ’구조(Schema)’를 사전 협의 없이 변경하면(예: 텔레메트리 데이터에 새로운 필드를 추가하거나 기존 필드의 데이터 타입을 변경), 이 데이터를 소비하는 다른 모든 서비스에서 심각한 데이터 파싱 오류가 발생하며 시스템 전체가 마비될 수 있다. 스키마 레지스트리는 모든 데이터의 스키마를 중앙에서 버전별로 관리하는 시스템이다.34 데이터를 발행하는 프로듀서는 데이터를 보내기 전에 먼저 스키마 레지스트리에 해당 데이터의 스키마를 등록하고, 실제 데이터와 함께 스키마의 고유 ID를 Kafka로 전송한다. 데이터를 구독하는 컨슈머는 메시지를 받으면 이 스키마 ID를 이용해 스키마 레지스트리에서 정확한 버전의 스키마를 조회하여 데이터를 안전하게 역직렬화(Deserialize)한다. 더 중요한 것은, 스키마 레지스트리가 하위 호환성 규칙(Backward Compatibility)을 강제하여, 기존 컨슈머 시스템을 망가뜨릴 수 있는 스키마 변경을 원천적으로 차단한다는 점이다. 결과적으로, 스키마 레지스트리를 도입하는 것은 개발팀 간의 불필요한 조율 비용을 줄이고 데이터 파이프라인의 예기치 않은 붕괴를 막아, 장기적으로 유지보수 가능하고 신뢰성 높은 데이터 아키텍처를 구축하기 위한 필수적인 투자이다.

2.4 핵심 기능 구현 심층 분석

Private UTM 시스템의 가치는 거시적인 아키텍처뿐만 아니라, 그 안에서 동작하는 핵심 기능들의 정교함과 신뢰성에 의해 결정된다. 본 절에서는 비행 계획 관리, 동적 경로 계획 등 시스템의 두뇌에 해당하는 기능들의 구현 방안을 심층적으로 분석한다.

2.4.1 비행 계획 데이터 모델 및 승인 절차

FAA 운용개념서(CONOPS)에 명시된 바와 같이, 비행 의도(Intent) 정보의 공유는 UTM의 가장 기본적인 전제 조건이다.13 따라서 비행 계획을 표현하는 데이터 모델은 명확하고 포괄적이어야 한다. 이 데이터 모델은 최소한 다음의 정보들을 포함해야 한다.

• 기본 식별 정보: flight_plan_id (고유 식별자), operator_id (운용 주체), drone_id (사용 기체), pilot_id (담당 조종사)
• 4차원 운용 볼륨 (4D Operation Volume): 위도, 경도, 고도, 그리고 시간으로 정의되는 4차원 공간 정보. 이는 일련의 경유점(Waypoints) 리스트 또는 비행 영역을 나타내는 다각형(Polygon)과 고도 범위, 그리고 예상 시작 및 종료 시간으로 구체화된다.13
• 운용 파라미터: 최대 순항 속도, 수직 상승/하강 속도, 비행 모드(VLOS/BVLOS) 등 기체의 운용 제약 조건.
• 비상 대응 계획 (Contingency Plan): 통신 두절 시 자동 복귀(RTH), 제자리 비행(Hover) 등 사전에 정의된 비상 행동 계획과, 비상 착륙이 가능한 후보지 목록.
• 규제 관련 정보: 해당 비행에 필요한 허가 또는 규제 면제(Waiver) 문서 번호 등 규제 준수 증빙 자료.

비행 계획이 제출되고 승인되는 과정은 여러 마이크로서비스 간의 복잡한 상호작용을 수반한다. 이 과정을 명확히 정의하기 위해 UML 시퀀스 다이어그램(UML Sequence Diagram)을 활용하여 상호작용 흐름을 시각화할 수 있다.42 승인 절차의 흐름은 다음과 같이 요약될 수 있다.

1. 조종사 (모바일/웹 앱) 가 비행 계획 데이터를 입력하고 API 게이트웨이에 제출한다: submitFlightPlan(flightPlanData).
2. API 게이트웨이는 요청을 인증하고 비행 계획 서비스로 전달한다: createFlightPlan(flightPlanData).
3. 비행 계획 서비스는 비행 계획의 유효성을 검증하기 위해 다른 서비스들과 협력한다.

• 공역 서비스에 운용 볼륨을 전달하여 비행금지구역 등 공역 제한과 저촉되는지 확인한다: checkAirspaceRestrictions(operationVolume).
• 교통 서비스에 운용 볼륨을 전달하여 이미 승인된 다른 비행 계획과 시간/공간적으로 충돌하는지 확인한다 (전략적 충돌 해소, Strategic Deconfliction): checkStrategicConflicts(operationVolume).

4. 모든 검증을 통과하면, 비행 계획 서비스는 해당 계획의 상태를 ’승인 대기(PENDING_APPROVAL)’로 변경하고 데이터베이스에 저장한다.
5. 비행 계획 서비스는 관리자에게 승인 요청이 있음을 알리기 위해 알림 서비스를 호출한다: notifyAdmin(flightPlanId).
6. 관리자 (웹 앱) 가 승인 요청을 확인하고 승인 버튼을 클릭하면, 요청은 API 게이트웨이를 거쳐 비행 계획 서비스로 전달된다: approveFlightPlan(flightPlanId).
7. 비행 계획 서비스는 해당 비행 계획의 상태를 ’승인됨(APPROVED)’으로 최종 변경한다.
8. 상태 변경이 완료되면, 비행 계획 서비스는 비동기적 처리를 위해 Kafka에 FlightPlanApproved 이벤트를 발행한다.
9. 교통 서비스는 이 이벤트를 구독하여, 승인된 비행 정보를 실시간 교통 관제 시스템에 등록한다.
10. 알림 서비스 역시 이 이벤트를 구독하여, 조종사에게 비행이 최종 승인되었음을 통보한다.

2.4.2 동적 경로 계획 알고리즘

안전하고 효율적인 비행을 위해서는 정적 및 동적 환경을 모두 고려하는 지능적인 경로 계획 알고리즘이 필수적이다.

• 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) (동적/실시간 경로 재설정): 실제 비행 중에는 예측 불가능한 상황이 발생할 수 있다. 갑작스러운 악천후, 긴급 항공기의 출현으로 인한 공역의 동적 폐쇄, 예기치 않은 다른 드론의 등장 등 정적 경로 계획만으로는 대응할 수 없는 상황에 대처하기 위해 강화학습이 강력한 해법을 제공한다.

• 적용 방안: 강화학습 에이전트(Agent)는 현재 상태(State: 드론의 위치, 속도, 배터리 잔량, 주변 교통 상황, 실시간 기상 데이터)를 입력받아, 장기적으로 가장 높은 보상(Reward)을 얻을 수 있는 최적의 행동(Action: 고도 변경, 방향 전환, 속도 조절)을 선택하도록 학습된다. 보상은 목표 지점에 안전하게 도달, 다른 항공기와의 충돌 회피, 에너지 소모 최소화 등을 기준으로 설계된다. 이러한 접근법을 통해 복잡하고 동적인 도시 환경에서 최적의 공역 구조(예: 방향별 고도 분리)를 동적으로 결정하거나 48, 주변 교통 흐름을 고려하여 가장 안전하고 효율적으로 비행 고도층을 변경하는 기동을 학습시킬 수 있다.49

이 두 가지 알고리즘은 상호 배타적인 것이 아니라, 상호 보완적으로 사용될 때 가장 큰 시너지를 낼 수 있다. 최적의 경로 계획 시스템은 정적 계획을 위한 A*와 동적 대응을 위한 강화학습의 하이브리드(Hybrid) 접근 방식을 요구한다. 이는 여러 연구에서도 그 효율성이 입증된 바 있다.46 구체적인 구현 시나리오는 다음과 같다.

1. 사전 계획 단계 (Pre-flight): 시스템은 A* 알고리즘을 사용하여, 알려진 모든 정적 장애물(건물, 지형)과 규제(비행금지구역)를 고려한 전역 최적 경로(Global Path)를 생성하여 비행 계획에 포함시킨다.
2. 실시간 비행 단계 (In-flight): 드론이 이 전역 경로를 따라 비행하는 동안, 기체에 탑재되거나 클라우드에서 실행되는 강화학습 기반의 지역 플래너(Local Planner)가 실시간 센서 데이터(카메라, 라이다)와 교통 정보를 바탕으로 주변의 동적 장애물(다른 드론, 조류, 기상 변화)을 회피하기 위한 미세한 경로 조정을 실시간으로 수행한다.

이러한 하이브리드 접근법은 A*의 최적성과 강화학습의 적응성을 결합하여, 계산 효율성과 동적 환경 대응 능력을 모두 확보하는 가장 현실적이고 강력한 솔루션이다. 시스템 아키텍처는 이러한 하이브리드 경로 계획 모듈을 원활히 지원하도록 설계되어야 한다.

2.5 데이터베이스 및 기체 관리 시스템 설계

안전하고 효율적인 드론 운용을 위해서는 비행 데이터와 기체 정보를 체계적으로 관리하는 것이 무엇보다 중요하다. 수집된 데이터는 안전 감사, 성능 개선 분석, 규제 준수 증빙 등 다양한 목적으로 활용되는 핵심 자산이다.50 이러한 다양한 데이터의 특성을 효율적으로 관리하기 위해, 단일 종류의 데이터베이스가 아닌 데이터의 성격에 맞는 여러 종류의 데이터베이스를 조합하여 사용하는

폴리글랏 퍼시스턴스(Polyglot Persistence) 전략을 채택해야 한다.

• 관계형 데이터베이스 (RDBMS, 예: PostgreSQL): 사용자 정보, 기체 등록 정보, 비행 계획 등과 같이 데이터의 정합성과 트랜잭션의 일관성이 매우 중요한 정형 데이터를 저장하는 데 사용한다. PostGIS 확장 기능을 활용하면 지리 공간 데이터(예: 비행 경로, 공역 폴리곤)에 대한 효율적인 쿼리도 가능하다.
• 주요 테이블 스키마 예시:
• 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)
• 시계열 데이터베이스 (TSDB, 예: InfluxDB, TimescaleDB): 드론이 초당 수십 회씩 생성하는 대용량, 고빈도의 텔레메트리 데이터를 저장하고, 시간 범위에 따른 빠른 조회 및 집계 연산에 최적화된 성능을 제공한다.
• Measurement (테이블에 해당) 예시: telemetry
• Tags (인덱싱되는 컬럼): drone_id, mission_id, pilot_id
• Fields (실제 값): latitude, longitude, altitude, ground_speed, vertical_speed, battery_voltage, rssi (수신 신호 강도)
• 문서 데이터베이스 (NoSQL, 예: MongoDB): 임무별로 수집되는 페이로드 데이터(예: 고해상도 이미지 메타데이터, 센서 로그)와 같이 구조가 유연하거나 비정형적인 데이터를 저장하는 데 적합하다. 스키마 변경이 자유로워 다양한 종류의 데이터를 쉽게 저장하고 관리할 수 있다.51

이러한 데이터베이스 설계를 기반으로 한 기체 관리 시스템은 단순히 자산 목록을 나열하는 수준을 넘어서야 한다. 상업적 드론 운용에서의 기체 관리(Fleet Management)는 단순한 자산 목록이 아니라, 임무 수행 직전의 ’운용 준비태세(Operational Readiness)’를 종합적으로 보장하는 지능형 시스템이어야 한다. 상업적 드론 운용에서 가장 중요한 것 중 하나는, 고객이 원하는 바로 그 시점에 드론이 안전하게 임무를 수행할 수 있는 최상의 상태를 유지하는 것이다.50

이는 단순히 드론의 목록을 관리하는 것을 넘어, 배터리의 충전 상태 및 노후도(수명 주기), 예정된 정비 일정, 설치된 펌웨어의 버전, 그리고 임무에 배정될 조종사의 자격 및 최근 비행 기록 등 복합적인 요소를 실시간으로 종합 분석하여 판단해야 함을 의미한다. 예를 들어, 시스템에서 특정 임무에 드론을 배정하려고 할 때, 드론 기단 서비스는 자동으로 다음과 같은 ‘준비태세 확인(Readiness Check)’ 로직을 수행해야 한다.

1. 기체 적합성: 배정하려는 드론의 모델과 페이로드가 해당 임무(예: 장거리 배송, 고해상도 촬영)의 요구사항을 만족하는가?
2. 배터리 상태: 해당 드론에 장착된 배터리가 임무 수행에 필요한 비행 시간을 보장할 만큼 충분히 충전되어 있는가? 배터리의 전체 충전 횟수(Cycle Count)가 제조사 권장 교체 주기에 임박하지 않았는가?
3. 정비 상태: 해당 드론의 누적 비행 시간이 정기 점검 주기에 도달했거나, 예정된 정비 일정이 임박하지 않았는가?
4. 조종사 자격: 임무에 배정된 조종사가 해당 기체 모델에 대한 운용 자격을 보유하고 있는가? 최근 일정 기간 동안 충분한 비행 경험을 유지하고 있는가?

이러한 지능적인 ‘준비태세 확인’ 기능은 드론 기단 서비스의 핵심 로직이 되어야 하며, 앞서 설계한 데이터베이스 스키마는 이 로직을 지원하기 위한 모든 정보를 담고 있어야 한다. 이 기능은 인적 오류로 인한 안전사고를 예방하고, 비효율적인 수동 확인 절차를 자동화하여 전체적인 운영 효율성을 극대화하는 결정적인 역할을 수행할 것이다.

3. 개발 및 서비스 조직 구성

성공적인 Private UTM 시스템의 구축과 운영은 탁월한 기술 아키텍처만으로는 불가능하다. 빠르게 변화하는 시장 요구에 민첩하게 대응하고 혁신을 주도할 수 있는 개발 조직, 그리고 24시간 365일 무중단 서비스를 보장하며 고객의 신뢰를 얻을 수 있는 서비스 운영 조직의 설계가 병행되어야 한다.

3.1 개발 조직: 스포티파이 모델 기반의 애자일 조직

전통적인 폭포수 모델이나 상명하달식의 경직된 조직 구조는 복잡하고 빠르게 진화하는 UTM 기술과 시장 요구에 효과적으로 대응하기 어렵다. 대신, 팀의 자율성과 팀 간의 유기적인 협력을 극대화하는 스포티파이(Spotify) 모델을 본 프로젝트의 개발 조직 프레임워크로 채택하는 것을 제안한다.52 이 모델은 대규모 조직이 애자일 원칙을 효과적으로 확장할 수 있도록 돕는 검증된 접근법이다.

스포티파이 모델의 핵심 구성 요소는 다음과 같다.53

• 스쿼드 (Squad): 특정 임무(Mission)를 부여받은 6~12명 규모의 작고 자율적인 교차기능팀(Cross-functional team)이다. 각 스쿼드는 마치 하나의 미니 스타트업처럼 움직이며, 자신들의 목표를 달성하기 위한 최적의 작업 방식(Scrum, Kanban 등)을 스스로 선택한다. 스쿼드는 제2부에서 정의한 마이크로서비스와 1:1 또는 1:N 관계로 매칭되어, 특정 기능 영역에 대한 완전한 소유권(Ownership)을 가진다.
• 트라이브 (Tribe): 서로 연관된 미션을 수행하는 여러 스쿼드들의 집합이다. 예를 들어, 비행 계획, 교통 정보, 공역 관리 등 핵심 관제 기능과 관련된 스쿼드들을 묶어 ’항공 관제 핵심 트라이브(Air Traffic Core Tribe)’를 구성할 수 있다. 트라이브는 던바의 수(Dunbar’s Number) 원칙에 따라 100명 미만으로 유지하여 구성원 간의 긴밀한 소통과 신뢰 관계 형성을 촉진한다.
• 챕터 (Chapter): 동일한 역량과 기술 스택을 가진 전문가들의 기능적 집합이다. 예를 들어, 여러 스쿼드에 흩어져 있는 백엔드 개발자들은 ’백엔드 챕터’에 소속된다. 이들은 정기적으로 모여 기술 표준을 논의하고, 모범 사례를 공유하며, 공통의 기술적 문제를 함께 해결한다. 챕터 리더는 해당 구성원들의 기술적 성장과 경력 개발을 돕는 인사 관리자 역할을 겸할 수 있다.
• 길드 (Guild): 특정 관심사를 공유하는 사람들의 비공식적인 커뮤니티이다. 챕터와 달리 트라이브에 구애받지 않고 조직 전체에 걸쳐 형성되며, 누구나 자발적으로 참여할 수 있다. 예를 들어, ‘성능 최적화 길드’, ‘머신러닝 길드’, ‘보안 길드’ 등을 통해 조직 내 지식을 전파하고 자발적인 혁신을 촉진한다.

이 모델에 따라, Private UTM 개발 조직은 다음과 같은 기능별 스쿼드로 구성될 수 있다. (표 3 참조)

• 비행 운영 스쿼드 (Flight Operations Squad): Flight Plan Service, Airspace Service 개발 및 운영 담당.
• 데이터 플랫폼 스쿼드 (Data Platform Squad): Telemetry Ingestion, Real-time Processing, Data Analytics Service 등 데이터 파이프라인 전체 담당.
• 코어 서비스 스쿼드 (Core Services Squad): User Service, Drone Fleet Service, Notification Service 등 공통 기반 서비스 담당.
• 웹 프론트엔드 스쿼드 (Web Frontend Squad): 관리자 및 운영자를 위한 웹 기반 관제 대시보드 개발.
• 모바일 스쿼드 (Mobile Squad): 현장의 조종사를 위한 모바일 애플리케이션(iOS/Android) 개발.
• 플랫폼 엔지니어링 스쿼드 (Platform Engineering Squad): 쿠버네티스 클러스터, CI/CD 파이프라인, 모니터링 시스템 등 모든 개발 스쿼드가 사용하는 공통 인프라 구축 및 관리.

그러나 스포티파이 모델을 성공적으로 적용하기 위해서는 한 가지 중요한 전제 조건을 이해해야 한다. 바로 ’자율성(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)’이라는 마이크로서비스의 핵심 원칙을 조직과 아키텍처 양쪽에서 성공적으로 구현하는 길이다.

3.2 서비스 운영 조직: 24/7 무중단 서비스를 위한 조직

UTM 서비스는 항공기 운항과 직접적으로 연결되므로, 단 1분의 장애도 허용되지 않는 미션 크리티컬(Mission-critical) 서비스이다. 혁신적인 기능을 빠르게 개발하는 것만큼이나, 개발된 서비스를 24시간 365일 안정적으로 운영하고 고객의 신뢰를 확보하는 것이 사업의 성패를 좌우한다. 이를 위해 다음과 같은 전문화된 서비스 운영 조직의 구성이 필수적이다. (표 4 참조)

• 기술 지원팀 (Technical Support): 고객과의 최접점에서 발생하는 기술 문의, 기능 질문, 장애 접수 등을 담당하는 1차 방어선이다. 클라우드 및 온프레미스 고객을 모두 지원하며, 고객의 등급에 따라 차등화된 서비스 수준 협약(SLA)을 관리한다. 단순 문의는 FAQ나 기술 문서를 통해 해결하고, 복잡한 문제는 분석하여 관련 개발팀이나 SRE팀으로 정확하게 에스컬레이션하는 역할을 수행한다.
• 사이트 신뢰성 엔지니어링 (SRE, Site Reliability Engineering) 팀: 서비스의 가용성, 성능, 안정성, 확장성을 책임지는 핵심 팀이다. 이들은 “코드를 통해 인프라와 운영 업무를 자동화“하는 것을 목표로 한다. 주요 책임은 24/7 시스템 모니터링 체계 구축, 장애 발생 시 자동 복구를 위한 런북(Runbook) 자동화, 성능 병목 현상 분석 및 개선, 그리고 개발팀과 협력하여 안정적인 배포를 위한 CI/CD(지속적 통합/지속적 배포) 파이프라인을 운영하는 것이다. 또한, 서비스 수준 목표(SLO)와 서비스 수준 지표(SLI)를 정량적으로 정의하고 관리하여 서비스의 신뢰성을 데이터 기반으로 측정하고 개선한다.
• 보안 운영 센터 (SOC, Security Operations Center) / 제품 보안팀 (Product Security): 외부의 사이버 위협으로부터 시스템을 보호하고, 내부 데이터의 유출을 방지하는 보안 전문 조직이다. 실시간으로 보안 위협을 탐지하고 대응하며, 정기적인 시스템 취약점 점검 및 모의 해킹을 통해 잠재적인 보안 허점을 사전에 발견하고 제거한다. 또한, 전사적인 보안 정책을 수립하고, 데이터 암호화, 접근 제어, 감사 로그 관리 등 제품의 보안 기능을 설계 단계부터 강화하는 역할을 수행한다.31
• 규제 준수 및 대관 업무팀 (Regulatory Compliance & Government Affairs): 항공 안전과 직결된 규제 산업의 특성상, 매우 중요한 역할을 담당한다. 국토교통부, FAA, EASA 등 국내외 항공 당국과의 공식적인 소통 채널을 유지하고, 끊임없이 변화하는 규제 및 정책 동향을 신속하게 파악하여 제품과 서비스에 반영될 수 있도록 내부 조직에 전파한다. PSU/USS/USSP와 같은 서비스 제공자 인증을 획득하고 유지하며, 정기적인 규제 관련 감사에 대응한다. 또한, ASTM, EUROCAE 등 국제 표준화 기구 활동에 적극적으로 참여하여 산업 표준 제정에 기여하고 기술 리더십을 확보하는 역할도 수행한다.17

이러한 운영 조직을 설계할 때, 클라우드와 온프레미스 고객 지원의 근본적인 차이점을 인지하는 것이 매우 중요하다. 온프레미스 고객 지원은 클라우드 환경과는 본질적으로 다른 접근 방식과 고도의 전문성을 요구한다. 클라우드(SaaS) 고객 지원은 우리가 완벽하게 통제하는 표준화된 환경 위에서 이루어지므로, 문제 분석과 해결의 주도권이 우리에게 있다. 그러나 온프레미스 고객 지원은 우리가 통제할 수 없는, 고객사 각각의 매우 다양하고 복잡한 IT 환경(상이한 네트워크 장비, 방화벽 정책, 서버 하드웨어, 운영체제 버전 등) 위에서 발생한 문제를 해결해야 하는 과제를 안고 있다.28

이는 단순히 우리 소프트웨어에 대한 깊은 지식만으로는 부족하며, 네트워킹, 시스템 관리, 데이터베이스, 가상화, 보안 등 광범위한 인프라 전반에 대한 해박한 지식을 갖춘 엔지니어를 필요로 함을 의미한다. 또한, 고객사의 엄격한 보안 정책으로 인해 원격 접속이 불가능한 경우가 많으므로, 안전한 원격 지원 솔루션을 사전에 마련하거나, 필요시 현장에 직접 엔지니어를 신속하게 파견할 수 있는 체계와 인력을 갖추어야 한다. 따라서 서비스 운영 조직 내에 일반 기술 지원팀과는 별도로, 고도의 인프라 전문성을 갖춘 **‘엔터프라이즈 지원팀(Enterprise Support Team)’**을 구성하고, 이들에게는 더 높은 수준의 기술 교육과 시스템 접근 권한을 부여하는 것이 바람직하다. 이들의 전문성이야말로 고가의 온프레미스 솔루션 계약을 유지하고, 고객과의 신뢰를 바탕으로 계약을 확장하는 핵심 동력이 될 것이다.

4. 종합 결론 및 전략적 권고

본 안내서는 서버, 웹, 모바일에서 구동되는 Private UTM 시스템을 클라우드와 온프레미스 환경으로 제공하기 위한 포괄적인 기술 및 조직 전략을 제시했다. 분석 결과를 종합하여, 성공적인 사업 추진을 위한 핵심 성공 요인과 단계별 사업 확장 로드맵을 다음과 같이 권고한다.

4.1 핵심 성공 요인 요약

성공적인 Private UTM 사업은 다음 세 가지 핵심 축의 유기적인 결합을 통해 달성될 수 있다.

• 전략 (Strategy): 사업의 정체성을 단순한 소프트웨어 개발사가 아닌, 항공 안전 법규와 기술을 융합하는 ‘규제 기술(RegTech)’ 기업으로 명확히 정의해야 한다. 시장 진입 초기에는 광범위한 시장을 얕게 공략하기보다, 가장 큰 잠재력을 가진 특정 산업(예: 물류, 에너지)을 선택하여 해당 분야의 문제를 깊이 파고들어 해결하는 ‘수직 계열화(Vertical Integration)’ 전략에 집중해야 한다. 장기적인 경쟁 우위는 관제 기능 자체가 아닌, 플랫폼에 축적된 데이터를 가공하여 새로운 가치를 창출하는 데이터 서비스에서 나온다는 점을 명심해야 한다.
• 아키텍처 (Architecture): 클라우드와 온프레미스 환경 모두에 유연하게 대응할 수 있도록 쿠버네티스(Kubernetes) 기반의 컨테이너 아키텍처를 채택해야 한다. 시스템의 복잡성을 관리하고 개발 속도를 높이기 위해 **마이크로서비스 아키텍처(MSA)**를 기반으로 설계하고, 서비스 간의 안정적인 비동기 통신을 위해 Apache Kafka 기반의 실시간 데이터 파이프라인을 구축해야 한다. 경로 계획 기능은 정적 환경에서의 최적 경로를 탐색하는 A* 알고리즘과 동적 환경 변화에 실시간으로 대응하는 **강화학습(RL)**을 결합한 하이브리드 방식으로 구현하여 안정성과 적응성을 모두 확보해야 한다.
• 조직 (Organization): 개발 조직은 자율성과 협업을 극대화하는 스포티파이 모델을 기반으로 구성하되, 시스템 전체의 일관성과 안정성을 보장하기 위한 강력한 아키텍처 거버넌스 체계를 반드시 갖추어야 한다. 서비스 운영 조직은 24/7 무중단 서비스를 목표로 SRE, 보안, 기술 지원, 규제 준수 등 전문화된 팀으로 구성해야 하며, 특히 고부가가치 온프레미스 고객을 위한 별도의 **‘엔터프라이즈 지원팀’**을 육성하여 차별화된 서비스를 제공해야 한다.

4.2 단계별 사업 확장 로드맵 권고

이상의 전략, 아키텍처, 조직 원칙을 바탕으로 다음과 같은 3단계 사업 확장 로드맵을 제안한다.

• 1단계: 최소 기능 제품(MVP) 출시 및 시장 검증 (1~2년)
• 목표: 핵심 기능에 집중한 클라우드 기반 MVP를 출시하여 초기 시장을 선점하고, 실제 운용 데이터를 통해 제품을 검증하고 안정화한다.
• 실행 방안:
• 가장 명확한 요구사항과 높은 지불 의사를 가진 단일 수직 시장(예: 국내 대형 물류사, 에너지 인프라 기업)을 목표 고객으로 선정한다.
• 글로벌 표준과 K-UAM의 최소 요구사항을 충족하는 4대 핵심 서비스(네트워크 식별, 지리인식, 비행 승인, 교통 정보) 개발에 모든 역량을 집중한다.
• 1~2개의 핵심 고객사(Design Partner)를 확보하여 긴밀하게 협력하며, 실제 필드에서 발생하는 문제들을 해결하고 제품의 완성도를 높인다. 이 과정에서 축적된 운용 데이터는 향후 AI 분석 서비스의 소중한 자산이 된다.
• 2단계: 서비스 확장 및 신규 시장 진입 (2~4년)
• 목표: 검증된 핵심 서비스를 바탕으로 부가 가치 서비스를 고도화하고, 온프레미스 솔루션을 공식 출시하여 정부/공공 시장으로 사업 영역을 확장한다.
• 실행 방안:
• AI 기반 분석, 고정밀 기상 정보, 시뮬레이션 등 1단계에서 수집한 데이터를 활용한 부가 가치 서비스를 상용화하여 제품의 차별성을 강화한다.
• 표준화된 온프레미스 패키지를 개발하여 데이터 주권과 보안을 중시하는 정부, 국방, 핵심 기반 시설 시장에 진입한다. 이를 위해 엔터프라이즈 지원 조직을 본격적으로 강화한다.
• 국토교통부의 K-UAM 로드맵 ‘성장기’ 진입에 맞춰, PSU(UAM 교통관리서비스 제공자) 사업자 인증을 위한 준비에 착수하고, 관련 법규 및 기술 요건을 충족시킨다.
• 3단계: 플랫폼 생태계 구축 및 글로벌 확장 (4년 이후)
• 목표: 안정적인 플랫폼과 풍부한 데이터를 기반으로 개방형 생태계를 구축하고, 이를 바탕으로 글로벌 시장 진출을 모색한다.
• 실행 방안:
• 핵심 기능을 표준 API 형태로 공개하여 서드파티(3rd Party) 개발사, 드론 제조사, 데이터 분석 기업 등이 참여하는 플랫폼 생태계를 조성한다.
• 축적된 비행 데이터를 익명화/가공하여 보험, 광고, 도시 계획 등 새로운 산업 분야에 판매하는 데이터 비즈니스 모델을 본격화한다.
• 국내 시장에서의 성공 사례와 K-UAM 운영 경험을 바탕으로, 동남아, 중동 등 UAM 도입에 적극적인 국가를 시작으로 글로벌 시장 진출을 추진한다.

이 로드맵은 불확실성이 높은 신규 시장에 진입하면서 위험을 최소화하고, 단계적으로 역량을 강화하며 지속 가능한 성장을 이루기 위한 전략적 경로를 제시한다. 성공적인 실행을 위해서는 각 단계별 목표에 맞는 자원 배분과 조직 역량 강화가 반드시 수반되어야 할 것이다.

5. 참고 자료

1. What Is Unified Threat Management (UTM)? - NinjaOne, accessed August 13, 2025, https://www.ninjaone.com/blog/what-is-unified-threat-management/
2. What is Unified Threat Management (UTM)? - GeeksforGeeks, accessed August 13, 2025, https://www.geeksforgeeks.org/computer-networks/what-is-unified-threat-management-utm/
3. What does the term UTM mean? Is UTM better or more accurate than latitude/longitude?, accessed August 13, 2025, https://www.usgs.gov/faqs/what-does-term-utm-mean-utm-better-or-more-accurate-latitudelongitude
4. Universal Transverse Mercator coordinate system - Wikipedia, accessed August 13, 2025, https://en.wikipedia.org/wiki/Universal_Transverse_Mercator_coordinate_system
5. 한국형 도심항공교통(K-UAM) 로드맵 - 보도자료 - 상세보기, accessed August 13, 2025, https://www.molit.go.kr/USR/NEWS/m_71/dtl.jsp?id=95083976
6. 한국형 도심항공교통(K-UAM) 로드맵 - KDI 경제정책 시계열서비스, accessed August 13, 2025, https://epts.kdi.re.kr/polcTmsesSrvc/them?SEARCH_CTE_SEQ=71005&BIG_CD=RELT_THEM00084&MID_CD=RELT_THEM00160&SML_CD=RELT_THEM00172
7. K-UAM 단계별 도입 목표 및 주요 지표 - 항공정보포털시스템, accessed August 13, 2025, https://airportal.go.kr/airplane/uamKo.do
8. 한국형 도심항공교통(K-UAM) 운용개념서 1.0, accessed August 13, 2025, https://smartcity.go.kr/wp-content/uploads/2021/09/%EC%B2%A8%EB%B6%80_%ED%95%9C%EA%B5%AD%ED%98%95_%EB%8F%84%EC%8B%AC%ED%95%AD%EA%B3%B5%EA%B5%90%ED%86%B5K_UAM_%EC%9A%B4%EC%9A%A9%EA%B0%9C%EB%85%90%EC%84%9C1.0.pdf
9. Delivery Drones Market Report 2025 - Research and Markets, accessed August 13, 2025, https://www.researchandmarkets.com/reports/5751921/delivery-drones-market-report
10. 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
11. (PDF) UAS Traffic Management (UTM) Concept of Operations to Safely Enable Low Altitude Flight Operations - ResearchGate, accessed August 13, 2025, https://www.researchgate.net/publication/303902685_UAS_Traffic_Management_UTM_Concept_of_Operations_to_Safely_Enable_Low_Altitude_Flight_Operations
12. UTM Market Size & Share Insights and Trends | 2025-2030, accessed August 13, 2025, https://www.nextmsc.com/report/utm-market-ad3043
13. Unmanned Aircraft System (UAS) Traffic Management (UTM) - FAA, accessed August 13, 2025, https://www.faa.gov/sites/faa.gov/files/2022-08/UTM_ConOps_v2.pdf
14. Unmanned Aircraft System Traffic Management (UTM) | Federal Aviation Administration, accessed August 13, 2025, https://www.faa.gov/uas/advanced_operations/traffic_management
15. Regulation 2021/664 U-space Regulatory Framework | SKYbrary Aviation Safety, accessed August 13, 2025, https://skybrary.aero/articles/regulation-2021664-u-space-regulatory-framework
16. Drone Flight Plans: How to Choose the Right Path - AgEagle Aerial Systems Inc., accessed August 13, 2025, https://ageagle.com/blog/drone-flight-plans-how-to-choose-the-right-path/
17. ANRA Technologies, accessed August 13, 2025, https://www.anratechnologies.com/home/
18. Our Work | OneSky, accessed August 13, 2025, https://www.onesky.xyz/our-work
19. UTM in Singapore: OneSky Works on Nationwide UTM Services for a Unique Urban Environment - Dronelife, accessed August 13, 2025, https://dronelife.com/2021/03/15/utm-in-singapore-onesky-works-on-nationwide-utm-services-for-a-unique-urban-environment/
20. ANRA Technologies, accessed August 13, 2025, https://www.anratechnologies.com/
21. OneSky: Uncrewed Traffic Management (UTM), accessed August 13, 2025, https://www.onesky.xyz/
22. 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
23. OneSky - - TruWeather Solutions, accessed August 13, 2025, https://truweathersolutions.com/onesky/
24. Uncrewed Traffic Management Services (UTM / U-space) - ANRA Technologies, accessed August 13, 2025, https://www.anratechnologies.com/home/anra-ctr-utm-uspace-rtm/
25. ANRA Technologies Upgrades U-Space Services with New Simulation Features - Dronelife, accessed August 13, 2025, https://dronelife.com/2024/04/11/anra-technologies-upgrades-u-space-services-with-new-simulation-features/
26. EU drone regulations: what is U-space? - Dronewatch Europe, accessed August 13, 2025, https://www.dronewatch.eu/eu-drone-regulations-what-is-u-space/
27. UTM solution for UTM Service Providers - Unifly, accessed August 13, 2025, https://www.unifly.aero/utm-utmserviceproviders/
28. IT Management: 6 Best Practices for Your On-Premise Infrastructure - Cynergy Technology, accessed August 13, 2025, https://www.cynergytech.com/stories/it-management-6-best-practices-on-premise-infrastructure/
29. Microservices Architecture Diagram Examples - DevTeam.Space, accessed August 13, 2025, https://www.devteam.space/blog/microservice-architecture-examples-and-diagram/
30. What is Unified Threat Management (UTM)? | Glossary | HPE, accessed August 13, 2025, https://www.hpe.com/us/en/what-is/unified-threat-management.html
31. Custom User Profiles for Optimizing Drone Fleet Management - MoldStud, accessed August 13, 2025, https://moldstud.com/articles/p-custom-user-profiles-for-optimizing-drone-fleet-management
32. Enterprise Business Managed Network Security - Comcast Business - Xfinity, accessed August 13, 2025, https://business.comcast.com/enterprise/products-services/managed-services/managed-security
33. Microservices Diagram: Best Practices & Examples - Multiplayer, accessed August 13, 2025, https://www.multiplayer.app/distributed-systems-architecture/microservices-diagram/
34. Real-Time Data Ingestion with Apache Kafka - Brainforge, accessed August 13, 2025, https://www.brainforge.ai/blog/real-time-data-ingestion-with-apache-kafka
35. A Survey on Networked Data Streaming With Apache Kafka - ResearchGate, accessed August 13, 2025, https://www.researchgate.net/publication/373025500_A_Survey_on_Networked_Data_Streaming_with_Apache_Kafka
36. How to use Apache Kafka to get Real-time IOT Data Analytics - Expeed Software, accessed August 13, 2025, https://www.expeed.com/get-real-time-iot-data-analytics-using-apache-kafka-and-apache-spark/
37. Processing and retrieval of geotagged unmanned aerial system telemetry - SlideShare, accessed August 13, 2025, https://www.slideshare.net/slideshow/processing-and-retrieval-of-geotagged-unmanned-aerial-system-telemetry-63887750/63887750
38. Go VS Java benchmarks, Which programming language or compiler is faster, accessed August 13, 2025, https://programming-language-benchmarks.vercel.app/go-vs-java
39. Go vs Java performance comparison - Proxify, accessed August 13, 2025, https://proxify.io/articles/go-vs-java-performance
40. Java Outperforming Go on a Simple Benchmark - Reddit, accessed August 13, 2025, https://www.reddit.com/r/java/comments/1dk6jx2/java_outperforming_go_on_a_simple_benchmark/
41. Simple data stream: Go being super slow compared to Java - Stack Overflow, accessed August 13, 2025, https://stackoverflow.com/questions/42841501/simple-data-stream-go-being-super-slow-compared-to-java
42. Sequence Diagrams - Unified Modeling Language (UML) - GeeksforGeeks, accessed August 13, 2025, https://www.geeksforgeeks.org/system-design/unified-modeling-language-uml-sequence-diagrams/
43. API Flow Diagram: Best Practices & Examples - Multiplayer, accessed August 13, 2025, https://www.multiplayer.app/distributed-systems-architecture/api-flow-diagram/
44. Drone Sequence Diagram [classic] - Creately, accessed August 13, 2025, https://creately.com/diagram/example/jfd8yau92/drone-sequence-diagram-classic
45. a-star path planning simulation for uas traffic management (utm) application - arXiv, accessed August 13, 2025, https://arxiv.org/pdf/2107.13103
46. Land-Coverage Aware Path-Planning for Multi-UAV Swarms in Search and Rescue Scenarios - arXiv, accessed August 13, 2025, https://arxiv.org/html/2505.08060v1
47. Learning-accelerated A* Search for Risk-aware Path Planning - arXiv, accessed August 13, 2025, https://arxiv.org/html/2409.11634v1
48. Using Reinforcement Learning to Improve Airspace Structuring in an Urban Environment, accessed August 13, 2025, https://www.mdpi.com/2226-4310/9/8/420
49. Using Reinforcement Learning in a Layered Airspace to Improve Layer Change Decision - MDPI, accessed August 13, 2025, https://www.mdpi.com/2226-4310/9/8/413
50. Drone Fleet Management Best Practic