같은 콘티뉴이티 사진에 데이터 본체와 파일 경로 기록이 두 개 있는 이유

콘티뉴이티 사진 한 장은 SlateX에서 성질이 다른 두 기록을 동시에 가질 수 있습니다. 데이터베이스에 들어 있는 이미지 데이터와, 앱 샌드박스 안의 디스크 파일을 가리키는 상대 경로가 그것입니다. 화면 표시는 이미지 데이터를 읽고, 파일을 지울 때는 저장해 둔 상대 경로에 의존합니다. 둘이 서로 다른 행위를 담당하므로, 「화면에는 아직 보인다」와 「디스크의 그 파일을 정확히 찾아 지울 수 있다」는 같은 일이 아닙니다.

이미지 데이터는 「무엇을 표시하는가」에 답하고, 파일 경로는 「어느 파일을 지우는가」에 답합니다. 두 기록은 서로를 대신할 수 없습니다.

표시는 이미지 데이터를 읽고, 삭제는 상대 경로를 봅니다

카드, 상세, 참조 구역, 비교 화면은 모두 데이터베이스 안의 이미지 데이터에서 사진을 읽으며, 서로 다른 화면에서 미리보기 규격만 다르게 씁니다. 다시 말해 이미지 데이터가 남아 있는 한 화면은 자기 표시 출처를 갖고 있으므로, 디스크 경로를 따라 그 사진을 먼저 다시 열 필요가 없습니다.

삭제 논리는 정반대입니다. 소재나 콘티뉴이티 라이브러리 파일을 지울 때 코드는 이전에 지속해 둔 상대 경로로 디스크 파일을 위치 찾고, 현재 모델 필드에서 파일 이름을 다시 짐작하는 일을 분명히 금지합니다. 저장해 둔 정확한 경로가 한 줄도 없으면, 삭제 논리는 이름 스캔으로 「겉보기에 그럴듯한」 파일을 찾아 나서지 않습니다.

그래서 같은 사진도 「데이터베이스 객체」와 「샌드박스 파일」로 동시에 이해해야 합니다. 데이터베이스 객체가 표시된다고 해서 디스크 파일의 권한 있는 위치까지 온전히 기록된 것은 아니고, 디스크 경로가 있다고 해서 표시 쪽이 도리어 그것에 의존하는 것도 아닙니다.

두 종류 사진은 서로 다른 디렉터리 명명을 탑니다

테이크 기록에 걸리는 콘티뉴이티 소재는 프로젝트, 씬, 컷, 테이크 층위로 경로를 만들고, 콘티뉴이티 라이브러리 항목에 걸리는 표지나 참조 소재는 라이브러리의 분류와 항목명으로 파일 이름을 만듭니다. 두 경로 가계는 서로 다른 업무 귀속을 표현하는 것이므로, 파일 이름만 보고 어느 객체에 속하는지 짐작해서는 안 됩니다.

이런 명명은 항목 이름을 바꿀 때 파일 이름도 달라지는 이유를 설명합니다. 콘티뉴이티 라이브러리 항목에 사진을 실어 저장할 때마다 현재 분류와 현재 이름으로 새 파일 이름을 만들고, 새 파일을 먼저 쓴 뒤 기록을 성공적으로 저장한 다음에야 옛 경로가 가리키던 파일을 지웁니다. 따라서 항목 이름을 고치는 일은 데이터베이스 속 글자 딱지만 바꾸는 것이 아니고, 사진을 실어 저장할 때 디스크 파일 이름도 현재 이름을 따라 다시 생성됩니다.

두 개의 쓰기 경로에는 권한 있는 경로가 남지 않습니다

콘티뉴이티 라이브러리 항목을 빠르게 새로 만들어 연결할 때, 현재 코드는 표지 이미지 데이터만 쓰고 표지 파일 경로는 쓰지 않습니다. 근접 수신으로 들어온 사진도 이미지 데이터만 쓰고 사진 경로는 쓰지 않습니다. 그래서 두 종류의 기록은 화면에는 여전히 사진이 뜰 수 있지만, 삭제 논리에는 지속해 둔 권한 있는 경로가 없습니다.

