Glide

요약

차가 흔들리기 2–7초 전에 알려, 탑승자가 스스로 대비하게 하는 자율주행 멀미 저감 시스템이다. 같은 멀미 지표(MSDV)를 센서 보드 · 웹 관제 · iOS 앱 세 곳에 같은 식으로 구현했다.

2 → 7초

흔들리기 전에 알리는 시간

설계값 · 속도에 연동, 실제 탑승으로 재조정

3곳

같은 멀미 지표가 도는 곳

센서 보드 · 웹 콘솔 · iOS 앱

8종

상황에 따라 바꾸는 알림 채널

산출물 · 우선순위 5단계

역할 – 문제 정의 · UX 설계 · 알고리즘 · 웹 · iOS · 펌웨어 · 웨어러블 목업 (1인)

개요

먼저 알리는 것이 이 제품의 전부다. 차가 흔들린 뒤에 달래지 않고, 흔들리기 2–7초 전에 알린다. 몸을 먼저 대비시키려는 설계다.

예고만으로는 끝나지 않는다. 자율주행차의 탑승자는 앞을 보지 않는다. 영상을 보고, 일하고, 마주 앉는다. 화면을 보고 있지 않은 사람에게 화면은 채널이 아니다. 그래서 움직임을 먼저 예측하고, 그다음에 지금 그 사람이 실제로 알아차릴 수 있는 감각을 고른다. 이 두 문장이 시스템의 골격이다.

제품은 네 레이어로 나뉜다. L0 경로 지능, L1 실내 제어, L2 감각 신호, L3 웨어러블이다. 차량 제어 권한이 필요한 L1이 조직적으로 가장 어렵다. 권한 없이 되는 L0과 L2부터 단독으로 성립하도록 나눴다.

웹 관제 콘솔은 따로 정리했다 – Glide Console

문제

• 원인 – 시각과 전정기관이 충돌한다. 자율주행에서는 전방을 보지 않는 시간, 비운전 활동, 마주 보는 좌석이 모두 늘어난다. 마주 보는 좌석 배치가 멀미를 유의미하게 늘린다는 연구가 있다(MDPI, 2025).
• 규모 – 자율주행 탑승자의 6~10%가 중등도 이상의 멀미를 정기적으로 겪는다는 연구가 있다(Sivak & Schoettle). 미국인의 최대 3분의 1이 차멀미를 겪는다는 조사도 있다(NIH · Mcity).
• 역설 – 멀티태스킹을 피하면 멀미는 해결된다. 하지만 그 순간 자율주행의 핵심 가치가 사라진다.

핵심 결정

1. 01움직임 뒤가 아니라 앞에서 말한다

   움직임을 감지해 화면을 보정하는 방식은 이미 여럿 있다. 가장 방어할 수 있는 지점은 감지가 아니라 예고라고 봤다. 예고가 있으면 탑승자가 흔들림에 그냥 쏠리는 대신 스스로 자세를 잡는다.

   →차가 흔들리기 2–7초 전에 알린다(설계값). 커브에서는 진동을 위에서 아래로 흐르듯 줘서 탑승자가 커브 안쪽으로 고개를 기울이게 한다(Active Head Tilt).

2. 02정보를 줄이는 대신, 전달하는 감각을 바꾼다

   뒤를 보고 앉았거나 영상을 보는 중이라면 화면 알림은 닿지 않는다. 알림이 많으면 무시하고, 한번 무시하면 신뢰가 무너진다.

   →역방향 좌석이면 시각을 모두 끄고 진동과 소리로 전한다. 다른 활동 중이면 글자 대신 조명과 진동으로 전한다. 임계값을 넘을 때만 말하고, 5초 안에 같은 움직임이 반복되면 두 번째부터는 화면을 끄고 진동만 남긴다. 알림 채널 8종, 우선순위 5단계(산출물).

3. 03시간과 편안함의 교환은 탑승자가 고른다

   가장 빠른 길과 가장 편한 길 중 무엇이 최선인지는 상황마다 다르다. 시스템이 대신 정할 문제가 아니라고 봤다.

   →Rush · Cruise · Glide · Pure Glide 네 단계 슬라이더를 두었다. 가장 편한 경로는 18% 더 걸렸다(시뮬레이션). 개입 단계에는 언제나 되돌리기 버튼을 함께 뒀다.

4. 04설계값보다 실제 탑승 체감을 따른다

   처음 정한 예고 시간 1.5 / 2 / 3초는 실제로 타 보니 늦었다. 대비할 시간이 없었다.

   →예고 시간을 2 / 3 / 5 / 7초로 올리고 속도에 연동했다(설계값). 예고 거리는 최소 40m로 두었다(설계값). 숫자를 지키는 대신 설계 문서를 고쳤다.

5. 05정확도보다 프라이버시를 앞에 둔다

   멀미 지표는 클라우드 없이 폰에서 적분한다. 그러면 원본 센서 데이터가 서버로 갈 이유 자체가 없다. 애초에 보내지 않은 데이터는 규제 대상도 아니다.

   →건강 데이터 연동을 뺐고 얼굴 영상은 저장하지 않는다. 대가로 감지 정확도를 잃었다. 그 손실은 양산 단계에서 차량 내장 센서로 되찾는 편이 맞다고 봤다.

