개요

개발 초기 단계에서 내걸었던 「모든 것이 사용자의 눈에 보이는 투명성」이라는 이상에서 한 걸음 더 나아가, 「어떤 일이 있어도 지능을 잃지 않는 견고성」으로 방향을 틀었다. v2.3에서의 버그와의 사투를 거쳐, v2.4에서 도달한 「뇌의 백업」 최종 형태를 기록한다.

신구 사양 비교

항목	구 사양 (v2.2 이전)	이행기 (v2.3)	최종 사양 (v2.4)
Drive 구성	모두 육안 확인 가능	Synced만 가시화	Synced만 가시화 (자동 정리)
백업 대상	일반적인 가시 폴더	숨겨진 영역 (AppData)	숨겨진 영역 (AppData)
암호화 솔트 (Salt)	단말기 내 한정	클라우드로 파일 동기화	앱 내 고정 (영속화)
복원 경험	동일 단말기만 가능	파일 동기화 지연으로 불안정	로그인 한 번으로 100% 성공
폴더 탐색	직하 폴더만	재귀적으로 전체 스캔	연도별 자동 폴더 + 재귀

1. 암호화 솔트 (Salt)의 「탈·파일 관리」

초기 설계에서는 암호화를 위한 키를 만드는 「솔트 (Salt)」를 클라우드로 동기화하고 있었다. 하지만 여기에는 함정이 있었다.

「DB 파일은 있지만, 솔트 파일의 동기화가 몇 초 늦어지고 있다」는 것만으로도 복원은 실패한다. 클라우드 연동에 있어 파일의 존재 여부를 전제로 하는 설계는 취약했다.

v2.4의 결단:

솔트를 파일로 취급하는 것을 그만두고, 「사용자의 Google ID」와 「앱 내 고정 문자열」을 조합하는 로직으로 변경. 이를 통해 「파일 분실로 인한 복호화 불능」 리스크를 물리적으로 제로(0)로 만들었다. Google 로그인만 할 수 있다면, 지구상 어디에서든 자신의 기억을 해독할 수 있다.

2. 기동 시퀀스의 「철저한 교통 정리」

v2.3.1에서는 기동 직후에 「복원 체크」, 「청소」, 「미전송 데이터 재전송」이 동시에 실행되는 설계상의 「정체」가 발생하고 있었다.

그 결과, 복원 중에 다른 처리가 DB를 건드리러 가서, Bad state: Store is closed라는 에러를 내뱉으며 루프에 빠지는 사태가 발생했다.

운용 개선:

모든 처리를 「직렬 (순서 대기)」 방식으로 변경.

복원이 필요한가? ➔ 필요하다면 다른 모든 기능을 셧다운하고 복원에 전념.

복원이 필요하지 않다면 ➔ 처음으로 청소와 동기화를 시작.

이 「교통 정리」를 통해 언인스톨(Uninstall) 후의 복원 성공률이 비약적으로 향상되었다.

3. 「자유로운 정리」와 「자동 정리」의 공존

「AI가 찾으니까 폴더 분류는 필요 없다」는 것은 개발자의 에고(Ego)였다. 사용자는 Drive를 열었을 때도 아름답게 정리되어 있기를 원한다.

하지만 Google의 보안 제한 (drive.file 권한)으로 인해, 사용자가 임의로 만든 폴더는 AI가 들여다볼 수 없다는 딜레마가 있었다.

해결책:

앱이 자동으로 「Synced / 2026 / 파일명」과 같이 연도별 폴더를 생성하여 관리하는 사양으로 변경.

사용자의 「정리하고 싶은 욕구」를 앱이 앞서서 충족시키면서도, AI가 확실하게 모든 원본을 추적할 수 있는 기술과 UX의 타협점을 찾아냈다.

결론

보여야 할 원본 (Synced)은 아름답게 정리되어 보이는 장소에.

지켜야 할 지능 (DB와 키)은 파일이라는 개념조차 버리고 안전한 장소로.

「버그투성이인 이상」을 버리고, 하나하나의 로그와 마주하며 「진흙탕 같은 현실」을 정리함으로써, Exa-Vision은 단순한 앱에서 평생 함께할 수 있는 「외부 기억 장치」로 진화했다.

Discussion