게스트, 로그인, 계정 전환 때 프로젝트 데이터는 각각 어디에 놓이는가

SlateX는 게스트 상태와 로그인 상태의 데이터를 서로 분리된 두 개의 물리 데이터베이스에 넣습니다. 두 개는 같은 데이터 모델을 쓰지만 같은 파일은 아닙니다. 게스트 데이터베이스는 로그인하지 않은 상태의 기록만 담당하고, 계정 데이터베이스는 로그인 뒤의 기록을 담당하며, 클라우드 프라이빗 데이터베이스가 설정된 쪽은 계정 데이터베이스뿐입니다. 계정을 바꿀 때 귀속은 「현재 누가 로그인했으니 모든 기록이 그 사람의 것이다」로 처리되지 않고, 기록별로 Apple 신원 조건에 따라 하나씩 판단됩니다.

분리된 데이터베이스가 풀는 것은 「데이터가 어느 쪽에 떨어지는가」의 문제이고, 어떤 보안·개인정보·기기 간 결과도 대신 보증하는 것이 아닙니다.

게스트 데이터베이스와 계정 데이터베이스는 두 개의 파일입니다

게스트 데이터베이스와 계정 데이터베이스는 모두 앱 지원 디렉터리 안의 전용 하위 디렉터리에 있습니다. 이 위치는 사용자가 「파일」 앱에서 직접 들여다보는 Documents 위치가 아니므로, 「데이터베이스 파일을 찾았다」를 「모든 매체까지 손에 넣었다」로 이해할 수도 없고, 데이터베이스 파일만 따로 백업하는 것을 완전한 백업 방안으로 적을 수도 없습니다.

두 데이터베이스는 같은 데이터 모델 인스턴스를 공유하므로, 프로젝트, 씬, 테이크 기록과 콘티뉴이티 소재 같은 대상은 여전히 같은 구조로 표현됩니다. 차이는 저장 지점에 있습니다. 게스트 데이터는 게스트 데이터베이스로 들어가고, 로그인 뒤의 계정 데이터는 계정 데이터베이스로 들어갑니다. 코드는 계정 데이터베이스에만 클라우드 프라이빗 데이터베이스를 설정했고, 게스트 데이터베이스는 전체 수명 주기 동안 클라우드 업로드 설정이 하나도 없습니다. 여기서 말하는 것은 코드의 설정 사실이고, 「기기에서 올려 테스트해 보니 업로드되지 않음이 확인되었다」는 결론이 아닙니다.

사진과 동영상은 데이터베이스 안에서 같은 성질이 아닙니다

사진의 데이터 본체는 데이터베이스 안의 바이너리 데이터로 저장되므로, 데이터베이스 기록과 함께 움직입니다. 동영상은 다릅니다. 데이터베이스에 저장되는 것은 로컬 파일을 가리키는 경로 하나이고, 동영상 파일 본체를 같은 데이터베이스 필드에 넣지 않습니다.

이 차이 때문에 사진 기록과 동영상 경로를 기기 간 이동에서 같은 메커니즘으로 이해할 수 없습니다. 코드는 데이터베이스에 각각 무엇이 저장되는지까지 설명할 수 있지만, 그것으로 「기기를 바꾸면 반드시 손에 넣을 수 있다」거나 「반드시 못 얻는다」고 약속할 수는 없습니다. 수신자는 둘을 서로 다른 두 저장 형태로 봐야 하며, 데이터베이스 동기화를 매체 파일이 이미 도착한 일과 같은 일로 취급할 수 없습니다.

데이터베이스에 매체 기록이 한 줄 있다는 것은, 대응하는 로컬 파일이 다른 기기에서 반드시 이미 나타났다는 뜻이 아닙니다.

로그인 뒤에도 귀속은 데이터베이스 통째로 주인이 바뀌는 일이 아님

계정 쪽 데이터 귀속은 기록별로 Apple 신원 조건을 판단합니다. 프로젝트와 거기서 도달 가능한 기록은 현재 신원의 귀속 경로에 닿아야 하고, 어떤 계정이 이때 로그인 상태라는 이유로 데이터베이스 안의 모든 것을 그 계정 소유로 볼 수 없습니다.

이 판단은 계정을 바꿀 때 한 기록을 계속 읽거나, 옮기거나, 지울 수 있는지도 좌우합니다. 다시 말해 로그인 상태는 어느 데이터 환경에 들어가는가의 조건 중 하나일 뿐이고, 구체적인 기록이 누구의 것인지는 그 기록 스스로 어떤 관계 경로를 따라 대응하는 신원까지 되돌아갈 수 있는지를 더 봐야 합니다.