›침묵의 규칙, 13단계 개입, 예고 거리 공식과 멀미 지표

침묵 – '침묵 = 신뢰'를 원칙으로 적었다. 직진 정속 구간에서는 알림이 0이다. 계속 말하는 시스템은 곧 꺼진다.

13단계 개입 – 개입은 심각도에 비례한다. 상시 노출 버튼(D0)에서 시작해 제안, 자동 적용 후 통보를 거쳐 정차와 재출발(D12)까지 13단계다. 모든 단계에 되돌리기 버튼을 둔다. 회복 프로토콜은 이와 별도로 3단계다. 멀미 지표가 10을 넘으면 화면을 어둡게 하고 시트를 리클라이닝한다(설계값 38도). 18을 넘으면 정차할 안전한 위치를 찾는다.

예고 거리 – max(40m, 속도 × 예고 시간 × 민감도).

멀미 지표(MSDV) – 가속도를 제곱해 시간에 따라 누적하고, 0~100의 Glide Score로 바꾼다. 상태 경계는 4 · 10 · 18이다(설계값). 센서 보드, 웹 콘솔, iOS 앱이 같은 식을 쓴다. 보드에서 잰 값과 앱이 보여주는 값이 같은 언어로 읽힌다.

이름이 같은 두 점수 – 경로 점수는 타기 전의 예측이고, 주행 점수는 타는 중의 누적이다. 이름은 같지만 공식이 다르다.

아직 설계안 – 멀미와 시간의 가중치를 비용 함수로 풀고, 최적해 대신 슬라이더 위의 한 점을 사용자가 고르게 한다. 이 구조는 아직 설계안이다. 구현하지 않았다.

과정

리서치

• 측정 지표 – 국제 표준(ISO 2631-1)에 뿌리를 둔 MSDV를 골랐다. 멀미를 재는 세 방식(MSDV, MISC, FMS)을 비교한 결과다. 표준 지표여야 외부와 같은 언어로 이야기할 수 있다.
• 경쟁 분석 – 비어 있는 것은 기술이 아니라 통합이었다. Apple Vehicle Motion Cues, ClearMotion, Bosch, Toyota, Holoride를 비교했다. 측정, 예측, 예고, 설명이 한 흐름으로 이어진 곳은 없었다. 이 영역은 선행기술이 밀집해 있다. '원천 기술'이라고 부르지 않는다.
• 검증 방법 – 주관 보고만으로는 판단할 수 없었다. 물리(IMU 기반 MSDV), 생체(심박·머리 자세), 주관(MISC·FMS), 행동(고개 숙임·손-입 가림 제스처를 CV로 감지), 이 네 축을 함께 봤다. 네 축이 같은 방향을 가리킬 때만 효과가 있다고 판정하도록 설계했다. 네 축은 모두 구축했지만 표본이 적어 통계적 유의성은 아직 없다.
• 데이터 – Tmap 경로와 POI, OSM/Overpass, 서울 TOPIS를 실제로 붙였다.

디자인

• 설계 원칙 다섯 가지 – 예고는 골든타임 · 침묵 = 신뢰 · 임계값에서만 발화 · 감각 채널의 우선순위 · 탑승자를 탓하지 않는 말투("모실게요").
• 햅틱 – 225ms 켜짐, 100ms 꺼짐, 225ms 켜짐 패턴이다. 실제로 타 보며 조율했다. 방향마다 세기 곡선이 다르다. 커브에서는 진동을 위에서 아래로 흘려 고개를 커브 안쪽으로 기울이게 한다. 흔들림에 그냥 쏠리는 대신 스스로 자세를 잡게 하는 것이다.
• 화면 – 차량 화면 5가지 상태, 휴대폰 상단 알림(Dynamic Island) 6가지 상태, 위젯 3종과 실시간 현황 2종, 알림 문구 50개 이상이다(산출물).
• 하드웨어가 UX에 거는 제약 – 오버헤드 모니터는 목을 들게 해서 오히려 멀미를 유발할 수 있다. 그래서 이 화면의 정보 밀도를 가장 낮게 잡았다.

프로토타입

세 부분이 같은 멀미 지표로 움직인다. 보드는 실제 움직임을 재고, 콘솔은 그것을 보며 조율하고, 앱은 탑승자에게 전한다. 보드와 앱은 직접 붙지 않는다. 웹을 경유한다.

• 센서 보드 – Arduino와 MPU6050 두 개(차량용 · 머리용), 좌우 진동 모터. 50Hz로 측정하고 시작할 때 200개 샘플로 보정한다.
• 웹 관제 콘솔 – 멀미 지표를 지도 위에서 보고, 사람이 뒤에서 시나리오를 재현하는 실험 도구다.
• iOS 앱 – SwiftUI, CoreMotion, 에어팟의 머리 움직임 센서, 햅틱. 빌드는 통과했다. TestFlight 배포는 아직이다. 프라이버시 매니페스트와 권한 정리는 끝냈고 남은 것은 유료 개발자 계정과 서명이다.

