서비스 기획자가 설계한 호출부터 복귀까지의 흐름
화면 속 ‘호출 버튼’을 누르면, 로봇이 이동을 시작한다.
당연한 것처럼 보이지만, 그 단순한 움직임 뒤에는 수많은 데이터 흐름이 숨어 있다.
기획자는 기계어를 다루진 않지만, 시스템을 이해하고 흐름을 설계할 줄 알아야 한다.
그래서 이번에는, 로봇 호출부터 복귀까지의 전체 데이터 흐름과 설계 포인트를 구조적으로 정리해본다.
※ 참고
실제 서비스에서는 CMS 서버, 제어 서버, 메시지 브로커 등 역할별로 다양한 서버가 협업한다.
이 글에서는 흐름 이해를 돕기 위해 '서버'라는 용어로 통칭하여 설명한다.
로봇이 움직이는 과정을 데이터 관점에서 정리하면 이렇게 된다.
1. 사용자가 호출 버튼을 누른다.
2. 서버가 호출 명령을 생성해 로봇에 전달한다.
3. 로봇이 목적지로 이동한다.
4. 도착을 감지하고 상태를 보고한다.
5. 대기 상태로 전환하거나, 다음 명령을 대기한다.
6. 복귀 명령을 수신하면 복귀를 시작한다.
7. 복귀 완료 후 서버에 최종 상태를 보고한다.
(※ 브런치에는 다이어그램 대신 글로 풀어 설명합니다.)
사용자 → 서버
: "호출 버튼 클릭" → 호출 명령 데이터 생성
서버 → 로봇
: "이동 명령(Publish)" → 이동할 좌표와 함께 전송
로봇 → 서버
: "도착 완료(Status Report)" → 목적지 도착 보고
서버 → 로봇
: "복귀 명령(Publish)" → 복귀 지점 좌표와 함께 전송
로봇 → 서버
: "복귀 완료(Status Report)" → 최종 복귀 보고
호출 요청
송신자: 사용자 앱 → 수신자: 서버
메시지 예시:
{"command": "call", "location": {"x":1.5, "y":3.0}}
설명: 사용자가 호출 버튼을 누르면 서버에 호출 명령을 보낸다.
이동 명령
송신자: 서버 → 수신자: 로봇
메시지 예시:
{"command": "move_to", "target": {"x":1.5, "y":3.0}}
설명: 서버가 로봇에 이동 명령을 전달한다.
도착 보고
송신자: 로봇 → 수신자: 서버
메시지 예시:
{"status": "arrived", "location": {"x":1.5, "y":3.0}}
설명: 로봇이 목적지 도착을 서버에 알린다.
복귀 명령
송신자: 서버 → 수신자: 로봇
메시지 예시:
{"command": "return_to_base"}
설명: 서버가 로봇에 복귀 명령을 보낸다.
복귀 완료 보고
송신자: 로봇 → 수신자: 서버
메시지 예시:
{"status": "returned", "location": {"x":0.0, "y":0.0}}
설명: 로봇이 복귀 완료를 서버에 알린다.
버튼 하나로 끝나는 서비스는 없다.
기획자는 다음을 반드시 고려해야 한다.
각 동작마다 필요한 데이터 구조를 명확히 정의할 것
필수 데이터와 선택 데이터를 구분할 것
상태(state) 변화를 모두 기록하고 관리할 것
오류 발생 시 대처 플로우까지 설계할 것
예를 들면,
"도착 보고가 일정 시간 안에 오지 않으면 긴급 알람을 띄운다."
같은 운영 시나리오도 데이터 기반으로 설계해야 한다.
데이터 완결성
필수 항목은 항상 전송되도록 강제하고, 선택 항목도 명확히 관리한다.
상태 관리
로봇의 상태 변화를 수시로 모니터링하고, 상태 전환 로직을 명확히 정의한다.
장애 대응 플로우
이동 실패, 경로 이탈, 통신 오류 등 다양한 에러 시나리오에 대한 복구 플로우를 사전에 설계한다.
확장성 고려
기본 이동 외에도, 추가 명령(음성 안내, 특정 액션 수행 등)을 쉽게 붙일 수 있도록 데이터 모델을 유연하게 설계한다.
기획자는 단순히 '버튼을 누르면 로봇이 움직인다'를 상상하는 것만으로 충분하지 않다.
버튼 클릭이라는 단순한 인터랙션이,
어떤 데이터를 만들고,
어떤 경로를 따라 이동하며,
어떤 시스템과 연결되어,
어떤 상태 변화를 일으키는지
시스템 전체의 동선과 흐름을 설계할 수 있어야 한다.
이는 단순한 UI/UX 설계를 넘어,
서비스 품질을 좌우하는 본질적 설계 능력과 직결된다.
로봇은 인간의 언어를 이해하지 않는다.
우리가 설계하는 데이터 구조, 데이터 흐름을 통해서만 세상과 대화할 수 있다.
기획자는 그 언어를 만들고, 흐름을 만들어야 한다.
'버튼'을 설계하는 것이 아니라,
'버튼을 눌렀을 때 세상이 어떻게 반응해야 하는지'를 설계하는 사람.
그것이 기획자가 시스템을 공부하고, 데이터 플로우를 설계해야 하는 이유다.
좋은 기획자는 UI를 그리는 사람이 아니다.
세상의 요청을 데이터로 번역하는 사람이다.
호출 버튼 하나,
복귀 명령 하나,
그 모든 행동은 결국 '보이지 않는 데이터 대화' 위에 있다.
기획자는 그 대화를 디자인하고, 흐름을 만들어야 한다.
그래야 진짜로 세상과 대화하는 로봇을 만들 수 있다.