ROS 2 개발에서 AI 에이전트가 실제 하드웨어에 접근하지 못하게 하는 권한 설계

'테스트해 놓으라'는 지시가 실제 장치 조작으로 이어지지 않게 하기

AI 코딩 에이전트에게 코드 조사, 수정, 테스트를 맡기고 싶습니다. ROS 2 개발에서도 이런 상황을 상상할 수 있을 것입니다. 한편, 개발용 PC에서 실제 하드웨어로 통신할 수 있는 환경에서는 '작동 확인'이라는 말이 어느 정도의 조작까지 의미하는지 미리 정해 두어야 합니다.

저는 로봇 개발 엔지니어로서 7년 경력이 있으며, 업무상 Claude Code를 여러 개 병행하여 사용하고 있습니다. 본 기사는 근무지의 구성이나 운영 사례를 소개하는 것이 아닙니다. 공개된 문서를 바탕으로 실제 하드웨어와 분리하여 AI를 사용하는 설계 방안을 정리합니다.

이전 글에서는 병렬 운영 시 작업이 멈추는 원인을 다루었습니다. 이번에는, 어디서 멈춰야 할지 그 경계를 정하는 것에 초점을 맞춥니다.

결론은 지시문(Instruction), 도구의 권한(Tool Permission), 실행 환경의 격리(Execution Environment Isolation)를 중첩시키는 것입니다. '실제 장치에 손대지 않는다'라고만 적는 것만으로는 부족하며, 위험해 보이는 명령어들을 나열하는 것만으로도 충분하지 않습니다.

1. 로봇 개발에서는 변경의 영향이 화면 밖으로 새어 나온다

소스 코드의 변경은 차이점(diff)을 되돌릴 수 있습니다. 하지만 작동 중인 로봇이 물체와 접촉한 결과는 코드를 되돌려도 취소할 수 없습니다. 모터 구동뿐만 아니라 센서 설정 변경이나 드라이버 재부팅 역시 인식 및 제어에 영향을 줄 수 있습니다.

주의해야 할 점은 실제 장치로의 SSH 연결만이 유일한 조작 경로가 아니라는 것입니다. ROS 2의 DDS 계열 미들웨어는 같은 네트워크 내의 노드가 자동으로 발견되는 구조를 가지고 있습니다. 개발 PC에서 실행된 노드가 의도치 않게 실제 장치와 통신할 가능성을 고려해야 합니다. [ROS 2 공식 discovery 설정]

예를 들어, 토픽(Topic)으로 전송하거나, 서비스 호출(Service Call), 액션의 목표값(Action Goal)을 전송하는 것은 수신자 입장에서 동작 요구가 될 수 있습니다. 파라미터 변경이나 여러 노드 실행 역시 이름만으로는 안전하다고 판단할 수 없습니다. 이러한 CLI 조작은 공식 튜토리얼에서 확인할 수 있습니다. [Topics, Services, Actions, Parameters, Launch]

따라서 '로컬 명령어라서 안전하다'가 아니라, **'어디에 도달하여 무엇을 일으킬 수 있는가'**를 기준으로 분류해야 합니다.

2. 허용/확인 필수/금지 여부를 실행 위치와 함께 결정한다

제가 여기서 제안하는 분류는 다음과 같습니다.

읽기(Read) 역시 구분해야 합니다. 저장된 로그를 읽는 것과 실제 장치의 토픽을 구독(Subscribe)하는 것은 다릅니다. 후자는 통신을 수반하며 센서 정보 등을 가져올 가능성이 있으므로, 본 기사의 자동 허용 범위에는 포함하지 않습니다.

'확인 필수(Confirmation Required)'는 '확인 버튼만 누르면 무엇이든 좋다'는 의미가 아닙니다. 본 기사 운영에서는 실제 장치 테스트를 사람이 관리하는 별도의 환경으로 이관합니다. AI 전용 환경의 연결 제한을 그 자리의 승인에 따라 완화하는 방식으로는 운영하지 않습니다.

3. 가장 먼저, 실제 장치에 도달할 수 없는 실행 환경을 만든다

AI에게는 개발과 시뮬레이션에 필요한 범위만 제공해야 합니다. 설계 단계에서는 다음 사항들을 확인합니다.

• 실제 장치 네트워크로 도달하는 경로를 환경 측에서 차단한다.
• 실제 장치용 키/인증 정보나 디바이스를 AI 환경으로 전달하지 않는다.
• 네트워크 제한이나 디바이스 할당을 AI 스스로 변경할 수 없게 한다.
• 시뮬레이터와 실제 장치를 연결하는 중계 프로세스도 분리한다.

컨테이너(Container)나 VM을 사용하는 것 자체가 목적은 아닙니다. 호스트와 통신 경로 또는 디바이스를 공유하고 있다면, 이름이 '개발 환경'이라 해도 실제 장치에 도달할 수 있습니다. 의존성 획득이나 AI 서비스로의 통신을 허용하는 경우에도, 실제 장치 도달 가능성과는 분리하여 설계합니다.

Claude Code에는 Bash용 샌드박스(Sandboxing) 기능도 있습니다. 하지만 대상이 되는 도구나 제한 범위를 확인하고 이용해야 합니다. 로봇으로의 통신 경로나 디바이스까지 일괄적으로 보호할 수 있다고 가정하지 않고, 외부 실행 환경에서도 제한을 겁니다.

