개인 메모를 보관하는 AI 기억 서버에 공동 작업자를 초대하려면, 먼저 그 작업자에게 어디까지 읽혀도 되는지 정해야 한다. 프로젝트별로 문서를 나눠놓았다는 설명만으로는 답이 나오지 않는다. 문서를 어떤 이름으로 묶을지와 누가 그 문서를 읽을 수 있을지는 별개의 결정이다.
모든 문서를 함께 읽는 방식 자체가 잘못은 아니다. 같은 자료를 공유하려는 소규모 팀은 단순한 권한 구조를 택할 수 있다. 개인 메모와 공동 문서의 독자가 같다면 분류만 나눠도 된다. 분리가 필요한지는 프로젝트 수보다 독자가 다른지에 달려 있다. 모두가 읽어도 되는 문서만 있는 서버에 세밀한 권한 체계를 덧붙이는 것은 관리할 일만 늘릴 수 있다.
반대로 개인 메모는 나만 읽고 공동 문서는 함께 읽어야 한다고 가정해 보자. 로그인한 사용자라면 서버의 모든 문서를 읽을 수 있는 구조에서 개인 프로젝트와 공동 프로젝트를 만드는 것만으로는 이 요구를 만족하지 못한다. 공동 작업자의 기본 화면에서 개인 프로젝트가 빠지더라도, 문서 주소를 직접 열거나 검색 범위를 바꿔 내용을 받을 수 있다면 개인 메모는 그 계정에 공개된 상태다.
로그인은 계정이 없는 방문자를 구별하는 데 쓰인다. 로그인한 사용자 중 누가 어떤 문서를 읽을 수 있는지는 그다음 문제다. 계정 발급 기능이 있다는 설명과 문서별 읽기 권한이 나뉜다는 설명을 같은 말로 받아들이면, 초대받은 사용자가 읽을 수 있는 범위를 실제보다 좁게 생각하기 쉽다.
AI에게 공동 프로젝트만 참고하라고 지시하는 방법도 구별해서 볼 필요가 있다. 그 지시는 답변에 사용할 자료의 범위를 정한다. AI가 사용하는 계정에 개인 메모를 읽을 권한이 남아 있다면, 지시만으로 그 권한이 사라지지는 않는다. 사용자가 읽지 못해야 할 문서는 AI가 사용자를 대신해 조회할 때도 내용을 돌려주지 않도록 접근을 통제해야 한다.
분리가 됐다는 근거를 얻으려면 개인 메모를 읽지 못해야 하는 공동 작업 계정으로 확인할 수 있다. 목록에서 빠지는지와 별개로 직접 문서 열기, 검색, AI를 통한 조회에서도 내용이 나오지 않는지 보는 것이다. 이는 접근 확인 방법의 제안이며 특정 제품에서 수행한 시험 결과가 아니다. 검색 범위나 답변 지시가 잘 적용되는지만 확인하고 문서 접근까지 막혔다고 결론 내려서는 안 된다.
공동 작업 계정이 개인 메모를 읽을 수 있다면 선택은 구체적이다. 문서 읽기 권한을 나누거나, 함께 읽어도 되는 문서만 그 서버에 둔다. 개인 프로젝트라는 이름을 더 눈에 띄게 붙여도 초대한 계정이 읽을 수 있는 내용은 줄어들지 않는다.