브라우저에 저장한 메모가 사라질 수 있을까

브라우저 안의 저장과 별도 보존을 구분하는 AI 생성 개념 이미지입니다.

브라우저에만 있는 중요한 자료는 저장 유지 조건을 확인하고 별도 내보내기나 동기화 경로를 확보하세요.

메모를 쓰고 탭을 닫았다가 다시 열었는데 내용이 남아 있습니다. 이 경험만으로 “이제 계속 보관된다”고 생각하기 쉽습니다. 하지만 브라우저 내부 저장은 다운로드 폴더에 직접 저장한 파일이나 서버 백업과 보관 조건이 다릅니다. 저장에 성공했다는 것과 다른 기기에서도 복구할 수 있다는 것은 별개입니다.

이 글은 브라우저 메모를 쓰는 사람과 그런 앱을 만드는 개발자가 함께 확인할 수 있는 순서로 정리했습니다. 2026년 9월 13일 MDN 문서 기준이며, 실제 사용자 자료를 삭제하거나 손실 확률을 측정한 글은 아닙니다. 코드도 저장 상태를 읽는 설명용 예시로, 실행 결과를 제시하지 않습니다.

먼저 메모가 있는 브라우저와 주소를 확인합니다

브라우저는 보통 출처인 origin을 기준으로 사이트 저장 공간을 나눕니다. 여기서 origin은 주소의 스킴, 호스트, 포트 조합입니다. https://notes.example과 http://notes.example은 같은 이름처럼 보여도 서로 다른 origin입니다. 같은 HTTPS 주소라도 포트가 다르면 구분됩니다.

반면 같은 origin의 /memo와 /draft는 경로만 다릅니다. 경로가 달라졌다고 브라우저 저장 영역까지 자동으로 따로 생기는 것은 아닙니다. 다만 다른 사이트 안에 삽입된 콘텐츠 등에서는 추가 분리가 적용될 수 있습니다. 모든 환경이 한 가지 규칙으로만 저장된다고 단순화하지는 않습니다. 사이트별 저장 공간의 구분

사용자가 실제로 메모를 찾을 때는 주소만큼 브라우저 프로필도 중요합니다. 원래 쓰던 프로필이 아닌 곳에서 빈 메모장이 열렸다고 해서 원본이 삭제됐다고 단정할 수 없습니다. 앱에 자체 계정 기능이 있다면 로그인한 계정도 확인합니다. 브라우저 계정에 로그인했다는 사실만으로 개별 웹앱의 메모가 서버에 동기화된다고 생각해서는 안 됩니다.

따라서 메모가 안 보일 때 첫 조치는 사이트 데이터 삭제가 아닙니다. 원래 브라우저·프로필·주소·앱 계정을 확인하고, 아직 내용이 보이는 탭이나 기기가 있다면 앱이 제공하는 내보내기 또는 복사로 별도 사본부터 확보합니다.

기본 저장과 영구 저장은 무엇이 다를까요

IndexedDB처럼 브라우저가 관리하는 저장소는 기본적으로 best-effort 방식입니다. 저장 공간 부족 등 브라우저의 정리 조건에 따라 자료가 제거될 수 있습니다. 비공개 탐색의 자료도 보통 해당 탐색 세션이 끝나면 지워지므로, 중요한 원본을 계속 보관할 장소로 가정하기 어렵습니다.

앱은 navigator.storage.persist()로 persistent 저장을 요청할 수 있습니다. 허용된 저장 영역은 브라우저의 자동 공간 정리로부터 보호되지만, 사용자가 사이트 데이터를 지우거나 기기 자체를 잃어버리는 문제까지 해결하지는 않습니다. 기본 보관과 자동 제거 조건

이때 “영구”라는 한국어가 보장 범위를 크게 느끼게 합니다. 실무에서는 “브라우저 자동 정리 대상에서 보호되는 저장 모드”라고 풀어 읽는 편이 정확합니다. 별도 서버에 사본을 만들거나 고장 난 디스크를 복구하는 기능이 아닙니다.

