망가지기 전 상태로 정확히 돌아갈 수 있을까?

여기서 돌아갈 곳은 미리 기록하고 확인한 복구점 T0다. 고장 직전까지 한 일을 모두 포함하지는 않는다. ‘정확히’는 지정한 코드·설정 파일 내용이 바이트 단위로 같고, 저장된 표의 구조와 모든 값, 정해 둔 동작이 기준과 맞는다는 뜻이다.

가상으로 만든 작은 할 일 목록에 결함 하나를 일부러 넣고, 두 복구 방식을 각각 두 번씩 한 차례 시험했다. 실제 사용자 사고나 AI가 우연히 만든 앱 결함을 재현한 것은 아니다. 코드만 되돌리면 잘못된 데이터가 남았고, 코드·데이터·설정을 함께 되돌리면 T0와 맞았지만 이후 정상 작업 두 건이 사라졌다. 성공률이나 일반 규칙을 밝힌 실험은 아니다.

이 글의 목차

공식 설명: 코드와 데이터의 복원 범위

Git restore는 지정한 원본에서 선택한 파일을 복원한다. 데이터베이스 파일을 Git에 함께 기록하는 프로젝트도 있으며, 제외 규칙도 이미 추적하는 파일에는 적용되지 않는다.

SQLite 백업 기능은 데이터베이스 사본을 만든다. integrity_check는 구조와 일부 제약 조건을 검사하며 외래 키 검사는 별도다. ok는 이 검사에서 문제가 없다는 뜻이다. 여기서 과거 값의 일치까지 보장하지는 않는다는 것은 검사 범위에 따른 해석이다. 위 문서의 확인일은 2026년 10월 5일이다.

이번 실험의 설계

이번 실험에서는 데이터·설정을 처음부터 Git 기록에서 제외하고, 스크립트가 관리하는 쓰기를 멈춰 함께 기록했다. SQLite 기록 방식은 delete였고 외부 프로세스의 쓰기까지 독립적으로 탐지한 것은 아니다. 실행 중인 DB 파일의 단순 복사는 진행 중인 변경 때문에 불완전할 수 있다. 이번에는 SQLite 백업 기능을 썼으며, 쓰기 중단은 이 실험의 조정 조건이지 그 기능의 보편적 필수 조건은 아니다.

기록된 관찰: 첫 시도 중단과 별도 재실행

2026년 9월 27일 한국 시간(UTC+09:00), macOS 27.0 arm64, Git 2.54.0, Python 3.9.6, SQLite 3.54.0에서 실행했다. Astra(Codex)가 실험 스크립트를 작성·실행했다. 로컬 가상 데이터·고정 스크립트로, 측정 중 모델 추론은 없었다. A는 코드만, B는 코드·데이터·설정을 복원하는 방식이다.

첫 시도는 읽기 전용 속성이 코드 사본에도 복사돼 결함을 넣기 전에 권한 오류로 멈췄다. 앱 복구 실패가 아니라 실험 스크립트의 준비 결함이다. 계획한 A·B 각 2회 중 실행은 각각 0/2회다. 정상 확인과 복원 연습은 각각 11/11개 검사를 통과했지만 고장 복구 결과는 아니다. 고장 상태·복구 시간·손실은 미측정이다. 절차를 고정하기 전, 편집 도구가 허용 폴더 밖 파일 생성을 1회 막았고 파일은 쓰이지 않았다. 다른 생성 방식으로 준비했다.

첫 시도는 재시도 없이 종료했다. 이후 사용자가 별도 2차 시도 한 번을 허용했고, 실행 전에 사본의 쓰기 권한 보정과 새 작업 공간을 기록했다. 앱·기대값·검사 규칙은 유지하고 첫 증거도 보존했다. 재실행에서도 정상 확인·복원 연습은 각각 11/11개 통과했다.

기록된 관찰: 2차 시도의 상태 변화

비교 범위는 app.py·.gitignore, tasks(id,title,done)의 표 구조와 번호순 전체 행, settings.json의 목록 제목·완료 항목 표시 설정이다. 0은 미완료, 1은 완료다.

4번 추가와 제목 변경은 정상 작업이다. ‘2번만 완료’의 대상 제한을 일부러 없애고 한 번 실행하자 네 행의 완료 값이 모두 1이 됐다. 2번은 요청한 대상이고 3번은 이미 완료 상태였으며, 1번·4번이 의도치 않게 바뀌었다. 고장 상태는 고장 대조 기록의 11개 검사 중 4개(표 구조·무결성·현재 목록 출력·현재 설정 출력)만 통과했지만 무결성 결과는 ok였다. 항목 이름과 완료 항목 표시 설정은 그대로였다.

기록된 관찰: 두 방식이 돌려놓은 것

복원 범위를 의도적으로 다르게 정한 비교다. 예상한 차이가 이 구현에서 실제로 나타나는지 확인했으며 방식의 우열을 가린 것은 아니다. 동일한 고장 상태의 새 사본에서 A1/B1/B2/A2 순서로, 각각 계획한 2/2회를 마쳤다.

