요약

  • RFC 3179는 SNMP 에이전트의 Script MIB와 언어별 런타임 시스템 사이에 작은 프로토콜을 놓았다. 231 응답은 명령이 실행 중, 일시 중단 또는 재개 상태에 도달했음을 증명할 수 있었다. 그러나 스크립트가 끝났다는 뜻은 아니었다.
  • 중간 결과, 치명적·비치명적 오류, 종료, 보관된 이력은 각기 다른 메시지와 다른 소유자를 가졌다. 이를 "성공" 하나로 축소한 수집기는 불완전한 자동화를 진단하는 데 필요한 순서를 파괴했다.
  • 깨끗한 종료와 저장된 결과조차 최종 주장에는 미달했다. 호출자는 여전히 결과 바이트를 이해해야 했고, 독립적인 관찰이 의도한 관리 네트워크 효과가 발생했는지 보여 주어야 했다.

관리 인터페이스는 런타임 경계에서 멈췄다

2001년 10월, RFC 3179는 Script MIB 확장성 프로토콜, 즉 SMX의 버전 1.1을 기술했다. 그 상태는 실험적(Experimental)이었다. 이 메모는 인터넷 표준을 지정하지 않는다고 명시적으로 말했다. 이 경계가 중요한 이유는 그 문서가 채택 사례, 이름이 붙은 네트워크에서의 상호운용성 또는 배포된 제품에서의 성공을 보여 주지 않으면서도 메커니즘에 대해서는 정밀했기 때문이다.

그 메커니즘은 표준 트랙인 Script MIB인 RFC 3165 곁에 놓였다. 이 MIB는 SNMP 관리자에게 스크립트 설치, 인수 전달, 인스턴스 시작, 실행 제어, 결과 수집을 위한 언어 독립적 표면을 주었다. SMX는 다른 문제를 다루었다. 그 MIB를 구현하는 에이전트가 모든 언어 엔진을 내부에 담을 필요는 없다는 것이었다. Java 런타임, Tcl 인터프리터 또는 다른 실행 시스템은 별도의 프로세스에 살면서 에이전트와 공통 프로토콜로 통신할 수 있었다.

이 분리는 확장성을 실용적으로 만들었다. 동시에 두 가지 관리 현실을 낳았다. SNMP 에이전트는 관리자가 무엇을 요청했는지, Script MIB가 무엇을 노출하는지 알았다. 런타임 시스템은 코드가 적재되고, 시작되고, 일시 중단되고, 재개되고, 중단되고, 조회될 수 있는지 알았다. 그들 사이를 오가는 응답은 그 경계에 대한 증거였다. 그것이 스크립트가 경계 너머에서 수행하기로 되어 있는 모든 것에 대한 증거는 아니었다.

SMX는 연결 설정과hello교환으로 시작했다. 그 다음start,suspend,resume,abort,status를 포함한 명령들을 정의했다. 응답은 세 자리 코드를 사용했고, 첫 자리가 성공, 실패, 비동기 통보 계열을 구분했다. 이 간결한 문법은 산문이 상태를 감추지 못하게 막았다는 점에서 유용했다. 그러나 코드는 그 범위가 온전히 유지될 때만 유용했다.

응답 231은 명령을 닫았지, 실행을 닫지 않았다

start절차가 가장 깨끗한 예이다. 런타임은 명령 문법, 스크립트, 그 스크립트의 보안 프로필을 검사했다. 요청이 진행 가능하면 런타임은 실행 중인 스크립트를 만들고, 스크립트가running상태에 도달한 뒤 231 응답을 보냈다. 요청이 아직 처리 중이면 그 상태까지 응답이 기다렸다. 시작이 실패하면 다른 코드가 실패를 보고했다.

이것은 강한 확인이었다. "바이트가 소켓에 도달했다"보다 강했다. 런타임이 요청을 해석했고 실행 중인 인스턴스를 확립했다는 뜻이었다. 그러나 그 코드는 "관리 작업이 완료되었다"를 뜻하지 않았다. 스크립트는 수 초 또는 수 시간 동안 실행될 수 있었다. 중간 관찰을 내놓거나, 복구 가능한 오류를 만나거나, 치명적으로 끝나거나, 무한히 기다릴 수 있었다. 또한 정상적으로 끝나면서 호출자가 형식이나 의미를 잘못 이해하는 답을 낼 수도 있었다.