요청 자체도 승인과 다릅니다. persist()는 비동기로 동작하며, 브라우저 판단에 따라 결과가 true 또는 false로 결정됩니다. 호출했다고 무조건 허용되는 것은 아닙니다. 보안 컨텍스트와 브라우저 지원 조건도 확인해야 합니다. persist()의 요청과 반환값

개발자라면 현재 상태부터 읽어 봅니다

아래는 앱이 자신의 origin에서 저장 상태를 표시하는 함수를 설계한 예시입니다. 메모 본문을 읽거나 삭제하지 않고, persistent 상태와 사용량 추정치를 요청합니다. 저장 권한을 새로 요청하는 persist()도 호출하지 않습니다. 알 수 없는 값은 0으로 바꾸지 않습니다.

async function readStorageStatus() {
  const manager = navigator.storage;
  if (!manager?.persisted || !manager?.estimate) {
    return { state: "unsupported" };
  }

  try {
    const [persistent, estimate] = await Promise.all([
      manager.persisted(),
      manager.estimate(),
    ]);
    const nonNegativeNumber = value =>
      Number.isFinite(value) && value >= 0 ? value : null;

    return {
      state: "available",
      persistent,
      usageBytes: nonNegativeNumber(estimate.usage),
      quotaBytes: nonNegativeNumber(estimate.quota),
    };
  } catch (error) {
    return {
      state: "unavailable",
      reason: error instanceof Error ? error.name : "UnknownError",
    };
  }
}

persisted()는 현재 저장 영역의 persistent 여부를 알려 줍니다. false라면 해당 보호 모드가 아니라는 뜻이지, 지금 메모가 사라졌거나 곧 사라진다는 뜻은 아닙니다. API를 지원하지 않거나 접근할 수 없다는 응답도 실제 메모 개수와는 관계가 없습니다. persisted()의 의미

estimate()의 사용량과 할당량은 추정치입니다. 디스크의 실제 남은 공간을 정밀하게 잰 값이 아니며, 앱의 특정 메모 파일 크기만 나타내지도 않습니다. 반환값이 없는데 0으로 표시하면 “사용량 없음” 또는 “남은 공간 없음”이라는 잘못된 결론을 유도할 수 있습니다. 위 예시가 미확인을 별도로 남기는 이유입니다. estimate()의 근사값과 한계

이 함수만 붙여도 백업 기능이 생기는 것은 아닙니다. 사용자는 상태를 알 수 있게 되고, 개발자는 별도 저장 경로를 안내할 근거를 얻습니다. 진단 화면에 “백업 완료” 대신 “이 브라우저 저장 상태”라는 제목이 어울리는 이유도 여기에 있습니다.

‘저장됨’은 어느 단계가 끝났다는 뜻일까요

가상의 메모 앱에 회의 준비라는 제목과 세 줄 본문을 입력한다고 해 보겠습니다. 입력칸에 글자가 보이는 상태, 브라우저 저장소에 쓰기가 끝난 상태, 서버에 동기화된 상태를 각각 나눠야 합니다. 첫 단계만 성공했는데 초록색 저장 완료 표시를 띄우면 탭을 닫는 순간 사용자의 기대와 실제 보관 상태가 어긋납니다.

IndexedDB를 쓴다면 개별 쓰기 요청이 성공한 시점뿐 아니라 트랜잭션이 완료됐는지를 봅니다. MDN의 complete 이벤트는 트랜잭션이 성공적으로 커밋됐을 때 발생하는 이벤트입니다. 앱은 실패나 중단도 처리하고, 로컬 저장 완료와 서버 동기화 완료를 서로 다른 상태로 보여 줄 수 있습니다. IndexedDB 트랜잭션 완료 이벤트

이벤트 하나가 모든 고장 상황에서의 복구를 보장한다는 뜻은 아닙니다. 다만 아직 완료되지 않은 작업을 완료라고 표시하지 않는 출발점입니다. 화면에 “로컬 저장됨, 서버 동기화 대기”라고 나와 있다면 사용자는 지금 탭을 닫아도 되는지와 다른 기기에서 볼 수 있는지를 따로 판단할 수 있습니다.

