결과물과 원본, 설정을 망설임 없이 찾아보세요.

설명할 수 있는 구조를 선택하세요

프로젝트 이름을 딴 폴더를 만들고, 역할이 분명한 몇 개의 위치를 마련하세요. 사람 이름이나 오늘 날짜만으로는 6주 후에 내용을 파악하기 어려울 수 있습니다. 최상위에 둔 노트에 입력, 진행 중인 시험, 최종 납품물이 어디 있는지 설명해야 합니다.

케임브리지 대학교는 폴더 정리와 일관된 이름 규칙을 미리 정해 두기를 권장합니다. 아래 모델은 간단한 작업 세션을 위한 BriefGPU의 제안입니다. 사용 중인 소프트웨어가 이미 프로젝트 구조를 정해 두고 있다면 그에 맞게 조정하세요. 프로젝트가 연결된 리소스를 찾을 수 있는지 확인하지 않은 채 옮기지 마세요.

받은 입력을 식별 가능한 상태로 유지하세요

첫 처리 전에 원본 이름과 위치를 포함한 소스 목록을 작성하세요. Cornell이 원시 데이터에 대해 권장하듯, 이러한 입력의 손상되지 않은 버전을 보관하세요. 단순히 '원본'이라는 이름만으로는 내용이 보호되지 않습니다: 소프트웨어에 다른 출력 폴더를 지정하고 테스트 파일로 동작을 확인하세요.

계산 전에 입력을 변환하거나 자르아야 한다면, 이 준비 작업을 명확히 식별된 단계로 처리하세요. 받은 소스와의 연결을 유지하세요. 그러면 이미 존재하던 결함, 준비 과정의 문제, GPU 처리의 효과를 구분할 수 있습니다.

새 소스가 이전 소스를 대체할 때는 버전과 다시 검토할 출력을 기록하세요. 이해하고자 하는 테스트에서 사용 중인 파일을 조용히 덮어쓰지 마세요. 규칙은 유용한 출처를 보존하는 것이지, 모든 작업 복사본을 무한정 보관하는 것이 아닙니다.

각 작업 단위에 안정적인 식별자를 부여하세요

image-001과 같은 짧은 식별자는 여러 테스트에서 동일한 입력을 추적하는 데 사용됩니다. 출력이 승인되더라도 그 역할은 변하지 않습니다. '좋음', '나쁨', '거의 최종' 등에 따라 파일 이름을 계속 바꾸지 말고, 인벤토리에 검증 상태를 기록하세요.

입력 100개라면 번호 001부터 100까지가 규칙적인 기준이 됩니다. 납품에 필요하다면 업무 참조 번호를 추가하세요. 서로 다른 하위 폴더에서 받은 photo.png라는 두 파일이 같은 것을 나타낸다고 가정하지 마세요. 입력의 전체 경로가 식별자와 계속 연결되어 있어야 합니다.

대상 도구와 호환되는 이름을 선택하세요. Windows는 특히 콜론, 물음표, 별표 문자를 예약해 두고 있으며, 일반 규칙으로는 대문자만으로 두 이름을 확실히 구분할 수도 없습니다. image-007_essai-02.png 같은 이름은 이러한 모호함을 피할 수 있습니다. 보편적인 호환성을 약속하기보다는 다른 도구의 고유한 제약 조건을 확인하세요.

예시: 두 번의 시도, 하나의 소스 컬렉션

두 개의 폴더에 도착한 여덟 개의 이미지를 가정해 봅시다. 인벤토리는 image-001부터 image-008까지 할당하고 원래 경로를 유지합니다. 첫 번째 패스는 essai-01 설정을 사용하며, 모든 출력은 해당 폴더에 들어갑니다. image-003과 image-006의 결함으로 인해 두 입력만 대상으로 한 두 번째 시도를 하게 됩니다.

첫 번째 시도의 만족스러운 여섯 개 결과는 폴더를 더 일관되게 만들기 위해 다시 계산하지 않습니다. 인벤토리는 각 입력에 대해 어떤 출력이 채택되었는지 표시합니다. v01 납품에는 예상된 이름을 가진 여덟 개의 파일이 포함되며, 그 출처가 두 번의 시도에 걸쳐 있더라도 마찬가지입니다. 이 예시는 조직 방식을 설명하는 것으로, 설정이 반드시 결과를 개선한다고 가정하지는 않습니다.

