저장했다는 보고는 저장의 증거가 아니었다

질문

기록 18건을 저장했다.
보고는 성공이었고 저장된 것은 0건이었다.

원인은 금방 나온다. 실패가 예외로 올라오지 않았다.
남는 질문은 하나다.
호출이 성공을 반환했다는 사실은 무엇의 증거인가?

판정

쓰기의 성공은 호출자의 반환값이 아니라 호출자 바깥의 독립 계층에서 확인한다.

그날 저장 시도는 18건이었고 성공은 0건이었다.
호출은 예외를 던지지 않았고 에이전트는 18건을 저장했다고 보고했다.
실패 형태는 0초 abort다. 죽은 취소 신호가 브리지를 건너오면서 호출이 시작되자마자 끊겼다.
끊긴 호출은 조용히 닫혔고, 호출자는 닫힘을 완료로 읽었다.

발각은 사람의 지적이었다.
기록이 남았느냐고 물어본 사람이 있어서 열어봤고, 열어보니 없었다.
도구는 자기가 실패했다고 말할 능력이 없었고 그 자리를 사람이 메웠다.

근거

반환값은 도착의 증거가 아니다

호출자가 돌려받는 값은 요청이 도착했다는 보고가 아니라,
호출을 시작한 쪽이 자기 상태를 어떻게 읽었는지에 대한 진술이다.
그 진술은 거짓도 아니었다. 호출자 관점에서는 예외도 대기도 없었다.

같은 사건을 세 계층에서 열어본 결과

호출 계층 - 반환값 성공, 예외 없음, 소요 0초
브리지 계층 - 죽은 취소 신호를 그대로 넘김
도구 계층 - 저장 요청이 도착한 기록 없음

세 줄은 서로 모순되지 않는다.
호출 계층만 보면 성공이 맞고, 도구 계층까지 내려가야 0건이 보인다.

실패를 던지게 고쳐도 순서는 남는다

재발 방지로 죽은 신호를 걸러내는 가드를 넣고 실패를 조용히 삼키는 대신 던지도록 바꿨다.
메모리뱅크 상시 사용도 에이전트 지침에 명문화했다.

이 가드는 이 실패 형태를 막는다. 다음 실패 형태를 막지는 않는다.
같은 달에 이 스택 자체가 2주 동안 조용히 내려가 있던 것을 뒤늦게 발견한 일이 있었다.
그때도 아무것도 던지지 않았고, 재발은 재시작 정책으로 막았다.
막는 방식이 매번 다르다는 것이 무음 실패의 성질이다.
그래서 개별 형태를 잡는 것과 별개로 확인하는 자리를 배선에 둔다.

증거는 쓴 쪽이 아니라 받은 쪽에 있다

복구는 단순했다. 권한 토큰으로 직접 API를 호출해 18건을 다시 넣었다.
중요한 것은 그 뒤였다.

쓰기 성공의 판정 기준 셋

호출자의 반환값 - 성공 18건, 실제 저장 0건
게이트웨이 접근 로그 - 요청 도착 18건, 응답 200
역방향 조회 - 표본 5건 질의, 5건 HIT

첫 줄은 쓴 쪽의 기록이고 나머지 둘은 받은 쪽의 기록이다.
접근 로그는 에이전트가 손댈 수 없고, 역방향 조회는 저장이 도착하지 않았으면 비어서 돌아온다.
셋 중 어긋난 것은 첫 줄뿐이었다.

한계·재검토 트리거

사건은 1건이다. n=1이고 배선도 하나다.
이 판정은 무음 실패 일반을 막는 대응책이 아니다.
쓰기 성공을 호출자 반환값으로 판정하던 지점 하나를 옮기라는 것이다.

되읽기가 싼 조건도 붙는다. 저장 단위가 18건이라 표본 5건을 즉시 확인할 수 있었다.
쓰기가 초당 수천 건이면 표본 설계부터 다시 해야 한다.

2026-09 기준 / 재검토 트리거: 실패를 던지도록 고친 뒤에도 독립 계층 확인과 호출자 반환값이 어긋나는 사례가 한 건이라도 나오면 이 판정을 다시 연다.