실행 결과를 만든 묶음과 근거를 추적한다
배포 계약은 어느 프로그램/모델을 어떤 자료·장치/조건에서 어떤 입력/출력 의미와 감독 범위로 실행하는지 정한 약속이다. 코드 commit만 같아도 카메라 보정/정규화·모델/관절 순서나 driver 설정이 다르면 동작이 달라질 수 있다. 최종 리포트는 파일 목록뿐 아니라 요구/시험과 실제 결과의 연결을 보여야 한다. 이 단위에서는 실제 외부 배포를 하지 않고 필요한 표/판정을 설계한다.
provenance는 산출물이 어디서 언제 어떻게 만들어졌는지 추적할 근거를 뜻한다. SLSA 공식 설명은 검증 가능한 소프트웨어 산출물의 출처 정보를 다룬다. 교재의 작은 manifest를 적었다고 SLSA 등급/검증 체계를 충족했다고 선언하지 않는다. 여기서는 원본 데이터/선택·빌드/검사·실행 결과의 ID/출처를 연결하는 기본 원칙으로 사용한다.
해시는 파일 내용의 동일성을 확인하는 식별 근거이고, 이름/태그는 사람이 붙인 라벨이다. Docker 공식 안내는 같은 태그가 다른 이미지로 바뀔 수 있어 digest 고정을 구분한다. 같은 이미지/해시라도 host kernel/driver·주변장치·물리 배치/자료와 모든 실행 결과가 같다는 보장은 아니다. 보존한 파일의 동일성과 과업 성능/물리 재현을 구별한다.
manifest는 입력에서 실제 출력까지 묶는다
가상 묶음 A의 표를 작성해 보자. 아래 c1/mA 같은 값은 설명용 ID이며 실제 commit/암호학적 hash가 아니다. 실제 프로젝트에서는 정확한 revision/digest·파일/자료 경로와 기록 시각/생성 근거를 사용한다.
| 층 | 합성 묶음 A의 계약 |
|---|---|
| 코드/런타임 | c1/runtime_r1, 필요한 OS/아키텍처·의존성/연산 지원 별도 기록 |
| 데이터/분할 | d1, 물체/세션별 그룹·선택/잠근 시험 ID |
| 모델/전처리 | mA/pA, 두 RGB camera·CHW·float32, 해상도/시간창·통계 sA |
| 행동 | schema S1, 6성분 절대 관절 목표 rad·정해진 순서, gripper 별도 |
| 보정/장치 | cal1, map/base/camera/TCP 방향·단위, mount1/tool1/driver1 |
| 시간/감독 | 관측 ID/clock·최대 나이, 명령 TTL/epoch·제한/중단·재개 규칙 |
모델이 단순히 6개 float를 낸다는 정보만으로 행동 계약이 완성되지 않는다. 정규화 복원·absolute/delta와 기준 시점/frame, joint/gripper의 순서/단위가 필요하다. calibration 파일이 같아도 카메라/공구 장착 위치가 바뀌면 유효성은 다시 확인해야 한다. 배터리/물체·접촉/주변 온도와 현재 상태도 과업 조건에 포함한다.
후보 B가 출력 schema S2의 7성분이고 마지막이 gripper인데 여전히 S1 소비기에 넣으면 호환되지 않는다. shape가 같더라도 순서/단위·행동 표현이 다르면 실패할 수 있다. mB와 옛 통계 sA를 조합하는 것도 검증한 묶음이 아니다. 요청마다 어느 묶음/epoch를 선택했는지 확인하고 늦은 이전 응답/남은 chunk를 섞지 않는다. 새 카메라 이름을 옛 이름으로 바꾸는 것만으로 동일 관측이 되지도 않는다.
admission 표는 모든 관문을 함께 적용한다
합성 현재 검사 시각 8.120 s, 근거 관측 8.000 s, 명령 발행 8.080 s를 같은 clock으로 주자. 최대 관측 나이는 0.100 s, 입구 TTL은 0.050 s다. 관측 나이는 0.120 s로 0.020 s 초과하고 명령 나이는 0.040 s로 0.010 s 여유다. 명령 봉투가 새롭다고 관측 조건 실패가 없어지지 않는다.
버전/권한과 현재 상태·제한이 맞아도 관측 실패이면 새 동작 admission을 통과시키지 않는다. admission은 여기서 명령을 새로 실행 경로에 받아들이는 판정이다. 이미 실행된 동작의 취소/물리 정지를 의미하지 않으며 M30.04의 감독/결과 확인을 따로 추적한다. 반대로 시간 조건이 통과해도 S1/S2 혼용이나 오래된 cal1의 장착 변경이면 전체 관문은 통과하지 않는다.
기록 표에는 요구 ID, 사용할 관측/버전·현재 상태, 판정 규칙, 원본 근거 ID/시각과 통과/거부/미상을 연결한다. 결함이 발견되면 실패를 숨기지 않고 어떤 관문을 막았는지·어떤 변경/재검증이 필요한지 남긴다. 모든 근거가 없는데 '대체로 정상' 하나로 실행 여부를 채우지 않는다.
시험 단계별 숫자를 바꾸어 보고하지 않는다
별도 합성 보고 입력에 '모형상 작업 기록 20건 중 성공 라벨 18건, shadow 관측 20건 중 admission 조건 만족 후보 18건, 실제 장비 trial 0건'이 있다고 하자. 이 표는 설명을 위해 만든 가상 기록이며 실제 시뮬레이터/정책을 실행해 얻은 것이 아니다. 첫 비율 90%는 가상 모형 기록의 성공 라벨 비율, 두 번째 90%는 비실행 후보 조건 충족률이다. 실제 장비 성공률은 0%가 아니라 미시험/미정의다.
세 행을 합쳐 36/40의 실제 성공률로 보고하면 다른 사건/단계를 섞은 것이다. 실제 trial의 성공 정의/초기 조건·개입/미상과 분모/원본이 따로 있어야 한다. M30.05의 독립성·층별/신뢰구간도 해당 설계/자료에 적용한다. 수치가 잘 나왔다는 이유로 합성·replay/shadow 결과를 실물 성과로 승격하지 않는다.
보고 문장은 '이 가상 입력에서 관문 계산을 통과했다', '이 실행 환경에서 특정 코드 출력을 재현했다', '실제 장비 조건에서 과제를 완료했다'처럼 근거 범위에 맞게 쓴다. 예상/관측/미확인과 실패 원인을 구분하면 다른 사람이 무엇을 다시 확인해야 할지 알 수 있다. 영상 한 장이나 데모 하이라이트만으로 전체 시험 분포를 대신하지 않는다.
승격/롤백은 현재 세계에서 검증한다
승격 전에는 후보 묶음/기준 입력·변형/거부·시간/메모리와 조건별 품질, 감독/중단·복구 및 담당 주체/권한을 점검한다. 전환 시 새 요청을 보류하고 현재 goal/장비 상태와 큐/필터·후보 이력/epoch를 정리하는 계약이 필요하다. 실제 운전은 해당 장비/현장의 별도 절차에 따르며 교재의 합성 표 통과로 승인하지 않는다.
롤백은 검증된 이전 묶음으로 돌아가는 관리 선택이다. 옛 파일을 복사하면 물체/로봇 자세·이전 명령의 영향까지 사라지는 것은 아니다. 이전 모델/전처리·통계/driver/보정의 호환과 가용성, 현재 장면/관측·권한/실행 상태를 다시 확인한다. 장착이 바뀌어 옛 cal1이 유효하지 않으면 옛 묶음이 보존되어도 즉시 재개할 수 없다.
최종 리포트는 목적/요구, 구성/manifest·실행/비실행 단계, 실험 설계/원본·계산 방법, 조건별 결과/실패·개입/미상, 승격/rollback 판단과 재현/다음 검증 순서로 쓴다. 재현 절차는 장비 없는 계산/자료 해석과 실제 장비 전제가 필요한 단계를 나눈다. 기존 6.5 End-to-End 배포와 6.8 포트폴리오 패키징을 연결하자. 이 단위의 산출물은 설계/리포트 초안이며 실제 배포·출판 파일 생성은 아니다.