상대방이 무엇을 할 수 있어야 하는지 정하세요
같은 결과물이라도 받는 이유는 다를 수 있습니다. 품질을 확인하려는 경우, 다른 도구에 파일을 넣으려는 경우, 또는 작업을 이어가려는 경우가 있죠. 링크를 보내기 전에 이 목적을 먼저 정하세요. 범위를 논의할 때는 미리보기만으로 충분할 때도 있지만, 실제 크기의 내보내기 파일을 확인하기에는 부족할 수 있습니다.
정확한 검토를 요청하세요. 어떤 파일을 열어야 하는지, 어떤 기준을 살펴야 하는지, 피드백은 어디에 남길지, 언제까지 원하는지를 함께 적어주세요. 작업 디렉터리 전체를 기본으로 보내지는 마세요. 제외된 변형본, 전체 로그, 불필요한 리소스는 상대방이 골라내기 어렵게 만들고, 납품과 무관한 정보까지 노출될 수 있습니다.
여기서 설명하는 공유는 여러분의 도구나 저장 위치에서 이루어집니다. BriefGPU 추적 기능 안에 팀 기능, 메신저, 파일 공간이 있다는 전제는 하지 않습니다. 받는 사람이 사용할 수 있는 저장 위치를 선택하세요.
말로 설명하지 않아도 이해되는 패키지를 만드세요
패키지에 프로젝트 이름과 버전 번호를 붙이세요. 예를 들어 collection-v01처럼요. 내용과 상태(검토 필요 또는 승인됨)를 설명하는 짧은 메모도 함께 넣으세요. 목록만으로도 결과물 개수를 세고 예외 항목을 확인할 수 있어야 합니다. Cornell의 README 안내서는 파일과 파일 사용에 필요한 정보를 문서화하라고 권장하지만, 여러분의 메모는 연구 자료보다 훨씬 짧아도 됩니다.
작업을 이어가기 위한 목적이라면 필요한 설정과 종속 항목을 따로 추가하세요. 완성된 결과물을 단순히 사용하는 목적이라면 작업 아카이브는 여러분 쪽에 보관하세요.
| 패키지 항목 | 답변하는 질문 |
|---|---|
| 전달 참고 사항 | 어떤 프로젝트, 어떤 버전, 어떤 작업이 기대되나요? |
| 선택된 결과 | 어떤 파일을 검토하거나 사용해야 하나요? |
| 인벤토리 | 출력물은 몇 개 있으며 각각 어떤 입력물에 해당하나요? |
| 확인된 예외 사항 | 무엇이 빠져 있거나 아직 결정해야 할 사항은 무엇인가요? |
| 피드백 표 | 의견을 파일과 기준에 어떻게 연결하나요? |
예시: 세 명이 검토하는 열여덟 장의 이미지 리뷰
이 가상의 예시에서 한 사람이 열여덟 장의 이미지를 만들고, 한 동료가 레퍼런스를 확인하며, 한 책임자가 배포용 결과물을 승인합니다. v01 패키지에는 검토할 열여덟 개의 출력물과 인벤토리가 들어 있습니다. 동료는 이미지를 확인하고 표를 작성할 수 있으며, 납품 파일을 수정할 필요는 없습니다.
지침은 레퍼런스와 표기를 확인한 뒤 이미지 식별자와 함께 차이점을 기록하라고 요청합니다. 그다음 책임자가 결과물을 합의된 기준과 비교합니다. 수정 여부를 결정하기 전에 피드백을 하나의 표에 모읍니다. 제안은 제공된 버전을 자동으로 수정하지 않습니다.
| 검토한 버전 | 파일 | 예시 관찰 내용 | 결정 |
|---|---|---|---|
| v01 | image-004.png | 인쇄된 레퍼런스가 읽을 수 없게 되었습니다. | 승인 전에 수정합니다. |
| v01 | image-011.png | 두 사람이 서로 다른 구도를 제안합니다. | 책임자가 따를 레퍼런스를 선택합니다. |
| v01 | 기타 이미지 | 예정된 검토에서 발견된 차이점이 없습니다. | 패키지 최종 확인을 조건으로 유지합니다. |
맡긴 작업에 맞게 권한을 설정하세요
공유 공간에서는 관련된 사람들을 각자의 계정으로 초대하고 작업에 맞는 권한을 선택하세요. 출력물을 검토할 때는 파일 열람 권한과 댓글용 별도 위치를 권장합니다. 패키지 수정은 납품물 준비를 맡은 사람에게만 허용하세요.
권한의 이름과 효과는 서비스마다 다릅니다. 예를 들어 OneDrive는 특정 사람을 대상으로 하는 링크와 링크를 받은 사람이면 누구나 사용할 수 있는 링크를 구분합니다. 또한 문서에 따르면 읽기 권한으로도 복사나 다운로드가 가능할 수 있습니다. 즉 '읽기 전용'이 '가져갈 수 없음'을 뜻하지는 않습니다. 사용 중인 계정에서 실제로 제공되는 옵션과 팀 규칙을 확인하세요.
공유 폴더 전체를 점검하세요. 이미 접근 가능한 위치에 파일을 추가하면 같은 수신자에게 노출될 수 있습니다. 납품 전용 폴더를 따로 마련해 기밀 원본, 계약서, 접근 수단이 패키지 밖에 남도록 하세요.
비밀번호는 검토 과정에서 제외하세요
결과물을 보여주려고 BriefGPU 계정 비밀번호를 빌려주지 마세요. 이는 계정 관리에 대한 접근 권한이지 특정 파일에 대한 제한된 권한이 아닙니다. 사용 중인 저장소의 공유 기능을 이용하거나 승인된 수신자에게 독립 실행형 패키지를 전달하세요.
납품 메모, 스크린샷, 주문 내역에 서비스 비밀번호나 개인 키, 액세스 토큰을 넣지 마세요. 여러 사람이 함께 작업을 이어받을 때는 각자 역할에 맞는 접근 수단을 가져야 합니다. 사용 중인 공유 도구가 필요한 권한을 지원하지 않으면 팀과 함께 다른 전달 방식을 정하세요.
주문 책임자는 로그인 정보를 제공하지 않고도 프로젝트에 유용한 요약을 전달할 수 있습니다.
수정했을 때는 새 버전을 게시하세요
예시의 피드백 이후 v02 패키지는 수정된 두 이미지를 교체하고 나머지 열여섯 장은 유지합니다. 안내문에는 두 가지 변경 사항을 정확히 밝히고 이 수정 사항을 확인해 달라고 요청합니다. 또한 패키지에 여전히 서로 다른 열여덟 개의 레퍼런스가 들어 있는지 확인해 달라고 요청합니다. v01에 대한 의견은 v01에 그대로 연결됩니다.
검토 도중 관련된 사람들에게 알리지 않고 파일을 조용히 교체하지 마세요. 같은 이름 아래 서로 다른 내용에 대해 의견을 남길 수 있습니다. 메시지와 안내문에 현재 버전을 명시하고, 승인 후 어느 버전을 사용해도 되는지 분명히 밝히세요.
구두로 주고받은 내용까지 포함해 한 사람이 결정 사항과 그 이유, 상태를 공통 표에 모읍니다.
수신자의 여정을 확인하세요
전체 전송에 앞서, 예정된 권한을 가진 사람이 자신의 계정으로 파일을 열도록 하세요. 올바른 폴더에 접근되는지, 보이는 버전이 맞는지, 대상 도구에서 열리는지, 피드백을 전달할 수 있는지 확인하세요. 본인의 소유자 세션만으로는 다른 사람들도 같은 접근 권한을 갖는다는 것이 증명되지 않습니다.
압축 파일이라면, 내려받은 복사본에서 압축 해제와 샘플 파일 열기까지 확인하세요. "링크를 받았습니다"라는 메시지는 접근, 다운로드, 수락 중 어느 것도 확인해 주지 않습니다. 단계에 맞는 응답을 요청하세요. 접근 확인, 검토 완료, 또는 버전 수락이 그 예입니다.
전달 후에는 더 이상 필요하지 않은 접근 권한을 다시 검토하세요. 일부 서비스는 링크와 상위 폴더에서 상속된 권한을 함께 적용하므로, 링크를 제거해도 모든 접근이 사라지지 않을 수 있습니다. Microsoft 문서는 OneDrive와 SharePoint에서 이러한 경로를 자세히 다루고 있습니다. 이미 내려받은 복사본은 링크를 삭제한다고 회수되지 않습니다.
수락된 버전과 보관된 결정으로 마무리하기
전달이 명확하려면 받는 사람이 어떤 버전을 사용해야 하는지, 합의된 제한 사항이 있다면 무엇인지, 파일을 어디에서 찾을 수 있는지 알아야 합니다. 결정을 목록과 함께 보관하세요. 예를 들어, 수락은 collection-v02와 그 열여덟 장의 이미지에 대한 것이며, 프로젝트의 모든 변형을 승인하는 것은 아닙니다.
패키지를 읽는 것은 백업을 대신하지 않습니다. 본인의 작업 재개에 필요한 복사본을 보관하고, 대여를 종료하기 전에 확인하세요. 이 전달 방식은 대여한 서버에서 특정 공유 기능, 보존 기간, 권한을 보장하지 않습니다. 이러한 설정은 사용하는 도구에서 직접 확인해야 합니다.