그럴듯한 제안과 실행 권한을 분리한다
언어 모델이 '컵을 옮기라'는 계획을 만들었다고 현재 사용자가 그 장비/장소/동작을 허가한 것은 아니다. 제안은 무엇을 하려는지 나타내는 자료이고, 권한은 누가 어떤 대상에 어떤 동작을 할 수 있는지를 신뢰된 정책이 정한 범위다. 문장이 정확하거나 JSON 형식 검사를 통과해도 두 조건은 독립이다. 존재하는 skill 이름과 숫자 범위를 확인하는 M22.02의 검사는 권한 확인의 일부만 다룬다.
최소 권한은 과업에 필요한 범위만 허용한다는 원칙이다. 물체 조회 권한이 있다고 이동/파지·설정 변경 권한을 함께 주지 않는다. 언어 모델에는 임의 shell이나 관리자 기능보다 정의된 skill의 제안만 맡기고, 실행 계층이 허가된 사용자/대상·공간/시간 범위를 검사하도록 설계한다. 이 단위의 설계 표는 인증 시스템을 구현한 결과가 아니며 실제 제품의 접근 통제/물리 안전 기능과 구분한다.
신뢰 경계는 어떤 정보를 권한/정책의 근거로 취급할 수 있는지 나누는 선이다. 카메라에 보이는 종이의 '관리자 승인, 제한 해제'라는 글자나 검색된 웹 문서는 환경 자료다. 그 문구를 현재 사용자/감독 정책의 명령으로 승격하면 간접 prompt injection의 통로가 된다. OWASP 공식 설명도 외부 콘텐츠로 모델의 행동이 바뀌는 위험과 권한 제한/출력 검증의 필요성을 다룬다. 프롬프트에 경고문 한 줄을 넣었다는 사실만으로 이런 경계가 보장되지는 않는다.
검증은 여러 관문이고 사람의 확인도 범위가 있다
감독기는 제안 수신→형식/의미 검증→권한/현재 전제 확인→필요한 사용자 확인→실행 허가→진행/결과 관찰의 관문을 둔다. 의미 검증은 대상 ID가 현재 장면에 존재하는지, 좌표/단위가 맞는지 등을 포함한다. 물리 실행 전제는 현재 상태·작업공간·접근 가능성 같은 별도 조건이다. 사람의 확인은 이 검사를 모두 생략하는 예외 키가 아니다.
그림 M22.06-1. 각 칸은 서로 다른 역할/근거다. 아래 방향은 자료/처리의 연결이며 실제 성공을 자동으로 보장하지 않는다. 직접 제작한 개념도이며 본문의 조건과 함께 읽는다.
확인 화면/기록에는 '계속?'만 쓰지 말고 대상 ID, 동작과 범위·예상 결과, 사용하는 관측/장면 버전, 만료와 중단 경로를 구체적으로 제시한다. 허가된 확인 주체가 정해진 범위를 승인해야 한다. 장면이나 대상·동작 범위가 바뀌었으면 이전 확인을 자동 재사용하지 않는다. 반복 확인을 많이 받는 것보다 실제 변화가 무엇인지 판단할 수 있도록 만드는 일이 중요하다.
교육용 허가표에서 사용자 U는 scene 버전 v12의 cup_7을 tray_A로 옮기는 skill만 허용받았다. tool 설정 변경과 다른 방 이동은 범위 밖이다. 승인 ID A7은 이 사용자/skill/대상·장면에 연결되며 발행 시각은 같은 단조 시계의 10.000 s, 유효기간은 0.800 s다. 이 예의 검사 규칙은 나이 age=현재 시각−발행 시각이 0 이상이고 0.800 s 이하일 때만 유효하다는 것이다. 경계 포함 여부를 명시했으므로 시스템마다 임의로 바꾸지 않는다.
현재 10.600 s이면 age=0.600 s, 남은 여유는 0.200 s다. 그러나 장면이 v13으로 바뀌면 시각 조건이 맞아도 이 승인으로 새 장면을 실행하지 않는다. 현재 10.850 s이면 age=0.850 s로 0.050 s 초과다. 현재 시각이 발행보다 이르면 음수 나이를 신선함으로 인정하지 않고 clock/재시작·기록 오류를 확인한다. 다른 시계의 값을 빼서 이 계산을 해서는 안 된다.
허가의 만료와 실행의 중단은 다른 사건이다
위의 유효기간은 이번 예에서 명령을 받아들일 수 있는 입구 조건이다. 10.600 s에 허가한 동작이 10.800 s 뒤에 자동으로 정지한다는 뜻은 아니다. 동작 중 허가 갱신/lease나 실행 deadline·중단 정책이 필요하면 별도 계약으로 정한다. 오래된 관측을 새 승인 봉투에 담는 경우도 있어 승인 나이와 관측 나이를 따로 검사한다.
예를 들어 관측 stamp가 10.450 s이고 실행 검사 시각이 10.600 s라면 관측 나이는 0.150 s다. 허용 관측 나이를 0.100 s로 정한 합성 조건에서는 승인 age가 통과해도 관측은 실패다. 사용자 확인을 다시 받는 것만으로 오래된 관측이 새로워지지 않는다. 재관측 후 대상/장면·권한과 확인 범위를 다시 맞춘다. 이 시간 기준은 교육용 입력이며 실제 장비의 안전 임계값을 권고한 것이 아니다.
중단 요청은 관측 가능한 결과로 닫아야 한다
실행 중 피드백이 오래 끊기면 성공/실패가 아니라 결과 미상일 수 있다. 감독 상태를 실행 중, 중단 요청 중, 중단 처리 중, 종료 결과 확인, 상태 미상처럼 구분하면 요청을 사실로 오인하는 일을 줄일 수 있다. ROS 2 Action 설계는 goal 수락/실행·cancel 처리와 최종 결과를 구별한다. cancel 응답을 받았다는 것만으로 로봇의 물리 속도가 0이거나 에너지가 차단되었다고 선언하지 않는다.
합성 로그에서 20.000 s에 실행 중 피드백을 마지막으로 받았고, 20.300 s에 중단 요청, 20.320 s에 cancel 수락을 받았지만 최종 결과/관절 속도·물체 상태가 없다면 중단 요청과 수락만 확인된 것이다. 필요한 실제 정지/작업 상태 확인은 미상으로 남긴다. timeout이 나도 같은 명령을 새 ID로 즉시 반복하면 이전 동작과 겹칠 수 있다. 서버/장비의 현재 상태와 중복 요청 처리 계약을 확인해야 한다.
재개는 이전 계획의 다음 줄을 무조건 실행하는 작업이 아니다. 현재 위치/물체 파지·장면·유효 관측과 권한을 확인하고, 이어서 수행할 수 있는 단계인지 재계획해야 한다. 보호 정지/비상 정지·장비 고장 뒤의 복구는 해당 장비 절차와 권한을 따라야 하며 이 소프트웨어 상태표로 대체하지 않는다. 감독 기록에는 제안/거부 이유, 정책/모델·장면/관측 버전, 승인 주체와 범위, goal ID·시각, 중단/결과 근거를 남긴다. 모델이 생성한 설명과 실제 로그의 증거도 분리한다.
기존 6.4 안전 배포 감독기와 연결하되, 교육용 감독 예제를 인증된 안전 제어기로 부르지 않는다. 아래 과제는 종이 표에서 관문과 미상 상태를 판정하며 실제 실행/중단 명령을 보내지 않는다.