커널이 다시 시작되면 변수는 없어지지만 외부에서 처리한 일까지 사라지는 것은 아니다. 화면에 결과 목록이 비었다고 항목 전체를 다시 실행하면 중복 처리가 생길 수 있다. 나는 이어하기의 근거를 Python 변수만으로 만들지 않고 호스트의 파일 원장에서 읽도록 했다. 다시 여는 동작과 다시 실행하는 동작을 나눈 것이다.

변수와 원장의 소유 위치를 다르게 둔다

Workflow 인스턴스는 실행 중 결과를 메모리 목록에 담지만 프로젝트 업무 모드의 status는 program.status를 호스트에 요청한다. 호스트는 프로그램 위치 아래에서 context key와 jobId를 조합한 파일을 찾는다. 커널 안의 목록을 다시 만드는 것과 디스크의 업무 기록을 읽는 경로가 다르다.

보관함의 단일 실행 모드는 status에서 자체 결과 목록을 보여 주므로 같은 영속성으로 설명하지 않는다. 파일 원장 기반 이어하기는 프로젝트 업무 노트북의 경로다. 나는 “주피터를 쓴다”는 말보다 어떤 어댑터가 결과를 보관하는지 확인하는 것이 복구 설명에 더 중요하다고 봤다.

파일이 없는 경우와 잘못된 파일을 구별한다

원장을 읽을 때 파일이 없으면 새 업무의 빈 항목 목록을 만든다. JSON을 읽지 못하거나 다른 오류가 나면 NOTEBOOK_JOB_RECORD_INVALID다. 손상된 기록을 빈 목록으로 바꿔 모든 항목이 미실행인 것처럼 취급하지 않는다. 자료 없음과 기록 해석 실패에는 다른 의미가 있다.

원본 함수가 모든 필드에 완전한 스키마 검증을 하는 것은 아니다. 이 글은 그보다 넓은 무결성 보장을 붙이지 않는다. 아래 독립 모듈은 더 좁은 합성 기록 형식에 필드와 identity 검사를 추가해 시험했다. 원본 구현과 설명용 확장을 구분해 무엇이 실제 제품 코드인지 남겼다.

최종 결과 전의 기록도 복구 자료가 된다

호스트는 started에 해당하는 running 항목을 먼저 저장한 뒤 실제 실행을 요청한다. 최종 결과가 돌아오면 runId와 완료 단계, 산출물 위치와 오류를 덧붙인다. 마지막 저장이 없더라도 처음 실행하려던 항목의 흔적은 남길 수 있다. 그 흔적을 성공으로 바꾸지 않는 것이 중요하다.

기록이 running인 채 남았다고 실제로 아직 프로세스가 살아 있다고 단정하지 않는다. 반대로 프로세스가 없어졌다고 외부 행동이 없었다고 판단하지 않는다. 복구는 이 두 불확실함을 확인하는 일이다. 원장을 읽는 기능이 실제 서비스의 원래 결과를 자동으로 확인해 준다고 쓰지 않는다.

기록의 경계는 프로그램·프로젝트·업무다

같은 jobId라도 context key가 다르면 다른 파일을 읽는다. 프로그램의 위치도 따로 들어간다. 이 경계 덕분에 다른 프로젝트의 메모리가 비었다고 원래 프로젝트의 결과를 가져와 완료 처리하지 않는다. 사용자는 이어갈 프로젝트와 프로그램을 먼저 맞춰야 한다.

커널 재생성으로 새 연결을 얻었다는 사실은 그 경계를 바꿀 이유가 아니다. 반면 새 프로젝트로 복사했다면 새로운 업무 자료일 수 있다. 나는 ID를 유지하라는 설명과 다른 소유의 기록을 섞지 말라는 설명을 함께 둔다. 저장 위치가 있다는 것만으로 올바른 기록을 읽었다는 보장은 되지 않는다.

시험에서는 서비스를 다시 만들어 읽는다

기존 시험은 한 서비스를 사용해 항목을 완료한 뒤 새 NotebookPrograms 인스턴스로 같은 항목을 요청한다. reused 결과와 실행 횟수를 확인하고 상태 목록에서 이전 실패 이력과 실행 폴더를 읽는다. 같은 메모리 객체를 계속 쓰는 시험만으로 이어하기를 설명하지 않는다.

이 시험은 호스트 서비스 재생성과 파일 원장을 다루며 실제 Jupyter 커널의 모든 종료 조건을 재현한 것은 아니다. 이번 콘텐츠 작업도 원래 커널을 종료하지 않았다. 독립 모듈에서는 별도 파일 원장 인스턴스로 다시 여는 동작과 저장 실패를24개 시험에 넣었다. 파일 지속과 커널 복구의 시험 범위를 끝까지 나눴다.

다시 시작하기는 남은 사실을 읽는 데서 시작한다

화면이 비어 있거나 변수가 사라지면 새로 시작한 듯 느껴진다. 그러나 업무의 시간은 커널의 수명보다 길 수 있다. 나는 이어하기 화면에서 이전 항목의 상태와 실제 실행 기록을 먼저 읽게 하는 것이 사용자의 기억에 맡기는 것보다 낫다고 생각한다.

다른 컴퓨터에서 쓰려면 같은 파일이 있다는 것만으로 충분하지 않다. 정의와 SDK, 계정과 자료 연결, 쓰기 주체도 확인해야 한다. 이 구현이 공통 외부 PC 연결기를 완성했다는 뜻은 아니다. 복구 가능한 범위를 정확히 말해야 사용자가 새 출발과 기존 업무의 계속을 구분할 수 있다.