1. 다시 실행을 클릭하기 전에 상황을 고정하세요
작업 추가를 멈추고 같은 배치의 실행이 아직 활성 상태가 아닌지 확인하세요. 연결이 끊어졌다고 해서 항상 소프트웨어가 멈춘 것은 아닙니다. 가능하다면 그 상태를 확인하세요. 두 번째 복사본을 실행하면 중복이 생기거나 같은 대상에 기록될 수 있습니다.
로그, 입력 파일 목록, 설정, 오류 메시지를 보관하세요. 추적 표를 수정하기 전에 복사본을 만들어 두세요. 의심스러운 출력물은 원본이나 이미 승인된 결과를 덮어쓰지 않도록 별도 위치에 보관하세요. 대상 저장 공간이 가득 찼다면, 무엇을 보존해야 하는지 파악한 뒤 공간을 마련하거나 다른 대상을 준비하세요.
2. 각 항목에 안정적인 식별자를 부여하세요
한 행은 하나의 예상 작업을 나타내야 합니다. 예를 들어 IMG-017은 catalogue/chaise-face.png와 연결됩니다. 경로만으로는 이동 후 모호해질 수 있고, photo.png 같은 짧은 이름은 여러 폴더에 존재할 수 있습니다. 고유 식별자와 원래 입력과의 대응 관계를 유지하세요.
설정 식별자, 출력 경로, 상태, 시도 횟수, 짧은 사유를 추가하세요. 이 로그는 일반 표나 프로젝트의 CSV로 충분합니다. 이미지, 비밀번호, 머신의 전체 기술 로그까지 담을 필요는 없습니다. 누구든 올바른 항목을 찾고 그것이 재개 목록에 포함된 이유를 설명할 수 있어야 합니다.
이미 승인된 식별자 뒤의 원본을 수정하지 마세요. 새 항목이나 다른 변환에는 명확히 기록된 새 버전이 필요합니다. 그렇지 않으면 같은 식별자가 결국 호환되지 않는 두 작업을 가리키게 되어, 로그로 무엇이 완료되었는지 판단할 수 없게 됩니다.
| ID | 구성 | 상태 | 출력 또는 사유 |
|---|---|---|---|
| IMG-017 | essai-02 | 승인됨 | IMG-017.png 열어서 확인함 |
| IMG-018 | essai-02 | 확인 필요 | 파일은 있으나 확인 미완료 |
| IMG-019 | essai-02 | 실패 | 처리 중 메모리 부족 |
| IMG-020 | essai-02 | 할 일 | 예상 출력을 찾을 수 없음 |
3. 로그와 실제 파일을 대조하세요
예정된 각 식별자에 대해 예상 출력을 찾으세요. 용도에 필요한 형식, 크기, 내용을 확인한 뒤 대상 도구로 파일을 여세요. 이미 승인되었고 여전히 존재하는 출력은 재개 목록에서 제외됩니다. 로그에는 «승인됨»이라는데 출력이 없다면, 다시 계산할지 결정하기 전에 먼저 보관된 복사본을 찾으세요.
중단 시점에 «진행 중»이던 항목은 확인 대상으로 분류하세요. 일부는 완전할 수 있고 일부는 부분적일 수 있습니다. 파일 날짜나 크기는 단서일 뿐 검증은 아닙니다. 알려진 식별자 없는 추가 파일은 출처를 찾을 때까지 따로 보관하세요.
이미지의 경우 Pillow는 파일 식별, 픽셀 읽기, 구조 검증을 구분합니다. 따라서 헤더만 여는 프로그램은 모든 것을 확인하지 못합니다. 자동 검사로 일부 손상을 찾을 수는 있지만, 텍스트가 읽히는지나 색상이 결과물에 맞는지는 판단하지 못합니다.
4. 불완전한 항목과 거부된 결과를 구분하세요
부분 출력은 다시 하거나 완전한 복사본에서 복원해야 합니다. 완전하지만 받아들일 수 없는 출력은 먼저 결함을 이해해야 합니다. 읽을 수 없는 입력이나 체계적으로 메모리가 부족한 경우에 같은 설정으로 다시 실행하면 문제가 반복될 가능성이 높습니다. 이 식별자를 다시 대기열에 넣기 전에 수정 사항을 기록하세요.
상태는 적게 유지하세요: 할 일, 진행 중, 확인 필요, 승인됨, 실패. «승인됨»으로의 전환은 계산 시작이 아니라 확인 후에 이루어집니다. 항목을 제외하기로 했다면 사유와 프로젝트에 필요한 동의를 담아 «제외됨» 상태를 추가하세요. 예상 총계에서 조용히 사라져서는 안 됩니다.
새 시도를 새 작업으로 세지 마세요. IMG-019는 시도가 세 번이어도 채택된 출력은 하나일 수 있습니다. 이 구분이 예순 번의 실행과 예순 개의 서로 다른 결과물을 혼동하지 않게 해줍니다.
예시: 아직 필요한 열아홉 개 항목 찾기
이 예시 시나리오는 서로 독립적인 이미지 예순 장을 다룹니다. 중단 후 확인한 결과 마흔한 개의 출력이 승인되었고, 네 개는 부분적이며, 여섯 개는 실패했고, 아홉 개는 없습니다. 로그는 41 + 4 + 6 + 9 = 60개의 식별자를 제대로 포함합니다. 재개 대상은 열아홉 개 항목이며, 여섯 번의 실패 원인을 해결하는 것이 조건입니다.
담당자는 열아홉 개의 식별자 목록을 재구성한 뒤, 네 개의 부분 파일, 여섯 개의 오류, 아홉 개의 출력 없는 작업을 구분합니다. 먼저 수정된 항목 하나와 누락된 항목 하나를 다시 처리합니다. 또한 이미 승인된 이미지가 선택 항목에 포함되지 않았음을 확인합니다. 이 간단한 점검으로 나머지 처리 전에 목록의 유효성을 검증합니다.
이후 추가 항목 열여덟 개가 승인되었는데도 소스 파일 하나가 여전히 판독 불가능하다면, 결과는 승인 오십구 개와 설명된 실패 하나입니다. 배치가 육십 개에서 완료되었다고 선언되지 않습니다. 다음 선택은 올바른 입력을 다시 찾거나 해당 항목의 제외를 승인받는 것이지, 그 줄을 숨기는 것이 아닙니다.
| 점검 후 상태 | 식별자 수 | 제안된 처리 |
|---|---|---|
| 승인 및 출력 확인됨 | 41 | 보존, 재실행 없음 |
| 부분 출력 | 4 | 별도 보관 후 재작업 |
| 식별된 실패 | 6 | 재시도 전 원인 수정 |
| 출력 없음 | 9 | 해당 항목부터 다시 시작 |
| 재작업할 총계 | 19 | 4 + 6 + 9, 중복 없음 |
5. 별도 위치에서 재작업을 진행하세요
선별된 식별자만 담은 재작업 폴더를 준비하거나 소프트웨어의 명시적 선택 기능을 사용하세요. 실행 전에 목록을 다시 확인하세요. 도구에서 '기존 파일 무시'를 제공한다면 그 의미를 확인하세요. 부분 파일이 존재한다는 이유로 잘못 무시될 수 있습니다. 검증된 로그가 기준입니다.
새 출력은 별도 폴더에서 해당 설정 및 시도와 함께 생성하세요. 이전 버전을 교체하기 전에 검증하세요. 일부 스크립트는 확인 없이 기존 파일을 덮어쓸 수 있으며, Python은 특히 os.replace에 대해 이를 문서화하고 있습니다. 명명 규칙만으로는 덮어쓰기를 방지할 수 없습니다.
결함을 수정하기 위해 설정을 변경하면 그 변경을 가시적으로 유지하세요. 두 구성의 출력이 동일한 기준을 충족하고 프로젝트에서 혼용이 허용된다면 둘 다 보존할 수 있습니다. 시각적으로 균일한 시리즈를 위해서는 폴더를 합치기 전에 새 출력과 이전 출력을 비교하세요.
6. 수량이 아니라 식별자별로 결과를 검증하세요
마지막에는 각 예상 식별자에 대해 설명된 상태가 있어야 합니다. IMG-017의 사본 두 개가 IMG-020의 부재를 보상하지 못합니다. 이름의 고유성, 항목과의 대응, 채택된 출력의 구성을 확인하세요. 재작업한 파일을 열고 재작업의 원인이 되었던 항목을 점검하세요.
완료된 폴더에는 승인된 출력, 갱신된 로그, 설정, 그리고 제외되거나 아직 막힌 항목의 목록이 포함됩니다. 이 일체를 검증된 사본과 함께 백업하세요. '승인됨'이라는 한 줄은 파일이나 그 백업을 대신하지 못합니다.
이 방법은 독립적인 작업을 해당 항목부터 재작업합니다. 시뮬레이션, 렌더링 또는 학습을 정지 명령의 정확한 지점에서 자동으로 이어가는 것은 불가능합니다. 이러한 작업에는 소프트웨어별 재개 상태가 필요합니다. 또한 임대 환경에 남아 있는 폴더가 기간 이후에도 보존된다고 가정하지 마세요. 사본을 준비하세요.