회사나 조직의 디지털 자산은 소중하다. 온라인과 오프라인 서비스를 구분할 필요도 없다. 일을 진행하고 영유하는 순간부터 문서는 생성된다. (가끔 문서 자체를 생성하지 않고 구전으로만 시작하고 끝나는 조직도 있다. 거긴 피해라.) 소스코드라면 깃 베이스 저장소(깃허브, 깃랩 등)를 활용하고, 고용량 이미지나 동영상 파일을 편하게 쓰기 위해 드랍박스 같은 저장 특화 서비스를 쓰기도 한다.
그중에서 가장 많은 포션을 차지하는 저장소는 조직 도메인을 장착한 이메일 서비스를 쓸 때 제공되는 저장소가 아닐까 싶다. 물론, 이메일 서버를 별도 인프라로 구성해서 쓰는 조직도 있고, 이메일과 저장소를 완전히 분리해서 쓰는 조직도 있다. 하지만 구글 워크스페이스나 MS365를 쓰면, 관리 운영 리소스를 줄일 수 있다. 이들 계정으로 다른 서비스에 SSO로 로그인하거나, 조직도를 반영해서 쓰는 편의도 있다.
문제는 문서 생성을 시작하는 위치와 저장하는 위치를 고민하지 않고 본인 사적 공간만 운영하는 관습을 유지하는 행위를 마주할 때 생긴다. 업무 산출물, 프로젝트 문서, 공용 템플릿, 정책 문서 등 디지털 자산으로 귀결되는 모든 문서는 공유 드라이브에 들어가 있어야 한다. 하다 못해 컨플루언스나 노션 등을 쓰더라도 팀이나 조직 워크스페이스 안에 문서가 속해야 한다. 이 글 제목 그대로다. 내 드라이브, 공유 드라이브, 공유 문서함은 모두 서로 다른 곳이다.
이 자체를 전혀 고민하지 않고, 문서나 디렉터리에 공유 권한을 넣으면 끝이라는 이들에게 어디서부터 설명을 시작해야 하는지도 난감하다. 문서나 디렉터리에 걸린 공유 권한은 그 자체로 그냥 공유 설정일 뿐, 문서 소유권을 뜻하지 않는다. 디지털 자산의 소유권은 누구에게 있어야 할까? (AI에 이 질문 넣으면 정말 순식간에 공유 드라이브 사용이라는 답이 돌아온다. 하지만 그들은 애초에 이 질문 자체를 하지 않는다.)
기본 개념
내 드라이브는 기본적으로 "개인 소유" 공간이다. 그리고 그 공간에 초대받은 사람만 접근할 수 있다. 초대받은 사람이 접근 후에 할 수 있는 활동 범위를 다르게 설정할 순 있지만, 어쨌거나 초대받아 들어갔을 뿐이다.
공유 드라이브는 “조직/팀 소유" 공간이다. 여기에서 말하는 "조직/팀"은 실제 존재하는 인물이 아니라 가상으로 지정한 그룹이다. 공유 드라이브는 (조직마다 정책이 다르긴 하지만) 기본적으로 해당 조직이나 팀 접근 설정을 해서 사용한다. 그래서 보통 공유 드라이브 접근 인원을 한 명 한 명 제어하지 않는다. 해당 인원의 조직이나 팀 소속을 변경하면 공유 드라이브 접근 설정에 맞춰서 자동으로 적용된다. 조직/팀원 모두가 사라져도 이 드라이브는 남는다. 없어진 조직을 다른 조직으로 이관 또는 상속하면서 공유 드라이브 접근 권한을 바꾸기도 한다.
공유 드라이브 사용 판별 기준
- 이 문서를 1개월 뒤에도 조직에서 찾아볼까? → Yes면 공유 드라이브
- 이 문서 또는 문서 영향 범위 업무는 내가 없어도 운영돼야 하나? → Yes면 공유 드라이브
- 수신자/참여자가 2명 이상이고 재참조 가능성이 있는가? → Yes면 공유 드라이브
- 진짜 개인 초안/임시 메모인가? → 내 드라이브
내 드라이브와 공유 문서함
내 드라이브의 소유자는 나 하나
애초에 작은 일 또는 빠른 작업을 위해 내 드라이브에서 작업하며 특정 인원과 공유했다면, 얼른 공유 드라이브에 옮겨두는 것이 좋다. 단 1명이라도 공유한 인원이 생겼다면, 그 순간 논리적으로 공동 작업물이며 조직 자산화를 위한 신호다. 보고를 위한 솔플이었다고 괜찮을까? 아니다. 보고를 받는 사람도 결국 그 문서를 추후에 확인할 일이 생길 수 있다. 내 드라이브의 전체 설정이나 개인 계정의 상태에 따라 언제든지 공유 권한은 바뀔 수 있다. 안정성이 매우 좋지 않은 개인 계정 종속이다.
내 드라이브에 팀 문서를 두면, 팀 자산의 생사(접근/이관/감사)가 개인 계정에 종속된다. 파일별 공유는 시간이 지날수록 권한이 누더기가 되고, "누가 왜 접근 가능한지" 아무도 설명 못 한다. 링크 공유 한 번 퍼지면 회수 비용은 팀 전체가 낸다. 그러니 팀 문서는 처음부터 공유 드라이브에 있어야 한다.
공유 문서함은 그저 목록일 뿐
다른 사람이 그 사람의 개인 드라이브 또는 다른 조직의 공유 드라이브에서 나를 초대했을 때, 그 문서가 내 공유 문서함에 들어온다. 이는 공유 드라이브가 아니다. 어쩌면 이름이 주는 어감 때문에 공유 문서함과 공유 드라이브 사이의 차이가 미미하다고 생각할 수도 있다. 하지만 엄청나게 큰 차이를 가진다. 기본 개념이 우선 원칙이자 조건이기 때문이다.
공유 문서함은 그저 누가 나한테 공유해준 것들의 목록일 뿐이다. 그래서 문서 소유권이나 거버넌스와는 매우 동떨어진 곳이다.
DL을 가르쳐주는 이가 없다
요즘은 DL이 그냥 조직도에 따른 팀 메일 정도로만 생각해도 충분하다. DL의 원래 의미는 Distribution List다. 한국말로 직역하면 배포 리스트다. 저장소가 아니라 사람 묶음 주소다. 보통 DL은 조직도를 반영해서 구성한다. 혹은 조직 의사 결정 권한 레벨에 따른 분리를 해두기도 한다. 매번 특정 그룹 인원을 한 명 한 명 다 입력하기는 너무 귀찮은 일이니 묶어서 관리한다.
구글 워크스페이스에서는 구글 그룹스가 이 기능을 한다. 그렇다고 DL과 구글 그룹스가 동일한 개념이라고 할 순 없다. 구글 그룹스 자체가 워낙 다양한 기능을 가지고 있는 터라, DL을 편하게 구현할 기능을 거의 다 가지고 있다. 관리자나 권한자가 DL을 구글 그룹스로 묶음 설정을 해서, 공유 드라이브에 이 그룹을 위한 드라이브를 만들어 접속 권한을 넣는다. 구글 그룹스에서 멤버 구성만 변경하면, 공유 드라이브 접속 권한은 자동으로 바뀐다. (그래서 대기업에서는 대량 인사이동 발생 시, 공유 드라이브 접속으로 이런저런 이슈가 생긴다.)
당신의 신상 변화가 조직에 영향을 주지 않기를 바라며
처음부터 DL를 통해 권한을 주고 받으며 공유 드라이브를 쓰는 문화에 익숙하지 않았다면, 지금부터라도 이해하고 납득하길 바란다. 팀원이 이동한다고 문서까지 이동하는 과오를 유발해선 안 된다.
팀 이동이든 퇴사를 앞둔 사람들이 자기가 없으면 자기가 하던 일은 누가 하느냐란 고민을 많이 한다. 그때마다 내가 하는 말은, 그건 남은 자의 몫이라는 거다. 남은 자는 일이 잘 굴러가는 동안에는 남아있는 문서 영향을 적게 받는다. 어느 순간 생기는 돌발 상황에 대응하기 위해 문서를 뒤지며 히스토리를 추적한다. 배려가 필요 없는 이들만 남는데 뭘 챙겨주냐고 할 수도 있다. 하지만 그 입장이 내가 될 수도 있다는 생각도 한 번쯤 해보길 바란다. 인수인계할 상황을 만들어 주지 않은 조직을 탓하게 만들고 싶다면, 준비된 상태로 공유 드라이브에 디지털 자산을 잘 보관해 두길 바란다. 조직에서 만든 산출물은 부디 공유 드라이브에 넣자.
내 드라이브에 있는 파일은 제 것인데요?
맞습니다. 당신의 것입니다. 다만, 개인의 소유를 주장할 거면, 애초에 회사 계정/업무 흐름에 올리지 말아야 합니다. 팀이 쓰게 만들었으면 팀 공간에 뒀어야 합니다. 혹은 회사 업무를 위해 사용한 개인 자료를 남겨둔 것이라면 삭제하거나, 업무 자료로 이관하거나 하는 등 취사선택을 하셔야 합니다. 혹은 당신의 것을 조직 내 다른 이와 공유했다면, 그 순간 기본 원칙에 맞춰서 공유 드라이브로 옮기는 것이 좋습니다.