›센서 보드와 웨어러블 사양

보드 – Arduino, MPU6050 두 개, MAX30102 심박 센서, 좌우 진동 모터. 50Hz 측정, 시작 시 200개 샘플 보정. 심박은 연구용 보드에서만 잰다. 소비자용 iOS 앱은 건강 데이터를 쓰지 않는다.

차량 화면 – Waveshare ESP32-S3-Touch-AMOLED-1.32, 466×466 오버헤드 모니터, LVGL V8.

웨어러블 목업 – OpenSCAD로 파라메트릭 모델을 잡고 Fusion 360에서 곡면을 다듬어 Bambu Studio로 슬라이싱했다. 이어피스는 유양돌기에 닿는 진동 모터(21×30×3mm)를 쓴다. 오픈형 이어폰의 착용 구조를 먼저 조사했다. 비전 밴드는 관자놀이에 LRA 두 개를 두고 따로 제어한다. 이어훅 곡선이 끊겨 hull() 체인 방식으로 바꿨다. 실제 제품의 착용 구조를 먼저 보는 편이 빨랐다.

iOS – CMHeadphoneMotionManager로 에어팟의 머리 자세를 받고, AVAudioEnvironmentNode로 공간음을 만든다. TrueDepth 영상은 저장하지 않는다.

활동

연구 콘솔

알고리즘이 완성되기 전에 예고와 침묵부터 검증해야 했다. 그래서 실험 도구를 먼저 만들었다. 사람이 뒤에서 개입 시점과 강도를 조작하고, 탑승자에게는 자동으로 보이게 하는 도구다. 센서, 시뮬레이션, 오디오, 햅틱, 비전을 한 화면에서 맞춘 이 콘솔은 따로 정리했다 – Glide Console

결과

−78%

가다 서다 (Stop-Go) · 시뮬레이션

−77%

최단 경로 대비 멀미 지표 MSDV · 시뮬레이션

+18%

추가 소요 시간 · 시뮬레이션

같은 구간을 Glide를 켠 상태와 끈 상태로 주행시켜 MSDV 누적 곡선을 비교한 값이다. 비교를 돌린 도구는 연구 콘솔의 시뮬레이션 엔진이다.

사람이 개입하는 지점

• 자동 – 멀미 지표(MSDV)를 계속 잰다. 임계값을 넘기 전에 먼저 알린다.
• 사람 – 개입은 심각도에 비례한다. 가벼운 제안에서 시작해 자동 적용 후 통보, 필요하면 정차까지 13단계다. 모든 단계에 되돌리기 버튼이 있다. 시간과 편안함을 맞바꾸는 결정은 언제나 탑승자가 한다.
• 침묵도 설계 – 임계값 아래에서는 말하지 않는다. 계속 말하는 시스템은 곧 꺼진다.

회고

맞았던 것

• 하나의 지표를 세 곳에 같은 식으로 구현한 것. 보드에서 잰 값과 콘솔이 그린 곡선과 앱이 보여주는 점수가 같은 언어로 읽혔다. 세 곳의 공식이 달랐다면 어느 값을 믿을지부터 다퉜을 것이다.
• 예고를 제품의 중심에 둔 것. 감지와 완화는 이미 여럿이 한다. 예고로 탑승자의 자세를 바꾸는 쪽이 이 제품이 방어할 수 있는 지점이었다.
• 데모는 최악의 환경을 가정해 만든 것. 센서가 죽었을 때 가짜 센서 경로가 시연을 살렸다.

틀렸던 것

• 설계값을 몸보다 믿었다. 예고 시간 1.5 / 2 / 3초는 문서에서는 충분했고 실제로 타 보니 늦었다. 지켜야 할 것은 숫자가 아니라 경험이었다.
• 보드와 앱이 직접 붙을 줄 알았다. 모션 센서가 I2C에서 인식되지 않았다. 지금도 보드는 웹을 경유한다.
• UX의 일관성 문제를 화면 문제로 봤다. 대개 정보 구조의 문제였다. 여러 곳에 흩어진 차량 설정 화면을 하나의 공통 컴포넌트로 합쳤다.
• 소비자용 호출 앱을 먼저 만들 수 있다고 봤다. 방향을 자동차 회사에 넣는 SDK와 차량에 상관없이 쓰는 동반 앱으로 바꿨다. B2C는 지역에 묶이고 B2B는 그렇지 않다. 그리고 실험용으로 만든 관제 도구가 이미 고객사가 쓸 화면이었다.

다음에 확인할 것

• 실차 대조 실험. 지금 효과 수치는 전부 시뮬레이션이다. 같은 구간을 실제 차량에서 A/B로 돌려야 한다.
• 네 축이 같은 방향을 가리키는지. 축은 모두 만들었다. 표본이 부족하다.
• TestFlight 배포. 남은 것은 유료 개발자 계정과 서명이다.
• 블루투스 직접 연동과 개인화 모델. 사람마다 예고 시간이 달라야 하는지 아직 모른다.