Skip to content
isdnetworks
Go back

남아 있는 것과 백업된 것

주말에 시스템 업데이트가 예정돼 있어서 작업 정리를 하다가 산출물들이 어디 있는지 확인했다.

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 에 둬도 된다. 조사 결과처럼 다시 만들 수 없는 것부터 옮겨 두는 것이 우선이었다.

정리


Share this post on:

Previous Post
실패한 것을 찾아 원인을 고치고 다시 돌렸다
Next Post
큰 테이블의 진입점