새로고침하면 사라지는 앱? AI가 만든 데이터 저장을 끝까지 확인해봤다

저장됐다는 화면 표시만으로 정말 저장됐다고 말할 수 있을까? 화면만 바뀌었거나 이 브라우저 안에만 남았는데도 앱은 얼마든지 저장된 것처럼 보일 수 있다.

AI로 앱을 만들거나 맡길 때 이 차이를 확인할 수 있도록, 가짜 기록만 넣은 폐기 가능한 로컬 앱 하나를 시험했다. 저장 위치만 비교하는 브라우저 화면과 기록을 만들고 지우는 핵심 앱을 같은 UI에 두고, 브라우저와 로컬 API(화면과 저장소를 잇는 통로), SQLite(파일형 데이터 저장소)를 나눠 살폈다. AI 앱 전체를 평가하는 비교는 아니다.

1. 어디에 저장됐나?
2. 누가 저장을 확인했나?
3. 누가 그 데이터에 접근할 수 있나?

이 글의 목차

1. 어디에 저장됐나

먼저 저장 위치만 비교하는 화면에서 기록 하나를 실행 중 메모리, sessionStorage, localStorage, IndexedDB, 그리고 일부러 값을 버리는 가짜 저장 방식에 각각 넣었다. 하드 새로고침 뒤 결과는 다음과 같았다.

공식 문서에 따르면 sessionStorage는 탭 세션 동안 유지되고, localStorage는 같은 출처의 브라우저 세션을 넘어 남을 수 있다. IndexedDB는 브라우저 쪽 구조화 저장소다. 따라서 이번처럼 “새로고침 후 보인다”는 관찰만으로는 서버 저장이나 다른 기기 복구를 증명할 수 없다. 브라우저 저장소도 삭제·축출될 수 있다(MDN 저장 용량과 축출 기준).

이번 브라우저 확인은 하드 새로고침까지만 했다. 브라우저 프로세스를 완전히 종료한 뒤 재시작하는 검사와 깨끗한 새 프로필에서의 UI 검사는 실행하지 않았다. 이 두 UI 검사는 아래의 검증기 25개 체크포인트와 별개이며, 성공이나 실패로 판정하지 않았다.

2. 누가 저장을 확인했나

핵심 앱에서는 가짜 사용자 A가 기록 세 개를 만들고, 하나를 수정하고, 하나를 삭제했다. 앱의 응답만 믿지 않고 별도 검증기가 SQLite 파일을 직접 읽어 예상한 ID·내용·버전과 비교했다. 로컬 API가 캐시를 쓰지 않는다는 응답(Cache-Control: no-store)과 SQLite에서 읽었다는 자기표시(read_source: sqlite_authoritative)도 받았지만, 이 표시 자체를 증거로 삼지는 않았다. API 결과가 독립적인 SQLite 직접 검사와 일치하는지 다시 대조했다.

실행은 세 번이었다. 첫 실행은 제한 환경이 로컬 포트 연결을 막아 2 PASS·20 FAIL·2 INVALID·1 NOT RUN을 남겼다. 두 번째는 서버 프로세스가 첫 요청 전에 종료되어 3 PASS·21 FAIL·1 NOT RUN이었다. 두 번 모두 앱 품질 판정에서 제외했다. 환경과 프로세스 운영 실패를 숨기지 않고 보존한 뒤, 미리 정해 바꾸지 않은 같은 검사 순서를 정상 로컬 환경에서 실행한 세 번째만 앱 관찰값으로 사용했다.

세 번째 유효 실행의 기계 판정은 24 PASS, 0 FAIL, 0 INVALID, 1 NOT RUN이었다. 이는 기능 완성도 점수가 아니라 생성·수정·삭제, 직접 읽기, 서버 불가 상태의 부정 확인, 접근 차단 등을 포함한 25개 체크포인트의 합계다. 여기서 1 NOT RUN은 로컬 코드 아티팩트 교체 한 항목이다.

