히스토리, 복구와 문제 해결

복구는 마지막에 붙이는 문제 해결 절이 아니라 문서를 자산으로 신뢰하기 위한 핵심 기능이다. 이 장은 저장 완료의 의미, 외부 편집 충돌, 비정상 종료 recovery snapshot, 문서·Binder history와 rollback을 하나의 흐름으로 설명한다.

먼저 구분할 것

상황	우선 행동	보존 목표
디스크 파일이 외부에서 변경됨	원본 다시 불러오기·내 버전 유지·사본 저장 비교	두 버전 중 하나를 조용히 잃지 않기
닫기 전에 변경이 남음	저장·사본 저장·변경 버리기 선택	사용자의 명시적 결정
비정상 종료 뒤 recovery 발견	원본과 snapshot diff 확인	최신이라는 이유만으로 자동 덮어쓰기 금지
과거 변경을 되돌림	문서 diff 또는 Binder staging 검토	복원 전 현재 상태와 rollback journal 보존

연속 복구 예제

1. Glif에서 project-brief.md를 수정하되 저장하지 않는다.
2. 외부 편집기에서 같은 파일의 다른 문장을 바꾼다.
3. 충돌 화면에서 원본 다시 불러오기, 내 버전 유지와 사본 저장의 예상 결과를 비교한다.
4. 사본 저장을 선택해 두 내용을 모두 보존한다.
5. History에서 변경 시점을 day/week/month로 묶어 찾고 diff를 연다.
6. 한 section을 복원한 뒤 최근 복원을 다시 되돌린다.

상세 가이드

• 외부 변경 재조정과 충돌 처리: 시작 시 Scope 재조정, 열린 문서의 외부 변경, 충돌 없는 선택과 사본 보존
• History 타임라인과 기간별 변경 분포: 최근 변경, 일·주·월 그룹, 문서 diff와 안전한 복원

Binder 복원

Binder 전체 복원은 여러 파일을 즉시 덮어쓰는 단일 copy가 아니다. staging에서 변경 목록을 검토하고 journal을 만든 뒤 적용한다. 일부 파일이 실패하면 성공한 경로와 남은 경로를 구분하고 rollback 결과를 확인한다.

기능별 문제 해결 색인

• 첫 시작 문제 해결
• Kanban 문제 해결
• 문서 저장·닫기·복구
• 히스토리와 복원

오류를 catch하고 빈 결과로 바꾸는 방식은 복구가 아니다. 실패한 대상, 보존된 데이터, 다시 시도할 action과 diagnostic 위치를 함께 제시한다.

실제 복구 증거

복구는 “이전 상태로 돌아갔다”는 toast가 아니라 현재 diff와 보존된 경로를 확인하는 절차다.

복구 실행 순서

1. 현재 원본과 열린 editor의 저장 상태를 기록한다.
2. 충돌 원본, recovery snapshot 또는 history revision을 선택한다.
3. diff에서 추가·삭제·충돌 줄을 확인한다.
4. 원본 다시 불러오기, 내 버전 유지, 사본 저장 또는 section 복원 중 하나를 명시적으로 고른다.
5. 적용 전 journal과 rollback 경로가 생성되는지 확인한다.
6. 적용 후 파일 hash, 문서 화면과 Binder 결과를 다시 연다.
7. 필요하면 방금 복원을 다시 되돌려 복구 가능성을 확인한다.

절대 하지 않을 것

• 최신 snapshot이라는 이유만으로 현재 원본을 자동 덮어쓰기
• 충돌 파일을 성공처럼 숨기기
• Binder 전체를 확인 없이 한 번에 덮어쓰기
• rollback 실패 경로를 빈 결과로 바꾸기
• history 화면의 diff를 실제 파일 저장 완료로 오인하기

이 장의 완료 기준

• 외부 변경과 local unsaved 변경을 구분했다.
• 복원 전 diff와 journal을 보존했다.
• section 복원과 전체 Binder 복원의 범위를 구분했다.
• 적용 후 source·profile·publish 결과를 재검증했다.
• 실패한 경로와 재시도 action을 기록했다.