Feasix AI

요약

관제 화면에서 가장 중요한 것은 모든 정보를 보여주는 일이 아니었다. 조종자가 지금 로봇을 제어할 수 있는지 먼저 판단하게 만드는 일이었다.

20

최종 화면

산출물 · 1920×1080 · 다크 단일 테마

30

컴포넌트

산출물 · 상태별 다축 변형

220

디자인 토큰

산출물 · Primitive · Semantic · Spacing · Radius · Text

홍익대학교 × 페이식스에이아이 산학 연구 – 2차 연구의 기본형(A팀) 화면 설계와 두 팀 산출물 통합

개요

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

정식 연구명은 「Vision AI 기반 이동형 로봇 원격 조종 UX/UI 개선을 위한 기초 설계」다. 연구는 두 단계로 나눴다. 1차(2026.06–07)에서 문제와 설계 기준을 세웠고, 2차(2026.08–10)에서 기본형과 와이드형 두 팀이 병행 설계한 뒤 하나로 통합했다. 나는 2차의 기본형 트랙 화면 설계를 맡았다.

날짜는 두 개다. 프로젝트에는 2026년 6월 1차 연구부터 참여했고, 홍익대학교 학부연구생(Undergraduate Student Researcher)으로 정식 임용된 것은 2026년 8월이다. 앞은 참여 시점, 뒤는 임용 시점이다.

문제

1차 연구에서 정리한 UX 이슈는 세 가지였다.

1. 카메라 화면의 역할과 우선순위가 불명확하다. 전·후방과 보조 카메라가 비슷한 비중으로 놓여 화면 사이 시선 이동이 반복된다.
2. 주행 정보와 경고의 시각적 위계가 약하다. 속도와 거리처럼 계속 확인하는 정보와 즉시 확인해야 하는 경고가 구분되지 않는다.
3. 번호판 인식 결과와 그다음 행동이 이어지지 않는다. 결과는 표시되지만 재촬영이나 수동 확인 같은 다음 동작은 안내되지 않는다.

1차 연구의 결론은 "현재 인터페이스가 조종자의 인지 부하와 의사결정 부담을 키운다"였다. 문헌과 화면 분석에서 나온 결론이고, 측정값은 아니다.

핵심 결정

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

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

   →켜진 상태의 폭(AEB 186px, REC 260px)으로 폭을 고정했다. 8가지 상태 조합 전부에서 버튼의 x좌표가 1px도 움직이지 않는다. 전달한 파일에서 좌표를 직접 재서 확인했다.

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

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

   →전방 영상을 780×616으로 키워 면적이 2.4배가 됐다(파일 실측). 미니맵은 MAP 버튼으로 여는 팝업으로 옮겼다.

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

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

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

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

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

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

›나머지 결정 5건

• 패널의 제목은 상태 단어가 아니라 번호로 바꿨다 – 번호판 인식 패널인데 카드 제목이 「미등록」「미인식」이었고 정작 번호가 화면에 없었다. 제목을 인식된 번호로 두고 상태는 오른쪽 꼬리표로 내렸다. 실패한 건은 「번호 인식 실패」로 명시했다.
• 알림 기록의 위계를 뒤집었다 – 시각이 가장 크고, 무슨 일이 있었는지가 가장 작게 적혀 있었다. 메시지 16px, 부연 12px, 시각 12px 우측 정렬로 바꿨다. 절대 시각(02:14)은 상대 시각(3분 전)으로 바꿨다. 조종자는 '몇 시'보다 '무슨 일이'를 먼저 알아야 한다.
• 같은 기능의 진입점을 하나로 합쳤다 – 설정이 큰 창과 우측 패널 두 곳에, 알림 기록도 팝업과 패널 두 곳에 있었다. 설정은 큰 창 하나, 알림 기록은 상단바 팝업 하나로 통일했다. 진입점이 둘이면 사용자가 매번 어느 쪽인지 판단해야 한다.
• 팝오버는 누른 버튼 자리에서 자란다 – 창이 알림 줄 아래에 떠서 어느 버튼에서 나왔는지 알 수 없었다. 창의 상단을 버튼 상단(y=20)에 맞추고 버튼 중심에 가로 정렬했다. 창 머리에 같은 아이콘을 남겨 출처를 잇는다. 되돌릴 수 없는 동작(재연결, 제어권 전환)만 중앙 모달로 띄운다.
• 접어도 남길 것을 정했다 – 레일(56px) · 완전 숨김 · 영상 위에 떠 있는 알약 세 안을 비교했다. 완전 숨김은 영상 96px을 더 얻는 대신 '지금 몇 건 밀렸나'를 잃는다. 레일을 택했다. 접어도 인식 켜짐 여부와 미등록 건수는 남긴다.

