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