요약

  • SAMP 개인 초안 04판은 AI 에이전트에 내리는 CONFIG·EXEC 명령의 결과에 record_revision을 추가했다. 결과가 실질적으로 바뀌면 번호가 올라가고 이전 기록은 추가만 가능한 감사 이력에 남는다. 03판에는 이 필드가 없었다.
  • 늦게 확인된 성공은 원래 명령과 연결된 효과 증거가 있어야 한다. 바이트까지 같은 요청을 다시 보내면 최신 기록을 읽을 뿐 명령을 재실행하지 않는다. 실행 측이 최종 확정 번호를 확인할 수 없으면 결과 없이 back_pressure를 돌려준다.

결과를 고칠 수 있어도 어제의 무지는 지울 수 없다

교대 직전에 담당자가 에이전트의 로그 수준을 바꿨다고 하자. 첫 응답은 ‘불명’. 다음 근무자가 원하는 설정값을 보고 성공 표시를 한다. 하지만 그 값을 바꾼 사람이 원래 명령의 실행 주체였는지는 별개다. 다른 운영자가 손댔을 수도 있다. 현재 상태를 보여주는 화면과 명령의 인과관계를 증명하는 기록은 같은 물건이 아니다.

새 초안은 원래 작업 참조번호와 인증된 요청의 결합을 고정한다. 첫 권위 있는 결과는 개정번호 1이다. 나중에 해당 명령에 귀속되는 효과가 입증되면 개정번호 2를 기록할 수 있다. 처음의 불확실성, 당시 승인 근거, 증거 참조, 결론을 알게 된 시각은 감사 이력에 그대로 남는다. 동일 요청의 재전송은 상태 조회이며 두 번째 실행 허가가 아니다.

초안은 ‘지금 정상으로 보인다’는 말도 증거로 받아들이지 않는다. 정책상 허용됐다는 판단, 건강 상태 표시, 이후의 설정값만으로는 누가 무엇을 했는지 알 수 없다. 증거 형식이 효과를 그 명령에 묶어야 한다. 이미 확정된 최종 결과와 충돌하는 관찰이 나오면 감사상 불일치로 기록해 조사한다. 이전 결론을 조용히 바꿀 수는 없다.

실행 성공과 감사 기록의 영구 저장도 다른 사실이다. 명령이 실행된 뒤 저장 장치가 고장날 수 있다. 새 유효 개정번호를 확정할 수 있다면 execution_outcome과 audit_persistence가 두 사실을 따로 보고한다. 재시작이나 복제 서버 전환 뒤 최신 확정번호를 모르면 낡은 기록을 현재 결과처럼 내놓지 않는다. 관리자 쪽은 수용한 최고 번호를 보존한다. 낮은 번호는 되돌림, 같은 번호에 다른 내용은 충돌이다. 늦게 도착한 패킷이 역사책의 편집장이 되는 일을 막는 셈이다.

IETF 문서 상태는 이를 Experimental을 지향하는 개인 초안으로 표시한다. 불명 응답, 늦은 효과 증거, 번호 증가, 재시작을 잇는 인증된 실행 기록이 있어야 실제 구현이 이 약속을 지키는지 판단할 수 있다.

출처: 04판, 03판, IETF 문서 상태.