같은 경계가 다른 명령에도 적용되었다.suspend에서는 231 응답이 일시 중단 상태 뒤에 따랐거나, 스크립트가 이미 일시 중단되어 있다고 보고했다.resume에서는running으로 돌아왔거나 인스턴스가 이미 그 상태에 있다고 보고했다.status응답은 관찰된 상태를 기술했다.abort는 중단 뒤에 또는 인스턴스가 이미 중단된 경우 232를 내놓았다. 각 응답은 하나의 제어 동작을 닫았다. 어느 것도 스크립트의 의도된 외부 효과를 보증하지 않았다.

현대 자동화에서는 대시보드가 흔히 하나의 상태 필드를 선호하기 때문에 이 구분을 잃기 쉽다. "수락됨", "실행 중", "완료됨", "효과 발생"이 별개의 주장이 아니라 하나의 색깔의 단계가 되어 버린다. RFC 3179의 메시지 흐름은 그런 압축에 저항했다. 런타임 응답에는 식별 가능한 생산자와 명령, 유한한 의미가 있었다. 나중에 무엇인가를 말하려면 나중의 이벤트가 필요했다.

결과는 끝나기 전에 도착할 수 있었다

버전 1.1은 비동기 증거에 자신의 어휘를 주었다. 응답 532는 중간 결과를 실었다. 응답 533은 Script MIB를 통한smScriptResult통보를 유발해야 하는 중간 결과를 실었다. 이 차이는 런타임-에이전트 프로토콜 안에서 이동하는 데이터와 그 연결 너머로 노출되는 관리 통보를 분리했다.

중간 결과는 스크립트를 끝내지 않았다. 당연해 보이지만 운영상 중요하다. 모니터링 스크립트는 스캔을 완료하기 전에 부분 집계를 내놓을 수 있었다. 복구 스크립트는 다음 단계를 시도하기 전에 한 단계를 보고할 수 있었다. 첫 페이로드를 최종 답으로 취급하면 남은 실행 구간이 지워진다. 그 페이로드 뒤의 침묵을 성공으로 취급하면 프로세스가 멈췄을 가능성이 지워진다.

RFC 3165는 결과 경계를 더 넓혔다. 직접 스크립트 인수와 단일 직접 결과는 OCTET STRING 값이었다. 호출자는 그 형식과 의미를 이해해야 했다. 스크립트는 다른 MIB를 통해 복잡한 결과를 노출하거나, 편리한 전송에는 너무 큰 출력을 위해 URL을 돌려줄 수 있었다. 그 경우 최초의 수신은 더 적은 것을 증명했다. URL은 출력이 그곳에 있다고 말해졌다는 증거이지, 호출자가 그것을 검색하고, 파싱하고, 신뢰했다는 증거가 아니었다.

Script MIB는 끝난 실행의 이력을 나중 수집을 위해 보관할 수 있었다. 이것은 오프라인 운영을 지원했지만, 이력은 영원하지 않았다. 노화 제어가 가득 찬 테이블에서 항목이 어떻게 빠져나가는지 결정했다. 따라서 증거에는 실행 표면뿐 아니라 보존 표면도 있었다. 관리자가 너무 늦게 물으면 제어 시스템은 어떤 것이 한 번 실행되었다는 사실을 정직하게 알면서도 그것을 판단하는 데 필요한 결과를 더 이상 갖고 있지 않을 수 있었다.

오류는 항상 종료는 아니었다

RFC 3179는 오류와 끝남을 분리했다. 응답 536은 오류를 보고했다. 응답 537은smScriptException통보를 유발해야 하는 오류를 보고했다. 어느 쪽 오류든 치명적일 수도 비치명적일 수도 있었다. 비치명적 오류는 스크립트가 계속 진행할 수 있게 했다. 치명적 오류는 실행을 끝냈고, 그 뒤에 종료 응답이 따랐다.

