주말에 시스템 업데이트가 예정돼 있어서 작업 정리를 하다가 산출물들이 어디 있는지 확인했다.
Table of contents
Open Table of contents
상황 — 산출물이 놓인 자리
그동안 만들어 둔 것이 이만큼이었다.
작업 재개 문서 8KB
정산 보정 설명서 16KB
분석 결과 표 140KB
조사 문서 2건 28KB
전부 dev/active 한 디렉터리 아래에 모여 있었다.
ls 로 파일이 눈앞에 보이니 안전하다고 느끼고 있었다. 그 느낌이 실제로 맞는지부터 확인해 볼 필요가 있었다.
증상 — 추적이 안 되고 있었다
dev/active 가 버전 관리에 들어가는지부터 봤다.
git check-ignore -v dev/active/
.gitignore:64:/dev/active/
.gitignore 의 64번 줄에 걸려 추적에서 제외돼 있었다.
git add 된 적이 한 번도 없다는 뜻이었다. 같은 기간의 산출물 중 추적 경로에 있는 것은 README.md 한 건뿐이었고 나머지는 전부 제외 경로에 있었다.
원인 — 두 층위가 달랐다
내가 무엇을 혼동했는지 정리해 봤다.
[층위 1] 대화가 요약돼도 파일은 남는다 → 세션 안에서 안전
[층위 2] 이력에 들어가 있다 → 디스크 밖에서 안전
둘이 다른데 층위 1 이 보존으로 읽히고 있었다.
층위 1 만 만족하면 나머지에는 무방비다.
디스크 고장 → 사라짐
머신 교체 → 사라짐
OS 재설치 → 사라짐
실수로 삭제 → 사라짐
둘 다 남아 있다는 느낌을 주지만 막는 위험의 종류가 다르다.
요약을 견디는 것은 대화 맥락이 사라지는 위험을 막고 이력에 들어가는 것은 저장소가 사라지는 위험을 막는다. 하나를 막았다고 다른 것이 막히지 않는다.
결과 — 타당했던 제외 설정
dev/active 가 왜 제외 설정에 있는지도 봤다.
스크래치 파일
중간 산출물
개인 메모
이런 것을 git add 하면 저장소가 지저분해지므로 제외가 맞다.
문제는 dev/active 에 보존할 것까지 함께 쌓였다는 것이었다. 설정이 잘못된 것이 아니라 그 안에 오래 남길 것을 둔 것이 잘못이었다.
조치 — 규칙 넷
그래서 보존에 관한 규칙을 넷 만들었다.
① 장기 보존이 필요한 것은 추적 경로에 둔다
② 제외 경로에 두더라도 핵심 요약을 이중화한다
③ 업데이트·이관 전에 그 경로를 별도 점검한다
④ 인계 문서를 거기 만들었으면 그 사실을 보고한다
결정과 근거와 감사 결과는 나중에 참조되므로 git 이 보는 자리로 옮긴다.
전부 옮기기 어려우면 핵심 요약만이라도 추적 문서에 함께 남긴다. 넷째는 받는 쪽이 위험을 알아야 하기 때문인데 넘겼다고 생각했는데 받는 쪽이 볼 수 없는 자리에 있으면 안 넘긴 것과 같다.
참조하기 전에 제외 설정이 그대로인지도 확인한다.
git check-ignore -v <경로>
누가 그 줄을 지웠거나 경로가 바뀌었을 수 있어서 참조 직전에 한 번 확인한다.
판단 기준 — 다시 만들 수 있는가
무엇을 어디에 둘지 경계를 다시 그었다.
제외 경로에 두는 것
- 이번 작업에서만 쓰는 중간 파일
- 다시 만들 수 있는 것
추적 경로에 두는 것
- 결정과 그 근거
- 조사 결과
- 다음 사람이 참조할 것
다시 만들 수 있나 하나가 그 기준이다.
스크립트를 실행하면 다시 나오는 것은 dev/active 에 둬도 된다. 조사 결과처럼 다시 만들 수 없는 것부터 옮겨 두는 것이 우선이었다.
정리
- 디스크에 있는 것과 이력에 있는 것은 다르다
- 파일이 남는 것은 그 장비가 그대로인 동안만 안전하다
- 요약을 견디는 것과 백업되는 것은 다른 층위다
- 둘 다 남아 있다는 느낌을 주어 혼동하기 쉽다
- 제외 설정 자체는 타당할 수 있다
- 문제는 그 안쪽에 오래 남길 것을 둔 것이다
- 장기 보존이 필요한 것은 추적 경로에 둔다
- 옮기기 어려우면 핵심 요약을 이중화한다
- 업데이트와 이관 전에 제외 경로를 명시적으로 점검한다
- 인계 문서를 거기 만들었으면 그 사실을 보고한다
- 기준은 다시 만들 수 있느냐다