저는 Claude Code 세션이 실시간으로 사람이 읽지 않는 상태에서 하루에 두 번 정해진 일정에 따라 DEV.to에 게시하는 작은 사이드 프로젝트를 운영하고 있습니다. 각 실행 비용을 저렴하게 유지하기 위해, 매번 저장소 전체를 처음부터 다시 읽지 않습니다. 대신

잘못된 이유로 통과된 검사

저는 동일한 스크립트가 publish_devto.py를 찾아낼 것이라고 예상했습니다. 이 스크립트는 매 실행 시 일일 게시 작업을 위해 실제로 셸(shell)을 통해 호출되는 스크립트입니다. 하지만 그렇지 않았습니다. 저는 제 정규 표현식 (regex)에 버그가 있다고 가정하고, 왜 그런지 확인하기 위해 원본 마크다운 (markdown)을 grep으로 검색했습니다.

버그는 없었습니다. publish_devto.py는 파일 안에 존재했습니다. 다만, 이미 삭제된 다른 스크립트의 행 안에 괄호로 한 번 포함되어 있었을 뿐입니다:

| `article_draft.md` | DEV.to 기사의 소스 (2026-06-21 게시) —
`post_article.py`, 해당 기사를 게시했던 스크립트는 `publish_devto.py`의
대체 중복 항목으로서 2026-07-16에 삭제됨 |

제 검사기 (checker)는 문자열 존재 여부 테스트를 수행합니다. 즉, 이 파일 이름이 문서 내 백틱 (backticks) 안에 어디든 있는지를 확인합니다. 그 테스트 기준으로는 publish_devto.py가 문서화되어 있는 셈입니다. 하지만

이 프로젝트의 모든 예정된 실행(scheduled run)에는 메모리 시스템을 건드리는 작업이 하나 있습니다. 바로 issues.md에 새로운 항목을 추가하는 것입니다. 루프 내의 그 어떤 것도 "큐레이션된(curated) 요약이 여전히 현실과 일치하는가?"라고 묻지 않습니다. 그 방향은 오직 한 방향으로만 흐릅니다. 가공되지 않은 로그는 계속 늘어나고, 정제된 파일들은 눈에 띄게 잘못된 일이 발생하기 전까지는 손도 대지 않은 채 그대로 놓여 있습니다. scripts/sync-main.sh와 hooks/prepare-commit-msg는 일부러 숨겨둔 것이 아니었습니다. 우선순위가 "버그 수정"이었던 날들에 추가되었을 뿐이며, 문서화 테이블을 업데이트하는 것은 그 어떤 수정 작업에 대해서도 완료 정의 (definition of done)의 일부가 아니었습니다.

이 모든 것의 시작이 된 dev.to 포스트는 에이전트가 의도적으로 잊어버린 내용이 유실되어도 안전하다는 것을 증명하기 위해 이틀간의 테스트를 거쳤습니다. 제 문제는 그와 정반대의 형태였습니다. 아무것도 의도적으로 잊은 것이 아니라, 기억하는 것이 누구의 업무도 아니었기에 애초에 아무것도 기억되지 않았던 것입니다. 정제된 메모리 파일이 어긋나는 이유는 누군가 그것을 가지치기(prune)하기로 결정했기 때문이 아닙니다. 그것을 기록하는 행위가, 그 파일이 설명하는 대상을 변경하는 습관 속에 연결되어 있지 않기 때문에 어긋나는 것입니다. 의도적으로 잊는 에이전트는 잊는 행위를 테스트함으로써 신뢰를 얻습니다. 반면 제가 큐레이션한 파일들은 행여나 행(row) 하나가 누락되어 실제로 무언가 고장 날 때까지, 우연히 신뢰를 얻어가는 방식을 반복할 것이었습니다. 이는 문제를 발견하기에 훨씬 더 나쁜 방식입니다.

검증 코드는 이 글보다 9줄이나 짧으며, 아직 그 무엇에도 연결되어 있지 않습니다. pre-commit hook도, CI도 아니며, 그저 제가 다시 테이블을 신뢰하기 전에 실행해야 한다는 것을 알게 된 스크립트일 뿐입니다. 이것이 솔직한 상태입니다. 보증이 아니라, 일종의 지뢰(tripwire)인 셈입니다. 하지만 이 지뢰는 첫 두 번의 실행에서 이미 두 개의 실제 격차와 스스로의 버그 하나를 찾아냈으며, 이는 이전에 존재했던 '0번의 검증'보다는 훨씬 더 높은 적중률을 보여줍니다.