서버 없는 메모장에 백업과 복원이 꼭 필요했던 이유
코딩은 AI에게 맡겼습니다 · 시즌 1 / 14
2026년 7월 10일 v1.2.0에서는 백업·복원, 키보드 단축키와 시스템 글꼴을 추가했습니다. 네 개 파일에서 253줄을 추가하고 18줄을 삭제했습니다. 계정과 서버가 없다는 단순함을 유지하려면 사용자가 직접 데이터를 옮길 방법이 필요했습니다.
먼저 보는 핵심
로컬에 저장하면 외부 전송을 줄일 수 있지만, 데이터 유실까지 막아 주지는 않습니다. 확장 삭제, 저장소 손상, 기기 교체에 대비해 내보내기 형식, 검증, 병합 정책과 실패 시 원상 복구를 설계해야 합니다.
로컬 저장에도 백업이 필요한 이유
서버가 없으면 계정 유출과 운영 비용을 줄일 수 있습니다. 메모가 외부로 전송되지 않는다는 장점도 큽니다. 반대로 브라우저 안의 데이터에 문제가 생기면 운영자가 복구해 줄 사본이 없습니다.
일상적인 사용 중에도 다음과 같은 상황이 생길 수 있습니다.
- 확장 프로그램을 실수로 삭제한다.
- 새 컴퓨터로 이동한다.
- 브라우저 프로필을 초기화한다.
- 업데이트 중 데이터 형식이 바뀐다.
- 잘못된 복원 파일로 기존 메모를 덮는다.
사용자가 메모를 직접 보관하고 옮길 수 있도록 백업과 복원을 제품의 기본 기능으로 다뤄야 했습니다.
파일을 읽는 것과 안전하게 복원하는 것은 다르다
AI는 JSON 내보내기와 가져오기 코드를 빠르게 만들 수 있습니다. 복원에는 다음 정책이 더 필요합니다.
| 질문 | 가능한 선택 |
|---|---|
| 기존 데이터 처리 | 교체, 병합, 사용자 선택 |
| 중복 메모 | ID 기준, 내용 기준, 모두 유지 |
| 잘못된 파일 | 전체 거부, 유효 항목만 복원 |
| 버전 차이 | 마이그레이션, 읽기 전용 안내 |
| 실패 시 상태 | 변경 전 스냅샷으로 되돌리기 |
가장 위험한 구현은 파일을 읽자마자 기존 저장소를 지우는 방식입니다. 먼저 메모리에서 전체 구조를 검증하고, 복원 계획을 보여 준 뒤, 한 번에 적용해야 합니다.
백업 파일에 버전을 넣기
파일에는 메모 배열만 넣기보다 형식과 생성 정보를 함께 넣는 것이 좋습니다.
{
"format": "simple-side-note-backup",
"version": 1,
"exportedAt": "2026-07-10T00:00:00Z",
"notes": []
}
이 정보가 있으면 다른 JSON 파일을 실수로 불러오는 일을 줄이고, 다음 버전에서 변환 경로를 만들 수 있습니다.
AI에게 실패 테스트도 만들게 했다
정상 백업 한 번만 복원하면 충분하지 않습니다. 빈 파일, 잘린 JSON, 필수 필드 누락, 지나치게 큰 이미지, 중복 ID, 미래 버전 파일을 각각 시험해야 합니다.
AI는 구현뿐 아니라 오류를 일으킬 수 있는 테스트 입력을 만드는 데도 도움이 됐습니다. 복원에 실패했을 때 기존 메모가 유지되는지까지 확인하는 것이 중요했습니다.
다음 편
제품 기능은 준비됐지만 스토어에 올릴 파일은 따로 남아 있었습니다. 다음 편에서는 코드가 아닌 이미지와 설명 파일 23개가 왜 출시를 막았는지 다룹니다.
댓글
댓글 쓰기