11개 검사는 코드·설정·데이터 대조와 동작 확인을 묶은 것으로, 통과 개수는 복구율이 아니다. T0와 다른 정상 제목 수정도 불일치로 센다. A는 코드·표 구조·무결성·현재 목록/설정 출력·동작 검사에 통과했지만, 과거 행과 T0 설정/목록 대조에는 실패했다.

A는 두 번 모두 코드만 고쳤고 잘못된 완료 값은 남았다. A의 복원 과정이 새로 지운 것은 없었다. 다만 4번은 고장 때 이미 ‘완료’로 잘못 바뀐 채 남아 ‘온전히 보존’은 아니다. 제목 수정은 유지됐다.

B는 두 번 모두 지정한 코드·설정 파일의 바이트와 데이터 표 구조·번호순 전체 행이 T0와 맞았다. 동시에 정상 작업 두 건, 4번과 제목 수정이 사라졌다. 복구점 일치와 이후 작업 보존은 달랐다. 두 방식 모두 고장 직전의 정상 상태(네 항목의 값 0,0,1,0과 Demo v2)를 되찾지는 못했다.

동작은 별도 사본에 1·2번 미완료, 3번 완료인 (0,0,1)을 넣어 2번만 완료된 (0,1,1)이 되는지, 다시 열어도 같은지 확인했다. A·B 각 2/2회 통과했고 비교용으로 고치지 않은 결함 사본은 실패했다. 이 확인은 복원된 네 행이나 4번을 시험한 것이 아니며, 비교 대상인 복원 데이터 자체를 바꾸지 않았다. 동작 통과는 과거 데이터 복원과 다르다. 첫 시도의 백업은 논리 내용이 같아도 DB 파일 해시(내용 지문)가 달랐다. DB 파일 바이트 일치나 모든 미래 동작을 주장하지 않는다. 기대값은 앱 출력과 별도로 고정했지만 복원과 검증은 같은 스크립트가 수행했다. 독립 구현 검증기는 아니며, 원래 실행 사본 전체는 보관되지 않았다.

표와 이 문단의 시간은 자동 절차의 기록이다. 소수 여섯 자리로 반올림했고, 전체는 복원 시작검증 종료의 별도 측정이라 표시된 구간의 합과 끝자리가 다를 수 있다. 별도 사본 준비는 순서대로 0.007964·0.007863·0.009005·0.009480초, 자동 준비·저장·대조 검사는 0.314130초였다. T0결함도 0.077574초인 자동 실험이다.

첫 시도는 중단까지 시각 기록상 0.214146초였고 준비 합계는 미측정이다. 사람의 작업 시간·속도 우위를 뜻하지 않는다. 사본 준비 수치의 원자료는 시간 기록, 전체 경위는 실험 기록에 남겼다.

판단과 미검증 양식: 복구점 카드

내 판단으로는 무엇과 비교했고 무엇이 남거나 변하거나 사라졌는지 함께 적는 것이 중요하다. 아래 템플릿의 복구·손실 감소 효과는 미검증이다.

복구점 카드
기록 시각·시간대: ___ / 쓰기를 멈춘 범위: ___
코드 버전·위치: ___ / 설정 사본·위치: ___
데이터 사본·위치·해당 DB에 맞는 백업 방법: ___
무엇과 비교할지(앱 출력과 별도로 미리 저장한 기준): 파일 목록·내용, 표 구조·전체 값, 정해 둔 동작 ___
사본 복원 연습 결과: ___
이후 정상 작업과 잃어도 되는 범위: ___
복원 후 대조: 코드 ___ / 전체 데이터 ___ / 설정 ___ / 별도 사본의 동작 ___
남은·변한·사라진 작업: ___ / 확인하지 못한 것: ___

예를 들어 B는 ‘T0의 세 항목·Demo와 일치 / 이후 4번과 제목 수정은 사라짐’으로 적는다. 모르는 칸은 ‘모름’으로 둔다. 이후 작업의 값까지 남긴 근거가 없으면 이 비교만으로 손실을 확정할 수 없다. 항목이 있었다는 기록만으로는 변한 값을 놓칠 수 있다. 비교 결과·대조 검사·예정 범위가 맞지 않으면 멈춰 원인을 확인한다. 이 카드는 앱이 쓰고 있는 DB를 안전하게 백업하는 방법이나 서비스별 복구 절차를 대신하지 않는다.

한 기기·한 결함·방식별 두 번으로 신뢰도·최적 백업 간격·제품 및 모델 우열·생산성은 판단하지 못한다. 초보자 시간·사용성, 실제 비용·구독 잔여량·작성 모델 백엔드·CLI 버전은 미확인이다. 운영·호스팅·동시 쓰기·분산 환경, 데이터 구조 변경, 앱 밖 서비스로 이미 보낸 동작 되돌리기, 같은 디스크 고장으로 백업까지 잃는 경우, 정상적인 이후 작업만 골라 다시 적용하기도 미시험이다. 기존 완료 값의 정상 수정과 결함이 같은 값에서 충돌하는 경우도 시험하지 않았다. OS·파일 권한·파일 시각·미래 동작은 비교 밖이다. 검토 경위와 한계는 편집 회의 기록에 남겼다.

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