도심항공교통(UAM)에 대한 공개 논의 대부분은 기체, 공역, 또는 센서에 집중된다. 실무자들은 바인딩 제약이 다른 곳에 있음을 안다 — 버티포트 인허가.
이 노트는 인허가가 K-UAM 의 조용한 병목인 이유와, 그것이 소프트웨어 준비도에 의미하는 바를 설명한다.
토지 용도 변경 문제
버티포트는 한국의 계획 용어로 아직 존재하지 않는 용도다. 지자체 토지 용도 코드는 공항, 헬리포트, 그리고 차량기지를 인정한다. "버티포트" 는 인정하지 않는다. 그 범주 공백이 인허가 병목이다.
운영자는 새 패드를 열려는 순간 그 공백에 부딪힌다. 용도 변경 신청은 가장 가까운 기존 범주(보통 헬리포트)를 인용하며, 이는 헬리포트 등급 의무(근접 버퍼, 소음, 비상 접근)를 발동시킨다. 그 의무 중 일부는 버티포트 운영으로 깔끔히 이전된다 — 다른 일부, 특히 소음 envelope 과 근접 버퍼는 eVTOL 비행 프로파일과 일치하지 않으며 인허가별로 다투어야 한다.
공항으로부터 상속되는 것
버티포트는 운영자의 의지와 무관하게 공항의 문제를 상속한다. 기체가 여전히 동일한 저고도 레이어와 교차하기 때문에 조류 충돌 위험이 있다. 버티포트가 밀집 도심 지리의 민간 접근점이기 때문에 CBRN 위험이 있다. 재래식 회전익기, 드론, 응급 서비스와의 공역 통합은 기존 해법을 제공하지 않으면서 복잡성만 더한다.
소프트웨어 질문은 다음이 된다 — 버티포트 운영자가 첫날 무엇을 배포할 수 있는가? 정직한 답은 "버티포트 특화로는 많지 않다" 이다. AVIX-AI BirdThreat 같은 해법이 작동하는 이유는 그것이 상속된 공항 문제를 위해 설계되었고 버티포트 특화 인프라를 필요로 하지 않기 때문이다.
K-UAM 로드맵은 낙관적으로 읽힌다
국토교통부의 K-UAM 로드맵 2030 은 10년 말까지 200+ 버티포트가 운영되는 모습을 그린다. 그 규모에 대한 소프트웨어 준비도는 다룰 수 있는 문제다. 인허가 준비도는 그렇지 않다 — 낙관적 가정 하에서도 현재 지자체 심의 기간(인허가당 12–24개월)은 그 목표를 소프트웨어 제약이 되기 훨씬 전부터 인허가 흐름 제약으로 만든다.
이 불일치는 구조적이다. 소프트웨어 준비도는 배포에 걸쳐 누적된다. 인허가 준비도는 그렇지 않다 — 모든 인허가는 지역적이고, 모든 인허가는 맞춤이다.
우리가 그래도 이것을 게시하는 이유
UAMKT 는 인허가 정책을 작성하지 않는다. 우리는 파트너가 얻는 어떤 인허가 envelope 안에서도 작동해야 하는 소프트웨어를 작성한다. 제약을 큰 소리로 말하는 것은 배포 시점을 낙관적 로드맵 날짜가 아니라 실제 인허가 윈도우에 맞추도록 한다.
K-UAM 규제 법제화는 현재 working-group 검토 중이다. 우리는 법제화 노력에 기여할 의향이 있다 — 절차적 옵션은 Solutions overview 의 Engagement 항목을 보라.
—
문의: ceo@uamkt.com
1차 reference: 국토교통부 (2024). K-UAM Roadmap 2030.