Claude Code 공식: [Sandboxing]

ROS 측의 보조 설정으로는 대응하는 환경에서 다음 지정이 가능합니다.

export ROS_AUTOMATIC_DISCOVERY_RANGE=LOCALHOST

이는 자동 발견 범위를 동일 머신으로 제한하는 지정입니다. 다만, 정적인 연결 대상을 지정하는 ROS_STATIC_PEERS는

이 조합을 통해 다른 호스트와 통신할 수 있는 경우가 있습니다. 같은 호스트에 실기(실제 하드웨어)로 중계하는 프로세스가 있는 경우에도 별도의 확인이 필요합니다. 또한, 공식 자료에서는 이러한 변수가 rmw_zenoh

에서는 미지원으로 되어 있습니다. ROS 2 공식: Improved Dynamic Discovery

ROS_DOMAIN_ID는 DDS의 논리적인 통신 그룹을 분리하는 지정입니다. 연결을 허가하는 메커니즘으로는 취급하지 않으며, 실기(실제 하드웨어)와 값을 분리하는 것에만 의존하지 않습니다. ROS 2 공식: 환경 설정

주의: 사용 중인 ROS 2 배포판, RMW 구현, 정적 연결 대상, 중계 프로세스의 조합으로 인해 실기(실제 하드웨어)로의 통신이 실제로 차단되는지 검증해야 합니다. 환경 변수만으로는 차단을 보장하지 않습니다.

4. CLAUDE.md에는 판단 기준과 멈춘 후의 행동을 작성한다

CLAUDE.md는 프로젝트의 전제를 전달하는 데 사용합니다. 공식에서도 지시문(指示文)과 권한의 강제는 별개라고 설명하고 있습니다. Claude Code 공식: Memory

다음은 프로젝트 직하위에 둘 지시문의 초안입니다.

# 개발 작업 범위
- 이 환경은 코드 수정 및 격리된 시뮬레이션 전용입니다.
- 공개 가능한 코드, 문서, 저장된 로그를 조사해 주십시오.
...

'금지'만 적는 것보다 멈춘 후에 무엇을 제출할지까지 작성하면 리뷰에 연결하기 쉽습니다. 예를 들어 '작동 확인 불가'로 끝나는 대신, 기대하는 입출력, 실패 시의 조건, 시뮬레이터에서 확인할 수 있는 범위를 남깁니다.

5. 권한 규칙은 좁은 허가부터 시작한다

Claude Code의 프로젝트 공유 설정은 .claude/settings.json에 둘 수 있습니다. 개인 설정이나 로컬 설정도 있으므로, 실제로 적용되는 설정을 확인합니다. 공식: Settings

아래는 격리된 환경을 위한 출발점입니다. 실기(실제 하드웨어) 연결 환경에 그대로 적용하는 설정은 아닙니다.

{

시뮬레이션에서는 정상적인 경우뿐만 아니라, 입력이 누락되거나 예상치 못한 값을 받을 경우도 확인합니다. AI에게는 '성공했습니다'라는 결과뿐만 아니라, 무엇을 입력했고, 무엇을 기대했으며, 어떤 결과를 관측했는지 기록하도록 합니다. 재실행할 수 있는 절차가 있다면, 사람은 차이점과 결과를 비교하여 판단할 수 있습니다.

AI가 실행 파일을 변경한 경우에는, 이전에 허용했던 파일이라도 다시 확인합니다. 시뮬레이터용이라는 이름 그대로 실제 장치(実機) 드라이버를 로드하는 변경이 발생할 가능성이 있기 때문입니다. 허용되는 명령어가 같더라도, 호출되는 내용이 바뀌면 영향은 달라집니다.

**주의:** 시뮬레이터의 제품, 버전, 실행 파일은 프로젝트마다 다르므로, 본고에서는 실행 명령어를 고정하지 않았습니다. 실제 장치 드라이버나 외부 중계를 포함하지 않은 검증용 구성을 선택하여 사용해 주십시오.

마지막으로, 사람이 확인할 차이점(diff), 테스트 결과, 남겨진 제약 사항, 실제 장치에서 확인해야 할 항목을 정리합니다. 시뮬레이터에서 확인된 것을 실제 장치의 안전성 확인 완료 사항과 동일시하는 것이 중요하지 않습니다.

## 요약

ROS 2 개발에 AI를 도입할 때는, 명령어의 편리함보다 먼저 허용되는 범위를 정하는 것이 중요합니다. 읽기(read), 빌드(build), 테스트(test), 시뮬레이션(simulation)을 진행할 수 있는 환경을 준비하고, 실제 장치 연결이나 변경은 사람의 확인과 별도의 실행 환경으로 이관해야 합니다.

`CLAUDE.md`

에서 판단 기준을 전달하고, 권한 규칙으로 의도하지 않은 실행을 막으며, 환경 측면에서 실제 장치로 가는 경로를 제한합니다. 이 세 가지를 겹치는 것이 개발을 진행하면서 실제 장치와의 경계를 유지하기 위한 출발점입니다.

본 기사는 개인의 설계안이며 Anthropic사의 공식 견해가 아닙니다. 설정 예시는 2026년 10월 4일자 공개 자료를 기반으로 작성되었습니다.

Claude Code의 운영 환경 설계를 도와드리고 있습니다. https://coconala.com/services/4434757

### 토론 (Discussion)
![](https://static.zenn.studio/images/drawing/discussion.png)