시도 시점의 설정을 보존하세요

essai-02.txt라는 파일은 소프트웨어가 매개변수를 내보낼 수 없는 경우 단순한 메모일 수 있습니다. 도구 버전, 해당되는 경우 모델, 관련 입력, 선택한 값을 기록하세요. 이전 시도와 비교하여 변경한 이유도 추가하세요. 설정이 창에서만 보이는 경우 스크린샷으로 메모를 보완할 수 있습니다.

매번 시도 후 교체되는 단일 '현재 설정' 메모는 피하세요. 그것은 마지막 시도만 설명하고 이전 출력은 더 이상 설명하지 못합니다. 여러 시도가 동일한 매개변수를 사용하는 경우, 불필요하게 복사하지 말고 동일하게 식별된 구성을 참조하세요.

소프트웨어 버전과 매개변수는 결과를 설명하기 쉽게 해주지만, 그것만으로 동일한 재현을 보장하지는 않습니다. 일부 애플리케이션은 다른 정보나 리소스를 요구합니다. 특히 학습 상태의 경우 정확한 재현이 필요하면 해당 문서를 따르세요.

의사 결정을 설명하는 일지를 작성하세요

일지는 인벤토리를 보완합니다. 인벤토리는 '이 입력은 어디까지 진행되었는가?'에 답하고, 일지는 '왜 변경했는가?'에 답합니다. 날짜가 있는 몇 줄이면 충분합니다. 관련 시도, 관찰, 결정, 다음 확인 사항을 적으세요. 아무도 활용할 수 없다면 소프트웨어의 모든 메시지를 복사하지 마세요.

예시의 경우 유용한 한 줄은 다음과 같습니다. 'essai-01: image-003과 image-006에서 윤곽선이 불완전함, 설정 B로 이 두 입력을 다시 작업, 나머지 출력은 최종 검증 대기로 유지.' 검토 후 실제 결정을 추가하세요. 결함이 존재하지 않았던 것처럼 초기 관찰을 다시 쓰지 마세요.

기술 일지를 전달하기 전에 다시 읽어보세요. 개인 경로나 접근 수단이 포함되어 있을 수 있습니다. 비밀 정보는 문서 폴더와 분리하여 보관하세요. 동료를 위한 메모는 그가 필요로 하는 정보와 함께 작업을 설명해야 합니다.

분류, 납품, 백업을 구분하세요

작업 폴더는 여러분의 판단에 유용한 시도를 보관합니다. 납품 폴더는 수신자가 받아야 할 것을 모읍니다. 백업은 필요한 항목을 다른 대상에 보관하고 복사본을 검증합니다. 같은 공간에 나란히 놓인 세 개의 폴더만으로는 이 세 가지 기능을 수행하지 못합니다.

모든 원본을 각 시도 폴더에 복사하지 마세요. 인벤토리를 통해 출력과 입력을 연결하세요. 납품의 경우 자립적인 집합을 전달하기 위해 선택된 복사본이 유용할 수 있으며, 이때 출처와 버전을 기록하세요. 백업은 인벤토리와 전송 후 검증을 자세히 설명하는 전용 가이드를 따르세요.

제외된 변형을 정리하기 전에, 결정을 설명하거나 작업을 다시 하기 위해 여전히 필요한 변형이 있는지 확인하세요. 이 조직 방식은 어떤 보존 기간도 강제하지 않습니다. 무엇을 보관할 가치가 있는지 결정하고, 기준이 되는 복사본을 다시 찾을 수 있게 해줍니다.

무작위로 선택한 출력으로 점검하세요

먼저 소프트웨어를 열지 않고 납품 파일을 하나 선택하세요. 파일 이름과 인벤토리를 바탕으로 그 입력, 그것을 생성한 시도, 설정, 승인 결정을 찾아보세요. 재작업이 필요했던 출력으로 반복하세요. 과정이 기억에 의존한다면 추적에 연결 고리가 빠진 것입니다.

그다음에는 수량을 확인하세요. 예정된 입력 수, 채택된 결과물, 보류된 항목, 제외된 변형본을 점검합니다. 폴더가 잘 정리되어 있어도 내용은 여전히 불완전할 수 있습니다. 차이에 이유가 있고 다른 사람이 어떤 파일을 사용해야 하는지 이해할 수 있다면 이 간단한 점검은 끝난 것입니다.