나의 코딩 에이전트 (coding agent)는 할 일 목록을 가지고 있습니다. 이 목록은 공개된 GitHub 리포지토리 (repo)에 존재하며, 작업당 하나의 이슈 (issue)가 생성되고, 프로젝트별로 라벨 (label)이 붙으며, 에이전트가 작업함에 따라 자동으로 열리고 닫힙니다. 매 세션이 시작될 때 아직 열려 있는 이슈들이 다시 읽혀 들어오기 때문에, 백로그 (backlog)가 세션과 기기를 넘나들며 유지됩니다. 에이전트는 마지막 인스턴스가 멈춘 바로 그 지점에서 작업을 이어갑니다.

오늘 아침, 나는 에이전트에게 그 백로그를 실제 상황과 대조해 보라고 요청했습니다. 현재 프로젝트를 위해 열려 있는 작업은 11개였습니다. 그중 3개는 이미 완료된 상태였습니다. 하나는 5일 전에 끝났고, 나머지 두 개는 생성된 당일 오후에 이미 완료되었습니다. 그것들은 그 이후로 계속

생성 (create) 신호는 자동입니다. 에이전트는 작업을 먼저 생성하지 않고서는 작업을 시작할 수 없습니다. 즉, 작업을 추적하는 행위가 작업을 수행하는 행위와 결합되어 있습니다. 이를 트리거하는 도구 호출 (tool call)은 에이전트가 항상 수행하는 것이기 때문에, 훅 (hook)은 매번 실행됩니다.

완료 (complete) 신호는 자동이 아닙니다. 이는 작업이 이미 끝난 이후에 이루어져야 하는 별도의 선택적인 기록 (bookkeeping) 행위입니다. 에이전트의 주의 (attention)가 다음 작업으로 이동하는 바로 그 순간, 혹은 세션이 종료되는 시점, 또는 사람이 "좋아요, 감사합니다"라고 말하며 대화가 마무리되는 시점에 발생합니다. 이슈 (issue)를 닫는 것은 그 이후의 어떤 단계에도 의존하지 않는 유일한 단계입니다. 그래서 이 단계가 생략되곤 합니다.

결과적으로, 생성은 신뢰할 수 있지만 완료는 손실이 발생합니다. 열려 있는 이슈들이 쌓이는 이유는 작업이 완료되지 않아서가 아니라, 완료하는 것과 완료했다는 것을 기록하는 것이 서로 다른 두 가지 동작이며, 오직 첫 번째 동작만이 실질적인 하중을 견디고 있기 때문입니다.

그 결과, 복구 (restore)를 할 때마다 닫히지 않은 유령들이 마치 살아있는 것처럼 다시 나타납니다. 다음 세션은 이를 성실하게 가져와서, 몇 주 전에 이미 배포된 작업을 다시 검증하고, 만약 아무도 감사 (audit)를 수행하지 않는다면 — 다음번에도 똑같은 일을 반복합니다. 쓰기 편향적 (write-biased) 루프는 단순히 정보를 잃어버리는 것에 그치지 않고, 오래된 정보를 현재의 정보인 것처럼 적극적으로 다시 표면 위로 끌어올립니다.

실제 감사는 어떤 모습이었나

조정 (reconciliation) 과정 자체가 흥미로운 부분입니다. 왜냐하면 "에이전트의 자기 보고 (self-report)는 신뢰할 수 없다"에 대한 해결책은 "자기 보고를 믿지 말고 — 현실을 확인하라"이기 때문입니다.

세 가지 유령 각각은 오직 긍정적이고 외부적인 증거가 있을 때만 닫혔습니다:

• 누군가에게 링크를 이메일로 보내는 작업 → 해당 수신자와 일치하는 제목의 실제 전송된 Gmail 스레드에 의해 확인됨.
• 통화 일정을 잡는 작업 → 참석자가 초대되었고 초대에 needsAction (보냄, 답장 대기 —

1. 완료 신호를 생성 신호만큼 자동화하기 — 생성이 시작과 결합되어 있는 것처럼, "완료되었다고 기록하는 것"을 에이전트가 건너뛸 수 없는 무언가와 결합해야 합니다. 완료는 실제로 작업을 수행하는 것과는 별개의 이벤트이기 때문에 구현하기 어렵습니다.
2. 스스로 보고한 완료를 신뢰하지 말고 현실과 대조하여 검증하기 — 주장된 상태를 다운스트림 관찰 가능 데이터 (downstream observable)와 주기적으로 대조하여, 현실이 루프를 닫도록(close the loop) 해야 합니다.

이 감사는 2번 옵션에 해당합니다: 유령 상태 (ghost state)를 위한 가비지 컬렉터 (garbage collector) 역할을 합니다. 이 방식은 효과가 있으며, 저는 계속 실행할 것입니다. 하지만 이는 근본적인 질병인 쓰기 편향 (write-bias) 자체에 대한 임시방편 (patch)일 뿐입니다. 감사는 누출된 것을 정리할 뿐, 누출 자체를 막지는 못합니다.

한 문장 요약

에이전트는 의도를 신뢰성 있게 발표하지만 완료는 신뢰할 수 없습니다. 이는 작업의 시작은 수행과 결합되어 있는 반면, 완료는 단순한 장부 정리 (bookkeeping)에 불과하기 때문입니다. 따라서 에이전트 자신의 "완료"를 신뢰하는 모든 시스템은 이미 완료된 작업들로 조용히 채워질 것이며, 유일한 해결책은 보고서 대신 현실을 확인하는 것입니다.

Nick Meinhold는 enspyr.co에서 AI 기반 도구를 구축합니다. 여기서 설명된 작업 추적기는 전적으로 Claude Code 세션 훅 (session hooks)에 의해 구동됩니다. 이 포스트의 감사는 Claude가 자신의 백로그 (backlog)를 대상으로 직접 실행하였으며, 스스로 만들어낸 유령 상태들을 찾아냈습니다.