과정

리서치

• 원격 주행으로 좁혔다 – 거시 여정은 온보딩 → 운행 준비 → 원격 주행 및 모니터링 → 운행 종료 네 단계다. 주요 조종 업무와 UX 이슈가 원격 주행에 몰려 있어 이 구간을 핵심 분석 구간(Critical Journey)으로 정했다. 원격 주행은 다시 주행·상황 인지 / 번호판 확인 / 통신·예외 처리 세 업무로 나눴다. 업무마다 미시 여정 5단계로 쪼개 주요 활동, 필요 정보, 사용자 판단, 현재 문제, 시사점을 표로 정리했다.
• 여정 분석의 인사이트 3개 – 조종자는 차량을 조작하는 일보다 여러 화면을 동시에 확인하는 데 더 많은 집중을 쓴다. 결과를 보여주기보다 현재 상태를 분명히 이해시키는 편이 중요하다. 통신 이상에서는 장애의 원인보다 '지금 차량이 안전한가, 제어가 가능한가'를 먼저 확인한다.
• 설계 기준 3개 – 카메라 위계 및 주행 시야 확대, 업무 목적에 따른 정보 그룹화, 미인식 및 비상상황 대응 지원. 선행 연구 8편과 산업 사례 4건을 근거로 1차 연구에서 세웠고, 2차 화면 설계 전체의 기준이 됐다.
• 1차 약식 사용성 테스트 – 10명 내외가 참여했다. RC카와 다중 카메라, OBS Studio, Figma UI를 결합한 환경에서 확인했다. 차량을 직접 보지 못하는 상태를 만들어 화면만으로 조종하게 했다. 확인한 것은 시야, 차량 통제력, 임무 피드백, 비상 대처 네 가지다.
• 개발 제약을 설계 전에 받았다 – 개발사와 기술 회의를 열어 설계 방향의 구현 가능 여부를 먼저 확인했다. 제약을 설계가 끝난 뒤의 장애물이 아니라 설계 전의 입력으로 받았다. 이해관계자 피드백 6건은 하나씩 추적해 반영했다.

›선행 연구 8편과 산업 사례 4건

설계 기준마다 근거로 삼은 문헌과 사례는 다음과 같다.

• 01 카메라 위계 및 주행 시야 확대 – Gnatzig(2013), Tener & Lanir(2022), Wolf(2025), 그리고 현대·기아의 SVM. Gnatzig은 단일 영상 대신 센서 융합 디스플레이로 주행 상태를 통합해 보여주라고 제안한다. SVM은 왜곡 보정과 시점 변환, 영상 합성으로 카메라 네 대를 하나의 통합 뷰로 합친 양산 사례다.
• 02 업무 목적에 따른 정보 그룹화 – Wolf(2025), Kettwich(2021).
• 03 미인식 및 비상상황 대응 지원 – Tener & Lanir(2025), Parasuraman(2017), Fernride. Parasuraman은 네트워크 연결 상태를 영상 주변의 색상 띠로 표시하는 방식을 제시한다. Tener & Lanir(2022)의 전문가 인터뷰 14건에서는 차량에서 물리적으로 떨어져 감각 피드백이 사라지는 점이 원격 조종의 주요 난점으로 꼽혔다.

산업 사례 4건은 Vay(조종자가 차에 타지 않고 화면과 음향만으로 주행하는 상용 원격운전), 현대·기아 SVM, Ottopia(다중 화면 기반 원격조종 콘솔), Fernride(네트워크 본딩과 예측, 엣지 케이스에서 정지 후 호출)다.

디자인

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

디자인 시스템

두 팀이 병행 설계한 결과를 하나의 토큰 체계로 통합했다. 다른 팀의 디자인 언어는 유지하고 구조만 우리 시스템으로 다시 짰다. 하드코딩된 색 431개를 토큰에 연결했다.

›토큰 220개와 통합 과정

토큰은 Primitive 139 · Semantic 44 · Spacing 15 · Radius 6 · Text 16으로 나눴다. 필요한 색 램프(Amber, Blue)를 더하며 Primitive는 128개에서 139개가 됐다. Semantic 계층은 원래 값이 전부 흰색인 껍데기 4개였다. 이 계층을 44개 토큰으로 채워 Primitive를 참조하게 다시 설계했다. 토큰을 층으로 나누는 이유는 변경 비용이다. 값을 한 곳에서 바꾸면 모든 화면이 따라온다.