여기서 확인할 수 있는 것은 「어느 단계에서 경로를 쓰지 않았는가」이고, 이것을 「그러니 디스크 파일이 반드시 쌓인다」나 「그러니 누수가 일어났다」로 더 써서는 안 됩니다. 그것은 결과 층의 일로, 파일 시스템 표본과 실제 삭제 테스트까지 가야 결론을 낼 수 있습니다.

경로가 없다는 것은 위치를 확인할 수 있는 코드의 사실이고, 디스크에 최종적으로 무엇이 남는가는 실측이 필요한 또 다른 층의 결과입니다.

데이터베이스 사본과 샌드박스 파일도 같은 층이 아닙니다

데이터베이스에 저장한 이미지 데이터는 계정 쪽 데이터 사본에 들어갈 수 있지만, 지속해 둔 그 로컬 파일 경로가 가리키는 파일 자체는 같은 사본 범위에 들지 않습니다. 그래서 「데이터베이스 기록이 다른 기기에도 나타났다」를 「그 경로가 가리키던 샌드박스 파일까지 나타났다」로 쓸 수는 없습니다.

이 매체 파일은 모두 앱 자신의 샌드박스에 있고, 앱 패키지에 들어 있는 정적 자원이 아닙니다. 앱을 지우면 샌드박스 안의 로컬 파일은 앱 데이터와 함께 사라집니다. 반면 이것이 「클라우드에서 사진을 복구할 수 있다」는 약속이 되는 것도 아닙니다. 이 글은 데이터베이스 데이터와 로컬 경로의 관계만 설명하고, 재설치나 기기 교체 뒤의 복구 결과를 증명하지 않기 때문입니다.

동영상은 왜 따로 이해해야 하는가

동영상 기록은 파일을 위치 찾는 데 로컬 경로에 주로 의존하고, 읽을 때 착지점으로 되돌아가는 논리가 있어서, 기록 속 경로가 파일이 쓰일 당시의 위치를 여전히 가리키는 경우를 대비합니다. 그것은 사진이 「표시할 때 데이터베이스 이미지 데이터를 직접 읽는」 경로와 다르므로, 사진의 이중 쓰기 구조를 동영상에 그대로 덮어쓸 수는 없습니다.

이 글이 답할 수 있는 것은 다음입니다. 같은 사진에 이미지 데이터와 경로 기록이 두 개 있는 이유, 누가 어느 쪽을 읽는지, 이름을 바꿀 때 왜 파일 이름까지 바뀌는지, 그리고 어떤 쓰기 경로에 권한 있는 경로가 남지 않는지. 이것을 근거로 자동 중복 제거, 기기 간 복구, 파일이 없어지지 않는다는 것까지 약속할 수는 없습니다.

FAQ

사진은 아직 보이는데 삭제할 때 쓸 경로가 없는 이유는 무엇입니까?

표시 쪽은 데이터베이스 안의 이미지 데이터를 읽고, 삭제 쪽은 지속해 둔 상대 경로에 의존하기 때문입니다. 두 사슬이 읽는 기록이 서로 다릅니다.

콘티뉴이티 라이브러리 항목 이름을 바꾸면 글자만 바뀝니까?

사진을 실어 저장할 때는 글자만 바뀌지 않습니다. 현재 구현은 새로운 분류와 이름으로 파일 이름을 다시 만들고, 저장이 성공한 뒤에 옛 경로를 처리합니다.

어떤 사진 경로는 쓰이지 않았을 수 있습니까?

콘티뉴이티 라이브러리 항목을 빠르게 새로 만들어 연결할 때의 표지, 그리고 근접 수신으로 들어온 사진에 대해, 현재 쓰기 경로에는 이미지 데이터만 쓰고 권한 있는 경로는 쓰지 않는 경우가 있습니다.

데이터베이스에 사진이 있으면 다른 기기에도 대응하는 로컬 파일이 있습니까?

그렇게 끌어낼 수 없습니다. 데이터베이스의 이미지 데이터와 로컬 샌드박스 파일은 서로 다른 층이고, 경로가 가리키는 로컬 파일은 데이터베이스 기록이 있다고 해서 다른 기기에 이미 나타났음이 증명되지 않습니다.

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