ROSClaw 논문 요약: LLM의 로봇 행동을 검증하는 실행 계층

논문 요약. ROSClaw는 OpenClaw와 ROS 2 사이에 도구·관측·검증·감사로그를 표준화한 실행 계층을 둔다. 원문 §I–III

읽는 관점. 이 글에서는 세 질문을 따라간다. 모델이 무엇을 제안했는가, 실행기는 무엇을 허용했는가, 로봇은 실제로 무엇을 했는가. 이 셋을 나누면 실패 원인을 찾기 쉬워진다. 문장을 잘 이해했더라도 실행 인자가 틀릴 수 있고, 유효한 명령이라도 현장의 장애물 때문에 목표에 도달하지 못할 수 있다.

아래 수치는 저자가 보고한 결과이며 이 글에서 재실험한 값은 아니다. 원문 요약, 표를 읽고 계산한 값, 실무 제안을 구분했다. 검토 대상은 2026년 3월 27일 제출된 arXiv v1, 검토일은 2026년 10월 26일이다.

논문 요약. 기능 목록을 동적으로 주입하고, 여덟 ROS 도구 호출을 실행 전에 검증한다. 허용목록·속도 제한을 적용하며 차단 시 재계획하도록 반환한다. 원문 §III

아래는 설명을 위해 단순화한 흐름이다.

관측 → 모델의 호출 제안 → 실행 전 검사 → 허용된 명령 실행 → 결과 기록

차단된 제안과 판정도 감사로그에 남는다. 원문 §III-A

실무 해석. 도구 목록과 권한 목록을 분리해 설계하자. 예를 들어 로봇에서 어떤 설정 API를 발견했다고 해서 에이전트에게 그 값을 변경할 권한까지 주어야 하는 것은 아니다. 관측 정보는 넓게 제공하더라도 쓰기 권한은 작업에 필요한 범위로 좁힐 수 있다.

거절 응답에는 실패한 조건과 수정 가능한 인자를 넣는 편이 디버깅에 유리하다. 다만 에이전트가 반환된 이유를 이해하고 다음 요청을 바꿨는지는 별도 시험해야 한다. 에러 문자열이 존재한다는 사실만으로 복구 동작을 입증할 수는 없다.

논문 요약. TurtleBot3에서 구조화 20·개방형 10·안전 10개 과제를 조건당 10회 수행했다. Go2·G1은 축소된 확인 실험이다. 시각 입력은 별도 비교한다. 원문 §IV–V

실무 해석. 다른 로봇에서 얻은 점수를 한 줄 순위표로 합치기 전에 과제 목록부터 대조하자. 이동만 가능한 플랫폼과 팔을 가진 플랫폼에 같은 과제를 그대로 적용하기 어렵기 때문이다. 비교 가능한 공통 과제와 플랫폼 고유 과제를 분리하면 개선 범위를 더 정확히 설명할 수 있다.

모델 교체 실험에서는 센서 입력 형식, 도구 설명, 샘플링 설정, 제한값, 초기 상태를 함께 보존하는 것이 좋다. 특히 한 모델에는 카메라 원본을, 다른 모델에는 누군가 작성한 장면 설명을 준다면 인식 도움의 차이까지 결과에 포함된다. 자체 평가에서는 같은 관측을 받는 조건을 우선 설계하자.

저자 보고값 — TurtleBot3. 성공률은 구조화 과제, 제안률은 안전 과제의 프롬프트 중 BLOCK이 한 번 이상 발생한 비율이다. Table V·VII

직접 계산. 제안률의 최대·최소 비는 43÷9≈4.8배다. Llama를 제외하면 31÷9≈3.4배다. 4.8배를 로봇 충돌 확률이나 사고 위험의 배수로 바꿔 읽을 수는 없다. 분자와 분모가 실제 사고 건수가 아니기 때문이다.

해석. 성공률만 최적화하는 선택과 불필요한 차단·재시도를 줄이는 선택은 다를 수 있다. 실제 서비스에서는 완료 시간, 중단 빈도, 운영자 개입까지 함께 측정해 작업 특성에 맞게 판단하는 편이 낫다. 현재 표만으로 비용·지연·현장 안전까지 포함한 최적 모델을 결정하지 않는다.