서버가 응답하지 않을 때는 권위 있는 읽기도 실패했고, 서버가 돌아온 뒤 다시 읽을 수 있었다. 이는 서버가 꺼진 동안의 응답을 저장 확인으로 잘못 세지 않았다는 오프라인 부정 확인이며, 모든 캐시 상황을 시험했다는 뜻은 아니다. 별도의 로컬 서버 프로세스 재시작 검사에서는 다른 프로세스로 다시 띄운 뒤에도 같은 SQLite 기록이 유지됐다.

그러나 코드 아티팩트 교체와 호스팅 배포는 실행하지 않았다. 로컬 서버 재시작을 배포 성공이라고 부를 수는 없다. 클라우드 내구성, 백업 복원, 장기 보존도 이번 결과의 범위 밖이다. 이번 로컬 실행의 직접 금전 비용은 USD 0.00이었으며, 구독·노동·전기·장비 비용을 계산한 값은 아니다.

3. 누가 접근할 수 있나

저장이 오래 남아도 다른 사람이 볼 수 있다면 성공이라 하기 어렵다. 이 실험은 고정된 테스트 헤더 X-Synthetic-Identity로 가짜 사용자 A와 B를 구분했다. B가 자기 기록을 만드는 정상 경로를 먼저 통과한 뒤, A가 만든 기록의 ID를 읽고·수정하고·삭제하도록 요청했다. 해당 요청들은 404(찾을 수 없음)로 거부됐고 저장소의 A 기록도 바뀌지 않았다. 테스트 헤더를 빼고 보낸 읽기는 401(인증 필요), A가 B의 기록을 읽는 반대 방향 요청은 404였다.

이는 테스트한 경로에서만 사용자 분리가 작동했다는 뜻이다. 고정 헤더로 사용자를 구분한 로컬 장치라 실제 로그아웃 상태를 시험한 것이 아니며, 운영 인증이나 제품 보안을 증명하지 않는다. Supabase의 행 수준 보안 안내와 Firebase 보안 규칙 문서도 로그인과 데이터 권한을 별개로 다룬다.

중복도 별도 항목이다. 같은 작업 ID로 A의 생성 요청을 딱 한 번 다시 보냈을 때 기록은 하나로 유지됐다. 이것은 그 한 가지 재시도만 통과했다는 관찰이지, 모든 중복이나 동시 요청이 안전하다는 보장이 아니다. 저장 유지, 중복 재시도, 사용자 분리는 서로 대신할 수 없는 세 결과다.

저장 완료 표시보다 먼저 물을 것

비개발자가 AI로 앱을 만들 때는 다음 세 질문을 그대로 사용할 수 있다.

• 어디에 저장됐나: 화면이나 이 브라우저에만 남은 것인지, 서버 저장소까지 간 것인지 구분해 달라고 요청했는가?
• 누가 저장을 확인했나: 앱의 완료 표시가 아니라 저장소를 직접 읽은 결과도 보여 달라고 요청했는가? 새로고침·브라우저 재시작·서버 재시작·코드 교체·배포 중 실제로 넘은 경계도 구분했는가?
• 누가 접근할 수 있나: 허용 사용자뿐 아니라 거부되어야 할 사용자도 시험했는가?

이번 로컬 앱에서는 제한된 생성·읽기·수정·삭제, 한 번의 동일 작업 재시도, 선택한 사용자 분리 경로, 오프라인 부정 확인, 로컬 서버 프로세스 재시작이 예상과 맞았다. 그보다 넓은 결론은 내리지 않는다. 화면의 완료 표시보다 강한 증거는, 어디에 남았고 누가 확인했으며 누가 볼 수 없는지를 경계별로 기록한 결과다.

이 글은 AI를 활용해 자료 조사와 초안 작성을 보조하고, 작성자가 직접 검증·편집했습니다.