안전한 AI 로봇 에이전트 설계
안전은 기능이 아니라 전제 조건이다
AI 로봇 에이전트는 텍스트만 생성하는 시스템이 아니다. 잘못된 계획은 로봇팔의 충돌, 물체 파손, 사람과의 접촉으로 이어질 수 있다. 그래서 로봇 에이전트의 첫 번째 목표는 "무엇을 할 수 있는가"가 아니라 "무엇을 하지 말아야 하는가"다.
LLM은 자연어를 잘 이해하지만, 물리 세계의 안전을 자동으로 보장하지 않는다. 존재하지 않는 물체를 있다고 가정할 수 있고, 사용자의 말에 숨어 있는 위험을 놓칠 수 있으며, 실제 로봇이 수행할 수 없는 행동을 그럴듯한 계획으로 만들 수 있다. 특히 위험은 두 종류로 나타난다. 하나는 "사람 쪽으로 빠르게 움직여"처럼 명시적으로 위험한 명령이다. 다른 하나는 겉으로는 평범하지만 실행하면 위험해지는 암묵적 위험이다. 예를 들어 "책상 위 컵을 치워줘"라는 명령도 컵 안에 뜨거운 물이 있거나, 컵 옆에 노트북 전원 케이블이 있으면 위험한 작업이 된다. embodied LLM 에이전트 평가 연구에서도 명시적·암묵적 위험을 모두 다루는 안전 인식 계획이 중요하다고 본다1.
따라서 안전한 로봇 에이전트는 LLM의 답을 바로 실행하지 않는다. 명령을 해석한 뒤, 위험을 점검하고, 허용된 스킬만 고르고, 실행 전후로 계속 검증한다.
AI 생성 이미지
LLM 계획은 검증 대상이다
LLM이 만든 계획은 최종 명령이 아니다. 초안이다. 실행 전에 다음 질문을 통과해야 한다.
사용자의 목표가 명확한가?
대상 물체가 실제 센서로 확인되었는가?
대상과 주변 환경에 위험 요소가 있는가?
로봇이 이 작업을 수행할 권한이 있는가?
작업 공간, 속도, 힘, 접근 방향이 안전 제한 안에 있는가?
실패했을 때 멈출 조건이 정의되어 있는가?
예를 들어 사용자가 "저 컵을 치워줘"라고 말하면 로봇은 먼저 "저 컵"이 어떤 컵인지 확인해야 한다. 카메라가 컵을 두 개 찾았다면 추측해서는 안 된다. "왼쪽의 빨간 컵인가요, 오른쪽의 흰 컵인가요?"라고 물어야 한다. 컵이 뜨거운 음료로 분류되거나, 유리컵처럼 깨지기 쉬운 물체라면 일반 pick 스킬이 아니라 낮은 속도, 낮은 그리퍼 힘, 사용자 승인 같은 추가 조건이 필요하다.
안전 인식 작업 계획은 보통 다음 순서로 진행한다.
자연어 명령에서 목표, 대상, 위치, 금지 조건을 추출한다.
센서로 실제 환경 상태를 확인한다.
명시적 위험과 암묵적 위험을 점검한다.
필요한 경우 사용자에게 질문한다.
허용된 스킬 목록 안에서만 계획을 만든다.
실행 전 안전 검증기를 통과한 단계만 실행한다.
실행 결과를 확인하고, 위험하면 즉시 중단한다.
핵심은 LLM이 "할 수 있을 것 같다"고 말해도 로봇이 바로 움직이지 않는 구조를 만드는 것이다.
스킬 호출은 기본 거부로 시작한다
로봇 스킬은 LLM의 자유 출력에 맡기면 안 된다. LLM이 pick, place, navigate_to 같은 허용된 스킬을 호출하는 것은 괜찮다. 하지만 override_safety, set_motor_torque, disable_collision_check 같은 내부 기능을 만들어 내거나 호출하려 하면 반드시 차단해야 한다.
가장 단순하고 강력한 원칙은 기본값을 거부로 두는 것이다.
허용 목록에 있는 스킬만 실행한다.
스킬 이름을 정규식이나 정확한 이름으로 검사한다.
도구 유형을 검사한다.
인자 값의 범위와 패턴을 검사한다.
규칙에 맞지 않으면 실행하지 않는다.
고위험 행동은 사람 승인을 요구한다.
도구 권한 가드레일 시스템은 이런 방식으로 tool name, tool type, 인자 패턴을 allow/deny 규칙으로 검사할 수 있다. 또한 호출 전(pre-call)과 호출 후(post-call)에 모두 검사를 적용할 수 있다2. 로봇에서도 같은 생각을 적용한다.
호출 전 검사는 LLM에게 위험한 도구 자체를 주지 않거나, 요청 단계에서 금지된 스킬을 제거한다. 호출 후 검사는 LLM이 생성한 실제 스킬 호출을 보고 차단한다. 둘 다 필요하다. 호출 전 검사만 있으면 LLM이 예상하지 못한 형식으로 위험 행동을 만들 수 있다. 호출 후 검사만 있으면 애초에 위험한 후보를 LLM에게 보여 주는 문제가 남는다.
예를 들어 move_to는 허용하되, 인자가 작업 공간 밖이면 거부한다. pick은 허용하되, 대상이 "칼", "뜨거운 냄비", "사람 손"으로 분류되면 승인 없이는 거부한다. stop은 항상 허용하고, 다른 모든 스킬보다 우선순위를 높인다.
policy:
default_action: deny
allow:
- skill: detect_object
- skill: check_status
- skill: stop
- skill: pick
args:
object_type: "cup|box|bottle"
max_force_n: "0|[1-9]|10"
- skill: place
args:
zone: "safe_table_zone|tray_zone"
deny:
- skill: ".*override.*"
- skill: ".*disable.*safety.*"
- object_type: "knife|human|hot_object"이 예시는 개념을 보여 주기 위한 것이다. 실제 시스템에서는 정규식만으로 안전을 보장하지 않고, 객체 분류 결과, 작업 공간 좌표, 사람 감지, 충돌 검사 결과까지 함께 검사해야 한다.
자연어 안전 지시를 검증 가능한 규칙으로 바꾸기
"사람 근처에서는 천천히 움직여", "노트북 위를 지나가지 마", "컵을 든 상태에서는 팔을 높이 들어 올리지 마" 같은 문장은 사람이 이해하기 쉽다. 그러나 로봇 실행 계층은 자연어를 그대로 검증할 수 없다. 안전 지시는 기계가 검사할 수 있는 규칙으로 바뀌어야 한다.
대표적인 규칙은 다음과 같다.
작업 공간 경계: 로봇팔 TCP는 x, y, z 범위 안에서만 움직인다.
접근 금지 구역: 사람 주변, 노트북 위, 유리 물체 주변은 금지 영역으로 둔다.
선행 조건:
pick전에 대상이 검출되어야 하고, 충돌 없는 접근 경로가 있어야 한다.종료 조건: 힘 센서가 임계값을 넘거나 사람이 가까워지면 즉시 정지한다.
상태 전이:
holding_object=true일 때는 이동 속도와 회전 속도를 낮춘다.
더 엄격한 방식으로는 LTL 같은 형식 논리를 사용할 수 있다. LTL은 시간에 따라 어떤 조건이 항상 지켜져야 하는지, 어떤 조건이 어떤 행동 전에 먼저 만족되어야 하는지를 표현하는 논리다. Safety Chip 구조는 자연어 안전 규칙을 LTL로 변환하고, 이를 오토마톤이라는 검증 가능한 상태 표현으로 바꾼 뒤, LLM이 제안한 행동이 제약을 위반하는지 실행 전에 검사한다. 위반하면 행동을 잘라 내고, 위반 이유를 LLM에 돌려보내 재계획하게 한다3.
초기 프로젝트에서 반드시 LTL을 구현할 필요는 없다. 상태 기계만으로도 많은 안전 규칙을 표현할 수 있다.
IDLE
-> PLAN_READY: 계획 검증 통과
PLAN_READY
-> EXECUTING: 사용자 승인 또는 저위험 작업
EXECUTING
-> STOPPED: 사람 감지, 충돌 위험, 힘 초과
-> VERIFYING: 스킬 성공
VERIFYING
-> DONE: 완료 조건 만족
-> REPLAN: 실패 원인 재계획 가능
-> STOPPED: 반복 실패 또는 안전 위반중요한 것은 안전 규칙을 문서에만 두지 않는 것이다. 규칙은 코드로 표현되어야 하고, 실행 전후에 질의할 수 있어야 한다.
ROS2 실행 계층은 원자적 행동만 수행한다
LLM은 계획자다. ROS2 실행 계층은 실행자다. 이 둘을 분리해야 한다. LLM이 직접 관절 속도, 모터 토크, raw topic을 제어하게 해서는 안 된다. 대신 ROS2에는 안전하게 포장된 원자적 행동 라이브러리를 둔다.
원자적 행동은 detect_object, move_to, pick, place, navigate_to, check_status, stop처럼 독립적으로 검증 가능한 작은 행동이다. ROS-LLM 구조에서도 자연어 입력과 ROS 환경 정보를 함께 사용해 행동을 선택하고, 선택된 행동을 ROS 액션과 서비스로 구성된 원자적 행동 라이브러리로 실행하는 흐름을 제시한다. 실행 결과와 실패 플래그는 다시 피드백으로 사용된다4.
각 스킬은 다음 정보를 반환해야 한다.
{
"ok": false,
"skill": "pick",
"stage": "grasp",
"reason_code": "EMPTY_GRASP",
"message": "그리퍼가 닫혔지만 물체 폭이 감지되지 않았습니다.",
"retryable": true,
"suggested_recovery": ["redetect_object", "try_next_grasp_candidate"]
}이 반환값은 LLM에게 자유롭게 해석하라고 주는 이야기가 아니다. 재계획을 위한 구조화된 피드백이다. retryable=false이거나 reason_code=SAFETY_VIOLATION이면 LLM이 재시도 계획을 만들더라도 디스패처가 차단해야 한다.
물리적 안전 계층은 독립적이어야 한다
소프트웨어 권한 제한은 필요하지만 충분하지 않다. LLM이 안전한 계획을 만들고, 디스패처가 검증해도 센서 오류, 제어 지연, 사람의 갑작스러운 접근, 물체 미끄러짐은 언제든 발생할 수 있다. 그래서 물리적 안전 계층은 LLM과 독립적으로 동작해야 한다.
필수 안전 장치는 다음과 같다.
속도 제한: 사람 가까이, 물체를 든 상태, 불확실성이 큰 상태에서는 자동으로 감속한다.
힘 제한: 그리퍼 힘과 접촉 힘을 제한해 물체 파손과 사람 접촉 위험을 줄인다.
충돌 회피: 계획 단계와 실행 단계에서 로봇, 물체, 환경 충돌을 검사한다.
안전 구역: 로봇이 들어가면 안 되는 공간과 사람이 들어오면 로봇이 멈춰야 하는 공간을 분리한다.
사람 감지: 카메라, 라이다, 거리 센서로 사람 접근을 감지한다.
비상 정지: LLM, 네트워크, 디스패처와 무관하게 즉시 모터 출력을 끊을 수 있어야 한다.
수동 개입: 운영자가 현재 스킬을 취소하고 안전 자세로 복귀시킬 수 있어야 한다.
안전 정지는 실패가 아니다. 안전 정지는 로봇이 올바르게 작동했다는 신호일 수 있다. 위험한 상황에서 계속 움직이는 로봇이 실패한 로봇이다.
기록하지 않으면 통제할 수 없다
사고가 나거나 위험한 동작이 발생했을 때 "LLM이 그렇게 말했다"는 설명은 충분하지 않다. 어떤 명령이 들어왔고, LLM이 어떤 계획을 만들었고, 어떤 스킬이 어떤 인자로 호출되었고, 어떤 검증을 통과했으며, 어떤 센서 피드백이 있었는지 추적할 수 있어야 한다.
기록해야 할 항목은 다음과 같다.
사용자 원문 명령
LLM이 추출한 목표와 제약 조건
생성된 계획
계획 검증 결과
호출된 스킬 이름과 인자
실행 전 센서 상태
실행 중 피드백
실패 코드와 재시도 횟수
사용자 승인 여부
안전 정지 발생 여부
최종 성공 또는 중단 결과
고위험 행동은 감사 가능한 체크포인트를 거쳐야 한다. 예를 들어 깨지기 쉬운 물체, 뜨거운 물체, 사람 근처 동작, 금지 구역 근처 이동은 "실행 전 승인" 상태로 멈춘다. 로봇은 사용자에게 무엇을 하려는지, 왜 위험할 수 있는지, 어떤 제한을 적용할 것인지 설명한 뒤 승인을 받아야 한다.
안전한 에이전트의 기준
안전한 AI 로봇 에이전트는 모든 상황을 완벽히 예측하는 시스템이 아니다. 오히려 자신의 한계를 알고 멈출 수 있는 시스템이다.
좋은 기준은 다음과 같다.
모호하면 질문한다.
확신이 낮으면 다시 본다.
허용되지 않은 스킬은 실행하지 않는다.
안전 제약을 위반하는 계획은 재계획한다.
반복 실패하면 중단한다.
사람과 가까워지면 감속하거나 멈춘다.
모든 실행 과정을 로그로 남긴다.
위험한 행동은 사람 승인을 요구한다.
LLM 기반 로봇의 가치는 자연어를 이해하고 복잡한 작업을 유연하게 계획하는 데 있다. 그러나 물리 세계에서는 유용성보다 통제 가능성이 먼저다. 로봇이 똑똑해질수록 더 많은 권한을 주는 것이 아니라, 더 명확한 경계와 더 강한 검증 절차를 함께 설계해야 한다.
참고
1SafeAgentBench: A Benchmark for Safe Task Planning of Embodied LLM Agents
2LiteLLM Tool Permission Guardrail
3Plug in the Safety Chip: Enforcing Constraints for LLM-driven Robot Agents
4ROS-LLM: A ROS framework for embodied AI with task feedback and structured reasoning
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.