📑 목차
프로크리에이트에서 갤러리 썸네일이 깨지거나 로딩되지 않고, 특정 파일이 열리지 않는 문제는 단순 앱 오류가 아니라 갤러리 데이터베이스 손상이나 저장 구조 충돌에서 발생하는 경우가 많습니다. 이 글은 프로크리에이트 파일 손상 징후를 구분하고, iPad의 아이튠즈(또는 Finder) 로컬 백업을 활용해 작업 데이터를 복구하는 원리와 복원 프로세스를 정리합니다.
썸네일이 하얗게 뜨던 날, 그림이 사라진 게 아니라 연결이 끊긴 것
프로크리에이트를 열었는데 갤러리 썸네일이 회색으로 멈추거나, 미리 보기 이미지가 깨진 상태로 보이고, 클릭하면 파일이 열리지 않는 순간이 있습니다. 저는 처음 그 상황을 마주했을 때 그림이 날아갔다고 생각했습니다. 특히 수익화를 전제로 작업 파일을 쌓아두던 시기에는, 한 번의 손상이 단순한 작업 중단이 아니라 자산 손실로 이어질 수 있다는 압박이 컸습니다.
그런데 여러 번의 사례를 겪으면서 저는 문제의 성격이 생각보다 단순하지 않다는 점을 알게 됐습니다. 어떤 경우에는 파일 자체가 손상된 것이 아니라, 갤러리에서 파일을 보여주는 썸네일/목록 데이터베이스가 꼬여서 파일을 찾지 못하는 상태가 만들어지기도 했습니다. 즉, 파일이 완전히 소멸했다기보다 연결(인덱싱)이 끊긴 상태에 가까웠습니다.
이 글은 프로크리에이트 갤러리 썸네일 로딩 오류와 프로크리에이트 파일 손상을 디버깅 관점에서 구분하고, 최악의 경우를 대비해 아이튠즈(또는 Finder) 로컬 백업 데이터를 활용해 복원 가능성을 높이는 프로세스를 구조적으로 정리한 기록입니다. 단순히 '이렇게 하세요’가 아니라, 왜 이런 절차가 필요한지 데이터 구조 관점에서 설명합니다.
갤러리 썸네일 로딩 오류가 파일 손상은 아니다.
검색에서 흔히 프로크리에이트 파일 손상으로 묶이는 증상은 실제로 여러 유형이 섞여 있습니다. 저는 아래처럼 증상을 나누기 시작하면서 복구 판단이 훨씬 빨라졌습니다.
1) 썸네일만 깨졌는데 파일은 열리는 경우
- 썸네일이 검은색/하얀색/깨진 이미지로 보이지만 탭 하면 캔버스는 열림
→ 이 경우는 대체로 썸네일 캐시 또는 미리 보기 생성 과정이 꼬인 상태일 가능성이 큽니다.
2) 썸네일이 로딩되지 않고, 파일이 열리다가 튕기는 경우
- 회색 로딩이 길어지고, 열리는 듯하다가 종료
→ 캔버스 데이터 자체(레이어/타임랩스/메모리) 또는 갤러리 DB의 참조 정보가 깨졌을 수 있습니다.
3) 특정 파일만 ‘빈 캔버스’처럼 보이거나 아예 열리지 않는 경우
- 선택하면 아무 반응이 없거나 앱이 멈춤
→ 파일 단위 손상 가능성이 올라갑니다. 특히 대용량 레이어, 저장 중 강제 종료가 있었던 경우 더 그렇습니다.
여기서 핵심은, 프로크리에이트의 갤러리가 단순 폴더가 아니라는 점입니다. 갤러리는 작업 파일(procreate) 자체 + 미리 보기(썸네일) + 목록을 관리하는 내부 데이터베이스가 함께 움직이는 구조에 가깝습니다. 썸네일이 깨졌다고 해서 파일이 무조건 사라진 것은 아닙니다. 반대로 파일이 안 열린다고 해서 그림 데이터가 '0'이 된 것도 아닐 수 있습니다. 문제는 정상 접근 경로가 끊겼다는 것이고, 디버깅은 그 경로를 복구하거나 우회하는 전략이 됩니다.
왜 데이터베이스 오류가 발생하는가: 저장 실패보다 동기화·갱신 충돌이 더 위험
저는 초기에는 파일 손상의 원인을 대부분 내가 저장을 안 했기 때문이라고 생각했습니다. 하지만 실제로는 저장 자체보다, 저장 이후에 벌어지는 갤러리 갱신 과정에서 충돌이 생기는 경우가 더 인상적이었습니다.
1) 대용량 파일 + 갤러리 인덱싱 갱신 타이밍
프로크리에이트는 캔버스를 저장하면서 동시에 갤러리 썸네일과 미리 보기를 갱신합니다. 레이어가 많고 해상도가 큰 파일은 이 갱신 과정이 더 오래 걸리는데, 이때 앱이 강제 종료되거나 iPad가 메모리 압박을 받으면 썸네일/목록 정보가 업데이트 중단된 채로 남을 수 있습니다. 결과적으로 “파일은 있는데 갤러리가 제대로 가리키지 못하는 상태”가 생깁니다.
2) iCloud 동기화·기기 저장공간·백그라운드 정리의 조합
이전 글에서도 다뤘지만, iCloud는 편리한 대신 동기화가 즉시 반영되지 않는 지연과 버전 충돌이 생길 수 있습니다. 프로크리에이트가 내부적으로 갤러리 정보를 업데이트하는 순간에 iCloud가 파일 상태를 다시 정리하거나, 저장공간이 부족해 캐시를 정리하면, 갤러리 DB가 참조하는 파일 경로/상태와 실제 파일 상태가 어긋나기 시작합니다. 이런 어긋남은 파일이 사라졌다가 아니라 앱이 파일을 불완전한 상태로 인식한다로 나타납니다.
3) 업데이트 이후 구조 변경(앱/OS)
iPadOS 또는 프로크리에이트 업데이트 이후 썸네일이 다르게 보인다, 갤러리가 느리다 같은 현상이 생길 때가 있습니다. 이는 일부 파일이 새 형식으로 재색인되는 과정이 들어가기 때문일 수 있습니다. 이때도 중간에 전원/메모리/저장공간 변수가 끼면, 일부 파일만 문제를 일으키는 패턴이 나올 수 있습니다.
제가 강조하고 싶은 지점은 하나입니다.
갤러리 오류는 '그림을 못 그렸다'가 아니라 '데이터베이스 참조가 꼬였다'일 수 있다는 점입니다. 그래서 복구 전략도 '그림을 다시 그린다'가 아니라 '데이터 접근 경로를 되살린다'로 전환됩니다.
아이튠즈(또는 Finder) 로컬 백업을 활용한 복구 프로세스: 되돌리는 게 아니라 살아있는 버전으로 복원하는 방식
프로크리에이트 파일 손상에서 가장 강력한 안전장치는 결국 로컬 백업입니다. 여기서 말하는 로컬 백업은 PC/Mac에 저장되는 iPad 전체 백업(아이튠즈 또는 Finder 백업)을 의미합니다. 이유는 간단합니다. 로컬 백업은 클라우드 지연이나 버전 충돌과 다르게, 특정 시점의 iPad 상태를 통째로 고정해 두는 스냅숏에 가깝기 때문입니다.
다만 중요한 전제가 있습니다.
로컬 백업 복구는 그 파일만 쏙 꺼내는 형태가 아니라, 대개 백업 시점의 iPad 상태로 복원되는 방식이라서 복원 전략을 단계적으로 설계해야 합니다. 저는 다음 기준으로 접근했습니다.
0단계: 현재 상태를 먼저 보존
복원을 시도하기 전에, 가능한 범위에서 현재 파일을 확보해야 합니다. 이유는 두 가지입니다.
- 지금 상태가 완전히 망가진 게 아닐 수 있음
- 복원 과정에서 현재 데이터가 덮어씌워질 수 있음
그래서 저는 지금 열리는 파일이라도 외부로 내보내거나(PSD/PNG) 문제가 있는 갤러리라도 공유가 가능하면 공유로 빼두는 습관을 먼저 만들었습니다. 이 단계가 있으면 복원 후에도 손실 폭을 최소화할 수 있습니다.
1단계: 백업 존재 여부와 시점을 먼저 확인
아이튠즈/Finder 로컬 백업은 미리 해둔 사람만 쓸 수 있습니다. 그래서 디버깅의 출발점은 '백업이 있는가'입니다. 백업이 있다면 그 날짜가 중요합니다. 파일이 깨진 시점보다 이전 백업이라면, 복원 성공 확률이 올라갑니다.
2단계: 복원은 상태를 되돌리는 작업
로컬 백업 복원은 특정 앱만 복구하는 느낌이 아니라, iPad를 백업 시점 상태로 되돌리는 성격이 강합니다. 여기서 실무적인 판단이 필요합니다.
- 지금 iPad에 최근 작업이 많다면 → 복원 전에 반드시 외부로 빼둘 데이터가 있는지 점검
- 수익화 작업이 쌓였다면 → '복원 후 재동기화' 과정에서 충돌이 생기지 않도록 순서를 설계
저는 이 과정을 단순히 '복원 버튼을 누른다'로 생각하지 않게 됐습니다. 복원은 곧 버전 관리 선택입니다. 어느 시점의 데이터를 정답으로 인정할지 결정하는 일입니다.
3단계: 복원 후에는 갤러리 DB 재색인 여부 확인
복원이 완료된 후에도 썸네일이 바로 정상화되지 않는 경우가 있습니다. 이때 중요한 것은 파일이 실제로 열리는지입니다. 썸네일이 깨져도 파일이 열리면, 복원 자체는 성공한 것입니다. 갤러리 썸네일은 시간이 지나면서 재생성되거나, 앱 내부에서 다시 캐시가 만들어질 수 있습니다.
4단계: 복원 직후 이중 백업
복구가 되었다면 그 순간이 가장 위험합니다. 다시 같은 일이 생기면 다음에는 복원할 백업이 없을 수 있기 때문입니다. 저는 복원 직후 아래를 바로 실행합니다.
- 중요한 작업 파일부터 우선 외부 저장(파일앱/외장/PC)
- 다음 로컬 백업을 즉시 생성
- iCloud 동기화는 안정화 후 단계적으로 재개
이 루틴은 귀찮지만, 수익형 작업에서는 사실상 필수입니다. 파일이 곧 자산이기 때문입니다.
Q&A
Q. 썸네일이 깨졌으면 파일이 이미 손상된 건가요?
A. 꼭 그렇지는 않았습니다. 썸네일은 미리 보기 캐시에 가까워서, 파일은 정상인데 미리 보기만 실패한 경우도 있었습니다. 저는 파일이 열리는가를 먼저 기준으로 잡았습니다.
Q. 특정 파일만 안 열리면 복구가 불가능한가요?
A. 불가능하다고 단정하긴 어렵지만, 파일 단위 손상 가능성은 올라갑니다. 이때 로컬 백업이 있으면 손상 이전 버전으로 돌아갈 선택지가 생깁니다.
Q. iCloud만으로는 왜 불안한가요?
A. iCloud는 동기화 시점이 지연될 수 있고, 충돌 시 어느 버전이 최신인지가 애매해질 수 있습니다. 로컬 백업은 특정 시점을 고정하는 장점이 있습니다.
Q. 아이튠즈 백업 복원은 최후의 수단인가요?
A. 저는 최후의 수단으로 분류했습니다. 대신 최후의 수단이 작동하도록 평소에 백업을 만들어두는 습관이 더 중요했습니다.
나의 생각｜복구 기술보다 중요한 건 복구 가능한 구조를 갖추는 일
프로크리에이트 갤러리 썸네일 로딩 오류와 파일 손상 문제를 겪으며 저는 관점을 바꿨습니다. 처음에는 이 문제를 앱의 불안정함이나 운으로 받아들였지만, 실제로는 데이터 구조 관점에서 충분히 설명 가능한 사건이었습니다. 갤러리 DB, 미리 보기 캐시, 파일 상태, 동기화 타이밍이 엮이면서 파일이 사라진 것처럼 보이는 상태가 만들어질 수 있습니다.
수익화를 목표로 한다면 더 중요한 건 기술적인 복구법 그 자체가 아니라, 복구 가능한 버전 관리를 갖추는 것입니다. 로컬 백업은 번거롭지만, 복구의 마지막 안전장치로 기능합니다. 특히 작업 파일이 누적될수록, 그림을 잘 그리는 능력보다 데이터를 잃지 않는 구조가 더 큰 경쟁력이 됩니다.
저는 이제 오류를 완전히 피하려 하기보다, 오류가 나더라도 복구 가능한 방향으로 작업 환경을 설계합니다. 이것이 디지털 드로잉을 취미에서 자산으로 바꾸는 과정에서 반드시 필요한 기준이라고 판단합니다.