쓰기 실패 때는 입력 중인 본문을 화면에서 지우지 않고, 재시도와 복사·내보내기 같은 선택지를 제공하는 편이 좋습니다. 용량 초과 오류를 받았다고 기존 자료를 자동으로 지워 공간을 만드는 것은 별도의 데이터 보존 결정입니다. 사용자가 무엇이 지워지는지 모르는 정리 기능으로 처리하면 안 됩니다.

같은 메모로 보관과 복구를 따로 확인합니다

앞의 가상 메모를 시험 자료로 삼아 다음 순서로 앱을 점검할 수 있습니다. 실제 중요한 원본 대신 버려도 되는 내용을 쓰는 검사 설계입니다.

1. 제목과 본문을 입력하고 앱의 로컬 저장 완료 표시를 확인합니다.
2. 같은 브라우저·프로필·주소에서 페이지를 다시 열어 제목과 본문이 남아 있는지 대조합니다.
3. 앱의 내보내기로 별도 파일을 만들고, 파일명만 보지 말고 실제 텍스트와 필요한 자료가 포함됐는지 확인합니다.
4. 원본을 지우지 않은 채 분리된 시험 환경에서 지원되는 가져오기 절차를 확인합니다.
5. 동기화를 제공하는 앱이라면 다른 기기의 같은 앱 계정에서 마지막 수정 내용까지 보이는지 확인합니다.

2번은 재진입 확인이고 4번은 별도 사본의 복구 확인입니다. 두 검사는 서로 대신할 수 없습니다. 또한 5번에 성공해도 삭제까지 동기화되는 서비스라면 과거 버전을 되찾는 기능이 있는지 별도로 살펴야 합니다. 동기화와 독립적인 백업의 역할이 다른 이유입니다.

내보낸 파일이 보기 전용 텍스트라면 메모 본문은 살릴 수 있어도 앱의 폴더·태그·첨부까지 그대로 복원하지 못할 수 있습니다. 이를 실패라고 부를 필요는 없지만 보존한 범위를 정확히 알아야 합니다. “본문은 보관, 첨부와 분류는 별도 확인”처럼 기록하면 다음 작업이 분명해집니다.

이미 메모가 사라졌다면 무엇부터 멈춰야 할까요

브라우저 초기화, 앱 재설치, 사이트 데이터 삭제부터 반복하지 않습니다. 남아 있을 수 있는 로컬 자료와 진단 단서를 더 줄일 수 있습니다. 우선 원래 환경을 확인하고, 다른 기기에서 내용이 보인다면 변경 사항이 전파되기 전에 가능한 범위에서 별도 사본을 확보합니다.

이후 앱이 제공하는 휴지통·버전 기록·서버 동기화 상태를 확인합니다. 브라우저 내부에만 있던 자료가 실제로 삭제됐고 독립된 사본도 없다면, 이 글의 상태 조회 코드로 복구할 수는 없습니다. 복구 가능성은 저장 방식과 남은 자료에 달려 있으며 여기서는 확인할 수 없습니다.

고객 지원에 문의할 때도 메모 본문 전체를 보내기보다 사용 브라우저, 프로필 변경 여부, 앱 주소, 마지막으로 내용이 보인 시점, 표시된 오류부터 전달합니다. 개인정보가 들어 있는 저장소 덤프를 공개 게시판에 올리는 방식은 피합니다.

중요한 메모라면 브라우저 밖 사본 하나를 먼저 만듭니다

브라우저 저장 기능 자체가 쓸모없거나 항상 불안정하다는 결론은 아닙니다. 오프라인 편집과 빠른 재진입에 유용하지만, 사용자가 기대하는 보관 기간과 복구 범위를 앱이 실제로 제공하는지 확인해야 합니다.

지금 할 수 있는 가장 작은 확인은 중요한 메모 하나를 내보내고 파일을 직접 열어 보는 일입니다. 개발자라면 여기에 저장 실패 처리, 로컬·서버 상태 구분, 복구 가능한 내보내기 경로를 연결합니다. persistent 허용 여부는 그중 한 조건이며, 중요한 내용이 다른 곳에서도 살아 있는지를 확인하는 절차까지 대신하지는 않습니다.