이 앱의 다른 모든 것을 결정짓는 단 하나의 설계 원칙은 말로는 간단하지만 실제로 지키려면 꽤 번거로워요. 사진 드라이브는 철저히 읽기 전용으로만 열리고, 절대 쓰기 작업이 일어나지 않아요. 원본 옆에 사이드카 파일을 만들지도, 숨겨진 메타데이터 폴더를 두지도, 이름을 바꾸지도, 복사본을 옮기지도 않아요. 들어온 드라이브는 나갈 때도 바이트 하나 다르지 않은 그대로예요.
이 원칙은 있으면 좋은 정도로 들리지만, 이게 무엇을 배제하는지 보면 생각이 달라져요. 파일을 옮기거나 이름을 바꿔서 "정리"하는 방식의 도구들은 통째로 제외돼요. 썸네일, 얼굴 임베딩, 행사 경계 같은 파생 데이터를 원본 근처에 두는 것도 안 돼요. 앱이 아카이브에 대해 알게 되는 모든 정보는 완전히 다른 곳에 있어야 했고, 그래서 그 "다른 곳"이 어디가 될지를 초기에 정해야 했어요.
파생 데이터는 모두 내장 디스크에 저장돼요
답은 SQLite예요. 외장 드라이브가 아니라 Mac의 내장 디스크에 저장돼요. 인덱스(날짜, 인물, 행사 경계, 검색용 임베딩)와 썸네일 캐시 모두 그곳에 있고, 아카이브 자체와는 완전히 분리돼 있어요. 앱의 데이터 디렉터리를 지워도 아카이브는 아무 영향을 받지 않는다는 게 확실해요. 아카이브의 그 무엇도 이 디렉터리가 존재하는 것에 의존한 적이 없으니까요. 처음부터 다시 설치하면 앱은 자기 상태의 백업을 믿는 대신, 드라이브를 다시 읽어서 이해를 처음부터 다시 쌓아요.
SQLite의 write-ahead log(WAL)는 이론이 아니라 실전에서 가장 결정적이었던 부분이에요. 개발 중에 실제로 두 번의 하드 크래시가 있었어요 — 시뮬레이션한 장애 주입 테스트가 아니라 진짜 정전이었고, 실제 아카이브를 대상으로 분석이 돌아가던 도중 쓰기 작업 중간에 일어났어요. 두 번 모두 WAL 저널링 덕분에 데이터 손실은 전혀 없었어요. 다음 실행 시 데이터베이스는 일관된 상태로 돌아왔고, 멈췄던 지점에서 거의 그대로 이어졌으며, 수동 복구가 전혀 필요 없었어요. 이런 보장은 필요할 일이 없기를 바라면서도 직접 테스트해 보고 싶지는 않은 종류의 것이지만, 외장 드라이브와 몇 시간씩 돌아가는 백그라운드 분석, 그리고 케이블이 가끔 걸리적거리는 가정 환경이 만나면서 출시 전에 실제로 두 번이나 검증됐어요.
'읽는다'는 게 실제로 얼마나 복원해 낼까
읽기 전용이라는 보장도 결국 그 원칙을 지키면서 실제로 얼마나 뽑아낼 수 있느냐에 달려 있는데, 실제 가족 아카이브의 메타데이터는 깔끔한 테스트 세트보다 훨씬 지저분해요. 기준이 된 아카이브에서는 파일의 92%가 곧바로 사용 가능한 EXIF 날짜를 갖고 있었어요. 나머지 8%는 대체 수단이 필요했는데 — 파일 시스템 타임스탬프, 폴더명에 담긴 날짜, 같은 행사 내 주변 사진으로부터의 추론 — 이런 대체 수단을 거치고 나면 커버리지가 98.1%에 도달해요. 마지막 2%는 정직한 한계예요. 일부 파일은 파일 안에도, 주변 어디에도 아무런 단서를 남기지 않고, 어떤 대체 수단의 연쇄도 없는 것을 만들어 낼 수는 없으니까요.
이해가 끝나기 전에도 둘러볼 수 있어요
읽기 전용과 파생 데이터의 분리는 안전성 문제를 해결하지만, 별개로 인내심 문제가 남아요. 큰 아카이브를 전체 분석하는 데는 몇 시간이 걸리는데, 사진 한 장 보자고 진행률 표시줄만 쳐다보고 싶은 사람은 없죠. 앱을 드라이브에 처음 연결한 지 몇 분 만에 라이브러리를 둘러볼 수 있게 되는데, 초기 패스만으로도 충분한 인덱스와 썸네일이 갖춰져서 기본적인 탐색이 실제로 가능해져요. 겉핥기가 아니라요. 그 뒤로 더 깊은 분석 단계(얼굴 클러스터링, 행사 이름 짓기, 의미 기반 검색을 가능하게 하는 임베딩)가 계속 돌아가면서, 이미 사진을 보고 있는 동안 조용히 더 풍부한 답을 채워 나가요. 가장 비용이 큰 마지막 단계 뒤에 첫 유용한 순간을 가둬두지 않는 거예요.
리소스 관리는 권장 사항이 아니라 규칙이에요
마지막 요소는 건너뛰기 쉽지만, 잘못 건너뛰면 대가가 큰 부분이에요. 수십만 개의 파일을 읽고 이해하는 분석은 정말 무거운 작업이고, 누군가의 유일한 Mac에서 다른 용도로 그 컴퓨터를 쓰려는 동안 무거운 백그라운드 작업이 돌아가면 "프라이버시 우선 로컬 AI"가 "내 노트북이 왜 히터가 됐지"로 바뀌어 버려요. 여기 적용되는 규칙은 최선을 다하는 정도가 아니라 반드시 지켜지는 강제 규칙이에요. 분석이 포그라운드 작업과 절대 우선순위를 다투지 않도록 하는 백그라운드 QoS 스케줄링, 사용자가 활동을 시작하면 몇 초 안에 물러나는 적응형 작업자 수 조절, 메모리 사용량에 대한 확실한 상한선, 배터리나 발열 압박이 있으면 아예 멈추는 일시정지까지요. 기본 사양 Mac에서 돌아가는 전체 분석은 체감할 수 있으면 안 돼요. 만약 체감된다면 그건 트레이드오프가 아니라 버그예요.
읽기 전용 원본, 내장 디스크의 파생 데이터, 크래시에도 안전한 저널링, 실제로 지켜지는 리소스 제한까지, 이 모든 게 합쳐져서 그다지 화려하지 않은 엔지니어링 명제 하나로 이어져요. "로컬 우선"에서 흥미로운 지점은 AI가 서버 대신 기기에서 돈다는 사실 자체가 아니에요. 물론 그것도 사실이지만요. 진짜 핵심은 애초에 믿어야 할 서버가 없다는 거예요. 그 말은 이 모든 보장이 오직 책상 위에 놓인, 이미 다른 모든 것을 맡기고 있는 그 한 대의 기기에 대해서만 참이면 된다는 뜻이에요.