기술 · 실용 가이드
Immich Live Photo가 정지 사진으로 저장될 때: 메타데이터를 바꾸기 전에 파일 쌍 확인하기
원격 재생, 파일 식별자의 일치, 이미지 저장은 각각 다른 사실을 보여 줍니다. 정지 사진만 내려받은 상태를 복구된 백업으로 보기 전에 원본 파일 쌍과 사진 앱에 복원된 항목을 확인하세요.
Immich에서는 움직이는 Live Photo가 Apple 사진 앱에 새로 저장한 뒤 정지 사진으로만 보인다면 Live Photo 복원은 아직 확인되지 않은 상태입니다. 원본 파일을 보관하세요. 먼저 정지 사진과 짝을 이루는 동영상이 모두 있는지 확인하고, 실제 파일 형식과 관련 식별자를 살펴본 다음 사진 앱에 복원된 항목을 확인합니다. UUID 변경부터 시작하지 마세요.
이 확인을 나누어야 하는 구체적인 이유가 있습니다. 우리가 살펴본 Immich 모바일 저장 서비스 v3.2.1과 v3.3.5에서는 사진 앱 오류를 처리하는 한 분기가 정지 사진만 저장하려고 시도하고, 그 정적 저장 결과가 null이 아니면 성공으로 처리합니다. 이는 소스 코드에 대체 처리가 있다는 증거입니다. 사용자가 겪은 결과의 원인이 그 처리라는 증거나 모든 완료 메시지가 그 반환값에서 나온다는 뜻은 아닙니다.
서버 연결, 파일 쌍, 복원된 Live Photo는 서로 다른 증거입니다
Immich는 이미지를 동영상과 연결하고 자체 뷰어에서 움직임을 재생할 수 있습니다. 이것은 서버 쪽 상태에 대한 답입니다. 내려받은 파일이 두 개 있다는 사실은 자료 보존에 대한 답입니다. 새 항목이 Apple 사진 앱에서 Live Photo로 작동하는지가 실제로 확인하려는 복원 여부에 대한 답입니다. 앞 단계의 관찰을 다음 단계의 확인으로 대신해서는 안 됩니다.
Apple 문서는 동영상의 콘텐츠 식별자가 해당 정지 사진의 Exif MakerNote 안에 있는 메타데이터와 연결된다고 설명합니다. 반면 Immich 자체의 연결은 데이터베이스 관계입니다. 따라서 Immich에서 두 자산을 다시 연결했다는 사실만으로 파일에 포함된 Apple 메타데이터가 변경되었거나 사진 앱이 그 쌍을 받아들일 수 있다고 판단할 수는 없습니다.
원본 자료를 보관하고 실패한 경로를 기록하세요
보관본이나 원본 파일 다운로드에서 얻은 정지 사진과 짝을 이루는 동영상의 복사본으로 작업하세요. 둘을 별도 폴더에 함께 보관합니다. 내보낸 결과가 정지 사진뿐이라면 먼저 해당 원본 동영상을 찾으세요. 스크린샷, 미리보기, 이름을 새로 .MOV로 바꾼 파일은 없는 동영상 데이터를 대신할 수 없습니다. 복구를 시도하려고 Immich가 관리하는 저장소 안의 파일을 수정하지 마세요.
Immich 서버 버전, 모바일 앱 버전, iOS 버전과 함께 결과가 모바일 Save, 웹 다운로드, 다른 내보내기 방식 중 어디에서 나왔는지 기록하세요. 원본이 Apple Live Photo였는지 Android 모션 포토였는지도 적어 둡니다. 이 가이드는 Apple 사진 앱으로의 복원을 다루며, 서로 다른 플랫폼 사이에서 모션 포토를 변환하면 반드시 작동한다고 약속하지 않습니다.
아무것도 쓰지 않고 파일 형식과 식별자 그룹을 살펴보세요
ExifTool을 설치한 뒤 `exiftool -ver`를 실행하고, 이어서 `exiftool -a -G1 -s -FileType -ContentIdentifier "photo.JPG" "photo.MOV"`를 실행하세요. 따옴표 안의 두 경로는 준비한 복사본의 경로로 바꿉니다. 이 옵션들은 메타데이터를 읽습니다. 출력에서 파일별 구분과 그룹 이름을 유지하세요. 파일 이름이 .MOV로 끝난다는 사실은 실제 파일 형식 검사 결과를 대신하지 못합니다.
검사한 iPhone 샘플에서는 정지 사진에 [Apple] ContentIdentifier, 동영상에 [Keys] ContentIdentifier가 있었습니다. 이 값들을 비교하세요. 비슷해 보인다는 이유만으로 ImageUniqueID, 파일 이름의 UUID, 관계없는 XMP 값으로 대신하지 마세요. 해당 그룹이 없거나 여러 값이 충돌하거나 도구가 파일을 읽지 못하면 그 불확실성을 기록하고 유효한 파일 쌍이라고 단정하지 않습니다.
실제 실패 보고의 두 샘플은 하나의 메타데이터 처방으로 충분하지 않음을 보여 줍니다
우리는 Immich 이슈 14066과 15805에 첨부된 공개 JPEG/MOV 압축 파일을 ExifTool 13.59로 살펴봤습니다. 둘 다 JPEG와 MOV를 포함했습니다. 첫 번째 쌍에서는 Apple/Keys 콘텐츠 식별자가 달랐고 두 번째 쌍에서는 일치했습니다. 읽기 전용 검사 전후에 SHA-256을 비교해 네 파일 모두 변경되지 않았음도 확인했습니다.
이 결과는 제공된 파일을 분류할 뿐, 원래 실패의 원인을 진단하지는 않습니다. 이슈 14066에는 작업 기록이 없다는 오류도 포함되어 있었습니다. 이슈 15805는 잘못된 동영상 다운로드 URL을 고친 후속 수정에서 명시적으로 다뤘습니다. 우리는 iOS나 macOS 복원을 실행하지 않았습니다. 서버에서 내보낸 파일 쌍이 올바르더라도 과거 모바일 다운로드가 실제로 어떤 바이트를 전달했는지까지 입증되지는 않습니다.
실제로 확보한 증거에 따라 다음 행동을 정하세요
동영상이 없거나 읽을 수 없거나 실제로는 다른 이미지라면, 연결을 시도하기 전에 의도한 원본 자료부터 확보하세요. 관련 식별자가 없거나 서로 다르면 원본 보관본과 내보내기 이력으로 돌아가 어느 정지 사진과 동영상이 짝인지 확인합니다. 같은 기본 파일 이름이나 비슷한 촬영 시각은 단서일 뿐, 임의로 고른 파일의 식별자를 덮어써도 된다는 근거가 아닙니다.
관련 식별자가 일치한다면 UUID 교체를 만능 복구 방법으로 취급하지 마세요. 그 파일 쌍을 보관한 채 전달 과정과 사진 앱 저장 경로를 조사합니다. 기존 복구 도구는 파일 간에 식별자를 복사할 수 있지만, 그렇다고 동영상과 나머지 메타데이터가 올바르거나 Apple이 받아들인다고 보증할 수는 없습니다. 식별자가 일치하는데 복원이 실패했다면 같은 값을 계속 다시 쓸 일이 아니라 더 나은 증거를 모아야 할 상황입니다.
과거 클라이언트 수정과 정지 사진 대체 저장을 구분하세요
여기서는 이미 알려진 두 클라이언트 수정이 중요합니다. PR22708은 동영상 요청에 정지 사진 URL을 사용하던 문제를 고쳤습니다. PR29952는 완료된 Live Photo 다운로드 작업을 묶는 방식과 콜백의 상호 작용을 고쳤습니다. 이 사례들은 원본 파일 쌍의 식별자와 별개로 전달 과정에 문제가 생길 수 있음을 보여 줍니다. 어느 패치도 이후의 모든 정지 사진 다운로드 보고의 원인을 입증하지는 않습니다.
검사한 v3.2.1/v3.3.5 저장 코드는 오류 코드가 PHPhotosErrorDomain으로 시작하는 오류를 여전히 잡아서 saveImageWithFile을 시도하고, 그 정지 사진 저장으로 자산이 생성되었는지를 반환합니다. 우리는 이 불리언 값을 모든 UI 상태 표시까지 추적하지 않았습니다. 여기서 얻을 수 있는 결론은 더 좁습니다. 전송 진행률과 저장된 정지 사진만으로는 Live Photo가 완전히 복원되었다고 판단할 수 없습니다. 오래된 패치를 무작정 적용하지 말고 버전을 기록한 뒤, 지원되는 업데이트를 마친 후 원본을 보관한 예제 하나로 다시 확인하세요.
Apple 사진 앱에서 새로 복원된 항목을 확인하세요
라이브러리에 이미 있던 정상 사본 대신 이번 복원으로 생성된 항목을 살펴보세요. iPhone에서 Apple의 현재 안내에 따르면 Live Photos는 사진 → 모음 → 미디어 유형 → Live Photo에 있습니다. 항목을 열고 길게 눌러 재생하세요. 사진 앱에 Live 제어 기능이 여전히 보인다면 움직임이 사라졌다고 결론 내리기 전에 효과가 꺼져 있지는 않은지 확인합니다.
따로 재생되는 MOV는 보존된 유용한 자료지만, 사진 앱이 하나의 Live Photo로 복원했다는 증거는 아닙니다. 실제로 사용할 기기와 작업 방식에서 이 확인을 통과할 때까지 원본을 보관하세요. 깨끗한 시험 환경을 만들기 위해 유일한 정상 사본을 지우지 마세요. 원본 자료를 별도로 보관한 기존 실패 사례를 사용하거나, 가능하다면 분리된 시험용 대상으로 복원합니다.
복구 상태를 과장하지 않는 완료 기록을 남기세요
시험한 예제에 대해 버전, 내보내기 경로, 두 파일 형식, 관련 식별자의 일치 여부, 실제 사진 앱 재생 결과를 보관하세요. 유용한 지원 요청은 ‘원본 동영상 없음’, ‘두 자료는 보관했지만 복원 여부는 미확인’, ‘이 기기에서 복원 후 재생됨’을 구분할 수 있습니다. 오류가 나왔다면 정확한 내용을 포함하되, 오류가 없다는 이유만으로 Live 저장이 이루어졌다고 가정하지 마세요.
이 절차는 다음 판단의 범위를 좁혀 줍니다. 없는 동영상 프레임을 복구하거나 식별자가 일치하는 모든 쌍의 유효성을 인증하지는 않습니다. 실질적인 목표는 정확한 복원 결과와 원본 자료의 보존입니다. 아직 복원해야 하는 Live Photo의 남은 사본을, 서버에서 재생된다는 이유만으로 버려서는 안 됩니다.
