들어가며
KUSITMS 기업 프로젝트를 통해 UAM 기업 Verty와 웹 기반 가상 여정 체험 서비스를 제작했다.
Verty는 UAM 기체 운항과 버티포트 운영, 교통관리 및 통합 운영시스템을 준비하고 있는 기업이다. UAM은 아직 상용화 이전 단계에 있어 일반 사용자가 실제 이용 과정과 가치를 체감할 기회가 제한적이다.
기술과 산업에 관한 정보를 제공하는 것만으로는 사용자가 UAM을 자신의 이동 경험과 연결하기 어렵다. 구체적인 탑승 과정과 이용 맥락이 없으면 UAM은 실생활의 이동수단보다 막연한 미래 기술로 인식될 가능성이 높다.
프로젝트의 목표는 예약부터 탑승과 비행, 도착까지의 여정을 웹에서 경험하게 함으로써 UAM의 이용 과정과 가치를 구체적으로 전달하는 것이었다.
기획·디자인·프론트엔드·백엔드로 구성된 팀이 5주 동안 반응형 웹 MVP를 제작했다. 나는 프론트엔드 개발자로 참여해 예약 및 지도를 담당했다.
문제 정의
자료와 UAM 관련 조사를 바탕으로 두 가지 문제를 정의했다.
첫 번째는 낮은 개념 이해도였다.
UAM이라는 용어가 아직 익숙하지 않고, 기체와 운항 기술에 관한 정보만으로는 실제 이용 방법을 파악하기 어렵다. 사용자가 기존 이동수단과의 차이와 이용 가치를 판단할 수 있는 구체적인 맥락도 부족했다.
두 번째는 체감 가능한 탑승 경험의 부재였다.
상용화 이전 단계에서는 일반 사용자가 탑승 과정을 직접 경험할 수 없다. UAM이 제공할 수 있는 시간적·경험적 가치를 체감하기 어렵고, 산업에 대한 관심이 실제 기대나 이용 의향으로 이어지기도 어렵다.
우리 팀은 다음 두 가지 가설을 설정했다.
- 가상 여정 체험은 UAM의 개념과 이용 과정을 이해하는 데 도움이 될 것이다.
- 기존 이동수단과의 비교 및 비행 경험은 UAM의 시간적·경험적 가치를 전달하는 데 도움이 될 것이다.
이를 바탕으로 예약부터 탑승·비행·도착까지의 여정을 하나의 인터랙티브한 경험으로 제공하기로 했다.
서비스 구성
사용자는 온보딩을 거친 뒤 서울 이동과 제주 여행 중 하나를 선택하며 체험을 시작한다.
서울은 도심과 공항을 연결하는 시간 절약과 편리함을 중심으로 구성했다. 제주는 이동 과정에서 경험할 수 있는 풍경과 여행의 설렘을 중심으로 구성했다.
전체 서비스 흐름은 다음과 같다.
- 온보딩
- 서울 또는 제주 여정 선택
- 탑승·하차 버티포트 선택
- 탑승 날짜와 인원 선택
- 운항편 선택
- 예약 내용 확인
- 탑승 준비
- 노선별 비행 영상 체험
- 후기 작성
담당 영역
내가 맡은 핵심 범위는 버티포트 선택부터 운항편 선택과 체크인까지 이어지는 예약 도메인이었다.
주요 작업 범위는 다음과 같다.
- 탑승·하차 버티포트, 날짜, 탑승 인원 선택
- 현재 위치 및 주변 버티포트 조회
- 출발지와 도착지에 따른 선택 가능 목록 처리
- 운항편과 좌석 상태 조회
- UAM 및 기존 이동수단의 예상 시간 비교
- 지도 마커와 경로 시각화
- 예약 내용 확인 및 체험용 예약 생성
다단계 예약의 상태 일관성
예약 플로우는 버티포트 선택, 운항편 선택, 체크인의 세 단계로 구성됐다.
예약 조건과 운항편 선택은 서로 다른 수명주기를 가진다. 이전 단계로 돌아가는 것만으로는 사용자가 입력한 값을 초기화할 필요가 없지만, 날짜와 인원 또는 버티포트가 변경되면 기존 운항편은 더 이상 유효하지 않을 수 있다.
이에 따라 화면 이동과 검색 조건 변경을 별도의 상태 전이로 처리했다.
- 이전 단계로 이동하면 기존 입력과 선택을 유지한다.
- 운항편 조회 조건이 변경되면 기존 운항편 선택을 무효화한다.
- 변경된 조건으로 다시 조회하기 전까지 이후 단계의 재진입을 제한한다.
- 운항편 조회에 성공한 경우에만 다음 단계로 전환한다.
- 빈 결과와 요청 실패는 현재 단계에서 별도의 상태로 처리한다.
빠르게 검색 조건을 변경할 때 이전 요청의 응답이 최신 결과를 덮어쓰지 않도록 요청 취소와 최신 요청 식별을 함께 적용했다.
로컬 예약 정보와 원격 요청 상태도 분리했다. 예약 초안과 현재 단계는 reducer에서 관리하고, API 데이터와 로딩·오류 상태는 각 요청 hook에서 관리했다. 이를 통해 화면 상태 변경과 네트워크 요청의 생명주기를 독립적으로 제어했다.
현재 위치와 지도 연동
현재 위치는 예약 값이 아니라 버티포트 선택을 돕는 탐색 정보로 사용했다.
브라우저에서 좌표를 확인한 뒤 주변 버티포트를 거리순으로 조회하고, 역지오코딩을 통해 상세 주소를 표시했다. 가장 가까운 버티포트를 자동으로 선택하지는 않았으며, 사용자가 목록을 확인한 뒤 실제 탑승할 버티포트를 직접 선택하도록 했다.
위치 권한이 거부되거나 위치 조회가 실패해도 전체 버티포트 목록과 기존 선택은 유지된다. 지도 SDK를 사용할 수 없는 경우에도 수동 예약 흐름은 계속 이용할 수 있도록 구성했다.
출발지와 도착지가 모두 선택되면 지도에 두 지점과 경로를 표시하고, UAM과 택시·대중교통의 예상 이동 시간을 함께 제공했다. 이동 시간 비교는 사용자가 UAM의 시간적 가치를 기존 이동 경험과 직접 비교할 수 있도록 배치했다.
지도 경로 표현
지도 경로는 Naver Maps의 네이티브 Polyline을 사용해 구현했다.
초기 DOM 기반 경로선은 지도 이동과 확대·축소, 연속적인 viewport 변경 과정에서 SDK의 projection과 React 렌더링이 어긋나는 문제가 있었다.
경로 데이터를 지리 좌표 상태로 유지하고 렌더링을 지도 SDK에 위임하는 방식으로 변경했다. 출발지와 도착지가 모두 존재하면 두 좌표의 경계를 계산해 viewport에 반영하고, 한 지점만 존재하는 경우에는 해당 좌표를 중심으로 이동하도록 규칙을 통일했다.
체험용 API 연동
예약 화면에서는 다음 데이터를 연동했다.
- 전체 및 주변 버티포트
- 출발지 기준 도착 가능 버티포트
- 도착지 기준 출발 가능 버티포트
- 운항편 및 좌석 상태
- UAM과 기존 이동수단의 예상 시간
- 체험용 예약 생성
서버 응답은 UI에서 직접 사용하지 않고 화면 전용 모델로 변환했다. 좌표와 거리, 운항 시간, 좌석 상태, 기체 모델 등을 UI가 사용하는 형식으로 정규화하고, 지원하지 않는 기체 모델은 잘못된 이미지로 대체하지 않도록 필터링했다.
예약 조회에는 캐시를 사용하지 않고 최신 상태를 요청하도록 했으며, 예약 생성이 성공한 이후에만 다음 체험 단계로 이동하도록 구성했다.
노선별 비행 경험과 후기
예약이 완료되면 선택한 노선에 맞는 비행 영상이 재생된다.
비행 영상은 탑승과 이륙, 비행, 착륙까지의 흐름을 포함한다. 서울 노선은 빠른 이동과 도심 풍경을, 제주 노선은 관광지와 여행 경험을 중심으로 구성했다.
체험이 끝나면 사용자는 후기를 작성하거나 다른 노선을 다시 체험할 수 있다. 작성한 후기는 Notion 연동 API를 통해 관리할 수 있도록 구성했다.
마치며
Verty 프로젝트는 생소한 UAM을 설명하는 데서 그치지 않고, 사용자가 예약부터 비행까지 직접 따라가며 서비스의 가치를 상상할 수 있는 경험으로 구체화한 작업이었다. 서울에서는 이동 시간의 이점을, 제주에서는 새로운 이동수단이 주는 설렘을 전달하고자 했다.
내가 담당한 예약 과정에서는 사용자의 선택, 서버 데이터, 지도 화면이 서로 어긋나지 않게 연결하는 것이 가장 큰 과제였다. 버티포트나 날짜를 바꾸면 기존 운항편 선택을 무효화하고, 위치 조회나 지도 연동에 실패하더라도 사용자가 체험을 이어갈 수 있도록 했다. 이 과정에서 화면 하나를 완성하는 것보다 여러 상태가 바뀌는 순간에도 전체 여정을 일관되게 유지하는 일이 중요하다는 것을 배웠다.
5주 동안 막연한 미래 기술로 느껴질 수 있는 UAM을 웹에서 경험할 수 있는 MVP로 구현했다. 이번 프로젝트는 제품의 목적을 사용자 흐름으로 옮기고, 그 흐름을 안정적으로 작동시키는 프론트엔드의 역할을 깊이 고민한 경험이었다.
