끊겼다 다시 연결돼도 내 기록은 남을까?

체크 표시가 남아 있어도 서버 반영을 확인한 것은 아니다. 이번에는 저장·재전송 구조를 미리 지정해 AI로 만든 합성 체크리스트 하나를 시험했다. 같은 Mac의 시험용 서버를 멈춘 여섯 사례(A1–A3, B1–B3) 모두에서 세 변경이 앱 다시 열기와 기록을 지우지 않는 v2 업데이트 뒤 기기에 남았고, 최종 시험 서버 기록도 일치했다. 대기 중인 채 업데이트한 것은 B뿐이다. 완료 문구가 정확한 순간에 떴는지는 확인하지 못했다.

개념 일러스트이며 실제 시험 화면이나 동기화 성공의 증거가 아니다.

2026년 10월 8일, Mac 한 대에서 화면 창 없이 실행한 Chrome 탭으로 시험했다. 끊은 것은 같은 Mac의 시험용 서버였다. Wi-Fi나 인터넷을 끄지 않았고, 설치형 웹앱도 시험하지 않았다. 결과는 기준별 관찰이며 성공률이나 실제 서비스·모바일·여러 기기의 신뢰성 판정이 아니다.

이 글의 목차

출처로 보는 구분: 연결됨과 전달됨

MDN의 연결 상태 설명에 따르면 브라우저는 여러 단서로 온라인 여부를 판단하며, 인터넷에 닿지 않는 근거리망 연결도 온라인으로 볼 수 있다. 온라인 표시는 특정 서버의 수신 증명이 아니다.

IndexedDB 문서는 브라우저 안에 구조화된 데이터를 저장하는 기능을 설명한다. 기기 안의 저장 기능 자체가 서버의 수신 확인을 제공하는 것은 아니다.

기록된 관찰: 먼저 보내거나, 기다린 채 업데이트하거나

앱에는 기기 저장소와 전송 대기 목록, 재시도 때 유지할 작업 번호, 수신 확인, 기록을 보존하는 업데이트 구조를 미리 지정했다. 서버에도 같은 작업을 다시 받아도 한 번만 반영하는 장치를 제공했다. AI가 스스로 이런 구조를 발견했는지 평가한 실험이 아니다. 이 실험은 화면, 기기 저장소, 서버 기록을 각각 대조했다. 서버를 멈춘 모든 확인 시점에도 브라우저의 온라인 값은 참이었다.

매번 새 브라우저 시험 프로필과 데이터베이스의 10항목을 서버가 켜진 상태에서 열었다. 서버를 멈춘 채 앱을 닫았다 다시 연 뒤, 02번 체크 → 05번에 우산 / umbrella 입력 → 09번 체크 순서로 고쳤다. 다시 열어 기기에 세 변경과 대기 작업이 남는지 확인했다. 한·영 문구가 섞인 같은 앱을 사용했으며 언어별 실험은 아니다.

• A1–A3: 서버를 정상 재시작해 전송을 마친 다음 v2로 업데이트했다.
• B1–B3: 화면 파일은 제공하되 기록 전송은 거절하는 상태(HTTP 503)로 재시작했다. 세 작업을 대기시킨 채 v2로 업데이트한 뒤 전송을 허용했다. 전송 허용과 동시에 첫 작업인 02번 체크는 서버에 반영하고 응답만 끊도록 설정했다. 실제 응답 없는 실패와 별도 재시도가 나타난 것은 B1·B3뿐이다.

v2의 변경은 화면의 버전 표시와 기록을 지우지 않는 선택적 태그용 저장소 인덱스 추가였다. 서버와 주고받는 규칙은 그대로였다. v2를 내려받아 대기하는 동안 현재 버전은 v1이었다. 앱 탭과 저장소를 읽기만 하는 별도 확인 페이지를 닫고 다시 열자 화면·실행 코드·저장 구조가 v2에 맞게 바뀌었다. B에서는 그때도 세 변경이 기기에 남고 서버 확인을 기다렸다.