이것은 관찰자에게 하나가 아니라 세 개의 질문을 주었다. 오류가 발생했는가? 그것이 더 넓은 관리 인터페이스를 통해 노출되었는가? 그것이 실행 중인 인스턴스를 종료했는가? 첫 번째 질문에 답하는 로그 항목은 세 번째 질문에 답할 수 없었다. 두 번째 질문에 답하는 통보는 런타임의 실제 상태를 바꾸지 않은 채 사라지거나 지연될 수 있었다. "오류"라는 단어의 존재보다 증거의 순서가 더 중요했다.

버전 1.1은 종료에 대한 응답 538을 추가하면서 터미널 이벤트를 더 선명하게 했다. 이전의 534 "정상 종료" 및 535 "비정상 종료" 응답은 폐기(deprecated)되었다. 새 구조에서는 결과나 오류 증거가 자신의 메시지로 이동하고, 그 뒤에 하나의 명시적 종료 이벤트가 따랐다. 이 변경은 단일 터미널 레이블이 출력과 끝남 의미를 함께 짊어지게 하는 유혹을 줄였다.

그러나 538조차 업무적 판정은 아니었다. 그것은 런타임이 그 인스턴스를 종료된 것으로 간주했다는 증거였다. 종료가 유용했는지 판단하려면 호출자는 여전히 그 앞의 결과나 오류, 인수와 스크립트 신원, 반환된 바이트의 의미가 필요했다. 네트워크가 의도대로 바뀌었는지 판단하려면 관리 대상으로부터의 증거가 필요했다. 구성 읽어들이기, 카운터, 트래픽 동작, 도달 가능성 또는 그 작업에 적합한 다른 관찰이 필요했다.

보안 프로필이 코드를 옳게 만들지는 않았다

위임된 스크립팅은 권한도 옮겼다. RFC 3179는 Script MIB의 실행 소유자를 운영체제 보안 프로필과 런타임 시스템 프로필에 매핑할 것을 제안했다. 운영체제는 제한된 프로세스 환경을 만들 수 있었고, 안전한 인터프리터나 가상 머신은 언어별 제한을 강제할 수 있었다. 원격에서 선택된 코드가 그 작업을 훨씬 넘어서는 권한을 물려받을 수 있으므로, 이것들은 의미 있는 통제였다.

그러나 보안 프로필은 "이 실행이 무엇에 손댈 수 있는가?"에 답했다. "스크립트가 옳은가?"에는 답하지 않았다. 꽉 붙잡힌 스크립트가 틀린 결과를 계산할 수 있었다. 올바르게 작성된 스크립트가 틀린 인수를 받을 수 있었다. 정당한 소유자가 틀린 버전을 시작할 수 있었다. 정상 종료가 런타임 밖에서 대상이 요청을 거부한 탓에 의도한 장치를 그대로 둔 채 끝날 수도 있었다.

로컬 스크립트 저장소도 또 하나의 관리 지점이었다. 이 메모는 로컬 저장 영역의 파일에 쓸 수 있는 것이 SNMP 에이전트뿐이어야 한다고 경고했다. 다른 주체가 그것들을 바꿀 수 있다면 런타임은 특별한 권한으로 임의의 코드를 실행할 수 있었다. 따라서 관리용 스크립트 이름은 테이블 속 익숙한 레이블이 아니라 실제 실행된 바이트와 검증 가능하게 매핑되어야 했다.

전송도 같은 이유로 바뀌었다. SMX 1.1은 TCP를 유지하고 양방향 파이프를 선호 매핑으로 추가했다. 버전 1.0은 공유 비밀을 운영체제 환경 변수를 통해 전달했고, 그 노출은 보안 위험이었다. 파이프는 그 특정 메커니즘을 피했다. 그 자체만으로 전체 실행을 신뢰하게 만들지는 않았다. 파일 권한, 프로세스 신원, 종단 관리, 그리고 주변의 SNMP 접근 결정이 여전히 일치해야 했다.