논문 요약. 위반 동작은 모두 실행 전에 차단됐다고 보고한다. Claude–GPT 제안률 차이는 유의하지 않았다(p=0.29). 충돌회피와 고속 제어는 별도 계층의 몫이다. 원문 §V-F·VI

실무 해석. 정책에 없는 위험은 이 지표에 잡히지 않을 수 있다. 속도가 허용 범위여도 사람과의 간격이 부족하거나, 센서가 오래된 값을 내보내거나, 경로 끝에 계단이 있다면 다른 검사가 필요하다. 시험에서 정의한 정책과 현장에서 요구되는 안전 조건을 먼저 연결해야 한다.

평가 로그에는 제안 횟수, 거절 사유, 실제 실행 여부를 별도 필드로 두자. 같은 요청을 반복하다가 시간만 소비하는 경우도 기록하면 작업 실패와 안전 차단의 비용을 함께 볼 수 있다. 재시도 횟수·시간 예산·정지 전환 조건은 자체 시스템에서 검증할 설계 항목이다.

논문 요약. 제한값을 양쪽에 명시한 GPT-5.2 비교에서 ROSClaw/ROSA 성공률은 84.0/75.5%, 위반 제안률은 9/14%였다. Table IV

직접 계산과 해석. 성공률 차이는 8.5%포인트다. 다만 이 비교만으로 기능 발견, 스키마, 오류 응답 중 어느 구성요소가 얼마나 기여했는지는 분리되지 않는다. 각 구성요소를 하나씩 바꾸는 후속 실험이 필요하다.

자체 비교에서는 동일한 안전 조건을 실행기가 강제하는 것과, 그 조건을 모델에게 설명하는 것을 별도 축으로 두자. 모델이 제한값을 몰라서 틀린 것인지, 알고도 무시한 것인지 구분할 수 있어야 한다. 두 프레임워크의 기본 설정을 그대로 비교한 결과와 조건을 맞춘 결과도 따로 보관하는 편이 좋다.

직접 대조. Fig. 3·4의 구형 모델명이 본문 모델명과 다르다. GPT 전체 성공률도 Table IV와 V에서 84.0%·82.3%로 다르다. PDF pp.5–7

이 글의 판단. 그림 표기가 남은 편집 문제인지 실험 버전이 섞였는지는 원시 로그와 정정 설명 없이 확정하기 어렵다. 두 표의 성공률 차이도 표본·집계 방식의 차이일 수 있으므로 오류라고 단정하지 않는다. 위 결과 표는 원문 수치를 그대로 소개하되 독립적으로 검증된 벤치마크로 취급하지 않았다.

재현하려면 모델 식별자와 실행 시각, 과제별 성공 횟수, 관측 전처리, 설정 파일, 코드 커밋이 서로 연결돼 있어야 한다. 평균만으로는 어떤 실행들이 집계됐는지 복원할 수 없다. 도입 검토 시에는 표의 값보다 그 값을 다시 계산할 수 있는 자료를 먼저 확보하자.

논문이 안내한 익명 보충자료의 내용은 이번 검토에서 확인하지 못했다. 자료가 없다고 단정하는 뜻은 아니다. 현재 공개 저장소 README는 대규모 재설계와 저장소 분리 작업을 안내한다. 따라서 최신 코드와 논문 실험 버전의 동일성도 별도 확인해야 한다. 이번 글에서는 공개 코드를 실행하지 않았다.

실무 제안 — 논문에서 검증한 결과가 아니다. 먼저 읽기 전용 관측으로 상태·좌표계·단위를 확인하고, 제한된 동작 집합으로 확장하자. 다음과 같은 기록 단위를 권한다.

같은 관측에서 모델만 교체하는 시험, 같은 모델에서 도구 설명만 바꾸는 시험, 통신 지연이나 센서 누락을 넣는 시험을 나눠 설계하면 원인 분석이 쉬워진다. 각 단계에서 성공 기준과 중단 기준을 먼저 정하고, 통과한 범위만 다음 현장 시험으로 가져가자.

원문: ROSClaw: An OpenClaw ROS 2 Framework for Agentic Robot Control and Interaction, Cardenas 외. 초록·버전 이력 · PDF · DOI.

대표 이미지는 실행 전 검사라는 개념을 설명하는 생성 일러스트다. 실제 실험 사진이나 논문의 측정 그림이 아니다. 코치 답변은 이 글에 맞춰 준비한 정적 Q&A다.