하드코딩된 색 431개를 토큰에 연결했고, 전수 감사 스크립트로 Primitive 직접 참조 0건, 스타일 미적용 텍스트 0건, 잘린 텍스트 0건을 확인했다. 남은 미연결 274건은 의도된 예외로 목록을 남겼다.

스크립트로 한 번에 옮기자 부작용이 대량으로 생겼다. 사라진 화면 11장과 라벨 20개를 복구하고, 잘린 텍스트 50개를 다시 쟀다. 마스터를 고쳐도 화면에 반영되지 않는 일도 있었다. 상단바 8변형에 인스턴스 override가 걸려 있었고, 32곳에 직접 적용해 풀었다. 그 뒤로는 마스터를 고치기 전에 override가 있는지 먼저 확인한다. 숨긴 노드가 트리에서 사라져 수정할 수 없는 건도 있었다. 마스터에서 그 노드를 지우고 다시 만들어 id를 바꿔 override를 끊었다. 위 숫자는 모두 산출물의 규모다.

결과

0px

상태 조합 8가지에서 레이아웃 이동 · 파일 실측

2.4배

전방 카메라 면적 · 파일 실측

6 / 6

이해관계자 피드백 반영 · 산출물

1차 시안 6종이 2차 최종안 20장이 됐다. 최종 산출물은 화면 20장 · 컴포넌트 30종 · 디자인 토큰 220개다. 두 팀이 병행 설계하며 만든 하드코딩 색상 431개를 이 토큰 체계로 흡수했다. 기본형과 와이드형 두 안을 각각 라이트·다크 버전으로 2026년 9월 2일 개발사에 전달했다.

사람이 개입하는 지점

• AI가 하는 일 – 번호판 인식 AI가 차량을 등록 · 미등록 · 불확실 · 미인식으로 분류해 결과를 화면에 표시한다.
• 사람이 하는 일 – 인식 결과는 조종자가 최종 확인한다. 미인식이 생기면 조종자가 로봇을 그 위치로 다시 이동시켜 재촬영한다. 설계 기준 03(미인식 및 비상상황 대응 지원)에 따라 화면에 재촬영 기능을 배치했다. 통신 이상과 비상 상황은 토스트로 즉시 알려 사람이 바로 판단하게 했다.

회고

맞았던 것

• 개발 제약은 설계가 끝난 뒤의 장애물이 아니라, 설계 전의 입력이다. 기술 회의에서 구현 가능 여부를 먼저 확인하고 화면을 그렸다.
• 상시 주시 화면에서 좌표는 상태가 바뀌어도 그대로여야 한다. 버튼을 위치로 기억해 누르는 사용자에게는 정보보다 자리가 먼저다. 8가지 상태 조합에서 이동이 0px이다.
• 색은 발생 빈도 × 조치 필요성에 배분한다. 자주 생기는 것에 강한 색을 쓰면 정말 중요한 것이 묻힌다.
• 통합은 복사가 아니라 번역이다. 다른 팀의 디자인 언어는 남기고 구조만 우리 체계로 옮겼다.
• 예외 화면은 원인 진단이 아니라 안전 확인으로 시작한다. 여정 분석에서 조종자는 장애의 원인보다 제어 가능 여부를 먼저 본다는 것이 드러났다. 화면의 첫 줄을 거기에 맞췄다.

틀렸던 것

• 상태를 잘 보여주면 다음 행동은 따라온다고 봤다. 아니었다. 번호판 패널에는 상태 단어만 있고 정작 번호가 없었다. 결과를 보여주는 일과 다음 동작을 말하는 일은 다른 일이었다.
• 대량 변경은 스크립트로 끝난다고 봤다. 인스턴스 override와 텍스트 잘림이 대량으로 생겼다. 화면 11장과 라벨 20개를 복구하고 잘린 텍스트 50개를 다시 쟀다. 자동화가 만든 오류는 자동화로만 잡힌다는 것을 그때 배웠다.
• 조합안을 늘리면 비교가 쉬워진다고 봤다. 늘릴수록 무엇이 달라졌는지 읽기 어려워졌다. 한 번에 하나만 바꿔 비교하는 쪽으로 다시 줄였다.

다음에 확인할 것

• 인지 부하와 오류율. 아이트래킹이 진행 중이고, 결과가 나오면 이 페이지의 숫자를 채운다.
• 기본형과 와이드형 중 어느 배치가 실제 조종에서 나은지. 2차 사용자 조사에서 확인한다.
• 알림 줄을 늘 띄우려고 영상 높이 36px을 내준 교환이 옳았는지. 조종자가 어느 쪽을 택하는지 아직 모른다.
• 접힘 상태의 레일에 남긴 정보가 충분한지. 인식 켜짐 여부와 미등록 건수만으로 되는지 확인하지 않았다.