아래는 고정된 기준별 판정이다. ‘통과’는 해당 기준만 충족했다는 뜻이며 성공률로 합산하지 않는다. ‘미도달’은 해당 기준을 판정할 상황이 생기지 않음, ‘미검증’은 판정 근거 부족이다. B2의 통과 항목은 앱에 드러난 응답 유실 뒤 복구를 입증하지 않는다. 해당 조건의 예외는 다음 절에서 설명한다.

B2: 서버에는 응답 차단 뒤 중복 처리 기록이 있지만 브라우저에는 정상 응답 하나만 보였다. 해당 응답 차단에 대한 별도 재시도나 앱이 감지한 응답 유실 뒤 복구를 뜻하지 않는다. 작업 번호 재사용 판정에는 그보다 앞선 실패·전송 거절 때의 재시도도 포함된다. 값·화면 최신성은 체크리스트 값과 항목 수의 2초 기준이며 완료 문구의 정확성과 별개다. 설치는 시도하지 않아 미검증이다.

최종 기록은 각 사례에서 10항목, 의도한 세 변경, 작업별 반영 한 번, 대기 0건이었다. 나머지 일곱 항목도 유지됐다. A에는 서버의 중복 처리 사건이 없었다. 요청 반복 자체는 중복 반영이 아니며, 서버 장치가 기여한 정도는 따로 측정하지 않았다. 이 보존 판정은 해당 프로필의 짧은 다시 열기와 호환 업데이트에 한정되며 백업 증명이 아니다. 사이트 데이터 삭제·저장 공간 부족에 따른 브라우저의 데이터 정리·충돌·전원 상실은 시험하지 않았다. 화면·문구 2초, 자동 복구·버전 활성화 30초는 이 실험의 기준이지 표준이 아니다.

확인하지 못한 순간도 결과다

한·영 병기 화면의 한국어 문구는 ‘이 기기에 저장됨 · 전송 대기 3건’에서 ‘서버에 반영됨’으로 바뀌었다. 문구 정확성은 모든 사례에서 미검증이다. 첫 완료 문구보다 기기의 빈 대기 목록을 독립적으로 읽은 시점이 A1·A2·A3에서 각각 60·42·11밀리초, B1·B2·B3에서 42·30·51밀리초 늦었다. 직전 기기 확인에는 여전히 대기 작업이 있었다. 기록된 네트워크 응답 시각은 첫 완료 문구 캡처보다 앞서지만, 그 순간 기기의 대기 목록도 비었는지는 별개다. 거짓 완료 표시를 발견한 것도, 정확했다고 입증한 것도 아니다.

측정 전 점수에 넣지 않은 시험 실행인 보정을 두 번 했다. 응답 차단이 의도대로 드러나지 않은 경우도 있었다. 보정 1과 B2에서는 서버가 응답을 끊었는데 브라우저 관찰에는 한 요청의 정상 응답으로 나타났다. 이는 시험 장치의 관찰이다. 보정 1은 앱 아래의 브라우저 통신 계층이 재시도했을 가능성으로 강하게 설명되지만, 정확한 소켓 원인은 입증되지 않았다. 보정 1과 B2 모두 앱이 감지한 응답 유실 뒤 복구 성공으로 셀 수 없다.

측정 전에 시험 서버의 연결 종료 방식을 바꿨다. 앱의 동작과 채점 규칙은 그대로였다. 보정 2에서 조건을 확인하고 시험 파일을 고정했지만, B2에서는 다시 정상 응답으로 보였다. 보정 통과가 이후 모든 사례의 응답 유실을 보장하지 않았다. B1·B3은 응답 없는 실패 뒤 같은 번호의 별도 재시도와 한 번의 서버 반영을 확인했다. B2는 위 개별 판정을 유지하되 계획한 ‘앱에 드러난 응답 유실’ 비교에는 무효다. 그 조건은 미완성이며 보정 사례로 채우지 않았다.

작성자 판단: ‘여기 저장’과 ‘저기 확인’을 적어 두자

