서비스를 옮길 때 파일만 복사하면 공유가 끊기는 이유

새 서비스에서 파일이 열려도 고객의 예전 링크와 팀의 댓글까지 이어졌는지는 알 수 없다. 이전에는 파일 내용뿐 아니라 소유자와 공유 역할, 연결된 주소를 함께 인수해야 한다. 프로젝트 한 개를 기준으로 새 관리 주체와 최종 변경 시점을 정하는 방법을 살펴본다.

파일과 관계를 따로 목록으로 만든다

파일 본문 외에 소유자, 공유 대상, 역할, 링크, 댓글, 버전처럼 업무에 필요한 관계를 기록한다. 모든 정보를 목적지에서 유지할 수 있는지는 공식 가져오기 안내로 확인한다. 지원되지 않는 항목은 보관 기록이나 재설정 작업으로 구분한다.

Google Drive 폴더 공유 안내는 폴더 역할과 소유권 관련 조건을 설명한다. 이런 관계는 폴더를 다른 서비스에 복사하는 작업과 별도로 살펴야 한다. 같은 이름의 폴더가 새 위치에 있다는 사실만으로 같은 협업 환경이 만들어진 것은 아니다.

개인 소유와 조직 소유를 구분한다

업무 폴더 안에 있어도 개별 파일의 소유자가 개인 계정일 수 있다. 이전 전에 소유자와 관리 가능성을 확인하면 계정을 정리한 뒤 자료를 관리하기 어려워지는 상황을 줄일 수 있다.

조직 계정의 소유권 이전이나 외부 공유에는 관리자 정책이 있을 수 있다. 일반 계정의 내보내기 기능을 이용할 수 있다는 사실만으로 조직 자료를 외부로 전달할 권한이 생기지 않는다. 실제 허용된 범위에서 자료를 준비하고 인수 주체를 정한다.

업무 담당자 변경이라면 파일 목록만 전달하지 않고 새 관리자가 자료를 수정·공유·보관할 수 있는지 확인한다. 소유권이 유지되는지, 새 환경에서 별도 설정을 해야 하는지 기록한다. 사용자 계정을 제거하는 일정은 이러한 인수 확인과 분리해 결정한다.

프로젝트 한 개를 인수하는 상황으로 범위를 좁힌다

가상의 고객 프로젝트에 계약 문서, 결과물 폴더, 댓글이 달린 기획안, 고객에게 보낸 링크가 있다고 하자. 파일을 내려받아 새 서비스에 올리면 본문 사본은 생긴다. 그러나 고객의 접근 권한과 댓글의 맥락, 기존 메일의 링크까지 그대로 이어졌는지는 별도 작업이다. 이전 목록을 파일 이름만으로 만들면 이런 관계가 빠진다.

먼저 프로젝트를 관리할 새 주체를 정한다. 결과물 폴더를 소유할 계정과 편집할 팀원, 읽기만 할 고객을 나눈다. 내부 기획안은 고객용 결과물 폴더와 분리할 수 있다. 새 환경에서 동일한 역할 이름이 있더라도 실제 허용되는 행동을 확인한다. 예전 서비스의 ‘댓글 작성’이 새 서비스의 ‘편집’으로 넓어지지 않았는지 살핀다.

다음으로 기존 링크의 사용 위치를 찾는다. 고객 메일, 홈페이지, 업무 관리 도구, 문서 안의 연결이 이전 주소를 가리킬 수 있다. 자료가 새 위치에 있다는 사실을 알고 있는 사람과 예전 링크로만 찾는 사람은 다르다. 갱신해야 할 위치와 당분간 유지할 위치를 정해 두어야 이전 뒤에 문의가 생겼을 때 대응하기 쉽다.

두 서비스를 동시에 수정하는 기간을 줄인다

이전 중 양쪽에서 파일을 편집하면 어느 사본이 최신인지 흐려질 수 있다. 최종 복사 시점과 이후 수정할 위치를 합의하고, 마지막 변경분을 따로 대조한다. 업무를 멈출 수 없는 환경이라면 변경 목록을 남겨 어느 자료를 다시 옮겨야 하는지 추적한다.

