GitHub 저장소를 세 계열로 갈라 전수로 확인해 전부 0건을 세고, 8일 구간을 원천 부재로 닫았다.
석 달 가까이 그 판정을 그대로 두었다.
같은 구간을 덮는 당대 1차 기록은 세 곳에 통째로 남아 있었고, 세 곳 모두 내가 조사한 목록 밖이었다.
문제
부재 판정에는 근거가 있었다.
확인 대상은 내 계정에 있는 업무 저장소였다. 2026-06-11 이후 구간에서 PR 0건, 커밋 0건, 이슈 0건이다.
메모리 뱅크는 커버리지 구간인 2026-07-24부터 08-30까지의 저장 태그 43종을 훑었고 해당 계열이 없었다.
숫자는 지금 다시 세도 같다. 세 계열도 태그 목록도 실제로 비어 있었고, 그 전수 확인 자체는 틀리지 않았다.
문제는 그 다음 문장이었다.
판정문에 적힌 것은 "1차 기록은 어느 기기에도 없다"였고 뒤에 "구술만이 유일한 경로다"가 붙었다.
확인한 것은 저장소 세 계열과 뱅크 하나인데 판정은 기기 전체로 넓어졌다.
넓어진 자리에 조사 범위를 적어둔 문장은 어디에도 없었다.
사료는 세 곳에 통째로 있었다
2026-08-31에 같은 구간을 다시 조사했다.
이번에는 내가 통제하지 않는 표면부터 열었다. 회사 시스템과 클라우드 사본이다.
1차 기록이 나온 곳은 셋이다. 회사 전자결재 시스템, 개인 Google Drive 미러, 회사 Google Drive 폴더.
전자결재에 상신되고 승인된 일일업무보고가 13건 남아 있다. 2026-05-19부터 06-11까지 문서번호와 결재선과 승인 시각이 찍힌 원문이고, 개인 클라우드 미러에 인쇄본 12건이 별도로 보존돼 있다.
그중 8일 구간 안에 상신일이 든 것은 4건이다. 6월 2일, 4일, 5일, 9일.
같은 구간을 사내 메신저 자동 저장 로그가 다른 면에서 덮는다. 12파일에서 중복을 뺀 고유 메시지 386건이고 구간 안에서 5일치가 걸린다.
여기에 당사자가 종료 직전에 네 계열을 교차 대조해 만든 인수인계서 부록의 업무 연대기가 같은 구간을 일자별 표로 재구성해 둔 상태였다.
보고서가 없는 날도 비어 있지 않았다.
8일 구간의 결번 2일은 지방선거 임시공휴일과 휴무일로 사유가 확정된다.
재직 구간 전체로 넓히면 일일보고 결번일이 5일인데, 그중 4일은 회사 Google Drive 폴더의 파일 수정 시각에 그날의 산출물이 남아 있다.
두 계열이 모두 비는 하루가 휴무일이고, 그 사유는 인수인계서 각주에 당대 기록으로 적혀 있다.
같은 세션에서 판정 세 건이 뒤집혔다
같은 세션에서 부재와 결손 판정 세 건이 함께 갱신됐다. 성격은 서로 다르다.
| 판정 대상 | 기존 판정 | 현재 판정 | 조사 범위 밖에 있던 것 |
|---|---|---|---|
| 8일 구간의 1차 기록 | 원천 부재 | 구간 전체가 당대 1차 기록으로 덮인다 | 회사 전자결재 시스템과 클라우드 사본 두 곳 |
| 태그 정리에서 삭제된 문서 12건 | 결손, 성격 불명 | 결손은 실재하고 사료 가치는 0 | 삭제 기준을 하드코딩한 스크립트와 계획 문서 |
| 한 주 구간의 에이전트 세션 원문 | 기록 전무 | 프롬프트 계층만 남음 | 세션 원장 밖의 프롬프트 이력 |
세 건의 원인은 한 줄로 같다. 탐색 범위가 내가 통제하는 기기와 계정으로 암묵 한정돼 있었다.
삭제된 12건은 무엇이 지워졌는지 몰라 결손으로 남아 있었는데, 삭제 대상을 정한 태그 목록 10종이 저장소에 커밋된 채였다. 지워진 것은 테스트 산출물이었고 사료 가치가 걸릴 자리가 처음부터 없었다.
세션 원문 쪽은 원장이 0건이던 2026-07-06부터 07-13까지 구간에 프롬프트 174건이 남아 있었다. 세션 원장이 덮지 못한 계층을 Claude Code가 따로 쌓아두고 있었다.
셋 다 내가 한 번도 열어보지 않은 서랍에서 나왔다. 새로 만들어진 기록은 없다.
사료는 만들어진 자리에 남는다
사료가 왜 다른 표면에 있었는지는 각 기록이 만들어진 자리가 답한다.
전자결재에 상신한 보고서는 승인 시각과 결재선이 찍힌 채 회사 시스템에 남고, 메신저 로그는 메신저의 자동 저장 경로에 쌓인다.
인수인계를 정리하던 마지막 주에 만든 인쇄본과 폴더 사본은 개인 클라우드와 회사 드라이브에 놓였다.
셋 다 만들어진 시점부터 맥북 파일시스템과 GitHub 저장소 밖에 있었다.
그 사본을 만든 것은 나였다.
그런데 석 달 뒤에 부재를 선언하면서 그 사실을 조사 목록에 반영하지 않았다.
기록이 어디에 생기는지를 아는 것과, 부재를 판정할 때 그 자리를 조사 범위에 넣는 것은 다른 절차였다.
판정 라벨에 조사 범위를 붙인다
조사 산출물이 남긴 규약 개정은 두 건이다.
사료 전수의 정의에 제3자 업무 시스템 산출물을 명시한다. 전자결재와 그룹웨어와 메신저 내보내기처럼 결재선과 승인 시각이 찍힌 산출물을 당대 1차 기록으로 인정하고, 부재를 선언하기 전에 먼저 확인한다.
조사 지시서의 원천 목록은 개별 파일 열거 대신 디렉터리 전량 나열로 쓴다. 이번 판정을 뒤집은 결정적 사료는 지시서 목록에 들어 있지 않았다. 조사자가 목록 밖을 보지 않았다면 그 구간은 또 부재로 남았을 것이다.
라벨도 바뀌었다. "부재 확인"으로 종결돼 있던 판정이 "범위 내 부재"로 강등됐고, 판정문에 무엇을 어디까지 조사했는지를 함께 적게 됐다.
범위를 적지 않은 부재 판정은 재검증할 수단이 없다. 다음 사람이 같은 조사를 재현할 수도, 빠진 표면을 지목할 수도 없다.
결론
부재는 관측 범위의 함수다.
같은 구간을 세 계열에서 세고 0을 얻어도, 그 0이 덮는 것은 센 계열까지다.
범위를 적지 않은 부재 판정은 판정이 아니라 인상이다.
석 달 동안 나는 정확한 숫자 위에 그보다 넓은 문장을 얹어두고 있었고, 그사이 8일 구간은 전자결재 13건과 메신저 386건과 인수인계서의 업무 연대기가 이미 덮고 있었다.
한계·재검토 트리거
2026-09 기준 / 재검토 트리거: 아직 열어보지 않은 표면인 전사되지 않은 회의 녹음 2건에서 이 구간을 덮는 새 1차 기록이 나오거나, 조사 범위를 명시한 뒤에 내린 부재 판정이 다시 뒤집히면 이 규칙을 다시 연다.