🤖 경비로봇 에스코트 신기능 개발

📌 프로젝트 개요

• 로봇이 목적지까지 길안내를 하며, 로봇 상태에 따라 사용자에게 음성 및 화면 안내를 제공하는 경비 로봇 전용 서비스입니다.
• 대기, 이동, 도착, 혼잡, 일시정지, 경로 장애 등 로봇의 상태 변화를 실시간으로 수신해 화면을 전환하고,
  상황에 맞는 음성 안내를 함께 제공하여 보다 명확한 에스코트 경험을 구현하였습니다.
• 로봇이 에스코트를 수행 중일 때는 메인 화면 이동 및 기타 콘텐츠 이용이 제한되며,
  자동 복귀 이후에 정상적으로 사용할 수 있도록 설계하여 콘텐츠 안정성을 높였습니다.
• 이동 시작, 일시 정지, 목적지 변경, 원위치 복귀 등의 상태는 미들웨어와 합의한 규격으로 주고받으며,
  UI 전환뿐 아니라 로봇 하드웨어의 움직임 제어와도 연결됩니다.
• 안내가 끝난 뒤 로봇이 원위치로 돌아가는 복귀 구간까지 상태를 정의하여,
  복귀 중 일시정지, 재개, 중단도 안내 구간과 동일하게 처리되도록 구성하였습니다.

🧑‍💻 주요 기여

• 에스코트 기능의 기획에 참여하고, 프론트엔드 개발을 단독으로 담당하였습니다.
• 신규 콘텐츠의 성공적인 시연 및 상용화를 이끌었습니다.
• 콘텐츠와 미들웨어 사이의 통신 규격을 미들웨어 팀과 함께 정의하였습니다.
  전달 변수, 로봇 제어 명령, 상태 전이 이벤트를 시나리오 규격 문서로 관리했습니다.
  • 안내 및 복귀 구간에 걸친 상태 42종 중, 화면 전환이 필요한 32종을 콘텐츠에서 처리하도록 나누었습니다.
  • 콘텐츠는 iframe 내부에서 동작하며, postMessage 기반 메시지 규격으로 부모 윈도우와 통신하고
    부모가 이를 JSON-RPC over WebSocket 호출로 변환하는 2단 구조입니다.
  • 명령 전송과 이벤트 수신을 각각 별도 계층으로 두어, 화면 코드가 전송 방식에 직접 의존하지 않도록 구성했습니다.
• 상황에 맞는 TTS (Text-to-Speech) 음성 안내를 위해, 재생과 중단을 규격의 액션으로 위임하고
  콘텐츠는 재생 완료 이벤트를 받아 다음 화면으로 전환하도록 구현하였습니다.
  문장 길이나 언어에 관계없이 안내와 화면이 어긋나지 않습니다.
• 로봇이 전송하는 픽셀 좌표를 WebSocket으로 수신해, 도면 이미지 위 Canvas 2D 레이어에
  현위치와 목적지 마커를 직접 렌더링하였습니다.
  • 화면별로 도면 이미지 크기가 달라, 두 이미지의 가로, 세로 비율을 각각 좌표에 적용해 보정했습니다.
• 다국어(한/영/중) UI 텍스트, 음성 안내, 이미지 리소스를 제공하였습니다.
• 해당 프로젝트는 경비 로봇 사업이 확장되는 계기가 되었으며,
  기존 누적 4곳이던 도입이 이후 2년간 16개 고객사로 확대되어 비즈니스 모델로 안착하는 데 기여하였습니다.

🔧 기술 선택 및 설계 고민

문제 상황

• 에스코트 기능은 대기, 이동, 혼잡, 도착, 일시정지, 경로 장애, 복귀 등 40종이 넘는 상태를 처리해야 했습니다.
  각 상태마다 UI 화면 구성, TTS 음성 안내, 미들웨어 제어 명령이 모두 달랐고,
  초기에는 상태값을 단일 변수로 관리하며 if-else 분기로 처리했습니다.

• 상태가 늘어날수록 분기 로직이 복잡해졌고, 같은 상태 확인 로직이 UI, TTS, 미들웨어 각각에 중복으로 흩어지기 시작했습니다.
  특히 타이머 기반 이벤트가 문제였습니다.
  목적지 도착 후 자동 복귀, 장애물 감지 후 TTS 안내 -> 대기 -> 복귀로 이어지는 로직이
  서로 충돌하며 예상치 못한 동작이 반복됐습니다.

해결 방법

• 상태 어휘를 미들웨어와의 계약으로 보고, 콘텐츠 편의로 줄이지 않았습니다.
  미들웨어 입장에서 안내 중 TTS와 복귀 중 TTS는 서로 다른 하드웨어 상태이므로
  별개 신호여야 했고, 규격을 임의로 통합하면 상대 상태 머신이 깨지기 때문입니다.

• 대신 콘텐츠 안에서 다음과 같이 정리했습니다.

  • 상태 전환의 진입점을 하나로 통합하여, 어떤 상태가 들어와도 같은 경로로 화면이 바뀌도록 했습니다.
  • 상태별 처리를 개별 핸들러로 분리해, 상태 추가 및 수정이 다른 상태에 영향을 주지 않도록 했습니다.
  • 화면 동작이 동일한 상태는 핸들러를 공유해 중복 코드를 없앴습니다.
    (TTS 반복 안내 4종 -> 핸들러 1개)
  • 콘텐츠->플랫폼 명령과 플랫폼->콘텐츠 이벤트를 각각 별도 계층으로 두어,
    화면 코드가 통신 형식에 직접 의존하지 않도록 했습니다.

• 정리 이후 수정 범위가 명확해졌고, 타이머 이벤트 간 충돌 문제도 해소되었습니다.

🔥 트러블슈팅

상태 증가로 인한 설계 붕괴 -> 재설계

• 레퍼런스 없이 처음부터 설계하는 신규 프로젝트였습니다.
  초기 구조로는 상태가 늘어날수록 에러가 반복됐고, 결국 설계 단계부터 다시 잡아가는 결정을 내렸습니다.
  뒤늦은 재설계였지만, 상태 전환 경로를 하나로 모으고 나서 이후 상태 추가와 수정이 훨씬 수월해졌습니다.

안내와 화면의 어긋남

• 음성 안내가 끝나기 전에 화면이 넘어가거나, 안내가 끝났는데도 화면이 멈춰 있는 문제가 있었습니다.
  재생 시간을 타이머로 추정하면 문장 길이와 언어(한/영/중)에 따라 실제 재생 시간이 달라져
  어긋남을 없앨 수 없었습니다.
  재생을 플랫폼에 위임하고 완료 이벤트를 받아 다음 화면으로 넘기는 방식으로 바꾸어,
  문장 길이와 무관하게 항상 맞아떨어지도록 해결했습니다.

실제 환경과 테스트 환경의 차이

• 본사 공간만으로는 로봇이 실제로 이동하는 환경을 재현하기 어려웠습니다.
  하드웨어 설계팀이 있는 더 큰 건물 복도로 출근해 밤샘 테스트를 진행했고, 실제 도입 현장은 규모가 훨씬 커서 예기치 못한 이벤트가 다수 발생했습니다.
  시연 전날까지 반복 테스트와 수정을 이어가며 안정성을 확보했고, 최종 시연을 성공적으로 마쳤습니다.