낡은 TODO 를 급한 일로 보고받았다 — git status

프로젝트 문서에 「아직 안 됐다」고 적힌 줄을 읽고, 그게 지금도 안 돼 있다고 믿는 일이 있다. 보통은 맞는데 이번엔 5일 전에 이미 끝나 있었다.

2026-08-05, 유튜브 영상 하나를 번역 앱(눈치코치)에 붙일지 검토하던 중이었다. 클로드가 그 프로젝트 볼트 문서를 읽고 「다음 액션」 절을 근거로 들었다.

🔴 배포가 밀려 있다 (7-29 저녁 → 7-30 에 더 쌓였다) — 마이그레이션 4건은 운영 DB 에 이미 들어갔는데 앱 코드가 안 올라갔다. 오래 두지 말 것.

바로 아래 줄엔 "배포할 때 Vercel 환경변수 ADMIN_EMAILS·CRON_SECRET 을 같이 넣는다" 가 있었다. 클로드는 이 둘을 지금 급한 미해결로 보고했고, "마감이 7일 남았는데 배포가 밀려 있다" 를 새 기능을 넣지 말자는 근거 중 하나로 썼다.

읽다가 걸렸다.

"배포 밀린게 뭔말이야? 지금 푸시할거 하나도 없는데?"

레포를 실제로 조회하니 워킹트리 깨끗, 푸시 안 한 커밋 0건, 마지막 커밋은 7-31 20:43 이었다. Vercel 은 푸시가 곧 배포라 7/31에 이미 나가 있었다. 볼트의 그 줄은 7/29~30에 쓴 것이다.

정정하고 나서 다음 줄도 물었다.

"ADMIN_EMAILS·CRON_SECRET도 옛날에 완료했는데..?"

한 항목에서 두 줄이 같이 낡아 있었다.

「취소선을 안 그었다」가 원인인 줄 알았다

처음 떠오른 원인은 쓰는 쪽 문제였다. 끝냈는데 문서에 취소선을 안 그었다는 것. 그러면 처방도 뻔하다 — 끝내면 그 자리에서 문서를 고치자.

그런데 그 문서를 다시 열어보니 맨 위에 이미 이렇게 달려 있었다.

<!-- 완료된 항목은 지우지 말고 ~~취소선~~ → 실제 로 남긴다
     (같은 판단이 되살아나는 걸 막는다). -->

규칙은 있었다. 있는데 7/31에 안 걸렸다.

여기서 판단이 갈렸다. 같은 규칙을 더 크게 쓰거나 한 번 더 강조하는 건 답이 아니다. 이미 그 문서 맨 위에서 강조되고 있었으니까. 쓰는 쪽이 뚫린 게 문제가 아니라, 읽는 쪽에 방어가 아예 없었던 점이 문제였다.

🔴 가 붙어 있어서 확인이 더 밀렸다

왜 확인을 건너뛰었는지도 그제야 보였다. 그 줄엔 🔴 가 붙어 있었다.

급해 보이니까 빨리 전해야겠다는 쪽으로 작동해서, 확인이 오히려 뒤로 밀렸다. 표시가 강할수록 검증을 건너뛰게 만든다는 게 뒤집힌 부분이다.

한 가지 더 있었다. 정정하려고 같은 문구를 검색해보니, 그 낡은 문장이 원본 문서 말고 그날 새로 쓴 노트에도 이미 옮겨져 있었다. 낡은 사실을 읽으면 그걸 인용한 문서가 그 자리에서 하나 더 생긴다.

읽는 쪽 규칙을 새로 만들었다

원본 문서 — 두 줄에 취소선을 긋고 실측 결과(7-31 푸시로 해소, 미커밋 0)를 붙였다. 그리고 오늘 이 사고가 났다는 것 자체를 그 자리에 적었다. 안 적으면 또 난다.
베낀 곳 — 그날 새로 쓴 노트에서도 같은 문장을 빼고, 왜 틀렸는지 한 줄 남겼다.
~/.claude/rules/collaboration.md 에 규칙을 하나 추가했다.

문서에서 꺼낸 「상태」를 현재 사실로 말하려는 순간이 실측 시점이다. "밀려 있다"·"화면에 보인다"·"안 돼 있다"·"N건 남았다" 는 쓰인 날의 사실이지 오늘의 사실이 아니다. 확인 비용은 대개 명령 한 줄이다 — git status, grep. 🔴 급해 보일수록 실측한다.

원래 갖고 있던 규칙과 같은 병이라는 것도 같이 적어뒀다 — "기억에서 꺼낸 버전·가격·API 는 쓰기 전에 검색한다". 출처가 기억이냐 문서냐가 다를 뿐, 둘 다 낡았을 때 그 느낌이 안 온다는 게 똑같다.

이제 방어가 두 겹이다. 쓰는 쪽(끝내면 그 자리에서 긋는다)은 원래 있었고 뚫렸으니, 읽는 쪽(말하기 전에 실측한다)이 마지막 관문이다.