로봇 서비스에서 커스터마이징 가능한 명령 구조 설계 방법
"이 장소에 도착하면 인사를 해주세요."
"노인분에게는 음성 안내 속도를 조금 늦춰주세요."
"도슨트 모드일 땐 LED를 항상 켜주세요."
이러한 요청은 단순히 UI상의 옵션이 아니다.
서비스형 로봇에서 사용자 요청에 따라 동작을 변화시키기 위해서는 명령 구조를 커스터마이징 가능하게 설계해야 한다.
해당 설계는 조건 기반 트리거와 액션 블록으로 구성되며, 시스템에 의해 해석 가능하고 실행 가능한 데이터 포맷으로 관리되어야 한다.
서비스형 로봇에서 '사용자 맞춤 명령(Custom Command)'이란
사용자가 정의한 조건(Trigger)과 행동(Action)을 시스템 내부 로직으로 설계해 실행 가능한 메시지로 만드는 것을 말한다.
{
"trigger": {
"event": "arrived",
"location_id": "LOBBY_1"
},
"action": {
"type": "speak",
"content": "어서오세요. 안내를 시작하겠습니다.",
"language": "ko-KR"
}
}
trigger: 조건 정의 – 언제 어떤 상황에서 동작할 것인가 (조건)
action: 수행할 동작 – 말하기, 움직이기, LED 켜기 등 (동작)
사용자는 어떤 순간에 ‘맞춤 행동’을 기대하는가?
로봇의 어떤 기능이 사용자 정의에 적합한가?
예를 들어, 도슨트 로봇은 ‘특정 지점에서 정해진 음성 출력’이 핵심이지만,
청소 로봇은 ‘장애물 인식 후 회피 경로 설정’이 더 중요하다.
이벤트 기반 (arrived, touched, low_battery)
시간 기반 (scheduled_time)
센서 기반 (object_detected)
모든 조건은 표준화된 key-value 쌍으로 처리되어야
시스템 간 호환성과 추적 가능성이 높아진다.
동작 유형: speak, move, play_media, led_control 등
파라미터 정의: 텍스트, 좌표, 파일 경로, 효과 시간 등
기획자는 각 액션 유형별로 허용 파라미터와 제약 조건을 정의해야 한다.
예:
speak는 language, volume, priority 옵션을 포함할 수 있고,
move는 target_position, velocity, orientation이 필요할 수 있다.
내부 CMS에서 JSON 포맷으로 직렬화
MQTT, ROS Topic, REST API 등으로 전송
수신 노드는 메시지 스키마 기반 파싱 및 실행
권한 관리: 모든 사용자가 모든 명령을 등록할 수는 없음 → 관리자/운영자 권한 분리
안정성 보장: 동시 액션 실행 시 충돌 방지 (예: 이동 중 음성 출력 가능 여부)
상태 기반 실행 제한: 로봇이 대기 상태일 때만 실행, 장애 중에는 무시 등
명령 버전 관리: 명령의 변경/삭제 이력 관리 필요 (rollback 기능 포함)
실시간 모니터링: 등록된 명령 실행 성공/실패 여부 피드백 수집 및 UI 표시
사용자 맞춤 명령 설계는 단순히 “옵션 추가”가 아니다.
이는 로봇의 기능을 ‘개방형 시스템’으로 전환하는 설계 작업이다.
기획자는 다음을 설계해야 한다.
어떤 기능을 커스터마이징 가능하게 열 것인가
어떤 방식으로 사용자 입력을 구조화할 것인가
어떻게 실행하고, 실패했을 때는 어떻게 복구할 것인가
이때 가장 중요한 건
“기능의 유연성”과 “시스템의 안정성” 사이의 균형이다.
사용자 맞춤 명령 설계는 로봇의 기능을 정형화된 API 수준으로 공개하고, 서비스 운영자가 직접 시나리오를 구성할 수 있게 하는 구조다.
시스템적으로는 다음 요건을 만족해야 한다.
트리거/액션 모델 기반 구성 가능성
명령의 직렬화 및 안전한 실행 가능성
커스터마이징 확장성
명령 실행 상태에 대한 신뢰성 있는 피드백 제공