서버가 멈춘 동안에는 세 변경이 서버에 없었다. 반면 B1·B3의 첫 작업은 서버에 반영된 뒤에도 답장을 받지 못해 기기에서 대기 중이었다. 이 앱도 이미 기기 저장과 서버 확인을 나눠 표시했지만, ‘전송 대기’만으로는 이 차이가 드러나지 않았다. 작성자는 저장 위치·서버 반영·답장 확인을 나눠 적어 보기를 제안한다. 아래는 개인정보 없는 합성 자료를 쓰는 시험용 앱의 관찰 카드이며 실제 계정의 기록을 재전송하는 절차가 아니다. 효과나 초보자 이해도를 검증한 도구는 아니다.

실제 연결 장애 조건 / 시각:
개인정보 없는 시험 메모 / 체크 / 처음 항목 수:
입력 직후 문구 / 대기 건수:
같은 앱을 닫고 다시 연 뒤 값 / 문구 / 항목 수:
연결 회복 뒤 값 / 문구 / 항목 수:
업데이트를 거쳤다면 전후 화면의 대기 건수:
기기에 남음: 관찰 내용 또는 모름
서버에 반영됨: 앱 화면과 별개로 확인한 서버 기록 또는 미검증
서버 답장 확인: 관찰 내용 또는 모름
제작자에게 근거와 함께 물을 것:
  대기 기록은 어디에 남나? 무엇으로 수신을 확인하나?
  재시도에 같은 번호를 쓰나? 업데이트 때 대기 기록은 어떻게 남나?

화면과 항목 수만으로 서버의 중복 반영까지 확인할 수는 없다. 화면만 볼 수 있다면 카드의 서버 반영란은 미검증으로 남긴다. 제작자의 설명도 독립 증거를 대신하지 않는다. Wi-Fi를 끄거나 다른 기기에서 기록한 결과는 이번 실험과 다른 조건이다.

미측정·미확인 범위는 다음과 같다.

• 환경: 설치·독립 실행 모드, 창이 보이는 같은 Chrome, 모바일·다른 브라우저, 실제 무선·인터넷 단절과 Wi-Fi 로그인 화면. 보정 1의 통신 계층 설명을 이 환경들로 넓힐 수 없다.
• 앱 동작: 수동 복구, 첫 완료 순간, B2의 의도한 응답 유실, 앱 종료 뒤 전송, 여러 기기·사용자·탭의 충돌.
• 보존·운영: 장기 보존·브라우저의 저장 데이터 정리, 백업 복구, 충돌·전원 상실 내구성, 보안·권한 격리, 실제 서비스 운영 준비와 호스팅 업체 성능.
• 일반화: 지정하지 않은 작업 번호 생성 방식, 중복 방지 없는 서버, AI 제작 도구의 일반 능력·앱 집단의 신뢰성, 관찰 카드의 효과와 독자 이해도.

환경은 macOS 27.0 build 26A428, Chrome 155.0.8059.39(기록된 사용자 에이전트: HeadlessChrome/155.0.0.0), Playwright Core 1.62.1이다. Codex/Astra AI 코딩 세션으로 제작했지만 실제 응답 모델의 별도 증명과 토큰 사용량은 없다. 검증 담당은 제작 뒤 배정됐다. 실행은 조정 담당이 했고, 별도 실험 기록 담당은 저장된 자료를 재채점했다. 이 재채점은 재실행이 아니며, 늦은 검증 담당 배정이 제작 당시의 독립 검증을 뜻하지도 않는다. 화면 해석은 Codex의 편집 판단이다. 버전·입력·측정 전 고정한 파일과 원자료 경로는 별도로 보관한 실험 기록에 남겼다.

여섯 사례의 첫 시작부터 마지막 종료까지 측정 구간은 약 84초였다. 새 실험 비용은 0원이었다. 기존 구독료가 무료라는 뜻은 아니다. 전체 노동 시간, 검토·집필 시간과 정확한 사용량별 비용은 확보하지 못했다. 이 기록으로 제안할 수 있는 것은 자기 앱에서 ‘어디에 남았는지’를 묻는 습관이며, AI 앱이나 프로그레시브 웹앱(PWA) 전반의 신뢰성 보증은 아니다.

이 글은 AI를 활용해 자료 조사와 초안 작성을 보조했으며, 작성자가 최종 원고를 검토하고 수정 방향을 결정했습니다.