서버 없는 메모장에 백업과 복원이 꼭 필요했던 이유

코딩은 AI에게 맡겼습니다 · 시즌 1 / 14

2026년 7월 10일 v1.2.0에서는 백업·복원, 키보드 단축키와 시스템 글꼴을 추가했습니다. 네 개 파일에서 253줄을 추가하고 18줄을 삭제했습니다. 계정과 서버가 없다는 단순함을 유지하려면 사용자가 직접 데이터를 옮길 방법이 필요했습니다.

먼저 보는 핵심
로컬 저장은 외부 전송을 줄이지만 자동으로 안전해지는 것은 아닙니다. 확장 삭제, 저장소 손상, 기기 교체에 대비해 내보내기 형식, 검증, 병합 정책과 실패 시 원상 복구를 설계해야 합니다.

로컬 우선의 반대편

서버가 없으면 계정 유출과 운영 비용을 줄일 수 있습니다. 메모가 외부로 전송되지 않는다는 장점도 큽니다. 반대로 브라우저 안의 데이터에 문제가 생기면 운영자가 복구해 줄 사본이 없습니다.

사용자가 마주칠 수 있는 상황은 현실적입니다.

백업은 부가 기능이 아니라 로컬 우선 제품의 책임 일부였습니다.

AI는 JSON 내보내기와 가져오기 코드를 빠르게 만들 수 있습니다. 복원에는 다음 정책이 더 필요합니다.

가장 위험한 구현은 파일을 읽자마자 기존 저장소를 지우는 방식입니다. 먼저 메모리에서 전체 구조를 검증하고, 복원 계획을 보여 준 뒤, 한 번에 적용해야 합니다.

파일에는 메모 배열만 넣기보다 형식과 생성 정보를 함께 넣는 것이 좋습니다.

{
  "format": "simple-side-note-backup",
  "version": 1,
  "exportedAt": "2026-07-10T00:00:00Z",
  "notes": []
}

이 정보가 있으면 다른 JSON 파일을 실수로 불러오는 일을 줄이고, 다음 버전에서 변환 경로를 만들 수 있습니다.

정상 백업 한 번만 복원하면 충분하지 않습니다. 빈 파일, 잘린 JSON, 필수 필드 누락, 지나치게 큰 이미지, 중복 ID, 미래 버전 파일을 각각 시험해야 합니다.

AI가 구현 속도를 높인 만큼 실패 입력도 쉽게 만들 수 있습니다. 이때 생성 능력을 기능 추가가 아니라 파괴적인 입력을 만드는 데 사용하는 것이 효과적이었습니다.

제품 기능은 준비됐지만 스토어에 올릴 파일은 따로 남아 있었습니다. 다음 편에서는 코드가 아닌 이미지와 설명 파일 23개가 왜 출시를 막았는지 다룹니다.