Physix AI

요약

지하주차장을 도는 순찰 로봇을 원격으로 조종하는 관제사의 화면을 설계했습니다. 두 설계팀의 결과를 하나의 토큰 체계로 통합해, 화면 20장 · 컴포넌트 30종 · 토큰 220개의 시스템으로 정리했습니다.

20

최종 화면

1920×1080 · 다크 단일 테마

30

컴포넌트

상태별 다축 변형

220

디자인 토큰

Primitive · Semantic · Spacing · Radius · Text

홍익대학교 × 피직스에이아이 산학 연구 – 2차 연구의 기본형(A팀) 화면 설계 담당

개요

관제사는 관제실에 앉아 게임패드와 PC 모니터로 로봇을 몹니다. 여러 대의 카메라 영상, 주행 상태, 경고, 번호판 인식 결과를 오랜 시간 동시에 지켜봐야 합니다. 화면은 1920×1080 고정 해상도, 어두운 관제실을 위한 다크 단일 테마로 설계했습니다.

연구는 두 단계로 진행됩니다. 1차(2026.06–07)에서 문제와 설계 기준을 세웠고, 2차(2026.08–10)에서 기본형과 와이드형 두 팀이 병행 설계한 뒤 하나로 통합했습니다. 저는 2차의 기본형 트랙 화면 설계를 맡았습니다.

문제

1차 연구에서 정리한 핵심 이슈는 세 가지였습니다.

1. 카메라 화면들의 역할과 우선순위가 불명확하다.
2. 주행 정보와 경고의 시각적 위계가 약하다.
3. 번호판 인식 결과와 그다음 행동이 이어지지 않는다.

셋 모두 조종자의 인지 부하와 판단 부담을 키우는 문제였습니다.

리서치

• 여정 분석 – 온보딩 → 운행 준비 → 원격 주행 → 종료의 전체 여정 중 원격 주행을 가장 중요한 구간(Critical Journey)으로 정하고, 주행·상황 인지 / 번호판 확인 / 통신·예외 처리로 나눠 업무마다 5단계로 분해했습니다. 예외 상황의 핵심 인사이트는 "장애의 원인보다 '지금 차량이 안전한가, 제어가 가능한가'를 먼저 확인한다"였습니다.
• 문헌과 사례 – 선행 연구 8편과 산업 사례 4건(Vay, 현대·기아 SVM, Ottopia, Fernride)을 분석했습니다.
• 1차 약식 사용성 테스트 – 10명 내외를 대상으로 RC카와 다중 카메라, OBS, Figma UI를 결합한 환경에서 시야 · 통제력 · 임무 피드백 · 비상 대처의 네 요소를 확인했습니다.
• 개발사와의 기술 회의, 이해관계자 피드백 – 개발 제약을 설계 전에 입력으로 받고, 8월 피드백 6건을 하나씩 추적해 반영했습니다.

핵심 결정

1. 01상단 버튼의 폭은 켜진 상태에 맞춰 고정한다

   조종 중에는 버튼을 눈으로 찾지 않고 위치로 기억해 누릅니다. 상태에 따라 버튼 폭이 바뀌면 옆 버튼까지 밀려납니다.

   →8가지 상태 조합 전부에서 버튼의 x좌표가 1px도 움직이지 않습니다.

2. 02붉은 배경은 '등록되지 않은 차'에만 쓴다

   한 색은 한 가지만 뜻해야 합니다. 개발사와 확인한 인식 성능을 근거로, 드물게 생기는 인식 오류보다 등록 여부의 구분이 조종자에게 더 중요하다고 판단했습니다.

   →미인식·오인식 카드는 중립 면에 점 색으로 구분하고, 붉은 카드는 곧 '등록 안 된 차'라는 한 가지 뜻만 갖습니다.

3. 03전방 카메라를 가장 크게, 미니맵은 필요할 때만

   피드백의 첫 번째 요청이 '전방 카메라를 가장 크게'였습니다. 늘 떠 있던 미니맵이 주행에 필요한 시야를 가리고 있었습니다.

   →전방 영상을 780×616으로 키워 면적이 2.4배가 됐고, 미니맵은 MAP 버튼으로 여는 팝업으로 옮겼습니다.

4. 04알림 줄은 56px로 늘 자리를 지킨다

   조작 중에 레이아웃이 움직이는 것이 가장 위험합니다. 알림이 생길 때마다 영상이 밀리면 안 됩니다.

   →알림이 없을 때도 '정상 · 순찰 중'을 표시하며 자리를 지킵니다. 대가로 영상 높이가 888px에서 852px로 줄었고, 이 교환을 문서로 남겼습니다.

디자인

• 정보 구조 6영역 – 상단 내비게이션, 상태, 카메라 뷰, 주행·제어 바, 지도, 번호판 인식 패널.
• 상태는 색으로만 – 켜짐과 꺼짐은 색으로만 구분하고 버튼의 위치는 바꾸지 않습니다.
• 알림 3단계 – 일반(토스트), 긴급(화면 위아래의 붉은 그라데이션), 기록.
• 진입점 하나로 – 오른쪽 패널의 상태를 8가지에서 4가지로 줄였습니다. 팝오버는 버튼이 부풀어 오르듯 열리고, 후진할 때는 카메라 배치가 자동으로 바뀝니다. 초음파 거리는 mm로 표시하고 800mm에서 노랑, 180mm에서 빨강으로 바뀝니다.

디자인 시스템

›토큰 220개와 통합 과정

토큰은 Primitive 139 · Semantic 44 · Spacing 15 · Radius 6 · Text 16으로 나눴습니다. 필요한 색 램프(Amber, Blue)를 더하며 Primitive는 128개에서 139개가 됐습니다. 토큰을 층으로 나누는 이유는 변경 비용입니다 – 값을 한 곳에서 바꾸면 모든 화면이 따라옵니다.

두 팀의 결과를 합칠 때는 다른 팀의 디자인 언어를 유지한 채 구조를 우리 시스템으로 다시 짰습니다. 하드코딩된 색 431개를 토큰에 연결했고, 전수 감사 스크립트로 Primitive 직접 참조 0건, 스타일 미적용 텍스트 0건, 잘린 텍스트 0건을 확인했습니다. 남은 미연결 274건은 의도된 예외로 목록을 남겼습니다. 그 과정에서 사라진 화면 11장과 라벨 20개를 복구하고, 잘린 텍스트 50개를 다시 쟀습니다.

결과

0px

상태 조합 8가지에서 레이아웃 이동

2.4×

전방 카메라 면적

6 / 6

이해관계자 피드백 반영

1차 시안 6종이 2차 최종안 20장이 됐고, 기본형과 와이드형 두 안을 각각 라이트·다크 버전으로 2026년 9월 2일 개발사에 전달했습니다.

회고

• 색은 발생 빈도 × 조치 필요성에 배분한다. 자주 생기는 것에 강한 색을 쓰면 정말 중요한 것이 묻힙니다.
• 개발 제약은 설계가 끝난 뒤의 장애물이 아니라, 설계 전의 입력이다.
• 비교란 변수를 하나로 고정하는 일이다. 두 안을 공정하게 비교하려고 한 번에 하나만 바꿨습니다.
• 통합은 복사가 아니라 번역이다.