게스트 데이터는 적극적으로 로그인할 때만 옮겨감

게스트 기록이 계정 데이터베이스로 들어가는 것은 로그인 상태를 자동 복원할 때 겸해서 일어나는 일이 아닙니다. 사용자가 직접 로그인을 누른 경로만 게스트 전환 시작을 허락하고, 앱이 기존 자격 증명에서 로그인을 복원할 때는 게스트 데이터베이스를 자동으로 옮겨 넣지 않습니다.

전환 자체는 단계로 실행됩니다. 먼저 게스트 데이터베이스에서 스냅샷을 뜨고, 전환 가능한 대상을 계정 데이터베이스로 쓴 뒤, 이후에 새 컨텍스트를 사용해 속성별, 관계별, 귀속별로 검증합니다. 검증을 통과해야만 비로소 원본 쪽의 게스트 기록이 정리됩니다. 어느 한 단계에서 실패하면 원본 쪽은 정리 단계에 들어가지 않습니다.

검증을 통과하지 못하면 원본을 그대로 둡니다. 차라리 손대지 않고, 반쯤만 손대지는 않습니다. 이 문장은 현재 전환 순서를 설명한 것이고, 네트워크·클라우드·다른 기원이 어떤 추가 검증을 마쳤다는 뜻은 아닙니다.

이 페이지가 답할 수 있는 한계

이 메커니즘이 답할 수 있는 것은 게스트와 계정 기록이 각각 어느 데이터베이스에 떨어지는가, 어느 데이터베이스에 클라우드 프라이빗 데이터베이스가 설정되었는가, 매체가 데이터베이스 안에서 어떤 형태로 나타나는가, 그리고 적극적으로 로그인할 때 게스트 데이터가 어떻게 대조를 거쳐 전환되는가입니다. 특정 암호화 모델이나 전 범위 개인정보 보증을 증명하지 못하고, 누구도 읽을 수 없다는 것을 증명하지도 못하며, 코드의 설정을 이미 끝난 기기 보안 감사로 적을 수도 없습니다.

문제가 「다른 기기가 같은 순간에 같은 매체를 표시하는가」, 「앱을 지운 뒤에 복구할 수 있는가」, 「어떤 규정을 이로 충족하는가」로 바뀌면, 이 글은 이 기기 프로젝트 디렉터리의 실제 조직 방식만 설명하고 이런 경우들로 외삽하지 않습니다.

FAQ

게스트 상태와 로그인 상태가 같은 데이터베이스를 씁니까?

같지 않습니다. 두 상태는 분리된 물리 데이터베이스 파일을 쓰지만 같은 데이터 모델 인스턴스를 공유합니다. 게스트 기록은 게스트 데이터베이스로, 로그인 뒤의 기록은 계정 데이터베이스로 들어갑니다.

게스트 데이터베이스도 클라우드 프라이빗 데이터베이스에 들어갑니까?

현재 코드는 게스트 데이터베이스에 클라우드 업로드를 설정하지 않았고, 클라우드 프라이빗 데이터베이스가 설정된 쪽은 계정 데이터베이스뿐입니다. 이 말은 코드의 설정을 설명한 것이며, 기기 테스트로 모든 네트워크 동작을 증명했다는 뜻은 아닙니다.

사진과 동영상을 같은 기기 간 예상으로 이해하면 안 되는 이유는 무엇입니까?

사진의 데이터 본체는 데이터베이스 필드에 저장되지만, 동영상은 데이터베이스에 로컬 경로를 저장하기 때문입니다. 두 저장 형태가 다르므로, 데이터베이스 기록이 있다는 것만으로는 다른 기기에서 대응하는 파일을 이미 손에 넣었다고 끌어낼 수 없습니다.

게스트 데이터는 언제 로그인한 계정으로 들어갑니까?

사용자가 직접 로그인을 시작할 때만 게스트 전환 시작을 허락하고, 시스템이 기존 로그인 상태를 복원한다고 자동 전환되지 않습니다. 전환은 쓰기와 검증을 거치고, 검증을 통과하지 못하면 원본 기록이 그대로 남습니다.

Axiom One LLC — SlateX. 위 숫자는 2026-09-24 기준입니다.