파일 이름이 같다고 덮어쓰기부터 하지 않는다. 두 사본의 작성·수정 시점과 내용을 비교하고 필요한 변경을 합칠지 판단한다. 댓글이나 버전 기록을 목적지에서 유지할 수 없다면 판단 근거로 필요한 부분을 별도로 보관한다. 무엇을 유지하고 무엇을 새 환경에서 다시 만들었는지 기록해야 이전 범위를 설명할 수 있다.

수신자 확인은 실제로 필요한 행동을 기준으로 한다. 고객은 링크를 열고 결과물을 읽을 수 있는가, 팀원은 필요한 문서에 댓글을 쓸 수 있는가, 새 관리자는 공유를 정리할 수 있는가를 나눠 본다. 관리자의 화면 하나로 모든 역할을 통과 처리하지 않는다.

작은 프로젝트의 인수가 끝나면 같은 구조의 다른 자료로 범위를 넓힌다. 기존 계정을 정리하는 시점은 새 파일 업로드 완료가 아니라 자료와 관계의 인수 상태를 기준으로 정한다. 미확인 링크나 소유권이 남아 있다면 그 항목부터 해결해야 한다.

작은 프로젝트 묶음을 먼저 옮겨 본다

처음부터 전체 자료를 이동하기보다 실제 업무의 특성을 가진 작은 묶음을 선택한다. 한글 파일 이름, 하위 폴더, 댓글, 외부 공유 등 필요한 구조를 포함한다. 실제 비공개 자료를 시험하기 어렵다면 같은 구성의 시험 문서를 사용할 수 있지만 결과의 범위를 그 시험으로 제한한다.

새 환경에서 파일을 열고 편집하며, 필요한 수신자 계정으로 접근할 수 있는지 확인한다. 소유자 화면만으로 공유 성공을 판단하지 않는다. 일부 기능이 유지되지 않는다면 별도로 보관할 정보와 재설정할 작업을 정한다.

파일 형식을 바꾸는 경우에는 본문, 표, 글꼴, 연결 개체 등 중요한 요소를 대조한다. 파일이 열린다는 사실과 원래 업무에 필요한 편집·표시 기능이 유지되는지는 같은 질문이 아니다. 다른 앱에서의 결과를 기준으로 확인한다.

기존 링크를 어디서 쓰고 있는지 찾는다

옮긴 파일은 새 주소를 가질 수 있으므로 기존 링크의 사용 위치를 기록한다. 팀 문서, 홈페이지, 메일 안내, 자동화 설정처럼 연결을 쓰는 곳을 나누고 새 주소로 교체할지 일정 기간 유지할지 결정한다.

바로가기는 실제 파일 사본과 다를 수 있다. 새 폴더에 바로가기를 넣었다면 그 연결이 여전히 원래 계정과 위치에 의존하는지 확인한다. 원래 자료를 정리한 뒤에도 새 환경에서 독립적으로 쓸 수 있어야 이전 목표에 맞을 수 있다.

외부 사람에게 전달한 링크는 주소 교체만이 아니라 접근 역할도 다시 확인한다. 읽기 자료가 편집 가능해지거나 내부 파일이 공개 링크로 바뀌지 않았는지 살핀다. 공개 링크 점검을 함께 사용하면 목적과 수신 범위를 기록하기 쉽다.

최종 이전 시점과 마지막 변경분을 정한다

작업 중 원래 서비스에 자료가 계속 추가되면 이전 사본과 차이가 생길 수 있다. 어느 시점까지 원래 환경을 쓰고 언제부터 새 환경을 기준으로 할지 정한다. 변경된 파일과 새로 추가한 자료를 추적해 최종 반영 범위를 확인한다.

Google 데이터 내보내기 안내는 사본 만들기의 조건을 설명한다. 내보내기를 요청했다는 사실만으로 작업 중 새 자료까지 모두 포함된다고 기대하지 않는다. 실제 파일과 시점을 대조한다.

원래 환경의 자료를 정리하기 전에 새 환경에서 주요 업무를 수행해 본다. 보관용 원본이 필요한 경우 별도 사본과 목록을 유지한다. 백업 무결성 확인을 적용하면 원본 사본의 바이트 비교와 실제 파일 열람을 나누어 검토할 수 있다.

인수 기록에는 유지된 정보, 재설정한 공유, 이전되지 않은 항목, 새 관리자와 기준 시점을 남긴다. ‘모든 파일 복사 완료’보다 무엇이 계속 동작하고 무엇을 포기했는지 분명한 기록이 다음 업무에 더 도움이 된다.