이후의 SNMPv3 아키텍처, 사용자 기반 보안, 뷰 기반 접근 제어는 인증과 권한 부여에 관한 관련 맥락을 제공한다. 그러나 그것들은 특정 SMX 연결이 그것들을 사용했다는 증거, 호출자가 스크립트를 시작할 자격이 있었다는 증거, 또는 스크립트의 후속 동작이 승인된 뷰 안에 머물렀다는 증거가 아니다. 전송 보호, 실행 권한, 작업 결과는 여전히 별개의 표면이다.

유용한 장부에는 성공 필드가 하나 이상 있었다

감사 가능한 실행은 231 이전에 시작된다. 스크립트 바이트 또는 불변 버전, 소유자, 인수, 대상, 요청된 프로필, 시작 시각을 식별한다. 런타임 인스턴스 식별자와running을 확립한 응답을 기록한다. 모든 532 또는 533 결과를 순서대로 보존하고, 치명성과 함께 모든 536 또는 537 오류를 보존하며, 538 종료 이벤트를 보존한다. 그런 다음 보관된 Script MIB 이력 항목을 호출자가 수집한 것과 연결한다.

그다음이 해석이다. 호출자는 OCTET STRING이 무엇을 뜻했는지, 어떤 스키마나 스크립트 버전이 그 의미를 공급했는지 말해야 한다. 결과가 URL이었다면, 장부는 참조와 성공한 검색을 구분하고, 검색된 객체와 유효한 해석을 구분해야 한다. SNMP 통보가 기대되었다면, 기록은 생성과 수신자에게의 전달을 구분해야 한다.

그제서야 시스템은 관리 네트워크 결과의 증거를 붙여야 한다. 구성 작업에는 권위 있는 구성 표면에서의 읽어들이기가 필요하고, 관련이 있다면 실행 상태가 바뀌었다는 증거가 필요하다. 진단 작업에는 관찰 창과 분모가 필요하다. 트래픽 개입에는 이후의 카운터나 패킷 관찰이 필요하다. 명령 수신증은 그 빈칸을 사후에 채울 수 없다.

RFC 3179의 역사적 가치는 이 안무(choreography)에 있다. 그것은 스크립트가 관리를 자율적이거나 무결점으로 만들 것이라고 약속하지 않았다. 요청 처리, 실행 상태, 중간 출력, 오류, 종료에 서로 다른 메시지를 배정했다. 프로토콜은 런타임 경계에서 끝났고, 결과의 의미는 호출자에게 남겼다. 그 겸손은 여전히 유용하다. 모든 수신증이 하나의 전이를 증명하고, 어떤 수신증도 자신이 관찰하지 않은 결과로 승격되지 않을 때 자동화는 책임 가능해진다.

출처와 한계

RFC 3179의 프로토콜, 상태, 절차, 비동기 응답, 전송 매핑, 보안 고려사항은RFC 3179 텍스트,RFC Editor 기록,HTML 판,IETF 이력,정오표 조회에 문서화되어 있다. 인접한 Script MIB 모델, 결과 의미, 보관된 실행 이력은RFC 3165 텍스트,기록,HTML 판에서 온다. 버전 비교는 폐기된RFC 2593 텍스트와기록으로 제한된다.

이후의 SNMP 맥락은SNMP 아키텍처,사용자 기반 보안 모델,뷰 기반 접근 제어 모델에서 온다. 명령, 상태, 증거, 결과의 분석적 분리는 Lu Heng의running-code primacy,reality layers,minimum initial specification에세이에서 영향을 받았다. 16개 출처 세트는 2026년 10월 2일 Asia/Shanghai 기준으로 확정되었다.

이 기록들은 채택이나 결과가 아니라 프로토콜 설계와 상태를 증명한다. 현재의 어떤 구현, 운영자, 스크립트, 관리 장치, 보안 프로필, 공격, 오류율, 절약된 노동, 네트워크 변경 또는 서비스 결과도 식별하지 않는다. 응답 코드는 그 지정된 상태 전이 안에서만 해석된다. 최종 증거 연쇄 분석은 Sofia Ren의 편집적 독해이며, RFC 저자들이나 인용된 기관이 주장하는 것이 아니다.