자동화 코드를 남겼는데 다음에 어느 입력으로 실행해야 하는지 알 수 없다면 재사용하기 어렵다. 나는 Python 파일만 저장하지 않고 실행 정의와 노트북, 설명과 검증 상태를 함께 보관했다. 실행 때 생긴 결과는 다시 별도 폴더에 남겨 어떤 정의를 어떤 입력으로 사용했는지 구분하도록 했다.
recipe는 실행할 일을 설명하는 정본이다
recipe.json에는 시작 위치와 매개변수, 탭 별칭과 실제 단계가 있다. workflow.py에 업무 순서를 따로 복사해 두고 어느 쪽이 최신인지 추측하게 만들지 않는다. 일반 생성 진입점은 공통 SDK의 run_recipe로 전달한다. 매체별 특수 실행기는 있을 수 있으므로 모든 Python 파일이 같은 몇 줄이라고 단정하지 않는다.
정의는 엄격한 Recipe 형식으로 읽는다. 지원하는 단계와 필드를 검사하고 임의 code나 과거 element ref를 넣으면 거절한다. 그렇다고 Python 파일 자체가 운영체제 샌드박스라는 의미는 아니다. 저장된 정의 계약과 로컬 프로그램의 일반 파일 접근 능력은 별도로 봐야 한다.
노트북은 입력부터 결과까지 읽는 작업 화면이다
inspect.ipynb는 입력 설정, 자료·대상 확인, 업무 실행, 결과와 오류 확인의 셀로 구성한다. 같은 프로그램 ID의 Workflow를 만들고 prepare와 run, status를 호출한다. 설명만 있는 보고서가 아니라 실행 전후의 확인 순서를 담는 동반 문서다.
그러나 노트북 파일을 열었다는 것과 셀을 실행했다는 것은 다르다. 이전 출력도 지금 실행한 결과로 볼 수 없다. 보관함의 단일 항목 실행과 프로젝트 안에서 여러 항목을 이어가는 방식도 구분해 안내한다. 파일 확장자가 같다는 이유로 실행 수명과 재개 규칙까지 같다고 추정하지 않게 했다.
manifest는 표시와 검증 상태를 이어 준다
manifest에는 프로그램 ID와 이름, 버전, 연결 프로필, hash와 상태가 들어간다. 파일을 처음 만들면 실행 검증 전이라고 표시한다. 같은 이름으로 다시 저장해도 새 ID의 위치에 남기므로 이전 파일을 덮어쓰지 않는다. 이름은 사람이 찾는 단서이고 식별자는 보관 대상을 구분한다.
파일 무결성 hash는 recipe·workflow·노트북 셀 소스를 대상으로 계산한다. 실행 산출물을 정의와 같은 hash에 섞지 않는다. 코드가 같다는 것과 이번 실행의 결과가 올바르다는 것은 다른 질문이기 때문이다. manifest에 완료라고 적혀 있다는 사실만 확인하고 실제 파일 대조를 생략하지 않게 만들었다.
결과는 실행마다 다른 위치에 남긴다
실행은 새 run ID와 결과 위치를 가진다. result.json과 실제 산출물, 실행한 노트북이 정의 폴더의 과거 파일과 섞이지 않게 한다. 같은 프로그램을 여러 번 실행해도 어느 결과를 읽는지 구분할 수 있어야 한다. “마지막 결과”라는 화면 이름만으로 모든 실행의 역사를 대체하지 않는다.
현재 메모리의 active나 last와 디스크에 남은 실행도 구별한다. 기록을 읽을 때 ID와 프로필, 프로그램이 맞는지 검사하는 경로가 있다. 과거 running 기록은 결과 미확정으로 해석한다. 파일이 남았다고 이전 실행이 완료됐다는 뜻은 아니며 무작정 다시 실행할 근거도 아니다.
설명 파일에도 실행 전후의 차이를 쓴다
README는 같은 정의와 SDK를 사용한다는 관계, 입력 변경 위치와 재검증 필요를 설명한다. 로그인과 쿠키, 실행 접근 자격은 프로그램 한 벌에 복사하지 않는다. 재사용할 파일과 그때만 유효한 연결을 섞지 않으려는 운영 문서다.
기존 단위 시험은 두 번 저장한 파일이 서로 다른 ID인지, 다른 프로필에서 읽지 못하는지, 한 파일을 바꿔도 이전 사본이 남는지 확인한다. 이번 글에서는 해당 함수와 시험을 읽었다. 새 사용자 프로그램을 실행하거나 이 묶음만으로 다른 PC 설치가 검증됐다고 보고하지 않는다. 공통 SDK의 버전과 외부 환경도 실제 실행의 조건이다.
재사용할 사람에게 남겨야 할 질문이 바뀌었다
코드 한 개만 남길 때는 “실행되느냐”부터 묻게 된다. 한 벌로 남기면 어떤 입력과 대상이 필요한지, 현재 정의가 검증 당시와 같은지, 결과를 어디서 확인하는지부터 검토할 수 있다. 나는 파일 수를 늘리는 것보다 이 질문을 명확히 남기는 것이 중요하다고 봤다.
홈페이지의 공유 모듈도 같은 방식으로 코드와 시험, 예제와 한계를 함께 제공하려 한다. 내려받았다는 것과 현장 적용에 성공했다는 것은 다르다. 설명이 붙은 실행 재료를 공유해야 다음 제작자가 자기 업무의 조건을 확인하며 이어갈 수 있다. 보관은 실행 파일의 저장보다 넓은 작업이었다.