AI가 내 기록을 두 번 지웠다
개인 AI 어시스턴트 런타임을 직접 만들어 굴리는 기록. 3편.
하루치 기록 파일이 있다. memory/2026-07-26.md 같은 이름이고, 그날 무슨 일이 있었는지를 세션들이 append한다. 이게 다음 세션이 어제와 오늘을 파악하는 유일한 경로다.
이 파일이 두 번 잘렸다. 두 번 다 같은 방식이다.
- 세션 A가 파일을 읽는다. 그 시점 내용이 X다.
- 세션 A가 다른 일을 오래 한다. 그 사이 세션 B가 섹션을 append한다. 파일이 X + Y가 된다.
- 세션 A가 자기 기록을 붙이려고 X + Z를 파일에 쓴다.
- Y가 사라진다.
세션 A는 아무 잘못도 안 했다고 생각한다. 자기가 읽은 내용에 자기 것을 붙였으니까. 파일을 지운다는 의사는 어디에도 없다.
처음에는 개별 사고로 처리했다
첫 번째 사고 뒤에 규칙을 적었다. "기록 파일은 append만 한다."
두 번째 사고가 났다. 같은 방식으로.
한 번은 노이즈고 두 번은 패턴이다. 두 번째에는 규칙을 적는 대신 규칙을 구체화했다.
기록 파일은 append-only다. 쓰기 직전에 다시 읽고, 최신본 끝에 섹션을 append한다. 세션 초반에 읽어둔 구본 기반으로 파일 전체를 쓰는 것을 금지한다. 기존 섹션을 수정해야 하는 경우에도 삭제나 재작성이 아니라 정정 라인을 append한다.
마지막 문장이 처음에 없던 부분이다. "기존 내용이 틀렸다"는 상황에서 사람은 자연스럽게 그 부분을 고치려 한다. 그런데 고치려면 전체를 다시 써야 하고, 전체를 다시 쓰는 순간 같은 사고가 난다. 그래서 정정도 append로 한다. 파일 아래쪽에 "위 섹션의 판정을 정정한다"고 쓰는 게 위쪽을 고치는 것보다 안전하다.
읽기 불편해진다. 대신 안 사라진다. 나는 후자를 골랐다.
복구 절차
이미 잘린 파일을 복구하는 표준 절차도 정했다. git의 최신 커밋본과 현행 작업본을 합집합으로 병합한다.
잘린 사고에서 좋은 소식이 하나 있다. 커밋이 잦으면 잘린 부분이 대개 어느 커밋에는 남아 있다. 이틀에 커밋 41개가 나오는 저장소에서는 손실 창이 몇 분에서 몇십 분 수준이다.
그래서 규칙이 하나 더 붙는다. 중간 규모 이상의 작업이 끝나면 즉시 커밋한다. 커밋 빈도가 복구 가능성이다.
규칙은 여전히 문서에 있다
여기가 이 글의 정직한 부분이다. 위 규칙은 전부 문서 규칙이고 기계 강제가 아니다.
Claude Code 문서의 표현을 빌리면 이렇다. 훅은 결정론적이고 문서 지시는 권고다. 권고는 컨텍스트가 길어지면 묻힌다.
그러니 이 규칙이 세 번째 사고를 막을 것이라는 보장이 없다. 실제 처방은 도구 호출 단계에서 막는 것이다. 기존 내용이 줄어드는 쓰기를 거부하는 훅. 파일 크기나 줄 수가 감소하는 write를 실행 전에 차단하고, 정말 줄여야 하면 명시적 플래그를 요구한다.
아직 안 만들었다. 그래서 이 항목은 열린 구멍으로 남겨두고, 열려 있다는 사실을 적어둔다.
같은 계열의 두 번째 사고: 개행 문자가 셸 스크립트 아홉 개를 깼다
파일 무결성 사고가 하나 더 있었다. 성격이 다르다.
런타임 정리 작업 중에 파이썬으로 텍스트 파일 여러 개를 일괄 수정했다. write_text를 썼다. 그리고 셸 스크립트 아홉 개가 통째로 깨졌다.
원인은 개행 문자다. 파이썬의 기본 텍스트 쓰기가 이 호스트에서 LF를 CRLF로 변환했다. 저장소는 core.autocrlf=false로 LF를 보존하도록 설정돼 있다. 두 설정이 충돌하면서, 셸 스크립트의 모든 줄 끝에 캐리지 리턴이 붙었다.
셸은 그 캐리지 리턴을 명령의 일부로 읽는다.
다행히 bash -n으로 문법 검사를 돌리는 습관이 있어서 즉시 잡혔다. 바이트 단위로 복구했다.
여기서 나온 규칙. 이 호스트에서 텍스트 패치는 write_bytes로 한다. 그리고 셸 스크립트를 건드린 뒤에는 bash -n을 돈다.
이 사고가 앞의 사고와 같은 계열인 이유가 있다. 둘 다 "쓰기 도구가 내가 의도하지 않은 변형을 가한" 사고다. 하나는 컨텍스트의 낡음 때문이고 하나는 인코딩 기본값 때문인데, 결과는 같다. 내가 쓰려던 것과 파일에 들어간 것이 다르다.
정본과 미러: 미러가 정본보다 더 알면 사고다
파일 무결성의 다른 축이다.
같은 정보가 여러 파일에 있으면 어긋난다. 그래서 정본을 하나 정하고 나머지는 미러로 쓴다. 미러에는 상태를 복제하지 않고 링크만 둔다.
그런데 실제 사고는 반대 방향으로 났다. 미러 쪽에 정본에 없는 정보가 생겼다.
작업 폴더에 산출물이 만들어지면 그 폴더가 사실상 "이 일이 진행 중이다"라는 상태를 갖게 된다. 그런데 정본 표에는 그 항목의 행이 아직 없었다. 완료되면 등재하려고 기다린 것이다.
결과적으로 두 건이 정본에서 통째로 빠졌고, 그중 하나는 살아 있는 항목이었다. 정본만 읽는 질의에는 존재하지 않는 항목이 된 것이다.
규칙 둘이 여기서 나왔다.
하나. 미러가 정본보다 더 알게 되는 순간이 사고다. 작업 폴더에 산출물이 생기면 그 즉시 정본에 행을 만든다. 완료를 기다리지 않는다.
둘. 임시 로그는 원천이지 종착지가 아니다. 분류 작업의 중간 파일에 살아 있는 항목이 있으면 그날 정본으로 올린다. 정본에 없으면 없는 것이다. 질의는 정본만 읽으니까.
변동 데이터는 눈으로 재스캔하지 않는다
마지막 항목이다. 이건 사고 계보가 가장 길다.
100행이 넘는 목록을 주기적으로 확인해서 새 항목을 찾는 일이 있었다. 매번 훑었다. 그리고 새 항목이 계속 미끄러졌다. 몇 주 동안 못 본 항목이 여러 건 나왔다.
사람이 100행을 매번 정확히 비교할 수 있다고 가정한 게 잘못이다. 처방은 구조를 바꾸는 것이다.
- 누적 레지스트리와 diff. 본 항목의 식별자를 파일에 쌓고, 매 실행마다 차집합만 뽑는다.
- 첫 등장 강제 노출. 새 항목은 무조건 눈에 띄게 출력한다. 목록에 섞어 놓지 않는다.
- 전건 판정 의무. 새 항목은 하나도 남기지 않고 판정한다. "나중에 볼 것"은 판정이 아니다.
- 보류 항목 재방문 트리거. 판정을 미룬 항목에 재방문 시점을 걸어둔다.
이걸 만들고 나서는 누락이 안 났다. 사람의 주의력에 의존하는 감시를 기계의 차집합으로 바꾼 것뿐이다.
남은 질문
이 글에 나온 사고들의 공통 구조가 하나 있다. 전부 "그럴 의도가 없었는데 일어난 일"이다. 기록을 지울 의도가 없었고, 개행을 바꿀 의도가 없었고, 항목을 누락할 의도가 없었다.
의도가 없는 사고는 의지로 막을 수 없다. 더 조심하겠다는 결심으로는 세 번째가 안 막힌다. 막으려면 그 행동이 물리적으로 어렵거나, 일어났을 때 즉시 드러나야 한다.
그래서 운영의 대부분이 규칙을 잘 쓰는 게 아니라 규칙이 안 지켜져도 사고가 안 나는 구조를 만드는 일이라는 걸 지금은 안다.
물어야 할 건 이거다. 내 규칙 중에 기계가 지키는 건 몇 개이고 사람이 지키는 건 몇 개인가? 후자가 대부분이면 그 규칙들은 아직 규칙이 아니라 희망이다.